Update RateStatistics to handle too-little-data case.

Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

BUG=
R=mflodman@webrtc.org, stefan@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/51e60305e622f9156d37cb1f487bd4260d5ce410

[sprang_webrtc, 2016-06-01 15:38:15]

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

[stefan-webrtc, 2016-06-02 07:16:42]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics.cc
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics.c...
webrtc/base/rate_statistics.cc:85: // New oldest time is older than the current
one, not need to cull data.
no need to cull data

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics_u...
File webrtc/base/rate_statistics_unittest.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics_u...
webrtc/base/rate_statistics_unittest.cc:214: // Add another, now we have tice
the bitrate.
twice

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File webrtc/modules/remote_bitrate_estimator/include/bwe_defines.h (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/include/bwe_defines.h:43:
rtc::Optional<uint32_t> incoming_bitrate;
Seems like a nice improvement!

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc:251:
last_valid_incoming_bitrate_ = *incoming_bitrate;
If we make last_valid_incoming_bitrate_ an optional too we can always assign
this, I think?

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.h
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.h:127:
uint32_t last_valid_incoming_bitrate_;
Possibly change this to:
Optional<uint32_t> last_incoming_bitrate_;
instead?

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_unittest_helper.cc
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_unittest_helper.cc:364:
// Process after we have enough frames to get a valid input rate estimate.
Maybe comment on that this can be removed once the single stream estimator is
removed. Abs send time doesn't do anything in Process()

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
I'm not convinced this is correct. What if there are no samples? Shouldn't the
reported framerate be zero in that case?

[sprang_webrtc, 2016-06-02 08:09:32]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics.cc
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics.c...
webrtc/base/rate_statistics.cc:85: // New oldest time is older than the current
one, not need to cull data.
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> no need to cull data

Done.

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics_u...
File webrtc/base/rate_statistics_unittest.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/base/rate_statistics_u...
webrtc/base/rate_statistics_unittest.cc:214: // Add another, now we have tice
the bitrate.
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> twice

Done.

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File webrtc/modules/remote_bitrate_estimator/include/bwe_defines.h (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/include/bwe_defines.h:43:
rtc::Optional<uint32_t> incoming_bitrate;
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> Seems like a nice improvement!

Thanks! I think there are bunch of hidden places where optionals make sense..

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc:251:
last_valid_incoming_bitrate_ = *incoming_bitrate;
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> If we make last_valid_incoming_bitrate_ an optional too we can always assign
> this, I think?

See previous comment about bool incoming_bitrate_initialized_

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.h
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.h:127:
uint32_t last_valid_incoming_bitrate_;
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> Possibly change this to:
> Optional<uint32_t> last_incoming_bitrate_;
> instead?

Actually, the way intended to use this (save it to use with .value_or()) didn't
really pan out, so it's just used as a boolean flag now. I'll change it to bool
incoming_bitrate_initialized_ instead.

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_unittest_helper.cc
(right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_unittest_helper.cc:364:
// Process after we have enough frames to get a valid input rate estimate.
On 2016/06/02 07:16:41, stefan-webrtc (holmer) wrote:
> Maybe comment on that this can be removed once the single stream estimator is
> removed. Abs send time doesn't do anything in Process()

Done.

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> I'm not convinced this is correct. What if there are no samples? Shouldn't the
> reported framerate be zero in that case?

Yeah, you're right. I'll change it to default zero.
Same below.

[stefan-webrtc, 2016-06-02 08:14:39]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
On 2016/06/02 08:09:32, språng wrote:
> On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > I'm not convinced this is correct. What if there are no samples? Shouldn't
the
> > reported framerate be zero in that case?
> 
> Yeah, you're right. I'll change it to default zero.
> Same below.

So, will we now ever be able to measure 1 fps? :)

[sprang, 2016-06-02 09:00:50]

sprang@google.com changed reviewers:
+ sprang@google.com

[sprang, 2016-06-02 09:00:51]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
On 2016/06/02 08:14:39, stefan-webrtc (holmer) wrote:
> On 2016/06/02 08:09:32, språng wrote:
> > On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > > I'm not convinced this is correct. What if there are no samples? Shouldn't
> the
> > > reported framerate be zero in that case?
> > 
> > Yeah, you're right. I'll change it to default zero.
> > Same below.
> 
> So, will we now ever be able to measure 1 fps? :)

Not if the actual rate is <= 1 fps. But slightly more and we'll round down to 1
:)
Do you think we should extend the window size for this, to say 2s? I'm
hesitant...

[stefan-webrtc, 2016-06-02 09:05:51]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
On 2016/06/02 09:00:51, sprang wrote:
> On 2016/06/02 08:14:39, stefan-webrtc (holmer) wrote:
> > On 2016/06/02 08:09:32, språng wrote:
> > > On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > > > I'm not convinced this is correct. What if there are no samples?
Shouldn't
> > the
> > > > reported framerate be zero in that case?
> > > 
> > > Yeah, you're right. I'll change it to default zero.
> > > Same below.
> > 
> > So, will we now ever be able to measure 1 fps? :)
> 
> Not if the actual rate is <= 1 fps. But slightly more and we'll round down to
1
> :)
> Do you think we should extend the window size for this, to say 2s? I'm
> hesitant...

Not sure. I'm mostly thinking whether it would make sense to report 1 fps if we
have 1 sample within the 1 second window in the frame rate case? Maybe it
doesn't? Seems like the way this is now implemented means that we will report 0
fps if the framerate is exactly 1 fps, which seems wrong?

[sprang_webrtc, 2016-06-02 09:32:57]

On 2016/06/02 09:05:51, stefan-webrtc (holmer) wrote:
>
https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
> File webrtc/video/receive_statistics_proxy.cc (right):
> 
>
https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
> webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
> decode_fps_estimator_.Rate(now).value_or(1);
> On 2016/06/02 09:00:51, sprang wrote:
> > On 2016/06/02 08:14:39, stefan-webrtc (holmer) wrote:
> > > On 2016/06/02 08:09:32, språng wrote:
> > > > On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > > > > I'm not convinced this is correct. What if there are no samples?
> Shouldn't
> > > the
> > > > > reported framerate be zero in that case?
> > > > 
> > > > Yeah, you're right. I'll change it to default zero.
> > > > Same below.
> > > 
> > > So, will we now ever be able to measure 1 fps? :)
> > 
> > Not if the actual rate is <= 1 fps. But slightly more and we'll round down
to
> 1
> > :)
> > Do you think we should extend the window size for this, to say 2s? I'm
> > hesitant...
> 
> Not sure. I'm mostly thinking whether it would make sense to report 1 fps if
we
> have 1 sample within the 1 second window in the frame rate case? Maybe it
> doesn't? Seems like the way this is now implemented means that we will report
0
> fps if the framerate is exactly 1 fps, which seems wrong?

Maybe we could change the constraints for valid estimate, so that a single point
is valid, but only if the window size has grown to its fill size? The biggest
problems arise when we have a single point and a very small window...

[stefan-webrtc, 2016-06-02 09:45:26]

On 2016/06/02 09:32:57, språng wrote:
> On 2016/06/02 09:05:51, stefan-webrtc (holmer) wrote:
> >
>
https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
> > File webrtc/video/receive_statistics_proxy.cc (right):
> > 
> >
>
https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
> > webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
> > decode_fps_estimator_.Rate(now).value_or(1);
> > On 2016/06/02 09:00:51, sprang wrote:
> > > On 2016/06/02 08:14:39, stefan-webrtc (holmer) wrote:
> > > > On 2016/06/02 08:09:32, språng wrote:
> > > > > On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > > > > > I'm not convinced this is correct. What if there are no samples?
> > Shouldn't
> > > > the
> > > > > > reported framerate be zero in that case?
> > > > > 
> > > > > Yeah, you're right. I'll change it to default zero.
> > > > > Same below.
> > > > 
> > > > So, will we now ever be able to measure 1 fps? :)
> > > 
> > > Not if the actual rate is <= 1 fps. But slightly more and we'll round down
> to
> > 1
> > > :)
> > > Do you think we should extend the window size for this, to say 2s? I'm
> > > hesitant...
> > 
> > Not sure. I'm mostly thinking whether it would make sense to report 1 fps if
> we
> > have 1 sample within the 1 second window in the frame rate case? Maybe it
> > doesn't? Seems like the way this is now implemented means that we will
report
> 0
> > fps if the framerate is exactly 1 fps, which seems wrong?
> 
> Maybe we could change the constraints for valid estimate, so that a single
point
> is valid, but only if the window size has grown to its fill size? The biggest
> problems arise when we have a single point and a very small window...

Yes, that sounds like a good idea.

[sprang_webrtc, 2016-06-02 12:23:50]

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/2029593002/diff/1/webrtc/video/receive_statisti...
webrtc/video/receive_statistics_proxy.cc:250: stats_.decode_frame_rate =
decode_fps_estimator_.Rate(now).value_or(1);
On 2016/06/02 09:05:51, stefan-webrtc (holmer) wrote:
> On 2016/06/02 09:00:51, sprang wrote:
> > On 2016/06/02 08:14:39, stefan-webrtc (holmer) wrote:
> > > On 2016/06/02 08:09:32, språng wrote:
> > > > On 2016/06/02 07:16:42, stefan-webrtc (holmer) wrote:
> > > > > I'm not convinced this is correct. What if there are no samples?
> Shouldn't
> > > the
> > > > > reported framerate be zero in that case?
> > > > 
> > > > Yeah, you're right. I'll change it to default zero.
> > > > Same below.
> > > 
> > > So, will we now ever be able to measure 1 fps? :)
> > 
> > Not if the actual rate is <= 1 fps. But slightly more and we'll round down
to
> 1
> > :)
> > Do you think we should extend the window size for this, to say 2s? I'm
> > hesitant...
> 
> Not sure. I'm mostly thinking whether it would make sense to report 1 fps if
we
> have 1 sample within the 1 second window in the frame rate case? Maybe it
> doesn't? Seems like the way this is now implemented means that we will report
0
> fps if the framerate is exactly 1 fps, which seems wrong?

Done. PTAL

[stefan-webrtc, 2016-06-02 12:40:07]

lgtm

[sprang_webrtc, 2016-06-02 12:53:43]

+mflodman as webrtc/base owner

[sprang_webrtc, 2016-06-02 12:53:57]

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

[sprang_webrtc, 2016-06-02 12:54:11]

Description was changed from

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

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

to

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

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

[sprang_webrtc, 2016-06-02 12:54:11]

sprang@webrtc.org changed reviewers:
- sprang@google.com

[sprang_webrtc, 2016-06-08 09:36:07]

Ping mflodman

[sprang_webrtc, 2016-06-08 11:26:40]

Actually, found a bug. stefan may want to check that out

[stefan-webrtc, 2016-06-08 11:32:41]

https://codereview.webrtc.org/2029593002/diff/60001/webrtc/base/rate_statisti...
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/60001/webrtc/base/rate_statisti...
webrtc/base/rate_statistics.cc:102: if (num_samples_ == 0) {
Why is this any different? Looks like we're removing from both
accumulated_count_ and from num_samples_, so both should go to zero, right?

[sprang_webrtc, 2016-06-08 12:07:11]

https://codereview.webrtc.org/2029593002/diff/60001/webrtc/base/rate_statisti...
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/60001/webrtc/base/rate_statisti...
webrtc/base/rate_statistics.cc:102: if (num_samples_ == 0) {
On 2016/06/08 11:32:41, stefan-webrtc (holmer) wrote:
> Why is this any different? Looks like we're removing from both
> accumulated_count_ and from num_samples_, so both should go to zero, right?

We allow 0 as count in the Update() call, so the accumulated_count_ may be 0
even with num_samples_ > 0. This leads to trailing 0-samples not being cleaned
up, in turn causing Rate() to returning a stale 0-value.

See also the test I added to cover this.

[stefan-webrtc, 2016-06-08 12:17:19]

lgtm

[sprang_webrtc, 2016-06-08 12:40:20]

Crap, found another bug - triggered when Update() wasn't call for more than a
full window size (with a preciously updated instance).

ptal

[sprang_webrtc, 2016-06-09 11:13:44]

ping?

[stefan-webrtc, 2016-06-09 12:00:07]

lgtm

[mflodman, 2016-06-10 12:30:49]

One comment, then LGTm for base/*

https://codereview.webrtc.org/2029593002/diff/80001/webrtc/base/rate_statisti...
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/80001/webrtc/base/rate_statisti...
webrtc/base/rate_statistics.cc:88: if (new_oldest_time < oldest_time_)
You can keep '<=', right?

I don't see anything happening below anyway and I think the logic is easier if
there's <= and early return here.

[sprang_webrtc, 2016-06-10 13:11:22]

https://codereview.webrtc.org/2029593002/diff/80001/webrtc/base/rate_statisti...
File webrtc/base/rate_statistics.cc (right):

https://codereview.webrtc.org/2029593002/diff/80001/webrtc/base/rate_statisti...
webrtc/base/rate_statistics.cc:88: if (new_oldest_time < oldest_time_)
On 2016/06/10 12:30:49, mflodman wrote:
> You can keep '<=', right?
> 
> I don't see anything happening below anyway and I think the logic is easier if
> there's <= and early return here.

Done.

[sprang_webrtc, 2016-06-10 13:43:09]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2016-06-10 13:43:10]

The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org,
mflodman@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2029593002/#ps100001 (title:
"Addressed comment")

[commit-bot: I haz the power, 2016-06-10 13:43:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2029593002/100001

[commit-bot: I haz the power, 2016-06-10 13:50:10]

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

[commit-bot: I haz the power, 2016-06-10 13:50:11]

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

[sprang_webrtc, 2016-06-10 20:13:37]

Description was changed from

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

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

to

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

BUG=
R=mflodman@webrtc.org, stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/51e60305e622f9156d37cb1f4...
==========

[commit-bot: I haz the power, 2016-06-10 20:13:39]

Description was changed from

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

BUG=
R=mflodman@webrtc.org, stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/51e60305e622f9156d37cb1f4...
==========

to

==========
Update RateStatistics to handle too-little-data case.

To avoid the case where a single data point or too short window is used,
causing bad behavior due to bad stats, update RateStatistics to return
an Optional rather than a plain rate.

There was also a strange off by one bug where the rate was slightly
overestimated (N + 1 buckets, N ms time window).

These changes requires updates to a number of places, and may very well
cause seeming perf regressions (but the stats were probablty more wrong
previously).

BUG=
R=mflodman@webrtc.org, stefan@webrtc.org

Committed: https://crrev.com/51e60305e622f9156d37cb1f487bd4260d5ce410
Cr-Commit-Position: refs/heads/master@{#13103}
==========

[sprang_webrtc, 2016-06-10 20:13:40]

Committed patchset #6 (id:100001) manually as
51e60305e622f9156d37cb1f487bd4260d5ce410 (presubmit successful).