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

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

Худший ответ:
Хостить
Проигрывать