W3C: 开发专业媒体制作应用 (2)
来源：SMPTE 主讲人：Soeren Balko 内容整理：张一炜 本文第一部分介绍了在 clipchamp 中，如何使用 WebCodecs 来进行基于浏览器的视频编辑的流程，对其中存在挑战进行了讲解，第二部分主要围绕 Web 应用中的媒体元素准确性以及 DOM 的同步性方面的挑战，并对 Grabyo 在使用 Web 和基于云的技术来进行视频编辑与分发过程中所遇到的挑战和使用案例进行了讲解。
目录
- 用WebCodecs改进 clipchamp 的浏览器内视频编辑流程
- 介绍
- 将 WebCodecs API 集成到 clipchamp 中
- 集成 WebCodecs 的挑战
- 未来发展的展望
- 媒体元素的准确性和与DOM的同步性
- 背景介绍
- 存在挑战与使用案例
用WebCodecs改进 clipchamp 的浏览器内视频编辑流程
介绍
演讲中主要介绍了 clipchamp 在使用 WebCodecs 方面的工作。clipchamp 是一个完全基于浏览器的视频编辑器，能够带来云服务的便捷性以及桌面应用级的响应速度。
clipchamp 所有的服务都可以在浏览器上运行，并且不需要用户将媒体文件上传，运行成本很低，且能够确保用户媒体文件的隐私性。
但在浏览器上进行视频剪辑仍然是一个有挑战性的问题，主要的困难之处在于视频剪辑是一项比较消耗资源的大型任务，因此如何进行资源分配并确保性能是十分重要的。然而软件编码器对硬件底层资源的访问能力有限，这就对性能产生了一定的限制。另外，在跨浏览器支持方面，还需要考虑不同浏览器的特性进行额外的处理。这些也是 WebCodecs 需要解决的挑战。
将 WebCodecs API 集成到 clipchamp 中
在 clipchamp 中的一般视频剪辑流程中导出部分如下图所示。流程中最复杂的一步为将各个不同的视频片段导出成一个 mp4 文件的过程。其中包括了三个部分，首先在 decoder worker 部分负责从原始的素材中提取出原始帧流，然后将其送入到中间的合成器中，将所有的片段组合在一起，并产生得到另一个原始帧流，并送入到 Encoder worker 中，得到最终的 mp4 文件，这也是目前 WebCodecs 中的处理架构。
clipchamp 中视频剪辑的导出流程
在 clipchamp 的处理流程中，将 FFmpeg 编译的 WebAssembly 与 WebCodecs 的 API结合，用于复用与解复用，文件的 IO 操作，软件编码器的回调函数，滤波等操作。并通过将 WebAssembly 构建调用到 JavaScript 域，包括了初始化编码的配置，推流，拉取编码后的包和关闭的完整流程，用于 clipchamp 的网页应用中。
集成 WebCodecs 的挑战
然而在这其中还存在一些挑战。在整个处理流程中，需要人为的去创建一个视频编码器的预检模拟运行，只是为了获取一些额外的描述数据，如 H.264 中的 SPS\PPS，NALUs 等。使用这些额外的描述信息使得视频数据可以被正确的放在封装后容器格式的正确位置。
另外一个挑战在于，由于 FFmpeg 一般是在命令行中使用，其中的API是同步调用的形式。而浏览器中的基本为异步调用的形式，因此需要将 FFmpeg 的同步调用栈分解成多个异步调用。
未来发展的展望
在对未来 WebCodecs 的发展方向上，演讲者提出了以下4点的展望，以希望 WebCodecs 的使用可以更为简便。
- 添加 back pressure 机制，使得 WebCodecs 的 encoder 可以对传递原始视频的方式进行限流，能够提示缓冲区是否已满。
- 现在的 WebCodecs 的编码配置方面，只有对码流的控制。但在视频剪辑的场景中，更希望能够有针对质量的控制，而不是通过调节比特率来控制不同的图像质量。
- 提供对HDR 以及 HEVC 解码器的支持。
- Webworker 中使用 WebCodecs API 的同步调用风格也会很有用。
附上视频：http://mpvideo.qpic.cn/0bc3eqabwaaaemaiwv264brfajgddmsaagya.f10002.mp4?dis_k=4c5af56b7d8863d4246257525ffca465&dis_t=1653387897&vid=wxv_2361764810805313536&format_id=10002&support_redirect=0&mmversion=false
媒体元素的准确性和与DOM的同步性
背景介绍
演讲中首先对 Grabyo 进行了介绍，Grabyo 是一个用于广播制作的 SaaS 平台，它的用户群体主要是商业广播公司。Grabyo 使用 web 和基于云的技术来为广播工作流提供远程分发的能力。提供的服务主要包括了直播视频制作，直播视频流剪辑，非线性编辑以及将创意媒体发布到各种终端等。
存在挑战与使用案例
媒体制作工作流中一种常见的技术为是先为媒体创建一个低分辨率、低码率的草稿版本用于编辑工作。而在完成编辑后，则将其输出到一个性能更强的机器上去使用更强大的资源进行渲染操作，并得到最终的高质量版本。在 Grabyo 中，具体的做法为用户在 web 浏览器中选择视频的入点和出点后，再将其发送到另一个在云端的服务器来进行最终的处理和渲染。
定位帧的精度
在这种工作流中，存在的问题在于从 web 中得到的媒体元素时间戳是不准确的。当另一个应用加载相同的时间戳时，并不能够代表处理的是视频中的同一帧。这将导致在导出视频后，回放时查看的入点和出点可能会存在一帧的偏差。这在专业的视频工作流中是不允许的，并且在很多情况下，这种偏差会非常明显。
因此，为了获取用户处理视频的确切位置，一种做法为使用 HTMLVideoElement 的 current time 属性，这样做的问题就是准确度不够高。该属性是以秒为单位的，只能给到两位小数的精度，因而只能精确到百分之一秒。而对于一个 60 fps 的视频来说，其中每一帧的时间在 16ms 左右，因此使用百分之一秒的时间精度无法做到严丝合缝的切换到准确的帧上。并且，不同的视频渲染工具可能也有不同的时间定义，这就使得准确的同步成为挑战。可以通过使用 PTS，高分辨率的时间戳，以及使用针对帧数的 getter 与 setter 来解决。
DOM 同步
另一方面，在与DOM的同步中。DOM接口一般用于实时操作和监控媒体，例如控制播放的位置和状态，监控音频水平，分析和操作视频，显示覆盖元素以及将不同的媒体片段同步到一起。在这些任务中，都需要 DOM 能准确反应当前媒体的状态。通常来说，DOM 中的这些元素会随着媒体一起更新，可以使用事件监听器，或者使用requestAnimationFrame来进行。
由于 DOM 与媒体元素不在同一个线程中运行，所以二者之间已经不是同步的关系，DOM 的更新依赖于主UI线程。这就意味着任何的用户交互，或在 DOM 线程中运行的其他东西都有可能阻塞 DOM 的更新，导致 DOM 对媒体中的时间描述可能是滞后的。并且，更新 DOM 的性能成本也可能很高，比如在媒体中如果音频水平每秒更新了60次，DOM 也就需要更新60次，这对 UI 线程来说也是一个不小的负担，会导致用户体验的明显下降。
编解码器
所有主流浏览器都自带一系列的视频编解码器，通过对编码器支持的扩展以及对解码器的底层访问，可以实现新的功能。例如，使用帧内编码进行缩略图的快速搜索，在解码器部分保留特定时间片段的视频元素用于非线性编辑，将 PTS 等元数据集成到其中，以及进行专有纠错等。
在这方面，WebCodecs 可以帮助解决很多问题，包括在底层访问解码流程。
多线程
在媒体制作工作流中，经常需要在处理 UI 的同一线程中执行媒体操作，例如将视频渲染到画布上。然而目前这些任务的表现并不是很好，因为有些任务是相当耗费资源，并且运行相当频繁，阻塞了 UI 线程，降低用户体验。因此如果需要在画布上绘制视频，这可能需要在每个 requestAnimationFrame 中运行。
因此解决这一问题的传统方法就是使用多线程，即 WebWorkers。WebWorkers 支持在其中执行密集的线程。这样就能够提供一个后台的画布接口，允许 WebGL 在 woker 的边界内向画布渲染。但目前存在的挑战在于，视频元素中没有一个对等的 API, 因此视频元素不能在 worker 中被访问，且视频元素到画布的渲染过程需要在 DOM 线程中执行，不能单独运行在 Worker 中。这可以通过允许视频元素的获取与生成不影响主线程的情况下进行来解决。
附上视频：
http://mpvideo.qpic.cn/0bc3saabuaaarmaiufc64frfbegddkiaagqa.f10002.mp4?dis_k=824804b920294c3c90ae891db8316af6&dis_t=1653387898&vid=wxv_2361765136652402689&format_id=10002&support_redirect=0&mmversion=false