Intent to Ship: Add support for encoding CBR audio files with `MediaRecorder`.

191 views
Skip to first unread message

Simon Jackson

unread,
Jul 27, 2020, 5:30:39 PM7/27/20
to blin...@chromium.org
C simon....@sonocent.com https://github.com/w3c/mediacapture-record/pull/185 https://github.com/w3c/mediacapture-record/issues/183 https://chromium-review.googlesource.com/c/chromium/src/+/1731907 https://w3c.github.io/mediacapture-record/#mediarecorder-api Not needed The `MediaRecorder` spec was recently updated to allow either constant bitrate (CBR) or variable bitrate (VBR) encoding to be specified with `MediaRecorderOptions`, previously VBR was assumed when using anything other than uncompressed PCM. This change adds support for the updated specification and for enabling the hard CBR mode of the Opus encoder when CBR mode is configured for the `MediaRecorder`. https://github.com/w3c/mediacapture-record/pull/185
This is now in the editors draft https://w3c.github.io/mediacapture-record/#mediarecorder-api Gecko: No signal WebKit: No signal Web developers: No signals
No No There is currently no coverage this specification update; however, I have opened an issue to add it: https://github.com/web-platform-tests/wpt/issues/24666 https://bugs.chromium.org/p/chromium/issues/detail?id=980559 https://chromestatus.com/feature/5730124735447040
This intent message was generated by Chrome Platform Status.

PhistucK

unread,
Jul 28, 2020, 5:22:38 AM7/28/20
to Simon Jackson, blink-dev
To expand a bit, this will be adding a new audioBitrateMode field with the BitrateMode enum value of "cbr" or "vbr" to MediaRecorder instances and to the constructor options - new MediaRecorder(steam, {audioBitrateMode: "cbr"}).

☆PhistucK


--
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/CAAZh%2BM2VAD3pmhuknj69J6hWaTn%2BHWQZ_7EYqUGnPpbSVy%3DdYA%40mail.gmail.com.

Yoav Weiss

unread,
Jul 28, 2020, 8:48:51 AM7/28/20
to Simon Jackson, blink-dev
Thanks for working on this!

These are not a replacement for an explainer.
I'm also missing a TAG review (or justification as to why one is not required)

 
https://w3c.github.io/mediacapture-record/#mediarecorder-api Not needed The `MediaRecorder` spec was recently updated to allow either constant bitrate (CBR) or variable bitrate (VBR) encoding to be specified with `MediaRecorderOptions`, previously VBR was assumed when using anything other than uncompressed PCM. This change adds support for the updated specification and for enabling the hard CBR mode of the Opus encoder when CBR mode is configured for the `MediaRecorder`. https://github.com/w3c/mediacapture-record/pull/185
This is now in the editors draft https://w3c.github.io/mediacapture-record/#mediarecorder-api

Could you elaborate on the compatibility and interoperability risks?:
  • Are other browser engines likely to implement this functionality as well? 
  • Are there risks for content breaking by us supporting this? (I'm guessing "no") 
  • Are there risks for content breaking in other browsers if we were to ship this before them? 
  • Does the feature have feature detection mechanisms? 
  • Does it gracefully fallback when not supported?

 
Gecko: No signal WebKit: No signal Web developers: No signals

Signals (or at least asking for them) are now required. See this document.

No No There is currently no coverage this specification update; however, I have opened an issue to add it: https://github.com/web-platform-tests/wpt/issues/24666 https://bugs.chromium.org/p/chromium/issues/detail?id=980559 https://chromestatus.com/feature/5730124735447040
This intent message was generated by Chrome Platform Status.

--

Yoav Weiss

unread,
Jul 30, 2020, 7:29:31 AM7/30/20
to Simon Jackson, blink-dev


On Thu, Jul 30, 2020 at 12:28 PM Simon Jackson <simon....@sonocent.com> wrote:
Hi, 

Thanks for the response, I've never filled one of these in before and I wasn't really sure what to put for a fair few of the fields so I just made a best guess to start with. I now know what a TAG review is after some googling, but I'm not clear on whether or not this change needs one. Is there some criteria which indicate when one is required, or is the process to request one and they'll tell you if you don't require one?

There's no clear cut criteria - in this case the feature seems like something that might benefit from a review.
 

Thanks,
Simon

Simon Jackson

unread,
Jul 30, 2020, 7:49:35 PM7/30/20
to Yoav Weiss, blink-dev
I've updated the chromestatus with more information on the compatibility risks and an explainer link as requested, but I won't repost the form until I've added the rest of the requested details. I'm about to look into signals and requesting a TAG review, but in the meantime here is my attempt at an explainer: https://docs.google.com/document/d/10OheBob6lP7v-fO89g0A5F9BYnsMEU5Nkh4p-Bk0wMg/edit?usp=sharing

Simon Jackson

unread,
Jul 30, 2020, 7:49:56 PM7/30/20
to Yoav Weiss, blink-dev
Hi, 

Thanks for the response, I've never filled one of these in before and I wasn't really sure what to put for a fair few of the fields so I just made a best guess to start with. I now know what a TAG review is after some googling, but I'm not clear on whether or not this change needs one. Is there some criteria which indicate when one is required, or is the process to request one and they'll tell you if you don't require one?

Thanks,
Simon


On Tue, 28 Jul 2020 at 13:48, Yoav Weiss <yo...@yoav.ws> wrote:

Simon Jackson

unread,
Jul 31, 2020, 7:29:38 PM7/31/20
to Yoav Weiss, blink-dev
simon....@sonocent.com https://docs.google.com/document/d/10OheBob6lP7v-fO89g0A5F9BYnsMEU5Nkh4p-Bk0wMg/edit?usp=sharing https://w3c.github.io/mediacapture-record/#mediarecorder-api https://github.com/w3ctag/design-reviews/issues/540 Adds support for hard constant bitrate (CBR) mode of the Opus encoder when CBR mode is used for MediaRecorder. Without this change it is impossible to encode compressed constant bitrate audio files with the MediaRecorder. This implements a spec change allowing either constant bitrate (CBR) or variable bitrate (VBR) encoding on the MediaRecorderOptions object passed to the MediaRecorder constructor. Previously VBR was assumed when using anything other than uncompressed PCM. https://github.com/w3c/mediacapture-record/pull/185
This is a small change to the specification consisting of only adding a new property to MediaRecorder to retrieve the current bitrate mode and the ability to configure the bitrate mode using MediaRecorderOptions. Due to the small size of the change and the fact that it has already been through the PR process for inclusion into the editors draft, I feel that it is unlikely that other browsers will be unwilling to implement support. This change only affects the behaviour of encoding audio streams and the new option will be ignored if it is not yet supported. The default behaviour is also specified such that there will be no change in behaviour to the MediaRecorder if the new option is not configured/set by a user in browsers which do support the option. This is now in the editors draft https://w3c.github.io/mediacapture-record/#mediarecorder-api Gecko: No signal (https://github.com/mozilla/standards-positions/issues/414) WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-July/031317.html) Web developers: No signals
No No There is currently no coverage this specification update; however, I have opened an issue to add it: https://github.com/web-platform-tests/wpt/issues/24666 https://bugs.chromium.org/p/chromium/issues/detail?id=980559 https://chromestatus.com/feature/5730124735447040

Harald Alvestrand

unread,
Aug 19, 2020, 8:09:20 AM8/19/20
to Simon Jackson, Yoav Weiss, blink-dev
I can confirm that this has been discussed in the WEBRTC WG, and that there was no real opposition to adding the feature there (and the shape was revised based on discussion).
I don't know if it is valuable enough to make for wide usage, but it is a small API surface change with a good backwards compatibility story.

I don't see a reason to block it at this point.
(The implementation is available as a CL, but not landed yet.)


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZh%2BM0_TLKRQSiST6bjaYssxkf4SZ-enDcANnk38a_z%2BoMe9Q%40mail.gmail.com.

Yoav Weiss

unread,
Aug 19, 2020, 8:27:50 AM8/19/20
to Harald Alvestrand, Simon Jackson, blink-dev
LGTM1


On Wed, Aug 19, 2020 at 2:09 PM Harald Alvestrand <h...@google.com> wrote:
I can confirm that this has been discussed in the WEBRTC WG, and that there was no real opposition to adding the feature there (and the shape was revised based on discussion).
I don't know if it is valuable enough to make for wide usage, but it is a small API surface change with a good backwards compatibility story.

Thanks Harald! That's helpful context

Chris Harrelson

unread,
Aug 19, 2020, 1:28:42 PM8/19/20
to Yoav Weiss, Harald Alvestrand, Simon Jackson, blink-dev
LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgCpAcrzxtxR4fbO77-mCTp7VO%2BjdUE965zr%3Dom74AgNw%40mail.gmail.com.

Daniel Bratell

unread,
Aug 20, 2020, 2:49:55 PM8/20/20
to blink-dev, Chris Harrelson, Harald Alvestrand, Simon Jackson, blink-dev, yo...@yoav.ws
LGTM3
Reply all
Reply to author
Forward
0 new messages