Re: Updated Stats proposal - May 13

[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

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

minor nit:
unsigned long packets Lost;
should be:
unsigned long packetsLost;



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

Received on Tuesday, 13 May 2014 21:48:44 UTC