1

WebRTC在低延迟媒体流之中的地位

已有 237 阅读此文人 - - Uncategorized -

作者:Tsahi Levent-Levi(原文链接

翻译:刘通

原标题:The Role of WebRTC in Low-Latency Media Streaming

lowlatency1

Adobe最近给Flash写了一篇讣告,宣布Flash将在2020年退出历史舞台。我们已经知道了Flash大限将至,所以应该好好地来选一选它的替代品了。

使用Flash的一大好处就是它依赖RTMP协议所提供的媒体推流功能。现在很多浏览器已经让Flash的使用变得很困难了,所以很多内容供应商以及流服务都已经开始放弃Flash和RTMP转而寻找其他选择了。

有什么其他选择?

Flash的替代品有HLS和MPEG-DASH,这两个的工作方式比较相似。主要功能是给设备和浏览器发送媒体数据,在它们所适用的场景中相比延迟更加看重传输质量。

HLS和MPEG-DASH使用的是封包传输模型(packetized delivery model),这种模型基于一个清单将视频块切割并重组—如果有视频块在传输过程中丢失的话,为了保证数据的质量就需要对丢失块进行重传。所以,这两种的实现需要进行适当的缓存,在所有数据都可用之前要保持等待,然后再播放给用户。一句话来概括就是,传播失去了实时性。

一种解决办法是尝试改进HLS和MPEG-DASH实现,将他们优化到更低的延迟水平。或者选用Flash的第三种替代品,也就是我们今天的主角—WebRTC

WebRTC:更高需求,更低延迟

媒体流和实时视频通话的主要区别是强度:实时视频通话在两端需要提供更好的“及时”性。用户们需要与对方进行互动,并且一直需要知道对方的状态。这就意味着他们需要在任何可能的状况中都保持状态,也就需要消耗很高的计算资源。

媒体流,不需要这种紧密的连接。我们同一时间会发生两种独立的会话:广播者和媒体服务器,以及媒体服务器和他的观众—每个都有他们自己的一套规则,性能,优化以及需求。

当你用一个实时视频通话技术来进行一个媒体流场景时,通常都会遇到范围问题—让大范围传输受到限制。

原因是运行WebRTC需要额外的资源。这也符合常理,因为传输的延迟越低,我们所需要花费的资源和能量也就越多。

lowlatency2

尽管使用WebRTC的代价要比使用HLS高,但是使用WebRTC还以为着你可以达到任何低延迟的要求。

WebRTC进行流媒体传输的未来

WebRTC已经面世6年了。绝大多数时间,它都被用来做视频通话。大家试着使用WebRTC进行直播流也只是2到3年前的事情,解决方案大多都是针对广播者的。

举个例子,很多网络会议平台选用WebRTC,最终都只是在广播端才使用,将观众端留给延迟更高的技术。这些解决方案使用的是广泛应用于视频通话的开源以及盈利的技术。

随着Flash慢慢淡出市场,新的,更有交互性的直播流服务正在崛起,我们看到有新的服务提供商以及实现方案在更适合推流的领域使用WebRTC。

这些解决方案都会减少设备之间隐私的需要,低于视频通话的状态,为了提高范围并且降低成本。他们不再谈论SFU和同播,而是将精力聚焦于像ABR(Adaptive Bitrate,自适应码率)这种缩写词。

WebRTC一定会在实时流媒体技术中排在前几位。让我们对这项新兴技术的未来拭目以待。

期待你一针见血的评论,Come on!

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