1 of 33

W3C WebRTC

WG Meeting

April 22, 2025

8 AM - 10 AM

​

​

1

Chairs: Jan-Ivar Bruaroey

Youenn Fablet

Guido Urdaneta

2 of 33

W3C WG IPR Policy

2

3 of 33

Welcome!

  • Welcome to the April 2025 interim meeting of the W3C WebRTC WG, at which we will cover:
    • ​
  • Future meetings:
    • May 20, 2025

​

3

4 of 33

About this Virtual Meeting

4

5 of 33

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 33

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 33

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 33

Issues for Discussion Today

  • 08:10 - 08:50 AM MediaCapture-main
  • 08:50 - 09:30 AM WebRTC-encoded-transform
  • 09:30 - 09:50 AM SFrame
  • 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 33

MediaCapture-main

Start Time: 08:10 AM

End Time: 08:50 AM

9

10 of 33

MediaCapture-main

​

​

10

11 of 33

Issue #1019: What is the purpose of requiring a successful gUM call before enumerateDevices?

  • Privacy protection rule
    • navigator.mediaDevices.enumerateDevices used to be called by a lot of websites that would never do any capture�
  • This rule has web compatibility concerns
    • Some websites show device pickers when capture permission is `granted` before capture starts, Zoom for camera for instance�
  • Can we lower the compatibility concerns while preserving the privacy benefit?

11

12 of 33

Issue #1019: What is the purpose of requiring a successful gUM call before enumerateDevices?

  • Proposal
    • Expose camera devices if web page is granted camera permission and it is using microphone
    • Expose microphone devices if web page is granted microphone permission and it is using camera�
  • Privacy evaluation
    • Web site does not get more information except if actively capturing one device type�
  • Does it help compatibility?
    • Websites tend to eagerly request microphone access
    • It helps Zoom as it requests microphone access to render audio
    • May need evaluation on more affected websites (help?)�
  • Is this proposal good enough?

​

12

13 of 33

Issue #1035 - Support multiple echoCancellation modes

  • Different applications may want to use echo cancellation differently
  • Some applications want to cancel only remote participants, but not local audio
    • Suppose there is a music teacher and a student who communicate via peer connection
    • The student plays an instrument with some accompaniment played by the Web application or some other local application
    • This application on the student side wants echo cancellation to cancel audio from the teacher, but does not want to cancel the accompaniment
  • Some applications want to cancel everything
    • For privacy, an application would like to cancel everything, including screen readers

13

14 of 33

Issue #1035 - Support multiple echoCancellation modes

  • Proposal: support four values for echo cancellation
    • Private: cancel all audio
    • Remote: cancel only peer connections
    • Default: Let the UA decide what to cancel. Equivalent to current true
    • Off: Disable echo cancellation. Equivalent to current false

​

  • Possible implementation:
    • Introduce an EchoCancellationMode enum
    • Change the property to be (EchoCancellationMode or boolean)

14

15 of 33

Issue #1036 - HTMLVideoElement.currentTime is increasing differently on different UAs

  • Spec definition of currentTime���
  • https://jsfiddle.net/81yqcp9d/
    • Safari and Firefox have the same behavior: currentTime increments linearly with time
    • Chrome is incrementing currentTime when a new frame is retrieved
    • Real interop issue�
  • Can we align User Agents?
    • Should the spec be clearer?

​

15

Any non-negative integer. The initial value is 0 and the values increments linearly in real time whenever the element is potentially playing.

16 of 33

Discussion (End Time: 08:50)

  • ​

16

17 of 33

WebRTC-encoded-transform

Start Time: 08:50 AM

End Time: 09:30 AM

17

18 of 33

WebRTC-encoded-transform

​

18

19 of 33

Issue #230 - Clarification on "not processing video packets" requested

  • Second step of the `send request key frame algorithm`

��

  • Two interpretations (highlighted by WPT test)
    • A: Reject the promise in case of audio receiver
      • Safari
    • B: Reject the promise if not receiving video packets at the time the algorithm is executed
      • Firefox�
  • Can we align User Agents?
    • Should the spec be clearer?�

19

If depacketizer is not processing video packets, reject promise with InvalidStateError, abort these steps.

20 of 33

Issue #230 - Clarification on "not processing video packets" requested

  • Proposal
    • A: reject if part of audio receiver
    • Merge WPT test PR 51772
    • Make spec clearer

​

​

  • Rationale
    • A is the original intent
    • Step 2 check is synchronous, so it happens in the worker thread
      • No direct access to the transceiver state
      • Checking whether active will be racy anyway, it does not provide any guarantee to the web page that the request is sent to the network
      • WebRTC stats provide firCount�
  • We can discuss whether adding an in-parallel step to reject in case transceiver is inactive
    • As a follow-up

​

20

If depacketizer is part of an audio receiver, reject promise with InvalidStateError, abort these steps.

21 of 33

Issue #244 - Add audioLevel to RTCEncodedAudioFrameMetadata

  • audioLevel is currently exposed in RTCRtpContributingSource and stats

​

  • Exposing it as frame metadata would be good for applications using encoded transform
    • More efficient: No need to poll getContributingSources or getStats
    • More accurate: The level is known to correspond to the particular frame being processed
    • Potentially enables other use cases
      • For example, reduce redundancy for audio frames with zero/low audio level

21

22 of 33

Discussion (End Time: 09:30)

  • ​

22

23 of 33

SFrame

Start Time: 09:30 AM

End Time: 09:50 AM

23

24 of 33

SFrame

  • E2E support plan
    • RTCRtpScriptTransform as the short term solution
      • It works :)
    • SFrameTransform as the long term solution
      • Simpler, more efficient, more secure, MLS integration…

​

  • Where are we?
    • SFrame format is finished
    • SFrame Packetization format is under way
    • RTCRtpScriptTransform shipped, SFrameTransform is specified�
  • Implementation
    • WebKit SFrameTransform prototype

24

25 of 33

SFrame

  • How can we make progress?
    • Finish packetization format spec
      • Review of the current draft welcome here!
    • Improve WebRTC encoded transform spec
    • Implement specs�
  • Is now the time to do more in that area?

25

26 of 33

Issue #214 - Evaluate how to expose SFrame packetization format to RTCScriptTransform and SFrameTransform

SFrame packetization and RTCRtpScriptTransform

  • Sender side
    • How to select SFrame packetization?
  • Receiver side
    • Exposure of SFrame packets?
    • How to instruct of the media type after SFrame decryption?
      • Payload type (SFrame) != media type (codec)�
  • Proposal: expose additional information on encoded frames
    • Can be used by both SFrameTransform and RTCRtpScriptTransform

26

interface mixin RTCEncodedFrame {� attribute boolean isSFrame;

};

RTCEncodedAudioFrame includes RTCEncodedFrame;

RTCEncodedVideoFrame includes RTCEncodedFrame;

27 of 33

Issue #214 - Evaluate how to expose SFrame packetization format to RTCScriptTransform and SFrameTransform

SFrame packetization and SFrameTransform

  • When SFrame packetization format is negotiated
    • SFrameTranform on receiver side
      • Selected for SFrame packets only?
    • No transform on receiver side
      • Drop SFrame packets?
    • SFrameTransform on sender side
      • Automatic selection of SFrame packetization?�
  • When SFrame packetization format is not negotiated
    • SFrameTranform on receiver side
      • Never used?
    • SFrameTranform on sender side
      • Drop frames? Fire a new “Missing-packetization” error event?

27

28 of 33

Per packet SFrame - motivation

  • It is in use in WebEx
  • It has some advantages over per frame SFrame

28

29 of 33

Per packet SFrame - initial investigation

Various ways to support it

  • Via encoded transform model with SFrame packetization������
  • Leave it to WebRTC RTPTransport API
  • Use a new entry point in WebRTC pipeline
    • SFrameTransform construct? RTPtransport API entry point?�
  • Question to the WG
    • Is per packet SFrame packetization model compatible with WebRTC encoded transform model?
    • If so, how would fit in/be defined SFrame packetization, the crypto steps…

29

interface mixin RTCEncodedFrame {� attribute sequence<unsigned>? sframeOffsets;

};

partial dictionary SFrameTransformOptions {

boolean perFrame = “true”;

};

30 of 33

Discussion (End Time: 09:50)

  • ​

30

31 of 33

Wrapup and Next Steps

Start Time: 09:50 AM

End Time: 10:00 AM

31

32 of 33

Next Steps

  • Content goes here

32

33 of 33

Thank you

Special thanks to:

​

WG Participants, Editors & Chairs

33