GNOME Bugzilla – Bug 794168
streamiddemux: Not settings caps before adding pads
Last modified: 2018-11-03 12:45:01 UTC
I am trying to mux and demux raw video/audio using funnel and streamiddemux respectively. Below is the pipeline, funnel is used to mux audio/x-raw and video/x-raw. Later the stream is demuxed through streamiddemux. Pipeline behaviour is inconsistent across multiple runs. Some times pipeline runs as expected and some times I get negotiation error. gst-launch-1.0 uridecodebin uri=file:Devdas.mp4 name=dec \ dec.! video/x-raw ! fun.sink_0 \ dec.! audio/x-raw ! fun.sink_1 \ funnel name=fun ! streamiddemux name=sid \ sid. ! video/x-raw ! videoconvert ! fakesink \ sid. ! audio/x-raw ! audioconvert ! fakesink gst-launch-1.0 \ videotestsrc is-live=true ! fun.sink_0 \ audiotestsrc is-live=true ! fun.sink_1 \ funnel name=fun ! streamiddemux name=sid \ sid. ! video/x-raw ! queue ! videoconvert ! checksumsink \ sid. ! audio/x-raw ! queue ! audioconvert ! checksumsink When I further debugged the streamiddemux behaviour. Streamiddemux generated pad-added callback upon stream-start event, call back comes with no caps. which is leading to negotiation error. The sticky events comes in stream-start, caps, segment and tag. I even tried add pad after segment event but no luck. I still continue getting negotiation error. Regards, Vinod
It would have to delay adding the pad to the element for a bit, yes. The pads should be added after the caps are known. Do you want to provide a patch for this?
Sebastian, I am planning to provide patch for this bug. I modified code as below to add pad on SEGMENT/CAPS event. With this patch testsrc pipeline works (Withrout encoders) but other pipeline still throw error. Can some one help me to point out issue in below code. if (GST_EVENT_TYPE (event) == GST_EVENT_STREAM_START) { gst_event_parse_stream_start (event, &demux->stream_id); if (!demux->stream_id) goto no_stream_id; } else if (GST_EVENT_TYPE (event) == GST_EVENT_SEGMENT) { GST_OBJECT_LOCK (demux); active_srcpad = gst_streamid_demux_get_srcpad_by_stream_id (demux, demux->stream_id); if (!active_srcpad) { /* try to generate a srcpad */ if (gst_streamid_demux_srcpad_create (demux, pad, demux->stream_id)) { GST_OBJECT_UNLOCK (demux); gst_pad_set_active (demux->active_srcpad, TRUE); /* Forward sticky events to the new srcpad */ gst_pad_sticky_events_foreach (demux->sinkpad, forward_sticky_events, demux->active_srcpad); gst_element_add_pad (GST_ELEMENT_CAST (demux), demux->active_srcpad); } else { GST_OBJECT_UNLOCK (demux); goto fail_create_srcpad; } } else if (demux->active_srcpad != active_srcpad) { demux->active_srcpad = active_srcpad; GST_OBJECT_UNLOCK (demux); //gst_pad_sticky_events_foreach (demux->sinkpad, forward_sticky_events, // demux->active_srcpad); g_object_notify (G_OBJECT (demux), "active-pad"); } else GST_OBJECT_UNLOCK (demux); }
The best would be if you could provide a testcase (ideally a unit test), and an actual patch to apply/review and how exactly it fails.
Created attachment 369852 [details] [review] streamiddemux: Not settings caps before adding pads. Element is generating pads without caps. Delay the pad adding till sink pad receives caps event. With the patch the pipeline built using GST API are working but the pipeline built with gst-launch are not working.
Created attachment 369853 [details] Application written using GST APIs Continued .. Sebastian Dröge, I missed the pipeline details and test case in the patch description. Adding those details here. The patch is not working for below gst-launch pipeline. But it works for same pipeline if it is created using GST APIs(Test case is attached). gst-launch-1.0 \ videotestsrc is-live=true ! queue ! fun.sink_0 \ audiotestsrc is-live=true ! queue ! fun.sink_1 \ funnel name=fun ! queue ! streamiddemux name=sid \ sid.! video/x-raw ! queue ! videoconvert ! mux. \ sid.! audio/x-raw ! queue ! audioconvert ! mux. \ mpegtsmux name=mux ! fakesink --gst-debug=2 Please review the patch and let me know your comments. Regards, Vinod Kesti
Hi Can some body review the patch and update me ?? Regards, Vinod Kesti
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/277.