This allows users to let videorate fully fill the segments when received
EOS or on new segment, removing an arbitrary limit of 25 duplicates which
might not be what the user wants (for example on low FPS stream in GES,
that sometimes leaded to broken behavior)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3000>
when expose-all=False
When trying to find an decoder in that case, we loop over the different
decoder factories, and check that it outputs a format that matches the
requested one (through the :caps property), but if we find a decoder
that do match but later on some other don't we end up failing
autopluging. This patch ensures that we still plug the decoder that can
work.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3011>
We are supposed to guarantee that pads that are exposed have the caps
set, but for sources that have pad with "all raw caps" templates, we end
up exposing pads that don't have caps set yet, which can break code (in
GES for example).
To avoid that we let uridecodebin plug a `decodebin` after such pads and
let decodebin to handle that for us. In the end the only thing that
decodebin does in those cases is to wait for pads to be ready and expose
them, after that `uridecodebin` will expose those pads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3009>
GLib made the unfortunate decision to prevent libgobject from ever being
unloaded, which means that now any library which registers a static type
can't ever be unloaded either (and any library that depends on those,
ad nauseam).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/778>
Newer compilers ( clang 15 ) have turned stricter and errors out instead
of warning on implicit function declations
Fixes
gstssaparse.c:297:12: error: call to undeclared library function 'isspace' with type 'int (int)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
while (isspace(*t))
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2879>
When a new segment event arrives, it immediately updates
the current stored segment, which was used for calculating
the running time of the current text buffer for every
passing video frame. This means a segment that arrives
after the text buffer might get used to (mis)calculate
the running times subsequently.
Instead, calculate and store the right running time
using the current segment when storing the buffer. Later
the stored segment can get freely updated.
This fixes the case where pieces of video and text streams
are seamlessly concatenated and fed through the text overlay.
Previously, it could lead to the current text buffer suddenly
have a massive running time and blocking all further input.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2802>
This can be important for instance when a container holds multiple
tracks with the same media type, with no indication (eg tags) of
which track is the default one.
In that case, players usually pick the first track by default.
This is especially useful when using smart editing with GES, as
it will result in the same ordering as the input file that was
used as a template.
For reference, this yields the same order as ffprobe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1549>
when creating a profile from a discoverer info.
There is no justification for the existing code, and talking with
Thibault he cannot remember why the sort was in place.
On the other hand, this allows GES users to not have to implement
a callback for the select-tracks-for-object callback when using
it to trim a single clip, which the output profile was built from:
track elements will be placed in the appropriate track by default,
that is the one that will be connected to the matching profile.
For multi-clip timelines, the situation doesn't change, users will
still have to implement a callback and do the leg work of placing
track elements (if any) in a matching track (if any).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1549>
chroma-format, bit-depth-chroma, bit-depth-luma are all informative
fields set by the H265 and H265 parser upon receiving an SPS.
They shouldn't be constrained downstream of the parser, instead
if a user wants those to ultimately match certain values they
should do so by constraining a profile.
In this case however, we also always remove the profile constraint
in order to let encoders pick a suitable one as a function of the
raw input video format and their own capabilities.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1549>
With the 2.72 release, glib-networking developers have decided that
TLS certificate validation cannot be implemented correctly by them, so
they've deprecated it.
In a nutshell: a cert can have several validation errors, but there
are no guarantees that the TLS backend will return all those errors,
and things are made even more complicated by the fact that the list of
errors might refer to certs that are added for backwards-compat and
won't actually be used by the TLS library.
Our best option is to ignore the deprecation and pass the warning onto
users so they can make an appropriate security decision regarding
this.
We can't deprecate the tls-validation-flags property because it is
very useful when connecting to RTSP cameras that will never get
updates to fix certificate errors.
Relevant upstream merge requests / issues:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2214https://gitlab.gnome.org/GNOME/glib-networking/-/issues/179https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/193
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2494>
For formats which we don't have fast-path implementation, compositor
will convert it to common unpack formats (AYUV, ARGB, AYUV64 and ARGB64)
then blending will happen using the intermediate formats.
Finally blended image will be converted back to the selected output format
if required.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1486>
It is entirely possible for the cancellable to be cancelled (and freed)
in gst_rtsp_connection_flush() while there may be an ongoing read/write
operation.
Nothing prevents gst_rtsp_connection_flush() from waiting for the
outstanding read/writes.
This could lead to a crash like (where cancellable has been freed
within gst_rtsp_connection_flush()):
#0 0x00007ffff4351096 in g_output_stream_writev (stream=stream@entry=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6af950, cancellable=cancellable@entry=0x7fff300288a0, error=error@entry=0x7ffe2c6af958) at ../subprojects/glib/gio/goutputstream.c:377
#1 0x00007ffff44b2c38 in writev_bytes (stream=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6afb90, block=block@entry=1, cancellable=0x7fff300288a0) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:1320
#2 0x00007ffff44b583e in gst_rtsp_connection_send_messages_usec (conn=0x7fff30001370, messages=messages@entry=0x7ffe2c6afcc0, n_messages=n_messages@entry=1, timeout=timeout@entry=3000000) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:2056
#3 0x00007ffff44d2669 in gst_rtsp_client_sink_connection_send_messages (sink=0x7fffac0192c0, timeout=3000000, n_messages=1, messages=0x7ffe2c6afcc0, conninfo=0x7fffac019610) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:1929
#4 gst_rtsp_client_sink_try_send (sink=sink@entry=0x7fffac0192c0, conninfo=conninfo@entry=0x7fffac019610, requests=requests@entry=0x7ffe2c6afcc0, n_requests=n_requests@entry=1, response=response@entry=0x0, code=code@entry=0x0) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:2845
#5 0x00007ffff44d3077 in do_send_data (buffer=0x7fff38075c60, channel=<optimized out>, context=0x7fffac042640) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:3896
#6 0x00007ffff4281cc6 in gst_rtsp_stream_transport_send_rtp (trans=trans@entry=0x7fff20061f80, buffer=<optimized out>) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream-transport.c:632
#7 0x00007ffff4278e9b in push_data (stream=0x7fff40019bf0, is_rtp=<optimized out>, buffer_list=0x0, buffer=<optimized out>, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2586
#8 check_transport_backlog (stream=0x7fff40019bf0, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2645
#9 0x00007ffff42793b3 in send_tcp_message (idx=<optimized out>, stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2741
#10 send_func (stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2776
#11 0x00007ffff7d59fad in g_thread_proxy (data=0x7fffbc062920) at ../subprojects/glib/glib/gthread.c:827
#12 0x00007ffff7a8ce2d in start_thread () from /lib64/libc.so.6
#13 0x00007ffff7b12620 in clone3 () from /lib64/libc.so.6
Fix by adding a cancellable lock and returning an extra reference used
across all read/write operations. gst_rtsp_connection_flush() can free
the in-use cancellable and it will no longer affect any in progress
read/write.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2799>
4x downscaling of chroma with co-sited chroma has never worked
it seems.
Fixes incorrect videotestsrc output and videoconvert conversions
to Y41B, YUV9, YVU9 and IYU9 with co-sited chroma.
e.g.
gst-launch-1.0 videotestsrc ! video/x-raw,format=Y41B,width=1280,height=720 ! \
videoconvert ! autovideosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2789>
SMPTE 170M and 240M use the same RGB and white point coordinates
and therefore both primaries can be considered functionally
equivalent.
Also, some transfer functions have different name but equal
gamma functions. Adding another colorimetry compare function
to deal with thoes cases at once
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2765>
Raw memory upload should always be the least preferred input
caps, only added by the raw memory uploader as the last thing
in the caps.
Caps negotiation should still choose raw data when it needs to,
and other upload methods that can accept raw data buffers will still do so.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2725>
gst_video_convert_scale_get_fixed_format() receives 'othercaps' from
basetransforms' fixate_caps() vmethod which explicitly mentions that
'`othercaps` may not be writable'.
The gst_caps_intersect() call just before may or may not produce new
caps. Particularly in cases like EMPTY or ANY caps on either of the
inputs, only a ref is taken and returned to the caller.
As a result, gst_video_convert_scale_fixate_format() may have attempted
to modify a non-writable caps structure.
Fix by adding a gst_caps_make_writable().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2709>
There's no need to re-assign the return value of
g_string_append_*() functions and such to the variable
holding the GString. These return values are just for
convenience so function calls can be chained. The actual
GString pointer won't change, it's not a GList after all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2685>
This reverts commit 6f9ae5d758.
The _transform_caps() function can't tell the difference
between the caller wanting to know the output caps
for the current method, or all possible output caps. If
it includes caps for all possible methods, glupload can
end up negotiating and sending the wrong output caps
downstream.
Partially reverts !2687Fixes#1310
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2699>
If no filter caps are provided with a caps query, always
generate a full set of all caps from all upload methods,
not just the configured one. This is needed to handle
renegotiation when dealing with raw sysmem caps - as the upload
method might accept raw sysmem caps, but only the raw data
uploader adds those to the caps query.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2687>
This reverts commit f3292dc156.
Only the raw data uploader should add sysmem caps to the
actual caps query, because we want them to be at the
lowest priority. If upstream does select to send raw
caps, then the correct upload method will still
be chosen because the accept_caps implementation
will accept them
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2687>
When checking if we need to reconfigure when uploading, check
specifically the output caps of the current method will
result in compatible/incompatible caps, not the full set
of output caps from all upload methods.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2687>
Fixes warnings like:
Received a structure string that contains '="0.5"'. Reading as a gdouble value, rather than a string value. This is undesired behaviour, and with GStreamer 1.22 onward, this will be interpreted as a string value instead because it is wrapped in '"' quotes. If you want to guarantee this value is read as a string, before this change, use '=(string)"0.5"' instead. If you want to read in a gdouble value, leave its value unquoted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2621>
Some encoders (e.g. Makito) have H265 field-based interlacing, but then
also specify an 1:2 pixel aspect ratio. That makes it kind-of work with
decoders that don't properly support field-based decoding, but makes us
end up with the wrong aspect ratio if we implement everything properly.
As a workaround, detect 1:2 pixel aspect ratio for field-based
interlacing, and check if making that 1:1 would make the new display
aspect ratio common. In that case, we override it with 1:1.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2577>
When collection is updated, decodebin3 exposes pad first and then
streams-selected message is posted.
The condition can cause a situation where playbin3 links non-existing
combiner/playsink pads (since streams-selected is not posted yet) with
new decodebin output pad. This commit will re-check selected/active
streams condition on pad-added and reconfigure output if needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2482>
zlib is required, and if it isn't found it is checked several ways and
then forced via subproject(). This code was added in commit
b93e37592a, to account for systems where
zlib doesn't have pkg-config files installed.
But Meson already does dependency fallback, and also, since 0.54.0, does
the in-between checks for find_library('z') and has_header('zlib.h') via
the "system" type dependency. Simplify dependency lookup by marking it
as required, which also makes sure that the console log doesn't
confusingly list "not found".
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2484>
It is valid to have the padding set to 1 on the first packet and it
happens very often from TWCC packets coming from libwebrtc. This means
that we were totally ignoring many TWCC packets.
Fix test that checked that a first packet with padding was not valid and
instead test a single twcc packet with padding to check precisely what
this patch was about.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2422>
Background:
Whenever a caps event is received by appsink, the caps are stored in the
same internal queue as buffers. Only when enough buffers have been
popped from the queue to reach the caps, `priv->sample` gets its caps
updated to match, so that they are correct for the following buffers.
Note that as far as upstream elements are concerned, the caps of appsink
are updated immediately when the CAPS event is sent. Samples pulled from
appsink retain the old caps until a later buffer -- one that was sent by
upstream elements after the new caps -- is pulled.
The race condition:
When a flush is received, appsink clears the entire internal queue. The
caps of `priv->sample` are not updated as part of this process, and
instead remain as those of the sample that was last pulled by the user.
This leaves open a race condition where:
1. Upstream sends a new caps event, and possibly some buffers for the
new caps.
2. Upstream sends a flush (possibly from a different thread).
3. Upstream sends a new buffer for the new caps. Since as far as
upstream is concerned, appsink caps are the new caps already, no new
CAPS event is sent.
4. The appsink user pulls a sample, having not pulled before enough
samples to reach the buffers sent in step 1.
Bug: the pulled sample has the old caps instead of the new caps.
Fixing the race condition:
To avoid this problem, when a buffer is received after a flush,
`priv->sample`'s caps should be updated with the current caps before the
buffer is added to the internal queue.
Interestingly, before this patch, appsink already had code for this, in
gst_app_sink_render_common():
/* queue holding caps event might have been FLUSHed,
* but caps state still present in pad caps */
if (G_UNLIKELY (!priv->last_caps &&
gst_pad_has_current_caps (GST_BASE_SINK_PAD (psink)))) {
priv->last_caps = gst_pad_get_current_caps (GST_BASE_SINK_PAD (psink));
gst_sample_set_caps (priv->sample, priv->last_caps);
GST_DEBUG_OBJECT (appsink, "activating pad caps %" GST_PTR_FORMAT,
priv->last_caps);
}
This code assumes `priv->last_caps` is reset when a flush is received,
which makes sense, but unfortunately, there was no code in the flush
code path resetting it.
This patch adds such code, therefore fixing the race condition. A unit
test demonstrating the bug and testing its behavior with the fix has
also been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2413>
gst_value_serialize() does more than what's needed to printf-ing
especially when given GValue is already string. Just print string
value as-is without gst_value_serialize() to avoid unreadable
string print, especially for multi-bytes character encoding cases.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2387>
* Remove fields no longer used, or that can be replaced by smaller code
* Rename "channels" to a more meaningful "input pads"
* Directly handle/use combiner pads in the combiners instead of on the playbin3
main structure
Remove the corresponding combiner sinkpad whenever a uridecodebin3 source pad
goes away
* If used, store the corresponding combiner sink pad in the SourcePad helper
structure
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2384>
As implemented, we only support OpenGL 3 API from version 3.2. Though, there
is no issue enabling GLSL 1.30 even if we are going to restrict our API usage
to 2. This allows using texelFetch() on OpenGL 3.0 and 3.1 drivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2190>
Since the addition of tiling format with subsampled tile size
(NV12_16L32S), getting the tile width/height shifts and tile
size have become more complex. Add a helper to extract and
scale this information for the selected plane and format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2190>
