v4l2 for slow consumer apps

[Marianna Smidth Buschle]

This seems to be a lot more related to v4l2 itself than gstreamer.


About the request buffers I would make a test with yavta:

yavta /dev/qtec/video0 --capture -n 300

Then you can see if the limitation is on your driver (which then you 
can't do anything about) or if there is something with the v4l2 
implementation in gstreamer.


I don't really have any experience with the usrptr mode, I normally use 
mmap and then copy the frames to my own buffers.

But I would guess that your idea of "shifting" the allocated memory 
around could work.
And I would also think it has the potential to work with mmap as well.


I have tried using RW mode 10+ years ago and in that case it was too 
slow (I guess because of opening/closing the file), but it probably was 
just that I didn't know how to use it properly at the time.

A clear disadvantage of RW mode is not getting any metadata, in my case 
I use the timestamp and sequence number to detect frame drops, etc.

And I suppose that when using the RW mode since you don't specify to the 
driver how many frames to "buffer" I would think that if you don't read 
fast enough you will either drop frames on the driver side or get 
"stuck" with the older frame until you read it.


Best Regards

Marianna

On 04/09/2023 12.46, gstreamer-devel-request at lists.freedesktop.org wrote:
> Message: 1
> Date: Sun, 3 Sep 2023 17:29:49 +0300
> From: Regine Issan<regine.issan at gmail.com>
> To: Discussion of the development of and with GStreamer
> 	<gstreamer-devel at lists.freedesktop.org>
> Subject: v4l2 for slow consumer apps
> Message-ID:
> 	<CAA3wf2tCX_t2AHE_0YPMND8QO=JhaTmbWkLTQFXayqkhMdhSjg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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:
>
>         question1:
>         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
>
>        question2:
>        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 provate queue (with 300 ietms
>             b.4 enqueue that pointer to v4l2 buffer (with 32 items)
>
>         quesiton3:
>         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 ?
> PS:
> 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.
>
>     question4:
>     would you recommend any other v4l2 mode to support the requirements ?
>
> question5:
> if i will use dmabufs mode, i will eoncounter the same issue (failing on
> request bufs)
>
>     1.
>
> <https://forums.developer.nvidia.com/t/v4l2-limitations/265289#environment-details-details-1>Environment
> details details
>
> AGX Orin
> Ubunto, 20.04.6 LTS, Release 20.04, Codename: focal
> linux kernel: 5.10.104-tegra
> l4t 35.1.0
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230903/1a8736e0/attachment-0001.htm>

-- 
Best regards / Med venlig hilsen
“Marianna Smidth Buschle”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230904/0d5fa647/attachment.htm>