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
AudioEncoderConfig.latencyMode (or similar) #371
Comments
60 ms is too high as a default for RTC. There's a quite noticeable difference to use 20 ms frames. I think it could be useful with a frame size knob instead of a latencyMode that implicitly controls the frame size. It can be useful to increase the frame size to 60-120 ms when the bitrate is low (10-16 kbps) in order to reduce packet overhead. It's possible to also do that in the transport layer though, by aggregating frames into a single packet, so the question is if there are compression gains of using larger frame sizes. |
Here are my proposals with some context. Do not add AudioEncoderConfig.frameSize
Add OpusEncoderConfig.frameSize
Do not add AudioEncoderConfig.latencyMode (yet)
I'd love to hear if there are objections to adding |
we recommend use frameDuration/ptime in miiliseconds is more suitable, The parameter we need actually is duration per frame, this called ptime(packet time)in sdp rfc8866 6.4 , |
Thanks! I did intend Naming the parameter I am not an Opus expert though. If others have a strong preference for one or the other, both seem fine to me. |
for opus encoder, the frameSize actually is encoder buffer size , it's determined by sampleRate channel numbers and frameDuration. |
From TPAC: No pushback on this issue. Adding frameDuration seems good. I would let the spec editors adopt this PR. |
VideoEncoderConfig has latencyMode (#269).
AudioEncoder has similar concerns around latency (realtime) vs quality. For example, Chrome's opus encoder currently uses 60ms buffers (framesize) to maximize quality. This is in keeping with our default philosophy of "don't constrain features/quality unless the user asks for it". But we should offer realtime users a way to choose a lower-latency value.
An alternative would be to specify a more granular knob for just framesize. Or do both.
The text was updated successfully, but these errors were encountered: