GNOME Bugzilla – Bug 707931
rtpjitterbuffer: fails to output segment event causing possible pts/dts of output buffers to be out of segment
Last modified: 2013-09-12 13:06:26 UTC
If the incoming segment does not start at 0, say filesrc ! pcapparse is being used, then the segment will be generated by pcapparse and will start from a non-zero timestamp. rtpjitterbuffer seems to have an asssumption that the segment start is 0. To show this: gst-launch-1.0 -v filesrc location=test.pcap ! pcapparse ! application/x-rtp, payload=101, clock-rate=48000 ! rtpjitterbuffer ! fakesink silent=false Gives： Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)f170a2b77b0b4a9dd086b252ed42769cb1a2b1f44344b49371f66677a55e0854;) 0xe89c60 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)1378747322514700000, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0xe89d20 /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = application/x-rtp, payload=(int)101, clock-rate=(int)48000 /GstPipeline:pipeline0/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:src: caps = application/x-rtp, payload=(int)101, clock-rate=(int)48000 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)application/x-rtp, payload=(int)101, clock-rate=(int)48000;) 0xe89d80 /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = application/x-rtp, payload=(int)101, clock-rate=(int)48000 /GstPipeline:pipeline0/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink: caps = application/x-rtp, payload=(int)101, clock-rate=(int)48000 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = preroll ******* /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (45 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x7fd8b4006160 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (46 bytes, dts: 0:00:00.020000000, pts: 0:00:00.020000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x7fd8b4006270 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (46 bytes, dts: 0:00:00.040000000, pts: 0:00:00.040000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x7fd8b4006380 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (45 bytes, dts: 0:00:00.060000000, pts: 0:00:00.060000000, duration: none, etc. This can be worked around by putting an identity single-segment=true just before the rtpjitterbuffer, but that's just a hack. rtpjitterbuffer should send a segment event before it outputs buffers.
commit 9f9ba21404035dc37fef642e1679a6898da5cb8e Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Sep 12 15:01:36 2013 +0200 jitterbuffer: handle segments with non-0 start We keep the DTS and PTS in running-time inside the jitterbuffer. Make sure to transform it back to a buffer timestamp before pushing out the buffer. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=707931