16:02:20 <RRSAgent> RRSAgent has joined #webrtc
16:02:24 <RRSAgent> logging to https://www.w3.org/2025/12/09-webrtc-irc
16:02:24 <Zakim> Zakim has joined #webrtc
16:02:24 <dom> RRSAgent, make log public
16:02:25 <dom> Meeting: WebRTC December 2025 meeting
16:02:25 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/December_9_2025
16:02:25 <dom> Slideset: https://docs.google.com/presentation/d/1YW1Ump4IFnQEkTVlgI5rEzJVuWycVSVDDqj3S0s__9k/
16:02:25 <dom> Chairs: Guido, Jan-Ivar, Youenn
16:02:25 <dom> Present: Guido, Dom, Jan-Ivar
16:02:50 <dom> Present+ Youenn, Guido, Dom
16:04:32 <dom> Present+ Carine
16:05:31 <dom> Present+ MinhLe
16:05:52 <dom> Present+ Harald
16:06:09 <dom> Present+ ThomasNguyen
16:07:40 <dom> Present+ Jan-Ivar
16:08:34 <dom> Recording is starting
16:10:00 <dom> Topic: -> https://github.com/WICG/PEPC/blob/main/usermedia_element.md usermedia element
16:10:00 <dom> [slide 10]
16:12:46 <dom> minh: the <geolocation> element seems to work well; <usermedia> is a bit more complex, we're iterating on it based on input from Jan-Ivar and feedback from adopters, in particular with regard to muting
16:14:36 <dom> Jan-Ivar: generally supportive; there are different versions of PEPC with fairly different shapes - we need to look at the details, to make sure we can have PEPC buttons that can replace existing buttons
16:14:46 <dom> ... I suspect this WG might need to own the problem, should at least help
16:15:17 <dom> Youenn: confirming interest as shared in TPAC; still some concerns
16:15:42 <dom> ... some aspects don't belong to WebRTC, but the interactions of <usermedia> with device enumeration would best be handled in this WG
16:15:55 <dom> ... it would be good to understand how to work together on this
16:16:23 <dom> ... I'm not sure we're ready to dive into all the details, esp since it's still evolving
16:16:31 <dom> ... from what I've heard <geolocation> is about to ship in Chrome
16:16:44 <dom> ... for <usermedia>, I really want the WebRTC WG to have input to it before it ships
16:17:38 <dom> Guido: mute/unmute is being added to the <usermedia> element - can you say more? can you share more about VC apps developers feedback on this?
16:18:37 <dom> Thomas: when people click on <usermedia>, they get prompted for permission; then later it can be used to mute/unmute
16:19:11 <dom> -> https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 Discussion on <usermedia> element in PEPC repo
16:19:52 <dom> Present+ JasonMesser
16:20:10 <dom> Jan-Ivar: at Mozilla, we wanted the PEPC button to replace existing buttons in apps
16:20:47 <dom> ... for <usermedia>, we identified the unmute/mute button as the most likely affordance (matching .enabled from a MST perspective)
16:21:25 <dom> ... an alternative is relying on .muted state in MST (not under JS control)
16:22:13 <dom> ... a bit of a double-edge sword: stronger user guarantees vs ways for developers to provide additional values (e.g. detect speak-on-mute)
16:22:41 <dom> ... also, developers need to be on board with the approach, otherwise they can simply switch out to a regular button if the PEPC button is too restrictive
16:23:39 <dom> MinhLe: re pre-prompt vs in-app UI, this is mostly based on VC apps preferences which approach they take with PEPC
16:24:48 <dom> youenn: re mute and unmute, media session solves this, with different level of user gesture requirement
16:25:26 <dom> ... if mute/unmute gets integrated with PEPC, the main difference would be the constraints under which this gets callable
16:26:09 <dom> ... in media session, we felt that user gesture was sufficient for unmuting given that permission was granted previously - we only wanted to protect against e.g. a web page unmuting while hidden
16:26:45 <dom> ... Device enumeration is a pain point for Web pages given differences among browsers - it would be great if PEPC could help solve that
16:27:12 <dom> Jan-Ivar: +1 to improving device selection (possibly making enumerateDevices less important)
16:27:18 <dom> ... but maybe that's longer term
16:27:56 <dom> youenn: I'm thinking short term; is <usermedia> starting capture immediately? is it only giving permission for a potential later capture? how does it relate to device selection?
16:28:09 <dom> jan-ivar: my perspective is that it should be equivalent to a getUserMedia() call
16:28:38 <dom> youenn: so equivalent to a synchronous single-click getUserMedia
16:29:00 <dom> ... would be good to compare how different UAs deal with these situations; Safari doesn't behave the same with or without user gesture
16:29:22 <dom> jan-ivar: another feedback we gave was a <microphone> / <camera> elements to avoid polymorphic buttons
16:29:40 <dom> guido: that doesn't allow for asking for both
16:30:04 <dom> jan-ivar: we could have <usermedia> for this, but making sure we keep types clear
16:30:08 <dom> guido: so 3 elements
16:30:22 <dom> jan-ivar: which is already the case, but hidden behind the type attribute
16:31:37 <dom> dom: we should discuss how to split the work - are there PEPC hooks that could help with this?
16:33:28 <dom> Minh: we are very open to whatever format to find creative solutions e.g. in a workshop, to fulfill needs both from users and app developers
16:34:00 <dom> Youenn: the closest effort we had was with the permission spec which had different integrations across different specs
16:34:13 <dom> ... e.g. media capture defines how the media capture permissions are defined/granted
16:34:22 <dom> ... I wonder if we could do the same here
16:35:22 <dom> Minh: we're open to anything that helps coordination
16:35:38 <dom> Youenn: we should be OK from a charter perspective to have some of the work done in our group
16:38:29 <dom> Minh: today <usermedia> is in origin trial which isn't very comfortable; it would be great to find a way to reach an MVP to get some of it out of origin trial
16:39:05 <dom> Youenn: having one API ship in one browser before the spec is ready creates compat issues down the line
16:39:25 <dom> ... we can't commit to a specific schedule, but I'd be happy to support allocating WebRTC WG time for this
16:39:48 <dom> Jan-Ivar: +1 - happy to have seen positive changes to PEPC based on our engagement
16:41:31 <dom> Dom: +1 for being careful with interop - if you have a clear idea of what an MVP could look like, this could help prioritize the discussion of the WG
16:41:59 <dom> Minh: no clear description of this, but we could build a proposal with backwards compat in mind
16:42:13 <dom> Jan-Ivar: for me, an MVP would be buttons that can be used as toggles
16:42:23 <dom> ... we're flexible on styling if that helps with adoption
16:42:54 <dom> RESOLVED: Use Media Capture and Streams (or an extension of it) to provide a PEPC integration section as an anchor for further discussions
16:43:03 <hta> hta has joined #webrtc
16:43:08 <dom> Present+ PeterT
16:43:09 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/3085 DataChannel close event
16:43:09 <dom> [slide 13]
16:44:02 <dom> [slide 14]
16:47:13 <dom> Harald: +1 to the general rule and the specific application
16:47:28 <dom> ... will this be done via a queued task or done synchronously?
16:47:49 <dom> Youenn: we should check what browsers do; I suspect we should queue a task
16:48:07 <dom> Jan-Ivar: +1 to aligning with implementations; not sure about agreeing on the general rule, but it sounds nice
16:48:43 <dom> dom: re general rule, maybe worth submitting it to the Design Principles repo?
16:48:52 <dom> Youenn: we should check whether other specs have hit that pattern
16:48:57 <dom> ... I'll file an issue
16:49:17 <dom> RESOLVED: Align close event spec with Firefox/Chromium implementation
16:49:33 <dom> Topic: -> https://github.com/w3c/mediacapture-transform/issues/116 Mediacapture-transform track transfer
16:49:33 <dom> Subtopic: Developed feedback
16:49:33 <dom> [slide 17]
16:50:29 <dom> [slide 18]
16:51:54 <dom> [slide 19]
16:53:53 <dom> [slide 20]
16:55:04 <hta> Side remark: I checked the Chrome code, and there's a dispatch (PostTask) inbetween the pc.Close() and the firing of the event.
16:55:22 <dom> [slide 21]
16:55:44 <dom> [slide 22]
16:57:07 <dom> [slide 23]
16:59:26 <dom> Youenn: re synchronous stopping of track - is it in the case you have a track for camera which you're transforming (e.g. background blur), if you're stopping one, you have to stop the other synchronously?
17:00:19 <dom> Guido: the shim is meant to hide the complexity of managing the track, but turns  synchronous stop() operation into an asynchronous one
17:00:30 <dom> ... e.g. makes it harder to reason about whether all the tracks have been stopped
17:00:50 <dom> Youenn: so this isn't about having frames leaking
17:01:34 <dom> Guido: this may create situations where a track is stopped in one module but not in another
17:02:21 <dom> Youenn: when a track is stopped, there can be frames that can be processed after the track was stopped
17:02:37 <dom> ... I'm hearing with postMessage, there is more latency than with a native implementation
17:03:34 <dom> Guido: after stop(), expect for sink-in-flights in another thread, no further frames will be delivered to a sink; esp. since there is no guarantee a postMessage will always be delivered
17:03:50 <dom> ... this level of complexity should be fixed in the API
17:04:41 <dom> jan-ivar: I hope people don't rely on the synchronicity of stop() to stop frames being processed if they're already in a queue
17:05:13 <dom> Guido: the problem of synchronicity also applies to .enabled
17:05:25 <dom> jan-ivar: stop() is synchronous on the media thread, not on the main thread
17:05:55 <dom> ... with workers, there are 3 ways to get things to and from a worker: postMessage, transfered streams, rtcscripttransform
17:06:14 <dom> ... we as a WG have invented one API and are talking about invending a second one
17:07:05 <dom> Guido: this isn't a first for media processing
17:08:02 <dom> ... given the feedback from developers, it seems clear to me that this is something we should fix
17:08:34 <dom> jan-ivar: the shim can be fixed to communicate to multiple clones
17:09:04 <dom> Youenn: I can understand the value for very complex applications to avoid replacing a track with another one
17:09:22 <dom> ... although web apps have to deal with replacing tracks dynamically in case of capture failure
17:10:15 <dom> Guido: workers are targeted at complex applications in the first place; the fix is easy, we should fix it
17:12:11 <caribou> q?
17:13:14 <dom> dom: we've asked for feedback, we should listen to that feedback
17:14:48 <dom> jan-ivar: we are listening and it's important to reach consensus for interop, so we're willing to compromise on this
17:15:00 <dom> Subtopic: -> https://github.com/w3c/mediacapture-transform/issues/116#issuecomment-3602951782 MediaStreamTrackHandle
17:15:00 <dom> [slide 26]
17:17:00 <dom> [slide 27]
17:18:08 <dom> [slide 28]
17:20:20 <dom> [slide 29]
17:21:16 <dom> [slide 30]
17:22:35 <dom> [slide 31]
17:24:07 <dom> [slide 32]
17:24:30 <dom> Guido: worth it, yes; good enough, maybe
17:24:44 <dom> ... this would address the developers concerns I highlighted
17:25:06 <dom> ... so definitely in the right direction
17:25:37 <dom> ... I think GC-handling needs more discussion
17:26:42 <dom> ... I think the ScriptTransform approach is better as it doesn't have to expose a new object and allows for more optimizations
17:27:03 <dom> ... and it shouldn't be hard to replicate in other browsers already implementing encoded transform
17:27:24 <dom> ... we could compromise to that approach for interop
17:27:39 <dom> ... for processor
17:28:12 <dom> Youenn: so you would be OK with implementing Generator and Processor in worker, and track transfer
17:28:17 <dom> Guido: eventually
17:28:39 <dom> Harald: a problem with MST transfer is the size of the surface it exposes in worker
17:29:07 <dom> ... MSTHandle exposes a bit more surface than EncodedTransform-lookalike (which exposes only streams)
17:29:24 <dom> ... whereas MSTHandle might need some more (e.g. closed state?)
17:30:11 <dom> ... so slightly more complex, more API surface to manage (e.g. lifecyle of the object)
17:31:14 <dom> Jan-Ivar: this feels redundant, but it's the cleanest solution among the proposed ones
17:31:49 <dom> ... I believe we would be OK with implementing it, but I'll have to check with the team
17:32:22 <dom> ... will there be source support for handle? I wouldn't support this; it's important that track transfer be supported
17:33:41 <dom> Youenn: so PR to mediacapture-transform? should we do a CfC?
17:33:53 <dom> Guido: we should include audio in such a CfC
17:34:11 <dom> RESOLVED: start a PR to add MediaStreamTrackHandle to mediacapture-transform as a basis for a future CfC
17:34:21 <dom> Topic: -> https://github.com/w3c/mediacapture-transform/issues/29 Mediacapture-transform for audio
17:34:21 <dom> Subtopic: MediaStreamTrackProcessor for Audio
17:34:21 <dom> [slide 35]
17:35:27 <dom> [slide 36]
17:38:33 <dom> [slide 37]
17:38:36 <dom> [slide 38]
17:38:39 <dom> [slide 39]
17:39:59 <dom> [slide 40]
17:41:39 <dom> [slide 41]
17:43:36 <dom> [slide 42]
17:43:37 <dom> [slide 43]
17:45:01 <dom> [slide 44]
17:46:05 <dom> [slide 45]
17:47:30 <dom> [slide 46]
17:49:39 <dom> Youenn: thanks for the presentation and prototyping; for mstp, we could improve performance but there may be performance penalty for some browsers, and web developers can reasonably want something simpler
17:49:55 <dom> ... don't see a big drawback to exposing audio like we're doing for video frames
17:50:20 <dom> ... the feedback from Zoom seems to match a pretty natural pattern that the API should allow
17:51:06 <dom> ... for MSTG, it's useful for a sink for a PC, but a footgun for other sinks (e.g. recorder, video/audio elements)
17:51:24 <dom> ... this is problematic, but I'm not sure that MSTG is the right place to fix this
17:52:23 <dom> Guido: re PC as a sink - any other network-based API would have the same characteristics
17:52:39 <dom> ... note that AudioWorklet is conversely harmful to use with PC
17:52:47 <dom> ... without good alternative
17:53:31 <dom> Youenn: this is work addressing, but we shouldn't limit ourselves to MSTG; we should ask the Audio WG if they have thoughts about how this should be addressed from an audio processing perspective
17:53:57 <dom> ... it could be that a different audio context would work
17:54:06 <dom> Guido: offlineaudiocontext is this, but doesn't have integration with MST
17:54:13 <dom> Youenn: definitely worth discussing the issue more
17:54:41 <dom> Jan-Ivar: thanks a lot for investigating this - were the measures done in Chrome?
17:55:00 <dom> Guido: the shim run on all browsers; we ran the native comparison in Chrome
17:55:31 <dom> Jan-Ivar: we'll want to look more into these; re timestamp, that's worth filing an issue on audio worklet
17:55:42 <dom> ... we'll need a bit more time on the measurements to build a position on our end
17:56:01 <dom> Harald: there is a good reason for a worklet not to have a timestamp - it's real-time/synchronous
17:56:39 <dom> Guido: a worklet is dealing with a rendering quantum, not necessarily a full audio sample with its timestamp
17:57:00 <dom> ... there could be a situation where a quantum corresponds to more than one timestamped sample
17:57:53 <dom> Jan-Ivar: I'll follow up on the github issue once we've analysed the measurements in Firefox
17:58:13 <dom> RRSAgent, draft minutes
17:58:14 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/09-webrtc-minutes.html dom
19:27:54 <Zakim> Zakim has left #webrtc