Windows x64 port

squid_80 · 2nd January 2005, 06:31

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 · 2nd January 2005, 14:48

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

Joe Fenton · 3rd January 2005, 02:46

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

http://ayo.freshrpms.net/fedora/linu...PMS.freshrpms/

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

sysKin · 3rd January 2005, 03:45

Quote:

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/linu...PMS.freshrpms/

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

Or just get it from CVS.

Blue_MiSfit · 3rd January 2005, 06:55

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

Blue_MiSfit · 3rd January 2005, 07:06

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:

Code:

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 · 3rd January 2005, 07:39

Quote:

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:

Code:

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 · 4th January 2005, 04:31

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?

4th January 2005, 05:43

Quote:

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 · 4th January 2005, 11:10

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.

4th January 2005, 17:39

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 · 4th January 2005, 21:38

Quote:

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 · 5th January 2005, 04:02

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 · 5th January 2005, 21:53

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 · 5th January 2005, 22:59

Quote:

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 · 6th January 2005, 04:33

Quote:

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 · 6th January 2005, 08:28

Quote:

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 · 6th January 2005, 23:17

Quote:

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.

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 · 7th January 2005, 00:11

Quote:

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

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 · 7th January 2005, 02:29

No, I meant in making it slower.

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

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.

2nd January 2005, 06:31	#1 \| Link
squid_80 Registered User Join Date: Dec 2004 Location: Melbourne, AU Posts: 1,963	Windows x64 port 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. Last edited by squid_80; 30th January 2005 at 08:27.

2nd January 2005, 14:48	#2 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,769	Interesting! I should re-install winxp for 64 bit extended systems and test it. __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!!

5th January 2005, 04:02	#13 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,231	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 Last edited by Blue_MiSfit; 5th January 2005 at 04:51.

3rd January 2005, 02:46	#3 \| Link
Joe Fenton Registered User Join Date: Jul 2003 Location: In a house. Posts: 663	You might check the source for the 64bit Linux version of xvidcore against what you're doing. http://ayo.freshrpms.net/fedora/linu...PMS.freshrpms/ You'll find an rpm of 64bit xvid source there.

3rd January 2005, 06:55	#5 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,231	this is so f___ing cool. I will test ASAP on my x64 install.

3rd January 2005, 07:06	#6 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,231	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: Code: 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?

4th January 2005, 04:31	#8 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,231	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?

4th January 2005, 11:10	#10 \| Link
ChronoCross Does it really matter? Join Date: Jun 2004 Location: Chicago, IL Posts: 1,542	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.

4th January 2005, 17:39	#11 \| Link
superdump Guest Posts: n/a	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?

7th January 2005, 02:29	#20 \| Link
Joe Fenton Registered User Join Date: Jul 2003 Location: In a house. Posts: 663	No, I meant in making it slower. You said you expected it to be slower - and you succeeded. 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.