Содержание статьи
Всем привет! Решил посвятить отдельную статью своему приложению ratcast, которое я вскользь упоминал в прошлой статье. Оно работает по аналогии с конференциями в Discord и сосредоточено именно на этой функции. Приложение построено на моей сетевой библиотеке librats, но, в отличие от Discord, имеет полностью P2P-архитектуру: участники связываются друг с другом напрямую (и не только).
В этой статье я не буду подробно останавливаться на сетевых особенностях librats, о них можно почитать в прошлой статье. Вместо этого сосредоточусь на самом приложении ratcast и библиотеке libratcast как альтернативе librist/SRT. На них я раньше делал корпоративные решения, но они не отвечают моим потребностям в обнаружении участников.
Потребность в таком приложении назрела давно. Сейчас Discord фактически заблокирован в некоторых странах (интересно, в каких), а постоянно быть на связи со знакомыми по-прежнему нужно: мы часто вместе смотрим фильмы и играем в игры. Включать и выключать приложение обеспечивающие доступ на каждый чих и сложно, и напряжно. И тут как раз под рукой оказалась моя сетевая библиотека из проекта rats-search: её удачно получилось доточить под видеостриминг, а весь P2P-функционал в ней и так уже был.
Прежде чем перейду к статье, скачать можно тут:
https://github.com/librats/ratcast/releases
Релизы доступны на Windows, Linux, Mac OS X, Android (arm64)
Особенность архитектуры (дерево участников)
Сама архитектура устроена любопытно. Уже не раз писали, что P2P плохо подходит для видеоконференций. Два участника – нормально, три – держимся, а на 6–7 начинаются проблемы: каждому приходится отправлять отдельную копию видео, то есть 5–6 потоков одновременно, и исходящий канал перестаёт справляться. Именно поэтому тот же Discord использует не прямые соединения между участниками, а серверное SFU-решение, где все потоки раздаёт сервер.
Выходит, P2P плохой и не подходит? Не спешите паниковать: нагрузку можно распределить. В небольших группах по-прежнему использовать P2P, а в больших подключать SFU-ноду.
Но и это ещё не всё. В P2P-сетях существуют релейные ноды: любой участник способен ретранслировать трафик. Тогда он одновременно выступает и обычной нодой, и SFU-сервером:
Таким образом, потребность в отдельных SFU-серверах отпадает вовсе. Ratcast умеет выстраивать сеть в такую древовидную топологию. Пример для 7 участников:
Кроме того, ratcast может использовать серверы ratcast-server: они выступают в роли rendezvous-серверов, помогают пробивать даже симметричные NAT и при необходимости ретранслируют трафик. Но они полностью опциональны: участники находят друг друга через Mainline DHT и mDNS, а соединяются напрямую или через других участников. Серверы лишь ускоряют подключение и помогают в сложных сетях.
Простыми словами: масштабирование в ratcast не проблема, и бежать разворачивать серверы не нужно. Топология сети перестраивается на ходу, а без единого обязательного сервера и блокировать, по сути, нечего. А главное, всё это работает даже в сложно устроенных сетях 🙂
Кодеки и качество
Ratcast изначально проектировался с упором на эффективное кодирование и декодирование видео, без оглядки на WebRTC, который любит выбирать что-нибудь проверенное, например H.264 из 2003 года. Нет уж, спасибо, на дворе 2026-й, поэтому я постарался нафаршировать приложение современным стеком: почему бы и нет. В приоритете сейчас аппаратные AV1-энкодеры и декодеры (например, av1_nvenc от NVIDIA) для видео и Opus для звука:
Обратная совместимость тоже есть, как и программные декодеры: выбирается то, что лучше всего подходит всем участникам, но приоритет всё же за современным стеком. Поддерживается видео вплоть до 4K, и абсолютно бесплатно. Привет, Discord, как дела? 😉
Битрейт адаптивный и зависит от многих факторов, но прежде всего его регулирует librats в зависимости от качества вашей сети.
У приложения есть low-latency-профиль: он использует особый тип live-пакетов librats, чтобы добиться крайне низкой задержки, на уровне WebRTC или даже ниже.
Обнаружение участников, шифрование
Для обнаружения участников используются Mainline DHT и rendezvous-серверы, а в локальной сети протокол mDNS. Библиотека librats отлично уживается в одной сети с BitTorrent-клиентами и другими узлами DHT, что помогает участникам быстро находить друг друга и устанавливать соединение.
Для шифрования librats использует протокол Noise ( https://en.wikipedia.org/wiki/Noise_Protocol_Framework ) с Curve25519 и ChaCha20-Poly1305. Поверх этого сами видео- и аудиокадры шифруются сквозным шифрованием по стандарту SFrame (RFC 9605), поэтому серверы ratcast-server пересылают трафик, не имея доступа к ключам и не видя содержимого. Так что можете быть уверены: во время конференций за вами никто не подсматривает 🙂
Что можно в самом приложении?
Само приложение написано на C++ с использованием Qt. Основной упор сделан на трансляцию экрана и совместный просмотр: можно расшарить весь экран или отдельное окно, вместе смотреть фильмы и играть. Любой стрим можно развернуть на весь экран. Громкость регулируется как для каждого участника по отдельности, так и для самой трансляции. Приложение переведено на 10 языков.
Есть и небольшой чат, но пока он не в приоритете.
Как пользоваться?
В приложении есть три типа звонков, и у каждого свой вид ссылки:
-
Прямой звонок. Звонок одному человеку из ваших контактов: соединение создаётся напрямую между двумя участниками.
-
Комната. То же самое, что конференция в Zoom или Teams: вы отправляете сгенерированную ссылку, общаетесь, и на этом всё. Для следующего звонка нужна новая комната.
-
Группа. Более привычная сущность для пользователей Discord: существует постоянно, настраивается, а вход в неё выполняется по ссылке или сразу после старта приложения, если сохранена.
Скидываем ссылку человеку — он там.
Что там по поводу библиотеки?
Ядро видеопротокола вынесено в отдельную библиотеку libratcast. В будущем для неё появится плагин для GStreamer, как это уже сделано для RIST и SRT. Это позволит сторонним видеоприложениям подключаться к ratcast или организовывать собственные трансляции на этом протоколе. В общем, есть ещё над чем поработать.
Спасибо за внимание!
Загрузка...
