Re: [webrtc-stats] Stat for audio acceleration rate?

@alvestrand WRT "we shouldn't need a sample counter to divide by, 
since that's derivable from time + sample rate", what sample rate? 
There are 
[constraints](https://www.w3.org/TR/mediacapture-streams/#media-track-capabilities)
 but no stat for that. Packets != samples. And actual sample rate 
might vary and not be current rate * time.

WRT samplesInsertedByRateAdaption being both positive or negative I 
don't think it flies to have a single counter, samples can both be 
removed (googAccelerateRate) or added (googPreemptiveExpandRate) over 
a period of time but the sum could be zero.

Adding @hlundin. How about?
> **RTCMediaStreamTrackStats._samplesInserted_
> RTCMediaStreamTrackStats._samplesRemoved_**
> The number of samples that have been inserted/removed in order to 
slow down/speed up audio as the jitter buffer increases/decreases.
> 
> **RTCMediaStreamTrackStats._sampleCount_**
> The number of samples that have been added to the jitter buffer. 
This count includes both samples that have been inserted 
(_samplesInserted_) and samples that have been removed 
(_samplesRemoved_).

Or is "rate adaption" preferred over "jitter buffer"?

So `googAccelerateRate ~= samplesRemoved / sampleCount` and 
`googPreemptiveExpandRate ~= samplesInserted / sampleCount` if samples
 were to be counted over the same time period as the goog-rates.

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

Received on Tuesday, 14 February 2017 12:52:22 UTC