On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote:
Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit :
But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers.
This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer.
What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ?
Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless.
Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase.
What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough.
Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are.
The minimum is usually between 1 and 3, depending on hardware limitations.
Regards,
Hans