h264parse broken/invalid nal

Question

I am trying to simulate sending and receiving mpeg video with gst-launch-1.0.

Sender pipeline: gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080,framerate=15/1 ! queue ! x264enc bitrate=4000 ! queue ! mpegtsmux ! rtpmp2tpay ! udpsink host=224.10.10.10 port=15004

Receiver pipeline: gst-launch-1.0 -v rtpbin name=rtpbin udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)MP2T,payload=(int)33,seqnum-offset=(uint)2803,timestamp-offset=(uint)2170591411, ssrc=(uint)2276926567" port=15004 multicast-group=224.10.10.10 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! tsdemux ! h264parse ! capsfilter caps=video/x-h264,alignment=au,stream-format=avc ! avdec_h264 ! fpsdisplaysink sync=1 udpsrc port=18889 ! rtpbin.recv_rtcp_sink_0

deducted from: gst-launch-1.0 -v rtpbin name=rtpbin udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)MP2T,payload=(int)33,seqnum-offset=(uint)2803,timestamp-offset=(uint)2170591411, ssrc=(uint)2276926567" port=15004 multicast-group=224.10.10.10 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! tsdemux ! decodebin ! fpsdisplaysink sync=1 udpsrc port=18889 ! rtpbin.recv_rtcp_sink_0

Running the receiver first, then the sender results as expected displaying video window immediately.

But when the sender is launched first, receiever pipeline hangs for about 10 seconds displaying lots of those messages:

0:00:01.654820616 23285 0x56008c3bb640 WARN               h264parse gsth264parse.c:1349:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 32773 will be dropped

gst-launch-1.0 --gst-version returns:

GStreamer Core Library version 1.16.2

score 1 · Answer 1 · answered Nov 06 '21 at 15:17

1

I think it is similar to my question here. This error is being thrown because your h264parse element has not yet received the SPS/PPS data.

The warning is thrown from here:

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);
  [...]
}

For a slice, this fails here:

    case GST_H264_NAL_SLICE:
    case GST_H264_NAL_SLICE_DPA:
    case GST_H264_NAL_SLICE_DPB:
    case GST_H264_NAL_SLICE_DPC:
    case GST_H264_NAL_SLICE_IDR:
    case GST_H264_NAL_SLICE_EXT:
      /* expected state: got-sps|got-pps (valid picture headers) */
      h264parse->state &= GST_H264_PARSE_STATE_VALID_PICTURE_HEADERS;
      if (!GST_H264_PARSE_STATE_VALID (h264parse,
              GST_H264_PARSE_STATE_VALID_PICTURE_HEADERS))
        return FALSE;

I think this happens because when you start the sender first, then the SPS/PPS frames are emitted before the receiver starts, and therefore are lost for a while. You could try to make the sender emit this data more often. I think for instance h264parse config-interval=-1 would send it with every IDR frame.

answered Nov 06 '21 at 15:17

JonasVautherin

7,297
6
49
95

unfortunately it doesn't fix the warnings, should i change some other properties aswell? – Kyeiv Nov 08 '21 at 08:10
Maybe set `config-interval=-1` on the sender side? – JonasVautherin Nov 08 '21 at 22:36
I don't think there is any element i can set this property to. – Kyeiv Nov 09 '21 at 07:51
That would be h264parse :) – JonasVautherin Nov 09 '21 at 13:47
but i do not have any h264parse in sender pipeline, so i don't know where could i put it. – Kyeiv Nov 10 '21 at 06:41
Not super experienced with gstreamer, but what about trying after x264enc? – JonasVautherin Nov 10 '21 at 22:42
unfortunately this doesn't work either – Kyeiv Nov 15 '21 at 07:45
Oh sorry I missed that you are using `stream-format=avc`, I'm using `stream-format=byte-stream`. With avc, shouldn't you set the `codec_data` on the receiver side? – JonasVautherin Nov 15 '21 at 10:46

h264parse broken/invalid nal

1 Answers1