Need help for TX2 mipi issue

Hi, Support,

We use mipi (Toshiba TC359746) for video capture and transmission to TX2, video format YUV422, resolution 1024x768, pixel depth 16bit, 30fps. Our application (coming from the example12 of tegra_multimedia_api) uses V4L2 API to get video frames via nvbuff on TX2. We boundled 4xlanes of mipi channels into one for our video transmission, mipi driver is ov5693.c. When our application running on TX2 received the video frames and display the video via DVI, we found the video frames was tearing on screen, which seems the half of new frame data was writen into the nvbuff which was being read by application for displaying. The screen has part of previous frame and part of the current frame. Could you help to explain where the problem is, and tell us how to fix this problem?

We use the same hardware platform as described above, but changed the video format as 1920x1080, 16bit, 30fps, yuv422.


When we capture and display this video, we also had video frame tearing problem. But when we changed the resolution to 2048x1080, the tearing problem is gone. We don’t understand why. Could you explain?DeviceTree-tegra186-camera-e3326-a00.zip (1.8 KB)

Dump the data to file to check if have the same problem. If the raw data have the same problem it could be the device configure problem.

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1024,height=768 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=5 --stream-to=test.raw

We saved the RAW image using the command you provided and found no tearing of the image.Attached is the RAW file we saved.The DVI of TX2 is set at 1024x768 and the 60 frame resolution of the camera is 1024x768 and 30 frames.Could you please help us to analyze what causes the tearing problem?
test.zip (3.5 MB)

Try to boost the nvcsi/vi clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

We have tried according to the method you provided, but the image still appears tearing phenomenon, what else can cause this phenomenon?Please help us to analyze the reason!thank you

Could you confirm with v4l2src

gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw, width=(int)1920, height=(int)1080' ! xvimagesink -ev

We tried to capture the video using the following command, and observed that the image was not torn.However, tearing will occur when using the “12_camera_v4L2_cuda” program in the official “L4T_MultimediaAPI” to collect images.Please help us to see the configuration problem of “12_camera_v4L2_cuda” program.

gst - launch - 1.0 v4l2src device = / dev/video0!'video/x-raw, format=(string)UYVY, ww

idth=(int)1024, height=(int)768’ ! nvvidconv ! 'video/x-raw(memory:NVMM), formatt

=(string)I420, width=(int)1024, height=(int)768’ ! nvoverlaysink async=false synn

c=false

Boost the system to performance to try.

sudo nvpmodel -m 2
sudo jetson_clocks

Hello, we have executed the commands of “sudo NVpmodel-M 2” and “Sudo Jetson_clocks” according to your method, but the images have not been improved at all, and the tearing phenomenon still appears.Is it possible that there is a display problem in the “12_camera_v4L2_cuda” program?

@frank133788
Could you help to break down the sample code to check if any cuda process cause the tearing.