W3C/SMPTE 专业媒体制作 Web 技术联合研讨会

WebCodecs

Chris Cunningham 在他关于 WebCodecs 的开场演讲中，向媒体制作社区询问了可能需要的额外编码器选项。与会者提议增设一个质量控制选项，以便向浏览器表示 Web 应用是希望优先考虑编码质量还是编码延迟。这一提议应该可行。关于 API 的可能形态的讨论正在进行中，鼓励利益相关方关注其进展、提出贡献。

WebCodecs 为 Web 应用提供了对比特流进行解码（和编码）的能力，但比特流只有在解复用后才可用，WebCodecs 将这一问题留给 Web 应用来解决。Web 应用开发人员多次提出希望有一个用于解复用和复用的API。在 Web 应用使用 或 Web音频 API 中的 decodeAudioData 方法时，浏览器已经处理了这些步骤。Chris Cunningham 指出，Web应用可以利用现有库，如 MP4Box.js 或 FFmpeg。话虽如此，但这些库要么太局限，要么太宽泛，无法适用通用情况，而且Web应用要想集成这些库也很困难。Paul Adenot 指出，Firefox 已经使用 WebAssembly 代码对媒体内容实现了解复用，过程中没有明显的性能影响，而且对于编码流来说，内存副本几乎不是问题。总而言之，这方面还有待探索。可能需要一个基于 libavformat 库的专用开源复用/解复用库。另外，如果研究发现在应用层面上进行解复用/复用不具可行性，也许可以在 WebCodecs 的基础上扩展出复用/解复用 API。

媒体制作工作流程中使用的专业编解码器不同于媒体分发中使用的编解码器，包括 Adobe ProRes、JPEG 2000等格式。浏览器是否能够支持媒体制作编解码器？这可能很难实现。浏览器在 WebCodecs 中支持的编解码器列表很可能与其支持的媒体播放编解码器列表相匹配，浏览器在支持编解码格式时需要考虑诸多方面。或者，浏览器也许可以暴露出系统中可用的编解码器的钩子（hook）。要实现这一点，至少需要一个跨编解码库的通用抽象层。James Pearce 和 Paul Adenot 还指出，在浏览器中运行第三方代码可能会引入安全风险。

某些媒体文件会使用可变比特率进行编码。Nigel Megitt 询问，在这种情况下，是否可以通过查找特定的时间点来获取更好的支持。在编解码器层面，通常没有神奇的解决方案。可以改进查找的机制通常要在容器层面寻找。例如，MP3 文件可能包含一个目录，Web应用可以解析该目录用于即时定位适当的文件块。

一位与会者问到关于某些编解码器为了引导解码器，在媒体内容开始时可能需要支持对音频样本和视频帧编码/解码，这有时被称为启动（在音频领域中）或者预播放。这种样本和帧需要进行解码，但在播放过程中会跳过。Paul Adenot 解释说，WebCodecs 作为底层编解码器 API 的一个通道，Web 应用需要知道并处理它们正在使用的编解码器的预播放需求。要探索应用层面的实际影响，还需要进一步测试。

Yuhao Fu 指出，从视频元素本身检索解码帧有时会很有用。Paul Adenot 解释说，一旦标准化，WebRTC 工作组最近在研讨会后不久采用的 breakout box 提案就可以用来构造一个 MediaStreamTrackGenerator，它将使 Web 应用能够通过 HTMLMediaElement.captureStream() 方法检索的 MediaStream 访问解码后的帧。另一个选择是扩展video.requestVideoFrameCallback() 方法，使其也返回 VideoFrame 构造对象（在 WebCodecs 中定义）。

Web音频API

一旦 WebCodecs 得到广泛支持，理论上来说，decodeAudioData 方法就可以废弃了。不过，decodeAudioData 方法内置了对解复用的支持，这在许多需要访问解码音频样本的场景中很方便，而且广泛部署和使用的方法一般也不会从Web平台上消失。在可预见的将来，该方法仍应作为 Web 平台的一部分保留下来。

在由数字音频工作站（DAW）管理的专业音频工作流程中，音频准确性至关重要。例如，将正在录制的内容与正在播放的内容以及屏幕上渲染的可视化内容精准对齐。一般来说，这并不容易实现，因为它假定输入延迟、音频节点的固有延迟和输出延迟都是已知的。所有浏览器都暴露了相关的钩子，但并非所有浏览器都支持它们。Hongchan Choi 分享了 Chrome的设想即支持 outputLatency 和渲染能力 API 的设计，该 API 应该很快被会添加到Web音频API中。尽管如此，Paul Adenot 指出，其中存在着一个反复出现的问题，即系统从输入/输出设备读取的数据通常不可靠，这使得在浏览器中很难呈现有意义的度量。

W3C 音频工作组已经同意在 Web Workers 中暴露 AudioContext 对象，这使得数字音频工作站不必再将音频处理绑定到主 UI 线程上。Web音频API规范的更新正在进行中。

Kazuyuki Ashimura 想知道 Web 音频 API 对合成语音的支持。Paul Adenot 解释说，目前的系统不太适合这种处理，因为浏览器甚至可能在合成的音频样本通过扬声器或耳机播放之前，都无法获取它们。这个问题也许可以在2022年举办的语音交互研讨会上讨论。

James Pearce 问及 DSP 格式对自定义音频处理的支持。浏览器没有对特定的 DSP格式的原生支持，但是处理音频的代码可以用任何格式编写。有各种库可以用于处理 FAUST，例如 PureData、C++。

媒体同步

Sacha Guddoy 描述了一些媒体同步的用例，包括视频播放器与音频电平并排放置，以及音频播放需要与视频播放和 DOM 更新精确同步。Paul Adenot 解释了如何利用 Web Audio API 暴露的输出延迟来延迟 DOM 更新和视频帧呈现（通过WebCodecs），以同步视频和音频播放。HTMLMediaElement.requestVideoFrameCallback()提案可以用于简化视频相关用例中的同步逻辑。

Sacha Guddoy 还解释了如何在实时视觉混合应用中同步多个 WebRTC 流，例如使用多个摄像机。如果该建议得到更广泛的采用——且如果摄像机时钟也是同步的——则 Absolute Capture Time extension 可以用来给 RTP 数据包加上 NTP 时间戳。再加上研讨会后不久 WebRTC 工作组采用的 Harald Alvestrand 的breakout box model，Web 应用将能够延迟并同步渲染媒体流。

音频/视频和元数据之间的一般同步问题仍未能解决。例如，虽然媒体流在 WebRTC 是同步的，但数据信道与媒体流并不同步。在 WebCodecs 中暴露 SEI 元数据和解码帧的能力可以提供有用的同步钩子。

同步精度需求取决于使用场景，同时也会影响哪些同步钩子需要暴露和/或使用。目标精度水平需要在个案基础上加以明确。音频可能有严格的实时要求，而一些视频同步场景可能只需满足约100ms的精度。其他视频场景可能需要粗略或精确的帧精度水平。

WebRTC

Sergio Garcia Murillo 介绍了 WHIP，这是一个聚合 WebRTC 信令协议的提案。该协议可以被集成到媒体制作硬件中，以发挥WebRTC的开箱即用特性。这也将创造一个良性循环，以支持和暴露媒体制作所需的额外能力。IETF正在进行WHIP的标准化工作。

用于媒体制作的其他功能包括支持更高帧率的制作质量编解码器，支持多通道音频（环绕）或 基于对象的音频，支持高动态范围（HDR）和宽色域（WCG）媒体编码，或支持含透明通道的视频。

此外，WebRTC 对实时字幕没有适当的支持机制。RTCDataChannel 可用于串流文本，但数据信道与音频/视频轨道不同步（参见上文的媒体同步章节）。W3C 时序文本工作组为 TTML 文本开发了一个 TTML 实时扩展模块，但缺少标准的方法来串流 WebVTT。如何才能在 WebRTC 中集成实时字幕？

更高级的场景需要控制抖动缓冲区，例如，当 WebRTC 用于音乐和其他专业音频环境时，可以防止音频失真。

除了实时字幕之外，WebRTC 的部分功能已经在规范草案（如WebRTC 扩展草案）中进行了定义，而其他功能不需要对现有规范进行重大更新（例如对编解码器的支持）。媒体制作行业仍然需要在规范实现中权衡功能的优先级。某些场景（如对基于对象的音频的支持）仍需进一步探索以明确需求。

WebAssembly

Kevin Streeter 解释了如何使用 WebAssembly（WASM）将创作类应用从桌面移植到 Web。随着时间的推移，本地应用经历了大量的优化。由于 WebAssembly 在功能方面有所缺失，其中一些优化在 Web 版本中丢失，有时会导致工作流的运行速度可能比本地应用慢4到5倍。

第一个缺失的功能是对堆管理的64位支持。WebAssembly 内置了对64位数字的支持，可用于加快像素处理计算。但是，64位内存地址仍在制定中，浏览器还不支持。

另一个缺失的功能是高级 SIMD 支持。Luke Wagner 解释说，WebAssembly 中最初的一批 SIMD 支持是能够支持在各种桌面 CPU 上快速移植的前提下，该小组所能发现的范围最广的交集。Web Assembly 工作组的 SIMD 分组为了开发 WebAssembly 中的下一代 SIMD 指令，每两周召开一次会议，涵盖三个主要维度：支持特定于平台的指令、允许非确定性指令以及放宽向量大小。SIMD 分组欢迎有 WebAssembly 的实际工作负载来指导其工作。

最后，Web 媒体制作应用绝不会是纯粹的 WebAssembly 应用。它们还将通过 WebGL 或 WebGPU、运行在 CPU 上的 Web API 以及通过 Web Workers 的多线程操作来利用 GPU 计算。在跨越内存边界时，通常需要内存副本，而媒体制作工作流需要操作大量内存（尤其是在处理解码视频帧时）。

Luke Wagner 详细介绍了减少跨边界内存副本的解决方案。理论上，可能会对编译器做出更改，允许 Web 应用引用 WebAssembly 线性内存之外的内存页。在实践中，考虑到所需的工作量，这又不太现实。更好的解决方案是改进创建副本的操作，这样浏览器会尽可能使用内存映射（mmap）。这种方法可能需要更新许多规范，并且很难实现，但它不需要特定于 WebAssembly。在需要转换数据的情况下，另一种方法是延迟拷贝，以便将复制和转换操作融合在一起。

Web 平台孵化社区组（WICG）负责减少内存副本的协调工作。我们鼓励有兴趣的各方加入该存储库中的讨论。

文件系统集成

与 WebAssembly 一样，Kevin Streeter 讨论了将本地创作类应用程序移植到Web时出现的常见文件系统集成问题。这些问题最终归结为需要接收、处理和传输非常大的文件资源，同时需要优化I/O操作的数量以提高性能。Marijn Kruisselbrink 介绍了在文件系统访问 API 提案中定义的域私有文件系统（Origin Private File System）。该 API 旨在更好地处理大文件，并能够以最小的开销对其进行读写。也就是说，当需要将外部数据导入域私有文件系统时，仍然需要进行复制。在只读的情况中，也许可以适当放宽限制。写入域私有文件系统之外的文件则更加棘手。

域私有文件系统可能很快就会交由 WHATWG 负责。对此类和其他功能的支持高度依赖于浏览器厂商的意愿。媒体制作行业应当在规范实现中优先考虑该功能。

元数据

Bruce Devlin 概述了元数据的一个核心问题：在媒体采集阶段产生的元数据很容易在随后的媒体处理步骤中丢失，往往需要事后重新创建。往好了说，不方便，成本也很高。元数据也可能在传输过程中丢失，或者在播放过程中无法从应用中获取。元数据该如何才能保存下来呢？

Bruce Devlin 沿着两个轴对元数据进行分类：格式轴（文本或二进制？）和时间轴（与每一帧同步，或更不规则，或是嵌入定时的块状？）。管理和暴露元数据的解决方案要取决于元数据在这两个轴上的位置，以及为该元数据设想了哪些用例。用例之一是添加出处和真实信息，内容来源和真实性联盟（C2PA）目前正在探索这方面的用例。出处信息可在媒体播放期间或当用户按暂停时显示。在这样的场景中，元数据和帧之间实现同步是必不可少的。

标准化工作可以侧重于定义暴露不同类型元数据的 API。例如，DataCue API 建议可以在容器层面暴露元数据。WebCodecs 中对 SEI 元数据的支持（在研讨会期间讨论过）可以暴露编解码器层面的元数据。

元数据也需要使用标准化词汇表，以便媒体制作工作流可以用更抽象的转换术语来定义，并广泛应用于各种输入和输出源。Julian Fernandez-Campon 展示了使用标准化词汇表来介绍工作流中的处理步骤，这些处理步骤可以利用各种工具和服务。对于媒体内容而言，SMPTE ST2065(ACES)标准应该很合用。Brendan Quinn 指出IPTC 视频元数据中心可以使用其他标准。W3C 是否应该开发一个现有标准之间的映射词汇表？

无障碍

Ed Gray 回顾了现有的无障碍指南，特别是Web 内容无障碍指南（WCAG）和创作工具无障碍指南（ATAG），国际无障碍专业协会（IAAP）和 Web Access In Mind（WebAIM）等实践社区，以及无障碍的自述格式，如自愿性产品无障碍功能模板。

媒体创作工具中的无障碍功能覆盖许多层面，从对比度和键盘导航设计，到闭合式字幕支持和相机已连接的通知。正如通用设计原则中所阐述的那样，这是一项永无止境的工作，当公司设立专门的团队，当无障碍措施真正惠及每个人时，这是最好的解决方案。

现有技术

研讨会的一个主要收获是，Web 平台已经提供了合适的构建模块，以支持基于代理的架构中的核心媒体制作场景：媒体串流和渲染技术（例如，视频元素、基于 canvas 的渲染、MSE、Web 音频 API)、媒体传输技术（Fetch、WebRTC）、媒体处理技术（通过 JavaScript、WebAssembly 或 WebGL）和媒体存储技术（File API、IndexedDB)，这些技术在创作类应用中得到广泛支持和使用。

然而，很明显，Web 平台现在不能很好地适应专业媒体制作场景的无代理架构。研讨会期间提出的技术差距意味着这些场景可以在 Web 应用中实现，但只能在一定程度上实现。例如，在客户端设备上运行的 Web 媒体创作应用在解码和处理视频时可能需要将视频的分辨率限制在 480x270 ，因为它们不能利用硬件解码器。这些应用还可能遇到难以解决的同步问题，损失色彩保真度，或者远不及本地应用，因为它们不能获得处理媒体的优化措施，如高级 SIMD 指令。

正在进行的标准化工作

研讨会的演讲和讨论表明，正在进行的标准化工作将带来更先进的功能和性能改进，这是媒体制作行业所需要的。这其中包括对 WebCodecs 暴露的对媒体的底层访问、Web 音频 API 中更好的延迟测量功能、WebAssembly 中的增强性能（高级 SIMD、64位内存堆支持）、Web Workers 中所有 API 都可用时更流畅的 UI，以及 WebRTC 中的制作质量支持（多通道音频、更高帧率编解码器支持）。

这些正在进行的标准化工作横跨多个 W3C 工作组，包括 括媒体工作组 (例如 WebCodecs、媒体功能)、音频工作组、WebAssembly 工作组、WebRTC 工作组、无障碍指南工作组 (WCAG)、GPU for the Web 工作组 (WebGPU)、时序文本工作组或者进行预标准化工作（如域私有文件系统）的Web 平台孵化社区组 (WICG)。

这些工作组是公开运作的，并乐意接受对其交付成果的意见，这些意见通常是在 GitHub 存储库上提出的问题。这种单点反馈的方法可以很好地报告特定的需求，一些与会者已经提供了关于 WebCodecs 或 Web Audio API 的反馈。

这种单点反馈的方式有时是不够的。工作组需要更多的意见来对功能进行评估，来确认该需求在整个行业中广泛存在，来评估将该功能开放给 Web 应用是否是在性能和互操作性之间进行的合理权衡，或者探索其他设计。此外，有些功能只有从更广泛的媒体制作角度来看才有意义，而这些工作组不一定有这样的角度。

为了集思广益，工作组需要在以下方面协作：

• WICG 的减少内存副本计划需要协调与关于减少跨内存边界副本的机制讨论。
• Web 上的色彩社区组需要协调整个 Web 平台在高动态范围（HDR）和宽色域（WCG）方面的工作。
• 在媒体和娱乐兴趣组中，媒体时序事件特别任务组需要协调关于元数据公开的讨论.
• 更广泛地说，媒体和娱乐兴趣组在 W3C 需要充当媒体标准化工作的指导小组。
• 在 W3C、SMPTE 或其他地方也需要类似的协作，侧重于特定的主题。

计划建立媒体制作特别任务组

以上提到的协作方面针对的是与研讨会期间提出的问题有交集的主题。然而，目前还没有任何协调工作将 Web 专业媒体制作需求作为一个整体来看待。此次研讨会是一次性的协调工作，但显然，对研讨会期间开始的一些讨论，需要进行更深入的分析。此外，由于时间不足，研讨会未能涵盖所有相关主题。

与会者建议在基于 Web 的专业媒体制作方面开展协调工作。这项协调工作的覆盖范围将与研讨会相当：利用Web平台制作专业媒体，包括编辑、质量控制、调色/颜色校正、样片、视觉效果、音频、母带制作、翻译和服务。脱离 Web 平台的基于云端的流程和桌面应用程序将被排除在外。类似地，不操作媒体内容的应用（如文件共享应用）也不包含在内。

这项协调工作将负责：

• 连接Web平台和各专业媒体制作社区，
• 记录专业媒体制作的用例和特定需求，
• 当功能可以通过应用层面的现有技术实现时，对性能需求进行量化，
• 确定优先级并向工作组和标准实现者推广提案，
• 跟踪进度和实现情况。

考虑到研讨会期间提出的具体议题，这项协调工作可以：

• 在应用层面进行复用和解复用的代码实验，为 在WebCodecs 中创建（解）复用 API 的可行性提供信息。
• 评估 WebCodecs 中讨论的质量控制选项。
• 围绕元数据管理收集媒体制作用例，特别是 SEI 元数据和编码方面的用例，来提供给媒体时序事件特别任务组和媒体工作组进行讨论。
• 记录对专业编解码器的需求，并在标准实现过程中监测支持。
• 与 WebRTC 工作组合作，记录 WebRTC 的实时字幕需求。
• 探索同步需求和差距，使用代码来量化问题。
• 收集典型的内存工作负载以分析需要跨越内存边界（CPU、GPU、WASM）时的性能问题，并帮助相关工作组调整其API以避免重复出现问题。
• 记录针对媒体制作因文件过大而可能导致的文件资源管理问题。
• 确保在Web上的色彩社区组讨论中考虑媒体制作的角度。
• 探索媒体制作工作流程中对标准化词汇表的需求。
• 探索更具体的需求，如预播放/启动，或从<video>元素获得解码帧的能力。

为了取得更好的效果，这样的协调工作应围绕开发 API 的工作组和已经涉及感兴趣主题的主要协调点进行。建议由W3C 媒体和娱乐兴趣组负责这项协调工作：这项工作符合其作为 W3C 媒体标准化工作指导小组的职责，设想的工作范围不包括技术解决方案的开发，而是在负责基础标准的工作组（媒体工作组、音频工作组等）中找到其自然落脚点。