Сегментация MediaPipe Selfie V2 на WebGPU – размытие фона для рабочей системы

TL;DR

ИИ-размытие фона – эффект, который скрывает комнату за вами на видеозвонке, размывая каждый пиксель, не относящийся к телу, – стало базовым ожиданием для любого веб-видео-продукта. На 2026 год самый дешёвый, быстрый и архитектурно защищённый способ доставить его в браузер – это MediaPipe Image Segmenter с моделью selfie-сегментации на бэкенде WebGPU, скомпонованный через WebRTC Insertable Streams. Весь пайплайн весит около 450 КБ модели плюс 200 КБ WebAssembly-рантайма, работает на 30–60 кадрах в секунду на ноутбуке среднего класса, не требует сервера и корректно деградирует до WebGL в браузерах без поддержки WebGPU. Сложности не в модели – они в рендер-пайплайне, в разрыве между Chrome и Safari, в дрожании краёв на плечах, которое подрывает доверие пользователя, и в том, что посредственная статическая глубина размытия в Google Meet задала неверное ожидание. В этой статье разбираются модель, WebGPU-обработчик, интеграция с WebRTC, цепочка кросс-браузерных фолбэков и три ошибки, которые мы до сих пор видим в продакшене.

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

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

Пайплайн, описанный здесь, использует ту же архитектуру, что и в Google Meet, Zoom Web SDK, виджетах комнат 100ms, Daily и LiveKit, а также во всех white-label-решениях для видеоконференций, которые мы создавали с 2024 года. Эта статья предполагает, что вы ознакомились с уроком 2.1 по предобработке для CV и уроком 2.4 по SAM 2, поскольку размытие фона – это частный случай семантической сегментации, а базовые примитивы из этих уроков лежат в основе любого эффекта, который мы опишем далее.

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

Что такое «размытие фона» – пиксели, а не магия

Эффект, который все называют размытием фона, – это двухэтапная обработка изображения. На первом этапе – семантическая сегментация – для каждого пикселя входного кадра небольшая нейросеть выдаёт вероятность от 0 до 1 того, что этот пиксель относится к человеку, а не к фону. На втором этапе – компоновка – рендерер, используя эту маску вероятностей, смешивает чёткий оригинальный кадр (для пикселей человека) с гауссово-размытой копией того же кадра (для пикселей фона). Результат выглядит как глубина резкости реальной камеры, хотя никакой камеры не было: размытие программное, глубина резкости определена нейросетью, а граница между чёткими и размытыми участками задаётся маской размером 256×256 пикселей в градациях серого.

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

Современный эффект достигается благодаря модели. Пять лет назад сегментация человека от фона в реальном времени требовала либо камеры с датчиком глубины (например, Microsoft Kinect или iPhone TrueDepth), либо мощного серверного GPU. Мобильные архитектуры уровня смартфона, появившиеся в период с 2019 по 2022 год – такие как MobileNetV3 и её производные – позволили запускать сегментацию в реальном времени на том же CPU, который обрабатывает поток с веб-камеры. Модель, используемая в MediaPipe selfie segmentation, ML Kit и в режиме размытия фона в Google Meet, – одна из таких мобильных архитектур.

Модель MediaPipe Selfie Segmentation – Цифры, Которые Имеют Значение

MediaPipe selfie-сегментер – это бинарная сеть семантической сегментации с 106 000 параметров и размером файла 447 КБ в формате float32, который сокращается до примерно 230 КБ после INT8-квантизации. Архитектура основана на кастомной версии MobileNetV3 с модифицированной энкодер-декодерной структурой в стиле U-Net: бэкбон извлекает многомасштабные признаки, которые затем апсемплируются и объединяются в одноканальный выходной тензор той же высоты и ширины, что и вход. В model card описаны два варианта: general – принимает RGB-изображение размером 256×256 и выдаёт маску 256×256, и landscape – принимает изображение 144×256 и выдаёт маску 144×256. У модели landscape примерно в три раза меньше FLOPs по сравнению с general, и она работает соответственно быстрее; именно этот вариант используется для размытия фона в Google Meet.

Латентность, измеренная Google на Pixel 6 с GPU-бэкендом, составляет около 2 миллисекунд на кадр для general-модели и около 1 миллисекунды на кадр для landscape-модели. На современном ноутбучном процессоре (Apple M2, Intel Core i7 12-го поколения) с WebAssembly SIMD-бэкендом из пакета @mediapipe/tasks-vision та же модель работает со скоростью 5–10 миллисекунд на кадр – достаточно быстро для 30 fps с веб-камеры с запасом времени на стадию компоновки. На WebGPU-бэкенде модель обрабатывает кадр за 1–3 миллисекунды на том же железе, оставляя около 30 миллисекунд из 33-миллисекундного бюджета кадра на выполнение остальных задач.

Модель выдаёт 6-классовый выход (фон, волосы, кожа тела, кожа лица, одежда, прочее) в полной форме, но для размытия фона нам важна только одна граница: человек против не-человека. Большинство production-пайплайнов сводят 6-классовый выход к бинарной маске одним шагом – через softmax argmax или просто суммируя пять каналов «человека» и сравнивая результат с порогом.

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

У модели две известные слабости, и каждое production-развёртывание вынуждено их обходить. Первая: граница не может быть острее, чем позволяет разрешение в 256 пикселей. Маска для потока с вебкамеры 1080p апсемплируется примерно в 4 раза по каждому измерению, и наивный билинейный апсемпл даёт мягкий край, который выглядит нормально на щеке, но плохо – на отдельных прядях волос. Вторая: модель обучалась на одиночных людях, в кадре «голова-плечи», в помещении, с consumer-расстоянием до камеры; она плохо обобщается на несколько людей, экстремальные крупные планы, back-lit-сцены и широкоугольную съёмку с большого расстояния. Обе слабости устранимы, и фиксы мы разбираем ниже.

Почему WebGPU меняет арифметику

Раньше модель работала на WebGL. Она и сейчас может – и на 2026 год WebGL остаётся правильным бэкендом для пользователей Safari 17 и старше, для версий Firefox старше релизов с WebGPU 2025 года, и для примерно 8% пользователей Chrome в мире, чьё железо занесено в WebGPU-блоклист. WebGL работает потому, что сеть сегментации – стек свёрток, а fragment-шейдер можно заставить умножать матрицы, кодируя тензоры как текстуры и трактуя каждый draw call как dispatch вычисления. Это тот же тип обхода, что строила команда TensorFlow.js и что был в оригинальном веб-порте MediaPipe – и работает он от «достаточно быстро» до «больно» в зависимости от драйвера и GPU.

WebGPU изначально создавался для общих вычислений, а не для графики. Compute-шейдер имеет прямой доступ к буферам, поддерживает разделяемую память workgroup и явную синхронизацию; он может запускать workgroup из 16×16×1 потоков на произвольный тензор, не имитируя при этом треугольный графический пайплайн. На практике это даёт в сети для сегментации селфи ускорение в 3–5 раз по сравнению с WebGL на том же оборудовании и снижает накладные расходы на GPU-переносы памяти на 30–40%. Вендорские бенчмарки из обзора WebGPU 2026 на Sitepoint (Google, NVIDIA, Intel) показывают, что для ИИ-инференса в целом WebGPU обеспечивает ускорение в 15–30 раз по сравнению с WebGL на трансформерных архитектурах – сегментация селфи находится на нижнем конце этого диапазона, поскольку это чисто CNN-модель с небольшими активациями, однако прирост остаётся значительным.

Вторая причина важности WebGPU – поддержка браузерами. Chrome и Edge включили WebGPU по умолчанию на десктопах в мае 2023 года (версия 113) и на Android в 2024 году (версия 121). Firefox 141, вышедший в середине 2025 года, добавил WebGPU по умолчанию на Windows. Safari 18, релиз которого состоялся в конце 2024 года, включил WebGPU по умолчанию на macOS, iPadOS и iOS. К маю 2026 года от 92% до 96% глобальных пользователей Chrome, все пользователи актуальных версий Safari и большинство пользователей свежих Firefox имеют доступ к WebGPU. Этого достаточно, чтобы сделать WebGPU основным бэкендом, а WebGL – резервным, и именно эта инверсия стала причиной переписывания пайплайна.

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

Полный пайплайн – от getUserMedia до WebRTC

Production-размытие фона – это не просто вызов API. Это четырёхэтапный пайплайн, начинающийся на камере и завершающийся в WebRTC peer connection.

Стадия 1 – захват. Вызов navigator.mediaDevices.getUserMedia() возвращает MediaStream с одним видео-MediaStreamTrack. Этот трек является источником для всех последующих стадий. При входном разрешении 720p и частоте кадров 30 fps кадры поступают в виде объектов VideoFrame размером 1280×720 через API WebCodecs.

Стадия 2 – инференс. Каждый кадр передаётся в MediaPipe Image Segmenter через метод segmentForVideo(videoFrame, timestamp), который уменьшает разрешение входного изображения до 256×256, запускает модель на WebGPU-бэкенде и возвращает объект MPMask. По умолчанию маска на WebGPU хранится как GPU-текстура и не копируется в память CPU – именно это и обеспечивает половину скорости работы всего пайплайна.

Стадия 3 – компоновка. WebGPU fragment-шейдер принимает три входных изображения: оригинальный кадр разрешения 1280×720, его гауссово размытое копирование того же размера и маску 256×256. Для каждого выходного пикселя шейдер сэмплирует значение маски (с билинейной фильтрацией), использует его как вес для смешивания резкого и размытого кадров и записывает результат в offscreen-канвас. Сам гауссов фильтр реализован в два прохода – сначала горизонтальный, затем вертикальный – с одномерным ядром из 21 тапа и параметром сигмы, подобранным под визуальный эффект продукта: сигма 8 для плавного, Zoom-подобного размытия, сигма 16 – для сильного размытия, сигма 4 – для едва заметного эффекта, придающего профессиональный вид.

Стадия 4 – кодирование. Offscreen-канал оборачивается в MediaStreamTrackGenerator (Chrome) или VideoTrackGenerator (Safari, Firefox через спецификационный API), что позволяет получить MediaStreamTrack, выглядящий для WebRTC как обычный трек камеры. Этот трек добавляется в RTCPeerConnection с помощью pc.addTrack(processedTrack, processedStream), и с точки зрения получателя разницы между размытым и неразмытым отправителем не возникает.

Машинерия Insertable Streams – это компонент, соединяющий стадии 2–4. MediaStreamTrackProcessor читает камера-трек как ReadableStream из VideoFrame; вы обрабатываете эти кадры на стадиях 2 и 3; и записываете результат в VideoTrackGenerator, чтобы получить WritableStream из VideoFrame обратно. Вся обработка происходит полностью в фоновом потоке внутри Worker, что обеспечивает отзывчивость интерфейса даже на ноутбуке четырёхлетнего возраста.

// Скелет — внутри Worker, бэкенд WebGPU.
import { ImageSegmenter, FilesetResolver } from "@mediapipe/tasks-vision";

const vision = await FilesetResolver.forVisionTasks(
  "https://cdn.jsdelivr.net/npm/@mediapipe/tasks-vision/wasm",
);
const segmenter = await ImageSegmenter.createFromOptions(vision, {
  baseOptions: {
    modelAssetPath: "selfie_segmenter.tflite",
    delegate: "GPU",          // WebGPU в Chrome/Edge/Firefox/Safari
  },
  runningMode: "VIDEO",
  outputCategoryMask: true,
  outputConfidenceMasks: false,
});

const processor = new MediaStreamTrackProcessor({ track: cameraTrack });
const generator = new VideoTrackGenerator();
const reader = processor.readable.getReader();
const writer = generator.writable.getWriter();

while (true) {
  const { value: frame, done } = await reader.read();
  if (done) break;
  const mask = segmenter.segmentForVideo(frame, performance.now()).categoryMask;
  const composited = compositorRun(frame, mask, blurSigma);  // WebGPU shader
  await writer.write(composited);
  frame.close();
  mask.close();
}

Полная реализация – около 350 строк TypeScript, включая WebGPU-шейдер. Мы поддерживаем open-source-референс в GitHub-организации Фора Софт и поставляем этот же паттерн по умолчанию в наших клиентских обёртках для LiveKit и 100ms.

Кросс-браузерная реальность – лестница детекции возможностей

API Insertable Streams пока что поддерживается неравномерно. Chrome и Edge предоставляют предварительные версии от Google MediaStreamTrackProcessor и MediaStreamTrackGenerator как в основном потоке, так и в воркерах – для аудио- и видео-треков. Safari 18 Tech Preview и Firefox 141+ используют стандартные варианты от W3C – MediaStreamTrackProcessor и VideoTrackGenerator, – но только внутри воркеров и исключительно для видео-треков. Стандартная реализация – это то, к чему в итоге должен прийти Chrome, тогда как предварительная версия остаётся наиболее распространённой на данный момент.

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

Почему лестница важна: попадание на уровень 4 для пользователя Safari 17 на десктопе даёт визуально худший результат, чем уровень 1 на пользователе Chrome на том же железе, и пользователи уровня 4 сообщат об этом как о баге. Мы научились показывать активный уровень пользователю в маленькой ненавязчивой подсказке UI – «размытие фона использует ваш CPU, качество может быть снижено» – потому что пользователи, понимающие компромисс, заводят меньше тикетов поддержки, чем те, кто не понимает.

Распространённая ошибка продакшена – выбрать уровень 1 без проверки, что GPU пользователя не в WebGPU-блоклисте Chrome. Около 8% десктопных пользователей Chrome имеют WebGPU как API, но он отключён в рантайме блоклистом (обычно более старые Intel HD Graphics на Windows). Детекция возможностей означает проверку, что запрос WebGPU-адаптера действительно успешен, а не просто что navigator.gpu определён.

Численный пример – бюджет кадра на веб-камере при 30 fps

Поток 30 кадров в секунду даёт вам 33,33 миллисекунды на кадр, чтобы выполнить всё: прочитать кадр, уменьшить разрешение, пропустить через модель, увеличить маску, размыть кадр, собрать результат и передать обратно в WebRTC. Всё, что выходит за рамки этого времени, либо приводит к потере кадров, либо увеличивает задержку – пользователь замечает и то, и другое.

Рабочий пример на MacBook Pro M2 с Chrome 138 и входом с веб-камеры 1280×720. Модель работает на WebGPU и показывает медианное время инференса 1,5 мс на минутной записи. Даунсемпл с 1280×720 до 256×256 – 0,3 мс (один вызов GPU). Гауссово размытие, два раздельных прохода с сигмой 8 – 1,8 мс суммарно. Composite-шейдер – 0,4 мс. Шаг кодирования через WebCodecs обратно в VideoFrame – около 0,6 мс. Итого: 4,6 мс на кадр. Composite браузера и WebRTC-кодировщик добавляют ещё около 5 мс, прежде чем кадр покинет устройство, и в бюджете остаётся 23 мс запаса.

На шестилетнем ноутбуке с процессором Intel Core i5 и без дискретной видеокарты тот же пайплайн работает на уровне WebGL 2: 7 мс на инференс, 1 мс на даунсемпл, 4 мс на блюр, 1 мс на композитинг и 1 мс на кодирование – итого 14 мс. Всё ещё укладывается в бюджет. На Safari 17 на той же конфигурации срабатывает уровень 4: 18 мс на модель в WASM с SIMD на CPU, 6 мс на блюр через 2D canvas и 2 мс на композитинг – суммарно 26 мс. Почти нет запаса, а край маски выглядит заметно мягче.

Вывод: WebGPU-пайплайн не просто быстрее – это единственный пайплайн, который оставляет достаточно запаса для того, чтобы компоновщик мог сделать чистую работу. Уровень 4 работает, но визуальное качество заметно ниже.

Три ошибки, которые мы видим в продакшене

Это три провальных сценария, с которыми мы сталкивались в продакшене, и которые теперь проверяем на каждом code review перед тем, как фича размытия фона попадает в релиз.

Первая ошибка – ореол на мягком крае. Маска размером 256×256, наивно билинейно увеличенная до 1280×720, создаёт полосу шириной 3–4 пикселя вокруг силуэта, где значение маски находится между 0 и 1. В этой области компоновщик смешивает резкие и размытые пиксели, что приводит к появлению светлого ореола на тёмном фоне или тёмного ореола на светлом. Решение – двухэтапная постобработка самой маски: сначала лёгкий гауссовский размытие с сигмой 2 (убирает ступенчатые артефакты), затем резкий sigmoid-remap, который «толкает» средние значения маски к 0 или 1 (mask = 1 / (1 + exp(-12 * (mask - 0.5)))). Оба этапа реализованы в шейдере WebGPU-компоновщика и не требуют дополнительных затрат по производительности. Результат – переходная полоса в один пиксель, воспринимаемая как естественная глубина резкости, а не как флюоресцентный контур.

Вторая ошибка – дрожание волос. Модель обучалась на разрешении 256×256, и граница «волосы–фон» на таком масштабе составляет всего один пиксель. От кадра к кадру модель выдаёт слегка отличающиеся маски даже при абсолютно неподвижном изображении – это воспринимается как «мерцание» волос, когда пользователь сидит спокойно. Решение – временное сглаживание: мы храним небольшой ring buffer масок последних трёх кадров и выдаём усреднённое значение. Трёх кадров достаточно, чтобы устранить высокочастотное мерцание; более пяти кадров уже вызывает заметную задержку при движении. Стоимость – одна дополнительная выборка текстуры на пиксель для каждого буферизованного кадра; на WebGPU это незаметно в общем бюджете производительности.

Третья ошибка – сцены с несколькими людьми. Переговорная с двумя людьми перед одной камерой показывает, что модель относит обоих к пикселям «человека» – отсутствует instance-сегментация, нет разделения «человек слева» и «человек справа». Для размытия фона это обычно нормально – пользователи хотят видеть оба лица чёткими. Но как только продукт требует one-person сегментации (например, beauty-фильтр, применяемый только к пользователю, или аватар, заменяющий только одно лицо), правильный путь – не исправлять MediaPipe, а перейти на SAM 2 (урок 2.4), используя лицо пользователя в качестве промпта. MediaPipe подходит для разделения комната против людей, а SAM 2 – для выделения этого конкретного человека против всех остальных. Использование неподходящего инструмента для задачи – самая частая архитектурная ошибка, с которой мы сталкиваемся в этой области.

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

Build Versus Buy – Когда MediaPipe – Неверный Выбор

Для большинства веб-видео-продуктов MediaPipe Image Segmenter на WebGPU – правильный примитив. Он бесплатен, имеет пермиссивную лицензию (Apache 2.0), работает полностью на устройстве пользователя (что означает нулевую облачную стоимость на пользователя и нулевой PHI / GDPR-data-exfiltration), и качество достаточно высокое, чтобы средний пользователь не отличил его от Zoom или Meet. Мы используем его по умолчанию в нашей стандартной референс-архитектуре веб-конференций.

Есть три ситуации, когда покупка коммерческого SDK (Krisp, NVIDIA Maxine, Banuba, Persona, расширение agora.io background-blur) имеет больше смысла, чем разработка на основе MediaPipe.

Первая – когда вам нужны real-time шумоподавление, voice activity detection и ИИ-эхокомпенсация в одном продукте, и вы хотите работать с одним вендором для поддержки всех этих функций. Krisp поставляет размытие фона как часть того же SDK, что и модель шумоподавления; экономия времени на интеграции окупается даже при сопоставимом с MediaPipe качестве реализации.

Вторая – когда вам нужен hardware-accelerated-эффект в нативном десктопном приложении, а не в браузере. NVIDIA Maxine работает на RTX GPU пользователя через CUDA и даёт выше качества на поддерживаемом железе – но требует RTX-класс GPU, что отрезает длинный хвост ноутбуков и Mac. Для Windows-only-enterprise-десктоп-продукта, ориентированного на свежее RTX-железо, Maxine – легитимный выбор. Для кросс-платформенного веб-продукта – нет.

Третья – когда нужен подписанный, проверенный, сертифицированный по AVA блюр фона в регулируемом продукте (здравоохранение, оборонка, финансы). Коммерческие вендоры предлагают отчёты SOC 2, соглашения HIPAA BAA, документы соответствия EU AI Act и гарантии ответственности за поведение модели. MediaPipe – код под лицензией Apache; ответственность за аудит лежит на вас. В телемедицинском продукте, где вы согласуете контракты с госпиталями, BAA от коммерческого вендора иногда обходится дороже, чем плата за пользователя.

Для всего остального – а это подавляющее большинство продуктов – MediaPipe на WebGPU в 2026 году – правильный выбор. Кросс-ссылка на урок 6.6 по build-vs buy Krisp / Maxine / Dolby – там более подробный разбор по каждому вендору.

Где Тут Фора Софт

Фора Софт предоставляет размытие фона как часть WebRTC-решений для видеоконференций с 2021 года и использует описанный в статье WebGPU-рендерер в качестве переиспользуемого компонента во всех проектах – от видеоконференций и телемедицины до e-learning и AR/VR. Мы внедрили этот же пайплайн в white-label-конференц-инструменты для европейских телемедицинских платформ (где обработка на устройстве соответствует требованиям GDPR по локальности данных), в онлайн-обучающие продукты для детей (где на заднем плане могут быть другие члены семьи, которых нужно размыть), а также в OTT-потоки постпродакшна, где редакторы просматривают необработанные интервью и хотят видеть чистое превью без необходимости аренды студии. Если вы разрабатываете что-то подобное, паттерн сборки остаётся одинаковым; различаются лишь особенности вертикальной специализации остальной части продукта.

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

• MediaPipe Image Segmenter на WebGPU – стандарт с 2026 года для размытия фона в браузере.
• Сама модель очень компактна (447 КБ, 106 тыс. параметров); ключевая инженерная работа – в WebGPU-компоновщике.
• WebGPU работает в 3–5 раз быстрее WebGL на том же оборудовании и доступен большинству пользователей.
• Проверка поддержки функций обязательна: Safari 17, заблокированные версии Chrome, устаревшие браузеры – всем нужен резервный вариант.
• Три распространённые ошибки – ореол, мерцание волос, многопользовательская сегментация – имеют известные исправления; либо применяйте их, либо ждите тикетов поддержки.
• Для большинства веб-продуктов MediaPipe выигрывает по цене, лицензии, задержке и приватности; коммерческие SDK – по удобству интеграции и аудиту.

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

• Multi-object tracking – DeepSORT, ByteTrack, OC-SORT – когда размытия недостаточно, и нужно отслеживать конкретных людей между кадрами.
• Как размыть фон в Zoom, Teams, на iPhone – инженерный deep-dive – продуктовый взгляд на тот же пайплайн за брендированными интерфейсами.
• SAM 2 для видео – memory module, propagation, rotoscoping/ROI – более мощный сегментатор, к которому вы переходите, когда качество границ MediaPipe становится недостаточным.