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

连麦模块数据中间件设计和实现

文章插图

连麦模块也是目前音视频产品中用的比较多的一个能力，如在线教育、直播带货、PK、娱乐等等，并且已经慢慢成为一个标准化能力，但连麦模块在使用过程当中还存在比较多的问题。
标准直播是单向通信，且信令相对简单。融合连麦模块后，则会变成双向通信，信令会变得复杂，媒体流从单路流变成了多路流。如左下图，一个标准的直播SDK加连麦SDK的整合结构，可以看到白色区域是标准的直播流程，从创建直播间到建链、编码、封包，包括通过队列进行分发等等。当融合了连麦能力之后，对整个模块来说会增加更多的链路。首先会引入RTC的服务端，媒体服务端与信令服务端。另外可能还会引入一些类似于业务系统的消息机制，IM服务器等等。
用户如果发起连麦，可以看到左图红色的箭头。首先它会向RTC信令服务器发送连麦请求，同时也会向IM服务器发送一个请求，向IM服务器发送请求的原因，主要是为了做一些业务上的处理，比如说UI界面或者场景的一些流程处理。实际上信令服务器主要是为了传递加入房间的请求，请求到达主播直播间后，主播直播间会响应信令服务器，选择同意或者拒绝。如果同意，则会通过信令服务器将信号返回给小主播/观众，小主播/观众这个时候就会把数据传递到RTMP的媒体服务器，主播也会把媒体流传到RTMP服务器，两路流汇聚到RTMP服务器后，通过旁路转播等方式来进行对外的转播，此时观众就会看到两个主播或主播和观众合流的画面。
这个实现流程其实比较复杂繁琐，对于用户（主播）来说可能理解起来非常吃力。首先他要关心的东西特别多，例如 IM服务器、旁路直播，旁路直播还会涉及一些模板的设置等等，他可能都要去关心，所以使用起来非常的麻烦。而对于消费侧的观众来说，也同样存在一些问题，比如说会出现相同地址，但是会出现不同编码的两路流，这种情况下可能对于一些播放器来说会有一些挑战，可能会出现一些卡顿，因为它在不断的重置一些编码参数，另外这种方案通过旁路转推的方式，可能原始的直播流会断掉，就在频繁切换直播流跟混合流的过程当中可能就会出现延迟，可能对于拉流侧来说它就有很多的问题，也不太好。
针对这些问题其实我们也看到，就是用户在使用过程当中其实有很多的不方便，所以说可以看到说简单的数据传递，其实并不能让这个场景做的特别的简单和应用，后面我们就做了一些大量的端到端的一些数据链的整合，首先是我们考虑到了就是消费侧的编码播放器的一些问题，首先是切换编码参数，这个方案可能并不是一个适用的方案，所以我们采用了本地混流的技术方案，其好处在于我的推流各方面的参数可以保持一致而不发生变化，而其实对于移动端的处理能力来说，本地的2~3路流的合流，其实对一些硬件来说，压力并不是特别大。另外我们把IM服务器跟RTC信令服务器进行了整合，因为我们觉得让用户去关心这么多的信令其实是没有必要的，而且用户也可能会被这些问题所困扰，所以我们内部就通过服务端的方式进行了消息的整合，这样子就让用户使用起来变得更加简单。通过这种端到端的一些媒体和信令的整合，其实也是让数据流变得简单，提高了整体接入的应用性。
渲染模块数据中间件设计和实现

文章插图

为什么说渲染是音视频SDK关键技术之一？从整体技术链路的角度来说，渲染模块实际上是用户最能感知到的一个模块。在一些复杂的场景下，渲染模块也承载了一些数据的交互和处理。因此渲染模块所包括的处理已经不再只是渲染，可能会涉及到某些场景的特殊需求，例如清屏等等：多人会议的时候，相当于一个关闭画面的效果；如多路混流，前面提到的RTC混流方案等等，渲染模块也可以作为其中的一个技术方案。也包括像小程序，尤其是一些小程序、安卓的同层设计方案，渲染方案等等。
每个模块甚至每个处理的节点，都有可能存在渲染的需求，所以说我们要将渲染模块进一步拆分。首先通过数据管线的一个能力，把各个模块的数据汇聚到渲染模块，然后再进行数据的处理。这里通常会将一些数据转换成各个平台的处理能力，比如CPU的Buffer，还有一些Surface等等。
数据加工，相对之前的生产流程这是新增的一个节点，它主要是为了应对一些复杂场景，如安卓的同层渲染、Surface的创建与绘制相分离，比如业务模块持有了Surface，但是渲染模块会间接引用并绘制。这里可能还会去做多路流混流的一些参数化配置，可以把每路流作为一个间值进行保存，也会做像图层跟视频帧的绑定，然后通过渲染线程同时绘制多路流。