3、媒体流采集与编码：摄像头/麦克风驱动调试、H264/VP8编码器配置、码率控制策略
好，咱们进入第三章。这一章讲的是媒体流从物理世界进入数字系统的第一道关口——采集与编码。说白了，就是摄像头怎么把光信号变成帧，麦克风怎么把声波变成PCM流，然后这些裸数据又怎么被压缩成H264或VP8，最后塞进网络管道里。
我做过不少嵌入式WebRTC项目，踩得最多的坑其实不在网络层，反而就在这采集和编码的入口处。驱动没调好、编码器参数配错、码率控制策略选不对——这些问题一旦出现，后面所有的QoS算法都救不回来。所以这一章，咱们把这三个环节拆开揉碎了讲。
核心要点：采集是源头，编码是瓶颈。源头脏了，后面再怎么滤波也白搭；编码器配不好，带宽再大也卡顿。
3.1 摄像头/麦克风驱动调试
嵌入式平台上的摄像头和麦克风，跟PC上那套标准UVC、ALSA不太一样。很多SoC用的是MIPI CSI接口的摄像头，I2C控制，驱动得自己写或者移植。麦克风呢，常见的是I2S或PDM接口，驱动层要搞定时钟、DMA、采样率匹配。
我个人习惯，拿到一块新的摄像头模组，第一步不是调编码，而是先验证原始数据通路。怎么验证？用v4l2-ctl或者直接读/dev/video0，把裸帧dump出来看。
# 检查摄像头设备节点
ls -l /dev/video*
# 用v4l2-ctl查看支持的分辨率和格式
v4l2-ctl -d /dev/video0 --list-formats-ext
# 抓一帧原始数据（YUYV格式为例）
v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV
v4l2-ctl -d /dev/video0 --stream-mmap --stream-to=frame.raw --stream-count=1拿到frame.raw之后，用Python或者ImageMagick转成图片看一眼。如果图像偏色、有条纹、或者全是绿的——嗯，驱动时序或者MIPI lane配置大概率有问题。
经验之谈：我遇到过MIPI时钟频率配错导致图像右半部分全是噪点的情况。查了两天才发现是SoC的DPHY配置里，CLK和DATA lane的skew没对齐。后来用示波器量了MIPI差分信号才定位到。
麦克风这边，我建议先验证PCM数据能不能正常录下来。用arecord或者直接读ALSA设备节点：
# 列出音频设备
arecord -l
# 录制一段PCM数据（16bit, 16kHz, mono）
arecord -D hw:0,0 -f S16_LE -r 16000 -c 1 -d 5 test.wav
# 用audacity或者ffplay播放验证
ffplay -f s16le -ar 16000 -ac 1 test.wav如果录出来的声音有爆音、静音或者明显底噪，先检查时钟源。很多嵌入式平台的音频时钟是从PLL分出来的，分频系数不对会导致采样率漂移。我曾在某个项目里发现，板子跑久了音频会逐渐不同步，最后定位到是晶振温漂加上PLL锁相环抖动累积造成的。
注意：摄像头和麦克风的驱动调试，一定要在裸系统（不带WebRTC）下先验证通。否则你后面排查问题时，很难分清是驱动问题还是WebRTC内部处理的问题。
3.2 H264/VP8编码器配置
采集到原始帧之后，下一步就是编码。WebRTC内部集成了多种编码器，嵌入式平台上最常用的是H264（硬件编码器）和VP8（软件编码器）。
先说说H264。嵌入式SoC通常都有硬件H264编码器，比如海思的VENC、瑞芯微的MPP、全志的CEDRUS。硬件编码器效率高、功耗低，但配置起来比软件编码器麻烦——你得跟硬件寄存器打交道。
WebRTC里启用H264硬件编码器，通常需要实现一个VideoEncoder接口的子类。关键参数有这么几个：
| 参数 | 说明 | 典型值 | 注意事项 |
|---|---|---|---|
width/height |
编码分辨率 | 640x480 / 1280x720 | 必须对齐到16或32像素，否则硬件报错 |
framerate |
目标帧率 | 15 / 30 fps | 硬件编码器有最大帧率限制，查datasheet |
bitrate_kbps |
目标码率 | 500 / 1000 / 2000 | 码率太低画面会糊，太高网络扛不住 |
profile |
H264档次 | Baseline / Main / High | WebRTC通常用Baseline或Constrained Baseline |
gop_size |
关键帧间隔 | 30 / 60 / 120 | 丢包率高时适当减小，减少累积误差 |
VP8呢，是Google开源的软件编码器。它的优势在于跨平台一致性——不管什么芯片，跑出来的码流都一样。但代价是CPU占用高。我曾在ARM Cortex-A55上跑720p VP8编码，CPU直接飙到80%以上，发热严重。
VP8的配置相对简单，WebRTC内部已经封装好了VP8Encoder。你主要关注的是VP8Encoder::Config里的几个字段：
// VP8编码器配置示例
webrtc::VP8Encoder::Config config;
config.width = 640;
config.height = 480;
config.target_bitrate = 500000; // 500 kbps
config.max_bitrate = 800000; // 800 kbps
config.min_bitrate = 100000; // 100 kbps
config.rate_control = webrtc::VP8Encoder::Config::RateControl::kSVC;
config.complexity = webrtc::VP8Encoder::Config::Complexity::kComplexityNormal;关键决策：选H264还是VP8？我的建议是——如果SoC有稳定的H264硬件编码器，优先用H264。功耗和性能都更好。但如果你的产品需要跨平台兼容（比如Android和iOS互通），VP8更保险，因为所有平台都支持。
3.3 码率控制策略
码率控制，说白了就是编码器怎么在“画质”和“码率”之间做取舍。WebRTC里码率控制分三个层次：
- 全局码率控制：由
BitrateController根据网络带宽估算（BWE）动态调整目标码率。 - 编码器内部码率控制：编码器根据目标码率调整量化参数（QP）。
- 帧级码率控制：每一帧编码时，根据剩余预算调整宏块级别的QP。
咱们重点说编码器内部的码率控制模式。H264和VP8都支持三种模式：
| 模式 | 缩写 | 特点 | 适用场景 |
|---|---|---|---|
| 恒定码率 | CBR | 码率波动小，但画质不稳定 | 带宽受限、对码率抖动敏感的场景 |
| 可变码率 | VBR | 画质稳定，但码率波动大 | 带宽充裕、对画质要求高的场景 |
| 恒定质量 | CQ / CRF | 固定QP，画质恒定，码率不可控 | 本地录制、离线处理 |
WebRTC实时通信场景下，我强烈建议用CBR模式。为什么？因为WebRTC的带宽估算算法（GCC、BBR等）依赖于稳定的码率输出。如果你用VBR，码率忽高忽低，带宽估算会来回震荡，最终导致视频卡顿。
避坑指南：我曾经在一个项目中用了VBR模式，结果网络一波动，编码器瞬间吐出2倍于目标码率的数据，路由器直接丢包，画面花成一团。后来改成CBR，配合GCC的码率自适应，问题就解决了。
具体到H264硬件编码器，CBR模式的配置通常涉及以下几个寄存器或参数：
// 以瑞芯微MPP为例，配置CBR模式
MppEncCfg cfg;
mpp_enc_cfg_set_s32(cfg, "rc:mode", MPP_ENC_RC_MODE_CBR);
mpp_enc_cfg_set_s32(cfg, "rc:bps_target", 500000); // 目标码率 500kbps
mpp_enc_cfg_set_s32(cfg, "rc:bps_max", 550000); // 最大码率
mpp_enc_cfg_set_s32(cfg, "rc:bps_min", 450000); // 最小码率
mpp_enc_cfg_set_s32(cfg, "rc:quality", 60); // 质量等级 0-100VP8的CBR配置更简单，直接在VP8Encoder::Config里设置rate_control为kCBR即可。不过要注意，VP8的CBR模式在低码率下（比如200kbps以下）画质衰减很快，这时候可以考虑开启frame_drop——允许编码器在码率超标时主动丢帧，保证码率稳定。
注意：码率控制不是孤立配置的。它必须和WebRTC的带宽估算（BWE）联动。BWE告诉你当前网络能吞多少数据，码率控制负责让编码器输出不超过这个量。两者配合不好，就会出现“编码器输出1Mbps，但网络只能吃500kbps”的悲剧。
3.4 本章知识结构图
下面这张图把本章的核心逻辑串起来了。从物理世界的摄像头/麦克风，到驱动层、采集层、编码层，再到码率控制与网络出口，每一步都有对应的调试要点和配置参数。
这张图从左到右、从上到下展示了完整的媒体流路径。你可以把它当作调试时的检查清单——每到一个环节，先确认上一层的输出是否正常，再往下走。
3.5 本章小结
这一章我们聊了三件事：
- 驱动调试——摄像头用v4l2-ctl抓裸帧，麦克风用arecord录PCM，先验证原始数据通路。
- 编码器配置——H264硬件编码器关注分辨率对齐、码率、GOP；VP8软件编码器关注CPU占用和跨平台兼容性。
- 码率控制——实时通信场景优先选CBR模式，配合WebRTC的带宽估算联动工作。
嗯，这些内容看起来是基础，但我在实际项目中见过太多人跳过驱动验证直接调编码器，结果花了两周才发现是MIPI时钟配错了。所以我的建议是——慢就是快，先把采集通路调稳，再谈编码优化。