Re: Updated Stats proposal - May 13

On 05/15/2014 05:57 AM, Jan-Ivar Bruaroey wrote:
> 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!

Thanks!
>
> Minor nit:
> - boolean isRemote default false;
> + boolean isRemote = false;
Fixed!
> 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
> };
We discussed a bit about delay internally too - there's half a dozen 
goog* related delay variables - but decided not to propose anything, 
because these seem to be quite implementation dependent, and not really 
thought through - we'd like to look at the delay of the whole pipeline 
and have a monitoring application figuring out exactly where the time 
went, and our current variables don't really accomplish that.

Jitter buffer delay is also one of those pesky "varies with time" 
variables where it's not clear to me if we want instantaneous snapshots, 
time-smoothed values or max/min (or all three).
By the time I got that far, my head hurt, so I didn't propose anything.

> 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.
>

I used double because we have sub-millisecond RTT in some significant 
cases - the RTCP sender report timestamp is an NTP timestamp, which has 
rather fine resolution (1/2^32 seconds, or 0.2 nanoseconds), and the RTT 
to my nearest router is around half a millisecond this week.

While it's probably a pipe dream to get sub-ms RTT 
application-to-application at the moment, I like double better.

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

avSyncDelay seems like a MediaStreamTrack matter. Jitter buffers can be 
either place for single-SSRC-per-channel, but they may be better placed 
with the track once one does SVC or simulcast, since one would normally 
correct for jitter after merging the parts one intends to look at. But YMMV.

>
>> - 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)?

Living document = the WHATWG approach of keeping a draft around forever, 
adding features to it as time goes along, and never publishing a 
versioned snapshot. I see good and bad things about that approach - one 
bad thing is that it's hard to refer to a specific version for 
statements like "an implementation SHOULD/MUST support all the variables 
defined at X".
>
>>     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.

"Key" may be better. Code-wise, it's a global search/replace (or rather 
search/add/mark-for-deletion, since we can't just jank out the old names 
from under the running apps).
Other people's thoughts?

>
> 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?

stats-of-ssrc.codecId gives you the codec record, which has the "codec" 
field, which is "video/vp8" or similar.

I didn't want to introduce redundant information here without needing 
to, but might do it for convenience - what do people think? Should we 
represent the top level type "video" twice?

>
>> Enjoy!
>>
>>       Harald
>
> Thanks!
>
> .: Jan-Ivar :.
>