Re: Updated Stats proposal - May 13

On Wed, May 14, 2014 at 2:32 PM, Harald Alvestrand <> wrote:
> On 05/13/2014 11:47 PM, Varun Singh wrote:
>> [Snip]
>>>> Similarly, it would be nice to know if frames got discarded by the
>>>> decoder.
>>>> I suppose one can get these from
>>> We won't get there - the Media Source Extension isn't involved in WebRTC
>>> at
>>> all.
>>> But the word "discard" doesn't occur in the MSE spec - what were you
>>> thinking of?
>> droppedVideoFrames is part of videoPlaybackQuality [1], it is also
>> referenced in
>> FramesDiscardedCount in XRBLOCK Metrics [2].
>> [1]
>> [2]
> I added framesDropped and framesCorrupted to MediaStreamTrackStats, with
> reference to media-source. The XR block definitions seem to focus only on
> frames impacted by packet drops; that would fit with a SSRC-level stats
> variable. Do we need both?

There is a minor subtlety, the framesDropped means that it was an AVSync issue,
while the framesDiscarded at the SSRC-level means its the jitter
buffer that dropped
it before feeding to the decoder which may result in an increment in
the framesCorrupted
counter in the MediaStreamTrackStats.

>>>>>>> - Added "target bitrate" for an SSRC
>>>>>> Clarification, target bitrate is calculated by the congestion control,
>>>>>> and not necessarily the amount sent or produced by the SSRC.
>>>>> Have to clarify this further - I meant this to indicate the target
>>>>> bitrate
>>>>> that the codec has been set to produce. This may be lower than the
>>>>> available
>>>>> bitrate, for application or implementation specific reasons, but it
>>>>> should
>>>>> never be higher, I think.
>>>> Wouldn't the target bitrate vary with time, depending on the variation
>>>> in the available bitrate? And the available bitrate is something
>>>> measured
>>>> by the congestion control algorithm?
>>>> I guess what I want to know was how to interpret the value in the
>>>> target bitrate. i.e., I assumed that this would potentially mean the
>>>> bitrate
>>>> the codec was configured to meet (it may or may not) and the value may
>>>> vary with time.
>>> Hmm. I generally don't like "rate" variables, because they try to
>>> represent
>>> something in a point in time that varies over time, but with "target
>>> bitrate" I make an exception.
>>> Yes, target bitrate will vary over time, as the browser implementation
>>> responds to congestion signals, priority signals and other signals. The
>>> purpose of reporting "target bitrate" would not be to know how many bits
>>> travel - it's to verify that the priorities, constraints and congestion
>>> signals the browser sees have resulted in an allocation of targets that
>>> is
>>> more or less what you expected.
>>> Thus, "what the encoder was configured to meet" is exactly what we want
>>> here.
>> Okay, that clarifies the definition.
>> Another clarification: is the targetBitrate related to
>> RTCInboundRTPStreamStats?
>> all the other metrics are calculated by the endpoint based on the
>> received RTP packets,
>> but this is reported by the sender to the receiver.
>> If this is to be used for verifying the allocation of priorities,
>> shouldn't the targetBitrate
>> be reported on the RTCOutboundRTPStreamStats so that sender can check
>> if the priorities are
>> right and change them (though I am not sure if this possible via the
>> constraints API)?
> You're right. I added it to the wrong construct.
> Moved, and added more explanation about it.
> The situation I envision is that the JS would detect that the video is being
> sent in lousy quality, and put up a note in the UI saying "Your outgoing
> connection has bandwidth issues, video is being sent with low quality.
> Others may not see you clearly". Or something on that order. Not sure it
> makes UI sense, but it seems a thing app developers will want to detect - at
> least for their logs.

Yes, for me it was important to understand the definition so that we
can incorporate
it correctly in callstats.js, which pretty much does what you described above.

>> minor nit:
>> unsigned long packets Lost;
>> should be:
>> unsigned long packetsLost;
> Fixed, thanks!


Received on Thursday, 15 May 2014 08:49:35 UTC