作为实时音视频行业，我们对为什么不能零延迟推送视频提出很多理由，其中主要集中在网络容量或间歇性，扩展低延迟解决方案的成本，甚至局限性的现成处理器实时处理 4K Ultra HD 或高动态范围（HDR）内容方面。本文将从根本上分析涉及编解码器本身以及围绕可伸缩流视频出现的打包和分段问题。

文 / Tim Siglin

译 / 屈健宁

原文 / https://www.streamingmedia.co…

我们对于为什么视频不能及时、以未压缩的质量交付做出了很多解释。其中许多解释都是合理的，这些问题主要集中在网络容量或间歇性、扩展低延迟解决方案的成本、甚至局限性的现成处理器实时处理 4K Ultra HD 或者高动态范围（HDR）内容方面。

但是从根本上讲，这个问题比任何一个问题都要深入，涉及编解码器本身以及围绕可伸缩流视频出现的打包和分段问题，这两者都会增加固有的延迟。自 HDS，HLS 甚至 DASH 问世以来，我们中的一些人一直在抱怨这些延迟。向 OTT 实时流传输的转移已将这些延迟或同步性推到了最前沿，正如一位行业同事在 StreamingMedia East 2019 上提到的那样，这种延迟是同步的。

为了更好地解决流媒体的延迟问题，让我们使用这篇文章来探索提供视频和音频的方法，这些视频和音频绝对、肯定地必须在现在就存在 (套用曾经流行的联邦快递(FederalExpress) 口号)。

这不是一个理论上的练习，而是可以在 InfoComm 等贸易展览会上的对话中得到证明的方法，企业正在寻求在本地（通过使用图像放大或 IMAG）提供音视频内容同时还可以远程运作（跨校园或远程学习学生）的无延迟解决方案。

这些受教育程度高的用户，由于操作的复杂性和成本效益的原因，不想部署两种解决方案。这两种方案里，一种是本地交付的零延迟解决方案，另一种是非常低延迟的解决方案—用于远程用户，希望演示者和其本地受众进行交互。

编解码器可以挽救这个问题吗？

在零延迟本地交付用例中，标准的分段打包流式传输方法非常失败，但问题早在打包步骤之前就出现了，并且问题就出现在了音视频流式传输的核心：编码器。不过，这不仅是编码器的问题，因为随着时间的流逝，其中许多问题已经被优化并为我们的行业标准编解码器带来进一步提升。问题的主要部分在于编解码器本身，以及零延迟编码和传送的总体缺陷。

有关实时流编码和交付的讨论通常包括经典的三足凳插图，或者本文的受访者将其所称的决策的“编解码器三角形”。为了使流解决方案正常工作，三个“分支”或三角形“边”必须保持平衡。这三个方面分别是速度，质量和带宽。有些人用“成本”一词代替“带宽”，但都强调一个事实，即带宽越高，消费者和公司的成本就越高。

大规模流传输以节省带宽为前提。这样，对于点播内容，重点则放在速度和质量的交集上以保留带宽。为了在最低带宽下获得最佳质量，视频点播编码器可以花费更多的时间（例如，花费 2 个小时来编码 1 个小时的视频文件）以创建高完成度的产品，为给定编解码器施加相应带宽以使其达到最佳性能。

质量，延迟和带宽的竞争需求在此编解码器三角形中得到了说明。虽然 HEVC 降低了对带宽的需求，但这是以质量和延迟为代价的，因此大多数零帧延迟解决方案都选择了更高带宽的帧内（I 帧）选项，例如基于标准的 Motion JPEG 或内部专用的压缩编解码器 SDVoE。（图片由 SDVoE Alliance 提供。）

为了在有限的带宽上实现保证质量的要求，流媒体行业大量地使用帧间压缩，具体为将一组图片（GoP）聚集在一起并跨时间压缩，然后仅对 GoP 中相邻图像之间的差异进行编码。这些少于总数的图像帧称为 P 或 B 帧；每个 GoP 中的初始帧称为关键帧或 I 帧。

几乎所有帧间压缩解决方案，包括 H.264（AVC）和 H.265（HEVC），都使用 IPB 方法，在节省带宽方面，其效果令人印象深刻。与仅使用 I 帧的方法相比，在许多情况下，使用 P 和 B 帧，在 30-60 帧的单个 GoP 中可以看到多达 70%的聚合带宽节省。

然而，对于实时流传输，使用 P 和 B 帧可能会导致严重中断。回到三足凳，重点转移到了及时编码和交付之上。并且在实时流场景中，速度是最至关重要的，而质量和带宽是次要的。

实际上，为了在零延迟下实现真正的实时编码（我们稍后再定义），计时窗口非常短：以 60fps（例如 1080p60 或 4K60）在相机上拍摄的实时内容需要一帧每 0.016 秒或每 16 毫秒（ms）压缩并传送一次。

甚至还不是全部：虽然必须每 16 毫秒显示一帧，但传输过程和打包过程一样，也需要一些时间才能将编码的视频移动到以太网数据包中以便通过 IP 网络进行传输。这意味着，如果要以零延迟传送视频，则通常必须在传送时间的一半内（即，在 8 毫秒范围内）对视频帧进行编码。

这个问题让我们想起了帧间流视频的致命弱点：P 和 B 帧。由于编码器需要比较 GoP 中的多个帧以节省带宽，因此使用这些 P 或 B 帧会固有地增加额外的延迟。

那么，如何解决速度，质量和带宽（成本）之间的平衡？考虑一下可能是什么，让我们首先研究一个可能需要零延迟的典型用例。

“零延迟”

在现实环境中，任何等待时间都足以引起视觉不适。在某些情况下，我们可能都遇到了视觉上的不适，而且在这种情况下，演示者可能就在观众面前，并且被投影到同一房间的大屏幕上。

如果演示者举起手，并且编码器甚至需要十几个或更多额外的帧来进行编码，结果将是她的动作与投影屏幕上出现的信号之间出现两次一秒的延迟。

更糟糕的是，如果演示者使用的是投影到大屏幕上的计算机，那么如果演示者尝试在大屏幕上使用计算机鼠标进行交互时，可能会导致大约三帧的延迟时间从而让观众出现视觉不适。

因此，既然这会让本地观众和演示者都感到不适，那么为什么要使用完全压缩呢？

在过去的十年中，这是视听（AV）行业提出的论点，因为它试图达到一种技术进步的水平，从而可以在 IP 上以零延迟发送视频信号。零延迟的需求也是导致安装在大型演讲厅，运动场和音乐场所中的几乎所有 IMAG 解决方案仍主要在非打包的点对点解决方案上运行的原因。

AV 行业和流媒体行业都使用术语“延迟”来描述延迟。但是，在流媒体行业使用“低延迟”或“超低延迟”分别描述长达 5 秒的延迟和长达 1 秒的延迟的情况下，视音频行业开始大胆地断言：零延迟。

IP 上的 AV-over 解决方案（例如 SDVoE）允许同步视频数据的多播传输，我们可以将其与基于硬件的窗口和缩放单元结合使用，以在多个同类 HDTV 之间创建单个大视频图像的效果。与传统的视频墙缩放不同，AV-over-IP 解决方案除了端点缩放器外，不需要昂贵的矩阵开关。（图片由 SDVoEAlliance 提供。）

在某些方面，这种“零延迟”参考源于必要性，因为多输入，多输出视频开关（虽然有点类似于老式电话总机，但被称为矩阵开关）能够传递矩阵。在多达 128 个同时输出的配置中，一个或多个输出的输入的延迟时间小于 1ms。

切换开关

这些点对点解决方案在 1990 年代首次起作用的方式是使用五线 RGBHV 电缆，这种五线电缆分别提供三种颜色（红色，绿色，蓝色）和两种类型的图像同步（水平和垂直同步）。但是电缆很贵（每英尺几美金），而且终端是很笨重的 BNC 连接器。即使是一个简单的 16 输入，16 输出（16×16）矩阵开关的背面也将需要 160 个 BNC 连接器，并且这些装置的排列范围高达 128×128（很容易达到标准冰箱的大小），以容纳 1,250 多个单独的 BNC 连接器。

这些 RGBHV（及随后的 HDMI）矩阵开关的优势在于，隔行扫描的内容可以通过电缆完全不延迟地复制。从本质上讲，矩阵开关只是一个非常昂贵的信号增强器和分配放大器的组合，它位于一条长视频电缆的中间，可用于将信号发送到 100 英尺而不会降低信号质量。

这里有一个简短的注释：从 RGBHV 到 HDMI 电缆的切换增加了一点点扭曲，因为 HDMI 内容主要是逐行格式的（帧以单张图像形式呈现），而不是隔行扫描（图像是一系列隔行扫描的奇偶行）。虽然 HDMI 可以支持 1080i 和 1080p，但是 RGBHV 电缆只能支持 1080i。权衡渐进内容（例如 720p，1080p，2160p）意味着需要将术语从零等待时间转变为零帧等待时间。尽管某些解决方案仍要求零等待时间，但是任何渐进式内容都必须传输整个帧而不是一部分帧。

但是，一旦信号需要移到演讲厅之外，就连标准的 RGBHV 或 HDMI 视频电缆也无法使用 - 在某些情况下，例如 100 英尺以上的 HDMI 电缆就不存在了 - 因此，一种新的解决方案是必需的。几年前，从端点到矩阵的交付形式已从昂贵的专用视频电缆过渡到成本低得多的结构化布线。无屏蔽的四对 Cat5e 或 Cat6 电缆，端接至 RJ-45 或以太网连接器（或无屏蔽的双绞线或 UTP），能够传输长达 100 米（m）或 330 英尺的基带视频信号，并且在一般情况下这些都是挺廉价的。

在视频矩阵处切换至 UTP 输入和输出，即使电缆未传送 IP 信号，AV 集成商也可以使用建筑物中现有的铜线 Cat5e 和 Cat6 布线，但即使铜线 Cat6 布线也限于 100m 的传输距离。但是，这种 UTP 布线的使用为从多个教室将视频收集到集中式矩阵交换机提供了可能性。但是基本前提保持不变：点对点输入和输出进入非 IP 视频矩阵交换机。

移动到 utp 导致了一些有意的营销混乱 (比如 AV-overCat5 或 hdbaseT)，因为 IT 专业人士看到了布线，可能会认为这是标准的基于 IP 的视频传输。这种混乱也导致了几年的意外事故，例如，与传统的 PoweroverEthernet(POE) 插口相比，带有非标准功率插孔的 AV- 超 Cat5e 电缆 - 无意中插入了 IT 部门的以太网交换机，并最终被烧坏。

“HDBaseT 并不是满足流媒体需求的解决方案，”Arista 总裁 Paul Shu 说。Arista 是一家为医疗保健，酒店业和其他关键任务垂直市场提供工业计算解决方案的公司。“HDBaseT 旨在解决某些专业 AV 应用程序遇到的距离挑战，这是一种将距离扩展到 HDMI 不能达到的范围的解决方案。”

以太网软件定义视频（SDVoE）联盟主席贾斯汀·肯宁顿（Justin Kennington）解释了对这些 RGBHV 电缆以及后来的 Cat5e 或 Cat6 的结构化布线所交付的子帧交付时间的期望有多么严格：Kennington 表示：“在现有技术能够真正复制其性能之前，我们无法离开舒适，熟悉的矩阵开关。”HDBaseT 矩阵开关可以在数十微秒内[提供视频]，远远低于阈值。人类的感知力。”

SDVoE 的零帧延迟编码器可以缩小输入的视频图像的比例，从而使多个编码器的视频图像可以显示在单个屏幕上。这种多对一显示方案被称为多视图合成，利用以太网传输的优势来消除对昂贵的矩阵交换机的需求。（图片由 SDVoE Alliance 提供。）

根据 Kennington 的说法，财务状况将推动这一趋势 - 他估计，基于 IP 的技术可以满足相同的 UTP 或 HDMI 电缆的框架的零成本要求，48 端口 10G 以太网交换机的成本约为 5,000 美元，而 48×48 视频矩阵交换机的成本约为 59,000 美元。

FPGA 到补救（FPGA to the Rescue）

在流媒体行业开始考虑收益之前至少三年，AV 行业就采用了一种解决方案，即使用现场可编程门阵列（FPGA）来提供大规模并行编码。AptoVision 是一家在封装 FPGA 和以太网物理组件（网络和芯片制造术语方面称为“phys”）方面具有专业能力的公司，开发了如今在视音频市场中称为 SDVoE 的编码技术。

“SDVoE 端到端的延迟大约是 100 微秒或 0.1 毫秒，”肯宁顿说。他指出 SDVoE 是如何与 HDBaseT 的速度相媲美的，同时也允许通过低成本的以太网交换机将内容打包并以 IP 的形式交付，他补充道，“SDVoE 的构建方式是因为这是匹配矩阵交换机的视频性能所必需的。”

考虑到 H.264(AVC)和 H.265(HEVC)在 FPGA 编码方面的进展，流行业中的一些人可能会争辩说，逐帧或 I 帧 avc 或 hevc 可能适用于这些零帧延迟的用例，但专业 AV 集成商认为标准的流视频编解码器不符合用例要求。

“SDVoE 压缩编解码器，如果启用，会增加五行延迟，”肯宁顿说。“在 4KUHD，60 赫兹是 7.5 微秒，即使 I 帧也只有 AVC/HEVC 等等。”

肯宁顿在这方面是正确的，因为 MPEG 编解码器本来就是为跨多个帧节省带宽而设计的，而专为零帧等待时间设计的编解码器则可以对 16ms（或 16,000 微秒）以下的视频进行很好的编码。

IDK Corp.（HQ）执行董事兼专业视听设备制造商 IDKAmerica 首席执行官岩崎良平（Ryohei Iwasaki）进一步解释了为什么市场上不仅仅有基于标准的 MPEG 编解码器的空间，“因为 IDK 认为这些编解码器的用途和目的是不同的，所以在 SDVoE 和 H.264 / 265 之间切换。

岩崎继续说：“我们决定采用 10Gbps AV 解决方案，因为[a] 4K 信号具有 18GB，”他指的是未经压缩的 4K60 8 位视频信号在 14Gbps 范围内的事实，但考虑到 HDMI 通过 HDMI 电缆传输 4K60 信号所需的字位转换（8b/ 10b）。

Iwasaki 说：“我们为将来测试了许多其他编解码器的功能和可扩展性，并且 IDK 认为 SDVoE 可以满足现在的大多数专业视音频客户的需求，因此它是现在可以适用的一种。”

以太网交换机不是在 8b /10b 字位转换中测量的 - 实际上，一个 1Gbps 以太网交换机使用 4b / 5b 并以 1.25Gbps 的速率实际传输，但作为 1Gbps 交换机销售，以避免任何混淆 - 这意味着压缩是相当合理的：使用 SDVoE 方法流式传输的 4K60 8 位信号的亮度（约 1.4：1）。

Kennington 说，SDVoE 在开发 SDVoE FPGA-10G phys 软件包时还考虑了其他编解码器。“当奠定了成为 SDVoE 的基础时，我们确实调查了现有的编解码器（包括 MPEG 和 JPEG 等）。我们发现，它们都以节省带宽的名义做出了太多妥协。”

正如 Kennington 所说：“JPEG 样式的编解码器试图做出与我们相同的折衷方案：降低压缩效率，以换取更好的延迟和 / 图像质量。但是我们发现它们还需要做很多功课。”

然后，Kennington 通过基于 JPEG 的编解码器选项的核心，对这些高分辨率、零帧延迟的用例进行了研究，指出“基于离散余弦变换的原始 JPEG 受到振铃和块伪影的影响。“而且，”他继续说，“基于小波的 JPG2000 有其自身的问题，特别是在高分辨率计算机图形和某些颜色过渡方面，其中亮度相对恒定并且色度正在变化。”

这些亮度和色度问题是某些 DCT 编码方法固有的。实际上，DCT 可以被认为是老旧的方法，因为它距 JPEG 静态图像压缩的出现已有 30 年了。

Kennington 还指出，至少从峰值信噪比（PSNR）质量指标的角度来看，SDVoE 解决方案的性能要优于 JPEG。“我们的 PSNR 编解码器分数通常比 JPEG 更好。”他举了一个例子：“在游艇俱乐部的图像中，我们的分数为 57dB，而所示的最高质量 JPEG 示例为 45.5dB。”

对于要求在选择将哪个视频源发送到一个或多个输出监视器方面具有灵活性的传统 AV 集成，它最主要的成本来自用于管理传入和传出视频信号的昂贵矩阵开关。IP-AV 等解决方案（如 SDVoE）允许从编码器进行多播传输，用成本更低的 10Gb 以太网交换机代替了矩阵交换机。（图片由 SDVoE Alliance 提供。）

尽管 H.264 和 H.265 的命运不一定与 JPEG 相同，但它们确实具有相似之处，这可能使它们不太适合用作 IP over AV 集成市场的高分辨率 I 帧编解码器。

肯宁顿说：“可以对标准化的 MPEG 编解码器进行调整以减少延迟，但这是以图像保真度为代价的，反之亦然。”

廉价的带宽

虽然使用 10Gbps 以太网交换机来实时播放 4K608 位甚至 10 位内容的概念听起来有些过头，但 Kennington 解释了使用编解码器三角形的原因。“在专业视音频中，我们根本不需要优化帧间压缩即可节省的带宽。”他继续指出，大多数 IP 视音频解决方案均以 1Gbps 甚至 10Gbps 的速度运行，而不是标准的 2.5Mbps 或 6Mbps 用于从 Netflix 发送流式视频。

关于 4K60 内容的“相当轻”的压缩（本质上是 1.4：1 的压缩比），肯宁顿还回答了我对数据速率低于 10Gbps 的视频的疑问：“SDVoE 的编解码器甚至不使用压缩除非需要。由于 1080p608 位流每秒只有 3 吉比特，因此我们以原始数据速率传输时没有任何损失。同样适用于 6Gbps 的 4K30。我们仅压缩高于 10Gbps 原始数据速率的信号，例如 4K60。而且，我们只压缩适合 10G 以太网所需的最小压缩量。”

这就自然引起了一个问题，即为什么专业视音频市场已经开始使用 10G 交换机进行视频流传输。毕竟，10G 交换机仍然比 1G 交换机贵得多。Kennington 认为，这一切都归功于 AV 集成商能够可视化“图像质量，延迟和带宽之间的权衡”。

视音频集成中最便宜的部分是带宽，它至少位于一个物理位置（例如学校或大学校园）内。肯宁顿（Kennington）解释说，这就是 AV 与长距离流传输不同的地方：“[n] pro AV，延迟要求基本上是根据具体情况确定的。图像质量要求不断提高 - 更高的分辨率，更高的帧速率，更高的色位深度 - 但是带宽是独一无二的，因为以太网交换机上的带宽越来越便宜。所以我们使用它更优！”

肯宁顿（Kennington）同意在以太网上处理内容的其他方法是有效的，并补充说：“我不敢说 Netflix 并不成功！”但他指出，这些方法“会造成延迟损失并以某种方式损害图像质量。专业视听市场无法轻易接受。”

有妥协方法吗？

IDK 的 Iwasaki 指出，需要在 SDVoE 编解码器的极高数据传输率与将视频流从一个城市或内容发送到另一个城市的典型实时流媒体需求之间达成妥协：“某些客户需要更长的视频流距离，例如从日本到美国的距离。在这种情况下，客户需要使用 [其他] 编解码器（例如 H.264/ 265）来最小化带宽。IDK 也正在为此准备一个可以桥接 SDVoE 和 H.264 的设备。”

Iwasaki 补充说，桥接单元仍然是一个概念，并且为了避免级联问题并保持适当的色彩空间，SDVoE 视频将被解码回基带视频，然后在 H.264 中重新编码以进行标准流传输。

岩崎说：“在今年的 InfoComm 上，我们将拥有一个原型概念编码器，该编码器可以捕获，流式传输来自接收器单元的图像并可以通过管理系统进行控制。这些概念可帮助希望将实时解决方案和实际输出流信号集成在一起的人们。目前唯一的方法是将信号解码到基带一次（在 H.264 和 SDVoE 编码之间）。也许 SDVoE 联盟将来会提供直接的重新编码功能。”

Iwasaki 还指出，现在尚无法在 SDVoE 编解码器中录制演示文稿，并且 SDVoE 联盟的 Kennington 表示 SDVoE 编解码器仅用于实时传输场景。这就是基于标准的编解码器（例如 H.264 或 H.265）可以发挥作用的地方。

Iwasaki 认为：“如果客户希望具有针对这些信号的记录或网络流功能，我们将使用 H.264 / 265，因为它可以通过高压缩率来减少信号的带宽。”

Iwasaki 认为，丢失延迟与录制的内容无关，但是对于高分辨率内容，使用基于 MPEG 的视频编解码器的视频质量丢失仍然很明显。

新的平衡方式？

肯宁顿还建议，对于流媒体行业来说，这可能是一种新的三足凳图。衡量自己在编码和传输方面的适当平衡：“在讨论质量和带宽时，延迟，价格和功耗显得很大。”

要达到零帧延迟，需要大量的计算能力，并且 Kennington 指出，现有的基于标准的 MPEG 编解码器具有价格和功耗问题，而不仅仅是基本的质量和延迟问题。

肯宁顿说：“这些算法的计算复杂度也高得多，这对成本和功耗都有影响，特别是在实时编码器中。我知道的唯一用于实时 HEVC 编码的芯片是 Socionext 的，价格超过 1,000 美元，功耗超过 35 瓦，我们的合作伙伴制造商的端点售价为 1,000 至 2,000 美元。”虽然肯宁顿并不想在这个会议上讲述完整的细节，但是他的确表示过：“在价格和功率上比这个要高出 85%。”

在我们接近尾声的时候，这里有一个提示，即 AV 和流媒体产业正处于平行的道路上。在许多方面，这两个行业仅通过一种稍微不同的语言和围绕特定用例的不同方法而区分开来。

视音频行业对典型的流媒体（尤其是被编码成成千上万个 2 -10 秒 HLS 细分的经典视频点播高级资产）的延迟理解有点缺陷。在像 InfoComm 这样的 AV 行业活动中走到展厅，您经常会听到零延迟支持者谈论按需编码，这种编码需要服务器机架和长达一周的编码时间才能“正确处理”质量编码。

然而，视音频行业相当质疑 H.264 和 H.265 的功效，因为它们均基于 DCT，因此引入了许多问题，发现编解码器在尝试与零帧延迟跳动竞争时会十分被动。

是时候采用一种新的编解码方法了吗？用一个编解码器来处理本地传递的零帧延迟，以及对于非常低延迟的远程传递的可伸缩性？答案是肯定的，“是的”，而我们作为流媒体行业，最好在这个 IP 视频传输的新时代加强我们的游戏，以降低延迟、价格和功耗。

[本文作为“零和博弈”出现在 2019 年 7 月 / 8 月的 StreamingMedia Magazine 中。]