Hi everyone, I’m working with the Arducam IMX519 cameras (the 122° wide-angle lens version) on an Nvidia Orin Nano and I’m trying to get 2560x1440p30 output. Right now I can successfully run 1920x1080p60 and 3840x2160p17 using GStreamer with nvarguscamerasrc, but I can’t figure out how to get that middle resolution at a usable framerate. Does anyone know if there’s a driver modification needed to add a custom resolution/framerate mode for 1440p30? Or is there a GStreamer trick I’m missing?
The IMX519 sensor natively outputs 3840x2160 at roughly 17 fps — there’s no native 2560x1440 mode defined in the driver. But you don’t really need a driver change for this. The cleaner approach is to use the nvvidconv element in your GStreamer pipeline for hardware-accelerated scaling. It runs on the NVMM memory model so it’s quite efficient on Jetson hardware. Try this pipeline:
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)3840, height=(int)2160, framerate=(fraction)17/1' ! nvvidconv ! 'video/x-raw, width=(int)2560, height=(int)1440, framerate=(fraction)30/1' ! nvoverlaysink
The idea is: capture at the sensor’s native 4K resolution, then let nvvidconv handle the downscale to 1440p. No driver modification needed.
Thanks for the suggestion. I tested that exact pipeline and ran into two problems:
- The output is 2560×1550, not 2560×1440 — seems like the scaling is a bit off.
- More importantly, the framerate is still 17 fps. It looks like nvvidconv is just scaling the frames after capture, but the sensor itself is still running at its native 17 fps. The framerate=30/1 in the caps after nvvidconv doesn’t actually speed anything up — it just drops or duplicates frames I think.
What I really need is a sensor-level solution: something like a binning mode where the sensor bins the full 3840×2160 frame down by 2×2, which would give roughly half resolution but potentially double the framerate (around 34 fps). That way I’d have enough real frame data to work with. Is this something Arducam can implement in the driver? Or could the driver source code be shared so I can take a stab at implementing a binned mode myself?
You’re exactly right — nvvidconv only does spatial scaling; it can’t increase the sensor’s native framerate. The framerate caps on the output side of nvvidconv won’t magically give you more real frames. To actually get higher framerates at lower resolutions, you need a sensor mode that uses binning or skipping at the hardware level.
I’ve sent you the IMX519 driver source code via private message. Please check your messages for the download.
The general approach would be to add a new sensor mode entry in the driver that does 2×2 binning on the full 3840×2160 pixel array. That would give you a 1920×1080 output directly from the sensor at roughly double the framerate (~34 fps). From there, if you specifically need 2560×1440, you could still use nvvidconv to upscale slightly from the binned 1080p output — and at that point you’d have real ~34 fps to work with rather than 17.
Got the source, thanks. I’ll start digging into it. A couple quick questions before I go down this path:
- Is there an existing mode in the driver that already does binning I could reference as a template, or is the current driver entirely full-resolution modes?
- For the 2×2 binning implementation, are there any IMX519 register sets or timing tables you can share that would help with configuring the sensor for binned readout? I want to make sure I’m setting up the pixel clock and blanking intervals correctly for the ~34 fps target.
Appreciate the help — I think this is the right approach vs. trying to force it through GStreamer alone.
The current IMX519 driver as shipped only defines full-resolution modes (no binning/skipping modes are present), so you’ll be adding one from scratch. That said, the existing mode table structure in the driver should serve as a reasonable template — same register categories, just different values for the binned readout.
I’ve also sent you a set of IMX519 register configuration tables via private message that include the binning-related registers you’ll need. The key areas to focus on are:
- Binning mode select registers to enable 2×2 averaging
- Frame timing registers (line length, frame length) adjusted for the binned output — since you’re reading out fewer lines, the frame period shortens and framerate goes up
- Output size registers set to 1920×1080
The math works out roughly like: halving the vertical line count through binning means the frame readout time is cut roughly in half, which takes you from ~17 fps to ~34 fps. You may need to tweak the pixel clock slightly depending on what the ISP on the Orin side expects. Let us know how it goes or if you hit any register-level issues.