WebRTC 系列之视频辅流

WebRTC在PlanB方案下，只支持一条视频流发送，这条视频流，我们称之为”主流”。何为视频”辅流”？视频辅流是指第二条视频流，一般用于屏幕共享。

项目背景介绍

目前的SDK分享屏幕过程中，需要用摄像头采集的通道分享屏幕，该方案下，分享者只有一路上行视频流，该场景中要么上行摄像头画面，要么上行屏幕画面，两者是互斥的。

除非实例一个新的SDK专门采集并发送屏幕画面，但实例两个SDK的方案在业务层处理起来十分麻烦且会存在许多问题，例如如何处理两个流间的关系等。

在RTC场景中，还存在一种可以单独为屏幕分享开启一路上行视频流的方案，并称之为“辅流（subStream）”，辅流分享即共享者同时发布摄像头画面和屏幕画面两路画面。有了这个辅流的通道，同时也可以为新版本的iPhone支持前后2路摄像头发送视频数据奠定基础。

技术背景介绍

前期SDK的架构设计是一个多PeerConnection的模型，即：一个PeerConnection对应一路音视频流。随着新的SDP格式（UnifyPlan）的推出和支持，一个PeerConnection可以对应多路音视频流，即单PeerConnection模型。

基于单PC的架构，允许创建多个Transceiver，用于发送多条视频流。

概要介绍

目前视频流主要分为3类：Camera流、屏幕共享流、自定义输入视频流。

1.将Camera流作为主流，支持Simulcast

2.将自定义视频输入（非屏幕共享）作为主流，不支持Simulcast

3.将屏幕共享作为辅流，不支持Simulcast，有单独的屏幕共享编码策略

由于iOS屏幕共享的特殊性，其通过自定义视频输入的方式获取视频数据，因此存在如下图所示的流程图：

综上所述：iOS的自定义输入既可以使用主流的通道发送视频（非屏幕共享），也可以使用辅流的通道发送视频（屏幕共享）。

关键类图

上述提到的单PC架构，目前会有2个RtpTransceiver，一个是AudioTransceiver，一个是VideoTransceiver，而辅流的屏幕共享会在新增一个RtpTransceiver。一个VideoRtpSender会包含一个VideoMediaChannel。

1.信令层面需要支持多路视频流，使用mediaType用于区分上述的Camera流(Video)、屏幕共享流(ScreenShare)、自定义视频输入流(externalVideo)。

2.重构跨平台层的Capture和Source的管理。

3.重构用户和渲染画布的管理，从一个uid对应一个render，过渡到一个uid的sourceId对应一个render，每个uid可能会包含2个sourceId。

4.互动直播的服务器推流和录制需要支持主流和辅流的合流录制。

5.主流和辅流的拥塞控制方案的落地。

6.主流和辅流的码率分配方案的落地。

7.主流和辅流的编码器性能优化。

8.PacedSender发送策略、音画同步等方案的调整。

9.服务器Qos下行码率的分配方案的调整。

10. 辅流相关的统计数据的汇总。

11. 产品的计费问题。

码率分配

带宽分配的主要流程：

1.CC评估出来的总带宽分配会分给音频流、主流、辅流

2.主流内部再由Simulcast模块分配大小流的码率，不开Simulcast时就直接给大流

辅流会在上图的基础上再新增一个VideoSendStream。

目前关于码率分配的流程如下图所示,概括起来有一下几步：

1.cc的码率通过 transport controller 传递到 call 中

2.然后经过 BitrateAllocator 分配到各个注册的流中 （目前就是视频模块）

3.视频模块拿到分配的码率，分配给 fec 和重传，剩下来的分配给 video encoder bitrate

4.视频编码器模块拿到 video encoder bitrate，按照我们的策略，分配给大流、小流使用

拥塞控制

1、按照rfc2327(https://tools.ietf.org/html/rfc2327)，使用"b=<modifier>:<bandwidth-value>"的方式来指定建议带宽，有两种modifier(修饰符)：

AS：单一媒体带宽

CT：会话总带宽，表示所有媒体的总带宽

目前SDK使用b=AS:的方式指定摄像头码流或屏幕共享码流的建议带宽，并把这个值作为CC模块的估计值上限。

2、新的需求要求在同一会话中，可同时发送摄像头码流和屏幕共享码流，因此应把两路媒体的建议带宽值相加得到整个会话的建议带宽值，作为CC模块的估计值上限

3、WebRTC支持b=AS:方式(单路媒体)，在WebRTC内部对多路媒体进行相加处理即可满足需求，而WebRTC目前不支持b=CT:方式。所以建议使用b=AS:方式，改动相对较少。

处理流程

pub码流能力更新，通过sdp方式(b=AS:)的同步设置"最大带宽"到CC模块，当新增一路媒体流时，通过启动probe快速探测的方式，迅速上探到可用带宽：

快速带宽评估

突然增加一路媒体流时，需要能够很快上探到真实带宽值，使用probe快速探测算法实现这一目标：

1.如果探测成功，CC估计值迅速收敛，在带宽充足场景中收敛为CC上限，带宽受限场景中为真实带宽；

2.如果探测失败(如高丢包率场景)，CC估计值缓慢收敛，在带宽充足场景中最终收敛为CC上限， 带宽受限场景中为真实带宽。

Paced Sender处理

1.辅流与主流的视频大小流的发送优先级一致，所有视频媒体数据，使用预算和pacing multiplier的方式做平滑发送处理。

2.增加一个视频码流类型，kVideoSubStream = 3，与主流的大小流视频数据区分开来。

3.probe快速探测期间，当编码数据不足的情况下，发送padding数据弥补，以保证发送码率满足要求。

统计上报

1、发送端和接收端MediaInfo获取

当前SDK的MediaInfo获取逻辑为：a）遍历当前所有transceiver，获取每个transceiver的video_channel和voice_channel，从而获取到video_media_channel和voice_media_channel；b)根据media_channel 的getstats获取当前channel的MediaInfo；c)将获取的MediaInfo放在vertor media_infos中，便于上报；

主流和辅流同时发送场景，只是增加了一个transceiver，因此此逻辑适用于主流和辅流同时发送的场景，如下图：

2、带宽估计信息获取

当前SDK的带宽估计bweinfo获取逻辑：

1、获取gcc、probe探测等表示总体带宽信息；

2、获取每个transceiver的voiceChanel和videoChannel相关的带宽估计信息(类似于mediaInfo的获取)。

主流和辅流同时发送的场景只是增加了transceiver，因此此逻辑适用主流加辅流同时发送场景，如下图：