Задать вопрос
filnor
@filnor
¯\_( ツ)_/¯

Как правильно хостить и проигрывать видео в 2020?

Добрый вечер!
Мы недавно реализовали проект фестиваля, на сайте которого можно было посмотреть полнометражные фильмы.
В целом все прошло хорошо, но сейчас очень остро стоит вопрос относительно технологий которые для этого использовались, потому что очень явно ощущается, что что-то пошло не так, а на горизонте уже маячат похожие проекты.

Начитавшись того, как "правильно" должна выглядеть подобная реализация, решили заюзать эпловский HLS.
Конвертнули все видео-дорожки для разного качества при помощи ffmpeg. Разбили все файлы на видео-аудио дорожки при помощи mediafilesegmenter, mediasubtitlesegmenter - создали плейлисты при помощи variantplaylistcreator.
Получили класный master.m3u8 файл плейлиста, где все эти конфиги были красиво описаны.
И вроде бы на клиенте получаем полностью работоспособную систему, которая отлично работает... но не тут то было.

Когда на проект запустили пользователей - массово посыпались жалобы, у кого-то не грузит видео, кто-то ловит ошибки декода (chunk_demuxer_error_append_failed append stream parsing failed) у кого-то видео зависает на каких-то этапах и на отказ перестает грузиться. Это при том, что в первый день онлайн был не более 200 одновременных просмотров, а нагрузка по трафику из доступных 3гб\сек не превышала и 1\3.
Другими словами, пошла какая-то лажа.

Так как делать нужно было что-то срочно, решили от m3u8 файлов отказаться и перейти на отдачу цельных файлов сразу. В конфигах просто прописали ссылки на mp4 файлы, в которых сразу находилось всего одна аудио и видео дорожка. И чудо - все ошибки сразу пропали.
То есть получается, что отдача одним файлом и браузерный декод, вышли намного эффективнее чем то, что мы делали через HLS. ¯\_( ツ)_/¯

Мы посмотрели кучу стриминговых сервисов, большая часть из них отдавала все свои стримы в формате m3u8, и никаких проблем при этом люди не испытывали. Соответственно назрела куча вопросов о том, как таки стоит делать и в чем могла быть ошибка и как это исправить на будущее.

1) Как правильно хостить файлы на сервере? Нужна ли разбивка при помощи HLS\DASH? Где-то видел что эти технологии нужно использовать в паре, так как каждая из них имеет свою браузерную поддержку.

2) Должны ли быть на сервере какие-то специфичные настройки, для эффективной отдачи статического медиа-контента?

3) Медиа-плеер. Возможно, причина ошибок связана с плеером, который использовали на клиенте? Мы использовали https://flowplayer.com/.
Наслышан о таких плеерах, как Movie.js Shaka Player, jwplayer - возможно есть смысл попробовать какой-то из них? Плеер не обязательно бесплатный, просто хочется использовать технологию, которая сможет дать максимальное покрытие. Например, в этом проекте, люди заходили с телевизора, а на tizen flowplayer не работал, от слова совсем.

4) Шифрование\защита файлов. Как по мне отдача чистых mp4 файлов, небезопасна от слова совсем. Понятное дело, что собрать готовый файл с плейлиста, можно одной командой из ffmpeg, но в той реализации которая вышла, достаточно просто открыть дев. тулзы и получить прямую ссылку на файл который можно сохранить себе на пк.

Помогите на будущее делать хорошо :)
  • Вопрос задан
  • 2291 просмотр
Подписаться 37 Средний Комментировать
Решения вопроса 3
ValdikSS
@ValdikSS
То есть получается, что отдача одним файлом и браузерный декод, вышли намного эффективнее чем то, что мы делали через HLS. ¯\_( ツ)_/¯
Разумеется.
HLS для VoD используют в двух случаях:
1. Если нужно, прямо необходимо, автоматически подстраивать качество видео, не выбирая его руками;
2. Если нужно шифровать куски видео для каждого клиента индивидуально (DRM).

В остальных случаях, особого резона использовать HLS/DASH нет, т.к. для воспроизведения в браузере он требует media source и javascript-плеер, а обычное HTML5-видео — нет.

Мы посмотрели кучу стриминговых сервисов, большая часть из них отдавала все свои стримы в формате m3u8, и никаких проблем при этом люди не испытывали. Соответственно назрела куча вопросов о том, как таки стоит делать и в чем могла быть ошибка и как это исправить на будущее.

Чтобы понять, в чём могла быть ошибка, нужно хотя бы получить какой-то отладочный вывод, или повторить ошибку.
Во-первых, стандарта HLS «два»: ранний допускает использование контейнера MPEG-TS (.ts), более поздний добавляет поддержку .mp4. MPEG-TS поддерживается лучше, и проще в использовании и на этапе нарезки.

У меня однажды были точно такие же симптомы, что у вас. Оказалось, что на домене осталась старая DNS A-запись, указывающая на неработающий IP-адрес уже несуществующего сервера. И всё, на удивление, работало, и работало достаточно стабильно, но периодически поток прерывался с ошибками.

Сложно делать предположения без отладочных данных.

1) Как правильно хостить файлы на сервере? Нужна ли разбивка при помощи HLS\DASH? Где-то видел что эти технологии нужно использовать в паре, так как каждая из них имеет свою браузерную поддержку.
Для видеофайлов не требуется какой-то особый подход к размещению на диске. HLS поддерживается только мобильными браузерами (многими, но не всеми), а DASH не поддерживается никакими современными браузерами. Вам в любом случае придётся использовать javascript-плеер, который самостоятельно будет собирать поток из HLS/DASH и воспроизводить через media source, поэтому принципиальной разницы нет. Использовать и HLS, и DASH одновременно точно ни к чему.

2) Должны ли быть на сервере какие-то специфичные настройки, для эффективной отдачи статического медиа-контента?
Да не особо. Так как у вас многогигабитный канал, можно попробовать настроить сетевую подсистему (если речь о Linux), а именно увеличить TCP-буферы, буферы отправки и получения, количество conntrack-соединений (может, ошибки соединения возникают по причине лимита conntrack? В dmesg заглядывали?).

3) Медиа-плеер. Возможно, причина ошибок связана с плеером, который использовали на клиенте?
Может, безусловно. Плееры содержат достаточно сложный код: парсеры и демуксеры контейнеров, работа с HLS, media source, совместимость с разными браузерами.

Например, в этом проекте, люди заходили с телевизора, а на tizen flowplayer не работал, от слова совсем.
Рекомендую попробовать clappr.io — один из немногих, корректно работающих на устаревшем браузере Blackberry.

4) Шифрование\защита файлов. Как по мне отдача чистых mp4 файлов, небезопасна от слова совсем.
Зачем нужно защищать ваши файлы, если вы и так их проигрываете? Может, следует подумать о людях и об удобстве просмотра, и предоставить ссылку, которую можно открыть в нормальном видеоплеере, или скачать фильм в виде файла? Не понимаю эту дурацкую тенденцию.
Ответ написан
gbg
@gbg
Любые ответы на любые вопросы
Почитайте статьи про niginx-rtmp
Когда я делал свой стриминг, я делал несколько разных способов доставки с выбором способа, в зависимости от того, что за клиент подключился.
Для андроидов, например, я слал webm.
Для маков HLS
Для писюков - тоже webm
У меня был живой поток, так что архитектура была такая - один сервер делал транскодирование во все видеоформаты и все разрешения, (порядка 12 вариантов, 6 разрешений в двух форматах), и еще три энджайникса заворачивали расклонированные по udp-multicast потоки куда надо.

Ваша проблема, скорее всего, не в формате, а в затыках дисковой подсистемы. Подумайте о кластере типа ceph.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы