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

除此之外我们还支持一些二进制场景的分发，主要是为了配合像直播这种对数据有分发要求的场景做了一些协议的升级。在链条的最末端，可以看到我们也实现了AVControl，跟之前不太一样是我们制定了一个控制协议，这个控制协议主要是为了控制数据的流入和流出。为什么要做这个事情呢？我们知道音视频SDK最核心的就是数据在不断的传递，如果说某个模块出现异常，数据没有一种机制能保护它，可能会导致整个SDK的运行出现不稳定的情况。比如在直播场景分发的时候，我们发现网络有抖动，此时我们可以调整发送的速率、速度等。
这里简单的画了一下我们的数据流向，一个是推的方式，就是直接从相机这种模块采集数据，直接着向后面的某个模块去传递。一个是拉的方式，主要是指读取本地文件或者说是间接的获取数据，比如从网络读取数据首先需要将数据读下来，然后再传递到各个模块。这里其实相对于之前说了GPU在异步线程的一些处理，我们也做了一些兼容和保护，就是防止异步处理时对象被释放的情况发生。所以说我们基本上也是沿用了GPUImage协议简单的这种思想，然后在此基础上又增加了一些像控制协议的实现机制，让整个链路变得可控。

文章插图

除此之外，我们也发现在日常过程当中，只是简单的设计数据管线，其实并不能很好的对业务场景开发提供帮助，原因什么呢？
其实我们只是解决了各个模块数据之间的传递问题，但是并不能对最终产品的场景开发落地解决所有的问题，因为场景跟模块是有很大差异的。我们所了解的像点播、直播，甚至是特效等，它其实都是通用性的能力。但是实际场景就涉及到各个模块之间的组合，所以数据的传递并不能说传递一个数据，就能把一个场景串联起来。
【移动音视频SDK工程实践之数据采集和处理】这里也举了几个日常过程中典型的例子，比如对于点播的画质优化，会发现类型转换不是那么通畅和简单。对于连麦场景，如何让我们的SDK或者产品用起来更简单，像人脸特效，比如说涉及到能力的多样化，如何做到兼容性等，这些都不只是靠数据链路或模块搭载就能解决的。因此我们提到了一个中间件的概念，就是把数据进行桥接实现资源的共享，在各个模块或业务输出或使用的时候，就能提高整体数据采集或处理的应用性。所以说应用性也是我们数据采集管线的另一个考量指标。
特效模块数据中间件设计和实现接下来我们来看一下，在实际过程当中遇到的一些问题跟解决方案。

文章插图

特效模块通常是典型的PaaS结构，它上面存在多种模型，而且模型之间是可以进行插拔；它还有另外一个特点就是耗资源。那么如何在音视频SDK中将这个模块更好的运用起来，去对外提供能力呢？我们这里以人脸特效的高级美颜接口为例，高级美颜中涉及到的特征点非常多，像大眼、瘦脸、下巴等，而且这些特征点并不是通过一次迭代或是一个模型就能解决的，它可能会涉及到多次的迭代和多种模型的组合叠加。这样就会带来一个问题，在集成特效模块的时候，如果这些能力都是不断变化的，对于模块的使用来说，就存在一个不安全不稳定的因素。那么我们该如何把这个问题解决，或者说屏蔽掉呢？
这里我们提供了一个概念：首先在调用能力的时候，不直接去调用，而是把这些能力做进行抽象、封装，然后这些封装的模型，用来关联后面的一些不同的算法。因为别人在用SDK的时候，不一定按照你所有东西来集成，可能只使用其中部分能力，这样就有可能会导致一些特效的SDK存在版本不一致。如果没有这个代理层，当出现版本不一致的情况，对于上层来说可能就会出现大量接口的调整和修改，会比较耗时耗力。不过我们做代理的话，可能就给屏蔽上层接口的稳定性，然后通过我们的模型跟一些抽象对象，可以去驱动不同的AR模块的版本。
通过数据管线我们可以看到，从录制模块把数据传到effect接口，再把数据再给到AR SDK的时候，每个AR SDK都会有一个处理检测能力，会定时的检测主屏指标等，为什么要这么做？
我们知道现在的特效，场景、玩法是特别复杂的，处理效果没办法完全保证。所以为了保证每帧的处理和整体链路的稳定，我们需要不断做一些性能指标的监测，这些指标监测需要不断的反馈给上层的调用。比如当前数据传输的速度较快，或者传递帧太多处理不完，我们就可以通过数据管线进行回传，进行控制。甚至可以调整录制模块采集的帧率等，这样再把数据返回给录制模块，录制模块再将数据传递给其它模块，像预览进行渲染等。通过数据管线加代理的方案，我们就可以很好的整合不同AR版本、能力，对外保持接口的统一。