GNOME Bugzilla – Bug 728872
GstGLBufferPool should avoid to allocate upload resources that are not going to be used for sure
Last modified: 2015-01-08 13:20:36 UTC
I wonder if we could avoid our glbufferpool to init its pool->priv->upload when the pipeline does not involve external elements that perform uploading, like webkitvideosink. Indeed our gl elements have their own gstglupload instance and call gst_gl_upload_perform_with_buffer (filter/sink->upload, ...) to do it. That will allow to save some resources. Indeed a gstglupload internally allocates a FBO and shaders. Depending on the gl implementation the FBO resource could be comparable to a texture (i.e. some impl optimize the allocation until a draw is fire) Worth to avoid that especially on embedded platforms. I guess there is something to manage with GST_VIDEO_GL_TEXTURE_UPLOAD_META_API_TYPE but I wonder how. And maybe something custom in upload_meta_params. To sum-up, currently videotestsrc ! glimagesink allocates 2 gstglupload and the one in the gstbufferpool is never used. (A gstglupload allocates gstglconvert / FBO / Shaders ... )
What about having elements ref the bufferpools glupload (if it exists)?
good idea ! Also I think the glupload should be created in gst_gl_buffer_pool_start, not in set_config.
commit b903c61cebfba19e975450ca79d5b13e8eed27d0 Author: Matthew Waters <ystreet00@gmail.com> Date: Thu May 1 16:07:05 2014 +1000 gl/pool: init the upload object on start Theoretically, set_config could be called multiple times
commit dfc674514388a5646f2108ea5f1d4c464101c950 Author: Matthew Waters <ystreet00@gmail.com> Date: Fri May 2 15:56:59 2014 +1000 gl: use the bufferpool's upload when available Avoids duplicating GL resources https://bugzilla.gnome.org/show_bug.cgi?id=728872
Created attachment 293951 [details] Image artefacts
Commit : dfc674514388a5646f2108ea5f1d4c464101c950 generate a side effect in the following case : rtspsrc ! rtph264parse ! vaapidecode ! glcolorscale ! video/x-raw, format=BGRx, width=640, height 480 ! videoconvert ! xvimagesink Observation : The video stream contains a bigger image than the output stream of the vaapidecode. This can be see by the arterfact at the image bottom. Hypothesis : The caps has been updated but the bufferpool not, images are correctly processed but in a bigger buffer. Correction : I tried to revert the commit on the 1.4.5 branch but it appears that something else generate this behavior (something between dfc674514388a5646f2108ea5f1d4c464101c950 and 1.4.5). Attached a screenshot of the image artefacts
Created attachment 293954 [details] [review] Attempt to revert on 1.4.5 attempt to correct this behavior on 1.4.5
Can you open a new bug for this?