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 1.1 (Read 41716 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.


 

Opus 1.1

Reply #2
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?

AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but is this low decoding speed symptom of inefficiency? Please correct me if it's wrong and again correct me if 200x is not considered low. How low is considered low with a new generation processor?

Opus 1.1

Reply #3
http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Dated as yesterday (2013-12-04), the URL will probably be updated.

http://www.opus-codec.org/downloads/

https://ftp.mozilla.org/pub/mozilla.org/opus/win32/ (thanks o-l-a-v)


Considering that we're still working through the announcement, binaries and webpage updates, ... this is not officially released. It's a bit rude to rush this kind of announcement before we've even had time to announce ourselves or even checked that all files are what they're supposed to be. It also means next time we'll have to to through the trouble of hiding all these files.

Opus 1.1

Reply #4
Considering that we're still working through the announcement, binaries and webpage updates, ... this is not officially released. It's a bit rude to rush this kind of announcement before we've even had time to announce ourselves or even checked that all files are what they're supposed to be. It also means next time we'll have to to through the trouble of hiding all these files.

You're right, pardon about that. Can a mod please remove "Officially Released" from the 2nd line of the title of this thread?

With "Officially" I was only trying to say the new source is available, I didn't think it through. And again, I only do this because I get excited with new updates and features and I can't wait for everyone to start testing.

Thank you for the update.


Opus 1.1

Reply #6
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?

AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but how can be Opus considered a last generation codec if it's so inefficient? Please correct me if it's wrong to think that low decoding speed is symptom or inefficiency and again correct me if 200x is not considered low. How low is considered low with a new generation processor?

We have discussion about decoding speed here http://www.hydrogenaudio.org/forums/index....st&p=817600

Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%

Also there are 3 variables: quality, complexity and delay. It's hard to increase some of them without decrease another one(s).
While Opus is somewhat more complex it's a high quality codec and ... still low-delay.
Speaking of quality, even 1.1 still doesn't  hit a full potential of format and but it will be interesting to see how Opus now performs against the best encoders around here. 
 

A similar situation has happened with H.264 10 years ago. It consumed more power than previous gen video format.
Some companies  like DivX didn't want to adopt it and had pushed their DivX ASP format instead telling that ASP is less complex. Later they have realized they were too late and have bought a Mainconcept that had H.264 implementation.  And now they are one of the first to implement H.265 .

Opus 1.1

Reply #7
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?

AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but is this low decoding speed symptom of inefficiency? Please correct me if it's wrong and again correct me if 200x is not considered low. How low is considered low with a new generation processor?


How are you testing this, BTW?

You aren't comparing an SSE/SSE2/SSE3/SSE3/AVX/AVX2 optimized MP3/AAC decoder on a PC supporting all of those, against the Opus reference code with only ARM optimizations, are you? That would be a rather very silly thing to do and draw conclusions from.

Opus 1.1

Reply #8
We have discussion about decoding speed here http://www.hydrogenaudio.org/forums/index....st&p=817600

Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%

Also there are 3 variables: quality, complexity and delay. It's hard to increase some of them without decrease another one(s).
While Opus is somewhat more complex it's a high quality codec and ... still low-delay.
Speaking of quality, even 1.1 still doesn't  hit a full potential of format and but it will be interesting to see how Opus now performs against the best encoders around here. 
 

A similar situation has happened with H.264 10 years ago. It consumed more power than previous gen video format.
Some companies  like DivX didn't want to adopt it and had pushed their DivX ASP format instead telling that ASP is less complex. Later they have realized they were too late and have bought a Mainconcept that had H.264 implementation.  And now they are one of the first to implement H.265 .

Got it, thank you.

How are you testing this, BTW?

You aren't comparing an SSE/SSE2/SSE3/SSE3/AVX/AVX2 optimized MP3/AAC decoder on a PC supporting all of those, against the Opus reference code with only ARM optimizations, are you? That would be a rather very silly thing to do and draw conclusions from.

I did that too, encoding is much faster in optimized builds obviously but decoding is the same.

Opus 1.1

Reply #9
I did that too, encoding is much faster in optimized builds obviously but decoding is the same.


You did what too? What did you do? What did you compare? Which AAC decoder on what platform? What AAC version? LC? HE-AAC? HE-AACv2? Which MP3 decoder on what platform? Which Opus decoder on what platform?

Edit: Clarified the question even more.

Opus 1.1

Reply #10
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.

Opus 1.1 x86-32, Vorbis x86-32 libopus 1.3.3, Vorbis x86-32 aoTuV, Vorbis x86-32 aoTuV-SSE3 Optimized, Apple AAC 7.9.8.3, LAME 3.99.5 x86-32, LAME 3.100a2 x86-32.

IgorC explained what I needed to know.

Opus 1.1

Reply #11
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.


The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.

Opus 1.1

Reply #12
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.

Opus 1.1 x86-32, Vorbis x86-32 libopus 1.3.3, Vorbis x86-32 aoTuV, Vorbis x86-32 aoTuV-SSE3 Optimized, Apple AAC 7.9.8.3, LAME 3.99.5 x86-32, LAME 3.100a2 x86-32.


If you're using foobar2000 and the decoding test component, you're not using the decoders you list, but at best the encoders. For decoding it will use foobar2000's internal decoder for AAC, MP3 and Vorbis, which is ffmpeg-2.1 (IIRC), which in turn is extremely heavily optimized to use SSE/SSE2/.../AVX/etc. It will not use ffmpeg for Opus, because ffmpeg has no internal Opus decoder yet. It will use the reference decoder, which only has optimizations for ARM, which is not what you're running it on! It is however, what a battery powered phone or tablet will run on.

So yeah: you're comparing an extremely optimized decoder having had 13 years of optimization and using all CPU features with a reference one that's optimized for another platform.

(You also compared LC-AAC instead of HE-AAC or HE-AACv2, which doesn't really make sense for bitrates lower than about 80kbps, but that's another discussion)

Opus 1.1

Reply #13
The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.


No, ffmpeg's decoders can do this single-threaded. They're insanely fast on a system with all the latest SSE/AVX stuff. If your Xeon has one less revision of AVX than his, performance will already cut in half, though.

Opus 1.1

Reply #14
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.


The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.

I think the numbers are ok. The last foobar version had an insanely optimizied decoders, ffmpeg.

Opus 1.1

Reply #15
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.


The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.

I think the numbers are ok. The last foobar version had an insanely optimizied decoders, ffmpeg.


The vorbis decoder is actually libvorbis, not ffmpeg, at least in 1.3 beta 6's credits.  If hes getting 1500x single threaded for 128k, then hes running the equivalent of a ~6GHz Xeon which seems unlikely

Opus 1.1

Reply #16
I tested in rockbox on the Clipv2 (ARM9E) w/ 24 MHz RAM clock:

Opus 64k:51.24 MHz
Opus 128k: 58.09 MHz
Vorbis 128k: 48.45 MHz

Rockbox was synced to git a couple months ago, so its a bit behind, but probably pretty close to current release minus a few optimizations.

Opus 1.1

Reply #17
You may also try this optimized opus tools 0.1.8 which should be quite fast on all configurations:
- finally flac support added
- encoded range still doesn't match range_working exactly but is close to it, and as it looks official make from Mozilla neither does

http://www.datafilehost.com/d/4cec750c

Hopefully there's no more problem with artifacts

Opus 1.1

Reply #18
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%


FIrst, there are a lot more ARM players than just smart phones.  I think mine is 2 core 80 mhz.

Second, on a phone there will be other stuff going on than just decoding Opus, and you still want the CPU to go as low as it can.

Third, if I'm playing music on a phone and not diddling around with the controls, it's in sleep mode with the display off for the duration of the playlist/album.

BTW, my likely next phone uses Opus as the default codec for calls.

Opus 1.1

Reply #19
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%


FIrst, there are a lot more ARM players than just smart phones.  I think mine is 2 core 80 mhz.

I don't know what people prefer in another countries but where I live there are much more people who use smartphone to listen to music rather than media players.
And each time there are less people who use DAP. I remember the 2000-2007  years, allmost everybody used DAPs.  Popularity of DAPs is minimal nowdays. 

Second, on a phone there will be other stuff going on than just decoding Opus, and you still want the CPU to go as low as it can.

I don't see how 30-40 MHz  can do any difference, let's say on on 2x1200 MHz ARM CPU. In my experience I got 18 hours of audio playback on my smartphone with a dual Cortex A9 1.2 GHz.  I don't get any benefit to use a lighter audio codec because my battery ends way faster than that with intensive display+cpu+wi-fi use.

 
Third, if I'm playing music on a phone and not diddling around with the controls, it's in sleep mode with the display off for the duration of the playlist/album.

And You will get a long battery life with Opus in that mode anyway.

Opus 1.1

Reply #20
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%


FIrst, there are a lot more ARM players than just smart phones.  I think mine is 2 core 80 mhz.



Well, then yours is probably a portal player based device, which hasn't been on the market in 7 years

But yes, a little more optimization is needed for older devices.  I may try to look into this over the holidays if I can find the time.

Opus 1.1

Reply #21
I don't know what people prefer in another countries but where I live there are much more people who use smartphone to listen to music rather than media players.
And each time there are less people who use DAP. I remember the 2000-2007  years, allmost everybody used DAPs.  Popularity of DAPs is minimal nowdays.


The reasons I still use my player from that era are the microSD slot and replaceable battery.

Though my current phone has those, it is tough getting through a whole day on a charge while I typically go a week on the DAP.  I must say that Opus decoding is not a significant factor on phone battery unless I don't try to use it as a phone.  THe cell radio (which I could disable) will suck the battery dry in a few hours of "idling" if I'm in a weak coverage area.


Opus 1.1

Reply #22
There's an April time stamped build of Opus available on Rarewares which identifies itself as libopus 1.1.x-git in the encoded opus files.
What kind of improvements this build holds compared to the standard libopus 1.1 build?

Opus 1.1

Reply #23
There's an April time stamped build of Opus available on Rarewares which identifies itself as libopus 1.1.x-git in the encoded opus files.
What kind of improvements this build holds compared to the standard libopus 1.1 build?

I'd like to know too. Assume those changes are only minor/cosmetic and don't bring any substantial codec step up, otherwise it would be tagged a new verion and announced at http://www.opus-codec.org/

Opus 1.1

Reply #24
There have been well over a hundred commits since v1.1.  Many of them are documentation, typos, cross-platform build nits, etc, but there are some small improvements to audio of efficiency.  There are even a few outright bug fixes, although not anything you're likely to have noticed.

http://git.xiph.org/?p=opus.git;a=shortlog