WebRTC 系列之视频辅流

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

1、 需求背景

---

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

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

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

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

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

2、 技术背景

---

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

3、 技术实现

---

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

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

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

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

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