The build files had quite a few things wrong:
* Not using the method: kwarg, which can cause the wrong Qt to be
used for building
* There was no way to enable the build for them
* Qt was being detected multiple times, differently
* Unnecessary check for libGL
* have_cxx was being used incorrectly
* Qt tool detection was outdated
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9046>
Add support to the ALSA device provider to enumerate PCM outputs that do
not correspond to a physical sound device i.e. they are "virtual" sinks,
like the plug, dmix, or softvol PCM outputs that can be setup in the ALSA
configuration files.
The main use-case for this is allowing usage of GstDeviceMonitor in setups
where there is no audio server and have custom ALSA audio configurations.
As those are likely to be uncommon, the feature is opt-in: a list of device
names and wildcard patterns separated by semicolons must be assigned to the
GST_ALSA_PCM_ALLOW environment variable before such PCM outputs will be
enumerated by the ALSA device provider. This allows either scanning all
PCM outputs, listing individual outputs, providing simple patterns with
'*' wildcards (which match only at the start or end of the name), or
a combination of them:
GST_ALSA_PCM_ALLOW=1 # Enable listing PCM outputs.
GST_ALSA_PCM_ALLOW='*' # Same, using a wildcard.
GST_ALSA_PCM_ALLOW='out_1;out_1' # Exact listing.
GST_ALSA_PCM_ALLOW='out_*' # Using a wildcard.
GST_ALSA_PCM_ALLOW='out_*;other_*;line_out' # Multiple items.
The main motivation for this patch is supporting enumeration of PCM outputs
in the WebKit GTK and WPE ports, which use GstDeviceMonitor to determine
which devices may be chosen for sound output. While on desktops typically
PulseAudio or PipeWire are used nowadays, on embedded devices it is often
desirable to avoid them and use custom configurations that perform audio
routing and processing using only ALSA.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8831>
Stop testing DSD rates in gst_alsa_detect_dsd_rates() if the rate becomes zero
or negative. This avoids an infinite loop if gst_alsa_probe_supported_formats()
is used on a PCM sink defined like the following in the ALSA configuration file:
pcm.buggy {
type plug
slave.pcm "buggy_volume"
hint.description "Causes an infinite loop in GStreamer"
}
pcm.buggy_volume {
type softvol
slave.pcm "buggy_dmix"
control.name "buggy_volume"
}
pcm.buggy_dmix {
type dmix
ipc_key 12345
slave {
pcm "hw:0,0"
period_size 1024
buffer_size 4096
}
}
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8985>
So far we simply ignored it for MEMORY_DMABUF passthrough caps
without known negative cosequences, but with upcoming more complicated
caps negotiations it's becoming an issue, thus fix it.
Fixes: 7e71d4f753 ("gl: upload: Add DMA_DRM passthrough upload")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8964>
This pool isn't reusing its buffers, which makes it pointless to enable
the cache
Holding an extra buffer in free queue can also lead to a deadlock when
the pool's max buffer count is configured low (commonly 2).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8939>
By design, unixfd is meant to be used for zero-copy and failing when the data is
not FD based memory is wanted to help debug pipelines. Though, there exists
cases, notably with RTP payloader and demuxers, where its not possible
to get all the data into FD memory through allocation queries.
To allow using unixfd for these cases, introduce a property on the unixfdsink
that enable copying the non FD data into freshly allocated memfd.
Co-authored-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8861>
Wrap dependencies add a ton of warnings with the latest GCC in Fedora
42. Squelch them by specifying that these dependencies are not
a part of the gstreamer project, and should be treated as system deps.
libsoup needs some porting work for the bump, and vorbis/lame are
already at their latest releases.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8753>
Similar to NV12_10LE40, this is a 422 variant. This format is also named
NV20 (20bit per pixels) in other stack and is produced by rkvdec
decoder.
Co-authored-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5612>
The only thing that can be used in the chain function is the input segment. The
output segment might not be available at all yet or out of sync with the current
input segment.
Also because of that, the unadjusted timestamp has to be used for the
calculations as the adjustment is only part of the output segment.
This fixes the deadline calculation and the handling of force-keyunit events for
encoders using frame reordering (i.e. setting a minimum PTS).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8842>
There was a race condition where the demuxer would seek back to beginning after
determining the duration and while that seek was in progress one pad would
attempt to push a new buffer downstream, leading to a critical warning in
gst_pad_push().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8785>
driftsamples currently uses the requested skew directly, even if it
exceeds cexternal.
Use the approach that skew_slaving uses to fix this. As a side benefit,
this makes the custom_slaving and skew_slaving code easier to compare.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8605>
The 'new-pref' property sets the preference to use the new (next)
instead of the old (previous) buffer. The default is set to 0.5 to get
a similar behaviour as before the change.
Value 0.0 makes sure that only frames are shown where it's known that
the frame content is visible at that time, always show the old frame
until the new frame timestamp is reached.
Then, if the next buffer replaces the previous buffer the new buffer
is pushed as often as possible until PTS is reached. Before the new
buffer was only pushed once the new next buffer arrived.
Use GstClockTimeDiff because it's known that the current buffer time
is inside the time interval of previous buffer and next buffer the
calculation can be done with building absolute values. Special macros
are not needed here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
