The blend functions for alpha formats need to do more work than just
doing a memcpy, so we can do a memcpy when we know that a blend is not
actually needed.
1080p AYUV ! compositor background=transparent ! fakesink - 56% faster
Specifically, when we don't draw the background and the first pad we
draw completely covers the output frame, we can just copy it as-is.
The rest of the pads (if any) will get composited on top normally.
Add max-reorder property to make the old hard coded reordering limit of
100 configurable. It's particularly useful in some scenarios to set
max-reorder=0 to disable the behavior that the depayloader will drop
packets.
Note that although the default value is 100, the default limit has
increased with one because of the changed if-test. This was done to
allow the max-reorder value to be more intuitive. See tests.
If the background is transparent and obscured by a pad that may or may
not have alpha, we can still skip drawing it entirely
AYUV 1080p ! compositor background=transparent ! fakesink - 75% faster
We don't need to waste time drawing the background when one of the
pads completely covers the output and there's no alpha on the pad or
in the video format. Speedups:
I420 1080p ! compositor ! fakesink - 72% faster
I420 1080p ! compositor background=black ! fakesink - 45% faster
gst_gl_shader_string_get_highest_precision needs to make an OpenGL call
so execution outside the OpenGL thread and context results in undefined
behaviour.
Instead of checking if the requested GL API is GLES2 (because ANY can
be set) the string is matched with the GLES2 prefix, and if so, then
the string is offset.
RFC 7826 recommends (but does not require) starting at 0,
but at least one known server implementation fails to copy
request sequence numbers <1 into responses due to an
incorrect null check.
The server known to exhibit this behavior is the Parrot
Streaming Server, serving video from their UAV devices.
A fix has been submitted upstream as well:
https://github.com/Parrot-Developers/librtsp/pull/2
The Parrot developers are known to have tested with LibVLC.
In WireShark debugging, LibVLC appears to start with a CSeq
of 2, which is likely why this bug went unnoticed.
This reverts 487595a7d6, which set this to 0 citing the
RFC. The switch to 0 was thus a recent one; it's therefore
possible server implementors relied on the previous
GStreamer client behavior in their tests as well.
Fixes#624.
Continuation of 4fd7a2c783
We check the availability of the high precision floats in GLSL shaders
which involves an OpenGL call and thus is required to be executed on the
OpenGL thread.
The tests were not respecting that and could fail on more strict
drivers.
Tests update for 675415bf2e
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/590
We check the availability of the high precision floats in GLSL shaders
which involves an OpenGL call and thus is required to be executed on the
OpenGL thread.
The tests were not respecting that and could fail on more strict
drivers.
Tests update for 675415bf2e
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/590
valgrind gets confused with the following piece of code:
var37.i = ORC_CLAMP_SL((orc_int64)var33.i + (orc_int64)var34.i);
Where all variables are orc_int32
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
Removing gstalsadeviceprobe.[ch] as it was a relique from the 0.10
century.
This doesn't implement device monitoring but only probing, monitoring
should be implemented in its own commit.
This means we can use some newer features and get rid of some boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
The problem is that Gobject Introspections does not understand the const
gfloat matrix[16] as an matrix but as an array of gfloasts but as just
one gfloat.
To fix this i added the annotation to the parameter
descriptions.
