The Pipewire libcamera spa plugin exposes multiple camera properties.
Unlike v4l2, libcamera usually exposes these as normalized floating
point values. But as the SPA_PROP types are based on v4l2, they are
currently set to integers.
This causes a problem when using pw-cli to change the properties,
as the spa_json_to_pod_part function casts the properties according
to their spa_type_info. Other software that doesn't depend on the
spa_type_info can correctly set the properties, as the values are
encoded in the spa_pod type and therefore also carry a type.
As the limited range from switching integers to floats is likely not a
problem, the affected spa properties were changed to the Float type.
This will cause pw-cli to also generate spa_pod values of type float
when setting v4l2 properties. Therefore the v4l2 spa plugin is also
adapted to allow floating point properties and cast these to integers.
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Use dynamic pod builder so that we can also build complex formats.
Make sure we zero the format before we parse it or else we end up with
potentially uninitialized values.
When ENUM_FRAMESIZES or VIDIOC_ENUM_FRAMEINTERVALS return EINVAL for the
first index, make a dummy result and continue with that. This will
trigger an intersect withe filter so that we end up with something valid
instead of nothing.
Handle 0 framerates without crashing.
See #4063
Can be used to group ports together. Mostly because they are all from
the same stream and split into multiple ports by audioconvert/adapter.
Also useful for the alsa sequence to group client ports together.
Also interesting when pw-filter would be able to handle streams in the
future to find out what ports belong to what streams.
Advertise support for the videotransform metadata.
Make a new meta.videotransform.transform property to configure the
desired video transformation in the metadata.
This makes it possible for a session manager or other rules to set
a custom transformation on the source.
See #4034
A quite big number of UVC cameras - due to firmware or kernel driver
issues - have bad timestamps of the first frame, confusing clients
like pipewiresrc.
Drop the first frame, as this seems to be the most reliable workaround
for the time being.
Closes https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3910
Previously both `impl_on_notify_events()` and `process_{device,card}()`
called `check_access()`. Avoid that by merging `ACTION_ADD` and
`ACTION_DISABLE` into a single `ACTION_CHANGE` and let `process_{device,card}()`
call `check_access()` and decide what to do.
Split up `process_{device,card}()` to have a separate function that does
the lookup based on the udev device, and only use that when there is
no available reference to the actual device/card object.
Add a MAPPABLE data flag that hints that the fd in the data is mappable
with a simple mmap/munmap. Normally, DmaBuf is not mappable like that
unless explicitly indicated with this flag.
Set the MAPPABLE flag on the DmaBuf from v4l2 and libcamera fd.
When asked, mmap the buffer memory in all cases when the MAPPABLE
flag is set.
This solves the case where v4l2 has exported DmaBuf and is streaming to
node A and then node B links but doesn't get automatically mmaped
memory.
Fixes#3840
After we set the format, probe if we can do EXPBUF and enable/disable
the ALLOC_BUFFERS flag on the port.
This should gracefully handle the case where EXPBUF is not available.
Fixes#3821
When we try to alloc buffers but EXPBUF is not supported, make sure to
clear the alloc_buffers flag so that the caller can try again with
allocated buffers instead.
See #3821
When the filter has no format property, just enumerate all possible
framerates. Handle error case where the filter has the wrong type.
Makes gst-launch gstpipewiresrc ! video/x-raw ! fakesink work.
See #1793
Actually count the number of frame fractions we add. If we added 0, we
don't have any supported framerate that intersects with the filter and we
try the next frame size.
See #1793
Instead of watching /dev, use a separate watch for each device.
This is supposed to achieve the same result as the now reverted
88f0dbd6fc ("v4l2: don't set inotify on /dev"):
Doing inotify on /dev is not a good idea because we will be woken up by
a lot of unrelated events.
There is a report of a performance regression on some IO benchmark
because of lock contention within the fsnotify subsystem due to this.
Instead, just watch for attribute changes on the /dev/videoX files
directly. We are only interested in attribute changes, udev should
notify us when the file is added or removed.
Fixes#3439
Doing inotify on /dev is not a good idea because we will be woken up by
a lot of unrelated events.
There is a report of a performance regression on some IO benchmark
because of lock contention within the fsnotify subsystem due to this.
Instead, just watch for attribute changes on the /dev/videoX files
directly. We are only interested in attribute changes, udev should
notify us when the file is added or removed.
A driver node should use the target_duration and target_rate to adjust
the quantum and rate when the graph starts.
The camera nodes don't currently support any of this and simply enforce
a specific rate and duration for the graph clock. Mark this with a
FIXME. Otherwise, pipewire will complain that the node is ignoring the
configured graph rate.
We should really look at the graph target rate/quantum and only produce
a buffer when it is inside the current graph cycle. This would make it
possible to join audio and camera nodes and have them be in sync.
When we get buffers from the driver, check if we have at least as many
as we requested. If we have more, that's ok, we will simply not queue
them.
Previously we would ignore the input number of buffers and use the
allocated amount to fill up the buffer array, which might be too small
and then we crash.
