Re: Notes from the WEBRTC WG Virtual Interim on February 27

> On 28 Feb 2020, at 20:22, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> 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/ <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.


I think this issue and PR deserves more discussion before reaching consensus/merging.
A few thoughts related to the PR:
- In general, we want to move to a world where starting or restarting capture should be based on user activation.
- We should take into consideration the cases where the user agent does not want to unmute.
- We should take into consideration existing UIs that allow users to dynamically mute/unmute capture for pages that do capture.

I’ll update the related GitHub issue.

> 
> 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.