Quality Scaler is WEBRTC in accordance with the video quality, adaptive adjustment resolution of the scheme, the idea is generally: to observe the video encoding loss frame rate and QP changes, determine whether the capturer in the adaptor to adjust the encoding resolution. Its code is located at:
$ (ROOT)/src/webrtc/modules/video_coding/utility
The implementation is fairly simple,
Observe the average QP and drop frame rate encoded in 5 seconds,
If the Farme drop rate > 60% is considered poor quality, the resolution is lowered. This condition is generally not satisfied, if it is openh264 encoder, even if the Enable frame drop, drop rate is also <=50%, if it is iOS video toolbox, it will not drop frames, Android Mediacod EC behavior is similar to iOS and does not drop frames.
If the video type is H264, the average QP is less than or equal to 24, it will call Reportqplow, ask Capturer to raise the resolution, the average QP is greater than or equal to 37, call Reportqphigh, require capturer down resolution.
In actual use, the change of QP is directly related to the target code rate, the content complexity of the coding, and when the target code rate changes little, because the content of the code is different, it will cause the apparent qp to fluctuate greatly. The common idea is that the video resolution corresponds to the target bitrate, but there is no definite relationship between the two. In actual use, when the target rate is constant, there is a camera to the moving target, the resolution is reduced, to the static target, the resolution rises. There is also a target bitrate adjusted to nearly 2M, and the video resolution can only be maintained at 360p (640x360). WebRTC a lot of design is admirable, but for this design, although can not be said unreasonable, but some strange. I think there should be a better way.
The code version discussed in this article is branch 58.