W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Updated Stats proposal - May 13

From: Varun Singh <vsingh.ietf@gmail.com>
Date: Thu, 15 May 2014 12:17:29 +0300
Message-ID: <CAEbPqrx=os-p9qBxmAAmUDDwkYdiLGHfBNJrJSnZ-8FSAvpd9A@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi Harald, Jan-Ivar,

On Thu, May 15, 2014 at 11:29 AM, Harald Alvestrand
<harald@alvestrand.no> wrote:
> On 05/15/2014 05:57 AM, Jan-Ivar Bruaroey wrote:
>

[snip]
>
> 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.
>

Yes jitter buffer delay is pesky, but the instantaneous snapshot value would
not be sufficient, the monitoring application would additionally need the
nominal jitterBufferDelay to interpret the instantaneous value (and both
might vary with time). Lastly, not to conflate the variables max/min could be
maintained by the JS.

The definitions for the dejitter buffer are in
http://tools.ietf.org/html/rfc7005.


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

In our JS we already handle chrome and firefox stats separately, we were hoping
that as the specs stabilize there would be convergence and higher
confidence on the
availability of particular keys in the stats API.

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

if the video/, audio/ will always be prepended, then I am fine with having this
in just one place. But we've seen "vp8" and "opus" before, which is harder if
in the future we may have "foo" and no idea what "foo" is? "video/foo" is much
better. At least in our case, we would be able to log the data and later try to
interpret it.

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

Depends if this is going to be:
1) codec:"vp8" and codecType:"video", or
2) codec:"video/vp8" and codecType:"video" ?

I would prefer 1.

Thanks,
Varun

-- 
http://www.netlab.tkk.fi/~varun/
Received on Thursday, 15 May 2014 09:18:18 UTC

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