作者 / Sergio Garcia Murillo,Gustavo Garcia

编辑 / Chad Hart

翻译 / 小极狗


多方呼叫架构是一个常见的话题,主要是因为多方呼叫很难实现和理解,却同时被广泛需要。绝大多数的人都认为可伸缩视频编码(SVC)是最先进的,而多方呼叫架构却是最复杂的。


为了理解它是如何工作的,两个WebRTC视频架构专家:Sergio Garcia Murillo是资深的媒体服务器开发人员,同时还是Medooze的创始人。和这个话题直接相关,他最近正在利用VP9和SVC开发开源SFU项目;另外,知名视频专家Gustavo Garcia Bernando也会加入进来。


下面,我们一起来看看在Google Chrome浏览器的WebRTC实现中复杂的技术和还未记录在案的特点(功能)。拿出小本本做好笔记!




如何针对具有不同能力的参与者来调整视频比特率一直是WebRTC多方呼叫解决方案面临的挑战之一。传统的解决方案基于多点控制单元(MCU)模型。针对具有不同质量、分辨率和帧率的参与者,MCU的转码(完全解码流然后重新编码)分别提供了不同版本的流。


其后,基于转发数据包而不进行任何重新编码的选择性转发单元(SFU)模型开始变得非常流行。主要是因为其可扩展性同时还有相对便宜的服务器端架构,导致SFU在WebRTC中特别受欢迎。在过去几年中,Chrome 浏览器对同时联播和时间可扩展性提供了非官方支持——VP8压缩编解码器,这也是实现WebRTC SFU的最佳方式之一。同时联播要求端点能够发送两到三个具有不同分辨率、质量的相同的流,以便SFU服务器可以转发到每个目的地。幸运的是,在Chrome中启用同时播报功能时,您将自动获得对时间伸缩性的支持(如下所述)。这意味着SFU还可以根据可获得的带宽有选择地转发不同帧质量的数据包。


然而,同时联播确实存在一些缺点,它需要额外的独立编码流,导致了额外的带宽开销和CPU占用。


有什么更好的选择吗?当然有,可伸缩视频编码(SVC)就是一种更为复杂的方法,但它可以在保持SFU模型优点的同时将这种额外的开销降至最低。


什么是SVC

可伸缩视频编码SVC)是指在相同比特流内产生若干编码层的编解码器能力。SVC并不是一个新的概念,它最初是作为H264 / MPEG-4的一部分引入的,后来在2005年被标准化了。不同于发送具有冗余信息和分组开销的多个流的同时联播SVC旨在通过对单个比特流进行分层编码提供更高效的实现。使用单一流和新颖的编码方法提供轻量级视频路由架构的同时,还有助于降低网络带宽消耗和客户端CPU编码成本。


三个图层类型

有三种不同的层次:

时间 - 不同的帧速率。

空间 - 不同的图像大小

质量 - 不同的编码质量。


VP9支持将质量图层作为空间图层,而分辨率不会发生任何变化,因此从现在开始我们将只需要关注空间和时间层。 

SVC层结构决定了编码层之间的依赖关系。这样选择个图层并在编码之后删除所有其他非依赖图层时,也不会影响生成的流的可解码性。 

VP9中,每个层一个整数ID定义(从0开始)。ID较高的图层依赖于较低的图层。

 

编码和SFU选择

VP9 SVC为每个编码的图像帧生成一个超帧。超帧由属于单个时间和空间层的层帧组成。当通过RTP发送VP9 SVC时,每个超帧都会随着单个RTP帧中一起发送,在每个RTP包中都有额外的有效载荷描述,允许SFU提取各个层帧。这样,SFU可以选择当前空间和时间层所需的一个。

 

控制带宽

SFU可以在任何给定的全帧层下压缩(在时间上和空间上)。它只能在有效载荷描述表头上进行拓展升级。

降低时间层的尺寸会导致每秒解码帧数(FPS)的下降。对空间层进行缩小会降低解码图像的尺寸。放大将提供相反的效果。

 

ChromeVP9 SVC的状态 

目前,VP9 SVC仅在标准Chrome浏览器中允许使用。但是,对于任何编码流(至少从M57开始),VP9 SVC都可以使用命令行参数现场调试启用:

 

启用后ChromeSVC编码它发送的每个VP9流。通过上述设置,VP9编码器将产生2个空间层(size  size/2)和3个时间层(FPSFPS / 2FPS / 4),而且没有质量层。举例来说,如果以30 FPS尺寸640×480VGA图像进行编码,则可以在以下分辨率和帧率之间选择


Chrome浏览器 VP9 SVC编码例,指定2个空间层和3个时间层。

 

VP9有效载荷格式

每个携带VP9流的RTP包仅含来自一个层帧的数据。每个数据包也以VP9有效载荷描述开始。该有效载荷描述向SFU提供关于层帧依赖性和可伸缩性结构的提示。

 

模式

目前,Chrome Canary58提供VP9 SVC的两种有效载荷格式:

1.灵活模式 - 提供了动态改变时间层次结构和模式的能力。在每个有效载荷描述头上都提供了每个层帧的参考帧。此模式目前仅用于屏幕共享。

2.非灵活模式 - 在有效载荷描述的可伸缩性结构中指定帧组(GOF)内的每个帧的参考帧,直到发送新的可伸缩性结构前,它们都是固定不变的。这是目前用于实时视频的模式。

 

结构体

在非灵活模式下Chrome Canary实时视频所使用层帧依赖关系中,实际拓展性结构:


解码器需要获得依赖帧分辨帧是可解码的还是不给定接收的帧。

 

依赖性描述

幸运的是,有效载荷描述还为SFU提供提示,根据决定发送到每个端点的期望的时间和空间层来决定哪些帧可能被丢弃。我们需要检查的有效载荷描述的主要位是: 

  • P :图片间预测图层帧,指定当前图层帧是否依赖于同一空间层的先前图层帧。
  • D :使用层间依赖性,其指定当前层帧是否取决于来自当前超帧内紧接的前一空间层的层帧。
  • U :切换点,其指定当前层帧是否依赖于同一时间层的先前层帧。

S位被设置为0时,我们可以在层帧上设置较高的时间层,因为后面的更高时间层帧将不依赖于任何比当前层更高的时间层的先前层帧。当层帧不利用图片间预测时(P被设置为0),可以从直接较低的空间层帧向上切换到当前空间层的帧。

 

依赖模型

现在我们看看如何从最近的Chrome Canary捕获中获得实际的VP9 SVC编码流。对于RTP流的每个帧,我们已经解码了有效载荷描述并提取了代表性比特,并使用可伸缩性结构来描述层帧依赖性。


如图所示



图示说明VP9 SVC视频比特流结构。数字(1-9)的最后一行代表帧数。

 

T表示时间层。 S表示空间层。 S0T0是基础层。超帧14包括一组帧,同样58也是一组帧。 可以看出,空间层 S1的每个层帧依赖于同一超帧的S0层帧。另外,显然,  每个可伸缩性组的第二个T2帧不可缩放,因为它取决于先前的 T2T1帧。

 

选择性转发的例子

使用这个模型,我们来看看给定帧如何选择图层。

 

缩小规模

我们将超帧2中(红色部分)T2  S1层帧缩小到T1  S1层帧中,结果是大小没有改变,但FPS按预期减半:

 

缩小2帧的时间层

 

在相同的图层框架下我们可以进一步缩小到T1  S0,结果是图像尺寸减小(宽度和高度减半),FPS也减半:

 

缩小2帧的时间层

 

倍增 

为了时间上升,SFU应该等待具有切换点标志的层帧被启用(U比特被设置为1)。在非灵活模式下,根据可伸缩性结构周期性地发生。SFU需要等待一个不是帧间图像预测的层帧(P比特设置为0),然后才能进行空间放大。


通过发送RTCP反馈层刷新请求(LRR)消息 或者由图像丢失指示符(PLI/全帧内请求(FIR)来发送SFU能够强制编码器产生非帧间图像预测层帧的一种方式。在我们的RTP示例流中,我们必须等到第68帧才能看到它。这恰好是由帧6768之间的FIR发起的。空间层 S0 不依赖于先前的时间层 T0,所以在那之后可扩展性结构可以用新的帧组重新开始。

 

所以在之前的VP9流中,SFU能够空间上68进行倍增,在时间上73进行倍增

 

倍增示例

 

少了什么东西

目前,通过传递命令行标志并自动获取2个空间层加上3个时间层(如上所示),可以在Chrome中启用VP9 SVC(包括稳定版)。如果谷歌要将VP9 SVC设为默认选项至少还有四个方面的问题亟待解决 

1.启用VP9 SVC如何确定时间层和空间层的最佳组合,或者可以提供一个API来配置(但可能需要部分尚未提供的新ORTCAPI)。 

2.提供一种能够在每个会话中启用或禁用SVC的方法,因此可以使用SVC或者11使用传统VP9方式来进行多方呼叫,以避免SVC编码的开销。 

3.噪声消除被禁用(通过模糊帧消除缺陷),VP9中还不是默认启用。 

4.使用VP9 SVC时的CPU使用率仍然非常高 - 在中高端设备上,检测CPU过度使用和缩减发送的分辨率需要一些时间。

 

结果/演示 

所述,使用SVC编解码器的主要目标是能够生成不同版本的流,而不必对其进行转码。这意味着我们需要生成许多不同码率的流版本,以适应参与者不断变化的带宽。   


在下图中,我们以2Mbps的速度使用VP9 SVC发送同一个流。通过上面的 2SL3TL配置,我们可以通过选择不同的时间和空间层来生成6个不同的版本。最底层版本1/4分辨率的1/4帧速率)大约为250kbps,而其他层次则大约相差200kbps 

测量几个VP9 SVC层组合的比特率

 

您可以使用新的开源Medooze SFU进行测试,或者联系TokBox获取有关其VP9 SVC支持的更多信息。

 

Medooze提供了一个可以测试VP9图层选择Demo演示

地址https//sfu.medooze.com/svc/  

注意:需要Chrome上启用SVC才能正常工作! 

 

关于即构ZEGO

即构科技于2015年由QQ前总经理林友尧创立,A轮获得IDG投资,核心团队来自腾讯QQ,汇聚了来自YY和华为等厂商的顶尖语音视频人才。即构ZEGO致力于提供全球最清晰最稳定的实时语音视频云服务,助力企业业务创新,改变用户线上沟通方式。即构ZEGO深耕视频直播、视频社交、游戏语音、线上抓娃娃和在线教育等领域,赢得了映客、花椒直播、一直播、喜马拉雅FM、陌陌游戏、自由之战2、和好未来等顶级厂商托付和信赖。




Logo

致力于链接即构和开发者,提供实时互动和元宇宙领域的前沿洞察、技术分享和丰富的开发者活动,共建实时互动世界。

更多推荐