GNOME Bugzilla – Bug 701742
create GLX buffers first
Last modified: 2013-07-16 04:48:16 UTC
The g_display_map list imply an order of display creation. I think is best to try GLX before X11 for the texture uploading purpose.
Created attachment 246167 [details] [review] pluginsutil: GLX first
Hi, this was actually the case before (0.4-branch), but I re-ordered to prefer X11 over GLX, so that vaapisink uses a VA/X11 display by default, which will be more efficient than VA/GLX for 2D rendering. Do you still have an issue with the current approach? I normally fixed the GstVaapiDisplay cache nowadays, so if you get a bus message with VA/GLX display, then we should correctly get a real VA/GLX capable display, and not a VA/X11 one.
In webkit, we have our own video sink, and I can't foresee how I could ask for a VA/GLX display without linking gstreamer-vaapi directly.
Ah, ok, in clutter-gst we used to implement the GstVideoContext interface, or replying to the prepare-context bus message. This works without linking in libgstvaapi. Though, I saw in the other bug report that you are currently working with 1.2.x APIs (GstContext et al.), and that probably doesn't provide the same set of features?
(In reply to comment #4) > Ah, ok, in clutter-gst we used to implement the GstVideoContext interface, or > replying to the prepare-context bus message. This works without linking in > libgstvaapi. Though, I saw in the other bug report that you are currently > working with 1.2.x APIs (GstContext et al.), and that probably doesn't provide > the same set of features? mmmh... perhaps I missed those bits. Anyway, to add something that is decoder-specific won't be landed in WebKit, I'd bet :/
OK, you are both (+Lionel) right. Even though the enabling code in application is rather small, that's still the same similar code that needs to be copied over to several applications. The better option would be based on your patch, but with several additions: - Re-introduce the "use-glx" property in vaapisink to enable VA/GLX rendering, but keep it disabled so that we default to using vaPutSurface() even with VA/GLX displays ; - Some better heuristics to disambiguates Wayland / X11|GLX in the situations were vaapidecode, and libgstvaapi actually, has support for all display servers and we happen to run two of them in parallel. e.g. Weston/X11 + regular X server.
Adding Lionel so that he could also track the status of this one.
Merged into git master branch, and added a "use-glx" property to explicitly use OpenGL rendering in vaapisink (which is useless per se). Please report if this suits your purposes. Thanks.
commit ece5cb2d83d41fdecef4bbda874208b2089fb33a Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Thu Jun 27 13:53:46 2013 +0200 vaapisink: add "use-glx" property for OpenGL rendering. Now that VA/GLX capable buffers are generated by default on X11, thus depending on a VA/GLX display, we stil want to use vaPutSurface() for rendering since it is faster. Anyway, OpenGL rendering in vaapisink was only meant for testing and enabling "fancy" effects to play with. This has no real value. So, disable OpenGL rendering by default. commit 2fafbd7b64fc8f9deb14af58a0e40d2c5ebf7f22 Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Date: Thu Jun 6 05:36:03 2013 -0400 plugins: try to allocate a GLX display first over an X11 one. If the gstreamer-vaapi plug-in elements are built with GLX support, then try to allocate a GstVaapiDisplayGLX first before resorting to a VA/X11 display next. https://bugzilla.gnome.org/show_bug.cgi?id=701742