RTMP协议
发布时间:2020-12-15 04:32:14 所属栏目:百科 来源:网络整理
导读:RTMP协议 ? RTMP协议封包 由一个包头和一个包体组成,包头可以是4种长度的任意一种:12,8,4,? 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,AMFSize,AMFType,StreamID信息,?8字节的包头只纪录了时间戳,其他字节的包头纪录信息依次类推?。包体最大长度
RTMP协议?
RTMP协议封包 由一个包头和一个包体组成,包头可以是4种长度的任意一种:12,8,4,? 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,AMFSize,AMFType,StreamID信息,?8字节的包头只纪录了时间戳,其他字节的包头纪录信息依次类推?。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节.
完整的12字节RTMP包头每个字节的含义:
一、Head_Type 第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算:? Head_Type的前两个Bit和长度对应关系:
Head_Type的后面6个Bit和StreamID决定了ChannelID。??StreamID和ChannelID对应关系:StreamID=(ChannelID-4)/5+1?参考red5
例如在rtmp包里面经常看到的0xC2,就表示一字节的包头,channel=2. 二、TiMMER TiMMER占3个字节纪录的是时间戳,音视频流的时间戳是统一排的。可分为绝对时间戳和相对时间戳。 fms对于同一个流,发布的时间戳接受的时间戳是有区别的 publish时间戳,采用相对时间戳,时间戳值等于当前媒体包的绝对时间戳与上个媒体包的绝对时间戳之间的差距,也就是说音视频时间戳在一个时间轴上面.单位毫秒。 play时间戳,相对时间戳,时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包的绝对时间戳之间的差距,也就是说音视频时间戳分别为单独的时间轴,单位毫秒。 flv格式文件时间戳,绝对时间戳,时间戳长度3个字节。超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。 flv格式文件影片总时间长度保存在onMetaData的duration属性里面,长度为8个字节,是一个翻转的double类型。 三、AMFSize AMFSize占三个字节,这个长度是AMF长度,可超过RTMP包的最大长度128字节。如果超过了128字节,那么由多个后续RTMP封包组合,每个后续RTMP封包的头只占一个字节。一般就是以0xC?开头。 四、AMFType AMFSize占三个字节,这个长度是AMF长度,可超过RTMP包的最大长度128字节。 AMFType是包的类型
五、StreamID StreamID是音视频流的ID,如果AMFType!=0x08 或!=0x09那么 StreamID为0。 ChannelID 和StreamID之间的计算公式:StreamID=(ChannelID-4)/5+1?参考red5 例如当ChannelID为2、3、4时StreamID都为1 当ChannelID为9的时候StreamID为2 六、封包分析 例如有一个RTMP封包的数据 03?00 00 00?00 01 02?14?00 00 00 00?02?00 07?63 6F 6E 6E 65 63 74?00?3F F0 00 00 00 00 00 00?08?,,, 数据依次解析的含义? 03表示12字节头,channelid=3 000000表示Timmer=0 000102表示AMFSize=18 14表示AMFType=Invoke 方法调用 ?00 00 00 00 表示StreamID = 0 //到此,12字节RTMP头结束 ? 下面的是AMF数据分析,具体的AMF0数据格式请参考 http://www.cnweblog.com/fly2700/archive/2008/04/09/281432.html 02表示String 0007表示String长度7 63 6F 6E 6E 65 63 74 是String的Ascall值"connect" 00表示Double 3F F0 00 00 00 00 00 00 表示double的0.0 08表示Map数据开始
AMF0数据类型
Rtmp包默认的最大长度为128字节,(或通过chunksize改变rtmp包最大长度),当AMF数据超过128Byte的时候就可能有多个rtmp包组成,如果需要解码的rtmp包太长则被TCP协议分割成多个TCP包.那么解码的时候需要先将包含rtmp包的tcp封包合并,?再把合并的数据解码,解码后可得到amf格式的数据,将这些AMF数据取出来就可以对AMF数据解码了.服务器和Flash客户端之间的命令都是用AMF格式的数据在传送,例如connect() publish()等命令和服务器as脚本里面自己定义的一些方法. 常用的数据类型整理如下:?
? AMF0数据的嵌套关系如下: Object={ObjType + ObjValue} ObjType={CORE_BOOLEAN、CORE_NUMBER、CORE_STRING、CORE_DATE、CORE_ARRAY、CORE_MAP、CORE_OBJECT} CORE_BOOLEAN={Value(1 Byte)} CORE_NUMBER={Value(8 Byte)} CORE_String={StringLen(2 Byte) + StringValue(StringLen Byte)} CORE_DATE={value(10 Byte)} CORE_Array={ArrayLen(4 Byte) + Object} CORE_Map={MapNum(4 Byte) + CORE_Object} CORE_Object={CORE_String + Object} 例如完成握手后,Flash向FMS发送的第一个RTMP数据,内容如下: 上面一段数据由2个RTMP包组成,2个RTMP包头分别用蓝色表示,第一个蓝色的是12字节的包头,后面一个蓝色的C3是一个字节的包头,绿色部分是AMF数据,红色的是AMF数据类型,整个RTMP解码过程如下 [2008-06-18 16:59:20] DecodeInvoke: [2008-06-18 16:59:20] InvokeName:String:connect [2008-06-18 16:59:20] InvokeID:Double:0 [2008-06-18 16:59:20] Map:MapNum:0 [2008-06-18 16:59:20] Params:{ [2008-06-18 16:59:20] Key:String:objectEncoding [2008-06-18 16:59:20] Value:Double:0 [2008-06-18 16:59:20] Key:String:app [2008-06-18 16:59:20] Value:String:mediaserver [2008-06-18 16:59:20] Key:String:fpda [2008-06-18 16:59:20] Value:Bool:0 [2008-06-18 16:59:20] Key:String:tcUrl [2008-06-18 16:59:20] Value:String:rtmp://127.0.0.1/mediaserver [2008-06-18 16:59:20] Key:String:audioCodecs [2008-06-18 16:59:20] Value:Double:615 [2008-06-18 16:59:20] Key:String:videoCodecs [2008-06-18 16:59:20] Value:Double:76 [2008-06-18 16:59:20] }End Params [2008-06-18 16:59:20] InvokeParams:String:PUBLISHER [2008-06-18 16:59:20] InvokeParams:String:streamRecode ? 详细的数据类型,参考Red5 FMS3中为了实现H.264数据的直播而增加了一个数据类型,这个类型的值为0x16,这个类型不在下表中,如果需要请参看 http://www.cnweblog.com/fly2700/archive/2009/02/06/297957.html enum AMF { ??? /** ???? * Boolean value marker constant ???? */ ??? TYPE_BOOLEAN = 0x01,? ??? /** ???? * String marker constant ???? */ ?TYPE_STRING = 0x02, ??? /** ???? * Object marker constant ???? */ ??? TYPE_OBJECT = 0x03, ??? /** ???? * Movieclip marker constant ???? */ ??? TYPE_MOVIECLIP = 0x04, ??? /** ???? * Null marker constant ???? */ ?TYPE_NULL = 0x05, ??? /** ???? * Undefined marker constant ???? */ ?TYPE_UNDEFINED = 0x06, ??? /** ???? * Object reference marker constant ???? */ ?TYPE_REFERENCE = 0x07, ??? /** ???? * Mixed array marker constant ???? */ ?TYPE_MIXED_ARRAY = 0x08, ??? /** ???? * End of object marker constant ???? */ ?TYPE_END_OF_OBJECT = 0x09, ??? /** ???? * Array marker constant ???? */ ?TYPE_ARRAY = 0x0A, ??? /** ???? * Date marker constant ???? */ ?TYPE_DATE = 0x0B, ??? /** ???? * Long string marker constant ???? */ ?TYPE_LONG_STRING = 0x0C, ??? /** ???? * Unsupported type marker constant ???? */ ?TYPE_UNSUPPORTED = 0x0D, ??? /** ???? * Recordset marker constant ???? */ ?TYPE_RECORDSET = 0x0E, ??? /** ???? * XML marker constant ???? */ ?TYPE_XML = 0x0F, ??? /** ???? * Class marker constant ???? */ ?TYPE_CLASS_OBJECT = 0x10, ??? /** ???? * Object marker constant (for AMF3) ???? */ ?TYPE_AMF3_OBJECT = 0x11, ??? /** ???? * true marker constant ???? */ ?VALUE_TRUE = 0x01, ??? /** ???? * false marker constant ???? */ ?VALUE_FALSE = 0x00 };
关于rtmp封包中数据类型为0x16的封包 使用rtmp协议从FMS3中拉音视频数据的时候,会收到AMFType=0x16的封包,这种包在FMS2中从没有出现过. rtmp包头的第8个字节就是AMFType,也就是数据类型。例如AMFType=0x08表示音频包,AMFType=0x04表示Ping包等等。FMS3中为了实现H.264数据的直播而增加了一个数据类型,这个类型的值为0x16。AMFType=0x16的包中既包含了音频帧也包含了视频帧。其中音频帧和视频帧是一种新的格式存放的,类似FLV文件存储格式,每个音视频包作为一个Tag,许多的Tag组成了这个AMFType=0x16的数据类型,Tag的格式如下: 用途 大小(Byte) 数据含义? StreamType 1 流的种类(0x08=音频,0x09=视频)? MediaSize? 3 媒体数据区域大小?? TiMMER 3 绝对时间戳,单位毫秒? Reserve 4 保留,值为0? MediaData MediaSize 媒体数据,音频或视频? TagLen 4 帧的大小,值为媒体数据区域大小+参数长度(MediaSize+1+3+3+4)?
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |