GStreamer-devel

jerky playback with udpsrc and flutsdemux at receiver side.

Classic

List

Threaded

4 messages Options

Ambily N

jerky playback with udpsrc and flutsdemux at receiver side.

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.

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.

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

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

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.

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

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

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.

8.Other players like VLC plays it well wih the same sender.

Would someone be able to coment on the issue?
Regards

Ambily

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Wim Taymans

Re: jerky playback with udpsrc and flutsdemux at receiver side.

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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Ambily N

Re: jerky playback with udpsrc and flutsdemux at receiver side.

Hi Wim,

Thank you very much your quick response with clear explanations.

I had traced the timestamps going out from Fluendo demuxand those found to be similar in the live as well as non-live case.

So I understand the fix for live source is needed at the Fluendo TS demux part. Is this correct?

We need a container format like MPEG2 TS for H.264, since we need audio also.

So we can't use rtph264pay for this since its for H.264 VES.

Also could you please guide us on the required modifications on the demux ? Will simply copying of the udpsrc's timestamp to the outgoing buffers of demux (only if any upstream src is live) will help?

Regards

Ambiy

Ambily N

Re: jerky playback with udpsrc and flutsdemux at receiver side.

Hi,

We modified the timestamps going out from the demux. It use the same timestamps provided by udpsrc.

Now the packets are not being dropped by the sink.

Is this a correct fix?

Regards

Ambily.