- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 31 Jul 2023 15:14:51 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our WebRTC WG meeting on July 18 are available at:
https://www.w3.org/2023/07/18-webrtc-minutes.html
and copied as text below.
Thanks Harald for scribing!
Dom
WebRTC July 2023 meeting
[2]Agenda.
[2] https://www.w3.org/2011/04/webrtc/wiki/July_18_2023
Attendees
Present
Bernard, bhavani, fippo, guidou, hta, jib, palak,
pthatcher, Youenn
Regrets
Dom
Chair
Bernard, Harald, Jan-Ivar
Scribe
hta
Contents
1. [3]WebRTC Extended Use Cases
1. [4]Issue 94: Improvements for game pad input (Section
3.2.1)
2. [5]Issue #103: Feedback related to WebRTC-NV Low
Latency Streaming Use Case
3. [6]PR #116: Remove specific hardware reference (GPU)
4. [7]PR #117: Update Requirement N37
5. [8]PR #120: Section 3.2.2: Add Requirements N13 and
N16 (Bernard)
6. [9]PR #121: Section 3.2.2: Clarify meaning of “low
latency” (Bernard)
7. [10]PR #119: Section 3.2: Streaming should not require
user prompts without sending media.
8. [11]PR #118: Clarify Game Streaming requirements
(Section 3.2)
2. [12]SetMetadata for redundant relay PCs.
3. [13]Encoded Transform
1. [14]Issue #188: Clarify why backpressure should be
disabled
4. [15]Ice Controller API: ICE candidate pair selection and
nomination
5. [16]deviceId in permissions.query()
6. [17]Wrapup
7. [18]Summary of action items
8. [19]Summary of resolutions
Meeting minutes
Slideset: [20]https://lists.w3.org/Archives/Public/www-archive/
2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf
[20]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf
[21]WebRTC Extended Use Cases
[21] https://github.com/w3c/webrtc-nv-use-cases
Issue 94: Improvements for game pad input (Section 3.2.1)
[22][Slide 15]
[22]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=15
Bernard: Is gamepad input specification stalled?
… do we need it?
Youenn: sees no relationship
RESOLUTION: Send an email to the gamepad people and ask what's
going on, but do not change document.
Issue [23]#103: Feedback related to WebRTC-NV Low Latency Streaming
Use Case
[23] https://github.com/w3c/webrtc-nv-use-cases/issues/103
[24][Slide 16]
[24]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=16
NV Low Latency use cases
[25][Slide 17]
[25]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=17
Need to make some basic statements on how requirements are
written.
hta: would prefer to have issues and API proposals link to use
cases, not the other way round.
… demonstrating that it is possible to satisfy a performance
requirement is possible.
jib: agree that pointers should be to use cases, not from them.
jib: prefer to think of "low latency streaming" as "high
latency WebRTC".
jib: "streaming" needs definition, not just "low latency".
[26][Slide 19]
[26]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=19
What do we do about aspirations?
jib: use cases need to be something the WG commits to solving.
youenn: if it is not actionable, it is not worth having in the
document.
hta: aspirations should be there, fantasies should not be.
Finding the dividing line is hard.
PR [27]#116: Remove specific hardware reference (GPU)
[27] https://github.com/w3c/webrtc-nv-use-cases/issues/116
[28][Slide 20]
[28]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=20
Removing the "by utilizing the GPU" language.
Consensus on removing.
PR [29]#117: Update Requirement N37
[29] https://github.com/w3c/webrtc-nv-use-cases/issues/117
[30][Slide 21]
[30]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=21
Redirect N37 from "high resolution and frame rate" to "hardware
support"
jib: not sure - the new text seems different from the old one
bernard: lots of the stuff done (on zero-copy) has been done
outside this WG
PR [31]#120: Section 3.2.2: Add Requirements N13 and N16 (Bernard)
[31] https://github.com/w3c/webrtc-nv-use-cases/issues/120
[32][Slide 22]
[32]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=22
New requirements on datachannel in workers
jib: we don't have a proposal for service workers
hta: problem that N13/N16 presupposes datachannels
youenn: n13 and n16 are already supported by webrtc-extension
proposals
PR [33]#121: Section 3.2.2: Clarify meaning of “low latency”
(Bernard)
[33] https://github.com/w3c/webrtc-nv-use-cases/issues/121
[34][Slide 23]
[34]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=23
Suggests breaking <1s and <500ms into separate use cases. N39
for RTP fanout.
bernard: Low (not ultra low) supports DRM. punt decisions on
this to next time.
PR [35]#119: Section 3.2: Streaming should not require user prompts
without sending media.
[35] https://github.com/w3c/webrtc-nv-use-cases/issues/119
[36][Slide 25]
[36]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=25
Should not need permission prompts in receive-only.
youenn: If we don't need the ICE mode 1, N36 is already
satisfied.
jib: UAs shouldn't be forbidden to put up prompts. Fixing the
ICE problem is a good thing, but requirement should then state
that.
fippo: decoder implementation is also gated in the same way.
ACTION: jib to suggest better language.
PR [37]#118: Clarify Game Streaming requirements (Section 3.2)
[37] https://github.com/w3c/webrtc-nv-use-cases/issues/118
More game streaming requiremnts
[38][Slide 26]
[38]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=26
[39][Slide 27]
[39]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=27
jib: not clear about N49 (RPSI)
bernard: do we just need to support RPSI? No new API?
fippo: For N50 we have interval configuration already (but not
an API)
bhavani: RPSI or alt-ref would satisfy N48 without corruption
… are there multiple mechanisms?
bernarda: more discussion needed. Also about what is IETF and
what is W3C.
[40]SetMetadata for redundant relay PCs.
[40] https://github.com/w3c/webrtc-encoded-transform/issues/162
[41][Slide 31]
[41]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=31
[42][Slide 32]
[42]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=32
[43][Slide 33]
[43]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=33
[44][Slide 34]
[44]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=34
[45][Slide 35]
[45]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=35
[46][Slide 38]
[46]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=38
[47][Slide 39]
[47]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=39
[48][Slide 40]
[48]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=40
pthatcher: should we be able to set the SSRC?
presenter: no
youenn: current model is a transform - depends on reader/writer
relationship. That's a change we should discuss first.
… could achieve the same results by using WebCodecs
… plus jitter buffer plus canvas
palak: ack that it is not allowed in the spec
guidou: don't see that it is a problem to pass the frame.
jib: appreciate the use case, thinks the present proposed
solution is a bit problematic (relay between PCs)
jib: also want better alignment on video frames with webcodecs
hta: all the one way use cases demand breaking up the "one PC"
restrictions.
jib: february discussion has not achieved consensus on the one
way use cases.
bernard: discussion will continue on github
[49]Encoded Transform
[49] https://github.com/w3c/webrtc-encoded-transform
Issue [50]#188: Clarify why backpressure should be disabled
[50] https://github.com/w3c/webrtc-encoded-transform/issues/188
[51][Slide 43]
[51]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=43
youenn: webtransport wg had feedback on whether backpressure
should be visible.
… backpressure is good when we don't want to accumulate frames
… backpressure is JS-visible
… if we were using websockets, backpressure would be the only
thing available
… in our model, UA adaptation from network to encoder will
handle the slowdown
[52][Slide 46]
[52]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=46
youenn: transform will know if it is too slow
… proposal to go to +inf will not change what implementations
actually do
bernarda: trying to understand implications in terms of
webtransport - would it make sense to have backpressure on
reliable?
youenn: yes, maybe.
hta: need a better mechanism (explicit feedback). This change
is editorial, so basically not a problem.
youenn: welcome better solutions.
[53]Ice Controller API: ICE candidate pair selection and nomination
[53] https://github.com/w3c/webrtc-extensions/issues/171
[54][Slide 49]
[54]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=49
[55][Slide 50]
[55]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=50
[56][Slide 51]
[56]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=51
Suggest RFC 8445 escape clause - "send data on any candidate
pair, don't ever nominate"
pthatcher: like the idea :-) don't think we need to suppress
the nomination.
hta: with trickle ice and no end-of-candidates, we are not
reaching completed anyway. this might be easier than you think.
jib: maybe this needs to be IETF material. need to query people
who are presently on vactaion.
Discussion will continue on github.
[57][Slide 53]
[57]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=53
[58]deviceId in permissions.query()
[58] https://github.com/w3c/mediacapture-main/issues/965
[59][Slide 54]
[59]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=54
[60][Slide 55]
[60]
https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0004/WEBRTCWG-2023-07-18.pdf#page=55
hta: I am in favor of removing it - spec simpler
jib: will do only camera & microphone at first. Seems to have
consensus.
Wrapup
hta: Consensus on removing GPU language and removing
permissions.query(id)
Summary of action items
1. [61]jib to suggest better language.
Summary of resolutions
1. [62]Send an email to the gamepad people and ask what's
going on, but do not change document.
Received on Monday, 31 July 2023 13:14:54 UTC