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

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}
Committed: https://chromium.googlesource.com/external/webrtc/+/916170ae4692b505e1ef3e2b3562af8322420b7d

[sprang_webrtc, 2017-05-22 13:50:27]

The CQ bit was checked by sprang@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-22 13:50:32]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-05-22 14:01:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-22 14:01:01]

Dry run: Try jobs failed on following builders:
  linux_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_rel/builds/26227)

[sprang_webrtc, 2017-05-23 11:37:33]

Description was changed from

==========
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.

BUG=webrtc:7694
==========

to

==========
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
==========

[sprang_webrtc, 2017-05-23 11:37:41]

The CQ bit was checked by sprang@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-23 11:37:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[sprang_webrtc, 2017-05-23 11:38:24]

sprang@webrtc.org changed reviewers:
+ ilnik@webrtc.org

[ilnik, 2017-05-23 12:05:54]

lgtm with nits.

https://codereview.webrtc.org/2897983002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/codecs/vp8/screenshare_layers.cc (right):

https://codereview.webrtc.org/2897983002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/codecs/vp8/screenshare_layers.cc:385: // mean target
bitrate can be exceeded.
nit: Update the comment, it doesn't match.

[sprang_webrtc, 2017-05-23 12:35:41]

https://codereview.webrtc.org/2897983002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/codecs/vp8/screenshare_layers.cc (right):

https://codereview.webrtc.org/2897983002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/codecs/vp8/screenshare_layers.cc:385: // mean target
bitrate can be exceeded.
On 2017/05/23 12:05:54, ilnik wrote:
> nit: Update the comment, it doesn't match.

Done.

[sprang_webrtc, 2017-05-23 12:35:45]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-05-23 12:35:46]

The patchset sent to the CQ was uploaded after l-g-t-m from ilnik@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2897983002/#ps40001 (title:
"Updated comment")

[commit-bot: I haz the power, 2017-05-23 12:35:53]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-05-23 14:47:55]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1495542945777210,
"parent_rev": "7855fff5bf045e7975fca78bce6d85d0add61c0f", "commit_rev":
"916170ae4692b505e1ef3e2b3562af8322420b7d"}

[commit-bot: I haz the power, 2017-05-23 14:47:59]

Description was changed from

==========
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
==========

to

==========
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}
Committed:
https://chromium.googlesource.com/external/webrtc/+/916170ae4692b505e1ef3e2b3...
==========

[commit-bot: I haz the power, 2017-05-23 14:48:00]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/external/webrtc/+/916170ae4692b505e1ef3e2b3...