Intent to Implement & Ship: AudioEncoderConfig.bitrateMode
Thomas Guilbert
Contact emails
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
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
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5084320053592064
Yoav Weiss
--
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/CABrVPoak2%3DgxnREAhxe83D-BpSD0xF%3DnRFDbSiS8qrF0ZBQB7A%40mail.gmail.com.
Mike Taylor
LGTM2
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.
Manuel Rego Casasnovas
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
>> <blin...@chromium.org> wrote:
>>
>> Contact emails
>>
>> tgui...@google.com
>>
>>
>> Explainer
>>
>> None
>>
>>
>> Specification
>>
>> https://w3c.github.io/webcodecs/#dom-audioencoderconfig-bitratemode
>>
>> <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
>> <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
>> <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
>> --
>> 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
> --
> 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