Живые субтитры – паттерн fan-out ASR на стороне SFU

Кратко

Живые субтитры в видеозвонке – это бегущий текст, отображающий слова каждого участника. Он создаётся с помощью распознавания речи и появляется на экране через одну–две секунды после произнесённых фраз. Дешёвый и эффективный способ их реализации – распознавать речь каждого участника один раз на сервере, на медиа-роутере, который и так пересылает звук всех участников (он называется SFU), а затем рассылать готовый текст всем клиентам, вместо того чтобы заставлять каждое устройство выполнять распознавание самостоятельно. В статье этот подход подробно разобран от начала до конца: где SFU «снимает» аудиопоток, почему распознавание запускается только для тех, кто действительно говорит, как субтитры сначала появляются в виде черновой догадки, а затем фиксируются в окончательной строке, как текст возвращается клиентам через data channel и во что всё это обходится за одну встречу. Здесь же проведена граница доступности, на которой вы уже находитесь: живые субтитры – требование уровня AA в Web Content Accessibility Guidelines, а правило Министерства юстиции США делает их обязательными для крупных государственных учреждений с апреля 2026 года.

Почему это важно

Если ваш продукт собирает людей в живой звонок – платформа вебинаров, виртуальный класс, телемедицинская консультация, трансляция мэрии – субтитры из приятного дополнения превратились в то, чего пользователи ожидают, а всё чаще – в то, что требует закон. Инженерный вопрос теперь не в том, добавлять ли их, а в том, где работает распознавание речи: именно этот выбор определяет ваш счёт за облако, выглядят ли субтитры одинаково у всех участников и работает ли функция вообще на дешёвом телефоне. Эта статья для продакт-менеджера, основателя или техлида, которому нужно описать функцию субтитров, оценить её стоимость и обсудить с инженерами, не утонув в аббревиатурах протоколов. К концу вы поймёте единственный архитектурный паттерн, к которому сходятся продакшн-системы видеоконференций, почему он настолько дешевле очевидной альтернативы и какой дедлайн доступности превращает «надо бы добавить субтитры» в «субтитры нужны к дате». О движках распознавания речи, которые этот паттерн использует, читайте в разборе потокового ASR – Deepgram, Whisper, AssemblyAI; эта статья – про архитектуру конференции вокруг них.

Что такое живой субтитр

Начнём с самого предмета, потому что за словом «субтитры» скрывается важное различие. Субтитр (caption) – это строка текста, синхронизированная по времени с речью: он показывает, что именно произносится в данный момент и кто это говорит. От перевода под видео (subtitle) он отличается по замыслу: перевод предполагает, что зритель слышит речь, и передаёт её содержание, тогда как субтитр рассчитан на тех, кто не слышит, и потому дополнительно указывает говорящего и значимые звуки. В прямом эфире практическая реализация проста – полоса текста внизу видео, которая обновляется по мере выступления участников, обычно с указанием имени каждого говорящего.

Под большинством субтитров в интернете лежит стандартный формат, и его стоит назвать, потому что он определяет структуру данных. Это WebVTT – Web Video Text Tracks, спецификация W3C, базовая единица которой – «cue»: текстовый фрагмент с временем начала, временем окончания и словами для отображения. Cue выглядит примерно так же просто, как и звучит:

00:00:12.000 --> 00:00:15.500
<v Maria>Начнём с бюджета.

Этот тег <v Maria> – подпись говорящего: знать, кто сказал, – это важная часть субтитра, а не просто украшение. WebVTT разработан для заранее записанных файлов, где время каждого cue известно заранее, поэтому живой звонок не может предоставить готовый WebVTT-файл – он генерирует эти cue в реальном времени и передаёт их по потоку. Но общая модель остаётся понятной: дорожка живых субтитров – это последовательность привязанных ко времени cue с указанием говорящего, создаваемых по ходу встречи.

Движок, который превращает речь в эти cue, – это система автоматического распознавания речи, сокращённо ASR (Automatic Speech Recognition): программа, которая анализирует звуковой сигнал и преобразует его в текст. Вся эта статья – о том, где разместить этот движок в многопользовательском звонке и как его результат отображается на экране каждого участника.

Часы доступности, которые уже идут

Сначала о причине срочности. Живые субтитры – это не только любезность по отношению к глухим и слабослышащим; для многих продуктов это требование закона с привязанной датой.

Эталонный стандарт – Web Content Accessibility Guidelines, известный как WCAG, – разрабатывается Консорциумом Всемирной паутины (W3C). Один из его критериев успеха, № 1.2.4 с названием «Captions (Live)», прямо требует: субтитры должны быть доступны для всего живого аудиоконтента в синхронизированных медиа. Этот критерий относится к уровню соответствия AA – среднему из трёх уровней WCAG, на который ориентируются большинство законов и контрактов. Если ваш продукт транслирует живое аудио с видео, уровень AA означает наличие живых субтитров – и это не обсуждается.

В дедлайн эту рекомендацию превратило правило Министерства юстиции США 2024 года в рамках Americans with Disabilities Act (ADA). Оно обязывает государственные органы штатов и местного уровня обеспечивать соответствие веб-контенту и мобильным приложениям стандартам WCAG 2.1 уровня AA и устанавливает жёсткие сроки: учреждения, обслуживающие более 50 тысяч человек, должны выполнить требования к 24 апреля 2026 года, а меньшие – к 26 апреля 2027 года. Любая платформа, продающая свои услуги государственным университетам, судам, городским администрациям или государственным школам, автоматически наследует эти сроки через своих клиентов. Что касается телевидения США и части интернет-видео, Federal Communications Commission (FCC) уже много лет требует субтитров; новое правило Министерства юстиции переносит это требование напрямую в сферу веб-конференций и вебинаров.

Вывод – не юридическая консультация (обратитесь к своему юристу), а факт для планирования: если среди ваших покупателей есть госучреждения или крупные предприятия, у «субтитров», скорее всего, будет дата соответствия в 2026 году, и выбранная архитектура должна быть готова к этому сроку.

SFU, который у вас уже есть

Теперь об архитектуре – с одной деталью, которую вы, скорее всего, уже используете. В звонке с более чем двумя-тремя участниками звук и видео не передаются напрямую между всеми – иначе каждому устройству пришлось бы отправлять отдельную копию каждому другому, что быстро перегрузило бы телефоны и слабые каналы. Вместо этого потоки проходят через сервер посередине – Selective Forwarding Unit, или SFU. Каждый участник отправляет одну копию своего аудио и видео в SFU, а тот «раздаёт веером» – fan-out – нужные потоки всем остальным.

Представьте общую встречу из 30 человек. Без SFU телефон говорящего загружал бы 29 копий своего звука. С SFU телефон отправляет одну копию, а сервер раздаёт её 29 слушателям. Этот fan-out – один поток внутрь, много потоков наружу – и есть суть работы SFU, и именно благодаря ему вообще работают групповые звонки. О более широкой роли SFU и браузерных хуках вокруг него мы рассказываем в статье про интеграцию ИИ и WebRTC.

Вот ключевой инсайт, на котором строится вся статья: SFU – единственное место в системе, где в реальном времени уже доступен звук каждого участника, разделённый по говорящим. Это делает его естественным местом для интеграции распознавания речи. Вы не создаёте новую трубу – вы подключаетесь к той, которая уже передаёт ровно то, что нужно движку ASR.

Два места для уха: на клиенте или на сервере

Распознавание речи можно запустить ровно в двух местах, и выбор между ними – это и есть ключевое решение. Разницу проще всего увидеть, если посчитать.

Первый вариант – на клиенте: устройство каждого участника распознаёт звук, который он слышит. Это выглядит естественно – звук и так поступает на каждое устройство для воспроизведения, – и голоса остаются вне ваших серверов, что создаёт ощущение приватности. Но посчитайте стоимость. На встрече из 30 человек, если каждое устройство распознаёт речь, вы запускаете тридцать отдельных задач распознавания для одного разговора. Каждое устройство расходует батарею и процессорное время; дешёвый телефон может просто не справиться – начать пропускать кадры или перегреваться. Хуже того, тридцать устройств дадут тридцать слегка отличающихся расшифровок, потому что каждый движок работает с немного разным аудиосигналом. В результате два человека на одной встрече видят разные субтитры, а ваша запись, если вы её храните, не совпадает ни с одной из них.

Второй вариант – на сервере: SFU один раз записывает звук каждого говорящего, распознаёт его централизованно и рассылает полученный текст всем. Снова посчитайте. Для той же встречи из 30 человек распознавание нужно только для тех, кто действительно говорит – обычно одного, иногда двоих. Вы выполняете одну-две задачи распознавания вместо тридцати. Каждый участник видит один и тот же субтитр, потому что существует единственный источник истины. Рассылка текста практически ничего не стоит. И это одинаково хорошо работает на флагманском ноутбуке и на трёхлетнем телефоне, потому что устройству нужно лишь отобразить текст, а не генерировать его.

В такой формулировке выбор выглядит однобоким – и для групповых звонков он действительно таков. У распознавания на клиенте есть своя ниша: звонок один на один, офлайн- или приватный продукт, где звук не должен покидать устройство, либо резервный путь, если серверный путь недоступен – и этот сценарий мы подробно разбираем в отдельной статье про клиентский ASR с faster-whisper в браузере. Но для любой встречи с большим количеством участников распознавание на сервере – это масштабируемый паттерн, реализованный на SFU.

Нажмите, чтобы увеличить

Паттерн Fan-Out, Шаг За Шагом

Соберите детали – и получится паттерн, в честь которого названа статья. Он использует уже существующую работу SFU – раздачу медиа – и добавляет вторую, более скромную задачу: передачу текста.

Пройдём путь одной фразы. Мария говорит. Её устройство отправляет аудиопоток на сервер SFU – так же, как и раньше, чтобы другие участники могли её слышать. Серверный процесс подписывается на этот поток – он становится ещё одним потребителем звука, который SFU и так пересылает, – и передаёт речь Марии в потоковый ASR-движок. Движок преобразует речь в текст. Этот текст упаковывается в субтитровые cue и возвращается в SFU, который рассылает его всем 30 участникам по отдельному каналу для данных, а не для медиа. Приложение каждого участника получает cue и отображает текст на экране под видео Марии.

Итак, два fan-out на одном сервере: звук раздаётся, чтобы люди слышали, а текст субтитров раздаётся, чтобы люди читали. Раздача текста почти бесплатна по сравнению с раздачей звука – строка субтитра это несколько десятков байт, тогда как секунда звука это тысячи, – поэтому добавить субтитры к звонку, который уже идёт через SFU, это в основном вопрос проводки, а не новой инфраструктуры.

Одно уточнение делает паттерн эффективным, а не расточительным – и это шарнир всей конструкции: вы не распознаёте каждый аудиопоток постоянно. Вы распознаёте только те потоки, в которых в данный момент идёт речь. На входе перед дорогим ASR стоит небольшой и дешёвый детектор под названием Voice Activity Detection – VAD, программа, отвечающая на простой бинарный вопрос: «Говорит ли кто-то в этом звуке прямо сейчас?» Когда Мария говорит, её поток получает задачу распознавания; когда она замолкает – задача останавливается. Поскольку на реальной встрече одновременно говорят один-два человека, VAD-гейтинг означает, что вы платите за одну-две задачи распознавания, независимо от того, сколько людей находится в комнате.

Нажмите, чтобы увеличить

Считаем стоимость вслух

Причина, по которой паттерн важен с коммерческой точки зрения, – в том, что его стоимость можно посчитать одной строкой. Посчитаем. Потоковое распознавание речи тарифицируется по минутам обработанного аудио. Показательная ставка 2026 года – тариф Deepgram Nova-3, около $0,0077 за минуту, то есть примерно $0,46 за час звука.

Возьмём часовую встречу на 30 человек. Наивный подход – распознавать дорожку каждого участника на протяжении всей встречи – требует запуска 30 потоков по 60 минут:

наивная стоимость = 30 потоков × 60 мин × $0,0077/мин
наивная стоимость = 1 800 поток-минут × $0,0077
наивная стоимость = $13,86 за одну встречу

Теперь паттерн fan-out с VAD-гейтингом. На часовой встрече в среднем один активный говорящий за раз, иногда – двое: назовём это 1,5 потока реальной речи:

стоимость fan-out = 1,5 потока × 60 мин × $0,0077/мин
стоимость fan-out = 90 поток-минут × $0,0077
стоимость fan-out = $0,69 за одну встречу

Вот и весь аргумент в двух цифрах: $13,86 против $0,69 – разница в двадцать раз, за субтитры, которые при этом более согласованы и работают на слабых устройствах. Масштабируйте до продукта с десятью тысячами таких встреч в месяц – и разница составит примерно $138 600 против $6 900: между функцией, которая тихо приносит деньги, и той, что едва заметна в счёте. Рычаг – это VAD-гейтинг, и игнорировать его – самая дорогая ошибка во всей теме.

Черновик против финала: субтитр, который сам себя переписывает

У живых субтитров есть поведение, которое сначала может сбить с толку, и понимание его помогает избежать целый класс ошибок. Присмотритесь к живому субтитру – вы увидите, как слова появляются, потом меняются, потом застывают. «Думаю, нам стоит» становится «Думаю, нам стоит выпустить», а затем – «Думаю, нам стоит выпустить это в пятницу». Субтитр переписывает сам себя на месте. Это не ошибка; так работает потоковое распознавание, и ваш дизайн должен быть готов к такому поведению.

Потоковые ASR-движки выдают два типа результатов. Первый – черновик (partial), или промежуточный (interim) результат: быстрая, приблизительная догадка о сказанном, передаваемая, пока человек ещё говорит. Он помечен как не окончательный и, скорее всего, изменится по мере поступления новых звуковых данных и переосмысления движком. Второй – финальный результат, отправляемый, когда движок уверен, что фраза завершена и текст больше не изменится. Завершённость фразы движок определяет с помощью endpointing – обнаружения короткой паузы или спада речи, сигнализирующего о конце высказывания. Это та же идея, что и в VAD, но применяемая для поиска границ речи, а не просто для определения её наличия.

Компромисс – отзывчивость против стабильности. Показывать только финалы – и субтитры кажутся тормозными, появляясь с опозданием на секунду-другую после окончания фразы. Показывать черновики – и субтитры выглядят мгновенными, но мерцают, исправляя себя. В продакшен-системах используют черновики, чтобы субтитр казался живым: каждая строка фиксируется, как только приходит её финал – только что прочитанные слова перестают меняться, а ниже появляется следующая приблизительная догадка. Поэтому клиентский код должен трактовать входящий субтитр как замена текущей незавершённой строки, а не добавление новой, пока не придёт финал. Команды, добавляющие каждый черновик, получают субтитры, которые заикаются и дублируются; те, кто заменяет строки до получения финала, добиваются того самого чистого застывания, которого ждут пользователи. Подробнее о механике черновиков против финалов – в статье про потоковый ASR.

Нажмите, чтобы увеличить

Доставка текста: Data Channel

Субтитры сгенерированы и теперь должны быть доставлены на 30 экранов. Они не передаются вместе со звуком или видео – это непрерывные медиапотоки, в которых нет места для произвольного текста. Субтитры идут по отдельному каналу, встроенному в WebRTC специально для такой нагрузки: по data channel.

Data channel – это стандартизированный способ, с помощью которого браузеры в сессии WebRTC могут обмениваться произвольными данными, текстом или байтами. Он определён в спецификации IETF RFC 8831 «WebRTC Data Channels». Важно знать одно проектное решение, которое он предлагает, поскольку оно хорошо подходит для работы с субтитрами. Канал можно настроить как надёжный и упорядоченный – в этом случае каждое сообщение гарантированно доставляется и приходит в том же порядке, в каком было отправлено, – или как частично надёжный и неупорядоченный – система может терять или переставлять сообщения ради повышения скорости. Нижележащий транспорт, SCTP, обеспечивает надёжность и упорядоченность на уровне отдельных сообщений, а не всего соединения, поэтому приложение может использовать оба режима одновременно.

Для субтитров обычно выбирают надёжную и упорядоченную доставку: пропущенная или переставленная строка раздражает, а объём текста настолько мал, что обеспечить доставку практически ничего не стоит. Единственное исключение – черновики: поскольку каждый из них через мгновение будет заменён следующим черновиком или финальной версией, потеря одного по пути не критична, поэтому некоторые системы отправляют черновики «как получится», а финальные версии – надёжно. В любом случае субтитровый cue – текст, подпись говорящего и тайминг, те же поля, что и в cue WebVTT, – сериализуется, отправляется один раз из SFU в data channel и рассылается каждому участнику, который десериализует его и отображает на экране.

Здесь же фреймворки для конференций скрывают проводку. Например, LiveKit представляет транскрипцию как поток первого класса: его сервер публикует её клиентам, а клиентские SDK доставляют готовые к отображению текстовые события – приложение просто подписывается на субтитры, не разбирая data channel вручную. Open-source-стэки делают то же самое по-своему: серверный транскрайбер Jitsi, Jigasi, отправляет результаты распознавания обратно в встречу в формате JSON, который клиент Jitsi Meet преобразует в экранные субтитры. Под капотом – data channel; фреймворк лишь даёт ему более удобное имя.

Бюджет задержек для субтитров

Пользователи прощают субтитрам отставание от речи на мгновение; они не прощают отставание на много секунд. Поэтому полезно сложить, откуда берётся задержка субтитра, ведь итог – это бюджет, под который вы проектируете, та же дисциплина, что мы применяем ко всему звонку в статье про бюджет задержки до 100 мс, здесь применённая к тексту.

У путешествия субтитра – четыре участка. Первый: звук говорящего поднимается вверх в SFU – на приличном канале это занимает десятки миллисекунд. Второй: ASR-движок слушает и выдаёт черновик. Это самый продолжительный этап – обычно несколько сотен миллисекунд у быстрого потокового движка на первую догадку. Третий: текст субтитра спускается из SFU к участникам по data channel – снова десятки миллисекунд, ведь текст очень маленький. Четвёртый: клиент его отображает. Сложим участки:

задержка субтитра ≈ 80 мс (звук вверх) + 300 мс (черновик ASR) + 60 мс (текст вниз) + отрисовка
задержка субтитра ≈ менее полусекунды до первой черновой догадки

Итак, хорошо построенная функция субтитров показывает грубую строку примерно через полсекунды после того, как кто-то заговорил, а затем застывает её в финал через секунду-две, по мере завершения фразы. Доминирующий член – ASR-движок, поэтому при выборе вендора сравнивать нужно задержку до первого черновика движка, а не сеть. Всё, что добавляет сверху секунду – например, прогон звука через лишний шаг микширования перед распознаванием или ожидание финалов перед показом, – пользователи ощущают сразу, и это стоит оспаривать на ревью дизайна.

На клиенте или на сервере: таблица решений

Два подхода чётко выстраиваются по критериям, важным для описания функции.

Читайте таблицу по своему продукту. Групповой вебинар или класс, который вы записываете и хотите переводить, – однозначно серверный путь: вы получаете одну расшифровку, которая одновременно субтитрует, архивирует и обеспечивает перевод. Приватный продукт «один на один», где звук не должен попадать на сервер, – это клиентский путь, с более высокой стоимостью обработки на устройстве. Большинство конференц-решений – первый случай, поэтому паттерн fan-out используется по умолчанию.

Частая ошибка: распознавать каждую дорожку всё время

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

Потом система участвует в общей встрече из 30 человек, и счёт оказывается в двадцать раз выше ожидаемого – как показала математика выше, без какой-либо пользы: 28 молчащих участников генерируют пустые расшифровки по полной цене. Это лечится не более быстрым движком и не более дешёвым поставщиком, а VAD-гейтом. Сначала обнаруживай речь, потом распознавай. Второй, родственный, промах – оставлять распознавание активным во время долгих пауз в одном потоке; тот же гейт решает и эту проблему. Относитесь к вопросу «говорит ли кто-то на этом потоке прямо сейчас» как к тому, на который нужно получить дешёвый ответ прежде, чем тратить деньги на ответ «что они говорят» – и проблема стоимости исчезает.

Строить на фреймворке, покупать API или и то, и другое

Когда паттерн определён, остаётся практический выбор – из чего его собирать. У каждого из трёх слоёв есть своё решение «строить или покупать», и они независимы друг от друга.

Первый – медиасервер. Можно развернуть open-source SFU, например mediasoup, Janus или Jitsi, и полностью контролировать аудиозапись, либо воспользоваться хостинговой real-time-платформой вроде LiveKit, которая предоставляет SFU и встроенную транскрипцию – тогда субтитры становятся скорее настройкой, чем проектом. Самостоятельный хостинг заменяет инженерное время на контроль и более низкую стоимость за минуту; хостинговое решение, в свою очередь, заменяет затраты на скорость запуска.

Второй – движок распознавания, и здесь вы почти всегда используете API. Вендоры потокового ASR различаются по параметрам, важным для живых субтитров: задержка до первого черновика, точность на шумном реальном звуке, поддержка языков и цена. Deepgram лидирует по низкой задержке и выгодной цене, AssemblyAI и Speechmatics – по точности на «грязном» звуке, а self-hosted Whisper или речевой стек NVIDIA – оптимальный выбор, если звук не должен покидать вашу инфраструктуру или поминутная оплата должна стремиться к нулю при масштабировании. Подробное сравнение – в статье про потоковый ASR; паттерн для конференций, описанный в этой статье, остаётся одинаковым вне зависимости от выбранного движка.

Третий – это работа с сырой расшифровкой: разметка, определение, кто говорил (то есть диаризация диктора), когда участники не разделены по дорожкам; предварительная очистка звука с помощью шумоподавления, чтобы система распознавала слова, а не посторонние шумы, например, стук клавиатуры; и, если вы работаете с несколькими языками, передача той же расшифровки в перевод речи в реальном времени. Паттерн fan-out – это основа; всё остальное – как мышцы, которые вы к ней добавляете.

Где Здесь Фора Софт

Мы создаём живые видеопродукты, в которых субтитры стали обязательным элементом: платформы видеоконференций, виртуальные классы и e-learning, телемедицинские консультации, инструменты прямых трансляций и вебинаров – всё это строится на паттерне fan-out на стороне SFU, описанном в этой статье, потому что именно эта архитектура выдерживает нагрузку реальных клиентских сценариев. Дисциплина, которую мы применяем, – та, что изложена здесь: распознавание речи выполняется на медиасервере, который вы и так используете, и выносится за пределы детектора речевой активности, чтобы оплата шла за активных говорящих, а не за все подключённые места; черновики субтитров рассматриваются как незавершённые строки, фиксируемые только в конце; а текст доставляется по надёжному data channel, чтобы каждый участник видел одинаковый субтитр. Поскольку мы работаем в сфере образования и здравоохранения, мы закладываем дедлайны доступности с самого начала, а не добавляем субтитры задним числом, и поддерживаем центральную расшифровку, готовую обеспечить запись, поиск и перевод – ведь клиент, запросивший субтитры в этом квартале, почти наверняка потребует их и в следующем.

Ключевые выводы

• Живой субтитр – это текст с таймингом и указанием говорящего, созданный системой распознавания речи (ASR) и отображаемый с задержкой в одну–две секунды.
• Распознавайте речь один раз на каждого участника на SFU и распространяйте текст «веером», а не на каждом устройстве отдельно.
• VAD-гейт снижает затраты: вы платите только за активных участников, а не за все подключённые места.
• Субтитры поступают в виде быстрых черновиков, которые автоматически обновляются и в итоге фиксируются в окончательном варианте.
• Текст субтитров передаётся по data channel WebRTC (RFC 8831), как правило, надёжно и в правильном порядке.
• Живые субтитры являются требованием уровня AA в стандарте WCAG и станут обязательными для крупных государственных органов США с апреля 2026 года.

Что Почитать Далее

• Потоковый ASR в продакшене – Deepgram, Whisper, AssemblyAI
• WebRTC + AI: Insertable Streams, Encoded Transform и SFU
• Перевод речи в реальном времени в звонках