#540: Constant bitrate audio encoding with MediaRecorder

Visit on Github.

Opened Jul 30, 2020

Hey TAG!

I'm requesting a TAG review of MediaRecorder support for constant & variable encoding bitrate modes.

MediaRecorder does not currently provide a way of specifying whether to encode constant or variable bitrate audio files, variable bitrate is assumed except in the case of uncompressed PCM.

The linked pull request updates the editors draft to allow either constant or variable bitrate encoding to be specified to the MediaRecorder through a new field on MediaRecorderOptions. A property is also added to the MediaRecorder to retrieve the current bitrate mode setting.

Further details:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: No hard deadline, just asap.
  • The group where the work on this specification is currently being done: WebRTC WG
  • Major unresolved issues with or opposition to this specification: None.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @simoncent

Discussions

Discussed Aug 24, 2020 (See Github)

Tess: Very straightforward change to let authors request a bitrate mode, and also query what the bitrate mode is.

... Nice, straightforward proposal, good use cases.

... Only one quibble: Bitrate mode enum values are "vbr" and "cbr". I know what those mean, but it's obscure. It should be "constant" and "variable". The "bitrate" is already part of the API. I'll write that out in a comment.

Alice: Also it's hard to distinguish "v" and "b" via audio.

Tess: Right. I'll comment; Sangwhan might have additional concerns, so don't want to immediately close

Comment by @hober Aug 24, 2020 (See Github)

Hi @simoncent,

Thanks for bringing this to us. Overall, this looks like a very reasonable, incremental API improvement to me. I have one concern, with the values of your BitrateMode enum:

enum BitrateMode {
  "cbr",
  "vbr"
};

Maybe don't abbreviate these? I think "constant" and "variable" could be clearer to folks, and are easier to hear correctly when someone speaks them. See also our advice on naming, in particular Use common words.

Comment by @hober Aug 24, 2020 (See Github)

Also, we generally recommend that folks make their explainers available in Markdown or HTML; Google Docs is not globally accessible, but participants in web standards are.

Comment by @sizeak Aug 25, 2020 (See Github)

Hi @simoncent,

Thanks for bringing this to us. Overall, this looks like a very reasonable, incremental API improvement to me. I have one concern, with the values of your BitrateMode enum:

enum BitrateMode {
  "cbr",
  "vbr"
};

Maybe don't abbreviate these? I think "constant" and "variable" could be clearer to folks, and are easier to hear correctly when someone speaks them. See also our advice on naming, in particular Use common words.

That sounds reasonable to me, I'll open a PR to update the editors draft with the change.

Also, we generally recommend that folks make their explainers available in Markdown or HTML; Google Docs is not globally accessible, but participants in web standards are.

Thanks for the tip, are you highlighting this for future reference or are you requesting that I replace the explainer for this issue?

Thanks for your time!

Comment by @hober Sep 23, 2020 (See Github)

Maybe don't abbreviate these? I think "constant" and "variable" could be clearer to folks, and are easier to hear correctly when someone speaks them. See also our advice on naming, in particular Use common words.

That sounds reasonable to me, I'll open a PR to update the editors draft with the change.

Thanks! I haven't been able to track this PR down; did you file it?

Also, we generally recommend that folks make their explainers available in Markdown or HTML; Google Docs is not globally accessible, but participants in web standards are.

Thanks for the tip, are you highlighting this for future reference or are you requesting that I replace the explainer for this issue?

Both, I think.

Comment by @cynthia Sep 24, 2020 (See Github)

We left an issue on your end - but the group is happy with the proposal and think this can be closed. Thanks for bringing this to our attention!

Comment by @sizeak Oct 13, 2020 (See Github)

Maybe don't abbreviate these? I think "constant" and "variable" could be clearer to folks, and are easier to hear correctly when someone speaks them. See also our advice on naming, in particular Use common words.

That sounds reasonable to me, I'll open a PR to update the editors draft with the change.

Thanks! I haven't been able to track this PR down; did you file it?

No, sorry I haven't gotten to it yet, I haven't forgotten about it though, it's on my list. I will post a link here when I open it.

Also, we generally recommend that folks make their explainers available in Markdown or HTML; Google Docs is not globally accessible, but participants in web standards are.

Thanks for the tip, are you highlighting this for future reference or are you requesting that I replace the explainer for this issue?

Both, I think.

OK, thanks, I'll look into replacing it when I get time.