commit c401923f3ee3b4ec5423a3ede7e91550e2acd52d
author Yun Zhang <yunz@fb.com> Fri Oct 02 18:23:03 2020
committer Commit Bot <commit-bot@chromium.org> Mon Oct 05 11:11:51 2020
tree 0aea60c7449feb032e164835709121784d95aaf4
parent ab302568c717bb6a0a2053397958fd9530233373

Take max bitrate into account for target bitrate decision when min bitrate is empty

Currently, when only max bitrate available and min bitratea & target
bitrate are missing from encoding config, the target bitrate is decided
by the calculation from GetSimulcastConfig() according to width/height/qp.
The max bitrate doesn't play a role here other than ensure target < max.
This will make the target bitrate cap at some calculated number even
when control message gives much larger allocation through max bitrate.

In our cases, the L0 (at 180p) is capped at 80-90kbps even control
message gives L0's max bitrate over 300kbps. This under-use of bandwidth
happens to all layer other than top layer. Top layer will be compensated
with all the left bandwidth up to max at last.

Since in web api, we cannot pass down either min bitrate or target bitrate
(https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpEncodingParameters).
We propose a new logic to take max bitrate into consideration in this case,
use 3/4 max bitrate or calculated target bitrate whichever is larger.

Bug: None
Change-Id: I2234b4636daa379fd47d4bbe764cf8307b9a1ea4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186161
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32308}