共计 3583 个字符，预计需要花费 9 分钟才能阅读完成。
作者：网易云信资深客户端开发工程师 陶金亮
近几年，实时音视频畛域越来越热，业界很多音视频引擎都是基于 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，依照咱们的策略，调配给大流、小流应用；
拥塞管制
为了实现视频辅流的性能，咱们须要对拥塞管制进行相干的改变，次要通过以下四个方面的改变来实现：
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 获取。
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 搭建一个视频会议
