00:01:31 RRSAgent has joined #webrtc 00:01:36 logging to https://www.w3.org/2025/11/13-webrtc-irc 00:01:36 Zakim has joined #webrtc 00:01:36 RRSAgent, make log public 00:01:37 Meeting: WebRTC TPAC 2025 meeting - day 2 00:01:37 Agenda: https://www.w3.org/2011/04/webrtc/wiki/November_13_2025 00:01:37 Slideset: https://docs.google.com/presentation/d/1sd5zEnvlXO5Sk3ENQorUUIQiRz65sv0KZKxDMMYHM3I/edit 00:01:37 Chairs: Guido, Jan-Ivar, Youenn 00:01:37 Present: Guido, Dom, Jan-Ivar, Youenn, SUnShin, BrianBaldino, Carine, PeterT 00:02:33 Present+ Rik 00:02:52 Present- Jan-Ivar 00:03:09 Present+ Jan-Ivar 00:04:03 Lei_Zhao has joined #webrtc 00:04:09 Topic: -> https://github.com/w3c/webrtc-extensions/issues/124 WebRTC Event Log uploads with the Reporting API 00:04:09 [slide 49] 00:05:28 Present+ ErikS 00:05:35 [slide 50] 00:06:32 [slide 51] 00:07:55 [slide 52] 00:09:09 [slide 53] 00:10:58 [slide 54] 00:11:29 m-alkalbani has joined #webrtc 00:11:44 Present+ m-alkalbani 00:11:50 [slide 55] 00:12:01 Present+ Yoshihiko 00:13:28 q+ to ask about spec protocol buffers, alternative of a different reporting mime type 00:13:31 [slide 56] 00:14:59 [slide 57] 00:16:01 Present+ Nishita 00:16:04 q+ Jan-Ivar 00:16:29 ack me 00:16:29 dom, you wanted to ask about spec protocol buffers, alternative of a different reporting mime type 00:17:33 youenn: re protocol buffer, there are conversion algorithms to JSON we could reuse 00:17:46 dom: how well spec'd is the profocol buffer format? 00:17:56 guido: it would have to be part of that new spec, but it has been stable in libwebrtc 00:18:19 dom: rather than hacking the binary string into JSON, we could see if adding another format to the reporting API would be acceptable 00:19:13 Youenn: one use case for JSON is testing (weak), and exposing browser log through the web inspector - having it in JSON would make it easier 00:19:16 Present+ Harald 00:19:25 cabanier has joined #webrtc 00:19:34 present+ 00:19:56 Guido: the advantage of keeping the protocol buffer is the compatibility with existing native apps and tools 00:20:14 Jan-Ivar: mozilla's position on the reporting API is positive (although still behind a flag) 00:20:45 ... on the API shape, rather than 3 methods, could we add it as configuration option to PC? 00:21:10 Guido: for enabling, sounds good; it would still be good to keep stop/discard 00:23:03 dom: I'm not sure i understand the no-upload option 00:23:26 Guido: it's to use it in a local version 00:23:42 dom: but then that should be left to the developer tool rather the API 00:24:01 Harald: for additional methods, there could be a Log object that could expose the additional methods 00:24:13 dom: note if we have a boolean member, it can't default to true 00:24:31 Youenn: re content of event log, we should make sure privacy safety 00:24:50 ... compare it to existing information exposed today 00:25:01 ... maybe the asynchronous nature makes it better 00:25:17 ... we should ask a review from the PRivacy WG after having identified which new information is available 00:25:30 hta has joined #webrtc 00:25:33 Guido: I don't think there is anything new, except timing (which can also be detected by the app) 00:25:42 ... Chrome Privacy hasn't found issues atm 00:25:44 q? 00:25:56 Youenn: Binary format is worth discussing 00:26:05 ... any impact on performance? 00:26:19 Guido: not significant 00:26:27 dom: including on mobile? 00:26:44 Guido: don't expect so - native apps use it on mobile 00:26:59 Youenn: there may be value in allowing to discard some data in case perf is detected as problematic 00:27:28 .... can you share more about where this is already used? 00:27:45 Guido: it is in a Chrome extension API (which we're removing) 00:28:19 Present+ GabrielBrito 00:28:55 ack jan-ivar 00:29:34 jan-ivar: the other example of the reporting API feel more like smaller data set 00:29:50 ... are we sure a webrtc event log would be an adequate fit? 00:30:36 guido: these would be larger than typical reports, but given that they can be uploaded out of band, it shouldn't be a problem 00:31:05 RESOLVED: Overall support to explore this, with further discussion on privacy, performance and API shape 00:31:32 Guido: the API would be added to WebRTC extensions, and a separate spec for protocol buffers 00:31:44 Carine: any change we expect from Web Perf on reporting API? 00:31:52 Guido: we'll ask them to review the report spec 00:31:58 Topic: SFrame 00:31:58 [slide 60] 00:33:39 [slide 61] 00:35:23 [slide 62] 00:36:43 dom: type required vs default? 00:36:49 youenn: if we can converge on a default, sure 00:36:54 [slide 63] 00:37:36 [slide 64] 00:37:44 q+ jan-ivar 00:38:40 ack jan-ivar 00:39:38 i|[slide 60]|Subtopic: Improving SFrameTransform API 00:39:47 jan-ivar: LGTM 00:40:11 ... re default value, no strong opinion; we can always start with required, and see later for a default 00:40:17 q+ 00:40:21 ack hta 00:40:40 harald: the crypto API allows you to construct key from JS and manage keys that JS can't see 00:40:52 ... do we want to impose restrictions on which kind of key that can be used in this? 00:41:13 Youenn: the end goal would be if we have an MLS API, they would be integrated into this 00:41:31 ... even if the MLS API is added, it might be reasonable to keep JS-visible APIs in this 00:42:01 Harald: we could use the same trick as SRTP and derive a key from DTLS 00:42:12 ... this could even be the default 00:42:20 Youenn: this could be an option 00:42:43 ... there are sframe users that want control on key derivation, so we should probably support both approaches 00:43:29 ... These objects won't change the API key content (except if we use HArald's idea) 00:43:40 ... the web app will responsible for deriving keys, ideally using WebCrypto 00:43:55 ... there is already a spec to derive an sframe key from an MLS key 00:44:27 RESOLVED: rough consensus to proceed with the new proposed API shape, proceed with PR 00:44:43 Subtopic: SFrame + RTCRtpScriptTransform 00:44:45 [slide 65] 00:45:55 [slide 66] 00:47:21 kota has joined #webrtc 00:47:24 Youenn: I Think we should wait we get a request for this use case, this is mostly a proof of concept to evaluate feasability 00:47:30 q+ jan-ivar 00:47:35 Present+ kota 00:47:58 [slide 67] 00:48:26 q+ 00:49:14 Youenn: likewise, mostly looking at feasability, not planning to go there at this time 00:49:37 ack jan-ivar 00:50:13 jan-ivar: another approach might be to have a separate interface 00:50:32 Youenn: right, API shape can be discussed 00:50:50 hta: in a packet case, you'll have 4 or 5 packets input, and 1 frame out in the decoder 00:50:56 ... and vice versa for the encoder 00:51:22 Youenn: the packetizer is responsible for sending multiple packets 00:51:30 ... we're talking about an SFrame frame 00:52:13 ... on the receiver side, a frame would be the equivalent to a packet, send it to the depacketizer 00:52:25 hta: if we don't need the restriction we currently have, let's remove it 00:52:31 ... but I Like this overall direction 00:52:31 q? 00:52:33 ack hta 00:52:38 Topic: -> https://github.com/w3c/webrtc-encoded-transform/issues/211 Encoded Source API update 00:52:38 [slide 70] 00:54:14 [slide 71] 00:54:56 Present+ Kensaku 00:55:12 [slide 72] 00:55:58 [slide 73] 00:56:29 q+ PeterT 00:56:49 [slide 74] 00:57:34 [slide 75] 00:59:12 [slide 76] 00:59:49 [slide 77] 01:00:26 [slide 78] 01:00:49 [slide 79] 01:01:40 Present+ MarkusH 01:02:55 [slide 80] 01:03:09 Peter: this is great! esp the constructor 01:03:19 ... looking forward to the implementation 01:04:10 Youenn: we should probably not replicate the scripttransform api which has shown a bit problematic 01:04:22 ... (for the encodedsource constructor) 01:04:55 ... the encodedsource object in the worker has some APIs - we've discussed whether to have them in scripttransform 01:05:07 Guido: indeed, that's where they come from 01:05:18 Youenn: right - they might be worth factoring out in a mixin interface 01:05:35 Youenn: on the receiverside, there would be a jitter buffer tied to the peerconnection 01:05:48 ... would this be useful as a separate object from peerconnection 01:06:23 ... if so, what new API would the app be needed e.g. on setting the jitter buffer, if not too complex? 01:06:50 kota has joined #webrtc 01:06:55 ... re WebCodecs for rtcencodedsource objects - we discussed this in the joint meeting with media last year 01:07:04 ... maybe we should talk about this with them 01:07:19 ... this could be a constructor, transferable 01:07:25 ... either tomorrow, or later today 01:08:00 ... what do synchronous valid checks mean when enqueuing a frame? 01:08:14 Guido: some could be asynchronous since write is async anyway 01:08:30 ... this shouldn't make a difference 01:08:48 q+ jan-ivar 01:08:51 ack Peter 01:09:09 jan-ivar: where to file issues? 01:09:13 Guido: webrtc-extensions 01:09:18 ... or encoded-transform 01:10:06 Jan-Ivar: there are 3 ways to get something in a worker: postMessage, stream, rtctransform - this would be a 4th way 01:10:38 Guido: we could do something equivalent to transform, but since there are no properties, it's simpler to do the association directly; but we coudl emulate scripttransform 01:10:45 s/rtctransform/scripttransform 01:11:07 RESOLVED: rough consensus to make proposals in that direction 01:11:22 Topic: -> https://github.com/w3c/mediacapture-main/issues/1060 Camera intrinsics attributes 01:11:22 [slide 83] 01:11:40 Rik: (Meta, Oculus browser) 01:12:50 [slide 84] 01:14:21 q+ 01:14:36 Guido: a short explainer to explain why it's needed would be a good first step, with the various entries 01:14:50 Youenn: this should come to mediacapture-extensions 01:15:22 ... another entry point could be in MediaDeviceInfo for constant values 01:15:24 ack hta 01:15:50 hta: does this only make sense if the camera and the screen are locked together? 01:15:59 ... we also have pan/tilt/zoom 01:16:17 ... it seems a bit special-purpose only when you have a hardware-coupled camera 01:16:49 Rik: we could look at how android deal with pan/tilt/zoom 01:17:20 Jan-Ivar: I like the idea; MediaTrackSettings is part of the constrainable patterns 01:17:30 ... we need to understand the impact e.g. on getCapabilities 01:17:32 ack jan-ivar 01:18:06 ... maybe a bit more discussion on API shape 01:18:43 Rik: the sequences are fixed length, I'm not sure we can express in WebIDL 01:18:56 ... I can put more details in the explainer 01:19:39 youenn: if we don't want or need applyConstraints, then mediadeviceinfo feels like a better approach 01:20:54 Dom: worth doing the comparison of the two approaches in the explainer 01:21:22 ErikS: with pan/tilt/zoom, it changes the field of view 01:21:51 Dom: also worth addressing the explainer how it relates to pan/tilt/zoom in mediacapture-image 01:22:26 q+ 01:22:34 Youenn: overall, no objection in the direction 01:22:54 GabrielBrito has joined #webrtc 01:23:05 rik: this question applies to all other devices with a similar set up exposed to web developers 01:23:07 ack m-alkalbani 01:23:23 Topic: -> https://github.com/w3c/mediacapture-transform/issues/116 Mediacapture-transform and track transfer 01:23:24 [slide 86] 01:27:14 [slide 87] 01:29:01 [slide 88] 01:33:16 [slide 89] 01:33:20 [slide 90] 01:33:22 [slide 91] 01:34:24 MarkusH: what is the good use case for transfering the track to the worker? 01:34:58 jan-ivar: a track can be genreated from videocodecs, combine things 01:35:39 ... also want to avoid duplicate API that achieve the same things 01:36:24 Youenn: the usual way of doing exchanges between window and worker is postMessage 01:36:56 ... for datachannels, when we wanted to process things in the worker, there were 2 options: create a PC in the worker (feasible, but not done) 01:37:12 ... or transfer the channel to the worker - simpler and useful 01:37:38 ... you can use window to worker, or out of a process (e.g. via sharedworker) 01:37:49 ... for MST, it seems natural to re-use that pattern 01:38:30 ... we had received use cases from Google to have a track generated in an iframe to another cross-origin context, which can only be done via transfer 01:38:32 q? 01:38:47 ... which would be hard to do elsewhere 01:38:49 q+ 01:39:02 Guido: transfering from a window to a window is not the same as window to worker 01:39:08 q- 01:39:14 ... data channels are data objects 01:39:22 ... the objects with data is the stream, not the track 01:39:41 ... tracks are the control plane 01:40:01 ... forcing to move tracks to the worker to use the feature as it makes much more complicated 01:40:27 ... what we're proposing is to re-use a pattern we've used in the past 01:40:33 q+ 01:43:30 [discussing conformance of Chrome implementation with stream spec requirements] 01:44:16 q- 01:44:18 q+ 01:44:52 youenn: do we have signals of major customers saying they can't use the spec'd approach? 01:45:07 jan-ivar: the shim I provided should help with adoption 01:45:11 ack hta 01:45:24 hta: fixing the wrong model with a shim is not the right approach 01:46:10 jan-ivar: we're the only one with tight coupling with worker 01:46:15 guido: audio does it for worklet 01:46:58 dom: let's see if we can get developer signals 01:47:33 youenn: how is Google Meet adopting to the split situation? 01:47:37 MarkusH: I can checkout 01:47:51 RRSAgent, draft minutes 01:47:52 I have made the request to generate https://www.w3.org/2025/11/13-webrtc-minutes.html dom 02:46:05 s/Subtopic: SFrame + RTCRtpScriptTransform|Subtopic: -> https://github.com/w3c/webrtc-encoded-transform/issues/266 SFrame + RTCRtpScriptTransform 02:46:11 RRSAgent, draft minutes 02:46:13 I have made the request to generate https://www.w3.org/2025/11/13-webrtc-minutes.html dom 02:53:00 |[slide 60]| Related issues: https://github.com/w3c/webrtc-encoded-transform/issues/214 https://github.com/w3c/webrtc-encoded-transform/issues/283 https://github.com/w3c/webrtc-encoded-transform/issues/259 02:53:10 RRSAgent, draft minutes 02:53:12 I have made the request to generate https://www.w3.org/2025/11/13-webrtc-minutes.html dom 03:51:10 Zakim has left #webrtc