对WebRTC的错误认知 WebRTC最初是作为Google Hangouts的基础迭代技术而面世的。当时这种技术给大众的惯常印象是低质量的视频。这导致了之后WebRTC被谣传成无法规模化、不可用于ABR以及其视频都是低分辨率和低质量的技术。 确实，WebRTC需要在服务器和播放器之间建立持久连接才能保证其可扩展性。但大型流媒体商店在自己的交付基础架构中已经解决了这一问题。这就是为何要吸引成千上万

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

还有一些通用媒体应用程序格式（CMAF）块编码解决方案，这些方案允许单个文件集传递到HLS和DASH客户端。其中，基于低延迟CMAF的方案有许多优点，包括对传统播放器的支持。如果播放器没有低延迟的能力，它可以正常延迟速度来检索和播放片段。 此外，由于文件格式是基于标准的，因此现今支持DRM、字幕和广告插入的技术应能正常工作。并且HTTP段应该是可缓存的，防火墙也不会因此出现任何问题。 在大多数情况

根据Bitmovin发布的《2019年视频开发人员报告》，有54％的受访者关心延迟问题。 深入调查后发现，将近50％的调受访者计划在未来1-2年内使用低延迟技术，其中50％以上的受访者寻求不到5秒的延迟，30％寻求不到1秒的延迟。（图1）。 综上所示，是时候有一篇低延迟选项的文章供大家参考了，不是吗？ 在本文中，我首先会讲一些低延迟技术的基础知识，然后是一些选择技术的注意事项。 图1 Bitmov