<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> This seems to be a lot more related to v4l2 itself than gstreamer. About the request buffers I would make a test with yavta: <span class="token plain" style="box-sizing: border-box; color: rgb(57, 58, 52); font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 15.2px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre; background-color: rgb(246, 248, 250); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">yavta /dev/qtec/video0 --capture -n <span class="token number" style="box-sizing: border-box; font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 15.2px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre; background-color: rgb(246, 248, 250); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; color: rgb(54, 172, 170);">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 <div class="moz-cite-prefix">On 04/09/2023 12.46, <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel-request@lists.freedesktop.org">gstreamer-devel-request@lists.freedesktop.org</a> wrote: </div> <blockquote type="cite" cite="mid:mailman.22670.1693824376.927.gstreamer-devel@lists.freedesktop.org"> <pre class="moz-quote-pre" wrap="">Message: 1 Date: Sun, 3 Sep 2023 17:29:49 +0300 From: Regine Issan <a class="moz-txt-link-rfc2396E" href="mailto:regine.issan@gmail.com" moz-do-not-send="true"><regine.issan@gmail.com></a> To: Discussion of the development of and with GStreamer <a class="moz-txt-link-rfc2396E" href="mailto:gstreamer-devel@lists.freedesktop.org" moz-do-not-send="true"><gstreamer-devel@lists.freedesktop.org></a> Subject: v4l2 for slow consumer apps Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:CAA3wf2tCX_t2AHE_0YPMND8QO=JhaTmbWkLTQFXayqkhMdhSjg@mail.gmail.com" moz-do-not-send="true"><CAA3wf2tCX_t2AHE_0YPMND8QO=JhaTmbWkLTQFXayqkhMdhSjg@mail.gmail.com></a> 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. <a class="moz-txt-link-rfc2396E" href="https://forums.developer.nvidia.com/t/v4l2-limitations/265289#environment-details-details-1" moz-do-not-send="true"><https://forums.developer.nvidia.com/t/v4l2-limitations/265289#environment-details-details-1></a>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: <a class="moz-txt-link-rfc2396E" href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230903/1a8736e0/attachment-0001.htm" moz-do-not-send="true"><https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230903/1a8736e0/attachment-0001.htm></a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Best regards / Med venlig hilsen “Marianna Smidth Buschle”</pre> </body> </html>