– DRAFT –
WebRTC February 2025 meeting

Recording: https://youtu.be/vxKH7pYWczE

Slideset: https://docs.google.com/presentation/d/1XHPL-hiWXlra2bWDJHHkZmSGrx3Y97xGcEv43mnwIpU/ (archived PDF copy)

Media Capture and Streams

Issue #1020 What is the order of events being track clones?

[Slide 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 #1028 Revisit and document getUserMedia() track order

[Slide 13]

[Slide 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 #1027 How to interact with a device without a fixed capability?

[Slide 15]

<scribe> Proposal: Remove the sentence that says capabilities are effectively constant.

<scribe> Guido: Support.

<scribe> Harald: Support.

RESOLUTION: Prepare PR.

Webrtc Stats

Issue #789 Do not expose unknown usernameFragment to stats.

[Slide 16]

<scribe> Proposal: Merge PR #795

<scribe> Jan-Ivar: Support

<scribe> Harald: Should prevent people from reading these fragments. No idea how to resolve the web compat issue #601. In general, support the issue.

RESOLUTION: Support, review the PR again.

#794 Add PSNR

[Slide 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.

Captured Surface Control

Jan-Ivar's vision

[Slide 20]

[Slide 21]

<scribe> Issue #69

[Slide 22]

<scribe> Issue #67

[Slide 23]

<scribe> Issue #45

[Slide 24]

[Slide 25]

[Slide 26]

[Slide 27]

[Slide 28]

[Slide 29]

[Slide 30]

[Slide 31]

Elad's vision

[Slide 33]

[Slide 34]

[Slide 35]

[Slide 36]

[Slide 37]

[Slide 38]

[Slide 39]

<scribe> Issue #45

[Slide 41]

<scribe> Issue #67

[Slide 42]

<scribe> Issue #69

[Slide 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.