Timestamp issues faced while playback of H264 ove RTP

[amoln]

Hi all,

I want to playback H264 elementary stream received over RTP. The pipeline
used is as below:

gst-launch-0.10 gstrtpbin latency=1000 name=rtpbin udpsrc
caps='application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,profile-level-id=(string)\"\"'
uri=udp://239.255.255.10:25000 ! rtpbin.recv_rtp_sink_0 rtpbin. !
rtph264depay ! ffdec_h264 ! xvimagesink 

the playback freezes after specific time interval with the following warning
message:
*WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A
lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2595): gst_base_sink_is_too_late ():
/GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.
*

I tried to debug the issue if it is with the timing parameters that are
generated by the RTP client, however it seems that the timing parameters are
proper and are passed to the downstream elements appropriately. The
following log indicates the timing parameters for each element. The buffer
0x9e66088 is dropped in the following logs.. 
 
gstbasertpdepayload.c:520 Pushing buffer size 2036, timestamp
0:00:03.122934363
gstffmpegdec.c:2490 Received new data of size 2036,
offset:18446744073709551615, ts:0:00:03.122934363, dur:99:99:99.999999999
gstffmpegdec.c:2546 consuming 4791 bytes. ts:0:00:03.122556585
Index 125 yielded ts: 0:00:02.080905547, duration: 99:99:99.999999999,
offset: -1
*gstffmpegdec.c:2225 Decoded data, now pushing buffer 0x9e66088 with offset
-1, timestamp 0:00:02.080905547 and duration 0:00:00.040000000*
xvimagesink.c:2349 In gst_xvimagesink_get_times *start = 0:00:02.080905547
and *end = 0:00:02.120905547
gstbasesink.c:3343 got times start: 0:00:02.080905547, end:
0:00:02.120905547
xvimagesink.c:2349 In gst_xvimagesink_get_times *start = 0:00:02.080905547
and *end = 0:00:02.120905547
gstbasesink.c:1931 latency = 0:00:01.000000000... ts_offset =
0:00:00.000000000
possibly waiting for clock to reach 0:00:02.080905547, adjusted
0:00:03.080905547 due to render delay 0:00:00.000000000
gstbasesink.c:1991 time 0:00:03.080905547, base_time 24:39:47.207851657
gstbasesink.c:2009  jitter = 0:00:00.282059111
*buffer is too late 0:00:02.362964658 > 0:00:02.140905547
**emergency** last buffer 0x9e66088 at 0:00:01.060510596 > GST_SECOND (SIZE
152064) Last_in_time = 0:00:01.060510596
*gstbasesink.c:2605 Setting last_in_time to 0:00:02.080905547
gstffmpegdec.c:2546 consuming 0 bytes. ts:0:00:03.122934363
discont 0, seqnum 44244, rtptime 91614864, timestamp 0:00:03.122934363
discont 0, seqnum 44245, rtptime 91614864, timestamp 0:00:03.122934363
*WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A
lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2595): gst_base_sink_is_too_late ():
/GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.
*discont 0, seqnum 44246, rtptime 91614864, timestamp 0:00:03.122934363


The playback works fine when sync is disabled (i.e. sync=false is used for
xvimagesink)

To debug further I would like to know what can be the cause of this issue. 
1) Is the gst_clock_id_wait taking too much time on the machine where
gstreamer is running (However I doubt this since I have played an HD H264
stream with MP4 container of bitrate without any issues). 
2) Is the data/timestamps that are being generated by the RTP element
improper. (Which from the logs doesn't seem to be so)
3) Is the decoder not able to decode data appropriately.

I have attached logs for the complete sessions ( I apologize since the logs
are dumped using printf rather than gst-debug options).


Kindly let me know how I would proceed in debugging this issue.

Thanks,
Amol  http://gstreamer-devel.966125.n4.nabble.com/file/n4350901/logs.txt
logs.txt 

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Timestamp-issues-faced-while-playback-of-H264-ove-RTP-tp4350901p4350901.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.