When doing direct dmabuf upload, we rely on the GL stack for doing the color
transformation. The caps we transform from GL to DMABuf are always with a format
of RGBA. Instead of listing all GstVideoFormat and translating them back into
DRM formats, simply list all supported DRM format for the context.
This enable rendering DRM formats that don't have an shader based emulation
implemented such as NV15.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9306>
The transformation was fuzzy, adding random modifiers to the list. Use the newly
introduce helpers from 1.26 to precisely convert GStreamer formats to a DRM
fourcc and modifier pair and vice-versa.
This fixes support for formats that have a GstVideoFormat value and requires a
modifier.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9306>
Prevent race condition where gst_play_sink_do_reconfigure() could be called
from a pad probe while stream synchronizer pads are being released during
GST_STATE_CHANGE_PAUSED_TO_READY transition.
The race occurred when:
1. State change starts releasing stream synchronizer pads
2. Pads are unblocked earlier in the state change, allowing events to flow
3. A streaming thread triggers sinkpad_blocked_cb -> gst_play_sink_do_reconfigure
4. Reconfiguration tries to use already-released pad pointers
5. New pad creation fails with assertion in gst_pad_iterate_internal_links
The fix adds GST_PLAY_SINK_LOCK around the pad cleanup to ensure atomic
cleanup and prevent concurrent access during state transitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9233>
A user-supplied window handle (external_view) becomes the superView
of internal_view, which is closed with [view removeFromSuperview].
This fails silently if external_view = NULL (no handle supplied).
Call [win_internal_id close] in this case. Fixes#4432.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9049>
The copy of the exact same stream-start event prevents the multiqueue's sink
event function from being called because it is already stored on both pads at
link time
The text streams are no longer considered sparse by the multiqueue, so
interleave calculation is broken and makes us consume a lot of ram and we can
end up killed by the kernel because of this
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8412>
The profile argument passed to gst_encode_base_bin_set_profile is now
transfer-full. This issue was noticed after commit
6beb709d43d2023e7e5dc8f1ee1323bc28c9d1d8 which fixed profile refcount handling
in transcodebin.
Driving-by, an encoding profile leak was also fixed in _set_profile, in case
it's called for an already active element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9167>
When using the custom WebKitMediaSrc element (used by WebKit and able to
perform an initial seek in playbin), a stall caused by streamsynchronizer
was detected during an initial seek. The flow of events revealed that the
intertwining of the initial configuration of the streams with the reset
caused by the flush events from the seek left streamsynchronizer in an
inconsistent state:
streamsynchronizer0:sink_0 (video) events, starting before the seek:
stream-start --> Sets the stream to wait
flush-stop --> Clears the stream wait flag
caps
tag
segment
stream-collection
(buffers start to come and flow properly)
streamsynchronizer0:sink_1 (audio) events, happening after seek:
(no flush events, because the stream hadn't been initialized when the seek happened)
stream-start --> Sets the stream to wait
caps
segment
(stalled because the stream is in wait mode!)
The code in streamsynchronizer expects that all the streams are in wait
state before releasing all of them at once. The flush on the video stream
broke that assumption and that's why the audio stream is never released in
that scenario.
Avoiding the clearing of the wait flag on flush-stop isn't an actual solution
to the problem, as it creates other side effects and at least makes the
gst-editing-services/seek_with_stop test to timeout. The alternate solution
implemented in this patch consists on analyzing if the other streams different
from the one newly added (after the flush) aren't waiting (which would mean
that they've all been unlocked after all of them were waiting before), and,
in that case, mark the new stream as also not waiting.
A new test_stream_start_wait test case has been added to demonstrate this
problem. The test case creates a video stream, pushes a buffer, then
simulates a seek by pushing flush-start, flush-stop, stream-start and segment
events. Note that the flush-stop clears the video stream waiting flag.
After that, a new audio stream is created and stream-start and new segment
events are sent. Note that stream-start will set the audio stream to wait.
Then a buffer is pushed on each stream. In the failing case, the test hangs.
In the working case (after this fix), the test runs properly because the
fact of having seen a stream-start also helps to clear the wait flag.
A second new test_stream_start_wait_sparse test has also been added to prove
that this mechanism can also work with sparse streams (a special case of the
current stream-start handling code). This test behaves like the previous one,
but there's no video buffer after the seek (it'll come in the future, as the
stream is sparse, but actually never comes). The buffer after the seek in the
audio stream starts at its due time. Streamsynchronizer is able to ignore
the wait for the video stream and produce audio buffers on time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4544>
Align the calculations for the number of samples per block with the
calculations in adpcmdec.
For MS ADPCM we have in adpcmdec:
samples = (blocksize - 7 * dec->channels) * 2 + 2 * dec->channels;
outsize = 2 * samples;
outbuf = gst_buffer_new_and_alloc (outsize);
This gives us the total output byte size in 16 bits samples. To get back
to the samples, dividing by the channels and 2, we get the right samples per
block as:
int spb = ((strf->blockalign / strf->channels) - 7) * 2 + 2;
Which we can then use to calculate the bitrate in riff-media.
A similar calculation for DVI ADPCM is needed to get the right bitrate
in all cases.
Tested with the sample in https://bugzilla.gnome.org/show_bug.cgi?id=636245
and another (failing before this patch) sample.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9082>
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>