还有一些通用媒体应用程序格式（CMAF）块编码解决方案，这些方案允许单个文件集传递到HLS和DASH客户端。其中，基于低延迟CMAF的方案有许多优点，包括对传统播放器的支持。如果播放器没有低延迟的能力，它可以正常延迟速度来检索和播放片段。 此外，由于文件格式是基于标准的，因此现今支持DRM、字幕和广告插入的技术应能正常工作。并且HTTP段应该是可缓存的，防火墙也不会因此出现任何问题。
在大多数情况下，此类基于标准的方案可提供最大限度的生态系统灵活性。使您可以像正常延迟传输一样选择编码器、软件包、CDN和播放器。
基于WebSocket的方案
第三种方法通常基于WebSockets之类的实时协议，该协议在服务器和客户端之间创建并维护一种持久连接。任何一方均可使用该连接来传输数据。此连接可用于支持视频传输以及其他通信。这会为交互类应用程序的使用提供方便。
与WebRTC方案一样，使用WebSocket的方案通常是一种包含播放器和CDN的服务。您可以使用任何通过RTMP或WebRTC将媒体流传输到服务器的编码器。例如，Nanocosmos的NanoStream Cloud和Wowza的 Streaming Cloud With Ultra Low Latency。Wowza声称其解决方案的延迟不到3秒，而Nanocosmos则称只延迟大约1秒钟。
图3展示了对NanoStream Cloud的测试，在该测试中，我通过我笔记本上的OBS进行编码（见右图），然后将流发送到Nanocosmos服务器，然后用H5 Live Player播放。我拿着用iPhone计时。结果发现其延迟时间为1.3秒。请注意，iPhone本身不支持WebSocket，为此Nanocosmos创建了一个单独的低延迟HLS协议以最小化延迟。
（图3. Nanocosmos基于WebSockets的服务延迟不到1.5秒）
延迟目标决定技术的选择
使用实时流时需要平衡三个因素：质量、延迟和稳定性。但是对任何一种活动来说，这三种因素都不能兼得。例如，开箱即用的HLS之所以有约18秒的延迟是因为：其每段长度为6秒，并且Apple默认播放器在开始播放之前会缓冲这三段。好处是用户在降级之前，带宽是稳定的。而如果您想办法将延迟降低到3秒，则通过带宽短暂的变化（a short bandwidth blip）即可停止流。
从技术选择的角度来看，延迟分为三个级别。我们称第一级为“无所谓”级别。因为这一层级的应用属一对多的演示应用。几乎没有交互，也没有电视直播。比如教堂礼拜、市议会会议，甚至是一场遥远的音乐会这样的应用场景，只要将您的网段大小减小到2-4秒，您就可以将延迟减少到大约6-12秒之间。风险很小，没有开发成本，且测试成本是最低的。因为对于不必需的情况来说，低延迟不一定是最优选。
文章来源：https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134873
原文作者：Jan Ozer
