WebRTC支持SVC时SDP信令的协商过程

前言

WebRTC支持SVC需要从信令消息和媒体数据两方面入手，其中，信令消息主要是指SDP信息交换，媒体数据主要是指编码器可以编码出带有分层信息的视频码流，同时，打包出支持流媒体服务器转发的RTP包。今天本文会重点介绍信令消息部分的内容，下一篇文章会介绍媒体数据部分的内容。

正文

WebRTC搭配Mediasoup支持SVC能力时，首先需要WebRTC终端通过SDP信息协商交换彼此的SVC能力，协商决定使用SVC分层编码视频后，就开始通知编码器生成具备分层信息的视频编码码流。

一、推拉流整体示意图

WebRTC终端之间进行音视频实时通讯肯定少不了流媒体服务器的参与，本文以Mediasoup作为流媒体服务器为例进行介绍。现在先来看一个最简单的推拉流模型的示意图，其中包含推流端、拉流端、ms（Mediasoup）服务器，具体如下图所示：

上图重点体现了流媒体服务器上的部分逻辑内容，推流端把音视频数据推到Mediasoup流媒体服务器，ms会分别创建音频Producer和视频Producer，同时，也会为相应的拉流端创建音频Consumer和视频Consumer，音视频数据再通过ms内部的pipeline通道从Producer向Consumer传输。至此，整个模型的数据流就串起来了。

二、发布流

发布流和订阅流是两个相对独立的过程，其中，SDP信息交互也是分别进行的。接下来，我们先看一下发布流的整个过程，看看SVC的SDP信息是如何协商的。

推流端发起发布流操作，ms收到publish请求之后，会先检查本地是否已经发布过相同的媒体流了，如果存在，就临时保存一下这条流的已经被订阅的记录，同时销毁旧的媒体流；如果不存在，就执行正常逻辑，首先创建Pipeline，然后使用Pipeline对象创建Peer，再基于Peer实例化Publisher。

然后查询是否存在原来的订阅记录，如果存在，就查询刚才的记录，再根据读取的订阅记录恢复原来的数据连接；如果不存在，就继续执行剩下的逻辑，调用processOffer方法处理SVC信息，然后根据客户端的offer信息中是否存在SVC信息创建不同类型的Producer。

注意：这里需要说明的是，其实Producer本身并没有类型之分，这里是为了区分SVC和非SVC的不同逻辑分支才这样画图的。

如果推流端的offer中含有SVC信息，那么ms返回的answer中也会包含SVC信息；如果没有，那就返回普通的answer，启动非SVC模式推流。

三、订阅流

相比发布流，订阅流的过程可能会稍微复杂一些，拉流端发起订阅请求后，ms收到消息之后，会先判断本地是否存在对应的媒体流，如果没有，就直接报错并返回500的错误码。同样，如果不存在Pipeline内部媒体数据通道，也会直接报错并返回500的错误码。

接下来会进行兼容性判断，查看拉流端是否已经订阅过这路媒体流了。如果是，那就销毁旧的媒体流（原来订阅的）；如果不是，就继续创建Peer和Publisher实例，然后查看拉流端的offer中是否携带了SVC信息，如果携带了就表明拉流端希望订阅具有视频分层的媒体流，尽管拉流端表明了这样的意愿，但是还需要媒体流本身带有这样的分层属性才可以，毕竟分层数据不会凭空产生，需要推流端的编码器提供能力支持。因此，还需要判断媒体流的Producer是否具有SVC属性。

上述两个条件缺一不可，如果条件不成立就创建普通的Consumer实例；如果条件成立，还会进一步判断编码码流的数量，如果是大小流，会创建SimulcastConsumer实例；如果不是大小流，就会创建普通的SVCConsumer实例，同时返回相应的携带SVC标识的answer信息。

注意：这里需要明确的是SimulcastConsumer同时具备SVC和Simulcast的能力，不存在单独的SVCConsumer。

结尾

通过本文的介绍，相信大家对WebRTC在支持SVC能力时的SDP消息协商过程就非常清晰了。或者，至少对整个过程有一个基础的概念，推流端的发布流和拉流端的订阅流两个过程既是独立的，同时又存在一定的联系。下一篇文章会介绍SVC媒体数据方面的内容，敬请期待。

作者简介：😄大家好，我是 Data-Mining（liuzhen007），是一名典型的音视频技术爱好者，前后就职于传统广电巨头和音视频互联网公司，具有丰富的音视频直播和点播相关经验，对 WebRTC、FFmpeg 和 Electron 有非常深入的了解。同时也是 CSDN 博客专家（博客之星）、华为云享专家（共创编辑、十佳博主）、51CTO社区编辑、InfoQ 签约作者，欢迎关注我分享更多干货！😄