Meeting minutes
Recording: https://
Slideset: https://
WebRTC Extended Use Cases
Issue #94: Improvements for game pad input (Section 3.2.1)
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 #103: Feedback related to WebRTC-NV Low Latency Streaming Use Case
NV Low Latency use cases
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".
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 #116: Remove specific hardware reference (GPU)
Removing the "by utilizing the GPU" language.
Consensus on removing.
PR #117: Update Requirement N37
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 #120: Section 3.2.2: Add Requirements N13 and N16 (Bernard)
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 #121: Section 3.2.2: Clarify meaning of “low latency” (Bernard)
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 #119: Section 3.2: Streaming should not require user prompts without sending media.
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 #118: Clarify Game Streaming requirements (Section 3.2)
More game streaming requiremnts
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.
SetMetadata for redundant relay PCs.
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
Encoded Transform
Issue #188: Clarify why backpressure should be disabled
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
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.
Ice Controller API: ICE candidate pair selection and nomination
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.
deviceId in permissions.query()
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)