I’ve managed to get input from a TC358743 chip into Gstreamer using v4l2src, however this is not using the NVMM to pass data over to the encoder, as such I believe this is why my H265 pipeline is so choppy (although I might be wrong).
Should I be piping the output into the tegra-camera-platform and using nvcamerasrc instead? How does it differ to v4l2src, is there one?
Hi,
How is it going if you run ‘v4l2src ! xvimagesink’?
If I run with xvimagesink it shows a single frame. It’s strange because when I run it through the whole pipeline it streams video perfectly. If I enable debug it shows this warning: libv4l2 converter detected, disabling CREATE_BUFS. I wonder if that’s why it’s not streaming video?
This is the pipeline I’m using…
gst-launch-1.0 v4l2src ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), format=I420’ ! omxh264enc control-rate=2 bitrate=4000000 ! h264parse ! rtph264pay mtu=1400 pt=96 config-interval=1 ! udpsink host=192.168.1.107 port=1234 sync=false async=false
At about 1% usr and 13% sys.
This also works…
gst-launch-1.0 v4l2src ! ‘video/x-raw,format=I420,width=1920,height=1080,framerate=30/1’ ! omxh264enc control-rate=2 bitrate=4000000 ! h264parse ! rtph264pay mtu=1400 pt=96 config-interval=1 ! udpsink host=192.168.1.107 port=1234 sync=false async=false
At about 17% usr and 2% sys.
These produce a good image due to using H264 although it seems to drop out every now and again. It’s also working ok on H265 with these settings, but the CPU usage is so high I can’t get anywhere near the rated encoding for the TX2.
Hi,
Do you observe the choppy screen with [v4l2src ! xvimagesink]?
Please also check the choppy screen in running [v4l2src ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), format=I420’ ! nvovlerlaysink]
These both result in a still image rather than a video. The choppy image is encoding artifacts rather than an input issue. I think the issue here is the amount of CPU usage required to encode.
The driver simply starts the CSI stream to the nvcsi and vi drivers. Is using v4l2src the preferred way of capturing from vi?
Hi,
The issue should be in the camera source because the pipelines should run as video preview, not still image. Looks like only one frame is fetched. Are you able to continuously fetch frames via v4l2-ctl ?
Yes. Plus the pipeline that streams to h264 and UDP is video. I’ve built a new master image for the TX2 and will try flashing that.
Hi,
I mean if you run
[v4l2src ! xvimagesink]
[v4l2src ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), format=I420’ ! nvovlerlaysink]
Both should result in video preview, if you see it be still image, there is something wrong in the source.
I get a video preview with the second pipeline you gave. It is a still image with the first pipeline (xvimagesink). The image is crisp and clear on the screen. However, the CPU usage is about the same (if not slightly higher) as when it is being streamed using H264/5.
What is the expected CPU usage for 1080p using nvcsi/vi at 30 FPS?
Hi aie93, please share the info of ‘sudo ./tegrastats’. It shows the CPU usage.
RAM 420/7854MB (lfb 1700x4MB) cpu [0%@1113,off,off,0%@1113,0%@1113,0%@1113]
RAM 420/7854MB (lfb 1700x4MB) cpu [1%@345,off,off,48%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [0%@345,off,off,47%@345,1%@345,1%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [2%@345,off,off,49%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [1%@345,off,off,48%@345,1%@345,1%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [3%@345,off,off,48%@345,1%@345,0%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [41%@345,off,off,8%@345,1%@345,4%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [27%@345,off,off,23%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [3%@499,off,off,48%@499,2%@499,0%@499]
RAM 420/7854MB (lfb 1700x4MB) cpu [1%@345,off,off,48%@345,0%@345,0%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [28%@345,off,off,21%@345,3%@345,2%@345]
RAM 420/7854MB (lfb 1700x4MB) cpu [32%@499,off,off,18%@499,0%@499,2%@499]
RAM 420/7854MB (lfb 1700x4MB) cpu [3%@499,off,off,48%@499,1%@499,0%@499]
RAM 420/7854MB (lfb 1699x4MB) cpu [17%@345,off,off,34%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1699x4MB) cpu [50%@345,off,off,0%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1699x4MB) cpu [50%@499,off,off,1%@499,1%@499,1%@499]
RAM 420/7854MB (lfb 1699x4MB) cpu [11%@345,off,off,40%@345,2%@345,1%@345]
RAM 420/7854MB (lfb 1699x4MB) cpu [22%@499,off,off,29%@499,1%@499,0%@499]
The result looks fine.
RAM 420/7854MB (lfb 1699x4MB) cpu [22%@499,off,off,29%@499,1%@499,0%@499]
1 CPU runs at 499MHz with 22% loaded
1 CPU runs at 499MHz with 29% loaded
1 CPU runs at 499MHz with 1% loaded
In which case, do we have any clues on why the H265 encoder seems to perform so poorly?
It is an issue in your camera source that does not give good frames to h265 encoder. The encoder works fine. We have verified it with usb cameras going through v4l2src.
What do you mean by good frames? The frames seem to work correctly with the H264 encoder.
Sorry I am a bit confused. So now the issue is you will get different CPU usage in running the following two commands?
gst-launch-1.0 v4l2src num-buffers=300 ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), format=NV12’ ! omxh264enc control-rate=2 bitrate=4000000 ! fakesink & sudo ./tegrastats
gst-launch-1.0 v4l2src num-buffers=300 ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), format=NV12’ ! omxh265enc control-rate=2 bitrate=4000000 ! fakesink & sudo ./tegrastats
Please use NV12 as encoder input and eliminate rtp streaming for pure encoder comparison.