As the path to the gir file is passed to hotdoc.generate_doc() and
not the build target itself, meson doesn't know about the dependency.
In turn, as the CI doesn't build everything before building the
documentation target, some gir files might not exist, for instance
in the case of gst-rtsp-server, causing the output documentation to
be empty.
The error occurred silently because hotdoc accepts wildcards for
*-sources arguments, thus it won't warn about a missing gir file as
it is legitimate for glob matching to resolve to nothing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3686>
It might be possible to fulfill those but not with the first caps
structure. Instead of just fixating the first caps structure, check if
the preference can be fulfilled by any of the structures as the first
step.
Without this the following pipeline negotiates to mono after the
decoder because opusenc only has a single channel in its first caps
structure.
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2 ! opusenc \
! queue ! opusdec ! queue ! opusenc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3689>
When calculating the presentation offset for CMAF input in live
playback, subtract the stream_time of the fragment from the
calculated presentation offset, so that the first fragment
is played at running time zero.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3680>
This should fix pipelines such as this one to work as expected
... ! opusenc ! capsfilter caps='audio/x-opus,
channels=1; audio/x-opus, channels=2' ! ...
The expectation is that the encoder will propose the first structure
before the second one to the source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3673>
The number of expected pads was:
* Defaulting to 1
* Or being overriden by GST_MESSAGE_STREAMS_SELECTED
This fails if upstream isn't a selectable source and has multiple streams, and
would therefore cause failures with multi-stream gapless playback
Fixes#1672
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
It is quite possible to have the blocking probe called from different streaming
threads when all expected pads are present.
* Notify all waiters by using g_cond_broadcast instead of g_cond_signal
* Properly remove the probe after waiting
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
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/3635>
Commit d3a66f9851 introduced a potential deadlock with two parallel release_pad
calls, where one could release the main multiqueue lock (qlock) while still
holding the reconf_lock and then calling other routines which in some conditions
may try to acquire qlock again. The second release_pad could already acquire the
qlock and then start waiting on reconf_lock, which may never be possible because
because the first one isn't releasing it until it can acquire qlock.
Fix it by holding reconf_lock for the whole durationg of qlock, making this
particular deadlock impossible.
Fixes#1642
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3571>
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/3049>
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/3613>
NVDEC launches CUDA kernel function (ConvertNV12BLtoNV12 or so)
when CuvidMapVideoFrame() is called. Which seems to be
NVDEC's internal post-processing kernel function, maybe
to convert tiled YUV to linear YUV format or something similar.
A problem if we don't pass CUDA stream to the CuvidMapVideoFrame()
call is that the NVDEC's internel kernel function will use default CUDA stream.
Then lots of the other CUDA API calls will be blocked/serialized.
To avoid the unnecessary blocking, we should pass our own
CUDA stream object to the CuvidMapVideoFrame() call
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3605>
Using the "GstBin" flags to check if an adaptive demuxer is streams-aware isn't
a good idea since it prevents using elements which aren't bins.
Instead we see if a collection was posted by the demuxer by the time a pad is
added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3601>
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/3584>
This reverts the decision from
https://bugzilla.gnome.org/show_bug.cgi?id=754230
where it was decided that we rather play safe and only use the `tfdt` if
it is "significantly different" to the sum of sample durations.
As the specification says
If the time expressed in the track fragment decode time (‘tfdt’) box
exceeds the sum of the durations of the samples in the preceding
movie and movie fragments, then the duration of the last sample
preceding this track fragment is extended such that the sum now
equals the time given in this box.
we have to use the `tfdt` in general to allow for it to signal gaps in
the stream.
A muxer producing fragments might not yet know the full duration of the
last sample of a previous fragment if the next fragment starts with a
gap, and knowing the actual start of the next fragment would potentially
require to violate latency requirements.
Additionally, the existence of `tfdt` allows to avoid accumulating
rounding errors from summing up the durations.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3586>
... 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/3583>
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/3580>
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/3570>
If we keep the old events they can be end up being passed to the app, that could
discard the protection information because it has been seen before.
Drive by improvement: use g_queue_clear_full instead of foreach+clear for
protection events.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3547>
On macOS, a Cocoa event loop is needed in the main thread to ensure
things like opening a GL window work correctly. In the past, this was
patched into glib via Cerbero, but that prevented us from updating it.
This workaround simply runs an NSApplication and then calls the
main function on a secondary thread, allowing GStreamer to correctly
display windows and/or system permission prompts, for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3532>
