Re: [blink-dev] Re: Intent to Implement and Ship: OpusEncoderConfig `signal` and `application` parameters

['Thomas Guilbert' via blink-dev]

The last launch gate approval came in today.

Thanks!

On Wed, Apr 3, 2024 at 11:49 AM Thomas Guilbert 
wrote:

> I agree that this would have been a viable solution, and this was
> considered and discussed with the spec editors too [1]. These Opus flags
> were originally supposed to be contentHint, but ultimately it would have
> only ever been useful for Opus, so it was decided to keep it in the Opus
> config.
>
> [1] : https://github.com/w3c/webcodecs/pull/759#issuecomment-1928349508
>
> On Wed, Apr 3, 2024 at 9:10 AM Daniel Bratell  wrote:
>
>> This may be a bit of a tangent, but we had a discussion about AV1-only
>> encoder configuration a while back[1][2]. In the end they elected to have a
>> top level dictionary where some encoding configuration ended up. I wonder
>> if there is anything to learn from that process and their choices or if you
>> consider that orthogonal to this.
>>
>> /Daniel
>>
>> [1] AV1:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLH6ViLccGxHZzbCG_ChtSxiG59XoeYMPRqeW1Wk410rg%40mail.gmail.com
>>
>> [2] ContentHint:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9K9_YmJRFn%3DQBKb0GsETsSFex0DPprMRRpWUWgcvAtbA%40mail.gmail.com
>>
>>
>> On 2024-03-28 08:43, Yoav Weiss (@Shopify) wrote:
>>
>> Thanks!
>>
>> On Wed, Mar 27, 2024 at 10:41 PM Thomas Guilbert 
>> wrote:
>>
>>> I've flipped all the reviews and will update this thread when they are
>>> all completed.
>>>
>>> Thanks!
>>>
>>> On Wed, Mar 27, 2024 at 8:25 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
 Hey! Can you flip on the various reviews (privacy, enterprise, etc) in
 the chromestatus entry?

 On Tuesday, March 26, 2024 at 11:29:53 PM UTC+1 Thomas Guilbert wrote:

> Contact emails tguilb...@chromium.org
>
> Explainer None
>
> Specification
> https://w3c.github.io/webcodecs/opus_codec_registration.html#dom-opusencoderconfig-signal
>
> Summary
>
> `OpusEncoderConfig.signal` and `OpusEncoderConfig.application` were
> recently added to the WebCodecs spec [1]. Both parameters are mapped
> directly to implementation specific encoder knobs. These allow web authors
> to provide hints as to what type of data is being encoded, and in which
> context the data is being used. `signal` can be one of {"auto", "music",
> "voice"}. It configures the encoder for the best performance in encoding
> the specified type of data. `application` can be one of {"voip", "audio",
> "lowdelay"}. It configures the encoder to favor speech intelligibility,
> faithful reproduction of the original input, or minimal latency. [1] :
> https://github.com/w3c/webcodecs/pull/777
>
>
> Blink component Blink>Media>WebCodecs
> 
>
> TAG review None
>

>> Why not?
>>
>>
>>>
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (https://github.com/w3c/webcodecs/pull/777) Spec
> change approved by Mozilla representative. For an almost identical 
> feature,
> Mozilla said the "request for standards position" was not warranted, as
> they were active spec participants:
> https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364
>
> *WebKit*: No signal. Review from WebKit was requested on the spec
> change.
>

>> Can you ask for official positions? https://bit.ly/blink-signals
>>
>>
>>>
> *Web developers*: No signals
>
> *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
>
> 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
>
> Existing WPTs will be modified to cover this feature:
> https://wpt.fyi/results/webcodecs/audio-encoder-config.https.any.html
>
>
> Flag name on chrome://flags None
>
> Finch feature name None
>
> Non-finch justification
>
> Simple parameter changes.
>
>
> Requires code in //chrome? False
>
> Estimated milestones
> Shipping on desktop 125
> Shipping on Android 125
>
> 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 

Re: [blink-dev] Re: Intent to Implement and Ship: OpusEncoderConfig `signal` and `application` parameters

['Thomas Guilbert' via blink-dev]

I agree that this would have been a viable solution, and this was
considered and discussed with the spec editors too [1]. These Opus flags
were originally supposed to be contentHint, but ultimately it would have
only ever been useful for Opus, so it was decided to keep it in the Opus
config.

[1] : https://github.com/w3c/webcodecs/pull/759#issuecomment-1928349508

On Wed, Apr 3, 2024 at 9:10 AM Daniel Bratell  wrote:

> This may be a bit of a tangent, but we had a discussion about AV1-only
> encoder configuration a while back[1][2]. In the end they elected to have a
> top level dictionary where some encoding configuration ended up. I wonder
> if there is anything to learn from that process and their choices or if you
> consider that orthogonal to this.
>
> /Daniel
>
> [1] AV1:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiLH6ViLccGxHZzbCG_ChtSxiG59XoeYMPRqeW1Wk410rg%40mail.gmail.com
>
> [2] ContentHint:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9K9_YmJRFn%3DQBKb0GsETsSFex0DPprMRRpWUWgcvAtbA%40mail.gmail.com
>
>
> On 2024-03-28 08:43, Yoav Weiss (@Shopify) wrote:
>
> Thanks!
>
> On Wed, Mar 27, 2024 at 10:41 PM Thomas Guilbert 
> wrote:
>
>> I've flipped all the reviews and will update this thread when they are
>> all completed.
>>
>> Thanks!
>>
>> On Wed, Mar 27, 2024 at 8:25 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Hey! Can you flip on the various reviews (privacy, enterprise, etc) in
>>> the chromestatus entry?
>>>
>>> On Tuesday, March 26, 2024 at 11:29:53 PM UTC+1 Thomas Guilbert wrote:
>>>
 Contact emails tguilb...@chromium.org

 Explainer None

 Specification
 https://w3c.github.io/webcodecs/opus_codec_registration.html#dom-opusencoderconfig-signal

 Summary

 `OpusEncoderConfig.signal` and `OpusEncoderConfig.application` were
 recently added to the WebCodecs spec [1]. Both parameters are mapped
 directly to implementation specific encoder knobs. These allow web authors
 to provide hints as to what type of data is being encoded, and in which
 context the data is being used. `signal` can be one of {"auto", "music",
 "voice"}. It configures the encoder for the best performance in encoding
 the specified type of data. `application` can be one of {"voip", "audio",
 "lowdelay"}. It configures the encoder to favor speech intelligibility,
 faithful reproduction of the original input, or minimal latency. [1] :
 https://github.com/w3c/webcodecs/pull/777


 Blink component Blink>Media>WebCodecs
 

 TAG review None

>>>
> Why not?
>
>
>>

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: Positive (https://github.com/w3c/webcodecs/pull/777) Spec
 change approved by Mozilla representative. For an almost identical feature,
 Mozilla said the "request for standards position" was not warranted, as
 they were active spec participants:
 https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364

 *WebKit*: No signal. Review from WebKit was requested on the spec
 change.

>>>
> Can you ask for official positions? https://bit.ly/blink-signals
>
>
>>
 *Web developers*: No signals

 *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

 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

 Existing WPTs will be modified to cover this feature:
 https://wpt.fyi/results/webcodecs/audio-encoder-config.https.any.html


 Flag name on chrome://flags None

 Finch feature name None

 Non-finch justification

 Simple parameter changes.


 Requires code in //chrome? False

 Estimated milestones
 Shipping on desktop 125
 Shipping on Android 125

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

 This intent message was 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

['Thomas Guilbert' via blink-dev]

FYI, the enterprise policy landed in M124 (under
"PrefixedVideoFullscreenApiAvailability"), and the deprecation trial will
activate when M125 branches, on April 15th.

On Fri, Feb 2, 2024 at 12:16 PM Mike Taylor  wrote:

> LGTM3
> On 2/2/24 1:03 AM, Domenic Denicola wrote:
>
> LGTM2. Please be sure to update Chrome Status with the deprecation trial
> timelines and removal milestones so that data gets fed into the feature
> dashboard, beta blog posts, etc.
>
> On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
> wrote:
>
>> Thank you!
>>
>> I will be adding an enterprise policy to re-enable the APIs if necessary,
>> as part of the enterprise review. Deprecating the enterprise policy will
>> become the new objective after the proper amount of time has elapsed,
>> before the code can be deleted for good.
>>
>> I will keep updating this thread as I make it further in the launch
>> process.
>>
>> On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt 
>> wrote:
>>
>>> Thank you Thomas!
>>>
>>> As far as I'm aware that's all of the paperwork completed, so LGTM1 to
>>> disable the APIs by default and at the same time start a reverse origin
>>> trial to re-enable them for 6 months. If you hear feedback requesting an
>>> extension towards the end of those 6 months, please request an extension
>>> for another 6 months.
>>>
>>> On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert 
>>> wrote:
>>>
 Thanks for marking it for review!

 I submitted a request to review this change to the chromium enterprise
 mailing list.

 Thanks,
 Thomas

 On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor 
 wrote:

> Yep - seems that's the cause of confusion. In your first email,
> https://chromestatus.com/feature/5259513871466496 is linked from the
> bottom, so our review tooling is presenting that to us. But I've just
> flagged the new one so it will show up as well.
>
> thanks!
> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>
> I requested privacy/security/debuggability on the video element
> fullscreen API deprecation feature
>  
> last
> week. Privacy and debuggability are approved, just waiting on security.
>
> Mike, are you talking about requesting those gates on the original
> Prefixed Fullscreen API feature
> ? I don't have
> edit rights on that Chrome status entry, and upon closer look, it relates
> to `webkitRequestFullscreen`, which is not covered by this deprecation
> intent.
>
> > [...] requesting enterprise signoff [...]
> Is this a field on the chrome status entry? It doesn't show up for me.
> Or is this about emailing the list mentioned here
> 
> ?
>
> Thanks,
> Thomas
>
>
>
> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
> wrote:
>
>> Apologies in advance for excessive paperwork, but can you also put
>> https://chromestatus.com/feature/5111638103687168 through the
>> process, requesting enterprise signoff in particular? Enterprise folks
>> could depend on this and might need to take some extra action, and a
>> "Feature deprecation" entry is the only way we can flag that.
>>
>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>> wrote:
>>
>>> Gentle reminder to follow up on requesting
>>> privacy/security/debuggability approvals in chromestatus (which is
>>> currently blocking LGTMs).
>>>
>>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>>
 Would you mind requesting reviews for the various gates (privacy,
 security, debuggability) for an OT/DT in your chromestatus entry?
 On 1/19/24 10:43 PM, Thomas Guilbert wrote:

 Contact emails

 tguilb...@chromium.org

 Explainer

 None

 Specification

 https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled

 Summary
 There was an attempt in 2014
 
 to deprecate and remove the HTMLVideoElement-specific Prefixed 
 Fullscreen
 APIs. This meant removing the following APIs from HTMLVideoElement:

 readonly attribute boolean webkitSupportsFullscreen;
 readonly attribute boolean webkitDisplayingFullscreen;
 void webkitEnterFullscreen();
 void webkitExitFullscreen();
 // Note the different capitalization of the "S" in FullScreen.
 void webkitEnterFullScreen();
 void webkitExitFullScreen();

 The overall usage of these APIs is low, and has trended downwards
 over time. Here are the 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

['Thomas Guilbert' via blink-dev]

Thanks for marking it for review!

I submitted a request to review this change to the chromium enterprise
mailing list.

Thanks,
Thomas

On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor  wrote:

> Yep - seems that's the cause of confusion. In your first email,
> https://chromestatus.com/feature/5259513871466496 is linked from the
> bottom, so our review tooling is presenting that to us. But I've just
> flagged the new one so it will show up as well.
>
> thanks!
> On 1/31/24 2:41 PM, Thomas Guilbert wrote:
>
> I requested privacy/security/debuggability on the video element
> fullscreen API deprecation feature
>  last
> week. Privacy and debuggability are approved, just waiting on security.
>
> Mike, are you talking about requesting those gates on the original
> Prefixed Fullscreen API feature
> ? I don't have edit
> rights on that Chrome status entry, and upon closer look, it relates to
> `webkitRequestFullscreen`, which is not covered by this deprecation intent.
>
> > [...] requesting enterprise signoff [...]
> Is this a field on the chrome status entry? It doesn't show up for me. Or
> is this about emailing the list mentioned here
> 
> ?
>
> Thanks,
> Thomas
>
>
>
> On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
> wrote:
>
>> Apologies in advance for excessive paperwork, but can you also put
>> https://chromestatus.com/feature/5111638103687168 through the process,
>> requesting enterprise signoff in particular? Enterprise folks could depend
>> on this and might need to take some extra action, and a "Feature
>> deprecation" entry is the only way we can flag that.
>>
>> On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor 
>> wrote:
>>
>>> Gentle reminder to follow up on requesting
>>> privacy/security/debuggability approvals in chromestatus (which is
>>> currently blocking LGTMs).
>>>
>>> On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:
>>>
 Would you mind requesting reviews for the various gates (privacy,
 security, debuggability) for an OT/DT in your chromestatus entry?
 On 1/19/24 10:43 PM, Thomas Guilbert wrote:

 Contact emails

 tguilb...@chromium.org

 Explainer

 None

 Specification

 https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled

 Summary
 There was an attempt in 2014
 
 to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen
 APIs. This meant removing the following APIs from HTMLVideoElement:

 readonly attribute boolean webkitSupportsFullscreen;
 readonly attribute boolean webkitDisplayingFullscreen;
 void webkitEnterFullscreen();
 void webkitExitFullscreen();
 // Note the different capitalization of the "S" in FullScreen.
 void webkitEnterFullScreen();
 void webkitExitFullScreen();

 The overall usage of these APIs is low, and has trended downwards over
 time. Here are the latest usage numbers, as a % of total page loads:

 PrefixedVideoSupportsFullscreen: 0.025%
 PrefixedVideoDisplayingFullscreen: 0.082%
 PrefixedVideoEnterFullscreen: 0.001%
 PrefixedVideoExitFullscreen: 0.010%
 PrefixedVideoEnterFullScreen: 0.001%
 PrefixedVideoExitFullScreen: 0.000%


 There has been an unfortunate uptick in the past 2 years for the two
 following APIs, which means that it's best to remove them now, before they
 see a wider adoption. These numbers might be going up because the prefixed
 APIs are also present on iOS.

 https://chromestatus.com/metrics/feature/timeline/popularity/166
 https://chromestatus.com/metrics/feature/timeline/popularity/167

 There is an alternative set of APIs supported by all browsers that web
 authors can use.

 The full history of the removal attempt is here: crbug.com/346236


 Goals for experimentation

 The primary goal of the deprecation trial is to reduce the amount of
 broken user-visible experiences as the prefixed fullscreen APIs are
 removed, and to give time to web authors to transition to the modern API
 (which has been available for 5 years).


 The un-prefixed fullscreen APIs have been available since Chrome M71.

 Experiment timeline

 TBD, with a proposed 3 months duration

 Blink component

 Blink>Fullscreen
 Blink>Media>Video

 TAG review

 None

 TAG review status

 Not applicable

 Risks
 Interoperability and Compatibility

 Web Compatibility:

 Removing non-standard APIs should overall help web compatibility, and
 encourage web authors to use the unprefixed APIs. Some 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

['Thomas Guilbert' via blink-dev]

Ok for a 6 months trial, with the possibility to extend it further. I will
wait for the remaining security/privacy approvals and then update this
thread again.

Additionally, someone commented on the WebKit positions standards thread

that
the next version of Safari will have support for the fullscreen API (still
subject to change before shipping). It would be great timing if the API
ships on iOS, to minimize the work for web authors as they switch away from
the API.

On Fri, Jan 26, 2024 at 6:26 AM Philip Jägenstedt 
wrote:

> https://sites.google.com/a/chromium.org/dev/blink/launching-features
> doesn't give any guidance on the timeline, so let's just pick a timeline
> that makes sense for this case. It's been up to a year in other cases.
>
> Since feature detection is common, we have to remove the whole API surface
> and let code that depends on it throw exceptions. We won't be able to print
> anything helpful to the console informing developers that there is a
> deprecation trial. From their point of view it will simply be removed, and
> they might find out about the deprecation trial if they do some further
> research.
>
> Since the cost of supporting these APIs is very low, I think we
> should give developers plenty of time. But usage is already so low that
> it's not a certainty that anyone will really use the trial. So how about we
> start with 6 months, and if we see that there are sites using the trial to
> re-enable the feature, then we extend it by another 6 months. Would that
> work?
>
> On Thu, Jan 25, 2024 at 9:22 PM Thomas Guilbert 
> wrote:
>
>> Thank you Wesley for the useful information!
>>
>> > What timeline do you have in mind?
>> I'm not sure what reasonable timelines are, not having dealt with
>> deprecations before. Is 3 months for a deprecation trial acceptable?
>> Devtools should already have deprecation warnings
>> ,
>> but I don't see them in my console.
>>
>> I had looked at the only site listed for the
>> https://chromestatus.com/metrics/feature/timeline/popularity/170
>> use-counter. They are directly calling the API for their overlay welcome
>> video, but the page seemed to work fine with the API disabled. I don't
>> think the fullscreen actually happens, without the user interaction...
>>
>> This use counter shows a spike up from December to January
>> https://chromestatus.com/metrics/feature/timeline/popularity/168. 5
>> links are using https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js, one
>> link is also playing an overlay video intro.
>>
>> On Thu, Jan 25, 2024 at 12:25 AM Philip Jägenstedt 
>> wrote:
>>
>>> I'm also happy to support a plan to deprecate and remove. The use
>>> counter that best represents worst-case user impact at
>>> https://chromestatus.com/metrics/feature/timeline/popularity/170 at
>>> ~0.001%. But that's only when fullscreen actually happens (on user
>>> interaction) and it's very hard to say what proportion of sites could
>>> *potentially* hit this code path, especially given the ubiquitous
>>> pattern of trying multiple API names that's been necessary forever with
>>> fullscreen, so that some sites will just fall back to a working API.
>>>
>>> What timeline do you have in mind?
>>>
>>> On Thu, Jan 25, 2024 at 2:19 AM Domenic Denicola 
>>> wrote:
>>>
 Thanks Thomas for all your work here! Your HTTP Archive survey seems
 promising to me: it sounds like there are no regressions, and you found
 some great places to perform outreach. (Hi Wesley!)

 I'm happy to LGTM this as soon as the privacy/security reviews are
 approved and you've picked a target experiment timeline.

 On Thu, Jan 25, 2024 at 10:00 AM Wesley Luyten 
 wrote:

> Wesley from Mux here. I saw the issue come by.
>
> We'd be happy those API's could get deprecated and unified into the
> new one.
>
> Our Media Chrome (library, not browser) implementation handles this
> gracefully, some code here
>
> https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636
>
> The Vimeo player uses a variant of
> https://github.com/bdougherty/BigScreen, a similar popular library is
> https://github.com/sindresorhus/screenfull
>
> Just thought to mention it but iOS never supported the generic
> fullscreen API until very recent
> https://twitter.com/jensimmons/status/1717937227190460797
> It always required the webkit prefixed API on the video element (not
> any other element like a div etc )
> Y'all are aware of that?
> On Wednesday, January 24, 2024 at 6:23:16 PM UTC-6 Thomas Guilbert
> wrote:
>
>> I opened a support ticket with Mux, and opened an issue for 

[blink-dev] Intent to Implement & Ship: AudioEncoderConfig.bitrateMode

['Thomas Guilbert' via blink-dev]

Contact emails

tguilb...@google.com

Explainer

None

Specification

https://w3c.github.io/webcodecs/#dom-audioencoderconfig-bitratemode

Summary

Some audio codecs support specifying the audio encoder bitrate modes. This
feature adds a "bitrateMode" flag with a default value of “variable” to
WebCodec's AudioEncoderConfig, which mirrors the functionality already
present for VideoEncoderConfig
.

This flag will allow web authors to choose between encoding audio with a
variable bitrate or a constant bitrate. Specific codec encoder
implementations might have slightly different terminology (e.g. `CBR` vs
`VBR` for Opus), but all of them should map to the general concept of
"constant" versus "variable" bitrate.

The two options have the following effects:

   -

   “variable”:  allows an audio encoder to increase or lower its bitrate
   according to the content of the audio it is encoding, in order to preserve
   bandwidth/binary-size, while still maintaining a target quality. For
   example, an encoder might lower its bitrate when encoding silence, and
   revert to a full bitrate when encoding speech.
   -

   “constant” : forces an audio encoder to maintain the same bitrate,
   regardless of the audio content. This can be useful when a predictable
   bandwidth consumption is preferable.


As of M118, this flag will affect two codecs on Chromium: Opus and AAC.



Blink component

Blink>Media>WebCodecs

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The risk is low. Firefox has not yet shipped WebCodecs, but is currently
developing it. Safari has developed video WebCodecs, but not yet audio. The
flag should be easy for other browsers to add as they implement WebCodecs.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/837)

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

Web developers: Positive, as feature was originally a developper request –
https://github.com/w3c/webcodecs/issues/649

Other signals:

WebView application risks

This change does not deprecate existing APIs, and only supplements existing
APIs, with a sensible default. This should not be a WebView risk.



Debuggability



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

?

It will be at the time it is implemented. Example test

.

Flag name on chrome://flags

N/A

Finch feature name

N/A


Non-finch justification

Simple parameter change

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

Shipping on desktop

118

Shipping on Android

118

Anticipated spec changes

None



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5084320053592064

-- 
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/CABrVPoak2%3DgxnREAhxe83D-BpSD0xF%3DnRFDbSiS8qrF0ZBQB7A%40mail.gmail.com.