关于webrtc: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 流、屏幕共享流、自定义输出视频流，别离有不同属性：

将 Camera 流作为支流，反对 Simulcast；
将自定义视频输出（非屏幕共享）作为支流，不反对 Simulcast；
将屏幕共享作为辅流，不反对 Simulcast，有独自的屏幕共享编码策略；

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

综上所述：iOS 的自定义输出既能够应用支流的通道发送视频（非屏幕共享），也能够应用辅流的通道发送视频（屏幕共享）。

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

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

实现辅流须要对不同层面都做一些调整以及重构，具体如下：

信令层面须要反对多路视频流，应用 mediaType 用于辨别上述的 Camera 流 (Video)、屏幕共享流 (ScreenShare)、自定义视频输出流 (externalVideo)；
重构跨平台层的 Capture 和 Source 的治理；
重构用户和渲染画布的治理，从一个 UID 对应一个 render，过渡到一个 UID 的 sourceId 对应一个 render，每个 UID 可能会蕴含 2 个 sourceId；
互动直播的服务器推流和录制须要反对支流和辅流的合流录制；
支流和辅流的拥塞管制计划的落地；
支流和辅流的码率调配计划的落地；
支流和辅流的编码器性能优化；
PacedSender 发送策略、音画同步等计划的调整；
服务器 Qos 上行码率的调配计划的调整；
辅流相干的统计数据的汇总；

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

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

带宽调配的次要流程如下：

WebRTC 的拥塞控制算法 GCC（下文简称 CC）评估进去的总带宽调配会分给音频流、支流、辅流；
支流外部再由 Simulcast 模块调配大小流的码率，不开 Simulcast 时就间接给大流；

具体过程如图所示：

辅流会在上图的根底上再新增一个 VideoSendStream。

目前对于码率调配的流程如下图所示，概括起来有一下几步：

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

为了实现视频辅流的性能，咱们须要对拥塞管制进行相干的改变，次要通过以下四个方面的改变来实现：

依照 RFC 2327，应用 “b=< modifier >:< bandwidth-value >” 的形式来指定倡议带宽，有两种 modifier(修饰符)：

AS：繁多媒体带宽；
CT：会话总带宽，示意所有媒体的总带宽；

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

新的需要要求在同一会话中，可同时发送摄像头码流和屏幕共享码流，因而应把两路媒体的倡议带宽值相加失去整个会话的倡议带宽值，作为 CC 模块的估计值下限。

WebRTC 反对 b=AS: 形式 (单路媒体)，在 WebRTC 外部对多路媒体进行相加解决即可满足需要，而 WebRTC 目前不反对 b=CT: 形式，所以倡议应用 b=AS: 形式，改变绝对较少。

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

忽然减少一路媒体流时，须要可能很快上探到实在带宽值，应用 probe 疾速探测算法实现这一指标：

如果探测胜利，CC 估计值迅速收敛，在带宽短缺场景中收敛为 CC 下限，带宽受限场景中为实在带宽；
如果探测失败 (如高丢包率场景)，CC 估计值迟缓收敛，在带宽短缺场景中最终收敛为 CC 下限，带宽受限场景中为实在带宽；

辅流与支流的视频大小流的发送优先级统一，所有视频媒体数据，应用估算和 pacing multiplier 的形式做平滑发送解决；
减少一个视频码流类型，kVideoSubStream = 3，与支流的大小流视频数据辨别开来；
Probe 疾速探测期间，当编码数据有余的状况下，发送 padding 数据补救，以保障发送码率满足要求；

下图为理论进行码率调配测试的后果展现：

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

1、发送端和接收端 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，因而此逻辑实用于支流和辅流同时发送的场景，如下图：

2、带宽预计信息获取

以后 SDK 的带宽预计从 Bweinfo 获取逻辑：

获取 gcc、probe 探测等示意总体带宽信息；
获取每个 transceiver 的 voiceChanel 和 videoChannel 相干的带宽预计信息（相似于 MediaInfo 的获取）；

支流和辅流同时发送的场景只是减少了 transceiver，因而此逻辑实用支流加辅流同时发送场景，如下图：

以上就是对于 WebRTC 中视频辅流的分享，次要从业务需要登程，通过技术背景以及要害技术类图，具体分享了对于视频辅流的技术实现。也欢送留言与咱们交换对于 WebRTC 以及音视频相干技术。

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

关于webrtc:WebRTC-系列之视频辅流

需要背景

技术背景

技术实现

要害类图

辅流改变

带宽调配

码率调配

拥塞管制

SDP 信令改变

CC 总码率更新策略

疾速带宽评估

Paced Sender 解决

统计上报

总结

系列浏览