Re: [webrtc-pc] Spec-compliant way to get remote streams and tracks?

Taking a step back, the pivot to tracks in the API did two things for me:
 1. It lets us organize around what's being sent. E.g. when sending two video streams with a shared audio track, it's obvious we're sending three tracks, not four, yet we still reconstitute *two* video streams with a *shared* audio track remotely.
 
I think of the remote streams as managed by the remote *RTCPeerConnection* as a whole, not any individual receiver, since receivers are per track (a many-to-one or a few relationship).

 2. It decouples peer connection controls from `stream.addTrack` and `stream.removeTrack`, avoiding action at a distance.

Local stream makeup is irrelevant, because the stream makeup projected to the other side is made up entirely from the arguments to `pc.addTrack` et all. Therefore it matters little what stream(s) a track being sent is truly in. To illustrate:
```js
let track = stream.getTracks()[0];
pc.addTrack(track, stream); // no need to check if track is in stream here,
stream.removeTrack(track);  // because we may remove it right after anyway.
```

It sounds like `pc.getRemoveStreams()` did what you want, though we removed it in the spec. It truly is redundant though, as everything is exposed already in the `track` event.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1182#issuecomment-304162466 using your GitHub account

Received on Friday, 26 May 2017 00:53:15 UTC