GNOME Bugzilla – Bug 383102
[0.11] Rethink pad_blocking
Last modified: 2011-10-27 14:41:26 UTC
Hi, When a pad is set to blocked (while in push mode) either gst_pad_push or gst_pad_alloc_buffer_full can cause blocked to be signaled. Both function can be called from different thread (notibly when the src pad your blocking is from a queue). Thus something like the following can happen: Thread 1 pushes on the pad, Thread 2 sets the pad to block and waits, Thread 3 does a pad_alloc call and thus signals the blocking (even though Thread 1's push didn't necessarily return yet!) On a side note, it'd be nice if blocking could also be signalled if there is _no_ dataflow currently.. Especially for live sources where you never (really) know if there will be any dataflow.
no idea how to fix this...
Queue (and any other similar element) should serialize push and passthrough of buffer_alloc. For normal elements this is automatic, elements that start a task need additional locking.
While we're on the topic (several months later), it might also be good to set a flag on a pad when it's being chained through and unset it on return, since we need to take locks anyway.
what would you do with the flag?
ah, something else: when you have EOS on the pad and try to block it, it will never block. I think it should.
What's up with this? Maybe someone could add some unit tests that should work but don't work at the moment?
for 0.11 someone should rethink the pad blocking.
Is this actually still a problem in 0.11? (yes, we should rethink and rework pad blocking nonetheless) Without bufferalloc pad blocks will now only happen for synchronized events and buffers, i.e. can only be triggered from the streaming thread.
(In reply to comment #8) > Without bufferalloc pad blocks will now only happen for synchronized events and > buffers, i.e. can only be triggered from the streaming thread. Then it's mostly the same as a pad-probe and blocking in there instead of returning.
(In reply to comment #9) > (In reply to comment #8) > > Without bufferalloc pad blocks will now only happen for synchronized events and > > buffers, i.e. can only be triggered from the streaming thread. > > Then it's mostly the same as a pad-probe and blocking in there instead of > returning. I hope at some point that we can implement pad blocking and probes with the same code..
How is pad blocking in 0.11 different from probes? Apart from having a more annoying API ?
(In reply to comment #11) > How is pad blocking in 0.11 different from probes? Apart from having a more > annoying API ? What do you mean? probes and pad block are completely different things now. Probes lets you see the data and events that pass (both upstream and downstream) by triggering a signal. There is limited support for modifying the data. There is no support for blocking the dataflow in a way that works with flushing events. All callbacks are called from the streaming thread. Multiple probes can be installed on a pad. Pad blocking is to block the dataflow, only works on downstream events. Has support for blocking that works nicely with flushes. There is no support for looking at the blocked item nor modifying it. Only one block can be installed on a pad. The block can be handled from another thread.
I think this can be closed now ? Olivier? Wim?
probes and pad blocking are now the same code. pad_alloc is gone so you don't get weird pad blocks anymore from them. Also there is IDLE probe, which signals you whenever there is no dataflow at all. This should address all concerns known for pad blocking..