Skipped frames when displaying RTP / H.264 stream

[jean-philippe]

Update.

I've managed to narrow the problem down to the 'rtph264pay' and/or
'rtph264depay' elements.

With the following pipeline measures a framerate of 29.77Hz which
corresponds to 1 frame being lost every 128 frames:

videotestsrc is-live=true !
video/x-raw,width=640,height=480,format=I420,framerate=30/1 ! queue !
vpuenc_h264 ! queue ! rtph264pay ! queue ! rtph264depay ! fpsdisplaysink
text-overlay=false video-sink=fakesink sync=false

With either of the following pipelines, the framerate is 30Hz:

videotestsrc is-live=true !
video/x-raw,width=640,height=480,format=I420,framerate=30/1 ! queue ! 
rtpvrawpay ! queue ! rtpvrawdepay ! fpsdisplaysink text-overlay=false
video-sink=fakesink sync=false

videotestsrc is-live=true !
video/x-raw,width=640,height=480,format=I420,framerate=30/1 ! queue !
vpuenc_h264 ! queue ! fpsdisplaysink text-overlay=false video-sink=fakesink
sync=false

I've run the same tests on my Ubuntu 18.04 with x264enc, and got 30Hz for
all configurations.

Could this be showing a problem rtph264pay? I'll be looking at the code in
details tomorrow.

And/or the H.264 stream produced from the i.MX8MM VPU encoder is not 'right'
and rtph264pay as a result drops some data. So far the only strange thing I
have noticed is that the coded slices that correspond to he location of the
problem have a slice_qp_delta that is a very smaller negative number (-1906
and -1842) whereas other slices have values around 0 (1, 2, ...). I'll be
looking into what this means tomorrow.

If any of this rings a bell for anyone, please drop me a line. Could save me
day or weeks of analysis / debugging. 

Anyone here doing live streaming from NXP's i.MX8MMini?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/