webrtc源码阅读理解一

webrtc是一个比较成熟的实时音视频处理开源项目，一上来老大就扔给我一本webrtc native实践，虽然狠下心“翻”完了一遍，但是还是云里雾里的，在经过几个月的摸索之后，我大概知道原因了，归根到底，是基础不在一个层次，理解不了的，所以我决定，尝试写一个接近我这种零基础入门实时音视频的记录系列，希望能帮到一些同学

基础概念的理解

实时音视频是一个很长的流程，从采集-编码-传输-接收-解码-渲染，每一个步骤都是很大的模块，所以我们一个一个来，我们先从采集相关的设计开始，我们先看一些概念，否则直接看代码会有点懵

stream（流）：包含音频轨和视频轨的编码流

track（轨道）：音频轨或者视频轨

音视频同异点-我的理解

先说几个点

音频和视频还是很多地方不一样的
- 音频采集了，自己不不要同时听到自己，一般只需要传输给对方；一般只有一个采集的地方；即使有多个采集的地方，对方希望听到是合流之后的一个声音；
- 视频采集了，一般需要同时在己方和对方都渲染显示出来；可能要多个采集源；一般希望每个视频源独立展示（甚至是不同的设备展示）
音频和视频有很多地方是一致的
- 是同级的概念；整体的处理流程几乎一致
音频和视频输入和输出的过程不一样

整体感觉是视频的逻辑要比音频复杂一些，所以下面我主要也是围绕视频展开，音频也会顺便说下

视频代码设计

其实这个地方很难真正从零开始，我这里也是从中间某个点开始说（对着代码说自己的理解）；结合上面的同异点，我们来看下webrtc里面的代码设计

source和sink

这是我觉得第一个坑的设计，但你理解了之后，觉得这样设计也没有问题

联系实际场景，摄像头采集到图像之后，保存视频，成为视频源，编码和本地渲染需要消费图像做处理，类似于生产和消费的概念

对于消费者，也就是sink来说，如果我想要增加一个消费者，我继承sink接口，塞到保存视频源的实例里面去，让实例不断给我塞数据给我消费即可（onFrame），所以sink的接口定义比较好理解；

source的接口定义里面只有对sink的操作，这是我觉得一开始不好理解的地方，source并没有存储视频图像（为什么叫source呢？）；我现在的理解是，相对于sink，这样的接口就可以理解为source（摄像头采集图像之后，调用source的某个接口，这这个接口里面，对图像数据进行分发给sink，对于sink来说，这个实例就可以理解为source）；