Dash & 超低延时直播的研究

延时的来源

链式传播叠加的延时

  1. 编码和封装:引入延迟和参数配置、质量要求密切相关。某些流媒体协议可能会引入额外的延迟,因为它们只有在完全接收到后才输出一大块(chunk)媒体内容。
  2. 第一英里上传(first mile upload):将打包内容上传到CDN通常会受到商业条款的限制。例如,与来自新闻工作室的租用线路设置相比,如果通过无线连接完成上传将会产生更大的延迟。
  3. CDN传播:为了大规模传送内容,大多数媒体管道都利用内容传送网络(content delivery network)。因此,内容需要在不同缓存之间传播,从而引入额外延迟。
  4. 最后一英里交付(last mile delivery):用户网络连接可能会对延迟产生重大影响。用户可以在家庭网络连接到wifi热点,或者使用移动连接来访问网络内容。此外,由于可能会选取不同远近的CDN端点,用户地理位置也会造成额外延迟。
  5. 播放器缓冲区:视频播放器必须缓冲媒体以确保流畅播放。缓冲区大小通常在媒体规范中定义,但具有一定灵活性。播放缓冲是延迟的主要因素,优化缓冲区配置是常态。

7d8dfc0b722b8df93878853e19232c43.png

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:实时通信对于双向会议和通信等用例至关重要。

142a9a1242f3aa2fe1e5102e3219ed15.png

fig.2 (延迟长短定义)

DASH 和低延时

MPEG-DASH an overview

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

fb8fe91d3dff26d1f7675ead769ed73f.png

fig.3 (DASH 时间模型)

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

96dfb5085b6ced836e6c7e04103e1d55.png

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开始传输所必需的。
b3a74ef9f53c4050ea245c6c167c2117.png

359bd2896cd7f9c61b115d42da3de80f.png
一般来说,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流媒体方案解析

标签: none
返回文章列表 文章二维码
本页链接的二维码
打赏二维码