Meeting minutes
Recording: https://
Slideset: https://
WebRTC-PC Interop Issues 🎞︎
Issue #3088 [[IceRole]] initialized too late 🎞︎
Youenn: any observable change from this?
Jan-Ivar: I don't think so, but still to be confirmed through updated WPTs
RESOLUTION: Proceed with PR to fix this
Guido: the PR may provide opportunity for more detailed reaction
Issue #3090 · Should garbage collecting RTCPeerConnection be observable? 🎞︎
Youenn: when eventhandlers are registered, the PC isn't GC-able
… pc.onicecandidate is registered in the test under discussion
Harald: I'm remembering updating tests to add pc.close() to ensure GC
… we've been pushing that any way of reaching an open PC should make it not GC-able
Jan-Ivar: GC is obversable from the remote end
… current Firefox behavior is to GC more aggresively than other browsers, which avoids issues when devs don't call pc.close()
Youenn: in the test case we're discussing, this is because FF detects no ice candidate can reach pc2? otherwise, it feels like a bug in FF
Youenn: not sure about changing the spec; the test probably needs more review
Dom: how much real-word compat issue is this creating?
Jan-Ivar: not aware of any specifically
Dom: then maybe we don't need to fix it
Harald: fixing the test feels like always worth it
Issue #3092 · RTCError should be exposed on Workers 🎞︎
RESOLUTION: adopt proposal
Issue #3095 · https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-offer is unclear 🎞︎
Jan-Ivar: another option is to clarify the intent of the spec
Youenn: that's option A
Jan-Ivar: this predates promises, when we had concerns about the negotiationneeded event
… this may no longer be as much an issue if you await promises, but there are still hard-to-pin-down tricky timing issues that this was meant to prevent and are likely still relevant
… FF optimizes this cleverly, which could serve as a basis for a more specific algorithm
… the main goal is to ensure that as you're about to send the results of createOffer, you ensure it's still aligned with JS state
Youenn: given the example is about system resoures, that's not so clear to me
Harald: the relevant test creates an offer without any tracks, then add a track; this is not obvious that this is what the spec is asking
… I'd be in favor of some version of Option A if we can find a clean way to spec it
Youenn: if we go with option A, if negotiation might be needed and createOffer is in process, you would need to check
… the spec already asks to generate the answer on main thread
… we should either clarify the spec with normative language, or non-normative language, to ensure alignment between what's the page is asking and the offer
PROPOSED: Proceed with option A, ideally with normative language, or non-normative if not possible
Guido: is this causing issues in the wild? if not, option C is good
Youenn: not aware of real web compat issues
Jan-Ivar: can't rule it out since they would be really hard to track down
Harald: let's see a concrete proposal for option A before resolving this
TimP: if the change you've put in JS is not in the offer, won't there be a negotiationneeded event to fix things?
Jan-Ivar: but using negotiationneeded isn't required
TimP: if this was designed before we added better APIs (negotiationneeded and transceiver), is this complexity still needed?
Jan-Ivar: there are data races that the spec should protect from, even if they're corner cases
youenn: it's not an alternative between race and no-race - it's mostly about optimizing API shape
Jan-Ivar: I'll provide more background on the historical intent
Issue #3096 · Vague error for setting a description, inconsistent wpt 🎞︎
Guido: does this mean Chrome and Safari would fail the test?
Jan-Ivar: yes
Harald: I agree with the principle
Guido: I'm OK with fixing the test, but wouldn't want to keep it in Interop 26
Youenn: I'm OK with the fix; no strong feeling about interop 26, doesn't look like it should be a big change to libwebrtc
RESOLUTION: Proceed with fixing test case; integration in interop 26 still TBD
Issue #3097 · Should RTCDataChannel.send be allowed to throw synchronously for not enough buffer space 🎞︎
Jan-Ivar: FF lets you send an unlimited amout since we didn't see a reason to limit it; the proposed change works for us, although UA-dependent behavior isn't great
Youenn: this may be something worth bringing in a separate issue, but not part of interop 26
RESOLUTION: Proceed with proposal of spec clarification
Capabilities Element 🎞︎
Daniel: we've been discussing the <usermedia> element, now I have a draft spec
… interested in guidance in how to proceed with it moving forward
… we have a chrome legacy attribute on which I'm also seeking guidance
Jan-Ivar: going piecemeal would be OK
Youenn: +1 with going piecemeal after initial explainer - you may need to update mediacapture-main with hooks
Daniel: should I model this after the other explainer in mediacapture-extensions?
Guido: start from the TAG model
Youenn: so start with an explainer, then a series of PR on media capture extensions (possibly completed with additions to -main as needed)
… do you have a sense of a timeline?
Daniel: hope to get back to this next week; we already have a Blink-process explainer which I hope can serve as a good basis
MSTP audio / AudioTrackGenerator 🎞︎
Jan-Ivar: the data has been longer to produce than initially planned given Paul's availability
TimP: I have some sympathy on the overlap argument, but the use cases are quite different
… MSTP is mostly useful when you're processing both audio and video together - having different APIs for things that are tightly coupled in the way developers approach it is not very satisfactory
… e.g. do lips-rerendering in video based on the audio
Jan-Ivar: our finding is that audio and video are different enough that you're likely to end up wanting to treat them differently
TimP: I still feel like there is a useful niche in approaching them together
Guido: beyond measurements (on which I'm looking forward to refutal) - there is a non-niche use case requested by multiple use cases we presented at a previous meeting where audio glitches feel unavoidable when processing doesn't hit audio deadlines
… this particular use case can't be implemented without glitches in FF and Safari given lack of MSTP audio
Jan-Ivar: might be worth highlighting it on the github issue
Youenn: TimP made a good point about the scenario where having main thread + audio worklet + worker - this would be what a test should demonstrate
… it would be good to ensure the requirements from Chrome's team are well understood
Guido: we have sample code that illustrated our use case
Youenn: so two actions are needed: a better MSTP shim, and an illustration of how to avoid glitches when audio processing can't meet the audio clock based on the sample Guido shared previously
Harald: I would encourage a dedicated meeting between Guido and Paul to advance on this outside of a WG meeting
Previous discussion on the topic
Jan-Ivar: to clarify, the goal of the shim is not to demonstrate no perf impact - the proper comparison should be with a audio worklet architecture
TimP: if there is a such meeting, hope the group is invited (even if not required)
@@@: if there are differences of jitter between input and rendering, there will be glitches if there is no buffering, given WebAudio and MSTP have different models (push vs pull)
Youenn: what timeline for these actions? given potential dependency on implementation work
Jan-Ivar: I need to check with Paul