How can you determine the Arducam driver is loaded from that message? With the Arducam driver I would expect to see 4032x3040 as an available sensor mode for use in gstreamer, but I do not. See here for some more notes - https://github.com/ArduCAM/MIPI_Camera/issues/132
From what I’ve read on this forum and elsewhere, it appears the Arducam driver used to provide access to other resolution modes. Our use case depends on having access to the full 4:3 sensor readout of 4032x3040 at 30fps. Has that support been deprecated? From the wording on that Arducam page, it sounded like the Nvidia driver works but is limited to the two modes, whereas the Arducam driver was in continued development with the aim of providing additional modes. Is that not correct? Are you saying that the current Arducam driver is 100% functionally the same as the Nvidia one?
Yes, we will continue to develop, but the two drivers are the same at present, and we have not received any requests from users before, so we think maybe the current mode is enough.
At the moment, what you mainly want is the maximum resolution, right? Maybe we can finish it this week.
Thanks for the info. Yes, having the full 4:3 sensor resolution mode @ 30fps is very important for us, and I imagine other users as well (who are maybe just currently using older L4T / drivers). Please let me know if there’s anything I can do. Having that additional mode this week / next would be extremely helpful. Thanks!
Nice! The full resolution capture looks great. This is exactly what I need. Thanks!
One side note is that when running gst-launch-1.0 you need to specify sensor-mode=0|1|2 corresponding to the output of v4l2-ctl --list-formats-ext or else the output is just scaled/stretched from the default sensor mode, rather than correctly using a different window of the sensor (ie. 16x9 vs. 4x3). As long as the correct sensor-mode is used (0 in my case with this latest driver), all looks perfect. Thanks again!
Do you happen to know of any ways to minimize the chance of these drops? I’ve run sudo jetson_clocks but that doesn’t seem to have any impact. Are there any gstreamer buffers / settings that can be modified from the command-line that could help? Thanks again.
Sorry, I don’t know why the frame is dropped here, maybe it is caused by the insufficient processing speed of a certain component.
Perhaps it is the H264 encoding component?
It looks like the frames are dropping/duping on the earliest stages of the pipeline. I tested this by removing all encoding / parsing / muxing, filming a stopwatch, and then extracting individual frames and looking for dupes / dropped frames.
Here’s an example that outputs to raw YUV and then extracts the frames:
My question is, if I set framerate=24/1, will that actually force the sensor to produce frames at 24fps, or will it still be producing frames at the defined fps per the sensor mode (ie. 30fps) and then skipping frames to achieve 24fps?
If it is skipping frames to achieve 24fps (or any arbitrary fps), would it be possible to create a new sensor mode at a lower fps to avoid dropped / duped frames?
Thanks again!
PS - Here’s a Dropbox Link that contains the output files from the above YUV output test. You can see that frame 15 and 16 show the same time on the stopwatch, and are dupes.
For the YUV test, I was outputting to /dev/shm/ which is the ramdisk, so there shouldn’t be any throughput concerns. I’ll do a little more testing and get back to you. Thanks again.
Yah, it could be a limitation in the ISP. Lowering the resolution (and still using sensor-mode=0 to use the full 4:3 aspect ratio) does seem to reduce these frame drops/dupes. Using jetson_clocks also helps, and essentially makes the drops/dupes a non issue (the only drops are at the very beginning of the capture). Will this driver become an official release for Arducam? I hope so. Thanks again!
Is the latest Arducam driver based on the latest Nvidia driver? Or is it possible that it’s based on an earlier version that had this same v4l2-ctl issue? Thanks again.