Meeting minutes
Recording: https://
Slideset: https://
Mediacapture-screen-share 🎞︎
Issue #268 Make CaptureController inherit from EventTarget 🎞︎
Elad: I suggest making capturecontroller an eventTarget help making that object more useful - with a specific use case inspired by the screen capture mouse events
… can easily think of more use cases
[+1 from Harald, Henrik, Youenn]
JIB: LGTM
RESOLUTION: merge PR for #268
Issue #263 Improve upon CaptureStartFocusBehavior.no-focus-change 🎞︎
Elad: this was discussed in the past and we decided to let the app express a preference that the UA is free to take into account or ignore
… no-focus-change is ambiguous given Safari's model with MacOS windows picker
Elad: proposed to add a new value "focus-capturing-application" and keep "no-focus-change" to be platform-dependent, possibly to be deprecated in the future
youenn: I like "focus-capturing-application"; maybe we could already add a warning about "no-focus-change" that it will be deprecated (and leave it to implementations to figure out a deprecation schedule)
Elad: not sure if we want to commit to deprecate right away; will want to look at web compat
TimP: would support deprecating ASAP
Elad: right, need to consult data usage before committing
JIB: for other implementors, knowing whether we implement 2 or 3 values is important
… otherwise, we would have to throw on unrecognized values
Harald: if we have deployed code that uses this, the usual magic is to not break running code which would require some deprecation timeline
Youenn: would be best to state the direction in the spec clearly, knowing that implementations will need to adjust over time
TimP: I wonder if this could be solved by feature detection and ensure that only 2 are ever implemented in a given browser
JIB: this would be concerning for web compat
Elad: +1
… there may be value for "no-focus-change" in itself, e.g. for accessibility to reduce change
… I propose we start by adding "focus-capturing-application" and have a separate conversation on deprecation
[JIB: +1]
Youenn: +1, as long as we converge reasonably quickly
Issue #261 Allow apps to avoid riskier display-surface types 🎞︎
Youenn: dynamic changes might be tricky to manage - auto-pause might be a solution
… combined with the current preference
Elad: when the user is offered the current screen, they may not understand they shouldn't which can create bad user experience
… there isn't any hint to disable that
… monitorExclusion would follow the footsteps of selfBrowserSurface
Youenn: I think a preference would be better than a hard-set requirement
Elad: the intent is for this to be a hint to the UA that it could ignore
… in Chrome's case, it would remove the "monitor" option
Youenn: in MacOS, the user can dynamically change to the screen - this wouldn't under the control of the browser UI
… which would create inconsistencies
Elad: this would reduce the number of clicks in the Safari workflow
… the OS itself could choose not to expose the monitor with that hint
TimP: I like this in principle, but think it would be hard to expose it in a non-confusing way to users
… this will create unexpected variations for users from one meeting to another
Elad: this wouldn't be more confusing than shutting down abruptly an ongoing capture
TimP: still, users will ask "why can't i share my screen when I could on my previous call?"
Elad: the app doesn't have to use that hint if it finds it too hard to communicate to end users
JIB: the use case makes a lot of sense; I support this; while I dislike limiting user choice, sharing full screen is risky which makes me supportive
… what would be the default?
Bernard: we're running out of time
Elad: let's follow up on github
Requesting keyframes via setParameters (WebRTC Extensions) 🎞︎
Fippo: this proposal would rely on WebCodecs-defined WebIDL - how do we feel about this?
JIB: I like that proposal direction; not sure about the value of reusing WebCodecs IDL which may evolve in ways that wouldn't work for us
Fippo: true - that's already the case since there are codecs-specific fields already which we wouldn't want to import
Florent: we would still want to keep encoding options in sync with WebCodecs when they make sense
Youenn: WebCodecs is per frame when setParameters isn't - I prefer a separate dictionary, but keep the definition aligned with WebCodecs
JIB: if I specify false - what does that mean?
Fippo: you're not requesting keyframes
JIB: and setParameters() with no change but keyframe true, I get a keyframe?
Fippo: yes
JIB: a bit odd of an API, but it makes sense for synchronicity
Florent: setParameter is supposed to resolve the promise when all the params have been applied
… how would this sequenced with the keyframe?
Fippo: we can't know when a keyframe would be generated; and it gets more complex with several layers
… so we wouldn't wait for the keyframe to resolve the promise
Florent: SGTM
Fippo: I'll update the PR in that direction, with a similar but different object than WebCodecs
RESOLUTION: use second parameter with a similar but different dictionary than WebCodecs, clarify promise doesn't wait for the keyframe to resolve
WebRTC Extended Use Cases 🎞︎
Remove Use Cases That Don’t Add New Req’ts Pull Request #112 Pull Request #113 🎞︎
TimP: when this was raised, it was brought up this could be achieved with a JS library, which WHEP has kind of demonstrated
… unless anyone can think of a use case where UA assistance would be needed
… (although WHEP hasn't been implemented yet)
Bernard: in future meetings we would discuss streaming which relates to WHIP and WHEP as well
… in the meantime, this use case doesn't bring any requirement - any pushback on removing it?
TimP: the only reason would be to validate this is a valid usage of WebRTC
Bernard: the fact that WISH took this up kind of validates this (and they don't need our validation)
JIB: I support our use cases should only drive decisions in our WG
Dom: I think keeping track of edge usages is interesting, but I'm not sure the WG is equipped for that
… and this document should really focus on use cases that generate new requirements
Harald: not sure; but not strong objection either
RESOLUTION: remove section 3.9
Youenn: related to N22 - we should look at what we're defining in the WG
… the only thing we need to define is efficient access to a VideoFrame
Dom: remaining question for me is whether there are memory-copy reduction requirements the WebRTC WG would need to cover
Bernard: this is being worked on, but in the Media WG
TimP: yes, I think this has been overtaken by events (i.e. it is now available)
… I don't think there is anything left for us - even though clearly this is something that WebRTC supports
… ensuring proper integration with ML is definitely important, but maybe no longer in our scope
JIB: N22 is a superset requirement that satisfies funny hats & ML
Bernard: it doesn't really satisfy fully ML
JIB: I was going to suggest a requirement about "processing" rather than "manipulation"
Harald: I think the requirement was misguided in tying it to GPU
… not all media manipulation needs or benefits GPU
Bernard: typically audio doesn't go through GPU
… so N22 should be revised
RESOLUTION: remove ML use case section 3.7 #PR 113
Bernard: we'll also update N22 for funny hats
Process changes 🎞︎
TimP: how do we shape the doc moving forward? seeking guidance on the relationship between explainers and the use case docs? conversely, should we ensure API changes tie back to use cases?
Dom: a possibility would be to remove use cases & requirements that already have a home in a spec/explainer?
JIB: an explainer fulfills a different role - having early use cases remain useful
Dom: right, but they could be still be sequenced
JIB: maybe
Bernard: conversely, would we want to require use cases for new API proposals?
Dom: we already have a goal of having API proposals be accompanied by explainers that have fairly detailed use cases
TimP: then this document would be a queue of future use cases without backing proposals? This sounds workable
Harald: it often feels easier to focus on an explainer with a specific proposal than to get consensus on an addition to the use case doc
… or we need a lower bar of entry to the document
TimP: there are a bunch of developer requirements that are impossible to implement without getting implementers on board
IceController 🎞︎
Repository: w3c/
Issue #166 PR #168 - prevent candidate pair removal 🎞︎
Sameer: please keep feedback coming on #168
Issue #170 #171 - candidate pairs management 🎞︎
JIB: if you use a promise, would there also be an event?
Sameer: the event already exists, so it would have to be fired as well
JIB: with pruning and preventDefault, this could get awkward and footgunny
Sameer: prune() would not fire an event - it prunes it immediately without an event
JIB: we should be consistent; re promise, can it fail?
Sameer: in other additions we're considering, there is an event for deletion
… the only possible failure I can think of is pruning a candidate pair that doesn't exist
JIB: I meant fail async - input validation can be done sync
Sameer: can't think of anything of failure for prune()
… for setSelected(), there may be async failure cases depending on the implementation approach
Youenn: is it fine to prune the currently selected candidate pair? if we don't allow it, it would have to be async
Sameer: pruning the current selected pair is the equivalent of a pair going away for any other reason (e.g. network interface going down)
Youenn: but this could lead to situation of pruning the selected candidate pair without realizing it due to race conditions
… why does prune() take a sequence? is it for an optimization? (could use variadic arguments)
Sameer: indeed, that's to optimize it
TimP: +1 to allow for several pairs
… I'm slightly worried that the API isn't taking account the asymetry of control
Sameer: setSelected fails immediately if called on the controlled side
TimP: maybe other asymetricalities in the timing of things; maybe to discuss on a specific PR
Peter: I think we should allow the controlled side to override to set a selected pair, but it should be an explicit call
Sameer: that might make sense, indeed
… any thoughts selection by directly sending media vs doing an exchange?
JIB: I'm nervous that the ICE Transport is running async and with PC being a huge state machine - there could be a lot of races e.g. when considering ICE restart
… would these decisions be reversed by an ICE restart?
Sameer: I expect ICE restart would be a clean slate
JIB: I'll need to think more about potential races
TimP: re ICE round trip, it should happen, to the risk of messing up bandwidth estimation
Peter: wrt ICE restart - ICE restart is make-before-break, typically adding candidate pairs
… would newly added candidate pairs be able to override already selected pairs?
… I'm inclined the app should be in control
… There is no reason both sides would need to use the same pairs
… I would support sending media right away when selecting a pair; I don't see a good reason to wait for another roundtrip
Encoded Transform Codec Negotiation 🎞︎
Repository: w3c/
Bernard: what does it mean "not to know about it", or "to know about it"?
Harald: the UA has to know about the packetization mode
Bernard: so having a WebCodec decoder counts as "known"?
Harald: no, this is in the context of the WebRTC chain
Harald: I re-use mime types for packetization mode - in most cases, you would want to use a simple packetization mode (not H264)
Harald: note the payload type uses out-of-range SDP payload types
Harald: have filed PR #186
[youenn on the chat: My main question is on which IETF work would be needed here. payloadType setter on a frame seems fine, I am less sure about the other API.]
Harald: I don't think any IETF work is needed, as long as we recognize we would be using non-standardized mime type
… for packetization
JIB: this makes sense; I see there are pre-negotiation methods, then a negotiation would happen where the other side may reject a payload type
… would we need new APIs to set codecs?
Harald: I think we should align with what Florent is proposing
JIB: +1
TimP: much to my chagrin, I see the need to involve SDP in this
… how will we deal with scope rules of SDP, RTX, etc?
Harald: I haven't figured that out yet
… at the moment, we have a very imprecise surface for deciding what kind of protection features we want to turn on
… that's done through SDP munging, which is sad
… we should figure that out, and apply it to this case as well
… (deferring to a previously unsolved problem in other words)
JIB: there are only methods to add things, not remove; maybe this could be part of setConfiguration?
Harald: I thought about adding/removing - we're able to turn off codecs by removing them with setCodecs
… I prefer to focus on well-known needs, and small-scoped APIs rather than extending setConfiguration
Harald: any sentiment on whether we should adopt this?
[JIB: +1]
[Jared, Bernard, Guido: +1]
RESOLUTION: Adopt PR #186 with details to be discussed in the PR
JIB: Youenn's comment on IETF?
Bernard: there is a proposed work item in front of the IESG in this space (SKIP?)