Hi all, This mail thread uncovered some corner cases around how many buffers should be allocated if VIDIOC_REQBUFS with count = 1 is called: https://lore.kernel.org/linux-media/20241003-rp1-cfe-v6-0-d6762edd98a8@xxxxxxxxxxxxxxxx/T/#mc2210597d92b5a0f09fabdac2f7307128aaa9bd8 When it comes to the minimum number of buffers there are a number of limitations: 1) The DMA engine needs at least N buffers to be queued before it can start. Typically this is 0, 1 or 2, and a driver sets this via the vb2_queue min_queued_buffers field. So if min_queued_buffers = 1, then the DMA engine needs one buffer at all times to DMA to. Allocating just one buffer would mean the DMA engine can never return that buffer to userspace (it would just keep recycling the same buffer over and over), so the minimum must be min_queued_buffers + 1. 2) Historically VIDIOC_REQBUFS is expected to increase the count value to a number that ensures the application can smoothly process the video stream. Typically this will be 3 or 4 (if min_queued_buffers == 2): min_queued_buffers are used by the DMA engine, one buffer is queued up in vb2, ready to be used by the DMA engine as soon as it returns a filled buffer to userspace, and one buffer is processed by userspace. This is to support applications that call VIDIOC_REQBUFS with count = 1 and leave it to the driver to increment it to a workable value. 3) Stateful codecs in particular have additional requirements beyond the DMA engine limits due to the fact that they have to keep track of reference buffers and other codec limitations. As such more buffers are needed, and that number might also vary based on the specific codec used. The V4L2_CID_MIN_BUFFERS_FOR_CAPTURE/OUTPUT controls are used to report that. Support for this is required by the stateful codec API. The documentation of these controls suggest that these are generic controls, but as of today they are only used by stateful codec drivers. 4) Some corner cases (mainly/only SDR, I think) where you need more than the usual 3 or 4 buffers since the buffers arrive at a high frequency. Rather than have drivers try to correct the count value (typically incorrectly), the vb2_queue min_reqbufs_allocation field was added to set the minimum number of buffers that VIDIOC_REQBUFS should allocate if count is less than that. VIDIOC_CREATE_BUFS is not affected by that: if you use CREATE_BUFS you take full control of how many buffers you want to create. It might create fewer buffers if you run out of memory, but never more than requested. But what is missing is that if you use CREATE_BUFS you need to know the value of min_queued_buffers + 1, and that is not exposed. I would propose to add a min_num_buffers field to struct v4l2_create_buffers and add a V4L2_BUF_CAP_SUPPORTS_MIN_NUM_BUFFERS flag to signal the presence of that field. And vb2 can set it to min_queued_buffers + 1. The second proposal is to explicitly document that the V4L2_CID_MIN_BUFFERS_FOR_CAPTURE/OUTPUT are for stateful codec support only, at least for now. If this is in place, then min_reqbufs_allocation should be set to a sane number of buffers (i.e. typically 3 or 4), and if you want precise control, use VIDIOC_CREATE_BUFS. Regards, Hans
