Video Preview Tearing

Im trying to find the “best’“/”correct” settings for my camera on my Nano.

Jetpack version:

# R36 (release), REVISION: 4.7, GCID: 42132812, BOARD: generic, EABI: aarch64, DATE: Thu Sep 18 22:54:44 UTC 2025

# KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia

TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

Camera:
IMX477

v4l2-ctl --list-formats-ext

ioctl: VIDIOC_ENUM_FMT

	Type: Video Capture



	[0]: 'RG10' (10-bit Bayer RGRG/GBGB)

		Size: Discrete 4032x3040

			Interval: Discrete 0.048s (21.000 fps)

		Size: Discrete 3840x2160

			Interval: Discrete 0.033s (30.000 fps)

		Size: Discrete 1920x1080

			Interval: Discrete 0.017s (60.000 fps)

Issue:
When Im using nvgstcapture-1.0 without any flags, anything that should be centered in the video output is actually on the bottom right. When I set the flags to use 3840x2160 at 30fps, the video is tearing in the middle across the center.

Caveat: I have been using this over vnc, so Ill try it natively over HDMI just in case.

Hello @wasson.5e,

Have you tried capturing with gst-launch-1.0 and nvarguscamerasrc directly instead?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, it appears that you are experiencing issues with your camera settings on the Jetson Orin Nano. Specifically, you are seeing that objects that should be centered in the video output are instead appearing on the bottom right, and when you try to use a higher resolution and frame rate, the video is tearing in the middle.

To address this issue, I would recommend trying the following:

  1. Check your camera configuration: Ensure that your camera is properly configured and that the settings are correct. You can try using the nvgstcapture-1.0 command with the --help flag to see a list of available options and settings.
  2. Try a different capture method: Instead of using nvgstcapture-1.0, try using nvarguscamerasrc to capture video from your camera. This may help to resolve any issues related to the camera configuration.
  3. Adjust the resolution and frame rate: Try reducing the resolution and frame rate to see if this resolves the tearing issue. You can use the --resolution and --framerate flags with nvgstcapture-1.0 to adjust these settings.
  4. Check for any hardware issues: Ensure that your camera is properly connected to the Jetson Orin Nano and that there are no hardware issues that could be causing the problem.
  5. Try running the application natively: As you mentioned, try running the application natively over HDMI instead of using VNC to see if this resolves the issue.

In terms of specific settings, you may want to try the following:

  • nvgstcapture-1.0 -i 0 -r 3840x2160 -e to capture video at 3840x2160 resolution and 30fps.
  • nvgstcapture-1.0 -i 0 -r 1920x1080 -e to capture video at 1920x1080 resolution and 30fps.
  • nvarguscamerasrc -i 0 -r 3840x2160 -e to capture video at 3840x2160 resolution and 30fps using nvarguscamerasrc.

It’s also worth noting that the IMX477 camera has a maximum resolution of 3840x2160, so you may want to try reducing the resolution to see if this resolves the issue.

In comparison to other Jetson models, the Jetson Orin Nano has a similar camera interface to the Jetson AGX Orin, but with some differences in terms of camera configuration and settings. Therefore, you may need to adjust your camera settings accordingly.

I hope this helps to resolve your issue. If you have any further questions or concerns, please don’t hesitate to ask.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

I haven’t, but trying now. Hitting error after error trying to use the examples for the pipelines.

Using this information:

Nvidia GStreamer

GStreamer Docs

Update:

Trying this (just to try) since it’s a Bayer sensor, but hitting issues.

gst-launch-1.0 nvarguscamerasrc num-buffers=200 ! 'video/x-raw(memory:NVMM), width=1920, height=1080, framerate=30/1, format=NV12' ! omxh264enc ! qtmux ! filesink location=test.mp4 -e
WARNING: erroneous pipeline: no element "omxh264enc"

So, turns out omxh264enc is deprecated

So then I try and use

nvv4l2h264enc ! h264parse

And hit the same issue

WARNING: erroneous pipeline: no element "nvv4l2h264enc"

@wasson.5e,

Interesting. These pipes here should work.

Are you hitting errors with those?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

Tried checking your link, and the browser didn’t like it.

After searching, I should have the decoder installed

Nvidia Link

awasson@orinnano:~$ sudo apt list --installed | grep nvidia-l4t-gstreamer

nvidia-l4t-gstreamer/stable,now 36.4.7-20250918154033 arm64 [installed]

@wasson.5e,

Oops, thats weird. Its a sibling of the link you shared:

In section:

Applications Using GStreamer with V4L2 Source Plugin

But I saw you updated your previous message. Will check it out.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

@wasson.5e,

Can you try this pipe instead of the one that records video into a file?

gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, format=(string)NV12, framerate=(fraction)30/1' ! nvoverlaysink -e

Although is weird you don’t have the HW encoder elements. They should be available with Jetpack.

How did you flash your board?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

Yeah, I’ll give it a shot.

I flashed the ssd using the image from Nvidia, and then updated it according to their instructions.

Command failed due to syntax, but I don’t think it was what you sent.

Throws error:

awasson@orinnano:~$ gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, format=(string)NV12, framerate=(fraction)30/1' ! nvoverlaysink -e
-bash: syntax error near unexpected token `('

Works other than decoder:

awasson@orinnano:~$ gst-launch-1.0 nvarguscamerasrc num-buffers=200 ! 'video/x-raw(memory:NVMM), width=1920, height=1080, framerate=30/1, format=NV12' ! nvv4l2h264enc ! h264parse ! qtmux ! filesink location=test.mp4 -e
WARNING: erroneous pipeline: no element "nvv4l2h264enc"

@wasson.5e,

I think the issue might be the quotation marks used in the pipeline.

Can you try with:

gst-launch-1.0 nvarguscamerasrc ! "video/x-raw(memory:NVMM), width=1920, height=1080, format=(string)NV12, framerate=(fraction)30/1" ! nvoverlaysink -e

best regards,
Andrew
Embedded Software Engineer at ProventusNova

Any customized for the sensor driver device tree?

If yes, could you verify by native imx477 that enable by jetson-io.

Thanks

It didn’t like that either:

awasson@orinnano:~$ gst-launch-1.0 nvarguscamerasrc ! "video/x-raw(memory:NVMM), width=1920, height=1080, format=(string)NV12, framerate=(fraction)30/1" ! nvoverlaysink -e

WARNING: erroneous pipeline: no element "nvoverlaysink"

I don’t ‘think’ that the tree was edited. I enabled the camera by using jetson-io.py.

Just found out that nvoverlaysink is deprecated.

https://forums.developer.nvidia.com/t/nvarguscamerasrc-nvoverlaysink-missing/250307

This worked, but Im testing the Nano from remote (right at this second), and I didn’t see tearing. Another issue I was seeing is that when you place an object directly in front of the camera, the video is showing the object to be on the bottom right (of the output).

gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM),framerate=30/1,format=NV12' ! nvvidconv ! xvimagesink

Hey @wasson.5e,

That is an interesting behavior.

Can you share an image just so I can better visualize it ?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

I think that might have been due to resolution and the window size. Here is the tearing I’m seeing

@wasson.5e,

Thanks for sharing the image.

A couple questions:

  1. Does the tearing “move” ? Or is ti static?

  2. Can you try changing the pixel clock value on the device tree for something higher? It could be double what you currently have… is just a quick test.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

The tearing actually moves. I’ll try changing the clock value.

@wasson.5e,

Yeah that sounds like possible misconfiguration in pixel clock or on sensor timing.

Please keep me posted.

best regards,
Andrew
Embedded Software Engineer at ProventusNova