RTP协议全解(H264码流和PS流)-2015-4-22

("RTP协议全解（H264码流和PS流）写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/392073051、RTPHeader解析图11)V：RTP协议的版本号，占2位，当前协议版本号为22)P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。3)X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头4)CC：CSRC计数器，占4位，指示CSRC标识符的个数5)M:标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。6)PT:有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。7)序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。8)时戳(Timestamp)：占32位，必须使用90kHz时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。9)同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。10)特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理取一段码流如下：80e0001e0000d2f000000000419b6b49€?....??....A?kIe10f2653021aff0659971dd22e8c5001?.&S....Y?.?.?P.cc13ec52774ee50e7bfd161166277cb4?.?RwN?.{?..f'?f6e129d5d6a4ef3e12d8fd6c9751e7e9??)????>.??l?Q??cfc75ec8a951f68265d6485a86b0e08c??^??Q??e?HZ????其中，80是V_P_X_CC10000000e0是M_PT11100000001e是SequenceNum00000000000111100000d2f0是Timestamp00000000110100101111000000000000是SSRC00000000000000000000000000000000把前两字节换成二进制如下1000000011100000按顺序解释如下：10是V；0是P；0是X；0000是CC；1是M；1100000是PT；排版不如word看的清晰，大家凑合着看吧。原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/392073052、RTP荷载H264码流图2荷载格式定义三个不同的基本荷载结构，接收者可以通过RTP荷载的第一个字节后5位（如图2）识别荷载结构。1)单个NAL单元包：荷载中只包含一个NAL单元。NAL头类型域等于原始NAL单元类型,即在范围1到23之间2)聚合包：本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本,单时间聚合包类型A(STAP-A)，单时间聚合包类型B(STAP-B)，多时间聚合包类型(MTAP)16位位移(MTAP16),多时间聚合包类型(MTAP)24位位移(MTAP24)。赋予STAP-A,STAP-B,MTAP16,MTAP24的NAL单元类型号分别是24,25,26,273)分片单元：用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型28，29标识常用的打包时的分包规则是：如果小于MTU采用单个NAL单元包，如果大于MTU就采用FUs分片方式。因为常用的打包方式就是单个NAL包和FU-A方式，所以我们只解析这两种。2.1、单个NAL单元包图3定义在此的NAL单元包必须只包含一个。这意味聚合包和分片单元不可以用在单个NAL单元包中。并且RTP序号必须符合NAL单元的解码顺序。NAL单元的第一字节和RTP荷载头第一个字节重合。如图3。打包H264码流时，只需在帧前面加上12字节的RTP头即可。2.2、分片单元（FU-A）图4分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似，NAL单元必须按照RTP顺序号的顺序装配。当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs,MTAPs不可以被分片。FUs不可以嵌套。即,一个FU不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。图4表示FU-A的RTP荷载格式。FU-A由1字节的分片单元指示（如图5），1字节的分片单元头（如图6），和分片单元荷载组成。S:1bit当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。E:1bit当设置成1,结束位指示分片NAL单元的结束，即,荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的FU荷载不是分片NAL单元的最后分片,结束位设置为0。R:1bit保留位必须设置为0，接收者必须忽略该位打包时，原始的NAL头的前三位为FUindicator的前三位，原始的NAL头的后五位为FUheader的后五位。取一段码流分析如下：8060010f000e1000000000007c858882€`..........???000a7fca94053b7f3e7ffe142b2726f8...??.;.>.?.+'&?8988dd8562e16dfc3301381a1035f214????b?m?3.8..5?.846e21248f7262f0517e105f0d427112?n!$?rb?Q~._.Bq.176562a1f144dcdf4b4a38aa96b7dd24.eb??D??KJ8????$前12字节是RTPHeader7c是FUindicator85是FUHeaderFUindicator（0x7C）和FUHeader（0x85）换成二进制如下0111110010000101按顺序解析如下：0是F11是NRI11100是FUType，这里是28，即FU-A1是S，Start，说明是分片的第一包0是E，End，如果是分片的最后一包，设置为1，这里不是0是R，Remain，保留位，总是000101是NAlType，这里是5，说明是关键帧（不知道为什么是关键帧请自行谷歌）打包时，FUindicator的F、NRI是NALHeader中的F、NRI，Type是28；FUHeader的S、E、R分别按照分片起始位置设置，Type是NALHeader中的Type。解包时，取FUindicator的前三位和FUHeader的后五位，即01100101（0x65）为NAL类型。3、RTP荷载PS流针对H264做如下PS封装：每个IDRNALU前一般都会包含SPS、PPS等NALU，因此将SPS、PPS、IDR的NALU封装为一个PS包，包括ps头，然后加上PSsystemheader，PSsystemmap，PESheader+h264rawdata。所以一个IDRNALUPS包由外到内顺序是：PSheaderPSsystemheaderPSsystemMapPESheaderh264rawdata。对于其它非关键帧的PS包，就简单多了，直接加上PS头和PES头就可以了。顺序为：PSheaderPESheaderh264rawdata。以上是对只有视频video的情况，如果要把音频Audio也打包进PS封装，也可以。当有音频数据时，将数据加上PESheader放到视频PES后就可以了。顺序如下：PS包=PS头PES(video)PES(audio)，再用RTP封装发送就可以了。GB28181对RTP传输的数据负载类型有规定（参考GB28181附录B），负载类型中96-127RFC2250建议96表示PS封装，建议97为MPEG-4，建议98为H264即我们接收到的RTP包首先需要判断负载类型，若负载类型为96，则采用PS解复用，将音视频分开解码。若负载类型为98，直接按照H264的解码类型解码。注：此方法不一定准确，取决于打包格式是否标准PS包中的流类型（streamtype）的取值如下：1)MPEG-4视频流：0x10；2)H.264视频流：0x1B；3)SVAC视频流：0x80；4)G.711音频流：0x90；5)G.722.1音频流：0x92；6)G.723.1音频流：0x93；7)G.729音频流：0x99；8)SVAC音频流：0x9B。3.1、PS包头(起始码字段，值为0x000001BA)图71)Packstartcode：包起始码字段，值为0x000001BA的位串，用来标志一个包的开始。2)Systemclockreferencebase，systemclockreferenceextenstion：系统时钟参考字段。3)Packstuffinglength：包填充长度字段，3位整数，规定该字段后填充字节的个数/rtp/8060531f0094890000000000/ps/000001ba€`S..??........?7eff3efb4401005f6bf8000001e01453~.>?D.._k?...?.S8080052fbfcfbed11c42567b13580a1e€€./????.BV{.X..08b14f33693504536d33a8041558d921.?O3i5.Sm3?..X?!9741b9f1753d942b1fbc0bb2b497bf93?A??u=?+.?.?????前12位是RTPHeader，这里不再赘述；000001ba是包头起始码；接下来的9位包括了SCR，SCRE，MUXRate，具体看图7最后一位是保留位（0xf8），定义了是否有扩展，二进制如下11111000前5位跳过，后3位指示了扩展长度，这里是0.3.2、系统标题(SYS)(系统标题。取值0x000001BB的位串)图8Systemheader当且仅当pack是第一个数据包时才存在，即PS包头之后就是系统标题。取值0x000001BB的位串，指出系统标题的开始，暂时不需要处理，读取HeaderLength直接跳过即可。3.3、节目映射流(PSM)(节目流映射。取值0x000001BC的位串)Systemheader当且仅当pack是第一个数据包时才存在，即系统标题之后就是节目流映射。取值0x000001BC的位串，指出节目流映射的开始，暂时不需要处理，读取HeaderLength直接跳过即可。前5字节的结构同系统标题，见图8。取一段码流分析系统标题和节目映射流000001ba45a9d45c3401005f6bf80000...?E??\\4.._k?..01bb000c80ccf504e17fe0e0e8c0c020.?..€??.?.?????000001bc001ee1ff000000181be0000c...?..?......?..2a0a7fff000007081ffea05a90c00000........??Z??..00000000000001e07fe0808005216a75.......?.?€€.!ju前14个字节是PS包头（注意，没有扩展）；接下来的000001bb是系统标题起始码；接下来的000c说明了系统标题的长度（不包括起始码和长度字节本身）；接下来的12个字节是系统标题的具体内容，这里不做解析；继续看到000001bc，这是节目映射流起始码；紧接着的001e同样代表长度；跳过e1ff，基本没用；接下来是0018，代表基本流长度，说明了后面还有24个字节；接下来的1b，意思是H264编码格式；下一个字节e0，意思是视频流；接下里000c，同样代表接下的长度12个字节；跳过这12个字节，看到90，这是G.711音频格式；下一个字节是c0，代表音频流；接下来的0000同样代表长度，这里是0；接下来4个字节是CRC，循环冗余校验。到这里节目映射流解析完毕。（好累）。原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305好戏还在后头呢。3.4、PES分组头部图9别被这么长的图吓到，其实原理相同，但是，你必须处理其中的每一位。1)Packetstartcodeprefix：值为0x000001的位串，它和后面的streamid构成了标识分组开始的分组起始码，用来标志一个包的开始。2)Streamid：在节目流中，它规定了基本流的号码和类型。0x(C0~DF)指音频，0x(E0~EF)为视频3)PESpacketlength：16位字段，指出了PES分组中跟在该字段后的字节数目。值为0表示PES分组长度要么没有规定要么没有限制。这种情况只允许出现在有效负载包含来源于传输流分组中某个视频基本流的字节的PES分组中。4)PTS_DTS：2位字段。当值为'10'时，PTS字段应出现在PES分组标题中；当值为'11'时，PTS字段和DTS字段都应出现在PES分组标题中；当值为'00'时，PTS字段和DTS字段都不出现在PES分组标题中。值'01'是不允许的。5)ESCR：1位。置'1'时表示ESCR基础和扩展字段出现在PES分组标题中；值为'0'表示没有ESCR字段。6)ESrate：1位。置'1'时表示ESrate字段出现在PES分组标题中；值为'0'表示没有ESrate字段。7)DSMtrickmode：1位。置'1'时表示有8位特技方式字段；值为'0'表示没有该字段。8)Additionalinfo：1位。附加版权信息标志字段。置'1'时表示有附加拷贝信息字段；值为'0'表示没有该字段。9)CRC：1位。置'1'时表示CRC字段出现在PES分组标题中；值为'0'表示没有该字段。10)Extensionflag：1位标志。置'1'时表示PES分组标题中有扩展字段；值为'0'表示没有该字段。PESheaderdatalength：8位。PES标题数据长度字段。指出包含在PES分组标题中的可选字段和任何填充字节所占用的总字节数。该字段之前的字节指出了有无可选字段。老规矩，上码流：000001e021338080052b5fdf5c957184...?!3€€.+_?\\?q?aae4e9e9ec40cc17e0687b23f689df90?????@?.?h{#????a9d4be74b967ad346df0920d5a48dd13???t?g?4m??.ZH?.000001是起始码；e0是视频流；2133是帧长度；接下来的两个8080见下面的二进制解析；下一个字节05指出了可选字段的长度，前一字节指出了有无可选字段；接下来的5字节是PTS；第7、8字节的二进制如下：1000000010000000按顺序解析：第7个字节：10是标志位，必须是10；00是加扰控制字段，‘00’表示没有加密，剩下的01,10,11由用户自定义；0是优先级，1为高，0为低；0是数据对齐指示字段；0是版权字段；0是原始或拷贝字段。置'1'时表示相关PES分组有效负载的内容是原始的；'0'表示内容是一份拷贝；第8个字节：10是PTS_DTS字段，这里是10，表示有PTS,没有DTS；0是ESCR标志字段，这里为0，表示没有该段；0是ES速率标志字段，，这里为0，表示没有该段；0是DSM特技方式标志字段，，这里为0，表示没有该段；0是附加版权信息标志字段，，这里为0，表示没有该段；0是PESCRC标志字段，，这里为0，表示没有该段；0是PES扩展标志字段，，这里为0，表示没有该段；本段码流只有PTS，贴一下解析函数[cpp]viewplaincopyprint?1.unsignedlongparse_time_stamp(constunsignedcharp)2.{3.unsignedlongb;4.//共33位，溢出后从0开始5.unsignedlongval;6.7.//第1个字节的第5、6、7位8.b=p++;9.val=(b&0x0e)<<29;10.11.//第2个字节的8位和第3个字节的前7位12.b=((p++))<<8;13.b+=(p++);14.val+=((b&0xfffe)<<14);15.16.//第4个字节的8位和第5个字节的前7位17.b=((p++))<<8;18.b+=(p++);19.val+=((b&0xfffe)>>1);20.21.returnval;22.}其他字段可参考协议解析写在后面：第一次发原创，在这里感谢@cmengwei的无私帮助，提供了很多帮助，非常感谢。文档我都放在了我的资源里面，有1个下载积分，大家不要吝啬，绝对值得！《RTPPayloadFormatforH.264Video》http://download.csdn.net/detail/chen495810242/7904367《MPEG2-2(13818中文版)》http://download.csdn.net/detail/chen495810242/7904401RTP荷载H264的代码参考：http://blog.csdn.net/dengzikun/article/details/5807694RTP荷载PS流的代码参考：http://www.pudn.com/downloads33/sourcecode/windows/multimedia/detail105823.htmlhttp://www.oschina.net/code/snippet_99626_23737请不要跟我要源码，参考我提供的这些，你足以写出一个可以正常运行的程序。授人以鱼不如授人以渔。其他参考：http://blog.csdn.net/duanbeibei/article/details/1698183http://blog.csdn.net/wwyyxx26/article/details/15224879原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305",)