Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid bitrate

Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d (https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.

The cl now also make sure SendPacer starts with the configured bitrate provided in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current code that runs the proper at 300kbit regardless of configured start bitrate.

Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the BitrateController. If the queue is full, the controller reports a bitrate of zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....

Committed: https://crrev.com/ec81bcd5198cc09e4332ddeee195a1c992b6a780
Cr-Commit-Position: refs/heads/master@{#12688}

[perkj_webrtc, 2016-05-09 13:33:53]

Description was changed from

==========
Revert "Revert "Reland of Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d.

BUG=
==========

to

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=609816, webrtc:5687
==========

[perkj_webrtc, 2016-05-09 13:33:54]

perkj@webrtc.org changed reviewers:
+ stefan@webrtc.org

[perkj_webrtc, 2016-05-10 11:15:02]

Patchset #2 (id:20001) has been deleted

[perkj_webrtc, 2016-05-10 11:16:33]

Patchset #2 (id:40001) has been deleted

[perkj_webrtc, 2016-05-10 11:21:31]

Description was changed from

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=609816, webrtc:5687
==========

to

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.
It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.
With this cl the prober will run at the rate configured. 


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=609816, webrtc:5687
==========

[perkj_webrtc, 2016-05-10 11:21:43]

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

[commit-bot: I haz the power, 2016-05-10 11:21:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1958113003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1958113003/60001

[perkj_webrtc, 2016-05-10 11:22:18]

Please?

[commit-bot: I haz the power, 2016-05-10 11:28:18]

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

[commit-bot: I haz the power, 2016-05-10 11:28:18]

Dry run: Try jobs failed on following builders:
  mac_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/14973)
  win_x64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_x64_rel/builds/14562)

[pbos-webrtc, 2016-05-10 12:45:59]

Description was changed from

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.
It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.
With this cl the prober will run at the rate configured. 


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=609816, webrtc:5687
==========

to

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.
It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.
With this cl the prober will run at the rate configured. 


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
==========

[stefan-webrtc, 2016-05-10 15:07:35]

Do you think it would be possible to verify that the prober runs at the proper
rate or that the BWE is initialized correctly in a test, for instance in
video_send_stream_tests.cc  or end_to_end_tests.cc?

Btw, some tests are failing on the bots.

[perkj_webrtc, 2016-05-11 08:48:35]

PTAL
Fixed CongestionController unittest and also added test expectations that the
bitrate has been set on the Pacer.

[stefan-webrtc, 2016-05-11 09:34:01]

On 2016/05/11 08:48:35, perkj_webrtc wrote:
> PTAL
> Fixed CongestionController unittest and also added test expectations that the
> bitrate has been set on the Pacer.

I think we should change the description since this now is far from a pure
reland. :)

[stefan-webrtc, 2016-05-11 09:37:07]

With description updated: lgtm

[perkj_webrtc, 2016-05-11 10:44:28]

Description was changed from

==========
Reland of "Remove SendPacer from ViEEncoder"

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.
It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.
With this cl the prober will run at the rate configured. 


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
==========

to

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
==========

[perkj_webrtc, 2016-05-11 10:44:43]

The CQ bit was checked by perkj@webrtc.org

[commit-bot: I haz the power, 2016-05-11 10:44:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1958113003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1958113003/80001

[commit-bot: I haz the power, 2016-05-11 10:45:44]

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

[commit-bot: I haz the power, 2016-05-11 10:45:46]

Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[perkj_webrtc, 2016-05-11 10:47:32]

Description was changed from

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
==========

to

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
==========

[perkj_webrtc, 2016-05-11 10:47:32]

perkj@webrtc.org changed reviewers:
+ mflodman@webrtc.org

[perkj_webrtc, 2016-05-11 10:47:44]

The CQ bit was checked by perkj@webrtc.org

[commit-bot: I haz the power, 2016-05-11 10:47:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1958113003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1958113003/80001

[commit-bot: I haz the power, 2016-05-11 10:51:24]

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

[commit-bot: I haz the power, 2016-05-11 10:51:25]

Try jobs failed on following builders:
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)

[perkj_webrtc, 2016-05-11 12:58:51]

Description was changed from

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
==========

to

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....
==========

[perkj_webrtc, 2016-05-11 12:59:08]

The CQ bit was checked by perkj@webrtc.org

[commit-bot: I haz the power, 2016-05-11 12:59:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1958113003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1958113003/80001

[commit-bot: I haz the power, 2016-05-11 13:01:18]

Description was changed from

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....
==========

to

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....
==========

[commit-bot: I haz the power, 2016-05-11 13:01:19]

Committed patchset #3 (id:80001)

[commit-bot: I haz the power, 2016-05-11 13:01:23]

Description was changed from

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.


The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.


Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....
==========

to

==========
Remove SendPacer from ViEEncoder and make sure SendPacer starts at a valid
bitrate

This reverts commit e30c27205148b34ba421184efe65f6a0780b436d
(https://codereview.webrtc.org/1958053002/)

Original reverted cl is in patch set #1.
Changes in following patch sets.

The cl now also make sure SendPacer starts with the configured bitrate provided
in a call to CongestionController::SetBweBitrates)()

It turns out that the failing tests in 609816 is due to a bug in the current
code that runs the proper at 300kbit regardless of configured start bitrate.

Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the
BitrateController. If the queue is full, the controller reports a bitrate of
zero to  Call (and BitrateAllocator)

BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True  // Due to bug  in android_x86 cq builder....

Committed: https://crrev.com/ec81bcd5198cc09e4332ddeee195a1c992b6a780
Cr-Commit-Position: refs/heads/master@{#12688}
==========

[commit-bot: I haz the power, 2016-05-11 13:01:24]

Patchset 3 (id:??) landed as
https://crrev.com/ec81bcd5198cc09e4332ddeee195a1c992b6a780
Cr-Commit-Position: refs/heads/master@{#12688}