We’ve moved to https://meet.google.com/imp-xxhb-rjd
W3C WebRTC
WG Meeting
May 17, 2022
8 AM - 10 AM
2
Chairs: Bernard Aboba
Harald Alvestrand
Jan-Ivar Bruaroey
Meeting URL: https://meet.google.com/imp-xxhb-rjd
W3C WG IPR Policy
3
Welcome!
4
5
About this Virtual Meeting
6
W3C Code of Conduct
7
Virtual Interim Meeting Tips
This session is (still) being recorded
8
Understanding Document Status
9
Issues for Discussion Today
Time control:
10
WebRTC-Extensions & WebRTC-PC (Bernard)
Start Time: 08:10 AM
End Time: 08:50 AM
11
For Discussion Today
12
13
14
a=group:BUNDLE A B
a=group:BUNDLE C D
m=audio
a=cryptex
a=mid:A
m=audio
a=cryptex
a=mid:B
m=video
a=mid:C
m=video
a=mid:D
15
16
17
18
Issue 2735: webrtc-pc does not specify what level of support is required for RFC 7728 (RTP pause)
19
Issue 2735bis: webrtc-pc specifies using '~' in a=simulcast, but does not support RFC 7728 (RTP pause), which is a prerequisite
20
WebRTC-PC does not mention use of ‘~’
The Video Layer Allocation (VLA) RTP header extension indicates when simulcast layers are stopped (bandwidth = 0)
Doesn’t seem like there is a need for ~ in SDP
More WebRTC-PC Simulcast Issues
21
Issue 2722: sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]]
22
Issue 2722: sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]]
23
24
Issue 2723: The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed (cont’d
25
[BA] This doesn’t appear to be a contradiction to me, since the envelope is set via sRD(), not before.
Disallowing an answer to remove rids on a previously negotiated sender is probably not appropriate, since this would violate the simulcast spec, which requires the offerer to handle this case regardless of whether this is the initial negotiation or not. I think option 1 is the correct course of action here.
Issue 2723: The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed (cont’d)
26
Issue 2724: The language around setting a description appears to prohibit renegotiation of RIDs
27
Issue 2724: The language around setting a description appears to prohibit renegotiation of RIDs (cont’d)
28
Issue 2724: The language around setting a description appears to prohibit renegotiation of RIDs (cont’d)
29
RFC 8853 “Using Simulcast in SDP and RTP Sessions”
a=simulcast:send 1;2,3 recv 4
30
RFC 8853 “Using Simulcast in SDP and RTP Sessions”
31
Discussion (End Time: 08:50 AM)
32
CaptureController (Jan-Ivar)
Start Time: 08:50 AM
End Time: 09:10 AM
33
#190 Conditional Focus
Recap: getDisplayMedia “enables the acquisition of a user's display”. It’s a tool.
But all browsers focus a window or tab upon capture, which assumes the use case is�traditional screen-sharing in a video conference (VC). This is too limiting for apps:
So where to put a focus control API? Why not the video track? Two reasons:
We’ve stepped out of media consumption to remote control. Need a higher level object
#57 .sendCaptureAction() misplaced
Similarly, track.sendCaptureAction, the API to send supported actions to the captured page, seems misplaced on the MediaStreamTrack. The reasons are the same:
We’ve stepped out of media consumption to remote control.
A higher level “controller” object seems needed, that is owned by the caller, isn't clonable or necessarily shared with every media consumer.
#12 .getCaptureHandle() misplaced?
BTW the same can be said for getCaptureHandle. The mediacapture-handle spec notes:
But Chrome has already shipped this, so this proposal focuses instead on conditional focus and actions at the moment, even though identity is mentioned in subsequent slides.
#12 CaptureController
The dedicated controller object: *
const controller = new CaptureController();
const stream = await navigator.mediaDevices.getDisplayMedia({controller});�
const {origin, handle} = controller; // identity #12
await controller.focus(); // Default is no focus when controller is added! #190
const actions = controller.getSupportedActions(); // actions #57
if (actions.includes("nextslide")) {
await controller.sendAction("nextslide");
}
* For illustrative purposes. The controller is associated 1←→1 upon gDM success, and may not be reassociated. Presence of the controller suppresses the focus that happens today. Without a controller, gDM would continue to focus for backwards compatibility. Apps may call focus() anytime ahead of gDM or right after it (upto 1 second after seems fine, but let’s iterate on details). focus() resolves after captured window or tab has focus or asap on monitors, but no earlier than gDM success. It rejects if gDM rejects. getSupportedActions() may be empty. Exclusions may apply. Limit one gDM per controller. Non-transferable. No cash value.
Discussion (End Time: 09:10 AM)
38
WebRTC-encoded-transform & Mediacapture-extensions (Youenn)
Start Time: 09:10 AM
End Time: 09:30 AM
39
PR 132: Make generateKeyFrame take a single RID or none. Resolve the promise with the frame timestamp
40
PR 132: Make generateKeyFrame take a single RID or none. Resolve the promise with the frame timestamp
Promise<undefined> generateKeyFrame(optional sequence <DOMString> rids);
Promise<unsigned long long> generateKeyFrame(optional DOMString rid);
return Promise.race(rids.map(rid => transformer.generateKeyFrame(rid)));
41
PR 61: Add support for background blur and configuration change event
42
PR 61: Add support for background blur and configuration change event
43
PR 61: Add support for background blur and configuration change event
const stream = await navigator.mediaDevices.getUserMedia({video: true});
const track = stream.getVideoTracks()[0];
track.onconfigurationchange = () => {
// enable/disable web application background blur
toggleBackgroundBlur(track, track.getSettings().backgroundBlur);
};
44
PR 59: Add powerEfficientPixelFormat constraint
45
Discussion (End Time: 9:30 AM)
46
Dynamic Source for Screensharing (Elad)
Start Time: 09:30 AM
End Time: 09:50 AM
47
Introduction
48
The Arduous Process of Changing Sources
49
Utopia
Alternatives exist.
Deployment is challenging.
50
Deployment Challenges
Source-changing is new.
Existing applications are not adapted.
Some applications can’t ever fully adapt.
Granted, some applications are agnostic of the captured content.
But not all.
51
Case Study #1
52
Case Study #2
53
Blame Attribution
54
Application
Solution
Let’s not guess what the application wants. Let it tell us.
55
dictionary DisplayMediaStreamConstraints {
bool sourceChangeSupported;
};
Discussion (End Time: 9:50 AM)
56
Wrapup and Next Steps
(End Time: 10:00 AM)
57
Thank you
Special thanks to:
WG Participants, Editors & Chairs
58