来源
：W3C/SMPTE Joint Workshop on Professional Media Production on the Web

主讲人
：Pierre-Anthony Lemieux, Steve Cronan, Bruce Devlin

内容整理
：王珅
目录
  • 浏览器无损 UHD 视频
  • 制片元宇宙
  • 工作流中的元数据

浏览器无损 UHD 视频

本次分享的主持人为来自 W3C/SMPTE 网络专业媒体制作联合研讨会主席 Pierre-Anthony Lemieux，他向我们分享了最新的网络浏览器发展，现在在任何网络浏览器中使用专业媒体已经成为可能，并且实际上可以在 HTTP 服务器上播放无损的 UHD 视频，无需代码和插件。
首先主讲人向我们讲述了相关背景，在之前的很长一段时间，专业内容和网络浏览器之间存在着巨大的差距，两者使用不同的媒体格式和编解码器，针对不同的体验质量。而且专业内容主要是在内部，而浏览器则优先考虑互联网。但时代已经改变。
自 2000 年以来，网络浏览器有了长足的进步。之前网络内容主要是文本，偶尔通过插件播放视频。到今天，网络允许通过标准的 API 进行复杂的多媒体体验。对专业内容尤其重要的是，WebAssembly 现在可以将 C/C++库直接移植到网上。这使得使用网络浏览器不支持的专业媒体格式和编解码器成为可能。
第二，在 10 年前似乎不可能的事情现在已经发生了：演播室类型的内容现在在公共云中进行处理。这对一个主要以录像带为基础并将互联网视为洪水猛兽的行业来说是一个惊人的逆转。导致这种转变背后的原因肯定并不是某一事件。同时，云不仅更有效，而且更安全，因为处理内容的人为因素更少。现在几乎所有的电影公司都将他们的一些工作流程转移到了公共云端上。
所以主讲人认为专业媒体拥抱网络平台的时机已经成熟。主讲人提出这样一个问题：UHD 无损视频可以在没有代理的情况下在网络浏览器中播放吗?
专业的 UHD 无损视频与网络浏览器原生支持的典型视频是极为不同的。图像通常以每像素 48 位采样，而不是消费级视频中的每像素 24 位。图像通常使用 JPEG 2000 等编解码器进行无损压缩，而不是使用 AV1 或 AVC 有损压缩。这导致比特率为 Gbps，而不是 Mbps。压缩后的图像最终被包裹在 MXF 等文件格式中，同样不同于用于消费者交付的格式。在网络浏览器中播放专业视频的传统方法是将专业视频转码为网络浏览器可以理解的格式。
但这就导致了需要一个代理。例如从一个 5Gbps 的 JPEG 2000 MXF 文件开始，你可能最终得到一个 50Mbps 的 AVC MP4 文件。这种方法有很大的缺点：这种转换有延迟，元数据和图像的保真度降低。无代理架构则采取了不同的方法。在这种方法中，专业视频使用 JPEG 2000 进行压缩，并包裹在一个 MXF 文件中，存储在 HTTP 服务器上。使用 MXF 索引表，网络应用可以使用标准的 HTTP 字节范围请求直接访问每个单独的图像帧。根据网络条件和每个帧的大小，网络应用最终会读取完整或部分的帧。使用一个编译成 WebAssembly 的开源 JPEG 2000 C++库，网络应用就可以对部分或完整的图像帧进行解码。因为帧是使用 JPEG 2000 编码的，对部分帧的解码不会失败，反而会导致解码后的图像的分辨率降低。这种对帧的部分读取导致较低分辨率图像的能力是 JPEG 2000 分辨率渐进式编码流的一个标准特征。在这样的编码流中，低空间频率信息被存储在编码流的低字节中。而高空间频率的信息则存储在较高的字节中。因此，读取部分帧的结果是一个低分辨率的解码图像。
主讲人还提供了一个无代理架构的现场演示。其中视频是无损的 UHD 内容，每像素 48 比特，相当于约 5Gbps。该文件存储在 S3 上，并通过 CloudFront 分发。视频的质量将取决于你的可用带宽，但鉴于所涉及的比特率，不太可能是原始视频。然而请注意，当视频暂停时，该应用程序可以下载完整的框架，进而得到原始的质量水平。当然，这只是一个概念验证，所以还有很多改进的可能。
但是，它证明了在浏览器中以适应网络条件的方式播放 UHD 无损视频是可能的，使用标准的网络 API 和开源库，无需任何特殊的网络服务器。主讲人相信现在是专业工作流程拥抱网络平台的好时机。网络可以支持专业的编解码器和格式，专业媒体正在向云端转移。当然目前仍有一些差距。例如，网络平台确实缺乏对高动态范围和宽色域图像的支持。而样本和精确的媒体同步也确实可以改进。主讲人希望这些差距在将来能够及时得到填补。

制片元宇宙

主讲人首先探讨了什么是制片元宇宙，以及元数据是如何协调工作室和制片流程，然后分析了在这一过程中存在哪些挑战，他们又如何在这些工作室的虚拟生产中导致的。
首先是元宇宙制作的基础内容。元空间是从脚本开始的，是故事的基础。并在这个基础上进行调研，从网上调取图片，用故事板和概念艺术建立独特的内容，在世界各地拍摄照片，用建筑图纸进行布景设计，用一系列其他内容进行构造。然后，当进入拍摄阶段时，会以高帧率捕捉各种不同的分辨率，并可能在多个地点通过多个设备拍摄多个镜头。一部作品在几个月内产生数百兆字节，甚至数千兆字节的情况都并不罕见，并且需要将所有这些内容上传到云端，分发给多个供应商，他们都以不同的方式在不同的阶段处理这些内容，并且在制作过程中有不同的需求。剪辑部将这些东西剪在一起，并将所有的视觉特效团队和视觉特效层以及视觉元素组合在一起。
故事的基础是从脚本开始的。脚本是一个结构化的文件，有场景、室内、室外、日/夜标签、故事地点、人物等等，所有这些在脚本中都有。以此为基础，我们从故事地点扩展到实际地点，比如说实际拍摄的片场或者拍摄的特定布景，其中也有虚拟元素的序列和镜头。那么视觉效果部门要如何分解信息呢？这一切和制片元宇宙又是如何关联的呢？
主讲人进一步深入解析视觉特效，以某个特定镜头为例，它会被分解为至少数百帧画面，这些帧有不同的层，也许是前景板或者背景板。前景板可能是由模型、骨架和贴图组成的，并与连续镜头结合在一起，只是为了创造出几秒钟的优美画面。
例如，我们可以用一个骑马的人作为前景板。在背景层中加入一些烟雾、人群、硝烟，提亮上色，就会得到这个美妙的图片。因此你可以想象一下在全球范围内，数以百万计的帧，数以千计的镜头都经过这样的处理，就是为了制作这一件作品以及周边产品。
前景板
合成图
因此，重要的是你需要有一个统一的框架，如何从文件元数据构建这些信息，文件在资源中结构如何，角色与演员之间的连接组织，尽可能使用人工智能分析实现自动化。通过例如 FileMaker Ftrack 或 Shotgun 等外部数据库将镜头与视效团队联系起来。如何从制片的所有不同阶段建立支柱，从角色和前期制作，到现场拍摄到后期的编辑和归档，一直到原宇宙和实体。于是，我们利用所有这些数据来协调状态变化和触发事件的流程，以便在不同的情况下用不同的应用程序进行转码和文件传输，这都是为了尽可能快地移动这些数据以便给予创作者尽可能多的时间在他们赶在最后期限之前作出决策。制片的目的是在有限时间内创造出最好的作品，而我们的作用就是尽可能促进写作，提高决策的速度以及源源不断的创意。
挑战
而我们在浏览器中发现的一些关键挑战包括处理大尺寸的文件，以及对全球范围内大文件传输进行 UDP 加速。当你必须在一夜之间上传数 TB 的文件，并且需要传到另一个地方交付给下一个艺术家来处理时，你真的需要 Aspera 和 Signiant 这样的常用工具来为你提供稳健性。但如果能够在浏览器中获得本地支持那就好很多。上传文件夹目前在浏览器中仍存在许多挑战，结构化的文件，比如一个模型有相关联的骨架和贴图，要保持这些结构，通常需要人们压缩文件，然后在上传后将他们解压。
编辑是另一大挑战，当然编辑既具有云端，也具有实地属性，既可以在工作室完成也可以在家中完成，协调传输这些数据，并在合理的时间内把它送到需要的地方，这也推动了将桌面端带到云端的需求。因此直接在云端中运行通用操作系统和普通应用程序的需求正在日益增长。
还有很多处理原始媒体成本的挑战，总是需要转码，难以用任何形式的水印保护。在成品播放方面，已经有了良好的发展，在浏览器上，正如我们所看到的在诸多视频技术的加持下，如碎片化 MP4 以及低延迟流媒体直播，目前正在加速发展。
但对更高的比特率的需求，更高的保真度，5.1 音频等等，肯定是一个更高的要求。视觉和取证水印一直是我们工作的基础。正如我们谈到的上传的挑战，然后利用音频和人工智能分析的规模，主讲人认为一切正在朝着正确的方向发展，我们将在未来利用更多的东西。
最后主讲人欢迎大家投身这一领域中来，让元空间在未来发挥更大的作用。

工作流中的元数据

当我们想在网上看视频时，有很多相关的 API 和协议用于将视频和声音输入我们的浏览器。当然，其中有一些是超高延迟和超高压缩，而另一些则是低压缩和低延迟。但总的来说，你可以选择一个操作点，找到足够的工具来为你完成 90% 到 100% 的工作。
现在，你决定走另一条路。你想摄取一些视频。同样有一堆 API 和协议可以允许和帮助你改变压缩率、延迟、质量、可靠性、速度和实时性，以及基于你需要的一些东西来实现视频摄取。虽然没那么丝滑，但是能用。
现在，你想在摄入的数据中添加一些生产过程中的元数据，并把它放到你的云生产系统中。主讲人通常把这种元数据归为"外来物"，因为有很多不同的类型，每种类型通常都有很小的用途，而且很少有真正好的基础设施或框架来解决问题。主讲人见过 Arduino 和 Raspberry Pi 的混合体，通过 WiFi 的 RTP 实现传输，可以自定义速率控制，支持不同的文件类型，不同的同步方式，不同的错误纠正，但是同样的问题还是存在。
主讲人提到：在拍摄过程中，我们想通过时间轴获取元数据，能够知道哪些元数据是从哪些设备上来的，是哪一次拍摄得到的，用哪个相机拍摄的。这些都不是新问题，从电影和电视的早期开始，我们就已经把这些类型的系统捆绑在一起。到今天改变的是我们现在有能力将大量的数据拉到一个共同的云存储中，并在云中应用尽可能多的计算。Arri、Nablet 和 TrackMen 的优秀人员帮助我们组装 了一些工具包，以探索通用解决方案的轮廓，我们在网站 mxf-live.io 上记录了这一工作。你可以看到，我们从 Arri 摄像机内部捕获了一些数据，以及来自三脚架云台的平移、倾斜和桨 的外部数据馈送，将其封装成标准的文件格式，我们将其贴在 WiFi 上，然后将其序列化到编辑器的时间线上，这样我们就可以用捕获的元数据在直播中进行后期制作，但这并没有完全完成所有工作。
主讲人发现，实际上有四种主要的元数据，沿着两个轴线划分。第一条轴很简单，它是二进制的，还是文本的。这可以很好地预测你将如何处理下游的元数据。第二个轴是数据等时的位置，换句话说，每一个时钟滴答声对应一个样本，每个时钟滴答声都有一个嵌入的定时。
横轴
纵轴
一旦你掌握了这四种基本类型，你就可以看一下传输。能够将这些定时数据存储为可序列化的数据包流是有帮助的，为此我们选择了 MXF，因为它有可用的基础设施，并且能够将时钟表示为有理数，因此如果系统长期运行，如几周、几个月和几年，可以保持精确的时间，而没有漂移的风险。然后，这些数据包可以通过不同的传输方式进行映射和分层，如 WebRTC，以使它们从它们所在的地方，到达它们需要到达的地方。虽然 MXF 对于硬件和固件层来说非常方便，但有一些开源项目， 如 Pixar 的 OpenTimelineIO 和 ASWS，对于以通用的、与产品无关的方式与这些数据进行交互要友好得多。尽管如此，我们知道转码视频是有损失的，而转码元数据实际上可能会破坏其有用性。所以，只要有可能，保留原始的、可能是庞大的、原汁原味的元数据是至关重要的，而计算该元数据的简化代理对可视化来说也很重要。如果你要在一般情况下做所有这些事情，那么管理元数据类型的标识符，以及它如何与其他资产相关联，可能会成为一个噩梦，除非你设计了某种通用的框架来关联元素，基于简单的标识符，比如 URIs。
最后主讲人希望有更多的人对这一内容感兴趣并为之投入更多的时间，主讲人希望更多的人加入他们，并真正创造出对媒体世界以及其他垂直行业真正有价值的东西。
继续阅读
阅读原文