Event for RTCRtpSender.replaceTrack

[renjithspace]

Hi team, I couldn't find any event to listen to a RTCRtpSender.replaceTrack. Is there any option available to listen to that?

[henbos]

There isn’t one, but it returns a promise.

[renjithspace]

@henbos Thanks for your reply!
Yes, I can use the RTCRtpSender.replaceTrack promise resolution as a callback and confirmation from the senders end.
But how could I track it from receiver's end? Is there any RTCRtpReceiver.onreplacetrack event currenlty available?

For example:
Sender replacing a track:

RTCRtpSender.replaceTrack(mytrack)

Receiver listen to the track replacement:

RTCRtpReceiver.onreplacetrack = () => {
 // do something when sender replaced the track
}

Thanks

[henbos]

I see, strictly speaking that does not exist either. And with regards to replacing one track with another track, you'll just change what frames are being sent, but nothing is negotiated to tell the other endpoint that the track was replaced. However, you can start or stop the transmission if you are using replaceTrack(null) and replaceTrack(track), which is different from enabling or disabling the track that is being sent - as that just replaces the content with black frames. RTCRtpSender.track:

The track attribute is the track that is associated with this RTCRtpSender object. If track is ended, or if the track's output is disabled, i.e. the track is disabled and/or muted, the RTCRtpSender MUST send black frames (video) and MUST NOT send (audio). In the case of video, the RTCRtpSender SHOULD send one black frame per second. If track is null then the RTCRtpSender does not send. On getting, the attribute MUST return the value of the [[SenderTrack]] slot.

But so what happens if we start or stop sending?

Whenever an RTCRtpReceiver receives data on an RTP source whose corresponding MediaStreamTrack is muted, but not ended, and the [[Receptive]] slot of the RTCRtpTransceiver object the RTCRtpReceiver is a member of is true, it MUST queue a task to set the muted state of the corresponding MediaStreamTrack to false.

When one of the SSRCs for RTP source media streams received by an RTCRtpReceiver is removed either due to reception of a BYE or via timeout, it MUST queue a task to set the muted state of the corresponding MediaStreamTrack to true. Note that setRemoteDescription can also lead to the setting of the muted state of the track to the value true.

You should not expect to see an RTCP BYE, this only happens when the transmission ends permanently (e.g. RTCRtpTransceiver.stop()). But you should expect to see onmute fire after a timeout and onunmute to happen when receiving packets again. However...

• I don't know what this timeout is supposed to be, and in either case it is not instant like you might expect.
• It could also happen due to connectivity issues, so this is not a "replaceTrack" event.
• Chromium-based browsers does not implement muting and unmuting properly, so it can't be relied upon on several of today's implementations.

[henbos]

There is, however, RTCRtpReceiver.getContributingSources()[i].timestamp, which will tell you what time you last received an RTP packet. That might help you, but again, how could you tell if packets are not arriving due to replaceTrack() or due to a network disruption?

[alvestrand]

There is absolutely no sign on the receiver side that ReplaceTrack has happened; that was part of the design of ReplaceTrack.
If you want to tell the other side, you can add a track and negotiate instead, or send a nonstandard notiifcation on the datachannel.
Closing as "working as intended".