0

作者:Varun Singh,JÖRG OTT(原文链接

翻译:刘通

原标题:Visions for WebRTC Next Steps: Fine-grained Media Control in the browser

webrtc-logo

在11月初,W3C宣布推出供候选推荐的WebRTC v1.0,这意味着社区认为该标准是设计完整的,并且正在征求对API实施的反馈。

根据开发人员和浏览器提供商的反馈意见和API实施经验,v1.0 CR预计将在未来几个月内进行修订。这也意味着,除了修正bug以外,当前候选推荐(CR)提案中不会增加新的主要功能。

在最近结束的W3C技术大会/咨询委员会(TPAC)上,我们就WebRTC v1.0的后续发展进行了公开讨论。其中一个主题就是在WebRTC中加入新的传输方式,具体来说就是在WebRTC中采用QUIC。

QUIC传输

一点背景知识:QUIC目前在IETF中作为HTTP/2的替代品。由于它是通过UDP定义的,因此WebRTC有机会试用QUIC作为当前正使用的SCTP/DTLS的数据通道传输的替代品。

在Google工作的Peter Thatcher有一个Chrome中的QUIC工作原型,并提出将QUICTransport和QuicStream加入作为WebRTC的扩展传输。QuicTransport做了繁重的工作,并且是DtlsTransport和SctpTransport的组合。QuicStream紧密映射到IETF中定义的QUIC流,这意味着应用程序可以:

         # 往本地流中写数据(write)

         # 从远端流中读数据(read)

         # 当本地流完成时结束(finish)

         # 重置远端流(reset)

QUIC默认是可靠的。因此,本地流会希望通过例如超时这样的方法进行重置,因为特定的QuicStream已经尝试在合理的时间内提供内容。或者远端感觉它不需要从特定的流中获取数据,因为它已经前进并且可以远程重置它。最后结果是可以在这些QuicStream上构建数据通道,也就是很容易构建“大-有序-可靠”的消息,以及“小-无序-可靠”的消息。

QUIC上的媒体

今年夏天,一些从事RTP的人讨论需要什么才能通过QUIC发送媒体。拓展Peter提出的通过QUIC发送数据的建议,通过QUIC发送媒体将是一件非常棒的事情。

在一个媒体会话的生命周期中,该会话预计将会产生数百万/数千万的流,因此QUIC非常适合发送媒体帧。

与用于媒体的UDP一样,应用程序对其放入QUIC流中的内容有着完全的控制,也就是它可以将MTU大小的包,或者帧,或者一组图像放入QUIC流中。最重要的是,QUIC流是可靠的,并且可以从远端进行控制。如果下一帧或者GoP已经被解码,我们就拥有内置的跳帧或者一组图像。而且,这些策略可以根据网络环境进行调整。

举个例子,在丢包率更高或者延迟更高的网络中,QUIC流的结构与更稳定网络环境中的结构会有所不同。再往下,我们可能会看到QUIC中不可靠的流,这将允许更细度的分化。我只是抛砖引玉,我相信如果人们更深入的思考就会想出更复杂的层次结构,也许会提供更好的质量体验。

我们可以在JS领域上做到这些吗?

webrtc-vs-voip5

目前,QUIC的WebRTC实现可以在Chrome中做实验使用,它可以通过QUIC发送媒体。缺少的部分中,最简单的是将媒体轨道连接到QuicTransport的方式。我们可以通过让浏览器像在PeerConnection API中创建连接的方式来实现它。

但是,我觉得让 JavaScript控制这些是一个明智的做法。在WebRTC v1.0的PeerConnection API中,我们让浏览器管理媒体处理过程中的复杂部分:封装,调整帧速率,帧大小,媒体编码等等。在WebRTC v1.0的未来发展中,浏览器可以将每个加密的帧给 JavaScript来进行封装以及发送给远端端点。远端端点可以决定是播放媒体流还是重置流。其中有无限的可能,对JS赋予更多的控制里意味着具有自适应能力的实时应用将会变成现实。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.