17、视频处理：VP8/VP9/H264编码器选择、分辨率与帧率控制、视频前处理
视频编码这块，说实话，是WebRTC里最“黑盒”但又最绕不开的部分。你想想看，同样的网络环境，有人能流畅720p，有人连320p都卡成PPT，差别往往就在编码器选型和参数调优上。我个人习惯把编码器选择、分辨率帧率控制、前处理这三件事放在一起讲，因为它们在实际项目中是环环相扣的。
17.1 编码器三兄弟：VP8、VP9、H264
WebRTC默认支持VP8，这是Google亲儿子。但实际落地时，你会发现H264的兼容性更好，尤其是跟iOS和硬件编码器打交道的时候。VP9呢？压缩率确实高，但计算开销也大，移动端慎用。
| 编码器 | 压缩效率 | 计算开销 | 浏览器支持 | 我的推荐场景 |
|---|---|---|---|---|
| VP8 | 中等 | 低 | Chrome/Firefox原生 | 通用场景，兼容性首选 |
| VP9 | 高（比VP8省30%码率） | 高（解码也吃性能） | Chrome/Firefox较新版本 | 桌面端、带宽受限场景 |
| H264 | 中等 | 低（硬件编码器加持） | Chrome/Safari/Edge | iOS端、硬件编码需求 |
核心结论：别迷信“哪个编码器最好”。我在项目中遇到过，同一个编码器在不同设备上表现天差地别。比如H264的硬件编码器在iPhone上非常稳，但在某些Android低端机上反而会掉帧。所以我的建议是：先做兼容性检测，再根据设备能力动态切换。
17.2 分辨率与帧率控制：不是越高越好
很多人一上来就想要1080p 60fps，觉得这样才清晰。但你想想看，WebRTC是实时通信，不是录播。网络抖动一下，高分辨率高帧率反而会带来更严重的卡顿和延迟。
我一般遵循一个原则：分辨率保底，帧率保流畅。什么意思呢？
- 分辨率：根据屏幕尺寸和网络带宽动态调整。比如手机端，720p已经足够，再高肉眼也看不出区别，反而增加编码压力。
- 帧率：15fps是视频通话的底线，低于这个值会有明显顿挫感。30fps是黄金标准，60fps除非是屏幕共享或游戏直播，否则没必要。
我的调参习惯：在RTCPeerConnection的SDP协商阶段，我会设置一个“理想分辨率”和“最小分辨率”。比如理想是1280x720，最小是640x480。这样当网络变差时，WebRTC会自动降分辨率，而不是直接卡死。
代码层面怎么控制？其实很简单，通过MediaStreamTrack的applyConstraints方法就能动态调整：
// 获取视频轨道
const videoTrack = localStream.getVideoTracks()[0];
// 设置理想分辨率和帧率
const constraints = {
width: { ideal: 1280, min: 640 },
height: { ideal: 720, min: 480 },
frameRate: { ideal: 30, min: 15 }
};
videoTrack.applyConstraints(constraints)
.then(() => console.log('约束应用成功'))
.catch(err => console.error('约束失败:', err));
嗯，这里要注意：applyConstraints不是所有浏览器都完美支持，尤其是老版本Safari。所以我在项目中会先检测一下，如果不支持就回退到SDP协商时的参数。
17.3 视频前处理：降噪、美颜、尺寸裁剪
编码器只管压缩，它不关心画面干不干净。所以前处理这一步，说白了就是“把脏活累活干完，再交给编码器”。
我常用的前处理流程包括：
- 降噪：尤其是暗光环境下，摄像头噪点会严重浪费码率。一个简单的均值滤波就能让编码器省下20%的码率。
- 美颜/滤镜：这个看产品需求。但注意，美颜算法很吃CPU，建议只在高端设备上开启。
- 尺寸裁剪：有时候摄像头采集的是4:3，但我们需要16:9。直接拉伸会变形，所以我会先裁剪再缩放。
避坑指南：我曾经在项目中直接用了Canvas做前处理，结果发现CPU占用飙升，导致编码器拿不到足够的帧。后来改用WebGL做硬件加速，才把性能降下来。所以前处理一定要考虑性能开销，别捡了芝麻丢了西瓜。
前处理的代码实现，我一般用Canvas或OffscreenCanvas：
// 假设videoElement是摄像头输入
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
// 每帧处理
function processFrame() {
// 裁剪为16:9
const sourceWidth = videoElement.videoWidth;
const sourceHeight = videoElement.videoHeight;
const targetWidth = 1280;
const targetHeight = 720;
// 计算裁剪区域（居中裁剪）
const cropX = (sourceWidth - targetWidth * sourceHeight / targetHeight) / 2;
const cropY = 0;
const cropWidth = targetWidth * sourceHeight / targetHeight;
const cropHeight = sourceHeight;
ctx.drawImage(
videoElement,
cropX, cropY, cropWidth, cropHeight,
0, 0, targetWidth, targetHeight
);
// 这里可以加降噪或美颜处理
// 然后通过canvas.captureStream()输出到WebRTC
requestAnimationFrame(processFrame);
}
你看，前处理其实不复杂，但关键是要跟编码器配合好。比如降噪后的画面，VP9的压缩率能再提升10%左右，因为高频噪声少了。
17.4 知识体系总览
下面这张图是我自己总结的，把编码器选择、分辨率帧率控制、前处理三者的关系画出来了。你一看就明白：
从图里你能看到，前处理是承上启下的关键。摄像头采集的原始数据，经过降噪、裁剪等处理后，再根据当前网络状况选择合适的分辨率和帧率，最后交给编码器压缩传输。每一步都影响最终的用户体验。
总结一下我的经验：编码器选型看平台，分辨率帧率看网络，前处理看性能。三者不是孤立的，而是一个动态平衡的过程。我在实际项目中，会写一个“自适应视频引擎”，根据CPU使用率、网络带宽、设备型号自动调整这三个参数。效果比固定配置好得多。
好了，这一章的内容就到这里。视频处理这块水很深，但掌握了编码器特性、分辨率帧率控制逻辑、以及前处理技巧，你就能在大部分场景下做出靠谱的实时通信产品。