第二个级别是“提前剧透”，比如你邻居是个体育粉，他在隔壁看电视播放的体育比赛。突然他因为某个球员触地得分激动地狂喊，还发了推特。但你在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
