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

[Ulrich Windl]

>>> 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
s.net>:
> 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