Интеграция перевода видео в реальном времени: плейбук

Ключевые тезисы

Форма интеграции определяет всё остальное. Серверный бот-участник, инлайн-преобразование медиа, egress из SFU или захват на клиенте: выберите подходящую схему для вашей платформы и сэкономите месяцы работы.

LiveKit Agents и управляемый диалоговый ИИ-движок Agora: два самых быстрых пути в 2026 году. Оба решения предлагают встроенные инструменты для работы с аудио: можно подписываться на отдельные дорожки и публиковать аудиопоток с озвучкой перевода, не прибегая к ручной настройке RTP на низком уровне.

Доставка субтитров: три строки кода, а их синхронизация: три недели тонкой настройки. Используйте WebRTC data channel для точной доставки, отключайте частые обновления промежуточных результатов и ориентируйтесь на часы RTCP Sender Report, а не на системные.

Один воркер перевода на звонок не масштабируется. Заранее продумывайте автомасштабируемые пулы, маршрутизацию по парам языков, корректные переподключения и аварийный выключатель, пока в продакшене не окажется 500 одновременных комнат.

Мобильная интеграция добавляет 300-600 мс к десктопному бюджету. Особенности маршрутизации в iOS CallKit и Android ConnectionService проявляются поздно: закладывайте их в архитектуру заранее, а не исправляйте в ретроспективах.

Почему Фора Софт написала этот плейбук по интеграции

Фора Софт выпускает продукты на базе WebRTC с 2005 года: 250+ проектов, 2 миллиона часов разработки, заказчики из 17+ стран, 50 специалистов в штате без субподряда. В телемедицине, e-learning, вещании и корпоративном видео мы подключали агентов перевода в реальном времени к разным крупным видеоплатформам, включая LiveKit, Agora, Mediasoup и Jitsi. Этот плейбук объединяет интеграционные решения, которые мы применяем в первый день каждого проекта.

Мы разработали ядро для трансляций в реальном времени для БрейнСерт, платформы для уроков в реальном времени с доступностью 99,995% и свыше 500 миллионов минут проведённых занятий: тот же опыт с многоязычными субтитрами лежит в основе ТрансЛингвист, нашей платформы для живого перевода, которая объединяет ИИ и работу 8 000+ проверенных переводчиков по 62 языковым парам. Тот же голосовой канал в реальном времени лежит в основе Таннел, нашего сервиса p2p видеозвонков на WebRTC с входом по номеру комнаты. Наша более широкая практика разработки ПО для обработки видео и аудио на заказ: это та среда, где и рождаются эти интеграционные паттерны.

Продукт в реестре отечественного ПО Минцифры, программа «Мундиаль», реестровая запись № 21522.

Четыре паттерна интеграции, которые реально работают в продакшене

Любая интеграция перевода в реальном времени, которую мы запускали, сводится к одному из четырёх подходов. Сначала выбирайте подход, потом технологии. Так интеграция ИИ в видеопродукт остаётся одной схемой вместо набора разрозненных сервисов, пришитых друг к другу по ходу разработки.

Серверный бот-участник. Безголовый процесс подключается к звонку как обычный участник, подписывается на аудиодорожку каждого участника, запускает распознавание речи (ASR) и перевод (MT) на сервере и возвращает результат: либо в виде отдельной аудиодорожки с переводом, либо как субтитры через data channel. Это самый чистый подход и наш стандартный выбор для LiveKit и Agora, потому что обе платформы предоставляют полноценный SDK для ботов.

Инлайн-преобразование медиа. Плагин, зарегистрированный в медиапайплайне, перехватывает аудио до кодирования или после декодирования, заменяет или накладывает переведённый звук и возвращает его в ту же дорожку. Сюда подходят Microsoft Teams Media Extensibility (сервис для пользователей из России напрямую недоступен) и mediasoup plain-transport, а также Zoom Video SDK как сертифицированное приложение (сервис Zoom для конечного пользователя в России недоступен напрямую, но SDK применяется в продуктах для международных рынков). Плюс подхода: используется один поток, без удвоения участников. Минус: жёсткие ограничения по задержке колбэков и более тесная интеграция с внутренними механизмами вендора.

Egress из SFU во внешний воркер. SFU перенаправляет RTP в plain transport или RTP-эндпоинт, который читает воркер перевода. Воркер декодирует Opus, обрабатывает ASR, переводит текст и синтезирует речь, перекодирует аудио и отправляет RTP обратно в SFU как новый продюсер. Такой подход поддерживают Mediasoup, Janus и любые кастомные SFU. Это самый гибкий, но и самый трудоёмкий вариант: вам придётся самостоятельно управлять SSRC, джиттером, RTCP и FEC.

Захват на клиенте с облачным ASR. Браузер или мобильное приложение отправляет записанное аудио в облачный сервис распознавания речи через WebSocket, получает расшифровку и передаёт её участникам по каналу данных WebRTC. Такой подход хорошо работает для звонков один на один и при небольшой нагрузке, но не масштабируется на вебинары с сотнями слушателей: за каждого из них придётся платить за обработку речи.

Берите серверный бот-участник, когда у вас уже работают LiveKit, Agora, Daily или Jitsi, и вы хотите единый пайплайн перевода для комнаты независимо от количества подключённых слушателей.

Берите инлайн-преобразование медиа, когда вы интегрируетесь с Zoom Video SDK (напоминаем: сервис Zoom для пользователей из России недоступен напрямую) или Teams как сертифицированное приложение и вам нужен ровно один аудиопоток на участника.

Берите egress из SFU, когда у вас собственный стек на Mediasoup, Janus или Pion и нужен полный контроль над кодеками, джиттер-буферами и маршрутизацией по регионам.

Берите захват на клиенте, когда вы используете хостируемое SDK, которое не предоставляет серверные хуки для работы с аудио, например Daily или ранние managed-решения.

Внутри любого из четырёх подходов остаётся ещё один выбор, транспортный: OpenAI Realtime API с WebRTC и WebSockets собирается по-разному в зависимости от того, идёт ли поток из браузера или из серверного процесса.

По платформам: где аудио попадает в ваш пайплайн

Вот точные хуки, которые мы используем в интеграциях 2026 года.

Отдельная практическая деталь: Twilio Programmable Video находится в режиме end-of-life с отключением в конце 2026 года, а прямая оплата сервиса из России и так недоступна. Команды, у которых уже используется Twilio, должны прямо сейчас планировать переход на Zoom Video SDK, LiveKit или Daily. Если это про вас, добавляйте перевод в тот же проект: интегрироваться дважды расточительно.

LiveKit Agents: самый быстрый путь в 2026 году

LiveKit Agents: фреймворк на Python и Node для запуска безголовых ИИ-участников в комнатах LiveKit. В 2026 году это первое, к чему мы обращаемся в новых проектах: базовые возможности фреймворка идеально подходят для пайплайна перевода: подписка на дорожки, встроенный VAD, полноценный data channel, публикация аудиодорожки обратно в комнату. Скелет выглядит так:

from livekit import agents, rtc

async def entrypoint(ctx: agents.JobContext):
    await ctx.connect()
    async for track_pub in ctx.room.remote_participants.tracks():
        if track_pub.kind == rtc.TrackKind.AUDIO:
            audio_stream = rtc.AudioStream(track_pub.track)
            async for frame in audio_stream:
                text = await asr.stream(frame.data)
                translated = await mt.translate(text, target="es")
                await ctx.room.local_participant.publish_data(
                    payload=translated.encode(),
                    topic="captions.es",
                )

Это реальный код, а не псевдокод: 20 строк до субтитров. Чтобы публиковать озвучку перевода, добавьте rtc.LocalAudioTrack, созданный на основе вывода TTS, и вызовите publish_track. Запустите агента как воркер: диспетчер LiveKit автоматически назначит по одному агенту на комнату.

Масштабирование: запускайте агентов как Kubernetes Deployment за диспетчером LiveKit. Один под поддерживает примерно 10-20 одновременных комнат в зависимости от ASR-провайдера. Настройте автомасштабирование по загрузке CPU и количеству активных агентов. Оставляйте 25 процентов запаса на всплески переподключений, когда регион «дрожит». Голосовые сценарии нагружают эту схему сильнее текстовых, и LiveKit Agents на практике упираются сначала в пропускную способность ASR-провайдера, а уже потом в CPU пода.

Agora: сырые аудиофрагменты и управляемый ИИ-движок для диалогов

Agora предоставляет две корректные точки интеграции. Управляемый диалоговый ИИ-движок Agora: вариант, где внутри комнаты от вашего имени работает пайплайн STT, LLM и TTS, а снаружи доступны хуки для предварительной и последующей обработки. Наблюдатель сырых аудиокадров: автономный вариант, в котором вы регистрируете AudioFrameObserver, получаете PCM в onPlaybackAudioFrameBeforeMixing и отправляете PCM в выбранный ASR.

Чтобы публиковать переведённый голос, зарегистрируйте кастомный аудиоисточник (setExternalAudioSource) и передавайте PCM-кадры с вывода TTS. Важно соблюдать временные интервалы: Agora перебуферизует данные под свой внутренний таймер, поэтому отправляйте кадры с шагом 10 мс, а если TTS не успел, дополняйте тишиной.

Субтитры передаются через Agora Signaling (RTM) или по отдельному data stream в RTC-канале. По умолчанию используется отдельный поток: его доставка привязана к аудиосессии, и если она прервана, клиент точно знает, что субтитры недоступны.

Доставка субтитров: четыре механизма без мерцания

WebRTC data channel. Стандартный способ доставки в реальном времени. Отправляйте JSON-сообщения вида {t: ts, s: speakerId, p: "partial"|"final", x: "translated text"} каждые 150 мс, персонально каждому участнику, с минимальной нагрузкой на сервер.

Нативный RPC у SFU. publish_data в LiveKit, Agora RTM, sendAppMessage в Daily, командный канал Zoom SDK (сервис Zoom для пользователей из России напрямую недоступен). Семантика у всех одинаковая, различия в поведении при сбоях. Такой подход подходит, если важна надёжность и порядок доставки, которые обеспечивает вендор.

Server-sent events. Для внешних наблюдателей: модераторских консолей, сервисов доступности, мониторинга соответствия. Отделяет тайминг субтитров от RTC-сессии, устойчив к джиттеру, удобен для аудита.

WebVTT-дорожка. Полезна, когда вы дополнительно записываете звонок и хотите, чтобы плееры отображали субтитры нативно. Генерируйте VTT-файл из того же потока промежуточных результатов, а при записи повышайте до уровня only-final.

Ловушка с мерцанием субтитров, в которую попадает каждая команда: рендеринг сырых промежуточных результатов. Стриминговый ASR постоянно пересматривает свои предварительные расшифровки по мере поступления аудио, и текст на глазах меняется. Решение: буферизуйте промежуточные результаты на 150 мс, игнорируйте правки старше текущего кадра и отправляйте текст в финальную версию, когда ASR сообщает is_final=true.

Синхронизация: используйте часы RTCP, а не системные

Самый частый баг в продакшене первых версий интеграции: субтитры расходятся со звуком, потому что рендер субтитров использует системные таймстемпы, а аудио воспроизводится по медиа-часам SFU. Через 20 минут долгой встречи субтитры отстают на несколько секунд.

Правильный подход: помечать каждый субтитр таймстемпом RTP того аудиокадра, который обработал ASR, а на стороне получателя переводить его в NTP с помощью RTCP Sender Report. Такой функционал поддерживают все крупные клиенты и SFU: rtc.AudioFrame.timestamp в LiveKit, RTP-заголовок у consumer-объектов в mediasoup, renderTimestamp у Web Audio в MediaStreamTrackProcessor. Прикрепляйте таймстемп к каждому промежуточному результату: пусть рендер сам выравнивает субтитры по времени воспроизведения.

Для переведённого голоса применяется та же дисциплина, что и для оригинала, плюс одно важное условие: публикуйте сэмплы TTS с тем же шагом, что и исходное аудио, 10 мс при частоте 48 кГц. Если TTS отстаёт, дополняйте тишиной: так джиттер-буферу SFU работать удобнее. Отбрасывать кадры выгоднее, чем накапливать рассинхрон по времени.

Переподключения, повторные входы и согласованность состояния

Агент перевода, который переживает сетевой сбой, это тот, кто держит продакшен ночью. Три правила.

Состояние живёт вне агента. Глоссарий, языковые настройки, персональные переопределения и метаданные встречи хранятся в Redis или базе данных сессии с ключом roomId. После переподключения агент восстанавливает состояние быстрее чем за 100 мс.

Идемпотентность вызовов перевода. Каждый промежуточный результат имеет порядковый номер по говорящему. Если агент переподключился и отправил тот же фрагмент повторно, MT-сервис видит тот же seq и возвращает закэшированный результат, что устраняет мерцание при переподключениях.

Чистая семантика отключения. Когда агента вытесняют, отписывайтесь от дорожек, сбрасывайте буфер TTS и публикуйте финальный data-кадр «перевод приостановлен». Клиенты, не получившие кадров дольше 3 секунд, должны показывать чип «перевод переподключается», а не молча оставлять устаревший текст.

Клиентская сторона тоже важна: при переподключении пользователя клиент должен запросить у агента текущее состояние субтитров через data channel, а не ждать следующего промежуточного результата. Тот, кто заходит в 40-минутную встречу, хочет контекст, а не только следующее предложение.

Масштабирование: пулы воркеров, шардирование, контроль расходов

Один процесс перевода на звонок не масштабируется. Закладывайте пул с самого начала.

Пул воркеров. Kubernetes Deployment с HPA. Для LiveKit каждый под: это воркер LiveKit Agent, а диспетчер сам распределяет комнаты. Для Mediasoup и кастомных SFU используйте перед воркерами шард-роутер: сессия направляется на под воркера по consistent-хешу от roomId. Масштабируйте автоматически по количеству активных сессий и по загрузке CPU.

Маршрутизация по парам языков. Не распределяйте все языки по всем воркерам. Создайте отдельные пулы для крупных языковых групп, чтобы модели оставались в оперативной памяти, а ASR-провайдеры могли использовать региональную близость.

Региональное размещение. Размещайте воркеры в том же регионе, что и egress вашего SFU. Воркер, обрабатывающий поток из удалённого региона, будет тратить сотни миллисекунд сетевой задержки на каждый кадр, и одной такой задержки достаточно, чтобы превысить бюджет.

Контроль расходов. Считайте минуты перевода по тенантам и записывайте их в тот же спан, что и метрики биллинга. Ограничьте бесплатные тарифы на уровне ASR-воркера. Корпоративных клиентов направляйте на зарезервированные воркеры, чтобы нагрузка от бесплатных пользователей не нарушала SLA.

Мобильные платформы: ловушки интеграции на iOS и Android

Мобильная интеграция добавляет 300-600 мс к десктопному пайплайну и вносит платформенные особенности, из-за которых командам приходится тратить недели, если они выявляются поздно.

iOS. Используйте категорию AVAudioSession.playAndRecord с режимом .voiceChat. Включите фоновый режим voip и разрешение audio, чтобы перевод продолжал работать, когда приложение свёрнуто. Для интеграции с CallKit потребуется отдельный блок маршрутизации для дорожки переведённого голоса: по умолчанию система направляет только основное аудио звонка.

Android. Используйте foreground service с FOREGROUND_SERVICE_PHONE_CALL или FOREGROUND_SERVICE_MEDIA_PROJECTION в зависимости от задачи. Включите AudioManager.MODE_IN_COMMUNICATION для подавления эха. Будьте осторожны с функциями некоторых производителей, которые могут изменить аудиомаршрутизацию после отключения Bluetooth и незаметно отключить вторичную аудиодорожку, если не подтвердить её заново.

Локальный синтез речи на устройстве на мобильных работает быстрее облачного: экономится 200-400 мс на запрос, хотя качество может немного уступать. Пользователи чаще ценят отсутствие задержки выше идеального звучания голоса.

Аутентификация и изоляция тенантов

Воркер перевода: ещё один участник с особыми возможностями, поэтому ему нужен токен с минимально необходимыми правами, которые не должны делиться между тенантами.

LiveKit. Выдавайте JWT, привязанный к комнате, с правами canSubscribe, canPublish, canPublishData, без прав администратора. Срок действия короткий, 5-10 минут, с возможностью обновления. Идентификатор начинайте с префикса agent:, чтобы клиенты могли отфильтровывать его в интерфейсе.

Agora. Токен с ролью Role_Publisher и правом на передачу необработанного аудио, привязанный к конкретному каналу, обновляйте перед истечением срока действия.

Изоляция тенантов. Ключи для ASR, MT и TTS привязывайте к тенанту, а не к окружению. Учётные данные, с которыми воркер обрабатывает звонок тенанта A, не должны работать для тенанта B, даже если из-за ошибки конфигурации они станут доступны. Регулярно меняйте ключи по расписанию и настраивайте алерты при попытке их использования в другом тенанте.

Сетевой исход. Воркеры перевода должны иметь доступ только к эндпоинтам ASR, MT и TTS. Открытый исходящий трафик запрещён. Группы безопасности сети настроены с явным списком разрешённых адресов, всё остальное запрещено.

Тестирование: симуляция аудио, моки ASR, SLO по задержкам

Продакшен-пайплайнам перевода нужно три уровня тестирования, чтобы оставаться зелёными.

Уровень 1: модульные тесты и моки. Подменяйте провайдеры ASR и MT детерминированными ответами. Запускайте на каждом PR. Проверяют корректность проводки, а не качество работы.

Уровень 2: стенд с симулированным аудио. Тестовый стенд подключается к комнате как синтетический участник, воспроизводит размеченную аудиофикстуру и проверяет, что в канале данных субтитров появляется ожидаемый текст в пределах допустимой задержки. Запускайте такие тесты ночью против стейджинга: они ловят регрессии в таймингах обработки аудио.

Уровень 3: WER на эталонном датасете. Еженедельная выборка аудио из продакшена, собранная с согласия пользователей, сравнивается с расшифровками, сделанными вручную, по каждому языку. Если 95-й перцентиль WER за неделю растёт более чем на 2 пункта, срабатывает алерт. Такой подход ловит регрессии в качестве ASR-провайдеров, которые не удаётся выявить другими способами.

Ставьте все три уровня. Команды, которые отгружают только первый, узнают о проблемах с задержками и качеством от пользователей.

Резервные провайдеры и плавная деградация

Любой провайдер ASR, MT или TTS будет терять качество минимум дважды в год. Создавайте резерв до первого сбоя, а не после.

Многопровайдерный ASR. Основной провайдер и резервный на случай отказа, например Deepgram в основном контуре и Azure Speech как резерв (приём платежей от российских юрлиц напрямую недоступен, это стоит закладывать в план закупки). Circuit breaker на сессию: если задержка первого промежуточного результата превышает SLO несколько раз подряд, переключайтесь на резервный провайдер до конца сессии. Логируйте каждое переключение и настройте алерт по частоте.

Деградированные режимы. Только субтитры, если не работает TTS. Только субтитры на оригинальном языке, если не работает MT. Баннер «перевод временно недоступен», если вышел из строя весь пайплайн. Молчаливая деградация всегда хуже честной ошибки.

Аварийный выключатель. Один конфиг-флаг отключает перевод для тенанта, региона или для всех сразу. Проверяйте его работу раз в квартал.

Что регулирует закон при интеграции

Подключение перевода в реальном времени добавляет субпроцессоров, которые обрабатывают голос и текст участников, а это персональные данные по 152-ФЗ. Не оставляйте комплаенс юристам за три дня до релиза.

Оценка рисков обработки. Голосовое аудио: биометрические персональные данные, если система способна идентифицировать человека по голосу. Проводите оценку рисков обработки до подписания контрактов с поставщиками ASR, MT и TTS: фиксируйте цель обработки, сроки хранения, правила доступа и оставшиеся риски.

Договор с каждым субпроцессором. Каждый поставщик, участвующий в обработке аудио или расшифровке, должен быть указан в договоре поручения обработки персональных данных до запуска функции, с описанием условий обработки и сроков хранения. Уточняйте у каждого поставщика ASR, MT и TTS отдельно, поддерживает ли он требуемый уровень защиты данных, прежде чем отправлять через него чувствительное аудио.

Для медицинских сценариев дополнительно действуют требования 323-ФЗ и профильных приказов Минздрава. Для образовательных сценариев с участием несовершеннолетних применяются требования 273-ФЗ вместе с 152-ФЗ. Для организаций, относящихся к критической информационной инфраструктуре, значение имеет соответствие требованиям ФСТЭК и 187-ФЗ.

Локализация данных. Обработка и хранение персональных данных российских пользователей должны соответствовать требованиям к локализации, а маршрутизацию сессий по регионам стоит настраивать в диспетчере агентов, а не в сетевой инфраструктуре: так проще проводить аудит.

Сколько это стоит на практике

Разработка интеграции перевода в реальном времени в существующий видеостек под ключ у Фора Софт начинается от 450 000 ₽: итоговая стоимость зависит от выбранного паттерна интеграции, требований к масштабированию и требований к соответствию.

Каркас принятия решения: выберите паттерн интеграции по пяти вопросам

На какой вы платформе? LiveKit или Agora ведут к серверному боту. Zoom (сервис для пользователей из России напрямую недоступен) или Teams ведут к инлайн-обработке медиа. Mediasoup или собственное решение ведут к egress из SFU. Daily или устаревающие SDK ведут к захвату на клиенте или боту, в зависимости от зрелости SDK.

Нужен ли переведённый голос или достаточно субтитров? Для субтитров хватит data channel. Для голоса убедитесь, что ваша платформа поддерживает публикацию вторичной аудиодорожки от серверного участника без отдельной лицензии.

Какой потолок одновременности на первый год? Меньше 100 одновременных комнат: одного регионального пула воркеров достаточно. Больше 500: региональные пулы с первого дня, автомасштабирование и шардирование по roomId.

Мобильная платформа: поверхность первого класса? Если да, вкладывайтесь в локальный синтез речи и работу с foreground-сервисами заранее, а не ретрофитом.

Регуляторный контур? Для медицины: провайдеры с договором на обработку персональных данных, региональная маршрутизация, ограниченное хранение аудио. Для работы с широкой аудиторией: локализация данных и опубликованный список субпроцессоров.

Отвечать на эти пять вопросов имеет смысл после того, как принято продуктовое решение: перевод речи в реальном времени как план для бизнеса задаёт рамку, внутри которой технический паттерн выбирается почти однозначно.

Пять интеграционных ловушек, которые топят проекты

Системные часы для синхронизации субтитров. На демо работает, в продакшене дрейфует. Опирайтесь на таймстемпы из RTCP Sender Report и прикрепляйте их к каждой полезной нагрузке субтитров.

Один воркер на комнату навсегда. Как только конкуренция превысит ёмкость воркера, одна комната «задушит» остальные. Размеряйте поды на 10-20 комнат и автомасштабируйте агрессивно.

Эхо в ASR. Переведённый голос возвращается в комнату, ASR его распознаёт, а пайплайн переводит собственный вывод. Помечайте синтетическую аудиодорожку метаданными и пропускайте её на уровне обработчика аудиокадров.

Нет идемпотентности при переподключениях. Агент переподключился и переотправил промежуточные результаты, из-за чего субтитры начали мерцать и откатываться назад. Порядковые номера по говорящему плюс кэш на стороне MT полностью решают эту проблему.

Тишина в фоне на мобильных. Операционная система усыпляет приложение, и перевод обрывается на середине фразы. Проблема решается фоновыми режимами, foreground-сервисами и keep-alive аудиокадрами.

Все пять ловушек видны на схеме задолго до первой строки кода, поэтому оценку архитектуры интеграции дешевле проводить до старта разработки, пока правки стоят один разговор.

KPI для интегрированного пайплайна перевода

KPI качества. Задержка первого промежуточного результата: p50 не более 500 мс, p95 не более 1 секунды. WER на еженедельной выборке эталонного датасета: не более 8 процентов по топ-10 языкам. Покрытие субтитрами: не менее 90 процентов произнесённых слов, дошедших до зрителей.

Бизнес-метрики. Доля сессий с включённым переводом. Рост выручки на новых языковых рынках по кварталам. Доля обращений в поддержку, связанных с переводом, с целью снижения после шестой недели после запуска.

KPI надёжности. Успешность диспетчеризации агентов: не менее 99,5 процента. Количество переключений провайдеров: не более двух в месяц, иначе стоит пересмотреть договорённости. Стоимость одной переведённой минуты отслеживается по тенантам и парам языков.

Когда не стоит пока интегрировать перевод в реальном времени

Некоторым продуктам надо подождать. Если вы планируете мигрировать видеотранспорт, сначала завершите переход на новый транспорт, а уже потом внедряйте изменения в стек. Совмещение двух миграций удваивает риски, но не приносит дополнительной ценности.

Если вы ещё не достигли product-market fit и проблемы с локализацией не входят в тройку главных запросов пользователей, отложите. Перевод в реальном времени: это отдельный проект на 10-14 недель, и лучше потратить это время на то, что действительно нужно рынку.

Если ваша платформа не поддерживает серверные хуки для аудио и не планирует их внедрять, субтитры, созданные на стороне клиента, остаются временным решением. Инвестировать в озвучку с переводом стоит только после того, как платформа будет готова.

FAQ

Использовать LiveKit Agents или строить egress на Mediasoup?

Если у вас ещё нет Mediasoup, на LiveKit Agents проще и дешевле развернуть систему. Если Mediasoup уже используется по другим причинам, поддержка egress есть. Менять SFU только ради перевода смысла не имеет.

Как опубликовать переведённый голос в Daily.co?

Подключите безголового участника Daily с аудиоисточником через нативную интеграцию SDK и публикуйте кастомную дорожку с переведённым звуком: клиенты подписываются по идентификатору участника. Паттерн сложнее, чем у LiveKit Agents, но работает.

Какой полезной нагрузкой передавать субтитры через data channel?

Небольшой JSON на кадр с RTP-таймстемпом для синхронизации, полем sequence для упорядочивания и идемпотентности, языком для многоязычных комнат и флагом partial или final, который показывает клиенту, когда можно прекратить анимацию.

Сколько комнат может обслуживать один воркер перевода?

Для каскадного пайплайна с современным стриминговым ASR и MT один воркер на 2 vCPU и 2 ГБ RAM спокойно справляется с 10-15 одновременными комнатами при двух говорящих в каждой. Самостоятельный ASR на GPU обрабатывает 20-40 потоков в зависимости от модели. Рассчитывайте мощности с запасом.

Как остановить эхо-обратную связь при публикации переведённого голоса?

Помечайте переведённую дорожку устойчивым идентификатором и фильтруйте дорожки с этим идентификатором на уровне обработчика аудиокадров или при подписке, чтобы ASR никогда не обрабатывал собственный вывод. Делайте это в агенте, а не на клиенте: один централизованный фильтр проще проверить и поддерживать.

Можно ли встроить перевод в реальном времени в видеовстречи некоторых зарубежных платформ без использования их клиентского приложения?

Правильный путь: SDK с сырым медиа, оформленный как сертифицированное приложение в маркетплейсе платформы, с учётом того, что доступ к самим сервисам вроде Zoom для конечного пользователя в России напрямую недоступен. Обходные пути через скрейпинг существуют, но ломаются при каждом обновлении клиента.

Как обработать пользователя, который переподключается посреди встречи с длинным контекстом?

Держите скользящий транскрипт у агента на сервере. При переподключении клиент отправляет по data channel запрос на последние несколько секунд переведённых субтитров, а агент отвечает одной нагрузкой. Пользователь видит пропущенный контекст, а не оказывается посреди фразы.

Реалистичные сроки интеграции для уже существующего WebRTC-продукта?

10-14 недель на интеграцию в продакшен с LiveKit или Agora при работе с командой, использующей агентную разработку. Использование сторонних SDK конференц-платформ или кастомных решений на базе Mediasoup добавляет 3-5 недель на платформенную разработку. Подход mobile-first требует дополнительно 2-4 недели на реализацию слоя под операционные системы.

Готовы подключить перевод к видеостеку, не сломав продакшен?

Свяжитесь с Фора Софт: за 3 рабочих дня подготовим план MVP, аудит архитектуры и оценку стоимости бесплатно.