If a frame is dropped and re-encoded because it exceeded the target
bitrate by a large factor, the next frame will be encoded at max qp
(worst quality) in order to get a frame through in a timely manner. The
next frame after this will still have lower quality since the rate
controller essentially gets reset. In order to mitigate that we boost
the qp for that next frame, which brings the stream back to a good
quality quicker.
However, if the network conditions are _really_ bad, this boosted qp
may be too large, causing the frame again to be dropped an re-encoded.
This CL set's a minimum bitrate available in order to enabling the
boosting in the first place.
It also adjusts a timeout (max time between frames in TL0), since a
too small value and very difficult frames in conjunction with the
mentioned bad network could actually cause bad network over-utilization
in turn leading to packet loss and bad follow-on effects to that.
There was also some slop in the rate keeping for the two layers.
This has been tightened up and affected test cases have been fixed.
BUG=webrtc:7694
Review-Url: https://codereview.webrtc.org/2897983002
Cr-Commit-Position: refs/heads/master@{#18236}
916170ae46