Vi-output occupies 100% of the cpu

Hi everyone:
My orin jetpack version is 5.1.2, L4T 35.4.1
use command to get camera stream:

v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=2880,height=1860,pixelformat='UYVY' --stream-mmap=4

The camera fps is normal.
I hot-plug the camera and reset the camera, v4l2 cmd still run.
Video streams and fps obtained by V4L2 can be recovered
But “vi-output,fzca” ,It takes up 100% of a cpu

I use gstreamer command ,no such problem

I experienced this in JetPack-5.1.0
Refer to other students mentioned problem:
https://forums.developer.nvidia.com/t/vi-output-100-cpu-loading/244257
Thought the update would fix it, but it didn’t.
Please help check whether this problem is still a bug or is caused by the incompatibility between vi and v4l2
thanks

Does CPU usage still keep after recover? How long?

Even if it recovers,“vi-output, fzca” will always be 100% full of a cpu core,keep still

What’s the gst command that without problem?
Does restart v4l2-ctl help on the CPU usage?

BTW, I can’t catch the problem by using ov5693 to simulate unplug the sensor by streaming off the sensor via debugfs.

sudo su
echo 0 > sys/kernel/debug/camera-video0/streaming

Using gst cmd, hot swappable camera recovers without vi-output issues.
cmd:

gst-launch-1.0 v4l2src device=/dev/video0! 'video/x-raw,format=UYVY,width=2880,height=1860' !  videoconvert !  fpsdisplaysink video-sink=xvimagesink sync=false

yes,Restarting v4l2-ctl helps the CPU usage

I would suspect it could be caused by the APP(v4l2-ctl)
May need more information to figure it out.

Do you have an environment where this problem can be repeated?
Using the cmd I provided, read the video stream and then hot-swappable camera reset to recover the video stream. Whether the cpu of the vi-output is 100% occupied
thanks

I can’t reproduce the issue by unplug the camera(ov5693)

Under our scenario
When v4l2 cmd works. Unplugging the camera does not cause this problem. Re-enabling the camera will cause a vi-output problem when the video stream resumes

For our design unable to recovery by just connect the camera back.
But if we use debugfs to configure the sensor streaming off and streaming on to recover also didn’t see the problem.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.