search

w3c / webrtc-stats

WebRTC Statistics
https://w3c.github.io/webrtc-stats/
Other
128 stars 46 forks source link

Stat for how many adaptation changes occur for a video track #144

Closed henbos closed 6 years ago

henbos commented 7 years ago

The non-standardized Chromium getStats contains the following stat:

// The number of adaptation changes (video).
ssrc.googAdaptationChanges

Is this useful? Should this be standardized as unsigned long adaptationChanges in RTCMediaStreamTrackStats?

henbos commented 7 years ago

Is this only for adaptations that occur automatically? If the application lowers the capture resolution to lower CPU usage (perhaps as a decision based on another stat) this would not count?

henbos commented 7 years ago

This is related to #160.

vr000m commented 7 years ago

I am not sure, what is being measure here. If the purpose was to see if the congestion controller changed its setting, would it not be easier to see the bit rates or frame size changes?

henbos commented 7 years ago

@stefanholmer @icydragons Do you know of the usefulness of this counter versus noting that bit rates or frame size changes? (See above comment.) With infrequent polling of getStats you might not notice all adaption changes but do you care about precision of past history?

icydragons commented 7 years ago

It does provide some value. Since it is monotonically increasing, it is helpful in catching specific issues that happen in between polling intervals, especially to catch if there is a rapid switching between different resolutions which would be hard to detect otherwise (besides user complaints).

We use it in conjunction with an instantaneous (currently active) adaptation "reason" that is reported by chrome in multiple variables: 'googCpuLimitedResolution' 'googBandwidthLimitedResolution' 'googViewLimitedResolution'

Which help us define which limitation caused the change (we also have several that are defined in the app layer that we merge). I assume other implementations of webrtc will have reasons for adapting the video down, but they may not map identically with the ones Chrome uses. Having the overall googAdaptationChanges would also allow for detecting things that may not make it into the spec from other companies.

All told, the absolute measure is not as useful as the reason values though if I had to choose one. I see the discussion on the reasons is here: https://github.com/w3c/webrtc-stats/issues/160

alvestrand commented 7 years ago

If the adaptation reason in #160 is sampled, this counter could tell you if there have been multiple adaptations between samples. If it's just increased by one, we know we've seen all the values; if it's more than one, there have been intermediate values.

Question: If it goes from unlimited (HD) to CPU-limited(VGA) to CPU-limited(QVGA), is the number of adaptations 1 or 2?

henbos commented 6 years ago

To be continued at #256