GNOME Bugzilla – Bug 781000
Unexpected ERROR if changing states while pushing a sticky event.
Last modified: 2018-11-03 12:40:28 UTC
Currently, if the downstream element is stopped or goes flushing while a sticky event is pushed downstream as caused by a buffer push, it will cause a castrophic failure as the gst_pad_push() will return GST_FLOW_ERROR. I think it should return GST_FLOW_FLUSHING instead, so that it can be safely ignored if a flush caused it.
Created attachment 349419 [details] [review] pad: Return FLUSHING and not ERROR on event failure Returning ERROR causes pipelines to fail on downwards state changes if you are unlucky and try to push an sticky event while stopping. Returning FLUSHING seems to have no adverse effects and gets the right result.
Created attachment 349420 [details] [review] test: Test that failed events return flushing When a sticky event reaches the sink and the sink is flushing, then the return value is FALSE, this should cause a gst_pad_push() that caused this event to flow forward to fail with GST_FLOW_FLUSHING.
Review of attachment 349419 [details] [review]: ::: gst/gstpad.c @@ +5615,3 @@ break; default: + ret = GST_FLOW_FLUSHING; Why do you fix this issue differently compare to all the other places ? We have fixed this by checking if the peer-pad has the flushing flag set in all other places.
This is in sink pad on the downstream side. It's not about the peer pad being flushing, but about the element. For example, basesrc returns FALSE for sticky events after a flush start.
-- 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/228.