h264 订阅
H.264,同时也是MPEG-4第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC)而明确的说明它两方面的开发者。H264标准各主要部分有Access Unit delimiter(访问单元分割符),SEI(附加增强信息),primary coded picture(基本图像编码),Redundant Coded Picture(冗余图像编码)。还有Instantaneous Decoding Refresh(IDR,即时解码刷新)、Hypothetical Reference Decoder(HRD,假想参考解码)、Hypothetical Stream Scheduler(HSS,假想码流调度器)。 展开全文
H.264,同时也是MPEG-4第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC)而明确的说明它两方面的开发者。H264标准各主要部分有Access Unit delimiter(访问单元分割符),SEI(附加增强信息),primary coded picture(基本图像编码),Redundant Coded Picture(冗余图像编码)。还有Instantaneous Decoding Refresh(IDR,即时解码刷新)、Hypothetical Reference Decoder(HRD,假想参考解码)、Hypothetical Stream Scheduler(HSS,假想码流调度器)。
信息
属    性
数字视频压缩格式
属    于
MPEG-4第十部分
中文名
H.264
主要部分
访问单元分割符
H.264背景介绍
H.264是国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的继MPEG4之后的新一代数字视频压缩格式。H.264是ITU-T以H.26x系列为名称命名的视频编解码技术标准之一。H.264是ITU-T的VCEG(视频编码专家组)和ISO/IEC的MPEG(活动图像编码专家组)的联合视频组(JVT:joint video team)开发的一个数字视频编码标准。该标准最早来自于ITU-T的称之为H.26L的项目的开发。H.26L这个名称虽然不太常见,但是一直被使用着。H.264是ITU-T以H.26x系列为名称命名的标准之一,AVC是ISO/IEC MPEG一方的称呼。国际上制定视频编解码技术的组织有两个,一个是“国际电联(ITU-T)”,它制定的标准有H.261、H.263、H.263+等,另一个是“国际标准化组织(ISO)”它制定的标准有MPEG-1、MPEG-2、MPEG-4等。而H.264则是由两个组织联合组建的联合视频组(JVT)共同制定的新数字视频编码标准,所以它既是ITU-T的H.264,又是ISO/IEC的MPEG-4高级视频编码(Advanced Video Coding,AVC)的第10 部分。因此,不论是MPEG-4 AVC、MPEG-4 Part 10,还是ISO/IEC 14496-10,都是指H.264。1998年1月份标准开始草案征集,1999年9月,完成第一个草案,2001年5月制定了其测试模式TML-8,2002年6月的 JVT第5次会议通过了H.264的FCD板。2003年3月正式发布。在2005年又开发出了H.264的更高级应用标准MVC 和 SVC 版本。国际电联ITU和MPEG组织在发布了H.264标准之后,很快就发布公告,为下一代视频编解码标准H.265征集技术方案。为H.265设定的技术性能指标是:压缩效率比H.264提高1倍、且不明显提高编码和解码的计算量。据MPEG组织2009年西安会议的回顾,尚无一个技术提案达到上述指标。H.264是在MPEG-4技术的基础之上建立起来的,其编解码流程主要包括5个部分:帧间和帧内预测(Estimation)、变换(Transform)和反变换、量化(Quantization)和反量化、环路滤波(Loop Filter)、熵编码(Entropy Coding)。H.264标准的主要目标是:与其它现有的视频编码标准相比,在相同的带宽下提供更加优秀的图象质量。通过该标准,在同等图象质量下的压缩效率比以前的标准(MPEG2)提高了2倍左右。H.264可以提供11个等级、7个类别的子协议格式(算法),其中等级定义是对外部环境进行限定,例如带宽需求、内存需求、网络性能等等。等级越高,带宽要求就越高,视频质量也越高。类别定义则是针对特定应用,定义编码器所使用的特性子集,并规范不同应用环境中的编码器复杂程度。
收起全文
精华内容
下载资源
问答
  • 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上面发现了更加优秀的项目,分享给大家。

    https://github.com/ireader/media-server

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

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

    写在前面: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??

    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看的清晰,大家凑合着看吧。
     
    原创不易,转载请附上链接,谢谢http://blog.csdn.net/chen495810242/article/details/39207305
     

    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,基本没用;

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

    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》

    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

     

    彩蛋:这里竟然有源码😍😍😍

     👇👇👇👇👇

    👇👇👇👇👇

    https://mianbaoduo.com/o/bread/YZaXmJdr

     

    展开全文
  • H264

    千次阅读 2017-10-13 11:20:20
    H264 1、H264一个图像序列的组成:SPS+PPS+SEI+一个I帧+若干个P帧。SPS、PPS、SEI、一个I帧、一个P帧都 可以称为一个NALU。 2、H264的NALU结构:开始码+NALU头+NALU数据 (1)、开始码大小为四个字节,是一个...

    H264
    1、H264一个图像序列的组成:SPS+PPS+SEI+一个I帧+若干个P帧。SPS、PPS、SEI、一个I帧、一个P帧都
    可以称为一个NALU。
    2、H264的NALU结构:开始码+NALU头+NALU数据
    (1)、开始码大小为四个字节,是一个固定值00 00 00 01(十六进制),标识一个NALU的开始。
    (2)、NALU头大小为一个字节,前3位暂不讨论,后5位为type位,标识当前NALU的类型。
    (3)、NALU数据为编码器编出来的图像信息或图像数据。
    3、五种类型的NALU
    (1)、SPS(序列参数集):NALU头值为0x67(十六进制),NALU头type位值为7(十进制)。
    (2)、PPS(图像参数集):NALU头值为0x68(十六进制),NALU头type位值为8(十进制)。
    (3)、SEI(补充增强信息):NALU头值为0x06(十六进制),NALU头type位值为6(十进制)。
    (4)、I帧:NALU头值为0x65(十六进制),NALU头type位值为5(十进制)。
    (5)、P帧:NALU头值为0x61(十六进制),NALU头type位值为1(十进制)。
    4、H264的NALU打包成RTP包的模式(下面是用到的两种模式)
    (1)、一个NALU打包成一个RTP包,只需要在一个12字节的RTP包头后添加去掉开始码的NALU即可
    (这种模式在一个NALU的大小小于MTU时使用)。
    (2)、一个NALU打包成几个RTP包(FU_A模式),在12个字节的RTP头后面加上一个字节的
    FU indicator和一个字节的FU header。FU indicator前3位是NALU头的前3位,后5位是28(十进制),
    FU header第1位标记RTP包是否为NALU的第一片,第2位标记RTP包是否为NALU的最后一片。第3位是保
    留位,后5位是NALU头的type位。

    H264参考:
    1、RFC文档:RFC3984
    2、H264编码
    2.1、编码过程分两层:视频编码层(VCL)和网络抽象层(NAL)
    2.1.1、VCL
    VCL包含Codec的信令处理功能;以及如转换,量化,运动补偿预测机制;以及循环
    过滤器。他遵从今天大多数视频codec的一般概念,基于宏快的编码器,使用基
    于运动补偿的图像间预测和残余信号的转换编码。VCL编码器输出片断: 一个位
    串包含整数数目宏快的宏块数据,以及片断头信息(包含片断内第一个宏快的空
    间地址, 初始量化参数以及相似信息). 片断内的宏快按照扫描顺序安排,除非
    指定一个不同的宏块分配,通过使用被称为灵活宏块顺序语法Flexible
    Macroblock Ordering syntax.图像内的预测只用于一个片断内部。
    2.1.2、NAL
    (NAL)编码器封装VCL编码器输出的片断到网络抽象层单元(NAL units),它适
    合于通过包网路传输或用于面向包的多路复用环境。
    NAL使用NAL单元. 一个NAL单元由一字节的头和荷载字节串组成。 头指示
    NAL单元的类型, 是否有位错误或语法冲突在NAL单元荷载中,以及对于解码过
    程该NAL单元相对重要性的信息。
    2.2、参数集
    H.264规范包括两类参数集:顺序参数集和图像参数集。一个活动顺序参数集在一个编
    码视频序列中保持不变,一个活动图像参数集在一个编码图像里保持不变。顺序
    和图像参数集结构包含如图像大小,采用的可选的编码模式,宏块到片断组映射
    等信息。
    2.3、NAL单元
    2.3.1NAL单元的头是一个字节
    ±--------------+
    |0|1|2|3|4|5|6|7|
    ±±±±±±±±+
    |F|NRI| Type |
    ±--------------+
    F: 1 bit

    forbidden_zero_bit. H.264规范声明设置为1指示语法违例。
    NRI: 2 bits
    nal_ref_idc. 00值指示NAL单元的不用于帧间图像预测的重构参考图
    像。这样的NAL单元可以被丢弃而不用冒参考图像完整性的风险。大于0的值指
    示NAL单元的解码要求维护参考图像的完整性。
    Type: 5 bits
    nal_unit_type. 本部件指定NAL单元荷载类型。

    H264 RTP参考:
    H.264 视频 RTP 负载格式

    1. 网络抽象层单元类型 (NALU)
      NALU 头由一个字节组成, 它的语法如下:
      ±--------------+
      |0|1|2|3|4|5|6|7|
      ±±±±±±±±+
      |F|NRI| Type |
      ±--------------+
      F: 1 个比特.
      forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.
      NRI: 2 个比特.
      nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心
      这个属性.
      Type: 5 个比特.
      nal_unit_type. 这个 NALU 单元的类型. 简述如下:
      0 没有定义
      1-23 NAL单元 单个 NAL 单元包.
      24 STAP-A 单一时间的组合包
      24 STAP-B 单一时间的组合包
      26 MTAP16 多个时间的组合包
      27 MTAP24 多个时间的组合包
      28 FU-A 分片的单元
      29 FU-B 分片的单元
      30-31 没有定义
    2. 打包模式
      下面是 RFC 3550 中规定的 RTP 头的结构.
      0 1 2 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
      |V=2|P|X| CC |M| PT | sequence number |
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
      | timestamp |
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
      | synchronization source (SSRC) identifier |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      | contributing source (CSRC) identifiers |
      | … |
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
      负载类型 Payload type (PT): 7 bits
      序列号 Sequence number (SN): 16 bits
      时间戳 Timestamp: 32 bits

    H.264 Payload 格式定义了三种不同的基本的负载(Payload)结构. 接收端可能通过 RTP Payload
    的第一个字节来识别它们. 这一个字节类似 NALU 头的格式, 而这个头结构的 NAL 单元类型字段
    则指出了代表的是哪一种结构,
    这个字节的结构如下, 可以看出它和 H.264 的 NALU 头结构是一样的.
    ±--------------+
    |0|1|2|3|4|5|6|7|
    ±±±±±±±±+
    |F|NRI| Type |
    ±--------------+
    字段 Type: 这个 RTP payload 中 NAL 单元的类型. 这个字段和 H.264 中类型字段的区别是, 当 type
    的值为 24 ~ 31 表示这是一个特别格式的 NAL 单元, 而 H.264 中, 只取 1~23 是有效的值.

    24 STAP-A 单一时间的组合包
    24 STAP-B 单一时间的组合包
    26 MTAP16 多个时间的组合包
    27 MTAP24 多个时间的组合包
    28 FU-A 分片的单元
    29 FU-B 分片的单元
    30-31 没有定义
    可能的结构类型分别有:

    1. 单一 NAL 单元模式
      即一个 RTP 包仅由一个完整的 NALU 组成. 这种情况下 RTP NAL 头类型字段和原始的 H.264的
      NALU 头类型字段是一样的.
    2. 组合封包模式
      即可能是由多个 NAL 单元组成一个 RTP 包. 分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24.
      那么这里的类型值分别是 24, 25, 26 以及 27.
    3. 分片封包模式
      用于把一个 NALU 单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29.
      2.1 单一 NAL 单元模式
      对于 NALU 的长度小于 MTU 大小的包, 一般采用单一 NAL 单元模式.
      对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个
      NALU 单元的开始, 必须是 “00 00 00 01” 或 “00 00 01”, NALU 头仅一个字节, 其后都是 NALU 单元内容.
      打包时去除 “00 00 01” 或 “00 00 00 01” 的开始码, 把其他数据封包的 RTP 包即可.
      0 1 2 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
      |F|NRI| type | |
      ±±±±±±±±+ |
      | |
      | Bytes 2…n of a Single NAL unit |
      | |
      | ±±±±±±±±±±±±±±±±+
      | :…OPTIONAL RTP padding |
      ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+

    如有一个 H.264 的 NALU 是这样的:
    [00 00 00 01 67 42 A0 1E 23 56 0E 2F … ]
    这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.
    封装成 RTP 包将如下:
    [ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]
    即只要去掉 4 个字节的开始码就可以了.

    2.2 组合封包模式
    其次, 当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 1 Data                           |
      :                                                               :
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               | NALU 2 Size                   | NALU 2 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 2 Data                           |
      :                                                               :
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    2.3 Fragmentation Units (FUs).
    而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FU indicator  |   FU header   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 14.  RTP payload format for FU-A
    

    The FU indicator octet has the following format:
    ±--------------+
    |0|1|2|3|4|5|6|7|
    ±±±±±±±±+
    |F|NRI| Type |
    ±--------------+
    The FU header has the following format:
    ±--------------+
    |0|1|2|3|4|5|6|7|
    ±±±±±±±±+
    |S|E|R| Type |
    ±--------------+

    1. SDP 参数
      下面描述了如何在 SDP 中表示一个 H.264 流:
      . “m=” 行中的媒体名必须是 “video”
      . “a=rtpmap” 行中的编码名称必须是 “H264”.
      . “a=rtpmap” 行中的时钟频率必须是 90000.
      . 其他参数都包括在 “a=fmtp” 行中.
      如:
      m=video 49170 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
      下面介绍一些常用的参数.
      3.1 packetization-mode:
      表示支持的封包模式.
      当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
      当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
      当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.
      这个参数不可以取其他的值.
      3.2 sprop-parameter-sets:
      这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开.

    3.3 profile-level-id:
    这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节. 第一个字节表示 H.264 的 Profile 类型, 第
    三个字节表示 H.264 的 Profile 级别:

    3.4 max-mbps:
    这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.

    H264 SDP参考:
    使用RTP传输H264的时候,需要用到sdp协议描述,其中有两项:Sequence Parameter Sets (SPS) 和Picture Parameter Set (PPS)需要用到,那么这两项从哪里获取呢?答案是从H264码流中获取.在H264码流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"为开始码的,找到开始码之后,使用开始码之后的第一个字节的低5位判断是否为7(sps)或者8(pps), 及data[4] & 0x1f == 7 || data[4] & 0x1f == 8.然后对获取的nal去掉开始码之后进行base64编码,得到的信息就可以用于sdp.sps和pps需要用逗号分隔开来.
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    如何解析SDP中包含的H.264的SPS和PPS串
    http://www.pernet.tv.sixxs.org/thread-109-1-1.html
    SDP中的H.264的SPS和PPS串,包含了初始化H.264解码器所需要的信息参数,包括编码所用的profile,level,图像的宽和高,deblock滤波器等。
    由于SDP中的SPS和PPS都是BASE64编码形式的,不容易理解,附件有一个工具软件可以对SDP中的SPS和PPS进行解析。
    用法是在命令行中输入:
    spsparser sps.txt pps.txt output.txt

    例如sps.txt中的内容为:
    Z0LgFNoFglE=
    pps.txt中的内容为:
    aM4wpIA=

    最终解析的到的结果为:

    Start dumping SPS:
    profile_idc = 66
    constrained_set0_flag = 1
    constrained_set1_flag = 1
    constrained_set2_flag = 1
    constrained_set3_flag = 0
    level_idc = 20
    seq_parameter_set_id = 0
    chroma_format_idc = 1
    bit_depth_luma_minus8 = 0
    bit_depth_chroma_minus8 = 0
    seq_scaling_matrix_present_flag = 0
    log2_max_frame_num_minus4 = 0
    pic_order_cnt_type = 2
    log2_max_pic_order_cnt_lsb_minus4 = 0
    delta_pic_order_always_zero_flag = 0
    offset_for_non_ref_pic = 0
    offset_for_top_to_bottom_field = 0
    num_ref_frames_in_pic_order_cnt_cycle = 0
    num_ref_frames = 1
    gaps_in_frame_num_value_allowed_flag = 0
    pic_width_in_mbs_minus1 = 21
    pic_height_in_mbs_minus1 = 17
    frame_mbs_only_flag = 1
    mb_adaptive_frame_field_flag = 0
    direct_8x8_interence_flag = 0
    frame_cropping_flag = 0
    frame_cropping_rect_left_offset = 0
    frame_cropping_rect_right_offset = 0
    frame_cropping_rect_top_offset = 0
    frame_cropping_rect_bottom_offset = 0
    vui_parameters_present_flag = 0

    Start dumping PPS:
    pic_parameter_set_id = 0
    seq_parameter_set_id = 0
    entropy_coding_mode_flag = 0
    pic_order_present_flag = 0
    num_slice_groups_minus1 = 0
    slice_group_map_type = 0
    num_ref_idx_l0_active_minus1 = 0
    num_ref_idx_l1_active_minus1 = 0
    weighted_pref_flag = 0
    weighted_bipred_idc = 0
    pic_init_qp_minus26 = 0
    pic_init_qs_minus26 = 0
    chroma_qp_index_offset = 10
    deblocking_filter_control_present_flag = 1
    constrained_intra_pred_flag = 0
    redundant_pic_cnt_present_flag = 0
    transform_8x8_mode_flag = 0
    pic_scaling_matrix_present_flag = 0
    second_chroma_qp_index_offset = 10

    /
    这里需要特别提一下这两个参数
    pic_width_in_mbs_minus1 = 21
    pic_height_in_mbs_minus1 = 17
    分别表示图像的宽和高,以宏块(16x16)为单位的值减1
    因此,实际的宽为 (21+1)*16 = 352
    spsparser.rar
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    http://krdai.info.sixxs.org/blog/mp4-sps-pps-data.html

    最近在做跟 h264 encode/decode 相關的研究,目標是希望可以從 Android 的 MediaRecorder 當中取出 h264 的資訊。目前問題是在於 SPS 以及 PPS 到底要怎樣得到。由於 MediaRecorder 是寫入 mp4 檔案中,所以不得已只好來去分析一下 mp4 的檔案格式,發現沒有想像中的困難. 主要是參照 ISO/IEC 14496-15 這部份. 在 mp4 的檔案之中, 找到 avcC 這個字串, 之後就是接上 AVCDecoderConfigurationRecord. AVCDecoderConfigurationRecord 的 format 如下:

    [cpp] view plaincopy
    aligned(8) class AVCDecoderConfigurationRecord {
    unsigned int(8) configurationVersion = 1;
    unsigned int(8) AVCProfileIndication;
    unsigned int(8) profile_compatibility;
    unsigned int(8) AVCLevelIndication;

    bit(6) reserved = '111111’b;
    unsigned int(2) lengthSizeMinusOne;

    bit(3) reserved = '111’b;
    unsigned int(5) numOfSequenceParameterSets;

    for (i=0; i< numOfSequenceParameterSets; i++) {
    unsigned int(16) sequenceParameterSetLength ;
    bit(8sequenceParameterSetLength) sequenceParameterSetNALUnit;
    }
    unsigned int(8) numOfPictureParameterSets;
    for (i=0; i< numOfPictureParameterSets; i++) {
    unsigned int(16) pictureParameterSetLength;
    bit(8
    pictureParameterSetLength) pictureParameterSetNALUnit;
    }
    }

    對照一下這樣就可以找到 SPS 和 PPS

    +++++++++++++++++++++++++++++++++++++++++++++

    h264的SPS/PPS
    与分辨率有关
    与帧率无关(与帧率是否有关主要看sps中某个字段的值,当前海思编出的sps中该字段值标识与帧率无关)
    与N/P制无关

    1、4M
    Payload: 674d003295a80a002d69b808080810
    Payload: 68ee3c80

    2、4M_4x3
    Payload: 674d003295a809003669b808080810
    Payload: 68ee3c80

    3、3M
    Payload: 674d003295a808003069b808080810
    Payload: 68ee3c80

    4、1080P
    Payload: 674d002a95a81e0089f966e020202040
    Payload: 68ee3c80

    5、960P
    Payload: 674d002095a81401e69b80808081
    Payload: 68ee3c80

    6、720P
    Payload: 674d001f95a814016e9b80808081
    Payload: 68ee3c80

    7、D1
    Payload: 674d001e95a82c049a6e02020204
    Payload: 68ee3c80

    8、CIF
    Payload: 674d001495a85825a6e020202040
    Payload: 68ee3c80

    5M
    67 4d 0 32 95 a8 a 20 3d 7e 59 b8 8 8 8 10 0 0 0 1 68 ee 3c 80 0 0 0 1 6 e5 1 cc 80 0 0 0 1 65 b8 0 0 c 29 51 ff da 9c 5f 6f 9f cf ff ef a7 c7 61 ba 71 b9 97 56 34 4c ea 1a f1 36 e8 19 54 8b 50 bc 8c 28 6c df ec d1 28 4 e9 96 67 f7 28 59 51 5f fd 45 b f7 df ce ae 94 94 ed e1

    展开全文
  • h264

    千次阅读 2009-12-01 14:28:00
    H.264基本概况 随着HDTV的兴起,H.264这个规范频频出现在我们眼前,HD-DVD和蓝光DVD均计划采用这一标准进行节目制作。而且自2005年下半年以来,无论是NVIDIA还是ATI都把支持H.264硬件解码加速作为自己最值得夸耀的...

    H.264基本概况

      随着HDTV的兴起,H.264这个规范频频出现在我们眼前,HD-DVD和蓝光 DVD均计划采用这一标准进行节目制作。而且自2005年下半年以来,无论是NVIDIA还是ATI都把支持H.264硬件解码加速作为自己最值得夸耀的 视频技术。H.264到底是何方“神圣”呢?
      H.264,同时也是MPEG-4第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。
      H.264是一种高性能的视频编解码技术。目前国际上制定视频编解码技术的组织有两个,一个是 “国际电联(ITU-T)”,它制定的标准有H.261、H.263、H.263+等,另一个是“国际标准化组织(ISO)”它制定的标准有MPEG- 1、MPEG-2、MPEG-4等。而H.264则是由两个组织联合组建的联合视频组(JVT)共同制定的新数字视频编码标准,所以它既是ITU-T的 H.264,又是ISO/IEC的MPEG-4高级视频编码(Advanced Video Coding,AVC),而且它将成为MPEG-4标准的第10部分。因此,不论是MPEG-4 AVC、MPEG-4 Part 10,还是ISO/IEC 14496-10,都是指H.264。
      H.264最大的优势是具有很高的数据压缩比率,在同等图像质量的条件下,H.264的压缩比 是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。举个例子,原始文件的大小如果为88GB,采用MPEG-2压缩标准压缩后变成3.5GB,压 缩比为25∶1,而采用H.264压缩标准压缩后变为879MB,从88GB到879MB,H.264的压缩比达到惊人的102∶1!H.264为什么有 那么高的压缩比?低码率(Low Bit Rate)起了重要的作用,和MPEG-2和MPEG-4 ASP等压缩技术相比,H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是,H.264在具有高压缩比的同时还拥有高质量流畅 的图像。

    H.264算法的优势

       H.264是在MPEG-4技术的基础之上建立起来的,其编解码流程主要包括5个部分:帧间和帧内预测(Estimation)、变换 (Transform)和反变换、量化(Quantization)和反量化、环路滤波(Loop Filter)、熵编码(Entropy Coding)。
      H.264/MPEG-4 AVC(H.264)是1995年自MPEG-2视频压缩标准发布以后的最新、最有前途的视频压缩标准。H.264是由ITU-T和ISO/IEC的联合 开发组共同开发的最新国际视频编码标准。通过该标准,在同等图象质量下的压缩效率比以前的标准提高了2倍以上,因此,H.264被普遍认为是最有影响力的 行业标准。

    H.264的发展历史

      H.264在1997年ITU的视频编码专家组(Video Coding Experts Group)提出时被称为H.26L,在ITU与ISO合作研究后被称为MPEG4 Part10(MPEG4 AVC)或H.264(JVT)。

    H.264的高级技术背景

      H.264标准的主要目标是:与其它现有的视频编码标准相比,在相同的带宽下提供更加优秀的图象质量。
      而,H.264与以前的国际标准如H.263和MPEG-4相比,最大的优势体现在以下四个方面:
      1. 将每个视频帧分离成由像素组成的块,因此视频帧的编码处理的过程可以达到块的级别。
      2. 采用空间冗余的方法,对视频帧的一些原始块进行空间预测、转换、优化和熵编码(可变长编码)。
      3. 对连续帧的不同块采用临时存放的方法,这样,只需对连续帧中有改变的部分进行编码。该算法采用运动预测和运动补偿来完成。对某些特定的块,在一个或多个已经进行了编码的帧执行搜索来决定块的运动向量,并由此在后面的编码和解码中预测主块。
      4. 采用剩余空间冗余技术,对视频帧里的残留块进行编码。例如:对于源块和相应预测块的不同,再次采用转换、优化和熵编码。

    H.264的特征和高级优势

      H.264是国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的继MPEG4之后的新一代数字视频压缩格式,它即保留了以往压缩技术的优点和精华又具有其他压缩技术无法比拟的许多优点。
      1.低码流(Low Bit Rate):和MPEG2和MPEG4 ASP等压缩技术相比,在同等图像质量下,采用H.264技术压缩后的数据量只有MPEG2的1/8,MPEG4的1/3。
      显然,H.264压缩技术的采用将大大节省用户的下载时间和数据流量收费。
      2.高质量的图象:H.264能提供连续、流畅的高质量图象(DVD质量)。
      3.容错能力强:H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。
      4.网络适应性强:H.264提供了网络抽取层(Network Abstraction Layer), 使得H.264的文件能容易地在不同网络上传输(例如互联网,CDMA,GPRS,WCDMA,CDMA2000等)。

    H.264标准概述

       H.264和以前的标准一样,也是DPCM加变换编码的混合编码模式。但它采用“回归基本”的简洁设计,不用众多的选项,获得比H.263++好得多的 压缩性能;加强了对各种信道的适应能力,采用“网络友好”的结构和语法,有利于对误码和丢包的处理;应用目标范围较宽,以满足不同速率、不同解析度以及不 同传输(存储)场合的需求。
      技术上,它集中了以往标准的优点,并吸收了标准制定中积累的经验。与H.263 v2(H.263+)或MPEG-4简单类(Simple Profile)相比,H.264在使用与上述编码方法类似的最佳编码器时,在大多数码率下最多可节省50%的码率。H.264在所有码率下都能持续提供 较高的视频质量。H.264能工作在低延时模式以适应实时通信的应用(如视频会议),同时又能很好地工作在没有延时限制的应用,如视频存储和以服务器为基 础的视频流式应用。H.264提供包传输网中处理包丢失所需的工具,以及在易误码的无线网中处理比特误码的工具。
      在系统层面上,H.264提出了一个新的概念,在视频编码层(Video Coding Layer, VCL)和网络提取层(Network Abstraction Layer, NAL)之间进行概念性分割,前者是视频内容的核心压缩内容之表述,后者是通过特定类型网络进行递送的表述,这样的结构便于信息的封装和对信息进行更好的 优先级控制。H.264的系统编码框图如图1所示。

    H.264标准的主要特点

       H264标准是由JVT(Joint Video Team,视频联合工作组)组织提出的新一代数字视频编码标准。JVT于2001年12月在泰国Pattaya成立。它由ITU-T的VCEG(视频编码 专家组)和ISO/IEC的MPEG(活动图像编码专家组)两个国际标准化组织的专家联合组成。JVT的工作目标是制定一个新的视频编码标准,以实现视频 的高压缩比、高图像质量、良好的网络适应性等目标H264标准。H264标准将作为MPEG-4标准的一个新的部分(MPEG-4 part.10)而获得批准,是一个面向未来IP和无线环境下的新数字视频压缩编码标准。
      H264标准的主要特点如下:
      1.更高的编码效率:同H.263等标准的特率效率相比,能够平均节省大于50%的码率。
      2.高质量的视频画面:H.264能够在低码率情况下提供高质量的视频图像,在较低带宽上提供高质量的图像传输是H.264的应用亮点。
      3.提高网络适应能力:H.264可以工作在实时通信应用(如视频会议)低延时模式下,也可以工作在没有延时的视频存储或视频流服务器中。
      4.采用混合编码结构:同H.263相同,H.264也使用采用DCT变换编码加DPCM的差分编码的混合编码结构,还增加了如多模式运动估计、帧内预测、多帧预测、基于内容的变长编码、4x4二维整数变换等新的编码方式,提高了编码效率。
      5.H.264的编码选项较少:在H.263中编码时往往需要设置相当多选项,增加了编码的难度,而H.264做到了力求简洁的“回归基本”,降低了编码时复杂度。
      6.H.264可以应用在不同场合:H.264可以根据不同的环境使用不同的传输和播放速率,并且提供了丰富的错误处理工具,可以很好的控制或消除丢包和误码。
      7.错误恢复功能:H.264提供了解决网络传输包丢失的问题的工具,适用于在高误码率传输的无线网络中传输视频数据。
      8.较高的复杂度:264性能的改进是以增加复杂性为代价而获得的。据估计,H.264编码的计算复杂度大约相当于H.263的3倍,解码复杂度大约相当于H.263的2倍。
      H264标准各主要部分有Access Unit delimiter(访问单元分割符),SEI(附加增强信息),primary coded picture(基本图像编码),Redundant Coded Picture(冗余图像编码)。还有Instantaneous Decoding Refresh(IDR,即时解码刷新)、Hypothetical Reference Decoder(HRD,假想码流调度器)、Hypothetical Stream Scheduler(HSS,假想参考解码)。[4]

    .

    H.264标准的关键技术

      1.帧内预测编码
      帧内编码用来缩减图像的空间冗余。为了提高H.264帧内编码的效率,在给定帧中充分利用相邻 宏块的空间相关性,相邻的宏块通常含有相似的属性。因此,在对一给定宏块编码时,首先可以根据周围的宏块预测(典型的是根据左上角的宏块,因为此宏块已经 被编码处理),然后对预测值与实际值的差值进行编码,这样,相对于直接对该帧编码而言,可以大大减小码率。
      H.264提供6种模式进行4×4像素宏块预测,包括1种直流预测和5种方向预测,如图2所 示。在图中,相邻块的A到I共9个像素均已经被编码,可以被用以预测,如果我们选择模式4,那么,a、b、c、d4个像素被预测为与E相等的值,e、f、 g、h4个像素被预测为与F相等的值,对于图像中含有很少空间信息的平坦区,H.264也支持16×16的帧内编码。 图2 帧内编码模式
      2.帧间预测编码
      帧间预测编码利用连续帧中的时间冗余来进行运动估计和补偿。H.264的运动补偿支持以往的视 频编码标准中的大部分关键特性,而且灵活地添加了更多的功能,除了支持P帧、B帧外,H.264还支持一种新的流间传送帧——SP帧,如图3所示。码流中 包含SP帧后,能在有类似内容但有不同码率的码流之间快速切换,同时支持随机接入和快速回放模式。图3 SP-帧示意图H.264的运动估计有以下4个特性。
      (1)不同大小和形状的宏块分割
      对每一个16×16像素宏块的运动补偿可以采用不同的大小和形状,H.264支持7种模式,如图4所示。小块模式的运动补偿为运动详细信息的处理提高了性能,减少了方块效应,提高了图像的质量。图4 宏块分割方法
      (2)高精度的亚像素运动补偿
      在H.263中采用的是半像素精度的运动估计,而在H.264中可以采用1/4或者1/8像素 精度的运动估值。在要求相同精度的情况下,H.264使用1/4或者1/8像素精度的运动估计后的残差要比H.263采用半像素精度运动估计后的残差来得 小。这样在相同精度下,H.264在帧间编码中所需的码率更小。
      (3)多帧预测
      H.264提供可选的多帧预测功能,在帧间编码时,可选5个不同的参考帧,提供了更好的纠错性能,这样更可以改善视频图像质量。这一特性主要应用于以下场合:周期性的运动、平移运动、在两个不同的场景之间来回变换摄像机的镜头。
      (4)去块滤波器
      H.264定义了自适应去除块效应的滤波器,这可以处理预测环路中的水平和垂直块边缘,大大减少了方块效应。
      3.整数变换
      在变换方面,H.264使用了基于4×4像素块的类似于DCT的变换,但使用的是以整数为基础 的空间变换,不存在反变换,因为取舍而存在误差的问题,变换矩阵如图5所示。与浮点运算相比,整数DCT变换会引起一些额外的误差,但因为DCT变换后的 量化也存在量化误差,与之相比,整数DCT变换引起的量化误差影响并不大。此外,整数DCT变换还具有减少运算量和复杂度,有利于向定点DSP移植的优 点。
      4.量化
      H.264中可选32种不同的量化步长,这与H.263中有31个量化步长很相似,但是在H.264中,步长是以12.5%的复合率递进的,而不是一个固定常数。
      在H.264中,变换系数的读出方式也有两种:之字形(Zigzag)扫描和双扫描,如图6所示。大多数情况下使用简单的之字形扫描;双扫描仅用于使用较小量化级的块内,有助于提高编码效率。图6 变换系数的读出方式
      5.熵编码
      视频编码处理的最后一步就是熵编码,在H.264中采用了两种不同的熵编码方法:通用可变长编码(UVLC)和基于文本的自适应二进制算术编码(CABAC)。
      在H.263等标准中,根据要编码的数据类型如变换系数、运动矢量等,采用不同的VLC码表。 H.264中的UVLC码表提供了一个简单的方法,不管符号表述什么类型的数据,都使用统一变字长编码表。其优点是简单;缺点是单一的码表是从概率统计分 布模型得出的,没有考虑编码符号间的相关性,在中高码率时效果不是很好。
      因此,H.264中还提供了可选的CABAC方法。算术编码使编码和解码两边都能使用所有句法 元素(变换系数、运动矢量)的概率模型。为了提高算术编码的效率,通过内容建模的过程,使基本概率模型能适应随视频帧而改变的统计特性。内容建模提供了编 码符号的条件概率估计,利用合适的内容模型,存在于符号间的相关性可以通过选择目前要编码符号邻近的已编码符号的相应概率模型来去除,不同的句法元素通常 保持不同的模型。
      四、H.264在视频会议中的应用
      目前,大多数的视频会议系统均采用H.261或H.263视频编码标准,而H.264的出现, 使得在同等速率下,H.264能够比H.263减小50%的码率。也就是说,用户即使是只利用 384kbit/s的带宽,就可以享受H.263下高达 768kbit/s的高质量视频服务。H.264 不但有助于节省庞大开支,还可以提高资源的使用效率,同时令达到商业质量的视频会议服务拥有更多的潜在客户。
      目前,已经有少数几家厂商的视频会议产品支持H.264协议,厂商们致力于普及H.264这个全新的业界标准。随着其它视频会议方案厂商陆续效仿他们的做法,我们必将能全面体验H.264视频服务的优势。

    H.264的技术亮点

       1、分层设计 H.264的算法在概念上可以分为两层:视频编码层(VCL:Video Coding Layer)负责高效的视频内容表示,网络提取层(NAL:Network Abstraction Layer)负责以网络所要求的恰当的方式对数据进行打包和传送。在VCL和NAL之间定义了一个基于分组方式的接口,打包和相应的信令属于NAL的一部 分。这样,高编码效率和网络友好性的任务分别由VCL和NAL来完成。
      VCL层包括基于块的运动补偿混合编码和一些新特性。与前面的视频编码标准一样,H.264没有把前处理和后处理等功能包括在草案中,这样可以增加标准的灵活性。
      NAL负责使用下层网络的分段格式来封装数据,包括组帧、逻辑信道的信令、定时信息的利用或序 列结束信号等。例如,NAL支持视频在电路交换信道上的传输格式,支持视频在Internet上利用RTP/UDP/IP传输的格式。NAL包括自己的头 部信息、段结构信息和实际载荷信息,即上层的VCL数据。(如果采用数据分割技术,数据可能由几个部分组成)。
      2、高精度、多模式运动估计
      H.264支持1/4或1/8像素精度的运动矢量。在1/4像素精度时可使用6抽头滤波器来减少高频噪声,对于1/8像素精度的运动矢量,可使用更为复杂的8抽头的滤波器。在进行运动估计时,编码器还可选择"增强"内插滤波器来提高预测的效果。
      在H.264的运动预测中,一个宏块(MB)可以按图2被分为不同的子块,形成7种不同模式的 块尺寸。这种多模式的灵活和细致的划分,更切合图像中实际运动物体的形状,大大提高了运动估计的精确程度。在这种方式下,在每个宏块中可以包含有1、2、 4、8或16个运动矢量。
      在H.264中,允许编码器使用多于一帧的先前帧用于运动估计,这就是所谓的多帧参考技术。例如2帧或3帧刚刚编码好的参考帧,编码器将选择对每个目标宏块能给出更好的预测帧,并为每一宏块指示是哪一帧被用于预测。
      3、4×4块的整数变换
      H.264与先前的标准相似,对残差采用基于块的变换编码,但变换是整数操作而不是实数运算, 其过程和DCT基本相似。这种方法的优点在于:在编码器中和解码器中允许精度相同的变换和反变换,便于使用简单的定点运算方式。也就是说,这里没有"反变 换误差"。 变换的单位是4×4块,而不是以往常用的8×8块。由于用于变换块的尺寸缩小,运动物体的划分更精确,这样,不但变换计算量比较小,而且在运动物体边缘处 的衔接误差也大为减小。为了使小尺寸块的变换方式对图像中较大面积的平滑区域不产生块之间的灰度差异,可对帧内宏块亮度数据的16个4×4块的DC系数 (每个小块一个,共16个)进行第二次4×4块的变换,对色度数据的4个4×4块的DC系数(每个小块一个,共4个)进行2×2块的变换。
      H.264为了提高码率控制的能力,量化步长的变化的幅度控制在12.5%左右,而不是以不变的增幅变化。变换系数幅度的归一化被放在反量化过程中处理以减少计算的复杂性。为了强调彩色的逼真性,对色度系数采用了较小量化步长。
      4、统一的VLC
      H.264中熵编码有两种方法,一种是对所有的待编码的符号采用统一的VLC(UVLC :Universal VLC),另一种是采用内容自适应的二进制算术编码(CABAC:Context-Adaptive Binary Arithmetic Coding)。CABAC是可选项,其编码性能比UVLC稍好,但计算复杂度也高。UVLC使用一个长度无限的码字集,设计结构非常有规则,用相同的码 表可以对不同的对象进行编码。这种方法很容易产生一个码字,而解码器也很容易地识别码字的前缀,UVLC在发生比特错误时能快速获得重同步。
      5、帧内预测
      在先前的H.26x系列和MPEG-x系列标准中,都是采用的帧间预测的方式。在H.264中,当编码Intra图像时可用帧内预测。对于每个4×4块(除了边缘块特别处置以外),每
      个像素都可用17个最接近的先前已编码的像素的不同加权和(有的权值可为0)来预测,即此像素所在块的左上角的17个像素。显然,这种帧内预测不是在时间上,而是在空间域上进行的预测编码算法,可以除去相邻块之间的空间冗余度,取得更为有效的压缩。
      如图4所示,4×4方块中a、b、...、p为16 个待预测的像素点,而A、B、...、P是已编码的像素。如m点的值可以由(J+2K+L+2)/ 4 式来预测,也可以由(A+B+C+D+I+J+K+L)/ 8 式来预测,等等。按照所选取的预测参考的点不同,亮度共有9类不同的模式,但色度的帧内预测只有1类模式。
      6、面向IP和无线环境
      H.264 草案中包含了用于差错消除的工具,便于压缩视频在误码、丢包多发环境中传输,如移动信道或IP信道中传输的健壮性。
      为了抵御传输差错,H.264视频流中的时间同步可以通过采用帧内图像刷新来完成,空间同步由 条结构编码(slice structured coding)来支持。同时为了便于误码以后的再同步,在一幅图像的视频数据中还提供了一定的重同步点。另外,帧内宏块刷新和多参考宏块允许编码器在决定 宏块模式的时候不仅可以考虑编码效率,还可以考虑传输信道的特性。
      除了利用量化步长的改变来适应信道码率外,在H.264中,还常利用数据分割的方法来应对信道 码率的变化。从总体上说,数据分割的概念就是在编码器中生成具有不同优先级的视频数据以支持网络中的服务质量QoS。例如采用基于语法的数据分割 (syntax-based data partitioning)方法,将每帧数据的按其重要性分为几部分,这样允许在缓冲区溢出时丢弃不太重要的信息。还可以采用类似的时间数据分割 (temporal data partitioning)方法,通过在P帧和B帧中使用多个参考帧来完成。
      在无线通信的应用中,我们可以通过改变每一帧的量化精度或空间/时间分辨率来支持无线信道的大 比特率变化。可是,在多播的情况下,要求编码器对变化的各种比特率进行响应是不可能的。因此,不同于MPEG-4中采用的精细分级编码FGS(Fine Granular Scalability)的方法(效率比较低),H.264采用流切换的SP帧来代替分级编码。

    H264编码技术

      H.264的目标应用涵盖了目前大部分的视频服务,如有线电视远程监控、交互媒体、数字电视、视

    标准的整体框架

    频 会议、视频点播、流媒体服务等。H.264为解决不同应用中的网络传输的差异。定义了两层:视频编码层(VCL:Video Coding Layer)负责高效的视频内容表示,网络提取层(NAL:Network Abstraction Layer)负责以网络所要求的恰当的方式对数据进行打包和传送(如图所示: 标准的整体框架)。
      基本层次(Baseline Profile):该层次使用了H.264的除了B-Slices,CABAC以及交织编码模式外所有的特性。该层次主要使用于低时延的实时应用场合。
      主要层次(Main Profile):包含Baseline profile的所有特性,并包括了B-slices,CABAC以及交织编码模式。它主要针对对时延要求不高,当压缩率和质量要求较高的场合。
      扩展层次(Profile X):支持所有Baseline profile的特性,但不支持CABAC以及基于宏块的自适应帧场编码。该层次主要针对的时各种网络视频流传输方面的应用。

    H264层次构成

       H264标准是由JVT(Joint Video Team,视频联合工作组)组织提出的新一代数字视频编码标准。JVT于2001年12月在泰国Pattaya成立。它由ITU-T的VCEG(视频编码 专家组)和ISO/IEC的MPEG(活动图像编码专家组)两个国际标准化组织的专家联合组成。JVT的工作目标是制定一个新的视频编码标准,以实现视频 的高压缩比、高图像质量、良好的网络适应性等目标H264标准。H264标准将作为MPEG-4标准的一个新的部分(MPEG-4 part.10)而获得批准,是一个面向未来IP和无线环境下的新数字视频压缩编码标准。
      H264标准的主要特点如下:
      1.更高的编码效率:同H.263等标准的特率效率相比,能够平均节省大于50%的码率。
      2.高质量的视频画面:H.264能够在低码率情况下提供高质量的视频图像,在较低带宽上提供高质量的图像传输是H.264的应用亮点。
      3.提高网络适应能力:H.264可以工作在实时通信应用(如视频会议)低延时模式下,也可以工作在没有延时的视频存储或视频流服务器中。
      4.采用混合编码结构:同H.263相同,H.264也使用采用DCT变换编码加DPCM的差分编码的混合编码结构,还增加了如多模式运动估计、帧内预测、多帧预测、基于内容的变长编码、4x4二维整数变换等新的编码方式,提高了编码效率。
      5.H.264的编码选项较少:在H.263中编码时往往需要设置相当多选项,增加了编码的难度,而H.264做到了力求简洁的“回归基本”,降低了编码时复杂度。
      6.H.264可以应用在不同场合:H.264可以根据不同的环境使用不同的传输和播放速率,并且提供了丰富的错误处理工具,可以很好的控制或消除丢包和误码。
      7.错误恢复功能:H.264提供了解决网络传输包丢失的问题的工具,适用于在高误码率传输的无线网络中传输视频数据。
      8.较高的复杂度:264性能的改进是以增加复杂性为代价而获得的。据估计,H.264编码的计算复杂度大约相当于H.263的3倍,解码复杂度大约相当于H.263的2倍。
      H264标准各主要部分有Access Unit delimiter(访问单元分割符),SEI(附加增强信息),primary coded picture(基本图像编码),Redundant Coded Picture(冗余图像编码)。还有Instantaneous Decoding Refresh(IDR,即时解码刷新)、Hypothetical Reference Decoder(HRD,假想码流调度器)、Hypothetical Stream Scheduler(HSS,假想参考解码)。[6]

    .

    H.264解码

      由于目前蓝光格式的统一,使得市面上绝大多数的高清视频均是采用H.264的格式编码,它又分为四个最主要步骤,分别是流处理,逆变换,动态补偿,去方块滤波,这四步也是资源消耗的主要四个部分。
      H.264解码的四个步骤中的第一步“CAVLC/CABAC解码”是最为消耗运算资源,这方 面远高于其他三步(简单的说,CAVLC/CABAC是H.264编码规范中两种不同的算法,都是为了提高压缩比,其中CABAC比CAVLC压缩率更 高,但解码时自然也要求更高)。
      如果所有四个步骤全采用处理器纯软件解码运算,当碰上HDDVD版本的高码率H.264视频,处理器的负载会非常巨大,即使能流畅播放高清视频,也会因为处理器压力过重而影响其他同时开启的应用程序的执行效率。
      如果让处理器解码“CAVLC/CABAC解码”和“反向转换(Inverse Transformation)”两部分,由显示核心承担“运动补偿”和“解码去块”功能,则可以在一定程度上降低处理器的压力。 不过对于使用单核处理器或低端双核处理器的用户来说,这依然无法很好的应付这类视频;其次,碰上编码率更高的视频,依然会给处理器造成很大的处理难度,导 致视频播放的不确定性,可能消费者会遇到某些视频可以流畅播放,但是有些视频却丢帧的情况。
      通过以上两点可以看出,由显示核心承担全部的H.264视频解码和处理过程,让其解码运算可以 基本不依赖处理器将是最为经济、便捷的方法。如果能实现这一点,以后消费者就无需过分担心自己的处理器性能如何,不同的视频编码率导致的负载差距过大等等 问题,只要选择一颗能支持“H.264全解码”的显示核心,就能无所顾忌的播放所有高清视频,而采用了高清加速引擎 的英特尔GMA X4500HD芯片组则能够轻松全程解码H.264格式的高清视频,再加上高级去交错技术、电影模式检测、细节增强技术、ProcAMP技术和最新的显示连接技术则能够从图像品质、色彩饱和度以及高清接口等方面提升用户的高清体验。

    H.264的性能比较

       TML-8为H.264的测试模式,用它来对H.264的视频编码效率进行比较和测试。测试结果所提供的PSNR已清楚地表明,相对于MPEG- 4(ASP:Advanced Simple Profile)和H.263++(HLP:High Latency Profile)的性能,H.264的结果具有明显的优越性。
      H.264的PSNR比MPEG-4(ASP)和H.263++(HLP)明显要好,在6种速 率的对比测试中,H.264的PSNR比MPEG-4(ASP)平均要高2dB,比H.263(HLP)平均要高3dB。6个测试速率及其相关的条件分别 为:32 kbit/s速率、10f/s帧率和QCIF格式;64 kbit/s速率、15f/s帧率和QCIF格式;128kbit/s速率、15f/s帧率和CIF格式;256kbit/s速率、15f/s帧率和 QCIF格式;512 kbit/s速率、30f/s帧率和CIF格式;1024 kbit/s速率、30f/s帧率和CIF格式。

    H.264的错误恢复工具

       错误恢复的工具随着视频压缩编码技术的提高在不断改进。旧的标准(H.261、H263、MPEG-2的第二部分)中,使用片和宏块组的划分、帧内编码 宏 块、帧内编码片和帧内编码图像来防止错误的扩散。之后改进的标准(H.263+、MPEG-4)中,使用多帧参考和数据分割技术来恢复错误。
      H.264标准在以前的基础上提出了三种关键技术:(1)参数集合,(2) 灵活的宏块次序(FMO),(3)冗余片(RS)来进行错误的恢复。

    1. 帧内编码


      
      H.264中帧内编码的技术和以前标准一样,值得注意的是:
      (1)H.264中的帧内预测编码宏块的参考宏块可以是帧间编码宏块,帧内预测宏块并不像H.263中的帧内编码一样,而采用预测的帧内编码比非预测的帧 内编码有更好的编码效率,但减少了帧内编码的重同步性能,可以通过设置限制帧内预测标记来恢复这一性能。
      (2)只包含帧内宏块的片有两种,一种是帧内片(Islice),一种是立即刷新片(IDRslice),立即刷新片必存在于立即刷新图像 (IDRpicture)中。与短期参考图像相比,立即刷新图像有更强壮的重同步性能。
      在无线IP网络环境下,为了提高帧内图像的重同步性能,要采用率失真优化编码和设置限制帧内预测标记。

    2. 图像的分割


      
      H.264支持一幅图像划分成片,片中宏块的数目是任意的。在非FMO模式下,片中的宏块次序是同光栅扫描顺序,FMO模式下比较特殊。片的划分可以适配不同的MTU尺寸,也可以用来交织分组打包。

    3. 参考图像选择


      
      参考图像数据选择,不论是基于宏块、基于片,还是基于帧,都是错误恢复的有效工具。对于有反馈 的系统,编码器获得传输中丢失图像区域的信息后,参考图像可 以选择解码已经正确接收的图像对应的原图像区域作参考。在没有反馈的系统中,将会使用冗余的编码来增加错误恢复性能。

    4. 数据的划分


      
      通常情况下,一个宏块的数据是存放在一起而组成片的,数据划分使得一个片中的宏块数据重新组合,把宏块语义相关的数据组成一个划分,由划分来组装片。
      在H.264中有三种不同的数据划分。
      头信息划分:包含片中宏块的类型,量化参数和运动矢量,是片中最重要的信息。
      帧内信息划分:包含帧内CBPs和帧内系数,帧内信息可以阻止错误的蔓延。
      帧间信息划分:包含帧间CBPs和帧间系数,通常比前两个划分要大得多。
      帧内信息划分结合头信息解出帧内宏块,帧间信息划分结合头信息解出帧间宏块。帧间信息划分的重要性最低,对重同步没有贡献。当使用数据划分时,片中的数据根据其类型被保存到不同的缓存,同时片的大小也要调整,使得片中最大的划分小于MTU尺寸。
      解码端若获得所有的划分,就可以完整重构片;解码端若发现帧内信息或帧间信息划分丢失,可用的头信息仍然有很好的错误恢复性能。这是因为宏块类型和宏块的运动矢量含有宏块的基本特征。

    5. 参数集的使用


      
      序列的参数集(SPS)包括了一个图像序列的所有信息,图像的参数集(PPS)包括了一个图像 所有片的信息。多个不同的序列和图像参数集经排序存放在解码 器。编码器参考序列参数集设置图像参数集,依据每一个已编码片的片头的存储地址选择合适的图像参数集来使用。对序列的参数和图像的参数进行重点保护才能很 好地增强H.264错误恢复性能。
      在差错信道中使用参数集的关键是保证参数集及时、可靠地到达解码端。例如,在实时信道中,编码 器用可靠控制协议及早将他们以带外传输的方式发送,使控制协 议能够在引用新参数的第一个片到达之前把它们发给解码器;另外一个办法就是使用应用层保护,重发多个备份文件,确保至少有一个备份数据到达解码端;第三个 办法就是在编解码器的硬件中固化参数集设置。

    6. 灵活的宏块次序(FMO)


      
      灵活的宏块次序是H.264的一大特色,通过设置宏块次序映射表(MBAmap)来任意地指配 宏块到不同的片组,FMO模式打乱了原宏块顺序,降低了编码 效率,增加了时延,但增强了抗误码性能。FMO模式划分图像的模式各种各样,重要的有棋盘模式、矩形模式等。当然FMO模式也可以使一帧中的宏块顺序分 割,使得分割后的片的大小小于无线网络的MTU尺寸。经过FMO模式分割后的图像数据分开进行传输,以棋盘模式为例,当一个片组的数据丢失时可用另一个片 组的数据(包含丢失宏块的相邻宏块信息)进行错误掩盖。实验数据显示,当丢失率为(视频会议应用时)10%时,经错误掩盖后的图像仍然有很高的质 量。

    7. 冗余片方法


      
      前边提到了当使用无反馈的系统时,就不能使用参考帧选择的方法来进行错误恢复,应该在编码时增 加冗余的片来增强抗误码性能。要注意的是这些冗余片的编码参 数与非冗余片的编码参数不同,也就是用一个模糊的冗余片附加在一个清晰的片之后。在解码时先解清晰的片,如果其可用就丢弃冗余片;否则使用冗余模糊片来重 构图像。

    H.264在动中通应急图像传输中的应用

      动中通系统对编解码技术的需求
      动中通系统的卫星通道的特点决定了编解码器要具备如下能力。
      第一,受动中通卫星天线增益、经纬度、地球同步轨道通信卫星自身参数以及天气状况(如下雨、多云)的限制,在许多地区上行带宽超不过1.5Mbit/s。结合我公安实战要求,需要编解码器在低于1.5Mbit/s的带宽下能够传输清晰的D1质量的图像。
      第二,由于受到树木、山体及建筑物等物体的遮挡,卫星通道经常出现中断,这就要求图像编解码器在卫星链路恢复后,能够即时恢复图像传输。
      第三,卫星链路相对于有线链路其误码率要高很多,这就给动中通系统的编解码系统提出了更高的要求,要采取相应机制,以适应较高的误码率。
      第四,动中通系统经常需要在高速运行的环境下进行图像传输,此时图像的变化将非常剧烈,这就对编解码器的运算处理能力提出了更高的要求,这种要求远大于对室内电视会议系统图像处理能力的要求。
      第五,动中通系统一般运行在车载环境中,环境温度较高,电磁干扰较强,对编解码器的适应性和抗干扰性能都提出了很高的要求。
      H.264技术是动中通图像 编解码器理想的选择
      1.H.264技术的产生与发展
      图1 视频编码标准沿革示意图
      H.264是一种高性能的视频编解码技术。它是由两大标准化组织联合组建的联合视频组 (JVT)共同制定的新数字视频编码标准,所以它既是ITU-T的H.264,又是ISO/IEC的MPEG-4高级视频编码 (AdvancedVideoCoding,AVC),而且它将成为MPEG-4标准的第10部分。
      2.H.264技术可以很好地适应动中通卫星通道的特点,与动中通系统有效地结合。
      (1)具有较高的压缩效率
      H.264编码视频流与H.263或MPEG-4Simple Profile编码视频流相比,平均可节省39%的比特率。通过引入一系列新特性,H.264的压缩率提升近1倍,大大节省了卫星的传输带宽。目前,国内 的H.264编解码器厂商可以在1.2Mbit/s的编码码率下实现D1(720×576)分辨率的连续清晰图像。
      表1 H.264与MPEG-2压缩码率比较
      (2)基于UDP,实现图像即时恢复
      由于受到遮挡,动中通系统经常发生卫星链路中断的现象,在卫星信号恢复后,编解码系统要能够以 最快的速度恢复图像传输。H.264可以把关键信息分离出来,减小断流再恢复的同步时间,同时,H.264编解码器可以建立在UDP基础之上,能够快速重 建链路,目前国内的编解码器厂商已经实现图像即时恢复。
      (3)具有较强的抗丢包和抗误码性能
      在卫星数据通信过程中,由于噪声和其它原因,误码是必然存在的。H.264标准的参数集和片的 使用、FMO、冗余片等关键技术可以大大提高系统的抗丢包和抗误码性能。H.264定义了视频编码层(VLC)和网络提取层(NAL),并在框架结构上进 行了分离,可以在异构网络环境中使用。H.264把关键信息分离出来,凭借参数集的设计,确保在易出错的环境中正确地传输它们,也增强了码流传输的错误恢 复能力。H.264技术中定义了灵活片组(FMO)、数据分割等错误恢复工具,方便解码端实行错误掩盖。
      此外,在运行过程中,出现卫星链路中断或误码率过高时,实现了画面停留在最后清晰的一帧上,同 时,在实现了在信号恢复之后,画面从接收到的清晰的一帧开始。H.264技术内置的多种错误恢复工具有利于解码端进行错误掩盖,误码超过一定阈值后跳过该 帧,断流后则保持在最后一正常帧的静止画面,码流恢复后从第一个正常解码的IDR帧开始显示。
      (4)具有较强地抗干扰能力
      动中通系统中的摄像头有时会引入较大干扰,特别在低照度的环境中干扰对图像质量有非常大的影 响。根据分析主要有两种噪声会影响视频质量,一种是相邻色素之间产生的伪颜色噪声,一种是由于信号强度而产生的泊松噪声(会影响物体的边缘清晰度)。一般 滤波器的工作原理是先做低通滤波,然后再做高通滤波。从频谱上分析,物体的边缘成分在做低通的时候已经损失掉了一部分,尽管在高通后通过一定的处理可以还 原大部分,但实际上它已经不能够达到最理想的效果。这些噪点随着产品型号和工作环境的不同而不同。由于视频压缩算法效率与时间上的相关性有关,这种随机噪 点对视频压缩的影响非常大,有时候甚至造成码流成倍上升,将压缩算法的优点全部掩盖。H.264技术一方面使用了高级图像预处理方法,能够减小低照度环境 下噪点影响;另一方面,通过实时滤波技术的应用,使得在压缩之前就排除了信号中的干扰,压缩还原的图像有很大提高,同时也降低了传输码率。
      (5)网络适应性强
      H.264包含一个内置的互联网协议适配层 (InternetProtocolAdaptiveLayer),所以,H.264可以被映射到任何固定IP、无线IP、存储装置或广播网络中,而这就 是电信公司和消费性电子厂商都准备支持H.264的原因。H.264作为最新的视频编码标准,采取了一系列切合实际的技术措施,如视频编码层和网络提取层 分离、封装NALUnits、指定参数集等提高了网络适应性,增强了数据抗误码的顽健性,从而保证了视频传输后压缩视频的QoS。
      3.在动中通卫星系统中H.264编解码器经受住了实战的洗礼。
      北京奥运安保中大量地启用了平板式相控阵动中通卫星通信车,该类卫星车具有技术先进、机动灵 活、操作简单、锁星效果好、性价比高等诸多优点,但也有其难以弥补的不足——上行带宽低。在北京地区只有1.5Mbit/s左右,在原有MPEG-2或 MPEG-4SimpleProfile编解码器下,很难实现动中通条件下D1(720×576)分辨率的清晰图像连续传输。为此,有关方面技术人员对多 种编解码器做了大量的实验、对比以及改进,最终选择了H.264编解码器。在奥运安保期间,它实现了在1.2~1.5Mbit/s的视频码率下传输清晰的 D1图像,圆满完成了奥运安保尤其是火炬接力、公路自行车赛、马拉松赛等线路型赛事的图像传输任务。
      目前,国内的有关技术机构已经开始着手较窄带宽下适合无线移动传输的基于H.264技术的高清 编解码器的研发工作。随着技术的不断发展、整体结构的不断完善、算法的不断优化以及芯片处理能力的不断提高,相信不久便可以看见国产的H.264编解码器 在较窄的卫星带宽下实现高清品质的图像传输。[1]

    关于H.264的六个问题

      (1) H.264是国际标准吗?为何说H.264要比其他压缩技术更具前景?
      和此前的视频压缩技术如H.263不同的是,H.264虽然仍然是ITU-T体系之下的命名规 范,却大量借鉴了ISO/IEC的相关规范和研究。具体而言,ITU-T之下的视频编码专家组(Video Code Expert Group,VCEG)确立了H.264,而ISO/IEC之下的运动图像专家组(MPEG)则将其命名为MPEG-4Part10/AVC。这两个专家 组织共同制定了该标准。
      因此,H.264和此前的视频压缩技术相比,既是行业标准,同时也是国际标准。此前ITU-T制定的视频标准,因为和ISO/IEC的MPEG系列标准存在兼容性问题,所以严格意义上并没有合适的、较为统一并为设备商们全体遵循的全球性国际标准。
      和此前的压缩技术相比,H.264的优势主要体现在下面几个方面:
      1. 精确匹配解码,避免错误累积;
      2. 更简单的规范实施;
      3. 强大的容错能力;
      4. 高效压缩,比其他视频压缩能力高50%以上;
      5. 时延级差,以适应更多应用环境等。
       (2) H.264是标准体系,还是单一性标准?H.264的总体优缺点如何?有没有不足之处?
      VCEG和MPEG联合开发H.264标准带来的最大好处就是,有助于H.264在全球范围内的设备统一化,推广起来更为简便。但是和此前的视频标准一样,为了使得应用范围更广,H.264也还是通过等级区别和类别算法对多种应用场景进行各自的协议支持。
      H.264可以提供11个等级、7个类别的子协议格式(算法),其中等级定义是对外部环境进行 限定,例如带宽需求、内存需求、网络性能等等。等级越高,带宽要求就越高,视频质量也越高。类别定义则是针对特定应用,定义编码器所使用的特性子集,并规 范不同应用环境中的编码器复杂程度。
      H.264除了在技术上的优势,应用上的优点主要体现在被更广泛地接受,成为统一性的全球标准,可以降低总体应用成本。当前主要缺点是:对终端(网络摄像机、显示终端)要求更高。另外,对于家庭用户而言,解码回放设备价格过高,导致目前普及上存在一定的困难。
       (3) 当前H.264主要用在哪些领域?视频监控是主体方向吗?
      视频监控是H.264部署的重要方向之一,这得益于H.264强大的压缩能力、通用性,以及对 网络性能的容忍能力。但H.264的应用领域极为宽泛,视频监控只能是其主要的应用方向之一,而不能视作主体方向。可以说,当前所有的视频应用,都可以通 过H.264获得高质量的实现,例如数字电视广播、高清电视、在线视频的存储和点播、3G视频电话等等。
       (4) H.264相关技术在中国市场有没有大的应用(高于企业级)?
      我国是H.264部署较为活跃的国家,特别在视频监控行业,我国的投资巨大,但相关的市场总投入目前并无合适估算。原因在于,交通、公安,以及国家重点行业的视频设备尤其是高清视频设备部署情况并不是特别公开。
      2008年奥运会,成为中国部署H.264视频监控的一个重要阶段。此外,中国电信在早期阶段 进行的IPTV测试中,也大量采用了H.264技术,虽然后续中国电信也开始对国产视频标准AVS,但对H.264的测试和跟踪仍然在继续。中国电信“全 球眼”业务当前已经开始在一些局部地区大量采用H.264技术,并和现有专网视频业务进行混合方案的提供,效果良好,这是当前中国乃至全球范围内覆盖最 大、专项业务线最为全面的业务类型。
       (5) 中国在H.264方面的进展如何?自主技术方面有哪些突破?
      鉴于H.264作为全球通用标准的优势,国内大部分企业在部署新的视频应用时都有可能采用H.264,并且,正因为应用的广泛性,H.264的相关设备价格将会迅速下降,部署成本也将因此得以降低。
      我国的广电系统和电信运营商曾经将H.264作为主要的推动方向,并取得了一系列的成绩。在目前电信已经实行运营的IPTV项目中,几乎全部采用了H.264; 广电系统的各大电视台在进行从模拟向数字转换,以及网络双向改造中,也大量采用了H.264技术标准。
      而随着我国第二代具有自主知识产权的视频编码标准AVS(信息技术先进音视频编码)出台,情况 发生了变化。由于AVS对比H.264算法更为简便,专利授权模式和收费都较为便利和低廉,并且和H.264在编解码、压缩上处于同一水平,因此我国开始 大力推广AVS的应用及产业链打造。国家正在努力构建对AVS产业链的政策扶持和资金扶持,以促进AVS逐步走向快车道。从目前看,AVS标准已经看到 H.264的应用广泛程度和后续竞争的存在,很多公司在开发AVS的同时,积极将AVS纳入到和H.264兼容的体系中,这将有利于推动AVS的发展,并 在后续过程中,相互竞争的同时,为AVS的发展争取更多的空间。
       (6) H.264标准技术的采用,将会带动哪些上下游产品和应用的迅速发展?
      总体而言,H.264标准被视做下一代视频编解码应用的最佳实现之一,被普遍认为会是将来更具竞争力的标准。
      H.264的应用,至少能够促进以下几个方面的发展:
      1. 视频监控的全IP化和高清化;
      2. 百万像素摄像机市场的发展;
      3. 蓝光DVD及上下游硬件设备的发展;
      4. 局域网容量需求的上升,以及由此带动的网络存储容量升级;
      5. 数字电视、IPTV发展的提速,以及上下游产品和内容源质量提升;
      6. 网络带宽的进一步升级等。[2]

    国内H.264编解码器生产厂家


      北京亚邦伟业技术有限公司
      金三立视频科技(深圳)有限公司
      北京数码视讯科技股份有限公司
      埃比(AB)控股浙江安防有限公司
      南京江瑞计算机系统控制有限公司
      北京蛙视通信技术有限责任公司
      杭州海康威视数字技术股份有限公司
      北京欧恩亿光电科技有限公司
      杭州华三通信技术有限公司

    Intel G965支持H.264

       在近日举行的台北IDF大会上,Intel表示,目前Intel在显卡市场约占37%的份额,占据图形市场的大头,当然,Intel并没有生产独立的显 示芯片产品,其份额全部为内建显示核心IGP芯片组。Intel估计IGP芯片组的市场出货量将会在2004年至2010年期间提升13%,不过,这并不 意味着独立显示芯片产品的出货量将得以下降。
      现时Intel占整体IGP芯片市场约61%,为了保持优势Intel会在下一代G965 IGP使用第四代显示核心,定名为Intel Clear Video Technology。据Intel数码家庭事业群高级工师Brett Branch透露,它大幅度提供了G965的视频播放能力,包括加入Advanced De-interlacing、Mpeg-2 Hardware Acceleration、H.264 Hardware Acce;leration、High Definition Multimedia Interface (HDMI)介面、WMV9B High Definition Decode (iDCT/VC1)及ProcAmp API等,绝对不让PureVideo及AVIVO功能专美。这也让此前传出的G965芯片将不支持H.264的消息不攻自破。
      在3D效能方面,G965的第四代绘图核心规格进一步提升,成为首个支持Direct X 9.0、Sharder Model 3.0及OpenGL 1.5的Intel IGP平台,硬件Pixel Sader 3.0及Vertex Shader 3.0处理能力,硬件Transform & Lighting (T&L)及Full Precision Floting Point Operations支援HDR效果,实力绝对不能忽视,最高可共享256MB系统内存。
      目前G965已完成第一阶段的A0样本测试并进入B0的第二版测试,将于第14周至第18周完 成最后阶段C0-C1,量产及出货时间为2006年Q3,支援将推出的Conroe处理器核心,配合全新ICH8南桥晶片,并达成Windows Vista Premium OS认证。[5]

    展开全文
  • H264的基本原理

    万次阅读 2020-05-19 21:01:05
    H264概述 H264 是 MPEG-4 标准所定义的编码格式,标准写法应该是H.264。 H264 视频格式是经过有损压缩的,但在技术上尽可能做的降低存储体积下获得较好图像质量和低带宽图像快速传输。 H264压缩技术主要采用了...

    H264概述

    H264 是 MPEG-4 标准所定义的编码格式,标准写法应该是H.264。

    H264 视频格式是经过有损压缩的,但在技术上尽可能做的降低存储体积下获得较好图像质量和低带宽图像快速传输。 

    H264压缩技术主要采用了以下几种方法对视频数据进行压缩。包括:

    • 帧内预测压缩,解决的是空域数据冗余问题。
    • 帧间预测压缩(运动估计与补偿),解决的是时域数据冗余问题。
    • 整数离散余弦变换(DCT),将空间上的相关性变为频域上无关的数据然后进行量化。
    • CABAC压缩。

    H264结构中,一个视频图像编码后的数据叫做一帧,一帧由一个片(slice)或多个片组成,一个片由一个或多个宏块(MB)组成,一个宏块由16x16的yuv数据组成。宏块作为H264编码的基本单位。

    在H264协议内定义了三种帧,分别是I帧、B帧与P帧。I帧就是之前所说的一个完整的图像帧,而B、帧与P帧所对应的就是之前说的不编码全部图像的帧。P帧与B帧的差别就是P帧是参考之前的I帧而生成的,而B帧是参考前后图像帧编码生成的。

    经过压缩后的帧分为:I帧,P帧和B帧:

    • I帧:关键帧,采用帧内压缩技术。你可以理解为这一帧画面的完整保留;解码时只需要本帧数据就可以完成(因为包含完整画面)
    • P帧:向前参考帧,在压缩时,只参考前面已经处理的帧。采用帧间压缩技术。P帧表示的是这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。(也就是差别帧,P帧没有完整画面数据,只有与前一帧的画面差别的数据)
    • B帧:双向参考帧,在压缩时,它既参考前而的帧,又参考它后面的帧。采用帧间压缩技术。B帧记录的是本帧与前后帧的差别(具体比较复杂,有4种情况),换言之,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高,但是解码时CPU会比较累~。

    还有一个概念是,IDR帧

    一个序列的第一个图像叫做 IDR 图像(立即刷新图像),IDR 图像都是 I 帧图像H.264 引入 IDR 图像是为了解码的重同步,当解码器解码到 IDR 图像时,立即将参考帧队列清空,将已解码的数据全部输出或抛弃,重新查找参数集,开始一个新的序列。这样,如果前一个序列出现重大错误,在这里可以获得重新同步的机会。IDR图像之后的图像永远不会使用IDR之前的图像的数据来解码IDR 图像一定是 I 图像,但I图像不一定是 IDR 图像。一个序列中可以有很多的I图像,I 图像之后的图像可以引用 I 图像之间的图像做运动参考。

    还有一点注意的,对于 IDR 帧来说,在 IDR 帧之后的所有帧都不能引用任何 IDR 帧之前的帧的内容,与此相反,对于普通的 I 帧来说,位于其之后的 B- 和 P- 帧可以引用位于普通 I- 帧之前的 I- 帧。从随机存取的视频流中,播放器永远可以从一个 IDR 帧播放,因为在它之后没有任何帧引用之前的帧。但是,不能在一个没有 IDR 帧的视频中从任意点开始播放,因为后面的帧总是会引用前面的帧。

    继续再多补充一个概念,图像组(GOP)

    一个序列就是一段内容差异不太大的图像编码后生成的一串数据流。当运动变化比较少时,一个序列可以很长,因为运动变化少就代表图像画面的内容变动很小,所以就可以编一个 I 帧,然后一直 P 帧、B 帧了。当运动变化多时,可能一个序列就比较短了,比如就包含一个 I 帧和 3、4个P帧。

    GOP是画面组,一个GOP是一组连续的画面。
    GOP一般有两个数字,如M=3,N=12。M指定I帧与P帧之间的距离,N指定两个I帧之间的距离。那么现在的GOP结构是:

    I 帧、B帧、P帧还有一些特点,如下:
    I帧特点:
    1)它是一个全帧压缩编码帧。它将全帧图像信息进行JPEG压缩编码及传输;
    2)解码时仅用I帧的数据就可重构完整图像;
    3)I帧描述了图像背景和运动主体的详情;
    4)I帧不需要参考其他画面而生成;
    5)I帧是P帧和B帧的参考帧(其质量直接影响到同组中以后各帧的质量);
    6)I帧是帧组GOP的基础帧(第一帧),在一组中只有一个I帧;
    7)I帧不需要考虑运动矢量;
    8)I帧所占数据的信息量比较大。


    P帧特点:
    1)P帧是I帧后面相隔1~2帧的编码帧;
    2)P帧采用运动补偿的方法传送它与前面的I或P帧的差值及运动矢量(预测误差);
    3)解码时必须将I帧中的预测值与预测误差求和后才能重构完整的P帧图像;
    4)P帧属于前向预测的帧间编码。它只参考前面最靠近它的I帧或P帧;
    5)P帧可以是其后面P帧的参考帧,也可以是其前后的B帧的参考帧;
    6)由于P帧是参考帧,它可能造成解码错误的扩散;
    7)由于是差值传送,P帧的压缩比较高。


    B帧特点:
    1)B帧是由前面的I或P帧和后面的P帧来进行预测的;
    2)B帧传送的是它与前面的I或P帧和后面的P帧之间的预测误差及运动矢量;
    3)B帧是双向预测编码帧;
    4)B帧压缩比最高,因为它只反映并参考帧间运动主体的变化情况,预测比较准确;加大B帧的数量可以有效地提高视频数据的压缩比,但是在实时互动的环境下,过多的B帧会引起延时,因为B帧会过分的依赖于前后帧,在网络好的环境下,可以正常的传输帧,这样没有什么问题,但是在网络不好的时候,B帧会等待其他帧到来,会引起延时。
    5)B帧不是参考帧,不会造成解码错误的扩散。

    注:I、B、P各帧是根据压缩算法的需要,是人为定义的,它们都是实实在在的物理帧。一般来说,I帧的压缩率是7(跟JPG差不多),P帧是20,B帧可以达到50。可见使用B帧能节省大量空间,节省出来的空间可以用来保存多一些I帧,这样在相同码率下,可以提供更好的画质。

    备注:

    视频传输中会出现连个比较常见的现象,花屏 和 卡顿

    (1)如果在GOP分组中的P帧丢失,会造成解码端的图像发生错误。这就是花屏。GOP一组帧呈现出的连贯效果,由于P帧丢失,它需要更新的部分就没有,所以无法正常呈现。故出现花屏现象。

    (2)为了解决花屏的问题发生,我们可以将丢失 P帧 或是 I帧 的 GOP 丢掉(包含其中的所有帧),直到下一个I帧再重新刷新图像。但是由于这一帧丢掉了,所以会出现卡顿。

    H264压缩技术

    H264的基本原理其实非常简单,我们就简单的描述一下H264压缩数据的过程。通过摄像头采集到的视频帧(按每秒 30 帧算),被送到 H264 编码器的缓冲区中。编码器先要为每一幅图片划分宏块。

    H264采用的核心算法是帧内压缩和帧间压缩,帧内压缩是生成I帧的算法,帧间压缩是生成B帧和P帧的算法。

    帧内(Intraframe)压缩也称为空间压缩(Spatialcompression)。当压缩一帧图像时,仅考虑本帧的数据而不考虑相邻帧之间的冗余信息,这实际上与静态图像压缩类似。帧内一般采用有损压缩算法,由于帧内压缩是编码一个完整的图像,所以可以独立的解码、显示。帧内压缩一般达不到很高的压缩,跟编码jpeg差不多。

    帧间(Interframe)压缩的原理是:相邻几帧的数据有很大的相关性,或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息,根据这一特性,压缩相邻帧之间的冗余量就可以进一步提高压缩量,减小压缩比。帧间压缩也称为时间压缩(Temporalcompression),它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧差值(Framedifferencing)算法是一种典型的时间压缩法,它通过比较本帧与相邻帧之间的差异,仅记录本帧与其相邻帧的差值,这样可以大大减少数据量。

    压缩方式说明

    Step1:分组,也就是将一系列变换不大的图像归为一个组,也就是一个序列,也可以叫GOP(画面组);

    Step2:定义帧,将每组的图像帧归分为I帧、P帧和B帧三种类型;

    Step3:预测帧, 以I帧做为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧;

    Step4:数据传输, 最后将I帧数据与预测的差值信息进行存储和传输。

     

      1. 划分宏块

    H264默认是使用 16X16 大小的区域作为一个宏块,也可以划分成 8X8 大小。

    划分好宏块后,计算宏块的象素值。

    以此类推,计算一幅图像中每个宏块的像素值,所有宏块都处理完后如下面的样子。

      1. 划分子块

    H264对比较平坦的图像使用 16X16 大小的宏块。但为了更高的压缩率,还可以在 16X16 的宏块上更划分出更小的子块。子块的大小可以是 8X16、 16X8、 8X8、 4X8、 8X4、 4X4非常的灵活。

    上幅图中,红框内的 16X16 宏块中大部分是蓝色背景,而三只鹰的部分图像被划在了该宏块内,为了更好的处理三只鹰的部分图像,H264就在 16X16 的宏块内又划分出了多个子块。

    这样再经过帧内压缩,可以得到更高效的数据。下图是分别使用mpeg-2和H264对上面宏块进行压缩后的结果。其中左半部分为MPEG-2子块划分后压缩的结果,右半部分为H264的子块划压缩后的结果,可以看出H264的划分方法更具优势。

    宏块划分好后,就可以对H264编码器缓存中的所有图片进行分组了。

      1. 帧分组

    对于视频数据主要有两类数据冗余,一类是时间上的数据冗余,另一类是空间上的数据冗余。其中时间上的数据冗余是最大的。下面我们就先来说说视频数据时间上的冗余问题。

    为什么说时间上的冗余是最大的呢?假设摄像头每秒抓取30帧,这30帧的数据大部分情况下都是相关联的。也有可能不止30帧的的数据,可能几十帧,上百帧的数据都是关联特别密切的。

    对于这些关联特别密切的帧,其实我们只需要保存一帧的数据,其它帧都可以通过这一帧再按某种规则预测出来,所以说视频数据在时间上的冗余是最多的。

    为了达到相关帧通过预测的方法来压缩数据,就需要将视频帧进行分组。那么如何判定某些帧关系密切,可以划为一组呢?我们来看一下例子,下面是捕获的一组运动的台球的视频帧,台球从右上角滚到了左下角。

     

     

    H264编码器会按顺序,每次取出两幅相邻的帧进行宏块比较,计算两帧的相似度。如下图:

     

     

    通过宏块扫描与宏块搜索可以发现这两个帧的关联度是非常高的。进而发现这一组帧的关联度都是非常高的。因此,上面这几帧就可以划分为一组。其算法是:在相邻几幅图像画面中,一般有差别的像素只有10%以内的点,亮度差值变化不超过2%,而色度差值的变化只有1%以内,我们认为这样的图可以分到一组。

    在这样一组帧中,经过编码后,我们只保留第一帧的完整数据,其它帧都通过参考上一帧计算出来。我们称第一帧为IDR/I帧,其它帧我们称为P/B帧,这样编码后的数据帧组我们称为GOP

      1. 运动估计与补偿

    H264编码器中将帧分组后,就要计算帧组内物体的运动矢量了。还以上面运动的台球视频帧为例,我们来看一下它是如何计算运动矢量的。

    H264编码器首先按顺序从缓冲区头部取出两帧视频数据,然后进行宏块扫描。当发现其中一幅图片中有物体时,就在另一幅图的邻近位置(搜索窗口中)进行搜索。如果此时在另一幅图中找到该物体,那么就可以计算出物体的运动矢量了。下面这幅图就是搜索后的台球移动的位置。

    通过上图中台球位置相差,就可以计算出台球运行的方向和距离。H264依次把每一帧中球移动的距离和方向都记录下来就成了下面的样子。

     

    运动矢量计算出来后,将相同部分(也就是绿色部分)减去,就得到了补偿数据。我们最终只需要将补偿数据进行压缩保存,以后在解码时就可以恢复原图了。压缩补偿后的数据只需要记录很少的一点数据。如下所示:

    我们把运动矢量与补偿称为帧间压缩技术,它解决的是视频帧在时间上的数据冗余。除了帧间压缩,帧内也要进行数据压缩,帧内数据压缩解决的是空间上的数据冗余。下面我们就来介绍一下帧内压缩技术。

      1. 帧内预测

    人眼对图象都有一个识别度,对低频的亮度很敏感,对高频的亮度不太敏感。所以基于一些研究,可以将一幅图像中人眼不敏感的数据去除掉。这样就提出了帧内预测技术。

    H264的帧内压缩与JPEG很相似。一幅图像被划分好宏块后,对每个宏块可以进行 9 种模式的预测。找出与原图最接近的一种预测模式。

    下面这幅图是对整幅图中的每个宏块进行预测的过程。

    帧内预测后的图像与原始图像的对比如下:

    然后,将原始图像与帧内预测后的图像相减得残差值。

    再将我们之前得到的预测模式信息一起保存起来,这样我们就可以在解码时恢复原图了。效果如下:

    经过帧内与帧间的压缩后,虽然数据有大幅减少,但还有优化的空间。

      1. 对残差数据做DCT

    可以将残差数据做整数离散余弦变换,去掉数据的相关性,进一步压缩数据。如下图所示,左侧为原数据的宏块,右侧为计算出的残差数据的宏块。

     

    将残差数据宏块数字化后如下图所示:

    将残差数据宏块进行 DCT 转换。

    去掉相关联的数据后,我们可以看出数据被进一步压缩了。

    做完 DCT 后,还不够,还要进行 CABAC 进行无损压缩。

      1. CABAC

    上面的帧内压缩是属于有损压缩技术。也就是说图像被压缩后,无法完全复原。而CABAC属于无损压缩技术。

    无损压缩技术大家最熟悉的可能就是哈夫曼编码了,给高频的词一个短码,给低频词一个长码从而达到数据压缩的目的。MPEG-2中使用的VLC就是这种算法,我们以 A-Z 作为例子,A属于高频数据,Z属于低频数据。看看它是如何做的。

    CABAC也是给高频数据短码,给低频数据长码。同时还会根据上下文相关性进行压缩,这种方式又比VLC高效很多。其效果如下:

    现在将 A-Z 换成视频帧,它就成了下面的样子。

     

    从上面这张图中明显可以看出采用 CACBA 的无损压缩方案要比 VLC 高效的多。

     

    H264分层结构

    H264的主要目标是为了有高的视频压缩比和良好的网络亲和性,为了达成这两个目标,H264的解决方案是将系统框架分为两个层面,分别是视频编码层面(VCL)和网络抽象层面(NAL),如图;

    H.264原始码流(裸流)是由一个接一个NALU组成,它的功能分为两层,VCL(视频编码层) NAL(网络抽象层).

    
     
    VCL(Video Coding Layer) + NAL(Network Abstraction Layer).
    1. VCL:包括核心压缩引擎和块,宏块和片的语法级别定义,设计目标是尽可能地独立于网络进行高效的编码;
    2. NAL:负责将VCL产生的比特字符串适配到各种各样的网络和多元环境中,覆盖了所有片级以上的语法级别。

    因为H264最终还是要在网络上进行传输,在传输的时候,网络包的最大传输单元是1500字节,一个H264的帧往往是大于1500字节的,所以需要将一个帧拆成多个包进行传输。这些拆包、组包等工作都在NAL层去处理。

    H264码流结构

    VCL进行数据传输或存储之前,这些编码的VCL数据,被映射或封装进NAL单元(NALU)。

    H264码流是由一个个的NAL单元组成,其中SPS、PPS、IDR和SLICE是NAL单元某一类型的数据。

    1. H264的NAL单元

    一个NALU = 一组对应于视频编码的NALU头部信息 + 一个原始字节序列负荷(RBSP,Raw Byte Sequence Payload).

    如图所示,下图中的NALU的头 + RBSP 就相当于一个NALU(Nal Unit),每个单元都按独立的NALU传送。H.264的结构全部都是以NALU为主,理解了NALU,就理解了H.264的结构。
    一个原始的H.264 NALU 单元常由 [StartCode] [NALU Header] [NALU Payload] 三部分组成,其中 Start Code 用于标示这是一个NALU 单元的开始,必须是”00 00 00 01” ”00 00 01”

     

    3字节的0x000001只有一种场合下使用,就是一个完整的帧被编为多个slice的时候,包含这些slice的nalu使用3字节起始码。其余场合都是4字节的。

      1. NAL Header

    NAL单元的头部是由forbidden_bit(1bit)nal_reference_bit(2bits)(优先级),nal_unit_type(5bits)(类型)三个部分组成的。

    1F(forbiden):禁止位,占用NAL头的第一个位,当禁止位值为1时表示语法错误;

    2NRI:参考级别,占用NAL头的第二到第三个位;值越大,该NAL越重要。

    3Type:Nal单元数据类型,也就是标识该NAL单元的数据类型是哪种,占用NAL头的第四到第8个位;

    举例来说:

    00 00 00 01 06:  SEI信息  

    00 00 00 01 67:  0x67&0x1f = 0x07 :SPS

    00 00 00 01 68:  0x68&0x1f = 0x08 :PPS

    00 00 00 01 65:  0x65&0x1f = 0x05: IDR Slice

     

           在具体介绍NAL数据类型前,有必要知道NAL分为VCL和非VCL的NAL单元。其中SPS、SEI、PPS等非VCL的NAL参数对解码和显示视频都是很有用的。

            而另外一个需要了解的概念就是参数集(Parameter sets),参数集是携带解码参数的NAL单元,参数集对于正确解码是非常重要的,在一个有损耗的传输场景中,传输过程中比特列或包可能丢失或损坏,在这种网络环境下,参数集可以通过高质量的服务来发送,比如向前纠错机制或优先级机制。Parameter sets与其之外的句法元素之间的关系如图9所示:

     

    每种类型都有代表一种数据类型,比较重要的以下几种做个简单的介绍:

    1、非VCL的NAL数据类型:

    1)、SPS(序列参数集):SPS对如标识符、帧数以及参考帧数目、解码图像尺寸和帧场模式等解码参数进行标识记录。

    2)、PPS(图像参数集):PPS对如熵编码类型、有效参考图像的数目和初始化等解码参数进行标志记录。

    3)、SEI(补充增强信息):这部分参数可作为H264的比特流数据而被传输,每一个SEI信息被封装成一个NAL单元。SEI对于解码器来说可能是有用的,但是对于基本的解码过程来说,并不是必须的。

     

    @:先标记一下,SPS、PPS内容是编码器给的。(出处的话,慢慢研究)

     

    2、VCL的NAL数据类型

    1)、 头信息块,包括宏块类型,量化参数,运动矢量。这些信息是最重要的,因为离开他们,被的数据块种的码元都无法使用。该数据分块称为A类数据分块。

    2)、 帧内编码信息数据块,称为B类数据分块。它包含帧内编码宏块类型,帧内编码系数。对应的slice来说,B类数据分块的可用性依赖于A类数据分块。和帧间编码信息数据块不通的是,帧内编码信息能防止进一步的偏差,因此比帧间编码信息更重要。

    3)、 帧间编码信息数据块,称为C类数据分块。它包含帧间编码宏块类型,帧间编码系数。它通常是slice种最大的一部分。帧间编码信息数据块是不重要的一部分。它所包含的信息并不提供编解码器之间的同步。C类数据分块的可用性也依赖于A类数据分块,但于B类数据分块无关。

    以上三种数据块每种分割被单独的存放在一个NAL单元中,因此可以被单独传输。

     

      1. RBSP原始字节序列负荷

    序列举

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

    1SODB String Of Data Bits 原始数据比特流

            因为它是流的形式,所以长度不一定是8倍数,它是由 VLC 层产生的。由于我们计算机是以8倍数去处理数据所以计算机在处理H264时,就需要 RBSP

    2RBSPSODB + tailing bits (原始字节序列载荷)

            由于它是一个压缩流,SODB 不知道是在何处结束,所以算法在SODB最后一位补一个1,没有按字节对齐的则补 0

    3EBSP (扩展字节序列载荷)

            在生成压缩流之后,在每一帧的开头加一个起始位,这个起始位一般是 00 00 00 01 或者是 00 00 01。所以在h264码流中规定每有两个连续的00 00,就增加一个0x03

     

    补充:EBSP RBSP的区别

            ANALU的主体涉及到三个重要的名词,分别为EBSPRBSPSODB。其中EBSP完全等价于NALU主体,而且它们三个的结构关系为:EBSP包含RBSPRBSP包含SODB

            h264的文档中,并没有EBSP这一名词出现,但是在h264的官方参考软件JM里,却使用了EBSPNALU的组成部分为:

     

            NALU = NALU Header + RBSP

     

            其实严格来说,这个等式是不成立的,因为RBSP并不等于NALU刨去NALU Header。严格来说,NALU的组成部分应为:

            NALU = NALU Header + EBSP

            其中的EBSP为扩展字节序列载荷(Encapsulated Byte Sequence Payload),而RBSP为原始字节序列载荷(Raw Byte Sequence Payload)。

             B、那为什么要弄一个EBSP呢?

            EBSP相较于RBSP,多了防止竞争的一个字节:0x03

            我们知道,NALU的起始码为0x0000010x00000001,同时H264规定,当检测到0x000000时,也可以表示当前NALU的结束。那这样就会产生一个问题,就是如果在NALU的内部,出现了0x0000010x000000时该怎么办?

            所以H264就提出了“防止竞争”这样一种机制,当编码器编码完一个NAL时,应该检测NALU内部,是否出现如下左侧的四个序列。当检测到它们存在时,编码器就在最后一个字节前,插入一个新的字节:0x03

            这样一来,当我们拿到EBSP时,就需要检测EBSP内是否有序列:0x000003,如果有,则去掉其中的0x03。这样一来,我们就能得到原始字节序列载荷:RBSP

     

        1. SPS 和 PPS

    SPS即Sequence Paramater Set,又称作序列参数集。SPS中保存了一组编码视频序列(Coded video sequence)的全局参数。存放包括:帧数、参考帧数目、解码图像尺寸、帧场编码模式选择标识等。所谓的编码视频序列即原始视频的一帧一帧的像素数据经过编码之后的结构组成的序列。而每一帧的编码后数据所依赖的参数保存于图像参数集中。一般情况SPS和PPS的NAL Unit通常位于整个码流的起始位置。但在某些特殊情况下,在码流中间也可能出现这两种结构,主要原因可能为:

    解码器需要在码流中间开始解码;
    编码器在编码的过程中改变了码流的参数(如图像分辨率等);
    H.264中另一重要的参数集合为图像参数集Picture Paramater Set(PPS)。和图像相关的参数集,存放包括:熵编码模式选择标识、片组数目、初始量化参数和去方块滤波系数调整标识等。通常情况下,PPS类似于SPS,在H.264的裸码流中单独保存在一个NAL Unit中,只是PPS NAL Unit的nal_unit_type值为8;而在封装格式中,PPS通常与SPS一起,保存在视频文件的文件头中。

    在一组帧之前,首先要收到SPS 和 PPS ,不然的话是无法解码的。这两组数据划分为I帧,是不能丢的。

      1. H264的NAL单元与片,宏之间的联系

            其实到这里可能就比较难理解了,为什么数据NAL单元中有这么多数据类型,这个SLICE又是什么东西,为什么不直接是编码后出来的原始字节序列载荷,所以我觉得在这里再讲述帧所细分的一些片和宏的概念应该是比较合适的,也是能够参照上下文更能理解这些概念的位置,又能给这些困惑做一个合理一点的解释,所以在此做一个描述:

     

    1帧(一幅图像) = 1~N个片(slice)  //也可以说1到多个片为一个片组

    1个片 = 1~N个宏块(Marcroblock)

    1个宏块 = 16X16的YUV数据(原始视频采集数据)

     

    从数据层次角度来说,一幅原始的图片可以算作广义上的一帧,帧包含片组和片,片组由片来组成,片由宏块来组成,每个宏块可以是4*4、8*8、16*16像素规模的大小,它们之间的联系如图10所示。每个片都是一个独立的编码单位。

     

                                                    图10

    从容纳数据角度来说,NAL单元除了容纳Slice编码的码流外,还可以容纳其他数据,这也就是为什么有SPS、PPS等这些数据出现的原因,并且这些数据在传输H264码流的过程中起到不可或缺的作用,具体作用上面也是有讲到的。

    那么也就可以对下面这些概念做一个大小的排序了:

                    序列>图像>片>宏>像素(当然还有片组、亚宏块等等这些概念,初步了解就不了解这么深了,后面再慢慢研究)

     

    同时有几点需要说明一下,这样能便于理解NAL单元:

    (1)、如果不采用 FMO(灵活宏块排序) 机制,则一幅图像只有一个片组;

    (2)、如果不使用多个片,则一个片组只有一个片;

    (3)、如果不采用 DP(数据分割)机制,则一个片就是一个 NALU,一个 NALU 也就是一个片。

       否则,一个片的组成需要由 三个 NALU 组成,也就是上面说到的A、B、C类数据块。

     

    这时候在看下面这幅码流数据分层图11就比较能理解整体的码流结构组成了;

                                                           图11

     

     

        如我们所见,每个分片也包含着头和数据两部分,分片头中包含着分片类型、分片中的宏块类型、分片帧的数量以及对应的帧的设置和参数等信息,而分片数据中则是宏块,这里就是我们要找的存储像素数据的地方;宏块是视频信息的主要承载者,因为它包含着每一个像素的亮度和色度信息。视频解码最主要的工作则是提供高效的方式从码流中获得宏块中的像素阵列。宏块数据的组成如下图12所示:

                                        图12

     

        从上图中,可以看到,宏块中包含了宏块类型、预测类型、Coded Block Pattern、Quantization Parameter、像素的亮度和色度数据集等等信息。

    至此,我们对 H.264 的码流数据结构应该有了一个大致的了解。

     

        1. Slice()

    如图所示,NALU的主体中包含了Slice().

     
    一个片 = Slice Header + Slice Data

    片是H.264提出的新概念,通过编码图片后切分通过高效的方式整合出来的概念。一张图片有一个或者多个片,而片由NALU装载并进行网络传输的。但是NALU不一定是切片,这是充分不必要条件,因为 NALU 还有可能装载着其他用作描述视频的信息.

    那么为什么要设置片呢?
    设置片的目的是为了限制误码的扩散和传输,应使编码片相互间是独立的。某片的预测不能以其他片中的宏块为参考图像,这样某一片中的预测误差才不会传播到其他片中

    可以看到上图中,每个图像中,若干宏块(Macroblock)被排列成片。一个视频图像可编程一个或更多个片,每片包含整数个宏块 (MB),每片至少包含一个宏块。
    片有一下五种类型:

    意义

    I

    只包含I宏块

    P

    包含PI宏块

    B

    包含BI宏块

    SP

    包含P / I宏块,用于不同码流之间的切换

    SI

    一种特殊类型的编码宏块

        1. 宏块(Macroblock)

    刚才在片中提到了宏块.那么什么是宏块呢?
    宏块是视频信息的主要承载者。一个编码图像通常划分为多个宏块组成.包含着每一个像素的亮度和色度信息。视频解码最主要的工作则是提供高效的方式从码流中获得宏块中像素阵列

    1
    一个宏块 = 一个16*16的亮度像素 + 一个8×8Cb + 一个8×8Cr彩色像素块组成。(YCbCr 是属于 YUV 家族的一员,在YCbCr 中 Y 是指亮度分量,Cb 指蓝色色度分量,而 Cr 指红色色度分量)

     

    宏块分类

    意义

    I 宏块

    利用从当前片中已解码的像素作为参考进行帧内预测

    P 宏块

    利用前面已编码图像作为参考进行帧内预测,一个帧内编码的宏块可进一步作宏块的分割:16×16.16×8.8×16.8×8亮度像素块。如果选了8×8的子宏块,则可再分成各种子宏块的分割,其尺寸为8×88×44×84×4

    B 宏块

    利用双向的参考图像(当前和未来的已编码图像帧)进行帧内预测

    2.1句发元素的分层结构, H.264 中,句法元素共被组织成 序列、图像、片、宏块、子宏块五个层次。
    句法元素的分层结构有助于更有效地节省码流。例如,再一个图像中,经常会在各个片之间有相同的数据,如果每个片都同时携带这些数据,势必会造成码流的浪费。更为有效的做法是将该图像的公共信息抽取出来,形成图像一级的句法元素,而在片级只携带该片自身独有的句法元素


    2.2宏块的句法单

    宏块分类

    意义

    mb_type

    确定该 MB 是帧内或帧间(P B)编码模式,确定该 MB 分割的尺寸

    mb_pred

    确定帧内预测模式(帧内宏块)确定表 0 或表 1 参考图 像,和每一宏块分割的差分编码的运动矢量(帧间宏块,除 8×8 宏块分割的帧内 MB)

    sub_mb_pred

    (只对 8×8MB 分割的帧内 MB)确定每一子宏块的子宏 块分割,每一宏块分割的表 0 /或表 1 的参考图象;每一 宏块子分割的差分编码运动矢量。

    coded_block_pattern

    指出哪个 8×8 (亮度和彩色) 编码变换系数

    mb_qp_delta

    量化参数的改变值

    residual

    预测后对应于残差图象取样的编码变换系数

        1. 图像,场和

    图像是个集合概念,顶 场、底场、帧都可以称为图像。对于H.264 协议来说,我们平常所熟悉的那些称呼,例如: I 帧、P 帧、B帧等等,实际上都是我们把图像这个概念具体化和细小化了。我们 H.264里提到的通常就是指不分场的图像

    视频的一场或一帧可用来产生一个编码图像。一帧通常是一个完整的图像。当采集视频信号时,如果采用隔行扫描(.偶数行),则扫描下来的一帧图像就被分为了两个部分,这每一部分就被称为 [],根据次序氛围[顶场]  [底场]

    方式

    作用域

    帧编码方式

    活动量较小或者静止的图像宜采用

    场编码方式

    活动量较大的运动图像

     

    参考 

    https://blog.csdn.net/go_str/article/details/80340564

    https://blog.csdn.net/qq_28090573/article/details/89881047

    从零了解H264结构

     

    展开全文
  • RTP载荷H264视频流

    万次阅读 2020-05-21 11:52:33
    H264 RTP包解析 预备 视频: 由一副副连续的图像构成,由于数据量比较大,因此为了节省带宽以及存储,就需要进行必要的压缩与解压缩,也就是编解码。 h264裸码流: 对一个图像或者一个视频序列进行压缩,...
  • h264测试文件

    千次下载 热门讨论 2011-12-08 11:34:47
    希望能对要h264文件测试,而又没有的朋友有所帮助
  • H264基本原理

    万次阅读 多人点赞 2017-11-15 02:23:43
    H264视频压缩算法现在无疑是所有视频压缩技术中使用最广泛,最流行的。随着 x264/openh264以及ffmpeg等开源库的推出,大多数使用者无需再对H264的细节做过多的研究,这大降低了人们使用H264的成本。但为了用好H264,...
  • H264解析开源库H264Bitstream

    千次阅读 2016-10-26 21:46:44
    H264Bitstream:解析H264的开源库。对于理解H264码流结构有很好的帮助。 https://sourceforge.net/projects/h264bitstream/
  • H264系列(5):关于ITU-H264 和 ISO/IEC H264 的关系
  • Qt基于FFmpeg播放本地 H.264(H264)文件

    万次阅读 多人点赞 2016-07-19 11:06:25
    最近在弄H264的硬件编解码,基于DM3730,但是为了调试方便,在小红帽上用FFmpeg实现了H264的软件编解码。现在弄了一个Windows的例子,给需要的同学参考一下,如果大家觉得有帮助,可以小手一抖,帮我点个赞。 这个...
  • H264/AVC视频解码时AVC1和H264的区别

    千次阅读 2017-04-19 10:11:55
    The following media subtypes are defined for H.264 video.SubtypeFOURCCDescriptionMEDIASUBTYPE_AVC1'AVC1'H.264 bitstream without start codes.MEDIASUBTYPE_H264'H264'H.264 bitstream with start codes.MEDI
  • android硬编码h264

    千次下载 热门讨论 2013-12-26 15:20:25
    android 用新api mediacodec硬编码h264, 发送到vlc播放。
  • h264 raw stream parser-读取H264裸流信息

    千次阅读 2019-08-14 10:17:56
     要分析h264裸流中的数据,H264BSAnalyzer这个工具就不错,在这里推荐一下。  用H264BSAnalyzer读取我编码的一段h264视频,截图如下:  阅读或者修改就不太方便,依赖一些编解码库。昨天,我阅读webrtc的代码,...
  • YUV编码为H264 H264封装为MP4

    千次阅读 2018-05-09 17:23:39
    YUV编码为H264 H264封装为MP4 参考文献: [1]http://blog.csdn.net/leixiaohua1020/article/details/42078645 [2]http://blog.csdn.net/firehood_/article/details/8813587 [3]...
  • 关于H.264 x264 h264 AVC1

    2015-06-03 22:58:21
    1. H.264是MPEG4的第十部分,是一个标准。...对头,H.264是需要付费的编码格式,而x264是符合H.264标准的一个开源项目,是免费的,也就是H264的一个简化版,不支持某些高级特性。但x264非常优秀,并不比H264
  • 入门理解H264编码

    万次阅读 多人点赞 2018-05-17 16:50:27
    最近入门音视频技术,一直在学习H264编解码标准,了解了不少关于H264的相关知识,对于网上各种类型的资料,始终没有找到一篇适合的知识梳理资料。可能是查找方式不对,所以花费了比较多的时间。经过一段时间的熟悉后...
  • H.264 (H264)文件800_600.264,分辨率800*600,亲测可用
  • read H264 Nal

    千次阅读 2021-01-26 14:01:26
    从264文件中读取Nal,一般用于测试的时候H264输入源: 参考:https://blog.csdn.net/leixiaohua1020/article/details/17933821 分辨率较大的话需要修改READH264_MAXFRAME_SIZE, #include <stdio.h> #...
  • MP4的视频H264封装有2种格式:h264和avc1 AVC1 描述:H.264 bitstream without start codes.一般通过ffmpeg转码生成的视频,是不带起始码0x00000001的。 H264 描述:H.264 bitstream with start codes.一般对于一下...
  • H.264 x264 h264 AVC1的关系和区别

    千次阅读 2016-12-19 17:54:32
    H.264是MPEG4的第十部分,是一个标准。...对头,H.264是需要付费的编码格式,而x264是符合H.264标准的一个开源项目,是免费的,也就是H264的一个简化版,不支持某些高级特性。但x264非常优秀,并不比H264
  • H264Player播放器

    千次下载 热门讨论 2010-12-18 09:25:15
    H.264录像文件播放器。能播放264录像文件,这是一个能播放H264录像文件的程序,希望对有需要的有所帮助
  • H264流媒体源代码和相关资料.rar

    千次下载 热门讨论 2010-01-04 15:46:11
    本示例代码在我的电脑上实现了对标准H264码流的RTP打包发送到本机的1234端口,用VLC播放器从1234端口能接收到该码流并实时播放。代码附有详细的注释,应该很容易理解(前提是大家稍微对RFC3550 RFC3984协议有了解)...
  • 函数h264_mp4toannexb_filter详解 1、ffmpeg中处理h264码流分为两种情况 a、没有extradata则直接把packet中的数据交给解码器 b、如果有extradata,则需要把sps和pps的数据分析出来,连同packet.data一起交给解码...
  • H264和H265 RTP封包解包

    2020-06-06 15:09:11
    学习H264和H265封包解包时浏览过的博客的链接如下: H264 H264基础及RTP分包解包 H264 RTP封包原理 RTP H264注意点(FU-A分包方式说明) H265 H265 Nalu类型详细解析 H265 Nalu类型判断及 sps 数据解析 H265封装成...
  • 2、H264 码流分析软件 :H264Visa 测试数据:720P - 大雄兔_60fps_2D.h264 输出数据:720P - 大雄兔_60fps_2D.yuv 1、用H264Visa打开720P - 大雄兔_60fps_2D.h264,点击【tools】选择【Start YUV Output】,选择...
  • H264系列(4):h264协议帧头数据解析
  •   前言 H264视频压缩算法现在无疑是...随着 x264/openh264以及ffmpeg等开源库的推出,大多数使用者无需再对H264的细节做过多的研究,这大降低了人们使用H264的成本。 但为了用好H264,我们还是要对H264的基本原...
  • h264和h265

    千次阅读 2016-12-02 15:20:51
    h264和h265是视频的一种压缩格式

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 29,386
精华内容 11,754
关键字:

h264