- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Mar 2020 14:37:22 +0000
- To: public-webrtc-logs@w3.org
I want to address those good ideas, but first I'd like to separate interpretation from remedy, because I don't accept those premises as interpretations of the current spec. **My interpretation is in https://github.com/w3c/webrtc-pc/issues/2476:** there's one set of transceivers in webrtc-pc that JSEP reads and modifies from a different thread. > JSEP's in-parallel steps can't read webrtc-pc's set of transceivers, because that is a race. Sure it can. Yes it's a race, and I agree we _probably_ need to fix it somehow, but it's what the spec says to do at the moment, because JSEP says _"RtpTransceivers of ... that were added to the PeerConnection by addTrack"_, and webrtc-pc doesn't intervene here. I want to establish that A) Firefox is spec compliant here, and 2) the spec needs to be fixed. Because at least one Firefox engineer who worked hard to follow the spec, will have a lot of work to do to fix this with whatever we come up with, so I think we should be clear the problem is in the spec, not the interpretation. Oh, and C) the intent has always been for this addTrack to get associated one way or another: ```js pc.setRemoteDescription(offer); // note: no await pc.addTrack(track, stream); // Supposed to always get associated ``` ...even though even in the current spec with its direct cross-thread data writing, one _tiny window_ remains: An (e.g. onclick) addTrack called in a task queued immediately ahead of SRD's queued task for success, won't get associated. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2502#issuecomment-606668087 using your GitHub account
Received on Tuesday, 31 March 2020 14:37:26 UTC