webrtc-自定义视频流-分析篇

以后可能不怎么会接触Webrtc的技术了，记录一下我这一段时间在webrtc使用的一些东西和一些理解。这一篇会先说一下我在webrtc中自定义视频流方法的思考。我所开发的webrtc是基于centos7进行开发的，所以如果我没有特意标注的情况下都指的是linux下的webrtc，看官请知悉。

分析

我们知道webrtc是一套实时音视频会议系统，所以音视频源默认是通过麦克风和摄像头获取的。而我们的功能需要传输一段游戏视频。如果需要自定义传输内容有哪些方法呢，大胆假设一下。

1.欺骗webrtc，将你的视频数据伪装成摄像头的数据输入webrtc。下称摄像头伪装法。
2.webrtc中有一个自定义编码器的功能，通过重载编码器接口，实现一个伪装的编码器。下称编码器伪装法。
3.架空webrtc的捕获器和编码器，直接将编码完的视频数据导入打包段代码。下称码流伪装法。
4.只使用webrtc的libjingle(建连传输模块)而不使用它的编码模块。下称裸奔法。

我大概想到这些方法，让我们来分析一下：

1.摄像头伪装法

摄像头伪装法在Windows端的测试过程中真的使用过，由于Windows的webrtc会强制获取摄像头。如果你在同一台电脑上开启两个peerconnecton_client(webrtc的样例程序，linux端也叫这个名字)的话，会导致程序异常崩溃。所以一开始测试程序的时候用了一个模拟摄像头的程序来测试。这个方法的优点是明显且有分量的： 保留了webrtc的原始完整流程。
为什么说这个是一个有分量的优点呢？我们知道webrtc是一套庞大且功能丰富的架构，里面包括了码流传输、音视频编码等功能。这些功能里面又有很多的细节，比如码流传输里面的带宽检测机制，音频编码里面的回声抑制技术等等。可以说webrtc本身的功能已经非常完整，在不破坏webrtc任何流程的情况下，我们就能完整的使用到这些全面的功能，对于前期的原型开发进度是很有帮助的。
这个功能说实话我并没有想到有什么缺点。硬要说的话因为这个流程需要的数据是原始的画面数据，假如你已有的数据如果不是图片数据流而是一个已经编码好的视频数据流的话就不适合用这个方法了。同时，由于我对于linux上的摄像头模拟不太清楚，所以也不知道这个思路在linux上的实用性。

2.编码器伪装法

在网上你可以看到很多自定义编码器的文章，比如[链接]。我第一次看到这个方法并不是这个文章，不过相同的是文章里面对于自定义编码器的目的是用于ffmpeg编码器的替换。借助一个自定义的编码器，其实很多的功能我们都能做到。通过实现一个伪装编码器来传递码流的方法你们也能想象出来，优点也比较明显：
1.这个方法对于整体的webrtc流程破坏性也比较小，上层结构基本完全相同，webrtc本身对于编码器的一些控制参数也能够收到。
2.相较于伪装摄像头的方法，编码器可以自由选择这件事也是一个很好的条件。webrtc编码默认选用的openH264的编码效率公认是比较低的，用这个方法之后你甚至可以调用硬件编码。

缺点的话是这个方法需要的工作量算是比较大的，尤其是对于我这种英语苦手，在2016年webrtc的文档还比较匮乏的时候完成这个工程对于一个新接触c++的人来说时间是不允许的。所以这个方法一直被列在后续的优化方法上，但是直到项目结束也没有时间做。

3.码流伪装法

这个就是我所使用的方法了，通过直接在视频数据打包处将编码好的视频流塞进去，跳过了webrtc内部的采集和编码过程。为什么用的是这个方法呢，因为我们的系统的架构的视频数据采集和编码是在另外一台服务上的。结构大概如下：

这么做端原因是我们的视频输出和编码操作都是比较消耗性能的，而webrtc客户端程序本身比较占用的带宽。将两者分布到不同的服务器后可以最大化的减少成本。
为了在方便码流在服务器之间的传输，需要减少数据的传输量，所以视频会在编码完成后才传出。当然在这种结构下伪装编码器的做法也是可行的，只是用码流伪装的方法工作量比较小，所以选择了该方法，该方法的实现我会在后续给出。

4.裸奔法

该方法直接用webrtc的传输模块，完成目的干净粗暴，但是同时也抛弃了webrtc的很多功能。而且能不能和完整的webrtc客户端进行对接也有待考证，如果有知道的朋友请告诉我。这个方法应该是比较推荐大神使用，像我这种菜鸡就完全驾驭不住了。

后记

本来想将我的实现方法也在本篇里面写出，但是写完前面的发现废话和文字太多了，可能切分一下会好一点，所以这篇讨论就到此为止，具体实现请看下篇。
我是llsxily，一个语文不好的码农，感谢你看到这里，你可以叫我橘子。