Running the context query in _start and during the NULL->READY state transition
can fail because downstream elements might not be able to answer and thus the
source element would not be able to reuse downstream GLContext and GLDisplay.
This issue happened specifically when trying to use gltestsrc in playbin.
Without this, a buffer is dropped if glupload indicates that it is
necessary to reconfigure.
Avoid this by explicitly reconfiguring immediately and uploading the buffer
again.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Fixes the internal viewconvert to not scale buffers for output with the
following pipeline:
gltestsrc ! glimagesink
It also fixes overlay composition with a resized output with an OpenGL
upstream:
gltestsrc ! timeoverlay ! glimagesink
Attempting to use the MAX(1, display_rect) would result in the overlay
composition attempting to draw into 1x1 buffer and calculate some
grossly incorrect sizes.
previously failing case:
gltestsrc ! textoverlay text=GStreamer ! glimagesinkelement
Without this, a buffer is dropped if glupload indicates that it is
necessary to reconfigure.
Avoid this by explicitly reconfiguring immediately and uploading the buffer
again.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This effectively (but optionally) requires libjpeg-turbo which
ships with a .pc file and is what pretty much everyone these days
uses anyway for libjpeg, so shouldn't be a problem hopefully.
https://bugzilla.gnome.org/show_bug.cgi?id=796947
Matches the output from a similar glimagesink pipeline when
rotating from an upstream gltransformation passed through
the affine transformation meta with xpos/ypos being set.
https://bugzilla.gnome.org/show_bug.cgi?id=794401
e4bf9ed8f0 was not quite right and changed
the wrong thing. Intead we needed to change the multiplication order
and should have kept the previous to/from matrices as is done in this
patch.
The matrices were converting the wrong values with non-diagonal-only matrices.
e.g. a typical yflip matrix in [-1,1]^3 such as
1 0 0 0
0 -1 0 0
0 0 1 0
0 0 0 1
Would have actually required a matrix like this in [0,1]^3
1 0 0 0
0 -1 0 0
0 0 1 0
0 -2 0 1
Which is
1. not consistent with our multiplication convention and would require
transposing matrices or changing our multiplication order (from what is
generally used on opengl matrix guides/tutorials).
2. Produces incorrect values when input with actual vertices accounting for
the difference in multiplication order. e.g. some vertices multiplied by
the yflip matrix using vertex * yflip(== transpose(yflip) * vertex):
vertex: -> result: expected:
vec4(1,0,1,1) -> vec4(1,-2,1,1) vec4(1,1,1,1)
vec4(1,1,1,1) -> vec4(1,-3,1,1) vec4(1,0,1,1)
With the updated values, we now get the expected values.
Includes a test for this behaviour and the example above
glcolorbalance is in the default GL path inside glimagesink,
so has been causing an possibly-unnecessary extra texture copy
on Android for a while now. If we're just doing passthrough,
we can support OES directly. If not, they'll be transformed
to 2D textures and colourbalanced.
This moves all the conversion related code to a single place, allows
less code-duplication inside compositor and makes the glmixer code less
awkward. It's also the same pattern as used by GstAudioAggregator.
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.
It performs similarly to the existing alpha element however performs
calculations in floating point rather than with small (guint8) integers
so some differences are to be expected.
https://bugzilla.gnome.org/show_bug.cgi?id=794070
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.
When doing a 3D/multiview transformation and rescaling to
match the output window size, the resulting PAR may
not match the input any more and needs recalculating,
or else the GstSample reported to client-draw has the
wrong PAR.
Even if the input is monoscopic, the app might want to display
it in a different layout, to do side-by-side for VR for example,
so if the app changes the output-multiview-mode always use that.
We can either receive an element that is floating or not and need to
accomodate that in the signal return values. Do so by removing the
floating flag.
https://bugzilla.gnome.org/show_bug.cgi?id=792597
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
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 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
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
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
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
