[Bug 793213] blocking probe and flush events issue

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793213

--- Comment #3 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Patricia Muscalu from comment #2)
> Just to clarify, it's not a gst-rtsp-server use case.
> We have a pipeline with matroskamux element that does not support seeking.

Indeed, I looked to fast

> The whole idea is to block dataflow in the pipeline and unblock it when
> flush-stop is received on the blocking pad. 
> We currently solve this problem by installing another probe (
> GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM | GST_PAD_PROBE_TYPE_EVENT_FLUSH) on the
> same pad as soon as the pad has been blocked (<=> the probe list is changed
> in this case meaning that the first preroll buffer will trigger the probe
> callback again).
> 
> Installing a probe with the following mask
> GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM | 
> GST_PAD_PROBE_TYPE_DATA_DOWNSTREAM | GST_PAD_PROBE_TYPE_EVENT_FLUSH, I would
> actually expect to get notification about the flush events being sent. In
> this
> particular case the pad is unblocked and the flush events are sent to the
> peer pad.

So the probes work if you only register for the flushes but not if you register
for flushes and data? Or does it only work if you register for flushes after a
data probe triggered already?


But yes, your expectations are correct. That's how it should work

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.