当前位置: 首页 > 后端技术 > Python

实现零延迟的视频和音频是一个标准的零和游戏

时间:2023-03-26 13:50:47 Python

作为实时音视频行业,我们提出了很多不能零延迟推送视频的原因,主要集中在网络容量或间歇性,扩展低延迟解决方案成本,甚至是现成处理器在实时处理4K超高清或高动态范围(HDR)内容方面的局限性。本文将从根本上分析编解码器本身和可扩展流视频所涉及的打包和碎片化问题。文/TimSiglin译/曲佳宁原文/https://www.streamingmedia.co...对于视频未按时交付且未压缩质量的原因,我们有很多解释。其中许多解释似乎是合理的,问题集中在网络容量或间歇性、扩展低延迟解决方案的成本,甚至是现成处理器处理4K超高清或高动态范围(HDR)内容的局限性实时。但从根本上说,问题比任何一个都更严重,涉及编解码器本身以及围绕可扩展流视频出现的打包和碎片问题,这两者都会增加固有的延迟。自从HDS、HLS甚至DASH时代以来,我们中的一些人就一直在抱怨这些延迟。向OTT直播的转变将这些延迟或同步性带到了最前沿,正如一位业内同事在StreamingMediaEast2019上提到的那样,这是同步的。为了更好地解决流媒体的延迟问题,让我们使用本文来探索传送视频和音频的方法,这些视频和音频现在绝对、绝对必须存在(套用曾经流行的FederalExpress标语)。这不是理论练习,而是一种可以在InfoComm等贸易展的对话中展示的方法,企业希望在本地(通过使用图像放大或IMAG)交付视听内容,同时也可以远程操作(通过无延迟解决方案)适用于在校或远程学习的学生)。由于操作复杂性和成本效益,这些受过高等教育的用户不想同时部署这两种解决方案。在这两个选项中,一个是用于本地交付的零延迟解决方案,另一个是非常低延迟的解决方案——适用于希望演示者与本地观众互动的远程用户。编解码器可以保存这个吗?在零延迟本地交付用例中,标准的分段打包流媒体方法惨遭失败,但问题早在打包步骤之前就开始了,而且是音频和视频流媒体的核心:编码器。不过,这不仅仅是编码器问题,因为随着时间的推移,其中许多问题都得到了优化,从而进一步改进了我们的行业标准编解码器。问题的主要部分在于编解码器本身,以及零延迟编码和交付的普遍不足。关于实时流媒体编码和传输的讨论通常包括三足凳的经典插图,或者本文的受访者称之为决策的“编解码器三角形”。为了使流媒体解决方案正常工作,三个“分支”或三角形“边”必须保持平衡。这三个方面是速度、质量和带宽。有些人使用“成本”这个词而不是“带宽”,但都强调这样一个事实,即更多的带宽对消费者和公司来说意味着更多的成本。大规模流式传输的前提是节省带宽。因此,对于点播内容,重点在于速度和质量的交集以保留带宽。为了在最低带宽下获得最佳质量,视频点播编码器可以花费更多时间(例如,2小时来编码1小时的视频文件)来创建高品质产品,该产品会施加适当的带宽以获得最佳性能。这个编解码器三角形说明了质量、延迟和带宽的竞争需求。虽然HEVC减少了对带宽的需求,但这是以质量和延迟为代价的,因此大多数零帧延迟解决方案选择更高带宽的帧内(I帧)选项,例如基于标准的MotionJPEG或内部专用压缩编解码器SDVoE。(图片由SDVoE联盟提供。)为了在有限的带宽上实现有保证的质量,流媒体行业大量使用帧间压缩,这涉及将一组图片(GoP)组合在一起并跨时间压缩它们,然后仅相邻图片之间的差异GoP中的图像被编码。这些少于总的图像帧称为P或B帧;每个GoP中的初始帧称为关键帧或I帧。几乎所有帧间压缩解决方案,包括H.264(AVC)和H.265(HEVC),都使用IPB方法,这在带宽节省方面令人印象深刻。在许多情况下使用P和B帧,与仅I帧的方法相比,在30-60帧的单个GoP中可以看到高达70%的总带宽节省。然而,对于实时流,使用P和B帧会导致严重的中断。回到三足凳上,重点转移到及时编码和交付上。而在直播场景中,速度是第一位的,质量和带宽是次要的。实际上,对于零延迟的真正实时编码(我们将在后面定义),计时窗口非常短:摄像机以60fps(例如1080p60或4K60)捕获的实时内容需要每0.016秒一帧,或者每16毫秒(ms)压缩并传输一次。这还不是全部:虽然每16毫秒必须显示一帧,但传输过程与打包过程一样,需要一些时间才能将编码视频移动到以太网数据包中,以便通过IP网络传输。拨动开关这些点对点解决方案在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线缆是不存在的——因此需要一种新的解决方案。几年前,从端点到矩阵的传输形式从昂贵的专用视频电缆转变为成本低得多的结构化布线。端接到RJ-45或以太网连接器(或非屏蔽双绞线或UTP)的非屏蔽四对Cat5e或Cat6电缆,能够传输长达100米(m)或330英尺的基带视频信号,而且通常这些电缆非常便宜。在视频矩阵上切换到UTP输入和输出允许AV集成商使用建筑物中现有的Cat5e和Cat6铜缆,即使这些缆线不承载IP信号,但即使是Cat6铜缆也仅限于100米的传输距离。然而,使用这种UTP布线开启了从多个教室收集视频到集中式矩阵交换机的可能性。但基本前提保持不变:点对点输入和输出进入非IP视频矩阵交换机。转向utp导致一些故意的营销混乱(如AV-overCat5或hdbaseT),因为IT专业人员看到布线并可能认为它是标准的基于IP的视频传输。这种混淆也导致了数年的事故,例如与传统的以太网供电(POE)插孔相比,带有非标准电源插孔的AV-over-Cat5e电缆——无意中插入了IT部门的以太网交换机,并最终烧坏。“HDBaseT不是满足流媒体需求的解决方案,”Arista总裁PaulShu说。Arista是一家为医疗保健、酒店和其他任务关键型垂直市场提供工业计算解决方案的公司。“HDBaseT旨在解决一些专业AV应用程序遇到的距离挑战,它是一种将距离扩展到HDMI无法达到的解决方案。”软件定义以太网视频(SDVoE)联盟总裁JustinKennington(JustinKennington)解释了人们对这些RGBHV电缆以及后来的Cat5e或Cat6结构化布线的子帧交付时间的期望有多么严格:离开舒适、熟悉的环境矩阵开关。”HDBaseT矩阵开关可以在几十微秒内[提供视频],远低于阈值。人类的感知。“SDVoE的零帧延迟编码器可以缩小输入视频图像,使来自多个编码器的视频图像可以显示在一个屏幕上。这种多对一的显示方案称为多视图合成,利用以太网传输优势,消除了对昂贵矩阵开关的需求。(图片由SDVoE联盟提供。)根据Kennington的说法,财务状况将推动这一趋势——他估计基于IP的技术可以满足相同的UTP或HDMI电缆要求。零成本要求框架,一个48端口10G以太网交换机的成本约为5,000美元,而一个48x48视频矩阵交换机的成本约为59,000美元。从FPGA到救援(FPGAtotheRescue)至少需要三年时间,流媒体行业才开始考虑其好处。一种解决方案AV行业在2009年采用的技术是使用现场可编程门阵列(FPGA)来提供大规模并行编码。phys”),开发了现在在AV市场上称为SDVoE的技术。“端到端延迟SDVoE的周期约为100微秒或0.1毫秒,”Kennington说。指出SDVoE如何与HDBaseT的速度相媲美,同时还允许通过低成本以太网交换机将内容作为IP打包和交付,他补充说,“SDVoE的构建方式是因为这与矩阵交换机相匹配。”视频性能所必需的。”考虑到H.264(AVC)和H.265(HEVC)在FPGA编码方面的进展,流媒体行业的一些人可能会争辩说逐帧或I帧avc或hevc可能适用对于这些零帧延迟用例,专业AV集成商认为标准流视频编解码器不符合用例要求。“如果启用SDVoE压缩编解码器,则会增加五行延迟,”Kennington说。“在4KUHD中,60Hz是7.5微秒,甚至I帧也只是AVC/HEVC等。”Kennington在这方面是正确的,因为MPEG编解码器本质上旨在节省多个帧的带宽,而设计用于零帧延迟的编解码器可以编码视频远低于16毫秒(或16,000微秒)。IDKCorp.(总部)执行董事兼专业视听设备制造商IDKAAmerica首席执行官RyoheiIwasaki进一步解释了为什么基于标准的MPEG编解码器在市场上有更多空间,“因为IDK认为secodecs路由器的用途和用途不同,因此在SDVoE和H.264/265之间切换。Iwasaki继续说:“我们决定采用10GbpsAV解决方案,因为[a]4K信号有18GB,”他说,指的是未指定压缩的4K608位视频信号在14Gbps范围内的事实,但考虑到位-HDMI通过HDMI电缆传输4K60信号所需的位转换(8b/10b)。Iwasaki说:“我们为未来测试了许多其他编解码器的功能和可扩展性,IDK认为SDVoE可以满足当今大多数专业AV客户的需求,因此它是现在可以应用的。”以太网交换机没有在8b/10b位转换中测量-事实上,1Gbps以太网交换机使用4b/5b并且实际上以1.25Gbps传输,但作为1Gbps交换机销售以避免任何混淆-这意味着压缩是相当合理的:亮度(大约1.4:1)对于使用SDVoE方法传输的4K608位信号。Kennington说,SDVoE在开发SDVoEFPGA-10Gphys包时还考虑了其??他编解码器。”在为SDVoE奠定基础时,我们确实调查了现有的编解码器(包括MPEG和JPEG等)。我们发现他们都以节省带宽的名义做出了太多的妥协。“正如Kennington所说:“JPEG风格的编解码器试图做出与我们相同的权衡:降低压缩效率以换取更好的延迟和/或图像质量。但是我们发现他们还需要做很多功课。Kennington随后通过基于JPEG的编解码器选项的核心检查了这些高分辨率、零帧延迟的用例,并指出“原始的基于DCT的JPEG存在振铃和块伪影”。“而且,”他继续说道,“基于小波的JPG2000有其自身的问题,特别是在高分辨率计算机图形和某些颜色过渡中,其中亮度相对恒定而色度正在变化。”这些亮度和色度问题是某些DCT编码方法所固有的。事实上,DCT可以被认为是一种古老的方法,因为JPEG静止图像压缩问世已有30年了。Kennington还指出,SDVoE解决方案优于JPEG,至少从峰值信噪比(PSNR)质量指标的角度来看是这样。“我们的PSNR编解码器分数通常优于JPEG。”他举了一个例子:“在游艇俱乐部图像中,我们得分为57dB,而显示的最高质量JPEG示例为45.5dB。”对于请求传统的AV集成可以灵活地选择将哪个视频源发送到一个或多个输出监视器,其大部分成本都花在了用于管理输入和输出视频信号的昂贵矩阵开关上。IP-AV(如SDVoE)等解决方案允许从编码器进行多播传输,用成本更低的10Gb以太网交换机取代矩阵交换机。(图片由SDVoE联盟提供。)虽然H.264和H.265不一定与JPEG命运相同,但它们确实有相似之处,这可能使它们不太适合作为IPoverAV集成市场的高分辨率I框架编解码器。“可以对标准化的MPEG编解码器进行调整以减少延迟,但这是以牺牲图像保真度为代价的,反之亦然,”Kennington说。尽管使用10Gbps以太网交换机实时播放4K608带宽便宜1位甚至10位内容的概念听起来有些过分,但Kennington解释了使用编解码器三角形的原因。“在ProAV中,我们根本不需要通过优化帧间压缩来节省带宽。”他接着指出,大多数AVoverIP解决方案以1Gbps甚至10Gbps的速度运行,而不是用于从Netflix发送流媒体视频的标准2.5Mbps或6Mbps。关于4K60内容的“非常轻”压缩(基本上是1.4:1压缩比),Kennington还回答了我关于数据速率低于10Gbps的视频的问题:“SDVoE的编解码器甚至不使用压缩,除非需要。因为1080p608比特流只有3千兆每秒,我们以原始数据速率传输时没有损失。这同样适用于6Gbps的4K30。我们只压缩高于10Gbps原始数据速率的信号,例如4K60。并且,我们只压缩所需的最小压缩量适合10G以太网。”这自然引出了一个问题,为什么专业AV市场已经开始使用10G交换机进行视频流传输。毕竟,10G交换机仍然比1G交换机贵得多。根据Kennington的说法,这都归功于AV集成商能够“可视化”图像质量、延迟和带宽之间的权衡。”AV集成中成本最低的部分是带宽,它至少是一个物理位置(例如学校或大学校园)。Kennington解释说,这就是AV与长距离的不同之处-distancestreaming:“[n]proAV,延迟要求基本上是个案。对图像质量的要求不断提高——更高的分辨率、更高的帧速率、更高的色位深度——但带宽是独一无二的,因为它在以太网交换机上变得越来越便宜。所以我们最好使用它!”Kennington同意以太网处理内容的其他方法是有效的,并补充说:“我不敢说Netflix不成功!”但他指出,这些方法“造成延迟惩罚并以某种方式妥协画质。亲AV市场不能轻易接受。”有没有妥协的办法?IDK的Iwasaki指出,需要在SDVoE编解码器的极高数据速率与将视频流或内容从一个城市发送到另一个城市的典型实时流媒体需求之间做出妥协:“一些客户需要更长的视频流距离,例如从日本到美国。在这种情况下,客户需要使用[其他]编解码器(例如H.264/265)来最小化带宽。IDK还为此和H.264准备了SDVoE的桥梁。”Iwasaki补充说,桥接单元仍然是一个概念,为了避免级联问题并保持适当的色彩空间,SDVoE视频将被解码回基带视频,然后在H.264中重新编码以用于标准流媒体。“在今年的InfoComm,我们将拥有一个原型概念编码器,它可以从接收器单元捕获、传输图像并通过管理系统控制它们,”Iwasaki说。“这些概念有望为集成方案和实际输出流的人们带来实时解决方案信号。目前唯一的方法是将信号解码一次到基带(在H.264和SDVoE编码之间)。也许未来SDVoE联盟会提供直接重新编码的能力。Iwasaki还指出,目前尚无法在SDVoE编解码器中录制演示,SDVoECon??sortium的Kennington表示,SDVoE编解码器仅针对实时传输场景。这就是基于标准的编解码器(例如H.264或H.265)可以发挥作用的地方。Iwasaki认为:“如果客户希望对这些信号进行录制或网络流传输功能,我们将使用H.264/265,因为它可以通过高压缩比降低信号的带宽。据Iwasaki说,延迟损失是与录制的内容无关,但使用基于MPEG的视频编解码器的视频质量损失对于高分辨率内容仍然很明显。平衡的新方法?肯宁顿还建议,对于流媒体行业,这可能是一种新的三者-世界的腿凳图。衡量编码和传输的正确平衡:“在讨论质量和带宽时,延迟、价格和功耗显得很重要。“实现零帧延迟需要大量的计算能力,Kennington指出,现有的基于标准的MPEG编解码器存在价格和功耗问题,而不仅仅是基本的质量和延迟问题。Kennington说:“这些算法的计算复杂性也高得多,这对成本和功耗有影响,尤其是在实时编码器中。我所知道的用于实时HEVC编码的唯一芯片是Socionext,它的成本超过1,000美元,功耗超过35瓦,我们的合作伙伴制造商以1,000到2,000美元的价格出售端点。虽然Kennington不想在这次会议上详细介绍,但他确实表示,“就价格和功率而言,它比那高出85%。”“当我们接近尾声时,这里有一个迹象表明AV和流媒体行业正走在平行的道路上。在许多方面,这两个行业只是通过略有不同的语言和围绕特定用例的不同方法分开。”区分。AV行业对典型流媒体延迟的理解(尤其是编码成数千个2-10秒HLS片段的经典视频点播高级资产)有点缺陷。在像InfoComm这样的AV行业走进活动的陈列室,您会经常听到零延迟支持者谈论按需编码,这需要服务器机架和长达一周的编码时间才能“正确”进行高质量编码。然而,AV行业对H.264和H.265的功效持怀疑态度,因为它们都基于DCT,因此引入了许多问题,发现编解码器在试图与零帧延迟抖动竞争时相当被动.是时候采用新的编解码器方法了吗?一种用于本地交付的零帧延迟的编解码器,以及用于极低延迟远程交付的可扩展性?答案是肯定的,“是的”,我们作为流媒体行业更好地在这个IP视频传输的新时代加强我们的游戏,以减少延迟、价格和功耗。[本文以“零和游戏”的形式出现在StreamingMediaMagazine2019年7月/8月号。]