精华内容
下载资源
问答
  • H264码流解析

    2017-01-21 12:59:47
    H264码流解析 这是一段H264码流,00 00 00 01这是对应forbidden_zero_bit的f(1),接着后面的nal_ref_idc的u(2),这个怎么解呀,有点晕.刚接触不久,nal_unit_type的u(5),后面的profile_idc的u(8)指的是那几个,是多少? ...
    H264码流解析
    
    这是一段H264码流,00 00 00 01这是对应forbidden_zero_bit的f(1),接着后面的nal_ref_idc的u(2),这个怎么解呀,有点晕.刚接触不久,nal_unit_type的u(5),后面的profile_idc的u(8)指的是那几个,是多少?
    nal_ref_idc的u(2)对应67变成前两位0 1也就是1,nal_unit_type取64接着的5位 10 01 1则组合成19 ,profile_idc的u(8)则是后面的64转化为十进制则是100,level_idc则是0D是13,seq_parameter_set_id的ue(v),则指到AC了,这是哥伦布编码,这个是怎么算出来的?


    00 00 00 01是Start code后面的ox67为 0110 0111
    forbidden_zero_bit 是禁止位,应该是第一位即f(1)=0,1为语法有错误
    nal_ref_idc是参考级别,代表被其它帧参考情况,u(2)= 11 = 3最(0为无参考,详见规范)
    nal_unit_type是该帧的类型,为剩下的5位,u(5)= 0 0111 = 7
    目前类型有:
    //H264定义的类型 values for nal_unit_type
    typedef enum {
    NALU_TYPE_SLICE = 1,
    NALU_TYPE_DPA = 2,
    NALU_TYPE_DPB = 3,
    NALU_TYPE_DPC = 4,
    NALU_TYPE_IDR = 5,
    NALU_TYPE_SEI = 6,
    NALU_TYPE_SPS = 7,
    NALU_TYPE_PPS = 8,
    NALU_TYPE_AUD = 9,
    NALU_TYPE_EOSEQ = 10,
    NALU_TYPE_EOSTREAM = 11,
    NALU_TYPE_FILL = 12,
    #if (MVC_EXTENSION_ENABLE)
    NALU_TYPE_PREFIX = 14,
    NALU_TYPE_SUB_SPS = 15,
    NALU_TYPE_SLC_EXT = 20,
    NALU_TYPE_VDRD = 24 // View and Dependency Representation Delimiter NAL Unit
    #endif
    } NaluType;
    可以看出是NALU_TYPE_SPS 即sequence parameter sets
    profile_idc的u(8)则是后面的64转化为十进制则是100,
    66 Baseline
    77 Main
    88 Extended
    100 High (FRExt)
    110 High 10 (FRExt)
    122 High 4:2:2 (FRExt)
    144 High 4:4:4 (FRExt)
    100是High (FRExt)
    “level_idc则是0D是13,seq_parameter_set_id的ue(v),则指到AC了,这是哥伦布编码,答案是0,这个是怎么算出来的?“

    展开全文
  • h264码流分析

    2015-07-03 09:20:34
    vs2013工程,直接输出到控制台,需要查看其它h264码流,只需要更改main函数中的filename。仿Elecard stream analyzer写的。有很多地方不足,但对于初学者可以借鉴学习。有的参数分析不全,有的没有分析。不过sps, ...
  • RTP协议全解析H264码流和PS

    万次阅读 多人点赞 2014-09-12 17:35:05
    1RTP Header解析 2、RTP荷载H264码流 2.1、单个NAL单元包 2.2、分片单元(FU-A) 3、RTP荷载PS 3.1、PS包头 3.2、系统标题 3.3、节目映射 3.4、PES分组头部

    这么多年过去,偶然发现这篇文章的阅读量已经接近20万,略感自豪。

    本想把代码公开了,但是在Gayhub上面发现了更加优秀的项目,分享给大家。

    GitHub - ireader/media-server: RTSP/RTP/RTMP/FLV/HLS/MPEG-TS/MPEG-PS/MPEG-DASH/MP4/fMP4/MKV/WebM

    感谢作者老陈,开源了这么好的东西,避免大家重复造轮子了。

    ---------------------------------------------------------------------以上为2020年更新-----------------------------------------------------------------------

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

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

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

    原创不易,转载请附上链接,谢谢RTP协议全解析(H264码流和PS流)_对牛乱弹琴-CSDN博客_ps流

    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??

    cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????

    其中,
    80               是V_P_X_CC
    e0               是M_PT
    00 1e          是SequenceNum
    把前两字节换成二进制如下
    1000 0000 1110 0000
    按顺序解释如下:
    10               是V;
    0                 是P;
    0                 是X;
    0000           是CC;
    1                 是M;
    110 0000    是PT;
    排版不如word看的清晰,大家凑合着看吧。

    2、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, 27

    3)   分片单元:用于分片单个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: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始,开始位设为0。

    E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束,即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片,结束位设置为0。

    R: 1 bit 保留位必须设置为0,接收者必须忽略该位

    打包时,原始的NAL头的前三位为FU indicator的前三位,原始的NAL头的后五位为FU header的后五位。
    取一段码流分析如下:

    80 60 01 0f 00 0e 10 00 00 0000 00 7c 85 88 82 €`..........|???

    00 0a 7f ca 94 05 3b7f 3e 7f fe 14 2b 27 26 f8 ...??.;.>.?.+'&?

    89 88 dd 85 62 e1 6dfc 33 01 38 1a 10 35 f2 14 ????b?m?3.8..5?.

    84 6e 21 24 8f 72 62f0 51 7e 10 5f 0d 42 71 12 ?n!$?rb?Q~._.Bq.

    17 65 62 a1 f1 44 dc df 4b 4a 38 aa 96 b7 dd 24 .eb??D??KJ8????$
    前12字节是RTP Header
    7c是FU indicator
    85是FU Header
    FU indicator(0x7C)和FU Header(0x85)换成二进制如下
    0111 1100 1000 0101
    按顺序解析如下:
    0                            是F
    11                          是NRI
    11100                    是FU Type,这里是28,即FU-A
    1                            是S,Start,说明是分片的第一包
    0                            是E,End,如果是分片的最后一包,设置为1,这里不是
    0                            是R,Remain,保留位,总是0
    00101                    是NAl Type,这里是5,说明是关键帧(不知道为什么是关键帧请自行谷歌)

    打包时,FUindicator的F、NRI是NAL Header中的F、NRI,Type是28;FU Header的S、E、R分别按照分片起始位置设置,Type是NAL Header中的Type。

    解包时,取FU indicator的前三位和FU Header的后五位,即0110 0101(0x65)为NAL类型。

    3、RTP荷载PS流

            针对H264 做如下PS 封装:每个IDR NALU 前一般都会包含SPS、PPS 等NALU,因此将SPS、PPS、IDR 的NALU 封装为一个PS 包,包括ps 头,然后加上PS system header,PS system map,PES header+h264 raw data。所以一个IDR NALU PS 包由外到内顺序是:PSheader| PS system header | PS system Map | PES header | h264 raw data。对于其它非关键帧的PS 包,就简单多了,直接加上PS头和PES 头就可以了。顺序为:PS header | PES header | h264raw data。以上是对只有视频video 的情况,如果要把音频Audio也打包进PS 封装,也可以。当有音频数据时,将数据加上PES header 放到视频PES 后就可以了。顺序如下:PS 包=PS头|PES(video)|PES(audio),再用RTP 封装发送就可以了。

            GB28181 对RTP 传输的数据负载类型有规定(参考GB28181 附录B),负载类型中96-127

            RFC2250 建议96 表示PS 封装,建议97 为MPEG-4,建议98 为H264

            即我们接收到的RTP 包首先需要判断负载类型,若负载类型为96,则采用PS 解复用,将音视频分开解码。若负载类型为98,直接按照H264 的解码类型解码。

            注:此方法不一定准确,取决于打包格式是否标准

    PS 包中的流类型(stream type)的取值如下:

    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包头

                                                     图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?!

    9741 b9 f1 75 3d 94 2b 1f bc 0b b2 b4 97 bf 93 ?A??u=?+.?.?????

    前12位是RTP Header,这里不再赘述;

    000001ba是包头起始码;

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

    最后一位是保留位(0xf8),定义了是否有扩展,二进制如下

    1111 1000

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

    3.2、系统标题


                                                               图8
    Systemheader当且仅当pack是第一个数据包时才存在,即PS包头之后就是系统标题。取值0x000001BB的位串,指出系统标题的开始,暂时不需要处理,读取Header Length直接跳过即可。

    3.3、节目映射流

    Systemheader当且仅当pack是第一个数据包时才存在,即系统标题之后就是节目流映射。取值0x000001BC的位串,指出节目流映射的开始,暂时不需要处理,读取Header Length直接跳过即可。前5字节的结构同系统标题,见图8。

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

    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??..

    00 00 00 00 00 00 01 e0 7f e0 80 80 0521 6a 75  .......?.?€€.!ju

    前14个字节是PS包头(注意,没有扩展);

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

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

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

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

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

    跳过e1 ff,基本没用;

    接着2个字节代表program_stream_info长度,这里是00 00,即便有值,一般也可以直接跳过;

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

    接下来的1b,意思是H264编码格式;

    下一个字节e0,意思是视频流;

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

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

    下一个字节是c0,代表音频流;

    接下来的00 00同样代表长度,这里是0;

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

    到这里节目映射流解析完毕。(好累)。

    原创不易,转载请附上链接,谢谢RTP协议全解析(H264码流和PS流)_对牛乱弹琴-CSDN博客_ps流

    好戏还在后头呢。

    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'表示没有该字段。

    PES header data length: 8 位。PES 标题数据长度字段。指出包含在PES 分组标题中的可选字段和任何填充字节所占用的总字节数。该字段之前的字节指出了有无可选字段。

    老规矩,上码流:

    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{#????

    a9d4 be 74 b9 67 ad 34 6d f0 92 0d 5a 48 dd 13 ???t?g?4m??.ZH?.

    00 00 01是起始码;

    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;
    }

    其他字段可参考协议解析

    ps:

    遇到00 00 01 bd的,这个是海康私有流的标识,可以丢弃。丢弃之后就看不到原视频里移动侦测时闪烁的红框。

    ps:

    另外,有的hk摄像头回调然后解读出来的原始h.264码流,有的一包里只有分界符数据(nal_unit_type=9)或补充增强信息单元(nal_unit_type=6),如果直接送入解码器,有可能会出现问题,这里的处理方式要么丢弃这两个部分,要么和之后的数据合起来,再送入解码器里,如有遇到的朋友可以交流一下:)

    写在后面:

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

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

    《RTP Payload Format for H.264 Video》

    rfc3984(For264).txt_PS流-互联网文档类资源-CSDN下载

    《MPEG2-2(13818中文版)》

    MPEG2-2(13818中文版)_mpeg2-C++文档类资源-CSDN下载

    RTP荷载H264的代码参考:

    基于RTP的H264视频数据打包解包类_子鲲的专栏 -CSDN博客_h264 rtp 解包

    RTP荷载PS流的代码参考:

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

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

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

    授人以鱼不如授人以渔。

    其他参考:

    MPEG-2 PS流_duanbeibei的专栏-CSDN博客

    从海康7816的ps流里获取数据h264数据_wwyyxx26的专栏-CSDN博客

    原创不易,转载请附上链接,谢谢RTP协议全解析(H264码流和PS流)_对牛乱弹琴-CSDN博客_ps流

    展开全文
  • H264码流分析软件

    2018-05-08 08:40:28
    非常好用的一款H264码流分析软件,不仅可以查看I帧间隔和每帧大小,还可以打开信息不全的H264视频帧
  • H264码流分析软件EStreamEyeTools 破解版。有破解安装步骤
  • H264码流分析工具(H264Visa.rar)

    热门讨论 2011-09-29 16:59:43
    一个很好的h264码流分析工具,可以对h264文件进行结构分析及解码分析,是学习h264视频格式的最佳工具
  • H264码流分析

    2019-08-20 13:46:29
    H.264原始码流(裸)是由一个接一个NALU组成,它的功能分为两层,VCL(视频编码层)和 NAL(网络提取层),其中VCL是为了表示视频数据的内容,NAL层则是为了格式化数据。 SODB与RBSP SODB 数据比特串 -> 是编码后...

    H.264标准协议定义了两种不同的类型:一种是VCL即Video Coding Layer,一种是NAL即Network Abstraction Layer。其中前者就是编码器吐出来的原始编码数据,没有考虑传输和存储问题。后面这种就是为了展现H.264的网络亲和性,对VCL输出的slice片数据进行了封装为NALUs(NAL  Units)。

    SODB与RBSP
    SODB 数据比特串 -> 是编码后的原始数据.
    RBSP 原始字节序列载荷 -> 在原始编码数据的后面添加了 结尾比特。一个 bit“1”若干比特“0”,以便字节对齐。

    NAL Header

    由三部分组成,forbidden_bit(1bit),nal_reference_bit(2bits)(优先级),nal_unit_type(5bits)(类型)。

    一个h264文件是由NAL序列组成的,为了区分单个的NAL,在生成NAL序列中,往每个NAL单元前添加一个起始编码前缀'0x00 00 00 01'。

    在解码过程中,我们只需要取出NALU头字节的后5位,即将NALU头字节和0x1F进行与计算即可得知NALU类型,即:

    NALU类型 = NALU头字节 & 0x1F

    码流格式 

    H.264标准中指定了视频如何编码成独立的包,但如何存储和传输这些包却未作规范,为了针对不同的存储传输需求,出现了两种打包方法。一种即Annex B格式,另一种称为AVCC格式,这里仅介绍Annex B格式。

    Annex B格式用起始码(Start Code)来标识一个NALU从哪里开始,它在每个NALU的开始处添加三字节或四字节的起始码0x000001或0x00000001。通过定位起始码,解码器就可以很容易的识别NALU的边界。
    当然,用起始码定位NALU边界存在一个问题,即NALU中可能存在与起始码相同的数据。同时H.264规定,当检测到0x000000时,也可以表征当前NAL的结束。为了防止这些问题,在构建NALU时,需要将数据中的0x000000,0x000001,0x000002,0x000003中插入防竞争字节(Emulation Prevention Bytes)0x03,使其变为:

    0x000000 = 0x0000 03 00
    0x000001 = 0x0000 03 01
    解码器在检测到0x000003时,将0x03抛弃,恢复原始数据。

    由于Annex B格式每个NALU都包含起始码,所以解码器可以从视频流随机点开始进行解码,常用于实时的流格式。在这种格式中通常会周期性的重复SPS和PPS,并且经常时在每一个关键帧之前。

    展开全文
  • H264码流分析工具

    千次阅读 2019-10-09 19:14:46
    重点记录使用工具分析H264码流。使用该工具,可方便查看码中NALU的结构,为我们学习和理解有很大帮助。 H264码流介绍 笔者直接参考:https://blog.csdn.net/chenchong_219/article/details/37990541 工具使用说明 ...

    概述

    本文作为一个笔记,记录笔者学习H264码流的过程。重点记录使用工具分析H264码流。使用该工具,可方便查看码流中NALU的结构,为我们学习和理解有很大帮助。

    H264码流介绍

    笔者直接参考:https://blog.csdn.net/chenchong_219/article/details/37990541

    工具使用说明

    • 工具下载地址
      https://download.csdn.net/download/lyy901135/11839793
    • 打开工具
      在这里插入图片描述
      在这里插入图片描述
    • 打开文件
      在这里插入图片描述
    • 查看帧信息
      在这里插入图片描述
      上图可看到工具帮我们解析出H264码流中的帧情况,并注明了帧的起始地址。可根据该地址在二进制文件中查看。查看二进制推荐使用HexPad工具,可自行下载。

    查看H264码流PQ值

    在这里插入图片描述

    展开全文
  • 里面包含Elecard StreamEye Tools和H264Visa两个H.264码流分析工具,另外,还有几个h264格式的测试视频!
  • rtp载荷h264码流分析

    2018-12-18 21:03:36
    rtp载荷h264码流分析  H.264 的基本由一系列NALU(Network Abstraction Layer Unit )组成,不同的NALU数据量各不相同。当数据是储存在介质上时,在每个NALU 前添加起始码:0x000001,用来指示一个 NALU的起始...
  • H264码流分析.zip

    2021-03-03 14:06:00
    有EasyICE elecardstreameye 系列,搜索打包在一起了,良心分享给大家使用。
  • 包括CTI-TS、EasyICE、elecardstreameyetools、VideoEye H264码流分析工具,做音视频开发的必备神器,里面包括有ts264、yuv播放等工具
  • 强力的h264实时分析工具 ,能分析各种场合下的h264资源,适用于h264开发者,学习者。在图像分析上,VISA还是比EYE更加厉害,它包括了滤波前以及预测残差等等数据的输出。 另一款强力分析工具是Elecard StreamEye ...
  • 仿elecard stream analyzer 写的MFC代码,有很多不足,对了解h264码流有帮助,供大家学习之用
  • videoeye&streameye
  • H264码流分析 --264分析两大利器:264VISA和Elecard StreamEye Tools
  • H264码流解析及NALU

    千次阅读 2016-07-12 11:59:10
    ffmpeg 从mp4上提取H264的nalu http://blog.csdn.net/gavinr/article/details/7183499 639 /* bitstream filters */ 640 REGISTER_BSF(AAC_ADTSTOASC, aac_adtstoasc); 641 REGISTER_BSF(CHO
  • h264码流分析器(源码)

    2015-08-14 10:58:53
    仿elecard stream analyzer 做的码流分析器,有很多不足,对了解264结构有少一定帮助,供大家学习之用
  • 在这个资源中,包含了CTI-TS、EasyICE、elecardstreameyetools、VideoEye和yuvplayer。是您在作音视频开发、码流分析过程中不可或缺的利器!
  • H264码流分析和打包RTP过程

    千次阅读 2021-04-09 11:13:59
    H264是专门去除这些冗余的算法,我们把这种算法称为H264编码。视频压缩算法来压缩视频的占用空间,提高存储和传输的效率,在获得有效的压缩效果的同时,使得压缩过程引起的失真最小。      ...
  • H264码流分层 NAL层,视频数据网络抽象层,作用是控制二进制数据的传输,主要用于网络传输。 VCL层,视频数据编码层。 VCL结构关系 NALU NAL Header (1B)+ RBSP H264码流中NALU sps pps IDR帧的理解 ...
  • h264码流分析及其工具

    2015-08-05 19:53:00
    总的来说H264码流的打包方式有两种,一种为annex-b byte stream format的格式,这个是绝大部分编码器的默认输出格式,就是每个帧的开头的3~4个字节是H264的start_code,0x00000001或者0x000001。另一种是 avcc byte ...
  • Elecard H264.zip 分析H264码流的工具
  • 几款H264码流分析工具

    万次阅读 2018-07-17 10:36:38
    包括CTI-TS、EasyICE、elecardstreameyetools、VideoEye 下载地址:https://download.csdn.net/download/jctian000/10545674
  • h264-工具 mkv2mkv : Usage: mkv2mkv input-file output-file convert audio/video files with optional H.264 video rencoding and aac audio reencoding. 3D H.264 input video (with MVC) can be reencoded to ...
  • 1、码流总体结构: ( 参考:http://blog.csdn.net/chenchong_219/article/details/37990541 http://www.cnblogs.com/lidabo/p/4602422.html) h264的功能分为两层,视频编码层(VCL)和网络提取层/网络抽象层...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 195,513
精华内容 78,205
关键字:

h264码流解析