GStreamer-devel

Should RTSPSRC correct for time drift when converting the RTP timestamp to gstreamer clock?

Classic

List

Threaded

3 messages Options

Loren Rogers

Should RTSPSRC correct for time drift when converting the RTP timestamp to gstreamer clock?

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?

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

Edward Hervey

Re: Should RTSPSRC correct for time drift when converting the RTP timestamp to gstreamer clock?

Administrator

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

Marco Ballesio

Re: Should RTSPSRC correct for time drift when converting the RTP timestamp to gstreamer clock?

Hi,

On Thu, Jan 27, 2011 at 10:09 AM, Edward Hervey <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>