流媒体|从入门到出家:流媒体协议—FLV | WebRTC编风网
0

流媒体|从入门到出家:流媒体协议—FLV

已有 812 人阅读此文 - - 观止云(微信ID: bravovcloud) - dora

认识FLV

上一篇讲了HTTP在流媒体中的应用,接下来我们先把基于HTTP的HTTP-FLV和HLS两种直播中应用非常广泛的协议提一下。

先看看HTTP-FLV长成什么样子:http://ip:port/live/livestream.flv,协议头是http,另外”.flv”这个尾巴是它最明显的特征。

在流媒体尤其是直播应用中,为什么我们要如此重视HTTP-FLV呢,因为他的使用非常广泛,可以这么说,当下的直播平台中大部分的主线路使用的都是HTTP-FLV协议,备线路多为RTMP。小编随便在Safari中打开几个直播平台房间,一抓包就不难发现使用HTTP-FLV协议的身影:熊猫、斗鱼、虎牙、B站。

1

FLV格式

在说HTTP-FLV之前,我们有必要对FLV adobe 官方标准有个认识,因为HTTP-FLV协议中封装格式使用的是FLV。

FLV文件格式标准是写F4V/FLV fileformat spec v10.1的附录E里面的FLVFile Format。

 单位说明

2

 FLV 文件头和文件体 (E.2,E.3)

从整个文件上看,FLV = FLV FileHeader + FLV File Body。通常,FLV的前13个字节(flv header + PreviousTagSize0)完全相同,所以, 程序中会单独定义一个常量来指定。

3

FLV Tag (E.4)

4

Timestamp和TimestampExtended组成了这个TAG包数据的PT 信息,PTS =Timestamp | TimestampExtended << 24。

AudioTag (E.4.2)

由于AAC编码的特殊性, 这里着重说明了AAC编码的Tag格式。

5

AudioTagHeader的第一个字节,也就是接跟着StreamID的1个字节包含了音频类型,采样率等的基本信息。

AudioTagHeader之后跟着的就是AUDIODATA部分了。但是,这里有个特例,如果音频格式(SoundFormat)是 AAC,AudioTagHeader中会多出1个字节的数据AACPacketType,这个字段来表示AACAUDIODATA的类型: 0 = AAC sequence header,1 = AAC raw。

AudioSpecificConfig结构描述非常复杂,在标准文档中是用伪代码描述的,这里先假定要编码的音频格式,做一下简化。

音频编码为:AAC-LC, 音频采样率为 44100。

6

在FLV的文件中,一般情况下AAC sequence header这种包只出现1次, 而且是第一个audio tag,为什么需要这种tag,因为在做FLV demux的时候,如果是AAC的音频,需要在每帧AAC ES流前边添加7个字节ADST头, ADST是解码器通用的格式, 也就是说AAC的纯ES流要打包成ADST格式的AAC文件,解码器才能正常播放。就是在打包ADST的时候,需要samplingFrequencyIndex这个信息,samplingFrequencyIndex最准确的信息是在AudioSpecificConfig中,这样,你就完全可以把FLV文件中的音频信息及数据提取出来,送给音频解码器正常播放了。

VideoTag (E.4.3)

由于AVC(H.264)编码的特殊性,这里着重说明了AVC(H.264编码的Tag格式。

7

VideoTagHeader的第一个字节,也就是接跟着StreamID的1个字节包含着视频帧类型及视频CodecID等最基本信息。

VideoTagHeader之后跟着的就是VIDEODATA部分了。但是,这里有个特例,如果视频格式(CodecID)是AVC,VideoTagHeader会多出4个字节的信息。

AVCDecoderConfigurationRecord包含着是H.264解码相关比较重要的SPS和PPS信息,在给AVC解码器送数据流之前一定要把SPS和PPS信息送出,否则的话,解码器不能正常解码。而且在解码器stop之后再次start之前, 如seek,快进快退状态切换等,都需要重新送一遍SPS和PPS的信息。AVCDecoderConfigurationRecord在FLV文件中一般情况也只出现1次, 也就是第一个video tag。

AVCDecoderConfigurationRecord长度为sizeof(UI8) * (11 +sps_size + pps_size)

8jpg

SCRIPTDATA (E.4.4)

ScriptTagBody内容用AMF编码。

9

一个SCRIPTDATAVALUE记录包含一个有类型的ActionScript值。

 onMetadata (E.5)

FLV metadata object保存在SCRIPTDATA中,叫onMetaData。不同的软件生成的FLV的properties不同。

83030314567409405

keyframes索引信息

官方的文档中并没有对keyframesindex做描述, 但是,flv的这种结构每个tag又不像TS有同步头,如果没有keyframes index的话,seek及快进快退的效果会非常差,因为需要一个tag一个tag的顺序读取。后来在做flv文件合成的时候,发现网上有的flv文件将keyframes信息隐藏在ScriptTag中。keyframes几乎是一个非官方的标准, 也就是民间标准。

两个常用的操作metadata的工具是flvtool2和FLVMDI,都是把keyframes作为一个默认的元信息项目。在FLVMDI的主页上有描述:

10

也就是说keyframes中包含着2个内容‘filepositions’和‘times’分别指的是关键帧的文件位置和关键帧的PTS。通过keyframes可以建立起自己的Index,然后在seek和快进快退的操作中,快速有效地跳转到你想要找的关键帧位置进行处理。

 FLV分析工具

▲  http://www.flvmeta.com/

▲  yamdi:将flv转成带索引的flv,yamdi -i i.flv -o o.flv

▲  flvlib:pip install flvlib,查看索引信息:debug-flv–metadata file.flv

▲  flvchek:http://www.adobe.com/products/adobe-media-server-family/tool-downloads.html

HTTP-FLV

我们这里说的HTTP-FLV,主要是说的是HTTP-FLV流,而不是基于HTTP的FLV视频文件点播,也不是能够随意SEEK的HTTP FLV伪流。

FLV渐进式下载:通过HTTP协议将FLV下载到播放器中播放,无法直接拉到中间去播放。

HTTP FLV伪流:支持SEEK,可从未下载的部分开始播放。

HTTP-FLV流:拥有和流式协议RTMP一样的特征,长连接,流式数据。

HTTP-FLV技术实现

HTTP协议中有个content-length字段的约定,即http的body部分的长度。服务器回复http请求时如果有这个字段,客户端就接收这个长度的数据然后认为数据传输完成了,开始播放。

如果服务器回复http请求中没有这个字段,客户端就一直保持长连接接收数据,直到服务器跟客户端的socket断开。

HTTP-FLV流就利用了上述的第二个原理,服务器回复客户端请求的时候不加content-length字段,在回复了http内容之后,进行持续的数据发送,客户端就一直接收数据,以此实现了HTTP-FLV流直播。

数据传输依然是之前讲过的内容,每一个音视频数据都被封装成包含时间戳信息头的数据包,封装格式采用FLV,传输协议采用http。

HTTP-FLV抓包分析

打开熊猫TV的一条直播流:

http://175.25.168.16/pl3.live.panda.tv/live_panda/d4e0a83a7e0b0c6e4c5d03774169fa3e.flv?wshc_tag=0&wsts_tag=57e233b1&wsid_tag=6a27c14e&wsiphost=ipdbm

返回信息如下:

11

我们发现响应头中出现Connection:close的字段,表示网宿采用的是短连接方式,直接通过服务器关闭连接来确定消息的传输长度。

还有一种实现方式,如果HTTP Header中有Content-Length,那么这个Content-Length既表示实体长度,又表示传输长度。而HTTP-FLV这种流,服务器是不可能预先知道内容大小的,这时就可以使用Transfer-Encoding:chunked模式来传输数据了。如下的响应就是采用的Chunked的方式进行的传输的响应头:

14

HTTP-FLV延迟分析

通过http-flv的实现中不难发现,HTTP-FLV的延迟方面和RTMP能够保持一致。

HTTP-FLV与其他流媒体协议的比较

当前,RTMP、HLS、HTTP-FLV是直播应用的三种主协议,说他主流,主要是因为国内所有的CDN都支持对它们的分发。这里需要注意的是,有些厂商如网宿所指的HDL,国外所称的HFL,本质上都是我们今天所讲的HTTP-FLV协议。

观止云的BMS是在国内最早支持HTTP-FLV的流媒体服务器,且相对于其他方案,观止云BMS集群内部全走RTMP,只是在边缘实时转为HTTP-FLV。如此一来系统架构更简单,稳定,且一路RTMP回源节省了不少回源流量。

延迟比较

HTTP-FLV:低延迟,内容延迟可以低于3秒

RTMP:低延迟,内容延迟可以低于3秒

HLS::延迟较高,一般在10秒左右

易用性比较

RTMP和HTTP-FLV:二者一样,服务端需要专门的流媒体服务器,播放端需要专门的FlashPlayer。但目前浏览器支持Flash较好,所以PC上的播放问题不大,移动端需要专门的SDK解码。

HLS:更为易用,服务端就是WEB服务器外加切片工具。播放端只要是苹果设备、HTML5平台的浏览器均可直接播放。也就是说,移动端不论是IOS还是Android,微信,朋友圈等都可以直播播放HLS直播流。

RTMP和HTTP-FLV的比较:

RTMP和HTTP-FLV延迟上保持一致,在这二者的区别如下:

▲  穿墙:很多防火墙会墙掉RTMP,但是不会墙HTTP,因此HTTPFLV更不容易出问题。

▲  调度:虽然RTMP也能支持302,单实现起来较麻烦。HTTP FLV本身就支持302,更方便CDN进行重定向以便更精准的调度。

▲  容错: HTTP-FLV回源时也可以回多个源,能做到和RTMP一样,支持多级热备。

▲  简单:FLV是最简单的流媒体封装,HTTP是最广泛的协议,这两个组合在一起维护性更高,比RTMP简单。

▲  友好:HTTP-FLV代码量更小,集成SDK也更轻便。使用起来也更简单。

综上,HTTP-FLV协议具有RTMP的延迟优势,又继承了HTTP所有优势,是流媒体直播首选的分发协议。

另外,HTTP-FLV也能在推流端实现,用HTTP进行数据推流。就同样能在推流端实现上述一切优势了,只是目前国内还没有厂商实现。

 

0
相关文章!