"DTS going backward" at some conditions

[Sebastian Dröge]

On Di, 2013-12-10 at 00:56 +0200, Andrey Utkin wrote:
> When i execute the below command
> 
> GST_DEBUG=3 GST_DEBUG_DUMP_DOT_DIR=. gst-launch-1.0 rtspsrc
> location=rtsp://media.smart-streaming.com/mytest/mp4:sample_phone_150k.mp4
> name=source ! application/x-rtp, media=video ! queue ! rtph264depay  !
> mpegtsmux name=mux ! queue ! udpsink host=127.0.0.1 port=1234
> source. ! queue ! rtpmp4gdepay  ! mux.
> 
> i have such output (note the warnings at bottom)
> 
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> Progress: (open) Opening Stream
> Progress: (connect) Connecting to
> rtsp://media.smart-streaming.com/mytest/mp4:sample_phone_150k.mp4
> Progress: (open) Retrieving server options
> Progress: (open) Retrieving media info
> Progress: (request) SETUP stream 0
> Progress: (request) SETUP stream 1
> Progress: (open) Opened Stream
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Progress: (request) Sending PLAY request
> 0:00:02.247666247 16660 0x7f1f8802b9e0 FIXME                default
> gstutils.c:3625:gst_pad_create_stream_id_internal:<fakesrc0:src>
> Creating random stream-id, consider implementing a deterministic way
> of creating a stream-id
> 0:00:02.247745775 16660 0x7f1f8802ba30 FIXME                default
> gstutils.c:3625:gst_pad_create_stream_id_internal:<fakesrc1:src>
> Creating random stream-id, consider implementing a deterministic way
> of creating a stream-id
> Progress: (request) Sending PLAY request
> Progress: (request) Sent PLAY request
> 0:00:02.737265031 16660 0x7f1f8802b850 WARN         rtpjitterbuffer
> rtpjitterbuffer.c:185:rtp_jitter_buffer_set_clock_rate: Clock rate
> changed from 0 to 90000
> 0:00:02.838822152 16660      0x12249e0 WARN         rtpjitterbuffer
> rtpjitterbuffer.c:185:rtp_jitter_buffer_set_clock_rate: Clock rate
> changed from 0 to 48000
> 0:00:04.668274799 16660      0x11e54f0 FIXME               basesink
> gstbasesink.c:3022:gst_base_sink_default_event:<udpsink0> stream-start
> event without group-id. Consider implementing group-id handling in the
> upstream elements
> 0:00:14.416913998 16660      0x12340f0 WARN               mpegtsmux
> mpegtsmux.c:1046:mpegtsmux_clip_inc_running_time:<mux:sink_65>
> ignoring DTS going backward
> 0:00:27.417683308 16660      0x12340a0 WARN               mpegtsmux
> mpegtsmux.c:1046:mpegtsmux_clip_inc_running_time:<mux:sink_66>
> ignoring DTS going backward

These warnings would suggest a problem in the source stream. If you add
an identity element with silent=false and run gst-launch with -v, do you
see that the DTS is not monotonically increasing? The identity element
should be after the h264 depayloader.

The DTS in this case would be added on the buffers by the
rtpjitterbuffer element inside rtspsrc. Which could of course do
something wrong there in your case too.

> These warnings from last lines appear at random periods (and frequency
> depends on pipeline config), but not once.
> Also the strange thing is that line "buffering XX%" is there all the
> time, and constantly rolling from 0% to 100% again and again.

That would suggest that you send data faster than real-time, or at least
faster than the source stream arrives at your device. As this is
probably all just real-time, you could disable any buffering (i.e. not
handle the BUFFERING messages at all for example) and just pipe data
from RTP to the udpsink as it arrives (also sync=false on udpsink maybe
if data arrives in real-time anyway).

> But when i remove queue between muxer and udpsink, such warnings (and
> "buffering" line too) are absent. I am not sure if it means there is
> no problem in such case, or it just doesn't manifest itself.

This part doesn't make much sense TBH :) The queue there should not be
the one who emits the BUFFERING messages, which element does emit them
in your case?

Also the queue does not change timestamps or anything else, so the DTS
should be exactly the same as before. However I would recommend to also
add queues in front of the muxer sinkpads, to not block the pipeline
parts while the muxer does its job (and waits for data on the other
branch).

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131213/69cf8109/attachment-0001.pgp>