Re: [webrtc-pc] Reconsider replaceTrack's blocking on the operations queue. (#3017)

> The purpose of blocking on the operations queue was to make it deterministic whether the SLD wouild operate on the tracks current when we called SetLocalDescription or the tracks current after ReplaceTrack. Seems that not doing so is a bug. 

I can't seem to find a case where this matters in any browser. https://jsfiddle.net/jib1/Ltsed06f/10 creates a transceiver with a null track, but waits for replaceTrack(track) to finish before first negotiation, yet the msid line does *not* contain that late-added track's id (it contains a random id instead).

Firefox *always* creates a random track id in the msid, unless you set `media.peerconnection.sdp.encode_track_id = true` in about:config. So if any website is relying on msid track ids to match, they'd be broken in Firefox, and I think we would have heard about it.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 November 2024 19:05:43 UTC