Catching NVPARSER IRAP Seeking errors in gstreamer pipeline

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
Jetson Xavier NX
• DeepStream Version
6.0
• JetPack Version (valid for Jetson only)
4.6.2
• TensorRT Version

I have a Jetson Xavier NX with Jetpack 4.6.2 and am ingesting various RTSP sources in a pipeline for processing in a custom application. With a few of our internal sources (one from a Dahua camera and another generated by mediamtx) when the stream is opened with uridecodebin3 or rtspsrc the logging output is spammed with “NVPARSER: HEVC: Seeking is not performed on IRAP picture” logging. The issue for us is fixed if we use uridecodebinfor whatever reason, however I am still curious as to how I would be able to catch these errors from the generated pipeline if they were to occur again? I tried creating a bus watch withgst_bus_add_watch() and popping any messages that come through but with no good consistency did a message come through when the error occurred.
It appears that the NVPARSER error comes from the nvv4l2decoder element, so my question is how am I best off catching errors from this element so I can handle the situation?

3

This error handling should be the behavior of the gstreamer framework.

Do you mean the following code, can you get a different error message?

case GST_MESSAGE_ERROR:{
      gchar *debug;
      GError *error;
      gst_message_parse_error (msg, &error, &debug);
      g_printerr ("ERROR from element %s: %s\n",
          GST_OBJECT_NAME (msg->src), error->message);
      if (debug)
        g_printerr ("Error details: %s\n", debug);
      g_free (debug);
      g_error_free (error);
      g_main_loop_quit (loop);
      break;
    }

Can you dump the rtsp stream to a local file using the following command line?

gst-launch-1.0 -e urisourcebin uri="your rtsp url" ! queue ! parsebin ! queue ! h264parse(h265parse) ! mpegtsmux ! filesink location=rtsp.ts
4

I never get any GST_MESSAGE_ERROR messages back. I do during my pipeline startup get a lot of GST_MESSAGE_STREAM_STATUS, however I also get a few of those during a successful start as well with a more normal stream and also before any NVPARSER errors occur. GST_MESSAGE_STREAM_STATUS I feel like doesn’t really indicate what’s happened, only that something has occurred, so I’m hesitant to treat it as an error.

Stream dumped: Dropbox

5

1.Using this stream, can you reproduce the problem? It looks like certain information in the stream triggers the issue. Do you try other RTSP sources? Maybe it is specific to certain RTSP source.

2.I modified deepstream-test1 to support h265 and did not reproduce the problem. I use the latest JetPack 6.0 and DeepStream 7.0.

Since you use Xavier, it only supports DeepStream 6.3. Can you try to upgrade?

6

I don’t care about fixing the issue, I already have a fix like I already clearly stated. I’m asking how should I best go about catching errors when this occurs, as I only get GST_MESSAGE_STREAM_STATUS from the pipeline bus watch. If it’s not possible I want you guys to admit this so I don’t waste time.

No, because I’m using Jetpack 4.6.2, like I said, which only seems to support 6.0.1 (according to SDK Manager).

7

Ok, this is a problem with the specific version and hevc stream, you can ignore it

8

I can ignore… what?

9

To add I can also get it to occur with h264, the example i just provided happened to be hevc

10
  1. You have a workaround.
  2. You do not plan to upgrade. I tested the new version and there is no such problem. We usually do not maintain the old version. If this doesn’t impact your work, you can ignore it.
11

I have a workaround but there may be times when I want to use uridecodebin3 or rtspsrc as I’ve encountered weirdness with streams in the past. When you say no such problem occurs I assume you mean that the NVPARSER error doesn’t occur. I want to know if there’s another way/the proper way to catch this error when it DOES occur from the nvv4l2decoder element, and what you people internally throw, or if the way errors are supposed to be reported are fundamentally broken.