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: IETF Opus codec now ready for testing (Read 392770 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

IETF Opus codec now ready for testing

Reply #525
Perhaps Nekit1234007 can detail what the "crazy parameters" were.

Code: [Select]
 -mfpmath=both -Ofast -flto -march=native
I have Core i5-450M. I think they’re crazy, but I might be wrong here, I’m not very experienced in configuring/building stuff.


IETF Opus codec now ready for testing

Reply #527
-march=native means it will optimize for your build machine's processor. It's probably better to go for something more generic than that.


IETF Opus codec now ready for testing

Reply #529
Finally Google will support Opus in its new WebM. It will add new video and audio codecs VP9+Opus to previous VP8+Vorbis.
http://peter.sh/2012/12/vp9-and-opus-backg...by-positioning/

I've enabled the flag and relaunched the browser. When I do the HTML5 test at html5test.com, I still see the browser as not having Opus support. Can anybody confirm that?

IETF Opus codec now ready for testing

Reply #530
Finally Google will support Opus in its new WebM. It will add new video and audio codecs VP9+Opus to previous VP8+Vorbis.
http://peter.sh/2012/12/vp9-and-opus-backg...by-positioning/

I've enabled the flag and relaunched the browser. When I do the HTML5 test at html5test.com, I still see the browser as not having Opus support. Can anybody confirm that?

I managed to play Opus in Chrome Dev, but it crashes Chrome on a few songs for some reason...
Doesn't really bother me since I use Firefox as my main.
EDIT: OH yeah forgot to mention html5test is also reporting no opus support.

IETF Opus codec now ready for testing

Reply #531
since webm is nothing but matroska container i wonder how do they mux vp9 and opus. from what i know matroska team has not yet figure out how to propelly support .opus in .mkv. mainly issues with accurate seeking.

IETF Opus codec now ready for testing

Reply #532
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.

IETF Opus codec now ready for testing

Reply #533
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks


IETF Opus codec now ready for testing

Reply #535
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks


MSVC is the Microsoft C compiler that comes with Visual Studio. MSVCPP is the C++ compiler. The MSVC is considered to be sub-par to things like GCC, so many use MinGW. MSVC just supports C89. MSVCPP is pretty much standard on Windows though...

IETF Opus codec now ready for testing

Reply #536
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks


MSVC is the Microsoft C compiler that comes with Visual Studio. MSVCPP is the C++ compiler. The MSVC is considered to be sub-par to things like GCC, so many use MinGW. MSVC just supports C89. MSVCPP is pretty much standard on Windows though...

Many thanks for your detailed answer mate.When you say its sub par do you mean the quality of the encoding (sound quality)? If so would you recommend for me to wait for  a different compile to convert my music library  to opus ? Again thank you.

IETF Opus codec now ready for testing

Reply #537
Many thanks for your detailed answer mate.When you say its sub par do you mean the quality of the encoding (sound quality)?


He means that it might be slower.


IETF Opus codec now ready for testing

Reply #539
Here I have passed ABX test for git version of Opus from 10.11.2012 at 256 kbps.
-----------------------
If new Opus 1.2 "is tending towards constant quality rather than constant bitrate" then why it uses almost the same bitrate for mono? Musepack uses twice lower bitrate for mono. Why Opus can't do this?
For my opinion constant quality means that there shound not be any mention of bitrate at all. Encoder should have presets like "Low quality", "Good quality" and "High quality" and use an appropriate bitrate for every separate sample. Quality here is tied for audibility of distortions produced by encoder. For example, for simple piano music Vorbis q4 gives high quality (very difficult if possible to hear distortions), for rock-pop music Vorbis q4 gives good quality (distortions can be heard due to cutoff etc.), and for complex electronic music it gives low quality (sounds far from the original). So, Vorbis does not have true VBR mode. For true VBR mode user should not think about bitrate at all. I don't know weather it is possible for encoder to do such an analysis of a source audio, but it would be great it yes.

IETF Opus codec now ready for testing

Reply #540
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.

If you can tolerate betas and/or alphas/daily builds, VLC and Rockbox will do what you seek (mentioned several pages back).

IETF Opus codec now ready for testing

Reply #541
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.

 

IETF Opus codec now ready for testing

Reply #542
I don't know weather it is possible for encoder to do such an analysis of a source audio, but it would be great it yes.
It's only a matter of finding the right formula/algorithm.
There may be another reason why it's not done the way you described and that reason may be bitrate predictability. Personally, I would find it unnerving if I was encoding my collection for a portable device and would get a totally random bitrate for each song. I would have no idea how much I could fit onto the device and I could even end up in a situation where I would have to re-encode everything at a lower setting so it fits in there.

IETF Opus codec now ready for testing

Reply #543
Well, that's just the purpose of a true quality based mode: You want to be certain that the loss of quality stays below a given threshold. Usually that's just opposite to respecting a target bitrate.

__


^ your avatar: Caleb was chosen!

IETF Opus codec now ready for testing

Reply #544
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.

Thanks for your work.  Does this effort get added to the daily builds?

IETF Opus codec now ready for testing

Reply #545
Are there any prebuilt 1.1-alpha Windows binaries available to download? I like to try out the new unconstrained VBR encoding and i've tried to build it with VS 2012 Express but i can't compile the opustools because it's say all the projects are incompatbile in the solution. However i can compile the 1.1-alpha libopus just fine.



IETF Opus codec now ready for testing

Reply #548
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.

Thanks for your work.  Does this effort get added to the daily builds?


They are now, but the first changes are very minor. Much more work is needed.

IETF Opus codec now ready for testing

Reply #549
Some fun benchmarking on ARMv5 (AMS3525v2, Clipv2, 240MHz w/ 24MHz DRAM):

opus64k, 5ms delay:    102 MHz
opus64k, 20ms delay:  65 MHz
opus128k, 20ms delay:  75 MHz

A lot more work to do, but almost all the time is in the FFTs, so at least it should be possible.