W3C

– DRAFT –
WebRTC October 2024 Meeting

15 October 2024

Attendees

Present
bernard, eladalon, guidou, hbos, hta, jib, orphis, pthatcher, sameer, youenn
Regrets
Dom
Chair
Bernard, Guido, Jan-Ivar
Scribe
hta

Meeting minutes

Recording: https://www.youtube.com/watch?v=leE2CUpeewc

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

jib: it's "setcodecpreferences" not "setcodecrequirements" - so proposal A is acceptable

orphis: proposal b might be better (fail early)

pthatcher: not clear on send / receive codec preferences

jib: might need language to clarify "it's input to negotiation".

jib: fallback (A) should be more user friendly than failure (B)

tim panton: it's going to be pretty rare, easier to let the user who does strange things work things out than footguns. Prefer A.

orphis: A is a silent error, B is an explicit error.

RESOLUTION: Rough consensus on proposal A (fall back to "all supported codecs").

[Slide 15]

[Slide 17]

bernard: duration?

bernard: in favor of doing a PR.

youenn: this exercise needs to be done. <Not clear what is being proposed>

youenn: on the receiving side, we need the DecodedSource proposal, which doesn't exist yet.

jib: we need to solve this problem. worried about the different data semantics. Might be an alternative to use EncodedVideoChunk in webrtc transforms.

bernard: both audio and video?

hta: yes.

jib: is round-trip conversion lossless or lossy?

hta: it's lossy from RTC to EncodedVideoChunk

youennf: should consider sending encodedvideochunk + metadata to the encodedvideosource.

orphis: what happens if new fields are added in the video chunk?

hta: we will have to update both specs in tandem.

[Slide 21]

[Slide 22]

Encoder complexity control

[Slide 23]

bernard: both for audio and video?

bernard: this control exists for Opus.

youennf: don't know if the application can get enough information to use this API effectively.

hbos: much like the content-hint API.

tim panton: see an use for this when sending multiple streams of opus, for instance.

hta: we can use compute pressure as one signal

youennf: hope we have more signals than compute pressure

[[slide 26]

App control over ICE checks (restricted from previous version)

[Slide 28]

pthatcher: looks good, straightforward

[Slide 29]

sameer: ready to move to a PR.

[Slide 30]

future extensibility

[Slide 34]

[Slide 35]

[Slide 36]

[Slide 37]

[Slide 38]

[Slide 39]

pthatcher: at TPAC - asked about community group (CG) - some people interested in joining a CG that wouldn't join a WG

jib: would be good to keep it in the WG

jib: if someday we could polyfill RTPSender and RTPReceiver on top of RTPTransport, this would be something that we could get behind.

pthatcher: the hard part of polyfilling RTPReceiver is the jitter buffer.

[Slide 42]

[Slide 43]

[Slide 44]

[Slide 47]

[Slide 48]

[Slide 49]

proposal: go with #2

jib: what was wrong with what you proposed at tpac?

jib: not sure it's powerful enough to mitigate against remote control

[Slide 51]

eladalon: we can add a restricted list of events

eladalon: the TPAC proposals were clunky and unique on the web platform. This is more idiomatic.

jib: need to agree on the security level we are seeking.

youennf: look at ipad where pinch allows you to scroll & zoom at once.

youennf: could have an unified interface for both capture-wheel and set-zoom.

eladalon: don't understand why you'd want to merge these two very different user interactions.

eladalon: the demo works flawlessly with the trackpad.

jib: doesn't seem like tpac feedback has been incorporated.

eladalon: the minutes from tpac show a very different mood.

discussion....

youennf: capturewheel has a reasonable degree of consensus on the model, but has comments - will provide feedback within 1-2 weeks.

hta: capturewheel is ready to ship. we should concentrate on objections to setzoomlevel that show that there are security concerns are not mitigated.

youennf: we should consider whether reusing the direct forwarding mechanism is possible.

guidou: the setzoomlevel is interaction with an app-provided API that needs to work without a touch screen.

eladalon: note - don't look at the spec until end-of-day tomorrow.

youennf: need to file an issue with HTML - we want a stricter limit than transient activation, think we need HTML experts to chime in on this.

eladalon: the proposals #1 and #2 give stricter limitations than transient activiation (as you requested).

youennf: we want synchronous actcivation, not transient activation. html spec should define that.

eladalon: can you give me a timeline to come back with feedback?

jib / youennf: 2 weeks for feedback.

jib: limiting to click in the initial version seems good to me.

Summary of resolutions

  1. Rough consensus on proposal A (fall back to "all supported codecs").
Minutes manually created (not a transcript), formatted by scribe.perl version 235 (Thu Sep 26 22:53:03 2024 UTC).