End removed tracks remotely again; Make receiver.track nullable instead

[jan-ivar]

Instead of #1161, let's fire ended on remote tracks again like browsers do today, to avoid breakage.

Basically, when a transceiver's direction loses the "send" bit as a result of setting a remote description, fire an ended event on transceiver.receiver.track and set transceiver.receiver.track to null.

This necessitates making receiver.track nullable.

Later, should a transceiver's direction regain its "send" bit as a result of setting a remote description, set transceiver.receiver.track to a new track of the same kind, and call process the remote track (which fires a new track event).

This would be backwards compatible.

[taylor-b]

I was just talking about this idea with @pthatcherg today. I think it would work, though the receiver should also be recreated when a local description with the "recv" bit is set, so that media can be received before the answer.

[stefhak]

I think it would be good to work through the events (in terms of pc.removeTrack, transceiver.setDirection and so on, assuming onnegotiationneeded is wired up) that would lead to "send" and "recv" bits being set/unset.

But overall this looks like something that could work. If the intent is to have the received track being constantly connected to a video element or a recorder the sender can play with replaceTrack and use a null track for periods when there is nothing to send.

[aboba]

@jan-ivar @stefhak @taylor-b Section 5.1 says: "When the other peer stops sending a track in this manner, an ended event is fired at the MediaStreamTrack object." So one could argue that the existing draft already supports this.

Section 5.3 says "When one of the SSRCs for RTP source media streams received by receiver is removed (either due to reception of a BYE or via timeout), the mute event is fired at track. If and when packets are received again, the unmute event is fired at track." So according to this one could argue that when the sender stops sending, a mute event is received on the remote received track.

So there may actually be two events!

[jan-ivar]

@aboba That's where this started, in #1168.

Sadly, the more contradictory language in a spec, the more doubt it casts on the consensus reached.

On the muted event, that seems to be true. Unfortunately, mute may fire at other times as well, from overconstrained conditions in mediacapture, or "muted by the User Agent." e.g. a browser implementing a privacy shade or similar feature, so it'd be hard to deduce much from it alone.

[jan-ivar]

At the June virtual interim we came up with #1377 to give sites a way to detect remote track removal both in the spec and Chrome today, bridging an important transition period.

Basically, of the two approaches:

track.onended = () => log(`Track ${track.id} ended.`);
stream.onremovetrack = e => log(`Track ${e.track.id} removed.`);

only the first one would break.

Unfortunately, Firefox does not do the second one yet (though we'd add it asap).

It's still unclear however how web compatible this is. Anecdotally, it seems like few sites would be affected, just from the difficulty of dealing with browser differences when it comes to adding/removing tracks, but we don't know.

@foolip can we find out how many sites are using pc.removeStream and/or are listening to the ended event either with track.onended or addEventListener?

[foolip]

@foolip can we find out how many sites are using pc.removeStream and/or are listening to the ended event either with track.onended or addEventListener?

These numbers are percentage of page views in Chrome, not a proportion of sites, but pc.removeStream is https://www.chromestatus.com/metrics/feature/timeline/popularity/1646

There's no use counter for the "ended" event, though. Would it be useful? @guidou

[aboba]

Consensus at the September interim was to close this issue.