Constant bitrate audio encoding with MediaRecorder

[sizeak]

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.

• Explainer¹ (minimally containing user needs and example code): https://docs.google.com/document/d/10OheBob6lP7v-fO89g0A5F9BYnsMEU5Nkh4p-Bk0wMg/edit#heading=h.ii9q6v4v8ty2
• Specification URL: https://w3c.github.io/mediacapture-record/#mediarecorder-api
• Tests: Add coverage for audioBitrateMode property of MediaRecorder. web-platform-tests/wpt#24666
• Security and Privacy self-review²: https://docs.google.com/document/d/1TAN9YaCwXpHlZ4ZgirnoKf_MO_sxBwWYo1f9GsiSRdE/edit?usp=sharing
• GitHub repo (if you prefer feedback filed there): Add audioConstantBitRate flag to MediaRecorderOptions. w3c/mediacapture-record#185
• Primary contacts (and their relationship to the specification):
  • @simoncent, @jan-ivar, @alvestrand
• Organization(s)/project(s) driving the specification: W3C WebRTC Working Group
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Pull request to editors draft: Add audioConstantBitRate flag to MediaRecorderOptions. w3c/mediacapture-record#185
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chrome status: https://chromestatus.com/feature/5730124735447040
  • Mozilla standards position request: Constant bitrate audio encoding with MediaRecorder mozilla/standards-positions#414

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

[hober]

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.

[hober]

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.

[sizeak]

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!

[hober]

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.

[cynthia]

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!

[sizeak]

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.