pc.getSenders() and getReceivers() include stopped ones.

[jan-ivar]

Here's how I'd play pc tracks without any associated streams:

video.srcObject = new MediaStream(pc.getTransceivers()
                                  .filter(tc => !tc.stopped)
                                  .map(tc => tc.receiver.track));

The problem is, EXAMPLE 11 uses:

remoteView.srcObject = new MediaStream(pc.getReceivers().map(r => r.track));

Unfortunately, the latter and shorter incantation might include stopped receivers I'm not expecting.

Worse, pc.getReceivers() offers no easy way to tell whether my receivers are stopped or not.

Maybe it should only return non-stopped receivers?

Same question for pc.getSenders().

It turns out HTMLVideoElement conveniently ignores ended tracks, so the above still works. But this just seems to bury the surprise even further, and I could see people tripping over this in other situations.

[fippo]

I agree with @jan-ivar, I did not expect senders/receivers from stopped transceivers.
This may become a problem if you try something like "find the first video sender, then call replaceTrack on it". Which people may have used in the track-based model (I am fairly sure I did)

We can modify the collectSenders/collectReceivers algorithms to say
For each non-stopped transceiver in transceivers
(or add a step to skip, no preference)

[alvestrand]

Stopped transceivers are kind of useless junk. You can't restart them, you can't reuse them, they're no longer squatting on your media sections even. I'm happy with ignoring them in all cases except getTransceivers.

Note: getReceivers() will still return stopped tracks in active transceivers. (can those exist?)

[jan-ivar]

@alvestrand You mean if someone does

pc.getReceiver()[0].track.stop()

...? An odd thing to do.

WebRTC doesn't mention this, so according to mediacapture-main, the receiver.track just ends (its readyState "ended") permanently.

Since this renders the transceiver useless, should we stop the transceiver from this?

[aboba]

getReceiver()[0].track.stop() stops the receiver from rendering, but doesn't affect the corresponding sender in the transceiver. So I wouldn't suggest stopping the transceiver.