Re: [webrtc-stats] insertedSamplesForDeceleration and removedSamplesForAcceleration of inbound stats confusing (#809)

Thanks @alvestrand @fippo . I'm not seeing a lot of certainty, and it is concerning that there is no way to infer this information from the spec. 

That article is awesome and explains a lot. My interpretation of this statistic is the same as ^^^. The jitter buffer attempts to keep the playout rate constant given a varying packet arrival delay, packet loss, errored packets and so on. It does varying things to tune the buffer buffer size, and the packetization length to allow this. 

One of the tricks it does is attempt to match the current playout delay to a target delay (see [the better way](https://webrtchacks.com/how-webrtcs-neteq-jitter-buffer-provides-smooth-audio/#post-4560-_mv3ivinthkf5)). If the current delay is too early or too late it may slow down or speed up the playout of sample. The inference is that this is done by inserting samples or removing them from the buffer, but might be done in some other way (?)

The original statement you made @alvestrand still seems true-ish "The purpose of these counters is basically to figure out the number of cases where the jitter buffer is too small.". 
Would it be more true to say:

> The purpose is of these statistics is to determine how well the current playout delay is tracking the target delay, and hence how often audio has to be slowed down or sped up in order to maintain the desired playout delay."?



-- 
GitHub Notification of comment by hamishwillee
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/809#issuecomment-3130188568 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 29 July 2025 00:21:35 UTC