- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 28 Jun 2023 09:52:41 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our meeting held yesterday (June 27) are available at:
https://www.w3.org/2023/06/27-webrtc-minutes.html
and copied as text below.
I'll add the link to the YouTube video once it's available.
Dom
WebRTC June 2023 meeting
27 June 2023
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/June_27_2023
[3] https://www.w3.org/2023/06/27-webrtc-irc
Attendees
Present
AlfredHeggestad, Bernard, Carine, ColinRead, Dom, Elad,
Fippo, Florent, FredericWang, Guido, Harald, Henrik,
Jan-Ivar, JaredSiskin, PatrickRochill, PeterThatcher,
Sameer, SunShin, TimP, Youenn
Regrets
-
Chair
Bernard, HTA, Jan-Ivar
Scribe
dom
Contents
1. [4]Mediacapture-screen-share
1. [5]Issue #268 Make CaptureController inherit from
EventTarget
2. [6]Issue #263 Improve upon
CaptureStartFocusBehavior.no-focus-change
3. [7]Issue #261 Allow apps to avoid riskier
display-surface types
2. [8]Requesting keyframes via setParameters (WebRTC
Extensions)
3. [9]WebRTC Extended Use Cases
1. [10]Remove Use Cases That Don’t Add New Req’ts PR #112
PR #113
2. [11]Process changes
4. [12]IceController
1. [13]Issue #166 PR #168 - prevent candidate pair
removal
2. [14]Issue #170 #171 - candidate pairs management
5. [15]Encoded Transform Codec Negotiation
6. [16]Summary of resolutions
Meeting minutes
Slideset: [17]https://lists.w3.org/Archives/Public/www-archive/
2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf
[17]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf
[18]Mediacapture-screen-share
[18] https://github.com/w3c/mediacapture-screen-share/
Issue [19]#268 Make CaptureController inherit from EventTarget
[19] https://github.com/w3c/mediacapture-screen-share/issues/268
[20][Slide 12]
[20]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=12
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 [21]#268
[21] https://github.com/w3c/mediacapture-screen-share/issues/268
Issue [22]#263 Improve upon
CaptureStartFocusBehavior.no-focus-change
[22] https://github.com/w3c/mediacapture-screen-share/issues/263
[23][Slide 13]
[23]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=13
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
[24][Slide 14]
[24]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=14
Elad: proposed to add a new value "focus-capturing-application"
and keep "no-focus-change" to be platform-independent, 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 [25]#261 Allow apps to avoid riskier display-surface types
[25] https://github.com/w3c/mediacapture-screen-share/issues/261
[26][Slide 15]
[26]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=15
[27][Slide 16]
[27]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=16
[28][Slide 17]
[28]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=17
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
[29]Requesting keyframes via setParameters (WebRTC Extensions)
[29] https://github.com/w3c/webrtc-extensions/pull/167
[30][Slide 20]
[30]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=20
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
[31]WebRTC Extended Use Cases
[31] https://github.com/w3c/webrtc-nv-use-cases/
[32][Slide 23]
[32]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=23
Remove Use Cases That Don’t Add New Req’ts PR [33]#112 PR [34]#113
[33] https://github.com/w3c/webrtc-nv-use-cases/issues/112
[34] https://github.com/w3c/webrtc-nv-use-cases/issues/113
[35][Slide 25]
[35]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=25
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
[36][Slide 26]
[36]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=26
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
[37][Slide 31]
[37]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=31
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: [38]w3c/webrtc-extensions
[38] https://github.com/w3c/webrtc-extensions/
Issue [39]#166 PR [40]#168 - prevent candidate pair removal
[39] https://github.com/w3c/webrtc-extensions/issues/166
[40] https://github.com/w3c/webrtc-extensions/issues/168
[41][Slide 34]
[41]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=34
Sameer: please keep feedback coming on [42]#168
[42] https://github.com/w3c/webrtc-extensions/issues/168
Issue [43]#170 [44]#171 - candidate pairs management
[43] https://github.com/w3c/webrtc-extensions/issues/170
[44] https://github.com/w3c/webrtc-extensions/issues/171
[45][Slide 37]
[45]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=37
[46][Slide 38]
[46]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=38
[47][Slide 39]
[47]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=39
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
[48]Encoded Transform Codec Negotiation
[48] https://github.com/w3c/webrtc-encoded-transform/issues/172
Repository: [49]w3c/webrtc-encoded-transform
[49] https://github.com/w3c/webrtc-encoded-transform
[50][Slide 42]
[50]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=42
[51][Slide 43]
[51]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=43
[52][Slide 44]
[52]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=44
[53][Slide 45]
[53]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=45
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
[54][Slide 46]
[54]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=46
Harald: I re-use mime types for packetization mode - in most
cases, you would want to use a simple packetization mode (not
H264)
[55][Slide 47]
[55]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=47
Harald: note the payload type uses out-of-range SDP payload
types
[56][Slide 48]
[56]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=48
[57][Slide 49]
[57]
https://lists.w3.org/Archives/Public/www-archive/2023Jun/att-0003/WEBRTCWG-2023-06-27.pdf#page=49
Harald: have filed PR [58]#186
[58] https://github.com/w3c/webrtc-encoded-transform/issues/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 [59]#186 with details to be discussed in
the PR
[59] https://github.com/w3c/webrtc-encoded-transform/issues/186
JIB: Youenn's comment on IETF?
Bernard: there is a proposed work item in front of the IESG in
this space (SKIP?)
Summary of resolutions
1. [60]merge PR for #268
2. [61]use second parameter with a similar but different
dictionary than WebCodecs, clarify promise doesn't wait for
the keyframe to resolve
3. [62]remove section 3.9
4. [63]remove ML use case section 3.7 #PR 113
5. [64]Adopt PR #186 with details to be discussed in the PR
Minutes manually created (not a transcript), formatted by
[65]scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).
[65] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 28 June 2023 07:52:46 UTC