Стратегия адаптивной потоковой передачи, согласованная в большинстве браузеров и устройствах

Question

Я много исследовал текущее состояние потоковой передачи видео и игры в Интернете. Я публикую то, что я обобщил, и стратегию, которую, как мне кажется, следует придерживаться, чтобы поддерживать адаптивную потоковую передачу в большинстве устройств и браузеров. Я просто хотел получить отзывы от сообщества, если стратегия, над которой я работаю, имеет какие-то основные лазейки/улучшения в ней.

РЕЗЮМЕ

• Для того, чтобы поддержать большинство браузеров там сегодня для воспроизведения видео в <video> элемента HTML в нам нужно кодировать наши видео в по крайней мере 3 форматов WebM, OGG и MP4
• Чтобы иметь адаптивная потоковая передача данных для услуг видео по запросу доступны следующие варианты: MPEG-DASH, Apple HLS, плавная потоковая передача Microsoft и HDS от Adobe
• Первоначально я предпочел пойти с MPEG-DASH, поскольку это открытый стандарт, аналогичный HDS, HLS и Smooth Str и был изобретен, чтобы обеспечить общую платформу для обслуживания аудио/видео контента в любом браузере и ОС.
• Но на данный момент устройства Apple, работающие с Safari на iOS и Safari на Mac, полностью не поддерживают стандарт MPEG-DASH, поскольку Apple пока не поддерживает API-интерфейс расширения источников мультимедиа для html5, на котором базируется MPEG-DASH.
• Так я иду с внедрением MPEG-DASH (для не устройств Apple) + ЗОЖИ (для яблоневых устройств)
• Это означало бы, я должен буду генерировать как .mpd (используется MPEG-тир) и .m3u8 (используется HLS) на стороне сервера, которые затем будут обслуживаться клиентами. Я использую Node.js на стороне сервера для целей кодирования.

Теперь, насколько я знаю при использовании mpeg-dash, в основном это то, что он создает различные файлы мультимедиа с различными скоростями передачи в исходном файле и файл конфигурации, который содержит описания/правила, касающиеся какого потока должен быть отправлен клиенту в зависимости от полосы пропускания.

Та же логика относится к HLS, за исключением того, что она создает файл конфигурации с разными расширениями, а затем тип mpeg-dash.

Если я планирую поддерживать 3-битные скорости с тремя различными разрешениями, такими как 1020 * 720, 800 * 600, 400 * 300 для видео, тогда мне нужно создать такие видео для каждого из трех форматов, которые я собираюсь поддерживать (т. е. WEBM, OGG, MP4)

Итак, для любого видео, загруженного клиентом, мне нужно генерировать 3 * 3 = 9 видео вместе с созданием файла .mpd и .m3u8 для поддержки устройств, отличных от Apple и Apple ,

Действительно ли это хорошая практика? Или есть что-то большое, чего мне не хватает, чтобы иметь адаптивное потоковое решение Cross Browser?

Подсказки/Рекомендация/Предложения приветствуются.

Спасибо!

Answer 1

Ваш подход звучит об обряде. Safari на Mac теперь поддерживает расширения медиа-источников, так что еще один для DASH. Но HLS все еще требуется для iOS. Я надеялся, что iOS9 включит его, но пока не повезло. Теоретически возможно сделать DASH в приложении iOS с помощью VideoToolkit, но еще предстоит выяснить, сможет ли яблоко разрешить такую ​​вещь в магазине приложений. Лично я бы забыл webm и поддерживал только h264/aac.Silverlight и HDS следует полностью игнорировать. И Adobe, и Microsoft переходят к DASH. Также возможно воспроизвести HLS в MSE с помощью конвертера, написанного на javascript. Это немного сложнее, но есть несколько игроков, которые могут это сделать.

Answer 2

Здесь вы можете увидеть обзор различных браузеров и платформ с точки зрения MPEG-DASH и/или поддержку ЗОЖ: http://www.dash-player.com/blog/2015/06/replacing-flash-adaptive-streaming-and-drm-in-html5/

Мы обычно генерируют MPEG-DASH + содержание HLS параллельно, и обслуживают около 80 до 90% всех пользователей с MPEG-DASH (в HTML5 или Flash, например, http://www.dash-player.com) и от 10 до 20% с HLS.