W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

[webrtc-stats] Missing definition of "deleted". When exactly do stats get deleted?

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Jan 2018 23:33:25 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-289452103-1516232003-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-stats:

== Missing definition of "deleted". When exactly do stats get deleted? ==
One problem we ran into looking at `getCompletedStats` - which [using events](https://github.com/w3c/webrtc-stats/issues/235#issuecomment-358316276) might skirt, but nonetheless seems problematic - is the lack of timing guarantees or a definition of completed/deleted.

For instance - even using @alvestrand's [shim](https://github.com/w3c/webrtc-stats/issues/235#issuecomment-358316276) - would the following be guaranteed to work?
```js
let id = sender.track.id;
await sender.replaceTrack(null);
console.log([...pc.getCompletedStats().values()].find(s => s.trackIdentifier == id); // ?
```
Right now there's no guarantee around *when* stats objects end/complete/delete/finalize. Defining it might be hard as well. For instance, @vr000m has mentioned the importance of including every last byte sent wrt a removed track.

Luckily `replaceTrack` is already spec'ed to not resolve until the media switch has been made, but it doesn't talk about that, in order for the stats to be synchronously available in `replaceTrack`'s success callback, we would actually need to gather those stats as part of the replaceTrack algorithm.

This stuff is sort of only implied in the spec so far.

Alternatively, we could offer no such guarantees, and simply say these things happen eventually.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/300 using your GitHub account
Received on Wednesday, 17 January 2018 23:33:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 January 2018 23:33:43 UTC