[Bug 769293] vaapi/gl : Uploading to GL texture optimization

[GStreamer (GNOME Bugzilla)]

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

--- Comment #8 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
Hyunjun,

And important thing to notice is to tests your patches not only with
glimagesink, but with clutter{auto}videosink (clutter-gst) which is the video
sink used by totem and totem is an important user of gstreamer-vaapi.

(In reply to Hyunjun Ko from comment #7)
> Created attachment 332784 [details] [review]
> Proof of Concept: Uploading to GL texture optimization
> 
> This is proof-of-concept patch to share opinions.
> 
> Changes are following:
> - Cut the relationship between GstVaapiVideoMetaTexture and VaapiTexture.
> - Then VaapiDisplay has hash table of VaapiTexture instances.
> - Each upload call, lookup same name of texture in the hash table and then
> use it.
> 
> This is working fine with previous glupload patch, with good performance.
> 
> Question is:
> 1. Is it correct taht placing VaapiTexture apart from
> GstVaapiVideoMetaTexture?

Looks correct to have a texture provider independent of the buffers.

> 2. Is it correct that VaapiDisplay has texture instances?

I don't know. I don't thinks so. Perhaps in GstVaapiDisplay{GLX/EGL}

> 3. If reconfigure happens, texture instances should be removed? If so, where?

Yes. Perhaps if the buffer to push has a different size of the current texture
provider configuration, we should reset all the cached textures.

> 4. If we should limit the hash table's size, what's maximum size?

I don't know.

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