Re: Comments on the stats api on the webRTC wiki...

On 10/18/2013 11:54 PM, Göran Eriksson AP wrote:
> Hi Harald,
>
> Great to see the updated proposal for stats parameters uploaded on the W3C WebRTC Wiki, http://www.w3.org/2011/04/webrtc/wiki/Stats- this makes it much easier to discuss it before it ends up in the spec. It would be nice to see some other outstanding stuff there as well in time for TPAC.
>
> Now, a few comments and questions (not a complete list, :-)):
>
> 1. Have You considered stats for RTCDataChannel?

Considered, yes; written something, no.
>
> 2. RTCRTPStreamStats
> It is not obvious to me what "transportId" is about, especially since nothing like a "transport object" is in the API.

The transport has to exist as a conceptual object, but it's not exposed 
by the rest of the API at the moment. It's the ID of the RTCTransport 
stats object.

I'm not sure about the name, but what I was thinking of was (in ICE 
terms) the "connection" that one negotiates candidate pairs for; RTP 
tends to call it a "session", pre-BUNDLE SDP tended to call it an 
M-line. I need to check the terminology draft again to see what the best 
name is this week.

>
> 3. RTCInboundRTPStreamStats
> Perhaps a comment about meaning of "jitter" and how it is measured/calculated (unless obvious from context in spec) would be helpful?

Needs to reference the corresponding line in RFC 3550.
>
> 4. RTCMediaStreamTracks
> I note that frames received and decoded are included. In Media Source Extentions, there are possibilities to get stats on the video element about frames dropped, corrupted, displayed, etc (https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#htmlvideoelement-extensions)- I believe it would be good if we try to align with that API, at least when it comes to parameters.'

Thanks for the pointer - I think alignment wold be most valuable.
>
> 5. RTCTransport
> I was looking for information for which DSCP class that was used for a track and thought it may be in this dictionary. Such information could become useful in debugging an application I expect.

As soon as we've locked down what DSCP code points vary over, we should 
expose it as a stat.
At the moment, I think it's an attribute of either a MediaStreamTrack or 
an SSRC - the former if all simulcast/layers/repair flows etc have the 
same DSCP; the latter if it can vary across the layers.
,
>
> Many Regards
> Göran
>
>

Received on Saturday, 19 October 2013 02:37:30 UTC