[gst-devel] jerky playback with udpsrc and flutsdemux at receiver side.

[Wim Taymans]

On Sat, 2008-08-16 at 20:48 +0530, Ambily N wrote:
> Hi,
> 
> I am experiencing some issues while using rtp/udp live streaming of TS
> encapsulated H.264 stream.
> 
> The sender side pipe line is as
> 
> gst-launch filesrc location=
> gst-launch filesrc location=grandma.qcif.yuv blocksize=1 ! videoparse
> format=0 width=176 height=144 ! x264enc byte-stream=1 ! flutsmux !
> rtpmp2tpay ! udpsink host=localhost port=1234.
> 
> the receiver side the pipeline is as :
> 
> 
> gst-launch udpsrc port=1234 ! rtpmp2tdepay ! flutsdemux ! ffdec_h264 !
> queue
> ! sdlvideosink
> 
> The display is jerky and only I frames fets displayed at the sink.

flutsdemux does not take into account the timestamps set by udpsrc, it
simply assumes they start from 0. The timestamps generated by udpsrc are
based on the current clock time, which for live sources usually does not
start from 0.

All frames will therefore arrive too late in the sink. The jitter you
see is the QoS performing emergency visual updates every second.

> 
> The observations we have on the issue so far are the following.
> 
> 
> 1. The display is fine when we use tcpserversrc at the receiver and
> tcpclientsink at the sender.

tcpserversrc is not a live source and timestamps from 0.

> 
> 2.The display is fine if we modify the code of udpsrc and make it a
> non-live
> src.

This would work but then you will not be able to adapt to the rate at
which the media is sent.

> 
> 3.The display is smooth if we start the transmitter side first and
> thgen
> start the receiver.

In this case, the first captured packet will be captured immediatly,
close to 0. Clock drift between sender and receiver will slowly screw up
things after a while.

> 
> 4.The timestamps of the packets arriving at the sink are the same in
> both
> live and non-live cases but in the live case the packets seems to be
> late
> when compared with current clock time.

flutsdemux totally ignores the incomming timestamps and always generates
the same timestamps.

> 
> 5. The qos messages from the sink make the decoder skip to the next I
> frame
> and this continues all the way.

ok. 

> 
> 6.The display is fine if we disable the sync property at the
> sdlvideosink.

that would work, then you display at rate at which you receive data but
will not allow for interstream synchronisation.

> 
> 7. We tried the pipelin with rtph264pay and depay without TS
> encapsulation,which works fine. But in this case also at the sink, the
> sync
> property gets set to false due to invalid timestamp and the display is
> fine.
in this case you would need to insert a gstrtpjitterbuffer to get
smoothed timestamps that compensate for packet reordering due to h264.

> 
> 8.Other players like VLC plays it well wih the same sender.
> 
> Would someone be able to coment on the issue?
> Regards
> Ambily

There you go,
Wim
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel