Re: Updated Stats proposal - May 13

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
>>>
>>> https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
>>
>> 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] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#videoplaybackquality
> [2] http://tools.ietf.org/html/draft-singh-xrblock-webrtc-additional-stats-02#section-2.1.4

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

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

Received on Wednesday, 14 May 2014 11:32:54 UTC