H.264基本概念总结之SVC
date
May 13, 2022
slug
2022-05-13-H264-basics-svc
status
Published
tags
H.264
音视频
type
Post
AI summary
summary
本文基于对参考资料的学习，整理了H.264的SVC扩展的一些基础信息。
SVC：Scalable Video Coding，是H.264（AVC）视频编码算法的一个扩展。
SVC要解决的问题
H.264视频压缩算法是用来对图像数据进行压缩，以方便进行存储和通过网络传输。
在进行1对1传输的时候，使用标准的H.264(AVC)一般不存在问题：
- 在接收端处理能力比较强、网络带宽也比较好的情况下，可以设置编码器输出一个图像质量更高、分辨率更大、帧率更高的图像，给接收端提供更好的观赏体验；
- 而如果接收端处理能力有限，或者网络带宽不足以传输较好质量的压缩视频数据时，可以设置编码器输出的图像质量稍差一些，分辨率更低或者帧率更低，这样对网络传输要求的带宽更低，对解码器的处理能力也要求更低。
- 实际上在1对1通信的过程中，还可以在发送端与接收端的网络通信中，动态监测网络带宽的变化，对编码器进行动态的调整：网络质量更好的时候编码器输出码率更高、带宽更高的图像；而网络比较差的时候则输出码率更低、对带宽要求更低的图像。
但是，在一对多的视频通信应用场景中（最典型的就是视频会议、直播、在线点播等），一路摄像头采集的图像需要发给多个接收端，每个接收端的处理能力和网络通信状态都有差异，那么就对发给这些接收端的图像质量、分辨率、码率等提出不同的要求：处理能力更强、带宽更好的接收端期望能够收到码率更高、质量更好的图像，以尽可能保证用户体验；而处理能力有限、带宽较差的接收端至少期望能够收到一个码率更低但是确保播放过程中足够流畅的视频。
但是，对于标准的H.264(AVC)编码器而言，编码器的参数设置之后，输出的图像分辨率、帧率和图像质量等指标基本上就是固定的。
针对这个问题，最直接的解决办法就是：摄像头端的图像采集后，使用最高质量的视频压缩参数进行视频压缩，然后上传到中心服务器；在中心服务器上对这个高质量的图像进行各种不同分辨率、帧率、码率组合的转码操作；然后再根据接收端的网络带宽状况和处理能力，向不同的接收端分发不同的转码图像文件。
- 实际上，现在互联网上的点播系统（Youtube、B站等）的工作原理就是如此，主播的图像视频使用高质量编码参数压缩后上传到中心服务器，在中心服务器上进行转码，转码为不同的分辨率以支持不同的客户端设备。
以上解决方案的问题在于：在服务器端进行转码的操作在某些应用场合中太昂贵了！如果这个视频图像有成千上万个用户观看的话，在中心服务器上对上传视频进行转码操作是可行的，但是如果这个视频只有少数几个人（最典型的就是视频会议的应用）观看的话，还需要把每一路上传视频都进行转码并转发的话，对于中心服务器的压力就太大了。
- 想象一下，如果有8个人开会，那么就会有8路图像送到中心服务器同时进行各种分辨率和压缩质量的转码并分发，这对于中心服务器的压力会有多大。而付出这么大的计算量，却只能为8个人的小型会议提供服务，这种方案的性价比和流媒体的处理效率就太低了。
因此现在的问题就是，针对视频会议这类小型的一对多或者多对多的应用场景，如何在不通过中心服务器转码的情况下，能够实现对不同接收端提供不同质量和码率的视频分发？这就是H.264的SVC扩展所要解决的问题。
SVC解决以上问题的思路
SVC解决以上问题的思路就是：
- 在视频图像的提供者也就是摄像头端，进行一次编码，这个编码输出的图像流可以从结构上分为多个部分，完整的图像流（也就是所有部分的组合）就表示是最高质量级别的图像，码率也最大；而把这个图像流中所包含的各个部分进行各种组合，保留一部分，去掉一部分，就可以组成各种针对不同类型、不同质量级别的子图像流。
- 摄像头端把压缩好的完整图像流上传到中心服务器，中心服务器不需要对这个图像进行重新转码，只需要根据图像接收端的处理能力和带宽情况，从这个完整的图像流中选择部分或者全部流数据到接收端。
- 接收端收到图像以后直接进行解码回放，处理能力强、网络带宽状况好的接收端收到的很有可能就是完整的图像流，解码后回放的图像效果也最好；而处理能力差、带宽较差的接收端可能就只能接收到完整图像流的一部分，解码后仍然可以得到一个分辨率、帧率或者图像质量更差的效果，但至少能保证回放的流畅度。
以上方案中提到的完整图像流的“部分”实际上就是SVC中的分层（Layer）。所有分层的组合形成了最高质量的图像，部分分层的组合则可以得到一个某些特性较差、对带宽要求也较低的图像。
以上方案的关键就在于视频编解码器：
- 编码器端要能够按照以上的逻辑生成分层的视频图像流，在标准H.264的AVC规范里面是不支持的，AVC没有这个分层的概念；
- 解码器端则既要能够实现对完整图像流的解码，也能够对完整图像流的多个分层部分的组合进行解码，输出不同质量属性的视频图像；
而满足H.264的SVC扩展属性的视频Codec则可以符合以上两个条件。
SVC的技术实现细节
SVC中的S表示Scalable，表示是可以扩展的。在SVC的标准中，在以下三个维度上提供了可扩展的选项：
- Quality Scalability：图像压缩质量
- Temporal Scalability：帧率
- Spatial Scalability：分辨率
如上所述，SVC是以分层的实现来提供了对不同维度的可扩展支持。具体而言，一个完整的SVC图像流包含了一个Base Layer和多个Enhancement Layer。Base Layer表示这个图像流所能支持的最低视频图像属性的配置，每个Enhancement Layer代表在某个维度上进行的扩展增强支持。
因此，对于最差类型的处理能力和网络状况，可以直接发送一个Base Layer的数据；对于稍好点的接收端，可以发送一个Base Layer和一个或者多个Enhancement Layer的组合；而对于最好配置的接收端，可以把整个完整的SVC图像流发过去，得到最好的回放体验。
编码器所生成的SVC图像流的不同Layer的数据，在发送至中心服务器或者保存到本地文件中的时候，可以通过NALU Header来对不同Layer的数据区分。这样中心服务器在收到数据以后，就能知道这个数据是属于哪个Layer的数据。
Microsoft的UCConfig
微软针对他们的Teams和Skype For Business的认证体系，基于H.264的SVC标准，定义了5种UCConfig工作模式，分别针对不同类型的SVC Layer的可扩展组合，来满足视频会议系统对于SVC的应用需求：
- UCConfig Mode 0: Non-Scalable Single Layer AVC Bitstream.
- 不支持SVC扩展，实际上就是标准的H.264 AVC流。对于不支持SVC模式的H.264编码器的情况，只能选择这种工作模式；
- 这种模式也可以支持在同一个传输流中包含多个不同分辨率的Streaming。即Simulcast。
- UCConfig Mode 1: SVC Temporal Scalability with Hierarchical P.
- 多帧率扩展支持，每一条独立的传输流中包含有针对同一分辨率下的扩展帧率支持。
- UCConfig Mode 2q: SVC Temporal Scalability + Quality/SNR Scalability.
- 在UCConfig Mode 1的基础上，增加了图像质量分层的扩展支持。一条独立的传输流中同时包含了针对同一分辨率的扩展帧率分层支持和扩展图像质量分层支持。
- UCConfig Mode 2s: SVC Temporal Scalability + Spatial Scalability.
- 在UCConfig Mode 1的基础上，增加了多分辨率分层的扩展支持。一条独立的传输流中同时包含有对多分辨率的扩展分层支持和帧率扩展分层支持。
- UCConfig Mode 3: Full SVC Scalability (Temporal + SNR + Spatial).
- UCConfig基于H.264 SVC规范定义的最高级别的扩展分层支持。在同一条独立的传输流中，同时包含了对多分辨率、多帧率和图像质量的扩展分层支持。