GNOME Bugzilla – Bug 753099
vaapi: deprecated / compat calls when using opengl3 profile
Last modified: 2015-11-30 16:25:01 UTC
GST_DEBUG=4,*gl*:5,*vaapi*:5 GST_GL_PLATFORM=glx GST_GL_API=opengl3 playbin uri=file:////opt/vliaskov/Videos/run01.mp4 video-sink=glimagesink The following errors are reported due to deprecated calls with opengl3 core profile: ERROR glcontext gstglcontext.c:1076:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_2D) ERROR glcontext gstglcontext.c:1076:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D) ERROR glcontext gstglcontext.c:1076:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_ENUM in glGetTexLevelParameter[if]v(pname=GL_TEXTURE_BORDER) ERROR glcontext gstglcontext.c:1076:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_ENUM in glDisable(GL_TEXTURE_2D) The glGetTexLevelParameter GL_TEXTURE_BORDER call is in gst-libs/gst/vaapi/gstvaapitexture_glx.c:276 !gl_get_texture_param (target, GL_TEXTURE_BORDER, &border_width)) The glIsEnabled(GL_TEXTURE_2D) and glEnable(GL_TEXTURE_2D) calls are at gst-libs/gst/vaapi/gstvaapiutils_glx.c:486 and 497
I was thinking about this issue. I still don't know, but I wonder if we can use libGstGL for all the GL handling, instead of our own walled garden. At first sight, that would impose a new dependency and a fast changing one, that might be a bit dangerous. But we could adapt faster to all those hairy GL environments. Anyway, I don't know if this idea makes sense at all.
Since you mentioned it, I wanted to ask why gstvaapi is using its own GL calls and not libGstGL.. perhaps it was not a conscious design choice but this simply happened since libgstgl started after (or indepedently of) gstvaapi? It will probably be quite a bit of work, but it sounds like using libGstGL (as all other gl elements do) would be the best way to provide stability for future vaapi/gl interactions. Other thoughts?
Since you mentioned it, is there a specific reason why gstvaapi is using its own GL calls and not libGstGL? Perhaps it was not a conscious design choice but this simply happened since libgstgl started after (or indepedently of) gstvaapi? It will probably be quite a bit of work, but it sounds like using libGstGL (as all other gl elements do) would be the best way to provide stability for future vaapi/gl interactions. Other thoughts?
There are some other long term plans with gstreamer-vaapi: -- Make core libgstvaapi as a separate library (gst-libs/gst/vaapi) -- Merge gstreamer plugins to upstream gstreamer. Most of the codec level complexities, rendering specific code, display server handling etc are involved in libgstvaapi library. Once we mange to remove the rest of gstreamer dependency from this, it will become a useful library for more than one project. This has a major benefit of having a common codebase for all va-api implementations in mulitple projects. Personally I wouldn't prefer to add more dependencies to libgstvaapi, which will complicate the things more when we think about a separate library... Please remember that these things are not finalized yet... :)
*** Bug 754900 has been marked as a duplicate of this bug. ***
*** Bug 745233 has been marked as a duplicate of this bug. ***
*** Bug 758499 has been marked as a duplicate of this bug. ***
In the case of clutterautovideosink (clutter-gst3.0) the warning message that describes this problem is: (gst-play-1.0:22235): Cogl-WARNING **: driver/gl/cogl-framebuffer-gl.c:1427: GL error (1280): Invalid enumeration value
The problem, as far as I understand it, is this: The function gst_buffer_add_texture_upload_meta() is executed in the GL context of the sink/app. This context can be in the supported version of OpenGL in that sink: it can be Legacy GL or OpenGL3 or even OpenGL4. We need to check in which version of OpenGL is the code running, and even more, which context profile, and choose which instructions of those supported by the context. The offender code basically gets the width and the height of the texture provided by the sink/app.
Created attachment 316299 [details] [review] libs: add gl_get_current_api() In order to know which OpenGL API use, we must detect the API type of current context. This patch adds the function gl_get_current_api() which returns the OpenGL API type. This function is an adaptation of gst_gl_context_get_current_gl_api() from GstGL. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 316300 [details] [review] libs: add gl3_bind_texture_2d() Since OpenGL3.1 removed the fixed pipelines[1] enabling 2D textures is not needed. In particular, the Intel's Mesa implementation complains if it is called. This patch add a new binding function for 2D textures, without enabling gl3_bind_texture_2d()[2]. 1. https://www.opengl.org/wiki/Fixed_Function_Pipeline 2. https://www.opengl.org/wiki/Common_Mistakes#OOP_and_hidden_binding Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 316301 [details] [review] texture: check for expected target and format gst_vaapi_texture_glx_new_wrapped() only handles a GL_TEXTURE_2D target and formats GL_RGBA or GL_BGRA. This patch adds a debugging verification of those values. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 316302 [details] [review] texture: detect GL version and use the proper API When receiving the texture from the application or the video sink, we must know it size and border. To query the texture the API has changed according to the OpenGL version used in the GL context of the application/vsink. This patch checks the current context API type and queries the texture according to this detected API. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hm, more code for the 0.7 release... Is there any way to postpone this? IIUC, the main intention of these patches is to make clutter-gst work with vaapi in the latest release (3.0.14), right?
(In reply to Víctor Manuel Jáquez Leal from comment #8) > In the case of clutterautovideosink (clutter-gst3.0) the warning message > that describes this problem is: > > (gst-play-1.0:22235): Cogl-WARNING **: driver/gl/cogl-framebuffer-gl.c:1427: > GL error (1280): Invalid enumeration value This pipeline is working for me (both gst1.4 and gst1.6) clutter-gst-3.0.14 OpenGL version string: 3.0 Mesa 10.6.3 gst-launch-1.0 filesrc location= sample.mp4 ! qtdemux ! queue ! vaapiparse_h264 ! vaapidecode ! clutterautovideosink
(In reply to sreerenj from comment #15) > (In reply to Víctor Manuel Jáquez Leal from comment #8) > > In the case of clutterautovideosink (clutter-gst3.0) the warning message > > that describes this problem is: > > > > (gst-play-1.0:22235): Cogl-WARNING **: driver/gl/cogl-framebuffer-gl.c:1427: > > GL error (1280): Invalid enumeration value > > This pipeline is working for me (both gst1.4 and gst1.6) > clutter-gst-3.0.14 > OpenGL version string: 3.0 Mesa 10.6.3 > > gst-launch-1.0 filesrc location= sample.mp4 ! qtdemux ! queue ! > vaapiparse_h264 ! vaapidecode ! clutterautovideosink Also tested with, OpenGL version string: 3.0 Mesa 11.0.6 cogl: 1.22.0 clutter-gst: 3.0.14 Didn't see any issue!
Ok, I managed to reproduce it. This is related with recent clutter version, reproducible with clutter-1.24.2 and not with older clutter-1.22.2 :)
Patches lgtm ...
tested in gstreamer 1.4, 1.6, master and in debian testing with Totem and Iceweasel. In Iceweasel I see this message: (iceweasel:13916): GStreamer-WARNING **: Failed to load plugin '/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so': dlopen: cannot load any more object with static TLS But this is another issue. But, all in all, it seems to work fine. Pushing.
Attachment 316299 [details] pushed as 03fed57 - libs: add gl_get_current_api() Attachment 316300 [details] pushed as da835c7 - libs: add gl3_bind_texture_2d() Attachment 316301 [details] pushed as 1e39b59 - texture: check for expected target and format Attachment 316302 [details] pushed as 4897d96 - texture: detect GL version and use the proper API