直播流媒体技术正在不断进步，观众现在期望近实时播放。我们通过LL-HLS和LL-DASH协议实现玻璃到玻璃延迟仅为2.0-3.0秒的低延迟流媒体直播解决方案。该CDN优化支持标准播放器如hls.js、dash.js和原生Safari，确保优质的流媒体体验。
支持低于3秒延迟的LL-HLS和LL-DASH需要克服多个关键挑战。
从常规HLS切换到LL-HLS在相同数量的观众下，平均请求数和请求时间的变化如下图所示：切换时，请求时间和请求数显著增加。
传统的低延迟实现涉及两个原则，但这些方法在CDN上扩展性较差，无法满足低延迟需求。因此，需要新的方法来减少延迟，同时保持流媒体稳定性。
我们之前的延迟约为±5秒。将延迟进一步降低至2秒，尤其是在hls.js和Safari等播放器上的实现，是一个重大的技术挑战。
LL-DASH和LL-HLS协议使用非常不同的传输和播放方案。主要挑战在于让这两种协议在同一传输系统中同步工作。
DASH（基于HTTP的动态自适应流传输）是一个非常灵活的协议，其灵活性既是优势也是挑战。内容分段时，开发人员需要考虑众多细节。MPEG-DASH的基本原则包括：
低延迟流传输旨在尽可能接近实时边界播放直播内容。在LL-DASH中，段文件同步转码和分发，播放器无需等待整个文件录制完成，即可基于“targetLatency”属性开始播放。
然而，播放只能从关键帧开始，这引入了确定延迟的限制。
在LL-DASH中，可以通过平衡最小延迟和最后一公里交付质量来实现优化。如果关键帧太稀疏，数据更新和网络问题可能导致缓冲。
低延迟HLS与常规版本相比带来了一组新的条件，主要包括：
阻止播放列表重新加载：这通过指令#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES来控制。这指示服务器在部分文件完全可用之前保持请求。而传统HLS几乎即时返回清单（±30毫秒），LL-HLS引入的延迟等于准备下一个部分文件的时间，通常为500毫秒或更多。