Использование WebRTC в качестве альтернативы RTMP
Среднее прочтение 1 мин.
В прошлом году окончательно умер Adobe Flash Player . Несмотря на то, что крайняя дата определялась годами и была очень ожидаема, она повлияла на ключевую технологию во многих потоковых рабочих процессах: протокол обмена сообщениями в реальном времени (RTMP) .
RTMP изначально был разработан для передачи аудио, видео и других данных в Adobe Flash Player. А в период своего расцвета RTMP был основной технологией передачи видео через Интернет. Его можно было использовать от начала до конца и обеспечить быструю доставку в реальном времени. Однако сегодня его поддерживает меньше устройств и браузеров, чем когда-либо прежде.
Хотя RTMP останется надежным механизмом передачи видео между кодировщиками и серверами, этого нельзя сказать о воспроизведении на основе RTMP. По словам самой Adobe , вещателям рекомендуется «переносить любой существующий Flash-контент в… новые открытые форматы».
В выпуске журнала Streaming Media в начале прошлого года Роберт Рейнхард предупредил : «Если вы используете Flash для потоковой передачи в реальном времени с малой задержкой , у вас есть около года или меньше, чтобы попытаться перейти на решение WebRTC . И что это означает? Любой код, который вы используете на своем медиасервере на основе Flash (Adobe Media Systems, Wowza Streaming Engine и т. д.), необходимо перенести на WebRTC вместо протокола обмена сообщениями в реальном времени (RTMP)».
И все же многие распространители контента все еще пытаются заменить RTMP форматом воспроизведения видео в реальном времени. Почему? Что ж, и HLS , и MPEG-DASH поддерживают высококачественную потоковую передачу на различные устройства, но задержка более 30 секунд является стандартной для этих технологий на основе HTTP. Существуют расширения этих протоколов с малой задержкой ( HLS с малой задержкой и CMAF с малой задержкой для DASH ), но ни одно из них не достигает скорости доставки менее секунды, к которой многие стремятся. Кроме того, поддержка HLS с малой задержкой и CMAF с малой задержкой для DASH в проигрывателях , сетях доставки контента (CDN) и устройствах все еще находится на ранних стадиях.
Для потоковой передачи в реальном времени единственным вариантом является веб-коммуникация в реальном времени (WebRTC ), поэтому в последние годы она привлекла большое внимание. Технология на основе HTML5 предлагает самый быстрый способ передачи живого видео через Интернет. Более того, как и RTMP в расцвете сил, его можно использовать от начала до конца.
Но WebRTC не без ограничений. Протокол был разработан для кодирования на основе браузера и мелкомасштабной потоковой передачи, которые плохо сочетаются с некоторыми сценариями вещания.
Конечно, это модное словечко среди разработчиков, но является ли WebRTC лучшим решением для замены RTMP? Как я объясню, все зависит от технологий, которые вы используете для поддержки развертывания, и от того, чего вы пытаетесь достичь.
RTMP против WebRTC: сравнение
WebRTC дает несколько преимуществ по сравнению с RTMP. Во-первых, это новая технология с открытым исходным кодом, которая также стандартизирована IETF и W3C . Все основные браузеры поддерживают WebRTC, не требуя подключаемого модуля, что устраняет проблемы совместимости, связанные с проприетарными технологиями потоковой передачи. Кроме того, он выигрывает от сообщества разработчиков программного обеспечения, которые вносят свой вклад в его постоянное развитие.
Во-вторых, при скорости доставки менее 500 миллисекунд WebRTC является протоколом с наименьшей задержкой . Это делает его подходящим решением для создания интерактивного видеоконтентов, начиная от аукционов в реальном времени и заканчивая прямой торговлей , а также привлекательным вариантом для прямых спортивных трансляций, стремящихся получить преимущество над своими конкурентами.
Однако крупномасштабное вещание для многочисленных зрителей всегда было проблемой для WebRTC. Фреймворк видеочата просто не предназначен для масштабирования. К счастью, мы разработали решение для преодоления этого ограничения, о котором я подробно расскажу ниже.
Что касается передачи видео, WebRTC обеспечивает простую трансляцию с использованием только веб-браузера, но для вещателей, которые надеются контролировать свои настройки кодирования с помощью аппаратного или программного решения, кодирование на основе браузера не идеально. Точно так же RTMP опережает WebRTC, когда речь заходит об использовании синхронизированных метаданных для таких функций, как заголовки и рекламные маркеры.
Рабочие процессы WebRTC
Итак, где именно можно заменить RTMP на WebRTC, когда речь идет о потоковой передаче видео в реальном времени ? В качестве сквозной технологии можно использовать WebRTC для загрузки, выхода или того и другого. Вот посмотрите на преимущества на обоих концах рабочего процесса и на то, как его можно использовать от кодирования до доставки — без ущерба для масштаба.
Замена RTMP на WebRTC для Ingest
RTMP остается стандартом для передачи видео первой мили. И тому есть несколько причин. Во-первых, он широко поддерживается программным и аппаратным обеспечением для живого кодирования . Это также принято многими платформами социальных сетей.
Поставщики кодирования начали добавлять поддержку протоколов с открытым исходным кодом, таких как SRT , но ранее WebRTC был ограничен публикацией на основе браузера . Для тех, кто хочет транслировать прямо из своего браузера, используя только веб-камеру и микрофон, это отлично сработало. Но для распространителей контента, желающих транслировать созданный в реальном времени контент с помощью профессионального кодировщика, прием WebRTC не был вариантом.
Итак, команда Milicast разработала протокол WebRTC HTTP Ingest Protocol (WHIP), чтобы преодолеть это препятствие. WHIP предоставляет программное и аппаратное обеспечение для кодирования со стандартным сигнальным протоколом при общении с медиасерверами, что позволяет использовать WebRTC для разных поставщиков. WHIP позволяет напрямую принимать WebRTC, сохраняя преимущества задержки по сравнению с RTMP, устраняя при этом любые барьеры связи между кодировщиками и медиасерверами.
При использовании для загрузки WebRTC обеспечивает низкую задержку , обязательное шифрование и предлагает поддержку передовых кодеков , таких как Opus и VP9 . Он также становится жизнеспособным форматом для аппаратного и программного кодирования благодаря WHIP. Для рабочих процессов вещания, требующих точной настройки параметров кодирования (включая битрейт, кодеки и параметры кодека), это позволит WebRTC напрямую конкурировать с RTMP.
Замена RTMP на WebRTC для выхода
RTMP больше не поддерживается браузерами, что делает его мертвым на стороне воспроизведения. Большинство вещательных компаний сегодня используют HLS для доставки «последней мили», но при его использовании стандартными являются задержки более 30 секунд.Какие форматы потоковой передачи вы в настоящее время используете для доставки?
Когда дело доходит до альтернатив с низкой задержкой, WebRTC является самым быстрым из всех. По этой причине, если вам нужна настоящая интерактивность — и мы говорим о доставке видео менее чем за одну секунду для таких сценариев, как реагирование на чрезвычайные ситуации и удаленный мониторинг — тогда WebRTC — ваш лучший выбор. HLS с малой задержкой и CMAF с малой задержкой для DASH также являются хорошими вариантами, но они не могут обеспечить такую же доставку в реальном времени, как WebRTC.
Тем не менее, WebRTC не был предназначен для масштабного вещания. Раньше мы поощряли распространителей контента вместо этого использовать настроенный HLS или HLS с малой задержкой при трансляции интерактивного контента для большой аудитории, но мы расширили наше предложение, чтобы устранить это препятствие.
В частности, мы разработали новую функцию, которая развертывает WebRTC в пользовательской CDN, чтобы обеспечить почти безграничное масштабирование. Решение, масштабируемое потоковое вещание в реальном времени для Wowza Streaming Cloud , обеспечивает доставку вирусной аудитории по всему миру за доли секунды.
Соображения при реализации WebRTC
Если вы рассматриваете возможность использования WebRTC в качестве замены RTMP, примите во внимание следующие вопросы:
1. Вам требуется двустороннее видео или интерактивность в реальном времени?
Решения для интерактивной потоковой передачи в реальном времени и WebRTC идут рука об руку, как арахисовое масло и желе. Пока вы используете WebRTC как для публикации, так и для воспроизведения, достижима потоковая передача менее 500 мс. Более того, варианты использования, удобные для потоковой передачи менее секунды, могут использовать рабочий процесс RTMP для WebRTC. Также существуют гибридные модели, в которых интерактивные участники просматривают поток WebRTC, а пассивные зрители получают поток с более высокой задержкой, доставляемый через HLS.
2. Ожидаете ли вы стать вирусным?
Все распространители контента надеются, что их потоковые приложения станут очень успешными, и их будут смотреть тысячи или даже миллионы зрителей. Однако такое количество пользователей может легко перегрузить вашу инфраструктуру. Традиционные развертывания WebRTC ограничены в своих возможностях масштабирования без использования специально созданной CDN, как это предлагает наша функция потоковой передачи в реальном времени в масштабе . Поэтому убедитесь, что у вас есть правильная инфраструктура, если ваша цель — охватить большую аудиторию.
Вывод
Поскольку WebRTC был разработан для приложений видеочата, на пути его внедрения в рабочие процессы прямого вещания стояли два основных препятствия:
- Ограничения кодирования на основе браузера и отсутствие возможностей WebRTC в программном и аппаратном кодировании.
- Проблемы с масштабируемостью, которые затрудняли использование WebRTC при трансляции на тысячи и более зрителей.
К счастью, отрасль придумала обходные пути для обеих проблем, что делает WebRTC мощной альтернативой RTMP как на стороне приема, так и на стороне воспроизведения.
В нашем отчете о задержке потокового видео за 2021 год мы обнаружили, что WebRTC в настоящее время является вторым по популярности форматом для загрузки и третьим по популярности для доставки. Я ожидаю, что внедрение будет продолжать расти, учитывая работу, которую поставщики проделали для улучшения удобства использования WebRTC для прямой трансляции видео.
