W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2017

Re: [webrtc-stats] Stat for how many audio stream packets are expanded when packets are lost (and lost and the user is speaking)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Tue, 14 Feb 2017 14:12:59 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-279717209-1487081578-sysbot+gh@w3.org>
+@hlundin
If I understand correctly, Chromium has `googExpandRate` which is the 
fraction of audio filled to conceal packet-loss and 
`googSpeachExpandRate` which is the same but only applicable when 
there is something audible to play. Meaning if we stop receiving any 
packets `googExpandRate` might be 100% whereas `googSpeachExpandRate` 
is not applicable (0%) after we have no audio.

How about?

> **RTCInboundRTPStreamStats._packetsExpanded_**
> The number of packets that have been inserted to conceal 
packet-loss.
> 
> **RTCInboundRTPStreamStats._packetsAudibleExpanded_**
> The number of packets that have been inserted to conceal packet-loss
 while there is something audible to play. If our buffers are emptied 
_packetsExpanded_ will keep increasing, but not 
_packetsAudibleExpanded_.

Rates can be calculated from `packets[Audible]Expanded / 
(packetsReceived + packetsLost)` (see other packets members that 
already [exist in 
spec](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcinboundrtpstreamstats)).
 This is assuming `packetsLost` keeps increasing for muted streams, 
@vr000m do you know?

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at 
https://github.com/w3c/webrtc-stats/issues/152#issuecomment-279717209 
using your GitHub account
Received on Tuesday, 14 February 2017 14:13:08 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC