GNOME Bugzilla – Bug 793213
blocking probe and flush events issue
Last modified: 2018-11-03 12:44:46 UTC
Created attachment 367948 [details] test application The following problem has been observed: a blocking probe (GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM | GST_PAD_PROBE_TYPE_DATA_DOWNSTREAM | GST_PAD_PROBE_TYPE_EVENT_FLUSH) is installed on the source pad. When the pad is blocked, a flushing seek is performed. No flush-start/flush-stop events are received in the probe. Is the probe installed in an incorrect way? The attached dummy test application exposes the problem.
Looks all correct to me, but the testcase is quite complicated. This should already fail on a simple "audiotestsrc ! fakesink" pipeline with a seek. No need for gst-rtsp-server here. Does it by any chance work better if you take the sinkpad instead?
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.
(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
> > 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? > My observations: * the probe does work if it's only registered for flushes: test_pad_probe_flush_events_only () in tests/check/gst/gstpad.c * the probe does work if it's registered for flushes and downstream events: test_pad_probe_flush_events () * the probe doesn't work if it's registered for flushes and data: test case in the attached test application
Ok, so somewhere a condition must be wrong in gstpad.c but generally it works
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/274.