低延迟流媒体对高速的大量需求(三)

第二个级别是“提前剧透”,比如你邻居是个体育粉,他在隔壁看电视播放的体育比赛。突然他因为某个球员触地得分激动地狂喊,还发了推特。但你在30秒后才在电视上看到这一情景。这个例子和延迟的道理一样。大多数广播频道的延迟时间约为平均5-10秒;如果不要求提供显著优于广播方式的流媒体传输,则基于HTTP的技术大多数延迟时间约为2至5秒。

第三个级别是“实时”,多见于交互式应用程序,比如对用于赌博或拍卖的应用程序来说2秒的延迟也显得很长。至少目前,基于HTTP的技术可能无法大规模实现这一层级的目标。您可以试试基于WebRTC或WebSockets的解决方案。

如果你是一个播音员,且采用了基于WebRTC和基于WebSocket的解决方案,虽然广播延迟时间可以缩短至一秒,但该方案是存在一些局限的。首先,你的广播需要字幕和广告支持,而该方案并不支持字幕和广告的传输。其次,你可能需要DRM。尽管有几种非HAS服务提供内容保护,且将来可以提供取证水印,但与DASH、HLS或CMAF所使用的基于CENC的DRM相比,这是一种完全不同的解决方案。第三,由于某些编码限制可能会强加给某些(但不是全部)WebRTC编码器,所以与HAS相比,给定比特率的视频质量可能会受到影响。

最后,低延迟的HAS服务所生成的内容可以与不支持低延迟的播放器向后兼容,并可立即用于DVR或视频点播(VOD)。而对于基于WebRTC和WebSockets的系统来说,在VOD直播后,其媒体流可立即使用。但是如果不进行转码,该系统就不能采用传统的自适应比特率(ABR)格式。如果你每月只广播一个小时,则将流转换为基于HAS的VOD的费用(如果有要求)可以忽略不计。但如果你每小时要广播200个电视频道,那么转换成本就会爆炸式增长了。

迅速发展的HAS市场

如上所述,有很多企业致力于研究DASH或基于HLS的低延迟解决方案。比如苹果发布了其研制的低延迟HLS初步规范(俗称LL-HLS)。该规范与以前的方案有两点主要的不同。首先,LL-HLS启用了传输流块和分段的MP4文件,但DASH仅支持后者(从技术层面上讲,DASH是支持该方案中的传输流的,但很少使用它)。如果你使用传输流块将低延迟视频传输到HLS,那你需要使用分段MP4文件的单独流来支持DASH的低延迟输出。

编解码器供应商MainConcept的产品管理副总裁Thomas Kramer认为,苹果这一举动是在复杂化ABR生态系统。而ABR生态系统已逐渐向CMAF迁移。“苹果公司推出的LL-HLS带有第一组示例代码段,该代码段使用MPEG传输流,而非用于CMAF的fMP4或其他针对低延迟的专有扩展项目。在我看来,苹果公司没有意识到逐渐扩大的CMAF市场。他们更倾向于自己的生态系统和播放设备。”

文章来源:https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134873

原文作者:Jan Ozer

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营