[gst-devel] Should RTSPSRC correct for time drift when converting the RTP timestamp to gstreamer clock?

[Marco Ballesio]

Hi,

On Thu, Jan 27, 2011 at 10:09 AM, Edward Hervey <bilboed at gmail.com> wrote:
> On Wed, 2011-01-26 at 13:25 -0500, Loren Rogers wrote:
>> Hey gang,
>> I have a gstreamer program that records audio from an RTP audio
>> source.  I then timestamp the audio frame on the recorder based on the
>> gstreamer clock (RTSPSRC should have already done the RTP TS
>> ->gstreamer clock TS conversion).  I am finding that the time drifts
>> (i.e. the most recent gstreamer-clock-based timestamp on this audio
>> frame might be increasingly early or late relative to timestamp the
>> current recorder thinks it should be) when timestamping the frames end
>> to end.  I am wondering if this drift may be linked to the clock drift
>> between the audio device and my recording device.  Should the RTSPSRC
>> element already be correcting for such time drift when converting the
>> RTP timestamp to the gstreamer clock?
>
>  The drift should normally be taken into account (i.e. detecting that
> the remote clock is faster or slower than the local gstreamer clock
> being used) and compensated in rtspsrc (actually in the jitterbuffer
> contained within that element).

On top of this, a better synchronisation between sender and receiver
clock can be granted using the RTCP NTP feature. You'll need to enable
it from the server and set the "ntp-sync" on the gstrtpbin used as
session in rtspsrc.

Regards

>  What you might be experiencing though is jitter which is somewhat
> compensated but not completely.
>
>  A small test to do to see if it's indeed jitter you're getting to
> replace your encoding part with " ! queue ! autoaudiosink". If it plays
> back fine (no noise/pops) then it means you're experiencing jitter
> (which the audiosinks automatically correct up to 40ms difference).
>
>  If it's jitter indeed, you need to insert a audiorate with a specified
> tolerance value before your encoder. Try with values ranging from 10ms
> to 40ms until it records chunks of 10seconds without glitches. That's
> because encoders expect a perfect incoming audio stream (without any
> jitter/gaps/overlaps).
>
>    Edward
>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>