Make the converter format a higher priority in all cases. The converter
has been negotiated first and is able to make a better suggestion for
the ideal format in all cases.
Parse and use DSP formats.
Redo the conversion setup when the formats changed. We usually do this
when starting the node but the formats can change while running as well.
Get the dataType field from the Buffer param. This is a mask of the
supported data types for the buffers. Pass this to the allocating node
if there is one, otherwise use MemPtr as the allocated format.
When there is no data and the buffer is mmapable, try to mmap it. Unmap
again when clearing the buffers.
Use the mmaped data pointer of the buffer when processing.
Prefer to let the follower allocate buffers. If we are allocating
buffers, first do use_buffers on the allocating node or else the
non-allocating node just ends up with NULL buffers.
Keep the passthrough flag up to date when we unset a port format or when
it changes.
We should only fill in the buffer data/fd when the ALLOC flag is set.
We should only take the passthrough input buffer as output when we are
in passthrough mode.
Copy the header metadata.
The videoadapter always exposes the EnumPortConfig parameter. If no
converter is loaded, the EnumPortConfig parameter doesn't return a
parameter.
In this case, the client-node in the PipeWire server returns -ENOENT for
the EnumPortConfig, which in turn causes WirePlumber to fail the object
activation and it won't be able to create a link for the object.
This happens since Commit b57375ba85 ("stream: enable videoadapter in
all cases"), since now the videoadapter is always added. Before that,
the EnumPortConfig parameter was just not exposed and linking worked.
Running another client that ignores the error codes for missing
parameters (e.g., pw-dump) hides the issue, as the EnumPortConfig result
is cached as successful with 0 parameters and accessing the cache
doesn't return an error code.
Return the same PortConfig for EnumPortConfig as for PortConfig to fix
this.
When the follower doesn't produce enough data for this many attempts,
bail and cause an xrun to avoid an infinite loop.
The limit of 8 cause real-life problems and should be larger. It should
probably depend on the expected size per cycle (node.latency) and the
current quantum but we don't always have this information.
See #4334
To activate:
PIPEWIRE_PROPS='{ video.adapt.converter = video.convert.ffmpeg }' build/src/examples/video-play
This makes it possible to start firefox with mjpg capture and then
video-play and it will decode the mjpeg transparently. Works for other
incompatible video formats as well, as long as they can be mmapped.
Ideally this should use something GPU accelerated and this is what the
vulkan converter will do.
Try to passthrough the converter format to the follower when we can
before negotiating a conversion.
Try to convert between all follower formats instead of just the first
one.
When enumerating the port params, first enum the follower formats and
then the conversion formats.
Since the dummy plugin can't process buffers, we should configure the
adapter to use passthrough mode for now, instead of requiering the user
to do it manually.
