When a tile format is padded and imported as DMABuf, the stride
contains the information about the actual width and height in
number of tiles. This information is needed by the detiling shader
in order accuratly calculate the location of pixels. To fix that,
we also copy the offset and strides into the otuput format and
the converter will ensure that the shader is recompiled whenever
the stride changes.
This fixes video corruptions observed when decoding on MT8195
with videos that aren't not aligned to 64bytes in width.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3365>
Posting latency messages causes a full and potentially expensive latency
recalculation of the pipeline. While subclasses should check whether the latency
really changed or not before calling this function, we ensure that we do not
post such messages if it didn't change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3282>
duplicate symbol '__invoke_on_main' in:
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstvulkan-1.0.a(cocoa_gstvkwindow_cocoa.m.o)
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstgl-1.0.a(cocoa_gstglwindow_cocoa.m.o)
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Also make the same change in iOS for consistency.
Continuation of https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1132
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3242>
This allows correct handling of wrapping around backwards during the
first wraparound period and avoids the infamous "Cannot unwrap, any
wrapping took place yet" error message.
It allows makes sure that for actual timestamp jumps a valid value is
returned instead of 0, which then allows the caller to handle it
properly. Not having this can have the caller see the same timestamp (0)
for a very long time, which for example can cause rtpjitterbuffer to
output the same timestamp for a very long time.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1500
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3202>
The implementation was inconsistent between create and destroy. EGLImage
creation and destruction is requires for EGL 1.5 and up, while
otherwise the KHR version is only available if EGL_KHR_image_base
feature is set. Not doing these check may lead to getting a function
pointer to a stub, which is notably the case when using apitrace.
Fixes#1389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2925>
We need to call this to register the MusixBrainz tags before we use
them in an XMP schema.
Fixes this critical when attempting to run jpegparse on a JPEG
containing MusicBrainz XMP tags:
GStreamer-CRITICAL **: 20:41:07.885: gst_tag_get_type: assertion 'info != NULL' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3092>
The purpose of a deep buffer copy is to be able to release the source
buffer and all its dependencies. Attaching the parent buffer meta to
the newly created deep copy needlessly keeps holding a reference to the
parent buffer.
The issue this solves is the fact you need to allocate more
buffers, as you have free buffers being held for no reason. In the good
cases it will use more memory, in the bad case it will stall your
pipeline (since codecs often need a minimum number of buffers to
actually work).
Fixes#283
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2928>
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>
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>
