XviD latest dev-api-3 version AMD optimized

[drebel]

I hope Xvid devels will welcome a Greek effort on XviD optimization.It's a compilation especially for AMD CPUs , which combines latest Koepi's unstable build ,plus Umaniac's bugfixes.

It's only a .dll ,which means that it needs one of those two versions pre-installed in order to work (just change Xvid.dll in system32 folder)


According to _Frontier_ , the person who compiled this file, it contains Athlon/Duron/AthlonXP optimized (assembly instead of C) memory access routines (memcpy, memset)

On Intel Cpus , it just crashes...

Nic:
Sorry, Link removed, until sources released.

[Koepi]

I'll gladly read some real results on this - as the binaries we (Nic, uManiac and I) give out are already quite optimized, there's not much room left beyond those optimisations.

So, who dares posting results? :-)

Regards
Koepi

[symonjfox]

A small test:

Computer info: Athlon XP 1800+, 512 MB DDR, Hard disk IBM ata 100.
Xvid info: Constant Quantizer 2, Chroma Motion, 2 Bframes, VHQ1, Chroma optimizer. Everything else at default.
Source info:
AVS scirptLoadPlugin("C:\Programmi\avisynth 2.5\plugins\mpeg2dec3.dll")
Mpeg2Source("VTS__13_P01.16~9_1.d2v",idct=7,ipp=false,CPU=0)
Letterbox(80,80,8,8)
Trim(12501,15000)
ConvertToYUY2(interlaced=false)
(sorry about YUY2 but I used this script for DVD conversion, not for Xvid ... next time try YV12).

Koepi lastest unstable build
elapsed time: 4:51 ~9 fps (Virtual dub Mod says).

This optimized build
elapsed time 4:38 ~10 fps (VDM).
Note: Haven't Trellis quant option.

Yes, it's a little bit faster ... I hope that these optimizations will be included in next relases (maybe dev4).
Cheers

[Koepi]

Did you use trellis on my build?

Has drebel's build XVID_HQ_AC_PRED defined?

Hard to see the difference with the lack of detail...

Regards
Koepi

[symonjfox]

No, no. I didn't use Trellis.
Has drebel's build XVID_HQ_AC_PRED defined?
Hard to see the difference with the lack of detail...
I really don't know. I just download & Tested it. I really don't care about speed, I have my pc always on, so 1 hour, 2 hours, 24 hours ... who cares?

My opinion quality/speed is always the same: Quality over all!
Cheers

[K_R]

The 'feature' that makes this interesting to me is 'plus Umaniac's bugfixes'. Were there significant bugfixes made after Koepi's 2003-06-24 build?

[TheXung]

What on earth are umaniac's bugfixes? And how do you apply a bugfix to someone else's build? And why have we all of a sudden started calling this "drebel's build" when he clearly states that someone named _Frontier_ compiled this. Why does this forum in particular have so much trouble giving credit to the correct people?

[TheXung]

More importantly, why are we distributing a build with copyrighted non-GLPed code? (This is under the assumption that those memory routines came from the AMD code samples)

This also brings up the point, why are we distributing this build without the sources?

[cult]

Dont blame drebel for anything.Its not a build of his.Its made by a guy who calls himself _Frontman_(whoever he is)...
It is said clearly...According to _Frontier_ , the person who compiled this file

[drebel]

Guys !
Is it so difficult to accept that :

- it's not a build ( and certainly not mine )
- does not contain extra Xvid code.It's based on binaries already distributed .But even then I 'm not responsible for the copyright protection.Forum moderators can always remove the link if they find that this effort violates or offences opensource community.Just for the record, I'm copy-pasting from umaniac's site the cangelog


17.7.2003 11:00:
U vfw/src/codec.c (rev.1.29) syskin:
- ugly BITMAPV4HEADER / BITMAPINFOHEADER mismatch spotted by Cyrius ( suiryc at yahoo dot com ). Thanks!

26.6.2003 11:00:
U xvidcore/src/motion/motion_est.c (rev.1.72) syskin:
- VHQ is P4 compatible again | improved PBI decision *again*
U xvidcore/src/motion/motion_est.h (rev.1.10) syskin:
- VHQ is P4 compatible again | improved PBI decision *again*



I assume Koepi's build contains already the last two changes of syskin (and maybe some others, as well ;) ) , so that leaves only the first line.

_Frontier_ has given the permission to distribute the link and he's been notified for the discussion here , in case he decides to join.

[amango]

This build gives me 6-8% speed increase on my Athlon XP 1800. Nice! :)

If software is optimized more and more, we don't need no new processors anymore. :D

[Nic]

AMD Sources are normally free to use, but the link to the modifications to XviD should be released, not doing so does violate the GPL...and as such ill remove the link until they are released.

I'm sure the changes are pretty minute as I think I can guess the AMD optimisations used, but I think it's best we adhere to the GPL until then.

Cheers,
-Nic

[mf]

I knew quickly downloading that thing before the link was removed was a good idea :D.

[Sharktooth]

Yup:)

[amango]

This build produces larger files if I encode quality-based.

I encoded a short AVI with q95.

Koepi's build:
36.172KB

athlon-optimized build
38.358KB

So it is faster but it produces larger files that doesn't look better. (same settings for both builds)

[Sharktooth]

Are u sure?
I did some tests and it given me the same size.

[Human_USB]

I get about 1 to 2 frames more....... so this is great. Now I get 3 to 4 frames per second. I hope they can make it better, or make a AMD XP XVID like some linuxs

[Enigmax]

Where to now obtain that compilation optimized for AMD?
Interested in testing.

So that it does not publish its work to collaborate in the development of XviD?
Support the decision of NIC.

Greetings

[Human_USB]

The link was at the top but one of the mods removed it. Read the postings for more information.

[drebel]

The user Frontier is registered in this forum but due to forum regulations he cannot post until the 5 days limitation expires (next tuesday).So I will transfer his disappointment for this limitation and that his code is in fact using haltered AMD routines for memory management.He also has no problem uploading the sources if only Nic and Koepi do the same thing.Especially Koepi hasn't given any sources ,so he also violates GPL (I think he means for the unstable version )

[Koepi]

I have the sources for the stable build online, the sources for unstable can be requested at any time and are given out immediatly (happened ~10 times until now).

So there's no GPL violation on my side.

Binary mods are excessively violating any licenses though.

So, if someone doesn't share his sources at request (this was a request and the sources still are closed) there's no way to complain (in this case).

Send out regards, we're still expecting the sources - the sources which I use are a) given out on request and b)available at any time on the net, you just have to do a CVS checkout - my mods (and the ones i use) are in CVS always at most a few days after my binary release.

So stop this braindead flaming.

Koepi

P.S.: this kind of argument is indicating that the person who did those "magic hacks" is just trying to gain "respect" out of other people's hard work. I'd love to get proven wrong.

[drebel]

Frontier wrote :

This build uses latest Koepi's code (not the dev unstable build) , but I've added the last Umaniac's fixes (the ones mentioned before).Trellis quant is added ,IIRC, in version 0.9.2 which is what i'm working on.But this version does not contain the portion of the vfw for the use of trellis ,even if the code for it exists.
I didn't go over my head on this matter ,because even win32 devs haven't added their changes on the main source tree (especially Koepi with a big number of changes commited has broken compatibility with the linux version of xvid ,so did Nic...)As soon as I manage to solve some problems with the use of AMD routines on which this optimized version is based and the way to import those into linux build , I'll upload the sources.

PS(from drebel): this is a free Greek-English translation, so pls forgive any problems with comprehension from my part

[Koepi]

Originally posted by drebel
Frontier wrote :

especially Koepi with a big number of changes commited has broken compatibility with the linux version of xvid ,so did Nic...

Please show us where we did that instead of just spreading misinformation. I never had CVS access - how could i break anything? The changes I did were mostly committed by the *NIX folks amongst the xvid devs - so they're quite safe.

Koepi

Post edited to not sound as bad as it did.

[TheXung]

Originally posted by amango
This build produces larger files if I encode quality-based.

I encoded a short AVI with q95.

Koepi's build:
36.172KB

athlon-optimized build
38.358KB

So it is faster but it produces larger files that doesn't look better. (same settings for both builds)

Have you tried different sources of content? quality=95 I believe is pretty much a combination of quant 2 and 3. The quality setting is not actually indictative of actual quality of the encode. There has most likely been changes that affect quality since Koepi's last build. I recall at least one more commit where syskin changed the IPB decision making.

[Nic]

To nip this is in the bud, so to speak. Ill close this thread. drebel can edit the first post to put the link back in to the AMD binray once he can also add a source code link.
(as for me breaking GPL, thats crazy, as all I do is build from the CVS, with no changes made by me whatsoever, and the source to my filter is online...So don't spread misinformation, although probably any misunderstandings I hope were due to the translation)

Thread Closed.

-Nic