То есть получается, что отдача одним файлом и браузерный декод, вышли намного эффективнее чем то, что мы делали через 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 файлов, небезопасна от слова совсем.
Зачем нужно защищать ваши файлы, если вы и так их проигрываете? Может, следует подумать о людях и об удобстве просмотра, и предоставить ссылку, которую можно открыть в нормальном видеоплеере, или скачать фильм в виде файла? Не понимаю эту дурацкую тенденцию.
