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.
This came up in the case where v4l2 sets caps with colorimetry=NULL, and
then tries to parse back the colorimetry, causing a crash in
gst_video_get_colorimetry() because of g_str_equal(). We fix this by
making sure the only caller of the function never calls it with a null
colorimetry string.
SMPTE ST 2084 transfer characteristics (a.k.a ITU-R BT.2100-1 perceptual quantization, PQ)
is used for various HDR standard.
With ST 2084, we can represent BT 2100 (Rec. 2100). BT 2100 defines
various aspect of HDR such as resolution, transfer functions, matrix, primaries
and etc. It uses BT2020 color space (primaries and matrix) with PQ or HLG
transfer functions.
Protocols that are in the stream_uris list should always
be streams, no matter what they respond to the scheduling
query. The flag in the scheduling query is just another
way to declare something that needs buffering without the
whitelist, the absence of the flag shouldn't make us ignore
our known protocol list.
Also set is_stream always to a boolean and not a mask value.
