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 707621 - decodebin: stream-id can't be retrieved from autoplug-continue signal
decodebin: stream-id can't be retrieved from autoplug-continue signal
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.2.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-06 12:01 UTC by Christian Fredrik Kalager Schaller
Modified: 2013-11-29 16:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Fredrik Kalager Schaller 2013-09-06 12:01:07 UTC
Trying to get the streamid using this code from uridecodebin

   def on_autoplug_continue(self, element, pad, caps):
        print("autoplug continue")
        print(caps.to_string())
        stick=pad.get_sticky_event(Gst.EventType.STREAM_START, 0)
        print("stick is " +str(stick))

Stick ends up as None.
Comment 1 Sebastian Dröge (slomo) 2013-09-09 12:06:39 UTC
Right, the pad might not have a stream-start event yet because there might not even be data flow yet. decodebin does not necessarily wait for that if it can continue autoplugging before that already.

Why do you need it there and what for? :)
Comment 2 Tim-Philipp Müller 2013-09-09 12:16:49 UTC
I think he wants to prevent decoders from being plugged for streams which he's not going to use (for efficiency reasons).
Comment 3 Christian Fredrik Kalager Schaller 2013-09-09 12:31:02 UTC
No,although I did think of the efficiency gains as an additional bonus, but my primary concern is that if I have a file with lets say 6 audio streams, all mp3, I want to remux 3 of them and re-encode 3 of them, so I want to stop decoding the 3 I want to remux. There is currently no way of doing that as the 'caps' property would stop all 6 streams from decoding. So Wim suggested I use the autoplug_continue signal, but if I can't identify the streams I am getting I am lost.
Comment 4 Sebastian Dröge (slomo) 2013-09-09 12:53:59 UTC
For this we would need to change decodebin to always wait at least until the stream-start event... for simplicity maybe just always wait until the caps event.
Comment 5 Christian Fredrik Kalager Schaller 2013-09-13 09:53:35 UTC
Any chance of getting this fix in before 1.2.0 ?
Comment 6 Sebastian Dröge (slomo) 2013-09-13 10:15:08 UTC
This should be possible to fix any time, no need to do it now before 1.2.0... unless someone wants to actively work on that now.
Comment 7 Christian Fredrik Kalager Schaller 2013-09-13 11:59:39 UTC
Yeah, I didn't think there was a 1.2.0 dependency as such, I was just hoping to make a Transmageddon release alongside 1.2.0 and this is a blocker for me.

Christian
Comment 8 Wim Taymans 2013-11-21 14:01:10 UTC
I think this should fix it. I tested it by adding some code that dumps the events right before emiting the signals.

commit 8162a583a4dd68582bf186e2e47a8f0d68fa1980
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Thu Nov 21 14:13:16 2013 +0100

    ghostpad: copy sticky events to SRC ghostpads
    
    Update the sticky events on SRC ghostpads when retargeting. This ensures
    that the ghostpad has the exect same sticky events as the target pad. We
    don't want to do this for SINK ghostpads, they got the events from
    downstream and we don't want to overwrite them with the target pad
    events.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=707621
Comment 9 Wim Taymans 2013-11-29 16:33:59 UTC
Reverted, it caused regressions. I have pushed this replacement fix, please retest with this code.


commit fe36be1c03d71008bccadf1ff73ae336631b430b
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Fri Nov 29 17:02:41 2013 +0100

    Revert "ghostpad: copy sticky events to SRC ghostpads"
    
    This reverts commit 8162a583a4dd68582bf186e2e47a8f0d68fa1980.
    
    Automatically copying the sticky events makes it impossible for apps
    and elements to filter the events with event probes. This causes
    regressions (See #719437). The best option is to let the app/element
    copy and filter the events themselves after the ghostpad target is
    set.

commit 6db3b535eb32032598830e4ba49eac50a5e27dd9
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Fri Nov 29 17:30:09 2013 +0100

    uridecodebin: copy sticky events

commit a7151d0b3ea01c8c4d2e081cf12ad88bebf1956b
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Fri Nov 29 17:26:13 2013 +0100

    decodebin2: copy sticky events