WebRTC网络传输全景：一帧音视频从采集到播放到底经历了什么

前面我们已经学习过 WebRTC 的线程基础、音频引擎、视频 RTP 打包拆包、VP8/VP9 编解码以及音视频同步。到了这一篇，我们需要把这些知识串起来，从更高的视角看清楚：一帧音视频数据在 WebRTC 内部到底是怎么走完“采集、编码、发送、网络传输、接收、解码、播放”这条链路的。

这篇文章不是为了死记某一个类，而是建立一张完整地图。后面讲 SDP、ICE、DTLS、SRTP、拥塞控制、JitterBuffer、NetEQ、Pacer、NACK、RTX、Stats API 时，都可以回到这张地图中定位它们各自负责哪一段。

1. 为什么要先理解全链路

很多初学者调 WebRTC 时会遇到这些问题：

• 明明摄像头有画面，远端却没有视频。
• ICE 已经 connected，但音视频仍然不通。
• 本地发送帧率很高，远端播放却很卡。
• 网络丢包后，为什么有时能恢复，有时直接花屏。
• 延迟到底产生在采集、编码、网络，还是渲染。

如果只盯着一个模块，很容易迷路。WebRTC 是一个实时音视频系统，它的每个模块都不是孤立存在的：

• 采集模块决定原始数据从哪里来。
• 编码模块决定数据压缩方式和码率。
• RTP/RTCP 决定媒体包如何在网络上传输和反馈。
• ICE/DTLS/SRTP 决定连接如何建立以及数据如何加密。
• 拥塞控制决定当前网络还能发多少数据。
• JitterBuffer/NetEQ 决定接收端如何对抗抖动。
• 渲染和播