H264码流结构的分析

H.264是JVT组织起草的一个覆盖多种应用和面向多种传输环境的国际标准，它规定了三种档次，基本档次(Baseline profile)、主要档次(Mainprofile)和扩展档次(Extended profile)，其中基本档次利用I片和P片支持帧内和帧间编码。

支持利用基于上下文的自适应的变长编码进行的熵编码(CAVLC)，主要用于会议电视、可视电话和无线通信等实时视频通信。

AVS(Audio video coding)标准是由我国自主制定，拥有自主知识产权的音视频编解码技术标准。

AVS―M(Mobile video)是AVS系列标准中的第七部分――移动视频，应用于数字存储媒体、宽带视频业务、远程监控和可视电话等。

AVS-M和H.264(Baseline)视频解码器在结构上十分相似，但又各有其核心思想。

本文基于JMl0.2和WM3源代码对两解码器的关键技术作了详细分析。

程序中并未单独有H.264(Baseline)的代码，是笔者从JMl0.2中抽取出来分析的，下文中H.264均表示从基本档次上考虑。

两种标准的解码器结构AVS-M和H.254视频解码器都只需考虑I帧和P帧(为了两标准视频解码器更好地比较，本文对H.264只考虑帧图像，不考虑场图像)的解码。

总体思想是从比特流中解出头信息，产生预测块，熵解码得到的量化系数经反量化、反变换得到残差块。

预测块和残差块相加后，经过滤波器即可得到重建的图像，其结构框图如图1所示。

在实际应用当中，这两种标准设计出来的解码器应用领域有所不同，现就以下几个方面分析两种标准的差异。

1 比特流信息①NALU(Network AbstractLayer UnitX两标准中的比特流都是以NAL为单位，每个NAL 单元包含一个RBSP，NALU的头信息定义了RBSP所属类型。

类型一般包括序列参数集(SPS)、图像参数集(PPS)、增强信息(SEI)、条带(Slice)等，其中，SPS和PPS属于参数集，两标准采用参数集机制是为了将一些重要的序列、图像参数(解码图像尺寸、片组数、参考帧数、量化和滤波参数标记等)与其他参数分离，通过解码器先解码出来。

H264码流结构分析和rtp打包结构详解分类：linux应⽤程序之---流媒体（18）⽹络抽象层单元类型 (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 单⼀时间的组合包25 STAP-B 单⼀时间的组合包26 MTAP16 多个时间的组合包27 MTAP24 多个时间的组合包28 FU-A 分⽚的单元29 FU-B 分⽚的单元30-31 没有定义h264仅⽤1-23,24以后的⽤在RTP H264负载类型头中RTP 头的结构:0 1 2 30 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): 7bitsrfc⾥⾯对⼀些早期的格式定义了这个payload type。

数字电视H.264编码技术分析及应用展望典型的数字电视系统是在发送端的数字电视节目源(主要由视频、音频等数据组成)先经过信源编码处理．得到压缩编码后的视频、音频码流，随后进行信源编码，需要辅助数据与控制数据的支持。

信道编码实现检错、纠错功能，以提高数字电视传输信号的抗干扰能力，以便之适应信道传输特性，再进行载波调制以实现频谱搬移最后送入传输信道。

目前数字视频领域，有两大制定视频编码标准的组织，它们是ITU-T与ISO／IEC。

ITU-T制定的标准包括H．261、H．263、H．264，主要应用于实时视频通信领域，如会议电视。

MPEG系列标准是由ISO／IEC制定的，主要应用于视频存储(VCD、DVD)、广播电视、因特网或无线网上的流媒体等。

H．264具有较强的抗误码特性，可适应丢包率高、干扰严重的无线信道中的视频传输。

1 编码技术分析1．1 帧内预测编码帧内编码用来缩减图像的空间冗余。

为了提高H．264帧内编码的效率，在给定帧中充分利用相邻宏块的空间相关性，相邻的宏块通常含有相似的属性。

因此，在对一给定宏块编码时，首先可以根据周围的宏块预测(典型的是根据左上角的宏块，因为此宏块已经被编码处理)，然后对预测值与实际值的差值进行编码，这样，相对于直接对该帧编码而言，可以大大减小码率。

如图1。

1．2 帧间预测编码帧间预测编码利用连续帧中的时间冗余来进行运动估计和补偿。

H．264的运动补偿支持以往的视频编码标准中的大部分关键特性。

(1)不同大小和形状的宏块分割对每一个16×16像素宏块的运动补偿可以采用不同的大小和形状。

(2)高精度的亚像素运动补偿在H．263中采用的是半像素精度的运动估计，而在H．264中可以采用1／4或者1／8像素精度的运动估值。

在要求相同精度的情况下，H．264使用1／4或者1／8像素精度的运动估计后的残差要比H．263采用半像素精度运动估计后的残差来得小。

这样在相同精度下，H．264在帧间编码中所需的码率更小。

【知识点】H264,H265硬件编解码基础及码流分析前⾔⾳视频开发需要你懂得⾳视频中⼀些基本概念,针对编解码⽽⾔,我们必须提前懂得编解码器的⼀些特性,码流的结构,码流中⼀些重要信息如sps,pps,vps,start code以及基本的⼯作原理,⽽⼤多同学都只是⼀知半解,所以导致代码中的部分内容虽可以简单理解却不知其意,所以,在这⾥总结出了当前主流的H.264,H.265编码相关的原理,以供学习.1. 概览1.1. 为什么要编码众所周知,视频数据原始体积是巨⼤的,以720P 30fps的视频为例,⼀个像素⼤约3个字节,如下所得,每秒钟产⽣87MB,这样计算可得⼀分钟就将产⽣5.22GB。

数据量/每秒=1280*720*33*3/1024/1024=87MB因此,像这样体积重⼤的视频是⽆法在⽹络中直接传输的.⽽视频编码技术也就因运⽽⽣.关于视频编码原理的技术可以参考本⼈其他⽂章,这⾥不做过多描述.1.2. 编码技术经过很多年的开发迭代,已经有很多⼤⽜实现了视频编码技术,其中最主流的有H.264编码,以及新⼀代的H.265编码,⾕歌也开发了VP8,VP9编码技术.对移动端⽽⾔,苹果内部已经实现了如H.264,H.265编码,我们需要使⽤苹果提供的VideoToolbox框架来实现它.1.3. 编码分类软件编码(简称软编)：使⽤CPU进⾏编码。

硬件编码(简称硬编)：不使⽤CPU进⾏编码，使⽤显卡GPU,专⽤的DSP、FPGA、ASIC芯⽚等硬件进⾏编码。

优缺点软编：实现直接、简单，参数调整⽅便，升级易，但CPU负载重，性能较硬编码低，低码率下质量通常⽐硬编码要好⼀点。

硬编：性能⾼，低码率下通常质量低于硬编码器，但部分产品在GPU硬件平台移植了优秀的软编码算法（如X264）的，质量基本等同于软编码。

iOS系统中的硬编码苹果在iOS 8.0系统之前，没有开放系统的硬件编码解码功能，不过Mac OS系统⼀直有，被称为Video ToolBox的框架来处理硬件的编码和解码，终于在iOS 8.0后，苹果将该框架引⼊iOS系统。

H264编码原理以及I帧、B和P帧详解，H264码流结构分析H264码流结构分析/chenchong_219/article/details/379905411、码流总体结构：h264的功能分为两层，视频编码层（VCL）和⽹络提取层（NAL）。

H.264 的编码视频序列包括⼀系列的NAL 单元，每个NAL 单元包含⼀个RBSP。

⼀个原始的H.264 NALU 单元常由 [StartCode] [NALU Header] [NALU Payload] 三部分组成，其中 Start Code ⽤于标⽰这是⼀个NALU 单元的开始，必须是"00 00 00 01" 或"0000 01"。

其中RBPS有分为⼏种类型：NAL的解码单元的流程如下：2、 NAL Header：占⼀个字节，由三部分组成forbidden_bit(1bit)，nal_reference_bit(2bits)（优先级），nal_unit_type(5bits)（类型）。

forbidden_bit:禁⽌位。

nal_reference_bit：当前NAL的优先级，值越⼤，该NAL越重要。

nal_unit_type ：NAL类型。

参见下表⼏个例⼦：3、 ffmpeg解析H264流程分析这是⼀段实际的码流在上⾯的图⽚中,共有三个起始码:0x00 0000 01const uint8_t*ff_h264_decode_nal(H264Context*h, const uint8_t *src,int *dst_length, int*consumed, int length)中分析过程为：h->nal_ref_idc= src[0] >> 5;h->nal_unit_type= src[0] & 0x1F;此处src[0]即为06，写成⼆进制位0000 0110，则h->nal_ref_idc = 0，h->nal_unit_type = 6可以判断这个NALU类型为SEI，重要性优先级为0。

H.264码流结构解析1.H.264简介MPEG（Moving Picture Experts Group）和VCEG（Video Coding Experts Group）已经联合开发了一个比早期研发的MPEG 和H.263性能更好的视频压缩编码标准，这就是被命名为A VC（Advanced Video Coding），也被称为ITU-T H.264建议和MPEG-4的第10 部分的标准，简称为H.264/A VC或H.264。

这个国际标准已经与2003年3月正式被ITU-T所通过并在国际上正式颁布。

为适应高清视频压缩的需求，2004年又增加了FRExt部分；为适应不同码率及质量的需求，2006年又增加了可伸缩编码SVC。

2.H.264编码格式H.263定义的码流结构是分级结构，共四层。

自上而下分别为：图像层(picturelayer)、块组层(GOB layer)、宏块层(macroblock layer)和块层(block layer)。

而与H.263相比，H.264的码流结构和H.263的有很大的区别，它采用的不再是严格的分级结构。

H.264支持4:2:0的连续或隔行视频的编码和解码。

H.264压缩与H.263、MPEG-4相比，视频压缩比提高了一倍。

H.264的功能分为两层：视频编码层（VCL, Video Coding Layer）和网络提取层（NAL, Network Abstraction Layer）。

VCL数据即编码处理的输出，它表示被压缩编码后的视频数据序列。

在VCL数据传输或存储之前，这些编码的VCL数据，先被映射或封装进NAL单元中。

每个NAL单元包括一个原始字节序列负荷（RBSP, Raw Byte Sequence Payload）、一组对应于视频编码的NAL头信息。

RBSP的基本结构是：在原始编码数据的后若干比特0”，以便字节对齐。

面填加了结尾比特。

一个bit“1”“图1 NAL单元序列3.H.264传输H.264的编码视频序列包括一系列的NAL单元，每个NAL单元包含一个RBSP，见表1。

VIDEO ENGINEERINGNo．S2Vol.332009（Sum No．332）1引言在过去的MPEG-2或其他视频编码系统的设计中，通常采用专用的头解码器作为前端解码，这是由于比特流结构的变化很小[1-2]。

由于诸如MPEG-4和H.264/AVC 等先进压缩编码标准的应用，有了越来越多的编码工具和高压缩性能。

比特率的格式随着不同的标准而变化，越来越复杂和灵活的比特率结构被提了出来。

这些都激发了对多标准的通用解析器设计的研究。

另一方面，能灵活适应新标准的可编程处理器的使用也大大缩短了设备的面市时间。

比特流解析是依据压缩标准的数据流格式从比特流中抽取头信息和编码数据。

比特流解析可以作为解码系统的预处理单元。

通常在编程器上采用并行结构以提高视频处理效率，但这样对比特流的解析未必高效，这是因为大多数采用熵编码的编码工作都是可变长度的。

这便是从比特流寄存器中获得不确定比特数的位级序列处理法。

在当前或前一个码字或当前比特流指针位置确定之前，下一步要抽取的码字是事先并不知道的。

所以，对于串行的比特流解析和VLD 任务来说，采用常用的16位或32位DSP 效率并不高。

在文献[3]提出的多功能VLD 芯片能够解析H.261和JPEG 比特流。

一个基于RISC 核的比特流解析和VLD 结构[4]提高了常规RISC 对比特流的处理能力。

文献[1]提出一种基于硬件结构的用于MPEG-4视频的解析。

在H.264中增加了许多新的特性，如扩展的Golomb 编码、背景适应的VLC 和背景适应的算术熵编码等。

笔者提出了针对H.264/AVC 比特流解析基于硬件的可编程结构，可解析符合H.264/AVC 标准的ES 比特流以及熵解码，也能够扩展到其他一些视频标准比特流解析应用中。

2H.264/AVC 比特流结构分析比特流结构是将专门的定长和变长码字序列串联起来的编码规则。

根据参考文献[5]，H.264/AVC 将视频编码层（VCL ）打包后进一步生成网络抽象层（NAL ）单元。

H264基础简介前⾔H264是属于视频的编码层的标准格式，视频编码显然是为了压缩⼤⼩。

我们看下⼀个完全没压缩的视频数据⼤⼩。

假设视频是⾼清（1280 * 720），每秒30帧，也就是每秒的数据1280 * 720 *30 / 8(字节) /1024（KB）/1024(MB) = 3.11MB那么90分钟的电影就要16.7GB，这个数据量显然在当前⽹络下是不现实的。

视频压缩的原理就是去除视频冗余部分，下⾯列举下1，时间冗余时间冗余是序列图像(电视图像、动画)和语⾳数据中所经常包含的冗余。

图像序列中的两幅相邻的图像，后⼀幅图像与前⼀幅图像之间有较⼤的相关性，这反映为时间冗余。

同理，在语⾔中，由于⼈在说话时发⾳的⾳频是⼀连续的渐变过程，⽽不是⼀个完全的在时间上独⽴的过程，因⽽存在时间冗余。

2，空间冗余空间冗余是图像数据中经常存在的⼀种冗余。

在同⼀幅图像中，规则物体和规则背景(所谓规则是指表⾯颜⾊分布是有序的⽽不是杂乱⽆章的)的表⾯物理特性具有相关性，这些相关性的光成像结构在数字化图像中就表现为数据冗余。

,3，知识冗余有许多图像的理解与某些基础知识有相当⼤的相关性,例如：⼈脸的图像有固定的结构。

⽐如，嘴的上⽅有⿐⼦。

⿐⼦的上⽅有眼睛，⿐⼦位于正脸图像的中线上等等。

这类规律性的结构可由先验知识相背景知识得到，我们称此类冗余为知识冗余。

4，结构冗余有些图像从⼤域上看存在着⾮常强的纹理结构，例如布纹图像和草席图像，我们说它们在结构上存在冗余。

5，视觉冗余⼈类视觉系统对于图像场的任何变化，并不是都能感知的。

例如，对于图像的编码和解码处理时，由于压缩或量⽐截断引⼊了噪声⽽使图像发⽣了⼀些变化，如果这些变化不能为视觉所感知，则仍认为图像⾜够好。

事实上⼈类视觉系统⼀般的分辨能⼒约为26灰度等级，⽽⼀般图像量化采⽤28灰度等级，这类冗余我们称为视觉冗余。

通常情况下，⼈类视觉系统对亮度变化敏感，⽽对⾊度的变化相对不敏感；在⾼亮度区，⼈眼对亮度变化敏感度下降。

RTP协议全解（H264码流和PS流）写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。

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

1、RTP Header解析图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位，必须使用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?kIe1 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_CCe0 是M_PT00 1e 是SequenceNum00 00 d2 f0 是Timestamp00 00 00 00是SSRC把前两字节换成二进制如下1000 0000 1110 0000按顺序解释如下：10 是V；0 是P；0 是X；0000 是CC；1 是M；110 0000 是PT；排版不如word看的清晰，大家凑合着看吧。