互动场景下的低延迟编码技术

本文由上海交通大学教授宋利在LiveVideoStackCon2020线上峰会的演讲内容整理而成，从分析视频传输系统延迟入手，详细介绍视频编码延迟的产生机制，总结优化编码延迟的技术手段和业界典型的低延迟编码方案，讨论不同场景的延迟要求，并对后续技术演进发展方向进行展望。

本次分享的主题是互动场景下的低延迟编码技术，内容分为四个方面：一是互动媒体服务；二是低延迟视频编码技术；三是低延迟编码方案；四是应用场景和发展趋势。

01 PART 互动媒体服务

1.1 视频媒体形态

如图所示，我们将现有典型的视频相关服务按照高通量、强交互两个维度进行划分，其中横坐标表示高通量，纵坐标表示强交互，一些典型的视频映射到图中分布于不同的位置。 左下角部分可以称为基本视频，它涵盖了当前的一些主流应用，包括TV、视频监控、视频会议以及多人视频游戏等，其特点是以二维视频为主，同时交互形式包括单项、双项和多人交互。 如果从这个区域往外扩展，外面一层是可以称之为增强视频，沿高通量维度由高清向超高清、自由视、点云、光场过渡，交互维度包括仿真训练、电竞，两者都演进的方向是VR、AR，最后演进到全触感，也就是视频媒体形态正在由基本视频向增强视频演进，这两个维度某种程度和现在5G中两个维度很契合，高通量对应大带宽，强交互对应低延迟。

这张图显示了流媒体视频的典型服务场景，流媒体服务经过多年的发展，现在已经形成一个比较完整的技术和生态链，从源端、云端、边端到终端，包括背后的技术体系也相对比较趋同。现在经常使用的是以RTMP代表加H.264进行源端的推流，到CDN边缘上通过265，包括下行的HLS协议转换，形成流媒体服务的基本流，然后用户侧通过播放器从源端进行拉流，获得流媒体直播的体验。这套架构基本上比较成熟和完善，各家公司的竞争点主要体现在用不同的编码器进行替换，不同上下行协议的改造，以及CDN资源的部署，以此获得竞争优势。从整个媒体服务形态变化的角度看，大部分的努力是针对前面提到的通量这个维度。

图中展示了流媒体实时交互演进的一个典型示例，在直播场景下，通过手机小屏发出交互指令，可以在大屏播放时产生交互的反馈，获得一些个性化的体验；比如在下行过程中发起用户指令，叠加符合正在播放内容的、个性化渲染特效。在这种场景下，整个流媒体架构就会发生变化。在此之前是在云端、边端进行处理，与终端并没有太多交互，技术要素变化不大；但是增加互动维度后，在边缘侧就可以引入很多新的要素。

1.2 系统组成要素

构建一套实时的流媒体系统需要对系统中多个方面进行改进，除了视频编码标准外，媒体传送协议和视频渲染技术都需要实时化和低延迟处理。视频编码方面，低延迟编码技术可以和多种编码标准进行结合。 1.3 互动媒体服务系统的权衡

互动媒体服务系统与单点技术不同，需要考虑多方面因素的权衡。首先要满足低延迟，否则影响互动效果。其次是高体验，互动媒体是在现有媒体上叠加的效果，所以体验是也应该是叠加式的，不能因为互动而使原有基础视频的画质下降。最后是用户的大规模，与视频会议系统不同，一场会议很少会出现超过千人级的规模，但在互动流媒体场景下，由于接近直播流媒体，它的用户数量会比较多。

02 PART 低延迟视频编码技术

2.1 视频编解码

第二部分介绍了低延迟视频编码的共性技术，这些技术可能会用在不同的编码方案中。视频编码器有几大阵营，在分发域有：H.264/HEVC/VVC、AVS2/AVS3、VP9/AV1，在分发域中压缩性能是它的主要驱动力。在制作域有：TICO/JPEG-XS、JP2K、LLVC、XAVC、ProRes，这些编码器虽然是应用于视频中，但从技术角度来说更多是图像编码器。

将两大类编码器放在一起，更容易看出彼此之间的差异性，图中展示了五个维度，分别是：高压缩比、低延迟、低复杂度、高质量、平台友好性。将五个维度进行比较，分发域的编码如图所示，它的特点是高压缩比，但延迟和复杂度比较大，质量没有制作域那么高，相对来说压缩比就比较大。

帧内标准如JEPG、JPEG2K、XAVC、WebP，在延迟性和复杂度方面要好些，但代价是压缩比要差些，因为它应用的是专业领域场景，所以质量和码率比较高。

JPEG XS 是JPEG阵营过去两年推出的一个标准，强调复杂度和速度，它的性能在低延迟、低复杂度方面表现比较优秀，但压缩比较差。由图可知，要根据不同应用场景做出均衡性选择。

2.2 编码延迟的构成

编码延迟是指从视频单元（通常是帧）采集到编码完成生成码流所消耗的时间。公式中的max是表示以编码单元中花费时间最大的模块为延迟时间。

编码延迟的来源主要包括三部分：一是视频帧参考关系，二是编码流水线的设计，三是编码模块的复杂度。

2.2.1 低延迟参考结构

左图展示的是HEVC RA模式，典型的编码器一般使用双向B帧，在提高压缩率的同时会带来帧重排序延迟，在HEVC的典型RA模式中，双向参考关系额外引入了3帧延迟。 右图展示的是HEVC的LDP模式，如果只考虑延迟，HEVC的LDP模式只使用P帧，适用于低延迟场景，其单向参考关系不引入额外的延迟，但是带来了9%~42%的编码性能损失。 2.2.2 低延迟编码帧结构

周期性帧内刷新（PIR）编码结构是在LDP模式的基础上进一步降低延迟，被很多商业编码器所支持，被称为超低延迟的编码配置。 如图所示，它的原理是将一帧切成四个纵向的条块，每隔四帧就可刷新一遍。 它的特点主要有：一是常用的超低延迟配置模式，输出码率平缓，缓冲区溢出概率小。二是可以确保在一个刷新周期内完全恢复错误。三是刷新的频率方向，可以根据视频内容进一步优化。 2.2.3 编码流水线优化

编码器的整体架构决定了编码器的延迟和并行度，主要分为三种：帧处理、块处理、条处理。

帧处理是指对每个运动估计进行预测，编码器处理的模块是以帧为单元的，它会将整帧运动估计处理完，再进行运动补偿，在MPEG2这种比较简易的编码器中经常使用这种结构。

块处理相当于单线程参考编码器中的小逻辑，将每个CTU或每个宏块逐步推送到运动估计、预测等部分，X-循环是指每个块里会进行不同模式的选择，是不同模式的循环。Y-循环是指所有的块可以再循环一遍。其中每块中的宏块可以独立输出，不需要等整个帧处理完，所以它的好处是输出粒度小。但如果将块级的编程变成高并发、流水化结构就比较困难，因为粒度小，想做到流水化结构，处理单元要足够多。需要说明，编解码上下文很关键，切断上下文则编码预测性能会受到大的影响。

条处理是基于两者之间的处理，每一个内循环的粒度是以条块为基础，外循环是不同条块之间流水化推进。同时，运动估计和运动补偿耦合比较好适合于整体计算，可以将运动估计和预测放到一个计算单元上，其余的部分组合到另一个上，这样可以增加多级流水的处理。 这三种处理方式属于任务级分解，也是并发、并行化操作。此外，还有数据级分解，就是数据被切割并分配给不同的处理器。右图是在处理4K时可以切成多个高清进行处理，可以用到四种方案：帧级并行、slice级并行、tile级并行、波前并行处理。在实际的编码中，并发、并行化操作中任务级分解和数据级分解是混合使用的。 2.2.4 低延迟并行码率控制

一旦变成并行流水化，除了各个基本模块的调度，还要涉及整体码率控制的调整。码流的平稳程度是影响编码缓冲区延迟的重要因素，缓冲区上溢会造成数据丢失；缓冲区下溢会造成编码器无法得到数据，进而使得视频卡顿。在条/块级并行编码方案中，码率控制模型需要重新优化设计。 2.2.5 编码模式快速预测

第三个方面涉及编码中各个模块的复杂度，当代编码器的编码模式比较多，组合量比较大，即使每种编码模式足够快也不行，核心在于如何快速的在众多候选模式中选出准确的哪个，这就需要根据某种属性快速做出决策。这时深度学习的方法可以发挥作用，近期我们的一个工作中，采用基于深度学习预测CU划分和基于统计学习预测PU模式组合，替换高复杂度的递归编码探索，实现在性能基本保持不变前提下实现复杂度的显著降低。

03 PART 低延迟编码方案

3.1 SVT构架

这部分介绍一些典型的系统编码方案，首先是英特尔开源的SVT架构，它支持了前面所提到的很多要素，设计比较不错。 SVT构架细节

SVT架构是基于软件的视频编码优化框架，通过联合前处理-编码内部算法，实现性能-延迟-质量的三维优化，并针对Xeon处理器进行优化。 之所以称SVT为三维并行架构，因为它解耦视频分析、模式选择与编码，实现进程级并行；分层GOP内的帧级并行；将一帧图像分为不同条块，实现条块级并行。 SVT也照顾到速度和码率的主观质量优化，对于速度方面的主观质量优化有：首先根据整体复杂度目标，设置搜索的划分模式集合；其次根据块的HVS重要性进行区分；对于码率方面的主观质量优化有：一是根据HVS重要性调整QP偏置；二是降低人眼不敏感区域变换域高频分量。 3.2 H.265低延迟方案

SVT支持很多个编码器，以SVT-HEVC为例，它支持了13个preset（M0~M12），在速度和视觉质量之间实现了较好的权衡。其次，采用客观质量模式（默认）用于权衡速度和客观质量的关系，性能和速度优于x265。而且，最快档次的延迟在百毫秒级别，压缩比在300：1左右，配合其他低延迟技术可以降为小几十毫秒级别。

这部分介绍了H.265低延迟方案的硬件编码器，首先，NETINT基于自研芯片设计了Codensity T408视频转码器，在ASIC中进行复杂的编解码算法处理，从而最小化主机CPU的使用率，编码延迟约为5ms。 其次，NVIDA基于GPU设计了NVENC编码器，可以大幅度释放CPU和内存的负载压力，编码延迟约为3-10ms。 3.3 H.264低延迟方案

前面的两个方案主要面向云端的转码、流媒体服务等，还有一类是面向移动终端的，除了低延迟之外，对功耗、复杂度要求更严格，在这种场景下使用比较多的方案是基于H.264。H.264标准已经被工业界广泛认可和应用，其作为H.265的上一代标准，本身的编码复杂度相对较低，现有低延迟方案大都基于硬件设计。 左图是TPCast方案，它使用CAST公司的H.264-E-BPF IP核编码器，基于H.264 Baseline Profile设计。而且采用CAVLC选项降低熵编码复杂度，并采用帧内刷新技术降低比特率峰。它的编码延迟为10ms级别，压缩率为50：1。 右图是HHI方案，它基于H.264 Baseline Profile设计，采用Intra（16×16和4×4）和VLC编码（不使用CABAC），编码延迟为宏块行级，压缩率为10：1~20：1。两种方案应用的场景不同。 3.4 JPEG-XS低延迟方案

JPEG-XS低延迟方案是更低延迟的方案，它支持Main、Light、Light-subline、High这4种配置编码延迟为毫秒甚至微秒级，视觉无损情况下的压缩率为2：1~6：1，是一个简化的帧内压缩技术。 它的编码过程有：样本拉伸、DC偏移量去除、可逆颜色变换、小波变换、预量化、常规量化、熵编码。JPEG-XS主要是由IntoPIX公司推动的。 3.5 新型的低复杂度/低延迟编码方案

以V-Nova为代表介绍一下新型的低复杂度/低延迟编码方案，V-Nova P+立项的MPEG5-LCEVC标准，为内容分发域提供高压缩率、低复杂度方案。

左图所展示的编码结构类似于可伸缩编码SVC，分为基本层和增加层，网络带宽的适应性不是其考虑重点，而是考虑终端的兼容性以及复杂度，面向内容分发域。可以应用的场景如当手机上有一块硬解码能力的芯片，支持264 HD，如果传来一个4K的内容，利用这种方案可以进行分层，基本层利用264 HD，增强层用HEVC 4K编码，这样基本层可以使用手机的硬解码264 HD能力，而增强层可以使用复杂度比较低的软件能力，将其进一步增强解码提升到4K。

除此之外，V-Nova公司也正在SMPTE的制作域中推VC-6，主要用于专业的内容制作和影像应用。它的卖点是结合了机器学习技术和优化的码率控制，使用intra-only配置，编码延迟为80ms，编码的HD流为60Mbps。

04 PART 应用场景和发展趋势

4.1 应用场景

图中展示的是不同延迟量级对应的应用场景的划分，低延迟要与不同场景进行耦合，不同场景对延迟量的要求不同。图中横轴表示编码延迟，根据延迟时间将场景分为四种，纵轴表示压缩比。

秒级延迟场景以赛事直播为例，它对编码延迟要求并不高，之前一般采用H.264实时编码，对4K或8K视频开始使用H.265或AVS2编码标准实时编码。 百毫秒级延迟场景如视频通信、无线投屏，视频通信可接受的端到端延迟为~200ms。以ZOOM为例，它采用了H.264标准编码，编码延迟为11ms（720p），端到端延迟要求低于150ms。无线投屏以Miracast为例，它认证的无线设备端到端延迟不超过250ms，使用H.264和H.265（可选）标准，编码延迟约10~100ms。

十到一百毫秒级别称之为十毫秒级延迟场景，以云VR、云游戏为例，一般端到端延迟低于100ms时才能获得良好的体验。 NVIDA GeForce Now使用NVENC硬件编解码器可实现3-10ms的编码（H.265）和解码延迟，端到端延迟约75ms。 Google Stadia采用H.264和VP9编码标准，端到端延迟约130ms。

毫秒级延迟大多数场景不超过10毫秒，应用领域涵盖远程制作、数字孪生、高级XR等，往往同时需要非常高的视频质量和超低延迟，需要TSN/TTE（时间敏感/触发）类的基础网络架构支持，目前可选择的有JPEG-XS、SMPTE无压缩的解决方案，压缩效果还不太好，所以高压缩比下的超低延迟编解码仍然存在巨大技术挑战。 4.2 发展趋势

近期在多视角、自由视方面，华为、优酷、咪咕都做过一些示范应用，即将原先导播切换的自由度传送到用户侧，由用户进行发送，用户在观看流媒体视频中可以根据自己的喜欢进行视角的切换，以实现媒体服务的个性化。

以游戏类和远程操控类为代表的场景，以往观看流媒体是被动接收，现在大小屏都可以进行实时性交互，因此互动体验增强，这也是互动媒体发展的趋势。

本次分享主要介绍了低延迟互动媒体服务中的低延迟视频编解码环节的相关技术。要做到较好的低延迟互动媒体服务，还需要低延迟传送协议、实时图像渲染以及基础ICT网络技术整体的演进。就编码而言，需要结合平台特性重构编码实现架构，细化编码各工具性能与延迟关系。 比较理想的做法是面向不同延迟的弹性编码方案，如右图所示，将RD曲线按照延迟-压缩比的关系，形成一套根据场景需求进行弹性配置的编码框架，这是近期低延迟编码努力的方向。