移动音视频SDK工程实践之数据采集和处理( 二 ) _音视频SDK

其实在有些场景像点播或短视频，720p的分辨率已经不能满足场景的使用，甚至在一些运动场景，30fps的刷新率也已经没办法满足场景的开发，当然这些其实更多的是业务挑战。除此之外，刚才也说过整个多媒体技术的发展，编码器一直起到了举足轻重的作用，所以底层技术也在追求更高效的编码效率。
对于这些问题，其实大家都能达成一个共识，就是说速度是音视频SDK框架要解决的一个问题。但抛开现象看本质，速度其实还是来自于数据的传输，它是一个根本前提条件，因此如何让数据更高效的传递和更高效的处理，才是移动端SDK要解决的最根本问题。
数据采集管线的设计和实现

文章插图

这里介绍一下目前一些开源产品当中数据链的设计和方案，以两个产品为例，一个是GPUImage 。相信做过移动端SDK特效的同学应该都是耳熟能详了，因为它确实是比较好用，可以提供大量的Shader 。抛开Shader的不说，我们看一下它在数据链条的设计方式。首先GPUImage提供了一个传输数据的类Output和一个实现接收数据的Input，然后通过生产模式，生产模块像相机采集模块，以及本地相册模块，其实都是实现了Output的类，生产模块生产完毕后会交由Output进行渲染，这里它的强大之处在于Output可以与可编程的Shader进行强关联，很大程度的驱动了OpenGL的运行效率。然后将渲染后RGB的数据转换成FrameBuffer这个实体的对象，整个链条都是通过FrameBuffer进行接收，然后通过链条上的组件去实现了Input后，就能拿到Output传出的FrameBuffer，以此类推将FrameBuffer进一步的传递到下个链条当中，整个链条其实是非常清晰和简单。
我们再来看一下右边的FFmpeg，除了提供很多的数据链条的处理机制、数据的分包，它还可以在不进行解码的情况下进行转包，也可以把数据进行解码，做一些后处理等等，整个链条其实也是比较清晰的。

文章插图

介绍了两种多媒体框架，接下来看一下我们团队是怎么去考虑这些问题。实际开发中，音视频SDK框架中管线其实是不可控的，我们来看一下这两种方案的一些优势和问题。
首先GPUImage的优势是显而易见的，就是协议相对简单清晰，另外通过可编程Shader驱动了OpenGL，这样它的运行效率变的非常快，通过大量的Shader可以让开发同学去进一步学习这门语言，是一个优秀的图像处理开源框架。但同样存在一些问题，首先我们看到它提供的这些Shader其实大多数都是图像处理，并且基本上都是同步处理的。所以可能导致在使用GPUImage跟一些框架进行结合的时候，当你的某个模块涉及到耗时处理，这个时候有可能会出现某个对象被其它释放掉或怎么样，会造成整个线程的不安全。
FFmpeg的优势特别多，简单说一下它的函数指针，其实也是FFmpeg的一个最佳实践，它通过指针的方式，把数据进行一层层的拆分跟传递。但是它也同样存在一些问题，比如说FFmpeg是面向过程的，它的链路设计对于不熟悉FFmpeg的同学来说，可能会觉得链路非常复杂，使用起来可能并不是那么的得心应手。
所以我们经过多轮讨论跟思考，就希望得到一个数据管线，它首先像GPUImage，协议比较简单，用起来比较容易上手，对开发者来说是友好的；另外需要它是可控的，因为随着SDK的模块越来越多，我们发现在很多场景下，会出现不可控的问题；除此之外我们还希望它是支持同步或者是异步的，调度是安全的，链路配置是简单可依赖的。

文章插图

我们也总结了自己的一些方法论跟实践：专注链式，这主要还是考虑到音视频框架，链式是它的一个核心思想，所以我们遵从这种法则自研数据管线。
首先是制定数据协议，主要解决的是最基本的模块间数据的高效、稳定的传递。这里可以看到左图，它的方案跟刚才介绍的GPUImage有些相似，但是也有些不同。我们也提供了类似的AVOutput的模块和AVInput的数据传输接收的协议。但是我们并没有跟GPUImage的OpenGL进行绑定，只是单纯的去记录和管理这条链条上的各个的组件，我们叫target 。然后通过Dispatcher的机制，分发从生产端上报的视频帧，通过视频帧不断的传递到各个链路的target当中，而每个target实现AVInput其中的协议方法。例如frame跟type两个函数，frame就是从raiseFrame Output传递下来的数据；type主要是做一些音视频的音频跟视频的区分。