кажется это терминология webRTC https://webrtcglossary.com/mesh/ mesh можно делать, если групповой звонок на небольшое количество участников и не хочется вкладываться в серверное решение и CDN
Про «история звонков ВКонтакте началась гораздо раньше» там по тексту имеется в виду не раньше других сервисов, но сильно раньше пандемии. И когда видеосвязь стала так необходима, у нас уже была неплохая, чтобы соответствовать рынку.
В ближайшее время мы вообще снимем лимиты, на количество участников, сейчас 2048. У нас MCU для звука и SFU для видео, и горизонтальное скалирование звонка на любое количество серверов. Серверные нагрузки на decode/encode/JB audio порядка 5% CPU/user, сам mix почти ничего не стоит.
Для обучения в распознавании голосовых сразу использовались шумные, а не эталонные записи. То есть там адаптация к шуму заложена на уровне языковой модели, и поэтому не требуется дополнительная задержка на денойзинг. Скоро выпустим подробную статью про это. Но и предварительный денойзинг в распознавании голосовых тоже планируем тестировать.
да, мы проводили а/б тесты и контролируем огромное кол-во параметров клиента, рост потребления в пределах погрешности, что объяснимо, так как во время звонка основными факторами потребления являются кодирование/декодирование и сетевой стек
Специально для этого случая в настройках есть отключение шумодава. При этом проблему с дефектом речи решает VAD, который определяет речь, чтобы начало и конец не проглатывались.
верю что конкурентный рынок не позволит и так сделать, уже сейчас у МТС более 32% трафика UDP (28% из них QUIC), и в МТС на эти реалии смотрят нормально )
Интересное решение, было бы здорово его сравнить с QUIC или нашим протоколом
мы для стриминга видео по TCP мы используем BBR (для сетей с потерями он больше подходит чем Cubic)
да, мы используем дополнительную информацию с уровня приложения
и это не универсальный транспорт, это транспорт доставки сообщений длинной до 1Мб в беспроводных сетях
На RIPE 76 обсуждалась проблема того, что соединения с BBR угнетают другие соединения и предложена концепция BBR2. www.slideshare.net/apnic/tcp-and-bbr
в ОК порядка 8000 серверов
сервера раздающие трафик составляют менее 5% оборудования, мы можем себе это позволить )
а throughput мы поднимем, как только появятся доработки ядра под UDP
просто оставлю это тут tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00
ну т.е. это про то, что google не много думает об остальной сети в целом и ваших приложениях в частности
особенно хороша история с BBR vs Cubic: в ней последний страдает при congestion-е
кажется это терминология webRTC https://webrtcglossary.com/mesh/
mesh можно делать, если групповой звонок на небольшое количество участников и не хочется вкладываться в серверное решение и CDN
Про «история звонков ВКонтакте началась гораздо раньше» там по тексту имеется в виду не раньше других сервисов, но сильно раньше пандемии. И когда видеосвязь стала так необходима, у нас уже была неплохая, чтобы соответствовать рынку.
Правильно
в основном Java и C++
Если в звонке много участников, у нас это могут быть тысячи, то проблема шума становится гораздо острее
мы готовим еще две статьи про то как устроены наши звонки
В ближайшее время мы вообще снимем лимиты, на количество участников, сейчас 2048.
У нас MCU для звука и SFU для видео, и горизонтальное скалирование звонка на любое количество серверов. Серверные нагрузки на decode/encode/JB audio порядка 5% CPU/user, сам mix почти ничего не стоит.
Для обучения в распознавании голосовых сразу использовались шумные, а не эталонные записи. То есть там адаптация к шуму заложена на уровне языковой модели, и поэтому не требуется дополнительная задержка на денойзинг. Скоро выпустим подробную статью про это. Но и предварительный денойзинг в распознавании голосовых тоже планируем тестировать.
да, мы проводили а/б тесты и контролируем огромное кол-во параметров клиента, рост потребления в пределах погрешности, что объяснимо, так как во время звонка основными факторами потребления являются кодирование/декодирование и сетевой стек
Все компоненты и так опенсурсные, а обучали мы под наши специфические задачи.
Специально для этого случая в настройках есть отключение шумодава.
При этом проблему с дефектом речи решает VAD, который определяет речь, чтобы начало и конец не проглатывались.
мы для стриминга видео по TCP мы используем BBR (для сетей с потерями он больше подходит чем Cubic)
и это не универсальный транспорт, это транспорт доставки сообщений длинной до 1Мб в беспроводных сетях
сервера раздающие трафик составляют менее 5% оборудования, мы можем себе это позволить )
а throughput мы поднимем, как только появятся доработки ядра под UDP
ну т.е. это про то, что google не много думает об остальной сети в целом и ваших приложениях в частности
особенно хороша история с BBR vs Cubic: в ней последний страдает при congestion-е
32% — UDP трафик, 28% — QUIC
на проводах другое распределение, там много торрентов )
в следующем докладе обязательно расскажу