GSTs DMA_DRM API does explicitely not support implicit modifiers and
trying to use it would result in assertions like
```
gst_video_dma_drm_fourcc_to_string: assertion 'modifier != DRM_FORMAT_MOD_INVALID' failed
```
Fixes: f1b75fc6f ("gst: Add support for DMA_DRM / explicit modifiers")
By setting a "is-default" boolean property on the discovered GstDevice(s) the
application now gets a good hint of which device to select and use.
Fixes#4268
`pw_stream_destroy()` chains up to `on_remove_buffer()` in
GstPipeWireSrc which again needs the stream to still be around to call
`pw_stream_queue_buffer()` on it. By using `g_clear_pointer()` it will
already have been cleared, causing crashes.
Revert to the behavior from before the commit mentioned below and add a
comment in order to avoid regressing in a future cleanup.
Fixes: 0c40c0147 (gst: factor out the stream management and some common variables in a new class)
When a stream is stopped, chances are high that downstream elements
change or get reset, i.e. don't remember a previously send rotation
event. Thus reset the transform value in order to ensure we create a new
one on the next stream start.
In order to not regress the case when downstream *does* remember the
orientation and the buffer orientation changes from e.g.
`TRANSFORMATION_90` to `TRANSFORMATION_None` between stream
stop and restart, initialize the remembered transform to an invalid
value and ensure we always send a rotation event, even for
`TRANSFORMATION_None`.
PipeWire expects the SPA_TYPE_OBJECT_ParamBuffers to be valid after
setting SPA_PARAM_Format. The pipewiresink knows the final buffer size
only after the pipewirepool has been activated.
There is a race between PipeWire asking the pipewiresink for the buffers
and GStreamer activating the buffer pool. If GStreamer has not activated
the buffer pool before PipeWire asks for the Buffer params, PipeWire
won't allocate buffers with the correct type and size.
The chance of hitting this window increases, if the upstream GStreamer
element doesn't use the buffer pool. In this case the buffer pool is
activated by the first buffer that arrives at the pipewiresink, which
may take some time.
Instead of not updating the Buffer params when the buffer pool is not
active, wait for the buffer pool to become active.
Add a helper function for updating the params instead of handling it in
the pool_activated callback. This allows to explicitly set the params
from the element.
Print the state of the stream not only as the numeric value, but also
print the name of the state to help the reader.
While at it, add the sink element to the log output to be able to
identify the sink that received the state change.
The pipewiresrc starts the stream in active state but should be inactive
if only going to PAUSED state. This patch sets the stream to inactive
when wait_started has returned in the GStreamer state tranistions.
Also resets internal started state when going PAUSED -> READY.
Fixes#4049
Since commit f400ff2050 ("gst: Check for video/ caps before parsing
for info") JPEG support in the GStreamer elements is broken as JPEG is
not recognized as a video format anymore.
gst_video_info_from_caps is able to handle "video/" and "image/"
formats. Therefore, the check needs to allow "image/" too.
While at it, cleanup the formatting to make the check more readable.
The HAVE_GSTREAMER_DMA_DRM belongs to the inner brace, not the outer
brace, since the inner if statement is under HAVE_GSTREAMER_DMA_DRM.
While doesn't make a difference to the compiler, but confuses a reader.
Put the other brace under the HAVE_GSTREAMER_DMA_DRM.
Construct this new class from both the src and sink to be able to share code
Consolidate the previous mess of open/close/start/stop into a single pair
of open/close functions in the new stream class
The translation between Pipewire parameters and Gstreamer caps is,
for compatibility reasons, ambiguous. Formats with linear modifier
are translated both in the legacy way as `format`, as well as
`drm-format`.
When finishing negotiation and setting caps, ensure that we:
1. set caps that the peer actually supports in order to prevent
negotiation errors.
2. fixate caps to DMA_DRM if both options are supported, using the newly
introduced helper, in order to prevent hangs.
While on it, add some small clean-ups that hopefully make the code
easier to follow, notably that `pwsrc->caps` and `pwsrc->possible_caps`
are only used during negotiation.
When support for modifier-aware DMA_DRM formats was added in f1b75fc6,
the translation between Pipewire parameters and Gstreamer caps was kept
compatible with the] non-DMA_DRM/legacy API by reporting format/modifier
combinations with linear or invalid modifier both as `format` and
`drm-format`.
In cases when a linear modifier ends up being negotiated, this, however,
resurts in non-fixated caps, preventing the negotiation to succeed.
Add a helper that allows to fixate such caps.
When the link on the pipewire side is destroyed, on video streams, buffers
are removed abruptly and there is no way this pipeline can be revived,
so let's post an element error to stop it.
On a normal shutdown, the pool is first set to flushing in change_state(),
so checking for the flushing state is a good indicator to know if this
is a normal shutdown or not.
See #1980
This is for readability and better control.
Make sure we clear out all pointers to anything related to the released
pw_buffer, including all the memories.
The gst_video_info_from_caps() API isn't really intended to be used as a
check-for-videoness function (it generates an error-level GStreamer
debug message when used this way).
We check the caps for a video/ name for this reason, which is
functionally equivalent.
Both the GPtrArray and its contents are leaked in case of success.
`pw_stream_connect()` copies the params as needed, so use `g_autoptr()`
to free the array and with it, its contents.
The threadloop might fail to create because of missing plugins, so
handle that.
The context might fail to create because of some fatal config error or
missing plugin, handle that too instead of crashing.
See #3994
gst_pad_get_current_caps may return NULL and passing that into
gst_caps_is_equal may result in fatal critical log due to the
"g_return_val_if_fail (GST_IS_CAPS (caps1)" check. Fix by checking for
NULL to avoid this.
Some clients like many camera apps, including Cheese or Snapshot,
trigger a lot of unnessecary renegotiations. While arguably that should
be solved on a Gstreamer level, we can help out by checking if the
preferred new caps are the same that are already in use and skip the
renegotiation in this case.
This allows several apps to e.g. take pictures without a slow and heavy
stream restart.
In order to follow the documentation more closely. Also restructure the
code a bit to make it easier to follow.
See also: e3227b2b5 (gst: simplify modifier extraction)
Fixes: f1b75fc6f (gst: Add support for DMA_DRM / explicit modifiers)
spa_pod_get_values() handles both single values and Choice values and
turns the single value into a None choice.
Check that we have a None or Enum choice because we don't handle
anything else.
See !1952
A peer may announce support for a single modifier, in which case it may
not use a choice-pod. And while the documentation in `dma-buf.dox`
requires modifiers to always be announced as `SPA_CHOICE_Enum`, this has
been supported in the past - as well as matching Pipewire conventions.
Thus, in order to not break existing clients not crash, reintroduce
handling of modifiers as a single long.
Fixes: f1b75fc6f (gst: Add support for DMA_DRM / explicit modifiers)
Solution suggested by Barnabás Pőcze <pobrn@protonmail.com>
Parse the audio rate from the caps and set this as the stream node.rate
property. This will try to switch the graph to this rate and avoids
resampling.
Rework some of the property handling.
`gst_caps_make_writable()` may create a copy which we have to keep
using afterwards. The return value was meant to be used for that,
but was promptly forgotten for the initial user.
Avoid such errors in the future by using an in-out parameter instead.
While on it, add a type check and remove a check for an impossible
condition.
Fixes: 8a271a87b ("gst: Sanitize caps before translating")
gst-play uses autoaudiosink by default when playing audio, which
iterates over all sinks sorting them by rank. By default,
pipewiresink sets the rank to 0, but it can be overridden
by setting the GST_PLUGIN_FEATURE_RANK env. var. like this:
`GST_PLUGIN_FEATURE_RANK=pipewiresink:268 gst-play-1.0 /usr/share/sounds/alsa/test.wav`
But that doesn't work either because the autoaudiosink plugin also
filters the available options, testing for "Sink" and "Audio" to
appear in the classification metadata
(in the strstr comparison in
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/autodetect/gstautodetect.c?ref_type=heads#L220
klass is what's set by pipewire as classification,
self->type_klass is "Sink" and self->media_klass is "Audio")
Just adding the word Audio to the classification metadata fixes
this and allows pipewiresink to be selected by autoaudiosink.
I also set it in the source plugin since looking at the code,
autoaudiosrc works exactly the same.
DMABuf caps without concrete formats and modifiers don't map well to the
Pipewire negotiation process.
Introduce a new gst_caps_sanitize() helper function, where such cases
can be handled.
Gstreamer 1.24 added and largely switched to a new, modifier aware
DMABuf API. Unfortunately that breaks the existing DMABuf support in the
PW Gst element.
Add support for the new API.
Make a method to get the current time to compare agains the pw_time-now
field. This is currently CLOCK_MONOTONIC but make this into a method
so that we can more easily change it later.
When we disable autoconnect, disable the timeouts as well. Otherwise the
user has to connect the stream within the 30 second timeout or get a
failure. With autoconnect we can reasonably assume there is a problem
when the stream is not connected after 30 seconds.
Fixes#3884
