Stats for adaptation reason, for realsies

[henbos]

Merging all of these issues into one: #144, #160.

Alternatives:

• sequence (enum) - "CPU", "Bandwidth", "other".
• Pick the one that's obvious - "None", "CPU", "Bandwidth", "other"

googStats are a bunch of booleans that can be turned into a bitmask, and googAdaptationChanges counters.

[henbos]

In goog:
googBandwidthLimitedResolution
googCpuLimitedResolution

At some point there was:
googViewLimitedResolution

[vr000m]

However, there are a couple of questions:

• does this change each time the congestion control estimate is changed? or
• is every time the frame-size and frame-rate is changed?

For bitrate there can be a number of reasons:

• delay-mode
• loss-mode
• capped by max-bitrate
• or there was no content to send (black screen, no motion)?

For frame-size vs frame-rate changes, there could be several reasons as well:

• degradation-preference,
• CPU, or
• bandwidth.

To me these two are orthogonal.

[henbos]

Proposal:

unsigned long adaptationChanges;
Number of times target bitrate or resolution changed as a result of adaptation changing (it can change from CPU to CPU or from something to none, any time the setting is different).

sequence(string) adaptationReason;
The current things limiting bitrate or resolution, such as "CPU" or "bandwidth"

[henbos]

Problem: the target bitrate changes all the time.

[henbos]

What we want to solve: Why are we not seeing the optimal resolution?

[henbos]

Bitrate is always changing, and you're always bitrate limited.
I propose we only count adaptation when resolution or framerate is limited. For output framerate and encoded frame size is lower than input.

That is, as long as you get the expected resolution and framerate you're NOT bandwidth limited, even though bandwidth can affect the quality of the frames.

How about?

• enum currentQualityAdaptationReason: "cpu", "bandwidth", "other", "none"
• bandwidthLimitedDuration
• cpuLimitedDuration
• totalLimitedDuration
• adaptationCounter: Number of times currentAdaptationReason changes to/from "none".

[alvestrand]

With "record" being suggested in another bug, what about:
enum qualityLimitationReason = {cpu, bandwidth, other}
enum qualityLimitationMethod = {none, framerate, resolution, quality} // quality = qp value manipulation

... outgoing RTP stream ...
qualityLimitationReason limitationReason; // current most important reason
qualityLimitationMethod limitationMethod; // current most significant method
record<DOMString, double> limitationDurations; // key qualityLimitationReason, value seconds
long limitationChangeCounter; // changes every time reason or method changes

We could also attach to "track", but in the case of simulcast, things could be different for each RTP stream depending on, among other things, priority.

[henbos]

Assuming you're not sending lossless vIdeo, it's always going to adjust quality based on whatever bitrate it has available (constantly changing). In that sense it is always "bandwidth limited". Despite quality being important, in terms of "is there adaptation going on", the QP would be meaningless unless you define thresholds, but this might be opening a can of worms.

We thought that if there is need for adaptation, and it's only changing QP but not resolution and/or framerate there would be a bug in the WebRTC implementation. As such, we only need to care about resolution and/or framerate. If you have crappy quality, you probably also have crappy resolution/framerate.

[henbos]

Another important difference between QP and resolution/framerate, I would think, is that resolution/framerate is something you set with constraints/settings, and the other is the end result of other things.

[henbos]

I made an initial PR, excluding change counters for now. Is a change counter only valuable for flip flopping between limited and not limited? I'm hesitant towards increasing the counter up if it changes between "bandwidth" and "cpu" (or "other") in case it walks the line or going back and forth, imagining it is a little limited by both. How fast the counter increases would depend on how aggressive the implementation is. Hopefully, a counter that only goes up when it goes from no limitation to limitation is more stable and useful.