通常新手在学习 H.264 的时候，通常会认为 AVC 是 H.264 协议的别名。但自从2007年H.264协议中增加了 SVC 的部分之后，人们习惯将不包含 SVC 的H.264协议那一部分称为 AVC，而将 SVC 这一部分单独称为 SVC。所以提到 AVC 的时候，需要根据具体情况判断到底是指 H.264协议还是指协议中不包含 SVC 的那一部分。

可伸缩视频编码技术(SVC)在视频会议行业和视频通信中有着重要的影响。在2008年，当Vidyo首次推出SVC时，很少人意识到它背后所蕴含的变革力量。大多数人都认为它仅仅只是一个更好的编解码器，甚至还有可能存在一些有待完善的错误。

与任何新技术一样，刚开始时，我们都很难完全理解SVC的工作原理，相关系统及功能的实现机制，甚至是它对整个行业的影响。本文旨在提供一些有关SVC的事实和理论知识，同时分析一下目前可伸缩视频编码在视频通信领域的定位以及未来的前景所在。

所以，什么是 SVC？

SVC全称是Scalable Video Coding，翻译成可分层的，可分级的，可扩展的。H.264的AVC是JVT制定视频编码标准。H.264扩展标准支持多种可分级类型，其中空域可分级、时域可分级、质量可分级，是可分级模式的典型代表。JM86的编解码是基于AVC，JSVM的编解码是基于SVC。

H.264 SVC（H.264可分级编码）作为H.264标准的一个扩展最初由JVT在2004年开始制定，并于2007年7月获得ITU批准。H.264 SVC以H.264 AVC视频编解码器标准为基础，利用了AVC编解码器的各种高效算法工具，在编码产生的编码视频时间上（帧率）、空间上（分辨率）可扩展，并且是在视频质 量方面可扩展的，可产生不同帧速率、分辨率或质量等级的解码视频。

它是H.264 / MPEG-4 Part 10高级视频编码标准的扩展，统称为Advance Video Coding。AVC是由国际电信联盟(ITU)的视频编码专家组(VCEG)和国际标准化组织(ISO)的运动图像专家组(MPEG)共同开发的，合称联合视频组(JVT)。因此，AVC有两个正式名称：国际电信联盟(ITU)命名的H.264和国际标准化组织(ISO)命名的MPEG-4 Part 10。通常，通信领域的人倾向于将AVC称为H.264，而广播影音娱乐领域的人则倾向于将其称为AVC或MPEG-4。毫无疑问AVC一直是非常成功，它几乎适用于所有现代数字视频应用标准：从视频会议和YouTube，到蓝光DVD和iTunes商店。

SVC是AVC标准的附录G。有人却用AVC这个词来表示H.264标准和附录G，这令人费解。在本文中，我们使用AVC来描述H.264的不可伸缩部分，而用SVC来描述可伸缩部分，当不加区分时则使用H.264进行描述。即这样理解：AVC + SVC + ... = H.264

H.264规范提供了一种方法，允许根据特定的应用领域搭配不同的使用规范，事实上，绝大多数视频编码标准都会有基本的使用规范，并且提供可修改的方法，我们称之为配置文件。配置文件可以说是标准规范所提供的编码工具的子集，主要适用于特定的应用领域。例如，增加端到端延迟的功能对于广播视频而言是可接受的，但对于视频会议而言则是不可接受的，因此在面向视频会议的配置文件中则不包括这个功能。H.264的可伸缩特性体现在其配置文件的参数设置中：Scalable Baseline、Scalable High、Scalable Constrained Baseline、Scalable Constrained High和Scalable High Intra。尽管，在高清分辨率运行的软件配置文件中一般包含Scalable High参数，但是针对视频会议(移动设备)应用的配置文件，一般只包含Scalable Baseline和Scalable Constrained Baseline这两个参数。

与配置文件相关的是一个名为层级的概念。层级定义了特定配置文件中各种操作参数的限制。例如，它定义了特定解码器所能够处理的最大图片的大小。配置文件和级别是一个相当古老的概念：您的普通旧式DVD播放器中，播放MPEG-2格式的视频的主要配置文件是在主级解码器上。您的蓝光播放器所包含的H.264 AVC的高配置解码器则是在4.1级。

AVC和SVC有什么区别？

SVC和AVC的根本区别在于，前者将视频信号编码为一组图层。各层互相依赖，形成一个层次结构。特定层及其所依赖的层提供了以特定的保真度解码视频信号时所必需的信息。这里的保真度涉及一个或多个空间分辨率，时间分辨率或信噪比(SNR 压缩视频信号相对于其未压缩版本的失真度量)。不依赖于任何其他层的最底层被称为基本层，并提供最低质量等级的图像。每个附加层可以通过三个维度(空间，时间或SNR)中任何一个维度提高信号质量。

图1表示以不可缩放的方式进行视频编码。这就是大多数(如果不是全部的话)AVC兼容视频编码器的工作原理。图中每个正方形表示一张图片，而底部的数字表示时间实例。第一张图片为“I”帧，可独立编码，无需参考其他任何图片(“I”取自单词“intra”的首字母)。其他所有的图片为“P”帧，需要参考前面的帧画面进行预测然后编码。箭头表示预测的源图片以及目标图片。通过观察可知，只需一层，则可形成一个无止境的图片链。

图1：非缩放性视频编码

图2表示在时间维度上的可伸缩性视频编码。观察预测箭头的组织方式，在这个例子中，定义了三个不同的层(L0到L2)。图中的图片是垂直偏移的，以便在视觉上分离三层。每一层都需要依赖较低层才能被解码，但不需要任何较高层。这允许从顶层开始移除图片，而不影响剩余图片的可解码性。例如，我们假设图例中显示的图层以30 fps的帧速率显示。如果我们移除所有L2层的图片，剩下层(L0和L1)仍然可以成功解码，并且产生一个15fps的视频。如果我们进一步删除所有的L1图像，那么剩下的L0层依然可以被解码并产生一个7.5fps的视频。

图2：时间可伸缩性

图3所示，我们可以通过扩展时间可伸缩性结构同时实现空间可伸缩性编码。每个图片现在有两部分：基础层分辨率图片的B部分和空间增强层的S部分，这两个部分结合则可生成全分辨率图像。空间增强层一般为水平和垂直方向上基底分辨率的1.5倍或者2倍。这为不同分辨率的视频在进行空间可缩放性编码时提供了便利，例如VGA和QVGA(比率为2)以及1080p和720p(比率为1.5)，都可以进行空间可伸缩性编码。空间可伸缩性可以与时间可伸缩性(和SNR)以完全独立的方式相结合。假设在图示例子的全速率和分辨率分别为30fps下的HD高清分辨率(720p)，那么我们可以在分辨率(HD、1/4HD)和帧速率(30fps、15fps、7.5 fps)之间进行任意组合。

图3：空间和时间的可伸缩性

H.264 SVC通过在在编码码流嵌入具有相关性的多个不同分辨率的子流实现空间上的可分级。上层所有的视频帧构成了高分辨率视频，下层所有的视频帧构成了低分辨率视频。值得注意的是，这不是唯一的可伸缩性结构——在构建空间和时间预测结构方面，该标准具有较大的灵活性。

SVC的一个非常重要的方面是基本层符合AVC的设计。换句话说，SVC信号的基本层可通过AVC解码器进行解码。这确保SVC信号与AVC向后兼容，尽管在涉及到一个以上的层时，其保真度会低于全信号。但注意，SVC编码器不需要一直生成分层比特流 - 如果在不需要和不必要进行可伸缩性编码的环境下运行时，则可以生成传统的AVC流。

为什么使用SVC？

SVC提供了一种适应性较强的视频信号表示方式。换句话说，无需对信号进行解码、处理和重新编码，也可以实现自适应。如果我们想要改变图像分辨率或时间帧速率，那么我们唯一需要做的就是从图1中的图表中移除适当的块。如果将这些块视为通过网络传输的数据包，这就相当于从传输的比特流中移除相应的网络数据包。这一点意义非常重大：它为基于多点控制单元(MCU)的传统视频会议系统架构提供了新的设计思路。

MCU是一个复杂的设备，它接收多个视频编码信号，解码后合成到一个新的图像上，重新编码后，再将编码信号发送给预定接收者。显然，从计算的角度来看，这是一个非常复杂的操作。此外，在系统运行中还引起了相当大的延迟，通常为150-200毫秒。为了更好的比较，我们给出一个数据：国际电联规定长途电话的端到端延迟的上限为180毫秒。超过180毫秒后，延迟会令正在通信的各方用户产生较差的体验感受。显然，与MCU进行交互式多点通信是非常困难的。由于采用了级联编码，会导致了质量的损失。值得注意的是，这些问题是架构中固有的，无论投入多少资源都不会消失。例如，提高MCU内部DSP处理器的速度也只能稍微减少延迟。

因此，具备H.264 SVC编码的视频会议系统，在保证高效的视频压缩性能的基础上，视频广播端可以通过一次编码产生具有不同帧率、分辨率的视频压缩码流，以适应不同网络带 宽、不同的显示屏幕和终端解码能力的应用需求，从而有效地避免了视频会议系统中MCU上复杂而昂贵的转码。

AVC不如SVC有效吗？

SVC的高效有一定的代价。如果SVC和AVC编码器产生的相似质量的比特流，那么SVC将比AVC需要大约10-15%的比特位(这取决于编码器的成熟性)。认识到这种“开销”对我们来说非常重要。尽管有额外的开销，但是我们将获得端到端的低延迟和稳健的容错性 - 仅AVC就无法实现这一点。事实上，如果我们考虑丢包造成的质量损失，我们很快会发现，因为AVC编码的质量下降得很快，所以它的效率是远低于SVC。额外的开销带来的回报是，我们的服务器可以轻松扩展至100位用户，以及所有高端视频会议系统功能，如个性化布局和速率匹配。

只关注压缩效率是一个非常狭隘的观点，因为它忽略了完整系统中真正发生的情况。通过共同考虑压缩效率和网络传输，人们可以设计解决方案平衡这两个方面的消耗，解决系统级问题。牢记SVC是AVC的扩展也很重要。这意味着，当条件允许时，换句话说，当网络具有极高的可靠性时，所有端点都具有类似于网络的访问速度，同时所有端点都具有类似的编码和解码能力时，SVC系统就可以恢复使用普通AVC。然而，当考察企业的全体用户时，我们很少能够访问这样一个非常可靠的网络，而且实际上我们也从未有过相同的接入网络或端点。

就像普通汽车和越野四轮驱动车一样，虽然四轮驱动车确实会燃烧更多的燃料，但是谁愿意在海边平面沙滩上或者峻岭山峰上冒险行驶普通汽车呢? 另外，您可以在不需要时关闭它。实际情况是，在全球互联网中，数据包走的路总是危险的。

可伸缩性、联播和SFUs

对于单一视频信号，同时提供多个不同表示的简单方法就是产生多个编码。与可伸缩编码相反，这不需要任何新的编码工具：您只需以不同的分辨率来多次运行编码器即可。这将产生多个独立的比特流，并且比可伸缩编码占用更多比特位(通常比单个高分辨率流高50%)。由于两个流之间缺乏依赖关系导致了较差的健壮性。这种方案被称为“联播”(源自“同时广播”)，并且可以被认为是可伸缩性编码的一个个别案例。（现阶段多数大厂的做法）

 图4：联播架构

隐藏在联播背后的是，您可以使用一个与VidyoRouter类似的服务器而不是可伸缩编码：终端将高分辨率和低分辨率的流一同传输到服务器端，然后再由服务器选择将流传输到不同的接收端。联播将其开销放置在糟糕的节点上：从传输端点到服务器的上行网络。这往往是最成问题的，例如，ADSL线路。联播技术的一个优点是最高分辨率比特流可以由传统(非伸缩性)解码器进行解码。因此，对于那些部署了大量无法升级的硬件解码器的公司来说，这更具有吸引力的。

在2008年VidyoRouter推出时，其操作原理非常新颖。事实上，和VidyoRouter同时发布的“RTP拓扑结构”RFC(RFC 5117)提供了一个可以用RTP实现的各种实时通信架构的调查，但没有预见到它。2013年10月，我创造了“选择性转发单元”(SFU)来描述选择性转发服务器的操作，不管它是否用于可伸缩视频或联播。在2015年11月发布的RFC 5117修订版(RFC 7667)中，该术语已被采纳，现在详细描述其操作。

http://info.vidyo.com/rs/vidyo/images/WP-Vidyo-SVC-Video-Communications.pdf

参照原文作者 / Alex Eleftheriadis, Ph.D., Chief Scientist of Vidyo