Re: [webrtc-stats] RTCPeerConnection.getStats: What to do with 'selector' argument?

I typed some notes earlier while on the plane:
what is the idea behind the selector argument to getStats()?

The optional selector argument to getStats() is a MediaStreamTrack.
It might imply that the caller is only interested in information about
 that track. For audiotracks, the caller might look for information 
about audio levels at a very high rate.
Calling getStats and then iterating the resulting map to find the 
report with the track id might be considered too heavy in such cases. 
Also it would signal the intent "I only care about this track" to the 
browser which would allow it to gather/update less information.

So lets assume we had an implementation of this selector that would 
only return the matching RTCMediaStreamTrackStats.
What would the ssrcIds be set to? (assuming #85 is fixed)
Would they point to an RTCRTPStreamStats object?
If so, I assume that this object has a transportId which points to an 
RTCTransportStats.
Which points to a selected candidate pair.

In the end, the call with the selector argument will have to return 
the complete set of statistics.
So what is the point? Is this simply an artifact of a previous 
statistics model that was not updated?

I can see this being marginally useful if the callback was something 
like this:
```
pc.getStats(track)
.then((reportForTrack, snowball) => {
  // look up *Id in snowball
})
```
which would save the initial iteration to find the right starting 
point.

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

Received on Monday, 19 December 2016 21:05:30 UTC