V4l2 limitations

Hello,i am trying to use v4l2 to capture frames, with zero copy.
to support set of consumers running in dockers,
I am using userptr mode (pointing to shared memeory).
to support “slow” consumers, i need to keep buffer 300 frames.Problem:
when i call VIDIOC_REQBUFS with count > 32 ,
it returns a struct with req.count = 32
(meaning, it allocated only 32 buffers).

questions are:

   assume i keep using userptr mode,
    is there anything to do request buffer of 300 pointers (in userptr mode) ?
    i have been reading several links about that question but non of them worked

  assuming i keep using userptr mode,
  i was thinking about the idea below.
 has anyone tried it ? any reason it will not work ?
      a. allocte a private  queue of 300 buffers to shared memeory.

       b.each time  i get frame from v4l2,

       b.1  dequeue the frame from v4l2 queue (with 32 items)
       b.2 enqueue it to private queue (with 300 items
      b.3 dequeue  pointer from private queue (with 300 ietms
       b.4 enqueue that pointer to v4l2 buffer (with 32 items)

   should i try r\w mode instead userptr 
   in r\w mode, i we call select and then read , providing read and address.
   i was thinking about the following idea:
   manage a cyclic buffer with 300 pointers to shared memory.
  each time i will call read , i will provide the point to the shared memory
  what are the disadvantages of that mode comparing to userptr ?

i read that r\w mode does not provide time stamptsm but i am not sure that does that mean and what are the implications.

would you recommend any other v4l2 mode to support the requirements ?

if i will use dmabufs mode, i will eoncounter the same issue (failing on request bufs)

Environment details detailsAGX Orin
Ubunto, 20.04.6 LTS, Release 20.04, Codename: focal
linux kernel: 5.10.104-tegra
l4t 35.1.0

please see-also Topic 201589 for running 12_camera_v4l2_cuda.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.