Low-Latency & Real-Time Streaming: SRT vs WHIP.
Последнее время мы стали получать от некоторых наших клиентов вопросы по поводу WHIP/WHEP-стриминга. После изучения темы мы решили добавить поддержку такого стриминга в наши продукты.
Чтобы у наших клиентов было понимание, когда использовать SRT или WHIP, мы решили написать эту статью с кратким обзором обоих вариантов.
Low-Latency и Real-Time
Давайте для начала определимся, что такое Real-Time и Low-Latency-стриминг. Это не что иное как градации Glass-to-Glass задержки. Будем использовать сокращения: RT, LL, g2g
Под RT-стримингом понимают такой стриминг, в котором задержка g2g не более 300-400 миллисекунд.
Следующим по градации идет LL-стриминг. Это такой стриминг, при котором задержка выше чем в RT, но остается в пределах 1000 миллисекунд.
Ярким представителем протокола для RT-стриминга является протокол WebRTC, который активно используется в разных системах телеконференций и работает в большинстве браузеров. Ну а ярким представителем LL-стриминга является протокол SRT, в котором можно добиться g2g задержки в пределах 400-800 миллисекунд.
Ок, а что такое WHIP?
Долгое время в WebRTC, как в стандарте, не была описана процедура начала сессии. Предполагалось, что разработчики систем на базе WebRTC, сами определяют, как 2 узла начнут общаться друг с другом. По этой причине разработчики стриминговых программ в каком-то смысле были скованы: они не могли послать WebRTC-поток на сторонний WebRTC-сервер, потому что механизм взаимодействия не был единым.
Но относительно недавно появилось простое решение этого вопроса. Кто-то сказал, а давайте будем использовать для начала взаимодействия протокол HTTP и оформим это как стандарт. Данный стандарт назвали WHIP/WHEP.
WHIP: WebRTC-HTTP Ingest Protocol (для стриминга на сервер)
WHEP: WebRTC-HTTP Egress Protocol (для стриминга с сервера)
Соответственно теперь разработчики стриминговых программ получили протокол для начала общения с WebRTC-сервером. Например в последнем релизе OBS Studio уже есть возможность делать стриминг по протоколу WHIP.
Аналогично и мы добавили данную возможность в наш энкодер SRT Streamer Pro. За счет простоты WHIP/WHEP-протокола их реализация была быстро добавлена в различные WebRTC-сервера.
Таким образом RT-стриминг на базе WebRTC стал более доступен для видеостриминговых команд.
За счет чего получается RT
Возникает вопрос за счет чего при WHIP-стриминге достигается сверхнизкая задержка по сравнению с тем же SRT-стримингом?
Ответ достаточно прост: WHIP-стриминг требует от энкодера кодировать поток в таком формате, который сразу проигрывается в браузерах зрителей. При соблюдении этого условия закодированный энкодером пакет, попадая на сервер, мгновенно перенаправляется зрителю в неизменном виде, за счет чего и получается сверхнизкая задержка.
Как вы наверное уже догадываетесь, “платой” за такую схему является скованность в выборе режимов кодирования, поскольку пакет изначально должен быть закодирован так чтобы браузеры всех пользователей могли его декодировать.
Последнее время мы стали получать от некоторых наших клиентов вопросы по поводу WHIP/WHEP-стриминга. После изучения темы мы решили добавить поддержку такого стриминга в наши продукты.
Чтобы у наших клиентов было понимание, когда использовать SRT или WHIP, мы решили написать эту статью с кратким обзором обоих вариантов.
Low-Latency и Real-Time
Давайте для начала определимся, что такое Real-Time и Low-Latency-стриминг. Это не что иное как градации Glass-to-Glass задержки. Будем использовать сокращения: RT, LL, g2g
Под RT-стримингом понимают такой стриминг, в котором задержка g2g не более 300-400 миллисекунд.
Следующим по градации идет LL-стриминг. Это такой стриминг, при котором задержка выше чем в RT, но остается в пределах 1000 миллисекунд.
Ярким представителем протокола для RT-стриминга является протокол WebRTC, который активно используется в разных системах телеконференций и работает в большинстве браузеров. Ну а ярким представителем LL-стриминга является протокол SRT, в котором можно добиться g2g задержки в пределах 400-800 миллисекунд.
Ок, а что такое WHIP?
Долгое время в WebRTC, как в стандарте, не была описана процедура начала сессии. Предполагалось, что разработчики систем на базе WebRTC, сами определяют, как 2 узла начнут общаться друг с другом. По этой причине разработчики стриминговых программ в каком-то смысле были скованы: они не могли послать WebRTC-поток на сторонний WebRTC-сервер, потому что механизм взаимодействия не был единым.
Но относительно недавно появилось простое решение этого вопроса. Кто-то сказал, а давайте будем использовать для начала взаимодействия протокол HTTP и оформим это как стандарт. Данный стандарт назвали WHIP/WHEP.
WHIP: WebRTC-HTTP Ingest Protocol (для стриминга на сервер)
WHEP: WebRTC-HTTP Egress Protocol (для стриминга с сервера)
Соответственно теперь разработчики стриминговых программ получили протокол для начала общения с WebRTC-сервером. Например в последнем релизе OBS Studio уже есть возможность делать стриминг по протоколу WHIP.
Аналогично и мы добавили данную возможность в наш энкодер SRT Streamer Pro. За счет простоты WHIP/WHEP-протокола их реализация была быстро добавлена в различные WebRTC-сервера.
Таким образом RT-стриминг на базе WebRTC стал более доступен для видеостриминговых команд.
За счет чего получается RT
Возникает вопрос за счет чего при WHIP-стриминге достигается сверхнизкая задержка по сравнению с тем же SRT-стримингом?
Ответ достаточно прост: WHIP-стриминг требует от энкодера кодировать поток в таком формате, который сразу проигрывается в браузерах зрителей. При соблюдении этого условия закодированный энкодером пакет, попадая на сервер, мгновенно перенаправляется зрителю в неизменном виде, за счет чего и получается сверхнизкая задержка.
Как вы наверное уже догадываетесь, “платой” за такую схему является скованность в выборе режимов кодирования, поскольку пакет изначально должен быть закодирован так чтобы браузеры всех пользователей могли его декодировать.
С другой стороны, протокол SRT не накладывает ограничения на форматы кодирования. Но при его использовании закодированный энкодером пакет должен пройти некую обработку, чтобы отобразить его в браузере. Как правило для дальнейшей раздачи зрителям поток преобразуется в формат HLS или DASH, иногда в WebRTC.
Ограничения WHIP
Чтобы WHIP-поток мог отображаться в браузерах клиентов, существуют ограничения на используемый формат.
Пример требований можно посмотреть по ссылке.
Когда используется SRT, а когда WHIP
Из вышесказанного следует очевидный вывод: когда следует использовать SRT, а когда WHIP.
SRT: используется для передачи высококачественного сигнала между локациями и Студией для последующей обработки и подготовки финального сигнала.
Чтобы WHIP-поток мог отображаться в браузерах клиентов, существуют ограничения на используемый формат.
- Разрешение до 1080
- Только progressive
- Не более двух аудиоканалов в кодеке OPUS
- Облегченные параметры для видеокодеков.
- Битрейт не более 8.5 Mbs
Пример требований можно посмотреть по ссылке.
Когда используется SRT, а когда WHIP
Из вышесказанного следует очевидный вывод: когда следует использовать SRT, а когда WHIP.
SRT: используется для передачи высококачественного сигнала между локациями и Студией для последующей обработки и подготовки финального сигнала.
WHIP: используется для стриминга финального сигнала конечным зрителям.
Где можно попробовать WHIP
В качестве энкодеров,поддерживающих WHIP-протокол, можно использовать:
В качестве серверной части можно использовать такие медиа-сервера, как:
Для быстрого ознакомления с WHIP/WHEP-стримингом можно воспользоваться пробным периодом сервиса Milicast.
Как начать на него стримить с помощью SRT Streamer Pro можно посмотреть в этой простой инструкции.
В качестве энкодеров,поддерживающих WHIP-протокол, можно использовать:
- OBS Studio
- SRT Streamer Pro
- Gstreamer
В качестве серверной части можно использовать такие медиа-сервера, как:
- RustXUI
- Janus
Для быстрого ознакомления с WHIP/WHEP-стримингом можно воспользоваться пробным периодом сервиса Milicast.
Как начать на него стримить с помощью SRT Streamer Pro можно посмотреть в этой простой инструкции.
