Created attachment 366596 [details] [review]
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.