RTSP Inspector (RTSP 巡检官) logo RTSP Inspector (RTSP 巡检官) RTSP 流媒体诊断

2026-06-02

H.264 FU-A RTP 分片修复——RTSP 视频损坏（丢包、NAL 重组）

修复 H.264 FU-A RTP 碎片中损坏的 RTSP 视频。使用真实的诊断命令涵盖丢失的片段、开始/结束位错误、NAL 重组失败、数据包丢失、MTU 和解码器错误。

h264 fu-a, RTP 碎片, rtsp视频, 丢包, 最终单元重新组装, h264解码器错误, rtsp诊断

H.264 over RTP 的中断看起来像是解码器错误，但实际上是分组问题。 RTSP 会话有效。 DESCRIBE 返回有效的 SDP。设置成功。 PLAY 返回 200 OK。 RTP 数据包到达时带有映射到 H.264 的正确负载类型。尽管如此，视频仍显示块损坏、冻结、黑帧或解码器错误。

错误在日志中如下所示：

[h264 @ 0x...] invalid NAL unit size
[h264 @ 0x...] missing picture in access unit
[h264 @ 0x...] non-existing PPS 0 referenced
[h264 @ 0x...] decode_slice_header error
[h264 @ 0x...] no frame!

The fast answer

Why fragmentation exists

The structure of an FU-A packet

Each FU-A RTP packet contains:

Byte 0: FU indicator
  bit 7: F (forbidden_zero_bit) — normally 0
  bits 6-5: NRI (nal_ref_idc) — priority
  bits 4-0: Type = 28 (FU-A)
Byte 1: FU header
  bit 7: S (Start) — 1 for first fragment
  bit 6: E (End) — 1 for last fragment
  bit 5: R (Reserved) — always 0
  bits 4-0: Type — original NAL unit type (1=non-IDR, 5=IDR, 7=SPS, 8=PPS)
Byte 2+: Fragment payload — the actual NAL unit data

一个 NAL 单元的完整 FU-A 序列：

Packet 1: FU indicator (type=28) | FU header (S=1, E=0, type=5) | payload[0..N]
Packet 2: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[N+1..M]
Packet 3: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[M+1..P]
Packet 4: FU indicator (type=28) | FU header (S=0, E=1, type=5) | payload[P+1..END]

The RTP marker bit

Failure modes: what breaks and why

Failure 1: Missing middle fragment

Expected:  1000(S)  1001(M)  1002(M)  1003(E|marker)
Received:  1000(S)  1001(M)  [LOST]   1003(E|marker)

重组器看到一个开始片段，一个中间片段，然后一个结束片段 - 但有效负载字节没有连接。重新组装的NAL单元有间隙。

症状：

  • 阻止帧水平带中的损坏
  • 解码器报告“无效的 NAL 单元大小”
  • 损坏仅限于一个访问单元（在下一个 IDR 时清除）

失败2：缺少起始片段

Expected:  1000(S)  1001(M)  1002(E)
Received:  [LOST]   1001(M)  1002(E)

Failure 3: Missing end fragment

Expected:  1000(S)  1001(M)  1002(E|marker)
Received:  1000(S)  1001(M)  [LOST]

重组器永远看不到结束片段。 NAL 单元边界从未得到确认。解码器等待更多从未到达的数据。

症状：

  • 视频冻结
  • 解码器报告“访问单元中缺少图片”
  • 播放停止，直到下一个完整的访问单元到达

失败4：碎片乱序

Expected:  1000(S)  1001(M)  1002(E)
Received:  1000(S)  1002(E)  1001(M)

Diagnostic workflow

Step 1: Confirm H.264 payload mapping

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=...
  • packetization-mode=1 表示非交错模式（支持 FU-A）
  • packetization-mode=0 表示单个 NAL 单元模式（无碎片 - 非常有限）

第 2 步：跟踪 RTP 序列号

在您的捕获中，查看视频轨道的 RTP 序列号。间隙表示数据包丢失：

Seq 1000: FU-A Start, NAL type 5 (IDR)
Seq 1001: FU-A middle
Seq 1003: FU-A End, marker=1   ← gap at 1002

Step 3: Inspect FU-A headers

Byte 0 (FU indicator):
  0x7C = NRI=3, Type=28 (FU-A)

字节 1（FU 标头）：
  0x85 = S=1, E=0, R=0, Type=5 (IDR 切片) ← IDR 的起始片段
  0x45 = S=0, E=0, R=0, Type=5 ← 中间片段
  0x65 = S=0, E=1, R=0, Type=5 ← 结束片段；仅当该 NAL 同时结束访问单元时设置标记

寻找错误的值：

  • 非启动数据包上的 S=1 → 重组器混乱
  • 在 E=1 之前设置标记 → 产生错误的访问单元边界
  • 若后面还有其他 NAL 单元，E=1 且未设置标记也可能完全正确
  • 类型在序列中更改 → 编码器错误或流损坏

第 4 步：验证重新组装是否完成

对于每个 NAL 单元： 1.找到起始片段（S=1） 2. 遵循连续的序列号，直到结束片段（E=1） 3. 计数碎片；验证没有序列间隙 4. 将标记与访问单元边界对照；不要要求每个 FU-A 结束片段都带标记 5. 验证所有片段具有相同的时间戳和 NAL 类型

第 5 步：比较运输方式

通过 UDP 和 TCP 交错运行相同的流。如果 TCP 上的视频是干净的，但 UDP 上的视频已损坏，则问题是网络数据包丢失，而不是编码器或解码器问题。

第 6 步：IDR 与非 IDR 分析

IDR 帧较大，每个 NAL 单元需要更多 FU-A 片段。更多碎片=更多丢包风险。如果损坏主要出现在场景变化时或每隔几秒（在 IDR 间隔），则 IDR 帧就是受害者。

修复选项：

  • 降低 IDR 帧大小（降低关键帧的分辨率或比特率）
  • 增加 IDR 间隔（减少大帧，但丢失恢复速度较慢）
  • 减少编码器处 FU-A 的 MTU（更多碎片，但每个碎片更小，不太可能触发 IP 碎片）

恢复策略

在重组器处

  • 完全丢弃损坏的访问单元，而不是向解码器提供部分数据
  • 通过 RTCP 请求新的 IDR 帧（如果相机支持）
  • 等待下一个IDR帧（解码器将自动恢复）

在编码器处

  • 降低 NAL 单元大小限制以减少每个访问单元的片段
  • 使用定期帧内刷新而不是完整的 IDR 帧（较小的关键帧）
  • 如果 RTP 堆栈支持，则启用 FEC（前向纠错）

在网络上

  • 如果数据包丢失不可避免，则从 UDP 切换到 TCP 交错
  • 确保路径 MTU 发现有效（避免 IP 碎片）
  • 优先考虑拥塞链路上的 RTP 流量

当不是 FU-A 时

并非所有 H.264 损坏都是 FU-A 碎片。查看：

  • SPS/PPS 缺失： 解码器错误，例如“不存在的 PPS” - 检查 SDP sprop-parameter-sets
  • **错误的配置文件/级别：**解码器无法处理流复杂性
  • 编码器错误： 编码器产生无效的 NAL 单元语法
  • 源头比特流损坏： 摄像机的编码器损坏，而不是网络损坏

如果 RTP 数据包以完美的序列号和正确的 FU-A 标头到达，但解码器仍然失败，则问题出在 H.264 比特流本身，而不是传输。

<!-- rtsp-localized-evidence-foundation-v1:start -->

“H.264 FU-A RTP 分片修复——RTSP 视频损坏（丢包、NAL 重组）”的可复现实证流程

直接答案是：黑屏或单个状态码不能证明故障归属。可靠诊断必须把 RTSP 请求与响应、协商后的 Transport、有效 Session，以及后续 RTP 序列号、时间戳和 RTCP 证据放进同一条时间线。处理“H.264 FU-A RTP 分片修复——RTSP 视频损坏（丢包、NAL 重组）”时，可以从最接近可见症状的层开始，但不能把控制层、网络路径和解码器问题混成一个结论。

修改摄像机、防火墙或 VMS 前，先建立一份小型基线。记录隐藏密码后的 RTSP URL、测试时间、路径、请求的 Transport、服务器响应和首个媒体包到达时间。设备同时支持 UDP 与 TCP interleaved 时，应分两次测试。不要在同一次实验里同时更换路径、凭据和传输模式，否则第二次成功也无法说明哪项变化真正修复了问题。

检查层 必须保存的证据 决策问题
RTSP 方法、状态、头字段、CSeq、Session 服务器是否接受了这一项操作
SDP control、payload type、clock rate、codec 服务器描述的是否为目标媒体轨
Transport client_port、server_port、interleaved 两端是否使用同一条媒体通道
RTP SSRC、sequence、timestamp、marker 媒体单元是否按可解释顺序到达
RTCP sender report、CNAME、BYE 时钟、身份和结束事件能否关联
解码器 SPS/PPS/VPS、packetization mode 已到达的 payload 能否完成初始化

始终区分“媒体没有到达”和“媒体到达但无法解码”。SETUP 与 PLAY 成功后仍无 RTP，应检查 UDP 路径、NAT、防火墙和不匹配的 Transport 响应。RTP 序列出现缺口，证明存在丢包或重排。序列连续却仍无画面，则应转向 payload type、clock rate、帧边界以及 H.264/H.265 参数。这个边界比播放器的笼统错误更能确定下一位修复责任人。

怎样写出可直接引用的答案

用三句话写明最后成功的操作、第一项失败证据和下一项区分实验。例如：“DESCRIBE、SETUP 与 PLAY 均成功；客户端声明的端口没有收到 RTP；改用 TCP interleaved 可区分 UDP 被阻断和媒体路径错误。”没有响应或数据包证据时，不要直接宣称整台摄像机或整段网络已经损坏。

最小复现资料包括什么

保存 OPTIONS、DESCRIBE、SETUP、PLAY、SDP、Transport 响应和脱敏后的 Session。媒体侧至少记录 SSRC、首尾序列号、clock rate、缺口数量和抓取时长。VLC 或另一套 VMS 的成败可以作为差异实验，但不能证明成功客户端正确处理了所有协议边界。

什么时候检查服务器，什么时候检查客户端

服务器明确拒绝方法、返回不存在的 control URL、回复不兼容 Transport，或无说明地改变 SSRC/时钟时，应先检查服务器。客户端重复过期 nonce、遗漏 Session、请求 UDP 却没有开放端口，或把每个 NAL 结尾都当成 access unit 结尾时，应先检查客户端。故障位于中间路径时，每个结论都必须附带数据包与时间。

交付报告前怎样复核

从新连接重新测试，只比较两条时间线的第一个差异。删除密码和完整 Authorization 值，把每项结论关联到 CSeq、sequence 或 timestamp。继续查看相关 RTSP 指南，并用 RTSP Inspector在本地测试 RTSP 流和收集证据，无需把摄像机视频上传到公共服务。

<!-- rtsp-localized-evidence-foundation-v1:end --><!-- rtsp-localized-layer-verdicts-v1:start -->

从观察记录到可复核的分层结论

处理“H.264 FU-A RTP 分片修复——RTSP 视频损坏（丢包、NAL 重组）”时，先写观察，再写解释。观察必须能由另一位工程师在抓包中重新找到，例如带 CSeq 的 RTSP 状态、SDP 字段、Transport 响应、序列号缺口、SSRC 变化，或 RTP timestamp 与 RTCP sender report 的对应关系。“服务器很慢”或“编码不兼容”只是待验证假设，直到具体证据能比其他原因更好地解释结果。

把链路拆成边界。先确认 TCP 建立，再确认 OPTIONS 或 DESCRIBE 被接受；SDP 必须描述可用媒体轨、control URL、payload type 和 clock rate；SETUP 需要兼容的 Transport，PLAY 需要有效 Session。之后才检查 RTP 到达、顺序、时间和解码器准备。停在第一项缺少成功证据的边界，不要让后续数据掩盖前序缺口。

做对照实验时，尽量固定来源和时间区间。UDP 与 TCP interleaved 使用相同路径和凭据；main stream 与 sub stream 使用相同客户端和传输模式；比较 VLC 与 VMS 时，记录双方真实发送的方法、头字段和 URL。control URL、Authorization、Session 或 keepalive 的差异，可能比软件名称更能解释结果。

排除矩阵

每次先列两个假设。没有媒体时，可以比较 UDP 被阻断和服务器发往错误端口；TCP interleaved 检查前者，比较 Transport 提议、响应、IP 与端口检查后者。画面损坏时，RTP sequence 可区分丢包与初始化不足，而首帧前是否存在 SPS/PPS/VPS 可检查 codec 参数假设。

每个假设都要写支持证据和可反驳证据。任何数据包都无法否定的说法过于宽泛。“NAT 丢弃 UDP”可被客户端端口实际收到 RTP 反驳；“缺少 H.264 参数”可被 IDR 前有效 SPS/PPS 反驳。这样报告会成为有优先级的判断，而不是无序的可能性清单。

不要混用不同时间

RTSP CSeq 表示控制事务顺序，RTP sequence 表示包顺序，RTP timestamp 表示媒体采样时间，capture clock 表示数据到达观察点的时间。它们不是同一只钟。到达抖动不能单独证明 timestamp drift；没有 sequence 证据的 timestamp 跳变也不能单独证明丢包。音视频同步应使用 RTCP sender report 关联不同 RTP 时钟与共同参考。

最终验收资料

当修复能在新连接中以一项已记录变更重复出现时，才关闭调查。报告需要写明输入、最后成功边界、第一项失败证据、变更、复测结果和未测试事项。附上短小相关的 transcript 或统计，而不是一份没有范围的巨大文件。隐藏秘密，但保留 CSeq、脱敏 Session、SSRC 与时间区间。

使用RTSP 故障排除重建顺序，并通过 RTSP Inspector 报告把已证实的故障边界交给摄像机、网络或 VMS 团队。

<!-- rtsp-localized-layer-verdicts-v1:end -->

相关工作流