标签归档:m3u8

HTTP直播HTTP Live Streaming (HLS)

增加EXT-X-MEDIA-SEQUENCE或EXT-X 
      -DISCONTINUITY-SEQUENCE标签的值(第6.2.2节)。

      添加或删除EXT-X-STREAM-INF标签或EXT-XI-FRAME-STREAM-INF 
      标签(第6.2.4节)。请注意,客户端不需要
      重新加载主播放列表文件,因此更改它们可能不会
      立即生效。

      将EXT-X-ENDLIST标记添加到播放列表(第6.2.1节)。

   此外,播放列表文件可以包含EXT-X-PLAYLIST-TYPE标记
   ,其值为EVENT或VOD。如果标签存在且
   值为EVENT,则服务器不得更改或删除任何部分
   播放列表文件(尽管它可以向其添加行)。如果标签
   存在且值为VOD,则播放列表文件不得更改。

   播放列表中的每个媒体片段都必须应用EXTINF标记,以
   指示媒体片段的持续时间。

   媒体播放列表中的每个片段都具有整数不连续
   序列号。
   除了媒体内的时间戳之外,还可以使用不连续序列号来
   跨不同的再现来同步媒体段。Pantos&May将于2014年10月16日到期[第23页]

 
Internet-Draft HTTP Live Streaming 2014年4月

 
   段的不连续序列号是EXT-X 
   -DISCONTINUITY-SEQUENCE标记的值(如果没有,则为零)加上
   URI行之前的播放列表中的EXT-X-DISCONTINUITY标记的数量
   细分市场。

   包含EXT-X-PLAYLIST-TYPE标记的媒体播放列表,其
   值为EVENT或VOD,不得包含EXT-X-DISCONTINUITY- 
   SEQUENCE标记。

   服务器可以
   通过对其应用EXT-X-PROGRAM-DATE-TIME标记将绝对日期和时间与媒体段相关联。这
   定义了(挂钟)日期和时间的信息映射
   由标签指定给段中的第一媒体时间戳,
   其可以用作寻找,显示或用于其他
   目的的基础。如果服务器提供此映射,它应该将
   EXT-X-PROGRAM-DATE-TIME 
   标记应用于应用了EXT-X-DISCONTINUITY标记的每个段。

   如果媒体播放列表包含
   演示文稿的最终媒体段,则播放列表文件必须包含EXT-X-ENDLIST 
   标记。

   如果媒体播放列表不包含EXT-X-ENDLIST标记,则
   服务器必须使新版本的播放列表文件可用,
   其中包含至少一个新媒体段。它必须可用
   相对于以前版本的播放列表文件
   可用的时间:不早于该时间
   之后的目标持续时间的一半,并且不晚于该时间
   之后的目标持续时间的1.5倍。

   如果服务器希望删除整个演示文稿,则必须使
   播放列表文件对客户端不可用。它应该确保
   播放列表文件中的所有媒体段
   至少在删除时播放列表文件的持续时间内仍然可供客户端使用。

6.2.2。现场播放列表

   服务器可以通过
   从播放列表文件中删除媒体段来限制媒体段的可用性(第6.2.1节)。如果
   要删除媒体段,播放列表文件必须只包含
   一个EXT-X-MEDIA-SEQUENCE标记。对于
   从播放列表文件中删除的每个媒体段,其值必须递增1 。

   媒体片段必须按照
   它们在播放列表中出现的顺序从播放列表文件中删除。

   如果
   播放列表文件的持续时间减去段的持续时间
   小于目标持续时间的三倍,则服务器不得从播放列表文件中删除媒体段。

Pantos&May将于2014年10月16日到期[第24页]
 
Internet-Draft HTTP Live Streaming 2014年4月

 
   当服务器从播放列表中删除媒体段时,
   相应的媒体URI应该对客户端保持可用
   的时间段,该时间段等于段的持续时间加上
   分发的最长播放列表文件的持续时间。包含
   该段的服务器。

   如果服务器希望从
   包含EXT-X-DISCONTINUITY标签的媒体播放列表中删除段,则播放列表必须包含
   EXT-X-DISCONTINUITY-SEQUENCE标记。

   如果服务器从媒体
   播放列表中删除EXT-X-DISCONTINUITY标记,它必须增加EXT-X-DISCONTINUITY-的值 –
   SEQUENCE标记,以便
   仍然在播放列表中的段的不连续序列号保持不变。

   如果服务器计划在
   通过HTTP 将媒体段传递给客户端后将其删除,则应该确保HTTP响应包含
   反映计划生存时间的Expires标头。

   实时播放列表不得包含EXT-X-PLAYLIST-TYPE标记。

hls之m3u8、ts流格式详解

HLSHttp Live Streaming 是由Apple公司定义的用于实时流传输的协议,HLS基于HTTP协议实现,传输内容包括两部分,一是M3U8描述文件,二是TS媒体文件。

1、M3U8文件

   用文本方式对媒体文件进行描述,由一系列标签组成。

#EXTM3U

#EXT-X-TARGETDURATION:5

#EXTINF:5,

./0.ts

#EXTINF:5,

./1.ts

#EXTM3U:每个M3U8文件第一行必须是这个tag

#EXT-X-TARGETDURATION:指定最大的媒体段时间长度(秒),#EXTINF中指定的时间长度必须小于或等于这个最大值。该值只能出现一次。

#EXTINF:描述单个媒体文件的长度。后面为媒体文件,如./0.ts 

 

2、ts文件

    ts文件为传输流文件,视频编码主要格式h264/mpeg4,音频为acc/MP3。

   ts文件分为三层:ts层Transport Stream、pes层 Packet Elemental Stream、es层 Elementary Stream. es层就是音视频数据,pes层是在音视频数据上加了时间戳等对数据帧的说明信息,ts层就是在pes层加入数据流的识别和传输必须的信息

注: 详解如下

 (1)ts层     ts包大小固定为188字节,ts层分为三个部分:ts header、adaptation field、payload。ts header固定4个字节;adaptation field可能存在也可能不存在,主要作用是给不足188字节的数据做填充;payload是pes数据。

ts header

sync_byte 8b 同步字节,固定为0x47
transport_error_indicator 1b 传输错误指示符,表明在ts头的adapt域后由一个无用字节,通常都为0,这个字节算在adapt域长度内
payload_unit_start_indicator 1b 负载单元起始标示符,一个完整的数据包开始时标记为1
transport_priority 1b 传输优先级,0为低优先级,1为高优先级,通常取0
pid 13b pid值
transport_scrambling_control 2b 传输加扰控制,00表示未加密
adaptation_field_control 2b 是否包含自适应区,‘00’保留;‘01’为无自适应域,仅含有效负载;‘10’为仅含自适应域,无有效负载;‘11’为同时带有自适应域和有效负载。
continuity_counter 4b 递增计数器,从0-f,起始值不一定取0,但必须是连续的

     ts层的内容是通过PID值来标识的,主要内容包括:PAT表、PMT表、音频流、视频流。解析ts流要先找到PAT表,只要找到PAT就可以找到PMT,然后就可以找到音视频流了。PAT表的PID值固定为0。PAT表和PMT表需要定期插入ts流,因为用户随时可能加入ts流,这个间隔比较小,通常每隔几个视频帧就要加入PAT和PMT。PAT和PMT表是必须的,还可以加入其它表如SDT(业务描述表)等,不过hls流只要有PAT和PMT就可以播放了。

  • PAT表:他主要的作用就是指明了PMT表的PID值。

  • PMT表:他主要的作用就是指明了音视频流的PID值。

  • 音频流/视频流:承载音视频内容。

adaption

adaptation_field_length 1B 自适应域长度,后面的字节数
flag 1B 取0x50表示包含PCR或0x40表示不包含PCR
PCR 5B Program Clock Reference,节目时钟参考,用于恢复出与编码端一致的系统时序时钟STC(System Time Clock)。
stuffing_bytes xB 填充字节,取值0xff

     自适应区的长度要包含传输错误指示符标识的一个字节。pcr是节目时钟参考,pcr、dts、pts都是对同一个系统时钟的采样值,pcr是递增的,因此可以将其设置为dts值,音频数据不需要pcr。如果没有字段,ipad是可以播放的,但vlc无法播放。打包ts流时PAT和PMT表是没有adaptation field的,不够的长度直接补0xff即可。视频流和音频流都需要加adaptation field,通常加在一个帧的第一个ts包和最后一个ts包里,中间的ts包不加。

PAT格式

table_id 8b PAT表固定为0x00
section_syntax_indicator 1b 固定为1
zero 1b 固定为0
reserved 2b 固定为11
section_length 12b 后面数据的长度
transport_stream_id 16b 传输流ID,固定为0x0001
reserved 2b 固定为11
version_number 5b 版本号,固定为00000,如果PAT有变化则版本号加1
current_next_indicator 1b 固定为1,表示这个PAT表可以用,如果为0则要等待下一个PAT表
section_number 8b 固定为0x00
last_section_number 8b 固定为0x00
开始循环    
program_number 16b 节目号为0x0000时表示这是NIT,节目号为0x0001时,表示这是PMT
reserved 3b 固定为111
PID 13b 节目号对应内容的PID值
结束循环    
CRC32 32b 前面数据的CRC32校验码

PMT格式

table_id 8b PMT表取值随意,0x02
section_syntax_indicator 1b 固定为1
zero 1b 固定为0
reserved 2b 固定为11
section_length 12b 后面数据的长度
program_number 16b 频道号码,表示当前的PMT关联到的频道,取值0x0001
reserved 2b 固定为11
version_number 5b 版本号,固定为00000,如果PAT有变化则版本号加1
current_next_indicator 1b 固定为1
section_number 8b 固定为0x00
last_section_number 8b 固定为0x00
reserved 3b 固定为111
PCR_PID 13b PCR(节目参考时钟)所在TS分组的PID,指定为视频PID
reserved 4b 固定为1111
program_info_length 12b 节目描述信息,指定为0x000表示没有
开始循环    
stream_type 8b 流类型,标志是Video还是Audio还是其他数据,h.264编码对应0x1b,aac编码对应0x0f,mp3编码对应0x03
reserved 3b 固定为111
elementary_PID 13b 与stream_type对应的PID
reserved 4b 固定为1111
ES_info_length 12b 描述信息,指定为0x000表示没有
结束循环    
CRC32 32b 前面数据的CRC32校验码



(2)pes层

     pes层是在每一个视频/音频帧上加入了时间戳等信息,pes包内容很多,我们只留下最常用的。

pes start code 3B 开始码,固定为0x000001
stream id 1B 音频取值(0xc0-0xdf),通常为0xc0

视频取值(0xe0-0xef),通常为0xe0
pes packet length 2B 后面pes数据的长度,0表示长度不限制,

只有视频数据长度会超过0xffff
flag 1B 通常取值0x80,表示数据不加密、无优先级、备份的数据
flag 1B 取值0x80表示只含有pts,取值0xc0表示含有pts和dts
pes data length 1B 后面数据的长度,取值5或10
pts 5B 33bit值
dts 5B 33bit值

     pts是显示时间戳、dts是解码时间戳,视频数据两种时间戳都需要,音频数据的pts和dts相同,所以只需要pts。有pts和dts两种时间戳是B帧引起的,I帧和P帧的pts等于dts。如果一个视频没有B帧,则pts永远和dts相同。从文件中顺序读取视频帧,取出的帧顺序和dts顺序相同。dts算法比较简单,初始值 + 增量即可,pts计算比较复杂,需要在dts的基础上加偏移量。

     音频的pes中只有pts(同dts),视频的I、P帧两种时间戳都要有,视频B帧只要pts(同dts)。打包pts和dts就需要知道视频帧类型,但是通过容器格式我们是无法判断帧类型的,必须解析h.264内容才可以获取帧类型。

举例说明:

                         I          P          B          B          B          P

读取顺序:         1         2          3          4          5          6

dts顺序:           1         2          3          4          5          6

pts顺序:           1         5          3          2          4          6

点播视频dts算法:

dts = 初始值 + 90000 / video_frame_rate,初始值可以随便指定,但是最好不要取0,video_frame_rate就是帧率,比如23、30。

pts和dts是以timescale为单位的,1s = 90000 time scale , 一帧就应该是90000/video_frame_rate 个timescale。

用一帧的timescale除以采样频率就可以转换为一帧的播放时长

点播音频dts算法:

dts = 初始值 + (90000 * audio_samples_per_frame) / audio_sample_rate,audio_samples_per_frame这个值与编解码相关,aac取值1024,mp3取值1158,audio_sample_rate是采样率,比如24000、41000。AAC一帧解码出来是每声道1024个sample,也就是说一帧的时长为1024/sample_rate秒。所以每一帧时间戳依次0,1024/sample_rate,…,1024*n/sample_rate秒。

直播视频的dts和pts应该直接用直播数据流中的时间,不应该按公式计算。

(3)es层

     es层指的就是音视频数据,我们只介绍h.264视频和aac音频。

h.264视频:

     打包h.264数据我们必须给视频数据加上一个nalu(Network Abstraction Layer unit),nalu包括nalu header和nalu type,nalu header固定为0x00000001(帧开始)或0x000001(帧中)。h.264的数据是由slice组成的,slice的内容包括:视频、sps、pps等。nalu type决定了后面的h.264数据内容。

F 1b forbidden_zero_bit,h.264规定必须取0
NRI 2b nal_ref_idc,取值0~3,指示这个nalu的重要性,I帧、sps、pps通常取3,P帧通常取2,B帧通常取0
Type 5b 参考下表
nal_unit_type 说明
0 未使用
1 非IDR图像片,IDR指关键帧
2 片分区A
3 片分区B
4 片分区C
5 IDR图像片,即关键帧
6 补充增强信息单元(SEI)
7 SPS序列参数集
8 PPS图像参数集
9 分解符
10 序列结束
11 码流结束
12 填充
13~23 保留
24~31 未使用

     红色字体显示的内容是最常用的,打包es层数据时pes头和es数据之间要加入一个type=9的nalu,关键帧slice前必须要加入type=7和type=8的nalu,而且是紧邻。

转自:http://my.oschina.NET/u/727148/blog/666824

M3U8的简单介绍和在Android中使用的思路

 (在项目中有用到m3u8,现在写篇博文,算是简单的总结

首先是名词介绍,什么是m3u8。m3u8是m3u的一种,不过是utf-8格式的,我记忆中说m3u8是苹果公司搞出来的一种播放的标准吧,其实简单来说就是把整个视频切成一段一段的,然后呢用一个m3u8格式来存这些个小段视频们的地址。可能大家就要问了,这么麻烦干嘛。其实m3u8是为了码率适配而生,而怎样去适配码率呢,这个下面介绍格式的时候会介绍到。

上两个m3u8文件的例子地址,大家能有直观的认识,这是我从Vitamio的官网上扒的。

http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8

http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8

 

我总结了一下我遇到的m3u8格式,虽然不能说涵盖了全部的情况,但是也差不多了:

1、一级目录(我觉着一级的目录没有适配码率的功能)

1.1、打开第一级m3u8文件,能找到真正的视频地址

1.2、第一级m3u8文件中,没有真正的视频地址,需要拼接才能找到真正的视频地址

2、二级目录

2.1、二级地址在一级文件中直接能看到

2.2、二级地址在一级文件中不能直接看到,需要拼接一级链接的地址才能找到二级文件的地址

2.2、打开二级目录,能找到整整的视频地址

2.3、没有真正的视频地址,需要拼接才能找到真正的视频地址

 

篇幅关系我不能给大家全部列举出这些全部的可能性。我就拿最麻烦的举个例子,其他的大家自行脑补吧,原理都是一样的,怎么样都跑不出协议的范畴之外。

我们在浏览器中输入http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8,会得到一个名为bipbopall.m3u8的文件,此文件的内容如下:

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000

gear1/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=311111

gear2/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=484444

gear3/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=737777

gear4/prog_index.m3u8

这就符合上面的2.2种情况,这四种码率的m3u8的地址你都不能直接得到,那怎么办呢,我们用得到这个文件的链接地址的前半段http://devimages.apple.com/iphone/samples/bipbop/拼接上二级文件的相对地址gear1/prog_index.m3u8得到一个地址http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8

把此地址放到浏览器中,我们又会得到一个同样名为prog_index.m3u8的文件,内容如下:

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10, no desc

fileSequence0.ts

#EXTINF:10, no desc

fileSequence1.ts

#EXTINF:10, no desc

fileSequence2.ts

#EXTINF:10, no desc

fileSequence3.ts

#EXTINF:10, no desc

fileSequence4.ts

#EXTINF:10, no desc

fileSequence5.ts

#EXTINF:10, no desc

.

.

.

#EXTINF:10, no desc

fileSequence179.ts

#EXTINF:1, no desc

fileSequence180.ts

#EXT-X-ENDLIST

我们很开心的发现,这设计简直是巧(sang)夺(xin)天(bing)工(kuang),我们还是没有得到真正的视频地址,老办法拼接后我们得到这么一段链http://devimages.apple.com/iphone/samples/bipbop/gear1/fileSequence179.ts,这就是真正的视频地址。

我举的这个例子是最复杂的情况,一般的情况对于这个来说都是相对简单的。就跟软件设计一样,我们先考虑到最难得情况,简单的来说就迎刃而解了

此篇博文没有具体介绍m3u8的格式,各位看管不了解的话还请自行Google之。

此篇博文完全是作者的经验之谈,可能有不确切的地方还请见谅,转载请贴原文地址。

M3U8有啥好处 ?

网上搜索了一下,大家众说纷纭,个人理解主要是可以做多码率的适配,根据网络带宽,客户端会选择一个适合自己码率的文件进行播放,保证视频流的流畅。

在IOS device和mac上可以用http的方式进行分发,其中playlist标准为由m3u扩展而来的m3u8文件,媒体文件为MPEG2-TS或者AAC文件(audio only)。

m3u8文件有两种应用场景:

多码率适配流,

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS=”mp4a.40.5″

http://example.com/audio-only.m3u8

单码率适配流

#EXTM3U

#EXT-X-TARGETDURATION:5220

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST



国际标准组织对此的定义 rfc doc:

http://tools.ietf.org/html/draft-pantos-http-live-streaming-06

m3u8 文件是m3u文件的扩展。在该rfc中定义了扩展的关键字:

其中:

#EXT-X-TARGETDURATION

定义每个TS的最大的duration。

#EXT-X-MEDIA-SEQUENCE

定义当前m3u8文件中第一个文件的序列号,每个ts文件在m3u8文件中都有固定唯一的序列号,该序列号用于在MBR时切换码率进行对齐。

#EXT-X-KEY

定义加密方式和key文件的url,用于取得16bytes的key文件解码ts文件。

属性:

METHOD

URL

#EXT-X-PROGRAM-DATE-TIME

第一个文件的绝对时间

#EXT-X-ALLOW-CACHE

是否允许cache。

#EXT-X-ENDLIST

表明m3u8文件的结束。live m3u8没有该tag。

#EXT-X-STREAM-INF

属性:

BANDWIDTH              指定码率

PROGRAM-ID            唯一ID

CODECS                    指定流的编码类型

#EXT-X-DISCONTINUITY

当遇到该tag的时候说明以下属性发生了变化:

file format 

number and type of tracks

encoding parameters

encoding sequence

timestamp sequence

#EXT-X-VERSION             该属性用不用都可以,可以没有





M3U8分顶级M3U8和二级M3U8, 顶级M3U8主要是做多码率适配的, 二级M3U8才是真正的切片文件,

客户端默认会首先选择码率最高的请求,如果发现码率达不到,会请求郊低码率的流

一个实际使用中的顶级M3U8文件如下 :

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=201273221265,BANDWIDTH=358400

11.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=201273221265,BANDWIDTH=972800

22.m3u8



上面顶级M3U8文件中又定义了 11.m3u8 和 22.m3u8 两个二级文件,客户端会选择其中一个获取其内容。

二级M3U8文件内容如下:



#EXTM3U

#EXT-X-VERSION:1

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:3,

1-4.ts

#EXTINF:8,

1-6.ts

#EXTINF:8,

1-8.ts

#EXTINF:8,

1-10.ts

#EXTINF:8,

1-12.ts

#EXTINF:8,

1-14.ts

#EXTINF:8,

1-16.ts

#EXTINF:9,

1-18.ts

#EXTINF:6,

1-20.ts

#EXTINF:8,

1-22.ts

#EXTINF:9,

1-24.ts

#EXTINF:3,

1-26.ts

#EXT-X-ENDLIST



客户端拿到上面的二级M3U8文件后,会继续请求里面的文件,这时就可进行播放了。

上面讲解的是点播的情况,直播的情况,M3U8文件里面会有属性告诉是直播,客户端会定时来请求新的M3U8文件。

流媒体开发之–HLS–M3U8解析(2): HLS草案

目录

1 简介 2

2 概述 2

3 播放列表文件 3

3.1 介绍 3

3.2新标签 4

3.2.1 EXT-X-TARGETDURATION 4

3.2.2 EXT-X-MEDIA-SEQUENCE 4

3.2.3 EXT-X-KEY 4

3.2.4 EXT-X-PROGRAM-DATE-TIME 5

3.2.5 EXT-X-ALLOW-CATCH 5

3.2.6 EXT-X-ENDLIST 5

3.2.7 EXT-X-STREAM-INF 5

3.2.8 EXT-X-DISCONTINUITY 6

3.2.9 EXT-X-VERSION 6

4 多媒体文件 7

5 密钥文件 7

5.1 介绍 7

5.2  IV FOR AES-128 7

6 客户端/服务器行为 8

6.1 介绍 8

6.2 服务器进程 8

6.2.1介绍 8

6.2.2 滑动窗口播放列表 9

6.2.3 加密媒体文件 9

6.2.4 提供变种数据流 10

6.3 客户端进程 10

6.2.1 介绍 10

6.2.2 加载播放列表文件 11

6.2.3播放播放列表文件 11

6.2.4重新载入播放列表文件 11

6.2.5 确定下一个要加载的文件 12

6.2.6 解密经加密的媒体文件 12

7 协议版本的兼容性 12

8 例子 12

8.1 简单的播放列表文件 12

8.2 滑动窗口播放列表,使用https 13

8.3 加密的媒体文件与播放列表文件 13

8.4 变种的播放列表文件 13

 
 

1简介

本文档介绍了通过HTTP传输极大的多媒体数据流的协议[RFC2616]。该协议支持媒体数据的加密,并提供流的备用版本(如比特率)。媒体数据可以在创建后被很快地传输,允许它在近实时被接收。

在第11章中列出了,如HTTP的,描述相关标准的外部引用。

 

2概述

多媒体演示文稿是由播放列表文件中的URI指定的,播放列表是一个由uri和信息标签组成的有序列表。每一个URI都关联了一个媒体文件,该媒体文件是一个连续数据流的一个分片。
为了播放数据流,客户端首先获取播放列表文件,然后获取并播放列表中的每一个媒体文件。正如本文档所描述的那样,它通过重载播放列表文件来发现其他新增的分片。
文档中的关键词“必须”“不准”,“需要”“应该”“不应该”“推荐”“可以”“可选”等见RFC2119
 

3播放列表文件

3.1介绍

播放列表必须是扩展的M3U文件,该文档通过定义新的标签扩展了m3u文件的格式。M3U播放列表是一个文本文件,它包含了各自独立的行,行以一个LF字符或者LF字符紧跟一个CR字符来结束。行可以是一个URI,空行,或者以字符#开头。空行将会被忽略。空格只能作为一行中不同元素间的分隔。

一个URI 表示一个媒体文件或是变种播放列表文件(见3.2.7)

    URI可以是相对的,一个相对的URI必须被包含该URI的播放列表文件中的URI所解析。

以注释字符#开头的行可能是注释或者标签,标签以#EXT开头,其他所有行都应该被忽略。播放列表文件的持续时间是他所指向的媒体文件的时长的总和。

.M3U8作为文件名后缀或者HTTPContent-Type(RFC2616)为“Application/vnd.apple.mpegurl”的M3U播放列表文件使用UTF-8(RFC3629)编码。以.M3U作为文件名后缀或者HTTPContent-Type为“audio/mpegurl”的M3U播放列表文件使用US-ASCII编码。

播放列表文件名必须以.M3U8为后缀、HTTPContent-Type为“Application/vnd.apple.mpegurl”(如果使用http传输)或者以.M3U为后缀、HTTPContent-Type为“audio/mpegurl”。

扩展的M3U文件格式定义了两种标签:EXTM3U和EXTINF。区分扩展的M3U文件与普通M3U文件的关键在于前者的首行为#EXTM3U。

EXTINF是一个记录标记,该标记描述了后边URI所指定的媒体文件。每个媒体文件URI前边必须有EXTINF标签。格式如下:

#EXTINF: <DURATION>,<TITLE>

DURATION是一个整数,它指定了媒体文件以秒为单位的持续时间,时间应四舍五入到最接近的整数。行内逗号后边的剩余部分是媒体文件的名字,该名字是媒体分片的人眼可读的信息标题。

该文档定义了如下的新标签:EXT-X-TARGETDURATION,EXT-X-MEDIA-SEQUENCE,EXT-X-KEY,EXT-X-PROGRAM-DATE-TIME,EXT-X-ALLOW-CATCH,EXT-X-ENDLIST,EXT-X-STREAM-INF,EXT-X-DISCONTINUITY,EXT-X-VERSION

 

3.2新标签

3.2.1      EXT-X-TARGETDURATION

该标签指定了媒体文件持续时间的最大值,播放文件列表中的媒体文件在EXTINF标签中定义的持续时间必须小于或者等于该标签指定的持续时间。该标签在播放列表文件中必须出现一次,其格式为:
# EXT-X-TARGETDURATION:<s>
S是一个以秒为单位的整数。

3.2.2      EXT-X-MEDIA-SEQUENCE

播放列表文件中每个媒体文件的URI都有一个唯一的序列号。URI的序列号等于它之前那个RUI的序列号加一。EXT-X-MEDIA-SEQUENCE指明了出现在播放列表文件中的第一个URI的序列号。其格式如下:
#EXT-X-MEDIA-SEQUENCE:<Number>
播放列表文件中的EXT-X-MEDIA-SEQUENCE标签不能多于一个。如果播放列表文件中没有EXT-X-MEDIA-SEQUENCE标签,那么将会把播放列表中第一个URI的序列号当成0。
媒体文件的序列号码不是必须出现在它的URI中的。见6.3.2和6.3.5。

3.2.3      EXT-X-KEY

媒体文件可能是被加密的,EXT-X-KEY提供了解密媒体文件的必要信息,它的格式如下:
#EXT-X-KEY:METHOD=<method> [,URI = “<uri>”] [,IV = <iv>]
Method属性指定了加密方法,定义了两种加密方法:NONE和AES-128。
加密方法NONE表示媒体文件不被加密,如果加密方法是NONE,那么URI和IV属性不允许存在。
加密方法AES-128表示媒体文件使用高级加密标准128位密钥和PKCS7 padding加密。如果加密方法是AES-128,那么对于URI属性,如果存在,则指定获取密钥的方法;对于IV属性,如果存在,则指定使用密钥的初始化向量。
IV属性出现在协议版本2中,新的EXT-X-KEY将会取代任何一个先前的EXT-X-KEY。
如果播放列表文件没有包含EXT-X-KEY标签,那么媒体文件将不会被加密。
密钥文件的格式见第五章,媒体文件加密信息见5.2、6.2.3、6.3.6。

3.2.4      EXT-X-PROGRAM-DATE-TIME

EXT-X-PROGRAM-DATE-TIME标签将下一个媒体文件的开头和绝对日期关联起来。日期/时间的表示基于ISO/IEC,并且要指明时区。例如:
#EXT-X-PROGRAM-DATE-TIME:<YYYY–MM–DDThh:mm:ssZ>
详见6.2.1和6.3.3

3.2.5      EXT-X-ALLOW-CATCH

EXT-X-ALLOW-CATCH标签指定客户端可以或者不准缓存下载的媒体文件用来重播。它可能会出现在播放列表文件的任何地方,但是不能出现两次或以上。该标签适用于播放列表中的所有分片。其格式如下:
#EXT-X-ALLOW-CACHE:<YES|NO>
详见6.3.3

3.2.6      EXT-X-ENDLIST

    EXT-X-ENDLIST标签标示没有更多媒体文件将会加入到播放列表中,它可能会出现在播放列表文件的任何地方,但是不能出现两次或以上。其格式如下:

#EXT-X-ENDLIST

3.2.7      EXT-X-STREAM-INF

     EXT-X-STREAM-INF标签表示在播放列表中的下一个URI标识另一个播放列表文件。格式如下:

#EXT-X-STREAM-INF:[attribute=value][,attribute=value]* <URI>

在一个EXT-X-STREAM-INF标签中attribute不能出现两次或以上。其它属性定义:
BANDWIDTH = <n>
n为每秒比特数,它必须是每个媒体文件比特速率的上限,必须经过计算包含那些在播放列表中出现的或者将要出现的容器开销。
PROGRAM-ID=<i>
i是一个数字,在播放列表文件的范围内唯一的标识了一个特定的演示文稿。
    一个播放列表文件可能包含多个具有相同PROGRAM-ID 的EXT-X-STREAM-INF标签来标识某个演示文稿的不同编码。这些变种的的播放列表可能包含额外的EXT-X-STREAM-INF标签。
 
CODECS="[format][,format]*"
 
每一种格式都指定了存在于媒体文件中的媒体类型。合法的格式标示符都是那些在ISO文件格式名称空间被RFC4281定义的格式。
RESOLUTION=<N>x<M>
 
N是流中视频水平编码分辨率的近似,以像素数表示,M是编码垂直分辨率的近似。

3.2.8      EXT-X-DISCONTINUITY

     EXT-X-DISCONTINUITY标签表示该标签后边的媒体文件和之前的媒体文件之间的编码间断。特性可能改变的一组是:
file format
number and type of tracks
encoding parameters
encoding sequence
详见第四章,6.2.1、6.3.3。
 
 

3.2.9      EXT-X-VERSION

EXT-X-VERSION标签指出了播放列表版本的适应性。播放列表文件、其关联的媒体和服务器必须遵守最新版本的所有规定。
 
 

4多媒体文件

每一个媒体文件资源定位符都必须标识一个媒体文件,该文件是整体数据的一个分片。每个媒体文件必须按照MPEG-2的传输流和MPEG-2音频流的格式。[ISO13818]
传输流文件必须包含一个MPEG-2节目。在每个文件的开始应该有一个节目关联表和一个节目映射表。包含视频的文件应该有至少一个密钥帧和足够的信息来完全初始化一个视频解码器。
播放列表中的媒体文件必须是编码流中媒体文件的末尾与先前的序列号的延续,除非它是播放列表中出现的第一个媒体文件,或者它前边有EXT-X-DISCONTINUITY标签。
客户端应该准备好处理一个特定类型(音频或视频等)的多个轨道。一个没有优先级的客户端应该选择它能播放的具有最小数字编号的音轨。
客户端应该忽略那些传输流的内部不能识别的流。
媒体文件内样本流和相应的多媒体流的编码参数应保持一致。然而客户端应该解决编码的变化问题,例如缩放视频内容以适应分辨率改变。

5密钥文件

5.1介绍

    URI属性中EXT-X-KEY标签标识一个密钥文件。密钥文件包含解密播放列表中媒体文件的密钥。AES-128加密算法使用16字节的密钥。密钥文件的格式为16字节的二进制数数组。

5.2  IV FOR AES-128

128位AES在加密和解密的时候需要提供一个相同的16字节的初始化向量(IV),变换IV可以提高密钥的健壮性。
如果EXT-X-KEY标签有IV属性,在使用密钥加密或者解密的时候必须使用此属性值作为IV。这个值必须被解释为128位的16进制数,而且必须有前缀0x。
    如果EXT-X-KEY标签没有IV属性,在加密或者解密媒体文件的时候必须使用序列号作为IV值。大端二进制表示的序列号应该放置在16字节的缓冲区中且左边补0。

6客户端/服务器行为

6.1介绍

本章介绍服务器怎样产生播放列表和媒体文件以及客户端怎样下载并播放。

6.2服务器进程

6.2.1介绍

MPEG-2数据流的产生超过了本文档的范围,本文档仅仅假设有一个数据流连续的源。
服务器必须将数据流分割成持续时间大致相等的媒体文件,服务器应该尝试点分割流来支持对个别媒体文件的有效解码,例如包和关键帧的边界。
服务器必须为媒体文件创建URI,允许它的客户端能够获取到文件。
服务器必须创建播放列表。播放列表必须符合第三章描述的格式。服务器要提供的媒体文件的URI必须按顺序出现在播放列表中。如果URI出现在了播放列表中,那么这个媒体文件对于客户端必须是可用的。
播放列表文件必须包含一个EXT-X-TARGRTDURATION标签,它必须指明添加到播放列表中媒体文件的最大EXTINF值。整个演示文稿期间,这个值必须保持不变。典型持续时间为10s。
播放列表文件应该包含EXT-X-VERSION标签来说明流对于版本的兼容性。它的值应该是服务器、播放列表文件和其所关联的媒体文件都能执行的最低协议版本。
如果播放列表文件通过HTTP传输,那么服务器应该支持客户端请求使用gzip内容编码。
从客户端的角度来看,播放列表文件的变更必须是自动的。
服务器不可以改变EXT-X-ALLOW-CATCH的值。
播放列表中每个媒体文件的URI必须以EXTINF作为前缀来说明媒体文件的持续时间。
服务器可以将媒体文件和绝对的日期和时间关联起来,只要在它的URI前缀上一个EXT-X-PROGRAM-DATE-TIME标签。日期和时间的值提供了一个媒体时间表到挂钟时间的信息映射,该挂钟时间可以作为搜索、显示或其他目的的基准。
如果服务器提供了这个映射,那么它应该在每个EXT-X-DISCONTINUITY标签的后边加一个EXT-X-PROGRAM-DATE-TIME标签。
如果播放列表文件包含演示文稿的最后一个分片,那么应该加一个EXT-X-ENDLIST标签。
如果播放列表文件没有包含EXT-X-ENDLIST标签,那么服务器应该使一个新版本的播放列表文件可用,并至少包含一个媒体文件的URI。新的播放列表文件必须与前一个播放列表文件在相对的时间内有效:从上一个播放列表文件开始有效的时间算起,不早于0.5倍持续时间,不晚于1.5倍持续时间。//不太清楚可用是什么意思?
如果服务器期望移除演示文稿,它必须使播放列表文件对于客户端不可用,在播放列表被清除时,它应该确保播放列表文件中的所有媒体文件对于客户端来说至少在一个播放列表文件持续时间内是可用的。

6.2.2滑动窗口播放列表

服务器可以限制最近一段时间添加到播放列表文件中的媒体文件的可用性,为了达到这个目的,播放列表文件必须包含准确的EXT-X-MEDIA-SEQUENCE标签。标签的值是按照从播放列表中移除的媒体文件的URI递增的。
媒体文件的URI必须按照其加入的顺序移除。当服务器从播放列表移除URI时,媒体文件在一段时间内必须保持可用,该时间等于媒体文件的时间加上包含该媒体文件的最长播放列表文件的时间。
当媒体文件通过http传输给客户端后,如果服务器打算移除该文件,那么它应该确保http响应头包含反应生存时间的过期头。
那些不包含EXT-X-ENDLIST标签的播放列表文件的持续时间必须至少三倍于targrtdutration。//为什么是三倍?

6.2.3加密媒体文件

如果媒体文件需要被加密,那么服务器必须定义一个URI来允许被授权的客户端获取包含解密密钥的密钥文件。密钥文件必须符合第五章描述的格式。服务器可以在密钥响应中设置超时头来表名密钥可以被缓存。
如果采用AES-128加密算法,那么AES-128 CBC加密模式应该适应于每一个媒体文件。整个文件必须是加密的。密码块的连接不能用于跨媒体文件。用于解密的初始化向量必须是媒体文件的序列号或者EXT-X-KEY标签的IV属性的值。服务器必须使用这种加密算法和其他由紧随在播放列表文件中URI后边的EXT-X-KEY标签所指定的属性来加密播放列表文件中的每一个媒体文件。EXT-X-KEY标签中方法为none或者没有EXT-X-KEY标签的媒体文件不能被加密。
    如果播放列表文件包含了一个经过加密的媒体文件的URI,那么服务器不可以将EXT-X-KEY标签从播放列表文件中移除。

6.2.4提供变种数据流

服务器可以提供多个播放列表文件来支持对同一个演示文稿的不同编码。提供变种播放列表文件列出每一个变种流,从而使得客户端可以在不同编码之间动态切换。
变种播放列表文件必须为每一个变种流包含一个EXT-X-STREAM-INF标签。同一演示文稿的每个EXT-X-STREAM-INF都必须有相同的programid。每个演示文稿的programid在变种播放列表内必须是唯一的。
如果EXT-X-STREAM-INF标签包含CODECS属性,则属性值必须包含RFC4281定义的所有格式,
 
服务器在生成变种流的时候必须遵守以下规则:
1)每一个变种流必须呈现相同的内容,包括流的间断性。
2)每个变种播放列表文件必须有相同的target duration。
3)只在个别变种播放列表文件中出现的内容必须放在列表文件的头或者尾,且不能超过target duration。
4)变种流内匹配内容,必须有匹配时间戳。这可以使客户端同步流。
5)基本音频流文件必须在文件中第一个样本的采样信号的时间戳前预先准备一个ID3 PRIV标签,标签的所有者标示符为“com.apple.streaming.transportStreamTimestamp”。二进制数据必须是33位的基本时间戳,用8字节的数字表示。
 
另外,所有的变种流都应该包含相同编码的音频二进制流。这使得客户端在不同的流之间切换时没有毛刺声音。//什么事毛刺声音?

6.3客户端进程

6.3.1介绍

客户端怎样获取播放列表中的URI不在本文档的范围之内,我们假设已经获取到了URI。

6.3.2加载播放列表文件

每一次加载或者重载播放列表文件时:
客户端必须保证播放列表文件以EXTM3U标签开头,并且如果协议版本号存在,客户端必须支持该版本。否则,客户端不可以试图使用该列表文件。
客户端可以忽略它不能识别的标签和属性。
如果播放列表文件包含了EXT-X-MEDIA-SEQUENCE标签,那么客户端会假设在播放列表被加载的时间内以及播放列表的持续时间内媒体文件将变得不可用。播放列表的持续时间等于其中包含的媒体文件时长的总和。//为啥假设不可用?

6.3.3播放播放列表文件

当开始播放的时候,客户端首先从播放列表中选择要播放的媒体文件。如果不存在EXT-X-ENDLIST标签,并且客户端想正常播放媒体(按顺序以标准速率播放),那么客户端就不应该从播放列表文件尾部选择少于三个target duration的媒体文件。
为了达到正常播放的目的,媒体文件必须按照他们在播放列表中的顺序播放。客户端还可以用其他任何方式播放,比如顺序播放,随机播放,特效播放等。
对于存在EXT-X-DISCONTINUITY标签的媒体文件,在播放之前客户端必须准备好重置分析和解码器。
为了不间断播放,应该提前载入媒体文件,以补偿延时和吞吐量的变化。
如果播放列表文件包含了EXT-X-ALLOW-CATCH标签,并且它的值为NO,那么客户端在播放以后不可以缓存媒体文件。否则允许缓存用来以后重播。
客户端可以使用EXT-X-PROGRAM-DATE-TIME标签来为用户显示节目的起始时间。如果这个值包含了时区信息,那么客户端应该考虑到这点;如果不包含,那么客户端不可以推测时区。
客户端不能依靠EXT-X-ALLOW-CATCH标签值的正确性和一致性。

6.3.4重新载入播放列表文件

客户端必须阶段性的重新载入播放列表文件,除非文件包含了EXT-X-ENDLIST标签。然而也不能过于频繁的载入。
当客户端第一次载入播放列表文件或者已经载入但是发现文件与上次载入的时候有了变化,客户端都必须等待一段时间在可以再次载入。这段时间被称为原始最小重载延迟,它是从客户端开始载入一个播放列表文件开始计算的。
原始最小重载延迟是播放列表文件中最后一个媒体文件的持续时间。媒体文件的持续时间由EXTINF标签来指定。
如果客户端重载了一个播放列表文件,但是发现文件并没有变化,那么它在重试之前必须等一段时间。最小延迟是target duration的倍数。第一次是0.5倍,第二次1.5倍,3倍。。。

6.3.5确定下一个要加载的文件

当播放列表文件被载入或者重载以后,客户端必须检查播放列表来确定要载入的媒体文件。要载入的第一个文件必须是客户端要播放的第一个文件,见6.3.3。
    如果要播放的文件已经被载入,并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签,那么客户端必须确认播放列表文件包含了最后一个被载入的媒体文件的URI,如果不包含,则暂停播放。要载入的下一个媒体文件必须是上一次载入的媒体文件URI之后的第一个媒体文件的URI。
    如果要播放的文件已经被载入,并且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签,那么要载入的下一个媒体文件就是比上一次载入的文件的序列号大的媒体文件中的序列号最小者。

6.3.6解密经加密的媒体文件

如果播放列表文件包含了一个指定密钥文件URI的EXT-X-KEY标签,客户端必须获取密钥文件,并使用其中的密钥来解密KEY标签之后的所有媒体文件,直到遇到另一个EXT-X-KEY标签为止。

7协议版本的兼容性

客户端和服务器必须使用版本2以及更高版本。
 
 

8例子

8.1简单的播放列表文件

#EXTM3U

#EXT-X-TARGETDURATION:5220

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

 

8.2滑动窗口播放列表,使用https

#EXTM3U

#EXT-X-TARGETDURATION:8

#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:8,

https://priv.example.com/fileSequence2680.ts

#EXTINF:8,

https://priv.example.com/fileSequence2681.ts

#EXTINF:8,

https://priv.example.com/fileSequence2682.ts
 

8.3加密的媒体文件与播放列表文件

#EXTM3U

#EXT-X-MEDIA-SEQUENCE:7794

#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI=”https://priv.example.com/key.php?r=52″

#EXTINF:15,

http://media.example.com/fileSequence52-1.ts

#EXTINF:15,

http://media.example.com/fileSequence52-2.ts

#EXTINF:15,

http://media.example.com/fileSequence52-3.ts

#EXT-X-KEY:METHOD=AES-128,URI=”https://priv.example.com/key.php?r=53″

#EXTINF:15,

http://media.example.com/fileSequence53-1.ts

变种的播放列表文件

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000

http://example.com/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000

http://example.com/mid.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS=”mp4a.40.5″

http://example.com/audio-only.m3u8

ffmpeg对mp4视频进行TS切片及m3u8索引文件支持hls

要想利用HLS来实现视频的在线播放,就得需要将一个完整的视频文件切割成多个ts视频流,然后利用m3u8的索引文件来播放。基本是利用开源的ffmpeg对mp4视频进行TS切片及建立m3u8索引文件支持hls,提升播放速度。

1.ffmpeg切片命令,以H264和AAC的形式对视频进行输出

ffmpeg -i input.mp4 -c:v libx264 -c:a aac -strict -2 -f hls output.m3u8

2.ffmpeg转化成HLS时附带的指令 

-hls_time n: 设置每片的长度,默认值为2。单位为秒

-hls_list_size n:设置播放列表保存的最多条目,设置为0会保存有所片信息,默认值为5

-hls_wrap n:设置多少片之后开始覆盖,如果设置为0则不会覆盖,默认值为0.这个选项能够避免在磁盘上存储过多的片,而且能够限制写入磁盘的最多的片的数量

-hls_start_number n:设置播放列表中sequence number的值为number,默认值为0

3.对ffmpeg切片指令的使用

ffmpeg -i output.mp4 -c:v libx264 -c:a aac -strict -2 -f hls -hls_list_size 0 -hls_time 5 output1.m3u8 

将输出的 M3u8 可直接使用vlc打开,发现拖动的时候会出现画面丢失的现象,待解决。

ffmpeg  -i output.mp4 -vcodec h264 -vb 1000k -profile baseline -acodec aac -ac 1 -ar 44100 -ab 24 -hls_list_size 0 -hls_time 10 -f hls output.mp4.m3u8

利用ffmpeg将MP4文件切成ts和m3u8(苹果官方推荐ffmpeg脚本)

1、将MP4转成m3u8

ffmpeg -i test.mp4 -codec copy -bsf h264_mp4toannexb test.ts

2、将ts转成m3u8

网上很多垃圾文章推荐segmenter工具,但用的时候,3.5G的ts文件丢了一半的数据,于是想到了ffmpeg转。

在国外网站找到命令,一句话搞定,没报半句错:

ffmpeg -i 12生肖.ts -c copy -map 0 -f segment -segment_list playlist.m3u8 -segment_time 10 output%03d.ts

顺便共享给各位国内的同仁,免得深受其苦。毕竟,大家都说HLS代表future,rtsp已经是过去式了。

苹果官方推荐ffmpeg脚本

#!/bin/sh

BR=800k

ffmpeg -i $1 -f mpegts -acodec libmp3lame -ar 48000 -ab 64k -s 320×240 -vcodec libx264 -b $BR -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 5 -trellis 1 -refs 1 -coder0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate $BR -bufsize $BR-rc_eq ‘blurCplx^(1-qComp)’ -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 320:240 -g 30-async 2 sample_$BR_pre.ts

segmenter sample_$BR_pre.ts 10 sample_$BR stream-$BR.m3u8 http://www.ioncannon.net/

rm -f sample_$BR_pre.ts

视频云直播中的关键帧(I帧)技术探秘

一.关键帧的痛点

在视频领域,电影、电视、数字视频等可视为随时间连续变换的许多张画面,而帧则指这些画面当中的每一张。如果把这些帧转换成图片文件,并原封不动的根据一个指定的格式连续摆放的话,就得到了一个视频文件。当然,这个文件有点类似电影的胶片。

不过如果按照如此的方式存储视频的话,文件势必会变得很大,而且其间有很多重复的数据。所以需要专门的算法对视频文件进行编码。对于视频的编码格式来讲,常见的就是H264。

一旦视频进行编码之后,得到的文件可以看做是连续的一组帧的集合,而这一组帧中的每一个都是有自己的类型的。帧的类型分为以下3种:

* Inter Frame(I帧)

* P-Frame(P帧)

* B-Frame(B帧)

其中只有I帧中的数据是可以自描述的,也就是说当我们获得I帧的数据之后,就可以直接解码出当前帧的图像,对于B帧和P帧来说需要找到对应的一个或者多个参考帧才能解码出来,见图一所示;



图一.jpg

因此对于非I帧来说想要进行解码就需要多个参考帧进行计算,并得出最终的结果。由此引出了Group of Picture的概念。

对于P帧和B帧来说,他们所包含的内容可以理解为针对其参考帧的一个patch,也就是一个变化量,所以他们不用包含整个图像的信息,只要描述好与参考帧之间的变化关系即可。所以在字节大小方面,P帧和B帧要远远小于I帧的。这也是视频压缩能节省空间的一个原因所在。

 

二.GoP性能调优分析



Group of Picture(以下简称GoP)顾名思义就是有一组帧组成的一个序列。Wikipedia上给出的一个图简单的解释了GoP是怎么回事(见图二):

图二.jpg

GoP由I帧开始,后面跟随者一组B帧和P帧,直到下一个I帧之前的帧为一个GoP。了解了GoP之后,就会发现播放器只有在拿到某个GoP中的I帧之后才能播放视频。对于GoP来说,编码器都是可以进行设置的,像OBS,ffmpeg等程序可以通过对应的设置和参数对视频的GoP进行设置。

那么引出了一个问题:GoP到底应该设置多大?那么GoP的大小到底有什么影响呢?

  1. GoP设置比较大时:

好处:由于B帧和P帧的字节大小会比I帧小很多,所以GoP越长,所包含的B帧和P帧越多,响应的压缩比也会更高,或者说同样的码率下,视频会更清晰一些。

坏处:对于视频直播来说,播放器连接到服务器的时间是不固定的,当播放器在GoP中间连接服务器,并获取了中间的B帧和P帧,这时播放器是无法对这些帧进行解码的,需要进行丢弃。所以会导致客户端的首屏播放时间变长(客户端需要等待一段时间才能看到图像)。

  2.  如果 GoP设置比较小时:

好处:由于GoP设置小可以降低I帧间隔时间,对于直播来说可以实现秒开的功能。

坏处:由于GoP时间比较短,会导致I帧的比例增高,压缩比降低。同样码率情况下视频的质量会有所下降。

 

三 .为什么我的HLS视频加载会慢?



HLS (HTTP Live Streaming),Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。HLS格式的视频分为两个部分的。首先,HLS会根据指定的切片时间和实际的GoP大小对视频进行切割,并生成.ts文件。其次,HLS会生成一个.m3u8文件来保存这些ts文件的索引。

 

HLS协议可以用来做点播,也可以用来做直播。HLS直播是对直播流实时进行格式转换,并切片出.ts文件,同时更新.m3u8文件。客户端通过间歇获取新的.m3u8文件来获取新的.ts文件的索引。HLS点播是通过预先转码好的视频进行切片,并生成一个完整的.m3u8文件,客户端通过获取.m3u8文件来得到视频的时长和各个.ts切片文件的索引。

对于HLS格式的直播来说,.m3u8文件会在生成完一个.ts文件之后才生成。所以对于HLS直播来说,刚开始推流时,到第一个.ts文件生成完毕之前是无法打开的。同理,HLS的延迟也是跟.ts文件切片时间相关的。也就是说HLS的ts文件切片时间为1秒的话,HLS直播的延迟最小为1秒。

当然对于播放端来讲,下载.m3u8文件,然后下载第一个.ts文件也是需要花费一点时间的,那么这个时间也会加在延迟中。

对于.ts文件的切割来讲,并不是告诉直播服务器指定1秒切一个.ts文件他就能保证1秒切一个.ts文件的。.ts文件的切割还是要根据直播视频的实际GoP大小来进行切割的。之前已经讲过,任何一个视频流在播放端需要能获取到完整的GoP才能播放,所以一个.ts文件所实际包含的时间是GoP的整数倍。

例如:当视频的GoP设置为1秒,.ts切片时间为2秒时,实际的.ts文件切片所包含的视频为2秒。当视频的GoP设置为5秒,.ts切片时间为2妙时,实际的.ts文件切片所包含的视频为5秒。

从上面两个例子不难发现,视频流的实际GoP对HLS切片的时间影响非常大。如果视频流的GoP大小设置不合适的话,那么HLS的切片时间就会变长,同时也会增加HLS的延迟。这个特性对于HLS直播来讲简直就是延迟杀手。如果推流上来的GoP为10秒的话,不要说切出来一个.ts文件就要10秒,同时下载一个.ts文件所花费的时间也会大大增加。

另外如果是HLS点播的话,流的GoP设置过大也会影响点播视频的加载时间。一般的一个720P的视频,如果切片时间为2秒的话,单个.ts文件也就是在百K字节上下。对于现有的网速来讲,下载这么一个.ts文件很快。但如果源视频的GoP很大,会导致第一个.ts文件所包含的视频时常变长(比如10秒),同时导致.ts文件的大小膨胀到接近1M字节上下。想想看,如果第一个.ts文件是1M字节的话,播放器下载这个.ts文件的时间会是多久。

 

四.为什么我的RTMP直播首屏渲染速度很慢?



RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。

对于RTMP协议的直播视频来说,它并不像HLS协议需要切.ts文件,它只是把视频流实时地进行转发即可。RTMP协议本身也会抽象出一个Packet的概念来封装H264编码中的帧,也就是一个Packet会包含1到多个帧,播放器以Packet为单位来进行解码。那么RTMP的问题在于客户端连接的时间点是否合适。

例如一个RTMP直播流的GoP设置为2秒,如果客户端接入时间刚好是第4秒,那么客户端会获取一个包含I帧的Packet,由于I帧是自描述的,所以客户端可以直接解码出该帧的画面并显示出来。但是当客户端的接入之间为第5秒,那么他会获得一个包含B帧或者P帧的Packet,由于客户端拿到的数据是一个不完整的GoP,所以客户端只好抛弃当前获取的Packet中视频的数据,而且只有当获取到包含下一个GoP的I帧的Packet时才能解码出图像。因此客户端会等待1秒才能播放出画面。

由此我们可以得出一个结论:GoP的大小会影响RTMP播放端的首帧加载时间。也就是说首帧加载时间最久为一个GoP的时间。当然,如何客户端运气够好的话,可以瞬间播放。

为了优化首帧加载时间,我们可以在流媒体服务器端增加一个缓存,把上一个GoP缓存在内存中。如果客户端接入的话,我们首先放出来的是上一个GoP。这样客户端接到的数据永远是一I帧开头的数据。

不过这种方案对于延迟要求比较高的场景下就不适合。毕竟GoP的缓存会增加一个延迟,具体延迟的时间也是跟GoP大小相关的。如果要实时性,那么GoP缓存并不能很好的解决问题,只能通过减少关键帧间隔的方式来进行调优了。



五.结论



在视频直播和点播盛行的年代,对于GoP大小的取舍还是需要看具体应用场景。对于直播来讲,对延迟要求敏感的应用来说,1~2秒的GoP大小还是比较合适的,至于GoP缓存来讲,还是不用为好。如果是对延迟要求不敏感,对首屏播放时间很敏感的应用,GoP还是1~2秒最为合适,GoP缓存应该是必备的。另外直播使用HLS的话,延迟是绝对PK不过RTMP的。

对于点播的应用来说,视频加载速度是个硬指标,如果不是HLS格式的话,GoP大小适当选大一点可以降低视频文件大小,提高视频打开速度。HLS格式的话,还是推荐在2秒左右,否则很影响视频打开速度的。

其实视频直播技术的挑战很多,这次分享的只是其中一小部分,也是迅达云SpeedyCloud研发团队的经验总结,希望能够和大家多交流,一起为技术社区发展做些有益的事情。



六.Q&A



问题1:求推荐视频直播的知识资源,关于rmtp、h264编码的更多知识。大量视频文件存储服务器技术方案有哪些?

这方面的内容,可以通过翻阅wikipedia,Google来获取想要的知识。另外看一些开源项目的文档也会有所帮助。比如Nginx-RTMP-Module,Simple-rtmp-server,ffmpeg

 

问题2:视频直播这块有没有开源项目可以来练手的?  

上面说到了Nginx-rtmp,SRS,FFMPEG

 

问题3:nginx 的rtmp模块,可以配置gop缓存时间吗?

nginx-rtmp是没有GoP Cache的。Simple-RTMP-Server是有的。

 

问题4:求现在创业公司如何快速搭建自己的直播平台,是自研还是使用第三方平台,有哪些第三方平台可以推荐?

搭建直播平台的话,涉及的东西会很多,一般都是自研一部分,外包一部分。

 

问题5:老师说到B侦和P侦需要参考侦才能解码,但在GoP的那张图中没有看到参考侦呀?

最前面和最后的两个橘黄色的是I帧。另外参考不一定是I帧,前后的B帧和P帧都可以做参考

 

问题6:ffmepg里,哪个选项是配置 x264的 gop的?

-g参数可以设置gop长度,单位是帧。

 

问题7:就rtmpserver来说,哪些server 使用者更多些?

这个看应用场景了,如果是自己用,Nginx-rtmp比较容易一些,如果是做CDN的话,simple-rtmp-server是个比较好的选择。