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>
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>
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>
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>
Sometimes the seek to the end of file to determine the duration would trigger a
reset of the source pads, that would confuse the decoder downstream and trigger
an error. So the proposed fix is to not reset pads when the segment event being
processed is the consequence of a seek performed to determine the duration.
Fixes#4212
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/937>
After calculating a correct duration the oggdemux in some cases sets the duration to GST_CLOCK_TIME_NONE.
After that any seek will fail due to the oggdemux calculating a target time after the actual duration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8296>
The check is exactly the same, but more explicit.
Original commit that introduced the check is
20fb58be198e7d76ece4e6c635cda7c919fad6d2:
---
vorbisdec: don't put invalid bitrate values into the taglist
Bitrates are stored as 32-bit signed integers in the vorbis
identification headers, but seem to be read incorrectly,
namely as unsigned 32-bit integers, into the vorbis structure
members which are of type long, which makes our check for
values <= 0 fail with files that put -1 in there for unset
values.
---
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8229>
* if downstream provides us with a pool that can allocate DMA buffers,
gldownload wraps it into a GL buffer pool that uses
glEGLImageTargetTexture2DOES() to import dmabuf into textures
* upstream GL elements can allocate from that pool
* gldownload unwraps DMA buffers from incoming GL buffers and passes
them downstream
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6792>
When measuring video latency, one mechanism involves taking a photo
with a camera of two screens showing the test video overlayed with
timeoverlay or clockoverlay. In these cases, if the display's pixel
response time is crappy, you will see ghosting due to which it can be
quite difficult to discern what the current timestamp being shown is.
This commit adds a property that *also* shows the timestamp in
a different (sequentially predictable) location every frame, which
makes it easy to tell what the latest rendered timestamp is.
For bonus points, you can also use the fade-time of the previous frame
to measure with sub-framerate accuracy when the photo was taken, not
just clamped to the framerate, giving you a higher precision latency
value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6935>
Simple gst_gl_sync_meta_wait() is not sufficient to ensure GL commands
are executed before dma-buf devices get to see the buffer.
This is the first step that should make the code behave correctly for
everybody, although there may be performance penalty. In the future we
should introduce a more general sync meta that would allow to move the
waiting from gldownload (the producer) to the sink elements (the
consumers).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6968>
