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

[webrtc-stats] We need "sender" and "receiver" stats, not "track" stats

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Tue, 11 Jul 2017 01:48:02 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-241900628-1499737679-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-stats:

== We need "sender" and "receiver" stats, not "track" stats ==
[RTCMediaStreamTrackStats](https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamtrackstats) sets up a nice symmetry between local fields:
```js
    unsigned long       framesCaptured;
    unsigned long       framesSent;
```
and remote fields:
```js
    unsigned long       framesReceived;
    unsigned long       framesDecoded;
    unsigned long       framesDropped;
    unsigned long       framesCorrupted;
    unsigned long       partialFramesLost;
    unsigned long       fullFramesLost;
```
Would you expect to be able to compare `framesSent` and `framesReceived`?

Unfortunately, this was designed before transceivers, senders and replaceTrack, so there's an impedance mismatch: In the new model, remote tracks are tied to *senders*, not local tracks.

E.g. take the ["Hold" example](http://w3c.github.io/webrtc-pc/#hold-functionality) in the spec:
 1. I put you on hold using `audio.sender.replaceTrack(null)`,
 2. and then I bring you back from hold with `audio.sender.replaceTrack(micTrack)`

Would you still expect to be able to compare `framesSent` and `framesReceived`?

We can't because the *local* stats have now been reset from the time of the second `replaceTrack`, whereas the remote stats are *never reset*. The counters are out of sync.

There's also stats bloat (on the local side only), in that you'll see one additional `detached` RTCMediaStreamTrackStats record for each time `replaceTrack(micTrack)` was called. In theory, the sum of all the `framesSent` with the same track `id` should be comparable to `framesReceived`, but that's quite a bit of work, asymmetrical and unintuitive.

Instead, we think people care more about transmission data in relation to the *sender*, not the track.

### Proposal

After splitting up the dictionary in https://github.com/w3c/webrtc-stats/issues/230, replace the `"track"` [RTCStatsType](https://w3c.github.io/webrtc-stats/#dom-rtcstatstype) with `"sender"` and `"receiver"` and have those refer to the local and remote half of this dictionary respectively. e.g.

s/LocalVideoStreamTrackStats/VideoSenderStats/
s/RemoteVideoStreamTrackStats/VideoReceiverStats/
s/LocalAudioStreamTrackStats/AudioSenderStats/
s/RemoteAudioStreamTrackStats/AudioReceiverStats/


Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/231 using your GitHub account
Received on Tuesday, 11 July 2017 01:48:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC