GNOME Bugzilla – Bug 752815
basesrc: events don't get pushed if basesrc has no pending buffers to send
Last modified: 2018-11-03 12:29:14 UTC
Use case: In some later stage of the pipeline I want to detect when an append has been fully processed. Timeouts aren't a very robust solution, and EOS isn't an alternative either (I don't want to reset the pipeline). The best alternative is to send a custom downstream event after the append, signaling that no more data will be fed by now. That event will be detected by a probe later in the pipeline. Problem: However, basesrc doesn't emit the custom event until a new chunk of data is appended after the event (but I don't want to do that). The primary reason for not emitting the event is that gst_base_src_loop() is stalled waiting for new buffers in a call to gst_base_src_getrange().
Created attachment 308066 [details] [review] Patch 1/2 This patch partially solves the problem, but not in all the cases. Some review and guidance would be great.
Created attachment 308067 [details] [review] patch 2/2 This patch complements the previous one, checking have_events again after the create function returns, possibly waken by the GST_EVENT_CUSTOM_DOWNSTREAM case in gst_base_src_send_event().
A unit test would be great too :)
Created attachment 308096 [details] [review] Unit test This unit test clearly fails with a timeout when the event is not received. With my patches applied, the event is received. However, even though the last step of the test inserts an EOS (I can see it in the logs), it seems to be never processed. Therefore, the test doesn't succeed either. I work in a cross-build environment and can't run the tests directly. I use this command to manually run the basesrc test after copying it to the device: GST_DEBUG="check:INFO,fdsrc:7,basesrc:7" GST_STATE_IGNORE_ELEMENTS="" ./basesrc
Review of attachment 308066 [details] [review]: This patch needs to be rebased now, sorry. Careful, the locking have changed.
This patch, when rebased, will have the same issue reported by #785142, so adding a dep on it (even though not a blocker, it's just so we remember there is a link).
-- 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/124.