[Bug 743687] playback: gstreamer-vaapi doesn't work with Totem master

[GStreamer (GNOME Bugzilla)]

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

--- Comment #40 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
As usual, I think Edward is right :)

After debugging I found that part of the  problem is in gstreamer-vaapi, which
I state in bug #744618 :

Currently, in vaapidecode, the src caps are set immediately after the sink caps
are negotiated, but at that moment the pipeline may not be fully constructed
and the video sink has not negotiated its supported caps. In this case, the
forced feature is the least optimized one: memory:SystemMemory and I420 color
format. Even more, the reconfiguration events in downstream are ignored.

The first patch (attachment #297391) tries to solve this problem delaying the
src caps negotiation until the first frame in handled. Also it checks if the
caps in the src pad need to be reconfigured.


Nevertheless, I found *another* problem, which is not related with
gstreamer-vaapi in my opinion, but with the caps negotiation during the
auto-plugin in the playback:

vaapidecode always adds to its buffer pool the configuration option
GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META if the
decide_allocation()'s query has GST_VIDEO_GL_TEXTURE_UPLOAD_META_API_TYPE.

There are occasions where the query has the API type, but the negotiated src
caps don't have the feature meta:GstVideoGLTextureUploadMeta but
memory:SystemMemory.

An example of this case occurs with
https://hadess.fedorapeople.org/bug743687.mkv rendering ClutterAutoVideoSink:
after several caps re-negotiations they are settle as memory:SystemMemory with
I420 format, though during the decide_allocation() the vaapidecoder buffer pool
enables the options GLTextureUplodMeta because the query has the API type. 

Under this contradiction, vaapidecode adds the GLTextureUploadMeta API to its
buffer pool configuration, and adds its buffer's meta to each output buffer,
even if the negotiated caps feature is memory:SystemMemory with I420 color
format.

As a result, ClutterAutoVideoSink doesn't render any buffer since its gl upload
method for I420 buffers is a no-op.

The second patch (attachment #297746) workarounds this situation by only adding
the option GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META to the
vaapidecode buffer pool *if* the query has the API type *and* the negotiated
caps feature is meta:GstVideoGLTextureUploadMeta.

In my opinion I should open another bug for this issue in playback. What do you
think?

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