Google Stadia
对于Google Stadia，Google使用QUIC代替SCTP作为控件，用WebRTC进行实时流式传输。
但这还不够。Google Stadia需要更低的WebRTC延迟。因此，Stadia添加了一个Chrome实验来减少WebRTC中的播放延迟。我的一些客户已经采用了这项实验，并对自己用例的结果感到满意。
Google还调整和改进了VP9解码器，使其可以处理4K 60fps流。
对于Stadia，需要开发者在WebRTC代码库内部进行更改，以使其无论在哪都能很好地应用其服务。
Google2020年的WebRTC策略将发生什么变化？
WebRTC 1.0版本几乎已“退出”舞台。
最新的CR（候选推荐书）日期为12月13日。希望这是我们进行下一步前的最后一个CR了。而如果查看WebRTC的原始章程，我们会发现很有趣的事：
完成上述事项所需的时间比最初预期的要长一些，但我们马上就成功了。
而Google在两个月前就完成了WebRTC 1.0代码的内部升级。
那么接下来呢？
除了管家服务、bug修复和计划WebRTC NV（下一个版本）之外，我认为很大程度上Google会由内部调整转向如何在WebRTC上投入更多的资金，从而保持或提高市场竞争力。这是一个开源项目，意味着某些功能将需要保留在开源代码库之外。就像Google Duo中新的丢包隐藏机制一样。
这要如何实现？
首先要做的是提高开发人员的灵活性和控制力，使其理解WebRTC的内涵及其运行方式。理想情况下，如果使用WebAssembly以及未来的WebTransport和WebCodecs这两项新计划的话，会分拆WebRTC的很多东西。这样就可以从基准实施中分离改措施进，并将其作为专有功能引入。
Google将在WebRTC代码库中使用什么内容，以及将哪些内容排除在外，将通过使用机器学习和人工智能来决定。每当某个功能利用成熟的机器学习模型时，Google就极有可能会尝试将该功能保留，不使其进入WebRTC。 为什么？ 因为该功能如今价值最高，所获投资最多。
你该为此担心吗？
也许是的，但这是我们早该预料到的。
Google在WebRTC上投入了大量资金。没有它的投资，我们如今觉得理所当然的、在WebRTC中看到和使用的一切都不可能成为现实。
而且其投资持续了这么长时间也令人惊讶。
WebRTC弥补了媒体引擎的基本空白和要求。我们不应奢望更多。如果你想改进WebRTC，或想要处于WebRTC技术的最前沿，就需要自己投资。我们无法仅依靠Google，这从来都不是一个好选择。
有了WebRTC，2020变得有趣也复杂起来了！
文章作者：Tsahi Levent-Levi
