GNOME Bugzilla – Bug 693318
GstGhost pad 'wrong' behavior concerning sticky events
Last modified: 2013-02-13 08:45:53 UTC
Scenario: we have a bin with a demuxer. The demuxer signals pad-added, and the bin adds a corresponding ghostpad and signals it's own pad-added. And external signal handlers checks the newly created pad and finds out that it doesn't have a current caps. This is true even if the demxuer elements newly added pad does have a current caps. What I expect: I expect ghost pads to be as functionally identical to the target pad as possible, including having the same sticky events after changing target.
I think so too. Setting a target should be like linking IMHO, the sticky events should be forwarded in that case. This would also solve an annoyance with uridecodebin and friends (that you can't reliably get the actual fixed caps for the pad just exposed)
Created attachment 235488 [details] [review] Forward sticky event when activating the pad This works for me, but the question is if there might be more cases that I don't consider with this patch. I think I need a pair of more experienced gstreamer-eyes to look at this...
Comment on attachment 235488 [details] [review] Forward sticky event when activating the pad Sorry, forgot some debugging in there
Created attachment 235490 [details] [review] Forward sticky event when activating the pad
Not sure if this should happen when activating a pad. It should happen when setting a target (as Tim said above), but we can't just send events from there... so instead it should happen after setting a target the first time a serialized event arrives. Why did you decide to do that sending when activating the pad?
Well... As you say I can't do it when setting target (things are flushing at that point). But doing it when the first serialized event arrives is not a solution either since that would put us on square 1. We need these sticky events to be transferred to the ghost pad as soon as we start using it as a clone of the other pad: After activating and adding it to the bin. As I said in the the comment I am not sure about the patch, I don't know these parts good enough. But I seems to me we won't be able to wait for anything serialized before moving them. Activation should prepare the pad for data transfer, should it not? It feels to me that it's acceptable to do stuff like this there. It is part of preparing the ghostpad for usage.
I don't see any other option than to let the element deal with the events in the streaming thread. In this case it should go like: * new pad is blocked * ghostpad is made, activated and linked from block callback * ghostpad is blocked * other pad is unblocked * in block callback from ghostpad, expose pad on decodebin It's cumbersome but I don't see any other way of transfering the events safely than by letting the streaming thread do it.
NOTABUG then?
Ok, I will open a new bug for the places I find where we do it wrong (like in uridecodebin).