Notes from the WEBRTC WG Virtual Interim on February 27

Thanks to Henrik for scribing.  Here are the notes (with some corrections additions from me). Comments welcome.

W3C WEBRTC WG Virtual Interim
February 27, 2020

Link to slides: https://docs.google.com/presentation/d/1NIHzumglY9cYa4b7rcEbHGVsMam5BiY80VfFDB6cDjQ/


KITE update (Dr. Alex)

  *   Status reports from IETF 106 (November 2019). Potential update at IETF 107.

  *   Browsers: Status report from November 2019 still looks accurate. Lots of green on chrome, less so on Safari and Firefox.

  *   SFUs: Mix of support, see slide. Medooze, Mediasoup, Janus support Unified Plan, setParameters, addTransceiver, RIDs, repairid and SSRC-less operation.


Issue 642: Turn off device on disabled track (Jan-Ivar)

track.enabled. can be used to turn on and off camera.


Problem: The hardware light is still on when the track is disabled on some browsers. May surprise users.


Spec not being explicit about behavior => people work around the issue by stopping the track and calling getUserMedia again. Causes re-prompt in Firefox.


Proposal: Mandate “turning light off”, basically.

Decision: Merge PR.


Issue 655: How to avoid wide-lens & telephoto on new phones

Flagship phones have multiple back cameras. Wide-lens!

Possible solution to use focusDecision?


Proposal A: focalLength

Proposal B: angleOfView


Discussion: Which constraint makes sense to a camera person?

Which spec to add it do? Suggestion to add it to the mediacapture-main spec.


Decision: Rough consensus to go forward with proposal A but in millimeters.


Issue 652: In-browser device picker (Jan-Ivar)

Exposing all devices reveals actual privacy sensitive information. TAG and PING wants a privacy-by-default flow. “Rule of least power”.

  *   “Availability-style API”: nothing prevents UA from letting the user customize a single default cam/mic and expose a single device.

  *   “Picker-style API”: Goals: get rid of labels and granting all devices by default. This focuses on the first goal


Minimal-changes based proposals. Use cases listed: new visitor, repeat visitor, changing camera devices...


Firefox has a picker, but only if permission is absent. No obstacle for other browsers to do the same.


Changing camera: without knowing about all devices, we need a in-browser picker to be shown regardless of permissions.


Proposal: getUserMedia(existingDeviceId: <current id>) would re-prompt, always.


chooseUserMedia() unless we change the semantics of getUserMedia().

Either

  *   Add constraints semantics: “browser-chooses”, “user-chooses”

  *   Can switch default and deprecate long-term.

Or

  *   chooseUserMedia()


Decision: Move in the direction towards picker - group is more positive towards “semantics” - but don’t break the web until we have a usable option implemented.

This appears to be closest to "Option B" on the slides.


Insertable Streams

API for transforming the data after encoding (sender) and before decoding (receiver).

Other insertion points under consideration (e.g. after decoding or before encoding).


Status update: Experimental implementation in Chrome - API has shifted from what was proposed in at TPAC because the original idea was hard to implement.

Use case 1: end-to-end encryption. Proof-of-concept implementation done.

See explainer and example slides.


Relation to other efforts: WebCodecs (experience will be fed back to that effort) and TransferableStreams (allows WebWorker processing).

Not related to WebGPU.


Capture Timestamp

The abs-capture-timestamp allows accurate A/V synchronization, and as the slides explain a way to calculate end-to-end delay regardless of number of hops between capture system and receiving system.

FYI: Chrome is implementing this and the PR has merged on webrtc-extensions.


RTP Header Extensions

We need an API to control header extensions. There are too many of them and people are forced to SDP munge.

Public design doc published, prototype in Chrome in progress. Next steps: origin trial.


Content-Hints

RTCDegradationPreference is now in Content-Hint.

The spec is a lot more specific about how content hints and constraints interact than before.

Little bit of usage, call for consensus.

Should we ask for CR publication? Let’s take the steps towards that.