2020年WebRTC的下一步是什么

了解更多关于流媒体分析的信息流媒体的下一个事件.

从流媒体东部观看完整的演示， VES204. 在低延迟流媒体服务中部署WebRTC，在… 流媒体会议视频门户.

阅读这段录音的完整文本:

Dr. 亚历克斯Gouiallard: 明年呢?? 这取决于你问谁. 如果你问谷歌，他们说得非常非常清楚，AV1, QUIC和Web Assembly . 因此，LAPI在新WebRTC中的角色将允许人们使用JavaScript或其他语言自带编解码器. 幸运的是，JavaScript还不够快，这就是WASM的作用，它实际上有一些纯粹的基于web的加密和编码. 等等......。, 然后, 您不依赖于浏览器实现, 你不受他们支持哪种编解码器的限制, 您只受CPU和WASM容量的限制. QUIC超级超级热, 我甚至不打算去那里, AV1是一种新的编解码器, 我们稍微讲了一下, 很明显，你可以在这里阅读副标题, 视距, 正确的. 我想要一个更好的压缩和更好的网络弹性, 质量差的交通工具可以更快地建立一个机构，可以使很多东西多样化, 数据等等.

QUIC的一个非常棒的用例是，您可以在数据和视频帧之间实现完美的同步, 这是你今天在WebRTC的数据通道中无法做到的. 这意味着AR，对吧. 对于AR来说，你需要拥有与框架完全同步的数据，而现在还不是这样. 所以即使你看所有的Facebook和所有其他人工智能或虚拟现实的东西, 当你移动时，你会看到它有点结渣，这是因为数据通道和媒体没有同步. 有了QUIC，你将能够在相同的传输中使用相同的时间戳, 所以设计上是同步的.

根据Facebook的说法，它是QUIC, QUIC，而且只有QUIC. 实际上我可以把Akamai放在这里. Akamai就像, 我想考虑TC, 我将直接跳到QUIC上，我将在QUIC上做媒体，这将是非常棒的, 我不知道能不能成功，但肯定很棒. 所以Facebook上周开放了他们的堆栈. 非常棒的实现，他们在生产中使用的非常高级，代码很干净. 到目前为止，QUIC有13,12,13个实现. 它们或多或少是学术性的，或者是为标准本身工作的人准备的.

他们已经在生产中使用了一年了，所以他们实际上不仅提供QUIC堆栈，还提供用于负载平衡的服务器等等, 它是美丽的. 所以如果你想了解QUIC，不要阅读规范，直接去GitHub，它真的很好. 根据AOMedia、英特尔和Netflix的说法，它是AV1. 所以这里有一点策略. Netflix和英特尔宣布将实时实现AV1编码器的原因也是因为他们试图为AV2定位.

正确的, 所以他们想要取代利比亚, 英特尔和Netflix的SVT-AV1实现的amedia成员使用的官方实现是什么. 这将为他们在讨论和amedia内部的政治事务中提供更多的杠杆作用. 但如果你不追求实时，它是一个很好的编解码器. 如果你在寻找视频点播, 它真的很好，即使在普通的戴尔现成硬件上也能运行得非常快.