下一代直播--低延迟直播技术探索

一、背景

互联网直播的发展大致可分为 4 个阶段:创新期、演进期、量产期和瓶颈期,分别对应着不同的直播场景、实现技术,相应地会有不同的延迟及用户体验。

综上可以看到,直播技术的发展和直播场景是相辅相成的。场景驱动技术发展,技术反过来支撑更多的直播场景。当前我司已经支持的连麦技术,在「主播-主播」之间的延迟已经较低了,但还是存在两个问题:

  1. 业界目前越来越火的直播带货场景,需要实现「主播-观众」端的低延迟;
  2. 在线教育等场景下,用户在观众状态和嘉宾状态之间切换,由于延迟的不一致,导致用户体验较差,可能还会有黑屏中断等问题;

因此对下一代超低延迟直播技术的探索,成了我们当前不得不做的一项工作。

二、技术实现

当前业界的主流直播实现方案为 rtmp + http-flv + hls。存在以下问题:

因此,大部分基于 TCP 的协议无法满足低延迟直播的需求,需在 UDP 方案中进行调研。

纵观业界当前比较领先的低延迟直播技术实现,大体上有 WebRTC、QUIC、SRT、CMAF、LLHLS 等方案。这里做一简单对比:

指标 WebRTC QUIC SRT CMAF LLHLS
提出时间 2010 2012 2012,2017 2016 2019
覆盖链路 采集、编解码、传输、渲染 传输 编码、传输 封装、传输 封装、传输
传输层协议 UDP UDP UDP TCP TCP
类型 流式、不可靠 流式、可靠 流式、可靠+不可靠 ABR切片式、可靠 ABR切片式、可靠
针对场景 端到端音视频通信 通用协议 媒体远程制作 下行分发、CDN友好 下行分发、CDN友好
标准化 RFC/W3C RFC Draft Halvision SRT联盟 ISO MPEG Apple
延时 端到端 250ms >2s >2s >3s >2s
终端 H5、iOS、Android Chrome FFmpeg H5 iOS

这里简要介绍一下 WebRTC、QUIC 及 LLHLS:

1. WebRTC

WebRTC,即 Web Real-Time Communication,web实时通信技术。实现了基于网页的语音对话或视频通话,目的是无插件地实现 web 端的实时通信能力。

WebRTC 提供了音视频的核心技术,包括音视频采集、编解码、网络传输、终端展示等,覆盖了流媒体的大部分环节,且支持跨平台,通过简单调用 API 即可使用。

从延迟上看,WebRTC 由于采用了 UDP 的传输协议,端到端延迟一般在毫秒级别,极限情况下可达到 100ms 以内。

2. QUIC

QUIC,即 Quick UDP Internet Connection,是 Google 开发的一种基于 UDP 协议的低延迟互联网传输协议。解决了 TCP 的头部阻塞、握手/挥手延迟、切换网络断线重连等问题。可在一定程度上降低端到端的延迟。

但由于 QUIC 的设计目标是成为一个通用的传输协议,也并没有针对多媒体数据进行优化,因此其应用在音视频传输上的延迟是秒级的。

3. LLHLS

苹果于 2019 年提出了低延迟 hls 的草案,旨在通过降低切片发布延时、优化客户端发现新分片的方式、消除额外 rtt、减小传输开销等方式,进一步降低 hls 的直播延迟。具体可见:低延迟 hls 调研

3.1 降低发布延时

降低发布延时是通过允许服务器在主分片准备好之前,先发布其中部分内容的方式来实现的。假设当前一个分片时长为 6s,可将其切成 30 个小分片,每个小分片包含 200ms,可独立被客户端获取并播放。且当一个分片被全部生成后,其小分片会被删除,以避免播放列表的膨胀。

可以通过如下标签启用部分分片功能:

#EXT-X-PART-INF:PART-TARGET=0.33334
#EXT-X-PART:DURATION=0.33334,URI="filePart271.0.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.1.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.2.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.3.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.4.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.5.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.6.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.7.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.8.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.9.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.10.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.11.mp4"
#EXTINF:4.00008,
fileSequence271.mp4

EXP-X-PART-INF 标签的 PART-TARGET 属性标识每个部分片段的持续时间,该值为十进制浮点数。

EXT-X-PART 标签表示每一个具体的部分片段,DURATION 属性标识持续时长,URI 为该部分片段的标识符,INDEPENDENT=YES 表示该部分片段包含一个独立的帧,以此来提高客户端切入的效率。

3.2 播放列表增量更新

客户端第一次请求 m3u8 时,服务器会返回全量分片列表。此后客户端只会关心 m3u8 的增量部分,因此发起的是增量请求,以便客户端更频繁地获取播放列表,从而降低延迟。返回数据相比原始全量数据会大大减少,以便于放在一个 MTU 数据包内返回。

增量更新可以减少每次传输的数据量,可通过以下标签予以支持:

#EXT-X-SERVER-CONTROL:CAN-SKIP-UNTIL=12.0
#EXT-X-SKIP:SKIPPED-SEGMENTS=3

EXT-X-SERVER-CONTROL 标签使服务器指示对传递指令的支持,CAN-SKIP-UNTIL 指示服务器可以响应 HLSskip 指令来生成播放列表增量更新。它的值是需要跳过的秒的十进制浮点数。

EXT-X-SKIP 标签的 SKIPPED-SEGMENTS 属性表示需要被跳过的分片数。

3.3 阻塞客户端请求

为了在生成新媒体段和部分段后及时通知到客户端,低延迟 HLS 引入了阻塞客户端加载请求的功能。当客户端发出 HTTP GET 请求更新媒体播放列表时,可以带上 HLSmsn 这个参数,以表明其希望播放列表里包括将来的片段。然后,服务器阻塞请求,直到包含该片段的播放列表版本可用为止。此特性可以消除客户端对播放列表的轮询。

3.4 优化客户端发现新分片的方式

服务器使用新标签 EXT-X-PRELOAD-HINT 来通知客户端即将出现的部分段和媒体初始化段。客户端可以提前发出对提示资源的 GET 请求;只要媒体可用,服务器就会响应该请求。具体来说,就是在服务器上还没有新分片之前,客户端就已经发起对该分片的请求。一旦服务器上生成了该分片,就可以立即推送给客户端。此种方式可以在小于 1rtt 的时间内发现新分片。

#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
#EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

该 m3u8 文件表明,当前已经生成了三个分片,EXT-X-PRELOAD-HINT 标签表示第四个分片虽然还未生成,但可以提前推送给客户端。

3.5 消除额外往返

客户端第一次请求到全量播放列表后,会和服务器建立起一条连接。此后当有新分片生成时,服务器会主动将 m3u8 和 ts 分片推送给客户端,减少了一次轮询的 rtt 时间。

由于服务器推送方式需要 HTTP/2 的支持,在 CDN 场景下不友好,因此该方案已被废除。

3.6 快速切换码率

由于是增量更新 m3u8,当 CDN 上有两种码率的流时,每次返回时可以携带额外信息。因此当客户端需要切换到不同码率时,就可以直接切换。

三、业界做法

当前业界比较成熟的低延迟直播系统有腾讯云的快直播、阿里云的 RTS,均采用 WebRTC 作为底层流媒体框架。简要介绍如下:

1. 腾讯云快直播

快直播方案改造的就是从CDN分发节点到SDK、再到观众端播放这部分,这样的好处在于主播推流中间的录制、截图、转码等都可以复用,接入简单,可以同时出flv、rtmp、hls、WebRTC的数据流。

此外,快直播从五个方面对标准WebRTC进行升级,包括支持aac(同时支持adts、latm两种封装)、视频支持H265和B帧、通过STP协商精简了信令交互、可以关闭gtrs以及支持透传metadata。

在接入方面,快直播的接入其实非常简单,只需要一步就可以从标准直播升级为快直播——升级播放端、其余全部复用。Web/H5端调用浏览器WebRTC接入快直播,App接入需要集成SDK。

在直播效果上,快直播能做到的延迟一般是300ms左右,极限延迟可以做到43ms。并且首帧在 100ms 左右,质量和flv相当,而延迟从10秒降低到300ms,并且可以抗30%+丢包。

2. 阿里云 RTS

RTS 是由阿里云和淘宝直播共建的低延迟直播系统,此系统分两大块:

RTS拥有四个技术特性:

RTS 底层依赖阿里云 GRTN 网络,GRTN的定位是基于中心云和边缘云的异构节点,构建超低延时、全分布式下沉的通信级流媒体传输网络。目前融合了互联网直播和RTC等多种业务场景的音视频流传输和交换。基于GRTN的短延时直播RTS可以支持标准H5 WebRTC推播,在千万级并发情况下延时可以控制在1s以内;RTC端到端延时可以控制在250ms左右。

四、总结

五、参考文献