After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753099 - vaapi: deprecated / compat calls when using opengl3 profile
vaapi: deprecated / compat calls when using opengl3 profile
Status: RESOLVED FIXED
Product: gstreamer-vaapi
Classification: Other
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
: 745233 754900 758499 (view as bug list)
Depends on:
Blocks: 750547 755406
 
 
Reported: 2015-07-31 11:11 UTC by Vasilis Liaskovitis
Modified: 2015-11-30 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
libs: add gl_get_current_api() (3.99 KB, patch)
2015-11-26 10:35 UTC, Víctor Manuel Jáquez Leal
committed Details | Review
libs: add gl3_bind_texture_2d() (4.43 KB, patch)
2015-11-26 10:35 UTC, Víctor Manuel Jáquez Leal
committed Details | Review
texture: check for expected target and format (1.45 KB, patch)
2015-11-26 10:35 UTC, Víctor Manuel Jáquez Leal
committed Details | Review
texture: detect GL version and use the proper API (3.22 KB, patch)
2015-11-26 10:35 UTC, Víctor Manuel Jáquez Leal
committed Details | Review

Description Vasilis Liaskovitis 2015-07-31 11:11:47 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
Comment 1 Víctor Manuel Jáquez Leal 2015-08-06 17:32:59 UTC
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.
Comment 2 Vasilis Liaskovitis 2015-08-06 22:54:51 UTC
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?
Comment 3 Vasilis Liaskovitis 2015-08-06 22:55:44 UTC
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?
Comment 4 sreerenj 2015-08-07 06:41:34 UTC
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... :)
Comment 5 Víctor Manuel Jáquez Leal 2015-09-22 10:37:47 UTC
*** Bug 754900 has been marked as a duplicate of this bug. ***
Comment 6 Víctor Manuel Jáquez Leal 2015-11-19 17:34:55 UTC
*** Bug 745233 has been marked as a duplicate of this bug. ***
Comment 7 Víctor Manuel Jáquez Leal 2015-11-23 15:14:48 UTC
*** Bug 758499 has been marked as a duplicate of this bug. ***
Comment 8 Víctor Manuel Jáquez Leal 2015-11-23 15:35:09 UTC
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
Comment 9 Víctor Manuel Jáquez Leal 2015-11-25 11:19:48 UTC
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.
Comment 10 Víctor Manuel Jáquez Leal 2015-11-26 10:35:31 UTC
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>
Comment 11 Víctor Manuel Jáquez Leal 2015-11-26 10:35:38 UTC
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>
Comment 12 Víctor Manuel Jáquez Leal 2015-11-26 10:35:49 UTC
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>
Comment 13 Víctor Manuel Jáquez Leal 2015-11-26 10:35:59 UTC
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>
Comment 14 sreerenj 2015-11-27 14:52:26 UTC
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?
Comment 15 sreerenj 2015-11-27 17:09:44 UTC
(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
Comment 16 sreerenj 2015-11-28 21:37:23 UTC
(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!
Comment 17 sreerenj 2015-11-28 22:29:45 UTC
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 :)
Comment 18 sreerenj 2015-11-30 10:39:36 UTC
Patches lgtm ...
Comment 19 Víctor Manuel Jáquez Leal 2015-11-30 16:23:04 UTC
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.
Comment 20 Víctor Manuel Jáquez Leal 2015-11-30 16:24:38 UTC
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