Re: [blink-dev] Ready for Developer Testing: Media Previews opt-out

['Philipp Hancke' via blink-dev]

Interesting, this goes in the direction of
  https://github.com/w3c/mediacapture-extensions/issues/2
which I had considered "that ship has sailed". The spec landed

https://w3c.github.io/mediacapture-extensions/#camera%20and%20microphone%20picker
but I don't recall any implementations.
Will this be wired up to the "semantics" field?

It seems that choosing the output device is missing, that is a quite common
feature.

Am Di., 9. Apr. 2024 um 17:07 Uhr schrieb mark a. foltz :

> Contact emailsmfo...@chromium.org, bryantchand...@chromium.org
>
> ExplainerNone
>
> Specification
> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>
> Design docs
>
> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>
> Summary
>
> Allow coordination between sites using Page Embedded Permissions Controls
> and concurrent experiments with the camera and microphone permissions UI in
> Chrome.
>
>
> Blink componentBlink>MediaStream
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None as this feature concerns the functionality of Chrome's permissions
> UI, and does not change the behavior of the APIs that are gated by it:
> navigator.mediaDevices.enumerateDevices and
> navigator.mediaDevices.getUserMedia Other browsers implement their own
> permissions UIs independently of Chrome.
>
>
> *Gecko*: N/A
>
> *WebKit*: N/A
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Goals for experimentation
>
>
>
> Ongoing technical constraints
>
> There are no plans to add media previews to Chrome on platforms other than
> Windows/Mac/Linux.
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> There are currently no plans to launch previews outside of
> Windows/Mac/Linux.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> N/A
>
>
> DevTrial instructionshttps://tinyurl.com/yc6mvth8
>
> Flag name on chrome://flags--enable-features=camera-mic-preview
>
> Finch feature nameCameraMicPreview
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/330762482
>
> Launch bughttps://launch.corp.google.com/launch/4304480
>
> Estimated milestones
> Origin trial desktop first 125
> Origin trial desktop last 136
> DevTrial on desktop 122
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5100528783851520
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgg%2BHEQFdnM53Q0wxGhRmsW%3D8A0%2Ba43MXs5nGaP4eujexSOOQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLNEw%3D%2BzmhjZedWyeLPiQrsbf6fRzj%2BYVPvq9YcpAPL2g%40mail.gmail.com.

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

['Philipp Hancke' via blink-dev]

Yoav,

in WebRTC land "we have a sample for that" (thanks to the one and only
WebRTC devrel guy Sam Dutton, I think I stole this tagline from him)!
  https://webrtc.github.io/samples/src/content/getusermedia/record/
with recent changes to improve MP4 support.

Discovery currently happens with isTypeSupported but it seems the WG just
decided to deprecate that:

https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141
(not sure how I feel about that, I'd rather nuke MediaRecorder entirely in
favor of WebCodecs + IndexedDB)

Am Do., 29. Feb. 2024 um 09:13 Uhr schrieb Yoav Weiss (@Shopify) <
yoavwe...@chromium.org>:

>
>
> On Thu, Feb 29, 2024 at 1:46 AM 'Sunggook Chue' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Here is an explainer, summary only.
>>
>>
>> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing
>
>
> Thanks! That's very useful! :)
>
> What's the feature detection story? How can developers know which formats
> are supported?
>
>
>>
>>
>> On Wednesday, February 28, 2024 at 7:53:29 AM UTC-8 yoav...@chromium.org
>> wrote:
>>
>>> On Tue, Feb 27, 2024 at 1:45 AM Mike Taylor 
>>> wrote:
>>>

 On 2/22/24 9:21 PM, 'Sunggook Chue' via blink-dev wrote:

 Contact emails

 sun...@microsoft.com

 dalec...@chromium.com (reviewer and mentor).

 Explainer

 https://www.w3.org/TR/mediastream-recording/

 That's not an explainer..
>>> Could you maybe write a short (inline?) explainer that outlines what it
>>> is that we want to ship, what it would help developers achieve, how we
>>> envision them using this feature, etc.?
>>>
>>>

 Specification

 https://www.w3.org/TR/mediastream-recording/

 Summary

 Adds support for muxing audio/video into MP4 containers with
 MediaRecorder.

 Developers can record media format, container, with MP4 of H264 video
 and AAC audio codecs in the MediaRecorder API.


 Blink component

 Blink::MediaRecording

 TAG review
 TAG review status
 Risks

 No Additional risks on existing containers such as webm.

 Interoperability and Compatibility

 This is missing vendor and developer signals - can you add (or request)
 them please?

 Ergonomics

 N/A


 Activation

 Unchallenging to use.


 Security

 N/A


 WebView Application Risks

 N/A


 Debuggability

 Developers can see the API failure on DevTools.

 Is this feature fully tested by web-platform-tests
 
 ?

 Yes

 Flag name

 MediaRecorderEnableMp4Muxer

 Tracking bug

 https://issues.chromium.org/issues/40127044

 Launch bug

 https://issues.chromium.org/issues/40127044

 Sample links

 https://webrtc.github.io/samples/src/content/getusermedia/record/

 Estimated milestones

 Dev Trial on Desktop: 120


 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5163469011943424

 Links to previous Intent discussions

 This intent message was generated by Chrome Platform Status
 .
 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1dd6d89b-34f4-4f18-b3e8-c1309d479530n%40chromium.org
 
 .

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+...@chromium.org.

>>> To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8119a014-24b2-487e-bbbd-324c1bf77081%40chromium.org
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dc2463e3-ef73-46ff-888e-23c8a9e446b1n%40chromium.org
>> 

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

['Philipp Hancke' via blink-dev]

Safari's "choice" of containers and codecs has basically led to a situation
where there was no interoperable way to record a video using MediaRecorder
that could be played in other browsers?

Am Do., 29. Feb. 2024 um 01:46 Uhr schrieb 'Sunggook Chue' via blink-dev <
blink-dev@chromium.org>:

> Here is an explainer, summary only.
>
>
> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing
>
> On Wednesday, February 28, 2024 at 7:53:29 AM UTC-8 yoav...@chromium.org
> wrote:
>
>> On Tue, Feb 27, 2024 at 1:45 AM Mike Taylor  wrote:
>>
>>>
>>> On 2/22/24 9:21 PM, 'Sunggook Chue' via blink-dev wrote:
>>>
>>> Contact emails
>>>
>>> sun...@microsoft.com
>>>
>>> dalec...@chromium.com (reviewer and mentor).
>>>
>>> Explainer
>>>
>>> https://www.w3.org/TR/mediastream-recording/
>>>
>>> That's not an explainer..
>> Could you maybe write a short (inline?) explainer that outlines what it
>> is that we want to ship, what it would help developers achieve, how we
>> envision them using this feature, etc.?
>>
>>
>>>
>>> Specification
>>>
>>> https://www.w3.org/TR/mediastream-recording/
>>>
>>> Summary
>>>
>>> Adds support for muxing audio/video into MP4 containers with
>>> MediaRecorder.
>>>
>>> Developers can record media format, container, with MP4 of H264 video
>>> and AAC audio codecs in the MediaRecorder API.
>>>
>>>
>>> Blink component
>>>
>>> Blink::MediaRecording
>>>
>>> TAG review
>>> TAG review status
>>> Risks
>>>
>>> No Additional risks on existing containers such as webm.
>>>
>>> Interoperability and Compatibility
>>>
>>> This is missing vendor and developer signals - can you add (or request)
>>> them please?
>>>
>>> Ergonomics
>>>
>>> N/A
>>>
>>>
>>> Activation
>>>
>>> Unchallenging to use.
>>>
>>>
>>> Security
>>>
>>> N/A
>>>
>>>
>>> WebView Application Risks
>>>
>>> N/A
>>>
>>>
>>> Debuggability
>>>
>>> Developers can see the API failure on DevTools.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Flag name
>>>
>>> MediaRecorderEnableMp4Muxer
>>>
>>> Tracking bug
>>>
>>> https://issues.chromium.org/issues/40127044
>>>
>>> Launch bug
>>>
>>> https://issues.chromium.org/issues/40127044
>>>
>>> Sample links
>>>
>>> https://webrtc.github.io/samples/src/content/getusermedia/record/
>>>
>>> Estimated milestones
>>>
>>> Dev Trial on Desktop: 120
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5163469011943424
>>>
>>> Links to previous Intent discussions
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1dd6d89b-34f4-4f18-b3e8-c1309d479530n%40chromium.org
>>> 
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+...@chromium.org.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8119a014-24b2-487e-bbbd-324c1bf77081%40chromium.org
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dc2463e3-ef73-46ff-888e-23c8a9e446b1n%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLbyDFk_0zjZ2G%3Dik6rg-SMCJavZbgEmp%3DgAiABuHPxcg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: RTCIceCandidate url and relayProtocol attributes

['Philipp Hancke' via blink-dev]

Am Mi., 14. Feb. 2024 um 16:09 Uhr schrieb Yoav Weiss (@Shopify) <
yoavwe...@chromium.org>:

>
>
> On Monday, February 12, 2024 at 7:52:17 PM UTC+1 philipp...@googlemail.com
> wrote:
>
> Contact emails
>
> phan...@microsoft.com
>
> Explainer
>
> None
>
>
> I think it would be useful to write a few sentences on what you want to
> ship, what's the motivation for shipping it and how we expect web
> developers to make use of it.
>

Will add. There are two small use-cases:
1/ "which server did I gather this ICE candidate from", as shown on
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
2/ answering the "Is my call now getting relayed via a TURN server" in
the selectedcandidatepairchange
event
.
Which
sometimes leads to the question
  "why is my call being relayed through a server in another part of the
world and doing it over TCP makes things terrible?"

Both of these were possible to obtain by asking the getStats API and then
traversing the stats graph but that is rather cumbersome (and that still
requires a lot of backward compat code

for
the second case)
In the case of relayProtocol it was also possible by looking at the upper 8
bits of the "priority" field already exposed but that was/is
implementation-specific.


> Specification
>
> https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface
>
> Summary
>
> https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface
>
> gets implementations for two new properties for RTCIceCandidate objects
> emitted from the 'icecandidate' event.
>
>
> https://github.com/w3c/webrtc-pc/pull/2773
>
> added the url of the STUN or TURN server a local ICE candidate of type
> 'srflx' or 'relay' was gathered from.
>
> https://github.com/w3c/webrtc-pc/pull/2763
>
> added the relay protocol (i.e. whether the candidate was gathered via
> TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidate of type 'relay' was
> gathered from.
>
>
> These properties are already available in the getStats API as
> RTCIceCandidateStats.
>
>
> OK, so I'm guessing the motivation here is ergonomics?
>
Any reason why we want to expose the same data from multiple APIs?
>

Ergonomics and consistency, this makes both APIs return the same
information for the ICE candidates.


> Blink component
>
> Blink>WebRTC
> 
>
> TAG review
>
> None
>
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> None
>
>
> Gecko: No official signal yet but positive (https://github.com/mozilla/
> standards-positions/issues/976)
>
> WebKit: No signal (https://github.com/WebKit/
> standards-positions/issues/310)
>
> Web developers: No signals
>
> Other signals:
>
> WebView application risks
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Not testable in WPT due to lack of STUN/TURN servers
>
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1354626
>
> Estimated milestones
>
> Shipping on desktop
>
> 123
>
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5170426198360064
>
> This intent message was generated by Chrome Platform Status
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLL_76M3hPHQCY%3Df7BptBh5S%3D_LFG0hcz%2BvC7a%3DYrPiJQ%40mail.gmail.com.

[blink-dev] Intent to Ship: RTCIceCandidate url and relayProtocol attributes

['Philipp Hancke' via blink-dev]

Contact emails

phan...@microsoft.com

Explainer

None

Specification

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

Summary

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

gets implementations for two new properties for RTCIceCandidate objects
emitted from the 'icecandidate' event.


https://github.com/w3c/webrtc-pc/pull/2773

added the url of the STUN or TURN server a local ICE candidate of type
'srflx' or 'relay' was gathered from.

https://github.com/w3c/webrtc-pc/pull/2763

added the relay protocol (i.e. whether the candidate was gathered via
TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidate of type 'relay' was
gathered from.

These properties are already available in the getStats API as
RTCIceCandidateStats.

Blink component

Blink>WebRTC


TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None


Gecko: No official signal yet but positive (
https://github.com/mozilla/standards-positions/issues/976)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/310)

Web developers: No signals

Other signals:

WebView application risks

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests

?

Not testable in WPT due to lack of STUN/TURN servers


Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1354626

Estimated milestones

Shipping on desktop

123


Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5170426198360064

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLOeY4xw2tFS5SzsY2zGByiLaHNrtq_ougiuAboRn6J1g%40mail.gmail.com.

[blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

['Philipp Hancke' via blink-dev]

Contact emails

phan...@microsoft.com, ma...@microsoft.com

Explainer

https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters

Specification

https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe

Summary

Adds an optional second parameter to WebRTC's RTCRtpSender.setParameters
call which can be used to ask the associated encoder to generate a key
frame.

Blink component

Blink>WebRTC>PeerConnection


TAG review

None, small addition to WebRTC

TAG review status

Not applicable

RisksInteroperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/858)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/237)

Web developers: Positive Microsoft Teams is quite interested in the feature.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests

?

Yes

See WPT added as part of
https://chromium-review.googlesource.com/c/chromium/src/+/4643591

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1354101

Estimated milestones

Shipping on desktop

122


Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161082937409536

This intent message was generated by Chrome Platform Status
 and then copy-pasted around

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJ0%3D-O%2BQoJoXfEWO1KBrLNHWnzTUGxXJSJOpm8BJTQEjw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebCodecs support for enabling AV1 screen content coding tools

['Philipp Hancke' via blink-dev]

We ended up *not* shipping this here as the underlying feature ended up
being integrated into contentHint by Eugene.
Which is another way to get consistency with WebRTC.

https://jsfiddle.net/fippo/r392ohwz/24 works great in Canary with a
significantly reduced bitrate \o/

Am Mi., 8. Nov. 2023 um 17:09 Uhr schrieb Chris Harrelson <
chris...@chromium.org>:

> LGTM3
>
> On Wed, Nov 8, 2023 at 7:30 AM Mike Taylor  wrote:
>
>> LGTM2
>> On 11/8/23 5:16 AM, Yoav Weiss wrote:
>>
>> LGTM1 - seems like a simple and useful addition to the API surface.
>>
>> On Wednesday, November 1, 2023 at 3:07:22 PM UTC+1
>> philipp...@googlemail.com wrote:
>>
>>> Am Mi., 25. Okt. 2023 um 18:40 Uhr schrieb Mike Taylor <
>>> miketa...@chromium.org>:
>>>
>>>> On 10/20/23 2:27 PM, 'Philipp Hancke' via blink-dev wrote:
>>>>
>>>> Contact emails
>>>>
>>>>
>>>> * phan...@microsoft.com ,
>>>> bernard.ab...@microsoft.com  * Explainer
>>>>
>>>> * None *
>>>>
>>>> For those looking for an explainer, hope down to the design docs
>>>> section (nice explainer, btw!).
>>>>
>>>>
>>>> Specification
>>>>
>>>>
>>>> *
>>>> https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools
>>>> <https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools>
>>>> * Design docs
>>>>
>>>>
>>>> *
>>>> https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md
>>>> <https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md>
>>>> * Summary
>>>>
>>>>
>>>>
>>>> * Adds AV1EncoderConfig (a dictionary containing
>>>> forceScreenContentTools) to the VideoEncoderConfig along these lines:
>>>> encoder.configure({ codec: 'av01.0.04M.08', av1: { forceScreenContentTools:
>>>> true}, width: 1920, height: 1080, bitrate: 2_000_000, framerate: 5, });
>>>> This allows an application to encode “screen content”, in particular
>>>> presentation slides, in a more efficient way supported by the AV1 codec.
>>>> This material is typically static, often includes text, a limited set of
>>>> colors, lots of repetitive content (e.g. straight lines, shapes) for which
>>>> the encoder can optimize. See the explainer for a lot of visual examples.
>>>> This AV1 feature is already supported by WebRTC and enabled for screen
>>>> sharing MediaStreamTracks so this increases platform consistency. * Blink
>>>> component
>>>>
>>>>
>>>> * Blink>Media>WebCodecs
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>
>>>> * TAG review
>>>>
>>>>
>>>> * None * TAG review status
>>>>
>>>> * Not applicable *
>>>>
>>>> An FYI review would be nice (especially given the discussions around
>>>> per-frame/per-codec options), can you send one?
>>>>
>>>
>>> Opened an issue here:
>>> https://github.com/w3ctag/design-reviews/issues/912
>>>
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>>
>>>> * None Gecko: Neutral similar to this situation
>>>> https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364
>>>> <https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364>
>>>> *
>>>>
>>>> Can we go ahead and request a position? It's not clear to me that
>>>> Mozilla was present when the feature was discussed at
>>>> https://lists.w3.org/Archives/Public/public-media-wg/2023Apr/0007.html.
>>>>
>>>
>>> Done: https://github.com/mozilla/standards-positions/issues/916
>>> Looks like this was discussed at the editors meeting:
>>> https://github.com/w3c/webcodecs/pull/662#issuecomment-1526010045 but
>>> since those don't have notes... ;-)
>>>
>>>>
>>>>
>>>>
>>>>
>>>> * WebKit: No signal
>>>> (https://github.com/WebKit/standards-positions/issues/239
>>>> <https://github.com/WebKit/standards-positions/issues/239>) Web developers:
>>>> No signals 

Re: [blink-dev] Intent to Prototype: MediaStreamTrack Stats (Audio)

['Philipp Hancke' via blink-dev]

[snip]

>
>
> *Web developers*: Positive
>
>
> Any links?
>
>
> I don't have any links but I've been told that web developers have been
> "asking for input latency metrics for years".
> On behalf of Google, Google Meet web developers are asking for both
> dropped frames ratio metrics and input latency metrics, so I am developing
> these PRs together with the WebRTC audio experts who requested them.
>

I've asked my Microsoft Teams Web audio folks and they look forward  to
being able to measure capture glitches this way.
Nobody likes audio glitches and I hope this will help reduce them and/or
identifying devices which are more prone.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJ%3Du9jyicXwCa%2BBrwHZ40DrrQD6XEsL2wJfnZVT6W3BiQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebCodecs support for enabling AV1 screen content coding tools

['Philipp Hancke' via blink-dev]

Am Mi., 25. Okt. 2023 um 18:40 Uhr schrieb Mike Taylor <
miketa...@chromium.org>:

> On 10/20/23 2:27 PM, 'Philipp Hancke' via blink-dev wrote:
>
> Contact emails
>
>
> * phan...@microsoft.com ,
> bernard.ab...@microsoft.com  * Explainer
>
> * None *
>
> For those looking for an explainer, hope down to the design docs section
> (nice explainer, btw!).
>
>
> Specification
>
>
> *
> https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools
> <https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools>
> * Design docs
>
>
> *
> https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md
> <https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md>
> * Summary
>
>
>
> * Adds AV1EncoderConfig (a dictionary containing forceScreenContentTools)
> to the VideoEncoderConfig along these lines: encoder.configure({ codec:
> 'av01.0.04M.08', av1: { forceScreenContentTools: true}, width: 1920,
> height: 1080, bitrate: 2_000_000, framerate: 5, }); This allows an
> application to encode “screen content”, in particular presentation slides,
> in a more efficient way supported by the AV1 codec. This material is
> typically static, often includes text, a limited set of colors, lots of
> repetitive content (e.g. straight lines, shapes) for which the encoder can
> optimize. See the explainer for a lot of visual examples. This AV1 feature
> is already supported by WebRTC and enabled for screen sharing
> MediaStreamTracks so this increases platform consistency. * Blink
> component
>
>
> * Blink>Media>WebCodecs
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>
> * TAG review
>
>
> * None * TAG review status
>
> * Not applicable *
>
> An FYI review would be nice (especially given the discussions around
> per-frame/per-codec options), can you send one?
>

Opened an issue here: https://github.com/w3ctag/design-reviews/issues/912

>
> Risks
>
> Interoperability and Compatibility
>
>
> * None Gecko: Neutral similar to this situation
> https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364
> <https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364>
> *
>
> Can we go ahead and request a position? It's not clear to me that Mozilla
> was present when the feature was discussed at
> https://lists.w3.org/Archives/Public/public-media-wg/2023Apr/0007.html.
>

Done: https://github.com/mozilla/standards-positions/issues/916
Looks like this was discussed at the editors meeting:
https://github.com/w3c/webcodecs/pull/662#issuecomment-1526010045 but since
those don't have notes... ;-)

>
>
>
>
> * WebKit: No signal
> (https://github.com/WebKit/standards-positions/issues/239
> <https://github.com/WebKit/standards-positions/issues/239>) Web developers:
> No signals Presented in the screen capture community group during TPAC
> 2023, slides here:
> https://docs.google.com/presentation/d/10i4HFYZ4CylpFUuoJcigfiI5uS7pK3uaseQpcYhugAY/edit#slide=id.g27ea3fad398_0_0
> <https://docs.google.com/presentation/d/10i4HFYZ4CylpFUuoJcigfiI5uS7pK3uaseQpcYhugAY/edit#slide=id.g27ea3fad398_0_0>
> Other signals: * WebView application risks
>
>
> * Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
> None * Debuggability
>
>
> * None *Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
>
> * Yes * Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?
>
>
>
> * No Unclear to what degree this is testable. Enabling this feature
> reduces the encoded frame size which makes it tough to test, it might be
> possible with a canvas source that provides predictable input similar to
> https://webrtc.github.io/samples/src/content/insertable-streams/video-processing/
> <https://webrtc.github.io/samples/src/content/insertable-streams/video-processing/>
> * Flag name on chrome://flags
>
>
> * None * Finch feature name
>
>
> * None * Non-finch justification
>
>
> * None * Requires code in //chrome?
>
>
> * False * Tracking bug
>
>
> * https://bugs.chromium.org/p/chromium/issues/detail?id=1464862
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1464862> * Estimated
> milestones
>
>
> * Shipping on desktop 121 * Anticipated spec changes
>
>
>
> * No

[blink-dev] Intent to Ship: WebCodecs support for enabling AV1 screen content coding tools

['Philipp Hancke' via blink-dev]

Contact emails


*phan...@microsoft.com , bernard.ab...@microsoft.com
*Explainer


*None*Specification


*https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools
*Design
docs


*https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md
*
Summary




*Adds AV1EncoderConfig (a dictionary containing forceScreenContentTools) to
the VideoEncoderConfig along these lines: encoder.configure({ codec:
'av01.0.04M.08', av1: { forceScreenContentTools: true}, width: 1920,
height: 1080, bitrate: 2_000_000, framerate: 5, }); This allows an
application to encode “screen content”, in particular presentation slides,
in a more efficient way supported by the AV1 codec.This material is
typically static, often includes text, a limited set of colors, lots of
repetitive content (e.g. straight lines, shapes) for which the encoder can
optimize.See the explainer for a lot of visual examples. This AV1 feature
is already supported by WebRTC and enabled for screen sharing
MediaStreamTracks so this increases platform consistency.*Blink component


*Blink>Media>WebCodecs
*TAG
review


*None*TAG review status


*Not applicable*Risks

Interoperability and Compatibility






*NoneGecko: Neutral similar to this situation
https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364
WebKit:
No signal (https://github.com/WebKit/standards-positions/issues/239
)Web developers:
No signals Presented in the screen capture community group during TPAC
2023, slides here:
https://docs.google.com/presentation/d/10i4HFYZ4CylpFUuoJcigfiI5uS7pK3uaseQpcYhugAY/edit#slide=id.g27ea3fad398_0_0
Other
signals:*WebView application risks


*Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?None*
Debuggability


*None*Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?


*Yes*Is this feature fully tested by web-platform-tests

?



*NoUnclear to what degree this is testable. Enabling this feature reduces
the encoded frame size which makes it tough to test, it might be possible
with a canvas source that provides predictable input similar to
https://webrtc.github.io/samples/src/content/insertable-streams/video-processing/
*Flag
name on chrome://flags


*None*Finch feature name


*None*Non-finch justification


*None*Requires code in //chrome?


*False*Tracking bug


*https://bugs.chromium.org/p/chromium/issues/detail?id=1464862
*Estimated
milestones


*Shipping on desktop121*Anticipated spec changes



*None*Link to entry on the Chrome Platform Status


*https://chromestatus.com/feature/6307770441138176
*Links to previous
Intent discussionsn/a

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJc34b%3DMrX7HhXQP_gZ3wCFg43qHbLJ7mKQqOPe7WYVwA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

['Philipp Hancke' via blink-dev]

Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss <
yoavwe...@chromium.org>:

>
>
> On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Great follow up to
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
>> Big fan!
>>
>
heh, great original I2S ;-)


> On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>> phan...@microsoft.com, h...@chromium.org
>>>
>>> Specification
>>> https://datatracker.ietf.org/doc/rfc8446
>>>
>>
> This is an interesting simple case where I agree that an explainer for
> this would be superfluous (as the Summary sums up what you're planning to
> ship).
>
>
>>
>>>
>>> Summary
>>>
>>> Randomize the order of DTLS ClientHello extensions, to reduce potential
>>> ecosystem brittleness.
>>>
>>>
>>> This is a WebRTC specific follow-up to
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
>>>  which
>>> launched successfully a while back.
>>>
>>>
>>> WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP
>>> and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
>>> negotiate encryption keys.
>>>
>>> Middleboxes might expect the use_srtp flag in a certain position which
>>> changes with this feature.
>>>
>>>
>>> Blink component
>>> Blink>WebRTC
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC>
>>>
>>> TAG review
>>> None
>>>
>>> TAG review status
>>> Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> It is possible that WebRTC's ClientHello extension ordering is already
>>> ossified. This change may cause compatibility issues with middleboxes, SBCs
>>> or other network monitoring software. We will do a slow rollout and monitor
>>> breakage.
>>>
>>
> Presumably, this will be behind a base feature to support the slow rollout?
>

It is guarded with WebRTC's internal FieldTrial which is overridden with a
base::FieldTrial in magic build ways.

Also, I assume the TLS side of things went smoothly. Any reason to believe
> DTLS would be significantly worse?
>

It did (see here
<https://bugs.chromium.org/p/webrtc/issues/detail?id=15467#c2>). Our very
own dreaded middleboxes (SBC or "Session Border Controller"; callcenters
use them) tend to be conservative in terms of deployment (see e.g. this
comment <https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c23>)
but most of them use a single vendor for browser interop testing who can
help with reaching out (in addition to discuss-webrtc and the release
notes) which should minimize the potential for breakage.


>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/709) Applied to
>>> TLS and DTLS equally
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/92)
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> n/a, not developer facing
>>>
>>>
>>> Activation
>>>
>>> n/a, not developer facing
>>>
>>>
>>> Security
>>>
>>> Using a fixed extension order can encourage server implementers to
>>> fingerprint Chrome and then assume specific implementation behavior. This
>>> can limit ecosystem agility when Chrome implements future modifications to
>>> DTLS, if the server implementations are not prepared for Chrome to change
>>> its ClientHello. Chrome will randomly order extensions, subject to the
>>> pre_shared_key constraint in the RFC. This will reduce the risk of server
>>> and middleboxes fixating on details of our current ClientHello. This should
>>> make the DTLS ecosystem more robust to changes.
>>>
>>>
>>> WebView application risks
>>>
>>> *Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?*
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> n/a, inner function of TLS stack. Possible to ins

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

['Philipp Hancke' via blink-dev]

Should/can this also be applied to WebRTC's DTLS connections?

(we don't have numbers but that can be fixed)

Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss <
yoavwe...@chromium.org>:

> LGTM1 to remove support, given that 0.009% of TLS connections divided by
> ~30 is roughly at our typical threshold. Also given the dominance of
> subresource TLS connections, it's likely that breakage would hit one of
> those subresources, making it less likely to cause functional damage
> (compared to e.g. the navigation request TLS connection).
>
> On Mon, Sep 25, 2023 at 6:03 PM David Adrian  wrote:
>
>> There are approximately 30x TLS connections relative to pageloads, due to
>> subresources. Once you have a TLS connection open for a main frame, I'm not
>> sure how many page loads happen across it. Probably a lot, but it's still
>> dominated by subresources.
>>
>> In practice, the 0.02% bound appears to have shaken out to sub 0.01%
>> (0.009%), determined by looking at differences in the "OK" result for
>> Net.SSL_Connection_Error.
>>
>> On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin 
>>> wrote:
>>>
 On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss 
 wrote:

> On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss 
> wrote:
>
>> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian 
>>> wrote:
>>>
 > This should probably be an "Intent to Deprecate and Remove"
 rather than an "Intent to Ship".

 You're absolutely right that it should be, unfortunately that's not
 the subject Chrome Status generated. I'll file an issue.

>>>
>>> Oops, yes, you did everything right here. There's already
>>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749
>>> about changing this subject line, and now
>>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 to
>>> align the Chrome Status UI with the launching-features page.
>>>
>>> > The RFC's introduction at
 https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a
 pretty good explainer for why we should remove SHA-1 signatures.

 Agreed. Noting in general, there is a large process mismatch
 between TLS launches and the Blink launch process, as discussed in
 https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ.
 That's why this Intent looks a little different.

>>>
>> I wouldn't categorize it as a large process mismatch. But that's an
>> orthogonal discussion.
>>
>>
>>>
 As for the launch itself, I'll note it's been at 10% on Finch for a
 couple weeks and everything looks gray, so we should be safe to ramp 
 up to
 100%. The only thing of note was a correlation with an unrelated
 crash in Blink
 ,
 since the deprecation rollout was fairly large. It only showed at 10%, 
 not
 1%.

>>>
>  How would we know of breakage in those 10%? Would that look like
> users filing issues? Something else?
>
>
 On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin <
 jyass...@google.com> wrote:

> This should probably be an "Intent to Deprecate and Remove"
> 
> rather than an "Intent to Ship". I'll let an API owner say if there's 
> a
> reason to re-send it; probably there isn't.
>
> On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsdadr...@google.com
>>
>> ExplainerNone
>>
>
> The RFC's introduction at
> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is
> a pretty good explainer for why we should remove SHA-1 signatures.
>
>
>> Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html
>>
>> Summary
>>
>> Chrome is removing support for signature algorithms using SHA-1
>> for server signatures during the TLS handshake. This does not affect 
>> SHA-1
>> support in server certificates, which was already removed, or in 
>> client
>> certificates, which continues to be supported. SHA-1 can be 
>> temporarily
>> re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled
>> enterprise policy. This policy will be removed in Chrome 123.
>>
>>
>> Blink componentInternals>Network>SSL
>> 

[blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

['Philipp Hancke' via blink-dev]

Contact emails
phan...@microsoft.com, h...@chromium.org

Specification
https://datatracker.ietf.org/doc/rfc8446

Summary

Randomize the order of DTLS ClientHello extensions, to reduce potential
ecosystem brittleness.


This is a WebRTC specific follow-up to
https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
which
launched successfully a while back.


WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP and
also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
negotiate encryption keys.

Middleboxes might expect the use_srtp flag in a certain position which
changes with this feature.


Blink component
Blink>WebRTC


TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

It is possible that WebRTC's ClientHello extension ordering is already
ossified. This change may cause compatibility issues with middleboxes, SBCs
or other network monitoring software. We will do a slow rollout and monitor
breakage.


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/709)
Applied to TLS and DTLS equally

*WebKit*: No signal (https://github.com/WebKit/standards-positions/issues/92
)

*Web developers*: No signals

*Other signals*:

Ergonomics

n/a, not developer facing


Activation

n/a, not developer facing


Security

Using a fixed extension order can encourage server implementers to
fingerprint Chrome and then assume specific implementation behavior. This
can limit ecosystem agility when Chrome implements future modifications to
DTLS, if the server implementations are not prepared for Chrome to change
its ClientHello. Chrome will randomly order extensions, subject to the
pre_shared_key constraint in the RFC. This will reduce the risk of server
and middleboxes fixating on details of our current ClientHello. This should
make the DTLS ecosystem more robust to changes.


WebView application risks

*Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?*

None


Debuggability

n/a, inner function of TLS stack. Possible to inspect using tools like
Wireshark


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests

?
No

Flag name on chrome://flags
None

Finch feature name
WebRTC-PermuteTlsClientHello

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/webrtc/issues/detail?id=15467

Estimated milestones
Shipping on desktop 120


Anticipated spec changes

*Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).*
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5191245718880256

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BWEyR_PRHcAfNNR0w1SECOZ%2B3PqVN3x%3DGcYjK10tE6sg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebRTC Codec Selection API

['Philipp Hancke' via blink-dev]

Am Do., 21. Sept. 2023 um 10:43 Uhr schrieb Florent Castelli <
orp...@chromium.org>:

>
>
> On Wed, Sep 20, 2023 at 5:21 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Wed, Sep 20, 2023 at 11:48 AM Florent Castelli 
>> wrote:
>>
>>> Contact emailsorp...@chromium.org
>>>
>>> Explainer
>>> https://github.com/Orphis/webrtc-extensions/blob/explainer/explainers/codec-selection.md
>>>
>>> Specification
>>> https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-codec
>>>
>>> Summary
>>>
>>> This new API extends WebRTC encoding parameters to allow developers to
>>> choose a specific negotiated codec to be used for encoding an RTP stream.
>>>
>>>
>>> Blink componentBlink>WebRTC>PeerConnection
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/836
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risks are low. This is a new dictionary member and API
>>> surface, if it isn't used by current applications, it should not cause any
>>> impact on compatibility.
>>>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/789)
>>>
>>> *WebKit*: Positive (
>>> https://github.com/WebKit/standards-positions/issues/179)
>>>
>>> *Web developers*: No signals
>>>
>>
>> Presumably this is something WebRTC developers are interested in. Any
>> ways you can think of to extract such a signal for WebRTC things in the
>> future?
>>
>
> WebRTC developers are indeed interested but have nothing to link to.
> Google Meet is interested in using the API and other conferencing solutions
> have been interested in advanced scenarios this API allows as well.
>

Same for MSFT Teams which I work on. Switching between codecs on the fly is
becoming important (e.g. because AV1 has encoding tools which very much
benefit static content for slide sharing).
While this is already possible with SDP renegotiation (even locally), the
API is much more ergonomic and avoids some race conditions.

The API also enables use-cases where multiple simulcast streams (i.e. same
picture but different resolutions) can use different codecs, e.g. a more
modern one like AV1 for small resolutions where software encoding is
feasible and a hardware encoded one (H264, VP9 I think) for large
resolutions

What I heard from Jitsi Meet via Saul (cc'd in case he wants to say more)
sounded similar.

>
>>
>>>
>>> Ergonomics
>>>
>>> No ergonomic risks. This API is part of WebRTC and will be used with
>>> other encoding parameters. One of its goals is to improve the WebRTC
>>> ergonomics by removing the need to make several calls with possible side
>>> effects to change the active codec, which should improve performance as
>>> well.
>>>
>>>
>>> Debuggability
>>>
>>> WebRTC is not supported by DevTools at the moment.
>>> chrome://webrtc-internals will reflect in the RTP stream statistics which
>>> codec is currently used.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature nameRTCRtpEncodingParametersCodec
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442194
>>>
>>> Estimated milestones
>>> Shipping on desktop 119
>>> Shipping on Android 119
>>> Shipping on WebView 119
>>> Shipping on WebView 119
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5200982281027584
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXEi2i3DzkXQo1ptX-KR%2BULh-4LOt5zpOi14BTstZN_9g%40mail.gmail.com
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXo_QcNo%3DSXCxq_bh%2BMEhoUY6FCDJK%3D3q%3DkDr4xs1yUbw%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> 

Re: [blink-dev] Intent to Implement and Ship: Per-frame quantizer in VideoEncoder

['Philipp Hancke' via blink-dev]

Am Mi., 19. Juli 2023 um 14:25 Uhr schrieb Yoav Weiss <
yoavwe...@chromium.org>:

>
>
> On Thu, Jul 13, 2023 at 10:53 PM 'Eugene Zemtsov' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Any new feedback or resolution on this one?
>>
>> On Fri, Jul 7, 2023 at 5:53 AM Sangwhan Moon  wrote:
>>
>>> (resending from correct email)
>>>
>>> On 2023年07月07日 00時32分12秒 (+09:00), Mike Taylor wrote:
>>>
>>> On 7/5/23 8:57 PM, 'Eugene Zemtsov' via blink-dev wrote:
>>>
>>> Intent to Implement and Ship: Per-frame quantizer in VideoEncoder
>>>
>>> Contact emails
>>>
>>> ezemt...@google.com
>>>
>>> Explainer
>>>
>>> None
>>>
>>>
> I think an explainer can be significantly helpful in helping us understand
> how developers will be using this feature and what use cases it'd cover.
> Could you write one or add an inline explanation outlining that?
>

Explaining that is tough without going into the details "what is
quantization for video codecs. See
  https://www.vcodex.com/h264avc-4x4-transform-and-quantization/
for a very detailed explanation for H264.

the tl;dr is that folks who encode video like tuning all kinds of knobs to
get the "best" result and qp is one of those.

>
>
>>
>>> Specification
>>>
>>> https://www.w3.org/TR/webcodecs/#video-encoder-bitrate-mode
>>>
>>> Summary
>>>
>>> Adds "quantizer" VideoEncoderBitrateMode for VideoEncoder. This allows
>>> to specify a quantizer parameter for each frame for AV1, VP9, and AVC video
>>> codecs. The quantizer parameter is set via codec specific extensions for
>>> VideoEncoderEncodeOptions.
>>>
>>> Assuming I know very little about video codecs, what use cases does this
>>> enable for developers?
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink>Media>WebCodecs
>>> 
>>>
>>> TAG review
>>>
>>> None.
>>>
>>> Previously WebCodecs API had TAG review as a whole:
>>>
>>> https://github.com/w3ctag/design-reviews/issues/612
>>>
>>> This is a new addition since that review, but it's a trivial addition
>>> (IMHO) so a new review request isn't needed.
>>>
>>>
>>> I agree, I don't see anything particularly contentious in the proposal
>>> that would warrant a full review.
>>>
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Neutral (
>>> https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364)
>>> Paul Adenot (Mozilla) expressed that minor changes to WebCodecs spec don't
>>> need to go through the full "Request for Mozilla Position" process assuming
>>> they were approved by the Media Working Group.
>>>
>>> WebKit: Positive (https://www.w3.org/2023/03/07-mediawg-minutes.html#t02)
>>> The issue was discussed on 07 March 2023 by w3c Media working group. Jer
>>> Noble (Apple) was actively participating and provided input for spec
>>> details.
>>>
>>> Can we request a formal position from WebKit, at least to let them know
>>> we're intending to ship?
>>>
>>>
>>> Web developers: Positive (https://github.com/w3c/webcodecs/issues/56)
>>> People ask for this on GitHub
>>>
>>> Other signals:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1424154
>>>
>>> Estimated milestones
>>>
>>> Shipping on desktop
>>>
>>> 117
>>>
>>> Shipping on Android
>>>
>>> 117
>>>
>>>
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5783986600673280
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Eugene Zemtsov.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrF0PKfpVbaYWX-hR0wJ%2Bb9H4YtwFBUc6Y6JGSmFT7pVgQ%40mail.gmail.com
>>> 
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> 

[blink-dev] Intent to Ship: WebRTC RTP header extension control

['Philipp Hancke' via blink-dev]

Contact emails

h...@google.com, h...@google.com, phan...@microsoft.com (sticking to my
already subscribed email for sending)

Explainer

https://docs.google.com/document/d/1y1hTsMeav5ijPvoqu1R6U4YC564i1QzgkMeIqWhgiis/edit#

(slightly outdated but still conveys the general idea)

Spec

https://w3c.github.io/webrtc-extensions/#rtp-header-extension-control

There’s also an IETF change pending
 for inclusion into RFC8829-bis
 that
allows us to change some of the language of the W3C spec, but this will not
change any behavior and is only editorial as far as the implementation is
concerned. It also updates the IETF spec to match the current behavior of
browsers

.

TAG review

N/A; minor extension to WebRTC

Blink component

Blink>WebRTC


Summary

The RTP header extensions API adds a control surface  to the WebRTC
RTCRtpTransceiver API which allows developers to control which RTP header
extensions are being negotiated by WebRTC.

This is something that is currently only possible via a non-standard API
where the Session Description Protocol string is manually modified to tell
WebRTC which header extensions to use. By providing apps with a
spec-compliant alternative we’ll be that much closer to deprecating the
non-standard code path.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/65YdUi02yZk/m/dXL1a8PYBQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes

Debuggability

The resulting RTP header extensions are visible in
chrome://webrtc-internals by looking at the SDP meaning any app using this
API can be inspected via this dev tool. The API also conveys which header
extensions were negotiated via a getter for JS level debugging.

Risks

Interoperability and Compatibility

Firefox: positive https://github.com/mozilla/standards-positions/issues/713
with great feedback that improved the specification

Safari: positive https://github.com/WebKit/standards-positions/issues/100

Web / Framework developers: Positive (Teams and Google Meet)

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

Yes:
https://wpt.fyi/results/webrtc-extensions/RTCRtpTransceiver-headerExtensionControl.html

Entry on the feature dashboard 

https://chromestatus.com/feature/5680189201711104

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BVVgjhZg%2BG1sbj%2BzUtaMzooeo9RRQPONx0%2B-G1ROA%2BgQ%40mail.gmail.com.

[blink-dev] PSA: Removal of WebRTC getStats encoderImplementation "unknown" and dataChannelIdentifier "-1"

['Philipp Hancke' via blink-dev]

The WebRTC getStats API exposes the encoder and decoder implementation
names for outbound and inbound video:

https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-encoderimplementation

It will no longer provide the value “unknown” in cases where statistics are
queried before a video frame was encoded or decoded. Instead, the
dictionary member will be omitted which follows the general pattern not to
return meaningless information described in

https://w3c.github.io/webrtc-stats/#guidelines-for-implementing-stats-objects

The stats collector implementation actually checks for the empty string

but the underlying data source has a default value of "unknown".

Similarly, the datachannel statistics dataChannelIdentifier

https://w3c.github.io/webrtc-stats/#dom-rtcdatachannelstats-datachannelidentifier

is currently being set to -1 before the DTLS connection is established.

This is being guarded against in the “legacy stats
”
but not the spec stats sadly.

Both properties are not available in Firefox or Safari yet as can be seen
in WPT

so applications should be prepared for this already.

For more details see the respectives changes [1
, 2
] in libwebrtc.

Chromestatus feature links:

https://chromestatus.com/feature/5072770423062528

https://chromestatus.com/feature/5088165401985024

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJ4srvRBfytkAhJenVuvZcgq8HokVj3R5Qci80kWZnBLw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

['Philipp Hancke' via blink-dev]

hey Yoav,

Am Fr., 17. Feb. 2023 um 08:52 Uhr schrieb Yoav Weiss <
yoavwe...@chromium.org>:

> Hey Henrik!
>
> I think the general outline of the plan makes sense, but the timelines
> seem too aggressive. As we've recently seen in the track stats removal,
> there can be a time difference between the point a developer puts in the
> work to opt-in for a deprecation trial and the point in which this work
> reaches users.
>

Your view might be skewed by that incident which I would classify as minor
and with relatively good communication upfront.
For scale, this
 is what I
call a meltdown ;-)

WebRTC is a complex (monolithical) API that still is not done after more
than a decade.
Commits to libwebrtc (which rolls into Chrome as a dependency) are still
around 200 per month (peak was around 600 in 2017).
The challenge is that a lot of the subtle changes in behavior are
nontrivial to detect, see e.g. this one
.
Some breakage gets caught early enough in the process by vendor CI systems
(e.g. here  and
that isn't even related directly to WebRTC) that it doesn't make it to
stable.

Compared to dealing with those kind of issues (which in the best case come
with a 4-8 week window) a planned deprecation is easy ;-)

I think it would make sense to:
> * Add a deprecation warning in M113 and enable a Deprecation Trial. Set a
> tentative removal milestone for M119.
> * Start throwing an exception up to Beta in M114 to try and get people's
> attention
> * Broadly communicate this change is coming in multiple channels. DevRel
> folks may be able to help there. +Paul Kinlan  and 
> +Andre
> Bandarra  for thoughts.
> * In parallel to the above, turn the usecounters into UKM
> ,
> and try to see where most usage lies. (and try to understand if it's coming
> from libraries with longer deployment lifecycles)
> * Flip the switch (and be ready to revert) in M119
>
> I know this is a bit longer and more work than the plan you outlined, but
> given the few fire drills we had recently, it seems better to err on the
> cautious side.
>
> Also, do you know if more removals are planned on your side? It seems like
> it'd be better to "bundle" them so that library authors only have to
> "respin" their deployment once, rather than every few milestones.
>

There are a few that might make sense to remove together:

   - The legacy callback based variants of createOffer, setLocalDescription
   et al, graph here
   

   .
   The high setLocalDescription usage here is due to "WebRTC leaks my ip
   address" trackers (maybe breaking them makes them reevaluate whether after
   the mdns changes they still get useful data?)
   setRemoteDescription and getUserMedia give a much better relative
   baseline of actual usage.
   - addStream which has been replaced by addTrack, graph here
   

   .
   - RTCIceServer.url, see the tracking bug
    and graph
   here .
   Again hard to interpret due to "WebRTC leaks my ip address" (in this
   case the public one). Given that Safari throws and the change needed is to
   replace "url" with "urls" this still seems safe for actual usage.
   - the nonstandard "negotiate" rtcpMuxPolicy, see the 2017 I2D
   
and tracking
   bug . The
   good news is that the then-new version of Asterisk that no longer needed
   this has been EOL'd a while ago.
   - The usage looks pretty low
    but even
   if the new metrics coming to M111
   

   put it at 0.1% of relative WebRTC usage I'm concerned that this might
   represent callcenter usage where the WebCompat argument "does not work in
   Safari" does not apply because the callcenter agents use Chromebooks.
   ("Callcenters" are even more conservative than "enterprise usage" here,
   with breakages
   

   costing a lot of money)

None of those require changes which are as technically involved as the
"plan-b deprecation".
For the first two https://github.com/fippo/webrtc-codemods even does the
job automatically.




> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström  wrote:
>
>> 

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Philipp Hancke' via blink-dev]

Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström :

> *Contact emails*
> h...@chromium.org, h...@chromium.org
>
> *Background*
> I attempted to remove this feature before but had forgotten to file an
> intent to deprecate, background here
> .
>
> *Specification*
> The getStats() API spec is here  and
> it contains all the metrics. The deprecated metrics are also listed, but in
> the obsolete section
> .
> There's an open issue to remove obsolete metrics from the spec as soon as
> they are unshipped from modern browsers. This is considered a blocker for
> the document to reach Proposed Recommendation status.
>
> *Summary*
> WebRTC is a set of JavaScript APIs (spec
> ) that allow real-time communication
> between browsers. For the relevant metrics being removed, we're only
> talking about the WebRTC use case that is sending or receiving audio or
> video (typically Video Conferencing use cases), not the data channel use
> cases that is a popular WebRTC use case, since data channel only use cases
> would never have any tracks/streams.
>
> RTCPeerConnection.getStats() returns a map of string-to-objects, where
> each object is one of the dictionaries defined in the stats spec. The
> reason an app calls getStats() is mostly to report quality metrics (send
> and receive resolutions, bitrates, glitches, video QP, etc) which can be
> important for A/B experimentation. It can also be used in a way that
> impacts app logic or even UX inside the app. Most common use case I can
> think of: poll getStats() at 10 Hz and render volume bars for each
> participant based on volume levels from stats objects.
>
> The deprecation in question is to remove some stats objects that were made
> obsolete several years ago: all metrics on the "track" dictionary have been
> moved to non-obsolete objects ("inbound-rtp", "outbound-rtp",
> "media-source"). Reasons for wanting to deprecate include:
>
>- Spec-compliance: needed for browser implementations to align and for
>the spec to become Proposed Recommendation.
>- Web compat: Firefox never implement "track" or "steam"
>
> 
>  due
>to them being obsolete.
>- Performance: the duplicated metrics make up ~40% of the stats report
>size, which can be a significant number of bytes in larger meetings and it
>is common for apps to poll getStats() 10 times per second.
>- Tech debt: unblock removal of 1400 LOC.
>
> In the meantime, the obsolete metrics is duplicated in several places of
> the stats report.
>
> *Risks*
> *- Impossible to properly measure usage*
> Because stats objects are exposed as JavaScript dictionaries, and because
> apps have to iterate all objects of the stats report in order to find the
> ones they are interested in or if they just dump all the data without
> filtering, there is no way to measure how big the dependency is on track in
> the real world.
>
> While we lack use counters, we have some positive signs:
>
>- Because Firefox does not have "track" or "stream" stats, any app
>that can run on Firefox already exercises the paths of these not existing.
>
>
>- An experiment to "unship deprecated metrics" has been running at 50%
>Canary since October
>
> ,
>giving developers testing Canary a heads-up. Nobody complained until the
>experiment reached Stable.
>- We got to 50% Stable in M109 and while we're in the process of
>rolling it back now due to breaking twilio-video.js
>, it's
>interesting to note that this is the only breakage we are aware of (that
>does not mean there aren't more breakages, but I believe this at least says
>something about the severity).
>
> *- Selenium et al typically starts browsers from fresh profiles and hence
> does not know the finch trial seed*
> The most likely explanation for breakage is not testing Canary or test
> environments not having access to Finch experiments. This makes the
> behavior on Stable a surprise.
>
> *- To have a Reverse Origin Trial or not to have a Reverse Origin Trial?*
> Migrating should require so few lines of code (look for stats.type ==
> 'inbound-rtp' instead of stats.type == 'track', for example) that it seems
> to be a bigger hurdle for a developer to enroll in the trial than to simply
> fix their code.
>
> *- Compatiblity risk*
> There is one particular metric out of all metrics that, if you run Safari,
> does not exist on "inbound-rtp" yet. This can be a problem, but again is
> probably not a big problem because this particular metric was never
> implemented on Firefox so apps 

Re: [blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Philipp Hancke' via blink-dev]

uld pre-seed the profiles
used with the finch trial seed (and for deprecations it might be better to
recommended a command line for the CI).

I'm still in favor of the removal but removing by default (possibly guarded
by a killswitch) seems like a less error-prone process.

Philipp
(*) I am somewhat pessimistic about the actual state of the "webrtc
industry" wrt to automated tests
(**) at least that was my conclusion from a post-mortem of the VP8 temporal
layer reduction
<https://groups.google.com/g/discuss-webrtc/c/N1sMEBJhOz4/m/r9BJbhYEBgAJ> that
is, in what must be the longest "trial" ever, still ongoing?


>
>>
>>> Best,
>>>
>>> Alex
>>>
>>>
> On Tue, Jan 10, 2023 at 12:34 AM 'Aaron Boushley' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Can you help me understand exactly which objects are being removed here?
>> We rely on `RTCPeerConnection.getStats()` although we pass in a stream
>> selector. We then iterate over the returned stats reports looking for ones
>> containing the values we need.
>>
>
> The selector (be it an RTCRtpSender, RTCRtpReceiver or MediaStreamTrack)
> continues to work, it's just that the report no longer contains the removed
> stats objects.
>
>
>>
>> Is this a removal of the stats objects that have the fixed ID of "track"
>> and "stream"?
>>
>
> It is the removal of the stats objects where .type == "track" or .type ==
> "stream".
> In the spec this refers to dictionaries RTCMediaStreamTrackStats
> <https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamtrackstats> and
> RTCMediaStreamStats
> <https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamstats> which are
> part of the "Obsolete" section of the spec. See RTCStatsType
> <https://w3c.github.io/webrtc-stats/#rtcstatstype-str*> for complete list
> of stats object types.
>
> Regarding the track stats dictionary, the same metrics are still
> available, but you have to look at the non-deprecated locations:
> RTCOutboundRtpStreamStats
> <https://w3c.github.io/webrtc-stats/#outboundrtpstats-dict*> and
> RTCInboundRtpStreamStats
> <https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats> 
> dictionaries
> instead (type == "outbound-rtp" and type == "inbound-rtp"). See also the
> type "media-source" referenced from outbound-rtp.mediaSourceId.
>
>
>> Is there any more documentation I can look at beyond the 2 sentences
>> above?
>>
>
> The spec <https://w3c.github.io/webrtc-stats/> as well as the
> implementation
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h>
>  are
> good resources in general.
>
>
>>
>> Aaron
>>
>>
>
>> On Mon, Jan 9, 2023 at 11:30 AM 'Philipp Hancke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Henrik,
>>>>
>>>> while I understand that this has been ongoing for a while in Canary
>>>> <https://groups.google.com/g/discuss-webrtc/c/R7Mcux9RK6g/m/KG8qe6AEBgAJ>
>>>> and Beta
>>>> <https://groups.google.com/g/discuss-webrtc/c/9c8ZjberEcI/m/wbdQr77VBQAJ> 
>>>> for
>>>> a while without anyone raising issues,
>>>> the timeline "tomorrow" (with ramp-up) comes as a surprise, in
>>>> particular considering practices like code freezes over the holidays.
>>>>
>>>> Can you explain why you think you don't need an intent to deprecate on
>>>> blink-dev (cc'd)?
>>>> (I agree they should go away but don't see a need for such an
>>>> aggressive timeline)
>>>>
>>>> Am Mo., 9. Jan. 2023 um 10:40 Uhr schrieb Henrik Boström <
>>>> h...@webrtc.org>:
>>>>
>>>>> With the Stable release of M109 tomorrow, the deprecated "track" and
>>>>> "stream" stats objects returned by RTCPeerConnection.getStats() will no
>>>>> longer be available.
>>>>>
>>>>> This is unshipped at 1% Stable, but it will soon ramp up further with
>>>>> the goal of 100% unshipped in M109.
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "discuss-webrtc" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to discuss-webrtc+unsubscr...@googleg

Finch trials percentages history (was: Re: [blink-dev] Re: Intent to Remove: Rename User-Agent Client Hint ACCEPT-CH tokens)

['Philipp Hancke' via blink-dev]

old thread alert (hence reducing the cc list) but I've found the data
scraped by
  https://github.com/nornagon/finch-trials-history
(see https://github.com/nornagon/finch-trials for how it works)
to be incredibly useful (most recently in this issue
).

chrome://version/?show-variations-cmd is quite a useful feature too but
only provides a limited view.

Am Do., 14. Jan. 2021 um 18:03 Uhr schrieb Philip Jägenstedt <
foo...@chromium.org>:

> On Tue, Jan 12, 2021 at 12:12 AM 'Eric Lawrence' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> > I have been informed that we can't share the exact percentages for
>> Finch trials
>>
>> I'm curious about why that is? The Finch system publishes the percentages
>> as a part of its design, so anyone who wants to can get the numbers.
>>
>
> I didn't know that, but I guess because the config is maintained in
> google3. If you are able to get the percentage from a public endpoint, feel
> free to post it here :)
>
> FWIW, I don't think the exact percentage here changes the calculus.
> Whether it's 10% or 90% or something else, this was still shipped very
> recently to less than all users.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdOB283e04WQWhu_dJrR_VACgQ_06WRKSuQvCVbcnsaSA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2By_9rKrx10ta9XsNd%3DpxVnk%3DhdTkAx9P%2B9qbzTVX_biA%40mail.gmail.com.

[blink-dev] Re: [discuss-webrtc] Deprecated "track" and "stream" stats are unshipped in M109.

['Philipp Hancke' via blink-dev]

Henrik,

while I understand that this has been ongoing for a while in Canary

and Beta
 for
a while without anyone raising issues,
the timeline "tomorrow" (with ramp-up) comes as a surprise, in particular
considering practices like code freezes over the holidays.

Can you explain why you think you don't need an intent to deprecate on
blink-dev (cc'd)?
(I agree they should go away but don't see a need for such an aggressive
timeline)

Am Mo., 9. Jan. 2023 um 10:40 Uhr schrieb Henrik Boström :

> With the Stable release of M109 tomorrow, the deprecated "track" and
> "stream" stats objects returned by RTCPeerConnection.getStats() will no
> longer be available.
>
> This is unshipped at 1% Stable, but it will soon ramp up further with the
> goal of 100% unshipped in M109.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss-webrtc+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/0ebcadca-6d66-4f7c-b7e5-d2ac707a6e84n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJ-vkiyVTH%2BsSNOjv67zx0p7qLra1ePdGJS3JW3GTzfKQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

['Philipp Hancke' via blink-dev]

the ID of the sink needs to be obtained from
navigator.mediaDevices.enumerateDevices because
https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
is not implemented anywhere?

Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org>:

> Contact emails
>
> hongc...@chromium.org, alvi...@chromium.org, mjwil...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://github.com/WebAudio/web-audio-api/pull/2498
>
> Summary
>
> AudioContext.setSinkId sets the ID of the audio device to use for output.
> This allows the AudioElement to route audio to a connected output device of
> user's choosing.
>
>
> Blink component
>
> Blink>WebAudio
> 
>
> TAG review
>
> This is a small API change within Web Audio API. The WG was advised that
> this is too small for the TAG review.
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive (https://github.com/WebAudio/web-audio-api/issues/2400)
> Mozilla is co-developing the spec change.
>
> WebKit: No signal
>
> Web developers: Positive (
> https://github.com/WebAudio/web-audio-api/issues/2400) Many developers
> chimed in the spec issue and the implementation crbug entry (
> crbug.com/1216187). Also several partners expressed the need for this
> API. We have not seen any negative feedback on this.
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> Debuggability
>
> This adds a new method to AudioContext; the WebIDL change will be
> addressed by the DevTools automatically.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> This is a part of Web Audio API, which is available on all platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes. The WPT will be added for this feature.
>
> Flag name
>
> –enable-blink-features=AudioContextSetSinkId
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1355977
>
> Launch bug
>
> https://crbug.com/1216187
>
> Estimated milestones
>
> 108
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5190163462881280
>
> This intent message was generated by Chrome Platform Status
> .
>
>
> --
> Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
> 650-797-1279 <(650)%20650-797-1279>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAj6AJ01%3DgXdUepU9Aejf6DOt2qmsK%3DUm%2BJSEDoVRMeyqw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BucfBFY2sjh-Pw%2BGcvNiGy11NZa56UZgg8i_ZvkxD5Aw%40mail.gmail.com.

Re: [blink-dev] Question regarding webrtc

['Philipp Hancke' via blink-dev]

the discuss-webrtc  list is
probably a better place to ask in the future.

Adding video to an audio-only call will, by design, require renegotiation.
There is a sample for that at
https://webrtc.github.io/samples/src/content/peerconnection/upgrade/
- it adds the camera but you can just replace the getUserMedia call with
getDisplayMedia.

Am Mi., 6. Juli 2022 um 18:01 Uhr schrieb Shubham Bhateja <
sbhat...@kingeranalytics.com>:

> Hello Blink,
>
>
> I am working on a project in which we are using an audio call feature of
> WebRTC. Audio call works fine. On button click we need to enable share
> screen and replaceTracks with share screen track only, but replaceTrack web
> api replaces tracks of same kind, for example audio track can only be
> replaced with audio track or video track can only be replaced with video
> track. In my case, I am trying to achieve two things:
>
> #1: I want to enable share screen while the audio track is on.
>
> #2: If I can replace the audio track with share screen track appended in
> it without renegotiations.
>
> Any help will be highly appreciated!
>
>
>
>
>
> Sent from Mail  for
> Windows
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR15MB5245EB1D56925CFCBF8421A3DDBE9%40SJ0PR15MB5245.namprd15.prod.outlook.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKJ4ezS-vQ4buJizY684tos%2BVzSS-euzYCzn43RgUW%3Dyg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to deprecate and remove: SDES key exchange for WebRTC

['Philipp Hancke' via blink-dev]

Am Sa., 26. März 2022 um 21:39 Uhr schrieb dxssx dxssx <
dxssx.dx...@gmail.com>:

> Is this the right place to ask question? (I came across from google
> results)
>

the discuss-webrtc mailing list is a better place (so please remove
blink-dev when responding)


> Just curious about the intention "The reason why SDES is deprecated is
> that it is a security problem: It exposes session keys to Javascript, which
> means that entities with access to the negotiation exchange, or with the
> ability to subvert the Javascript, can decrypt the media sent over the
> connection."
>

The decision to not support SDES in WebRTC dates back to an IETF decision
from 2013.
https://webrtchacks.com/webrtc-must-implement-dtls-srtp-but-must-not-implement-sdes/
has some details and links to the slides.


> Is javascript a real concern? IIUC, the new insertable stream will allow
> javascript to be able to access media and the potential usage of it for
> E2EE will intentionally let javascript to handle E2EE keys.
>

The concern here is not javascript but exposing the key to signaling
servers, passive MITM attacks and retroactive decryption.
DTLS doesn't suffer from those problems, not exposing the encryption keys
to Javascript is a bonus here.

Thanks.
>
> On Thursday, August 26, 2021 at 1:45:47 AM UTC-7 Harald Alvestrand wrote:
>
>> Contact emailsh...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://www.rfc-editor.org/rfc/rfc8826#section-4.3.1
>>
>> Summary
>>
>> The SDES key exchange mechanism for WebRTC has been declared a MUST NOT
>> in the relevant IETF standards since 2013. The SDES specification has been
>> declared Historic by the IETF. Its usage in Chrome has declined
>> significantly over the recent year. This intent is to deprecate and remove
>> this code from Chromium and WebRTC.
>>
>>
>> Blink componentBlink>WebRTC>Network
>> 
>>
>> Motivation
>>
>> The reason why SDES is deprecated is that it is a security problem: It
>> exposes session keys to Javascript, which means that entities with access
>> to the negotiation exchange, or with the ability to subvert the Javascript,
>> can decrypt the media sent over the connection.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>>
>> Debuggability
>>
>> When this feature is removed, people attempting to set up such a
>> connection will fail to do so. This should be easy to diagnose.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/webrtc/11066
>>
>> Estimated milestones
>>
>> Link to entry on the Chrome Platform Status
>> https://www.chromestatus.com/feature/5695324321480704
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39f67083-8391-4e0a-8f3e-549848adbc73n%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLs-Lq%3DVV8ooP%2By6RYjwnkwP1cKk1Zrm6aZnSD--tcjdw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Philipp Hancke' via blink-dev]

Am Mi., 8. Dez. 2021 um 17:52 Uhr schrieb Philip Jägenstedt <
foo...@chromium.org>:

> Hi Harald,
>
> Can you spell out what the uncontroversial parts of this would be? Looking
> at the IDL in https://w3c.github.io/webrtc-svc/ it looks like it's all
> about modes.
>
> My guess is that it's RTCRtpEncodingParameters's scalabilityMode, but is
> that right?
>

yeah
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
which is currently behind a flag.

Best regards,
> Philip
>
> On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> It seems like we don't have a strong push towards either the
>> MediaCapabilities or the Codec Capabilities solution in the issue on the
>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is bad
>> for quick resolution.
>>
>> In the interest of getting the uncontroversial parts shipped - what would
>> people think of letting the Codec Capabilities list of modes remain behind
>> the flag, and push the rest of the API to public?
>> Many usages of the function would work quite well with only probing for
>> supported modes by trying to set the ones they want; we could then let the
>> issue sort itself out in peace.
>>
>> (On the receiver side, there seems to be consensus on abandoning the mode
>> list for other reasons.)
>>
>>
>>
>>
>> On Wed, Nov 24, 2021 at 3:21 PM Mike West  wrote:
>>
>>> Friendly ping on Yoav's question about timelines.
>>>
>>> -mike
>>>
>>>
>>> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss 
>>> wrote:
>>>
 How long of a delay are we talking about here? Weeks? Months? Years?

 On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand
 wrote:

> The scalability modes (being able to set them) are the point of the
> launch.
> Figuring out which of the desired ones are available seems like it
> would be a requirement.
>
>
> On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini <
> fs...@chromium.org> wrote:
>
>> It seems they are asking for a delay on Chrome launching this until
>> the WebRTC WG makes a decision on it.
>> It's not clear from the issue that there's a consensus on the right
>> approach there.
>>
>> Did you consider launching things separately and delaying the
>> scalability modes? Or does the whole launch make no sense without it?
>>
>> --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1197505b-23e6-491a-8fc6-4b386cce0bcen%40chromium.org
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVHmEvq6MANGA078Fa9TqQe63b3QS5icAFaLbjH34ETfmw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdU%2BkKr%3DqETzu8fBD6VmqGDQJwEuiXtn%2BKO-EtbDnquvg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLh%3DqCr8TR6NJ6z4%3Dux6HtKYU2j7EB9ch0m%2B4c-TsK4wA%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Philipp Hancke' via blink-dev]

Am Do., 26. Aug. 2021 um 22:47 Uhr schrieb Harald Alvestrand :

>
>
> On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss  wrote:
>
>> A few questions raised at the API OWNERS meeting today.
>>
>> On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
>>
>>> On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss 
>>> wrote:
>>>
>>>> What would breakage look like?
>>>>
>>>
>>> Once the feature is gone (the end state), anyone attempting to set up a
>>> connection using SDES will have their session rejected.
>>> Anyone attempting to set the constraint will just have it ignored, like
>>> any other unsupported value in a dictionary.
>>>
>>
>> OK. Any enterprise risk here? Are you aware of any enterprise apps using
>> this?
>>
>
> I doubt it. There is no real reason for using it; DTLS is safer and
> simpler to configure.
>

I bet there are some callcenters using it on the agent side and being
callcenters, they won't report metrics.
The list of vendors is known though. As is the IETF 2013 consensus that
this is a MUST NOT.


>
>>
>>>
>>> I'm thinking that we should add an intermediate step where anyone
>>> attempting to configure SDES has the constructor throw rather than ignoring
>>> the member.
>>>
>>
>> An unhandled exception seems more risky than a silent failure here, right?
>> Any reason to think console warnings won't be enough?
>>
>
> The connection won't go through anyway unless both ends of the connection
> upgrade at the same time; throwing is a failure that is more obvious.
> When things fail, I like to have them fail for obvious reasons.
>

The existing behaviour of throwing in setRemoteDescription when receiving
an SDES-only offer seems good (and works in both Chrome and Firefox).
The error code might need some work, it differs between Chrome and Firefox.

We have some test coverage for this:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/peerconnection/RTCPeerConnection-sdes-constraint.html;l=11;drc=09074552ce314b5d942d960ceaa90599671ee137
I'll add a negative assertion as a WPT. Why ask when you can write a test
:-)


>
>
>>
>>
>>>
>>>
>>>> What's the requested timeline for the deprecation part of this?
>>>>
>>>
>>> I'd like to get the deprecation warning in 95 (stable Oct 19), start
>>> throwing in 97 (stable Jan 4), and removing the code entirely in 99 (stable
>>> Mar 1).
>>>
>>>
>>>> Any plans for targeted outreach for the remaining users?
>>>>
>>>
>>> Only the usual PSA on webrtc-users and discuss-webrtc + word of mouth.
>>>
>>>
>>>>
>>>> On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> stats here:
>>>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/2383
>>>>>
>>>>
>>>> Impressive decline in usage!
>>>>
>>>>
>>>>> Away with it!
>>>>>
>>>>> Am Do., 26. Aug. 2021 um 10:45 Uhr schrieb 'Harald Alvestrand' via
>>>>> blink-dev :
>>>>>
>>>>>> Contact emails...@chromium.org
>>>>>>
>>>>>> ExplainerNone
>>>>>>
>>>>>> Specificationhttps://www.rfc-editor.org/rfc/rfc8826#section-4.3.1
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> The SDES key exchange mechanism for WebRTC has been declared a MUST
>>>>>> NOT in the relevant IETF standards since 2013. The SDES specification has
>>>>>> been declared Historic by the IETF. Its usage in Chrome has declined
>>>>>> significantly over the recent year. This intent is to deprecate and 
>>>>>> remove
>>>>>> this code from Chromium and WebRTC.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>WebRTC>Network
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3ENetwork>
>>>>>>
>>>>>> Motivation
>>>>>>
>>>>>> The reason why SDES is deprecated is that it is a security problem:
>>>>>> It exposes session keys to Javascript, which means that entities with
>>>>>> access to the negotiation exchange, or with the ability to subvert the
>

Re: [blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Philipp Hancke' via blink-dev]

stats here:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2383
Away with it!

Am Do., 26. Aug. 2021 um 10:45 Uhr schrieb 'Harald Alvestrand' via
blink-dev :

> Contact emails...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://www.rfc-editor.org/rfc/rfc8826#section-4.3.1
>
> Summary
>
> The SDES key exchange mechanism for WebRTC has been declared a MUST NOT in
> the relevant IETF standards since 2013. The SDES specification has been
> declared Historic by the IETF. Its usage in Chrome has declined
> significantly over the recent year. This intent is to deprecate and remove
> this code from Chromium and WebRTC.
>
>
> Blink componentBlink>WebRTC>Network
> 
>
> Motivation
>
> The reason why SDES is deprecated is that it is a security problem: It
> exposes session keys to Javascript, which means that entities with access
> to the negotiation exchange, or with the ability to subvert the Javascript,
> can decrypt the media sent over the connection.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
>
> Debuggability
>
> When this feature is removed, people attempting to set up such a
> connection will fail to do so. This should be easy to diagnose.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/webrtc/11066
>
> Estimated milestones
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5695324321480704
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJrgemVNeyGP5bw%3Dp40%2Bwc6Zbxi3q-CRWpqV%2BpU%3Dk8%2BgQ%40mail.gmail.com.