Re: Updated Stats proposal - May 13

On 05/13/2014 04:02 PM, Varun Singh wrote:
> On Tue, May 13, 2014 at 3:58 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> On 05/13/2014 02:39 PM, Varun Singh wrote:
>>> On Tue, May 13, 2014 at 2:56 PM, Harald Alvestrand <harald@alvestrand.no>
>>> wrote:
>>>> Changes include:
>>>>
>>>> - Added counters for FIR, PLI, NACK and SLI
>>> The reference to FIR should be changed to RFC5104
>>> http://tools.ietf.org/html/rfc5104#section-4.3.1
>>> Was there some discussion around including RPSI (Reference Picture
>>> Selection Indication) for implementations that support it?
>>
>> Right - it seems that these two share an acronym, but not a codepoint....
>>
>> It seems that the FIR in RFC 5104 is defined by PT=PSFB (206) and FMT=4,
>> which makes the 2 first bytes 0x84CE. while the one in 2032 is defined by
>> PT=RTCP_FIR, which makes the 2 first bytes 0x80C0.
>>
> yes the one in RFC5104.
>
>> I assume that it's the RFC 5104 FIRs we want to count, and the RFC 2032 FIRs
>> should be ignored.
>>
>> WRT RPSI - no discussion, do you think it's needed?
>>
> If the encoder-decoder synchronization is broken, it would help any algorithm
> trying to estimate QoE from the network parameters. But this depends on any
> implementation sending RPSI.

As defined in RFC 4585 section 6.3.3, it's a message with content 
defined per codec - I don't care much one way or another. Does anyone 
have an implementation using RPSI that they want supported in WebRTC?

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


>
>>>> - Added a "packets lost" counter
>>> In IETF 89 (Vancouver) and IETF 90 (London) XRBLOCK discussed
>>> additional statistics for WebRTC [1,2].
>>> Of these burst discard and burst loss were particularly found
>>> interesting, note that those documents are not WG documents and not
>>> all metrics documented there have WG consensus. But discussion about
>>> them in XRBLOCK would be really useful.
>>>
>>>> - 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.

(deleting some stuff with no further comments needed)

Received on Tuesday, 13 May 2014 14:33:03 UTC