•|Hardware Platform Jetson AGX Xavier|
| •|DeepStream Version 4.0 And 5.0|
| •|JetPack Version 4.2 and 4.4 DP|
| •|TensorRT Version 5.0 and 7.1|
Hello guys, during my tests I noticed that:
executing the following pipeline I get different results using DS4 or DS5
gst-launch-1.0 filesrc location = /opt/nvidia/deepstream/deepstream-5.0/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! nvvideoconvert ! video/x-raw,format=RGBA ! fakesink
gst-launch-1.0 filesrc location = /opt/nvidia/deepstream/deepstream-4.0/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! nvvideoconvert ! video/x-raw,format=RGBA ! fakesink
on Jetson AGX Xavier
Jetpack 4.4DP and DS5.0 the execution time is:0:00:08.959876829
on jetson AGX Xavier Jetpack 4.2 and DS4.0 the execution time is: 0:00:03.024086334
If I remove the nvvideoconvert and restart the execution I get the following results:
gst-launch-1.0 filesrc location = /opt/nvidia/deepstream/deepstream-5.0/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! fakesink
gst-launch-1.0 filesrc location = /opt/nvidia/deepstream/deepstream-4.0/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! fakesink
on Jetson AGX Xavier
Jetpack 4.4DP and DS5.0 the execution time is:0:00:02.943324920
on jetson AGX Xavier Jetpack 4.2 and DS4.0 the execution time is: 0:00:02.982979002
As you can see without nvvideoconvert the results are very similar, with nvvideoconvert through DS5 the execution seems slower than the previous one made through DS4.
Is there any reason?
Did I make any mistake?
with the solution you provide me with, the results that I get on DS5 are similar to the ones of DS4.
Just one more thing, do you think that in further release of Jetpack (4.4 no developer preview) this settings will be enabled by default?
We have developed a feature in r32.4.3:
Support for Dynamic Frequency Scaling (DFS) for Video Image Compositor (VIC) using actmon
L4T page. If the loading is fine and performance is enough, you may keep it enabled for saving power. If you run a heavy-loading system, you can disable it and run in max clock.
@DaneLLL Under what circumstances should we do this ? When running multiple sources in a deepstream pipeline - anything that needs max performance?
How do we disable max clocks on VIC? Woud it be:
$ echo off > /sys/devices/13e10000.host1x/15340000.vic/power/control
Is there any criteria to set the best value for target frequency?
Is there a way to make these values persistent, also after a reboot of the device?
By default DFS is enabled. For manualy control, you can list all frequencies
$ cat /sys/devices/13e10000.host1x/15340000.vic/devfreq/15340000.vic/available_frequencies
And pick one fitting your usecase.
@DaneLLL - It seems strange that DFS is causing slower pipelines in DS5.0dp. What is the purpose of DFS if this is the case?
Are you able to help with previous questions:
Should we always switch to manual and max clocks (this is basically what jetson_clocks does for everything else)
How to disable manual and turn DFS back on
How to automatically set this so we don’t have to do it every time after a reboot?
The purpose of DFS is for power saving. Actually sample_1080p_h264.mp4 is a 50-second content. It looks OK to have the execution time 0:00:08.959876829. If you don’t have concern in power consumption and like to turn off DFS, please add the commands in rc.local to manually configure it. There is an example of using rc.local:
We follow this page to add /etc/systemd/system/rc-local.service
and add /etc/rc.local
/usr/bin/gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=300 ! video/x-raw,width=1920,height=1080,framerate=30/1,format=UYVY ! queue max-size-time=0 ! nvvidconv ! 'video/x-raw(memory:NVMM)' ! omxh264enc bitrate=5000000 ! video/x-h264 ! h264parse ! video/x-h264 ! queue ! flvmux name=mux streamable=true ! filesink location=/tmp/a.flv audiotestsrc num-buffers=500 ! queue ! audioconver…