Comments 2
Для начала весьма неплохо, но до полноценного Selective Forwarding Unit тут еще очень много. У вас тут просто Forwarding Unit получается пока.
Selective он называется потому, что он не передает все видео от всех пользователей всем остальным в максимальном качестве. Тут ни процессорных мощностей ни пропускной способности сети не хватит.
Особенно это касается видео: тут клиенты обычно отправляют simulcast - сразу несколько потоков своего видео в разном качестве с разным битрейтом. А SFU, в зависимости от пропускной способности остальных клиентов, которые хотят это видео смотреть, отправлеят один из потоков, переключаясь между ними на лету. Так что получатель даже ничего про несколько потоков не знает, а видит лишь один RTP поток с меняющимся качеством.
Так что львиная часть SFU - это прямая работа с RTP пакетами.
Проблема с sfu в том что тиражируется уже кодированный кадр, и если получатель вдруг не смог его получить, то он теряет пачку кадров, пока не получит опорный кадр.
В случае же стандартной стандартной peer to peer модели источник может выкинуть ещё не зжатый кадр (или несколько), если сеть получателя не позволяет получить их , так как деградировала. Это не приводит к таким плохим последствиям, так как получатель просто не получит этот кадр и ему не нужно будет ждать ключевого кадра.
Понятно, что модель peer to peer не подойдёт для больших систем.
Погружение в Web RTC или пишем SFU своими силами