WebRTC + AI: Insertable Streams, Encoded Transform, WebGPU и сравнение video SDK

Кратко

Добавить ИИ в живой видеопродукт – это два вопроса: где в конвейере WebRTC вашему коду разрешено обрабатывать каждый кадр и может ли выбранный video SDK вообще получить доступ к этим кадрам. Браузер теперь предлагает две официальные точки вставки – путь сырых кадров для on-device ИИ (в паре с WebGPU для быстрого инференса) и путь закодированных кадров для сквозного шифрования и работы с метаданными – и выбор точки определяет, что сможет делать ИИ-функция, а что – нет. На стороне «купить» рынок video SDK в 2026 году чётко делится на закрытые managed-платформы, которые запускаются быстро, но полностью контролируют конвейер, и открытые фреймворки вроде LiveKit, которые предоставляют доступ к кадрам и возможность self-host. Эта статья описывает и то, и другое: точки вставки ИИ на основе стандартов и актуальное сравнение с ценами – 100ms, Agora, Daily, Twilio Video, Vonage, Zoom Video SDK, Amazon Chime SDK и LiveKit.

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

Если вы продакт-менеджер, основатель или техлид и решаете, стоит ли добавлять видео в продукт – или внедрять поверх него ИИ-функции вроде размытия фона, живых субтитров или агента в звонке, – выбор video SDK задаёт потолок для всего, что вы построите дальше. Выберите закрытую managed-платформу – и запустите рабочий звонок за неделю, но через полгода можете обнаружить, что не сможете интегрировать свою модель в медиапоток. Выберите открытый фреймворк – получите полный контроль, но за счёт увеличения объёма разработки. Эта статья предлагает стандарты, определяющие, где в WebRTC-звонке может применяться ИИ, а также сравнение SDK с ценами и оценкой их готовности к ИИ, чтобы разговор «сделать или купить» произошёл до того, как вы окажетесь в тупике, а не после.

Сначала: что такое «video SDK»

Video SDK – это готовый набор инструментов (библиотеки кода и хостинговый бэкенд), который позволяет разработчику добавить живые видеозвонки в приложение, не создавая сложные компоненты с нуля. Эти сложные задачи вполне реальны: захват камеры и микрофона, сжатие потоков, прохождение через файрволы, маршрутизация медиа между несколькими участниками, запись и тысячи краевых случаев при плохой сети. Video SDK решает всё это всего несколькими вызовами функций.

Полезно различать два термина, которые часто путают. video sdk – это клиентская библиотека, которую вы подключаете к веб-, iOS- или Android-приложению. video conferencing api – это серверный интерфейс: хостинг комнат, токены, запись и вебхуки, с которыми взаимодействует библиотека. На практике крупные вендоры предлагают и то, и другое как единый продукт, поэтому, когда в статье говорят «video SDK», обычно имеют в виду весь пакет – библиотеки и облачную инфраструктуру за ними.

Почти все эти продукты построены на одном фундаменте – WebRTC. WebRTC (Web Real-Time Communication) – это открытый стандарт, позволяющий браузерам и приложениям напрямую обмениваться аудио, видео и данными с минимальной задержкой. Базовая платформа достигла финальной стадии, когда консорциум World Wide Web Consortium – организация, отвечающая за стандартизацию веб-технологий, – 13 марта 2025 года опубликовал WebRTC 1.0 как полноценную Recommendation. Под браузерным API лежит семейство транспортных спецификаций Internet Engineering Task Force – RFC 8825–8834, – которые определяют, как защищается и передаётся медиаданные. Для покупателя вывод один: все вендоры используют один и тот же базовый язык; различаются лишь объём и степень его открытости для вас.

Главный вопрос: можете ли вы добраться до кадров?

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

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

Сам браузер теперь определяет ровно две станции, на которых вашему коду разрешено находиться. Понять их – и есть вся суть.

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

Точка первая: сырые кадры, где живёт on-device AI

Первая станция – точка сырых кадров. Здесь кадр – это настоящая, несжатая картинка, сетка пикселей: либо сразу после съёмки камерой и до сжатия, либо сразу после распаковки на принимающей стороне и до отображения на экране. Здесь работает зрительный ИИ, потому что модель, которая выделяет человека на фоне или находит лицо, должна видеть реальные пиксели, а не сжатые данные.

Браузер подключается к этой точке через спецификацию W3C под названием MediaStreamTrack Insertable Media Processing using Streams, обычно сокращаемую до «insertable media processing» или «mediacapture-transform». Она передаёт коду каждый кадр с камеры в виде объекта VideoFrame, который можно прочитать, изменить и отправить дальше. В паре с ней работает WebCodecs – ещё одна спецификация W3C, находящаяся на стадии стандартизации, – обеспечивающая низкоуровневый доступ к кодерам и декодерам, чтобы при необходимости самостоятельно сжимать или распаковывать кадры.

Подвох обработки сырых кадров – в скорости. При 30 кадрах в секунду новый кадр приходит каждые 33 миллисекунды, и ваш ИИ-работник должен успеть обработать его до появления следующего – иначе видео начнёт подрагивать. Сделаем простой расчёт: одна секунда, делённая на 30 кадров, даёт 0,033 секунды, то есть 33 миллисекунды на кадр. Модель, требующая 40 миллисекунд, не просто создаёт задержку – она пропускает каждый третий кадр. Поэтому искусственный интеллект, работающий с сырыми кадрами, обязан быть быстрым, и тут на помощь приходит графический чип.

WebGPU: движок, который делает on-device ИИ достаточно быстрым

Современная модель ИИ работает на графическом процессоре (GPU) – чипе, изначально созданном для отрисовки графики в играх, – намного быстрее, чем на универсальном CPU, потому что GPU одновременно выполняет тысячи мелких вычислений. До недавнего времени у браузеров не было прямого способа использовать GPU для общих вычислений. Это изменил WebGPU – стандарт W3C, обеспечивающий веб-коду прямой и современный доступ к GPU как для графики, так и для численных расчётов.

Важность WebGPU для этой статьи – в сроках. К концу 2025 года он достиг статуса, который веб-сообщество называет «Baseline»: каждый крупный браузер теперь включает его по умолчанию. В Chrome он доступен с версии 113 ещё с 2023 года; Firefox включил его на Windows в версии 141 в июле 2025 года и на Mac с Apple Silicon – в версии 145; Safari представил его в Safari 26 на macOS, iOS и iPadOS. Впервые разработчик может рассчитывать на наличие быстрого on-device ИИ-движка в браузере без плагинов и без включения экспериментальных флагов.

Сложите всё вместе – и проступает ясная возможность. API сырых кадров передаёт коду каждый кадр с камеры; WebGPU обрабатывает его с помощью модели за пару миллисекунд; изменённый кадр возвращается в конвейер до кодирования. Именно так работают продакшен-эффекты вроде размытия фона и сегментации: модель Google MediaPipe Selfie Segmentation обрабатывает кадр в браузере менее чем за три миллисекунды на GPU, легко укладываясь в 33-миллисекундный бюджет. Эту конкретную функцию мы подробно разбираем в материале о размытии фона; здесь важна структура: сырые кадры плюс WebGPU – это путь on-device ИИ, и он целиком работает на устройстве пользователя при нулевой сетевой нагрузке.

Точка вторая: закодированные кадры, где живёт шифрование

Вторая станция – это точка закодированных кадров, и она расположена совсем в другом месте: после сжатия видео, между кодером и тем участком конвейера, который разбивает сжатые данные на сетевые пакеты. На этом этапе кадр уже не является изображением, которое можно рассмотреть, а представляет собой компактный блок закодированных байтов. Запустить на нём зрительный ИИ невозможно – ведь нет пикселей, которые можно было бы проанализировать. Так зачем же нужен доступ именно сюда?

Две причины – шифрование и метаданные. Браузер подключается к этой точке через спецификацию WebRTC Encoded Transform – проект стандарта W3C. Основной объект API называется RTCRtpScriptTransform. Он заменяет более ранний, ныне устаревший подход под названием Insertable Streams: если в старых статьях или примерах кода вы встречаете createEncodedStreams, это устаревшее имя той же концепции, и в новых проектах следует использовать API Encoded Transform. Firefox поддерживает его начиная с версии 117; Chrome также его поддерживает.

Главное применение точки закодированных кадров – сквозное шифрование. В обычном групповом звонке медиасервер посередине, известный как Selective Forwarding Unit (SFU), поскольку он пересылает видео каждого участника всем остальным, технически может просматривать передаваемые медиа. Сквозное шифрование устраняет эту уязвимость, шифруя каждый кадр прямо на устройстве отправителя так, что расшифровать его могут только другие участники, а сервер способен лишь маршрутизировать трафик, но не просматривать содержимое. Стандарт, определяющий этот подход, – IETF RFC 9605 «Secure Frame» (август 2024) – шифрует целые медиакадры, оставляя открытыми лишь небольшие метаданные маршрутизации, необходимые SFU. API Encoded Transform – это точка, в которой ваш код может применить такое шифрование. То есть точка закодированных кадров – не инструмент для визуального ИИ; это инструмент безопасности и сигнализации, и путать эти две вещи – частая и дорогостоящая ошибка.

«Частая ошибка: команды слышат «Insertable Streams позволяют обрабатывать медиа» и думают, что именно сюда подключается модель размытия фона или субтитров. Это не так. Точка закодированных кадров работает со сжатыми байтами и нужна для шифрования и метаданных; зрительный и звуковой ИИ должны работать в точке сырых кадров на несжатых данных. Подключение модели к неверной станции означает, что у неё нет пикселей, и она тихо не делает ничего полезного.»

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

Почему выбор SDK решает всё вышесказанное

Теперь две части статьи соединяются. Всё, что говорилось выше, предполагает, что вы можете получить доступ к кадрам. А сможете ли вы это сделать на самом деле – зависит исключительно от выбранного video SDK, поскольку каждый вендор сам определяет, насколько глубоко открывать конвейер WebRTC.

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

Это и есть ось «build против buy», и для ИИ-видеопродукта она важнее цены. Дешёвый SDK, замыкающий конвейер, может оказаться самым дорогим решением, если он блокирует ключевую функцию, от которой зависит ваш продукт.

Ландшафт Video SDK в 2026

Рынок консолидировался и изменился с тех пор, как появился WebRTC, и перед сравнением решений стоит учесть несколько важных изменений.

100ms – платформа инфраструктуры живого видео, основанная в 2020 году инженерами, ранее работавшими над масштабным стримингом в Disney+ Hotstar и Meta. Её ключевое предложение – единый SDK, объединяющий конференции на базе WebRTC, HLS-стриминг, чат и запись, а также готовые компоненты интерфейса, позволяющие командам быстро запускать продукты. Ценообразование – pay-as-you-grow: около $0,004 за участнико-минуту видео, аудио-нагрузки – со скидкой до 75%, бесплатный тариф включает до 10 000 минут в месяц и ИИ-транскрипцию «из коробки». Это управляемая (managed) платформа: быстрая интеграция в продакшн, основная часть конвейера работает в их облаке.

Agora – одна из старейших чистых платформ реального времени. Её тарифы на 2026 год остаются на уровне около $0,99 за тысячу аудио-минут и $3,99 за тысячу минут HD-видео, при этом предоставляется 10 000 бесплатных минут в месяц, общих для всех RTC-продуктов, и действуют автоматические скидки 5–10% на старших тарифных планах. Платформа богата возможностями, работает глобально и является managed-решением.

Daily известна высоким качеством опыта разработчика и прозрачной ценовой моделью: 10 000 бесплатных участнико-минут в месяц, далее – ровно 0,004 доллара за участнико-минуту с автоматическими скидками при увеличении объёма. Платформа предоставляет больше возможностей низкоуровневого контроля, чем большинство managed-провайдеров, и активно развивает инструменты для ИИ-агентов.

Twilio Video требует уточнения, потому что в интернете до сих пор ходят устаревшие заявления о его закрытии. В марте 2024 года Twilio объявил о прекращении поддержки Programmable Video, но уже в октябре 2024 года отменил это решение: Twilio Video остаётся самостоятельным продуктом, пользователям ничего делать не нужно, а фокус смещён на видеосвязь «один на один» для взаимодействия с клиентами. Если вы читаете статью 2024 года, в которой говорится о его закрытии, эта информация устарела.

Vonage Video API – наследник TokBox OpenTok, одного из первых игроков на рынке WebRTC. Платформа продолжает работать, однако оригинальная линейка SDK OpenTok переведена в режим поддержки и интегрирована в «Unified» Vonage Video API с новой системой аутентификации (Application ID и приватный ключ вместо прежнего API-ключа и секрета). Проекты, использующие OpenTok, должны планировать миграцию – это задача на 2026 год, а не опциональная возможность.

Zoom Video SDK позволяет разработчикам интегрировать медиадвижок Zoom в собственные приложения – это отдельный продукт от Zoom Meetings. Стоимость составляет около 0,0035 доллара за участнико-минуту (3,50 доллара за тысячу минут) и реализуется через платформу Zoom Build пакетами кредитов: 100 кредитов за 100 долларов и 500 кредитов за 450 долларов. Отсутствие полноценного pay-as-you-go режима делает использование SDK неудобным при всплесковых или сезонных нагрузках.

Amazon Chime SDK – это подход AWS «из строительных блоков»: оплата по факту без минимальных сумм, аудио – по $0,0017 за минуту на участника, видео – по битрейту: от $0,0015 за минуту при низком качестве до $0,017 за минуту при скорости выше двух мегабит в секунду. Естественно интегрируется с остальной частью AWS и является разумным выбором для команд, уже глубоко погружённых в эту экосистему.

LiveKit – выдающийся открытый фреймворк. Его сервер с открытым исходным кодом позволяет размещать его самостоятельно и платить только за собственную облачную инфраструктуру, либо использовать LiveKit Cloud с бесплатным тарифом Build (5 000 минут WebRTC, 50 ГБ исходящего трафика, 1 000 минут ИИ-агента в месяц), тарифом Ship за 50 долларов и тарифом Scale за 500 долларов. Стоимость минуты WebRTC-соединения составляет около 0,0004–0,0005 доллара плюс трафик – 0,10–0,12 доллара за гигабайт. Поскольку LiveKit полностью раскрывает конвейер и предлагает отдельный фреймворк для ИИ-агентов, он стал естественным выбором для команд, чья основная продукция – это ИИ-функция, а не обычные звонки. Архитектуру и ценообразование мы подробно разбираем в уроке про ассистента встреч на LiveKit.

Сравнение, которое важно: цена и готовность к ИИ

Цена сама по себе обманчива, потому что SDK рассчитываются по-разному – одни по участнико-минуте, другие по тысяче минут, третьи по объёму трафика, – и потому что самый дешёвый запечатанный конвейер может не поддерживать нужную вам функцию. Ниже приведённая таблица сопоставляет цифры 2026 года с колонкой, которую большинство сравнений игнорирует: можно ли интегрировать собственный ИИ в медиапоток.

Закономерность – вот суть. Управляемые платформы группируются вокруг $0,004 за участнико-минуту и жертвуют контролем над конвейером ради скорости доставки. Блочные и открытые решения (Amazon Chime SDK, LiveKit) дешевле по минутной ставке, но требуют больше усилий от инженеров – именно они позволяют привлечь нужные для ИИ кадры. Единого победителя нет – есть лишь соответствие вашим приоритетам.

Расчёт на примере: во что реально обходится 1 000 групповых звонков

Цифры делают компромисс осязаемым. Допустим, продукт проводит 1 000 групповых звонков в месяц, по четыре участника на 30 минут. Расчётная единица у большинства вендоров – участнико-минута, поэтому сначала посчитаем объём:

1 000 звонков
× 4 участника
× 30 минут
= 120 000 участнико-минут в месяц

На managed-платформе – по 0,004 доллара за участнико-минуту, без бесплатного тарифа:

120 000 участнико-минут
× $0,004
= $480 в месяц

Вычтем 10 000 бесплатных минут – останется около 440 долларов. На LiveKit Cloud та же нагрузка рассчитывается в WebRTC-минутах по примерно 0,0005 доллара за минуту плюс трафик, который при групповом видео стандартного разрешения обычно обходится дешевле в пересчёте на минуту, но добавляет отдельную плату за egress – поэтому итоговая стоимость зависит не только от количества минут, но и от битрейта видео. Суть не в том, что «X дешевле». Суть в том, что сравнивать два SDK можно только тогда, когда оба приведены к одной единице измерения и учтён трафик там, где модель тарифицирует его отдельно. Базовая ставка за минуту, игнорирующая egress, может занижать реальную стоимость почти вдвое. Скачиваемый воркшит в конце автоматически пересчитывает эти цифры для каждого вендора из таблицы.

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

Как ИИ-функции интегрируются в две точки вставки

Чтобы замкнуть круг, вот как распространённые функции ИИ встраиваются в конвейер обработки видео – чтобы вы могли понять, поддерживает ли их конкретный SDK. Функции, которым нужны пиксели – размытие фона, виртуальные фоны, бьюти-фильтры, детекция лиц, субтитры на устройстве – размещаются на этапе сырых кадров и зависят от того, предоставляет ли SDK доступ к кадрам камеры и интерфейсу WebGPU. Функции, требующие безопасности – сквозное шифрование, водяные знаки в метаданных – работают на этапе закодированных кадров и зависят от поддержки Encoded Transform. А функции, выполняемые на сервере, а не в браузере – серверная транскрипция, анализ записи, агент в звонке, подключающийся как участник – не нуждаются ни в одной из точек вставки на стороне клиента; им нужен SDK, позволяющий боту подписаться на медиасервер, и здесь особенно хорошо зарекомендовали себя открытые фреймворки и блочные платформы.

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

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

Мы разрабатываем продукты для живого видео с 2005 года – видеоконференции, WebRTC-приложения, e-learning, телемедицину и видеонаблюдение в реальном времени. Вопрос «разрабатывать или покупать» SDK почти на каждом проекте становится первым архитектурным решением. Мы начинали с managed-платформ, когда важна была скорость вывода продукта на рынок, и выбирали открытые фреймворки вроде LiveKit, когда ключевая ценность продукта заключалась в ИИ-функционале внутри звонков. Наша инженерная команда регулярно публикует анализы стоимости и миграций между этими платформами, потому что правильный выбор зависит от масштаба, дорожной карты функций и того, какой частью медиапути продукт должен управлять. Наша задача – подобрать SDK под тот ИИ, который вы планируете внедрить, чтобы решение, принятое на первой неделе, по-прежнему поддерживало функцию, придуманную через два года.

Главное

• Video SDK объединяет захват, транспорт и маршрутизацию WebRTC всего в несколько вызовов функций.
• Браузер предоставляет две точки интеграции для ИИ: сырые кадры – для компьютерного зрения, закодированные – для шифрования и работы с метаданными.
• Обработка ИИ на сырых кадрах с использованием WebGPU выполняется на устройстве за миллисекунды; WebGPU теперь является базовой технологией во всех современных браузерах.
• Encoded Transform (ранее Insertable Streams) предназначен для шифрования и добавления метаданных, а не для задач компьютерного зрения.
• Управляемые SDK запускаются быстро, но ограничивают гибкость медиапотока; открытые фреймворки дают доступ к нужным кадрам для ИИ.
• Выбирайте SDK в первую очередь исходя из того, должен ли продукт контролировать медиапуть, а уже затем – по цене.

Что почитать дальше

• Бюджет задержки real-time ИИ: как уложиться в 100 мс
• Как размыть фон в Zoom, Teams и на iPhone – инженерный разбор
• Ассистент встреч на LiveKit – архитектура и цены