H.264 NALU全面解析：从码流结构到FFmpeg实战

发布时间：2026/10/16 21:11:17
H.264 NALU全面解析：从码流结构到FFmpeg实战
1. 从码流角度看懂 H.264为什么必须理解 NALU做视频开发的人不管你是搞播放器、做流媒体服务、还是写音视频剪辑工具只要碰到 H.264有一个坎绝对绕不过去——NALU。我在第一次接触 H.264 裸流时直接拿十六进制编辑器打开一个 .264 文件看到满屏的00 00 00 01开头的数据块当时是懵的。等到把 NALU 的结构、类型、封装模式一点点啃明白之后再看码流就像看带目录的书每一段数据是什么角色、有多大作用、该往哪里放一目了然。这篇博文聚焦 H.264 格式分析中的核心部分网络抽象层单元 NALUNetwork Abstraction Layer Unit。我会从 NALU 的功能结构讲起把 VCL视频编码层和 NAL网络提取层的分工讲清楚再专门拆解 H.264 最常见的封装模式——annexb 模式。最后用 FFmpeg 实际验证这些理论让每一个概念都能在命令行里落地。无论你是初学者还是已经写了几年视频代码的开发者这几个知识点都是必须掌握的。初学者可以通过这篇文章建立起完整的码流认知框架有经验的开发者也可以借此查漏补缺——特别是 NALU 类型识别、SPS/PPS 的作用这些细节很多人平时就在用但未必能讲清楚原理。2. NALU 是什么H.264 码流的基本构成单元2.1 VCL 和 NAL视频编码层的“内容”与网络提取层的“容器”先从 H.264 的整体架构说起。H.264 编码器输出的东西内部逻辑上分为两层VCLVideo Coding Layer视频编码层负责处理视频内容本身包括帧内预测、帧间预测、变换、量化、熵编码等一系列操作最终产生的是真正的图像压缩数据比如切片 Slice 数据。NALNetwork Abstraction Layer网络提取层负责把 VCL 产生的数据打包成适合网络传输或存储的格式。它做的事情是把编码器输出的原始比特流按照语法规则分割、封装添加上必要的头部信息形成一个个独立的数据单元。这两层的关系可以类比成货物和集装箱。VCL 产生的是货物本身——图像压缩后的数据NAL 是集装箱——把货物装进去贴上标签头部信息让它可以被搬运、运输、识别。没有 NAL 的封装裸的 VCL 数据在网络传输中根本无法被识别和重组。正是由于这种分层设计H.264 才能同时适应多种应用场景既可以用于实时视频通话RTP 传输也可以用于本地文件存储MP4、MKV还可以用于广播电视TS 流。无论承载环境怎么变VCL 层的内容不需要改动只需要 NAL 层按照不同的封装格式做适配即可。2.2 NALU 的完整定义起始码 头部 负载NALUNetwork Abstraction Layer Unit网络抽象层单元就是 NAL 层操作的基本单位。一个完整的 NALU 由三部分构成NALU 组成部分作用说明起始码Start Code标记 NALU 的起始位置一般是00 00 00 014字节或00 00 013字节4字节主要用于流起始、SPS、PPS、IDR 等关键帧前NAL HeaderNAL 头描述该 NALU 的类型和属性固定为 1 字节包含 forbidden_zero_bit、nal_ref_idc、nal_unit_type 三个字段RBSPRaw Byte Sequence Payload实际的负载数据原始字节序列载荷VCL 类型的 NALU 装载切片数据非 VCL 类型装载参数集等信息在 annexb 模式下每个 NALU 前面都必须有起始码。而且要注意起始码不属于 NALU 本身——它是附加上去的分隔符。真正属于 NALU 的是从 NAL Header 开始到 RBSP 末尾的所有字节。这里有个初学者容易混淆的点起始码不是只有一种长度。编码器在输出时00 00 00 014字节多用于关键位置00 00 013字节则常见于普通切片。解码器在扫描码流时只要找到00 00 01这个模式就会被认定为起始码前面多出来的那个00是为了避免与更长的起始码冲突属于防竞争字节的一部分。通俗来说4字节起始码是严打状态保证绝对不产生歧义3字节起始码是常规状态节省那 1 个字节的码率开销。在解码器里判断起始码是通过逐字节扫描实现的检测到连续两个0x00后跟一个0x01就说明找到了 NALU 的边界。所以禁止在负载数据中出现00 00 01这个模式否则解码器会误判。为了解决这个问题H.264 引入了防竞争机制——在编码端遇到连续的00 00 01或00 00 02、00 00 03时会在第三个字节前插入一个0x03解码端看到00 00 03则自动删除第三个字节。这个机制在分析码流时经常能看到要提醒自己这是正常现象不是数据损坏。2.3 NAL Header 逐位拆解读懂第 1 个字节NALU 的第一个字节是它的身份证。这一字节的 8 个 bit 被分成三个字段forbidden_zero_bitF 位1 bit必须为 0。如果发现是 1说明码流可能已经损坏解码器通常要丢弃这个 NALU。nal_ref_idcNRI 位2 bit表示该 NALU 的优先级取值范围 0~3。值越大说明越重要。典型场景SPS、PPS、IDR 切片的 nal_ref_idc 通常不等于 0非参考图像的优先级可以为 0。这个字段在丢包策略里很有价值——网络拥塞时优先丢 nal_ref_idc 为 0 的 NALU保住关键帧。nal_unit_typeType 位5 bit表示 NALU 的具体类型取值范围 0~31。这个是分析码流时最常看的字段。比如一个 NALU 的第一个字节是0x67转成二进制就是0110 0111拆开来看F 位 0nal_ref_idc 3二进制11nal_unit_type 7二进制00111类型为 7就是 SPS。如果看到0x68类型就是 8即 PPS。看到0x65类型为 5即 IDR 切片。这些十六进制数值在 FFmpeg 输出或者十六进制编辑器里经常出现记住几个常用值能极大提高分析效率。2.4 常见 NALU 类型速查表nal_unit_type类型名称中文含义说明1非 IDR 切片Non-IDR Slice普通编码帧的切片承载 P 帧、B 帧的压缩数据5IDR 切片IDR Slice关键帧切片立即刷新参考帧解码器从这里开始可以完整解码6SEI补充增强信息携带字幕、时间戳等辅助信息可有可无7SPS序列参数集编码全局参数分辨率、帧率、档次级别等8PPS图像参数集编码图像参数熵编码模式、切片组配置等9AUD访问单元分隔符标记一个访问单元一帧画面的开始这里要特别强调 SPS 和 PPS 的关键作用。解码器拿到一个 H.264 码流第一步就是找 SPS 和 PPS。没有这两个参数集后续的切片数据根本无法解析——不知道分辨率、不知道熵编码方式、不知道参考帧数量图像就是一团乱码。所以在封装成 MP4 时SPS 和 PPS 会被提取出来放到avcCbox 中在 annexb 裸流中它们则作为独立的 NALU 出现在关键帧前面。这种两种封装模式的差异我们下一节详细说。3. annexb 模式全面拆解H.264 最经典的封装方式3.1 annexb 模式的定位裸流与传输场景的最爱H.264 标准定义了两种 NALU 封装格式Annex B和AVCC也称 Length-Prefixed。两者的核心区别在于怎么知道每个 NALU 从哪开始、到哪结束。Annex B 模式用起始码Start Code来分隔 NALU格式是[起始码] [NALU] [起始码] [NALU] ...。AVCC 模式在每个 NALU 前面加一个长度字段通常 4 字节格式是[长度] [NALU] [长度] [NALU] ...。为什么会存在这两种模式因为使用场景不同。Annex B 是 H.264 标准的原生格式由于起始码的存在可以很方便地在码流中做字节扫描定位特别适合流媒体传输比如 RTP 打包、TS 流承载。MP4、MKV 这类文件格式则更倾向于 AVCC因为文件内部需要随机访问用长度字段定位更高效不需要逐字节扫描。举一个实际例子你在做 RTSP 直播时拉到的 H.264 数据流几乎清一色是 Annex B 格式。因为流媒体场景要求解码器能够随时从任意位置接入起始码可以快速完成 NALU 同步而 MP4 文件的 moov box 中直接写明了每个 sample 的偏移量和大小用 AVCC 更合适。FFmpeg 转码时如果你手动指定h264_mp4toannexb这个 bitstream filter本质就是在做这两种模式的转换。3.2 一帧画面由哪些 NALU 组成理解了 NALU 类型之后我们把视角拉到一帧画面的维度。在 annexb 模式中一帧完整的图像访问单元Access Unit的组织方式是这样的[起始码] [AUD NALU] 可选标记帧开始 [起始码] [SPS NALU] 可选仅 IDR 帧前出现 [起始码] [PPS NALU] 可选仅 IDR 帧前出现 [起始码] [SEI NALU] 可选携带补充信息 [起始码] [IDR/非IDR切片 NALU] 真正的图像压缩数据如果这是第一帧 IDR 帧关键帧通常前面带着 SPS 和 PPS这样解码器才能从头开始解码。如果是后续的 P 帧或 B 帧往往只有切片类型的 NALU可能连着同一个 slice 被拆成多个 NALU 的情况多切片编码。实际解析时我发现很多人把 VCL 和 NAL 的概念混淆。这里再强调一下NAL 层负责把所有数据都打包成 NALU——不管是 SPS、PPS 这类元数据还是真正的图像压缩数据在 NAL 层看来都是一个个 NALU。区别只是类型不同类型 1/5 是 VCL 类型的 NALU里面装的是切片压缩数据类型 6/7/8/9 是非 VCL 类型的 NALU装的是辅助信息或参数集。VCL 和 NAL 不是两种数据而是同一个数据在编码过程中所处的不同逻辑层级。3.3 起始码后的防竞争机制详解上面提到过防竞争字节插入这里展开说一下因为实际解析 raw h264 文件时一定会碰到它看不懂会以为是编码器出了问题。H.264 标准规定在 RBSP 数据内部不允许出现连续的模式00 00 01或00 00 02或00 00 03。因为前两个可能是起始码序列的关键部分后者可能造成 NALU 边界的误判。编码器在做完熵编码、生成 RBSP 之后会对数据逐字节检查检测到连续两个0x00时检查第三个字节如果第三个字节是0x00、0x01、0x02、0x03中的任意一个就在该字节前插入0x03。解码器拿到 NALU 后做反向操作遇到00 00 03就丢弃中间的03还原出真实的 RBSP 数据。举例假设压缩数据中有一段是00 00 01 A0 32码流中实际存储的是00 00 03 01 A0 32。如果你用 hexdump 查看 .264 文件看到00 00 03这种序列不用担心这是正常的防竞争机制原始数据并没有损坏。3.4 annexb 与 AVCC 模式对比什么时候用哪种对比维度Annex BAVCCNALU 分隔方式起始码3或4字节可变长长度字段通常4字节定长码流定位方式逐字节扫描查找起始码读取长度字段后精确跳转SPS/PPS 存放作为 NALU 嵌在码流中存放在容器头部如 MP4 的 avcC box典型应用TS 流、RTP 实时传输、HLS 切片MP4、MKV、FLV 等文件容器随机访问效率相对低要扫描高直接跳转码流冗余每 NALU 多出 3~4 字节起始码每 NALU 多出 4 字节长度实际工作中最常见的转换场景出现在当你要把封装在 MP4 里的 H.264 视频转到流媒体协议上播放时。MP4 内部是 AVCC 封装SPS/PPS 藏在容器元数据里码流中并没有起始码而 RTSP 或 TS 流必须用 Annex B。FFmpeg 里用-bsf:v h264_mp4toannexb就可以完成转换它会自动提取 MP4 里的 SPS/PPS并把它作为 NALU 插入到码流中同时把长度字段替换为起始码。4. FFmpeg 实操解析 H.264 裸流中的 NALU4.1 准备一段 H.264 裸流理论说了这么多现在上手操作。我们先准备一段 H.264 裸流文件。如果你手上没有现成的 .264 文件可以用 FFmpeg 自己生成# 用 FFmpeg 生成 100 帧的测试视频编码为 H.264输出 annexb 格式的裸流 ffmpeg -f lavfi -i testsrcsize640x480:rate30 -t 3 -c:v libx264 -profile:v baseline -level 3.0 -pix_fmt yuv420p -f h264 test.h264关键点是输出格式指定为-f h264。FFmpeg 默认把 H.264 输出封装为 MP4而这里我们需要的是裸流所以强制指定为 h264 格式出来的就是 annexb 封装模式的原始码流。查看生成文件的大小和头部信息# 查看文件大小 ls -l test.h264 # 查看文件头部的二进制内容 xxd test.h264 | head -20成功的话打开文件应该能看到0000 0001开头的字节序列这印证了上面讲的起始码结构。4.2 提取并识别每一个 NALU 的类型取一段 H.264 裸流文件用 FFmpeg 自带的工具解析 NALU。首先用 ffprobe 查看流的基本信息ffprobe -v error -show_streams -select_streams v:0 test.h264输出里找这几个关键的键值对codec_nameh264确认视频编码格式profileBaseline编码档次width640、height480分辨率信息这些数据实际是从 SPS 中解析出来的然后我们需要一个能逐 NALU 分析的方案。最直接的办法是 FFmpeg 提供的 trace 头信息# 输出 H.264 码流的详细解析信息包括每个 NALU 的位置和大小 ffmpeg -v trace -i test.h264 -f null - 21 | grep nal这段命令会输出大量的日志信息一条条看可能头晕。更实用的方法是写一段简短的 Python 脚本手动解析 NALUimport struct def analyze_h264_nalus(filepath): with open(filepath, rb) as f: data f.read() # 查找所有 NALU 的起始位置 nalu_positions [] i 0 while i len(data) - 3: if data[i] 0 and data[i1] 0 and data[i2] 1: nalu_positions.append((i, 3, 00 00 01)) i 3 elif data[i] 0 and data[i1] 0 and data[i2] 0 and data[i3] 1: nalu_positions.append((i, 4, 00 00 00 01)) i 4 else: i 1 # 解析每个 NALU for j, (start, sc_len, sc_type) in enumerate(nalu_positions): # 计算 NALU 数据范围不含起始码 nalu_start start sc_len nalu_end nalu_positions[j1][0] if j1 len(nalu_positions) else len(data) nalu_data data[nalu_start:nalu_end] if len(nalu_data) 0: continue header_byte nalu_data[0] nal_ref_idc (header_byte 5) 0x03 nal_unit_type header_byte 0x1F type_names { 1: 非IDR切片(Slice), 5: IDR切片(IDR Slice), 6: SEI, 7: SPS, 8: PPS, 9: AUD } name type_names.get(nal_unit_type, f类型{nal_unit_type}) print(fNALU {j:3d}: 位置{start:8d} 起始码{sc_type} f长度{len(nalu_data):6d} 类型{nal_unit_type:2d} {name} fnal_ref_idc{nal_ref_idc}) print(f\n共 {len(nalu_positions)} 个 NALU) analyze_h264_nalus(test.h264)运行这段脚本应该能看到清晰的 NALU 列表。正常的一段 H.264 编码 TS测试序列通常输出的 NALU 类型是 7SPS、8PPS、5IDR、1非 IDR。而且你会注意到 SPS 和 PPS 通常只在开头出现一次或者每个 IDR 帧前出现一次取决于编码器的 GOP 设置。4.3 使用 ffprobe 验证关键帧间隔GOPNALU 识别的直接应用场景是看视频流的关键帧间隔。我们把 GOPGroup of Pictures理解为“两个关键帧之间相隔多少帧画面”。关键帧有时也叫 IDR 帧在 H.264 中对应 NALU 类型 5。用 FFmpeg 查看每个关键帧的位置ffprobe -v error -select_streams v:0 -show_frames -show_entries framekey_frame,pict_type,pkt_pos,pkt_size -of csv test.h264输出类似这样frame,0,1,I,294,18264 frame,1,0,P,18558,3624 frame,2,0,P,22182,3541 ...第三列1表示该帧是关键帧0表示非关键帧。第四列I表示 I 帧即 IDRP表示 P 帧。这是从 NALU 层面验证关键帧间隔是否合理的一个很直接的手段。对于视频点播场景GOP 过大比如超过 10 秒会导致用户拖拽进度条时等待时间变长因为播放器必须等下一个 IDR 帧才能开始渲染。做流媒体时我更关注 ffmpeg 转码命令中的-g参数它就是用来设定 GOP 大小的——也就是每隔多少帧插入一个 IDR 帧。4.4 H.264 两种封装模式转换实战实际业务中把 MP4 里的 H.264 转成 annexb 裸流是高频操作。用 FFmpeg 的 bitstream filter 一行搞定# 从 MP4 文件提取 H.264 裸流annexb 模式 ffmpeg -i input.mp4 -c copy -bsf:v h264_mp4toannexb output.h264参数解释-c copy不重新编码直接拷贝原始数据速度快-bsf:v h264_mp4toannexb对视频流应用 bitstream filter把 AVCC 格式的 NALU 转换为附带有起始码的 Annex B 格式转换完成后用上面写的 Python 脚本解析 output.h264你会看到 SPS 和 PPS 作为 NALU 出现在码流里了——这就是 AVCC 转到 Annex B 最明显的标志。再做一个反向的例子。把 annexb 裸流转成 MP4# 从 H.264 裸流封装成 MP4 ffmpeg -i test.h264 -c copy output.mp4这个操作会触发 FFmpeg 自动做 annexb 到 AVCC 的转换SPS 和 PPS 会被提取出来写入 MP4 的 avcC box而 NALU 前面的起始码会被替换为 4 字节的长度字段。封装完以后再用 ffprobe 验证ffprobe -v error -show_entries streamcodec_name,width,height,pix_fmt,profile,level output.mp4这个过程是理解封装格式之间差异的最好实践。很多流媒体服务的转封装服务原理都在于此。5. 实践中的坑H.264 NALU 解析常见问题与排查5.1 问题一SPS/PPS 缺失导致花屏或解码失败现象播放器播放某段 H.264 裸流时画面一开始是花屏的播放几秒后才恢复正常。或者解码器直接报错。原因码流中缺少 SPS 或 PPS NALU解码器只能等到下一个 IDR 帧携带参数集才能正常解码。排查方法# 统计裸流中 SPS 和 PPS 的数量 python3 analyze_h264_nalus.py test.h264 | grep -E SPS|PPS如果SPS数量明显少于IDR数量就有问题。正常情况每个 IDR 帧前至少有一组 SPS/PPS。如果整个文件只有开头有 SPS/PPS后面带了多个 IDR 帧那后续的 IDR 帧解码会遇到麻烦。解决方案重新编码时强制每个 IDR 前加 SPS/PPS。用 FFmpeg 的x264opts参数ffmpeg -i input.mp4 -c:v libx264 -x264opts keyint250:min-keyint25:scenecut40 -x264-params repeat-header1 -f h264 output.h264repeat-header1强制编码器在每个关键帧前重复输出 SPS/PPS。做流媒体时这一步能大幅提高播放器的兼容性。5.2 问题二00 00 03被误认为数据错误现象新手用十六进制编辑器查看 .264 文件看到里面的00 00 03字节序列认为文件编码损坏。原因这是 H.264 标准的防竞争机制不是数据错误。解码器内部会自动去掉这个03字节。排查方法解析 NALU 时不应该直接跳过00 00 03序列而应该在解码层面处理。如果是自己写的简单解析器需要实现 EPBemulation prevention byte移除逻辑def remove_epb(data): result bytearray() i 0 while i len(data): if (i 2 len(data) and data[i] 0 and data[i1] 0 and data[i2] 3): result.extend([data[i], data[i1]]) # 保留两个 00 i 3 else: result.append(data[i]) i 1 return bytes(result)心得在写自己的 H.264 解析工具时一定要把 EPB 移除放在 RBSP 解析的前一步否则得到的参数内容比如 SPS 里的分辨率数值会是错误的。5.3 问题三多切片编码导致一帧对应多个 NALU现象解析码流时发现一个 IDR 帧对应了多个nal_unit_type5的 NALU误以为是多个关键帧。原因H.264 允许把一帧图像切分成多个 slice切片每个 slice 是一个独立的 NALU。IDR 帧的多个切片 NALU 类型都是 5但它们属于同一帧。现代编码器默认不开多 slice但某些特定配置比如为了 MTU 限制会开启。排查方法判断是否为同一帧需要结合 POCPicture Order Count或 frame_num 字段这些字段存在于 slice header 中单纯看 NALU 类型不够。解决方案对大多数视频处理场景不需要特殊处理。如果你要基于 NALU 做帧级别的切片比如 HLS 分片需要额外解析 slice header 来判断一帧的边界。使用 FFmpeg 的h264_metadata或h264_slicebitstream filter 可以控制 slice 数量# 强制每帧只生成一个 slice如果编码器支持 ffmpeg -i input -c:v libx264 -x264opts slices1 output.mp45.4 问题四NALU 边界识别错误现象自己写的解析器在扫描 NALU 起始码时总是多个 NALU 串在一起或者把负载中的00 00 01当成了起始码。原因没有处理防竞争字节。RBSP 内部在编码时已经禁止出现00 00 01、00 00 02、00 00 03模式但你直接扫描原始文件字节流理论上负载中不该出现这些序列。如果你的解析器依然出错问题多半出在起始码扫描逻辑上——你没有先移除防竞争字节导致负载内部出现了被03分隔的假起始码序列。排查方法检查负载数据中是否存在00 00 03 01。如果存在说明你扫到了 EPB 字节。标准的起始码00 00 01前面应该没有多余字节除了可能额外的00构成 4 字节起始码。解决方案在分割 NALU 时直接用正则表达式在原始字节流上匹配\x00\x00\x01和\x00\x00\x00\x01即可。注意EPB 插入后负载中不会出现连续的00 00 01所以这种匹配是安全的。我用的 Python 脚本就是基于这个原理。5.5 问题五AUD NALU 的作用与实际取舍现象某些码流每帧开头有nal_unit_type9AUD的 NALU某些码流没有播放器都能正常工作所以不确定这个东西到底干嘛的。原因AUDAccess Unit Delimiter是访问单元分隔符用来标记一帧数据的开始。它属于可选数据。官方规范没有强制要求所以编码器默认不会输出。排查方法# 查看码流中是否包含 AUD ffprobe -v trace -i test.h264 21 | grep AccessUnitDelimiter | head -10心得AUD 不是必须的。但如果你的码流是用于广播级传输或需要严格帧边界对齐的场景加上 AUD 有助于解码器精确判断帧起始位置能够提高容错能力。用 FFmpeg 添加 AUD 可以这样做ffmpeg -i input.mp4 -c:v libx264 -x264-params aud1 output.h2645.6 问题六nal_ref_idc 在封装转换中丢失现象从 MP4 转成 annexb 模式后用解析工具查看 NALU 头发现某些 NALU 的 nal_ref_idc 字段变了。原因FFmpeg 在做h264_mp4toannexb转换时不会篡改 NALU 头部字节字段本身不会变。但如果你用不同工具对比的是文件封装层面的元数据比如某些工具从 MP4 里读出的参数等级信息和裸流里的 NALU 头信息是两码事。要注意区分。排查方法直接用十六进制对比转换前后的 NALU 头字节即可。如果对不齐需要考虑是不是转换前的 MP4 本身就有问题码流或者封装工具做了修正。6. FFmpeg 在 H.264 码流排查中的几个高频用法这部分是我平时工作中最常用到的 FFmpeg 命令组合针对不同的排查场景做一个整理方便直接复制使用。6.1 快速查看 H.264 码流关键参数ffprobe -v error -show_streams -select_streams v:0 -show_entries streamprofile,level,width,height,pix_fmt,r_frame_rate,bit_rate test.h264输出中profile和level直接来自 SPS能快速判断这个码流的档次和级别。做兼容性排查时这两个字段基本是第一眼要看的东西。6.2 找出码流中的所有 SPS/PPSffmpeg -v trace -i test.h264 -f null - 21 | grep -E sps|pps | head -20看到输出中每个 SPS/PPS 的偏移量和大小配合十六进制编辑器就能定位到具体的字节位置深入检查参数内容。6.3 检查是否有损坏的 NALU# 让 FFmpeg 强制解码观察错误日志 ffmpeg -v error -i test.h264 -f null - 21 | grep -E error|Invalid|corrupt | head -20如果出现error while decoding MB或者corrupt macroblock这类日志说明码流中有损坏的 NALU。这时可以用前面写的 Python 脚本逐 NALU 定位找到问题数据的具体位置。6.4 H.264 转封装修复缺失的起始码有些从网络抓包或者老旧工具产出的 H.264 码流NALU 之间没有起始码。可以用 FFmpeg 修复# 一些老旧流媒体工具产出的 H.264 没有标准起始码用 h264_mp4toannexb 处理 ffmpeg -i input.264 -c copy -bsf:v h264_mp4toannexb output_fixed.264注意如果输入数据本身是 ES 流Elementary StreamFFmpeg 也能解析但最好还是先确认输入码流的封装格式。6.5 分析 SPS 中的分辨率变化当视频流中途分辨率变了多分辨率拼接播放器可能会花屏。用 FFmpeg 查看每一帧的实际分辨率ffprobe -v error -select_streams v:0 -show_frames -show_entries framewidth,height -of csv test.h264如果宽度、高度列中途发生了变化说明码流中出现了新的 SPS。按时间轴定位后可以找到切换点前后的 NALU进而判断是否属于异常切换。7. 阶段性总结与我的个人经验回到文章开头的问题——为什么要花这么大力气把 NALU 搞明白因为 H.264 是整个视频生态的基石而 NALU 是理解 H.264 码流的钥匙。VCL 决定了视频内容的压缩效率NAL 决定了这些内容能不能被正确传输、存储、定位和重组。搞不懂 NALU你连00 00 01和00 00 00 01为什么要混合出现都说不清楚。以我多年做视频处理和流媒体开发的经验以下几个点特别值得提醒第一不要轻视 SPS 和 PPS。它们在 annexb 模式下就是两个普通的 NALU但承载的是整个视频流的“宪法”。做封装转换时如果 SPS/PPS 处理不当后续救起来极其痛苦。建议在写任何 H.264 相关工具时把 SPS/PPS 解析模块放到最前面——它们是排错的第一突破口。第二调试 H.264 码流要有“分层排查”的意识。第一层看 NALU 类型是否正常SPS/PPS 是否存在、关键帧间隔是否合理第二层看 NALU 内部语法是否符合规范需要借助解析工具看 SPS 里是否写了个异常的分辨率第三层才看像素数据本身是否损坏。绝大多数问题在前两层就能定位。第三FFmpeg 用熟了要往里面走一层。会敲命令只是最基础的我建议你把本篇文章里 Python 解析 NALU 的脚本自己写一遍、跑一遍把00 00 00 01和00 00 01的区别、nal_ref_idc和nal_unit_type的位运算逻辑吃透。这一步做完你再看 FFmpeg 的日志输出、bitstream filter 的原理、h264 相关的源码都会有豁然开朗的感觉。第四尽量构建一个标准的 H.264 样本库。我平时会刻意保留几套配置不同的 H.264 测试流Baseline 级别、Main 级别、High 级别Keyframe 短间隔、长间隔带 AUD、不带 AUD。每次处理客户问题或者验证新工具时先用这些样本跑一遍对照能省很多排查时间。这篇文章聚焦在 NALU 和 annexb 模式的理论与实践下一篇我准备深入 SPS 的二进制细节——从 NALU 类型 7 的 RBSP 中一步步解析出profile_idc、level_idc、pic_width_in_mbs_minus1等字段到时候你会真正感受到“手撕 H.264 二进制”的快感。如果你在阅读或实践中有任何问题欢迎随时交流。