This was miss-leading VAAPI which was not forcing linear back buffers,
would still export DMABuf. That caused bad rendering as the buffers are
tiled and most likely compressed.
https://bugzilla.gnome.org/show_bug.cgi?id=796822
This was miss-leading VAAPI which was not forcing linear back buffers,
would still export DMABuf. That caused bad rendering as the buffers are
tiled and most likely compressed.
V4L2 and OMX decoder don't support draining and keeping reference
frames. As a side effect, these decoder just stops working on
gaps/discont. When this drain was introduced, the commit stated that
this was for TRICKMODE_KEY_UNITS, so only drain if running in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=796771
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.
We would make the subproject conditional on the wrap-mode=nodownload
however get_option('wrap-mode') or similar is not available from
meson.build files as the wrap-mode is meant to be used automatically.
Instead use the dependency fallback mechanism to get at the subproject
where possible i.e. when downloading is allows and only add the compat
includes when we have a valid internal dependency from the gl-headers
subproject.
https://bugzilla.gnome.org/show_bug.cgi?id=796534
Helper function for bindings, in python for example
users can now replace:
res, msg = GstSdp.SDPMessage.new()
GstSdp.sdp_message_parse_buffer(bytes(text.encode()), msg)
with:
res, msg = GstSdp.SDPMessage.new_from_text(text)
https://bugzilla.gnome.org/show_bug.cgi?id=796563
This reverts commit 82c43ff9a3.
Reverting for the time being, since it trips up build bots
that don't have network connectivity.
We ideally shouldn't have a subproject that's used unconditionally.
The external time should be moved only as much as needed
to get back to the ideal center point, so that the clock
is still allowed to drift both directions after the correction.
This reduces excessive back and forth corrections that were
caused by the assumption of a linear drift.
https://bugzilla.gnome.org/show_bug.cgi?id=788006
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
