Unable to Capture Nvidia Plugin Errors using GStreamer Bus

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hi,

I can’t capture these error messages using Gstreamer bus. How can my gstreamer application capture them using the bus?

Here are the error:

eColor Player: nvdc: failed to open ‘/dev/tegra_dc_ctrl’.
Feb 17 11:35:18 nano2 eeColor Player: NvxBaseWorkerFunction[2575] comp OMX.Nvidia.std.iv_renderer.overlay.yuv420 Error -2147479552
Feb 17 11:35:18 nano2 eeColor Player: NvxBaseWorkerFunction[2575] comp OMX.Nvidia.std.iv_renderer.overlay.yuv420 Error -2147479552
Feb 17 11:35:18 nano2 eeColor Player: nvdc: open: Too many open files in system

I can capture other error but not these.

Here is my bus code snippet
switch (GST_MESSAGE_TYPE (message)) {
case GST_MESSAGE_ERROR:{
GError *err;
gchar *debug;

        gst_message_parse_error (message, &err, &debug);
        if (enable_debug == TRUE) {
            syslog(LOG_ERR, "bus_cb: error %s message", err->message);
        }
        g_error_free (err);
        g_free (debug);
        g_main_loop_quit (loop);
        break;
    }
    
    default:
        /* unhandled message */
        break;
}

Tom

2

Not sure how you would recover from that even if you could catch it. It looks like you’re running out of file descriptors. Are you opening a file in a loop somewhere and not closing it?

3

Any idea how I can catch these NVIDIA plugin errors inside my gstreamer player app? Or is there anyway I can catch these error using Linux signals, etc…?

4

Hi,
Do you set overlay index out of range and hit the error? Like:

$ gst-launch-1.0 videotestsrc ! nvoverlaysink overlay-x=400 overlay-y=400 overlay-w=320 overlay-h=240 overlay=3

You may use nvcompositor to composite multiple overlays into one.

5

I don’t use any overlay properties. These errors occur when the hdmi handshake is lost. The point is I can’t capture these error using the gstreamer bus as these plugins don’t appear to put errors on the bus.

6

Well, if you’re running out of file descriptors, that’s a limited system resource, so there isn’t anything that can could be done to fix it without killing the process or closing those resources, even if nvidia’s elements did post a message on the bus when that happened.

Usually that happens when you open something repeatedly (eg. in a loop, or a callback, which is bad) but don’t close it. If you want to print all bus messages anyway, you can put something to handle the GstMessage class in where you have /* unhandled messages */

The GST_MESSAGE_TYPE_NAME macro will get the message type name for a message and GST_MESSAGE_SRC_NAME will get the message source name. Once you know if there is a message at the trouble spot, you can add another case handling it’s type specifically. Other languages have far more idiomatic ways of getting the content.

I can’t personally replicate your issue with my Xavier. I just unplugged and replugged my hdmi cable with a gstreamer pipeline running, nothing was posted on the bus (and I log all of that), and I am not running out of FDs.