Привет, это небольшая история о том, как продуктовая команда vc.ru в свободное время занялась сторонним проектом, но переоценила свою экспертизу в разработке кросс-платформенных приложений и неправильно определила MVP. Наша очередь делиться неудачными кейсами.
А что не так с выбором Janus? Конкретно он или весь стек SFU решений не оправдывают ожиданий?)
Тут мы почему-то еще с первого MVP решили выбрать AudioBridgePlugin (MCU). Идея казалась классной. Всего два соединения на клиент вне зависимости от кол-ва участников. Следующим слоем наложили VideoRoom, и видео потоки пошли по SFU.
С течением времени начали задумываться о качестве звука. В принципе, качество звука было лучше чем в Слаке на порядок, но когда два и более человек одновременно начинают говорить (понятно что это абсурд, но все равно такое часто случается) в аудио потоке появляются артефакты (громкие трески), довольно не приятные, особенно если сидишь в наушниках. Долго дебажили в чем проблема, и оказалось дело в алгоритме софтверного микшера, и Lorenzo в каком-то треде писал, что тут ничего не поделать, они выбрали оптимальный алгоритм по трудозатратности/качеству.
Стали думать, что нужно перевести Audio в тот же VideoRoom и потестить как оно будет. Параллельно мы оптимизировали код, чтобы шаринг видео не отжирал много ресурсов. И заметили такую штуку, что тот же Google Meat использует один PeerConnection для нескольких потоков. Janus при этом на каждый видео поток создает отдельный PeerConnection, что на ровном месте с каждым новом потоком создает нормальный такой оверхед в ~15% от ядра, даже если видео уже перестало стримится, а ты забыл задестроить его.
Про кривые доки, API и JS клиент вообще молчу.
Вообще mediasoup.org очень нравится с виду. В демке видео потоки так же, как в Google Meet группируются в одном PeerConnection'е.