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 决定接收端如何对抗抖动。渲染和播