В этом сообщении блога мы опишем доказательство концепции, над которой мы работаем, чтобы найти открытый и стандартизированный способ использования WebRTC для потоковой передачи в реальном времени с малой задержкой. Это наш вклад в техническую работу в контексте стандартизации потоковой передачи на основе WebRTC, и весь исходный код, связанный с этим подтверждением концепции, доступен как открытый исходный код.

Существует ряд вариантов использования, которые стали возможными благодаря интеграции потоковой передачи WebRTC. Отчет, разработанный DASH-IF, описывает некоторые варианты использования и технические соображения, которые необходимо учитывать [1]. Случаи использования, которые варьируются от интерактивных живых концертов/музыкальных мероприятий до интерактивности на стадионе и трансляций с меньшей задержкой.

WebRTC — это набор стандартов, и сегодня поддержка WebRTC включена во все современные браузеры и даже в некоторые более современные Smart TV. Первоначально WebRTC был сосредоточен на видеоконференциях, но его функции со сверхнизкой задержкой (требуемые для двусторонней связи) являются привлекательной функцией для потоковой передачи в реальном времени. Уменьшение задержки при переходе от одного устройства к другому — одна из самых обсуждаемых тем в индустрии потокового вещания. Но внедрение и интеграция WebRTC в индустрию потокового вещания было медленным процессом, и мы считаем, что отсутствие стандартов о том, как интегрировать WebRTC в этом контексте, способствовало этому медленному темпу.

Для начала необходимо стандартизировать две основные области: прием и воспроизведение. Когда мы приступили к проверке концепции, мы решили сократить объем, чтобы охватить эти две фундаментальные области. На стороне загрузки уже существует инициатива по стандартизации загрузки мультимедиа в службу потоковой передачи или CDN с использованием WebRTC под названием WHIP (протокол загрузки WebRTC-HTTP [2]). Проект стандарта, опубликованный в октябре 2021 года и написанный С. Мурильо и А. Гуайяром из CoSMo Software.

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

Мы разработали библиотеку Javascript [3], которая реализует протокол WHIP и может быть интегрирована в веб-приложение. Это означает, что веб-приложение приема, основанное на этой библиотеке и протоколе WHIP, не привязано жестко к конкретному медиасерверу WebRTC, если медиасервер поддерживает WHIP. В рамках этого проекта мы разработали базовый медиа-сервер, который предоставляет конечную точку WHIP и вещательную компанию (SFU) [4]. Теперь у нас есть стандартизированный способ для отправителя получать мультимедиа с помощью WebRTC.

Следующей задачей было воспроизведение этого канала. На момент написания этого поста и этого проекта еще не существовало стандарта для использования и воспроизведения канала с использованием WebRTC. Здесь нам пришлось применить немного другой подход из-за этого факта. Мы разработали библиотеку проигрывателя для воспроизведения WebRTC [5], которая была разработана так, чтобы быть независимой от медиа-сервера. Мы достигли этого, разработав плеер с использованием адаптеров медиасервера.

Адаптер отвечает за обмен SDP (предложение/ответ), в то время как другие общие моменты обрабатываются вне адаптера и в проигрывателе. Проигрыватель прикрепляет поток WebRTC к элементу HTML-видео, но не отображает какой-либо скин или элементы управления. Это было намеренно оставлено за пределами этой библиотеки. Мы начали с реализации адаптера, который работал с нашим медиа-сервером, который мы разработали для этого прототипа. Обмен SDP в этом случае вдохновлен WHIP, поскольку он использует HTTP в качестве транспортного протокола с дизайном API на основе ресурсов. Ресурс канала находится с URL-адресом, и адаптер медиасервера отправляет HTTP POST с полезной нагрузкой application/json, включая предложение SDP. Причина использования JSON заключалась в том, что мы хотели расширить его другими данными, а не только SDP. В ответ адаптер получает ответ SDP от медиа-сервера.

Затем мы добавили эту библиотеку проигрывателя WebRTC в наш веб-плеер Eyevinn [6]. Eyevinn Web Player — это модульная структура проигрывателя, которая включает в себя другие библиотеки проигрывателя, такие как HLS.js, Shaka Player и DASH.js, для поддержки воспроизведения наиболее распространенных протоколов потоковой передачи HTTP. Добавление поддержки WebRTC с помощью библиотеки проигрывателя WebRTC было легким делом, и мы могли использовать скин и элементы управления, уже доступные в веб-плеере.

Теперь у нас есть проигрыватель, который не привязан к конкретному медиа-серверу, но как нам указать, какой адаптер должен использовать проигрыватель? Способ, которым мы решили эту проблему, и надеемся, что это может вдохновить работу по стандартизации, которая ведется вокруг DASH и WebRTC, состоял в том, чтобы немного расширить манифест MPEG-DASH. Наш медиа-сервер может вернуть манифест MPEG-DASH для канала, например:

GET https://broadcaster-wrtc.dev.eyevinn.technology:443/broadcaster/mpd/60dc933b-0738-485d-8f81-01d8fae7402c

вернет этот MPEG-DASH:

<MPD profiles="urn:mpeg:dash:profile:webrtc-live:2022">
  <Period 
     xlink:href="https://broadcaster-wrtc.dev.eyevinn.technology:443/broadcaster/channel/60dc933b-0738-485d-8f81-01d8fae7402c" 
     xlink:rel="urn:ietf:params:whip:eyevinn-wrtc-channel"
     xlink:actuate="onRequest"></Period>
</MPD>

Манифест MPEG-DASH, содержащий одну точку с xlink:href и локатором ресурса канала. Чтобы WebRTC-плеер понимал, какой адаптер использовать, мы добавили атрибут xlink:rel, описывающий, на какой тип ресурса он указывает. Затем мы могли бы проанализировать этот манифест и узнать, какой адаптер использовать в проигрывателе.

С этим прототипом у нас есть доказательство концепции, когда приложение для загрузки WebRTC на основе браузера может принимать любой тип медиа-сервера, совместимого с WHIP, и способ сигнализировать независимому от медиа-сервера проигрывателю WebRTC, какой адаптер использовать. Все с открытым исходным кодом, и вы можете использовать его в усилиях по стандартизации WebRTC и воспроизведения. Конечная цель состоит в том, чтобы не иметь адаптеров, специфичных для медиа-сервера, а вместо этого использовать один, который реализует общий стандарт для всех медиа-серверов.

Если вы хотите попробовать, прототип доступен онлайн по адресу https://webcast.eyevinn.technology/

На данный момент участниками этого проекта являются Йонас Бирме, Бенджамин Валлберг и Маркус Спангенберг, все из Eyevinn Technology AB.

Если вы хотите узнать больше об этом прототипе и проверке концепции, вы можете связаться с Джонасом Бирме, вице-президентом по исследованиям и разработкам Eyevinn Technology.

Eevinn Technology — ведущий специалист в области видеотехнологий и распространения мультимедиа, а также почетный организатор ежегодной скандинавской конференции Streaming Tech Sweden.

Связанные блоги разработчиков:

Ссылки в этой статье:

[1] https://dashif.org/webRTC/report
[2] https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
[3] https://www.npmjs.com/package/@eyevinn/whip-web-client
[4] https://www.npmjs.com/package/@ eyevinn/whip-endpoint
[5] https://github.com/Eyevinn/webrtc-player
[6] https://web.player.eyevinn.technology/