由于工作项目中需要,花了一点时间来研究了一下HTTP Live Streaming
简称HLS
先来一段官方的介绍。
Send live and on‐demand audio and video to iPhone, iPad, Mac, Apple TV, and PC with HTTP Live Streaming (HLS) technology from Apple. Using the same protocol that powers the web, HLS lets you deploy content using ordinary web servers and content delivery networks. HLS is designed for reliability and dynamically adapts to network conditions by optimizing playback for the available speed of wired and wireless connections.
英语极差脸皮极厚的人看完后理解如下
使用
Apple
的HLS
技术,我们可以发送直播和点播的音视频到iPhone
、iPad
、Mac
、Apple TV
以及PC
(只要遵守HLS
都可以)。使用常用于Web
的HTTP
协议,HLS
可以让你通过普通的Web服务器以及内容分发网络来部署内容。通过优化,充分利用有线和无线连接的速度来进行playback
,HLS
是一种可靠的,可以动态适配不同网络条件的协议。
HLS协议简介
协议编码格式要求
- 视频的编码格式
H264
- 音频的编码格式
AAC
MP3
AC-3
- 视频的封装格式
ts
- 保存
ts
索引的m3u8
文件
协议优势
-
HLS
相对于rtmp
来讲实用了标准的HTTP
协议来传输数据,可以避免在一些特殊的网络环境下被屏蔽。 -
HLS
相比rtmp
在服务器端做负载均衡要简单的多。因为HLS
是无状态协议HTTP
,客户端只需要按照顺序使用下载存储在服务器的普通ts
文件进行播放就可以。而RTMP
是一种有状态协议,很难对视频服务器进行平滑扩展,因为需要为每一个播放视频流的客户端维护状态。 -
HLS
协议本身实现了码率自适应,在不同带宽情况下,设备可以自动切换到最适合自己码率的视频播放。
协议缺点
-
HLS
协议在直播的视频延迟时间很难做到10s
一下演示,而RTMP
协议的延时可以降到3s-4s秒
左右
协议工作流程
transport_stream_2x.png
从input
到output
来解释一下这张图,首先我们要将摄像头采集的视频流上传到server
上,但是我们不用关心采集的视频是什么格式,也不用在乎用什么协议将视频上传到服务器。因为官方文档是这样说的You Can Send Live Streams or Video on Demand, with Optional Encryption
You Can Send Audio and Video Without Special Server Software
。当视频流被推到server
上之后Media encoder
模块将会把原数据转码成H264
格式的数据,这个时候stream segmenter
模块将会对H264
数据进行切片成若干个ts
文件,并且生成对用的一个m3u8
索引文件记录ts
文件,当然在m3u8
文件内部依然可以包含子m3 u8
索引。最后Distribution
只是一个普通的业务服务器,通过HTTP
请求下发m3u8
文件,客户端通过解析m3u8
获取里面的ts
索引即可播放HLS
视频流。
IndexFile(Playlists)介绍
图片来自官方文档
说是IndexFile
其实就是m3u8
文件的逻辑架构。先看一下官方解释
In a typical configuration, a hardware encoder takes audio-video input, encodes it as H.264 video and AAC audio, and outputs it in an MPEG-2 Transport Stream, which is then broken into a series of short media files by a software stream segmenter. These files are placed on a web server. The segmenter also creates and maintains an index file containing a list of the media files. The URL of the index file is published on the web server. Client software reads the index, then requests the listed media files in order and displays them without any pauses or gaps between segments.
上面这幅图虽然是对IndexFile
逻辑架构作出了一个简单的展示,其实也是对播放器的播放逻辑作出了一定的说明。客户端播放HLS
视频流首先下载一级IndexFile
,它里面记录了二级索引文件Alternate-A
、Alternate-B
、Alternate-C
的地址,然后客户端再去下载二级索引文件,二级索引文件中又记录了ts
文件的下载地址,这样客户端就可以按顺序下载ts
视频文件并连续播放即可。
m3u8文本介绍
从官网上找了一个m3u8
文本事例,在这里简单的介绍一下
#EXT-X-VERSION:3
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-PLAYLIST-TYPE:VOD
# Old-style integer duration; avoid for newer clients.
#EXTINF:10,
http://media.example.com/segment0.ts
# New-style floating-point duration; use for modern clients.
#EXTINF:10.0,
http://media.example.com/segment1.ts
#EXTINF:9.5,
http://media.example.com/segment2.ts
#ZEN-TOTAL-DURATION: 29.5
#EXT-X-ENDLIST
上面记得参数解释一下
-
#EXT-X-PLAYLIST-TYPE
-
VOD
即为点拨视频,换句话说就是该视频的全部的ts文件已经被生成好了 -
Live
即为直播,就是实时生成m3u8
和ts
文件。它的索引文件一直处于动态变化的,播放的时候需要不断下载二级index
文件
-
-
#EXT-X-TARGETDURATION
- 指定当前视频流中的单个切片即
ts
文件的最大时长
- 指定当前视频流中的单个切片即
-
#EXT-X-ENDLIST
- 表示这个
m3u8
文件到这里结束了
- 表示这个
-
#ZEN-TOTAL-DURATION
- 这个
m3u8
所含ts
总时间长度
- 这个
-
#EXTINF
- 紧随后面的那个
ts
的时间长度
- 紧随后面的那个
有时候我们可能还会遇到BANDWIDTH
参数,表示随后这个ts
绑定的比特率
欢迎讨论
Email huliuworld@yahoo.com