实时低延迟流式传输

本文来自BITMOVIN，由Jameson Steiner编辑，文章主要内容是“实时低延迟流式传输”。

什么是实时低延迟？

实时流媒体的低延迟是指事件内容在媒体交付链的一端被捕获并在另一端向用户播放之间的时间延迟。考虑一个在足球比赛中进球的进球：实时等待时间是指从进球打入并由摄像机捕获到观看者在自己的设备上看到该进球之间的时间延迟。有几个不同的术语可以定义该时间：端到端延迟，hand-waving延迟或glass-to-glass延迟。端到端的视频编码流程如图1所示。

图1 端到端视频编码流程

低延迟是当前媒体行业最大的挑战之一，本文将深度探讨为什么需要关注低延迟。

为什么要关注低延迟？

01

跨多个分发渠道交付的实时内容

与通过卫星，地面或有线服务的传统线性广播交付相比，跨多个分发渠道交付的内容延迟较高。像MPEG-DASH和Apple HLS这样的OTT传输方法已经成为移动设备向观众传输视频的标准。诸如体育或新闻之类的实时网络内容推动了对低实时延迟的需求，因为这些网络试图通过各种分发方式（例如OTT与有线电视）同时交付内容。

设想一个场景，在这个场景中，全球决赛中播放着用户最喜欢的足球队，其邻居（同一支球队粉丝）使用传统的有线网络。在比赛的最后时刻，用户却听到了邻居大声咒骂，尽管该用户距离比赛结束还有1分钟多的时间。这时候延迟会使得用户体验变差，因为用户知道自己喜欢的球队肯定输了。因此越来越低的实时延迟需求已变得显而易见，在如今的数字世界中，广播和流传输之间的延迟差异是无法接受的。有很多因素会影响内容在观看者的屏幕上显示的速度。除了基础设施问题（例如未针对低延迟进行优化）之外，流传输方法还可能会因社交媒体源，推送通知等其他因素而导致延迟。

02

互动直播内容

每当涉及到观众互动时，实时等待时间应尽可能短，以确保良好的体验质量（QoE）。这样的用例包括网络研讨会，拍卖等。高延迟是最低的需求，而实时是最高的要求。可以参阅图2延迟频谱（包括延迟类型，延迟时间和流格式）：

图2 延迟图谱

延迟图谱显示，未优化的OTT传输大约会引入30秒钟以上的延迟，而有线电视广播的时间大约为5秒钟。此外，使用OTT方法可能无法实现亚秒级的等待时间，并且需要WebRTC等其他协议。

实时延迟来自何处？

首先，对实时延迟作技术定义：捕获的视频帧与将其呈现给回放客户端之间的时间差。换句话说，这是视频帧在媒体处理和交付链上花费的时间。链中的每个组件都会引入一定量的延迟，并最终累积为实时延迟。

实时延迟的主要来源有：

01

提前缓冲以确保播放稳定性

图3 实时流时间轴

视频播放器会在其播放位置之前保持预设量的缓冲数据。标准值是在播放过程中始终预先加载约30秒的缓冲区。造成这种情况的原因之一是，如果在播放期间网络带宽下降，则仍有30秒的数据要播放而不会中断。在这段时间内，播放器可以对新的带宽条件做出适当的反应，从而为播放器腾出一些时间来适应。缓冲时间通常还会影响比特率适应决策，因为低缓冲水平可能意味着更积极的向下适应。

但是，当流缓冲30秒时，播放器必须在其播放位置的流直播边缘之后至少保留30秒；这将导致30秒的实时延迟。相反，这意味着要实现低等待时间，就需要更接近实时边缘，这意味着要有最小的缓冲区。如果我们将延迟时间设为5秒，那么播放器最多会有5秒的缓冲时间。因此，必须做出在等待时间和回放稳定性之间进行艰难的折中决策。

02

Segment的生产、转移和消费

实时流是实时编码的，如果一个segment持续时间为6秒，则编码器将花费6秒来产生一个完整的segment。此外，如果将fragmented MP4（fMP4）用作容器格式，则编码器只能在将其完全编码后（即，开始对该片段进行编码后6秒钟）将一个片段写入所需的存储中。因此，一旦将segment传输到存储区，其最早的帧就已经过去6秒钟了。在传送链的另一端，播放器只能解码完整的fMP4片段，因此需要先下载一个完整的片段，然后才能对其进行处理。此外网络传输，像将视频上传到CDN原始服务器，在CDN内传输内容以及从CDN边缘服务器下载到客户端一样，可能会降低整体延迟。

图4 编码流程中的数据segment

我们可以做什么？

01

简单的方法：使用更短的segment

由于等待时间与segment的持续时间相关，所以减少等待时间的简单方法是使用更短的segment，例如1s的持续时间。但是这会带来负面影响，如：

• 影响编码效率。每个视频片段都需要从关键帧开始，更短的segment意味着更小的GOP，这会导致差分/预测编码的效率下降。并且在相同内容上获得同等感知质量，短segment需要花费更多的bit；
• 更多的网络请求，例如每个请求都浪费了Time to first byte（TTFB）的时间；
• Segment数量的增加会降低CDN的缓存效率；
• 播放器处的缓冲区以跳跃的方式增长，这增加了由于重新缓冲而导致播放停顿的风险。

02

分块编码与传输

为了解决仅完整地产生和使用segment的问题，我们可以使用MPEG-CMAF（通用媒体应用格式）标准中指定的分块编码方案。CMAF基于ISO基本媒体文件格式（ISO BMFF）定义了一种容器格式，类似于MP4容器格式，该格式已被浏览器和终端设备广泛支持。CMAF在其分块编码功能中引入了CMAF块的概念。与在单个大型mdat框中具有媒体有效负载的“普通” fMP4段相比，分块CMAF允许段由一系列CMAF组块（moof + mdat元组）组成。在极端情况下，每个帧都可以放入自己的CMAF块中。这样一来，编码器负责制作，播放器的解码器则可以逐块使用片段，而不必限制整个片段的使用。诚然，MPEG-TS容器格式提供的属性与分块CMAF类似，但由于缺少fMP4和CMAF提供的本机设备和平台支持，因此它已逐渐淡出。

图5 6s fMP4 segment vs 分块CMAF

图6 内存中的分块CMAF数据

单独进行分块编码并不能帮助我们减少延迟，但这是一个关键步骤。为了利用分块编码，需要将该过程与HTTP 1.1分块传输编码（CTE）结合起来。CTE是HTTP的一项功能，它允许在大小未知的情况下进行资源传输。它是通过逐块传输资源并用长度为0的块标志结尾来实现的。可以在编码器上利用CTE，在生成CMAF块后立即将它们写入存储，而无需等待编码的完成。这使播放器可以请求（也使用CTE）仍在编码的segment的可用CMAF块，并将它们尽可能快地转发给解码器以进行播放。因此，一旦接收到第一个CMAF块，就允许回放。

低延迟分块传输

低延迟分块传输除了带来低延迟，还有以下几点影响：

• 不断接收到的CMAF块流中，可以使客户端缓冲区级别更平滑，跳动更少。因此降低了缓冲区欠载的风险并提高了播放稳定性。
• 由于能够在segment下载期间部分解码和播放片段，因此流启动速度更快（到第一帧的时间），并可以在客户端进行查找。
• 与未分块的分段相比，分块文件大小的开销更高，这是因为分块编码引入了其他元数据（moof box，mdat标头）。
• 客户端上的低缓冲区级别会影响播放稳定性。较低的实时延迟意味着客户端靠近实时边缘，并且缓冲区级别较低。因此，最长可达到的缓冲区级别受到当前实时延迟的限制。这是QoE的折中：延迟与播放稳定性。
• 用于客户端的自适应流传输的带宽估计很困难。当在实时边缘加载段时，下载速率将受到源/编码器的限制。由于内容是实时生成的，因此编码6秒长的片段需要花费6秒钟。因此，segment不再受到网络限制，而受到编码器限制。这导致带宽估计出现问题，目前在业界很普遍的带宽估计方法基于下载持续时间，带宽估计的标准公式为：估计带宽=segmentSize /下载持续时间

由于下载持续时间大致等于使用CTE在活跃的实时边缘加载时的分段持续时间，因此它不再可以用来估计客户端带宽。带宽估计是任何自适应流播放器的关键部分，必须解决估计带宽不足的问题。学术界和整个流媒体行业正在研究寻找更好的方法来估计分块的低延迟交付方案中的带宽，例如ACTE。

MPEG-DASH直播流基础知识

在深入了解MPEG-DASH中低延迟流媒体如何工作之前，我们首先需要了解DASH实时流的一些基本流机制，其中最重要的是分段可用性的概念。

DASH媒体表示描述(DASH Media Presentation Description, MPD)是一个包含DASH流基本元数据的XML文档。它描述了流由哪些段组成，以及播放客户端如何获得这些段。在DASH中，点播和直播流之间的主要区别在于，流的所有片段都可以在任何时候进行点播；而对于直播流来说，片段是随着时间的推移而一个接一个连续产生的。每当产生一个新的段，它就会通过MPD向播放客户端发出信号，表示它的可用性。需要注意的是，一个段只有在它被完全编码并写到原点时才可用。

MPD会指定流可用性的开始时间(Availability Start Time)和一个恒定的段持续时间，例如2秒。使用这些值，播放器可以计算出当前有多少段在可用性窗口中，以及它们各自的可用性开始时间。例如，第二个段的段可用性开始时间为AST + segment_duration * 2。

低延迟流与MPEG-DASH

前文描述了分块编码和传输如何允许对仍在编码过程中的片段进行部分加载和使用。为了让播放器意识到这个动作，MPD中的片段可用性被调整到发送更早的可用性，即当第一个片段完成时。这是使用MPD中的availabilityTimeOffset完成的。因此，播放器不会等待一个片段完全可用，而是更早地加载和使用它。

图7 具有基于模板的寻址方案的实时流（简化）

以图7为例，分段时间为2秒，块时间为0.033秒(即一个视频帧率为29.97 fps)。为了在第一个块完成后发送段可用性，我们将把availabilityTimeOffset设置为1.967秒(segment_duration- chunk_duration)。这将标志图中的灰色部分成为可用部分。

下面的MPD代表了这个例子：

 1<?xml version="1.0" encoding="utf-8"?>
 2<MPD
 3  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 4  xmlns="urn:mpeg:dash:schema:mpd:2011"
 5  xmlns:xlink="http://www.w3.org/1999/xlink"
 6xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd"
 7  profiles="urn:mpeg:dash:profile:isoff-live:2011"
 8  type="dynamic"
 9  minimumUpdatePeriod="PT500S"
10  suggestedPresentationDelay="PT2S"
11  availabilityStartTime="2019-08-20T05:00:03Z"
12  publishTime="2019-08-20T12:42:07Z"
13  minBufferTime="PT2.0S">
14  <Period start="PT0.0S">
15    <AdaptationSet
16      contentType="video"
17      segmentAlignment="true"
18      bitstreamSwitching="true"
19      frameRate="30000/1001">
20      <Representation
21       id="0"
22       mimeType="video/mp4"
23       codecs="avc1.64001f"
24       bandwidth="2000000"
25       width="1280"
26       height="720"
27        <SegmentTemplate
28         timescale="1000000"
29         duration="2000000"
30         availabilityTimeOffset="1.967"
31         initialization="1566277203/init-stream$RepresentationID$.m4s"
32         media="1566277203/chunk-stream_t_$RepresentationID$-$Number%05d$.m4s"
33         startNumber="1">
34        </SegmentTemplate>
35      </Representation>
36    </AdaptationSet>
37  </Period>
38</MPD>

总结一下，对于低延迟DASH，主要做两件事：

• 分块编码和传输(即分块CMAF)
• 发送正在进行的段的早期可用性

虽然前面的方法实现了基本的低延迟DASH设置，但还需要考虑进一步优化和稳定流体验。DASH行业论坛正在为低延迟DASH制定指导方针，预计将于2020年7月初在下一代DASH-IF Interoperability Points(DASH-IF IOP)中发布。下面将解释这些准则的关键部分。请注意，目前有些功能还没有正式定稿和标准化（2020年6月时）。

Wallclock时间映射

为了测量延迟，需要一个媒体显示时间和wall-clock时间之间的映射。这样，对于流的任何给定呈现时间，都可以知道相应的wall-clock时间。然后可以通过确定相应的wall-clock时间并从当前wall-clock时间中减去它来计算给定回放位置的延迟时间。

这种映射可以通过在段或MPD中指定一个所谓的生产者参考时间来实现。它实际上指定了产生相应的段/块的wallclock时间。

1<ProducerReferenceTime
2  id="0"
3  type="encoder"
4  presentationTime="538590000000"
5  wallclockTime="2020-05-19T14:57:45Z">
6</ProducerReferenceTime>

type属性指定引用时间是由捕获设备还是由编码器设置的。分别计算端到端延迟(EEL)和编码显示延迟(EDL)。

客户端时间同步

播放客户端上的精确时间/时钟对于涉及客户端wallclock时间的计算(如段可用性计算和延迟计算)是必要的。建议MPD包含UTCTiming元素，该元素指定一个时间源，可用于调整客户端时钟的任何漂移。

1<UTCTiming
2  schemeIdUri="urn:mpeg:dash:utc:http-iso:2014"
3  value="https://time.akamai.com/?iso"
4/>

低延迟服务描述

ServiceDescription元素应该用于指定服务提供者所需的目标延迟和最小/最大延迟边界(以毫秒为单位)。此外，播放速率边界可以被指定来定义回放加速/减速的允许范围，由播放客户端来满足延迟要求。

1<ServiceDescription id="0">
2  <Latency target="3500" min="2000" max="10000" referenceId="0"/>
3  <PlaybackRate min="0.9" max="1.1"/>
4</ServiceDescription>

在大多数播放器实现中，这些参数是通过配置和api外部提供的。

再同步点

前文指出，分块传输将可实现的延迟与片段持续时间解耦，使我们能够选择相对较长的片段持续时间，以保持良好的视频编码效率。反过来，这也阻碍了播放器快速的高质量适应，因为高质量的转换只能在片段边界上进行。在低延迟、低缓冲水平的情况下，快速适应(特别是下切换)将是可取的，以避免缓冲不足和播放中断。

为此，可以使用指定段属性(如块持续时间和块大小)的Resync元素。播放客户端可以利用它们来定位重新同步点和

• 根据延迟需求加入流中间段
• 开关表示中段
• 缓冲下冲后，在中段位置重新同步

上文是对不久的将来的展望，显示了媒体行业在使用MPEG-DASH启动低延迟流媒体和为生产服务做好准备方面所付出的巨大努力。

附上原文链接：

https://bitmovin.com/live-low-latency-streaming-p1/

https://bitmovin.com/live-low-latency-streaming-p2/