W3C开发专业媒体制作应用1
来源：W3C/SMPTEJointWorkshoponProfessionalMediaProductionontheWeb主讲人：ChristophGuttandinandSachaGuddoy内容整理：张志宇ChristophGuttandin介绍了他对行业发展的一些愿望，SachaGuddoy则介绍了直播媒体制作中的WebRTC。
目录
无论能做什么，都会做
愿望清单
更贴合实现者的愿望
总结
直播媒体制作中的WebRTC
Grabyo简介
流同步化的使用场景
流同步化的挑战
MediaStreamTrack插入流
无论能做什么，都会做愿望清单愿望清单当我被要求为这次研讨会准备演讲时，我认为这是一个向世界表达我们愿望的绝佳机会。因此，我要求我的同事帮助我准备一份清单，其中包含我们希望在某个时候实施或我们已经实施但如果可能的话真正希望以更好的方式实施的东西。
自定义编解码器自定义编解码器清单上的第一个项目是将自定义编解码器与WebRTC一起使用。你可以通过对音频数据和视频数据进行编码来做到这一点。然后你可以忽略WebRTC的媒体功能，并通过DataChannel发送数据。但整个过程非常繁琐，至少对于视频来说，它不是很准确。每个视频帧都需要绘制到画布上，然后需要从那里抓取，将其移交给WebAssembly。当实时使用时，你很可能会丢失几帧。
幸运的是，我们现在可以使用WebCodecs以更有效的方式做到这一点。但到目前为止，WebCodecs仅在Chromium浏览器中可用，Firefox正在研究它。
部分解码部分解码清单中的下一个项目是部分解码，指的是只能解码媒体资产的特定范围或者某个特定帧的能力。对于音频来说，有一种非常黑客的方法，它通过使用decodeAudioData()方法工作，此方法在AudioContext上可用。但它会自动将音频重新采样到AudioContext的采样率，这意味着在进行实际解码之前，需要手动解析文件，以了解正确的采样率。decodeAudioData()仅适用于完整文件，这是在解码前需要解析文件的另一个原因。我们需要弄清楚在哪里可以切片，虽然这并不容易弄清楚，但对于大多数文件类型来说这是可能的。如果操作正确，decodeAudioData()会很乐意解码文件的一部分，因为它认为它正在解码整个文件。但是，decodeAudioData()在最新版本的Safari浏览器中坏了。该错误已经在代码库中修复，但是不知道该修复程序何时可供Safari用户使用。
要解码单个视频帧，可以使用媒体元素加载视频，然后使用seekToNextFrame()逐个获取帧。但这只适用于Firefox。
但是，既然在Chromium和Firefox中都支持WebCodecs，所以这些都不再必要了。
下放工作下放工作另一件至关重要的事情是尽可能多地将工作下放到其他线程。最后，主线程应该只是用于触发工作，而不是用于操作。
有一些API已经遵循了这种模式。其中之一是AudioWorklet和WebAudioAPI。对于视频内容，有OffscreenCanvas，可以在WebWorker中使用。最后但并非最不重要的是，可以将TransformStream插入MediaStream，并将其传输给WebWorker。
媒体同步媒体同步另一件通常棘手的事情是保持媒体的同步。特别是如果涉及一些音频或视频处理，这通常会延迟其中之一，需要确保当情况变得非常棘手时，音频和视频可以再次实现同步。
AudioContext上有两个属性，让我们知道用户何时可以真正听到该AudioContext上安排的声音。这使我们能够确保当时显示的视频帧与音频匹配。但遗憾的是，到目前为止，这些属性仅在Firefox中完全有效。
输出选择输出选择对我们来说，另一个热门话题是可以选择特定的输出设备，而不是使用默认的输出设备。
有一种方法可以调用来更改媒体元素的输出设备，但到目前为止，它只适用于Chromium浏览器，它被称为setSinkId()。据我所知，Firefox目前正在实施selectAudioOutput()方法，这是一种同意访问音频输出设备的新方法。
Chromium浏览器已经公开了音频输出设备。因此，使用setSinkId()并不真正需要实现selectAudioOutput()。
更贴合实现者的愿望无论如何，我想出了一些不再真正与规格相关的愿望，更适合实现者。
发布应该无聊该清单上的第一个项目是，我希望发布尽可能无聊。我认为Chromium浏览器和Firefox确实有一个很好的流程来确保这一点。
nightly版本两个浏览器都发布nightly版本。现在，这是Chromium的97版本和Firefox的95版本。
beta版本nightly版本的状态每4周就会升级到下一阶段。无论当时的nightly版本是什么，都会成为beta版。同样，nightly版本也会增加。因此，今天这些浏览器的nightly版本中的任何内容都将在至少4周内进入beta版。
stable版本再过4周后，beta版成为stable版本，nightly版本成为新的beta版。这就像源源不断的更新，当一项功能到达beta版频道时，您可以计算它向所有普通用户开放的日期。整个过程非常可预测，也超级无聊。
regrssions应该被尽快修复我希望regrssions尽快得到修复。想象一下，构建一个媒体专业人士每天依靠的网络应用程序来完成他们的工作。突然，浏览器更新导致该应用程序失败。我知道即使是Safari浏览器也可以非常及时地获得安全更新。我也希望补丁能修复regrssions，这种情况也会发生。
给用户更多权限我知道一些强大的功能可能会被恶意页面滥用。我绝对同意，默认情况下，每个页面都不应该启用某些功能。然而，我认为浏览器的用户应该可以选择允许某些网站访问文件系统，录制整个屏幕，捕获系统音频，接收MIDI消息，运行高优先级线程等。我认为这在每种情况下都不需要是明确的权限提示。它也可以是一条小小的吐司式消息，弹出来通知用户特定API或完全不同的东西的使用情况。重点是，我认为应该授权用户自行决定他们想要启用哪些功能，以及他们现在最好不想使用哪些功能。
给开发人员更多权限同样，作为一名开发人员，我真的很想拥有同样的权限。正如我之前所说，我喜欢对每个浏览器的当前和即将发布的版本运行自动测试。我在本地这样做，我也通过BrowserStack和SauceLabs等服务在云中这样做。测试媒体API是一个真正的挑战，因为它们通常需要用户交互才能工作。但显然在运行自动测试时没有用户。可以为Chromium浏览器和Firefox设置标志。但它们并没有很好地记录在案，它们总是落后于浏览器的功能，可悲的是，它们有不时断裂的倾向。至少据我所知，在以编程方式启动浏览器时，甚至无法在Safari浏览器中禁用自动播放策略。这意味着在Safari浏览器中测试更困难。这反过来意味着错误的捕获更少。这当然是一个真正的问题，因为正如我之前所说，一个典型的错误会在Safari浏览器中停留至少6个月。
总结最后，我想再次重复这次演讲的标题：技术的基本规则是，无论能做什么，都会做。我认为为网络构建专业媒体应用程序是今天可以做到的。我知道很多人都在做这件事，我希望并相信，这成为新常态只是时间问题。
附上演讲视频：
直播媒体制作中的WebRTCGrabyo简介Grabyo简介Grabyo是一个SaaS平台，为商业广播公司提供直播制作工具。一些产品包括直播制作、视频编辑、从直播中剪切以及发布到各种端点。
在Grabyo，我们在现场制作产品中使用WebRTC。这是工作方式，用户将看到，在他们的网络浏览器中，他们将有多个直播，他们将能够监控这些直播，并选择哪些直播被输出到他们的广播端点。我们还拥有多个边车应用程序和多窗口工作流程。例如，弹出一个播放器。
流同步化的使用场景流同步化的使用场景我们面临的挑战之一是流的同步化问题。我们想做的是让来自不同相机的多个直播馈送进来，并能够在它们之间切换。但是，如果我们的直播没有完全同步，如果这两个相机没有完全同步，那么当你在它们之间切换时，它们之间会非常明显，它们之间有一些延迟，这对观众来说很刺耳。
当您的页面上有多个WebRTC流时，保持所有这些流的同步不一定是最直截了当的事情。浏览器会尽力而为，但它们没有绑定在一起。因此，例如，如果您在不同的相机之间切割，您希望这些相机完全同时显示。如果您正在进行多方聊天，也不会想要延迟。
流同步化的挑战流同步化的挑战同步方面相当困难。网络条件可能是不可预测的，您实际上没有办法纠正这一点，也没有办法与客户端的流同步相协调。如果流上有嵌入式时间戳，那么您可能会这样做，使用较低级别的东西，例如Web传输。
在上下文之间共享连接我们最近使用的一种模式是将工作流程划分为不同的浏览器上下文。能够创建一个弹出窗口，允许您在一个窗口中监控特定视频，并能够在另一个窗口中监控其他所有内容。
或者能够在一个窗口中编辑音频，并在另一个窗口中监控您的视频。在最后一个场景中，您将在浏览器中有两个相同WebRTC连接的实例。如果我想将实时流的视频放在一个窗口中，因为这是我的视频控制套件，并且我想在另一个窗口中拥有相同的实时流，因为这是我的音频控制套件，那么我必须有两个WebRTC连接。这是头顶性能的两倍，带宽的两倍，等等。
我们考虑了SharedWebWorkers的工作方式，即SharedWorker界面，该界面允许多个上下文共享该Worker中发生的事情。如果我们能对WebRTC做同样的事情，这将大大减少我们的性能开销。
对于专业的桌面应用程序来说，这些类型的工作流程非常强大。如果您是使用某种NLE的视频编辑器，您可能想要尽可能多的屏幕空间用于时间线、显示器、资产箱等。能够将我们界面的不同部分拆分到不同的窗口中，以便用户可以按照他们认为合适的方式定位它们，这真的很有帮助。
这样做有什么好处？资源消耗显然更少，因为你只有一个连接。上下文之间存在固有的同步，因为数据来自同一连接。现在，使用共享工人和网络传输可能是可能的。但浏览器对此的支持不是特别好。Accuracy在这项技术中也很重要。更准确的时间戳可能有助于我们同步这些流。此外，它还有助于同步其他内容。例如，在DOM中同步覆盖层，或者DOM中的通知。
MediaStreamTrack插入流MediaStreamTrack插入流从WebRTC连接中编码和解码数据的能力也非常有用。目前，WebRTC连接的API表面非常小，它不会向我们公开太多有用的信息。能够将我们自己的代码放入该管道将允许我们做所有这些有趣的事情。
例如，当我们想展示一个特定的框架时，它就会出现。例如，从不同的浏览器窗口同步音频和视频。在它们渲染到DOM之前，我们可以确切地知道正在呈现哪个帧，这样我们就可以准备与之同步的DOM元素。我们可能会发送专有的错误更正数据，以优先处理任何链接故障，并优先考虑图像质量。
许多问题都可以使用MediaStreamTrack插入流功能来解决。这仍在规范草案中，我真的很想看到更多的浏览器支持。
附上演讲视频：
媒矿工厂
转载请注明：http://www.abuoumao.com/hyfz/106.html
