GNOME Bugzilla – Bug 677340
Event errors ignored, even if caused by dataflow errors
Last modified: 2018-11-03 12:15:26 UTC
Consider the following pipeline: audiotestsrc num-buffers=1 ! vorbisenc ! vorbisdec ! sink vorbisdec will only push buffers to the sink as a result of the EOS event sent downstream from audiotestsrc and vorbisenc. So all gst_pad_push() in vorbisenc and audiotestsrc will always see GST_FLOW_OK. If the pushing of data in vorbisdec (remember: triggered by the EOS event) now fails audiotestsrc (the element driving the pipeline and the element that should post error messages on the bus if pushing data fails) can't post an error message on the bus as the return values of event pushing does do not contain enough information to decide if an (and which) error happened. Thus the pipeline silently fails and goes into EOS state without any error messages on the bus (note: this requires 0ca7b85ead53e6b8be76971d5b7003ef55c8e08c, without this the pipeline just waits for EOS forever). This could be solved by handling data-pushing-caused-by-EOS as a special case, and requiring elements to post error messages themselves on the bus in that case (instead of letting it handled by the element driving the pipeline as usual). Or we need flow returns for events.
As discussed on IRC the idea would be to let EOS return FALSE immediately, unlike other sticky events that only fail during data flow, if something goes wrong. This makes sense because no data will come after EOS anymore that could trigger a failure. This OTOH also means that demuxers and other multi-src elements need to combine event return values. If it returns FALSE for all pads, FALSE is it in general. If one returns TRUE it's TRUE. Elements driving the pipeline must post an error if pushing a sticky event failed. And elements that are failing in draining, i.e. due to an EOS event, have to post an error message on the bus too.
First part: commit 5a8c901507774aa6634c72e5ab0254b06dcbe2b2 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Mon Jun 4 11:25:47 2012 +0200 pad: Always return errors for EOS events immediately For non-EOS events things will error out later during data flow but after EOS events no data flow is happening. See bug #677340.
what happens if you have queues in the pipeline? The EOS push will succeed for the source, how does the error gets posted in this case?
The queue probably has to do that then, which might also make sense because it's driving that part of the pipeline.
Just spotted, but not sure if it actually fully does what's needed here commit e5a73cc2ffec5146171fc8aeb691e0c5580b4266 Author: Wim Taymans <wtaymans@redhat.com> Date: Wed Dec 11 14:42:34 2013 +0100 queue: don't ignore event return value Pass the event return value upstream. Remove strange goto construct.
It's not complete, no. But a bug that needed to be fixed for the above mentioned to work at all ;)
Is this still applicable ? If not, could the new event_full pad implementation help ? (they return GstFlowReturn instead of just booleans)
Yes, still happening. Just run the pipeline in the first comment :)
-- 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/24.