-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add audioConstantBitRate
flag to MediaRecorderOptions
.
#185
Conversation
WRT IPR checks, this PR is a follow on from https://chromium-review.googlesource.com/c/chromium/src/+/1731907 |
Unfortunately the IPR check is the W3C IPR check, not the Google IPR check. |
No it isn't, sorry. |
So what do I need to do WRT IPR? |
hi @sizeak, can you get in touch with me at dom@w3.org? This will help explore the possibilities. |
Thank you @sizeak for providing separately the proper IPR commitment - the IPR error can be safely ignored for this pull request at this time (I'll work in actually clearing it, but don't want to block this discussion on this) |
Thanks for helping with the IPR stuff. Does anyone have any thoughts on adding the flag? |
Hi, Sorry to keep pestering, but this is something causing us pain in live. How do we move this forward? Thanks |
It seems innocent to me, but I don't know about implementation details. An audio MediaStreamTrack is something playing live, do we always have enough samples and can we always transform it to a constant bitrate. @ivocreusen Can you comment on the idea of recording (through the MediaRecorder API) i.e. encoding at a constant bitrate? Context: general API about encoding a track, not specific to WebRTC. |
Can't this be set with |
That was my suggestion to the Chrome team in the PR linked at the top of this thread, but the file owner said it was a hack. Here is the relevant quote from the PR:
|
My inclination is to say this is a supported feature, not a hack. Open to hear arguments to the contrary. @Pehrsons thoughts? |
To clarify: adding API surface to cover everything that can already be set through |
I'll feed back the reaction here to the original Chrome PR and see if the developer that objected would like to weigh in, unless you would be willing to make the case for the |
@sizeak Feel free to point them here. |
Hi group, the comment was from me. I maintain the media mime parsing code in Chrome and I work on the MediaCapabilities spec where mime/codec strings are a key input. Both recording and playback operate on codecs in containers. Right now, when it comes to opus at least, we are unified in the the way its described. To date, "opus.cbr" is not a valid codec string. All UAs that support opus playback implicitly support both cbr and vbr, but querying any playback API's (canPlayType(), MediaCapabilities, isTypeSupported()) with "opus.cbr" will get a return value that indicates non-support (because they don't recognize it). The need to signal CBR support is specific to the domain of MediaRecorder, and not necessarily specific to opus. Adding an attribute that is external to the codec string solves the issue and avoids the pitfalls above. |
MediaRecorder.bs
Outdated
@@ -580,6 +580,7 @@ dictionary MediaRecorderOptions { | |||
unsigned long audioBitsPerSecond; | |||
unsigned long videoBitsPerSecond; | |||
unsigned long bitsPerSecond; | |||
boolean audioConstantBitRate; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: maybe call it BitsPerSecond to match the other members
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BitsPerSecond
is a bit verbose, especially in the case of audioConstantBitsPerSecond
, but you are right that it would be better to be consistent. Will update.
@chcunningham Thanks for clarifying. I was missing this important detail. In that case I agree |
Thanks for commenting @chcunningham, I think I'm in agreement too now. I hadn't considered this:
While I don't think there is an official spec for the Opus mimetype (although there may be something browser specific), I interpreted https://tools.ietf.org/html/rfc6381#page-8 as allowing "opus.cbr", but I hadn't stopped to consider that it would be meaningless specifying it in regards to anything other than an encoder, which does make it feel a bit hacky. |
I'm a bit torn about adding attributes this way because if one were to add support for all encoder capabilities we'd get a very large struct, without any apparent structure. Unfortunately there's precedence through the BitsPerSecond attributes. To be pragmatic and to set a precedence that hopefully avoids painting us too far into potential future corners, I suggest we change it to Likewise for video since we're adding the spec language for this anyway. I think this should use slots in the ctor algorithm like is done for the BitsPerSecond init dict attributes, because the start algorithm (where these attributes should be used to constrain the configuration of the recorder) doesn't have access to the init dict. We should probably say something on what is allowed if the UA for some reason does not support a given mode. |
So would everybody be happy with this:
|
I want to see
Otherwise LGTM at a high level. |
BitrateMode sounds good to me. |
Replace the single audioConstantBitsPerSecond field with a BitrateMode enum and fileds for audio and video bitrate mode using this enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept lgtm. Just need to flesh out some details.
Are you happy with the changes @Pehrsons ? |
@simoncent he's going to be out for a while, but I don't think he would object. Will try to get this merged Thursday. |
Ah sorry, I didn't realise. That would be great, thanks! |
Ran out of time during the editor's meeting unfortunately. I'm ok with merging this. @henbos @alvestrand do you see any reasons we shouldn't? |
I am fine with CBR for audio, I am less sure about video. |
MediaRecorder.bs
Outdated
@@ -283,6 +303,14 @@ interface MediaRecorder : EventTarget { | |||
the value might be surpassed, not achieved, or only be achieved over a long | |||
period of time.</li> | |||
|
|||
<li>Constrain the configuration of |recorder| to encode using the | |||
{{BitrateMode}} specified by the value of |recorder|'s {{videoBitrateMode}} | |||
attribute for all video tracks |recorder| will be recording.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this make sense for video?
I think CBR is fairly widespread for audio, but more rare wrt video (most encoders require heavy dynamic tuning to produce CBR). I'm happy with merging the audio CBR value now, and revisitng the question of whether we want video CBR later. |
will split out video for now, fix order bug, and merge. |
Fixes #183 |
This pull request is to add the ability to specify that a constant bitrate audio file should be encoded, as detailed in #183