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/4027>
If we have caps then we can only set exactly those caps, if we have no
caps yet then negotiating anything is not very meaningful because the
caps are defined by the application and not downstream.
Avoids, among other things, an unnecessary allocation query and spurious
useless caps being set before the first buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4020>
This crept in several years ago sadly :(
The usage of accurate seeking should be reserved to use-cases where it is
essential that we seek to that position. This should not be the default.
There is a new option `--acurate-seeks/-a` to be able to force that.
Furthermore, if accurate seeks aren't required, a player should be using the
GST_SEEK_FLAG_KEY_UNIT flag to seek to the closest keyframe and provide the most
reactive experience.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4017>
Generating the source element is done when uridecodebin is doing the
READY to PAUSED state change, so it is reasonable to set the new source
element to that state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4016>
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/3990>
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/3964>
Fixes#1358.
Passing ARGB64/RGBA64 to vtenc caused the encoding to fail
when running on M1 Pro/Max variants with macOS 12.x, so let's
remove these formats from caps when such scenario is detected.
This issue appears to have been fixed OS-side in macOS 13.0.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3962>
This was causing incorrect output when seeking, especially
when used with a multithreaded source like `videotestsrc n-threads=2`.
It should now correctly wait for frames still being processed by VT
while vtdec is flushing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3937>
We are using std::isspace() with one parameter. That function is defined
in the cctype header.
```
win32ipcutils.cpp(34): error C2672: 'std::isspace': no matching overloaded function found
win32ipcutils.cpp(34): error C2780: 'bool std::isspace(_Elem,const std::locale &)': expects 2 arguments - 1 provided
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3936>
When the task already exists, we forgot to free the passed `user_data`.
This wasn't an issue for most C code, which doesn't pass a
`GDestroyNotify`, but bindings such as gstreamer-rs do!
That said, allocating a trampoline in gstreamer-rs just for it to get
thrown away again is awkward. Maybe we need a `gst_pad_resume_task`?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3925>
The VA API has not defined the scaling list entries for U/V planes
for the 4:4:4 stream. In fact, we do not meet the 4:4:4 format output
for H264 so far, and scaling list is not used frequently, so we just
print out some warning and ignore these scaling list values.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3877>
