标签：rtp   h264   ps   mpeg-2   

写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，

其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。

互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。

原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305

1、RTP Header解析

                                                                                    图1

1)        V：RTP协议的版本号，占2位，当前协议版本号为2

2)        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位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9)        同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10)    特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理

取一段码流如下：

80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI

e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.

cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f‘|?

f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??

2、RTP荷载H264码流

2.1、单个NAL单元包

2.2、分片单元（FU-A）

3、RTP荷载PS流

3.1、PS包头

                                                 图7

1)        Pack start code：包起始码字段，值为0x000001BA的位串，用来标志一个包的开始。

2)        System clock reference base，system clock reference extenstion：系统时钟参考字段。

3)        Pack stuffing length ：包填充长度字段，3 位整数，规定该字段后填充字节的个数

80 60 53 1f 00 94 89 00 00 0000 00 00 00 01 ba €`S..??........?

7e ff 3e fb 44 01 00 5f 6b f8 00 00 01 e0 14 53 ~.>?D.._k?...?.S

80 80 05 2f bf cf bed1 1c 42 56 7b 13 58 0a 1e €€./????.BV{.X..

08 b1 4f 33 69 35 0453 6d 33 a8 04 15 58 d9 21 .?O3i5.Sm3?..X?!

前12位是RTP Header，这里不再赘述；

000001ba是包头起始码；

接下来的9位包括了SCR，SCRE，MUXRate，具体看图7

最后一位是保留位（0xf8），定义了是否有扩展，二进制如下

1111 1000

前5位跳过，后3位指示了扩展长度，这里是0.

3.2、系统标题

                                                           图8

3.3、节目映射流

取一段码流分析系统标题和节目映射流

00 00 01 ba 45 a9 d4 5c 34 0100 5f 6b f8 00 00  ...?E??\4.._k?..

01 bb 00 0c 80 cc f5 04 e1 7f e0 e0 e8 c0 c0 20  .?..€??.?.?????

00 00 01 bc 00 1e e1 ff00 00 00 18 1b e0 00 0c ...?..?......?..

2a 0a 7f ff 00 00 0708 1f fe a0 5a 90 c0 00 00  *........??Z??..

前14个字节是PS包头（注意，没有扩展）；

接下来的00 00 01 bb是系统标题起始码；

接下来的00 0c说明了系统标题的长度（不包括起始码和长度字节本身）；

接下来的12个字节是系统标题的具体内容，这里不做解析；

继续看到00 00 01 bc，这是节目映射流起始码；

紧接着的00 1e同样代表长度；

跳过e1 ff，基本没用；

接下来是00 18，代表基本流长度，说明了后面还有24个字节；

接下来的1b，意思是H264编码格式；

下一个字节e0，意思是视频流；

接下里00 0c，同样代表接下的长度12个字节；

跳过这12个字节，看到90，这是G.711音频格式；

下一个字节是c0，代表音频流；

接下来的00 00同样代表长度，这里是0；

接下来4个字节是CRC，循环冗余校验。

到这里节目映射流解析完毕。（好累）。

原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305

好戏还在后头呢。

3.4、PES分组头部

                                                         图9

别被这么长的图吓到，其实原理相同，但是，你必须处理其中的每一位。

1)        Packet start code prefix：值为0x000001的位串，它和后面的stream id 构成了标识分组开始的分组起始码，用来标志一个包的开始。

2)        Stream id：在节目流中，它规定了基本流的号码和类型。0x(C0~DF)指音频，0x(E0~EF)为视频

3)        PES packet length：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‘时表示ES rate 字段出现在PES 分组标题中；值为‘0‘表示没有ES rate 字段。

7)        DSMtrick mode：1 位。置‘1‘时表示有8 位特技方式字段；值为‘0‘表示没有该字段。

8)        Additionalinfo：1 位。附加版权信息标志字段。置‘1‘时表示有附加拷贝信息字段；值为‘0‘表示没有该字段。

9)        CRC：1 位。置‘1‘时表示CRC 字段出现在PES 分组标题中；值为‘0‘表示没有该字段。

10)    Extensionflag：1 位标志。置‘1‘时表示PES 分组标题中有扩展字段；值为‘0‘表示没有该字段。

老规矩，上码流：

00 00 01 e0 21 33 80 80 05 2b 5f df 5c 95 71 84 ...?!3€€.+_?\?q?

aa e4 e9 e9 ec 40 cc17 e0 68 7b 23 f6 89 df 90 ?????@?.?h{#????

e0是视频流；

21 33 是帧长度；

接下来的两个80 80见下面的二进制解析；

下一个字节05指出了可选字段的长度，前一字节指出了有无可选字段；

接下来的5字节是PTS；

第7、8字节的二进制如下：

1000 0000 1000 0000

按顺序解析：

第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，贴一下解析函数

unsigned long parse_time_stamp (const unsigned char *p)
{
    unsigned long b;
    //共33位，溢出后从0开始
    unsigned long val;

    //第1个字节的第5、6、7位
    b = *p++;
    val = (b & 0x0e) << 29;

    //第2个字节的8位和第3个字节的前7位
    b = (*(p++)) << 8;
    b += *(p++);
    val += ((b & 0xfffe) << 14);

    //第4个字节的8位和第5个字节的前7位
    b = (*(p++)) << 8;
    b += *(p++);
    val += ((b & 0xfffe) >> 1);

    return val;
}

其他字段可参考协议解析

写在后面：

第一次发原创，在这里感谢  @cmengwei  的无私帮助，提供了很多帮助，非常感谢。

文档我都放在了我的资源里面，有1个下载积分，大家不要吝啬，绝对值得！

《RTP Payload Format for H.264 Video》

http://download.csdn.net/detail/chen495810242/7904367

《MPEG2-2(13818中文版)》

http://download.csdn.net/detail/chen495810242/7904401

RTP荷载H264的代码参考：

http://blog.csdn.net/dengzikun/article/details/5807694

RTP荷载PS流的代码参考：

http://www.pudn.com/downloads33/sourcecode/windows/multimedia/detail105823.html

http://www.oschina.net/code/snippet_99626_23737

请不要跟我要源码，参考我提供的这些，你足以写出一个可以正常运行的程序。

授人以鱼不如授人以渔。

其他参考：

http://blog.csdn.net/duanbeibei/article/details/1698183

http://blog.csdn.net/wwyyxx26/article/details/15224879

原创不易，转载请附上链接，谢谢http://blog.csdn.net/chen495810242/article/details/39207305

RTP协议全解（H264码流和PS流）

标签：rtp   h264   ps   mpeg-2   

原文地址：http://blog.csdn.net/chen495810242/article/details/39207305