Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus decoding complexity (Read 2002 times) previous topic - next topic
0 Members and 9 Guests are viewing this topic.

Opus decoding complexity

Hello. Assume the maximum possible complexity of a non-freeformat MP3 decoding process is X, what is the roughly maximum possible decoding complexity of non-custom Opus in X (2x, 5x, 10x etc)? Opus is described as a hero but i'm afraid it is very complex and hard.

Re: Opus decoding complexity

Reply #1 –
Define "complexity".

If decoding speed is a sufficient proxy, then it's easy to test this with foobar2000 (this assumes software decoding; specialized hardware will affect the speed), but there's lots of variables that could affect decoding speed.  My extremely rough benchmarking shows that decoding Opus files is about 1/2 as fast as a Lame-encoded MP3 of approximately the same average bitrate.

Single-threaded decoding test (3 passes)
MP3 (Lame 3.100 V2) is 1058x realtime
Opus (1.4) is 539x realtime

MP3:
Code: [Select]
System:
  CPU: AMD Ryzen 9 3900X 12-Core Processor, features: MMX SSE SSE2 SSE3 SSE4.1 SSE4.2 AVX LZCNT
  Architecture: x64
  App: foobar2000 v2.1.4
Settings:
  High priority: no
  Buffer entire file into memory: yes
  Warm-up: yes
  Passes: 3
  Threads: 1
  Postprocessing: none
Stats by codec:
  MP3: 1058.144x realtime
File: Rule 5 - James Picard.mp3
  Run 1:
    Decoded length: 3:14.640
    Opening time: 0:00.001
    Decoding time: 0:00.184
    Speed (x realtime): 1054.937
  Run 2:
    Decoded length: 3:14.640
    Opening time: 0:00.001
    Decoding time: 0:00.184
    Speed (x realtime): 1055.695
  Run 3:
    Decoded length: 3:14.640
    Opening time: 0:00.001
    Decoding time: 0:00.182
    Speed (x realtime): 1063.845
  Total:
    Opening time: 0:00.001 min, 0:00.001 max, 0:00.001 average
    Decoding time: 0:00.182 min, 0:00.184 max, 0:00.183 average
    Speed (x realtime): 1054.937 min, 1063.844 max, 1058.143 average
Total:
  Decoded length: 9:43.920
  Opening time: 0:00.002
  Decoding time: 0:00.550
  Speed (x realtime): 1058.144

Opus:
Code: [Select]
System:
  CPU: AMD Ryzen 9 3900X 12-Core Processor, features: MMX SSE SSE2 SSE3 SSE4.1 SSE4.2 AVX LZCNT
  Architecture: x64
  App: foobar2000 v2.1.4
Settings:
  High priority: no
  Buffer entire file into memory: yes
  Warm-up: yes
  Passes: 3
  Threads: 1
  Postprocessing: none
Stats by codec:
  Opus: 539.492x realtime
File: Rule 5 - James Picard.opus
  Run 1:
    Decoded length: 3:14.640
    Opening time: 0:00.000
    Decoding time: 0:00.362
    Speed (x realtime): 537.041
  Run 2:
    Decoded length: 3:14.640
    Opening time: 0:00.000
    Decoding time: 0:00.360
    Speed (x realtime): 539.971
  Run 3:
    Decoded length: 3:14.640
    Opening time: 0:00.000
    Decoding time: 0:00.359
    Speed (x realtime): 541.482
  Total:
    Opening time: 0:00.000 min, 0:00.000 max, 0:00.000 average
    Decoding time: 0:00.359 min, 0:00.362 max, 0:00.361 average
    Speed (x realtime): 537.041 min, 541.482 max, 539.491 average
Total:
  Decoded length: 9:43.920
  Opening time: 0:00.000
  Decoding time: 0:01.082
  Speed (x realtime): 539.492

Re: Opus decoding complexity

Reply #2 –
@Heliologue Complexity is primarily speed and secondarily required RAM amount for me, and these results are already gave me an idea: Opus is not a hero. By the way, which foobar2000 component gives these results? Thank you.
 

Re: Opus decoding complexity

Reply #4 –
Rockbox.org comparison, only one single test of ADPCM, but:
FLAC being 80 percent faster. Than "Intel 4-bit IMA-ADPCM (adpcm-xq)", tested on Sansa Fuze+.
Is that IMA-ADPCM heavier than I thought, or just not so well optimized?

(Possibly relevant to the OP's thread at https://hydrogenaud.io/index.php/topic,125802 ... ? Edit: Damn me, it was already pointed out in that thread, I need reading glasses.)

Re: Opus decoding complexity

Reply #5 –
Quote from: Klymins on
Complexity is primarily speed and secondarily required RAM amount for me, and these results are already gave me an idea: Opus is not a hero. By the way, which foobar2000 component gives these results? Thank you.

I guess "hero" is subjective; if you're interested in the simplest possible codec, then no.  If you're looking for an open-source, royalty-free lossy codec that achieves transparency at a relatively low bitrate, then I would argue that it's an excellent choice. It's certainly popular with the crowd here at HA.

"Decoding speed test" is part of foo_ui_std, or at least it is in the 2.x series.  For me it exists under a context menu under "Utilities" (I honestly don't remember if that's default or not).

Re: Opus decoding complexity

Reply #6 –
Quote from: Klymins on
Hello. Assume the maximum possible complexity of a non-freeformat MP3 decoding process is X, what is the roughly maximum possible decoding complexity of non-custom Opus in X (2x, 5x, 10x etc)?

Roughly the same complexity as MP3. 

Re: Opus decoding complexity

Reply #7 –
@Heliologue Thanks. Of course it's subjective, but it even does not sound better than MP3 for music to me. @saratoga Looks like you're wrong. I did the decoding speed test myself and MP3 was way faster than Opus.

Code: [Select]
System:
  CPU: AMD Ryzen 5 3600 6-Core Processor, features: MMX SSE SSE2 SSE3 SSE4.1 SSE4.2 AVX LZCNT
  Architecture: x86
  App: foobar2000 v2.1.4
Settings:
  High priority: yes
  Buffer entire file into memory: yes
  Warm-up: yes
  Passes: 4
  Threads: 1
  Postprocessing: none
Stats by codec:
  MP3: 6381.428x realtime
  Opus: 1126.563x realtime
File: C:\Users\Klymins\Music\jkl.opus
  Run 1:
    Decoded length: 3:03.445
    Opening time: 0:00.001
    Decoding time: 0:00.163
    Speed (x realtime): 1123.691
  Run 2:
    Decoded length: 3:03.445
    Opening time: 0:00.000
    Decoding time: 0:00.162
    Speed (x realtime): 1129.944
  Run 3:
    Decoded length: 3:03.445
    Opening time: 0:00.000
    Decoding time: 0:00.162
    Speed (x realtime): 1130.042
  Run 4:
    Decoded length: 3:03.445
    Opening time: 0:00.000
    Decoding time: 0:00.163
    Speed (x realtime): 1122.618
  Total:
    Opening time: 0:00.000 min, 0:00.001 max, 0:00.000 average
    Decoding time: 0:00.162 min, 0:00.163 max, 0:00.163 average
    Speed (x realtime): 1122.618 min, 1130.041 max, 1126.563 average
File: C:\Users\Klymins\Music\jkl.mp3
  Run 1:
    Decoded length: 3:03.854
    Opening time: 0:00.000
    Decoding time: 0:00.029
    Speed (x realtime): 6342.310
  Run 2:
    Decoded length: 3:03.854
    Opening time: 0:00.000
    Decoding time: 0:00.029
    Speed (x realtime): 6375.277
  Run 3:
    Decoded length: 3:03.854
    Opening time: 0:00.000
    Decoding time: 0:00.028
    Speed (x realtime): 6405.395
  Run 4:
    Decoded length: 3:03.854
    Opening time: 0:00.000
    Decoding time: 0:00.028
    Speed (x realtime): 6403.142
  Total:
    Opening time: 0:00.000 min, 0:00.000 max, 0:00.000 average
    Decoding time: 0:00.028 min, 0:00.029 max, 0:00.029 average
    Speed (x realtime): 6342.310 min, 6405.395 max, 6381.428 average
Total:
  Decoded length: 24:29.196
  Opening time: 0:00.002
  Decoding time: 0:00.764
  Speed (x realtime): 1916.542

Edit: Both are 16kbps.

Re: Opus decoding complexity

Reply #8 –
Quote from: Klymins on
@saratoga Looks like you're wrong. I did the decoding speed test myself and MP3 was way faster than Opus.

Different devices (and software environments) have different capabilities and properties. The same applies to decoders.

On the sort of device where this would become a concern, a fixed-point Opus decoder is used (possibly with extra optimizations applied).
On a PC, a floating-point Opus decoder (slower, but more accurate) is often used.

libopus offers both variants. A native Opus decoder exists in FFmpeg too which is maybe floating-point only (not sure).

There are many MP3 decoders out there.

Not sure which decoders would have been used in your test.

Quote
Edit: Both are 16kbps.

Opus is basically two codecs in one, SILK and CELT. One of the two, or a hybrid, is maybe used internally. At 16kbps, SILK (optimized for low-bitrate voice content) was probably used. Hybrid is a possibility too depending on input parameters and content.  In any case, that test is not sufficient.

------

The way you're approaching this almost give the impression that you're trying to solve a puzzle or answer a pop quiz question. Maybe defining a practical use-case, testing for it, then asking questions if any arise, would be a better and more fruitful approach!

Re: Opus decoding complexity

Reply #9 –
@2012 Thank you, I still think Opus is not for me. By the way, which Opus codec is more similar to MP3?

Re: Opus decoding complexity

Reply #10 –
Quote from: Klymins on
@saratoga Looks like you're wrong. I did the decoding speed test myself and MP3 was way faster than Opus.

I'm not wrong, you're just confusing the speed of whatever decoder you tested for complexity.

Re: Opus decoding complexity

Reply #11 –
Decoding speeds:
FLAC  - 1090x
uncompressed WAV - 40000x

FLAC is 40x times slower than uncompressed WAV. "FLAC is not hero"

All smartphones with SOC on 28nm or better have the same battery life for playback of MP3, AAC, HE-AAC, Opus, Vorbis, Musepack, FLAC or uncompressed WAV. 
During audio playback CPU consumes only tiny fraction of complete system consumption (CPU, I/O, RAM, storage, DAC and  audio amplifier).

Decoding speed of audio decoder is not an indicator of battery life.
Complexity of decoder isn't an important subject by itself, rather its influence on usability indicators as battery life of devices.

Re: Opus decoding complexity

Reply #12 –
@btc I'm not asking about battery life.

Re: Opus decoding complexity

Reply #13 –
Then explain why complexity is issue.