月度归档：2016年09月

redis编译错误：Test replication partial resync: no backlog in tests/integration/replication-psync.tcl

下午配置一台centos服务器，编译redis， 运行make test 报了这样的一个错误：

!!! WARNING The following tests failed:
*** [err]: Test replication partial resync: ok psync (diskless: yes, reconnect: 1) in tests/integration/replication-psync.tcl
Expected condition ‘[s -1 sync_partial_ok] > 0’ to be true ([s -1 sync_partial_ok] > 0)
Cleanup: may take some time… OK
make[1]: *** [test] Error 1
make[1]: Leaving directory `/usr/local/src/redis-3.2.1/src’
make: *** [test] Error 2

■ 解决办法：

1，只用单核运行 make test：

taskset -c 1 sudo make test


2，更改 tests/integration/replication-psync.tcl 文件：

vi tests/integration/replication-psync.tcl

把对应报错的那段代码中的 after后面的数字，从100改成 500。我个人觉得，这个参数貌似是等待的毫秒数。


编辑文件tests/integration/replication-psync.tcl

然后找到after 100 把此值修改成200或者300。重新执行make test就可以了



same issue on

Linux sie 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux

was able to pass all tests ONLY when using single CPU core using:

taskset -c 0 sudo make test

is it OK to run the server anyway?

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

重磅：广电总局祭出牌照大旗，直播行业即将洗牌，面临生死大考

摘要：广电总局要求直播须持有视听许可证，否则不得开展业务。视听直播行业该应当引起非常重视，因为这样的监管信号比之以往更为强烈，如果再不加以重视，直播平台将终矣。

近日，国家新闻出版广电总局下发《关于加强网络视听节目直播服务管理有关问题的通知》，重申相关规定，要求网络视听节目直播机构依法开展直播服务。

通知要求的核心在于：未持有《信息网络传播视听节目许可证》的机构和个人，不得通过互联网直播间以个人网络演艺形式开展直播业务，也不得利用网络直播平台（直播间）开办新闻、综艺、体育、访谈、评论等各类视听节目。未经批准，任何机构和个人不得在互联网上使用“电视台”、“广播电台”、“电台”、“TV”等广播电视专有名称开展业务。

1.直播行业大限已至？

“狼来了”喊了无数遍后，广电总局这次是真的下决心要整顿视听直播行业了，毕竟截止今年4月，广电总局就已然进行了25轮行业专项整治。我们如果仔细观察，其实也不难发现在整个互联网行业下，近期各主管部门纷纷出台规定，针对各类互联网模式加重监管要求，并导致多个行业领域面临生死大考。P2P网络借贷行业在《网络借贷信息中介机构业务活动管理暂行办法》出台后，97%以上的P2P平台都面临淘汰；网约专车行业在《网络预约出租汽车经营服务管理暂行办法》颁出后，各网约车平台即面临重大变革；跨境电商行业在海关总署的税收新政后变得惴惴不案，但还好获得暂缓一年的转型机会。

2015-2016年，在《网络安全法立》法大趋势下，互联网行业内各领域都加速了洗牌的节奏，这也是近些年互联网行业乱象丛生背后的监管之义。2016年被称为网络直播元年，但是视听直播行业却长期一直处于风口浪尖之中，不论是业内的不正当竞争，例如今年刚判决的电竞直播第一案，还是直播领域内的低俗秀场表演，都让人感觉这简直就是一个无法无天的领域。

如果对广电总局的多轮视听节目整治有所观察，我们会发现广电总局此次使用了最为简洁明了的语言，直接针对视听直播，要求其持有《信息网络传播视听节目许可证》，其实真可谓不多见，甚至说是前所未有，这更与往常只打击低俗内容，以及以混沌不清的官方法律字眼表述直播节目和视听许可证之间的关系并不相同。所以，我们认为视听直播行业该应当引起非常重视，因为这样的监管信号比之以往更为强烈，如果再不加以重视，直播平台将终矣。

2.视听直播行业持证现状观察

根据艾瑞咨询《2016年中国在线直播行业专题研究》显示，2015年中国在线直播平台数量接近200家。而网络资料显示，截至2016年初，获取《信息网络传播视听节目许可证号的平台》数量为332家，而其中“广播电视、电台”类传统媒体持证机构为91家，报社类持证机构为35家，新闻类机构为15家，以及我们所知道的优酷、乐视等老牌视频节目服务商。稍加观察即可发现，持证单位主要还是分布在国有封闭型广播电视传媒行业内，纯互联网新兴商业体下其实并不普遍，特别是垂直直播领域内单位几乎可以忽略不计。

先来看一下图表。以下是2016年4月，互联网法律匠公众平台（MCLAWMAN）所做的统计图表《视听商业模式准入证照聚合图表》:

QQ截图20160912154007.jpg

 

这张图表将目前主流的互联网视频创业分类为综合视频、音乐、电台、直播及短视频这几类。从图上可以看出，和互联网视频创业相关的许可证照主要包括信息网络传播视听节目许可证、广播电视节目制作经营许可证、网络文化经营许可证、互联网新闻信息服务许可证、互联网出版许可证及出版物经营许可证这几个大类。可以看到，持有《信息网络传播视听节目许可证》的单位也主要分布于视频点播类平台，而不是垂直视频直播类平台，这与视频点播类明确需要视听许可证之监管规则不无关系。

再细一步，观察直播领域，目前商业模式主要分类为秀场直播、游戏电竞直播、电商类直播、社交类直播、活动分享类直播、弹幕类直播等，在各类不同的直播模式下，持证情况也各不相同，但总体上绝大部分直播平台，不论是PC端，还是移动端，均没有办理《信息网络传播视听节目许可证》，照这样的模式下去，包括新浪直播、斗鱼直播、网易直播、脉脉职播等都将不能继续从事直播业务了。

QQ截图20160912153938.jpg

 

3.博弈：《视听许可证》和《网络文化许可证》

长期以来，基于秀场直播以及游戏电竞类直播而兴起的互联网直播行业，一直将自己的商业模式定位于“网络表演”，而非视听节目，这也导致绝大部分直播平台转而向各地文化主管单位申办《网络文化经营许可证》，即“文网文证”，而不向广电系统申办视听许可证的直接原因。这点其实一直令行业普遍感到非常困惑，连很多行业从业者也不太了解两个证照之间的区别。只取得文网文证就开展直播业务，这到底有没有法律依据？答案很可惜：没有！

根据文化部《互联网文化管理暂行规定》规定，“互联网文化产品”均需办理《网络文化经营许可证》，而“互联网文化产品”包括“专门为互联网而生产的网络音乐娱乐、网络游戏、网络演出剧（节）目、网络表演、网络艺术品、网络动漫等互联网文化产品”，其中就包括网络表演。而互联网文化活动也包括“将文化产品登载在互联网上……供用户浏览、欣赏、使用或者下载的在线传播行为”。

再看，2008年开始实施的《互联网视听节目服务管理规定》规定“互联网视听节目服务，是指制作、编辑、集成并通过互联网向公众提供视音频节目，以及为他人提供上载传播视听节目服务的活动”，顾名思义，凡是通过互联网向公众提供视频和音频节目的，都必须办理该视听许可证。

而当我们比较以上两个规定时，几乎所有正常人都看不出网络视频节目到底该办哪个证，还是两个都要办。但依据《互联网视听节目服务管理规定》，不论是直播还是点播，都必须办理视听许可证，毕竟我们仍应当看到，很多直播平台也不是纯直播，其在直播后也可以提供回看的点播功能。同时，我们在《互联网视听节目服务业务分类目录》中也看到第二大类中第7项视听许可为“一般社会性、团体性文化活动、体育赛事等向公众进行实况视音频直播的服务”，即包括直播业务。

而为什么很多平台只申请了文网文证就宣告万事大吉了呢，主要原因还在于“自我催眠”，或者说是自欺欺人，毕竟这些平台基本都是拿不到视听许可证的，所以只能寻求文网文证的庇护，加上主管部门总是没来查处，所以更加有恃无恐了。

关键问题来了，为什么说基本都是拿不到视听许可证的？根据目前法规，办理《信息网络传播视听节目许可证》的第一项要求就是申办单位“为国有独资或国有控股单位”，意思就是说，不好意思，事况重大，只有我们国有单位才能办证，一般小单位就算了别来凑热闹了，是不是就有点傻眼了。而且非控股的非公有资本如果想来投资，你们之间不得有关联关系——你们别想联合起来。反观办理文网文证，其要求就没有这么苛刻了，目前来看最大的实质性“障碍”是“不低于100万元的注册资金，其中申请从事网络游戏经营活动的应当具备不低于1000万元的注册资金”的要求，这对于动则进入ABCDE轮融资的互联网企业而言，不是个问题。所以，天然的“又红又专”纯正血统才是难以逾越的障碍。

4.广播电视专用名称不得使用

《关于加强网络视听节目直播服务管理有关问题的通知》规定：未经批准，任何机构和个人不得在互联网上使用“电视台”、“广播电台”、“电台”、“TV”等广播电视专有名称开展业务。而遍观我国广播电视管理条例等法规，我国并没有明确规定何为“广播电视专有名称”，只在我国《互联网视听节目服务管理规定》第二十三条规定“擅自在互联网上使用广播电视专有名称开展业务的”，可“并处3万元以下罚款”。

在这样的模式下，目前业内所知道的虎牙TV，战旗TV、熊猫TV都不能再使用了而应当改名了，顺着这个思路（即电视的英文翻译为TV），我们发现例如FM也将不能使用了，因为FM的中文即为电台，那么类如蜻蜓FM、荔枝FM、豆辩FM、考拉FM等都应当进入改名行列。可以想象一下，如果这些公司都已经将FM列入商标申请，那该有多少悲催，一切从头来。

全局精确流量调度新思路-HttpDNS服务详解

小编：对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”，导致访问错误内容，失败连接等，让我们在互联网上畅游的爽快瞬间消失，而对于这关键的第一跳，鹅厂也在持续深入研究和思考对策，今天小编就邀请了我们负责这块域名解析的好伙伴—廖伟健同学跟我们做一个分享。同时，今天小编也非常希望了解大伙对这块内容的感受，所以今天文中加入了投票功能，希望您投上神圣的一票哦。事不延迟，我们启程 ！

但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？

一、问题根源：

要解决问题，我们得先得了解下现在国内各ISP的LocalDNS的基本情况。国内运营商LocalDNS造成的用户访问异常可以归为下三类：

1、域名缓存：

域名缓存很好理解，就是LocalDNS缓存了腾讯的域名的解析结果，不向腾讯权威DNS发起递归，示意图如下：

022251G8O.jpg

022251G8O.jpg

022251G8O.jpg

为何LocalDNS要把域名解析结果进行缓存呢？原因有以下几个：

（1）保证用户访问流量在本网内消化：国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量，同时减少跨网结算，运营商在网内搭建了内容缓存服务器，通过把域名强行指向内容缓存服务器的IP地址，就实现了把本地本网流量完全留在了本地的目的。

（2）推送广告：有部分LocalDNS会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。

这种类型的行为就是我们常说的域名缓存，域名缓存会导致用户产生以下的访问异常：

A、仅对80端口的http服务做了缓存，如果域名是通过https协议或其它端口提供服务的，用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等。

B、缓存服务器的运维水平参差不齐，时有出现缓存服务器故障导致用户访问异常的问题。

2、解析转发：

除了域名缓存以外，运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。正常的LocalDNS递归解析过程是这样的：

而部分小运营商为了节省资源，就直接将解析请求转发到了其它运营的递归LocalDNS上去了：

这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

3、LocalDNS递归出口NAT：

LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址：

这样的直接后果就是GSLB DNS收到的域名解析请求的来源IP还是成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

二、现有的解决方案及存在的问题：

运营商的LocalDNS解析域名异常，给对用户访问腾讯业务的体验造成了非常大的损害。那么我们是如何处理这些域名解析异常的问题的呢？

1、实时监控+商务推动：

这种方案是目前腾讯的运营团队一直在使用的方案。这种方案就是周期比较长，毕竟通过行政手段来推动运营商来解决这个问题是比较耗时的。另外我们通过大数据分析，得出的结论是Top 3的问题用户均为移动互联网用户。对于这部分用户，我们有什么技术手段可以解决以上的问题呢？

2、绕过自动分配DNS，使用114dns或Google public DNS：

这个方案看上去很美好，114dns是国内最大的中立缓存DNS，而Google又是秉承不作恶理念的互联网工程帝国巨鳄，而且腾讯的权威DNS又支持edns-client-subnet功能，能直接识别使用Google publicDNS解析腾讯域名的用户的IP地址，不会出现流量调度失效。但是问题来了：

（1）如何在用户侧构造域名请求：对于PC端的客户端来说，构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包，而且要兼容各种iOS和android的版本的话，技术上是可行的，只是兼容的成本会很高。

（2）推动用户修改配置极高：如果要推动用户手动修改PC的DNS配置的话，在PC端和手机客户端的WiFI下面还算勉强可行。但是要用户修改在移动互联网环境下的DNS配置，其难度不言而喻。

3、完全抛弃域名，自建connectcenter进行流量调度：

如果要采用这种这种方案的话，首先你就得要拿到一份准确的IP地址库来判断用户的归属，然后再制定个协议搭个connect center来做调度，然后再对接入层做调度改造。这种方案和2种方案一样，不是不能做，只是成本会比较高，尤其对于腾讯这种业务规模如此庞大的公司而言。

三、利用HttpDNS解决用户域名解析异常：

既然上面的方案都存在那么多的问题，那有没有一种调度精准、成本低廉、配置方便的基于域名的流量调度系统呢？答案是肯定的。腾讯公司的GSLB 团队推出了一种全新的域名解析调度系统：HttpDNS。HttpDNS是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案，专治LocalDNS解析异常以及流量调度不准。详细介绍如下：

（1）HttpDNS基本原理：

HttpDNS的原理非常简单，主要有两步：

A、客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）

B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。

（2）HttpDNS优势：

从原理上来讲，HttpDNS只是将域名解析的协议由DNS协议换成了Http协议，并不复杂。但是这一微小的转换，却带来了无数的收益：

A、根治域名解析异常：由于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。

B、调度精准：HttpDNS能直接获取到用户IP，通过结合腾讯自有专利技术生成的IP地址库以及测速系统，可以保证将用户引导的访问最快的IDC节点上。

C、实现成本低廉：接入HttpDNS的业务仅需要对客户端接入层做少量改造，无需用户手机进行root或越狱；而且由于Http协议请求构造非常简单，兼容各版本的移动操作系统更不成问题；另外HttpDNS的后端配置完全复用现有权威DNS配置，管理成本也非常低。总而言之，就是以最小的改造成本，解决了业务遭受域名解析异常的问题，并满足业务精确流量调度的需求。

D、扩展性强：HttpDNS提供可靠的域名解析服务，业务可将自有调度逻辑与HttpDNS返回结果结合，实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址，指定网络类型的用户连接指定的IP地址等。

当然各位可能会问：用户将首选的域名解析方式切换到了HttpDNS，那么HttpDNS的高可用又是如何保证的呢？另外不同运营商的用户访问到同一个HttpDNS的服务IP，用户的访问延迟如何保证？

为了保证高可用及提升用户体验，HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络，与全国多个主流运营商建立了BGP互联，保证了这些运营商的用户能够快速地访问到HttpDNS服务；另外HttpDNS在多个数据中心进行了部署，任意一个节点发生故障时均能无缝切换到备份节点，保证用户解析正常。

四、接入效果及未来展望：

当前HttpDNS已在腾讯内部接入了多个业务，覆盖数亿用户，并已持续稳定运行超过一年时间。而接入了HttpDNS的业务在用户访问体验方面都有了非常大的提升。以某个接入HttpDNS的业务为例，该业务仅通过接入HttpDNS，在未做任何其它优化的情况下，用户平均访问延迟下降超过10%，访问失败率下降了超过五分之一，用户访问体验的效果提升非常显著。另外腾讯的HttpDNS服务除了在腾讯内部被广泛使用以外，也受到了业务同行的肯定。国内最大的publicDNS服务商114dns在受到腾讯DNS的启发下，也推出了HttpDNS服务。

在未来的日子里，腾讯GSLB团队将会在腾讯内部进一步推广HttpDNS服务，并将在实际业务的需求下对HttpDNS服务进行升级，如提供更为通用、安全、简单的接入协议，进一步提升接入用户的网络访问体验等等。希望HttpDNS能为各位在解决域名解析异常及全局流量调度失效方面提供一个简单、可行的思路，也欢迎各位业界同行与腾讯一起，就如何进行更精准的全局流量调度方面进行更为深入的讨论！

http://119.29.29.29/

接入文档
https://www.dnspod.cn/httpdns/guide

DEMO
https://www.dnspod.cn/httpdns/demo

腾讯DNSPod公共DNS 119.29.29.29 体验报告

腾讯DNSPod推出新Open DNS服务，公共DNS是119.29.29.29

python升级导致yum命令无法使用的解决办法

1、报错信息如下：

[plain]view plain copy

 print?

  1. [root@develop bin]# yum  
  2. [root@develop local]# yum -y install prce  
  3. There was a problem importing one of the Python modules  
  4. required to run yum. The error leading to this problem was:  
  5.   
  6.   
  7.    No module named yum  
  8.   
  9.   
  10. Please install a package which provides this module, or  
  11. verify that the module is installed correctly.  
  12.   
  13.   
  14. It’s possible that the above module doesn’t match the  
  15. current version of Python, which is:  
  16. 2.6.1 (r261:67515, Aug 7 2010, 11:36:17)  
  17. [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)]  
  18.   
  19.   
  20. If you cannot solve this problem yourself, please go to  
  21. the yum faq at:  
  22. http://wiki.linux.duke.edu/YumFaq  









错误原因：错误信息描述为 yum 所依赖的python 不相符，请安装相对应的python即可





2、查看yum版本

[root@develop local]# rpm -qa |grep yum

yum-3.2.8-9.el5.centos.1

yum-metadata-parser-1.1.2-2.el5





3、查看python版本

[plain]view plain copy

 print?

  1. [root@develop local]# whereis python  
  2. python: /usr/bin/python2.4 /usr/bin/python /usr/lib/python2.4 /usr/local/bin/python2.6 /usr/local/bin/python2.6-config /usr/local/bin/python /usr/local/lib/python2.6 /usr/share/man/man1/python.1.gz  







果然装了两个版本python





4、执行python，查看到使用2.6.1的版本

[plain]view plain copy

 print?

  1. [root@develop local]# python  
  2. Python 2.6.1 (r261:67515, Aug 7 2010, 11:36:17)  
  3. [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2  
  4. Type “help”, “copyright”, “credits” or “license” for more information.  
  5. >>>  









5、猜测yum调用了高版本的python。





6、解决方法：

查找yum和 yum-updatest文件,并编辑此py文件

[plain]view plain copy

 print?

  1. [root@develop local]# which yum  
  2. /usr/bin/yum  
  3. [root@develop local]# vi /usr/bin/yum  
[plain]view plain copy

 print?

  1. [root@develop local]# vi /usr/bin/yum-updatest  







将

#!/usr/bin/python

改为:

#!/usr/bin/python2.4





然后保存OK.


如果不修改/usr/bin/yum ,则yum无法使用

如果不修改/usr/bin/yum-updatest  会出现如下错误

 File “/usr/sbin/yum-updatesd”, line 35, in <module>
    import dbus
ImportError: No module named dbus

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处理RTMP流媒体的命令大全

 ffmpeg处理RTMP流媒体的命令大全,将文件当做直播送至live,将直播媒体保存至本地文件,将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流,将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流,将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变,功能一样，只是采用-x264opts选项….

1、将文件当做直播送至live

[plain] view plain copy

  1. ffmpeg -re -i localFile.mp4 -c copy -f flv rtmp://server/live/streamName  

2、将直播媒体保存至本地文件

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/streamName -c copy dump.flv  

3、将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream  

4、将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://server/live/h264Stream  

5、将其中一个直播流，视频不变，音频改用faac压缩，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -acodec libfaac -ar 44100 -ab 48k -vcodec copy -f flv rtmp://server/live/h264_AAC_Stream  

6、将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变

[plain] view plain copy

  1. ffmpeg -re -i rtmp://server/live/high_FMLE_stream -acodec copy -vcodec x264lib -s 640×360 -b 500k -vpre medium -vpre baseline rtmp://server/live/baseline_500k -acodec copy -vcodec x264lib -s 480×272 -b 300k -vpre medium -vpre baseline rtmp://server/live/baseline_300k -acodec copy -vcodec x264lib -s 320×200 -b 150k -vpre medium -vpre baseline rtmp://server/live/baseline_150k -acodec libfaac -vn -ab 48k rtmp://server/live/audio_only_AAC_48k  

7、功能一样，只是采用-x264opts选项

[plain] view plain copy

  1. ffmpeg -re -i rtmp://server/live/high_FMLE_stream -c:a copy -c:v x264lib -s 640×360 -x264opts bitrate=500:profile=baseline:preset=slow rtmp://server/live/baseline_500k -c:a copy -c:v x264lib -s 480×272 -x264opts bitrate=300:profile=baseline:preset=slow rtmp://server/live/baseline_300k -c:a copy -c:v x264lib -s 320×200 -x264opts bitrate=150:profile=baseline:preset=slow rtmp://server/live/baseline_150k -c:a libfaac -vn -b:a 48k rtmp://server/live/audio_only_AAC_48k  

8、将当前摄像头及音频通过DSSHOW采集，视频h264、音频faac压缩后发布

[plain] view plain copy

  1. ffmpeg -r 25 -f dshow -s 640×480 -i video=”video source name”:audio=”audio source name” -vcodec libx264 -b 600k -vpre slow -acodec libfaac -ab 128k -f flv rtmp://server/application/stream_name  

9、将一个JPG图片经过h264压缩循环输出为mp4视频

[plain] view plain copy

  1. ffmpeg.exe -i INPUT.jpg -an -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -subq 10 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -flags2 +dct8x8 -trellis 2 -partitions +parti8x8+parti4x4 -crf 24 -threads 0 -r 25 -g 25 -y OUTPUT.mp4  

10、将普通流视频改用h264压缩，音频不变，送至高清流服务(新版本FMS live=1)

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv “rtmp://server/live/h264Stream live=1″