GNOME Bugzilla – Bug 707621
decodebin: stream-id can't be retrieved from autoplug-continue signal
Last modified: 2013-11-29 16:33:59 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.
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? :)
I think he wants to prevent decoders from being plugged for streams which he's not going to use (for efficiency reasons).
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.
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.
Any chance of getting this fix in before 1.2.0 ?
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.
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
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
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