[Bug 757821] New: New GstPadEventFunction which returns a GstFlowReturn

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 757821
           Summary: New GstPadEventFunction which returns a GstFlowReturn
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bilboed at bilboed.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Currently pushing events on a pad returns a gboolean value.

While on its own this is not problematic, it causes issues with sticky event
propagation.

The use-case is the following:
* Two elements (element1 and element2) are linked
* There are sticky events that need propagating from element1:src to
element2:sink
* element1 pushes a buffer (gst_pad_push())
* gst_pad_push calls check_sticky() before doing the actual push. Note that if
check_sticky() returns something else than GST_FLOW_OK, that flowret is
returned straight away.
* check_sticky() calls push_sticky for all events
** push_sticky() calls gst_pad_push_event_unchecked () (which returns a
GstFlowReturn)
*** gst_pad_push_event_unchecked() will eventually call
gst_pad_send_event_unchecked () (which returns a GstFlowReturn) on the peer
pad.
**** gst_pad_send_event_unchecked() will call the GstPad GstEventFunction
(which returns a ==>gboolean<==). Based on that boolean return value, and the
type of event, that function will return a certain GstFlowReturn.

And this is where the problem lies ...

  ==> Some asynchronous elements, such as the various *queue elements, will
return FALSE if downstream is flushing (i.e. the last buffer push returned
GST_FLOW_FLUSHING).
  ==> core cannot see that it is returning FALSE because downstream is flushing
  ==> Depending on the type of event, it will transform that FALSE into
GST_FLOW_NOT_NEGOTIATED or GST_FLOW_ERROR
  ==> That flow return trickles all the way upstream and we get a failure

And in a more generic fashion, this is breaking the rationale that
GstFlowReturn should be properly propagated upstream. In this case it is broken
(GstFlowReturn from downstream of an element is not propagated to the upstream
push, due to the sticky event step).


I'm open to other proposals on how to fix this, but I'd say a simple way
forward would be to create:
* a new GstFlowReturn GstPadEventFullFunc(GstPad*, GstObject *, GstEvent*);
* a new GstPad eventfullfunc
* If the eventfullfunc is present, call that in gst_pad_send_event_unchecked()
and use that GstFlowReturn directly, else do the standard code path

Comments/Feedback welcome

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