RTCStatsCollector and RTCPeerConnectionStats added

RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3] https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstats-dict*

BUG=chromium:627816, chromium:636818
Committed: https://crrev.com/d565b73121b1b7672fb7d1f115bbbbb137a838eb
Cr-Commit-Position: refs/heads/master@{#13979}

[hbos, 2016-08-14 09:18:28]

Description was changed from

==========
RTCStatsCollector

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

to

==========
RTCStatsCollector

BUG=chromium:627816, chromium:636818
==========

[hbos, 2016-08-14 09:40:12]

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

[commit-bot: I haz the power, 2016-08-14 09:40:23]

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, 2016-08-14 09:47:13]

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

[commit-bot: I haz the power, 2016-08-14 09:47:13]

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

[hbos, 2016-08-14 11:40:30]

Description was changed from

==========
RTCStatsCollector

BUG=chromium:627816, chromium:636818
==========

to

==========
RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3]
https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstat...

BUG=chromium:627816, chromium:636818
==========

[hbos, 2016-08-24 09:39:14]

Patchset #4 (id:60001) has been deleted

[hbos, 2016-08-24 09:39:21]

Patchset #3 (id:40001) has been deleted

[hbos, 2016-08-24 09:39:29]

Patchset #2 (id:20001) has been deleted

[hbos, 2016-08-24 09:39:39]

Patchset #1 (id:1) has been deleted

[hbos, 2016-08-24 09:50:51]

Patchset #1 (id:80001) has been deleted

[hbos, 2016-08-24 10:33:38]

hbos@webrtc.org changed reviewers:
+ hta@webrtc.org, magjed@webrtc.org

[hbos, 2016-08-24 10:33:39]

Please take a look hta and magjed.

hta: everything
magjed: webrtc/stats/DEPS stamping

I'll add a webrtc/api OWNER too after first round.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/BUILD.gn
File webrtc/stats/BUILD.gn (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/BUILD.gn#ne...
webrtc/stats/BUILD.gn:35: }
This is because rtcstatscollector.cc and rtcstatsstatscollector_unittest.cc
include webrtc/api/peerconnection.h which includes a bunch of stuff, resulting
in lots of chromium-style errors in all sorts of webrtc/api and webrtc/media
header files (Complex class/struct needs an explicit out-of-line constructor,
Complex constructor/destructor has an inlined body, Complex class/struct needs
an explicit out-of-line constructor/destructor, etc, etc).

We also get some of these errors for the rtcstats_objects.h due to not having a
explicit out of line copy constructor and destructor, and because the
WEBRTC_RTCSTATS_IMPL macro defines inline virtual methods. We could split the
macro up into a "DECLARE" and "DEFINE" version for .h and .cc files but I don't
feel like doing that in this CL when we have to ignore these warnings anyway.

(The warnings are only present in GN, not GYP.)

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/DEPS
File webrtc/stats/DEPS (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/DEPS#newcode4
webrtc/stats/DEPS:4: "+webrtc/media",
Due to rtcstatscollector_unittest.cc including
webrtc/media/base/fakemediaengine.h

[hta-webrtc, 2016-08-24 13:02:16]

Every time I see a double representing time, I would prefer it to be in seconds
(since the Unix epoch if abolute, just seconds if relative).

Otherwise, nits.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.cc (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:37: double now = GetTimeNowMs();
Milliseconds again?

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:59: return timing_->TimerNow() *
rtc::kNumMillisecsPerSec;
If you keep cache lifetime in seconds (0.05 by default), this function is
superfluous.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:65: // yield incorrect counts. Address before
closing crbug.com/636818.
Spec reference:
https://w3c.github.io/webrtc-stats/webrtc-stats.html#pcstats-dict* - it is good
to have the link in the code.

And yes, it's wrong; these are supposed to be incrementing counters. I'll get
the spec updated to clarify that.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:31: double cache_lifetime = 50.0,
What's the unit of this lifetime?
It used to be 50 milliseconds, but all other doubles are in seconds (I think).

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:33: new rtc::Timing()));
Checking: Do default arguments to constructors get executed once (like in
Python) or every time we invoke the constructor?
(I assume it won't be executed when the argument is filled in.)

If the latter, will there be a new rtc::Timing() object created for every
instance of RTCStatsCollector? That seems wasteful.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector_unittest.cc (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:97: EXPECT_EQ(a.get(), b.get());
Should you add EXPECT_TRUE(a.get()) too? This set of tests will trivially pass
if GetStatsReport returns null the first 2 times.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:141:
EXPECT_EQ(*pcstats.data_channels_opened, static_cast<uint32_t>(1));
I'd expect "opened" to be larger than "closed", since the difference is supposed
to be the number of currently open datachannels. Later CL, but you may want to
add a TODO.

[hbos, 2016-08-24 14:27:59]

hbos@webrtc.org changed reviewers:
+ glaznev@webrtc.org

[hbos, 2016-08-24 14:28:00]

Please take (another) look hta, glaznev, magjed.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.cc (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:37: double now = GetTimeNowMs();
On 2016/08/24 13:02:15, hta-webrtc wrote:
> Milliseconds again?

Ah, I forgot about having changed stats to use seconds. Updated the collector to
do so as well.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:59: return timing_->TimerNow() *
rtc::kNumMillisecsPerSec;
On 2016/08/24 13:02:15, hta-webrtc wrote:
> If you keep cache lifetime in seconds (0.05 by default), this function is
> superfluous.

Done.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.cc:65: // yield incorrect counts. Address before
closing crbug.com/636818.
On 2016/08/24 13:02:15, hta-webrtc wrote:
> Spec reference:
> https://w3c.github.io/webrtc-stats/webrtc-stats.html#pcstats-dict* - it is
good
> to have the link in the code.
> 
> And yes, it's wrong; these are supposed to be incrementing counters. I'll get
> the spec updated to clarify that.

Done.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:31: double cache_lifetime = 50.0,
On 2016/08/24 13:02:16, hta-webrtc wrote:
> What's the unit of this lifetime?
> It used to be 50 milliseconds, but all other doubles are in seconds (I think).

Changed to seconds and added a comment for the variable.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:33: new rtc::Timing()));
On 2016/08/24 13:02:16, hta-webrtc wrote:
> Checking: Do default arguments to constructors get executed once (like in
> Python) or every time we invoke the constructor?
> (I assume it won't be executed when the argument is filled in.)
> 
> If the latter, will there be a new rtc::Timing() object created for every
> instance of RTCStatsCollector? That seems wasteful.

There's one Timing object constructed per collector. It contains no data, only
methods, so it's not that wasteful. We'll only have one collector per peer
connection.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector_unittest.cc (right):

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:97: EXPECT_EQ(a.get(), b.get());
On 2016/08/24 13:02:16, hta-webrtc wrote:
> Should you add EXPECT_TRUE(a.get()) too? This set of tests will trivially pass
> if GetStatsReport returns null the first 2 times.

Done.

https://codereview.webrtc.org/2242043002/diff/120001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:141:
EXPECT_EQ(*pcstats.data_channels_opened, static_cast<uint32_t>(1));
On 2016/08/24 13:02:16, hta-webrtc wrote:
> I'd expect "opened" to be larger than "closed", since the difference is
supposed
> to be the number of currently open datachannels. Later CL, but you may want to
> add a TODO.

Done.

[magjed_webrtc, 2016-08-25 09:07:52]

I have looked at the DEPS part. Can you clarify why stats need to depend on
media? The only reason I see is that fakemediaengine is used in
rtcstatscollector_unittest.cc, and it's only used to set up
cricket::ChannelManager. Can the dependency to media be avoided?

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/api/rtcstats_obje...
File webrtc/api/rtcstats_objects.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/api/rtcstats_obje...
webrtc/api/rtcstats_objects.h:15: #include <string>
memory and vector seem to be unused includes in this file

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:16: #include "webrtc/api/peerconnection.h"
If this is only used for PeerConnection*, forward declare it instead of
including it.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:19: #include "webrtc/base/refcount.h"
refcount is not needed?

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:29: RTCStatsCollector(
You have only one mandatory argument, so I think you need to use explicit here
to disallow implicit conversions from PeerConnection*.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector_unittest.cc (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:15: #include <utility>
This looks unused as well?

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:70: cricket::FakeMediaEngine*
media_engine_;
This member variable is unused.

[hta-webrtc, 2016-08-26 09:28:57]

lgtm

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:45: bool IsSignalingThread() const;
Naming nit: This isn't a thread, so "IsSignalingThread" is a misleading name.
"IsOnSignalingThread" is better.
(Unless there's other code that you want to be consistent with)

[hta-webrtc, 2016-08-26 09:28:57]

lgtm

lgtm

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:45: bool IsSignalingThread() const;
Naming nit: This isn't a thread, so "IsSignalingThread" is a misleading name.
"IsOnSignalingThread" is better.
(Unless there's other code that you want to be consistent with)

[hta-webrtc, 2016-08-26 09:28:57]

lgtm

lgtm

lgtm

[hta-webrtc, 2016-08-26 09:29:16]

lgtm

[hta-webrtc, 2016-08-26 09:29:56]

lgtm

I meant to say "lgtm once magjed's comments are addressed".

[hbos, 2016-08-29 13:10:59]

Please take (another) look glaznev and magjed.

On 2016/08/25 09:07:52, magjed_webrtc wrote:
> I have looked at the DEPS part. Can you clarify why stats need to depend on
> media? The only reason I see is that fakemediaengine is used in
> rtcstatscollector_unittest.cc, and it's only used to set up
> cricket::ChannelManager. Can the dependency to media be avoided?

So far that is the only dependency. To avoid it I would have to move it, but it
should live with the class it is faking I think. I can't create my own version
of it without including media/, but that would also not be nice (code
duplication).
Considering stats will be collected for a lot of different things, I think a
media/ inclusion is just a matter of time with or without that particular
inclusion.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/api/rtcstats_obje...
File webrtc/api/rtcstats_objects.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/api/rtcstats_obje...
webrtc/api/rtcstats_objects.h:15: #include <string>
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> memory and vector seem to be unused includes in this file

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector.h (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:16: #include "webrtc/api/peerconnection.h"
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> If this is only used for PeerConnection*, forward declare it instead of
> including it.

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:19: #include "webrtc/base/refcount.h"
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> refcount is not needed?

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:29: RTCStatsCollector(
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> You have only one mandatory argument, so I think you need to use explicit here
> to disallow implicit conversions from PeerConnection*.

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector.h:45: bool IsSignalingThread() const;
On 2016/08/26 09:28:57, hta-webrtc wrote:
> Naming nit: This isn't a thread, so "IsSignalingThread" is a misleading name.
> "IsOnSignalingThread" is better.
> (Unless there's other code that you want to be consistent with)
> 

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
File webrtc/stats/rtcstatscollector_unittest.cc (right):

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:15: #include <utility>
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> This looks unused as well?

Done.

https://codereview.webrtc.org/2242043002/diff/160001/webrtc/stats/rtcstatscol...
webrtc/stats/rtcstatscollector_unittest.cc:70: cricket::FakeMediaEngine*
media_engine_;
On 2016/08/25 09:07:52, magjed_webrtc wrote:
> This member variable is unused.

Removed it.

[magjed_webrtc, 2016-08-30 08:21:42]

On 2016/08/29 13:10:59, hbos wrote:
> Please take (another) look glaznev and magjed.
> 
> On 2016/08/25 09:07:52, magjed_webrtc wrote:
> > I have looked at the DEPS part. Can you clarify why stats need to depend on
> > media? The only reason I see is that fakemediaengine is used in
> > rtcstatscollector_unittest.cc, and it's only used to set up
> > cricket::ChannelManager. Can the dependency to media be avoided?
> 
> So far that is the only dependency. To avoid it I would have to move it, but
it
> should live with the class it is faking I think. I can't create my own version
> of it without including media/, but that would also not be nice (code
> duplication).
> Considering stats will be collected for a lot of different things, I think a
> media/ inclusion is just a matter of time with or without that particular
> inclusion.
>
Alright, thanks for the explanation. lgtm

[hbos, 2016-08-30 08:31:45]

Please take a look, glaznev.

[AlexG, 2016-08-30 17:05:57]

lgtm

[hbos, 2016-08-30 20:48:57]

The CQ bit was checked by hbos@webrtc.org

[hbos, 2016-08-30 20:48:57]

The patchset sent to the CQ was uploaded after l-g-t-m from hta@webrtc.org,
magjed@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2242043002/#ps220001 (title:
"Rebase with master")

[commit-bot: I haz the power, 2016-08-30 20:48:59]

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-30 21:04:39]

Description was changed from

==========
RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3]
https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstat...

BUG=chromium:627816, chromium:636818
==========

to

==========
RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3]
https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstat...

BUG=chromium:627816, chromium:636818
==========

[commit-bot: I haz the power, 2016-08-30 21:04:40]

Committed patchset #7 (id:220001)

[commit-bot: I haz the power, 2016-08-30 21:04:51]

Description was changed from

==========
RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3]
https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstat...

BUG=chromium:627816, chromium:636818
==========

to

==========
RTCStatsCollector and RTCPeerConnectionStats added.

This is the stats collector for the new stats types, RTCStats[1] and
RTCStatsReport[2]. It so far only produces RTCPeerConnectionStats[3] as
an example of how it would collect stats. Each RTCStats subclass will
get a corresponding RTCStatsCollector::ProduceFooStats().

Stats reports are cached and returned as const references (ref
counting). This allows stats to be inspected by multiple observers and
across multiple threads. No copies will have to be made when surfacing
this to Blink or other places.

The current implementation of ProducePeerConnectionStats() only look at
existing DataChannels. This might be incorret if data channels can be
removed? Will investigate in a follow-up, crbug.com/636818.

[1] https://www.w3.org/TR/2016/WD-webrtc-20160531/#idl-def-rtcstats
[2] https://www.w3.org/TR/2016/WD-webrtc-20160531/#rtcstatsreport-object
[3]
https://w3c.github.io/webrtc-stats/archives/20160526/webrtc-stats.html#pcstat...

BUG=chromium:627816, chromium:636818

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

[commit-bot: I haz the power, 2016-08-30 21:04:52]

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