Стратегия адаптивной потоковой передачи согласована для большинства браузеров и устройств.
Я много исследовал в отношении текущего состояния потокового видео и воспроизведения в Интернете. Я публикую информацию о том, что я суммировал, и о стратегии, которой, как мне кажется, я должен следовать, для поддержки адаптивной потоковой передачи через большинство устройств и браузеры. Я просто хотел получить обратную связь от сообщества, если в стратегии, над которой я работаю, есть какие-то серьезные лазейки / улучшения.
РЕЗЮМЕ
- Для того, чтобы поддержать большинство браузеров сегодня для воспроизведения видео в формате HTML
<video>элемент, который нам нужен для кодирования наших видео, по крайней мере, в 3 форматах WEBM, OGG и MP4 - Для использования адаптивной потоковой передачи для услуг видео по запросу доступны следующие варианты: MPEG-DASH, HLS от Apple, Microsoft Smooth Streaming и Adobe HDS.
- Первоначально я предпочитал использовать MPEG-DASH, поскольку он является открытым стандартом, аналогичным HDS, HLS и Smooth Streaming, и был изобретен для обеспечения общей платформы для обслуживания аудио / видео контента в любом браузере и ОС.
- Но на данный момент устройства Apple, работающие с Safari на iOS и Safari на Mac, не полностью поддерживают стандарт MPEG-DASH, поскольку Apple еще не поддерживает API расширений Media Source html5, на котором основан MPEG-DASH.
- Так что я иду с реализацией MPEG-DASH (для устройств не Apple) + HLS (для устройств Apple)
- Это будет означать, что мне нужно будет сгенерировать файлы.mpd(используемый mpeg-dash) и .m3u8(используемый HLS) на стороне сервера, которые затем будут обслуживаться клиентам. Я использую Node.js на стороне сервера для целей кодирования.
Теперь, насколько мне известно, при использовании mpeg-dash, в основном он создает различные файлы мультимедиа с разной скоростью передачи данных из исходного файла и файл конфигурации, содержащий описания / правила относительно того, какой поток должен быть отправлен клиенту. в зависимости от пропускной способности.
Та же логика применима к HLS за исключением того, что он создает файл конфигурации с другими расширениями, чем у mpeg-dash.
Если я планирую поддерживать 3 скорости передачи в битах с 3 различными разрешениями, такими как 1020*720, 800*600, 400*300 для видео, тогда мне нужно создать такие видео для каждого из 3 форматов, которые я собираюсь поддерживать (т. Е. WEBM, OGG, MP4)
Таким образом, для любого видео, загруженного клиентом, мне нужно сгенерировать всего 3*3 = 9 видео вместе с генерацией файлов.mpd и.m3u8 для поддержки устройств не Apple и Apple.
Кажется ли это хорошей практикой? Или есть что-то большое, чего мне не хватает, чтобы использовать Cross Browser Adaptive Streaming Solution?
Советы / рекомендации / предложения приветствуются.
Спасибо!
2 ответа
Ваш подход звучит об обряде. Safari на Mac теперь поддерживает расширения источников мультимедиа, так что это еще один вариант для DASH. Но HLS все еще нужен для iOS. Я надеялся, что iOS9 включит его, но пока не повезло. Теоретически возможно сделать DASH в приложении для iOS с использованием VideoToolkit, но еще неизвестно, допустит ли Apple такую вещь в магазине приложений. Лично я бы забыл webm, и поддерживал только h264/aac. Silverlight и HDS следует полностью игнорировать. И Adobe, и Microsoft переходят на DASH. Также возможно играть HLS в MSE через конвертер, написанный на javascript. Это немного сложнее, но есть несколько игроков, которые могут это сделать.
Здесь вы можете увидеть обзор различных браузеров и платформ с точки зрения поддержки MPEG-DASH и / или HLS: 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.