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.040000000xvimagesink.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
logs.txt
Locked
