[webrtc-stats] Add counter for number of times resolution changes (#476)

henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== Add counter for number of times resolution changes ==
The spec allows us to see if and why we are resolution limited ([qualityLimitationReason](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-qualitylimitationreason)) as well as how long we have been limited ([qualityLimitationDurations](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-qualitylimitationdurations)). We can also poll for resolution ([frameWidth/frameHeight](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-framewidth)) which gives us a good idea about quality.

However, every time the resolution changes because of being quality limited that will have a noticeable effect to quality for the user. It will also have an impact on the bandwidth usage because it necessarily creates additional key frames. [keyFramesEncoded](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-keyframesencoded) does not tell us why it went up, and estimating resolution changes requires polling getStats a lot. There could be an easier way to measure this.

I propose adding RTCOutboundRtpStreamStats.qualityLimitationResolutionChanges:
> Number of times that the resolution has changed because of we are quality limited (qualityLimitationReason is not "none"). The counter is initially zero, and increases when the resolution goes up or down. For example, a 720p track being sent as 640x480 for some time and then recovers to 720p, qualityLimitationResolutionChanges will have the value 2.

Note that this is a separate discussion than when we discussed number of times the quality limitation reason changed. We are not counting flip-flopping going between "cpu" and "bandwidth" for example; we could be "bandwidth" limited for 100% of the call and the resolution could still vary during the call. This counter is about resolution changes, not reason changes, and complements qualityLimitationDurations nicely without adding additional polling logic to the application.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/476 using your GitHub account

Received on Tuesday, 27 August 2019 12:39:40 UTC