Re: Updated Stats proposal - May 13

On 05/15/2014 11:17 AM, Varun Singh wrote:
> 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.
>

If getStats is called every 10 seconds or so, max/min values maintained 
by JS would be different from max/min values maintained by the browser. 
So having browser-managed max/min has value.

I note that the RFC 7005 definitions refer to "this reporting interval", 
implying that max/min gets reset every time a report is produced. This 
is somewhat problematic in a stats situation, since we've otherwise 
stuck with the idea that calling getStats doesn't change the value of 
any observed variable.

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

The codec record is new as of this proposal, so there is no existing 
conformant code...
>
>> 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" ?

If I were pulling this up, I'd add it to the SSRC data, so that one can 
interpret SSRC statistics without referring to the codec record:

ssrc.mediaType: "video"

with a note saying that this MUST be consistent with the media type of 
the corresponding "codec" entry.


>
> I would prefer 1.
>
> Thanks,
> Varun
>

Received on Thursday, 15 May 2014 09:31:40 UTC