CODEWITHSUNDEEP
gstreamerh.264gstreamer-1.0
JonasVautherin
JonasVautherin

Reputation: 8033

h264parse: broken/invalid nal Type

I am receiving h264 frames over a serial link, trying to play them with gstreamer. I set the caps to gst_caps_from_string("video/x-h264"), and it seems to accept them (if I use other caps, e.g. application/x-rtp, then the gstreamer log output complains about incompatible caps).

More specifically, I use the following elements: appsrc ! h264parse ! rtph264pay, and it seems like h264parse is the one not being happy.

When I pass (through appsrc) a frame that I get as a byte[] of length 8018, I get the following log output:

WARN h264parse gsth264parse.c:1496:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 6 SEI, Size: 12 will be dropped
WARN h264parse gsth264parse.c:1496:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 6 SEI, Size: 12 will be dropped
WARN h264parse gsth264parse.c:1496:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 7986 will be dropped

Note how those 3 WARN lines are similar, with the first two dropping size 12, and the last one dropping size <my byte[] size> - 32.

This is consistent over all the frames I send: it always complains twice about dropping 12, and then about dropping the length of the frame I pass minus 32.

Why could that be? Could it be related to my pipeline not receiving SPS/PPS data? I have been dumping the frames (appsrc ! identity dump=true ! ...), but I can't seem to find any frame that starts with 00 00 00 01 67 or 00 00 00 01 68, though I'm not sure if that could create those warnings or not.

Upvotes: 4

Views: 3924

Answers (1)

JonasVautherin
JonasVautherin

Reputation: 8033

From the source code, this message comes from:

if (!gst_h264_parse_process_nal (h264parse, &nalu)) {
  GST_WARNING_OBJECT (h264parse,
      "broken/invalid nal Type: %d %s, Size: %u will be dropped",
      nalu.type, _nal_name (nalu.type), nalu.size);
  [...]
}

Where gst_h264_parse_process_nal(), for SEI frames, returns FALSE when:

case GST_H264_NAL_SEI:
  /* expected state: got-sps */
  if (!GST_H264_PARSE_STATE_VALID (h264parse, GST_H264_PARSE_STATE_GOT_SPS))
    return FALSE;

With GST_H264_PARSE_STATE_VALID defined as:

#define GST_H264_PARSE_STATE_VALID(parse, expected_state) \
  (((parse)->state & (expected_state)) == (expected_state))

It seems that this error comes when the state does not have GST_H264_PARSE_STATE_GOT_SPS set.

As a conclusion, the frames in the question above are dropped because the SPS data has not been received at this point.

Upvotes: 5

Related Questions