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
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.
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
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
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
