Re: Updated Stats proposal - May 13

Hi Harald,

Apologies for the late response, a couple of comments inline.

On Thu, May 15, 2014 at 12:31 PM, Harald Alvestrand
<harald@alvestrand.no> wrote:
> 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.
>

Ok, I see the point, but this assumes that measurement reported by the browser
is sampled over a different interval, which may be true for the
dejitter buffer size metric.

> 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

Not necessarily, the reported value is the current value at the time
generating the report.
The dejitter metric is a sampled value, which is calculated when each
packet arrives.

The definition of a sampled metric is in RFC6792,
https://tools.ietf.org/html/rfc6792:
copy pasting the relevant part below:

 Sampled metrics

      Metrics measured at a particular time instant and sampled from the
      values of a continuously measured or calculated metric within a
      reporting interval (generally, the value of some measurement as
      taken at the end of the reporting interval).  An example is the
      inter-arrival jitter reported in RTCP SR and RR packets, which is
      continually updated as each RTP data packet arrives but is only
      reported based on a snapshot of the value that is sampled at the
      instant the reporting interval ends.

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

Thanks for the clarification.

>>
>>> 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 like this idea. +1


-- 
http://www.netlab.tkk.fi/~varun/

Received on Monday, 19 May 2014 15:28:07 UTC