Opus Codec 1.1.1 Brings Encoder/Decoder Optimizations

[phoronix]

Phoronix: Opus Codec 1.1.1 Brings Encoder/Decoder Optimizations

Version 1.1.1 of the Opus audio codec was released this past week...

http://www.phoronix.com/scan.php?page=news_item&px=Opus-1.1.1-Released

[bug77]

That's nice and everything, but what does it really mean? Can we get better sound now?
Because I doubt many end users will care that someone shove 10ms off their encoding process or that the decoding uses 1 less microwatt.

Let me rephrase the initial question: are these just routine improvements or do they enable something bigger?

[Prescience500]

It means playing and encoding/decoding opus will use less CPU, RAM, and possibly take less time to encode. It might improve battery life ever so slightly. Unfortunately, we'll probably have to wait for version 1.2 or 2.0 for quality per bitrate improvements. I think it mostly matters for phones and maybe data centers.

[caligula]

That's nice and everything, but what does it really mean? Can we get better sound now?
Because I doubt many end users will care that someone shove 10ms off their encoding process or that the decoding uses 1 less microwatt.

Let me rephrase the initial question: are these just routine improvements or do they enable something bigger?

So are you basically against software development? The code is already so good that anyone who improves it should be beheaded?

[Tomin]

I just looked at the News section on Opus homepage and there was releases like 1.1 and 1.1.1 so I wonder if their next release is 1.1.1.1. And after that comes 1.1.1.1.1.

[Prescience500]

I just looked at the News section on Opus homepage and there was releases like 1.1 and 1.1.1 so I wonder if their next release is 1.1.1.1. And after that comes 1.1.1.1.1.

That could be an easy April Fool's joke, lol.

[bug77]

So are you basically against software development? The code is already so good that anyone who improves it should be beheaded?

What gave you the idea I'm against anything? I just asked if these are some purely technical improvements or whether making SSE more pervasive we can now use more advanced profiles (for example). Because copy/pasting a changelog makes for a quick, but sometimes incomplete story.

[Namenlos]

[…]Unfortunately, we'll probably have to wait for version 1.2 or 2.0 for quality per bitrate improvements.[…]

Very unlikely, that there will be any significant improvements in the future. Maybe some metrics get added for a better vbr management, but even that is doubtful considering how close together all results are in this listening test: http://listening-test.coresv.net/results.htm 1.1 was done because of bad quality in harpsichord encoding.

[caligula]

What gave you the idea I'm against anything? I just asked if these are some purely technical improvements or whether making SSE more pervasive we can now use more advanced profiles (for example). Because copy/pasting a changelog makes for a quick, but sometimes incomplete story.

Ok. I just thought that you wouldn't appreciate optimizations. It's a big thing if you batch process lots of stuff on server side with multiple parallel threads.

[Lennie]

I had a quick look at it and the (well written) code contributed by Cisco touches both encoder and decoder parts, and it's definitely a welcome change.

For the decoder it means:
- less power consumption
- more responsive low power devices

For the encoder it means:
- less power consumption
- providing higher compression ratios without causing lag/delay
- less bandwidth usage
- higher audio quality at the same size (vs. lower quality at lower compression ratios)

That sounds good.

But the Opus codec is already the best codec available, it's efficient and with great quality and it's available for free and with free code.

So my preference would be that they rather spend time on VP8/9 or those other video codecs which are meant to be the next generation.