视频代码设计：source和sink

视频代码设计

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

source和sink

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

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

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

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

videoBroadcaster

broadcaster做的就是我们上面那段话想做的事情

source的接口太简单了，下面是videoSourceBase的函数定义，还增加了一个sinks的成员来保存所有的sink成员；

而broadcaster同时继承了sink和source，这就是我们想做的事情：初始化一个broadcaster实例，增加一个消费者sink的时候，把sink通过broadcaster的source接口存入sinks即可；当采集到图像的时候，把图像按照既定的逻辑调用所有sink的接口即可；

webrtc里面同时是sink又是source的实例还有很多，例如

这是第一个实际概念到代码设计的实践，可以看到，简单的物理概念想真正用代码设计构架起来，还是需要很多抽象设计和构架思考的

 source、track、stream

 上面说完了整体一个大概念的图像采集之后，采集分发的小流程，这些图像数据source要变成track最后要形成 stream，我们看下这里的设计，在这些之前，有些更细节的概念也要考虑到，例如音视频发生了变化需要通知观察者

所以首先定义了观察者接口和通知者接口，都是很纯粹的接口定义

而通知者的继承关系则很长，通知接口有三个继承者MediaSourceInterface，MediaStreamTrackInterface，MediaStreamInterface，基本source、track、stream都是通知者