Technologies stack

[alexlapa]

WIP

Имеются следующие сценарии:

Video-call (видеозвонок) - 1 <-> 1. Latency < 1s.
Conference (конференция) - n <-> n. Latency < 1s.
Broadcasting (трансляция) - 1 -> n. Latency < 10s.

Необходимо выбрать подходящие технологии для их реализации.

Video-call 1 <-> 1 (3<->3 тоже можно пускать).

Очевидным вариантом будет обычный WebRTC full mesh. От нас в таком случае требуется простой сигналинг и STUN+TURN сервера.

P2P для 1 <-> 1 (3<->3 тоже будет тянуть в большинстве случаев) уже устоявшийся подход, используется и Hangouts и Jitsi.

Плюсы:

1. Не напрягаем сервер.
2. Минимально возможная латентость.

Минусы:

1. Требование к ресурсам пользователя, откуда и вытекает ограничение на количество пользователей.
2. В любом случае существует незначительная вероятность, что клиенты не смогу законнектится, в таком случае, их надо будет переводит на коннект через сервер. Что будет возможно только после реализации конференций.

По хорошему(и как это сделано в Hangouts, Jitsi), все варианты видео-вещания можно начинать с p2p WebRTC, а потом уже переключать на другие варианты. Правда, с seamless переключением будут проблемы (вообще сомневаюсь что это реализуемо, ожидаю, что в любом случае переключение будет занимать 2-3 секунды).

Conference (конференция) - n <-> n

Тут уже без полноценного медиа-сервера никак. И никаких принципиально новых подходов в этом вопросе не появилось, поэтому, webrtc-beyond-one-one вполне актуальна.

Основную разницу между MCU и SFU подходами можно обозначить следующим образом:

SFU взаимодейтсвуют с потоками на транспортном уровне, к медиа не спускаются, поэтому:

This central point only does packet inspection and forwarding, but not expensive encoding and decoding of the actual media.

Из этого вытекает:

1. Меньше нагрузка на сервер, но больше на клиента.
2. С полученным медиа мы ничего сделать не сможем, только передать дальше.

MCU спускаются на медиа-уровень, где возможностей много больше. Нас больше всего интересуют: transcoding, transmuxing, transrating, уменьшение нагрузки на клиента(как минимум отсутствие необходимости simulcast'а), лучший interop. Trade-off - серверу надо много CPU.

Предлагается использовать свежий gst с поддержкой WebRTC. Нужны биндинги. Самые актуальные и развиваемые - Rust'овые, SDP, WebRTC. Таким образом мы получаем все что умеет сам gst(совсем все). Trade-off - это будет сложно = долго. gst сам по себе вещь далеко не простая, а, учитывая необкатанность их webrtc-bin, можно утверждать, что и в сам gst надо будет спуститься, где совсем уж хардкор.

Альтернативы: множество готовых SFU, но, при их использовании, целесообразность разработки этого проекта сомнительна.

Broadcasts - 1 -> n

Смягченные требования к задержке и возможность трансмуксирования позволяют посмотреть в сторону HTTP-streaming. Там расклады такие:

1. MSS - выбывает сразу, так как требует установки Silverlight.
2. Adobe HDS - выбывает сразу, так как требует Flash Player.
3. MPEG-DASH
4. HLS

По оставшимся стоит расписать поподробнее. По основным критериям они одинаковы:

1. Можно выжать <10s задержку.
2. Оба(HLS с недавнего времени) умееют работать с fMP4(h264/h265). Фактически, HLS сейчас DASH compatible.
3. Умеют DRM.
4. Умеют live(mainfest refresh).

Проблемы с DASH:

1. iOS, tvOS.
2. Нужные нам штуки все еще не замежены: qtmux: Add support for DASH,dashsink: New sink for DASH.

Очевидно, надо делать HLS. Желательно, сразу с fMP4 как задел на DASH в будущем. Но тут все зависит от gst, а точной информации по этому поводу не обнаружилось. Видео от публикующих принимать по WebRTC с H264.

[tyranron]

@alexlapa I think it's quite obvious to bake in both SFU and MCU.
As far as MCU is... hmmm... "deeper" one, we can design ability to opt-in/opt-out it if necessary/desirable.

Trade-off - это будет сложно = долго. gst сам по себе вещь далеко не простая, а, учитывая необкатанность их webrtc-bin, можно утверждать, что и в сам gst надо будет спуститься, где совсем уж хардкор.

Well, building a reasonable media server is sort of hardcore anyway 😉

[tyranron]

@alexlapa as I see the major solutions at the moment are Janus and Kurento. It would be nice if you will overview (or point out to) their inner designs. Obviously, there will be a lot for learning and inspiring.

[alexlapa]

@tyranron ,

I think it's quite obvious to bake in both SFU and MCU.
As far as MCU is... hmmm... "deeper" one, we can design ability to opt-in/opt-out it if necessary/desirable.

Чтобы быть более строгим в формулировках, уточню, что, идеологически, подход MCU - сляниие нескольких медиа-потоков в один. То есть, клиент 1 должен получать видео клиентов 2 и 3. MCU в прямом смысле мержит эти потоки в один(с каким-нибудь стандартным layout'ом) и отправляет клиенту 1.

Я дал другое обьяснение разницы подходов, так как оно более подходит под real life ситуации: SFU'шки обычно просто роутят потоки от симулькастящих клиентов, MCU'шки все вопросы транскодирования/трансмуксирования берут на себя.

as I see the major solutions at the moment are Janus and Kurento. It would be nice if you will overview (or point out to) their inner designs. Obviously, there will be a lot for learning and inspiring.

👍