导致解码延时/丢帧的语法元素—H264

最新推荐文章于 2024-07-13 12:56:30 发布

walkingMa

最新推荐文章于 2024-07-13 12:56:30 发布

阅读量4.1k

点赞数 1

本文链接：https://blog.csdn.net/listener51/article/details/54347333

版权

//***************************可能导致解码延时的语法元素****************************//

VUI 中有这样的信息:

num_reorder_frames 是用于标示出显示的时候需要缓冲多少帧以方便排序，比如IPP序列是不需要缓冲，或者重排序的，如果缓冲太多帧会造成延迟。当然这个也有一个最大值，可以从 profile 算的，一般是 4 。 IPB 序列，需要缓冲的帧数一般是 4 ，或者2 。 H264 流里面应该指定，不过有的不标准的流不会指定，所以为了兼容，可能需要设置成最大值。

在H264 的标准文档中， E-6 表格也有介绍，其中 NumUnitsInTicks TimeScale 是可以算出流的帧率的，不过有的也是不准的，比如松下的摄像头算出来至于一半。

PPS中有这样的信息：

redundant_pic_cnt 对于属于基本编码图像的条带和条带数据隔离带应等于0。对于一个冗余编码图像的编码条带或编码条带数据隔离带的redundant_pic_cnt 的值应大于0。当redundant_pic_cnt 在比特流中不存在时，应推定其值为0。redundant_pic_cnt 的值应该在0 到127 范围内；每个冗余编码图像都有一个对应的基本编码图像；对于冗余编码图像的编码条带（或数据分割），其通过pic_parameter_set_id指定的图像参数集，必须与对应的基本编码图像的编码条带指定的图像参数集具有相同的pic_order_present_flag值；标准里在介绍这个元素时用了将近一页的篇幅，内容还挺多，不想过现在关于冗余图像的部分，还是先不要看了，越看脑子越乱，先大概知道有这么回事儿，等以后对H.264熟悉了再回来看也许就容易多了。

元素存在条件：

图像参数集中的redundant_pic_cnt_present_flag等于1（表示redundant_pic_cnt 语法元素将出现在条带头、图像参数集中指明（直接或与相应的数据分割块 A 关联）的数据分割块B 和数据分割块C 中）。对于数据分割，当这个条件符合时，不仅在A分割的码流中会出现redundant_pic_cnt（并不是直接出现，而是包含在分割A的片头结构中），还会在与之对应的B、C分割中也出现（直接出现）。

//********************可能导致解码丢帧的语法元素********************************************//

SPS中有这样的信息：

gaps_in_frame_num_value_allowed_flag等于0时，参考帧的frame_num都是连续的；如果等于1，这时若网络阻塞，编码器可以将编码后的若干图像丢弃，而不用另行通知解码器。在这种情况下，解码器必须有机制将缺失的frame_num 及所对应的图像填补，否则后续图像若将运动矢量指向缺失的图像将会产生解码错误。

//***********************************profile_idc 与 profile的关系***********************************//

表1 profile_idc 与profile的对应关系

      if (profile_idc == 100 ||  // High profile
            profile_idc == 110 ||  // High10 profile
            profile_idc == 122 ||  // High422 profile
            profile_idc == 244 ||  // High444 Predictive profile
            profile_idc ==  44 ||  // Cavlc444 profile
            profile_idc ==  83 ||  // Scalable Constrained High profile (SVC)
            profile_idc ==  86 ||  // Scalable High Intra profile (SVC)
            profile_idc == 118 ||  // Stereo High profile (MVC)
            profile_idc == 128 ||  // Multiview High profile (MVC)
            profile_idc == 138 ||  // Multiview Depth High profile (MVCD)
            profile_idc == 144)    // old High444 profile

在不借助任何工具的情况下，怎么通过码流中的数据简要的判断该帧的数据类型呢？以图1为例：

图1 码流中的一个数据片段

00 00 00 01 是Start code（起始码），后面的0x64转化为二进制则为 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支持的 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;

那么怎么简要判断该码流是属于哪种profile呢？以图1为例：

profile_idc的u(8)则是将00 00 00 01 67 64 中第6个位置的十进制数（64）转化为十进制数（100）后，在到表1中查找相应的profile。