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

文 / 宋利

整理 / LiveVideoStack

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

互动媒体服务

1.1 视频媒体形态

如图所示，我们将现有典型的视频相关服务按照高通量、强交互两个维度进行划分，其中横坐标表示高通量，纵坐标表示强交互，一些典型的视频映射到图中分布于不同的位置。

左下角部分可以称为基本视频，它涵盖了当前的一些主流应用，包括TV、视频监控、视频会议以及多人视频游戏等，其特点是以二维视频为主，同时交互形式包括单项、双项和多人交互。

如果从这个区域往外扩展，外面一层是可以称之为增强视频，沿高通量维度由高清向超高清、自由视、点云、光场过渡，交互维度包括仿真训练、电竞，两者都演进的方向是VR、AR，最后演进到全触感，也就是视频媒体形态正在由基本视频向增强视频演进，这两个维度某种程度和现在5G中两个维度很契合，高通量对应大带宽，强交互对应低延迟。

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

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

1.2 系统组成要素

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

1.3 互动媒体服务系统的权衡

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

低延迟视频编码技术

2.1 视频编解码

第二部分介绍了低延迟视频编码的共性技术，这些技术可能会用在不同的编码方案中。视频编码器有几大阵营，在分发域有：H.264/HEVC/VVC、AVS2/3、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模式组合，替换高复杂度的递归编码探索，实现在性能基本保持不变前提下实现复杂度的显著降低。

低延迟编码方案

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+立项的MPEG 5--LCEVC标准，为内容分发域提供高压缩率、低复杂度方案。

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

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

应用场景和发展趋势

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 发展趋势