[Bug 792399] New: inputselector: always proxy context query

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 792399
           Summary: inputselector: always proxy context query
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: m.tretter at pengutronix.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 366596
  --> https://bugzilla.gnome.org/attachment.cgi?id=366596&action=edit
0001-inputselector-always-proxy-context-query.patch

The input selector should forward the GST_QUERY_CONTEXT for inactive pads,
because a context should be shared between multiple elements in a pipeline and 
elements that are linked via an input selector should share the same context.

In my concrete use case, I have a pipeline that has a vaapidecodebin and 
vaapisink with an input selector in between. The sink pad of the input
selector that is linked to the vaapidecodebin is not the active pad, but is
switched once the STREAM_START event arrives on that pad.

As soon as the first buffer arrives from the vaapipostproc at the vaapisink
and is looked up via the surface id, the vaapisink crashes, because it fails
to find the surface in its va context.

The problem is that the vaapipostproc element tries to get a va display from
the sink with a GST_QUERY_CONTEXT query, but the query is not correctly
forwarded by the input selector, because the sink pad is not the active pad.
Consequently, the vaapipostproc element creates a new display (and underlying
va context), which is distinct from the one the vaapisink is using. Therefore,
the elements are looking for the surface ids in different contexts.

I can work around this issue by using a funnel instead of the input selector
or by handling the HAVE_CONTEXT and NEED_CONTEXT messages in my application,
but I would expect that this is handled in the pipeline, because the elements
are already linked.

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