gst_video_frame_map() will store an updated video info base
on the video meta. In order to have the right stride and offset
we should update that video info accordingly.
The target texture of an EGLImage is the texture bind just
before calling glEGLImageTargetTexture2D.
As we currently only support a gl texture as the source of an EGLImage
the gl texture is actually already allocated when creating the eglimage.
I also see some cases where it fails to upload an eglimage when
glTexImage2D is called on the target.
GST_GL_WINDOW is used for window system specific choices.
An EGLDisplay can be created from window systems with egl support by using
eglGetDisplay().
https://bugzilla.gnome.org/show_bug.cgi?id=729551
This commit makes the loading of the GModules threadsafe, and
always first tries to load the symbol for the GL library that
is selected for the current context. Only then it falls back
to looking into the current module (NULL), and only as a last
resort the context specific function (e.g. eglGetProcAddress())
is called.
Also add configure parameters to select the names of the library
modules instead of using the defaults, and let the defaults be
independent of the G_MODULE_SUFFIX.
https://bugzilla.gnome.org/show_bug.cgi?id=728753
Previously, we used the width to determine the amount of data to be
copied using pbos. This, makes it allocate enough data for the
the strides as well.
Most of our 2D filters use the same simple vertex shader.
Also define the default fragment shader as the identity.
Avoid duplicating the same vertex and fragment shader text.
This should fix QoS problems, where basesink believed it was rendering with
20FPS but actually we were just queueing up X11 Expose events and only once
in a while something was rendered.
I was lucky that:
e1 = vc_dispmanx_element_add ()
eglCreateWindowSurface (e1)
vc_dispmanx_element_remove (e1)
e2 = vc_dispmanx_element_add ()
resulted in having e2 equal to e1. And also having the egl surface
that does not allocate its buffers before the first draw.
It avoids to draw to an invalid buffer.
Withtout this the default frame buffer is undefined:
glBindFramebuffer (GL_FRAMEBUFFER, 0)
Visually you could see some white frames at the beginning
when lunching videotestsrc ! glimagesink
With OpenGL Profiler from XCode you could see some
GL_INVALID_FRAMEBUFFER_OPERATION for the first frames
"(NSApplication *)sharedApplication This method also makes a connection
to the window server and completes other initialization"
The implicit thing which is not mentioned is that it required
to be called in the main thread.
Fix a regression introduces by 82b7c915bb
When using with gst-launch, it was not possible to click on the close
cross of the window anymore which is a bit anoying and also because
it's was possible before.
Prior to this commit the GstGLContextCocoaClass was initialized
in the main thread because gst_gl_context_new was called in the
state change function from going from ready to paused.
From this commit this call is done from the streaming thread.
So that the call to [NSApplication sharedApplication];
was not done in the main thread anymore.
We now ensure that by assuming there is a GMainLoop running.
It's for debugging purpose so that's ok to do that. Also
note we already do this assumtion to run app itereations.
The regression had no consequence on the cocoa/videooverlay example
(that should be moved from gst-plugins-gl to -bad) because the
application is responsible for that necessary call.
This patch provides the basic infrastructure required for this.
Upload and Download has been ported to this.
Has the nice effect of allowing GstGLMemory to be our
refcounted texture object for any texture type (not just RGBA).
Should not lose any features/video formats.
As the relevant variables are initialized to 0/NULL, we can loop
over the full range and make sure we free partial allocations
when an error happens partway through initialization.
Mesa, for example returns valid pointers for glGetIntegerv and
glGetStringi even if the gl version is less than that required for
both those functions to supposedly exist.
https://bugzilla.gnome.org/show_bug.cgi?id=727324
* picked from old libgstegl:
- GstEGLImageMemory
- GstEGLImageAllocator
- last_buffer management from removed GstEGLImageBufferPool
* add-ons:
- GstEGLImageMemory now old a reference on GstGLContext
so that it can delete the EGLImage and its gltexture source
while having the associated gl context being current.
- add EGLImage support for GstVideoGLTextureUploadMeta which
mainly call EGLImageTargetTexture2D
- GstGLBufferPool now supports GstEGLImageAllocator
- glimagesink / glfilters / etc.. now propose GstEGLImageAllocator
to upstream
https://bugzilla.gnome.org/show_bug.cgi?id=703343
