作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：The Role of WebRTC in Low-Latency Media Streaming
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需要额外的资源。这也符合常理，因为传输的延迟越低，我们所需要花费的资源和能量也就越多。
尽管使用WebRTC的代价要比使用HLS高，但是使用WebRTC还以为着你可以达到任何低延迟的要求。
WebRTC进行流媒体传输的未来
WebRTC已经面世6年了。绝大多数时间，它都被用来做视频通话。大家试着使用WebRTC进行直播流也只是2到3年前的事情，解决方案大多都是针对广播者的。
举个例子，很多网络会议平台选用WebRTC，最终都只是在广播端才使用，将观众端留给延迟更高的技术。这些解决方案使用的是广泛应用于视频通话的开源以及盈利的技术。
随着Flash慢慢淡出市场，新的，更有交互性的直播流服务正在崛起，我们看到有新的服务提供商以及实现方案在更适合推流的领域使用WebRTC。
这些解决方案都会减少设备之间隐私的需要，低于视频通话的状态，为了提高范围并且降低成本。他们不再谈论SFU和同播，而是将精力聚焦于像ABR（Adaptive Bitrate，自适应码率）这种缩写词。
WebRTC一定会在实时流媒体技术中排在前几位。让我们对这项新兴技术的未来拭目以待。
