技术干货|HLS 协议详解及优化技术解析

又小拍发表于:2017年03月24日 15:24:59更新于:2017年03月27日 13:53:41

一、HLS 概述

HLS (HTTP Live Streaming), 是由 Apple 公司实现的基于 HTTP 的媒体流传输协议。他跟 DASH 协议的原理非常类似,通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件,然后提供一个配套的媒体列表文件给客户端,让客户端顺序地拉取这些媒体文件播放, 来实现看上去是在播放一条流的效果。HLS 目前广泛地应用于点播和直播领域。

在 HTML5 页面上使用 HLS 非常简单:

直接:

或者:

1、HLS 的优势

  • 客户端支持简单,只需要支持 HTTP 请求即可,HTTP 协议无状态,只需要按顺序下载媒体片段即可。

  • 使用 HTTP 协议网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器,CDN 支持良好。

  • Apple 的全系列产品支持,由于 HLS 是苹果提出的,      所以在 Apple 的全系列产品包括 iphone、 ipad、safari 都不需要安装任何插件就可以原生支持播放 HLS, 现在Android 也加入了对 HLS 的支持。

自带多码率自适应,Apple 在提出 HLS 时,就已经考虑了码流自适应的问题。

2、HLS 的劣势

  • 相比 RTMP 这类长连接协议,延时较高,难以用到互动直播场景。

  • 对于点播服务来说,由于 TS 切片通常较小,海量碎片在文件分发、一致性缓存、存储等方面都有较大挑战。

虽然HLS存在明显劣势,又拍云对此也有相应的解决方案。

二、HLS 协议详解

△HLS 整体架构图

上图可以看出,HLS总共有三个部分: Serve、CDN、Client。HLS 协议的主要内容是关于 M3U8 这个文本协议,其实生成与解析都非常简单,示例如下:

△简单的 Media Playlist

△包含多种比特率的 Master Playlist

HLS 通过 URI(RFC3986) 指向的一个 Playlist 来表示一个媒体流。一个 Playlist 可以是一个 Media Playlist 或者 Master Playlist, 使用 UTF-8 编码的文本文件,包含一些 URI 跟描述性的 tag。一个 Media Playlist 包含一个 Media Segments 列表,当顺序播放时,能播放整个完整的流。要想播放这个 Playlist,客户端需要首先下载他,然后播放里面的每一个 Media Segment。更加复杂的情况是,Playlist 是一个 Master Playlist,包含一个 Variant Stream 集合,通常每个 Variant Stream 里面是同一个流的多个不同版本(如:分辨率,码率不同)。

1HLS Media Segments

  • 每一个 Media Segment 通过一个 URI 指定,可能包含一个 byte range。

  • 每一个 Media Segment 的 duration 通过 EXTINF      tag 指定。

  • 每一个 Media Segment 有一个唯一的整数 Media Segment Number。

  • 有些媒体格式需要一个 format-specific sequence 来初始化一个 parser,在 Media Segment 被 parse 之前,这个字段叫做 Media Initialization      Section,通过 EXT-X-MAP      tag 来指定。

2、支持Media Segment的格式

l  MPEG-2 Transport Streams

  • 即最常见的 TS 文件。

  • RFC: ISO_13818。

  • Media Initialization Section: PAT(Program Association Table) 跟 PMT(Program Map Table)。

  • 每个 TS segment 必须值含一个 MPEG-2 Program。

  • 每一个 TS segment 包含一个 PAT 和 PMT,最好在 segment 的开始处,或者通过一个 EXT-X-MAP tag 来指定。

l  Fragmented MPEG-4

  • 即常提到的 fMP4。

  • RFC: ISOBMFF。

  • Media Initialization Section: ftyp box(包含一个高于 ios6 的 brand),ftyp box 必须紧跟在 moov box 之后,moov box 必须包含一个 trak box(对于每个 fMP4 segment 里面的 traf box,包含匹配的 track_ID)。每个 trak box 应该包含一个 sample table,但是他的 sample count 必须为 0。mvhd box 跟 tkhd 的 duration 必须为 0。mvex box 必须跟在上一个 trak box 后面。

  • 不像普通的 MP4 文件包含一个 moov box(包含 sample tables) 和一个 mdat box(包含对应的 samples),一个 fMP4 包含一个 moof box (包含 sample table 的子集),和一个 mdat box(包含对应的 samples)。

  • 在每一个 fMP4 segment 里面, 每一个 traf box 必须包含一个 tfdt box,fMP4 segment 必须使用 movie-fragment relative addressing。fMP4 segments 绝对不能使用外部的 data references。

  • 每一个 fMP4 segment 必须有一个 EXT-X-MAP tag。

l  Packed Audio

  • 一个 Packed Audio Segment 包含编码的 audio samples 和 ID3 tags。 简单的打包到一起,包含最小的 framing,并且没有 per-sample timestamp。

  • 支持的 Packed Audio:AAC with ADTS framing [ISO_13818_7], MP3 [ISO_13818_3],AC-3 [AC_3],Enhanced AC-3 [AC_3]。

  • 一个 Packed Audio Segment 没有 Media Initialization Section。

  • 每一个 Packed Audio Segment 必须在他的第一个 sample 指定 timestamp 通过一个 ID3 PRIV tag。

  • ID3 PRIV owner identifier 必须是 com.apple.streaming.transportStreamTimestamp

  • ID3 payload 必须是一个 33-bit MPEG-2 Program Elementary Stream timestamp 的大端 eight-octet number,高 31 为设置为 0。

l  WebVTT

  • 一个 WebVTT Segment 是一个 WebVTT 文件的一个 section,WebVTT Segment 包含 subtitles。

  • Media Initialization Section:WebVTT heade。

  • 每一个 WebVTT Segment 必须有以一个 WebVTT header 开始,或者有一个 EXT-X-MAP tag 来指定。

  • 每一个 WebVTT header 应该有一个 X-TIMESTAMP-MAP 来保证音视频同步。

l  HLS Playlists

  • Playlist 文件的格式是起源于 M3U,并且继承两个 tag:EXTM3UEXTINF

  • 下面的 tags 通过 BNF-style 语法来指定。

  • 一个 Playlist 文件必须通过 URI(.m3u8 或 m3u) 或者 HTTP Content-Type 来识别(application/vnd.apple.mpegurl 或 audio/mpegurl)。

  • 换行符可以用 \n 或者 \r\n

  • # 开头的是 tag 或者注释, 以 #EXT 开头的是 tag,其余的为注释,在解析时应该忽略。

  • Playlist 里面的 URI 可以用绝对地址或者相对地址,如果使用相对地址,那么是相对于 Playlist 文件的地址。

l  Attribute Lists

  • 有的 tags 的值是 Attribute Lists。

  • 一个 Attribute List 是一个用逗号分隔的 attribute/value 对列表。

  • 格式为: AttributeName=AttributeValue

l  Basic Tags

Basic Tags 可以用在 Media Playlist 和 Master Playlist 里面。

  • EXTM3U:必须在文件的第一行,标识是一个 Extended M3U Playlist 文件。

  • EXT-X-VERSION:表示 Playlist 兼容的版本。

l  Media Segment Tags

每一个 Media Segment 通过一系列的 Media Segment tags 跟一个 URI 来指定。有的 Media Segment tags 只应用与下一个 segment,有的则是应用所有下面的 segments。一个 Media Segment tag 只能出现在 Media Playlist 里面。

  • EXTINF:用于指定 Media Segment 的 duration。

  • EXT-X-BYTERANGE:用于指定 URI 的 sub-range

  • EXT-X-DISCONTINUITY:表示不连续。

  • EXT-X-KEY:表示 Media Segment 已加密,该值用于解密。

  • EXT-X-MAP:用于指定 Media Initialization Section。

  • EXT-X-PROGRAM-DATE-TIME:和 Media Segment 的第一个 sample 一起来确定时间戳。

  • EXT-X-DATERANGE:将一个时间范围和一组属性键值对结合到一起。

l  Media Playlist Tags

Media Playlist tags 描述 Media Playlist 的全局参数。同样地,Media Playlist tags 只能出现在 Media Playlist 里面。

  • EXT-X-TARGETDURATION:用于指定最大的 Media Segment duration。

  • EXT-X-MEDIA-SEQUENCE:用于指定第一个 Media Segment 的 Media Sequence Number。

  • EXT-X-DISCONTINUITY-SEQUENCE:用于不同 Variant Stream 之间同步。

  • EXT-X-ENDLIST:表示结束。

  • EXT-X-PLAYLIST-TYPE:可选,指定整个 Playlist 的类型。

  • EXT-X-I-FRAMES-ONLY:表示每个 Media Segment 描述一个单一的 I-frame。

l  Master Playlist Tags

Master Playlist tags 定义 Variant Streams,Renditions 和 其他显示的全局参数。Master Playlist tags 只能出现在 Master Playlist 中。

  • EXT-X-MEDIA:用于关联同一个内容的多个 Media Playlist 的多种 renditions。

  • EXT-X-STREAM-INF:用于指定一个 Variant Stream。

  • EXT-X-I-FRAME-STREAM-INF:用于指定一个 Media Playlist 包含媒体的 I-frames。

  • EXT-X-SESSION-DATA:存放一些 session 数据。

  • EXT-X-SESSION-KEY:用于解密。

l  Media or Master Playlist Tags

这里的 tags 可以出现在 Media Playlist 或者 Master Playlist 中.,但是如果同时出现在同一个 Master Playlist 和 Media Playlist 中时,必须为相同值。

  • EXT-X-INDEPENDENT-SEGMENTS:表示每个 Media Segment 可以独立解码。

  • EXT-X-START:标识一个优选的点来播放这个 Playlist。

3、采用HLS协议的服务器端与客户端逻辑

不同的播放器客户端以及服务器端的拉取规则都有很多细节差异,以下流程仅供参考。

服务器端逻辑

  • 将媒体源切片成 Media Segment,应该优先从可以高效解码的时间点来进行切片(如: I-frame)。

  • 为每一个 Media Segment 生成 URI。

  • Server 需要支持 “gzip” 方式压缩文本内容。

  • 创建一个 Media Playlist 索引文件,EXT-X-VERSION 不要高于他需要的版本,来提供更好的兼容性。

  • Server 不能随便修改 Media Playlist,除了 Append 文本到文件末尾,按顺序移除 Media Segment URIs,增长 EXT-X-MEDIA-SEQUENCEEXT-X-DISCONTINUITY-SEQUENCE,添加 EXT-X-ENDLIST 到文件尾。

  • 在最后添加 EXT-X-ENDLIST tag,来减少 Client reload Playlist 的次数。

  • 注意点播与直播服务器不同的地方是,直播的 m3u8 文件会不断更新,而点播的 m3u8 文件是不会变的,只需要客户端在开始时请求一次即可。

客户端逻辑

  • 客户端通过 URI 获取 Playlist,如果是 Master Playlist,客户端可以选择一个 Variant Stream 来播放。

  • 客户端检查 EXT-X-VERSION 版本是否满足。

  • 客户端应该忽略不可识别的 tags,忽略不可识别的属性键值对。

  •  加载 Media Playlist file。

  • 播放 Media Playlist file。

  • 重加载 Media Playlist file。

  • 决定下一次要加载的 Media Segment。

三、HLS优化技术解析

由于客户端每次请求 TS 或 M3U8 有可能都是一个新的连接请求,所以,我们无法有效的标识客户端,一旦出现问题,基本无法有效的定位问题, 因此一般工业级的服务器都会对传统的 HLS 做一些改进。本文主要介绍又拍云的 HLS+。

1、又拍云HLS+

l  Variant HLS

首先,下载一条又拍云的 M3U8 文件:

然后, 打开下载得到的 playlist 文件:

可以看出又拍云的 HLS+ 支持这种 Variant HLS 方式来标识一条 HLS 连接,同时可以看出,又拍云使用 uuid 来表示一条 HLS 连接。

l  HTTP 302

首先,以 HTTP 302 方式来请求播放地址。


打开 playlist 内容:

在跳转之后的地址存放真正的 playlist,同时也能够将 uuid 加入到了连接上。

总地来说,不管通过哪种方式,最终我们都能通过一个唯一的 id 来标识一条流,这样在排查问题时就可以根据这个 id 来定位播放过程中的问题。

四、HLS 延时分析

为了追求低延时效果,可以将切片切的更小,取片间隔做的更小,播放器未取到 3 个片就启动播放。但是这些优化方式都会增加 HLS 不稳定和出现错误的风险。

五、Demo

更多HLS信息,请点击「阅读原文」