- From: Varun Singh via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jun 2019 16:28:24 +0000
- To: public-webrtc-logs@w3.org
I am assuming that issue stems from the fact that at the output of the encoder, where the quality is measured, it is not clear what was the expectation from the bandwidth estimator nor that it was further limited by "cpu"?
In my mental model, the target quality (the input to the encoder) is set by the bandwidth estimator, and if the output comes out lower than the target (it is either due to "cpu" or something else).
To expand on the above, my interpretation of the usecase for quality limitation was:
1. target quality for the encoder is always set by bandwidth estimator, because it is component that is actively trying to modulate the video bitrate to fit the estimated capacity. Now if the bandwidth estimate is varying, and if the quality produced by the encoder is limited because of the bandwidth estimator, it is reasonable expectation to set it as "bandwidth". I can imagine at the beginning of the call, it has no estimate, the quality would default to a preset, if a bad preset is used, it would fall in to "other"?
2. output quality turns out to be lower than the target quality set by the bandwidth estimator, I would imagine this is either because of "cpu" limitation or input picture does not have enough fidelity to create high quality ("other").
--
GitHub Notification of comment by vr000m
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/440#issuecomment-506418220 using your GitHub account
Received on Thursday, 27 June 2019 16:28:25 UTC