Send audio packets immediately instead of pacing them.

Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high priority) packets immediatelly even if the pacer is paused and even if the available media budget has been used. The existing code will not send audio if the pacing budget has been used. It will normally send audio when the pacer is paused, but if the media budget was already used up when the pacer was paused, it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155
Committed: https://crrev.com/8b70faf262e9892ac089b5b794ac8393944a0528
Cr-Commit-Position: refs/heads/master@{#13592}

[terelius, 2016-07-29 14:57:51]

Description was changed from

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when is receives a zero bitrate estimate.

BUG=webrtc:6155
==========

to

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155
==========

[terelius, 2016-07-29 14:58:30]

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

[stefan-webrtc, 2016-07-29 15:05:13]

lgtm, but fix the nits.

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
File webrtc/modules/pacing/paced_sender.cc (right):

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
webrtc/modules/pacing/paced_sender.cc:288: LOG(LS_ERROR) << "PacedSender is not
designed to handle 0 bitrate.";
Change to an RTC_DCHECK instead?

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
webrtc/modules/pacing/paced_sender.cc:447: probe_cluster_id ==
PacketInfo::kNotAProbe)
{}

[terelius, 2016-07-30 18:14:15]

please take another look

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
File webrtc/modules/pacing/paced_sender.cc (right):

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
webrtc/modules/pacing/paced_sender.cc:288: LOG(LS_ERROR) << "PacedSender is not
designed to handle 0 bitrate.";
On 2016/07/29 15:05:13, stefan-webrtc (holmer) wrote:
> Change to an RTC_DCHECK instead?

I would like to see if this ever happens in production.

https://codereview.webrtc.org/2193183003/diff/20001/webrtc/modules/pacing/pac...
webrtc/modules/pacing/paced_sender.cc:447: probe_cluster_id ==
PacketInfo::kNotAProbe)
On 2016/07/29 15:05:13, stefan-webrtc (holmer) wrote:
> {}

Done.

[terelius, 2016-08-01 14:25:02]

The CQ bit was checked by terelius@webrtc.org

[terelius, 2016-08-01 14:25:02]

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

[commit-bot: I haz the power, 2016-08-01 14:25:10]

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, 2016-08-01 16:47:34]

Description was changed from

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155
==========

to

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155
==========

[commit-bot: I haz the power, 2016-08-01 16:47:35]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-08-01 16:47:44]

Description was changed from

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155
==========

to

==========
Send audio packets immediately instead of pacing them.

The intended behavior of the pacer is that it should send audio (i.e high
priority) packets immediatelly even if the pacer is paused and even if the
available media budget has been used. The existing code will not send audio if
the pacing budget has been used. It will normally send audio when the pacer is
paused, but if the media budget was already used up when the pacer was paused,
it would neither send audio nor update the budget.

Updated the implementatation and the unit test. Added logging for when the pacer
is paused, and when it receives a zero bitrate estimate.

BUG=webrtc:6155

Committed: https://crrev.com/8b70faf262e9892ac089b5b794ac8393944a0528
Cr-Commit-Position: refs/heads/master@{#13592}
==========

[commit-bot: I haz the power, 2016-08-01 16:47:45]

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