Re: Updated Stats proposal - May 13

On Wed, May 14, 2014 at 2:32 PM, Harald Alvestrand <harald@alvestrand.no> 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
>>>>
>>>>
>>>> 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?
>

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



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

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