The bottom half of my feed coming from my imx477 via jetson orin nano is delayed with the top section.
Here are 10 frames, the top section is almost real time, where the bottom half then slowly renders in and is constantly delayed.
I am using Cam1 port, i am using nvgstcapture-1.0 in the terminal
(i can only embed 2 images as I’m a new user, but the bottom half will slowly start rendering in, then always be slightly behind the top section)
It happen during the sensor start up time?
Hi Shane,
Tested this specifically:
* ran nvgstcapture-1.0 continuously for over 4 minutes, not just a few frames. The delayed-bottom-half artifact was completely consistent for the entire duration. So it’s not a sensor startup/warm-up transient; it’s a persistent, steady-state behavior of the capture pipeline on this setup.
For reference, this is on CAM1, JetPack 6.2.1 / L4T 36.4.3 (Orin Nano Super), IMX477 (Arducam B0274), using the native jetson-io-configured driver (Camera IMX477-C, num_lanes=2 — 4-lane isn’t usable on this driver per your note in another thread about sensor register reconfiguration). Cable continuity and power at the connector both check out fine (checked with multimeter), and I’ve ruled out orientation, resolution dependence, and the IR-cut filter mechanism as causes.
Let me know what else would help you narrow it down, happy to pull register dumps, try a different resolution/framerate combo, or whatever’s useful.
Thanks for looking into this.
Do you verify by any others module?
Could you have argus_camera to recoding to file to check.
Thanks
Hey Shane,
Ran the argus_camera test. Using 09_argus_camera_jpeg at a native sensor mode (1920x1080, sensor-mode 1, no ISP scaling), I get the exact same artifact as with nvarguscamerasrc/GStreamer: top of frame updates in real time, bottom ~60-70% lags behind by a noticeable delay. This bypasses GStreamer entirely, straight libargus capture to JPEG via NVJPEG.
So it reproduces identically across two independent capture backends (GStreamer’s nvarguscamerasrc plugin, and raw libargus), which rules out GStreamer or the encoder as the cause and points at the shared VI/CSI capture or ISP pipeline underneath both.
One side note: at a non-native, scaled resolution (1280x720, cropped down from the sensor’s default mode) the top was still quick/real-time, same as always, but visually shattered/torn, likely from a bad aspect-ratio or stride mismatch introduced by the ISP scaler, not a different bug. Same underlying delay, just an extra cosmetic artifact on top when scaling is involved.
We only have one other CSI module on hand (Raspberry Pi AI Camera, IMX500) and it isn’t Jetson-driver compatible, it never even gets detected as a video device on this setup, so it’s not usable as a clean sensor-vs-platform comparison. If there’s a specific known-good module you’d recommend for that test, let us know, otherwise happy to try whatever’s next on your end.
You can see how the bottom is still a bit delayed from the top section. I used this command to run it:
/usr/src/jetson_multimedia_api/samples/09_argus_camera_jpeg/argus_camera_jpeg --sensor-mode 1 --img-res 1920x1080 --cap-time 999999 --fps 30 --sid 0 -v
These are just 2 images i selected (its showing a monitor)
It’s easy to observe the problem?
Could you recording a video to show the problem.
Thanks
Of course, here is a recording:
Hello @tfolbaek
A couple of useful next steps would be:
The argus_camera_jpeg test bypasses GStreamer, but it still uses the Argus camera stack. A direct V4L2 RAW capture would better isolate the sensor/CSI/VI path:
v4l2-ctl --list-devices
v4l2-ctl -d /dev/videoX --list-formats-ext
v4l2-ctl -d /dev/videoX --all
v4l2-ctl -d /dev/videoX --verbose \
--set-ctrl=sensor_mode=1 \
--set-fmt-video=width=1920,height=1080,pixelformat=RG10 \
--stream-mmap --stream-count=100 \
--stream-to=imx477_mode1.raw
Change the commands accordingly.
You can follow this page to enable and get the trace: Sensor Software Troubleshooting — NVIDIA Jetson Linux Developer Guide
It can give you detailed information about the capture pipeline, including frame start/end events, CSI/VI errors, timeouts, etc.
Regards,
David Monge
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com
Hi David, Hi Shane,
Ran both suggested tests. Summary:
Raw V4L2 capture (bypasses Argus + ISP entirely), clean, no split.
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=60 --stream-to=imx477_motion_test.raw
Raw video from this is attached.
libargus direct capture (bypasses GStreamer, still uses ISP), same split as GStreamer/nvarguscamerasrc, confirmed at native sensor mode.
/usr/src/jetson_multimedia_api/samples/09_argus_camera_jpeg/argus_camera_jpeg --sensor-mode 1 --img-res 1920x1080 --cap-time 5 --fps 30 --sid 0 -v
VI/CamRTC ftrace during a run that visibly showed the split — zero fault/timeout/error events, fully regular vi_task_submit/isp_task_submit scheduling start to finish, clean shutdown.
modprobe rtcpu_debug
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo 3 > /sys/kernel/debug/camrtc/log-level
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace > vi_camrtc_trace.log (made an LLM agent look through it)
Conclusion: sensor, CSI, and VI/DMA capture are all clean, and firmware-level scheduling shows no faults during a run with the visible artifact. Both paths that show the bug (GStreamer and raw libargus) share the ISP processing stage; the one path that skips it (raw V4L2) is clean. Points at the ISP’s pixel-processing/output-write stage specifically, not the sensor, CSI, or capture scheduling.
Let us know what you’d want to look at next.
Please also verify by nvargus_nvraw to bypass ISP to capture the JPEG file.
Resolved. I had 2 issues:
1. Wrong ISP calibration. The camera_overrides.isp shipped in Arducam’s t234-nx-…-36.4.3 package is a generic example calibration: header reads examples\mobile\outputs\ and platform jetson chip xavier. On Orin that produces the split-frame artifact. Replacing it with RidgeRun’s IMX477 calibration resolved the corruption. This seems worth flagging to Arducam, the package ships an ISP override calibrated for a different SoC.
2. Wrong device tree overlay. I had a hand-modified 4-lane overlay active. It registered two sensor modes while the driver enumerated three, and the mode that actually streamed (4032x3040) was in neither list, which caused the sensor_mode=2 EINVAL, the silent override of S_FMT to full resolution, and the STREAMON hangs that leaked buffers. Reinstalling the Arducam package and selecting the stock imx477-dual (2-lane) overlay fixed it. All three modes now register and match the driver: 4032x3040@21, 3840x2160@30, 1920x1080@60.
Correction to my earlier post: the raw V4L2 capture I described as 1920x1080 was actually 4032x3040 (1470873600 bytes / 60 frames), the broken overlay was silently forcing full resolution. The conclusion still holds, since the raw path was clean at either resolution, but the figure was wrong.
Thanks @ShaneCCC and @david.monge ,the three-way capture comparison is what isolated the ISP stage, and the confirmation that 4-lane needs the sensor’s own register tables reconfigured saved me from chasing it further.
Good catching.
I would appreciate if you can report to Arducam to avoid the problem by forum user.
Thanks