Comments 6
Автор, конечно, выдал что-то эпичное. Такое ощущение, что статья писалась после беглого прочтения пары форумов, а не из опыта. MCU на браузерном движке — звучит примерно как «самолёт на педалях»: вроде летит, но только в воображении. Может, прежде чем писать про архитектуру WebRTC, стоит хотя бы разобраться, как работает RTP и зачем нужен SFU?
Извините, вероятно, вы оставили комментарий, исходя только из заголовка, в статье есть про SFU и не только.
Упоминание SFU там есть, но выглядит скорее как галочка для видимости, чем осознанная часть архитектуры. Такое чувство, что материал писался больше под впечатлением от демо, чем с пониманием особенностей медиасервера. Возможно, если чуть глубже копнуть в RTP/RTCP и топологию потоков, получится статья, к которой вопросов не будет.
В гибридной схеме MCU+SFU MCU должен декодировать N входящих потоков, но кодировать уже только один исходящий. Были ли у вас возможности измерить, насколько именно использование GPU (через браузер) снижает нагрузку на CPU по сравнению с программным кодированием? И есть ли у вас метрики, определяющие, когда выгоднее подключать пользователя к MCU, а когда направлять ему индивидуальные потоки через SFU?
Привет. Спасибо, что помогаешь раскрыть тему. Как расписал в примерах по распределению нагрузки на MCU без GPU и с ним, видно, что нагрузка на CPU снизилась на ~43%. MCU выгодно использовать на мобильных устройствах в первую очередь, а так для всех слабых устройств и в медленных сетях.
WEBRTC MCU на основе браузерного движка