G_signal_connect () data problem

The current pipeline, works with only one rtsp input stream:
rtsp 0-> uridecodebin ->nvstreammux → queue → nvmultistreamtiler → queue → nvvideoconvert → queue → nvosd → queue → nvvideoconvert → queue → capsfilter ->queue → nvv4l2h264enc → queue → rtph264pay → queue → udpsink → Rtsp Server

I want to extend the pipeline to work with multiple streams
rtspp 1 →
rtsp 0-> uridecodebin ->nvstreammux → queue → nvmultistreamtiler → queue → nvvideoconvert → queue → nvosd → queue → nvvideoconvert → queue → capsfilter ->queue → nvv4l2h264enc → queue → rtph264pay → queue → udpsink → Rtsp Server

The problem is that when I call the following callback function:
g_signal_connect (G_OBJECT (bin), “pad-added”,G_CALLBACK (cb_newpad), &source_id);

where source_id is a gint with a value of 1

It seems as if data is not passed correctly into the cb_newpad function (below).

static void cb_newpad (GstElement * decodebin, GstPad * pad, gpointer data)

When the variable:
**gint source_id = *(gint *) data; **
is printed out in this callback function, it returns the value 0, and not 1.

This causes the second stream to fail because of the following error:
Element stream-muxer already has a pad named sink_00, the behaviour of gst_element_get_request_pad() for existing pads is undefined!

This is because the pad sink_00 has already been made for the first stream.

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Where did you add the callback to? Can you upload the whole code?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.