GNOME Bugzilla – Bug 584686
[playbin2] Need {audio,video,text}-tags-changed signals
Last modified: 2009-06-04 13:47:39 UTC
Hi, it'd be nice if playbin2 had {audio,video,text}-tags-changed signals that are emitted whenever the tags are changed so one can call get-{a,v,t}-tags to get the latest tags. Currently this can only be done by polling get-{a,v,t}-tags or by installing an event probe on the a/v/t pads.
could be done by proxying the property notify of the inputselector.
Ok, done :) commit 28b366db00bbc591325549417b668f18a5d4d949 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Jun 4 08:57:24 2009 +0200 playbin2: API: Add {audio,video,text}-tags-changed signals Fixes bug #584686. commit a0ad632320eb4b29b873e8c9058e01dde4a21535 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Jun 4 08:56:29 2009 +0200 inputselector: Notify when the tags property of the selector sinkpads change First part of bug #584686.
Why do we keep adding signal notify stuff emitted from streaming threads everywhere? This sucked, a lot, in 0.8, and nothing much has changed since then: - it's painful for apps, since they have to marshal things into the main thread (not to mention that those poor souls who just wanted to write a simple player using playbin2 have to learn about threading and marshalling things into the other threads). - it's racy and may lead to crashes due to still unfixed GObject bugs. - it's hard to extend (add new arguments etc.) In fact, the only upside I can see is that it's introspectable via gst-inspect. Can we please come up with a better system for these things?
(Ok, so this isn't a notify signal, but other than the notify raciness my points still apply, I think.)
In 0.11 I'd propose that the sinks are the only elements that post tags as messages on the bus... then this wouldn't be a problem anymore. Other than a signal for the tags-changed stuff a element message could be used as well, right. I've used a signal because similar things are already done as signal in playbin2 for consistency and because it's a proxy signal for the notify::caps signal of the input-selector sinkpads.
Comment #5: I was actually going to implement this in 0.10 already but then I ran into some problems in basesink and stopped the attempt.