W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2020

Notes from the January 14 Virtual Interim

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Thu, 23 Jan 2020 16:28:13 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <CY1PR00MB0123AFDC89D6153315A240B4EC0F0@CY1PR00MB0123.namprd00.prod.outlook.com>
Here are Henrik's notes from the January 14, 2020 virtual interim.  Please send corrections/additions to the list.

Slides from the meeting are here:
https://docs.google.com/presentation/d/1zhbRBbxVAlwVzqU7j5SIYKoLRc6Ec-brcDhNcfAI1sU


The notes below are paraphrases of key points of the conversations, not the full conversation or exact quotes.

WebRTC-PC

Issue 2412

Henrik: WPTs are best written when implementing the feature.

Yoenn: Should have WPT for small changes, maybe not large new APIs.

Bernard: Do we have a true picture of where we are?

Dom: Main roadblock is having WPT reviews rather than producing tests per-se.

Jan-Ivar: WPT PRs get stuck, browser imported WPTs get merged.

Dom: Happy to take an action item to map out test gaps, but only if we think this will have an impact.

Bernard is willing to take a look at current test code.

Alexandre: Do you need KITE test results for mobile?

Dom: W3C process-wise we need two implementations.

Bernard: An honest report should at least mention KITE results.

Bernard: Found relatively minor differences between Chrome and Edge, mostly getUserMedia.


Conclusion

No desire to abandon the testing policy.

Some desire to enforce “no test - no merge” if writing a test is easy. Best to merge test and PR at the same time. Some flexibility might be in order.

Editors need merge rights on WPT repo.

Should incorporate KITE inte testing report.

Editor call should incorporate testing PRs.

Media Capture and Streams

Jan-Ivar is summarizing a bunch of related issues and pitching a solution for all of it:

Issue 640 / 656 / 649 / 652

PING review raised privacy concerns. We do not expose minimum information to achieve user goals.

Issue 640

Putting “label” behind GUM permissions would break Firefox or make Firefox grant permission to all devices (worse).

Let’s make an API that works well in all browsers.

Issue 656

The user can’t choose the correct camera & microphone up-front. Firefox is the only browser that lets the user override the default choice.

Issue 649

Can explicitly ask for a specific deviceId to avoid picker, but enumerateDevices() removed deviceId before prompt.

Issue 652

In practise, pickers are very basic but are no event cross-browser compatible. Yet they are the sole reason why we expose device info. The current model is a total failure (reasons listed). There is no path to privacy here.

Issue 652

The pitch: do everything “in-chrome”, i.e. in-browser picker in the style of getDisplayMedia().

Transition:

Stage 1: Put label behind gum permissions.

Stage 2: Remove label in enumerateDevices().

Semantic difference between initial permission and adding/changing to another device.

PR 644

Mandate “in-chrome” getUserMedia selector when constraints resolve to multiple choices.

Proposal A: Do this. Backwards compatibility issue: sites using “ideal” instead of “exact” would re-promt on visit, for multi-camera users only.

Proposal B: Mitigate backwards compatibility issue by adding a new boolean: “chosen”.

Proposal C: New API instead of boolean: navigator.mediaDevices.chooseUserMedia().


Conclusion

Concerns with compatibility issues of proposal A. Interest in proposal B or C. Difference in opinion about the path forward. More discussion needed.

Jan-Ivar to make a specific proposal for B or C - Jan-Ivar prefers B. Browser vendors need to discuss internally about desire to implement the picker, but positive arguments can be made.

RTP Header Extensions

Need API to control which header extensions to use. Too many is a problem. Even if it’s possible to use an extension, we may want to turn some off (e.g. multiple extensions for similar things and both are supported, we only want to use one of them).

RTCRtpTransceiver API for SDP negotiation.


Conclusion

Bernard, Youenn, Henrik agree with the proposal but we need to flesh out the details.

Tim Panton has concerns that this may encourage adding more extensions (breeding rabbits).

Editors fear rabbits will breed regardless, but that this may make them less harmful.

Harald will make a PR.
Received on Thursday, 23 January 2020 16:28:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 23 January 2020 16:28:19 UTC