H264解析：NALU结构与SPS、PPS详解-CSDN博客

本文链接：https://blog.csdn.net/dss875914213/article/details/123011670

获得 h264 文件

ffmpeg -i test.mp4 -codec copy -bsf: h264_mp4toannexb -f h264 test.264

概述

h264 数据是保存在 NALU 中的，但是 NALU 之间如何进行分割，常用的有两种方式，一种是 annexb模式，其通过在每个 NALU 前面加上 startcode (0x000001或0x00000001）分割 NALU。另外一种是AVCC模式，通过在 NALU 前面添加表示 NALU 长度的字节。
本文使用 annexb 模式分析 h264 格式
NALU 由 NALU header ， NALU 数据组成

NALU header

在这里插入图片描述
感觉这个图好奇怪，不是应该是 F 代表第 7 位吗？
F：
forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.
NRI：
nal_ref_idc. 取00~11,指示这个NALU的重要性,如00的NALU解码器可以丢弃它而不影响图像的回放,0～3，取值越大，表示当前NAL越重要，需要优先受到保护。如果当前NAL是属于参考帧的片，或是序列参数集，或是图像参数集这些重要的单位时，本句法元素必需大于0。
Type：
标识NAL单元中的RBSP数据类型，其中，nal_unit_type为1， 2， 3， 4， 5的NAL单元称为VCL的NAL单元，其他类型的NAL单元为非VCL的NAL单元。
列举一些重要的 Type
6 补充增强信息单元（SEI）
7 SPS
8 PPS

SEI 格式

· SEI payload type (该SEI遵循的语法)
· SEI payload size (该SEI所携带信息的长度)
这里我们只讨论SEI payloadType = 5的情况，即遵循user_data_unregistered()语法的SEI信息

· SEI payload uuid (SEI)
· SEI payload content
以及作为结尾的
· rbsp trailing bits (0x80)

SEI payload type 解析方式：持续读取8bit，直到非0xff为止，然后把读取的数值累加，累加值即为SEI payload type。
SEI payload size 同上
SEI payload uuid 主要是对下面 sei 的标识，可以使用 16 byte 标识，也可以使用 4 byte 表示
在这里插入图片描述
参考文献

h264 文件解析

h264 协议下载
在这里插入图片描述

该 NALU header 为 0x06 ，type 为6代表该 NALU 中保存的是 SEI，NRI 为 0，表示该 NALU 不重要，可以丢弃。
在这里插入图片描述
该 NALU header 为 0x67，type 为 7 代表该 NALU 中保存的是 SPS，NRI 为 3，表示该 NALU 重要，不能丢弃。

sps 每个参数的意思

在这里插入图片描述

sps 为 00 00 00 01 67 64 00 2a ac d9 40 78 02 27 e5 84 00 00 03 00 04 00 00 03 01 e0 3c 60 c6 58

参数名字	参数类型	值
profile_idc	u(8)	100 (100 High (FRExt) 参考)
constraint_set0_flag	u(1)	0(参考)
constraint_set1_flag	u(1)	0(参考)
constraint_set2_flag	u(1)	0(参考)
constraint_set3_flag	u(1)	0(参考)
constraint_set4_flag	u(1)	0(参考)
constraint_set5_flag	u(1)	0(参考)
reserved_zero_2bits	u(2)	0(参考)
level_idc	u(8)	42(4.2 (Supports 2Kx1K format. Frame coding only. 125829120 samples/sec)参考)
seq_parameter_set_id	ue(v)参考	1 对应的 codenum 为 0
chroma_format_idc	ue(v)	010 对应 codenum 为1
bit_depth_luma_minus8	ue(v)	1
bit_depth_chroma_minus8	ue(v)	1
qpprime_y_zero_transform_bypass_flag	u(1)	0
seq_scaling_matrix_present_flag	u(1)	0
log2_max_frame_num_minus4	ue(v)	1 对应的 codenum 为 0
pic_order_cnt_type	ue(v)	1 对应 codenum 为 0
log2_max_pic_order_cnt_lsb_minus4	ue(v)	011 对应 codenum 为 2
max_num_ref_frames	ue(v)	00101 对应 codenum 为4
gaps_in_frame_num_value_allowed_flag	u(1)	0
pic_width_in_mbs_minus1	ue(v)	0000001111000 对应的 codenum 为 119
pic_height_in_map_units_minus1	ue(v)	0000001000100 对应的 codenum 为 67
frame_mbs_only_flag	u(1)	1
direct_8x8_inference_flag	u(1)	1
frame_cropping_flag	u(1)	1
frame_crop_left_offset	ue(v)	1 对应 codenum 为0
frame_crop_right_offset	ue(v)	1 对应 codenum 为0
frame_crop_top_offset	ue(v)	1 对应 codenum 为0
frame_crop_bottom_offset	ue(v)	00101 对应 codenum 为4
vui_parameters_present_flag	u(1)	1
下面的其他数据是关于 vui_parameters，后面在补充

主要计算一下视频的宽和高
参考

width =  (pic_width_in_mbs_minus1+1) * 16; 
height = (2 - frame_mbs_only_flag) *(pic_height_in_map_units_minus1 +1) * 16;
if (frame_cropping_flag)
{
    unsigned int crop_unit_x; 
    unsigned int crop_unit_y;
    crop_unit_x = 2; 
    crop_unit_y = 2 * (2 - frame_mbs_only_flag);		编码图像为场时高度只在一侧进行裁剪

    width -= crop_unit_x * (frame_crop_left_offset +  frame_crop_right_offset);			左右裁剪
    height -= crop_unit_y * (frame_crop_top_offset +  frame_crop_bottom_offset); 		上下裁剪
}

width = (119+1)16-2(0+0) = 1920
height = (67+1)16-2(2-1)*(0+4) = 1080

pps 每个参数的意思

在这里插入图片描述

参考文献

https://blog.csdn.net/strikedragon/article/details/90108067
https://www.cardinalpeak.com/blog/the-h-264-sequence-parameter-set // 列举 sps 和 pps 每个的意思
https://www.pianshen.com/article/8566983403/ ue(v) 解释
https://blog.csdn.net/lizhijian21/article/details/80982403
https://blog.csdn.net/qq_40732350/article/details/89479040