- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 26 Feb 2025 10:32:17 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi, The minutes of the WebRTC WG meeting held on February 18 are available at: https://www.w3.org/2025/02/18-webrtc-minutes.html (with video recording) Thanks Guido for taking notes! Dom WebRTC February 2025 meeting [2]Agenda. [2] https://www.w3.org/2011/04/webrtc/wiki/February_18_2025 Attendees Present Elad, Guido, Harald, Jan-Ivar, Philipp_Hancke Regrets Dom, Youenn Chair Guido, Jan-Ivar Scribe Guido Contents 1. [3]Media Capture and Streams 1. [4]Issue #1020 What is the order of events being track clones? 2. [5]Issue #1028 Revisit and document getUserMedia() track order 3. [6]Issue #1027 How to interact with a device without a fixed capability? 2. [7]Webrtc Stats 1. [8]Issue #789 Do not expose unknown usernameFragment to stats. 2. [9]#794 Add PSNR 3. [10]Captured Surface Control 1. [11]Jan-Ivar's vision 2. [12]Elad's vision 3. [13]Discussion 4. [14]Summary of resolutions Meeting minutes Recording: [15]https://youtu.be/vxKH7pYWczE [15] https://youtu.be/vxKH7pYWczE IFRAME: [16]https://www.youtube.com/embed/vxKH7pYWczE?enablejsapi=1&rel =0&modestbranding=1 [16] https://www.youtube.com/embed/vxKH7pYWczE?enablejsapi=1&rel=0&modestbranding=1 Slideset: [17]https://docs.google.com/presentation/d/ 1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/ ([18]archived PDF copy) [17] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/ [19]Media Capture and Streams [19] https://github.com/w3c/mediacapture-main/ Issue [20]#1020 What is the order of events being track clones? [20] https://github.com/w3c/mediacapture-main/issues/1020 [21][Slide 12] [21] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#12 <scribe> Proposed: force deterministic per thread. <scribe> Harald: Verify that this is compatible with existing applications. RESOLUTION: Prepare PR and WPT to ensure existing behavior matches proposal. Issue [22]#1028 Revisit and document getUserMedia() track order [22] https://github.com/w3c/mediacapture-main/issues/1028 [23][Slide 13] [23] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#13 [24][Slide 14] [24] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#14 <scribe> Proposed: Specify order of tracks returned by MST.getTracks() to conform with modern Infra which recommends ordered sets to match Firefox behavior. <scribe> Harald: Internally Chrome treats audio and video tracks separately for historical reasons, and I propose to keep it like that. <scribe> Philipp_Hancke: A problem is that addTrack/getTracks are used together. Propose to do what Chrome does. <scribe> Guido: Oppose this proposal since it is incompatible with existing implementations. Chrome <scribe> Philipp_Hancke: Developers can be confused by it. Is it a practical problem? RESOLUTION: No resolution. Try to get feedback from Safari. Issue [25]#1027 How to interact with a device without a fixed capability? [25] https://github.com/w3c/mediacapture-main/issues/1027 [26][Slide 15] [26] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#15 <scribe> Proposal: Remove the sentence that says capabilities are effectively constant. <scribe> Guido: Support. <scribe> Harald: Support. RESOLUTION: Prepare PR. [27]Webrtc Stats [27] https://github.com/w3c/webrtc-stats/ Issue [28]#789 Do not expose unknown usernameFragment to stats. [28] https://github.com/w3c/webrtc-stats/issues/789 [29][Slide 16] [29] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#16 <scribe> Proposal: Merge PR [30]#795 [30] https://github.com/w3c/webrtc-stats/issues/795 <scribe> Jan-Ivar: Support <scribe> Harald: Should prevent people from reading these fragments. No idea how to resolve the web compat issue [31]#601. In general, support the issue. [31] https://github.com/w3c/webrtc-stats/issues/601 RESOLUTION: Support, review the PR again. [32]#794 Add PSNR [32] https://github.com/w3c/webrtc-stats/issues/794 [33][Slide 17] [33] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#17 <scribe> Expose peak signal-to-noise ratio <scribe> Implemented at Meta. Great results, but costly to compute per frame. <scribe> Jan-Ivar: I don't see any problem, but need to check internally at Firefox. <scribe> Harald: PSNR doesn't necessarily match human perception of quality. Big changes in PSNR correlate with big changes in quality. Small changes do not. [34]Captured Surface Control [34] https://github.com/w3c/mediacapture-surface-control/ Jan-Ivar's vision [35][Slide 20] [35] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#20 [36][Slide 21] [36] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#21 <scribe> Issue [37]#69 [37] https://github.com/w3c/mediacapture-surface-control/issues/69 [38][Slide 22] [38] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#22 <scribe> Issue [39]#67 [39] https://github.com/w3c/mediacapture-surface-control/issues/67 [40][Slide 23] [40] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#23 <scribe> Issue [41]#45 [41] https://github.com/w3c/mediacapture-surface-control/issues/45 [42][Slide 24] [42] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#24 [43][Slide 25] [43] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#25 [44][Slide 26] [44] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#26 [45][Slide 27] [45] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#27 [46][Slide 28] [46] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#28 [47][Slide 29] [47] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#29 [48][Slide 30] [48] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#30 [49][Slide 31] [49] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#31 Elad's vision [50][Slide 33] [50] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#33 [51][Slide 34] [51] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#34 [52][Slide 35] [52] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#35 [53][Slide 36] [53] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#36 [54][Slide 37] [54] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#37 [55][Slide 38] [55] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#38 [56][Slide 39] [56] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#39 <scribe> Issue [57]#45 [57] https://github.com/w3c/mediacapture-surface-control/issues/45 [58][Slide 41] [58] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#41 <scribe> Issue [59]#67 [59] https://github.com/w3c/mediacapture-surface-control/issues/67 [60][Slide 42] [60] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#42 <scribe> Issue [61]#69 [61] https://github.com/w3c/mediacapture-surface-control/issues/69 [62][Slide 43] [62] https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/#43 Discussion <scribe> Jan-Ivar: The existing APi is too powerful. <scribe> ... Requires the app to construct the illusion. <scribe> ... I don't think it's accurate to say the user interacts with the captured tab, but with a preview. <scribe> ... I prefer the Web developer to interact with the preview element. <scribe> ... The UA does calculations based on something the app can change. <scribe> ... Doesn't work with touch events. <scribe> [Disagreement about what the user is interacting with] <scribe> Jan-Ivar: interacting with a representation of the captured tab. <scribe> Elad: Interacting with the tab. Limited to one preview: straightforward extension in the future. <scribe> Jan-Ivar: Overlay: they're a problem in general, not just for this API. <scribe> Jan-Ivar: Let's discuss behaviors. Do we agree on behaviors? <scribe> Harald: I find the controller more natural. Implementation-wise the <scribe> Elad: Both API surfaces are equally powerful or powerless since they can implement the same limitations. RESOLUTION: Continue the debate on github to nail down the behavior. No input outside Jan-Ivar and Google in the meeting. Summary of resolutions 1. [63]Prepare PR and WPT to ensure existing behavior matches proposal. 2. [64]No resolution. Try to get feedback from Safari. 3. [65]Prepare PR. 4. [66]Support, review the PR again. 5. [67]Continue the debate on github to nail down the behavior. No input outside Jan-Ivar and Google in the meeting.
Received on Wednesday, 26 February 2025 09:32:19 UTC