After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708988 - interleave: Does not handle request pad names correctly
interleave: Does not handle request pad names correctly
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-28 10:47 UTC by Yasushi SHOJI
Modified: 2018-11-03 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG=4 GST_DEBUG_NO_COLOR=1 gst-launch-1.0 interleave name=i ! pulsesink audiotestsrc ! i.sink_0 audiotestsrc wave=red-noise ! i.sink_1 (14.48 KB, text/plain)
2013-09-28 10:47 UTC, Yasushi SHOJI
Details

Description Yasushi SHOJI 2013-09-28 10:47:33 UTC
Created attachment 255977 [details]
GST_DEBUG=4 GST_DEBUG_NO_COLOR=1 gst-launch-1.0 interleave name=i ! pulsesink audiotestsrc ! i.sink_0 audiotestsrc wave=red-noise ! i.sink_1

It seems to me that the interleave module example on the current documentation[1] does not work. The command line example is this:

gst-launch-1.0 interleave name=i ! audioconvert ! wavenc ! filesink location=file.wav  filesrc location=file1.wav ! decodebin ! audioconvert ! "audio/x-raw,channels=1" ! queue ! i.sink_0   filesrc location=file2.wav ! decodebin ! audioconvert ! "audio/x-raw,channels=1" ! queue ! i.sink_1

It is very long so I've modified to shorten it to this:

gst-launch-1.0 interleave name=i ! pulsesink \
audiotestsrc                ! audio/x-raw,channels=1 ! i.sink_0 \
audiotestsrc wave=red-noise ! audio/x-raw,channels=1 ! i.sink_1

Both example failed to run with an error message:
WARNING: erroneous pipeline: could not link audiotestsrc0 to i

slomo on the GStreamer IRC channel told me that the "problem is that interleave does not take the requested pad name into account... so the second chain requests "sink_1" but gets "sink_0", and the other way around".

To back up his comment, I've taken a debug message to see what it says (Full log attached). Here is the excerpt that I think relevant:

The second chain (sink_1) request:
GST_ELEMENT_PADS gstutils.c:1543:gst_element_link_pads_full: trying to link element capsfilter0:src to element i:sink_1
GST_ELEMENT_PADS gstelement.c:897:gst_element_get_static_pad: found pad capsfilter0:src
GST_ELEMENT_PADS gstelement.c:894:gst_element_get_static_pad: no such pad 'sink_1' in element "i"
GST_ELEMENT_PADS gstelement.c:894:gst_element_get_static_pad: no such pad 'sink_1' in element "i"
GST_ELEMENT_PADS gstelement.c:646:gst_element_add_pad:<i> adding pad 'sink_0'
        GST_PADS gstutils.c:1443:prepare_link_maybe_ghosting: capsfilter0 and i in same bin, no need for ghost pads
        GST_PADS gstpad.c:2083:gst_pad_link_prepare: trying to link capsfilter0gst_pad_link_prepare: trying to link capsfilter0:src and i:sink_0
        GST_PADS gstpad.c:2285:gst_pad_link_full: linked capsfilter0:src and i:sink_0, successful

As you can see that the sink_1 reqest ended up linking to sink_0. Pipleline creation continue to the first chain (sink_0) request:

GST_ELEMENT_PADS gstutils.c:1543:gst_element_link_pads_full: trying to link element capsfilter1:src to element i:sink_0
GST_ELEMENT_PADS gstelement.c:897:gst_element_get_static_pad: found pad capsfilter1:src
GST_ELEMENT_PADS gstelement.c:897:gst_element_get_static_pad: found pad i:sink_0
         default gstutils.c:1877:gst_element_link_pads_filtered: Could not link pads: capsfilter:src - i:sink_0

and failed.

[1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-interleave.html
Comment 1 Sebastian Dröge (slomo) 2013-09-28 10:48:56 UTC
interleave should use the request pad name if possible. However this is a bit tricky in interleave because the number of the pad is used as the index of the channel that it represents.
Comment 2 Sebastian Dröge (slomo) 2013-10-07 12:57:16 UTC
The best might be to just sort all pads by their number, and use them in that order for the channels. And check if there's a gap in the numbers.
Comment 3 Nicolas Dufresne (ndufresne) 2015-05-29 16:30:08 UTC
So req_name in the reuqest pad function is ignored. this also applies to audiointerleave. I don't see any code that try to warn on channel clash, so I guess it simply get overwritten (hopefully I'm wrong).
Comment 4 GStreamer system administrator 2018-11-03 14:49:56 UTC
-- 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/gst-plugins-good/issues/94.