全能媒体机—Matrix in Media?

摘要：

本文总结了发表在IBC2018上，由英国Streampunk Media Ltd.的R. I. Cartwright和美国Gilmer＆Associates Inc.的B. Gilmer撰写的“The Infinite Capacity Media Machine”，介绍了全能媒体机(具有无限的计算-存储-传输能力的理想媒体机器)的概念以及敏捷媒体蓝图计划，并分析了当前系统的性能以及未来的工作方向。

云计算的快节奏发展正在推动将应用于专业媒体制作的新型机器的发展。无服务、分布式、集群和GPU加速，云适应架构的本质正在改变软件和服务的模式和设计。是否有可能将现有媒体架构的高度顺序性、线路定时架构转变为随机、消息驱动和异步云？从可扩展以实现个性化生产的平台中出现了哪些可能的新创意？

如果我们在网络，存储和计算方面拥有无限的性能，媒体机将被如何构建？这种机器的设计和构建它的计划以Agile Media Blueprint（敏捷媒体蓝图）的形式介绍，并呈现了在视频数据的背景下，全能的理想概念相关的当前系统的性能测量和分析。

引言

在大数据和社交媒体等趋势的推动下，信息技术的综合应用正在迅速发展。根据首选模型（例如摩尔定律，Gilder定律），网络、计算性能和存储容量（带宽和容量）每六个月到三年翻一番。同时，软件开发和云的趋势正在重新组织计算资源的配置和访问方式，超越单个计算机的边界，以开发大规模并行图形处理单元（GPU）和计算集群。

正在根据IT趋势规划其未来技术平台的媒体公司需要考虑部署时可用机器的潜在性能。IT技术的性能提升率是否超过了媒体质量的数据速率的增长速度，甚至超过了从SD到HD到4K到8K具有更高的帧速率和更高的色彩深度的趋势？如果是这种情况，应考虑理想主义机器，其能够处理所需的任何媒体数据，适用于任何给定的工作流程并且使用趋于零的时间，在此称为全能媒体机。

本文首先从媒体格式、网络、计算和存储方面描述全能媒体机。利用当今可用的技术，引入了敏捷媒体蓝图[1]——一种如何在今天建立这种机器的技术计划。为了测试从通用信息技术（IT）到理想机器的道路有多远，我们使用商品网络传输的媒体数据的一些测量，用GPU处理并由集群内存缓存管理。然后分析理想工作和全能之间的差距，描述未来建立机器的工作并缩小差距。

全能媒体机

在本节中，将研究全能机器的各方面性能，包括视频格式、视频传输、处理和存储方式。

格式考虑

本文主要关注关于无压缩媒体格式的创建、处理和存储，以完整质量信号替换基带信号，而无需牺牲媒体质量以节省比特率。在许多当前的媒体工作流程中，压缩具有克服传输瓶颈和存储容量问题的优点。但同时，压缩增加了延迟、复杂性及能源消耗。假设性能无限，本文主张无压缩格式是更可取的。

此外，无压缩格式在并行处理环境中具有显著优势。图像很好地分成像素的子阵列，并且每个区域可以同时工作。将图片分割成串行移动的连续线序列可能降低传输延迟。无压缩方法可以省去打包、解包、数据复制和转换过程，尤其是当整个处理流程中使用通用的无压缩格式时。

也就是说，在实现全能媒体机的设计时，应该在增加业务价值的地方应用压缩。例如，降低相对低价值材料的长期存储成本。本文假设的是，如果可以在第一个事项中进行无压缩工作，则可以应用成本函数来在稍后阶段通过压缩来优化工作流。

传输架构

想象媒体工作流程为旅程，包括将一系列图片从位置A移动到位置B。如何从A到B取决于交通类型：

1. 像铁路一样，建造从A到B的轨道和运行列车，每个车厢都是图片的一条线。任何时候只有一列火车可以在轨道上运行，需要时间表、信号和管理，以及弹性所需的备用容量。从A到B，铁路网络快速高效。但是，添加新位置需要大量计划和成本。
2. 像道路网络一样，A和B之间存在许多不同的路线，并且每一帧或帧的一部分携带于单独的自动驾驶车辆中。通过卫星导航和实时交通报告，车辆各自找到自己的最佳路线，并且在没有整体拥堵的情况下，图片的各部分将全部及时到达。大多数地点都先发制人地连接到道路网络，弹性通过冗余路线和及时重新发送任何缺失的部分。

列车网络相当于专用的点对点媒体架构，如SDI架构和使用托管网络的IP等价架构，如SMPTEST2110。

道路网络就像一个通用的计算机网络，许多云平台的优化支持更像道路的互联网架构。虽然铁路提供快速、高效、可靠的交通方式，但公路网提供了高度的灵活性和个体选择。

如果所有图片都及时到达，传输方式是否重要？如果在自我优化道路网络中，图片不按时间表（例如实时状况）运行导致内容提前到达怎么办？由于全能性，即高速且无拥堵，道路网络的灵活性是一个重要的优点。通过局域网中的100Gbps无阻塞网络，一帧高清视频可以在不到2毫秒的时间内以线速传输，如果每帧或部分帧可以并行传输则更快。因此，本文假设自我优化传输比实时更快，甚至趋于瞬时，对大多数工作流程都是有益的。

计算服务

转换媒体、应用图形、缩放、混合、分析和过滤是生产过程中可以应用的一些操作。在数字生产环境中，每一项操作都需要计算服务。这些服务的一种方法是将它们分解为可按需执行的可组合原子函数。对于全能的机器，假定每个函数执行时间为零。

现代图形处理单元（GPU）具有大规模并行处理能力，包含数百或数千个计算核心的许多台式机和笔记本电脑可以将媒体处理任务分解为执行每个阶段所花费的时间趋于零的点。另一个替代方案是使用计算集群和“函数即服务”（例如AWS Lambda），有趣的是可能会大规模扩展——转码整个电影即细分为块，且每个块同时处理即可仅使用几秒钟完成。

存储选择

媒体存储需要具有高性能，可靠性和可扩展性以满足不断增长的媒体数据量的需求。存储通常是系统中的瓶颈，可选择的视频编解码器是存储带宽/大小与持久性质量之间的平衡。凭借无限的存储容量和存储带宽，为什么不以最高质量存储所有内容？或者甚至是任何可能的质量？是否媒体存储只是以便再次需求，还是应用无限的计算能力来按需制作每种格式？

基于格式存储媒体的选择是可以利用机器学习来执行的操作。

集群RAM缓存的应用解决了网站上的许多性能问题。RAM相对便宜，并且许多快速周转媒体工作流程（例如新闻和体育制作），主要使用在过去24小时内创建的少量媒体剪辑。全能媒体计算机可以应用集群RAM缓存来提供媒体池的高性能存储，这可以通过长期存储来补充，例如基于云的对象存储。

敏捷媒体蓝图

敏捷媒体蓝图（AMB）[1]将全能机器概念发展成技术计划，媒体公司和供应商可以遵循这些技术计划来构建能在和互联网相同的平台上运行的高度灵活和可扩展的系统。通过遵循该计划，媒体公司能够比使用传统架构更有效地创建和货币化内容。AMB可以利用用于运行全球千兆系统（如Twitter）的所有硬件、软件、网络和相关组件。

敏捷媒体蓝图始于人、团队、组织内和组织间。如图1所示，它从这里开始，不仅因为人是我们技艺导向行业的关键组成部分，而且人们可以在一开始就解决安全问题。管理员可以为人员分配角色，并根据业务需求，可以在组织中为不同组织中的人员授予特定权限。例如，来自两个远程制作公司并使用两个不同OB Vans的工作人员可以被赋予角色，允许他们协作进行一次性事项。此方法允许人们使用共享内容API进行安全协作，可以实现内容API互连相机、麦克风、扬声器、多视图和控制表面。

图 1 人和各自的角色

虽然可以部署AMB以满足专业媒体制作需求，但它也可以用于有效地生成需要与终端观众直接交互的新类型内容。如图2所示，AMB通过广播媒体、over-the-top流媒体（OTT）和移动设备来定位社交消费者。

图 2 消费者与固定内容互动

传统的广播架构永远无法向数万（数百万？）观众提供个性化内容——这是对广播基本概念的“诅咒”。但是无论观众希望看到什么，只要他们想，都意味着AMB架构的无缝扩展至关重要。在许多情况下，在个性化内容场景中，内容被缓存并作为一次性事项流式传输给观众。许多广播公司已经根据每个观众的成本按比例支付带宽费用，而没有受益于更紧密的双向关系。

如图3所示，AMB的核心是基于粒度的内容API，用于逐个元素访问媒体，由最佳的云适应技术支持，包括集群RAM缓存、AI、对象存储。微服务使新媒体元素按需订购，不再需要通过创建媒体元素来浪费时间和资源“以防万一”。

图 3 常见的内容API提供了统一、开放的界面

AMB中的媒体传输在内容API之间，双向链接并行运行，速度更快、更慢或与实时相当。如图4所示，时间到字节的转换接口（字节-时间组件）允许内容被读取和写入公用信号和文件格式，并且允许即时合成。

图 4 字节转换允许创建/消耗现有格式

文件和流的库可以使用索引数据库支持的字节-时间解包组件，即时或根据计划迁移到AMB的实现中（参见图5）。这允许媒体工厂轻松地从基于文件的架构迁移到基于API的架构。

图 5 字节转换和索引有助于创建公共媒体文件和流格式

衡量差距

理想主义全能机器与AMB提出的现有技术之间的差距是什么？是否需要使用AMB技术处理媒体的时间趋于零？本节介绍在高速网络、GPU和计算群集上移动和处理视频数据的一些初步测量。进行这些测量的主要目的是在行业中建立一个持续的过程，从而对机器的媒体能力进行常规基准测试，为战略和购买决策提供信息参考。

高速网络

使用HTTP和HTTPS在网络中移动高清视频帧所需的速度测量是作为测试云适应的专业媒体的物联网架构的一部分[2]。选择该协议是因为它可以使用商品互联网技术进行扩展和保护。结果表明，在局域10Gbps网络中，可以比实时更快地传输每帧视频，同时通过TLS加密及通过TCP进行恢复。并行传输相同流的部分也是可能的，从而增加了最大吞吐量。

GPU并行处理

无压缩的视频帧是数百万像素的阵列。现代PC连接到高分辨率屏幕（高清分辨率或更好），并用于视频编辑、游戏和设计等应用。为了实现2D图像和3D环境的实时渲染，现已开发了专用图形处理芯片，其可以支持在数百个单独的核上并行处理图像的区域。最初，通过图形处理语言（如OpenGL和DirectX）访问这种专用加速器，2009年OpenCL语言[3]被发布，以便于访问GPU以执行以类C语言编程的一般处理任务。

对于无压缩媒体的处理，GPU架构中的瓶颈一直是GPU专用随机访问存储器（图形RAM）。对于媒体制作任务，每个视频帧必须从CPU RAM移动到GPU RAM、处理然后移回。复制媒体所花费的时间，以及在OpenCL出现之前将其转换为适合处理的格式，是资源密集且速度慢的。一旦在GPU上，就可以构建媒体处理流水线，其中每个阶段在几毫秒或更短的时间内运行。

2015年，英特尔推出了第9代图形架构[4]以支持OpenCL语言的2.0版本。这包括一个称为共享虚拟内存（SVM）的工具，CPU和GPU可以在相同的内存区域上运行，一次锁定一个块（粗粒度）或协同工作——就好像GPU只是CPU的另一个核心（细粒度）。由于不必复制数据，这意味着可以在几微秒内将一帧视频传送到CPU或从CPU传送到GPU。当CPU和GPU位于同一处理器芯片上时，缓存存储器也是共享的，这意味着GPU对存储器的访问不受PCI总线速度的限制。

图6中的图表显示了将无压缩的视频帧移动到GPU，执行简单操作并从GPU移回CPU的测量结果。结果比较使用数据复制（无）与使用三个不同GPU的SVM（精细/粗略）的模拟HD和4K有效负载的时间：

1. 英特尔图形HD520GPU与英特尔酷睿i7-6500CPU位于同一芯片。
2. 英特尔图形UHD630GPU与英特尔酷睿i3-8100CPU位于同一芯片（价格100英镑）。
3. nVidia Quadro M1000MGPU通过PCI连接到Intel Core i7-6700HQ CPU（细粒度SVM不支持，粗粒度SVM支持实验）。

结果表明，低成本的共享存储器架构可以加速媒体处理流水线，并且比实时更快地执行视频图像的复杂处理，即使对于以120帧/秒运行的无压缩4K视频也是如此。

图 6 使用nodencl测量GPU媒体传输和处理速度

集群键值缓存

为了实现互联网应用所需的规模和弹性水平，互联网平台的缓存层已得到增强，可以服务、管理和协调处理请求。通过将基于RAM的快速缓存与业务逻辑和用于扩展与弹性的集群相结合，键值缓存（例如Memcached，Redis）承载了面向Internet的应用程序的大部分后端逻辑。这些缓存支持任意数据blob，那么如果这些blob是媒体数据会发生什么，例如视频？

图7中的图表显示了出入Redis集群高速缓存的模拟HD和4K有效负载的读写时间的基本测试，每个操作都是串行和并行的。该缓存是AWS Elasticache服务中最小的缓存，它基于使用“最多10千兆位”网络互连的r4.large实例。Node.JS在云可用区域中与部分集群并置，用作在另一个r4.large实例上运行的Redis集群客户端。对于高清媒体，帧出入集群的速度快于或相当于实时（允许隔行扫描），显示了这种集群用于视频处理的能力。对于4K无压缩视频，时序低于实时。未来的工作有很大的空间来探索更快、更大的集群和优化的客户端实现。

图 7 使用redia测量模拟视频有效负载的Redis集群速度

存储

作为BBC研发云计算项目的一部分，近期的工作采用了类似的方法来对媒体对象存储进行基准测试[5]，结果显示了无压缩高清视频的线性缩放。

分析

全能是一种理想主义的概念，即使有足够的预算，云数据中心的数万台计算机的性能也可能已经饱和。例如，为使用无压缩流的每一百万观众提供一个独特的4K流会使这样一个数据中心的性能过载，甚至可能使媒体公司破产！然而这是一个极端的例子。对于要求较低的媒体工厂工作流程，通过创建在观众组之间共享的压缩媒体片段来实现个性化，为了复制现有工作流程，云架构通过数百台服务器的固定现场设备提供可用性能数量级的增加。换句话说，虽然不是真正的无限性能，但显然全能可用于探索创新的可能性。本文介绍的全能媒体机的定义是能够处理尽可能多的媒体，及工作流程需要的时间趋于零。持续的全能化工作基于多维改进：

• 机会灵活化：多租户和按需扩展模型，以便工作流在需要时只租用所需的资源。
• 驾驭核心IT发展：IT技术发展包含了更高性能的云产品、尖端的计算机科学和利用更快的硬件。
• 应用广泛化：AMB的设计为使用当今的集群云架构执行媒体工作流程提供了适当的框架。
• 软件优化：开发利用多核系统和GPU加速的优化软件，实现固有的可并行媒体处理。

上面提到的在适当的架构实例上运行的轻微优化软件的测量显示了无压缩HD媒体的存储、处理和传输时间优于实时，这意味着对于媒体工厂的跨维度操作处理时间趋于零。

是否应该调整云架构以使其更接近现有内部架构，例如支持基于线路的时序，具有PTP时钟并符合SMPTE2110-21的数据包间到达时间？理想情况下，是的，应创建一个可以从广播车到云架构使用的通用工具包。云服务提供商的媒体公司对此项技术有需求并很快就会提供一些技术要点。然而，这种方法可能过度设计，因为它将把顺序SDI架构（例如，数据速率限于媒体实时，每个媒体元素的每个组成部分按顺序处理）的设计选择与其他异步云计算机相结合，限制了计算集群和/或流水线GPU处理的充分利用。可以说，遵循这条路径——采用传统架构的约束模型并将其转移到云端——将无法从增加性能的所有潜在维度中受益。

不应将传统约束转移到云，而应采用与现代软件开发实践一致的方法。这从采用隐藏操作问题的技术开始，例如缩放、弹性和API背后的分布式处理，然后在顶部添加媒体功能作为包装。这些API支持的技术体现在集群或无服务器云产品中，旨在提供易于部署、响应迅速的Web应用程序，可动态扩展到数百万用户。在降低项目风险的同时提供业务敏捷性，顶部的特定于媒体域的包装可以采用AMB定义的可组合功能作为微服务。

未来工作

AMB是一项技术计划，需要通过规范、概念验证活动、开发以及构建其组件的项目计划进行开发。迄今为止，AMB已作为高级媒体工作流协会的讨论文件出版，旨在促进从2018年秋季开始的讨论。

开源物联网框架动力学[2]的开发正在进行中，包括HTTP/S传输、媒体编码和解码、媒体转型与合成、缩放和混合、媒体打包——不同的位模式和色彩空间翻译、文件和流接口等等。目前这项工作的重点是通过内存高效的OpenCL[3]加速媒体处理来优化框架，从SD扩展到UHD/WCG内容。这些工具可通过软件自动化进行部署，从RaspberryPi计算机、笔记本电脑、工作站扩展到GPU加速的云服务器。该物联网框架的模块是AMB微服务的第一候选实现项目。

总结

将IT技术应用于专业媒体制作的战略规划可以从使用中的机器具有全能性、无处理和无传输延迟的角度出发。做出这样的假设增加了新的通过云计算规模和多维创新实现的创造机会，例如个性化生产。

不应试图将当前的架构转移到云，系统可以设计为尽可能接近理想主义的全能机器，敏捷媒体蓝图（AMB）则提供了如何实现这一目标的计划。采用这种方法将实现利用计算集群和无服务器架构的备选工作流程，并从敏捷性、高性能、并行和分布式计算机技术中受益。基准测试速度和建模部署此类系统进行媒体处理的成本应该成为所有媒体项目的持续活动。通过使用相同的架构并进行扩展以提供顶层（OTT）服务，并对如何提供媒体工作流程进行不同的思考，显然可以使现有架构的媒体机性能大幅提升。

参考文献

[1]. Cartwright, R. I. and Gilmer, B. 2018. Agile Media Blueprint – creating and monetizing content using the Internet technology platform. Discussion paper of the Advanced Media Workflow Association. Available:

https://www.amwa.tv/downloads/reference_documents/The_Agile_Media_Blueprint.pdf

[2]. Cartwright, R. I. 2018. An Internet of Things architecture for cloud-fit professional media workflow. SMPTE Motion Imaging Journal. June 2018.

[3]. The Khronos Group. 2009. The Open CL Specification. Version 1.0, rev 48 and subsequent versions. Khronos Group specification. Available: https://www.khronos.org/registry/OpenCL/ [4]. Junkins, S. 2015. The Compute Architecture of Intel Processor Graphics Gen9. Version 1.0. Intel whitepaper. Available:

https://software.intel.com/sites/default/files/managed/c5/9a/The-Compute-Architecture-ofIntel-Processor-Graphics-Gen9-v1d0.pdf

[5]. S. Nicholson, 2018. Beyond Streams and Files – Storing Frames in the Cloud. BBC R&D blog. Available:

https://www.bbc.co.uk/rd/blog/2018-03-cloud-video-productionstream-file-frame