- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 21 Feb 2024 08:49:04 +0100
- To: public-webrtc@w3.org
Hi,
The minutes of our Feb 2024 meeting held yesterday are available at:
https://www.w3.org/2024/02/20-webrtc-minutes.html
and copied as text below.
Dom
WebRTC February 2024 meeting
20 February 2024
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/February_20_2024
[3] https://www.w3.org/2024/02/20-webrtc-irc
Attendees
Present
Bernard, Carine, Dom, Elad, Fippo, Florent, Guido,
Harald, Jan-Ivar, PatrickRockhill, Peter, SunShin, TimP,
Youenn
Regrets
-
Chair
Bernard, HTA, Jan-Ivar
Scribe
dom
Contents
1. [4]WebRTC API
1. [5]Issues with receive-only codecs aboba/
hevc-webrtc#22
2. [6]Modify the codec description model to ease
describing changes #2925 #2935
3. [7]Should media capabilities influence what is exposed
in what is exposed in WebRTC offers and answers #2929
4. [8]Existing setCodecPreferences NOTE is wrong and
should be deleted #2933
5. [9]setCodecPreferences to deal with both send and recv
codecs #2939
2. [10]Screen Capture
1. [11]Issue triage and milestones
2. [12]Should we have a screenshare extension spec? #297
3. [13]Distinguish cancellations from absent OS
permissions #281
3. [14]MediaStream Recording
1. [15]Issue #202 Deprecate isTypeSupported
4. [16]Media Capture specs
1. [17]Issue triage and milestones of Media Capture and
Streams
2. [18]captureStream on OffscreenCanvas on
3. [19]Expose MediaStream in Workers
4. [20]How should MediaStreamTrack interact with BFCache?
5. [21]Add guidance for defining a new source of
MediaStreamTrack
5. [22]Summary of resolutions
Meeting minutes
Slideset: [23]https://lists.w3.org/Archives/Public/www-archive/
2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf
[23]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf
[24]WebRTC API
[24] https://github.com/w3c/webrtc-pc/
Issues with receive-only codecs [25]aboba/hevc-webrtc#22
[25] https://github.com/aboba/hevc-webrtc/issues/22
[26][Slide 11]
[26]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=11
Bernard: not a WebRTC issue - it came up in IETF AVTCORE wrt
receive-only codecs
Repository: [27]w3c/webrtc-pc
[27] https://github.com/w3c/webrtc-pc/
Modify the codec description model to ease describing changes
[28]#2925 [29]#2935
[28] https://github.com/w3c/webrtc-pc/issues/2925
[29] https://github.com/w3c/webrtc-pc/issues/2935
[30][Slide 12]
[30]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=12
[31][Slide 13]
[31]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=13
[32][Slide 14]
[32]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=14
Harald: is this a reasonable direction to go in?
Bernard: it is; the more I read, the more current situation
doesn't make sense, with too much unspecified, so this is a
good step forward
Jan-Ivar: overall it makes sense to add more details to it and
it will help having a more neutral baseline
… we need to keep track of fingerprinting concerns, but we
should be aligning with Media Capabilities in any case
… this looks like an improvement to me
Bernard: Media Capabilities doesn't have any way to look at
directionality except encoder/decoder - not sure if it's a good
match
Harald: you have to make two calls to media capabilities to
figure what you can send/received
bernard: so you're confident that encoder/decoder matches
send/receive? we should test it too
Harald: hearing no push back, we'll bring this as candidate to
merge at the editors meeting on Thursday
RESOLUTION: Bring [33]#2935 for merging to editors meeting
[33] https://github.com/w3c/webrtc-pc/issues/2935
Should media capabilities influence what is exposed in what is
exposed in WebRTC offers and answers [34]#2929
[34] https://github.com/w3c/webrtc-pc/issues/2929
[35][Slide 15]
[35]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=15
Youenn: more and more codecs get exposed on the Web and in
WebRTC
… for playback, media capabilities allow to control how much
information gets exposed to the web site
… for WebRTC, everything gets exposed via getCapabilities or
via SDP
… this is a fingerprinting issue, but also has an impact on the
number of allocated payload types
Harald: not all codecs get exposed, but they can be discovered
through setLocalDescription
Youenn: getCapabilities was initially designed to expose
everything supported, but it would be best to deprecate it
… can we move to use media capabilities as a replacement?
[36][Slide 16]
[36]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=16
Youenn: please chime in in [37]#2929 too
[37] https://github.com/w3c/webrtc-pc/issues/2929
Bernard: this makes sense for the simpler codecs à la VP8, VP9,
AV1, but e.g. HEVC raises weird situations
… say I query a common level that can be used for
encoding/decoding, how would this impact the whole offer/answer
negotiation?
Youenn: the idea would be that media capabilities would give
you WebRTC-specific data that could be plugged into the WebRTC
API
Bernard: but for these send-only or receive-only situations
across levels...
Youenn: SDP can't express all these situations
… this wouldn't be an improvement, but it doesn't make things
worse
… and at least, the web app would know what's not available
e.g. on the decoding side
TimP: I like this - it feels overdue
… the UA-to-UA disadvantage doesn't feel too serious
… the only issue I have is how precise the query would have to
be e.g. on which submode of which profile of a codec
… esp since UA are known to lie on some of these questions
Bernard: indeed, e.g. with H264 and 265
Youenn: this profile complexity would be in scope indeed
Harald: it's probably good to link webrtc and media
capabilities codec more closely
… Youenn has a PR to have media capabilities return a WebRTC
shape for doecs when queried
… to ensure it is inspectable and usable in WebRTC land
… it's good to have the default set of codecs be implementation
defined
… if we have a codec that is universally supported by a given
platform, it doesn't expose much fingerprinting surface to
expose it
Youenn: I'll revive the Media Capabilities proposal
Jan-Ivar: I'm also supportive; reducing fingerprinting surface
feels good, or at least reducing the list to a default list
Youenn: I'll work on an API proposal to tie Media Capabilities
and WebRTC - not sure yet if it's at the transceiver level,
please bring input on the issue
Harald: the codec model description will help as well for this
RESOLUTION: Proceed with proposal based on data-minimization
appraoch
RESOLUTION: Youenn to revive to Media Capabilities proposal
[38]media-capabilities#186
[38] https://github.com/w3c/media-capabilities/issues/186
Existing setCodecPreferences NOTE is wrong and should be deleted
[39]#2933
[39] https://github.com/w3c/webrtc-pc/issues/2933
[40][Slide 17]
[40]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=17
Fippo: if no objection, I'll bring a PR and a WPT test
Bernard: I agree it's extraneous
RESOLUTION: Fippo to submit a PR to remove note and a matching
WPT test
setCodecPreferences to deal with both send and recv codecs [41]#2939
[41] https://github.com/w3c/webrtc-pc/issues/2939
[42][Slide 18]
[42]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=18
[43][Slide 19]
[43]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=19
Bernard: I'm not sure this is entirely right given that it's
based on a JSEP paragraph that looks like it may be wrong
… sendrecv, sendonly, recvonly are 3 separate sets that
setCodecPreferences gives order to
… when changing direction, you're shifting to a different set
… it's not clear that the preferences can survive such a shift
Fippo: JSEP is confusing in that area
… it only talks about sendrecv, not the two other sets you're
alluding to
… it may be challenging to change this in terms of web
compatibility though
Jan-Ivar: regardless of what JSEP says, it would be desirable
if we kept sCP and direction change orthogonal
… this could be addressed by having a super list that is
filtered; if the filter ends up with an empty list, I'm a bit
wary about throwing, although this does feel like a mistake
Harald: changing direction after you have configured the codec
influences the set of codecs available
… if we require at least one sendrecv codec, we are safe, and
adding recvonly codecs is also safe
… this is a painful aspect of SDP - we should just admit
failure on the sendonly case and figure out the least painful
approach to deal with - maybe the last option
Fippo: if we have nothing in common, the regular approach would
be to reject the m-line, hence my preference for the 3rd option
… should we wait for a JSEP change in this space?
Bernard: I think we should come up with a proposal for JSEP
Fippo: OK, will bring this back at the next meeting after more
off-line discussions
[44]Screen Capture
[44] https://github.com/w3c/mediacapture-screen-share/
[45][Slide 22]
[45]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=22
Bernard: the WPT results for Screen Capture shows little
adoption for capture controller
Jan-Ivar: lots of green (getDisplayMedia works in all
browsers), the red parts are for the new capture controller API
… some red on iframe delegation, but the big difference is
capture controller
… it's not controversial, but hasn't been implemented outside
of Chrome yet
… it's not on FF's short term roadmap
Youenn: likewise for Safari
… we discussed a similar issue in Media WG - moving to CR would
still be beneficial
Jan-Ivar: +1
Issue triage and milestones
[46][Slide 24]
[46]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=24
Jan-Ivar: please chime in if you feel the assignment of issues
to milestones need adjustment
Should we have a screenshare extension spec? [47]#297
[47] https://github.com/w3c/mediacapture-screen-share/issues/297
[48][Slide 25]
[48]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=25
Youenn: I think it makes sense; in the Media WG, it was advised
that an extension spec is more complex and needs more work for
editors, but from the point of view for web developers, it
clarifies what is mature and what isn't
… if it's not useful for developers, then maybe a forever CR
would be a better model
TimP: do we think realistically it will help? are the 12
enhancements really blocking? are the 19 issues solvable in a
reasonable timeframe?
Jan-Ivar: I think it will help because the enhancement are real
additional features
Elad: +1 if it helps with making progress on issues
TimP: but do we thinkg the 19 CR issues are solvable in a
sensible timeframe?
Jan-Ivar: yes
Elad: there may also be issues that shouldn't be considered as
CR blocking
Jan-Ivar: getDisplayMedia mostly works, and separating what's
additional value would help
Bernard: +1 that they're addressable, and they would allow to
get e.g. more focus on privacy issues
Jan-Ivar: hearing mostly agreement this would be the right path
forward
Elad: when do we want to lock the list of issues as
CR-blocking?
Jan-Ivar: I think we can start moving issues over to the new
repo right away, and move them back if needed
… and then we have to do the work to close the 19 issues
RESOLUTION: Create extensions repo for screen capture and move
issues related to new features there
Distinguish cancellations from absent OS permissions [49]#281
[49] https://github.com/w3c/mediacapture-screen-share/issues/281
[50][Slide 26]
[50]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=26
Elad: this is a problem worth solving; this sounds like a
possible solution, wonder if we could improve it
… i.e. the spec isn't explicit on this, would be useful to make
it so
… also not sure NotFoundError isn't the most explicit
expression
… e.g. we could define a new error with a more specific type
Jan-Ivar: in general, there is generally pushback against
defining new custom errors
… and prefer re-using existing DOM errors even if they're not a
perfect fit
… I'm not too concerned about this imperfect fit
Youenn: NotFoundError feels like a reasonable minimal API
already in use; in terms of ergonomics, I think it's ok as long
as the spec is very explicit about this interpretation of
NotFoundError
Jan-Ivar: +1 to making this explicit in the spec
Elad: can we make it that NotFoundError be restricted to this?
e.g. in a situation where constraints would limit shareable
surfaces?
Jan-Ivar: it sounds like NotFoundError would still be a
reasonable fit for that situation, but that feels like an edge
case
Elad: fair, we can leave that question aside
… could we still allow UA-dependent subclassing?
Dom: that would lead to non-interoperable behavior
Youenn: re OS permissions, I'm not sure that's a well-defined
concept for the platform
… we should check what's being used e.g. in HTML or Permissions
Jan-Ivar: maybe this is a clarification to bring to
mediacapture-screenshare on "no sources of type T are
available" with a parenthesis that describes these examples
Jan-Ivar: would we want to apply to this mic/cameras? knowing
that they could be distinguished from no hardware with
enumerateDevices()
Guido: for OS permissions in camera/mic, we use notallowederror
with a different message
Elad: enumerateDevices() isn't 100% robust to make the
distinction given that users can plug/unplug devices
RESOLUTION: Move forward with a PR to clarify that
NotFoundError would apply for OS permissions in screen-capture
Jan-Ivar: I'll file an issue for a follow up discussion on
mediacapture-main
Elad: aligning the two would be best (although not fully
required)
[51]MediaStream Recording
[51] https://github.com/w3c/mediacapture-record/
[52][Slide 29]
[52]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=29
Bernard: WPT shows tests with limited support
Youenn: Safari doesn't support webm recording; not sure about
mp4
dom: I don't think there are codecs requirements in recording -
if so, codec specific tests should be marked as optional
[53][Slide 30]
[53]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=30
Jan-Ivar: overall numbers are looking pretty good
Youenn: not sure why there are codec/format-specific tests e.g.
for stop()
[54][Slide 31]
[54]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=31
Bernard: I support this; WebCodecs is indeed the way forward
for many of the requested enhancements for recorder
[no objection raised to proceeding with that plan]
Issue [55]#202 Deprecate isTypeSupported
[55] https://github.com/w3c/mediacapture-record/issues/202
[56][Slide 32]
[56]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=32
Bernard: this could simply quote media capabilities spec
Jan-Ivar: we could return a fixed list as Youenn suggested
earlier in the webrtc case
… this would solve the privacy issue neatly here
Bernard: wfm
Youenn: +1
Dom: it needs to stay in the spec for web compat, but should be
described as returning fixed answers and its usage discouraged
RESOLUTION: Make isTypeSupported return a fixed list of answers
and mark it as deprecated
Media Capture specs
Issue triage and milestones of Media Capture and Streams
[57][Slide 35]
[57]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=35
Jan-Ivar: we would like to see more activity in this spec to
accelerate progress towards Rec
[58]captureStream on OffscreenCanvas on
[58] https://github.com/w3c/mediacapture-fromelement/issues/65
[59][Slide 37]
[59]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=37
Youenn: no objection - but feels like low priority, not sure
there is much web developer demand for this
Harald: offscreencavas has usages, not all of them in workers
… this isn't related to mediacapture-main though?
… the only relation is the availability on MediaStream on
workers
Jan-Ivar: yes, that's the next issue I wanted to discuss, since
answering yes to this would give an answer to this
Jan-Ivar: not hearing objection, nor much interest either
RESOLUTION: Supporting captureStream on OffscreenCanvas is
reasonable but low priority
[60]Expose MediaStream in Workers
[60] https://github.com/w3c/mediacapture-extensions/pull/26
[61][Slide 38]
[61]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=38
Jan-Ivar: not hearing objection on this either
Dom: (but not much excitement either)
RESOLUTION: Exposing MediaStream in workers is reasonable but
low priority
[62]How should MediaStreamTrack interact with BFCache?
[62] https://github.com/w3c/mediacapture-main/issues/974
[63][Slide 39]
[63]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=39
Youenn: +1 to this proposal; not just because that's Safari
current behavior, but also because it will help with getting
web sites handle device failure situations better
… would like us to be more proactive on pushing outreach for
this
Harald: I've had a lot of discussions on BF-cache in the
context of peerconnection where we're trying to make WebRTC
more BF-cache friendly
… This sounds nice, but I think I'll want to think this through
some more
Youenn: this is indeed also worth discussing for WebRTC-PC
Harald: let's keep discussing this in the issue, want to hear
from Guido
Guido: +1
Youenn: I'll file an issue in webrtc-pc on BF-cache
friendliness
[64]Add guidance for defining a new source of MediaStreamTrack
[64] https://github.com/w3c/mediacapture-main/pull/988
[65][Slide 40]
[65]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=40
Jan-Ivar: this PR adds clarifications to what muted and ended
for other sources of tracks
[66][Slide 41]
[66]
https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf#page=41
Guido: +1 on the generic guidance; the mic/camera language
needs more discussion
Youenn: proposed language sounds good to me; we should review
our source-defining specs to make sure they're consistent with
that guidance
Jan-Ivar: yes, let's file these issues before landing that PR
… will get that done before the next Editros meeting
RESOLUTION: Bring [67]#988 to editors meeting for merging after
having filed issues in source-defining specs
[67] https://github.com/w3c/mediacapture-main/issues/988
Summary of resolutions
1. [68]Bring #2935 for merging to editors meeting
2. [69]Proceed with proposal based on data-minimization
appraoch
3. [70]Youenn to revive to Media Capabilities proposal
media-capabilities#186
4. [71]Fippo to submit a PR to remove note and a matching WPT
test
5. [72]Create extensions repo for screen capture and move
issues related to new features there
6. [73]Move forward with a PR to clarify that NotFoundError
would apply for OS permissions in screen-capture
7. [74]Make isTypeSupported return a fixed list of answers and
mark it as deprecated
8. [75]Supporting captureStream on OffscreenCanvas is
reasonable but low priority
9. [76]Exposing MediaStream in workers is reasonable but low
priority
10. [77]Bring #988 to editors meeting for merging after having
filed issues in source-defining specs
Received on Wednesday, 21 February 2024 07:49:08 UTC