On Jetpack 4.3, I observed this simple GStreamer pipeline taking ~8% of a CPU core. But on Jetpack 5 the same pipeline takes ~13%.
gst-launch-1.0 rtspsrc location=rtsp://10.0.0.43:554/jpeg latency=0 ! fakesink
Are there any options for this element that might help with reducing CPU? I have tried experimenting by adjusting the UDP buffer size, but that affects the framerate stability (fluctuates wildly as the buffer size decreases)
Hi,
Please execute sudo jetson_clocks and check sudo tegrastats. This should be more clear to check CPU usage. By default CPU clock is varying and it is difficult to get accurate loading from the percentage.
I’ve run jetson_clocks and set the power mode to MAXN on both Jetpack 4 and Jetpack 5. But there is a big difference in CPU usage for the same command (almost 6% of a core)
Also, I don’t think tegrastats should be used to profile individual processes, it’s good for profiling system-wide CPU/GPU consumption but not for per-process CPU load.
Please see the bash script below that I used to profile the gstreamer pipeline at 10Hz, that I borrowed from this SO post.
Profiling Script:
#!/bin/bash
set -e
topp() (
if [ -n "$O" ]; then
$* &
else
$* &>/dev/null &
fi
pid="$!"
trap "kill $pid" SIGINT
o='%cpu,%mem,vsz,rss'
printf '%s\n' "$o"
i=0
while s="$(ps --no-headers -o "$o" -p "$pid")"; do
printf "$i $s\n"
i=$(($i + 1))
sleep "${T:-0.1}"
done
)
topp $*
Command:
./topp gst-launch-1.0 rtspsrc location=rtsp://10.0.0.45:554/jpeg latency=0 ! rtpjpegdepay ! fakesink sync=false async=false
On Jetpack 4: average of 12.5% of a CPU core
1305 12.6 0.0 756728 17784
1306 12.6 0.0 756728 17784
1307 12.7 0.0 756728 17784
1308 12.7 0.0 756728 17784
1309 12.6 0.0 756728 17784
1310 12.6 0.0 756728 17784
1311 12.6 0.0 756728 17784
1312 12.6 0.0 756728 17784
1313 12.6 0.0 756728 17784
1314 12.6 0.0 756728 17784
1315 12.7 0.0 756728 17784
1316 12.7 0.0 756728 17784
On Jetpack 5: average of 18.3% of a CPU core
1227 18.3 0.0 759828 15176
1228 18.3 0.0 759828 15176
1229 18.3 0.0 759828 15176
1230 18.3 0.0 759828 15176
1231 18.2 0.0 759828 15176
Hi,
In the pipeline it looks like the CPU usage is mainly form rtspsrc. And it is upgraded from 1.14.5 to 1.16.3. We don’t have customization to the plugin, so it may be certain update in the plugin for bug fixes.
Not sure if it helps bu tyou may set the properties for a try:
retry : Max number of retries when allocating RTP ports.
flags: readable, writable
Unsigned Integer. Range: 0 - 65535 Default: 20
udp-reconnect : Reconnect to the server if RTSP connection is closed when doing UDP
flags: readable, writable
Boolean. Default: true
Or enable synchronization mechanism for a try:
... ! fakesink sync=true
I’ve tried different parameters, and the one you suggested, but they didn’t help.
It seems like the increase in CPU is not just due to the GStreamer version, but there’s something else in the newer Jetpack that’s affecting performance. Please review the results I’m sharing from running a minimal example.
Test command:
./topp gst-launch-1.0 rtspsrc location=rtsp://10.0.0.45:554/jpeg latency=0 ! rtpjpegdepay ! fakesink sync=false async=false
Average CPU (% of a CPU core)
Jetpack 4.3; GStreamer 1.14: 12.5%
Jetpack 5.1.1; GStreamer 1.14: 16.0%
Jetpack 5.1.1; GStreamer 1.16: 18%
Re-ran the minimal example with CPU vulnerability(Spectre v2 and v4) mitigations disabled .
Hi,
It looks like there is deviation between gstreamer 1.14 and 1.16. And certain increase may be from K4.9 to K5.10. We enable our platforms with upstream kernel but don’t make customization. This is more like certain code change in kernel code makes the increase. Probably CPU hotplug mechanism is more active on K5.10.
Please check the document:
CPU hotplug in the Kernel — The Linux Kernel documentation
and see if there is parameters that you can adjust to customize the mechanism for the use-case.