Re: Updated Stats proposal - May 13

On 5/13/14 7:56 AM, Harald Alvestrand wrote:
> I have updated the Stats proposal to include a few more stats that the 
> Chrome team has found necessary and/or useful to their work.
>
> The proposal is at https://www.w3.org/2011/04/webrtc/wiki/Stats

Looks great!

Minor nit:

- boolean isRemote default false;
+ boolean isRemote = false;

Here are a couple of mozilla team additions for consideration:

dictionary RTCInboundRTPStreamStats : RTCRTPStreamStats {
     ...
     long avSyncDelay; // audio lag in ms (negative = video lag in ms)
     unsigned long jitterBufferDelay; // in ms
     unsigned long roundTripTime;     // in ms
};

Notes:

  * We have round-trip time in milliseconds (unsigned long) and inside
    RTCInboundRTPStreamStats, which is what RTCP on the outbound side is
    stored as. I think that makes sense since we compute RTT when
    ReceiverReports return to sender.

  * Seeing the live stuff you added to RTCMediaStreamTrackStats, I'm
    unsure we put avSyncDelay and jitterBufferDelay in the right place.


> - Do we need an IANA registry for later stats, or should we go with 
> "living document" approaches?

I don't know what "living document" approaches are, but they sound 
preferable to an IANA registry (perhaps we can use them for constraints 
as well)?

>     DOMString trackIdentifier;  // track.id property
> ...
>     DOMString streamIdentifier; // stream.id property

A little confusing still. I wonder if we should use 'fooKey' (as in 
"key-value pair" and "foreign-key" in DB-speak) instead of 'fooId' to 
cross-reference stats objects, to free up 'Id' for trackId and streamId 
here.

Lastly, a question: What's the proper way to determine whether a stat is 
audio or video? Should we add one? Or is sniffing for presence of 
certain keys reliable? Which ones?

> Enjoy!
>
>       Harald

Thanks!

.: Jan-Ivar :.