Синхронный просмотр видео онлайн: почему screen share архитектурно плохое решение и как это исправить
Задача на первый взгляд простая: двое в разных локациях хотят смотреть одно видео синхронно. На практике большинство берёт первое что под рукой (screen share) и получает предсказуемо плохой результат. Разберём что происходит под капотом у каждого подхода.
Screen share
Discord, Zoom, Telegram используют WebRTC или собственные протоколы. Поток с дисплея захватывается, кодируется (VP8/VP9 или H.264 с агрессивным битрейтом для экономии полосы), передаётся через TURN/STUN-сервер, декодируется у получателя. Качество деградирует на каждом этапе, это следствие архитектуры, не баг. Задержка от 500 мс до 3 секунд в зависимости от условий. Только инициатор получает оригинальный видеопоток.
Веб-сервисы (Watch2Gether, WParty)
Видео либо проксируется через их серверы, либо используется embed API платформы. В случае YouTube: iframe с postMessage API для управления. Качество ограничено их инфраструктурой. Российские платформы (Кинопоиск, RuTube, Иви) через embed не работают или работают с серьёзными ограничениями.
Синхронизация состояния плеера
Принципиально другой подход. Расширение не трогает видеопоток. Оно встраивается в страницу, перехватывает события нативного плеера (play, pause, seeked, timeupdate) через MutationObserver или прямую инъекцию в DOM, и транслирует их участникам комнаты через WebSocket. Каждый участник грузит видео напрямую с CDN платформы. Синхронизируется только управление, не контент.
TandemParty работает по этой схеме. Поддержка: Кинопоиск, YouTube, ВК Видео, RuTube, Иви. Задержка синхронизации команд в пределах сетевого RTT. Из нестандартного: QR-пульт, WebSocket-сессия позволяет телефону выступать вторым контроллером плеера после сканирования QR-кода с экрана.
Техническая статья про устройство синхронизации изнутри есть в блоге: tandemparty.ru/blog















