- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Feb 2017 12:52:16 +0000
- To: public-webrtc-logs@w3.org
@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