Pull to refresh

Comments 33

Я почему-то подумал 24*365*8 — это разрешение*цветность.
Особое разрешение для азиатов.
Ненавижу этот сервис: у меня видео с мыла вечно тормозит, каким-бы мощным не был комп и какая ось-бы на нём не стояла!!!
При этом с Ютумбы — всё более чем Ок!
Читая такие статьи понимаешь, что не боги горшки обжигают. Спасибо за рассказ.
вам теперь воткнуть наш flussonic в раздачу и 10-20 гигабит с сервера всякого стриминга HLS/HDS сможете хоть завтра раздавать =)
боюсь, упрутся в not invented here =)
Еще могут упереться в то, что эффективность у nginx, мягко говоря, не хуже. Зато бесплатно, продукт хорошо изучен и работает. И если очень надо стримминг, логичнее пообщаться с nginx.com тогда уже или свой модуль сделать.
Это вы серьезно про «если очень надо стримминг» и «свой модуль»?
Роман Арутюнян уже все сделал.
а какое отношение rtmp стриминг имеет к файловому видеохостингу?
Я, признаться, тоже не понял, зачем предыдущий комментатор вообще nginx упомянул, если можно просто взять flussonic :D Все равно придется брать, когда дорастет до нормальных потоков. Другое дело, что не все до них дорастают :)

Но и писать для nginx очередной hls тоже нет смысла, он там уже есть.
у nginx вроде есть файловый стриминг, но он не в открытом модуле Ромы, а в платной версии nginx.

Платность, безусловно, не проблема для тех, кому надо стримить, а не играться, но сам модуль nginx-rtmp для файлового хостинга не особо в помощь.

Подразумевалось, что если человек не знает о существовании nginx-rtmp, он и про ngx_http_hls_module из nginx plus вряд ли слышал :) А если бы знал, то не стал бы рассуждать о том, что «свой сделать», ибо вряд ли дешевле выйдет :)

Граждане, которым поиграться, обычно настолько жадные, что «заранее ffmpeg'ом» порежут на куски и index.m3u8 им же сделают. О чем видимо товарищ и хотел нам рассказать, когда писал «что эффективность у nginx, мягко говоря, не хуже. Зато бесплатно, продукт хорошо изучен и работает» :)
1. nginx проверенный на большом количестве проектов и серьезной производительности (80Гбит с сервера).

2. В мейле есть люди (catap, например), которые написали много разных модулей под nginx и его им будет гораздо проще заточить под себя, чем flussonic или другой аналогичный продукт.

Догадки о том, чего я знаю а чего нет, высказывать не обязательно, они не особенно полезны. Платный nginx я упомянул сразу, при количестве серверов больше сотни вполне может быть дешевле написать свой модуль. Нам разработка модуля (с чуть другими задачами, но тоже дополняющим nginx до медиасервера) обошлась 2.5 человекомесяца работы Сишного разработчика. Работает в продакшене, отлично держит нагрузку 30-40 Гбит, вероятно потянет и 80, не тестировали пока в таком режиме.
Так, что ничего такого нет в написании своего модуля.
И ведь не поленился же минус в карму поставить.
Может люди такие там и есть, не знаю. Но я не там уже более 5 лет :)
а ну живо вернись обратно и нахерачь пару модулей для тыптыща!
Макс, зачем для этого возвращаться? :)

В любом случае мой email ты знаешь ;)
мне было бы интересно посмотреть на 10-гигабитный _стриминг_ файлов nginx-ом.

Для flussonic сегодня это не проблема на разных конфигурациях.
Если я вам покажу 80 гбит на nginx стандартной конфигурации с одного сервера, закроем тему?
меня интересует не псевдостриминг, а стриминг.

Псевдостриминг вполне годится для раздачи порнороликов размером 320x240, но для чего-то поприличнее уже не годится.
Как скажете, не годится так не годится;)
вообще, nginx справляется с задачей микширования дорожек на лету на скорости десятки гигабит при тысячах подключений. Почему он не справится с задачей, условно, нарезки файла на части, для меня загадка.
смотрите, какая проблема есть у nginx: общей памяти между воркерами нет, поэтому для отдачи сегмента надо либо на каждый запрос прочитывать moov и выгребать информацию по дорожкам, либо в каждом воркере поддерживать кешированную информацию из moov, т.е. солидный перерасход памяти.

В nginx-rtmp из-за мультипроцессности есть серьезные архитектурные сложности, которые в том же evostream решались не один год.
Мы используем второй вариант, сервер с 32Г памяти вполне уверенно держал 12К коннектов при 20Г исходящего трафика. В системе было 16 воркеров.

Сколько тот moov весит, чтобы вызывать солидный перерасход памяти? десяток килобайт? При 10К коннектах, это максимум 100МБ на воркер или 1.6Г. Не так и много.

С другой стороны, в другом модуле (расширенной статистики) у нас реализован механизм шаренной памяти между воркерами. При необходимости это нескожно портировать и в муксер. Надобности небыло, на практике там это все дело выше 300-500МБ никогда не жрало.

У nginx в коммерческой версии есть официальные модули для стиминга. Я их не крутил, к сожалению, но очень сомневаюсь, что они бы выпустили неэффективное решение, судя по их подходу в опенсорс версии.
~5 (точно не помню, это оценка сверху)
Спасибо, очень интересно! А внешние CDN планируете использовать?
про CDN много уже сделано, и в планах есть еще, в статью не влезло
Сколько же боли в этих строчках. Ощущение, что вы не создавали крутой продукт, а вечно боролись с чем-то и пытались запрыгнуть на уходящий поезд.
vjp — а что находится внутри компонента Transcoder Daemon? обвязка вокруг ffmpeg?
Sign up to leave a comment.