The aggregated_frame is now called prepared_frame and passed to the
prepare_frame and cleanup_frame virtual methods directly. For the
currently queued buffer there is a method on the video aggregator pad
now.
Previously we assumed that the texture ID is going to be valid even
after unmapping the frame, as it was immediately unmapped before even
being used. Now we only unmap once we're done with the texture.
We call the base class first as this will remove the pad from
the aggregator, thus stopping misc callbacks from being called,
one of which (process_textures) will recreate the vertex_buffer
if it is destroyed
https://bugzilla.gnome.org/show_bug.cgi?id=760873
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
The same symbol also exists in libgstgl, although marked as private and
internal. This has no effect when doing static linking and there's a
symbol conflict.
gst_caps_intersect () may return an increased reference of one of the
input caps.
Fixes critical in the simple-launch-lines test:
Unexpected critical/warning: gst_caps_set_features: assertion 'IS_WRITABLE (caps)' failed
glvideomixer does not support it currently and it needs special support
for handling this correctly, and is rather non-trivial to implement for
all formats.
The videoaggregator negotiation sequence changed some time
back and broke glstereomix. Instead of doing nego incorrectly
in the find_best_format() vfunc, do it directly in the
update_caps() method.
Facilities are given to create fbo's and attach GL memory (renderbuffers
or textures). It also keeps track of the renderable size for use with
effective use with glViewport().
_get_gl_context() can be called concurrently from either propose_allocation() or
decide_allocation(). If it so happens that this happens at the same time,
the check for whether we already had a GL context was outside the lock. Inside
the lock and loop, the first thing that happens is that we unref the current GL
context (if valid) as if there was a conflict adding it to the display. If the
timing was unlucky, subsequent use of the GL context would be referencing an
already unreffed GL context object resulting in a critical:
g_object_ref: assertion 'object->ref_count > 0' failed
https://bugzilla.gnome.org/show_bug.cgi?id=766703
Provide a function to get the affine matrix in the meta in terms of NDC
coordinates and use as a standard opengl matrix.
Also advertise support for the affine transformation meta in the allocation
query.
We were always failing the allocation query as a flag was never being set to
signal a successful negotiation. Fix by setting the required flag on a
successful caps event from upstream.
We weren't using the result of find_best_format at all.
Also, move the find_best_format usage to the default update_caps() to make
sure that it is also overridable.
https://bugzilla.gnome.org/show_bug.cgi?id=764363
We want to iterate over all the pads, not just the first one. Fix by returning
TRUE in the GstAggregatorPadForeachFunc.
Removes a GST_IS_GL_CONTEXT() assertion on shutdown with >2 inputs
using gst-launch.
