32 bit to 64 bit Xvid performance impact (benchmarks)

[pogo stick]

Thanks for your builds, Squid!

I just quickly tried whole 64 bit encoding chain: AviSynth with DGDecode, VirtualDub and XviD. If I did everything right, it seems about 20% faster then 32 bit on second pass!

By the way, are you interested in x264 encoding? ;)

[squid_80]

Thanks for your builds, Squid!
By the way, are you interested in x264 encoding? ;)

Good to hear you got it all working :)
I've never used x264 myself, but I have heard that it's a bit on the slow side. I'll try and get a copy of the source and see how it looks... If there's not too much assembly (especially using inline __asm) it might be as simple as doing a recompile. Not sure how I'd go keeping it up to date though, the good thing about xvid is that the project has been managed very well and these days any changes are pretty small and easy to incorporate. I might just wait and see what happens with the next version of virtualdub; reading Avery Lee's latest blog entry (www.virtualdub.org) I think he's well on the way to getting 32-bit codecs to work with 64-bit vdub. If that's the case it would probably be best for me to leave 64-bit development up to the original codec developers, rather than releasing my own builds like I have been doing. (Any devs who would like assistance with 64-bit stuff, feel free to ask!)

[pogo stick]

There is some 64 bit code in x264 already and it seems like asm (don't know what it means :o). But it's *nix only. :( Here (http://forum.doom9.org/showthread.php?t=93716).

[Sharktooth]

x264 contains a lot of MMX code... it needs to be ported to SSE to make it work on win-xp x64.

[Joe Fenton]

x264 contains a lot of MMX code... it needs to be ported to SSE to make it work on win-xp x64.

It SHOULD but apparently XP64 does allow 64bit programs to still use MMX. The guy working on 64bit xvid just kept the MMX code in xvid and it seems to work fine in XP64.

[bill_baroud]

x264 contains a lot of MMX code... it needs to be ported to SSE to make it work on win-xp x64.

AFAIK, XP64 doesn't support MMX in their compiler _intrisics_.
that doesn't mean XP64 doesn't support MMX anymore (well at least, it's what i understood)

[squid_80]

We've been through this. MMX works fine in xp64. But using SSE2 is a better choice if possible since you can use intrinsics and the compiler should be smart enough to make the most of the extra registers. This is easier than writing external assembly and is more portable. The main disadvantage of using intrinsics was that the compiler produced crap code but this has been improved dramatically (both the compilers in the latest platform SDK and VS2005 seem pretty capable).
Having said all that, the easiest way to get a working 64-bit version of x264 would be to do what I did with xvid and just change the assembly code from x86 to x86-64 and make sure it matches the ABI. If there is linux x86-64 assembly code already then it should require very little work. Like I said I don't really have the time or experience with x264 to know if it is working as expected but if someone else wants to do it (sharktooth, weren't you attempting that once upon a time? (http://forum.doom9.org/showthread.php?p=624236#post624236)) feel free to ask for help.

[Sharktooth]

well, i tried and i failed :D
however linux hasn't the same "limitations" as windows has. gcc is able to compile 64bit code with both MMX, SSEx and FP.

[squid_80]

Ok, I've had a look at avisynth64's resizing discrepancies and here's the lowdown:

I'd missed a rounding calculation in the vertical resizing, this has been fixed (also vertical resizing should work for all colorspaces, not just YV12).
There was a bug in horizontal resizing converting dwords to words. Also fixed.
Now PointResize and BilinearResize produce the same output as a 32-bit build. But Bicubic, Lanczos and Lanczos4 can still produce values that vary by a range of about 4. Since the co-efficients used for resizing are produced using lots of floating point divisions (lanczos uses sine as well), I'm guessing there's small accuracy differences due to the compiler using different methods. This is probably something that is more or less unavoidable. The question is which has better accuracy, 32 or 64-bit? Or will anyone be able to see the difference? ;)
New avisynth64 is in the usual place: http://home.iprimus.com.au/ajdunstan/avisynth64.zip

[AliceD]

Hi,

i also tried to install all these progs to test the incredible performance of a 64bit sys, but unfortunately it's not working.

i got a winxp for 64bit ext. and installed it on drive d.
then i got
vdub 1.6.x for AMD64
XviD, avisynth and dgdecode somewhere from this thread i think.

so i installed XviD and the files are under windows\sysWOW64\ but nothing found in veedub or add/remove software neither under video-codecs.
then i made a d2v file with dgindex 1.2.1 as it says in the textfile of dgdecode64 and a avs but when i load the avs in veedub i get an error

"Avi Import Error: (Unknown)(80040154)"

eehhhh....

can anybody tell me how i get these things to work??

[AliceD]

avisynth and dgdecode are from squid_80°° thank you!

[squid_80]

Xvid64 and avisynth64 should be installed by right-clicking the .inf file that comes with them and choosing the install option. Nothing should be installed into windows\syswow64, they should automatically be copied into windows\system32. If they end up in syswow64 you're probably using a 32-bit file manager (people tend to do this so the context menus for winrar etc. still work) which is a bad idea.
If xvid64 is installed correctly it will definitely show up in add/remove programs and should also be listed under video codecs->properties in device manager.

[AliceD]

Oh yeah, it's working. Thank you. This was the problem, i installed it with total commander wich is still 32bit software. didn't know that windows even make differences from where it installes programms. i used the ms explorer and it's working.

thank you!

[fumigator]

Long time unseen in the scene, now I'm back. WOW squid you really grew with your Xvid, however I have not windows 64 bit installed anymore because of space problems (must get a bigger hard drive).

Anyway, the real reason I came back is that I heard someone did an experimentation with his video card, he did some work using video card hardware instead of the PC processor. Such a thing can be outstanding knowing that video card processors are much faster than x86 processors in math computations. Don't know who did this kind of experimentation, I searched over the net and found nothing, but I've heard of it and it seems to be true thing.

Thinking more about it, both Nvidia or ATI cards (or any of the kind) have hardware functions for antialiasing and resizing. So my idea is, if you encode in Divx, would be possible to let your video card do the resizing work and/or antialiasing, or even execute part of the encoding code?

What about that?

[wiak]

and btw 64bit xvid is the same as 32bit xvid in interface ;) its basicly the same layout but its complied on 64bit and not 32bit ;)

[fumigator]

look at some earlier post on this thread, specially page 3. C ya !

[zToFFe]

just tried those apps out,
source: PAL 704x576 (interlaced) capped with dvb-s card.
avs:
LoadPlugin("D:\dgdecode64\dgdecode.dll")
mpeg2source("D:\test64.d2v", idct=6)

the first 18 seconds of the encoding runs at 84fps,then 75, and then it starts to jump between 44,56,60,64,66,70 etc.

but when i add any of the lanczos resize filters (which i guess are not really compatible yet) the speeds drops to 28fps.

running on a:
dual xeon 3.2ghz/1mb/800fsb
2x512mb kingston ddr2 ecc/reg.

really nice work squid_80! :)

[wiak]

witch software do you guys make the d2v file with?

am getting this error
http://img374.imageshack.us/img374/4942/error4qq.jpg
here is how my avs file is:

LoadPlugin("D:\Download\dgdecode.dll")
mpeg2source("I:\1.d2v")

i cant get it to work :(

i have installed XviD64 (using the .inf), Avisynth64 (in system32 & i have run avisynth.reg)

System:
AMD Athlon 64 3200+
4x 512 MB TwinMOS PC3200 DDR400
4x WDC 250 GB
ATi Radeon X800 XT
ATi Theater 550 PRO
Windows XP Professional x64 Edition

i dont know what but its something that is WRONG :(

[Axed]

Obvious question first, did you download the update of DGIndex? If so, did you create a new D2V file or try to use the old one?

[squid_80]

From the readme file that I included with the 64-bit version of dgdecode:
It is based on the source code for version 1.2.1 and should be used with a corresponding version of DGIndex.
So the .d2v file needs to be made with DGIndex 1.2.1. Newer versions will create incompatible .d2v files.

[Sirber]

Keep the good work! I'm startimng to see an advantage to 64bit ^^

[wiak]

Thanks guys it realy works :D:D:D:
good work ! :D

[Xayd]

Awesome stuff squid. I'm anxiously awaiting more of your ports, got a dual nocona xeon machine that's begging to be a full 64 bit encoding box.

when you get back to working on filters again the remaining few filters that AutoGK uses would be awesome (removegrain, FDecimate, autocrop).

if you need anything for your efforts i'd be happy to chip in too.

[IvS]

1. squid_80: have you done any more work on the 64-bit XviD port?
2. Has anyone else tried seriously developing this idea?
3. Does anyone have a working link? :)

[squid_80]

1. squid_80: have you done any more work on the 64-bit XviD port?
2. Has anyone else tried seriously developing this idea?
3. Does anyone have a working link? :)
1. No, haven't touched it since May. But I might redo it when syskin's multithreading stuff is finished.
2. ? (not that I know of)
3. If my ftp server (ftp://squid80.no-ip.com) is unavailable try http://okejl.dk/dunstan

[IvS]

Thanks squid_80. I hope to see this being developed with help from others as well. The potential is huge.

[NeonEva]

3. If my ftp server (ftp://squid80.no-ip.com) is unavailable try http://okejl.dk/dunstan
neither works anymore any way to get a link to new working downloads ?

[daStorm]

http://nwgat.net/mirrors/okejl.dk/dunstan/
^_^
have fun