Re: [webrtc-pc] Remove stopped transceivers from getTransceivers() (#2092)

From [Exploring RTCRtpTransceiver](https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/) blog post, under the "Well-defined transceiver order" sub-heading:

> ### Well-defined transceiver order.
> Something I overlooked last year is that `transceiver.mid` is `null` before `setLocalDescription`. We avoided that problem above by establishing the connection ahead of sending anything, but this makes `mid` useless for correlating in the initial negotiation.
> 
> The good news here since last year is that `pc.getTransceivers()` order is now well-defined! Transceivers always appear in creation-order, whether introduced by you with `addTransceiver`, or in m-line order from `setRemoteDescription`. That m-line order matches the other side’s transceiver order, at least initially.
> 
> With some care, this means we can correlate tracks using transceiver order from the initial offer itself. Here’s an example—without check-boxes this time—that does that. We’re also introducing a microphone into the picture: 
> ```js
> let camStream;
> 
> (async () => {
>   try {
>     const [pc1, pc2] = localPeerConnectionLoop();
>     camStream = await navigator.mediaDevices.getUserMedia({video: true, audio: true});
>     let transceivers = [
>       pc1.addTransceiver(camStream.getVideoTracks()[0], {streams: [camStream]}),
>       pc1.addTransceiver(camStream.getAudioTracks()[0], {streams: [camStream]}),
>       pc1.addTransceiver(whiteNoise())
>     ];
> 
>     pc2.ontrack = ({transceiver, streams: [stream]}) => {
>       if (transceiver.mid == pc2.getTransceivers()[2].mid) {
>         videoB.srcObject = new MediaStream([transceiver.receiver.track]);
>       } else {
>         videoA.srcObject = stream;
>       }
>     }
>   } catch (e) {
>     console.log(e)
>   }
> })();
> ```
> In the “Result” tab, you’ll see the camera on the left again. You can mute the audio in that video element as well.
> 
> This time in `pc2.ontrack`, we don’t cheat by looking at the other side’s `transceivers`. We only look at our own `pc2.getTransceivers()` which is **guaranteed to be in the same order here**.
> 
> Specifically, we look if this is the third transceiver (`pc2.getTransceivers()[2]`), and if so, put it on the right, otherwise left. We also use the `streams` argument to intuitively group the camera and microphone tracks together. Since the third track didn’t have a stream in this case, we could have keyed off of that difference instead. There may be several ways to correlate at times: by transceiver order, by stream, or by out-of-band `mid`.
> 
> If you’re wondering how we can access the third transceiver already in the first `ontrack`, the API guarantees that `setRemoteDescription` is effectively done by the time the `track` events all fire. All transceivers are there; all tracks are in their streams.

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

Received on Friday, 15 February 2019 15:24:18 UTC