W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2019

Re: [webrtc-stats] Clarify qualityLimitationReason when limited by multiple reasons (#440)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Fri, 14 Jun 2019 13:46:17 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-502115391-1560519976-sysbot+gh@w3.org>
If you are limited in either case, that makes you less limited in the other case, these cannot be measured independently because any limitation changes the resource load of both resources (CPU and bandwidth). It really is not clear whether an implementation should say "cpu" or "bandwidth" in a given scenario that is some amount of limited in both. I think the order of detection ("first CPU was detected, then bandwidth was detected") adds complexity and assumptions without necessarily increasing interop or testability.

What Chrome does is that if both limitations have been detected (in any order) is it always says "bandwidth" (see discussion [here](https://webrtc-review.googlesource.com/c/src/+/138825/1/video/send_statistics_proxy.cc#1076)). I propose the spec should reflect the only implementation that has been shipped for this metric, as does @alvestrand:

> We discussed "cpu-and-bandwidth" when we added the stat, but a) it leads to combinatorial explosion if we add more limitation reasons, and b) if you reduce quality because of bandwidth limitations, CPU usage is also likely to drop, but you can't tell that the dropped CPU usage is because of the bandwidth limitation or because you'd also like to do CPU throttling. So I think prioritizing bandwidth is right, and the spec should say so.

GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/440#issuecomment-502115391 using your GitHub account
Received on Friday, 14 June 2019 13:46:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 14 June 2019 13:46:20 UTC