This will cause an integer overflow a little bit further down because we
allocate a bit more memory to allow for a NUL-terminator.
The caller should've avoided passing that much data in already as it's
not going to be a valid image and there's likely not even that much data
available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4901>
The framerate should only be replaced (and corrected for alternating field)
when it is parsed from the bitstream. Otherwise, the upstream framerate
from caps should be trusted and assumed correct.
Related to gst-plugins-bad!2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4884>
ptpd is defaulting to the hybrid mode, and was sending invalid multicast
PTP messages in that configuration until ce96c742a88792a8d92deebaf03927e1b367f4a9.
While this commit was made in 2015 there was no release in the meantime.
Work around this by detecting this case and defaulting to the default
values for the given intervals as given by the PTP standard.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4834>
The index is already incremented by 3 every iteration so multiplying it
by 3 additionally on each array access is doing it twice and does not
work.
This caused invalid files to be created if there's more than one CEA608
triplet in a buffer, and out of bounds memory reads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4832>
Whenever the surface is resized before the stream is negotiated, we endup
with an assertion in libgstvideo.
gst_video_center_rect: assertion 'src->h != 0' failed
This fixes it, by following the style aready in place, which is to ensure
surfaces have a minimum size of 1x1.
Fixes#1139
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4303>
setup_source() tries to plug a typefind element unconditionally to the
source element on non-live streams, no matter if the element is dynamic
or not. In the former case, the element might not have any src pad
created, so the plugging will fail, triggering an unrecoverable error.
This patch only tries the plugging when the element is not dynamic (no
new-pad callback has been configured). In case the element is dynamic,
the callback will take care of configuration when pads appear in the
future.
This solves many regressions on the YouTube MSE Conformance Tests[1] at
least in downstream WPE 2.38[2] after migrating from GStreamer 1.16 to
1.18, a change that introduces Playbin 3.
[1] https://ytlr-cert.appspot.com/latest/main.html
[2] https://github.com/WebPlatformForEmbedded/WPEWebKit/tree/wpe-2.38
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4074>
Fixes the following valgrind error:
==616== Conditional jump or move depends on uninitialised value(s)
==616== at 0x4900E34: gst_debug_print_object (gstinfo.c:1143)
==616== by 0x49010B6: gst_info_printf_pointer_extension_func (gstinfo.c:1215)
==616== by 0x4959FDB: __gst_printf_pointer_extension_serialize (printf-extension.c:47)
==616== by 0x495A487: printf_postprocess_args (vasnprintf.c:258)
==616== by 0x495A52C: __gst_vasnprintf (vasnprintf.c:290)
==616== by 0x4959F8F: __gst_vasprintf (printf.c:154)
==616== by 0x4901C1F: gst_debug_message_get (gstinfo.c:791)
==616== by 0x4901C75: _gst_debug_log_preamble (gstinfo.c:1431)
==616== by 0x4903208: gst_debug_log_default (gstinfo.c:1575)
==616== by 0x49020BA: gst_debug_log_full_valist (gstinfo.c:624)
==616== by 0x490211D: gst_debug_log_valist (gstinfo.c:656)
==616== by 0x49021AD: gst_debug_log (gstinfo.c:533)
==616== by 0x48DDC11: gst_buffer_copy_into (gstbuffer.c:693)
==616== by 0x48DF5F1: gst_buffer_copy_with_flags (gstbuffer.c:727)
==616== by 0x48DF640: gst_buffer_copy_deep (gstbuffer.c:756)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4037>
The av1C box is optional so dropping parsing does not break anything
fundamentally, and there seems to be no historical record how version 0
even looks like while the comments and the parsing disagreed with each
other.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4028>
When using qtdemux in a pipeline that should only work as a pure demuxer (not
for actual playback), qtdemux shouldn't emit new GstSegments to correct
the start time (jump to the future) to ensure that the user experiences no
playback delay. By doing so, it's generating the wrong segments when an append
of data from the past happens. When that happens, downstream elements such as
parsers (eg: aacparse) may clip those buffers laying before the GstSegment and
create problems on the GStreamer client app (eg: WebKit).
Getting buffers clipped out because of the wrong GstSegments started becoming
a problen when this commit was introduced:
ab6e49e9cc audioparsers: add back segment clipping to parsers that have lost it
This clipping makes test DASH shaka 35 from MVT tests[1] to fail in
WebKitGTK/WPE (at least) and can potentially cause a number of other problems
in the WebKit Media Source Extensions (MSE) code.
Note that this new behaviour of not emitting new GstSegments only makes sense
when qtdemux is being used as a pure demuxer and not as part of a regular
pipeline. This is why the variant field has been added. When equal to
VARIANT_MSE_BYTESTREAM, it will make qtdemux behave differently in push mode,
taking decisions that meet the expectations for an MSE-like processing mode.
This kind of tweaks have been done in the past for MSS streams, for instance.
That code has been refactored to use VARIANT_MSS_FRAGMENTED now, instead of
its own dedicated boolean flag.
Co-authored by: Alicia Boya García <ntrrgc@gmail.com>
...who suggested to use "variant: mse-bytestream" in the caps to identify that
mode, as proposed in her unmerged patch:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/467
[1] https://github.com/rdkcentral/mvt
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3995>
This fixes a compile error with recent upstream FFmpeg.
The AV_CODEC_CAP_AUTO_THREADS was deprecated and renamed to
AV_CODEC_CAP_OTHER_THREADS in FFmpeg upstream commit
7d09579190de (lavc 58.132.100).
The AV_CODEC_CAP_AUTO_THREADS was finally removed in FFmpeg upstream
commit 10c9a0874cb3 (lavc 59.63.100).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3965>
