实时通信（三）：音视频链路，采集、编码、RTP/RTCP、Jitter Buffer 与 A/V Sync

一帧视频进入 RTC 系统后，会经历采集、预处理、编码、RTP 分包、网络发送、接收重排、抖动缓冲、解码、渲染。音频也类似，只是音频通常更敏感：人能容忍视频降清晰度，却很难忍受声音断断续续。

graph LR
    A["Capture 采集"] --> B["Preprocess 前处理"]
    B --> C["Encode 编码"]
    C --> D["RTP packetize 分包"]
    D --> E["Network 网络"]
    E --> F["Jitter Buffer 重排缓冲"]
    F --> G["Decode 解码"]
    G --> H["Render 播放"]

音频常用 Opus，因为它能覆盖语音和音乐，支持低延迟、可变码率、包丢失隐藏。视频常见 H.264、VP8、VP9、AV1，不同 codec 在压缩效率、硬件支持、编码复杂度和专利生态上各有取舍。

RTP（Real-time Transport Protocol，实时传输协议）负责承载媒体流。它的核心字段包括 sequence number、timestamp、SSRC、payload type。sequence number 是包序号，用于检测丢包和乱序；timestamp 是媒体时间戳，用于恢复播放时间线；SSRC 是同步源标识，用来区分不同媒体流；payload type 映射到具体 codec。

RTCP（RTP Control Protocol，RTP 控制协议）负责反馈统计和控制：接收端报告丢包、jitter、RTT；发送端根据反馈调整码率；当关键帧丢失时，接收端可以通过 PLI（Picture Loss Indication，画面丢失指示）或 FIR（Full Intra Request，完整帧请求）请求新关键帧，也可以通过 NACK 请求重传部分 RTP 包。

音频和视频是不同 RTP 流，采样率和时间戳单位也不同。接收端需要借助 RTCP Sender Report 把 RTP timestamp 映射到 NTP 时间，进而把音频和视频对齐到同一条墙钟时间线。否则就会出现声音先到、嘴型后到，或者画面先动、声音滞后的体验问题。