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>
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/3939>
It is really difficult for people to figure out why nvcodec has
0 features. Even the debug log is cryptic. Also make sure the errors
go to the ERROR log level, which is more likely to be enabled by
default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3796>
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/3923>
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/3879>
It's not possible to annotate a in-parameter for a return value array as
the array length. Both are assumed to have the same direction and the
current annotation causes the size parameter to be considered an out
parameter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3794>
Due to the dynamic nature of multiqueue, when `use-interleave` is used we can't
report a maximum tolerated latency (when queried) since it is calculated
dynamically.
When in such live pipelines, we need to make sure multiqueue can handle the
lowest global latency (provided by this event). Failure to do that would
result in not providing enough buffering for a realtime pipeline.
Fixes#1732
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3792>
This is recommended by various specifications for such framerates, while
for integer framerates we continue using centiframes to allow for some
more accuracy.
Using N means that no rounding error accumulates, eventually leading to
outputting a packet with a different duration.
Some tools such as MediaInfo determine that a stream is variable
framerate if any packet has a different duration than the others, and
there is no reason I can see for not using the full 4 bytes of
resolution that the mp4 timescale offers.
Example problematic pipeline:
```
videotestsrc num-buffers=5001 ! video/x-raw,framerate=60000/1001,width=320,height=240 ! \
videoconvert ! x264enc bitrate=80000 speed-preset=1 tune=zerolatency ! h264parse ! \
video/x-h264,profile=high-10 ! mp4mux ! filesink location="result2.mp4"
```
This results in a media file that MediaInfo detects as variable
framerate because the 5000th packet has duration 99 instead of 100.
With this patch, the timescale is 60000 and all packets have duration
1001.
Related issue for context: https://bugzilla.gnome.org/show_bug.cgi?id=769041
Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3683>
gst_element_add_pad() is supposed to activate the pad if the element
state is >= PAUSED and the pad is not already active.
Unfortunately, before this patch, the activation was performed while the
element lock was still taken, which ended causing a deadlock in
gst_pad_start_task() as it attempted to post `stream-status` message in
the element, which also requires the element lock.
Elements could work around this bug by activating the pad manually
before adding it to the element.
This patch fixes the problem by performing pad activation only after the
element lock has been released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3651>
The latency messages are non-deterministic and can arrive before/after
async-done or during state-changes as they are posted by e.g. sinks from
their streaming thread but bins are finishing asynchronous state changes
from a secondary helper thread.
To solve this, expect latency messages at any time and assert that we
receive one at some point during the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3647>
The VAAPI vaQueryVideoProcPipelineCaps() requires the context as the
parameter. So far, we always pass VA_INVALID_ID and it can succeed.
But the API does not say that and in theory, a valid context is required.
Now the new platform really needs a valid context and so we have to
delay that query until the context is created.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3620>
If a discontinuity is detected in push mode, we need to clear the cached section
observations since they might have potentially changed.
This was only done properly when operating with TIME segments (dvb, udp,
adaptive demuxers, ...) but not with BYTE segments (such as with custom app/fd
sources).
We still don't want to flush out the PCR observations, since this might be
needed for seeking in push-based BYTE sources.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1650
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3600>
If the SETUP request returns an IPv6 server address in the Transport
field, we would generate an incorrect URI, and multiudpsink would fail
to initialize:
```
rtspsrc gstrtspsrc.c:9780:dump_key_value:<source> key: 'Transport', value: 'RTP/AVP;unicast;source=fe80::dc27:25ff:fe5e:bd13:8080;client_port=62696-62697;server_port=4000-4001'
...
rtspsrc gstrtspsrc.c:4595:gst_rtspsrc_stream_configure_udp_sinks:<source> configure RTP UDP sink for fe80::dc27:25ff:fe5e:bd13:8080:4000
...
multiudpsink gstmultiudpsink.c:1229:gst_multiudpsink_configure_client:<udpsink0> error: Invalid address family (got 23)
```
We can't look at stream->is_ipv6 because we can't rely on the server
returning the right value there. In the issue reported about this,
server reported itself as `KuP RTSP Server/0.1`, and the SDP was:
```
c=IN IP4
m=video 54608 RTP/AVP 96
a=rtpmap:96 H264/90000
```
So we need to parse the string value and figure out the family
ourselves.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1058
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3596>
If the driver does not support VIDIOC_CREATE_BUFS ioctl, the pool
configuration may get changed, which requires a validation. This would
fail to activate a pool in a case it shouldn't normally fail unless we
are out of memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2677>
... when rendering on external HWND. ShowWindow() will cause
synchronous message passing to window thread and then can be blocked.
At the same time, window thread can wait for GStreamer thread.
Instead of the synchronous call, queue the task to window message
and performs from the window thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3588>
Deadlock sequence:
* From a streaming thread, d3d11videosink sends synchronous message
to the parent window, so that internal (child) window can be
constructed on the parent window's thread
* App thread (parent window thread) is waiting for pipeline's
state change (to GST_STATE_NULL) but streaming thread is
blocked and waiting for app thread
To avoid the deadlock, GstD3D11WindowWin32 should send message
to the parent window asynchronously.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3573>
The rtpjitterbuffer test drop_messages_interval uses a GstClockTime for
the message drop interval. This property is defined as a guint. On
systems with 64-bit time_t but 32-bit uint, this can cause the
g_object_set function to fail to read the arguments properly.
Fixes: #1656
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3582>
Systems like musl libc don't support ISO 6937 in iconv. This ensures
that the MPEG-TS plugin can cope with that. There is existing support
in the plugin for other methods, so it seems to have been the original
intent anyway.
Fixes: #1314
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3563>
Apparently mesa 22.3.0 has updated the egl headers, and eglplatform.h now
contains commit
3670d645f4
after which xlib headers don't get included by default anymore but are
dependent upon whether USE_X11 was defined.
This breaks headless builds of gstreamer-vaapi because we always define
an internal define USE_X11 as either 1 or 0.
Change these defines to GST_VAAPI_USE_XYZ instead to avoid this.
Fixes#1634
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3558>
