别人问到了 svc的空域分层 所以想起来说说这个  我只是初学者中的菜鸟 搬运来 学习 大佬勿怪 请多指点带带弟弟~~ 

 H.264 SVC

可伸缩视频编码SVC（Scalable Video Coding）作为H.264标准的一个扩展最初由JVT在2004年开始制定，并于2007年7月获得ITU批准。已经过10年左右的发展。

　　SVC解决的痛点

众所周知，视频编码器是用来压缩原始采集的视频数据，压缩后的数据可以有效降低传输带宽和存储空间。而压缩的代价是增加了运算复杂度：压缩率越大，运算复杂度越高。在带宽和运算复杂度之间寻求平衡需要同时定义链路最低带宽和解码设备的最低能力。在传统视频系统中（比如：广播电视）就明确定义了解码设备（机顶盒）的最低需求。

现如今，视频被越来越多不同的应用使用。这些应用具有不同类型的接入终端，从个人计算机到平板，以及普及度极高但性能各异的手机等。对视频流而言，这些设备的需求各异。为了兼容不同的终端设备和链路带宽，同一个视频流必须用不同的设置多趟编码。其中，每种设置都对应一种视频流的传输带宽和对应观看设备的解码能力。如果事先得不到原始的未压缩视频，可能就需要多次转码，即对压缩后的流先解码，然后使用新的设置再次编码。

理想的情况是：视频应当仅编码一次，编码后的流在解码后将产生一个全分辨率视频。更为理想的情况时：如果一个低分辨率或低带宽的流需要被传输给一个低性能设备，则应该仅传输编码流的一小部分而不需要任何额外的运算。同时，选取的这一小部分流应该易于解码成低分辨率视频。如此，一次编码的码流就能够灵活适应不同的传输带宽和目标设备的处理能力，这正是SVC技术的特色。

　　H.264 SVC技术简介

　　H.264 SVC是H.264标准的扩展部分，作为H.264标准的一个扩展最初由JVT在2004年开始制定，并于2007年7月获得ITU批准。其目的是解决上节描述的场景。SVC以标准H.264 AVC视频编解码标准为基础，同时对原有编解码工具进行了扩充。不同的是，SVC生成的码率是可伸缩的：时域、空域和视频质量。也就是说，它能生成不同帧率、分辨率和质量等可分层的视频流，它利用了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商店。

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级。

　　SVC扩展部分引入了一种传统H.264 AVC不存在的概念——编码流中的层。基本层编码最低层的时域、空域和质量流；增强层以基本层作为起始点，对附加信息进行，从而在解码过程中重构更高层的质量、分辨率和时域层。通过解码基本层和相邻增强层，解码器能生成特定层的视频流。

　　H.264 SVC码流的分层结构如图1所示。编码器在编码某一特定层时只能参考较低层的编码信息。由此，可以在任意位置对码流进行删节，同时保持码流的有效性和可解码。这种分层方法让所生成的编码码流能够被删节以限制所消耗的带宽或者降低解码计算的要求，删节过程通过从编码视频流中提取所需要的各层而构成。

svc相关_音视频

为了实现时域可分级，H.264 SVC对参考帧和预测帧的实现有别于原有的H.264 AVC编码。传统的I帧，B帧和P帧的关系如图2所示；SVC采用分层预测结构，如图3所示，这种分层结构定义了最终码流的时域分层情况，该结构不但实现时域可伸缩同时确保低延时。

svc相关_音视频_02

该示例包含4个嵌套的时域层：T0（基本层），T1，T2和T3，上层的帧只能通过低层或同层已编码的帧进行预测。当播放帧率为3.75fps时，只需解码T0层的帧，丢弃所有其他帧；当播放帧率为7.5fps时，解码组成T0和T1层的帧，丢弃T2和T3层的帧；以此类推，解码T0，T1和T2层的帧，码流的播放帧率达到15fps；解码所有帧将恢复30fps的全帧率。

相比H.264 AVC（考虑baseline profile的情况），不管所需帧率是多少，所有的帧都必须解码。如果需要向低带宽网络传输码流，则需要先解码整个流，进行帧率下采样后再重新编码。

空域可伸缩遵循相似的原则。在这种情况下，低分辨率帧作为基本层编码，基本层解码并上采样后可以用来预测高层的帧，重构原始场景细节所需要的额外信息作为一个独立的增强层。某些情况下，重用运动信息能进一步增强编码效率。

由于可伸缩性的自身限制，H.264 SVC 存在一些不足。如图4所示，与传统的帧结构相比，参考帧和待预测帧之间的距离（比如T0到T1）可能更大。在高运动场景下，这可能会使压缩效率略有降低。

与不具备可伸缩性的全帧率和分辨率的H.264 AVC码流相比，包含三层时域可伸缩和空域可伸缩的SVC码流预计将增多20%的码流。相反，若用H.264 AVC实现可伸缩性，将需要编码多个流，从而导致带宽需求的大幅提高或是更高的转码代价。

　　SVC技术优劣势分析

1. 一次编码，多次解码

这正是SVC设计的初衷，那么在互联网双向实时视频交互应用中如何使用呢？发送端需要上传全码流，如前所述，如果解码器不需要较高层，它简单丢弃无用的包即可，但上传仍然占用了上行带宽。在互联网场景下，最后一公里带宽是双向视频应用经常面对的问题，通常上行带宽往往小于下行带宽，在下行带宽已经受限的情况下，如何上传全码流？当然，不同厂商有各自的解决方案，通过在网络中放置专门的网络设备分析并丢弃不需要的层。

2. 差错恢复

传统的差错恢复技术通过增加码流中的冗余信息来检测和校正差错。SVC的分层方法意味着不需要添加额外开销，就可以使低层利用高层的信息进行错误检测和纠正。同样的，要对AVC流进行相同的错误检测和校正，则意味着对整个流进行保护，从而导致最终的码流更大。如果在SVC流中检测到了错误，分辨率和帧率可以逐步降层直至基本层。在高信道噪音条件下，这种方式比H.264 AVC更容易接受。

很多测试结果表明，SVC的抗丢包率高达20%，然而深究一下就会发现这些测试方法存在缺陷。在在IP网络下，大多数丢包不是随机产生的，而是连续丢包。路由器缓冲队列溢出后，大量的包被丢弃。在这种情况下，依靠SVC分层提供冗余将失效，因为基本层和冗余信息都将丢失。

3. MCU去中心化

SVC的应用场景之一是减轻传统MCU的转码压力，码流在MCU无需额外处理，仅根据接收终端的带宽和解码能力进行删节并路由。对应的缺点是，它同时把压力从中心化的MCU转移到了众多的客户端。假设8个人参会，客户端必须解码7路而非一路；接收7路码流的带宽也比从MCU仅接收一路要大的多。现在，很多应用使用rtcp复用和捆绑技术将音频、视频和两路rtcp流合成到一个端口；使用SVC后，即便使用了rtcp复用和捆绑技术，也需要分别为每个参会者都绑定一个端口。

4. 存储管理

因为SVC码流或文件即使在删节后仍然可以解码，因此在传输和存储时都可采用SVC。分析磁盘上存储的文件，仅移除增强层而无需对视频流进行额外处理就可以有效压缩文件的大小，而AVC文件的处理方式只能是“要不全留，要不全删”。

5. 内容管理

SVC码流或文件固有的包含低层分辨率和帧率的流。这些流可以用来加速视频分析或视频分类等应用，时域可伸缩性也使流中的前向搜索变的更为容易。

　　应用及现状分析

在视频监控和视频会议等领域已经有一些国内外厂商（如华为，Vidyo，Polycom，Cisco，容联云通讯等）将SVC技术实现并集成在产品中。

虽然SVC本身是一个标准，但不意味这那些实现SVC的厂家之间能够互通。与H.264 AVC标准相比，使用SVC的厂家和应用较少，相应在市场标准化上难以统一。在使用SVC编码时，要全面考虑终端设备的编解码复杂度和带宽能力，根据应用场景灵活选择。

完事