1 of 37

W3C WebRTC

WG Meeting

May 20, 2025

8 AM - 10 AM

​

​

1

Chairs: Jan-Ivar Bruaroey

Youenn Fablet

Guido Urdaneta

2 of 37

W3C WG IPR Policy

2

3 of 37

Welcome!

  • Welcome to the May 2025 interim meeting of the W3C WebRTC WG, at which we will cover:
    • ​
  • Future meetings:
    • June 17 2025
    • July 15 2025

​

3

4 of 37

About this Virtual Meeting

4

5 of 37

W3C Code of Conduct

  • This meeting operates under W3C Code of Ethics and Professional Conduct�
  • We're all passionate about improving WebRTC and the Web, but let's all keep the conversations cordial and professional

5

6 of 37

Virtual Interim Meeting Tips

This session is (still) being recorded

  • Click to get into the speaker queue.
  • Click to get out of the speaker queue.
  • Please wait for microphone access to be granted before speaking.
  • If you jump the speaker queue, you will be muted.
  • Please use headphones when speaking to avoid echo.
  • Please state your full name before speaking.
  • Poll mechanism may be used to gauge the “sense of the room”.

6

7 of 37

Understanding Document Status

  • Hosting within the W3C repo does not imply adoption by the WG.
    • WG adoption requires a Call for Adoption (CfA) on the mailing list.
  • Editor’s drafts do not represent WG consensus.
    • WG drafts do imply consensus, once they’re confirmed by a Call for Consensus (CfC) on the mailing list.
    • Possible to merge PRs that may lack consensus, if a note is attached indicating controversy.

7

8 of 37

Issues for Discussion Today

  • 08:10 - 08:25 AM Transient activation after getDisplayMedia (Elad)
  • 08:25 - 08:40 AM windowAudio (Johannes + Elad)
  • 08:40 - 08:55 AM MediaCapture-main (Youenn)
  • 08:55 - 09:20 AM MediaCapture-output (Youenn)
  • 09:20 - 09:50 AM Grab Bag (Jan-Ivar)
  • 09:50 - 10:00 AM Wrapup and Next Steps (Chairs)

Time control:

  • A warning will be given 2 minutes before time is up.
  • Once time has elapsed we will move on to the next item.

8

9 of 37

Transient activation after getDisplayMedia

Start Time: 08:10 AM

End Time: 08:25 AM

9

10 of 37

Reminder: Transient Activation

  • MDN describes it as “user is currently interacting with the page.”
  • When the user delivers a mouse-click or a keyboard key-press somewhere within the app, transient activation is conferred for a brief time.
    • How long depends on the implementation.
    • Chrome uses 5s atm.
  • Web APIs are often gated on this requirement. Examples include:

10

11 of 37

Today’s discussion

  • Not up for discussion:
    • getDisplayMedia requires transient activation.
    • That’s the status quo.
    • We are not seeking to change that.
  • Up for discussion:
    • What happens immediately after getDisplayMedia resolves.

11

12 of 37

Observations

  • When getDisplayMedia is called, the user is shown a UA prompt.
  • The user can take arbitrarily long to interact with that prompt.
  • The transient activation used to call gDM, even if not consumed, is liable to elapse while the user interacts with that prompt.

12

13 of 37

Room for Improvement

  • When starting screen-sharing, a context-aware Web app can serve the user by taking additional actions.
    • Start playing media the user preconfigured to share.
    • Go full-screen if the user is recording a video game or a presentation.
    • Trigger PiP (Picture-in-Picture).
  • Recall that if capturing another tab/window, the user might no longer be looking at the capturing Web app when capture starts.
  • Ideally, the user should not need to…
    • Alt-tab back to the video-conferencing app to trigger PiP.
    • Record themselves interacting with the recording studio app and then later edit that interaction out.

13

14 of 37

Proposal

14

New:

15 of 37

Discussion (End Time: 08:40)

  • ​

15

16 of 37

windowAudio (Johannes + Elad)

Start Time: 08:25 AM

End Time: 08:40 AM

16

17 of 37

getDisplayMedia(): Window audio hint

  • getDisplayMedia() is an API to capture a user’s display.�Could be either a tab, window or monitor.
  • Application may offer audio capture by setting an option {audio: true}.�Could be either tab, system, or application audio.
  • Some applications prefer to not capture system audio.��SystemAudioPreferenceEnum was added with

17

include

The application prefers that options to share system audio be offered to the user for monitor display surfaces.

exclude

The application prefers that options to share system audio not be offered to the user.

18 of 37

Window audio

  • Application or System audio?
  • Examples:�
    • If a video player is captured, likely the user only intended to share a clip with sound. �=> Application audio.�
    • If a user is recording themselves giving a lecture about music, they might be showing a PDF with sheet music while playing music through a music player. �=> System audio.

18

19 of 37

Window audio, continued

  • Core principle is that the user decides.
  • But, the user is often busy, so user agents aim to offer choices with reasonable defaults.
  • The Web application often has more context about what the user is doing and can give a hint to the user agent.

​

19

Mock of window audio setting.

20 of 37

Proposal

  • Add WindowAudioPreferenceEnum windowAudio to DisplayMediaStreamOptions where:

​

20

enum WindowAudioPreferenceEnum {

“application”,

“system”,

“exclude”

};

​

application

The application prefers that the option to share application audio is offered to the user for window display surfaces.

system

The application prefers that the option to share system audio is offered to the user for window display surfaces.

exclude

The application prefers that no options to share audio be offered to the user for window display surfaces.

21 of 37

Discussion (End Time: 08:40)

  • ​

21

22 of 37

MediaCapture-main

Start Time: 08:40 AM

End Time: 08:55 AM

22

23 of 37

Should a muted video track be allowed to deliver black frames to its sinks?

No interoperability for enabled=false video tracks

  • https://jsfiddle.net/6gkvsfc7
  • Chrome and Safari
    • HTMLVideoElement is receiving video tracks but is rendering black
      • Rvfc is called
      • HTMLVideoElement gets resized according track video frame size
  • Firefox
    • HTMLVideoElement is not receiving video tracks
      • Rvfc is not called
      • HTMLVideoElement size remains as is until track is no longer muted/disabled

23

24 of 37

Should a muted video track be allowed to deliver black frames to its sinks?

Proposal: align with Firefox behavior & clarify the specification

  • Sinks do not receive any video frame
  • Sinks are expected to react to the signals themselves
    • HTMLVideoElement is rendering black but no rvfc/no size change
      • To be clarified in mediacapture-main
    • RTCRtpSender sends one black frame per second
      • Already covered in webrtc-pc
    • MediaStreamTrackProcessor
      • Nothing to do
    • MediaRecorder?
      • Which frame rate to use

24

25 of 37

Discussion (End Time: 08:55)

  • ​

25

26 of 37

MediaCapture-output

Start Time: 08:55 AM

End Time: 09:20 AM

26

27 of 37

Setting tab-wide audio output

  • Current issues
  • Most web applications want to target a single speaker
    • Convenient to do the switch within a single call
    • Better align with iOS & Android�
  • API sets the default speaker
    • HTMLMediaElement.setSinkId can override this default speaker

27

28 of 37

Setting tab-wide audio output

  • Default speaker scope?
    • All media elements of the tab
      • Third-party iframes could change the default speaker of its top-level context
    • All media elements of the context and its children�
  • Current proposal
    • Only allow this API on the top level context until we reach consensus on the default speaker scope�
  • How to make progress?
    • And where: Media WG or WebRTC WG?

28

29 of 37

Discussion (End Time: 09:20)

  • ​

29

30 of 37

Grab Bag

Start Time: 09:20 AM

End Time: 09:50 AM

30

31 of 37

Grab bag for discussion today

  • webrtc-pc
    • Issue 3049: Validate an ICE server url is missing length check for username
    • Issue 3045: Inconsistent initialization of transceiver.receiver.track.getSettings()
  • mediacapture-main
    • Issue 1041: Clarify resizeMode: none ⊆ crop-and-scale

​

31

32 of 37

Issue 3049 / PR 3050: Validate an ICE server url is missing length check for username

PR:

​

​

​

�RFC 8489: "USERNAME is a variable-length value … MUST contain a UTF-8-encoded [RFC3629] sequence of fewer than 509 bytes and MUST have been processed using the OpaqueString profile [RFC8265]."

�RFC 8265: "A password MUST NOT be zero bytes in length."

​

Means:

  • {username: chars509, credential: "foo"} // InvalidAccessError
  • {username: "", credential: "foo"} // is valid
  • {username: "", credential: ""} // InvalidAccessError

33 of 37

Issue 3045: Inconsistent initialization of

transceiver.receiver.track.getSettings()

The Constrainable Pattern disallows uninitialized values: “A [[Settings]] internal slot, initialized to a Settings dictionary describing the currently active settings values for each constrainable property exposed, as explained under Settings, or an empty dictionary if it has none” [exposed]

​

MediaCapture-main

gives this guidance:

​

Proposal: Apply the�same to webrtc-pc:

​

> RTCPeerConnection().addTransceiver("video").receiver.track.getSettings()�

{ aspectRatio: 1.3333333333333333, frameRate: 30, height: 480, width: 640 }

​

​

34 of 37

Issue 1041 / PR 1042: Clarify resizeMode: none ⊆ crop-and-scale

A camera with one native capability of 640x480@30 and the constraint {resizeMode: {exact: "crop-and-scale"}} produces what? We want:

​

640x480@30 not 639x480@30

​

Intent: "none" is a filter. IOW,

native modes ⊆ crop-and-scale

​

Fix the input to SelectSettings

to reflect this. PR:

35 of 37

Discussion (End Time: 09:50)

  • ​

35

36 of 37

Wrapup and Next Steps

Start Time: 09:50 AM

End Time: 10:00 AM

36

37 of 37

Thank you

Special thanks to:

​

WG Participants, Editors & Chairs

37