2021年10月12日
By 蒂姆Siglin 特约编辑
专题文章

超越软件:大规模流媒体的硬件处理

我将从写这篇文章时突然意识到的一个问题开始:在我30年的媒体生涯中，我使用过的每一个编解码器都是从基于硬件的编解码器开始的. 尽管这些编解码器很好用，但几乎所有的编解码器最终都变得很“软”.”,, 由于迁移到通用计算平台上的软件, 如今，这些“软”编解码器的效率都要低得多.

除了我职业生涯的头几个月——当我为多媒体幻灯片放映机的机架编程，使其在卷对卷磁带上播放提示音轨时, 在说服我的老板购买Pro Tools 442音频系统之前——我用过的每个媒体设备上的编解码器一开始都是专门的硬件. 这里有一个快速列表，可能是外国的，也可能是怀旧的, 根据你在这个行业工作的时间长短:

我的第一台广播现场摄像机是BetaSX, 使用MPEG-2硬件编码器.
这是我用过的第一台小尺寸相机, 基于索尼迷你dvd的VX1000, 是基于MPEG-2编码器，以适应内容在一个小墨盒.
我的第一台高清摄像机, 使用相同的迷你DV磁带, 是佳能XL2以一种非常奇怪的方式使用MPEG-2编码器编码“几乎1080p”，然后使用硬件解码器将“几乎1080p”外推到实际的1080p来播放.
我使用的第一个视频会议系统, 伦勃朗二世, 有MPEG-2编码器和加密模块吗. (这是MilSpec/国防部的版本, 但我想即使是企业版也有相同的功能.)
我咨询过的所有视频会议系统, 从Polycom到PictureTel再到Lifesize, 使用的硬件编码器, 包括H.261, H.263和H.264编解码器，早在流媒体出现之前. 事实上, 硬件编码器在视频会议中嵌入得如此之深(没有双关语的意思)，以至于我的咨询建议转向软客户端(允许参与者从办公桌加入视频会议的桌面应用程序)，得到的回应在某种程度上相当于比尔·盖茨(Bill Gates)关于不需要超过640KB内存的名言. 换句话说, 硬件代表了现在和未来, 直到苹果推出了基于mac软件的QuickTime视频会议，微软紧随其后推出了基于windows的NetMeeting.
我使用的第一个互联网协议电视(IPTV)编码器都是在asic上运行的MPEG-2硬件(稍后会详细介绍)，可以根据质量调整数百个频道, 带宽限制, 甚至可以在不需要重新启动或重新加载软件的情况下定位目标地理位置.
AV集成解决方案, 这需要零延迟, 所有这些都依赖于硬件进行编码, trans-rating, 为了保持在一个视频区域内而缩放(这是16毫秒), 如果你在记分的话). 直到今天, 当需要在一个给定的房间里设计一个视频矩阵或同步多个监视器时, 主时钟和硬件解码器的组合用于保持需要完美运行数周的设备的一致性, 个月, 甚至是几年.
早期H.264在流媒体中的应用, 一旦MPEG-1和MPEG-2编码转向软件，但仍然无法产生大规模的压缩效率, 需要专用硬件.

这绝不是一个详尽的清单，因为有许多硅基H.265编码器在现场坚固耐用, 无风扇机箱，只使用少量电源来完成编码任务. 我们在过去的文章中已经介绍了其中的一些, 跨越石油和天然气勘探等垂直市场, 远程军事行动, 制造业, 以及汽车行业. 但本文旨在理解专用硬件编码器和解码器的好处，因为它们与现实世界的流媒体和视频传输场景相关.

这也是我和多姆·罗宾逊探索在一年前的一篇文章中提到“流媒体绿化”, 在这篇文章中，我们建议业界在衡量流媒体解决方案的两个标准(价格和性能)之外，再增加第三个P(功率).

无论您是使用云还是混合解决方案来编码您的直播或点播流媒体内容, 高效编码已经成熟. 本文探讨了这些大规模解决方案背后的数学和科学，这些解决方案不仅对业务有益, 但也有好处环境.

软件解决方案

为什么软件如此受欢迎? 简短的回答是它在编程特定于视频的工作流程方面的灵活性, 使用现场可编程计算引擎.

大约在流媒体的第一个十年结束时，H.264编解码器已经优化到足以与通用计算芯片一起工作 (我们称之为cpu)，并很快进行了优化，利用图形处理器芯片(gpu)从单个通用服务器输出更多内容. 但与MPEG-1和MPEG-2不同的是，其中出现了许多高密度的硬件解决方案，这些解决方案适合电信运营的5 - 9模型.999%的正常运行时间)，并允许早期IPTV交付，移动到流媒体与H.264则走向了相反的方向:更多的基于软件的工作流.

这是一个相当典型的模式. 在新编解码器生命周期的头几年, 需要专用硬件将编码时间保持在合理范围内. 但随着编解码器的成熟和功能集的固化, 大多数编码转移到纯软件解决方案，可以运行在通用的cpu和, 如果更多的原料加工是否需要，CPU工作负载可以推到位于同一服务器上的高端GPU上.

然而，这些软件解决方案并不是那么高效, 当然不是大规模的, 消耗了比实际需要更多的处理能力.

这就是高效处理器的奇怪缩写，比如ASIC, DSP, 或者FPGA发挥作用:在规模上, 与标准的cpu和gpu相比，这些处理器以更快的速度和更低的功耗产生更高质量的编码.

为什么是硬件而不是“通用”的基于服务器的云?

稍后我将探讨这些缩写词, 但是，如果你仍然同意我的观点，请看看用于高效压缩的专用硬件, 我相信您一定会有这样一个问题:如果我们都可以访问重要的云百家乐软件，那么这些问题又有什么关系呢?

一个原因是云计算并不是那么高效. 是的, 它在全球范围内全天候可用, 哪一种更方便，意味着实例可以快速地启动并几乎同样快速地删除. 这对于不需要专用硬件的服务来说是完美的, 但它并不是那么完美，因为运行这些实例的通用计算硬件需要保持在始终在线的操作状态，当通用硬件没有满负荷使用时，这种状态会消耗大量的电力.

接下来的问题是，完全产能到底意味着什么, 因为大多数系统架构师认为，当处理器负载或网络接口卡(NIC)的利用率超过60%时，通用服务器的容量就达到了极限. 这是可以理解的, 因为系统架构师必须适应潜在的开销，并希望避免通用服务器的峰值容量阻塞. 但效率不高.

通用的基于服务器的云的另一个问题是，云本身增加了固有的延迟. 本地编码既可以用于本地分发，也可以用于互联网分发, 我们稍后会看到, 具有编码器之间同步的附加好处, 解码器, 以及监控设备.

图1. 以太网上的软件定义视频(SDVoE)零帧延迟编码器可以缩小输入视频图像的规模, 允许多个编码器的视频图像出现在一个屏幕上. 称为多视图合成, 这种多对一显示方案利用以太网传输来消除对昂贵的矩阵交换机的需要. (图片由 SDVoE联盟)

硬件的实际用例

还记得我在文章开头提到的AV集成解决方案吗? 这些都是公司董事会安装的解决方案, 培训中心, 或企业礼堂. 它们也用于娱乐场所, 在需要同步多个摄像头和屏幕的地方，本地显示和实时流的操作条件都不太理想.

当视频必须在数十个监视器之间保持同步时，您可以选择这些硬件解决方案，这些监视器可以从场地的一个有利位置看到. 我正看着你呢, 几个月前，我在冰球比赛间隙观看了当地溜冰场腊肠狗比赛的参与者.)

你可能经历过电脑视频混音器(如.g.(如TriCaster)，甚至软件包(如.g., OBS或Wirecast)有太多的视频延迟帧，既不能用作视频混频器，也不能用作给定场地内图像放大(IMAG)的源. 坐在前排的演讲者举起手臂强调一个观点, 一秒钟之后, 房间里的图像监视器, 无论是平板还是大屏幕, 她举起了手臂.

AV集成解决方案如何解决这种令人不安的视觉延迟? 硬件编码.

有时, 添加压缩, 但是有很多硬件解决方案, 数据路径足够宽——比通用处理器甚至gpu宽得多——本地显示部分不需要压缩.

最好的例子之一是由软件定义的以太网视频(SDVoE)联盟设计和许可的解决方案，用于Black Box提供的各种产品, IDK, 美国网件公司, Semtech, ZeeVee, 和其他人. 我在两年前报道过SDVoE方法，但这里有一个概述.

该解决方案提供零延迟, 通过未压缩的4K UHD高达4:4:2的视频，并为内容添加光压缩以达到HDMI 2的最高水平.0(即全4K 4:4:4 60Hz支持). “我们的压缩编解码器, 当启用, 增加5行延迟,贾斯汀·肯宁顿说, SDVoE联盟主席. “在超高清，60Hz，这是7.5微秒，甚至超过了只有i帧的AVC/HEVC等."

肯宁顿没有提到的是，溶液在携带未压缩的7时也是如此.1的声音, 添加AES-128加密，支持12位色深(这意味着它很容易支持HDR10和HDR10+), 只有10位色彩空间). 所有这些都是在一个预包装的硬件编码器/10Gbps网络接口上完成的，这个接口大约是一副扑克牌的一半大小. 编码器的运行效率如此之高，以至于它不需要流过两个芯片(一个FPGA和一个10G phy)的气流，因此它可以被塞进小的外壳中.

除了, 它可以与六个其他编码器组合在一个机架单元的四分之一的地方. (这些多编码器的典型尺寸约为6英寸深, 这样它们就可以安装在AV机架上，而不是像大多数普通服务器那样需要更大更深的数据中心机架.)

换句话说, 性能和功率效率允许更小, 更冷的设备也可以在等待下一个任务时进入休眠状态. 尝试使用基于几十年前设计的通用服务器.

专用硬件计算引擎的类型

既然我已经讨论了一个实际的用例, 我将在本文的其余部分讨论不同类型的专用硬件.

首先是专用集成电路(ASIC). ASIC有潜力成为流解决方案中最高效、最强大的计算平台, 但这也是最难做到的,“正是因为它是为一组特定的任务而专门建造的. 像这样, 在硅“旋转”或致力于压制/制造之前，要非常小心，因为任何疏忽都可能使ASIC无法用于其预期目的.

业内少数几家公司已经设计并部署了专用的asic. 他们每2-3年旋转一次硅, 但基于这些asic的产品的现场使用寿命很容易达到十年或二十年.

是否有一种方法可以获得类似的计算效率，同时仍然允许可编程性以适应不断变化的需求或新兴的行业标准? 是的，这是以两种不同的片上系统(SoC)方法的形式出现的:dsp和fpga.

NETINT功率降低

图2. NETINT声称在CPU和GPU编码上显著降低了功耗. (图片由 NETINT)

DSP(数字信号处理器)是一种SoC，通常用于处理基带信号, 例如音频或视频基本流, 在工作流程的前一步通过模数转换器(ADC)转换的数据。. 想想智能手机上的麦克风，它将模拟信号输入ADC. 然后由德州仪器(TI)或高通公司的DSP版本进行处理，将其记录到文件中, 作为电话交谈的一部分发送, 或两个.

与dsp合作是一门真正的科学, 高学习曲线限制了它们在非常专业的音频或视频产品中的使用. 大约20年前, 虽然, TI意识到它需要降低为视频压缩编程dsp的障碍, 因此，它开始提供编程接口(通过链接到集成开发环境), 或ide)以及以达芬奇命名的预先许可的音频和视频编解码器.

达芬奇允许程序员专注于在他或她理解的语言环境中编程，并将其与视频架构团队也理解的视频工作流工具联系起来. 当与TI DSP结合时, 其结果是更快地进入市场, 由于达芬奇软件接口和集成编解码器消除了学习如何优化编解码器到DSP平台的需要.

其中一个芯片的例子是数字媒体单片系统(DMSoC) TMS320-DM-368. 它的视频处理子系统能够以30fps的速度实现1080p.264视频处理引擎. 超越编解码器, 虽然, 这个SoC有一个集成的面部检测引擎, 模拟前端, 屏幕上的硬件显示, 以及若干数模转换器(dac)以允许输出到本地监视器. 它还通过4:2:2(8 /16位)接口包含各种颜色深度选项，允许多达16位YCC和24位RGB888.

另一家生产针对流媒体视频市场的dsp的公司是NETINT, 在中国和加拿大都有办事处. NETINT有一个基于dsp的SoC, 叫做netinttg4, 它声称比GPU甚至基于软件的CPU解决方案更高效.

As 图2 显示, SoC方法不仅具有更容易扩展的潜力, 而且这样做的功耗要求要低得多. 更有趣的是, NETINT声称，为CPU或GPU处理设计的FFmpeg工作流可以很容易地移植到使用netint4 SoC.

不过，关于这些说法，我要做一个简短的说明. 而我经营的非营利组织, 帮助我流媒体研究基金会, 在推荐特定的视频引擎之前，通常会在测试台上验证制造商的声明, 我们还没有机会在netinttg4上这样做. 不过，由于NETINT在其网站的主页上显示了这些数据，因此值得与大家分享 流媒体 读者.

说到索赔, 需求方, 和达芬奇, 另一种基于硬件的编码方式是FPGA(现场可编程门阵列)。. 我之前提到的解决方案, 来自SDVoE联盟, 使用FPGA和10Gbps网络接口, 该组织过去曾向我解释说，这样做是出于权力和性能两方面的好处, 因为fpga提供了非常宽的信号处理路径.

在本文的研究过程中, 我在FPGA领域遇到了一个听起来很熟悉的名字:Sean Gardner. 我查看了我的电话联系人，注意到在我做一些事情的时候，德州仪器有一个叫肖恩·加德纳的人早期达芬奇解决方案的基准分析. 所以我很好奇是不是同一个人. 这是, 他不仅停留在视频计算领域, 从dsp到fpga, 但他也为赛灵思的视频解决方案带来了类似的让程序员轻松上手的方法.

赛灵思公司 FPGA

图3. 赛灵思公司提供了两种类型的应用程序编程接口以及一个百家乐软件管理器来处理单个服务器中的多个fpga. (图片由赛灵思公司)

In a conversation with Gardner; his 赛灵思公司 colleague, Aaron Behman; and me, 两人开玩笑说，他们一直认为FPGA中的G应该代表“绿色”，这是基于FPGA解决方案的节能程度. 举个例子，他们让我看了一个关于Alveo U30 Media Accelerator的演示. 再一次。, 我们还没有在“帮助我流”上证实这些说法, 但如果数字是准确的, 他们是令人印象深刻的.

U30是一款半高半长PCIe单槽卡, 这意味着它甚至可以安装在小尺寸的电脑上. U30背后的想法是允许FFmpeg和其他视频工具中的现有工作流利用FPGA解决方案，从主机CPU卸载所有视频处理.

该卡提供硬件集成的H.264 (AVC)和H.265 (HEVC)编码和转码. 满负荷运转, 它消耗25瓦, 所以它与市场上大多数中档cpu的功耗相当. 对于那25瓦, 虽然, U30能够支持一些令人印象深刻的转码数字:2uhd 60 fps (2160p60)或 8个全高清高帧率(1080p60)或16个全高清标准帧率(1080p30)实时转码, 包括ABR缩放.

更有趣的是，赛灵思声称在一台服务器上测试了多达8张U30卡, 能够在单个服务器中生成多达256个720p30转码, 以及大多数配备gpu的服务器无法管理的自适应比特率输出.

加德纳指出，U30“是决定性的从吞吐量的角度来看, 但真正的好处来自于将主机CPU降低到可管理的水平.

“从CPU卸载的角度来看,加德纳说, CPU负载的减少提供了更低的CPU成本, 更好的保暖内衣裤, 在机架层面有更好的经济效益."

换句话说, 通过提高性能和降低整体功率输出, 这种FPGA解决方案提供了一种在不影响环境的情况下扩展流的方法.