Occasional slowdown (high cpu utilization) in 4 channel encoder application.

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

We have a TX2 application that captures video from CSI inputs, then encodes and transmits H264 video.

Normally it operates fine, the cpu is 80% or so idle (i.e. 20% utilization) , and the video quality is good (i.e. smooth). Our test scene is highway traffic,so there is quite a bit of fast motion, so any ‘stuttering’ is easily visible.

Encoding is done with a gstreamer pipeline like this (there’s a custom deinterlace step).

v4l2src device=/dev/video0  ! capsfilter caps=video/x-raw,width=720,height=243
! queue ! preinterlace ! deinterlace  ! nvvidconv ! capsfilter caps=video/x-raw(memory:NVMM)
! omxh264enc insert-sps-pps=true control-rate=1  profile=baseline  bitrate=8000000 iframeinterval=30
! capsfilter caps=video/x-h264,stream-format=(string)byte-stream
! queue ! h264parse config-interval=5  !  tee name=t  
t. ! queue ! mpegtsmux name=mux pat-interval=10000 pmt-interval=10000 alignment=7  
!  udpsink ttl=16 ttl-mc=8 ttl-mc=8 send-duplicates=false auto-multicast=false name=udpsinkts  
t. ! queue !  rtph264pay mtu=1400 config-interval=1 
!  udpsink ttl=16 ttl-mc=8 ttl-mc=8 send-duplicates=false auto-multicast=false name=udpsinkrtp bind-port=12002

After running for a while (several hours), there’s a failure scenario where the
following things happen

  1. Aggregate CPU utilization goes way up to 90%.
  2. Video shows intermittent stalls/stuttering.
  3. gstreamer pipelines repeatedly show the following error
pipeline warning mpegtsmux mpegtsmux.c:1161:mpegtsmux_clip_inc_running_time: ignoring DTS Going backward

Note that we are not 100% sure the error message correlates with the error
condition. The high CPU usage is definitely related.

This problem case cannot be cleared by restarting the encoding process, or resetting the TX2, it seems to require a power cycle to clear.

It is unclear if this is related to temperature, does seem possible, but looking through /sys/class/thermal/* it looks like the board is reaching about 60 deg-c, but the thresholds are closer to 90 to 100 deg-c.

Any ideas how we might go about tracking this down?

Thanks in Advance,

Cary

2

Hi,
Can you try to run sink in ‘sync=false’. DTS is decoding time stamp. There are synchronization mechanism in gstreamer frameworks. It might help to disable it.