Является ли прогрессивная загрузка HTTP жизнеспособной альтернативой HLS / DASH / RTMP для предоставления живого видео?

Я работаю над веб-сайтом, который должен транслировать живое видео пользователям, и поэтому мне пришлось разобраться с плачевным состоянием современной технологии потокового видео на основе браузера. Самые популярные решения для потокового вещания в настоящее время имеют проблемы совместимости; RTMP требует Flash, HLS только изначально поддерживается Safari и Chrome для Android, DASH не изначально поддерживается в любом месте и с помощью dash.js требует Media Source Extensions , которые еще не являются широко поддерживается.

Это приводит к вопросу, который мне кажется очевидным: возможно ли использовать простую прогрессивную загрузку в качестве альтернативы таким протоколам, как HLS, RTMP и DASH, которые либо требуют поддержки браузера, либо плагинов?

Идея использования прогрессивной загрузки для потокового вещания мультимедиа не является беспрецедентной; люди уже делают это для аудио. Такие инструменты, как liveCaster, позволяют вам передавать потоковое аудио в формате MP3 через один прогрессивный HTTP-ответ без необходимости предварительно записанного файла MP3, а такие библиотеки, как AmplitudeJS, стараются изо всех сил добавлять функции, связанные с этим видом потокового аудио в реальном времени .

Я не видел ни одного случая использования этой техники в дикой природе для видео , и я не могу сказать, почему. Похоже, что это устранит слой беспорядочных и сложных проблем совместимости на стороне браузера для сравнительно небольшого компромисса. (И совместимость по-прежнему является огромной проблемой для потокового вещания, даже когда профессионалы делают это; если я пытаюсь смотреть живое видео на iPlayer BBC в Firefox, я просто получаю сообщение об ошибке, сообщающее мне об установке Flash.) И все же никто не использует эта техника, и я никогда не видел, чтобы кто-нибудь упоминал эту идею, кроме меня.

Почему? Есть ли фундаментальное ограничение, которое я не вижу, которое сделало бы невозможным просто потоковую передачу видеофайла, такого как MP4, с помощью прогрессивной загрузки по мере его создания и воспроизведения его в <video>элементе при загрузке?

— Марк Эмери
источник

Не могли бы вы использовать библиотеку HLS javascript (например, hls.js здесь: github.com/video-dev/hls.js/tree/master ), чтобы добавить кросс-браузерную поддержку HLS для вашей страницы? Я полагаю, что, возможно, этого не было, когда вы задавали этот вопрос изначально ... но теперь это так. :)

— stuckj

Ваш вопрос верен, и теоретически я думаю, что вы можете использовать Progressive Downloads для потокового видео в реальном времени. На самом деле, многие онлайн потоковые видео, такие как YouTube и т. Д., Уже используют HTTP. Я предполагаю, что вы строго говорите о прямой трансляции, а не только о потоке.

Вы должны будете реализовать варианты использования Live Streaming, однако, сами! Что в противном случае потоковые протоколы (RTMP и т. Д.) Делают сами. Вот несколько причин, чтобы предпочесть эти протоколы и архитектуру:

1. Переменная скорость передачи

Большая часть потокового видео в реальном времени кодируется в VBR, и ваше видео должно быстро адаптироваться к изменяющейся загруженности сети вашего клиента. Таким образом, ваше видео может переключаться между несколькими разрешениями за очень короткое время, в зависимости от того, насколько быстрым или медленным является клиентское соединение.

Согласно Википедии

Он работает, определяя полосу пропускания пользователя и процессор в режиме реального времени и соответствующим образом регулируя качество видеопотока.

2. Живой контент

Наиболее важным моментом является то, что прямая трансляция означает живой контент. В отличие от прогрессивной загрузки HTTP, вы не можете буферизовать в любое время. Пользователь должен видеть последний кадр, предназначенный для всего мира, и не может отставать.

3. Отключить поиск

Незначительная проблема, но протокол не должен позволять пользователю искать в обратном направлении (и, очевидно, вперед). Это должно контролироваться не только на уровне видеоплеера, но и на уровне сети.

4. Частые отключения / ненадежная сеть

Я немного не уверен в этом вопросе, но знаю, что после отключения входящей загрузки HTTP может потребоваться некоторое время для установления другого рукопожатия (даже с keep-alive). Действующие протоколы намного быстрее подключаются и отключаются из-за следующего пункта ->

5. Латентность

HTTP по своей сути работает через TCP, что обеспечивает гарантированную доставку пакетов. Сравните это с UDP, используемым во многих протоколах (особенно в многопользовательских играх в режиме реального времени), где скорость имеет приоритет над гарантиями.

Для получения дополнительной информации смотрите здесь -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Копирование контента

Большинство серверов прямой трансляции будут отвечать только на контент текущего времени. Несмотря на то, что все еще возможно копировать контент живых потоков, нужно прибегнуть к захвату экрана и т. Д. Предоставление прогрессивной загрузки по HTTP делает задачу копирования контента довольно тривиальной (отсюда и так много загрузчиков YouTube).

Теперь HTTP можно смоделировать, чтобы обеспечить большую часть вышеперечисленного.

Вы упомянули HTTP Live Streaming (HLS) от Apple , наиболее близкий к тому, чего вы пытаетесь достичь.

И в этой области ведутся активные исследования, как указано здесь -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Я в поисках дополнительной информации и буду обновлять этот ответ.

— Гаурав Раманан
источник

Кажется неправильным упоминать задержку как недостаток использования прогрессивной загрузки HTTP, учитывая, что основными конкурентами являются DASH и HLS, которые доставляют сегменты видео через несколько последовательных HTTP-запросов. Я не знаю всех деталей протоколов, но я предполагаю, что последний подход требует минимальной задержки, по крайней мере, используемой длины сегмента, в то время как при прогрессивном подходе к загрузке теоретическая минимальная задержка отсутствует - более низкая задержка должна быть объявление преимущество прогрессивной загрузки подхода, не так ли?

— Марк Эмери

Кроме того, некоторые другие проблемы, такие как поиск и восстановление после отключений, - это проблемы, которые в равной степени относятся к реализации DASH на JavaScript, но dash.js, вероятно, преодолевает их. Я думаю, что их можно преодолеть для прогрессивного загрузчика, просто украдя все решения, которые разработчики dash.js придумали.

— Марк Амери

@MarkAmery Если вы сравните с DASH и HLS, то да, я думаю, что это сопоставимо. Но если вы сравните его с некоторыми старыми протоколами, использующими UDP, то HTTP потеряет управление! Даже если вы видите, что многие системы реального времени сегодня создаются с использованием Websockets и избегают HTTP из-за проблем с задержкой.

— Гаурав Раманан

Простота копирования контента является реальным недостатком по сравнению с dash.js и HLS. И я не уверен, как можно реализовать потоки с переменным битрейтом, используя прогрессивную загрузку, хотя я ожидаю, что это будет возможно с небольшой хитростью.

— Марк Амери

@MarkAmery Когда дело доходит до потокового вещания в реальном времени и в реальном времени, мы должны учитывать производительность, а не просто возможность. Я рассмотрю DASH, но мне интересно, есть ли тесты, которые показывают сравнение производительности между потоковыми протоколами и восстановлением HTTP после отключения.

— Гаурав Раманан