Dash & 超低延时直播的研究

延时的来源

链式传播叠加的延时

  1. 编码和封装：引入延迟和参数配置、质量要求密切相关。某些流媒体协议可能会引入额外的延迟，因为它们只有在完全接收到后才输出一大块（chunk）媒体内容。

  2. 第一英里上传（first mile upload）：将打包内容上传到 CDN 通常会受到商业条款的限制。例如，与来自新闻工作室的租用线路设置相比，如果通过无线连接完成上传将会产生更大的延迟。

  3. CDN 传播：为了大规模传送内容，大多数媒体管道都利用内容传送网络 (content delivery network)。因此，内容需要在不同缓存之间传播，从而引入额外延迟。

  4. 最后一英里交付 (last mile delivery)：用户网络连接可能会对延迟产生重大影响。用户可以在家庭网络连接到 wifi 热点，或者使用移动连接来访问网络内容。此外，由于可能会选取不同远近的 CDN 端点，用户地理位置也会造成额外延迟。

  5. 播放器缓冲区：视频播放器必须缓冲媒体以确保流畅播放。缓冲区大小通常在媒体规范中定义，但具有一定灵活性。播放缓冲是延迟的主要因素，优化缓冲区配置是常态。

fig.1 (延迟来源)

延迟的长短

  • 典型延迟（typical latency）18-45s：如下图所示，在这个区域，我们看到一般都是 HLS 和 MPEG-DASH 设置，这两种适用于非时间敏感的线性广播，并且不会与广播公司或社交媒体上的其他观众进行任何交互。

  • 较少延迟（reduced latency）5-18s：通过调整 HLS 和 MPEG-DASH 流来减少延迟，减少了 segment 大小并增加了 infrastructure 的大小。该方法通常用于直播新闻和体育赛事。

  • 低延迟（low latency）1-5s：低延迟通常被视为每个发布者的目标，因为它允许更多交互式用例。

  • 超低延迟（ultra low latency）200ms-1s：可以实现更好的交互性，感觉接近实时。虽然不适合语音通信或会议，但这种延迟通常对于常见用例而言足够低。

  • 实时通信（real time communication）0-200ms：实时通信对于双向会议和通信等用例至关重要。

fig.2 (延迟长短定义)

DASH 和低延时

MPEG-DASH an overview

DASH 是一个类似于 HLS 的分片传输协议（其中一些多轨道，无缝切换之类的特性我们这里暂不讨论），DASH 中的列表文件是 mpd (Media Presentation Description) 。根据 mpd 中的几个时间字段（fig.3），我们可以算出 服务器和播放器直接的端到端延迟，这点很重要（详细算法可以看 dash.js 中 getCurrentLiveLatency 方法源码）。

fig.3 (DASH 时间模型)

能准确的获取端到端延迟在直播中最重要的意义就是：我们有了控制延迟的基础条件。在上面描述延迟图中（fig.1），第二步到第四步的网络传输抖动是我们无法控制的，但是只要我们知道了延迟的具体时间，就可以通过控制播放器播放进度，来实现快进或者慢放来保持稳定延时（sample）。 在下图（fig.4）中，我们通过播放器设置将延迟控制在了 5s 整。

fig.4 (示例)

如何稳定进入 5s 以内？ CMAF！

分块编码

实现低延迟的第一个必需行为是分块编码（chunked encoding）。根据 MPEG CMAF 标准，CMAF 中各个对象的命名如图 1 所示。chunk 是最小的可引用单元，至少包含 moof 和 mdat 这两部分。一个或多个 chunk 以形成 fragment，一个或多个 fragment 形成一个 segment。标准 CMAF 的 media segment 使用单个 moof 和 mdat 编码，如图 2 所示，mdat 包含单个 IDR（Instantaneous Decoder Refresh，瞬时解码器刷新）帧，这是每个 segment 开始传输所必需的。

一般来说，segment 将保持一系列 chunk，即多个 moof / mdat 元组的序列，如图 2 所示。只有第一个元组保持 IDR 帧。将 segment 分成这些较短片段的优点是编码器可以在编码后立即输出每个 chunk 以便传输，这样就会导致整体延迟直接减少相同的量。每个块中包含多少帧没有固定的规定，目前的编码器范围为 1 至 15 帧。

DASH DASH-CMFA

再次强调一下，只有满足以下所有条件，才能稳定实现 ULL-CMAF 的减少延迟功能：

  1. CMAF 段中的内容是块编码的。

  2. 编码器调整其 DASH manifest/ HLS playlist 以适应分块编码的使用和数据的早期可用性。

  3. 编码器使用 HTTP 1.1 块编码传输将内容推送到 origin 处。

  4. CDN 在分发链的每个步骤使用 HTTP 块编码传输。

  5. 客户端：

    1. 准确地对 segment 的请求进行计时，并在 live edge 的一个 segment 持续时间内请求该切片;

    2. 在接收到比特流时对其进行解码，并且不用等到 segment 传输结束。在浏览器中运行的 HTML5 播放器必须使用 Fetch 而不是 XHR API，因为 Fetch 允许在数据仍在下载时读取响应主体;

    3. 有一个估计吞吐量的方案，因为标准的 segment 定时技术将会失效;

    4. 具有缓冲和自适应逻辑以应对非常低的缓冲;

    5. 由于吞吐量波动，如果它落后于直播流，要具有赶上直播流的功能。

参考内容

优化延迟的最佳解决方案（一）
优化延迟的最佳解决方案（二）
优化延迟的最佳解决方案（三）

The importance of low latency in video streaming
视频传输延迟分析及解决方案：CMAF、LHLS

BEST PRACTICES FOR ULTRA-LOW LATENCY STREAMING USING CHUNKED-ENCODED AND CHUNK-TRANSFERRED CMAF
超低延迟 CMAF 流媒体方案解析

赞 (0)

相关推荐