webrtc只能用rtmp推流吗

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

近几年，实时音视频领域越来越热，业界很多音视频引擎都是基于 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 以及音视频相关技术。