А меня всегда умиляют в постах про *nix софт ссылки для скачивания.
Все равно все пользуются пакетными менеджерами. Я, по крайней мере, искренне в это верю.
А пусть не умиляет, далеко не все дистрибы имеют репо, где собирают последние версии софта. А в репах по умолчанию в принципе такого софта нет.
Гигантского количества софта нет в репах, даже дополнительных, например вчера пытался найти репу для центоса с gpac.
А почему вы решили что не участвует? Вроде никто не запрещает смотреть на любом языке и использовать субтитры если ты язык не понимаешь.
Чем для юзера по большей то части отличается онлайн стриминг от просмотра скачанного файла? Только тем что онлайн это сразу, а скачать надо подождать.
Умеет переключать звуковые дорожки? Вы уверены? Я недавно как раз занимался исследованием этой темы, о подобной возможности никто не слышал. Что-то за последнее время поменялось? А то даже были мысли отдельно отдавать звук в роликах, чтобы не хранить для каждой звуковой дорожки еще и копию видеопотока для просмотра онлайн?
> Никаких преимуществ в использовании mp4 как контейнера перед flv я не нашел.
Я вижу минимум одно — если у вас видеосервис поддерживает HTML5 и Flash, то вам приходится держать видео в трех форматах — webm, mp4 и flv, если у вас сервер Nginx и нет стриминга для mp4 (по разным причинам).
Теперь же можно оставить только mp4 и webm, экономия места на лицо.
очень просто. Если вы взяли h264/aac и запаковали это в flv, то с 95% вероятностью вы потеряли этот контент для Apple устройств.
HLS _требует_ разрешения времени большего, чем дает flv. В адобовском формате требуются миллисекунды, а в MPEG-TS счет идет на доли микросекунды, соответственно если вы попробуете без дополнительных мер порезать свой flv контент, то получите квавающий звук и дергающееся видео.
Спасибо эпплу за хороший код, а адобу за удачный дизайн.
Я дико извиняюсь, но не могли бы вы пояснить людям не столь приближенным к тонкой настройке nginx в чем собственно заключается сказка? Хоть какие-то цифры, сравнения или примеры.
На мой взгляд с выходом HTTP Dynamic Streaming больше года назад для Flash проблема подбора медиа сервера отпала. Можно собрать схему для отдачи видео контента при помощи Apache (получение сегментов из файла) и NGINX (кеширующий proxy) — в итоге получается надежное и бесплатное решение с неограниченными возможностями масштабирования. Apache вытягивает чанки, а NGINX их очень быстро раздает из своих кешей.
Вот если бы Adobe для NGINX написала такой модуль :-) Можно было бы обойтись одним веб сервером.
Уж что то а держать апачи на сервере грешно, если конечно у вас не 10 пользователей онлайн.
Оно и раньше было бесплатное стоит нгинкс и стримит mp4 без всяких апач.
Сколько вы думаете гигабит потянет ваша связка на апаче + nginx на одном сервере?
Они отлично кешируются в NGINX. Творение Сысоева очень хорошо кеширует все, что через него проходит :-) По сути это HTTP payload размеров в пару мегабайт.
Не понимаю например у меня 100 террабайт видео, ну скажем одинаково популярных кусков 1 террабайт, куда nginx их закеширует?
Когда мелкое файло все понятно, с крупным я не вижу хороших механизмов кеширования, чтобы они давали хороший выхлоп.
Почему связка с апачи должна быть быстрее чем просто nginx?
Просто NGINX отдает файл лишь после полной загрузки / считывания. Могу ошибаться, но насколько я помню около года назад было именно так.
Apache модуль решает эту проблему и отдает кусок файла без его полного считывания.
Но это даже не самая главная причина. HTTP DS формат видео опубликованный Adobe — F4V — разбирается лишь их модулем для Apache. Поэтому все его и используют.
PS
Куски делают по несколько мегабайт. Если у Вас 100 Тб видео, то для эффективного кеширования и доставки не с системы хранения данных, а из кешей, Вам нужно много NGINX серверов с суммарным объемом жестких дисков 100 Тб.
Не встречал вебсервера, которые бы не могли отдать кусок файла произвольно.
Модуль апачи как и в nginx решает проблему перехода на произвольный кусок файла не по номеру байта, а по заданной секунде воспроизведения, то есть включает перемотку в произвольное место во флешплеере и переход к нужному ключевому кадру.
Кто именно всего его использует то? Просто я не встречал таких в природе пока что.
А почему я не могу сделать все на одном сервере? Ведь это дешевле чем много серверов? Можете привести пример как именно nginx кеширует отдачу по ключевым кадрам mp4? Я просто не понимаю этот механизм.
А это как раз и сделано для HTTP Dynamic Streaming. Где то даже на хабре была статья на эту тему. Прежде всего это дает возможность динамически переключать качество при переходе на следующий кусок. Ну и кусками управлять в кешах легко. В кеше оседают самые популярные куски только.
Ну а что мешает без кусков переключать качество?
По вашей ссылке в кешу нгинкса вообще куски по 4к, не уверен что там будут самые лучшие куски и это лучшая политика кеширования.
Попробую настроить это на nginx и посмотреть что вывалится в nginx.
По идее ничего не мешает. Просто в стандартных Framework'ах для Flash Player'а не реализована работа с динамическими потоками при передаче через HTTP PD. OSMF — который продвигается Adobe как основное средство для создания видео плееров, да и Strobe Media Playback — видео плеер Adobe на базе OSMF, поддерживают переключение качества лишь при HTTP DS.
Хотя никто не мешает сделать свой фреймворк и реализовать работу с переключением качества и при HTTP PD передаче.
Я в последнее время стараюсь использовать Strobe Media Playback. В него Adobe добавляет самые последние фичи и относительно оперативно баги правит.
Хотя конечно JW и другие тоже очень даже хороши и действительно поддерживают всякие варианты переключения. Началось это все после того, как Adobe в AS3 опубликовала возможность добавлять байты в мультимедиа поток (NetStream). Теперь видео можно хоть по сокету получать, хоть по P2P сети. Flash Player все отобразит.
А разные звуковые дорожки вы как держите?
Выше в комментариях написано что приходится держать два файла и по сути удвоение размера для наличия двух дорожек.
Она решена в последней версии OSMF — 1.6 (т.е. на стороне видео плеера), но требует использования HTTP DS на уровне сервера. Позволяет в плеере переключаться между разными аудио дорожками и не нужно хранить видео под каждую дорожку. Думаю дня через три в нашем блоге будет подробный отчет как это сделать с примерами кода видео плеера.
Только что в блог закинул статью про реализацию поддержки аудио дорожек. Реализация не самая технически продвинутая, но зато простая и эффективная. Статья в нашем блоге
Такая связка тянет десятки гигабит (не на одном сервере конечно). Adobe опубликовала бесплатный HTTP Dynamic Streaming модуль лишь для Apache. Такую архитектуру используют очень многие проекты. Например, BBC в своем блоге описывает процесс тестирования HD трансляций на основе HTTP DS доставки. Они используют Apache.
Кстати, Apache вовсе не обязательно высовывать наружу. Он может висеть на внутреннем порту или вообще во внутренней подсети.
Глядя на модуль ngx_http_mp4_module, думается что по всей видимости скоро и вместо радио-сервера(типа Icecast2/Shoutcast) можно будет использовать любимый nginx.
Я и так сейчас nginx'ом проксирую потоки Icecast'а, подставляю в юзерагент еще и город, страну через модуль geoip.
Думаю можт взяться и написать модуль Icecast для nginx чтобы nginx сам стал радиосервером и соответсвовал стандартам протокола Icecast.
Попробовали на одном из проектов, столкнулись с проблемой, что плеер начал проигрывать файл после полной загрузки. Ничего страшного для небольшого ролика и широких каналов, но когда речь идет о 100 мб и более время ожидания превращается в критичное… Пришлось вернуться к старым добрым костылям.
В nginx появился нативный модуль стриминга mp4