GNOME Bugzilla – Bug 766002
pad: IDLE probes don't block when returning GST_PAD_PROBE_OK
Last modified: 2016-05-19 22:50:09 UTC
The doc says: "probe idle pads and block" But if I return GST_PAD_PROBE_OK from that probe, it won't block the stream anymore, unlike a GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM probe. So if I want a probe that fire on idle AND block (as doc suggests) I must pass: GST_PAD_PROBE_TYPE_IDLE | GST_PAD_PROBE_TYPE_BLOCK | GST_PAD_PROBE_TYPE_DATA_DOWNSTREAM part-probes.txt is not clearer, it even more suggest that returning OK from an IDLE probe should keep it blocked. Or maybe it is the implementation that's wrong?
Check attachment #327311 [details] for a test case of this.
I would say the implementation is wrong. It should behave like other GST_PAD_PROBE_TYPE_BLOCKING (note the ING) and block on OK.
Can you provide a testcase patch against the existing pad tests?
Created attachment 327451 [details] Test case Here it is, cannot be more basic. - With GST_PAD_PROBE_TYPE_IDLE, it continues playing. - With GST_PAD_PROBE_TYPE_IDLE | GST_PAD_PROBE_TYPE_BLOCK, probe is called twice but stay blocked afterward.
(In reply to Sebastian Dröge (slomo) from comment #2) > I would say the implementation is wrong. It should behave like other > GST_PAD_PROBE_TYPE_BLOCKING (note the ING) and block on OK. Note that GST_PAD_PROBE_TYPE_BLOCKING is IDLE|BLOCK which makes no sense to have (at least in public API) if IDLE alone is already supposed to block.
Created attachment 327932 [details] [review] pad: Block data processing if an IDLE probe is still attached
This breaks the pad unit tests though: gst/gstpad.c:973:F:general:test_push_linked_flushing:0: Assertion 'gst_pad_push (src, buffer) == GST_FLOW_FLUSHING' failed gst/gstpad.c:1614:E:general:test_pad_probe_pull_idle:0: (after this point) Test timeout expired
commit edb27a8ec26dfc6d8f7db8c29a7b0b14053f26a5 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun May 15 15:02:49 2016 +0300 pad: Improve IDLE probe docs Make it explicit that the pad is only blocked while the callback is running, and the pad will be unblocked again once the callback returned. If BLOCK and IDLE behaviour is needed, both need to be used. https://bugzilla.gnome.org/show_bug.cgi?id=766002
And now it's start making sense, thanks!