[opus] Multithreaded encoding?
Timothy B. Terriberry
tterriberry at mozilla.com
Tue Mar 31 03:25:14 UTC 2020
Jesus Cea wrote:
> On 30/3/20 23:17, Ralph Giles wrote:
>> I'm not aware of any other attempts, and there have never been official
>> plans. It's difficult to partition input for opus at anything other than
>> the track level, because of the way the decoder derives its adaptive
>> state from recently-seen audio. I guess cutting together streams with at
>> least an 80ms overlap wouldn't glitch too much?
> According to the Opus standard, after 80 ms the encoding would converge.
> That is, only the previous 80 ms of audio would be needed to get a
> perfectly merged stream. You could play safe and do, lets say, 200 ms
> For example, read https://wiki.xiph.org/OggOpus .
> Efficiency is quite nice:
> 1 second fragments: 92%
> 10 seconds fragments: 99.2%
The 80ms is just a guideline, and not a guarantee that we have
exhaustively checked will always work. Also, it's for decoding (e.g.,
during seeking), not encoding. Still, probably good?
However, you can do this with essentially one frame of overlap, as
described in https://tools.ietf.org/html/rfc7845.html#section-7.2
There is an implementation of this joining in libopusenc, although it is
not currently, I believe, set up for multithreading.
However, keep in mind, this results in a chained file. These do not
necessarily have the greatest software support everywhere. Anything that
implements its Opus support via the opusfile library should be fine
(unless they made some assumptions in their use of the API that chaining
would violate; it's intentionally not completely transparent). Not
everything else handles it as gracefully. There is also some seeking
overhead when opening the file for implementations that want to know the
total file duration (like opusfile). opusfile tries to be pretty good
about this, but with a lot of links in your chain, it is more than a few
More information about the opus