First of all, the issue only seems to occur when encoding. I’ve tried running with output to nvoverlaysink instead of encoding with omxh264enc or nvv4l2h264enc. When outputting to a screen the CPU usage as stated by htop is at around 85%, spread fairly evenly across cores (no core goes above 50%). This seems to be stable (ran over several days without the issue happening).
When outputting to /dev/null through a nvv4l2h264enc, the total cpu usage for gstreamer processes is at around 93%, still spread fairly evenly across cores (no core going above 50%). However, after some amount of time (ranging from a few seconds to a tens of minutes) the pipeline crashes with ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src2: Could not read from resource. (have had it happen with all three of the sensors).
I have ran the pipeline encoding and outputting to /dev/null with input from two sensors (but otherwise exactly the same) and left it running overnight, and after 18 hours it was still running, so it seems like this might be related to the amount of data coming in from the three sensors?
Could there still be some DVFS happening causing pauses and making the ATOMP buffer overflow?
Thank you for the suggestion!
I have tried setting this but sadly this still doesn’t work. My pipeline is still crashing with the same error, and the kernel debug logs still show the ATOMP_FRAME_TRUNCATED error when things crash. tegrastats did confirm NVENC was locked at maximum frequency.
Hi JerryChang!
It does seem to be related to the multiple camera use-case. I’ve actually had it run fine with two cameras for a few days without crashing, while it crashes after just minutes with three cameras.
please refer to software features, you should check CSI and USB Camera Features.
it’s only claim multiple camera with resolution at 1920×1440@30-fps, the resolution and fps matters.
since your use-case already beyond the software supports, suggest you should have dual camera solution or reduce the resolution to have verificaition.
thanks
Ah, I see. Interestingly enough, running the same three cameras at the same resolution at once and outputting to an nvoverlaysink works perfectly fine (only thing changed is “omxh264enc ! matroskamux” to “nvoverlaysink”) - with three cameras running at 3840x2160. Runs perfectly fine for days without crashing.