GNOME Bugzilla – Bug 712798
videometa: add GstVideoGLTextureUploadMeta buffer pool option
Last modified: 2013-11-26 13:05:34 UTC
In order to configure the meta attached to buffers, a buffer pool option for GstVideoGLTextureUploadMeta need to exist. This is sperate to the caps feature in that an element may want/need to add the upload meta itself rather than allowing the buffer pool to.
Created attachment 260421 [details] [review] videometa: add GstVideoGLTextureUploadMeta buffer pool option
What exactly is the use case for this?
As a result of gstreamer-vaapi https://bugzilla.gnome.org/show_bug.cgi?id=712558
Why would the one added by the element be different/better than the one added by the buffer pool? For the vaapidecode ! glimagesink case it sounds more like the decoder should use its own buffer pool.
vaapi already does use its own bufferpool based on vasurfaces and rejects our glbufferpool in the vaapidecode ! glimagesink case. Currently in that case, adding the texture upload meta in the decoder results in a huge performance loss due to vaapitexture creation/deletion resulting in *MakeCurrent being called at least twice every frame. Bug #712558 is about trying to add the meta inside a vaapi buffer pool (the current one or a new gl texture buffer pool they might decide to create). So the problem is that the buffer pool needs to know if it needs to add texture upload meta (if the bufferpool supports it). Whether that is by capsfeatures or the above buffer pool option was discussed on irc. It was argued that capsfeatures were used for negotiation and the bufferpool option falls under the category of configuring the allocation which apparently are seperate concepts. Adding the bufferpool option falls more in line with the other videometa's (crop, alignment) which have their own bufferpool options and so has appeal from a consistency standpoint. Also, an element might use a gst library (of a possible multiple) that provides a bufferpool (or multiple) with (or without) support for the upload meta for whatever reason. With the bufferpool option, the element can check at runtime whether the bufferpool supports the upload meta or whether the element needs to add the meta itself because it might have more information than the bufferpool. Total pie in the sky concept however the concept remains. Choosing between multiple bufferpools. e.g. EGLImage vs GL texture. Another also, there's the option of selectively enabling the upload meta based on other parameters such as whether the OpenGL context's (or other hw-specific/API data) are (not) shared between the elements. In short, the element knows better, let it decide.
So how would this be used in the vaapi problem you mentioned? I'm not sure I completely understand the problem yet as I don't see how it is related to this buffer pool configuration. (In general I think it's a good idea to add this, independent of this use case)
Convenience and similarity with how the videometa enablement is currently handled in the bufferpools.
Ok, so that alone doesn't fix this problem and it's just for convenience? :)
commit 2e84acce582a33cd2268d87b969d4bacff705233 Author: Matthew Waters <ystreet00@gmail.com> Date: Thu Nov 21 22:54:42 2013 +1100 videometa: add GstVideoGLTextureUploadMeta buffer pool option allows configuration of whether GstVideoGLTextureUploadMeta is added to buffers resulting from a buffer pool. This is sperate to the caps feature in that an element may want to add the upload meta itself rather than allowing the buffer pool to. https://bugzilla.gnome.org/show_bug.cgi?id=712798