WebRTC 系列之视频辅流

做者：网易云信资深客户端开发工程师 陶金亮

近几年，实时音视频领域愈来愈热，业界不少音视频引擎都是基于 WebRTC 进行实现的。本文主要介绍 WebRTC 在视频辅流上的需求背景以及相关技术实现。

WebRTC 中的 SDP 支持两种方案： PlanB 方案 和 Unified Plan 方案。早期咱们使用多PeerConnection的 Plan B 方案中只支持一条视频流发送，这条视频流，咱们称之为”主流”。目前咱们使用单 PeerConnection 的 Unified Plan 方案，新增一条视频辅流，何为视频”辅流”？视频辅流是指第二条视频流，通常用于屏幕共享。

需求背景

随着业务的发展，一路视频流知足不了更多实际业务场景的需求，例如在多人视频聊天、网易会议以及其余在线教育场景下，须要同时发送两路视频流：一路是摄像头流，另外一路是屏幕共享流。

可是，目前使用 SDK 分享屏幕时，采用的是从摄像头采集通道进行屏幕分享。在该方案下，分享者只有一路上行视频流，该场景中要么上行摄像头画面，要么上行屏幕画面，二者是互斥的。

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

在 WebRTC 场景中，还存在一种能够单独为屏幕分享开启一路上行视频流的方案，并称之为“辅流（Substream）”。辅流分享即共享者同时发布摄像头画面和屏幕画面两路画面。

另外，有了这个辅流的通道，当设备为新版本 iPhone（新版本 iPhone 具备同时开启先后摄像头的能力）时，也为支持先后2路摄像头发送视频数据奠基了基础。

技术背景

前期 SDK 的架构设计是一个多 PeerConnection 的模型，即：一个 PeerConnection 对应一路音视频流。随着新的 SDP（Session Description Protocol）格式（UnifyPlan）的推出和支持，一个 PeerConnection 能够对应多路音视频流，即单 PeerConnection 模型，即基于单 PC 的架构，容许建立多个 Transceiver，用于发送多条视频流。

技术实现

目前视频流主要分为三类：Camera 流、屏幕共享流、自定义输入视频流，分别有不一样属性：

1. 将 Camera 流做为主流，支持 Simulcast；
2. 将自定义视频输入（非屏幕共享）做为主流，不支持 Simulcast；
3. 将屏幕共享做为辅流，不支持 Simulcast，有单独的屏幕共享编码策略；

因为 iOS 屏幕共享的特殊性，其须要经过自定义视频输入的方式来获取视频数据，所以存在以下图所示的流程图：

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

若是是其余平台，例如 Mac、Win、Aos 等，则会相对简单，摄像头数据和屏幕共享的数据都来自于 SDK 内部，外部自定义视频输入的数据才来自于外部。

关键类图

上述提到的单 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. 辅流相关的统计数据的汇总；

下面介绍在整个过程当中，比较重要的几个技术点的实现。

带宽分配

在弱网状况下，须要视频辅流的时候，咱们会优先把码率分配给音频流，其次是辅流，最后再分配给主流，总体策略为保辅流。

带宽分配的主要流程以下：

1. WebRTC 的拥塞控制算法 GCC（下文简称 CC） 评估出来的总带宽分配会分给音频流、主流、辅流；
2. 主流内部再由 Simulcast 模块分配大小流的码率，不开 Simulcast 时就直接给大流；

具体过程如图所示：

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

码率分配

目前关于码率分配的流程以下图所示，归纳起来有一下几步：

1. CC 的码率经过 transport controller 传递到 Call 中；
2. 而后通过 BitrateAllocator 分配到各个注册的流中 （目前就是视频模块）；
3. 视频模块拿到分配的码率，分配给 fec 和重传，剩下来的分配给 video encoder bitrate；
4. 视频编码器模块拿到 video encoder bitrate，按照咱们的策略，分配给大流、小流使用；

拥塞控制

为了实现视频辅流的功能，咱们须要对拥塞控制进行相关的改动，主要经过如下四个方面的改动来实现：

SDP 信令改动

按照 RFC 2327，使用 "b=< modifier >:< bandwidth-value >" 的方式来指定建议带宽，有两种 modifier(修饰符)：

• AS：单一媒体带宽；
• CT：会话总带宽，表示全部媒体的总带宽；

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

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

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

CC 总码率更新策略

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

快速带宽评估

忽然增长一路媒体流时，须要可以很快上探到真实带宽值，使用 probe 快速探测算法实现这一目标：

• 若是探测成功，CC 估计值迅速收敛，在带宽充足场景中收敛为 CC 上限，带宽受限场景中为真实带宽；
• 若是探测失败(如高丢包率场景)，CC 估计值缓慢收敛，在带宽充足场景中最终收敛为 CC 上限， 带宽受限场景中为真实带宽；

Paced Sender 处理

• 辅流与主流的视频大小流的发送优先级一致，全部视频媒体数据，使用预算和 pacing multiplier 的方式作平滑发送处理；
• 增长一个视频码流类型，kVideoSubStream = 3，与主流的大小流视频数据区分开来；
• Probe 快速探测期间，当编码数据不足的状况下，发送 padding 数据弥补，以保证发送码率知足要求；

下图为实际进行码率分配测试的结果展现：

统计上报

带宽的统计上报分为两个部分，分别是从 MediaInfo 获取以及 Bweinfo 获取。

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

当前 SDK 的带宽估计从 MediaInfo 获取逻辑为：

• 遍历当前全部 transceiver，获取每一个 transceiver 的 video_channel 和 voice_channel，从而获取到 video_media_channel 和 voice_media_channel；
• 根据 media_channel 的 getstats 获取当前 channel 的 MediaInfo；
• 将获取的 MediaInfo 放在 vertor media_infos 中，便于上报；

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

二、带宽估计信息获取

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

• 获取 gcc、probe 探测等表示整体带宽信息；
• 获取每一个 transceiver 的 voiceChanel 和 videoChannel 相关的带宽估计信息（相似于 MediaInfo 的获取）；

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

总结

以上就是关于 WebRTC 中视频辅流的分享，主要从业务需求出发，经过技术背景以及关键技术类图，详细分享了关于视频辅流的技术实现。也欢迎留言与咱们交流关于 WebRTC 以及音视频相关技术。

系列阅读

• WebRTC系列之音频的那些事
• 从入门到进阶｜如何基于WebRTC搭建一个视频会议