[opus] Multithreaded encoding?

[Timothy B. Terriberry]

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
> overlapping.
> 
> 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 
seeks.