The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/101ae86567ba231c612af756e2bb5925a127ea30

commit 101ae86567ba231c612af756e2bb5925a127ea30
Author: Henrik Boström <hbos@chromium.org>
Date: Fri Oct 13 20:38:59 2017

PC.setRemoteDescription: Use track-based callbacks over stream-based.

In RTP Media API, the processing of remote MediaStreamTracks works with
the "addition" or "removal" of a remote track, i.e. of a receiver. The
receiver has a track and an associated set of streams.
https://w3c.github.io/webrtc-pc/#processing-remote-mediastreamtracks

I refer to the new set of APIs as the track-based APIs, because they're
centered around tracks, tracks being added to streams is a side-effect
to the processing of tracks.

This is different from the stream-based APIs, centered around remote
streams being added or removed. While tracks could be added or removed
from streams in this API there was always the assumption that a stream
owned its track. As such, when a stream was added or removed, all of
its tracks would be created or destroyed.

Switching over to track-based callbacks, the ownership of tracks
changes. A track can be added or removed to zero, one or multiple
streams. On DidAddRemoteTrack we check if a stream or track exist before
we create it and add the track to the stream.

In this CL:
- The receiver's set of associated streams is exposed (C++ layers).
- Stream added/removed callbacks replaced by track added/removed,
  creating or getting streams/tracks based on the receivers.
- Updating mocks and unittests.

All usage cases that worked with addStream/removeStream() should
continue to work with the new callbacks, and the new callbacks will
enable new RTP Media API behavior not previously supported.

Additionally, this fixes  https://crbug.com/773613  because it makes ontrack fire
for new tracks, even if the new tracks are surfaced as belonging to an existing
stream.

Follow-up CLs:
- Add unittests for moving existing tracks between streams and make
  sure we don't end up with multiple tracks.  https://crbug.com/769743 
- With receivers added/removed based on callbacks, define
  getReceivers() as "return rtp_receivers_".  http://crbug.com/755166 

Future CLs:
- All associated events are fired according to spec and in the right
  order.  https://crbug.com/760107 
- Define getRemoteStreams() in terms of "all streams of all receivers".
   https://crbug.com/741618 
- Define addStream/removeStream() in terms of addTrack()/removeTrack().
   https://crbug.com/738929 
- Add usage metrics for add/remove tracks.  https://crbug.com/765170 

Resolving all these bugs will reduce the technical dept.

Bug:  773613 ,  741619 ,  705901 ,  769743 ,  760107 ,  741618 ,  738929 ,  765170 ,  webrtc:7933 
Change-Id: I75c18b889e1d4d5827c53bf6dd627f495ca22b51
Reviewed-on: https://chromium-review.googlesource.com/657639
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508805}
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/mock_peer_connection_impl.cc
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/mock_peer_connection_impl.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/mock_web_rtc_peer_connection_handler_client.cc
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/mock_web_rtc_peer_connection_handler_client.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/rtc_peer_connection_handler.cc
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/rtc_peer_connection_handler.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/rtc_peer_connection_handler_unittest.cc
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/webrtc/rtc_rtp_receiver.cc
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/content/renderer/media/webrtc/rtc_rtp_receiver.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/Source/modules/peerconnection/RTCRtpReceiver.cpp
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/Source/modules/peerconnection/RTCRtpReceiver.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/public/platform/WebRTCPeerConnectionHandlerClient.h
[modify] https://crrev.com/101ae86567ba231c612af756e2bb5925a127ea30/third_party/WebKit/public/platform/WebRTCRtpReceiver.h

TODO...?

PeerConnectionTracker
- TrackAddTrack (local/remote)
- TrackRemoveTrack (local/remote)
- TrackGetSenders

RTCPeerConnection.cpp / UseCounter
- addTrack
- removeTrack
- getSenders
- (Maybe in the future, file bug?) When pc, stream and track events fire if and
  only if they have an event listener.

Why are there two different metrics?

hta do you know why there is both a PeerConnectionTracker and UseCounter for tracking usage of APIs and SRD results?

And where do these show up? I figured we should get the use counters in before unflagging.

I believe the PeerConnectionTracker links to chrome://webrtc-internals, while the use counters link to UMA.

If you look at peer_connection_tracker.cc, you will see that it formats strings and calls SendPeerConnectionUpdate, which I think eventually ends up in a WebRTCEventLogHost.

I suspect that the two concepts were developed independently.

For this the preferred way for "UseCounter" is to do [Measure] in the .idl since the method signatures are different for legacy and non-legacy uses.

As for PeerConnectionTracker... I can't find anything in chrome://webrtc-internals, so I don't know how important this is.

Seems good to me. [Measure] in the IDL gives you a well defined metric, and I don't see a reason why this should show up in chrome://webrtc-internals at the moment.

Oh now I see what shows up in chrome://webrtc-internals. We should add this for addTrack and friends too. But I'll file a separate issue for that since it's for debugging and less important to make it to M64:  https://crbug.com/789935 

I'll mark this one as Verified when [Measure] has landed. We want this for the M64 cut (since the APIs are unflagged in M64), CL in CQ: https://chromium-review.googlesource.com/c/chromium/src/+/800110

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30a16b5da6a07359329d7a89c9a311a455b54b64

commit 30a16b5da6a07359329d7a89c9a311a455b54b64
Author: Henrik Boström <hbos@chromium.org>
Date: Thu Nov 30 14:53:35 2017

Add use counters for RTCPeerConnection's RTP Media API methods.

This will allow us to compare legacy versus compliant ways of handling
media in WebRTC. Legacy being addStream/removeStream/getLocalStreams/
getRemoteStreams. Spec way: addTrack/removeTrack/getSenders/
getReceivers.

No-Try: true
Bug:  765170 
Change-Id: I0efe37b26869d4d20c81d4c88d4390a926065c69
Reviewed-on: https://chromium-review.googlesource.com/800110
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520540}
[modify] https://crrev.com/30a16b5da6a07359329d7a89c9a311a455b54b64/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl
[modify] https://crrev.com/30a16b5da6a07359329d7a89c9a311a455b54b64/third_party/WebKit/public/platform/web_feature.mojom
[modify] https://crrev.com/30a16b5da6a07359329d7a89c9a311a455b54b64/tools/metrics/histograms/enums.xml

Did this make it to M64?

Yes.
commit 30a16b5da6a07359329d7a89c9a311a455b54b64 was:
  initially in 64.0.3282.0