GitLab

As documented, passing -1 to x and/or y should reset the render
rectangle to the window/display size.

https://bugzilla.gnome.org/show_bug.cgi?id=792798

This allow controlling the render rectangle from gst-launch-1.0.

https://bugzilla.gnome.org/show_bug.cgi?id=792798

Alsasrc introduced delay_lock in commit 519f85a4
because alsa-lib is not thread safe for the same handle.
Alsasrc uses the same threading pattern, it should be locked too.

https://bugzilla.gnome.org/show_bug.cgi?id=746015

If width or height are zero ... there's no video :)

So that the tests have access to them as well (gl-launch-lines.c)

error: "HAVE_PNG" is not defined, evaluates to 0 [-Werror=undef]

Tests and documentation will follow separately.

The mixer elements in the opengl plugin need to stay
in -bad for now since they use GstVideoAggregator.

https://bugzilla.gnome.org/show_bug.cgi?id=754094

When compiling with clang, an enum conversion error is triggered
since GstVideoFrameFlags are not GstVideoFlags.

This patch sets GST_VIDEO_FRAME_FLAG_NONE to the added video meta.

https://bugzilla.gnome.org/show_bug.cgi?id=791251

This fixes the build for platforms that don't support one or the other.

This patch adds code to gldownload to export the image as a
dmabuf if requested.  The element now exposes memory:DMABuf as
a cap feature, and if it is selected, the element exports the
texture to an EGL image and then a dmabuf. It also implements a
fallback to system memory download in case the exportation failed.

https://bugzilla.gnome.org/show_bug.cgi?id=776927

https://bugzilla.gnome.org/show_bug.cgi?id=739010

Allows keeping the GstGLCAOpenGLLayer public but not the winsys-specific
context/display/window.

This posed problems for the python bindings (and possibly others).

Instead, subclasses now use add_pad_template_with_gtype.

https://bugzilla.gnome.org/show_bug.cgi?id=789986

So we don't result in a critical when we've never created the GL context:

gst_gl_context_thread_add: assertion 'GST_IS_GL_CONTEXT (context)' failed

Calling GL functions not on the GL thread may crash in some GL
implementations.

https://bugzilla.gnome.org/show_bug.cgi?id=789665

Instead of gst_aggregator_iterate_sinkpads() which will
soon be removed.

https://bugzilla.gnome.org/show_bug.cgi?id=785679

https://bugzilla.gnome.org/show_bug.cgi?id=788127

This reverts commit d6e538dc5651fb03c85d7c7614bcf6c689f2db2f.

Need update output geometry when sink caps changed and use
gst_structure_set to update caps if structure is fixed

https://bugzilla.gnome.org/show_bug.cgi?id=787820

when using internal window, window resize should work
when pause state, but expose only do redisplay when
window_id is valid. So expose should do redisplay all
the time.

https://bugzilla.gnome.org/show_bug.cgi?id=787394

When tee is used, it will not request a pool, but still it wants to
know how many buffers are required.

https://bugzilla.gnome.org/show_bug.cgi?id=730758

- correct the matrix multiplication
- Use column-major matrices
  - reverse order of matrix multiplications

https://bugzilla.gnome.org/show_bug.cgi?id=785980

Drawing 5 vertices with GL_TRIANGLE_STRIP will draw an extra unneeded
triangle.

Can reproduce after installing libgraphene-dev

Also fixes caopengllayersink.h to anticipate build error on osx.

https://bugzilla.gnome.org/show_bug.cgi?id=784779

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 output caps will only change on a set_caps() call, so check if
they contain the SystemMemory feature then and save some
per-buffer CPU.

Add a function to install the default RGBA pad templates,
but don't make them required so that there can be
GstGLFilter sub-classes with different input/output
caps if they want. Remove the hard-coded RGBA restriction in
the set_caps_features call, as it will be taken care
of by intersecting with the pad templates.

Update all the sub-classes to match

https://bugzilla.gnome.org/show_bug.cgi?id=782947

This is now all handled in GstAggregator, so this code is not
called anymore.

https://bugzilla.gnome.org/show_bug.cgi?id=782918

https://bugzilla.gnome.org/show_bug.cgi?id=746529

https://bugzilla.gnome.org/show_bug.cgi?id=746529

https://bugzilla.gnome.org/show_bug.cgi?id=746529

Modelled off the videoaggregator caps handling as that seems the most
mature aggregtor-using implementation that has caps handling there is.

https://bugzilla.gnome.org/show_bug.cgi?id=776931

Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.