Forking the thread,
Le mercredi 15 janvier 2025 à 16:03 +0100, Paul Kocialkowski a écrit :
> Last words about private driver buffers (such as motion vectors and
> reconstruction buffers), I think they should remain private and unseen from
> userspace. We could add something extra to the uAPI later if there is really a
> need to access those.
I don't know if you noticed, but Jacopo started a proposal around multi-context
media controller. For this type of extension, my long term idea was that we
could adopt this, and introduced new nodes to expose specialized memory. These
nodes would be unlike by default, meaning the default behaviour with a single
m2m video node would remain.
An existing use case for that would be in the decoder space, VC8000D and up have
4 post processed output, which mean up to 5 outputs if you count the reference
frames. So we could set it up:
bitstream -> m2m -> reference frames
|
-- capture 1 -> post processed
|
-- capture 2 -> post processed
|
-- capture 3 -> post processed
|
-- capture 4 -> post processed
Simpler said then done, but I think this can work. I suspect it is quite
feasible to keep the stream state separated, allowing to reconfigure the chosen
output resolution without having to reset the decoder state (which is only bound
to reference frames). It also solve few issues we have in regard to over-memory
allocation when we hide the reference frames.
For encoders, reconstruction frames would also be capture nodes. I'm not
completely versed into what they can be used for, also their pixel format would
have to be known to be useful of course.
Nicolas
