[opus] Antw: [EXT] Re: Multithreaded encoding?

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Tue Mar 31 06:24:20 UTC 2020

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht
<11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum
> 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?

The original requestor did not mention whether the application is real-time or not: For non-real-time (i.e.: batch encoding), on n CPUs, would it work to divide the stream in n parts, encode each of theose (with some non-optimal encoding maybe) and then "join" the parts to one stream?


> On 2020-03-29 5:47 p.m., Jesus Cea wrote:
>> I am interested in being able to encode a single Opus stream using
>> several CPU cores.
>> I get a raw audio input and "opusenc" can transcode it at 1200% speed
>> (Raspberry PI 3B+). It saturates a single CPU core, but the other three
>> are idle.
>> Is out there any project to add multithreading options to "opusenc", or
>> something in that line?
>> Looking around, I have found this:
>> https://github.com/enzo1982/superfast#superfast-codecs 
>> https://hydrogenaud.io/index.php?topic=114598.0 
>> <https://github.com/enzo1982/superfast/blob/master/doc/SuperFast%20Codecs.pdf>
>> Is it out there any other multithreaded "opusenc" drop in replacement?.
>> Any plan for future "opusenc" improvement in this area?
>> Thanks.
>> _______________________________________________
>> opus mailing list
>> opus at xiph.org 
>> http://lists.xiph.org/mailman/listinfo/opus 
> _______________________________________________
> opus mailing list
> opus at xiph.org 
> http://lists.xiph.org/mailman/listinfo/opus 

More information about the opus mailing list