Skip to content
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

Fixed audio chunk size support #405

Closed
Yahweasel opened this issue Nov 17, 2021 · 4 comments
Closed

Fixed audio chunk size support #405

Yahweasel opened this issue Nov 17, 2021 · 4 comments
Labels
extension Interface changes that extend without breaking. TPAC 2022 Issues to discuss in upcoming TPAC meeting

Comments

@Yahweasel
Copy link
Contributor

(Apologies if this has already been suggested. I couldn't find it.)

Some environments (muxers, protocols) require that each audio chunk contain some fixed number of samples, typically either 20ms worth or the same as some associated video framerate. In FFmpeg terms, this is the "frame size" of the encoder. It would be nice to, for such environments, be able to set a fixed chunk size in AudioEncoder.configure.

I propose adding an optional chunkSize field to AudioEncoderConfig that restricts the chunk sizes produced by the encoder. Ideally, chunkSize could be a ConstrainULong, since it's a restriction on the output rather than a property of the input, and that way a maximum or minimum could be set instead of an exact value. Since sampleRate is optional, chunkSize may need to be in microseconds instead of samples, or alternatively it may be sensible to make chunkSize only valid if sampleRate is provided. Naturally, isConfigSupported should reject the configuration if the audio codec doesn't support the requested frame size.

Alternatively, it could be encoded into the codec string, but it's not a standard part of codec strings in common MIME types (as far as I'm aware), so that would be a deviation from standards.

@padenot
Copy link
Collaborator

padenot commented Nov 22, 2021

This is probably a good encoder knob to have. As things stand today, this would really only be useful for Opus, right? Since the packet for most others are ~fixed.

@Yahweasel
Copy link
Contributor Author

This is probably a good encoder knob to have. As things stand today, this would really only be useful for Opus, right? Since the packet for most others are ~fixed.

Opus is certainly what was at the top of my mind :). FLAC also supports different frame sizes, but Chrome doesn't even support FLAC encoding (booooo), so Opus is the most relevant.

@chcunningham chcunningham added the extension Interface changes that extend without breaking. label Nov 30, 2021
@chcunningham chcunningham added the TPAC 2022 Issues to discuss in upcoming TPAC meeting label Jul 27, 2022
@chcunningham
Copy link
Collaborator

@tguilbert-google, FYI, putting TPAC labels on this and related bugs as these seem like great discussion topics for WebRTC : Media joint session (a chance to review the proposals you're working on).

@tguilbert-google
Copy link
Member

If I'm not mistaken, this was fixed for Opus in #551. I'm closing this issue for now. Please re-open if I'm missing something, or open a new issue for other codecs (e.g. FLAC, but there are no browsers supporting FLAC encoding for the moment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension Interface changes that extend without breaking. TPAC 2022 Issues to discuss in upcoming TPAC meeting
Projects
None yet
Development

No branches or pull requests

4 participants