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
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.
It is valid for V4L2 devices to not implement any controls. QUERYCTRL
returns ENOTTY in these cases. Enumerating the controls must not fail in
these cases but return no controls.
The PropInfo either has a registered id (and then also a name from the
type-info) or a custom name as a string.
In all cases, the description contains a free form text that clarifies
the property.
Use the description in the stream controls name.
Mark some structures, arrays static/const at various places.
In some cases this prevents unnecessary initialization
when a function is entered.
All in all, the text segments across all shared
libraries are reduced by about 2 KiB. However,
the total size increases by about 2 KiB as well.
If the caller asks for MemFd, pass a DmaBuf because it is mostly
the same for v4l2.
Not very correct but it's not yet trivial to fall back to memfd.
And this way we have something to give to the clients that will work
when the client asks for MemFd or MemPtr.
When allocating memory, just export the mmaped memory and mark the
memory as MemPtr, not MemFd. Set the fd to -1.
Otherwise we might send this fd to the client, making the complete
device accessible to the client.
Some drivers seem to only use 2 buffers when asked for 16 buffers. We
can see this because the buffer is already queued. In this case, just
use the 2 buffers.
See #294
Only set the OUTSTANDING flag when we placed the buffer in an
io area and need to recycle it later.
When we captured a frame, put it in the queue. Then dequeue it
into the io area after recycling buffers.
Fixes#217
Add some padding, tweak some padding
Remove count in the clock, it's useless
For video frames we will want to use metadata to place
this on individual buffers.
Move some things around. Move the duration of the current cycle
to the clock. Also add the estimated next timeout to the clock.
Add a generic media specific counter to the clock.
Clean up the position_bar info. We can do with only a double beat
value and make the signature in floats.
Flesh out the io_position info. This has now the information needed
to convert a raw clock time into a stream time. It basically has
the same kind of features as GStreamer segments such as looping,
variable rate playback etc.. It also contains the state of the
timeline (paused/playing) and it can be used to update the position
and state from clients.
There is also extended information in the position field that
clients can update when they can.
Plugins basically only update the clock info they get (and use
the position info to check if they are slaved or not).
Before each cycle, check if there is a pending position update and
apply it.
Keep the output port buffers in a special mix info. They should
stay there even when the mix is removed and should only be cleared
explicitly with a NULL Format or 0 use_buffers.
