- 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