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

[Alex Russell]

LGTM3

On Friday, January 19, 2024 at 12:39:29 PM UTC-8 Mike Taylor wrote:

> LGTM2
> On 1/19/24 12:41 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Fri, Jan 19, 2024 at 7:36 AM 'Vladimir Levin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Thank you for the detailed explanation. It's hard to decipher from 
>> meeting notes whether a discussion is bikeshedding or serious objections :) 
>>
>> Based on your description, it does seem like there is good consensus
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström  wrote:
>>
>>> Having participated in both the WG meeting and the following editors 
>>> meetings where the editors merged the PR, my memory too is that there was 
>>> wide support for this. 
>>>
>>> To make sure I'm not misremembering, I rewatching the recording 
>>>  just now. I don't 
>>> hear anybody challenging the use case, it's mostly discussions about 
>>> whether this should be considered a "parameter" or not. Philipp explains 
>>> why it needs to be set at the same time as the other parameters even though 
>>> it's not a traditional parameter, Harald expresses a need for getParameters 
>>> and setParameters to work with the same params and Florent suggests a way 
>>> to solve this by introducing a second argument to the method. There are 
>>> some questions about whether the use case might already be covered by the 
>>> "active" flag, a point first made by Jan-Ivar, but there are problems with 
>>> that IMO and ultimately we ran out of time. So there was some ambiguity if 
>>> this was just bike shedding or if there were legitimately other options, 
>>> but most voices were supporting this and the recorded outcome was to 
>>> "refine the PR". So these discussions continued in follow-ups.
>>>
>>> The follow-ups happened during the editors meeting where the PR 
>>>  was refined, 
>>> approved by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and 
>>> merged. We went with Florent's suggestion of a second argument which 
>>> avoided the parameter issue that Harald initially raised. My understanding 
>>> is that everyone was happy with it, but I can't speak for other people.
>>> On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com 
>>> wrote:
>>>
 Based on the WG discussion (meeting notes: 
 https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem 
 that there is a very strong consensus that this is a right spot to add an 
 extra parameter. There are also no signals on the RFPs, but the spec PR 
 has 
 landed. How would you assess the vendor support for this change? 

 Thanks,
 Vlad

 On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
 blink-dev@chromium.org> wrote:

> This extension has consensus in the WEBRTC WG, and CLs are approved by 
> the Chrome WebRTC folks. 
>
>
> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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
>>
>> Risks Interoperability 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 

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

[Mike Taylor]

LGTM2

On 1/19/24 12:41 PM, Chris Harrelson wrote:

LGTM1

On Fri, Jan 19, 2024 at 7:36 AM 'Vladimir Levin' via blink-dev 
 wrote:


Thank you for the detailed explanation. It's hard to decipher from
meeting notes whether a discussion is bikeshedding or serious
objections :)

Based on your description, it does seem like there is good consensus

Thanks,
Vlad

On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström 
wrote:

Having participated in both the WG meeting and the following
editors meetings where the editors merged the PR, my memory
too is that there was wide support for this.

To make sure I'm not misremembering, I rewatching the
recording
 just
now. I don't hear anybody challenging the use case, it's
mostly discussions about whether this should be considered a
"parameter" or not. Philipp explains why it needs to be set at
the same time as the other parameters even though it's not a
traditional parameter, Harald expresses a need for
getParameters and setParameters to work with the same params
and Florent suggests a way to solve this by introducing a
second argument to the method. There are some questions about
whether the use case might already be covered by the "active"
flag, a point first made by Jan-Ivar, but there are problems
with that IMO and ultimately we ran out of time. So there was
some ambiguity if this was just bike shedding or if there were
legitimately other options, but most voices were supporting
this and the recorded outcome was to "refine the PR". So these
discussions continued in follow-ups.

The follow-ups happened during the editors meeting where the
PR  was
refined, approved by Jan-Ivar (Mozilla), Bernard (Microsoft)
and myself (Google) and merged. We went with Florent's
suggestion of a second argument which avoided the parameter
issue that Harald initially raised. My understanding is that
everyone was happy with it, but I can't speak for other people.
On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1
vmp...@google.com wrote:

Based on the WG discussion (meeting notes:
https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it
didn't seem that there is a very strong consensus that
this is a right spot to add an extra parameter. There are
also no signals on the RFPs, but the spec PR has landed.
How would you assess the vendor support for this change?

Thanks,
Vlad

On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via
blink-dev  wrote:

This extension has consensus in the WEBRTC WG, and CLs
are approved by the Chrome WebRTC folks.


On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via
blink-dev  wrote:


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


Risks


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


   

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

[Chris Harrelson]

LGTM1

On Fri, Jan 19, 2024 at 7:36 AM 'Vladimir Levin' via blink-dev <
blink-dev@chromium.org> wrote:

> Thank you for the detailed explanation. It's hard to decipher from meeting
> notes whether a discussion is bikeshedding or serious objections :)
>
> Based on your description, it does seem like there is good consensus
>
> Thanks,
> Vlad
>
> On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström  wrote:
>
>> Having participated in both the WG meeting and the following editors
>> meetings where the editors merged the PR, my memory too is that there was
>> wide support for this.
>>
>> To make sure I'm not misremembering, I rewatching the recording
>>  just now. I don't
>> hear anybody challenging the use case, it's mostly discussions about
>> whether this should be considered a "parameter" or not. Philipp explains
>> why it needs to be set at the same time as the other parameters even though
>> it's not a traditional parameter, Harald expresses a need for getParameters
>> and setParameters to work with the same params and Florent suggests a way
>> to solve this by introducing a second argument to the method. There are
>> some questions about whether the use case might already be covered by the
>> "active" flag, a point first made by Jan-Ivar, but there are problems with
>> that IMO and ultimately we ran out of time. So there was some ambiguity if
>> this was just bike shedding or if there were legitimately other options,
>> but most voices were supporting this and the recorded outcome was to
>> "refine the PR". So these discussions continued in follow-ups.
>>
>> The follow-ups happened during the editors meeting where the PR
>>  was refined,
>> approved by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and
>> merged. We went with Florent's suggestion of a second argument which
>> avoided the parameter issue that Harald initially raised. My understanding
>> is that everyone was happy with it, but I can't speak for other people.
>> On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com
>> wrote:
>>
>>> Based on the WG discussion (meeting notes:
>>> https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem
>>> that there is a very strong consensus that this is a right spot to add an
>>> extra parameter. There are also no signals on the RFPs, but the spec PR has
>>> landed. How would you assess the vendor support for this change?
>>>
>>> Thanks,
>>> Vlad
>>>
>>> On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 This extension has consensus in the WEBRTC WG, and CLs are approved by
 the Chrome WebRTC folks.


 On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
 blink-dev@chromium.org> wrote:

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

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

['Vladimir Levin' via blink-dev]

Thank you for the detailed explanation. It's hard to decipher from meeting
notes whether a discussion is bikeshedding or serious objections :)

Based on your description, it does seem like there is good consensus

Thanks,
Vlad

On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström  wrote:

> Having participated in both the WG meeting and the following editors
> meetings where the editors merged the PR, my memory too is that there was
> wide support for this.
>
> To make sure I'm not misremembering, I rewatching the recording
>  just now. I don't
> hear anybody challenging the use case, it's mostly discussions about
> whether this should be considered a "parameter" or not. Philipp explains
> why it needs to be set at the same time as the other parameters even though
> it's not a traditional parameter, Harald expresses a need for getParameters
> and setParameters to work with the same params and Florent suggests a way
> to solve this by introducing a second argument to the method. There are
> some questions about whether the use case might already be covered by the
> "active" flag, a point first made by Jan-Ivar, but there are problems with
> that IMO and ultimately we ran out of time. So there was some ambiguity if
> this was just bike shedding or if there were legitimately other options,
> but most voices were supporting this and the recorded outcome was to
> "refine the PR". So these discussions continued in follow-ups.
>
> The follow-ups happened during the editors meeting where the PR
>  was refined, approved
> by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and merged.
> We went with Florent's suggestion of a second argument which avoided the
> parameter issue that Harald initially raised. My understanding is that
> everyone was happy with it, but I can't speak for other people.
> On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com
> wrote:
>
>> Based on the WG discussion (meeting notes:
>> https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem
>> that there is a very strong consensus that this is a right spot to add an
>> extra parameter. There are also no signals on the RFPs, but the spec PR has
>> landed. How would you assess the vendor support for this change?
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> This extension has consensus in the WEBRTC WG, and CLs are approved by
>>> the Chrome WebRTC folks.
>>>
>>>
>>> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 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

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

[Henrik Boström]

Having participated in both the WG meeting and the following editors 
meetings where the editors merged the PR, my memory too is that there was 
wide support for this.

To make sure I'm not misremembering, I rewatching the recording 
 just now. I don't 
hear anybody challenging the use case, it's mostly discussions about 
whether this should be considered a "parameter" or not. Philipp explains 
why it needs to be set at the same time as the other parameters even though 
it's not a traditional parameter, Harald expresses a need for getParameters 
and setParameters to work with the same params and Florent suggests a way 
to solve this by introducing a second argument to the method. There are 
some questions about whether the use case might already be covered by the 
"active" flag, a point first made by Jan-Ivar, but there are problems with 
that IMO and ultimately we ran out of time. So there was some ambiguity if 
this was just bike shedding or if there were legitimately other options, 
but most voices were supporting this and the recorded outcome was to 
"refine the PR". So these discussions continued in follow-ups.

The follow-ups happened during the editors meeting where the PR 
 was refined, approved 
by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and merged. 
We went with Florent's suggestion of a second argument which avoided the 
parameter issue that Harald initially raised. My understanding is that 
everyone was happy with it, but I can't speak for other people.
On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com wrote:

> Based on the WG discussion (meeting notes: 
> https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem 
> that there is a very strong consensus that this is a right spot to add an 
> extra parameter. There are also no signals on the RFPs, but the spec PR has 
> landed. How would you assess the vendor support for this change?
>
> Thanks,
> Vlad
>
> On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> This extension has consensus in the WEBRTC WG, and CLs are approved by 
>> the Chrome WebRTC folks.
>>
>>
>> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> 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 

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

['Vladimir Levin' via blink-dev]

Based on the WG discussion (meeting notes:
https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem that
there is a very strong consensus that this is a right spot to add an extra
parameter. There are also no signals on the RFPs, but the spec PR has
landed. How would you assess the vendor support for this change?

Thanks,
Vlad

On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
blink-dev@chromium.org> wrote:

> This extension has consensus in the WEBRTC WG, and CLs are approved by the
> Chrome WebRTC folks.
>
>
> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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
>> 
>> .
>>
> --
> 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/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%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/CADsXd2PqZYvwPqD_koe7ay%2BsJs6bSs%2B_2RDPZRXRzPLKRG4T%2BQ%40mail.gmail.com.

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

['Harald Alvestrand' via blink-dev]

This extension has consensus in the WEBRTC WG, and CLs are approved by the
Chrome WebRTC folks.


On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
blink-dev@chromium.org> wrote:

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

-- 
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/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%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.