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

2023-08-23 Thread Manuel Rego Casasnovas 
LGTM3

On 22/08/2023 16:30, Mike Taylor wrote:
> LGTM2
> 
> On 8/22/23 10:10 AM, Yoav Weiss wrote:
>> LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being
>> supportive.
>>
>> On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev
>>  wrote:
>>
>> 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
>> 
>>
>>
>> -- 
>>

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

2023-08-22 Thread Mike Taylor 

LGTM2

On 8/22/23 10:10 AM, Yoav Weiss wrote:
LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being 
supportive.


On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev 
 wrote:


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

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

2023-08-22 Thread Yoav Weiss 
LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being
supportive.

On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev <
blink-dev@chromium.org> wrote:

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

-- 
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/CAL5BFfWxNYG8%2BiEnse%3DaHvWSdX%2BMnvfaURaxTxWGgthx8n0jNQ%40mail.gmail.com.

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

2023-08-17 Thread '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.