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. 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. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
