mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-24 10:41:04 +00:00
71d3ce4de2
Working on bug #743687, I realized that vaapidecode always adds to its buffer pool the config 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. Nevertheless, there are occasions where the query has the API type, but the last negotiated caps don't have the feature meta:GstVideoGLTextureUploadMeta. 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. This kind of output buffers chokes ClutterAutoVideosSink, since it uses a map that relates caps <-> GL upload method. If it receives a buffer with color format I420, it assumes that it doesn't have a texture upload meta, because only those with RGB color format has it. Our buffers, with I420 format, say that they have the upload meta too. In that case the mapped method is a dummy one which does nothing. I reported this issue in bug #744039 (the patch, obviously, was rejected). This patch workarounds the problem: the buffer pool's configuration option GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META is set if and only if the query has the GST_VIDEO_GL_TEXTURE_UPLOAD_META_API_TYPE *and* the negotiated caps feature is meta:GstVideoGLTextureUploadMeta. I have tested these patches with gst-master (1.5), gst-1.4 and gst-1.2 and in all they seem to work correctly. https://bugzilla.gnome.org/show_bug.cgi?id=744618 [adapted to fit current EGL changes] Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com> |
||
---|---|---|
.. | ||
vaapi | ||
Makefile.am |