HTTP progressive download渐进式传输

综述的协议对比，可以参考不同音视频传输协议的对比

比如现在常见的移动端互动直播，常使用HTTP-flv方式在网络上传输。使用flv极为简单的封装格式，再叠加http良好的网络兼容性，另外播放延迟和首帧时间也有较好的保证。

HTTP流式传输相关参考文档：

又拍云直播协议HTTP-FLV详解

一、基本介绍

• 1)HTTP-FLV是一个非常民间的说法，反正也没啥很官方的文档。一般叫做FLV over HTTP, 通常说的http progressive streaming(也因为并不是真正的流式传输而被称为progressive download)
• 2)progressive streaming和real streaming之间的差别是——看起来都是流式传输播放。progressive streaming实际上是一种将整个直播数据虚拟成一个巨大的flv文件，从服务端渐进地下载缓存小分片文件来模拟流式传输的方式，也就是说服务端将音视频数据封装为一个个小分片（在http-flv中就是一个个flv tag)，然后客户端通过HTTP请求下载到这些数据，缓存在本地然后播放，服务端只需要是HTTP服务器即可，不够安全。而真正的流式传输是像RTMP协议那样，建立了一个与服务端的长连接，服务端一有数据就实时转发，对服务端要求较高，比较安全。
• 3)个人觉得在互动直播播放端的话，除了对版权要求很高的场景或者要求码率自适应，实在想不到有什么原因要弃用HTTP-FLV。
• 4)http-flv的技术点就是——基本都是很成熟通用的技术，包括http服务器，flv tag的封装，播放flv数据。
• 5)HTTP progressive download和hls之类的差别——都是基于HTTP，都是服务端切成了一个个小分片，那怎么理解？（个人理解，错误请拍砖）除去hls的码率自适应特征，首先http-flv并不是一种物理上的切片文件，实际上服务端最终存储的仍旧是一个大文件（不过是容量体积不断增长的大文件），而hls却实实在在地将音视频数据封装在不同的物理分片中（服务端如果不及时清理，就会有大量的细碎文件存在）。http-flv中提到的分片只是整个大文件中的一段，拿出来无法独立解码播放，需要依赖最开始请求的metadata，而ts是可以独立解码播放的。通常来说http-flv提到的分片都很小，而hls中的切片比较大，这就导致了hls很严重的延迟问题。

二、开发过程中的改进点

直播过程中的累积延迟消除

会有专门的文档提到如何处理延迟，这里简单提一下。由于依赖可靠传输，播放过程中难免会出现延迟逐渐增大的情况，这显然是互动直播无法接受的。客户端播放http-flv时可以采用丢帧策略和抖动缓冲。

• 丢帧策略 丢帧就是按照字面的理解，解码播放过程中丢弃一些帧。丢哪些帧/关键帧还是仅非关键帧/视频帧还是音频帧/用什么频率和策略来丢帧？这些可以单独写一篇文章了。。。总之就是基于不花屏不变声，也不严重跳播的前提下平滑丢帧。
• 抖动缓冲 抖动缓冲其实还是为了适应网络环境及减小延迟，比如当网络变差或切换网络的时候（肿么破，根本下不到新的数据啊），这时候显然要把延迟的优先级降低，用已缓冲的数据来保证播放，而如果网络良好或者从较差网络中恢复，一下子从服务端下载到很多的数据了，也不用担心会卡顿了，这时候可以提高延迟的优先级，减少缓冲数据。

关于安全性

好像除了在建立连接的时候，加一些鉴权，暂时也没想到什么合适的办法。

客户端的支持

android和ios端观看互动直播的需求比较多，如果使用通用的软解码方式，可以统一双端播放内核，减少开发量。但是弊端也比较明显，一般软解的效率都比硬解要差一些。如果考虑到解码效率，决定选择硬解的话，需要客户端先将数据解封装成H264/AAC裸数据，然后再送入解码器，就不能直接调用系统上层封装的解码接口了。

关于P2P

相比起rtmp的封闭性来说，http-flv传输中客户端的P2P至少是可以实现的。但会要求客户端多缓冲一些数据。