在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

Posted LiveVideoStack

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了在Google Chrome WebRTC中分层蛋糕式的VP9 SVC相关的知识,希望对你有一定的参考价值。

多方呼叫架构是一个常见的话题,主要是因为多方呼叫很难实现和理解,却同时被广泛需要。绝大多数的人都认为可伸缩视频编码(SVC)是最先进的,而多方呼叫架构却是最复杂的。为了理解它是如何工作的,两个WebRTC视频架构专家:Sergio Garcia Murillo是资深的媒体服务器开发人员,同时还是Medooze的创始人。和这个话题直接相关,他最近正在利用VP9和SVC开发开源SFU项目;另外,知名视频专家Gustavo Garcia Bernando也会加入进来。


下面,我们一起来看看在Google Chrome浏览器的WebRTC实现中复杂的技术和还未记录在案的特点(功能)。本文来自即构科技的投稿。


作者 / Sergio Garcia Murillo,Gustavo Garcia

编辑 / Chad Hart


如何针对具有不同能力的参与者来调整视频比特率一直是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编码成本。


  • 三个图层类型


有三种不同的层次:


  1. 时间 - 不同的帧速率。

  2. 空间 - 不同的图像大小

  3. 质量 - 不同的编码质量。


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


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


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


  • 编码和SFU选择


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


  • 控制带宽


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


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


VP9 SVC的状态 


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



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


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

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


VP9有效载荷格式


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


  • 模式


目前,Chrome Canary(58)提供VP9 SVC的两种有效载荷格式:


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

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


  • 结构体


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


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC


解码器需要获得依赖帧,以分辨帧是“可解码的”还是在不给定时接收的帧。


  • 依赖性描述


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


  • P :图片间预测图层帧,指定当前图层帧是否依赖于同一空间层的先前图层帧。

  • D :使用层间依赖性,其指定当前层帧是否取决于来自当前超帧内紧接的前一空间层的层帧。

  • U :切换点,其指定当前层帧是否依赖于同一时间层的先前层帧。


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


依赖模型


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


如图所示:


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

图示说明VP9 SVC视频比特流结构。

数字(1-9)的最后一行代表帧数。


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


  • 选择性转发的例子


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


  • 缩小规模


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


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

缩小第2帧的时间层


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


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

缩小第2帧的时间层


  • 倍增


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


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


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


在Google Chrome WebRTC中分层蛋糕式的VP9 SVC

倍增示例


少了什么东西


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


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


2.提供一种能够在每个会话中启用或禁用SVC的方法,因此可以使用SVC或者1:1使用传统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演示

注意:在Chrome上启用SVC后才能正常工作


WebRTCon 2018 8折报名


WebRTCon希望与行业专家一同分享、探讨当下技术热点、行业最佳应用实践。如果你拥有音视频领域独当一面的能力,欢迎申请成为讲师,分享你的实践和洞察,请联系 speaker@livevideostack.com。更多详情扫描下图二维码或点击阅读原文。

以上是关于在Google Chrome WebRTC中分层蛋糕式的VP9 SVC的主要内容,如果未能解决你的问题,请参考以下文章

google为啥要开源webrtc

播放 WebRTC 流时 Chrome 崩溃?

关于webRTC中video的使用实践

Google Chrome 中未生成接力候选人

WebRTC Chrome 麦克风无法正常工作

WebRTC M96 Release Notes(SDP废除Plan B,支持Opus Red冗余编码)