文 / Tim Siglin
译 / 屈健宁
我们对于为什么视频不能及时、以未压缩的质量交付做出了很多解释。 其中许多解释都是合理的，这些问题主要集中在网络容量或间歇性、扩展低延迟解决方案的成本、甚至局限性的现成处理器实时处理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输出（16x16）矩阵开关的背面也将需要160个BNC连接器，并且这些装置的排列范围高达128x128（很容易达到标准冰箱的大小），以容纳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美元，而48x48视频矩阵交换机的成本约为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中。 ]
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/102513259
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
