opus - Mar 2020 - Antw: [EXT] Re: Multithreaded encoding?

>>> 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

On 2020-03-30 11:24 p.m., Ulrich Windl wrote:
> 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?
I think that's what they were suggesting. I assumed it wasn't realtime
because they mentioned it was already running at 12x and wanted it to go
faster. So 'batch' encoding but optimized for time-to-completion on a
single stream.

 -r

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20200331/5edd80db/attachment.sig>