GStreamer中h264parse报broken/invalid nal Type错误是什么原因？

问题根因 #

你遇到的h264parse丢帧告警确实和缺少SPS/PPS数据直接相关。
H.264的解析逻辑必须依赖SPS（序列参数集，NAL类型0x67）和PPS（图像参数集，NAL类型0x68）里的编码参数，才能校验后续SEI、Slice等其他NAL单元的合法性。如果h264parse没有先收到合法的SPS/PPS，会直接把所有后续NAL判定为无效数据丢弃，就是你看到的告警内容。

规律解释 #

你观测到的告警规律是因为你每次传入appsrc的8018字节数据，实际包含3个独立的NAL单元：2个12字节的SEI NAL、1个长度为7986的Slice NAL，三个NAL的总长度加上各自的起始码长度刚好等于你传入的byte数组长度，所以h264parse拆分后会依次抛出3条丢弃告警。

排查解决步骤 #

• 首先确认SPS/PPS来源：
  大部分H.264编码器只会在IDR关键帧前发送一次SPS/PPS，不会跟随每个普通帧输出。你可以先排查串行链路的发送端逻辑：
  1. 是否确实输出了SPS/PPS？
  2. 传输过程中是否把SPS/PPS帧过滤丢弃了？
  3. 你抓取的帧数据是否刚好跳过了IDR帧的传输区间？
     如果发送端输出的SPS/PPS是固定值，你可以直接把带00 00 00 01起始码的SPS、PPS二进制数据，在pipeline启动后、推普通视频帧之前优先推入appsrc。
• 修正appsrc的caps配置：
  你当前的caps只声明了video/x-h264，建议补全格式参数，避免h264parse格式误判：

  gst_caps_from_string("video/x-h264, stream-format=byte-stream, alignment=nal")
  

  如果你收到的H.264流是带长度前缀的AVCC格式（没有起始码），则需要把stream-format改成avcc。
• 校验帧格式：
  你排查时只搜索了4字节起始码的SPS/PPS，可以补充搜索3字节起始码（00 00 01 67、00 00 01 68）的内容，确认是否是起始码长度不匹配导致你没找到SPS/PPS。

内容的提问来源于stack exchange，提问作者JonasVautherin