Skipped frames when displaying RTP / H.264 stream

[jean-philippe]

Hi,

Thanks for your comments about packet loss, I have adjusted my server
pipeline to only produce I-Frames with a low CBR of 5kbps.

This made no difference whatsoever.

For memory, my pipelines:

Server: v4l2src name=camera !
video/x-raw,width=1920,height=1080,format=YUY2,framerate=30/1 ! queue !
vpuenc_h264 gop-size=1 bitrate=5000 ! queue ! h264parse ! identity
name=identity ! rtph264pay name=pay0

Client: rtspsrc name=videosrc location=rtsp://172.20.1.129:8554/video3 !
application/x-rtp,media=video ! queue name=q1 ! rtph264depay !
video/x-h264,stream-format=avc ! h264parse ! identity name=identity !
fakesink sync=false

*I’m still detecting a jump in PTS of 33ms (one frame) every 4.2s which is
128 frames or just over 10MB*; very suspicious!
I’ve increased the size of the queue on the client, but to no avail. Is
there a queue in ‘rtspsrc’? If so, can I / should I change its size? For
some reason, the macro GST_DEBUG_BIN_TO_DOT_FILE() does not dump the content
of the ‘rtspsrc’ bin in the pipeline above. The pipeline in the image
generates starts at the queue. Any idea why?

I only detect those PTS jumps when h264parse is in the pipeline. Any idea
why this may be?.. this could be a clue?

At the same time, libav prints the following errors:
ERROR                  libav :0:: Frame num change from 8 to 9 
ERROR                  libav :0:: decode_slice_header error

As mentioned before, I’m not seeing PTS discrepancies on the server side.

BTW, there was a typo in my previous post, the frame drop occurs every 4.2
seconds, not milliseconds.

For memory, I’m using the ‘identity’ element to look at the PTS of each
buffer and detect a jump in PTS between consecutive buffers. I do this on
the server side just before the ‘rtppayh264’ element and on the client just
before ‘avdec_h264’.

Could the FIXME warnings issued by rtpjitterbuffer have something to do with
the problem? I’m looking at the code, but don’t’ yet understand what they
mean. Any pointers someone can give?

FIXME        rtpjitterbuffer
gstrtpjitterbuffer.c:1535:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> 
Unsupported timestamp reference clock 
FIXME        rtpjitterbuffer
gstrtpjitterbuffer.c:1543:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> 
Unsupported media clock

One of the things that puzzle me is why the H.264 stream saved to file seems
to playback perfectly when the live display loses frames? 
Is it possible the decoder interpolates the missing frame when playing back
from file? But if so, how does it know the difference between a stream read
from file and one received live? 

JP



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