W3C: 开发专业媒体制作应用 (5)
来源：W3C/SMPTE Joint Workshop on Professional Media Production on the Web 主讲人: Kevin Streeter (Adobe), HE Zhi (MIGU - China Mobile) 翻译：钟宏成 演讲 1 中，首先对创建强大创意工具所需的许多技术领域进行广泛总结。然后，我们将深入研究几个选定的主题，以更好地了解我们需要从网络中获得的那种能力，以使这一切成为可能。演讲 2 中，分享了咪咕网编辑技术在体育转播直播和后期制作中的应用。
目录
- 将桌面级创意表达引入 Web
- WebAssembly 的使用
- 颜色
- 磁盘和文件系统
- 媒体的硬件编码和解码
- 体育广播的现场和后期制作
- 直播编辑工具
- 后期制作与剪辑
- 架构
- AI 增强制作
- 经验总结
将桌面级创意表达引入 Web
创作者习惯于触手可及的桌面级硬件的全部功能。我们如何构建具有相同水平的性能和表现力的应用程序，同时又具有基于 Web 的体验的所有好处？
以下是应用程序利用传统桌面平台的一些方式。
- 这些应用程序可以完全访问 64 位 CPU 和性能或指令集，例如 AVX。
- 他们可以访问大量内存。
- 他们可以完全访问磁盘硬件和本地文件系统。
- 他们使用低级 API 来提高性能和效率。
- 它们具有对色彩管理和色彩空间的端到端支持，可实现宽色域和高动态范围。
- 桌面软件可以访问输入硬件，例如触控笔、笔和其他设备。
- 他们可以使用现代媒体解码和编码，尤其是视频编码和解码。
- 他们可以访问支持图形和计算的现代 GPU 管道。
- 最后，他们可以获得那种体验质量的能力，例如剪贴板、可访问性和其他真正使工具为创意专业人士工作的东西。
WebAssembly 的使用
我们要深入研究的第一个领域是 WebAssembly 的使用。
创意媒体工具倾向于混合使用新的和现有的媒体处理代码。现有代码通常是用 C++ 编写的。此代码往往是计算密集型和内存密集型操作的混合。重要的是，并非所有这些代码都可以简单地移植到 GPU。
有时这是因为我们还没有真正找到一个好的基于 GPU 的操作解决方案，但通常也是因为我们有工作代码并且我们真的很想继续使用它。
随着时间的推移，这些代码库已经进行了大量优化，并且已经以几种不同的方式进行了优化。它们已经过优化以利用 64 位处理，并且它们还经过优化以利用大多数桌面级硬件上存在的 SIMD 指令集。
如果我们想在网络上做这些类型的事情，今天我们面临着一些挑战。一是今天对 WebAssembly 的浏览器内支持都是 32 位的。这不仅限制了处理能力，而且还限制了我们可以访问的内存总量。
目前大多数浏览器不支持 SIMD。有一些关于 SIMD 操作的建议，并且在某些浏览器中支持，但就该功能的可用性而言，它还处于早期阶段。
其中一个重要方面是，目前正在研究的 SIMD 提案确实强调可移植性而不是性能。这意味着我们不再真正能够访问最低级别的指令集，这确实会对整体性能产生影响。
颜色
下一个重要领域是颜色。
色彩管理、宽色域和高动态范围功能对于专业媒体制作至关重要。无论媒体类型如何，无论是视频摄影还是印刷品，都是如此。手机和平板电脑等消费类设备越来越多地支持宽色域和高动态范围，这使得为这些设备提供正确色彩的能力变得更加重要。
重要的是：颜色是一个端到端的问题，我们必须在系统的各个方面解决这个问题。这包括格式、像素处理和渲染。
现在，如今，诸如 CSS 4 之类的标准正在帮助支持扩展色彩空间成为可能，但目前并非所有浏览器都广泛支持这一点。此外，并非所有 Web 模块都支持这些颜色管理功能。例如，今天并没有真正的方法来确保 WebGL 能够正确显示广色域内容。最后，值得注意的是，不同的行业对颜色有自己的标准。这意味着如果我们想要支持创建针对这些行业的工具，网络平台需要具有包容性。
磁盘和文件系统
桌面创意工具大量使用本地磁盘并依赖对本地文件系统的访问。这些工具出于各种原因使用磁盘。他们使用它们来存储文档和项目。他们使用它们将内容导入和导出应用程序，并将它们用于暂存空间和缓存。
这些工具已针对磁盘 I/O 进行了非常仔细的优化，它们试图将 I/O 操作的总数和传输的数据总量都降至最低。今天基于浏览器的文件访问并没有真正提供对本地文件系统的写访问权限。而且 API 级别相当高，这意味着很难确保 I/O 是最佳的。
当前的提议（例如 Origin Private File System）很有前景，但需要允许使用主机文件系统进行有效的导入和导出。
最后，许多低级功能在 Web 平台中并没有真正的模拟。例如，不支持稀疏文件或零拷贝文件 I/O。
媒体的硬件编码和解码
专业媒体制作工具通常使用比典型消费者应用程序更专业的媒体格式。例如，摄影工具将使用 TIFF、JPEG 2000 等格式以及各种不同的原始图像格式。同样，视频工具将使用 REDCODE、ARRIRAW 或 ProRes 之类的东西。
现在对于图像应用程序，我们可以使用 WebAssembly 来进行编码和解码，特别是如果我们已经解决了我们在前面谈到的一些性能问题。但是视频要困难得多，因为在播放、擦除和创作的其他方面保持良好的帧速率非常非常重要。
现在，通过视频元素在网络中提供了获取硬件加速视频的能力，很快我们将可以通过 WebCodecs 等 API 进行访问。但这些 API 的一个问题是，它们仅适用于主流的面向消费者的格式，如 AVC 和 VP8 和 VP9。
现在，不幸的是，媒体编解码器面临一个不可避免的挑战，即其中许多都受到知识产权问题的困扰，这使得确保它们始终在所有设备上可用变得更加困难。所以我们这里可能需要一些方法来访问可插拔或模块化的硬件加速功能，因此当设备上存在此功能时，应用程序可以访问它。
体育广播的现场和后期制作
在 UEFA Euro 2020 和 Tokyo 2020 期间，基于网络的技术主要用于现场和后期制作。应用工具主要分为直播与流媒体、后期制作与剪辑、AI增强制作三大类。这些工具是基于 HTML5 和 ffmpeg 技术实现的。下表列出了使用的协议和技术。
直播编辑工具
我们来看看直播编辑工具。最喜欢的功能是剥离和发布。为了在 30 秒内制作和发布视频，我们做了很多改进。
首先，用 ffmpeg 将直播流统一重新编码为 HLS，并在2秒内对每个 ts 文件进行切片。二是快速压缩 720p 低码流进行网页浏览和编辑。第三，提供关键帧图片，通过 DOM 展示在操作轨迹上，方便截取定位。四、添加 video.js 播放对象，模拟脱条后快速浏览内容。第五，使用后台服务进行并行处理以提高性能。第六，使用 CDN 缓存。
而且还有一个问题，就是两个 video.js 对象有两个播放窗口，都需要下载 m3u8 文件。我们希望他们可以共享数据，避免重复下载，节省网络带宽，以便我们可以同时打开更多窗口，预览不同时段的内容。
后期制作与剪辑
可以看作是直播编辑工具的升级版。在这里，我们追求的不再是时效，而是专业。
我们需要通过复杂的多轨对象控制不同类型的内容，并通过画布显示。这里的难点在于处理性能和效率。如何做到这一点？
首先，对于整个架构，它保持了 WebGL 模拟，媒体服务最终处理的方式，以减少 Web 负载。其次，我们尝试将显示内容的窗口分辨率控制在 480 * 270。这是因为通过 WebGL 进行高分辨率渲染特效处理会占用普通笔记本电脑 80% 的 CPU。第三，为了不延迟鼠标悬停预览内容，我们在上传时使用 ffmpeg 将内容重新编码为HLS。最后还有一些操作优化点，比如提供一个 H5 小编辑窗口，供用户在上传时对需要的内容进行预处理和剪切。
我们试过用 Webcodecs 来实现，很方便，但是需要逐帧处理。不得不说，定位和剪辑内容不是很友好。最简单的方法是使用 ffmpeg 的 WebAssembly。我们希望 WebCodecs 能够支持更多这样的功能。
架构
综合来看，我们选择前轻后重的 W/S 架构，主要是三个原因。首先是上面提到的性能问题。其次，为了灵活性，Light Front 可以很容易地集成到商业应用中。三是为了兼容性。后台服务可以为云端的各种终端提供 API。好的，我们可以实现快速的业务集成，强大的复用性，易于扩展。
AI 增强制作
为了低成本制作更多内容，我们加入了AI功能，如自动加标签、自动加字幕、自动去水印、自动横竖屏、自动剪视频等。
经验总结
最后，让我们回过头来看看我们为什么选择网络编辑技术进行在线运营和制作平台。
以一家拥有 200 名员工的媒体公司为例。首先是版权的需要。通过网络编辑，我们可以将内容复制、下载和泄露的风险降到最低。二是操作的需要。用户可以通过在线修改和重新提交内容进行操作，节省大量时间。三是研发需求。如上所述，为了更好的性能、灵活性和兼容性。第四，为了成本。与购买工作站相比，使用共享云服务器可以节省 80% 以上的成本。五、建设和成熟周期更短，可节省 70% 的时间。
http://mpvideo.qpic.cn/0b2ewqaamaaapiaag4lrgzrfbngda22aabqa.f10002.mp4?dis_k=8533ad1f268fe4a554ffee788967c047&dis_t=1653388247&vid=wxv_2382061865079504896&format_id=10002&support_redirect=0&mmversion=false