Ogg Vorbis optimized for speed, ca. 1.5x faster than 1.1 original ver. Options

[nyaochi]

Some Japanese guys work on speed optimization of libvorbis by using SSE. Blacksword (or 637) launched an Ogg Vorbis acceleration project (in Japanese only) and releases oggenc binary and libvorbis patch based on libvorbis 1.1. This optimization includes SSE implementations of FFT, MDCT, windowing, channel coupling, sorting, psymodel, floor/residue encode, and so on. In my computer (Pentium IV 2.4GHz), ICL8.1 compiled oggenc binary of the optimized version (Archer Beta03) encodes at 23.4x while the one without optimization (ICL8.1 compiled but no SSE patches) does at 15.5x. Hence, this optimization archives ca. 1.5x speed gain.

Unlike GoGo-no-coder, it's not forking: he releases a patch for libvorbis source code without absolutely changing algorithm or data structure. This is very good for source code maintenance to keep up with up-to-date official libvorbis, but limits optimization possibility in some degree. Actually, the author says in readme.txt that there's little room left for optimization. So I think it's time for quality evaluation although this optimization is in development stage. After several bugs are found and fixed for the last week, bitrates are quite similar to the reference encoder for all quality values. If you find any bugs or quality degressions from official 1.1 one, please tell us.

Contributors are:
- Blacksword (or 637)'s SSE optimization (Japanese only): A number of functions in libvorbis are vectorized to take advantage of SSE instruction set as well as Opt-Sort and wuvorbis. For complete list of optimized functions, see readme.txt (in Japanese but you may easily find it) attached with the binary.
- Manuke's OptSort: Optimization of qsort function that consumes 20% of compression processing time, by assuming that _vp_quantize_couple_sort and _vp_noise_normalize_sort functions in psy.c call qsort with 8 or 32 element. This accelerates the whole compression process by 10%.
- W.Dee's wuvorbisfile (Japanese only?): wuvorbis.dll is a fast Ogg Vorbis decoder with SSE and 3DNow!, which is a part of KiriKiri software (useful for developing multi-media contents or adventure games). wuvorbis.dll decodes 1.4x-1.8x faster (SSE) and 1.5x-1.9x faster (3DNow!) than official libvorbis.

Happy encoding!

[eloj]

Archer RC2 is out.

[Josef K.]

Archer RC2 is out.

Regrettably, exactly the same problem (with the same sample) as RC1 detected here
(RC1 bug report can be found here)

[rjamorim]

Regrettably, exactly the same problem (with the same sample) as RC1 detected here
(RC1 bug report can be found here)

What's the point of posting the report at a forum the developer probably doesn't read?

If I were you I would send him an e-mail, and hope that he speaks at least some english.

[eloj]

If I were you I would send him an e-mail, and hope that he speaks at least some english.

I just sent him an email referencing this thread and that specific post. It would probably be helpful if someone could supply a test file.

Edit: I finally found a file that I have that crashes the encoder. It's track 14 off the Pain of Salvation - Be album. Let's see.. crash at around 65,3% completed....

Edit 2: Very tricky to pin down. This track only crashes at -q 3 of the different qualities I tried.

Edit 3: Okay, running under debugger:

"oggenc_archer.exe The instruction at 0x0042D568 referenced memory at 0xBF4EB730. The memory could not be read."

CODE

.text:0042D512 cvtss2si ecx, [eax+edi*4+0Ch]
.text:0042D518 cvtss2si ebx, [eax+edi*4+8]
.text:0042D51E cvtss2si esi, [eax+edi*4+4]
.text:0042D524 cvtss2si eax, [eax+edi*4]
.text:0042D529 mov     edi, [esp+50h+var_20]
.text:0042D52D add     ecx, edi
.text:0042D52F add     ebx, edi
.text:0042D531 add     esi, edi
.text:0042D533 add     edi, eax
.text:0042D535 mov     eax, [esp+50h+var_18]
.text:0042D539 imul    eax, [edx+8]
.text:0042D53D mov     [esp+50h+var_20], edi
.text:0042D541 mov     edi, [esp+50h+var_14]
.text:0042D545 add     eax, [edi+ecx*4]
.text:0042D548 imul    eax, [edx+8]
.text:0042D54C add     eax, [edi+ebx*4]
.text:0042D54F imul    eax, [edx+8]
.text:0042D553 add     eax, [edi+esi*4]
.text:0042D556 imul    eax, [edx+8]
.text:0042D55A mov     edx, [esp+50h+var_20]
.text:0042D55E add     eax, [edi+edx*4]
.text:0042D561 mov     edx, [esp+50h+var_10]
.text:0042D565 mov     edx, [edx+8]
.text:0042D568 cmp     dword ptr [edx+eax*4], 0          <--------------
.text:0042D56C jle     loc_42D6FE
.text:0042D572 mov     edx, [ebp+arg_C]
.text:0042D575 mov     ecx, [edx+10h]

It's a function that starts at 0x42D2FC and takes four parameters. Seems to only get called explicitly from one place, but its address is taken twice, so it could called as a function pointer too?. I'm not familiar enough with the code to identify it any further, and I don't think I even have the tools to build the source.

This post has been edited by eloj: Mar 18 2005, 17:32