浅谈HTTP-FLV(HTTP-Flash Video)

        如同HLS协议，都是基于HTTP的，HLS有播放列表和视音频数据两类调用，而FLV只有一次HTTP调用，调用请求中携带需要浏览的视音频标识信息。

        HTTP在返回正常的HTTP响应后，开始返回视音频数据。

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: video/x-flv
X-Frame-Options: ALLOW-FROM
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Transfer-Encoding: chunked
Cache-Control: no-cache
Server: Meida Server

        注意上面的Transfer-Encoding这个属性，这是一个HTTP的属性，代表后续返回的视音频数据，是分块传输的还是连续传输的。具体可见http-chunked的定义。

        如果分块，一般一个chunked中包含一帧或多帧经过flv封装的视音频数据，如果不分块，那么就直接发送flv封装的视音频数据，flv的封装这里就不具体描述了，大家可以见这篇博客。

        唯一补充的就是，对于H264的CodecID是0x07,而对于H265的CodecID则是0x0c.

        对于数据帧的描述，大家可见浅谈视频流这篇文章。

        接收端度chunked的数据，先按照http协议解析出chunked的数据，而后再解析flv封装的数据，最后得到裸的视音频编码数据，通过解码器进行解码后得到图片，并按照时间戳进行播放。

        

        对比HLS协议，因为HTTP-FLV的视音频数据，无需服务端进行一定时长的累加，而是达到单帧即可发送的效果，所以实时性会远高于HLS；同时对于直播而言，对于服务器的开销也会降低，无需在服务端累加形成TS数据，收取到的单帧数据可以进行实时发送，减少服务端的内存开销。

        但是HTTP-FLV只有一个Play的指令，而采用更复杂的协议，可以达成对音视频的控制（暂停、跳转等），后续将介绍RTMP协议，同样采用FLV封装，但是在外部协议上增加了更多的控制。