I am developing video processing pipelines on Jetson-TX2 using native libArgus provided by nVidia JetPack and I have a few questions regarding libArgus performance.
I am hoping someone can provide some insight regarding these matter.
- One of the performance evaluation is to produce 4 streams from a single 4K camera source (using IMX 274 through a Leopard Imaging 3 port adapter board as a test).
The 4 (consumer) stream settings are:
- 4K src => LibArgus (downscaled to 1080p, YUV420M) => H.264 encoded
- 4K src => LibArgus(downscaled to 720p, YUV420M) => H.264 encoded
- 4K src => LibArgus(cropped to 1080p, YUV420M) => H.264 encoded
- 4K src => LibArgus(cropped to 1080p and downscaled to 720p, YUV420M) => H.264 encoded
I am assuming the downscale and color space conversion is performed in the TX2 ISP feeding the camera core.
- Using JetPack 3.3 (L4T 28.2.1), I was able to achieve 30 fps at the LibArgus output and also at the H.264 encoder capture plane, so the aggregate performance is 120 fps combined given the stream settings.
Using JetPack 4.2 (L4T 32.1) I was NOT able to achieve the same performance. I can only reach about aggregate 99 fps of all 4 streams combined at libArgus output.
Was this reduction in performance due to ISP software change or due to some other reason?
Is there any means I can try to increase performance using JetPack 4.2?
The frame output of libArgus is copied into DMA buffer using IImageNativeBuffer interface in both cases.
- I have also noticed that the following .so are present in both Jetpack 3.3 and JetPack 4.2:
a. JetPack 3.3: Libargus_socketclient.so, libargus_socketserver.so, and libargus.so
b. jetpack 4.2: libnvargus_socketclient.so, libnvargus_socketserver.so, libnvargus.so
c. when using the socketclient.so (typical for gstreamer plugins and non-native applications) will invoke nvargus-daemon (as a server?)
- In JetPack 3.3, the default .so to link for native libArgus application is libargus.so and everything is working well.
- In JetPack 4.2, the default .so to link for native libArgus application has changed to socketclient version instead of the native libnvargus.so, and this incurs additional cpu loading and fps performance reduction in video processing experipements.
When I switch to link libnvargus.so for my experiment, the nvargus-daemon is no longer invoked but it seems to have more apparent memory leak, is this to be expected?
I like to understand the primary reason behind switching from using the native so (libnvargus.so) to the client version. Is this primarily to address/reduce the memory leak issue?
- JetPack 4.2 release note indicates the acknowledgement of memory leak issue,
- Is there an ETA (such as next release) or a development path planned to address this?
- Is this memory leak issue in addition to the one mentioned in L4T 28.3 or is it the same one?