媒体流基础：音频与视频的基本概念

做 WebRTC 开发，说白了就是在跟两样东西打交道：音频和视频。你想想看，不管是视频会议、远程教育还是直播连麦，最终用户感知到的就是声音清不清晰、画面流不流畅。这一章咱们就把最基础的概念理清楚。

我个人习惯把媒体流比作「水管系统」。音频是细水管，数据量小但要求实时；视频是粗水管，数据量大但可以稍微容忍延迟。这两根水管怎么接、怎么走，就是我们要聊的核心。

音频基础：采样率与量化

音频的本质是声波。麦克风把声波变成电信号，ADC（模数转换器）再把电信号变成数字。这里有两个关键参数：采样率和量化位数。

• 采样率：每秒采集多少个样本点。单位是 Hz。人耳能听到的频率范围是 20Hz-20kHz，根据奈奎斯特定理，采样率至少要达到信号最高频率的两倍。所以 CD 音质的 44.1kHz 就是这么来的。
• 量化位数：每个样本用多少 bit 表示。16bit 能表示 65536 个等级，动态范围约 96dB。WebRTC 里常用 16bit 线性 PCM。

采样率	常见场景	WebRTC 支持
8kHz	电话语音	支持（窄带）
16kHz	VoIP 宽带	支持
48kHz	WebRTC 默认	强制支持

视频基础：分辨率与帧率

视频说白了就是快速播放的图片序列。每一张图片叫一帧（frame）。这里有两个核心概念：分辨率和帧率。

• 分辨率：一帧图像有多少像素。比如 640x480 就是 30 万像素，1920x1080 就是 200 万像素。分辨率越高，细节越丰富，但数据量也越大。
• 帧率：每秒播放多少帧。单位是 fps。24fps 是电影标准，30fps 是电视标准，60fps 是流畅游戏标准。WebRTC 里常用 30fps。

你可能会问：「分辨率越高越好吗？」不一定。我做过一个项目，客户非要 4K 视频通话，结果带宽不够，画面卡成幻灯片。后来我们降到 720p，帧率稳定在 30fps，用户体验反而好了。说白了，稳定比高分辨率更重要。

编码格式简介

原始音频和视频数据量太大了。举个例子：1080p 30fps 的原始视频，每秒数据量约 1.5Gbps。这谁受得了？所以必须压缩。编码器就是干这个的。

音频编码：Opus

Opus 是 WebRTC 的「亲儿子」音频编码器。它由 IETF 标准化（RFC 6716），专门为实时通信设计。我个人非常喜欢 Opus，因为它太灵活了。

• 码率范围：6kbps 到 510kbps。窄带语音用 8kbps 就够了，全频带音乐可以用 128kbps。
• 采样率：支持 8kHz、12kHz、16kHz、24kHz、48kHz。
• 帧长：2.5ms、5ms、10ms、20ms、40ms、60ms。帧长越短，延迟越低，但压缩效率也越低。
• 算法：内部融合了 SILK（语音）和 CELT（音频）两种算法，能自动切换。

视频编码：VP8、VP9 与 H.264

视频编码这块就有点「三国演义」的意思了。WebRTC 标准要求浏览器必须支持 VP8 和 H.264，VP9 是可选。但实际使用中，这三者各有千秋。

编码器	压缩率	硬件支持	专利	WebRTC 地位
VP8	中等	软件为主	免费	强制要求
VP9	高（比 VP8 省 30-50% 码率）	部分硬件	免费	可选
H.264	中等	几乎所有硬件	需授权	强制要求

VP8：Google 开源，专利免费。压缩率一般，但解码速度快。我在做低端 Android 设备适配时，VP8 是首选——因为 VP8 的解码器在 ARM 上优化得最好。

VP9：VP8 的升级版，压缩率比 H.264 还高 30% 左右。但编码复杂度也高，实时编码时 CPU 消耗大。我建议只在带宽受限的场景下用 VP9，比如 4G 信号不好的地方。

H.264：业界老大哥，硬件支持最广。几乎所有手机、摄像头、编码器都支持 H.264 硬件编码。但要注意专利授权问题——虽然 WebRTC 里用 H.264 有 Cisco 的免费授权池，但商业产品还是要谨慎。

知识体系总览

下面这张图把本章的核心知识点串起来了。你可以看到音频和视频从采集到编码的完整路径。

这张图从左到右展示了音频和视频各自的处理链路。左边是音频：采集→采样量化→Opus 编码；右边是视频：采集→分辨率帧率设定→编码器选择（VP8/VP9/H.264）。最终两路数据汇聚到 RTP 封装层，准备送入网络。

你可能会注意到，音频和视频在 WebRTC 中是独立传输的。它们走不同的 RTP 流，有不同的 SSRC（同步源标识符）。接收端再根据时间戳把它们同步播放。这个机制叫「音视频同步」，后面章节会详细讲。