CAST-深刻理解并减少视频压缩系统的延迟

在视频的世界，延时是一帧被捕获的时刻和该帧显示时刻之间的时间间隔。对于任何其中有与视频内容的实时交互的系统，如视频会议或无人驾驶试点, 低延迟都是其一个重要的设计目标。

但“低延迟”的含义有所不同，实现低延时的方法并不总是显而易见的。

在这里，我们将定义和解释视频延迟的基本知识，并重点讨论视频编码方式的选择对延时的重要影响。

视频系统延迟特性

要使得照相机捕获的像素在视频显示器上可视，需要有几个阶段的处理。这些处理步骤每个都会引起延迟，以及用于发送压缩视频流所需要的时间，一起产生了总延迟，有时也被称为端至端的延迟。

延时在口头上常用时间单位来表达，例如，秒或毫秒（ms） 。

但是，视频延迟最大的贡献者是需要暂时缓存的数据，。正因为如此，视频系统工程师往往用缓冲的视频数据来计量延迟，例如，两帧或8个水平线的延迟。

把帧转换成时间取决于该视频的帧速率。例如，一个30帧每秒（fps）的视频一帧的延迟等于三十分之一秒（ 33.3ms ）的延迟。

图1：代表1080p30视频流的延迟

将视频线转换成时间需要帧速率和帧大小或分辨率。 720p的高清视频帧有720行水平线，所以延迟一行30fps的是1 /（30 * 720 ）= 0.046ms的延迟。 而1080@ 30fps的，同样的一行延时需要一个非常短的0.030ms 。

关于何为低延时,没有一个绝对值。相反，被认为是可以接受的低延迟会因应用不同而变化。

当人类进行实时视频会议或玩游戏时，延迟低于100ms的被认为是低，因为大多数人察觉不到这么小的延迟。但在一台机器与视频交互的应用中,常见于许多汽车,工业和医疗系统，然后延迟要求要低得多： 30毫秒， 10毫秒，即使是在一毫秒，这取决于系统的要求。

您还将看到这个词适用于视频处理功能和IP内核的超低延迟。这是一个营销的描述不是一个技术性的定义，是的，它只是意味着对于给定应用“真的，真的低延迟” 。

因为在今天的互联而可视的世界，这是司空见惯的。让我们来看看从相机（或服务器）的视频流通过网络到达显示的系统中的延迟。

正如大多数系统的设计目标，实现适当的低延迟的流媒体系统设计需要权衡硬件，处理速度，传输速度和视频质量的最佳平衡。正如前面所提到的，任何视频数据（未压缩或压缩的）的临时存储增加了延迟，因此降低缓冲是一个很好的首要目标。

缓冲视频的大小取决于处理所需要的最少数据。需要缓冲的数据的量可以从几像素到几条视频线，或者甚至整个帧。理解系统设计最大可容忍的延迟，我们可以很容易地计算出系统中所需缓存的大小，从而在做预算及优化延迟时推算出像素，线，或帧的水准。

例如，对于使用1080p30的视频流媒体系统，我们人类目视可接受的最大延迟为100ms，我们从而可以计算通过处理管道的最大允许缓冲如下：

100毫秒/每帧33.3ms = 3帧，或

1080行，每3帧帧x = 3240行，或

每行1920像素× 3240线=620万像素

在这个场景中，我们可以看到，对硬件JPEG编码器的延迟的担心（通常只有几千像素）是无关紧要的，因为它太小无法对终端到终端的延迟产生任何重大的影响。相反，人们应该专注于需要整个帧或大量视频线缓冲的系统节点。

每个设计关注点所获得的代表性结果如表1所示，这从一个精心设计的“低延迟”视频流媒体系统的各个阶段提供了该延迟的分布。这里所有不必要的帧级缓冲已被忽略，整个过程使用硬件编解码器（因为通常软件编解码具有更高的延迟，由于涉及到从OS来的内存传输和任务级别的管理）。

Processing Stage

Buffering

Latency

(1080p30)

CapturePost-Processing

(e.g., Bayer filter, chroma resampling)

A few lines (e.g.8)

< 0.50ms

Video Compression

(e.g. Motion-JPEG,MPEG-1/2/4 or H.264 with single-pass bitrate regulation)

8 lines forconversion from raster scan

A few thousandpixels on the encoder pipeline

0.25ms

<< 0.10ms

Network Processing

(e.g. RTP/UDP/IP encapsulation)

A few Kbytes

< 0.01ms

Decoder StreamBuffer

From a number offrames (e.g. more than 30) to

sub-frame (e.g. 1/2 frame)

from 16ms

to 1sec

Video Decompression

(JPEG, MPEG-1/2/4, or H.264)

8 lines forconversion from raster scan

A few thousand ofpixels on the decoder pipeline

0.25ms

<< 0.10ms

DisplayPre-Processing

(e.g. Scaling, Chroma Resampling)

A few lines (e.g.8)

< 0.50ms

表1, 一个低延迟1080p30的视频流系统的延迟分布。

由于大多数视频流应用中，占主导地位的剩余延迟贡献者是解码器流缓冲区（DSB）。接下来我们将看看这是什么，为什么我们需要，我们如何才能最优地减少它引入的延迟。

在表1的例子中，我们看到DSB可能增加从16ms到1秒的延迟。这种范围依赖于视频流的比特率属性。我们可以控制什么样的属性，以保持此范围的低端DSB延迟？

视频流系统的带宽限制，通常需要调节传输比特率。 720p30视频流例如，可能需要以不超过每秒10兆比特（Mbps）速率被压缩以通过一个速率限制在10Mbps的传输通道。[!--empirenews.page--]

可以合理地假设通过比特率调控后， 产生在每一个时间点是恒定的传输比特率，例如，每帧都是同样的10Mbps的速率。但是，这是不正确的，这就是为什么我们需要流的解码器的缓冲。让我们来看看视频压缩比特率调控如何运作。

视频压缩减少了视频数据的大小，通过使用较少的位来表示相同的视频内容。然而，并非所有类型的视频内容是同样容易接受压缩。在一个给定的帧，例如，平坦的背景部分的图像可以有较少的比特比需要的更详细的前景部分表示。以类似的方式，高速运动的序列比那些与中度或没有运动需要更多的比特。

其结果是，压缩天然会产生可变比特率（VBR）的数据流。随着比特率调节（或比特率控制） ，我们强制压缩产生相同数量的数据流在相等的时间内（例如，每10帧，或每3秒的间隔） 。我们称这种恒定比特率（CBR）视频。它以牺牲视频质量为代价，因为我们实际上是要求压缩引擎分配比特基于时间而不是基于图像本身。

用于定义恒定比特率的平均周期也有着重大的影响，对视频质量。例如， “ 10Mbps” ，可以对应CBR流一个大小为10Mbits每秒，或5Mbits每半秒，或100Mbits的每10秒。进一步重要的是要注意，在该平均周期之内的位速率波动。举例来说，我们可能会平均50Mbps的每5秒，但是，这可能意味着40Mbps的在前两秒和10Mbps 在其余3秒。

正如限定比特率会影响质量，限制平均周期长度也会影响质量，相对越小的平均周期对应越低的传输视频质量。