Windows x64 port

[squid_80]

I've been working on porting xvid to windows for AMD64 and I'm looking for people willing to test it. There's so many different options, I figure this is the quickest way to find bugs.

A zip of xvidcore and the vfw frontend can be downloaded here:
http://home.iprimus.com.au/ajdunstan/xvid64.zip

Unzip, right click the inf file, select install.
Getting the 64-bit version of VirtualDub is also a good idea, unless you've got some other way to test it. If VirtualDub crashes it probably won't bring up the familiar crash handler, it will just exit with no messages at all. This is my fault, not VirtualDub's.

This build is using MMX/3DNow instructions, which Microsoft and AMD have said not to do. So it may very well break if they release a new beta or there may be other issues not discovered. I am working on converting the functions to SSE2, but it takes time.

If people want the source I can put it up. I'm using visual studio .net 2003, winddk 3790, yasm-0.4.0 and WinXP for AMD64 1218. I'm not sure how you'd go about compiling with anything else.

KNOWN ISSUES:
None at the moment. :)

I've only done pretty basic encodings, you guys probably play around with the different options a lot more than I do. So give it a go and let me know what works and what doesn't. Speed comparisons are welcome too, try to make sure the 32-bit build you're comparing against is a 1.1 build.

[Sharktooth]

Interesting! I should re-install winxp for 64 bit extended systems and test it.

[Joe Fenton]

You might check the source for the 64bit Linux version of xvidcore against what you're doing.

http://ayo.freshrpms.net/fedora/linux/3/x86_64/SRPMS.freshrpms/

You'll find an rpm of 64bit xvid source there.

[sysKin]

Originally posted by Joe Fenton
You might check the source for the 64bit Linux version of xvidcore against what you're doing.

http://ayo.freshrpms.net/fedora/linux/3/x86_64/SRPMS.freshrpms/

You'll find an rpm of 64bit xvid source there.
Or just get it from CVS.

[Blue_MiSfit]

this is so f___ing cool. I will test ASAP on my x64 install.

[Blue_MiSfit]

Problem:

For me at least, I cannot seem to get avisynth to work properly on x64. I have Virtual Dub 64 1.6.1, XviD x64 from this thread, and when I try to open the following script into vdub:


LoadPlugin("H:\PROGRA~2\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("H:\PROGRA~2\GORDIA~1\AviSynthPlugins\UnDot.dll")

mpeg2source("D:\Family Guy Disc 3\213 - Road to Rhode Island\Road to Rhode Island.d2v")

Undot()


It refuses to open and says AVI Import Filter Error - (Unknown) (80040154)

I have avisynth 2.5.5 installed (albeit in 32 bit mode as I don't know of a 64 bit compile).

Ideas?

[squid_80]

Originally posted by Blue_MiSfit
Problem:

For me at least, I cannot seem to get avisynth to work properly on x64. I have Virtual Dub 64 1.6.1, XviD x64 from this thread, and when I try to open the following script into vdub:


LoadPlugin("H:\PROGRA~2\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("H:\PROGRA~2\GORDIA~1\AviSynthPlugins\UnDot.dll")

mpeg2source("D:\Family Guy Disc 3\213 - Road to Rhode Island\Road to Rhode Island.d2v")

Undot()


It refuses to open and says AVI Import Filter Error - (Unknown) (80040154)

I have avisynth 2.5.5 installed (albeit in 32 bit mode as I don't know of a 64 bit compile).

Ideas?

VirtualDub is 64-bit, avisynth is 32-bit. They can't work together.
But if you've got the xvid stuff installed, hopefully you should be able to open and encode xvid avis. VirtualDub also natively supports MPEG-1 files I think, if you've got any VCDs lying around.

[Blue_MiSfit]

So... I can play existing XviD content (awesome), but there's no way to serve decoded (from a d2v) YV12 frames into vdub right now?

[ObiKenobi]

Originally posted by Blue_MiSfit
So... I can play existing XviD content (awesome), but there's no way to serve decoded (from a d2v) YV12 frames into vdub right now?

Not until there is a 64-bit version of Avisynth.

[ChronoCross]

Kinda Defeats the point of having 64-bit versions of vdub and xvid since 90% of all encoded content today is done through avisynth. Perhaps The avisynth guru's should get to work on a x64 port.

[superdump]

If you have large amounts of HDD space, you could find some 64-bit optimised lossless codec and filter everything to a lossless file and then process it directly from the lossless file. Would that help?

[squid_80]

Originally posted by superdump
If you have large amounts of HDD space, you could find some 64-bit optimised lossless codec and filter everything to a lossless file and then process it directly from the lossless file. Would that help?

I've been thinking the same thing. A 64-bit version of huffyuv probably won't be too hard to do. Are there any other lossless codecs with source floating around?

[Blue_MiSfit]

I've been looking for a good lossless codec that would work in both 32 and 64 bit modes and I'm not seeing anything. I guess I will have to transcode some pre-existing material (MPEGs or an XviD AVI) to use for a speed test. Report coming soon.

[edit]
I took an 11:54 352x240 MPEG-1 clip @ 29.97 fps that had fair quality for being low resolution MPEG-1, and recompressed it into XviD using the following settings:

CQ2
Sharktooth's EQM V3HR
Adaptive Quant
Bvops @ 3/1.5/1
Quants 2-31
Trellis
MSP6
VHQ4
VHQ_Bvops

Everything else at default

And I got the following speed results:
XP Professional 32 Bit : 6:36
XP Professional x64 : 6:39

I also did a test with qpel enabled (which did produce horrible artifacts on the x64 edition, as expected) just for comparison and got the following results:

XP Professional 32 Bit : 9:48
XP Professional x64 : 9:55

As you can see, x64 is actually a bit slower. As expected :)

Just my results here folks,
~misfit

[Shinigami-Sama]

I still don't get how an encode ona 64bit system could be slower
it makes no sense
theres more of well everything :\
and extra 32bits increases teh amount of memory accsed a secnod by 2^23 more
and there aer more registers in teh 64 cpu
granted the clock speed is somewhat smaller
but amd makes up for that in decrased latancy and bottlenecks
it seems to defy logic :\
and another test should be done when avisynth64 come out
because it is kind of a slanted test unless there was no avisynth on the 32 encode
and test was made off a vcd?
isn't to low quality to make a vaild test?
I mean I find vcds hard to watch to begin with because of teh low detail
*heh funny thing I've noticed in this forum more so over others i syou guy seem to use "as" as "because" which is improper ;)
just a bit of fyi*

[chilledoutuk]

Originally posted by superdump
If you have large amounts of HDD space, you could find some 64-bit optimised lossless codec and filter everything to a lossless file and then process it directly from the lossless file. Would that help?

sort of defeats the point of 64bit optomised code as the only advantage to be had is faster encoding.

When microsoft pulls there collective thumbs out of there arses pehaps they will finally release the 64bit version of windows xp. Then there will be more incentive for 64bit versions of applications such avisynth.

[Joe Fenton]

Originally posted by Blue_MiSfit
And I got the following speed results:
XP Professional 32 Bit : 6:36
XP Professional x64 : 6:39

I also did a test with qpel enabled (which did produce horrible artifacts on the x64 edition, as expected) just for comparison and got the following results:

XP Professional 32 Bit : 9:48
XP Professional x64 : 9:55

As you can see, x64 is actually a bit slower. As expected :)

Actually, all this shows is that all the time is being spent in the areas that weren't optimized to take advantage of the extra resources in 64bit mode - i.e., the hand optimized MMX assembly routines. That makes sense... they made the routines in the first place because they do the majority of the work. You stated earlier you are using the same routines, so you aren't getting the benefit of 64bit. Those routines need to be converted to make use of SSE2 and the extra 8 SSE registers to REALLY see what it is capable of.

People always get confused when doing optimizations. They optimize something that is using less than 2% of the CPU and wonder why it's not any faster. You'll see that a lot as 64bit becomes more prevalent. People will be compiling programs with no regard as to what really needs optimizing and therefore see no improvement. What good is it to make the GUI 64bit -O3 optimized code when the rest of the program is optimized 32bit assembly? Rather extreme example, but it makes the point. You have to optimize the right parts of the program to see any improvement.

Most filters and codecs use hand-optimized assembly language subroutines that have been worked out to give the best results on a 32bit x86 CPU. These routines will have to be rewritten, some completely, for 64bit before multi-media takes a jump forward.

[squid_80]

Originally posted by Joe Fenton
You stated earlier you are using the same routines, so you aren't getting the benefit of 64bit. Those routines need to be converted to make use of SSE2 and the extra 8 SSE registers to REALLY see what it is capable of.

Is this directed at me? I never said this was an optimized build and I expected it to be slower than 32-bit. I put it here for two reasons: to unearth any serious bugs (crashes, bad output) and to give people a codec to use with vdub64. The only reason I said speed comparisons are welcome is because I expect them to be more or less the same, any significant difference should be investigated.

[Joe Fenton]

Originally posted by squid_80
Is this directed at me? I never said this was an optimized build and I expected it to be slower than 32-bit. I put it here for two reasons: to unearth any serious bugs (crashes, bad output) and to give people a codec to use with vdub64. The only reason I said speed comparisons are welcome is because I expect them to be more or less the same, any significant difference should be investigated.

Oh - well then, you succeeded. :D

I wasn't sure if you had expected it to be faster or not. Guess I should have reread the first posts. I missed that the first time through.

Well, at least it's about the same speed. I'm looking forward to when people start optimizing for 64bit. Even an extra 10 to 20% would be a help on a several hour long encode.

[squid_80]

Originally posted by Joe Fenton
Oh - well then, you succeeded. :D

Maybe. Only one tester so far, I wouldn't declare it bug free yet.

I think I've found the problem with qpel, I'll fix it and add a few new sse2 functions some time this weekend.

[Joe Fenton]

No, I meant in making it slower. ;) :D

You said you expected it to be slower - and you succeeded. :cool:

I don't currently have XP64 installed or I'd check it as well. I mostly stick to FC3 64bit these days. I haven't booted my main system into Windows in months. I've got a BP6 I use for Windows stuff right now.

[BBugsBunny]

Well I tried to test the x64 build as well, but I only get immediate crashes trying to encode an xvid avi in VD64 or trying to play a xvid file.

I use the (pre RC1) public available version of XP64 on a dual Intel Nocona Xeon 3.6GHz system.

XP64 itself runs fine, VD64 as well - did some tests with DV avi files.

[squid_80]

Originally posted by BBugsBunny
Well I tried to test the x64 build as well, but I only get immediate crashes trying to encode an xvid avi in VD64 or trying to play a xvid file.

I use the (pre RC1) public available version of XP64 on a dual Intel Nocona Xeon 3.6GHz system.

XP64 itself runs fine, VD64 as well - did some tests with DV avi files.

In the encoder configuration, under advanced options -> debug, can you try forcing all optimizations off. That should disable all the assembly functions.
If that works, try turning them back on except for the two 3DNow! options.

I didn't expect an Intel tester, the cpuid function has been hardcoded to return support for all instruction sets. Hopefully this is the problem.

[BBugsBunny]

Thanks squid_80!

Turning off the two 3DNow! options did the trick!
I encoded a dv avi as a 2 pass xvid avi without problems.
The playback still does not work under XP64 but I tested the file under w2k and it played back without any problems.
Can't find any decoder options to disable 3DNow!.

[squid_80]

Originally posted by BBugsBunny
Thanks squid_80!

Turning off the two 3DNow! options did the trick!
I encoded a dv avi as a 2 pass xvid avi without problems.
The playback still does not work under XP64 but I tested the file under w2k and it played back without any problems.
Can't find any decoder options to disable 3DNow!.

That's excellent to hear, it means I just need to fix the cpuid function (easy). I'll try and put a new download up tomorrow (with qpel fixed as well) then decoding should work for you.

[hellfred]

Originally posted by BBugsBunny

I encoded a dv avi as a 2 pass xvid avi without problems.
The playback still does not work under XP64 but I tested the file under w2k and it played back without any problems.If you just want to avoid having to boot to a non-x86 OS, you can try to build mplayer on win32 - meand win64 - using msys/mingw. AFAIK it has support for x86 systems. But i do not know, if it is possible to use 32bit msys/mingw binaries (of e.g. gcc) and get 64bit binaries. Maybe you have to crossscompile, either a new gcc or mplayer itself with a x86 enabled gcc.
Hellfred.

[Joe Fenton]

CygWin does not support Win64 in any form at this time, nor is it planned anytime soon according to their web page.

[hellfred]

Originally posted by Joe Fenton
CygWin does not support Win64 in any form at this time, nor is it planned anytime soon according to their web page.
So one needs to compile his own gcc that is able to crosscompile x86_64 binaries, to copy and run those binaries to the 64 bit windows. Let's see, if gcc can be compiled for win64. Looks like nobody succeeded up to now. (http://gcc.gnu.org/gcc-3.4/buildstat.html)

Hellfred.

[Joe Fenton]

Originally posted by hellfred
So one needs to compile his own gcc that is able to crosscompile x86_64 binaries, to copy and run those binaries to the 64 bit windows. Let's see, if gcc can be compiled for win64. Looks like nobody succeeded up to now. (http://gcc.gnu.org/gcc-3.4/buildstat.html)

Hellfred.

MS made their Win64 ABI incompatible with 64bit gcc ABI. Probably to force people into buying VS.Net. You can find a method of compiling Win64 programs here:

Link (http://www.amdzone.com/index.php?name=PNphpBB2&file=viewtopic&t=2216&sid=2bf7b233cc5aa8fd6b05ef23ad398d24)

[squid_80]

What exactly are we talking about building for XP64 - mplayer? Why? The windows media player that comes with xp64 is the same as previous versions.

[hellfred]

Originally posted by hellfred

Originally posted by BBugsBunny
I encoded a dv avi as a 2 pass xvid avi without problems.
The playback still does not work under XP64 but I tested the file under w2k and it played back without any problems.
If you just want to avoid having to boot to a non-x86 OS, you can try to build mplayer on win32 - meand win64 - using msys/mingw. AFAIK it has support for x86 systems. But i do not know, if it is possible to use 32bit msys/mingw binaries (of e.g. gcc) and get 64bit binaries. Maybe you have to crossscompile, either a new gcc or mplayer itself with a x86 enabled gcc.
Hellfred. [/B]
That is the reason we are talking about compiling mplayer for win32, to be able to evaluated the videos without having switch the OS.
Hellfred

[squid_80]

Originally posted by hellfred
That is the reason we are talking about compiling mplayer for win32, to be able to evaluated the videos without having switch the OS.
Hellfred

Windows media player works fine on win64 with ffdshow installed. I think that's a lot easier than rebuilding mplayer for win64.
I think when BBugsBunny said playback doesn't work under XP64 it's because he's either using virtualdub + my win64 version of the xvid codec (won't work because the cpuid function is broken for intel cpus) or he's using windows media player and it can't find a codec for decompression (ffdshow can fix this).

[BBugsBunny]

Actually I'm still using W2k and have XP64 installed only on an old 2 Gig HD to do some testing.
I wanted to see if XP64 works fine with my system and I was curios to see if VD64 works.
And if there are calls to test some interresting X64 builds like XviD I'll take a look as well.
I think even the time XP64 will be released it's far from the point that I'll actually will switch to XP64 because of the lack of diver/codec support (and no avisynth x64 in sight).
But it's good to have this old testing HD with XP64, so I can see when the time will be right to switch to XP64.

Did some SiSoft Sandra benchmark comparison as well (W2k/W2k3/XP64).
If someone is interessted the benchmaks can be found on the end of this tread:
http://forums.2cpu.com/showthread.php?threadid=58351

[Joe Fenton]

Originally posted by squid_80
What exactly are we talking about building for XP64 - mplayer? Why? The windows media player that comes with xp64 is the same as previous versions.

If you've been following the security bulletins and warnings in the news, WMP leads to spam and malware. I wouldn't use WMP if it were the only player out. It's bloated, slow, and tries to make me do what it wants instead of doing what I want. I use other players in Windows - for video I use BSPlayer, and for audio I use WinAMP. In Linux, I use xine and xmms.

The #1 way to secure your PC is don't use IE, OE, or WMP. Get replacements for all three and you'll be far better off.

[squid_80]

I am not promoting WMP. I am saying that I don't think building mplayer for win64 is worth the hassle when any 32-bit player will work just as well.

[Joe Fenton]

Originally posted by squid_80
I am not promoting WMP. I am saying that I don't think building mplayer for win64 is worth the hassle when any 32-bit player will work just as well.

64bit will do better eventually, but for now a 32bit player is perfectly fine in XP64. I used BSPlayer all the time I used XP64. It was indistinguishable from using it in 32bit XP Pro.

[squid_80]

I've made a windows x64 version of huffyuv to help with testing, if anyone wants it.

Download here (http://home.iprimus.com.au/ajdunstan/huffyuv64.zip), unzip, right-click the inf and install.

Using 32-bit windows, I load whatever mpeg-2 file I want to test into virtualdub via avisynth and transcode it to huffyuv. Then I can open the resulting file in vdub64 and transcode to xvid. Sounds kind of tiresome? Yeah, it is. But I couldn't think of an easier way to make the exact same clip accessible to both versions of vdub without using uncompressed files.