W3C: 媒体制作 API (1)

2022-04-11 19:34:06 浏览数 (1)

来源：W3C/SMPTE Joint Workshop on Professional Media Production on the Web 主讲人：Sergio Garcia Murillo (Cosmo Software)，Qiang Fu (Bilibili)，Patrick Brosset (Microsoft) 内容整理：彭 峰 三位演讲者分别介绍了自己所在公司在 web 流媒体和交互性方面的工作。WebRTC 中硬件编码器和广播工具可以在传输层上进行沟通，但是没有办法在信令层上进行交互，Sergio 介绍的 WHIP 可以解决这一问题。Qiang Fu 介绍的 web 浏览器的视频转码能够使得开发人员无需对编码有详尽的了解也能实现较好性能的视频转码。Patrick 介绍了一个小而实用的 API，使得基于 Web 的颜色创意应用开发更加容易。

目录

  • 让 WebRTC “成型”
    • WebRTC 的现况
    • WHIP (WEBRTC HTTP INGESTION PROTOCOL)
  • 在浏览器中转码视频
    • 视频转码
    • Web 浏览器的视频转码
  • The EyeDropper API
    • 颜色创意应用
    • EyeDropper API

让 WebRTC “成型”

WebRTC 的现况

由于 webRTC 不是端到端而是点对点技术和多方会议是主要用例，广播行业对它的看法从来都不是很好；也没有被视为流媒体的可行解决方案，因为它无法扩展，且难以使用。传统的流媒体行业主要由 Netflix 或 Hulu 等为代表的视频点播模式主导。然而，新冠病毒的大规模传播改变了这一切，它加速了实时媒体工作流程的采用，最终弥合了网络和广播之间的差距。

实时媒体需要接近于零延时来实现较强可交互性，新的用例使得大型专业级工作流在消费级设备中成为可能。而 WebRTC 正是提供这种实时媒体的完美技术。其目前已经实现了一些最初的设计目标，尽管存在一些瑕疵，但通过端到端加密或同步广播和支持 SVC 等附加属性，在网络规模上提供具有广播质量的高质量媒体是可能的。

然而，由于缺乏标准的信令协议，WebRTC 无法广泛使用各种可用的工具，也无法在流媒体世界中日常使用。例如 OBS、FFmpeg 或 vMix。更不用说缺乏硬件编码器和物理输入源，而现实情况中硬件编码器和物理输入源早已集成到许多专业的媒体工作流程中。

在广播行业，RTMP 仍然无处不在，用于直播和媒体摄取，进入数百甚至数千个媒体平台。当直播摄取内容时网络网络波动，WebRTC 提供的技术优势可以不增加端到端延迟。当我们试图利用 WebRTC 进行媒体摄取时，需要意识到虽然 WebRTC 是最好的实时流媒体传输协议，缺乏一个标准的每个 WebRTC 协议的现况使得流媒体服务需要实现一个定制协议，这使得硬件编码器和广播工具无法采用它。

WHIP 现存问题

WHIP (WEBRTC HTTP INGESTION PROTOCOL)

尽管其他媒体传输也可以用于媒体摄取，但同时使用 WebRTC 进行摄取和传输使得浏览器可以完成所有的工作，避免了协议转换带来的延迟和实现复杂性，并且通过设置共同解码器来可以避免码流转换。所以解决方案很简单，我们只需要一个参考信令协议。这个新协议的要求是它可能更容易实现，并且在当前 RTMP URI 下易于使用。并且仅支持特定的摄取用例，即 WebRTC 可能用例的一个子集，因为我们只需要支持单向流，以及不用考虑重新协商。

WHIP 示意图

为了完全兼容 WebRTC 和 RTCWeb 规范，必须降低要求和复杂性，以重新实现它，这样它可以被硬件编码器和广播工具采用。此外这个新协议应该尽可能地复用当前的 Web 技术，所以使用HTTP POST 来交换 SDP。连接状态由 WebRTC ICE 和 DTLS 状态控制。该协议的标准化工作正在 IETF 中进行。已经有一些平台实现了该协议，比如 Millicast 或以 Janus 为代表的媒体服务器，也有一些基于 GStreamer 的客户端实现，当然还有 JavaScript。

但这就是在专业媒体流中使用 WebRTC 所需的全部内容吗？不幸的是答案是否定。而且这主要不是因为缺乏规范，而是主要是因为大多数浏览器所需的许多功能的实现都落后了，即使有 API 可以启用它们，大多数时候，它们处于实验状态或隐藏在旗帜后面，无证或难以发现。例如，在音频方面发现的一些问题是可以使用 Multiopus 支持多声道音频。而 Multiopus 不是官方标准，只有 Chrome 支持。它是隐藏的，它请求 SDP 修改以支持它。又或者 NetEQ，即所有 WebRTC 浏览器中的抖动缓冲实现，都存在音频问题。另一个例子是 WebRTC 和 WebVTT 之间缺乏集成，使得实时字幕成为不可能。

在视频方面也有类似的现象，例如：

  • SVC 扩展 API 仅在 Chrome 中工作，这是一项实验性功能，尽管这可能会在接下来的几周内发生变化。
  • AV1 仅受 Chrome 支持，并且未在 Edge 中启用，即使它们共享几乎相同的代码库。
  • 支持 10 位的 VP9 配置文件仅由 Chrome 支持，并且仅在接收端。它在 Safari 中是实验性的。
  • playoutdelayhint 是一个可选扩展，仅在 Chrome 中受支持。
  • abs-capture-time 是一个标头扩展，可用于将视频与标准元数据同步，仅在 Chrome 中支持，但它再次被隐藏，需要 SDP 修改才能启用它。

总结来说，WebRTC 今天是可用的，即使它是以最小延迟交付专业广播质量媒体的最佳选择，但为了能够 WHIP WebRTC 成形，还有很多工作要做。

http://mpvideo.qpic.cn/0bc3h4aagaaayqahbbkk75rfap6dam7qaaya.f10002.mp4?dis_k=3822fac4e17c0e27d871acb7cf72af94&dis_t=1649676715&vid=wxv_2339654124214255617&format_id=10002&support_redirect=0&mmversion=false

在浏览器中转码视频

视频转码

某些视频格式（如 AVI 或 FLV）不能直接由 HTML 播放，可以通过 WebAssembly 或 JavaScript 为这些视频实现播放器，但是如果我们将它们转码为 MP4 或 WebM 格式，那么可以使用视频标签以 HTML 格式播放。此外对于某些视频，只需要进行小的调整便可以更改视频的分辨率和帧速率或其他一些参数以满足上传的要求，这些要求可以通过网络浏览器中的视频转码器来实现。

为什么需要视频转码

为了实现视频转码，首先将输入文件传递给 DEMUXER 以访问流和编码的视频块，然后将视频块传递给解码器以获取视频帧。之后，也许需要在框架上执行一些操作。通过它相反的方式后，最后得到了输出文件。ffmpeg 的视频转码流程如下图所示，但是在浏览器中，该如何实现视频转码？

ffmpeg 的视频转码流程

Web 浏览器的视频转码

Web 开发人员有一种流行的方式来实现视频转码，WebAssembly 可以提供帮助，将 ffmpeg 的源代码编译成 WebAssembly 后，在浏览器中运行并给它一个命令，就可以得到了需要的视频，乍一看真的很简单。但是 WebAssembly 看起来像一个黑盒子，开发人员并不关心其内部细节。

使用 WebAssembly 的过程中会出现一些常见问题，最主要的是为什么它这么慢，为什么相同的命令可以在浏览器和操作系统之间产生如此巨大的性能差异。怎样才能让它更快？答案是艰难的。WebAssembly 做了改进，为了支持 SIMD 和多线程。然而为了享受这些新功能，检查 EMScripten 和 ffmpeg 的配置是不可行的，需要修改 ffmpeg 的源代码，这对于 Web 开发人员来说，这确实是专业且艰难的。

为了实现浏览器转码，可以将转码过程分成不同的部分，每个部分可能有一个独特的解决方案。例如，demuxer 和 muxer 可以通过 JavaScript 实现，编码器和解码器可以简单地使用 WebCodecs API，视频帧可以在画布或 WebGL 上绘制。以集成方式测试，像乐高积木一样拼接每个部分。如下图所示，以集成方式对视频进行转码，解复用器和解码器集成为视频播放器。减少 WebAssembly 的大小，为 ffmpeg 导入了一些库并派生了一些文件。播放器的输出是 RGB 或 YUV 格式的视频帧。我将它传递给 WebCodecs API 以获取编码的视频块。然后这些块流过一个复用器，用于在 WebM 中制作视频以供观看，最后我得到了需要的本地视频。

视频转码器在浏览器中的集成

集成方式似乎足够灵活，甚至可以通过 JavaScript 更改画布中的框架，就像过滤器在 ffmpeg 中所做的那样，WebCodecs 很酷，它有硬件加速选项，开发人员不需要关注细节。唯一需要担心的是复用器。每个复用器都是不同的，我必须独立收集支持 MP4、WebM 和其他格式的解决方案，这需要很多时间。如果提供了官方的 muxer API，它的设计可以遵循 WebCodecs。

Web 浏览器的视频转码将获得以下好处。首先，它将完成浏览器中媒体处理的路线图。而如果我们想要普及一些视频格式，比如 WebM，应该降低制作它们的难度。这个工作最有价值的是它提供更好的编码体验，ffmpeg 的源代码真的很难，需要很多时间才能成为真正的专家。

http://mpvideo.qpic.cn/0b2euqaaaaaaqiahjvsk65rfbjgdacsaaaaa.f10002.mp4?dis_k=283b6b508f5db003f44ab8f1a8d89923&dis_t=1649676715&vid=wxv_2339654837581479936&format_id=10002&support_redirect=0&mmversion=false

The EyeDropper API

颜色创意应用

采样颜色创意应用程序是非常有用的东西，例如当使用 PowerPoint 之类的工具并且想要更改对象轮廓的颜色时，可以使用 EyeDropper 工具从不同的对象中获取颜色，这样就不必记住它是什么颜色，或者记住代码。浏览器中的开发者工具也有这个功能，如果想在开发工具的样式面板中更改颜色属性，通常有一个 EyeDropper 图标，允许点击网页的一部分，这样就可以立即获取该颜色，而不必记住十六进制代码。再例如 Photoshop 或类似 Photoshop 的应用程序通常也允许直接获取颜色。不幸的是，在网络开发中不能这样做。因此，如果现在正在使用 Web 技术开发创意应用程序，就无法做到这一点。

Sampling colors creative application 示意图

有一种方法可以在 Chromium 浏览器上执行此操作。如果在 Chromium 浏览器中使用输入类型颜色元素，则单击该元素后，你将看到一个下拉菜单，其中将包含一个允许执行此操作的 EyeDropper 图标，但这是非标准的，它在 Firefox 中的工作方式不同，例如，它具有此处显示的典型或默认颜色选择器调色板。此外，输入类型颜色很难用 CSS 设置样式，而且它是一个额外的 HTML 元素，你可能不想添加到标记中，如果可以直接从 JavaScript 驱动该功能就更好了。

这就是我们创建这个 EyeDropper API 的原因。这是一个新的 API。它现在被指定为 WICG 草案规范。它已通过 W3C TAG 审查，并由 Microsoft Edge 的工程师在 Chromium 开源项目中实施，因此目前可用于任何基于 Chromium 的浏览器，这也是与 Google Chrome 人员密切合作完成的。

EyeDropper API

演讲中展示了一下操作，表明 EyeDropper API 的易用性。如下图所示，EyeDropper API 的核心是 EyeDropper 类，如果想使用 EyeDropper，请实例化该类，然后你将获得一个可以调用 open 方法的对象，如果调用 open 方法，请立即打开 EyeDropper，用户可以从整个屏幕中选择颜色。详细细节可以参考 https://github.com/w3c/media-production-workshop/issues 上的讨论。

EyeDropper API 的使用

这是一个非常简单但很实用的 API，但有一些关于安全和隐私的疑虑——如果随机网站能够在屏幕上收集任何像素的颜色，那可能是一个问题。当使用开始跟踪鼠标的坐标，会不会揭示用户不应该在网上交换的信息。API 以下列方式解决了这些问题。首先，无法在用户操作之外使用 open 方法；其次，一旦调用了 open 方法，浏览器应该以非常非常明显的方式显示 EyeDropper 模式，屏幕会出现一个放大镜，因此，对于用户正在进行的用户来说，这是非常明显的，这不是通常出现的普通光标；然后，当用户移动鼠标时，API 无法从任何像素收集颜色，必须再次有一个用户行为——通常单击像素，才可以获得颜色的，否则就不行；最后，用户控制整个过程，可以选择任何时候结束 API 调用。

http://mpvideo.qpic.cn/0bc3nmaagaaakqahpi2k6frfa26danvqaaya.f10002.mp4?dis_k=9ed68c86b6862d91cf81efb9271bf8ff&dis_t=1649676715&vid=wxv_2339655258723155968&format_id=10002&support_redirect=0&mmversion=false

api 网站 视频处理 tcp/ip

0 人点赞