rtpbin: ts adjustment needs filtering/smoothing

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

rtpbin: ts adjustment needs filtering/smoothing

Charlie Laub

I have been developing and measuring the performance of a streaming audio pipeline. This streams audio using rtpbin (RTP+RTCP) over a WiFi connection, and uses NTP to synchronize clocks on all machines to better than 100 microseconds. There is one sender and two clients. The clients are connected to DACs and amplifiers and are built into a pair of loudspeakers, one into the left speaker and one into the right. The goal was to get synchronized streaming of PCM audio, with synchronization always better than 1 millisecond between left and right speakers. This helps to keep the stereo image centered.

 

I have been able to achieve and better the 1msec synchrony goal, but careful listening reveals “ticks” or “pops” in the audio that happen relatively frequently and only when there is audio (never in the absence of music). I assume what is happening is that zeros are being inserted into the audio, and when they happen to coincide with a peak in the music signal the result is audible.

 

In rtpbin, I have set the following parameters:

Latency=60 (milliseconds)

max-ts-offset-adjustment=2 (nanoseconds per frame???)

ntp-sync=true

ntp-time-source=ntp

rtcp-sync-interval=60000 (microseconds, or 1 minute)

all other ntpbin parameters are left at the default value.

 

The pipeline ends at an alsasinnk. I set the properties:

drift-tolerance=500 (microseconds)

provide-clock=false

 

I have been making measurements of the synchrony of the left and right speakers using ARTA and a microphone placed in front of each speaker. Measurements are done over long periods of time (e.g. hours) at regular intervals (a few minutes each). This data looks very good, and shows the level of synchrony I have been able to achieve.

 

Unfortunately the measurements did not reveal what listening test did: pops and ticks in the audio. My guess is that this is due to the way that the pipeline audio data is being modified in response to ntp time data.

 

Initially I had set the property max-ts-offset-adjustment to values in the thousands or hundreds (of nanoseconds). Measurements that were performed at intervals of only a few seconds would reveal the playback timing jumping around quite erratically and randomly as much as 10 milliseconds. This was surprising, because at the sampling rate I am using (48kHz) there are only about 50 frames per second. Until I set the max-ts-offset-adjustment parameter to 1 or 2 nsec could I prevent the playback timing from jumping around. I cannot set this parameter any lower.

 

Visual inspection of the timing measurements showed the timing randomly advancing and retarding every few seconds. Over time the “by eye” average seemed to be about the expected average value. Perhaps there is too much jitter in the data and corrections are being wildly overdone? Even with the minimum amount of ts-adjustment per frame, the audio has regular pops.

 

I am wondering if some kind of low-pass filtering could be applied to the timing info. The effect will be a smoothing of the data, so that the necessary correction changes smoothly over time instead of wildly back and forth. A parameter that conveys the maximum allowed or expected ts-rate-of-change could be introduced. From there it is straightforward to implement low pass filtering with a corner frequency corresponding to this time period using e.g. an FIR filter or moving average with a timing data sample rate equal to the rtcp-sync-interval. Higher frequency changes will be suppressed, but their values will still contribute to the overall ts correction if they contain a longer period drift. This would be much better than the current max-ts-offset-adjustment type limiting.

 

Is it possible to implement filtering of timing info along these lines?

 

I would be happy to provide my pipelines if that would be helpful, provide measurement data, or any other info that might lead to a solution.

 

-Charlie

 


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: rtpbin: ts adjustment needs filtering/smoothing

Nicolas Dufresne-5
Le vendredi 16 octobre 2020 à 20:55 -0400, [hidden email] a
écrit :

> I have been developing and measuring the performance of a streaming
> audio pipeline. This streams audio using rtpbin (RTP+RTCP) over a
> WiFi connection, and uses NTP to synchronize clocks on all machines
> to better than 100 microseconds. There is one sender and two clients.
> The clients are connected to DACs and amplifiers and are built into a
> pair of loudspeakers, one into the left speaker and one into the
> right. The goal was to get synchronized streaming of PCM audio, with
> synchronization always better than 1 millisecond between left and
> right speakers. This helps to keep the stereo image centered.
>  
> I have been able to achieve and better the 1msec synchrony goal, but
> careful listening reveals “ticks” or “pops” in the audio that happen
> relatively frequently and only when there is audio (never in the
> absence of music). I assume what is happening is that zeros are being
> inserted into the audio, and when they happen to coincide with a peak
> in the music signal the result is audible.
>  
> In rtpbin, I have set the following parameters:
> Latency=60 (milliseconds)
> max-ts-offset-adjustment=2 (nanoseconds per frame???)
> ntp-sync=true
> ntp-time-source=ntp
> rtcp-sync-interval=60000 (microseconds, or 1 minute)
> all other ntpbin parameters are left at the default value.
>  
> The pipeline ends at an alsasinnk. I set the properties:
> drift-tolerance=500 (microseconds)
> provide-clock=false
>  
> I have been making measurements of the synchrony of the left and
> right speakers using ARTA and a microphone placed in front of each
> speaker. Measurements are done over long periods of time (e.g. hours)
> at regular intervals (a few minutes each). This data looks very good,
> and shows the level of synchrony I have been able to achieve.
>  
> Unfortunately the measurements did not reveal what listening test
> did: pops and ticks in the audio. My guess is that this is due to the
> way that the pipeline audio data is being modified in response to ntp
> time data.
>  
> Initially I had set the property max-ts-offset-adjustment to values
> in the thousands or hundreds (of nanoseconds). Measurements that were
> performed at intervals of only a few seconds would reveal the
> playback timing jumping around quite erratically and randomly as much
> as 10 milliseconds. This was surprising, because at the sampling rate
> I am using (48kHz) there are only about 50 frames per second. Until I
> set the max-ts-offset-adjustment parameter to 1 or 2 nsec could I
> prevent the playback timing from jumping around. I cannot set this
> parameter any lower.
>  
> Visual inspection of the timing measurements showed the timing
> randomly advancing and retarding every few seconds. Over time the “by
> eye” average seemed to be about the expected average value. Perhaps
> there is too much jitter in the data and corrections are being wildly
> overdone? Even with the minimum amount of ts-adjustment per frame,
> the audio has regular pops.
>  
> I am wondering if some kind of low-pass filtering could be applied to
> the timing info. The effect will be a smoothing of the data, so that
> the necessary correction changes smoothly over time instead of wildly
> back and forth. A parameter that conveys the maximum allowed or
> expected ts-rate-of-change could be introduced. From there it is
> straightforward to implement low pass filtering with a corner
> frequency corresponding to this time period using e.g. an FIR filter
> or moving average with a timing data sample rate equal to the rtcp-
> sync-interval. Higher frequency changes will be suppressed, but their
> values will still contribute to the overall ts correction if they
> contain a longer period drift. This would be much better than the
> current max-ts-offset-adjustment type limiting.
>  
> Is it possible to implement filtering of timing info along these
> lines?

Perhaps you didn't notice the default slave-method, which is skew. Skew
will remove or fill with silence the audio stream to fix the
synchronization between the audio card clock and the NTP clock. As it
does that naively, you will ear ticks and pop. You'll also notice
the resample method, which in theory should work, but in practice the
resampler there is buggy and the adjustment too aggressive. Some work
is needed there to make it work.

Well known companies using GStreamer have introduced the "custom"
slave-method. Along with
gst_audio_base_sink_set_custom_slaving_callback(), you get notified per
units of the drift. These vendor controlls the HW, so instead of
resampling, they will adjust the audio clock PLL in order to lock the
audio to the system/ntp/ptp/etc. clock in use.

>  
> I would be happy to provide my pipelines if that would be helpful,
> provide measurement data, or any other info that might lead to a
> solution.
>  
> -Charlie
>  
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: rtpbin: ts adjustment needs filtering/smoothing

Charlie Laub
>Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization >between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in >theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

As you say "buggy" is an understatement - it is TERRIBLE. It's essentially unlistenable because the "over aggressive" action introduces a warble to the music, like you are listening underwater.  

So, the only solution that comes to mind is custom slaving, which is not available to the general public? Hmmmm.

Perhaps in place of the buggy ALSA resampler, you could implement asynchronous resampling? This was brought up in a post a couple of days ago in this list under the subject "Adaptive resampling in gstaudiobasesink.c". I think it would be very worthwhile and would really improve the audio performance of Gstreamer in general.

Could you or someone follow up on that topic?

-Charlie

-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of Nicolas Dufresne
Sent: Saturday, October 17, 2020 10:50 AM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

Well known companies using GStreamer have introduced the "custom"
slave-method. Along with
gst_audio_base_sink_set_custom_slaving_callback(), you get notified per units of the drift. These vendor controlls the HW, so instead of resampling, they will adjust the audio clock PLL in order to lock the audio to the system/ntp/ptp/etc. clock in use.

>  
> I would be happy to provide my pipelines if that would be helpful,
> provide measurement data, or any other info that might lead to a
> solution.
>  
> -Charlie
>  
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: rtpbin: ts adjustment needs filtering/smoothing

Nicolas Dufresne-5


Le sam. 17 oct. 2020 13 h 00, <[hidden email]> a écrit :
>Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization >between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in >theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

As you say "buggy" is an understatement - it is TERRIBLE. It's essentially unlistenable because the "over aggressive" action introduces a warble to the music, like you are listening underwater. 

So, the only solution that comes to mind is custom slaving, which is not available to the general public? Hmmmm.

Would be nice to tone down a little. The code is open source, the hard work of plumbing this is in place, but no one felt like contributing a fix for this (resampling is expensive, so mostly for desktop, were audio deamon already do a much better job). And we are aware it never worked.

As for the custom slaving mode, it's publicly available, but you need audio HW with a controllable PLL, and the rounding + smoothing in such case will always be HW specific.


Perhaps in place of the buggy ALSA resampler, you could implement asynchronous resampling? This was

This is pure C, there is no ALSA there. It is about 50 line of code. We have another resampler now, but no one looked it up to see if it can be used more dynamicly then how it is used in audioresample element.

brought up in a post a couple of days ago in this list under the subject "Adaptive resampling in gstaudiobasesink.c". I think it would be very worthwhile and would really improve the audio performance of Gstreamer in general.

Could you or someone follow up on that topic?

I'm sorry, I don't remember this thread. Do you have links ? Perhaps a merge request would get more attention.


-Charlie

-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of Nicolas Dufresne
Sent: Saturday, October 17, 2020 10:50 AM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

Well known companies using GStreamer have introduced the "custom"
slave-method. Along with
gst_audio_base_sink_set_custom_slaving_callback(), you get notified per units of the drift. These vendor controlls the HW, so instead of resampling, they will adjust the audio clock PLL in order to lock the audio to the system/ntp/ptp/etc. clock in use.

> I would be happy to provide my pipelines if that would be helpful,
> provide measurement data, or any other info that might lead to a
> solution.

> -Charlie

> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: rtpbin: ts adjustment needs filtering/smoothing

Charlie Laub

Nicolas,

 

Sorry for my tone, if that offended. I Thought your response was a little snarky and maybe that get me riled up. I am a bit frustrated after spending 4 weeks working on improving the synchronization only to start listening to the audio and hearing the ticks/pops. But let’s move on.

 

Can you point me to the “50 lines of code” you mention – I believe you are referring to the resampler code? Is that in GstAudioSink? I would like to look at it.

 

Also, the post/thread that I mentioned was sent to me via email from the gstreamer-devel list on freedesktop.org. The author is Pavel Hofman and the title is “Adaptive resampling in gstaudiobasesink.c”. It was posted last WED, 10/14. I will pop this up again by posting a reply to the message. Pavel is interested in working on the adaptive resampling, so if there is a better way for him to bring up the topic and how to write a patch please let him/me know. Thanks

 

-Charlie

 

 

From: gstreamer-devel <[hidden email]> On Behalf Of Nicolas Dufresne
Sent: Saturday, October 17, 2020 1:13 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

 

 

Le sam. 17 oct. 2020 13 h 00, <[hidden email]> a écrit :

>Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization >between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in >theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

As you say "buggy" is an understatement - it is TERRIBLE. It's essentially unlistenable because the "over aggressive" action introduces a warble to the music, like you are listening underwater. 

So, the only solution that comes to mind is custom slaving, which is not available to the general public? Hmmmm.

 

Would be nice to tone down a little. The code is open source, the hard work of plumbing this is in place, but no one felt like contributing a fix for this (resampling is expensive, so mostly for desktop, were audio deamon already do a much better job). And we are aware it never worked.

 

As for the custom slaving mode, it's publicly available, but you need audio HW with a controllable PLL, and the rounding + smoothing in such case will always be HW specific.

 


Perhaps in place of the buggy ALSA resampler, you could implement asynchronous resampling? This was

 

This is pure C, there is no ALSA there. It is about 50 line of code. We have another resampler now, but no one looked it up to see if it can be used more dynamicly then how it is used in audioresample element.

 

brought up in a post a couple of days ago in this list under the subject "Adaptive resampling in gstaudiobasesink.c". I think it would be very worthwhile and would really improve the audio performance of Gstreamer in general.

Could you or someone follow up on that topic?

 

I'm sorry, I don't remember this thread. Do you have links ? Perhaps a merge request would get more attention.

 


-Charlie

-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of Nicolas Dufresne
Sent: Saturday, October 17, 2020 10:50 AM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

Perhaps you didn't notice the default slave-method, which is skew. Skew will remove or fill with silence the audio stream to fix the synchronization between the audio card clock and the NTP clock. As it does that naively, you will ear ticks and pop. You'll also notice the resample method, which in theory should work, but in practice the resampler there is buggy and the adjustment too aggressive. Some work is needed there to make it work.

Well known companies using GStreamer have introduced the "custom"
slave-method. Along with
gst_audio_base_sink_set_custom_slaving_callback(), you get notified per units of the drift. These vendor controlls the HW, so instead of resampling, they will adjust the audio clock PLL in order to lock the audio to the system/ntp/ptp/etc. clock in use.



> I would be happy to provide my pipelines if that would be helpful,
> provide measurement data, or any other info that might lead to a
> solution.

> -Charlie

> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: rtpbin: ts adjustment needs filtering/smoothing

Sebastian Dröge-3
In reply to this post by Nicolas Dufresne-5
On Sat, 2020-10-17 at 13:13 -0400, Nicolas Dufresne wrote:
>
> This is pure C, there is no ALSA there. It is about 50 line of code.
> We have another resampler now, but no one looked it up to see if it
> can be used more dynamicly then how it is used in audioresample
> element.

I actually looked at that a while ago and came to the conclusion that
the resampler is fine and could be used for this, but the way how
GstAudioBaseSink and GstAudioRingBuffer work does not really fit with
how a resampler would behave. This needs some redesigning of how these
work together.

Apart from the current resampler in there being bad (it's just linear
interpolation), this is also a big reason why it doesn't work at all
currently.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: rtpbin: ts adjustment needs filtering/smoothing

Charlie Laub
I think I have raised a "false flag" about the source of the audio problems I am experiencing.

I am not convinced the problem lies with resampling in the alsasink/GstAudioSink because when I set the alsasink property slave-method=none the ticks and pops continue. The only other place in the pipeline (from what I understand!) where timing is being adjusted is in the rtpjitterbuffer. I probably should have made that more clear in my original post.

I am using rtpbin, which is a wrapper for several elements including rtpjitterbuffer. Initially I used the default value of max-ts-offset-adjustment, which is "0" but I think means "no limit". Then I measured the playback timing difference between two clients and it was moving around by several (occasionally more than 10) milliseconds every few seconds! This is very audible. Next I tried to limit the ts adjustments using max-ts-offset-adjustment, but I found I had to set it all the way down to 1 or 2 to minimize the changes made to ts. Thy timing difference was much more stable but still moved around sightly in my measurements. I think this may be why I hear ticks and pops in the audio playback.

At that point I thought that perhaps smoothing out the RTCP sender report clock/timing info might be one way to address this problem, if that is even what is going on. Since the "by eye average" playback timing seems about right, smoothing out the short term jitter seems to make sense.  

-Charlie


-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of Sebastian Dröge
Sent: Saturday, October 17, 2020 4:49 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

On Sat, 2020-10-17 at 13:13 -0400, Nicolas Dufresne wrote:
>
> This is pure C, there is no ALSA there. It is about 50 line of code.
> We have another resampler now, but no one looked it up to see if it
> can be used more dynamicly then how it is used in audioresample
> element.

I actually looked at that a while ago and came to the conclusion that the resampler is fine and could be used for this, but the way how GstAudioBaseSink and GstAudioRingBuffer work does not really fit with how a resampler would behave. This needs some redesigning of how these work together.

Apart from the current resampler in there being bad (it's just linear interpolation), this is also a big reason why it doesn't work at all currently.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: rtpbin: ts adjustment needs filtering/smoothing

Charlie Laub
Can someone point me to which source file contains the code for the jitterbuffer used by rtpbin. I'd like to take a look at how the ts adjustment is done, exactly.

Thanks

-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of [hidden email]
Sent: Sunday, October 18, 2020 11:30 AM
To: 'Discussion of the development of and with GStreamer' <[hidden email]>
Subject: RE: rtpbin: ts adjustment needs filtering/smoothing

I think I have raised a "false flag" about the source of the audio problems I am experiencing.

I am not convinced the problem lies with resampling in the alsasink/GstAudioSink because when I set the alsasink property slave-method=none the ticks and pops continue. The only other place in the pipeline (from what I understand!) where timing is being adjusted is in the rtpjitterbuffer. I probably should have made that more clear in my original post.

I am using rtpbin, which is a wrapper for several elements including rtpjitterbuffer. Initially I used the default value of max-ts-offset-adjustment, which is "0" but I think means "no limit". Then I measured the playback timing difference between two clients and it was moving around by several (occasionally more than 10) milliseconds every few seconds! This is very audible. Next I tried to limit the ts adjustments using max-ts-offset-adjustment, but I found I had to set it all the way down to 1 or 2 to minimize the changes made to ts. Thy timing difference was much more stable but still moved around sightly in my measurements. I think this may be why I hear ticks and pops in the audio playback.

At that point I thought that perhaps smoothing out the RTCP sender report clock/timing info might be one way to address this problem, if that is even what is going on. Since the "by eye average" playback timing seems about right, smoothing out the short term jitter seems to make sense.  

-Charlie


-----Original Message-----
From: gstreamer-devel <[hidden email]> On Behalf Of Sebastian Dröge
Sent: Saturday, October 17, 2020 4:49 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: Re: rtpbin: ts adjustment needs filtering/smoothing

On Sat, 2020-10-17 at 13:13 -0400, Nicolas Dufresne wrote:
>
> This is pure C, there is no ALSA there. It is about 50 line of code.
> We have another resampler now, but no one looked it up to see if it
> can be used more dynamicly then how it is used in audioresample
> element.

I actually looked at that a while ago and came to the conclusion that the resampler is fine and could be used for this, but the way how GstAudioBaseSink and GstAudioRingBuffer work does not really fit with how a resampler would behave. This needs some redesigning of how these work together.

Apart from the current resampler in there being bad (it's just linear interpolation), this is also a big reason why it doesn't work at all currently.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: rtpbin: ts adjustment needs filtering/smoothing

Tim Müller
Hi,

> Can someone point me to which source file contains the code for the
> jitterbuffer used by rtpbin. I'd like to take a look at how the ts
> adjustment is done, exactly.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/tree/master/gst/rtpmanager

Cheers
 Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel