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: Ogg Vorbis acceleration project (Read 190134 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ogg Vorbis acceleration project

Reply #175
I took my old compiles and also compiled the sources with SSE4.1 instruction set. Then I took an album (57m 37s) and encoded it. Results (encoding time, in seconds):

32 bit:
SSE  - 89.5 s
SSE2 - 72.2 s
SSE3 - 73.2 s
SSE4.1 - 72.1 s

64 bit:
SSE2 - 67.1 s
SSE3 - 66.5 s
SSE4.1 - 66.1 s

BTW, I also tested original Lancer from http://homepage3.nifty.com/blacksword/index.htm

SSE  - 57.7 s
SSE2 - 53.2 s
SSE3 - 53.1 s

SSE2 MT - 35.9 s (71.6 s total process time)
SSE3 MT - 36.2 s (72.3 s total process time)

Ogg Vorbis acceleration project

Reply #176
Pink Floyd - The Wall 1:21:09 (CPU specs: http://i46.tinypic.com/110lytc.png)

(q5.0)

oggenc2.87-1.3.3-generic: Total encoding time: 0:29.874, 162.99x realtime

oggenc2.87-1.3.3-x64: Total encoding time: 0:17.067, 285.30x realtime

oggenc2.87-aoTuVb6.03-generic: Total encoding time: 0:31.949, 152.40x realtime

oggenc2.87-aoTuVb6.03-x64: Total encoding time: 0:18.236, 267.01x realtime

oggenc2.87-aoTuVb6.03-LancerSSE: Total encoding time: 0:18.330, 265.64x realtime

oggenc2.87-aoTuVb6.03-LancerSSE2: Total encoding time: 0:18.096, 269.07x realtime

oggenc2.87-aoTuVb6.03-LancerSSE3: Total encoding time: 0:18.439, 264.07x realtime

oggenc2.87-aoTuVb6.03-LancerSSE3_x64: Total encoding time: 0:13.994, 347.95x realtime

-

qaac_1.38 (V82): Total encoding time: 0:20.374, 238.99x realtime

NeroAACCodec-1.5.1 (Q0.48): Total encoding time: 0:19.313, 252.12x realtime

lame3.99.5 (V2): Total encoding time: 0:19.344, 251.71x realtime

lame3.99.5-64 (V2): Total encoding time: 0:17.643, 275.98x realtime

Ogg Vorbis acceleration project

Reply #177
It seems that older versions (that require Intel DLLs) were faster than current. Also, SSE2_OLD version is as fast as before. (misconfigured compiler?..)

Ogg Vorbis acceleration project

Reply #178
It seems that older versions (that require Intel DLLs) were faster than current. Also, SSE2_OLD version is as fast as before. (misconfigured compiler?..)

The SSE2_OLD is actually configured in the same way as the SSE2 compile. Both are ICL 12.1 compiles. The only difference is that the OLD was compiled within VS2008 and the other within VS2010.


Ogg Vorbis acceleration project

Reply #180
After finally getting the 64-bit machine operational, I have some benches to add here (running i5-2600K [OC], 8GB, WinXP x64 SP2):

OggEnc 2.87 aoTuV b6.03 Lancer builds (-q 3 [126.2 kbps])
SSE2 ........ 74.13x
SSE2 old ... 98.84x
SSE3 ........ 74.13x
SSE3 x64 .. 107.83x
"Something bothering you, Mister Spock?"

Ogg Vorbis acceleration project

Reply #181
Could you test also SSE version?

Ogg Vorbis acceleration project

Reply #182
After finally getting the 64-bit machine operational, I have some benches to add here (running i5-2600K [OC], 8GB, WinXP x64 SP2):

i5 2500k  or i7 2600k?

Ogg Vorbis acceleration project

Reply #183
Ok, the results using Vorbis -q3 running on i5-2500K (OC'ed), 8GB, WinXP x64 SP2.

The encode rate and bitrate numbers come from the binaries themselves. To help make sense of which version I was running I included the binaries' date-stamps.
Code: [Select]
john33 (OggEnc 2.87 aoTuV b6.03, average bitrate 126.2 kbps, all builds Lancer except *)
----------------------------------------------------------------------------------------
Generic*    40.2072    05/04/2011
P4*        65.8952    05/04/2011
SSE        71.8857    07/04/2012
SSE2        74.1321    07/04/2012
SSE2 (old)  98.8428    07/04/2012
SSE3        74.1321    07/04/2012
SSE3 x64  107.8285    07/04/2012


lvqcl Lancer (OggEnc 2.87 aoTuV b5.7, average bitrate 118.6 kbps)
------------------------------------------------------------------
SSE        87.8602    02/20/2012
SSE2      118.6113    02/20/2012
SSE2 x64  131.7904    02/20/2012
SSE3      112.9632    02/20/2012
SSE3 x64  124.8540    02/20/2012

Blacksword Lancer (OggEnc 2.83, aoTuV b5, average bitrate 118.0 kbps)
---------------------------------------------------------------------
SSE      120.112743    11/09/2006
SSE2      131.673327    11/09/2006
SSE2 MT  200.035978    11/09/2006
SSE3      131.330713    11/09/2006
SSE3 MT  199.766456    11/09/2006
"Something bothering you, Mister Spock?"

Ogg Vorbis acceleration project

Reply #184
oggenc "02/20/2012" is based on aoTuV 5.7, not 6.03

Ogg Vorbis acceleration project

Reply #185
 Fixed.

I got pretty confused with this many binaries.
"Something bothering you, Mister Spock?"

Ogg Vorbis acceleration project

Reply #186
(Time expired editing above post while typing...)

FYI, I noticed the SSE binary in the aoTuV b5.7 bundle (post #121) declared itself b6.03. Because the bitrate is consistent with the other compiles in the bundle I'm guessing it's just a typo.

It's worth mentioning that Vorbis doesn't have drastic bitrate variance when compiler options change. When I posted the average bitrate in the above table it really means each individual file had the same bitrate, respective of the builder+compiler.
"Something bothering you, Mister Spock?"

Ogg Vorbis acceleration project

Reply #187
Quote
FYI, I noticed the SSE binary in the aoTuV b5.7 bundle (post #121) declared itself b6.03.

...That's strange. Thank you for the info.

Ogg Vorbis acceleration project

Reply #188
I was wondering if somebody whos got gcc could give us a compile with AVX or AVX+sse4/4.2a to test on bulldozer based chips.

apparently they fixed the AVX support with newer gcc versions http://www.primegrid.com/forum_thread.php?id=3912

would be interesting if it where possible to see how AVX would effect encode speeds if at all  (cant wait for them to also have FMA support)

thanks in advance to whoever gives us an avx build to play with

Ogg Vorbis acceleration project

Reply #189
Are the AoTuV b6.03 sources from post #117 mixed with Lancer?

For decoding only, are there major quality/bugfix differences between the current libvorbis/vorbisfile and what the latest "original" Lancer was based on (from late 2006)?

Ogg Vorbis acceleration project

Reply #190
Are the AoTuV b6.03 sources from post #117 mixed with Lancer?


Yes, but I tested only encoding part of these sources, and I'm not sure that decoding works properly.


For decoding only, are there major quality/bugfix differences between the current libvorbis/vorbisfile and what the latest "original" Lancer was based on (from late 2006)?


See http://svn.xiph.org/trunk/vorbis/CHANGES  (original Lancer is based on libvorbis 1.1.2).

Ogg Vorbis acceleration project

Reply #191
It seems there are decoding related changes since then. Also things like "Corrections to the specification" or "Fix a numerical instability in the edge extrapolation filter" which I don't know if are relevant or not.  So staying with an old version isn't a good idea.

How did you do the merge? Comparing Lancer against AoTuV 5, then AoTuV 5 to 6, or libvorbis (and co.) 1.1.2 to 1.3.3, and patching in  in unchanged parts?

Did you try creating new SSE code? If there are clear cases of calculations done on arrays, is it necessarily difficult?

Ogg Vorbis acceleration project

Reply #192
any chance of a compile with FMA support? 

we cant get an intel compiler build with AVX support because intels compiler blocks non-intel chips from getting AVX code paths sadly, but FMA could have a beneficial effect on encode performance I would think


Ogg Vorbis acceleration project

Reply #194
Quote
Ogg Vorbis acceleration project, Is it dead?

Yes. As vorbis himself. Xiph developing another codec "opus". Welcome, new abandonware. For people who support vorbis nothing remains except "thanks". Fate of many open source projects, lack of interest.

Tuning is boring? Start new project.

Ogg Vorbis acceleration project

Reply #195
Quote
Ogg Vorbis acceleration project, Is it dead?

Yes. As vorbis himself. Xiph developing another codec "opus". Welcome, new abandonware. For people who support vorbis nothing remains except "thanks". Fate of many open source projects, lack of interest.

Tuning is boring? Start new project.



How about wide hardware support? I'm not sure if the opus will get it even in next 2 years. That's nonsense (to close Vorbis project). Also AFAIK Opus has more targeting onto low latency and low bitrate (of course not without a cost of quality loses for simple file encoding at medium bitrates).
🇺🇦 Glory to Ukraine!

Ogg Vorbis acceleration project

Reply #196
1) Ogg Vorbis works very well in its current iteration;
2) Codec support these days is probably more software than "hardware".

Re: Ogg Vorbis acceleration project

Reply #197
Quote
Ogg Vorbis acceleration project, Is it dead?
Yes. As vorbis himself. Xiph developing another codec "opus". Welcome, new abandonware. For people who support vorbis nothing remains except "thanks". Fate of many open source projects, lack of interest.

Tuning is boring? Start new project.

6 years later. What was done:
Code: [Select]
libvorbis 1.3.7 (2020-07-04) -- "Xiph.Org libVorbis I 20200704 (Reducing Environment)"

* Fix CVE-2018-10393 - out-of-bounds read encoding very low sample rates.
* Fix CVE-2017-14160 - out-of-bounds read encoding very low sample rates.
* Fix CVE-2018-10392 - out-of-bounds access encoding invalid channel count.
* Fix handling invalid bytes per sample arguments.
* Fix handling invalid channel count arguments.
* Fix invalid free on seek failure.
* Fix negative shift reading blocksize.
* Fix accepting unreasonable float32 values.
* Fix tag comparison depending on locale.
* Fix unnecessarily linking libm.
* Fix memory leak in test_sharedbook.
* Update Visual Studio projects for ogg library filename change.
* Distribute CMake build files with the source package.
* Remove unnecessary configure --target switch.
* Add gitlab CI support.
* Add OSS-Fuzz support.
* Build system and integration updates.

libvorbis 1.3.6 (2018-03-16) -- "Xiph.Org libVorbis I 20180316 (Now 100% fewer shells)"

* Fix CVE-2018-5146 - out-of-bounds write on codebook decoding.
* Fix CVE-2017-14632 - free() on unitialized data
* Fix CVE-2017-14633 - out-of-bounds read
* Fix bitrate metadata parsing.
* Fix out-of-bounds read in codebook parsing.
* Fix residue vector size in Vorbis I spec.
* Appveyor support
* Travis CI support
* Add secondary CMake build system.
* Build system fixes

libvorbis 1.3.5 (2015-03-03) -- "Xiph.Org libVorbis I 20150105 (⛄⛄⛄⛄)"

* Tolerate single-entry codebooks.
* Fix decoder crash with invalid input.
* Fix encoder crash with non-positive sample rates.
# Fix issues in vorbisfile's seek bisection code.
* Spec errata.
* Reject multiple headers of the same type.
* Various build fixes and code cleanup.

libvorbis 1.3.4 (2014-01-22) -- "Xiph.Org libVorbis I 20140122 (Turpakäräjiin)"

* Reduce codebook footprint in library code.
* Various build and documentation fixes.