22、虚拟背景：人像分割、背景替换、GPU加速

虚拟背景这个功能，现在几乎成了视频会议的标配。你想想看，开视频会议时背后乱糟糟的，或者不想暴露自己在家穿着睡衣，一键换背景多方便。

但在移动端做虚拟背景，坑其实不少。我最早在项目中接入这个功能时，以为直接调个SDK就行，结果发现手机发热、卡顿、分割边缘锯齿严重……嗯，后来老老实实把整个流程捋了一遍，才真正搞定。

今天我们就来聊聊，在WebRTC移动端里，如何实现人像分割、背景替换，以及怎么用GPU加速让这一切跑得流畅。

一、整体流程：先搞清楚要做什么

虚拟背景的核心逻辑其实不复杂，就三步：

1. 拿到视频帧——从摄像头采集的每一帧画面
2. 人像分割——把画面中的人像区域和背景区域分开
3. 背景替换——把背景区域换成你想要的图片、视频或模糊效果

但每一步在移动端都有讲究。我画了一张流程图，帮你快速建立整体认知：

二、人像分割：选模型还是选SDK？

人像分割说白了就是语义分割的一个子集——只分两类：人和非人。移动端常用的方案有几种：

方案	优点	缺点	适用场景
MediaPipe SelfieSegmentation	轻量、跨平台、Google维护	精度一般，边缘细节不够	快速集成、对精度要求不高
TensorFlow Lite + 自定义模型	可定制、精度可控	需要训练、调参、优化	对分割质量有较高要求
MNN / NCNN 推理引擎	移动端优化好、速度快	模型转换麻烦、社区资源少	追求极致性能
第三方SDK（商汤、旷视等）	开箱即用、效果不错	收费、依赖厂商	商业项目、不想自己折腾

我个人习惯用MediaPipe做快速原型。它内置了自拍分割模型，输入一张RGB图，输出一张单通道的mask图，每个像素值0~255，表示属于人像的概率。

但要注意，MediaPipe的模型在头发丝、手指缝这些细节上表现一般。我在项目中遇到过一个问题：用户戴眼镜时，镜框边缘被错误地分割到了背景里，导致眼镜看起来像被抠掉了一块。后来我换了一个更精细的模型才解决。

三、背景替换：不只是贴图那么简单

拿到mask之后，背景替换其实就是一个像素级的混合操作。伪代码大概是这样的：

// 伪代码：背景替换核心逻辑
for each pixel (x, y):
    alpha = mask[x][y] / 255.0          // 人像透明度
    foreground = cameraFrame[x][y]       // 原图像素
    background = bgImage[x][y]           // 背景图/视频像素
    output[x][y] = alpha * foreground + (1 - alpha) * background

看起来简单对吧？但实际做的时候有几个坑：

• 分辨率对齐：背景图的分辨率必须跟视频帧一致，否则要缩放。缩放最好用GPU做，CPU做太慢。
• 颜色空间：摄像头采集的通常是NV12或YUV，而模型输入需要RGB。转换这一步也要注意效率。
• 背景类型：除了静态图片，还支持视频背景、模糊背景。模糊背景其实就是对原图的背景区域做高斯模糊，再跟人像合成。

我曾经踩过一个坑：用视频做背景时，背景视频的帧率跟摄像头帧率不一致，导致背景忽快忽慢。后来我加了一个帧率同步逻辑，让背景视频按摄像头的时间戳来播放，才解决。

四、GPU加速：让一切跑起来的关键

移动端的CPU资源很宝贵，尤其是视频通话场景下，编码、解码、网络传输已经占用了大量CPU。如果再让CPU做人像分割和图像合成，手机分分钟变暖手宝。

所以，GPU加速是必须的。具体来说，GPU在三个环节发挥作用：

1. 纹理转换：把摄像头帧从YUV转成RGB，直接通过OpenGL ES的shader完成，避免CPU拷贝。
2. 模型推理：现在主流的分割模型都支持GPU推理。比如MediaPipe就内置了GPU delegate，可以跑在OpenGL ES或Metal上。
3. 合成渲染：把原图、mask、背景图在GPU上做混合，直接输出到屏幕或编码器。

你看，差距非常明显。所以我的建议是：只要条件允许，一定要走GPU管线。

五、在WebRTC中集成虚拟背景

在WebRTC的移动端SDK里，虚拟背景通常是在视频采集之后、编码之前插入一个自定义处理环节。具体做法是：

• iOS端：实现 RTCVideoCapturerDelegate 或自定义 RTCVideoFrame 处理
• Android端：实现 VideoProcessor 或自定义 VideoSource
• 或者用第三方SDK提供的视频处理接口

以Android为例，核心代码结构大概是：

// Android端：自定义VideoProcessor
public class VirtualBackgroundProcessor implements VideoProcessor {
    
    private SegmentationModel model;
    private BackgroundRenderer renderer;
    
    @Override
    public void onFrame(VideoFrame frame, VideoProcessor.FrameCallback callback) {
        // 1. 获取纹理ID
        int textureId = frame.getTextureBuffer().getTextureId();
        
        // 2. 人像分割（GPU推理）
        ByteBuffer mask = model.segment(textureId, frame.getWidth(), frame.getHeight());
        
        // 3. 背景合成（GPU渲染）
        int outputTexture = renderer.composite(textureId, mask, bgTexture);
        
        // 4. 构造新的VideoFrame
        VideoFrame outputFrame = new VideoFrame(
            new TextureBufferImpl(outputTexture, ...),
            frame.getRotation(),
            frame.getTimestampNs()
        );
        
        callback.onFrame(outputFrame);
    }
}

六、避坑指南：我踩过的那些坑

做虚拟背景这一年多，我踩过的坑能写满一页纸。挑几个典型的说说：

• 模型加载慢：我曾经把模型文件放在assets里，第一次启动时加载花了3秒多。后来改成mmap加载，并且提前在后台线程初始化，启动时间降到200ms。
• 纹理泄露：每次合成都创建新的纹理，但忘记释放旧的，结果内存暴涨。后来我用了纹理池，复用纹理对象，内存稳如老狗。
• 旋转问题：摄像头采集的帧可能有旋转角度（比如前置摄像头是270度），但模型输入需要0度。如果不做旋转校正，分割结果会歪掉。
• 低端机兼容：有些老手机不支持OpenGL ES 3.0，只能用2.0。我的shader必须写两套，或者用兼容模式。

嗯，这些坑说起来都是泪。但踩过一次之后，后面再做类似功能就顺手多了。

七、总结

虚拟背景在移动端WebRTC中的实现，核心就是三件事：人像分割、背景合成、GPU加速。其中GPU加速是让一切变得可行的关键。

如果你现在要做一个虚拟背景功能，我的建议是：先用MediaPipe快速跑通流程，验证效果。如果对分割质量不满意，再换更精细的模型。性能优化方面，优先保证GPU管线畅通，避免CPU介入。

最后提醒一句：别忘了测试低端机。 我见过太多项目在旗舰机上跑得飞起，一到千元机就卡成PPT。虚拟背景这个功能，用户感知很强，做不好反而影响体验。

---

公众号:蓝海资料掘金营，微信deep3321