commit 916170ae4692b505e1ef3e2b3562af8322420b7d
author sprang <sprang@webrtc.org> Tue May 23 14:47:55 2017
committer Commit bot <commit-bot@chromium.org> Tue May 23 14:47:55 2017
tree 50cf5076b6b0f82a422e8c37fcfe2c2ecd59b76d
parent 7855fff5bf045e7975fca78bce6d85d0add61c0f

Don't boost QP after drop unless there is sufficient bandwidth

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}