We try to encode 6 video channels 720p60. It works great on 2 unit but on the 3-rd unit the video(s) looks a little bit corrupted after 20 or so minutes of encoding, moreover it looks like the time encoded within the stream goes slower:
We record a running clock, then when we playback the recorded video on the VLC application (on a PC) the slide bar shows after 40 minutes a gap of 4 minutes, while the time on the video shows the correct time (to ensure it with an external stop watch). Above is beside the corrupt frames once per a few seconds.
We run the same software (equiped with GStreamer) and the units share the same kernel version.
When we reduce the number of encoded streams to 3 (on the “corrupted” unit), the recorded movies looks OK as on the “good” units.
Hi,
Please share information about the cameras, such as vendoer and model ID. If the cameras are from our camera partners, we will check with them and do further investigation.
our unit has an FPGA which converts HD-SDI to MIPI. The unit is fed with an HD-SDI from HDMI active converter , which video is fed from a laptop. So no cameras there.
We thought that the input video video might be an issue as a non stable provider of 60 fps, but we have used the same setup and only replaced the unit, another thing that we did was replacing only the Jetson module, so we have narrowed the problem to a specific Jetson module.
we’ve run the script above (included video source field) for 30 minutes on 6 independent input channels, where the average framerate was 60 and there were no frames drop.
sudo nvpmodel -m 0 and sudo jetson-clocks is activate at all times upon unit boot - we activate it.
Though the connectivity between nvvidconv and omxh264enc per the following command line fails:
We’ve run the above pipeline on six simultaneous terminals with no problems, though when we added the 7-th we have experienced a drop in average bit rate (no frames’ drop) (from 60 to 55), the more terminals we added the more the average dropped.
We understand that the Jetson TX2 supposed to support a single 4k channel encoding, or it can encode the following number of pixels:
3840 x 2160 x 60 x1= 497,664,000 [pixels]
while we utilize only:
1280 x 720 x 60 x 7 = 387,072,000 [pixels]
(1280 x 720 x 60 x 9 = 497,664,000 [pixels])
I guess that there is some overhead which we must reduce in order to handle the problem we are facing.
Any advise?
There is a memory copy of CPU buffers to NVMM buffers in nvvidconv. We have an optimal solution in jetson_multimedia_api and demonstrated in 12_camera_v4l2_cuda, but in gstreamer, need to have the memory copy and it may impact the performance. You can check system loading by executing sudo tegrastats.
Hi,
On r32 releases, we have implemented a plugin nvv4l2camerasrc to eliminate the memory copy. Since you are on r28 release, have to use v4l2src. One thing you can try is to build the plugin on r28. But the source code is open on r32, it’s not guaranteed to work. You can see the source code in JP4.4.1 or JP4.5.
I finally have installed the JP4.5 on the evaluation board. and downloaded the Linux sources to both machines with r28 and r32. and tried to recompile the nvv4l2camerasrc:
r28:
nvidia@tegra-ubuntu:~/Linux_for_Tegra/source/public/gst-nvv4l2camera$ make clean
rm -rf gstnvv4l2camerasrc.o libgstnvv4l2camerasrc.so
nvidia@tegra-ubuntu:~/Linux_for_Tegra/source/public/gst-nvv4l2camera$ make
g++ -c gstnvv4l2camerasrc.cpp -fPIC -DEXPLICITLY_ADDED=1 -DGETTEXT_PACKAGE=1 -DHAVE_LIBV4L2=1 -DUSE_V4L2_TARGET_NV=1 pkg-config --cflags gstreamer-1.0 gstreamer-base-1.0 gstreamer-video-1.0 gstreamer-allocators-1.0 glib-2.0 libv4l2 -I./ -I…/ -o gstnvv4l2camerasrc.o
Package libv4l2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libv4l2.pc’
to the PKG_CONFIG_PATH environment variable
No package ‘libv4l2’ found
gstnvv4l2camerasrc.cpp:40:21: fatal error: gst/gst.h: No such file or directory
compilation terminated.
Makefile:67: recipe for target ‘gstnvv4l2camerasrc.o’ failed
make: *** [gstnvv4l2camerasrc.o] Error 1
Hi,
For r28 releases, the optimal solution is to execute sudo nvpmodel -m 0 and sudo jetson_clocks. If this does not bring enough perofrmance(six 720p60 encoding), you may try to build nvv4l2camersrc on r28, but it is not guaranteed to work since the source code is for r32.