OTT

嵌入在Web页面中的点播节目就是基于HTTP的解决方案，例如优酷、土豆等，就是基于Flash。
但这些节目都不是实时流，而是一种被称为渐进式下载的技术，浏览器从HTTP服务器上下载媒体文件，
当其有足够数据的时候就开始播放内容，同时继续下载媒体文件的余下部分。这种方式最大缺点是，
填充足够数据buffer的时间可能会很长。
4. 这种技术需要可以适应各种终端(PC、STB、移动终端，平板电脑等)；OTT技术在一些场合又被称为三屏融合技术，
正是因为其可以适应各种终端的特点，与另一种融合技术IMS相比，OTT技术可能是三屏融合实现更为快捷和平滑的一种技术；
HLS是三种技术中最早推出的一种OTT技术。
目前，HLS已经是最为广泛的OTT技术，它可以用于各种Apple公司的设备，如iPhone,iPad等。
HLS工作原理是基于分段的TS分片。HLS选择的容器是与传统IPTV、
有线电视、卫星电视一样的MPEG-2 TS流；选择的编码方式是H.264视频和AAC音频，同样是应用十分广泛的格式。
? 首先，编码器将码流编码为H.264/TS格式的多个码率.
? 然后分段器(Segmenter)将这些码率分为多个分片文件(Chunk)，通常时长是10s，同时生成一个Playlist文件(m3u或者是m3u8)用以表示分片文件的下载路径；
? 最后HTTP服务器负责分发这些内容
HLS另一个优势是可以智能实现自适应码率.实时的带宽选择合适的视频质量。根据下载分片文件的时间计算出带宽，然后选择最合适码率
通常：index.m3u8文件：标识一个频道或内容文件可用的不同的Profiles(流质量/码率)；
基本的协议交互过程如下：
1、 GET 获取索引prog_index.m3u8
2、 根据索引GET ts分段filesequence0.ts;
3、 根据索引GET ts分段filesequence1.ts；
4、 继续GET…

1） GET索引的HTTP连接一直保持；
2） GET ts分段的是另一个HTTP连接，如果没有快进快退的话讲一直保持；
3） 首次拖动时由客户端主动关闭上述两个HTTP连接，新建HTTP连接；
4） 再次拖动时关闭原有的GET HTTP连接，如果原有数据正在传输被中断，新建HTTP连接。
基本的协议交互过程同单码率，增加码率自适应功能，码率自适应过程如下：
1、 总是从最低码率Gear1开始播放；
2、 启动网络状况检测；
检测机制尚不明确， Apple给出的描述是“HTTP Live Streaming supports switching between streams dynamically if the available bandwidth changes. The client software uses heuristics to determine appropriate times to switch between the alternates. Currently, these heuristics are based on recent trends in measured network throughput. ” 从抓包情况推测可能就是通过ts分段下载的流量和时长计算吞吐的。
3、 根据检测情况切换码流；
具体是：
1） 先GET 获取新码流的索引prog_index.m3u8；
2） 然后根据索引GET 新码流的下一个ts分段，这里观察到下一个ts分段序号可能与当前码流的ts分段序号是重叠的，也可能是顺序的；
3） 从低向高切时，只要拿到高码率的ts分段，立即播放高码率ts分段；
4） 从高向低切时，直到播放完高码率的ts分段缓存之后，才播放低码率的ts分段；
5） 和单码率VOD点播一样始终保持最大6个ts分段缓存；
6） 根据2））-5），客户端抗扰动能力较强，网络环境恶化又迅速恢复时，不影响播放。

 Envivio与Apache的HTTP协议交互过程如下：
1） PUT上传加密秘钥；
PUT请求两次，第一次PUT没有携带DAV，Apache返回401 Authorization Required，Envivio由此判断上传路径开启DAV控制，后续请求必须携带DAV，第二次PUT携带DAV，Apache返回成功；
2） GET获取频道的索引文件01.m3u8；
该步骤目的尚不清楚，目前的实验表明不论路径有无01.m3u8文件，服务器返回404 Not Found或者200 OK，都不影响Envivio直播输出和iPhone直播观看，但是影响直播ts分段的起始序号，从抓包上无法推测因果关系，有待具体分析。
3） PUT上传频道主索引文件index.m3u8；
Index.m3u8内容固定不变：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=299296
01. m3u8
4） PUT上传第一个ts分段01-0.ts；
前面序号01代表码流序号，后面的序号0代表ts分段序号，根据2），ts分段的序号不一定从0开始，规则尚不清楚。
5） PUT+MOVE上传第一个索引文件01-0.m3u8；
前面序号01代表码流序号，后面的序号0代表索引序号，也即索引中最后一个ts分段序号，根据4），索引序号不一定从0开始。
PUT 01-0.m3u8.part，然后MOVE 01-0.m3u8.part为01-0.m3u8，其实就是上传成功后再改名，避免上传进行中被访问。
6） 步骤4）~ 5）循环执行直至上传完第六个分段01-05.ts和第六个索引01-05.m3u8；
7） 执行4）~ 5）上传完第七个分段01-06.ts和第七个索引01-06.m3u8；
当Envivio参数配成删除过期文件时，Apache上只缓存6个ts分段，与用iPhone 做VOD点播时iPhone上最多缓存6个ts分段是一致的。
8） DELETE删除过期的索引01-0.m3u8；
9） DELETE删除过期的ts分段01-0.ts；
10） 步骤7）-10）循环执行下去

iPhone与Apache的HTTP协议交互过程如下：
1） GET获取索引index.m3u8；
总是连续四个GET，每次请求携带参数有所不同，有待深入分析。
2） 根据index.m3u8，GET获取索引01.m3u8；
根据envivio 的publishingmanager定义的AliasMatch规则，Apache返回最新的内容，即01-0.m3u8的内容。
3） 根据01.m3u8，GET加密秘钥；
4） 根据01.m3u8，GET索引中的第一个ts分段；
5） 根据01.m3u8，GET索引中的第二个ts分段；
6） 根据01.m3u8，GET索引中的第三个也是最后一个ts分段；
7） GET更新索引index.m3u8；
根据envivio的publishingmanager.php和publishingmanager.conf定义的AliasMatch规则，Apache返回最新的内容，即01-1.m3u8的内容。
8） 步骤4）~7）循环执行下去，中间会根据01.m3u8的指示GET新的加密秘钥。