[Bug 793213] blocking probe and flush events issue

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Patricia Muscalu <patricia at axis.com> ---
Just to clarify, it's not a gst-rtsp-server use case.
We have a pipeline with matroskamux element that does not support seeking.

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.

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