Re: [webrtc-pc] RTCRtpReceiver.streams

> Whether you want to shim getLocal/RemoteStreams() or you want to do the 1.0 equivalent of those APIs 

@henbos The spec has moved away from streams as an API surface to RTCPeerConnection, deliberately, so we should discourage such shimming, not encourage it. E.g. we replaced the `addstream` event with the `track` event, and removed the methods you mention years ago.

There is no "1.0." of the spec yet.  People are free to shim whatever they want, but `getLocal/RemoteStreams()` are from an era where RTCPeerConnection in some implementations picked up on local changes to those streams. This no longer matches how things work.

Thus they confuse where the new API line is dawn, as to which objects RTCPeerConnection is aware of and reacts to. It's the most leaky of our [leaky abstractions](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/).

Streams are even optional in the new API, and they don't support early media. E.g. we can do:

```js
video.srcObject = new MediaStream([transceiver.receiver.track]);
await new Promise(r => transceiver.receiver.track.onunmute = r);
await video.play();

// Negotiate RTCPeerConnection here
```

So the only purpose really of the `track` event IMHO is to advertise the stream associations.

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

Received on Thursday, 26 July 2018 13:50:55 UTC