用于WebRTC的可伸缩视频编码(SVC)

Web实时通信（WebRTC）技术承诺了超低延迟的流媒体，但是有一个问题（可以这么说）。该技术是出了名的难以扩展，而且开发者尝试得越多，就越难保持构成WebRTC吸引力核心的速度。输入：辅助服务器和适应性工作流程，以规避这些障碍。

那么，这一切与可伸缩视频编码（SVC）有什么关系呢，SVC是2007年首次发布的编解码器扩展（比WebRTC最初推出的时间早了六年）？简而言之，当WebRTC还是谷歌眼中的苹果时，SVC被设计用来改善流的适应性，并且在解决WebRTC的可扩展性问题方面显示出巨大的前景。说来话长，请继续阅读。 

什么是可伸缩视频编码(SVC)？ 

让我们从 WebRTC 中抽出一分钟来上一堂简短的历史课。SVC 最初是作为 H.264（也称为 MPEG-4 或 AVC）编解码器的扩展。作为一种视频编解码器，H.264 压缩原始视频数据以便通过网络进行存储和传输。内置于其 1 和 0 中的是一系列关于如何压缩此数据的规则，包括帧速率和质量标准。为了更改此数据的比特率以流式传输到不同的设备，您需要以不同的大小解压缩和重新压缩数据。这对于媒体服务器来说是相当标准的，其工作通常需要对编码文件进行转码以改善播放效果。然而，这需要时间。 

通过添加 SVC，H.264 能够对原始视频数据进行分层编码，这样文件就可以“剥离”以访问不同的比特率，而无需解压缩数据。基本上，单个流被发送并根据需要在不同设备上播放。无需转码 。 

可伸缩视频编码和 WebRTC

尽管 H.264 是 WebRTC 支持的视频编解码器，但带有 H.264 的 SVC 不是。无论出于何种原因，SVC 仅作为 Google 自己的 VP9 编解码器的扩展以及最近与 Google 的 AV1 编解码器一起用于 WebRTC 。这是一件好事，因为 SVC 使用更少资源创建自适应流的独特方法非常适合解决速度与可扩展性难题。 

当然，如果您想将 SVC 与 WebRTC 结合使用，您需要的不仅仅是 VP9 或 AV1 视频编解码器，除非您的计划只是以单一高比特率向所有播放设备发送臃肿的流。典型的 WebRTC 不需要媒体服务器，这通常被认为是小规模流的优势。但是，SVC 需要一个选择性转发单元 (SFU) 媒体服务器来完成剥离编码流并将适当的比特率发送到播放设备以获得最佳流质量的重要工作。

可伸缩视频编码是如何工作的？ 

好吧，我们一直在向您抛出大量行话，尽管如此，您可能很清楚 SVC 究竟是如何促进流适应性和可扩展性的。也就是说，让我们对其进行分解，以更好地理解它与具有相似目标的工作流有何不同。 

想象一下您的流分为三个部分： 发布者、SFU和播放设备集合。 

发布者指的是您，或者更确切地说，是指您用来捕获和编码视频文件的任何设备。您可以将这些文件作为一个或多个编码流发送到 SFU 进行分发，每个文件都以特定的比特率进行编码。在 SVC 的情况下，您有一个在多个比特率层编码的流，这样如果您要剥离一层，您仍然可以在较低的比特率下有一个完整的流。 

这个流被发送到 SFU。SFU 的工作是剥离流层，创建适合在给定设备上进行最佳播放的流。  

然后 SFU 将调整后的流发送到适当的播放设备。根据目标设备的可用带宽和其他限制，一些可能会收到质量较低的流，而另一些可能会收到整个洋葱（可以这么说）。 

我应该使用什么比特率层？ 

WebRTC 带宽估计允许发布者根据他们与接收者设备之间的可用带宽来确定目标输出分辨率。您的发布商看不到中间有 SFU 的最终用户带宽，但它可以采用相同的策略，根据它和 SFU 之间的可用带宽来确定目标输出分辨率。该目标分辨率成为洋葱的顶层和通过算法运行该目标分辨率确定的所有其他层。 

降低比特率到底意味着什么？ 

比特等于数字信息。比特率是指比特通过网络传输的速度。这通常以千比特每秒 (Kbps) 为单位进行测量。更高的视频比特率可以以流式传输所需的速度传输更多信息，从而转化为更高质量的视频。 

也就是说，媒体发布者不只是丢弃视频块来创建较低层的洋葱。选择如何缩小视频的过程更加微妙。要理解这一点，将视频信息分为三类：空间、时间和信号质量。 

• 空间分辨率 ——将其视为给定帧（即像素）中的空间信息量。空间分辨率越高，图像越清晰。 
• 时间分辨率 ——这是给定视频中的时间信息量（即帧速率）。时间分辨率越高，视频越流畅。 
• 信号质量 ——自然地，比特和帧对视频的整体质量有影响。信号质量特指保真度，或原始图像的保存程度。  

根据这三种措施，编码成层的流将丢弃数据包（信息）以实现较低的比特率。它可能会优先考虑某些因素而不是其他因素，或者选择混合方法。 

可伸缩视频编码的好处

视频流的神奇之处在于它可以到达几乎任何地方的任何设备。视频流的挑战在于它通常 可以 到达任何地方的任何设备。流媒体专家一直在寻找更好、更可靠的方法来定制他们的流媒体以适应各种播放设备和带宽限制。那么 SVC 适合您还是应该探索不同的方法？ 

SVC 和自适应比特率流式传输

 如果您想流式传输到大量不同的设备，自适应比特率 (ABR) 流式传输被许多人视为黄金标准。此方法 在流式传输时对编码数据段进行转码。当每个数据段到达给定的播放设备时，有关带宽可用性的信息将被发回。媒体服务器  根据此信息向上或向下调整后续片段的比特率。这种方法对于在不牺牲流可靠性的情况下提供尽可能高的质量非常有效。 

对于许多用例，这是一个可靠的解决方案。然而，WebRTC 流媒体的支持者发现实时转码数据所需的时间显着增加了延迟。由于 WebRTC 的主要卖点是速度，这就带来了一个问题。 

另一方面，SVC 不需要转码。SFU 改变已经编码的数据而不需要重新打包它。简而言之，它比 ABR 更快，但没有那么细微差别，特别是在涉及最终用户带宽波动的情况下。 

SVC 和 WebRTC 联播

WebRTC 联播的工作方式与 SVC 非常相似。它们都涉及向 SFU 媒体服务器发送少量比特率选项，该服务器会为给定的最终用户设备选择最佳比特率。但是，WebRTC 联播不会创建单个分层流。相反，它以几个不同的比特率创建几个不同的流。 

SVC 和 WebRTC 同播具有相似的优势和工作流需求。但是，与单个分层流相比，编码三个独立流可能需要更多的发布者带宽。因此，SVC 是  实现相同带宽选项的更有效且资源密集度更低的方法。也就是说，分层流的臃肿特性确实会导致比特率损失。换句话说，它可能需要以更高的比特率进行流式传输，以保持类似单个流的相同质量。那并且它不适用于 WebRTC 的 VP8 编解码器。 

可伸缩视频编码入门 

Wowza 的 Real-Time Streaming at Scale 解决方案使 WebRTC 可以扩展到跨多个平台的一百万观众。在我们的工作流程中，发布者数据被发送到我们的 Wowza Video API。然后通过自定义内容分发网络 (CDN) 进行大规模分发。此 CDN 充当 SFU，通常用于 WebRTC 联播工作流。然而，我们对 VP9 和 AV1 编解码器的支持打开 了WebRTC 工作流程的可能性，直至可扩展视频编码。无论您的 WebRTC 需要什么，我们的视频专家都能让您走上正确的道路。

作者：Sydney Whalen，Wowza的内容作家和社交媒体营销人员。