64 bit avisynth?

[Blue_MiSfit]

Hello all,

I am just wondering if there are any plans to release avisynth for the Windows XP x64 edition beta. XviD and VirtualDub both have 64 bit branches now, and AviSynth is the only missing tool :)

If anyone has any information regarding this please let us all know!

Thanks
~misfit

[sh0dan]

MS has decided to ditch the current method of doing inline assembler, so basicly most assembler code has to be redone. :(

[Blue_MiSfit]

ouch.

[Richard Berg]

Intel's 64-bit compiler supports it (and has fewer bugs, from talking to several people), but their builds tend to be much slower than MS or GCC on AMD chips.

[Cyberia]

Originally posted by Richard Berg
Intel's 64-bit compiler supports it (and has fewer bugs, from talking to several people), but their builds tend to be much slower than MS or GCC on AMD chips. I thought I just read somewhere that the Intel compiler does not detect AMD processors having MMX/SSE/SSE2. It's a sneaky thing to do to make AMD look bad. There was a workaround too to force the optimizations anyway and then AMD performed very well indeed.

[d'Oursse]

cyberia: i think that it's here :

http://groups.google.ca/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.arch&selm=a13e403a.0402091438.14018f5a%40posting.google.com

[squid_80]

Wouldn't the assembly code need to be redone anyway?

[708145]

Originally posted by squid_80
Wouldn't the assembly code need to be redone anyway?

not completely, only the parts that would benefit a lot.

and yes: I'm looking forward to both Win64 and Lin64 versions of avisynth!

bis besser,
Tobias

[squid_80]

Originally posted by 708145
not completely, only the parts that would benefit a lot.


I mean any assembly code that uses memory addresses has to be redone, the 64-bit extended GPRs (rax, rcx etc.) must be used instead of the 32-bit registers (eax, ecx etc). So even if a compiler did support inline assembly, it would all still probably have to be modified. Not to mention other issues like microsoft saying MMX can't be used, certain instructions not being available in 64-bit mode...

[Sharktooth]

that's only an OS issue. the processor itself supports all mmx and x87 instructions in 64bit mode.
btw, you're right a big part of ASM should be rewritten but there are some tools on the AMD website that could help the transition a lot...

[squid_80]

Originally posted by Sharktooth
btw, you're right a big part of ASM should be rewritten but there are some tools on the AMD website that could help the transition a lot...
If it's that Convertsse2instrin perl script you're talking about, it sucks. I think they've removed it, and with good cause.

The instructions not available are things like "mov ah, [r8]" and a few undocumented opcodes like salc. Don't know if avisynth uses any of them, most are easy enough to work around anyway.

[JRepin]

Hi,

Has there been any progress on making 64-bit version for AMD64 possible? If not, when can ve expect it? Are there any plans for this?

Thanks for answers!

[Richard Berg]

If you read the above comments, you'll see we're not optimistic. Actually, if this blog is correct, the situation is even worse:

Regarding the (ick) comments about MMX: Don't use MMX on x64 [I don't think the ML64 assembler even supports it!]. I haven't yet seen a single scenario where MMX code runs faster than SSE2 code. The primary reason I've heard that people want to use MMX is because they already have a bunch of x86 ASM code using MMX. I have 1 word for you: rewrite. Chances are, if you don't rewrite it, your asm code will be completely wrong & broken, due to ABI restrictions - you won't discover this until you find yourself staring at a broken stack dump, or a terminated process, due to failed exception handling.
http://blogs.msdn.com/freik/archive/2004/11/06/253291.aspx

Honestly, I don't see how porting Avisynth to AMD64 would help, since all the time-sensitive portions are already vectorized. Some of the long script-functions being written by guys like Didee would benefit from large amounts of virtual memory, but not until machines with 2GB+ of RAM are common.

[JRepin]

Well you need a 64-bit app to use it from other 64-bit apps. You can't use 32-bit app. And avisynth is currently the only missing link in the 64-bit chain. Oh and some of us alreays have more then 2 GiB of memory

[708145]

Just to brag a bit:
dual opteron 250 with 16GB RAM here!

Eagerly awaiting 64 bit linux avisynth :p

bis besser,
Tobias

[Shinigami-Sama]

considreing I'm planing on buying an amd64fx mobo next
they would be nice to see
and iirc hte amd64 version of mmx sse1/2/3 ect. are slightly more effiacnt that intels;
but that might be flawed info on my part
but I love to see this come out before I buy hte amd64fx

[Richard Berg]

AMD K8 chips are slightly more efficient at MMX/SSE in that some of the latencies are lower, yes. However, if the instructions are ordered well enough that the P4's decoder can keep up, it's not enough extra efficiency to make up for the P4's clockspeed advantage.

[Shinigami-Sama]

AFAIK...
the AMD 64fx has a built-in ram manager as well
so that bumps up tranfer speeds of everything
and I guess I should clearify a bit more
I ment the 64fx;s that are coming out soon or just came out their new err 967 pin one
iirc I read that its latency was 80% lower than intel;s lastest P4
but I read that about a month ago I can;t rembmer hte link so I can't check though:(
but also
I read somewhere that intel uses two 64bit halves for sse and AMD uses a real 128bit channel
if so would that not make it more efficnat?
because 64bit+64bit=65bit seeing as how every bit you add you double hte infomation
but I might be off due to sleep deprivation though
but I still prefer amd over intel so this would give me a greater incentive to get hte ubernice 64fx when I get hte money

[squid_80]

Sorry to bring up this old thread again, but is anyone doing any work on porting to x64? I've done some basic work, got most of the core stuff ported and just finished an x64 version of dgdecode to go with it, I just want to make sure I'm not wasting time doing work that's already been done by someone else.

[sh0dan]

To my knowledge there isn't anyone else working on 64bit 2.5 based AviSynth. I'd love to help, but I don't have the platform available (or rather the OS available). Are you using VS .net 2003?

[squid_80]

Unfortunately, yes - VS.net 2003 with an old release of the winddk. I'm having problems with exception handling, Avery Lee tells me the latest VS 2005 beta fixes them but unfortunately I don't have an MSDN subscription so I can't get it. I figure I might as well wait for the retail version to come out.
Re the inline assembly code, which do you think would be a better way to go:
1. Changing it to intrinsics so it's not processor specific but still reasonably fast
2. Break the code out into seperate files, modify to x86_64 assembly and compile with yasm (or ml64, I guess). I prefer this method since you get more control over the hardware, but it's very non-portable. Plus you can use the MMX registers, although that's a bit of a grey area.

[sh0dan]

Isn't intrinsics MS specific? AFAICT, YASM should be portable to other x86-64 based systems, except that

- I'm still hoping for SoftWire to become 64 bit aware (http://sourceforge.net/forum/forum.php?thread_id=1095618&forum_id=184692). That would be a great solution.

[tsp]

It seems as if someone did make a 64 bit build. I don't know if it's 3.0 or 2.5 though.
http://www.planetamd64.com/index.php?showtopic=5013

[d'Oursse]

i don't think it's for 3.0 ;)

[Wilbert]

@squid_80,

1) On which build is AviSynth64 based?

2) Could you also release its source?

[squid_80]

@shodan: Softwire support would indeed be a great solution. When I said using yasm would be less portable I meant that it would be possible for someone to break the assembly unknowingly by changing the C code... I guess it's still not very clear what I mean.

@tsp: Recognise the planetamd64 user's name? ;)

@Wilbert: It's based on 2.55. The source is nothing special, it's mostly the same except for the resample code which got hacked up something terrible (putting pointers in an int array is not a good thing). It's available at http://home.iprimus.com.au/ajdunstan/avisynth64src.zip

[Richard Berg]

Avery Lee tells me the latest VS 2005 beta fixes them but unfortunately I don't have an MSDN subscription so I can't get it.
Beta 2 will be available to everyone very soon.

[squid_80]

Originally posted by Richard Berg
Beta 2 will be available to everyone very soon.

Good to hear, should fix the broken stack unwinding I'm getting. Hopefully the license will allow for redistribution.

[IanB]

Dear all,

As discussed (PM's) with Wilbert I have added Andrews source to the CVS repository with the branch Avisynth64.

Take a peek at Avisynth64 CVS branch (http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/src/?sortby=date&only_with_tag=Avisynth64#dirlist)Originally posted by squid_80
@Wilbert: It's based on 2.55. The source is nothing special, it's mostly the same except for the resample code which got hacked up something terrible (putting pointers in an int array is not a good thing). It's available at http://home.iprimus.com.au/ajdunstan/avisynth64src.zip Regards
IanB

[Wilbert]

So, anyone who wants to help squid_80 with porting (resizers except in YV12, color conversion routines and other stuff) can send us a PM.

Btw, dgdecode 1.2.1 is already done! But, it's the only plugin though ...

[squid_80]

Thanks guys. I'm struggling to get a x64 build of 1.1.0-beta2 xvid done at the moment (weird problems decoding b frames when compiled with the new PSDK, grrr) but as soon as that's sorted I'll get back to work on avisynth64. First task is to clean up all that sizeof(BYTE*)/sizeof(int) mess. I dunno why I didn't use a #define in the first place.:D Also I can't remember what I did with the Bitblts, but I bet they're less than optimal.

I guess if people want to start suggesting plugins (that have source available) that they would like to see done, here is as good a place as any. But be prepared to be patient (unless you want decomb - it's already half done).

[708145]

Originally posted by squid_80

I guess if people want to start suggesting plugins (that have source available) that they would like to see done, here is as good a place as any. But be prepared to be patient (unless you want decomb - it's already half done).

Great work.

But I'm confused: Is avs64 the same as avs3 ?
And which (if different) supports linux64 native?

About the filters: Just keep on porting :p Sadly for most filters I use the source is not published :(

bis besser,
Tobias

[Wilbert]

But I'm confused: Is avs64 the same as avs3 ?
Nope. (avs64 is based on 2.5.5, and avs3 is totally rewritten ...)

And which (if different) supports linux64 native?
The former for sure doesn't. I don't know about avs3 (don't think so, but perhaps bidoche can comment here ...).

[d'Oursse]

the 3 asm files of avs3 are not written for 64bits processors.

for a 64 bits version of avs3 on linux, just use a version of gcc that produces 64 bits executable/library

[708145]

Originally posted by d'Oursse
the 3 asm files of avs3 are not written for 64bits processors.

for a 64 bits version of avs3 on linux, just use a version of gcc that produces 64 bits executable/library

:D So avs3 compiles (without asm) on linux64? Awesome! :D

Now it just has to be finished...

bis besser,
Tobias

[pogo stick]

Squid, thank you for your build. I wanted to try this, but it didn't work for me. I did everything you wrote: copied avisynth.dll, clicked .reg, rebooted, used dgdecode64.zip, but VirtualDub gives me an error.

AVI Import Filter error: (Unknown) (80040154)

Did I forget about something? :confused:

[squid_80]

You are using windows x64 and veedub64.exe, correct?

[pogo stick]

Yes, correct.
By the way, your XviD build is working.

[squid_80]

Not really sure, sounds like avisynth.dll can't be found. Make sure it's in the right /windows/system32 dir (using a 32-bit file explorer can fool you), if that doesn't work try putting it in the same directory as veedub64.exe.

[pogo stick]

If I copy avisynth.dll to C:\WXP64\system32, the same file appears in C:\WXP64\SysWOW64. If I delete it from system32, it disappears from SysWOW64.
Putting avisynth.dll in veedub64.exe directory doesn't help.

[squid_80]

Then something is wrong; sounds like some 32-bit process is making you see /wxp64/sysWOW64 as /wxp64/system32.

[pogo stick]

Oh, I get it. FAR manager (32 bit) was the one who tricked me. I should look for 64 bit file managers.

Now it's working. :)

[Wilbert]

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



http://forum.doom9.org/showthread.php?p=666155#post666155

[squid_80]

Now that I think about it, I'm fairly sure what I wrote above (wilbert's quote) is wrong - it's more likely the coefficients are being calculated correctly but being overwritten/stored incorrectly. I'm guessing this because
a) only horizontal resize seems to be affected and it stores pointers (64-bit) in the same array as the pixel values. Probably the pointers are overwriting something or the array is overflowing.
b) Do point and bilinear use less taps than the others? Again this would indicate the array is not big enough due to the larger pointers.
Anyway, I'll work on it some more and see what happens.

Also using version() as a source to check that 2 different copies of avisynth produce binary compatible output is really dumb. I can't believe it took me two hours to realize that.

[squid_80]

I'm still trying to find how these discrepancies are sneaking in and seem to be getting pretty close. But can someone with intimate knowledge of the YV12 resampling algorithm please explain something to me about this code (from resample.cpp, starting at about line 292):
x86.paddd(mm3,mm7);
x86.paddd(mm4,mm7);
x86.psrld(mm3,14);
x86.paddd(mm5,mm7);
x86.psrld(mm4,14);
x86.psrld(mm5,14);
if (isse) {
x86.pshufw(mm3,mm3,(char)248); // 11111000
x86.pshufw(mm4,mm4,(char)143); // 10001111
x86.pshufw(mm5,mm5,(char)248);
x86.packuswb(mm3, mm3);
x86.packuswb(mm4, mm4);
x86.packuswb(mm5, mm5);
x86.por(mm3,mm4);
} else {

I'm wondering why mm3 and mm4 don't have the unneeded bits stripped away before the or operation. Near the top of the code the doubles held in the registers are shifted right by 14 bits, leaving 2 unknown bits in the high word. If these 2 bits aren't 0, they can survive the shuffles and packs and end up being or'ed into the final result. Or have I missed something?

[IanB]

Squid,

This code is the ultimate abuse of mmx arithmetic. The code that preceeds the code shown above that does the pmaddwd's and sums into mm3/mm4/mm5 has very carefully crafted coefficients from the generator code that make sure the sum doesn't exceed 16384*255*255. The great leap of faith is the way pixel pairs are treated as a single 16 bit word for much of the arithmetic. I still can't convince myself there is no carry across pixel pairs, but the code works.

To help understand the number ranges track backwards from the output "movd [eax],mm3" and make the assumption that each byte is between 0 and 255 and each deriving word or dword is ranged not to violate this, particularly the packuswb's.

Regards
IanB

[squid_80]

If there is no carry, then shouldn't this code perform the same:
if (isse) {
x86.pshufw(mm4,mm4,(char)248); // 11111000
x86.pshufw(mm3,mm3,(char)143); // 10001111
x86.pshufw(mm5,mm5,(char)248);
x86.packuswb(mm3, mm4);
x86.packuswb(mm5, mm5);
x86.psrlq(mm3,16);


(swaps the way mm3 and mm4 are shuffled, packs them both with one instruction into the centre of mm3 then shifts the results into bottom dword)

This gives different results to the existing code (try it on bright clip).

[IanB]

Hmmm, re-evaluating what I said, the sum limit should be only 16384*255. The pixel pairs stuff is total bull, I forgot about the byte to word explosion into the temp array.

For an excess to occur the coefficients have to sum to at least 16417, thats a lot of rounding error, or be negative (shudder) but I can't say it's impossible. Also there was that problem with zero coefficient sum that I was never completely satisfied with.

I've been putting off looking at this code because it is so devious and I was going to do an SSE2 version when the chroma planar alignment came of age. Research and testing required.

As for better code, this is how it should be, 9 isse/10 mmx -> 4 mmx. x86.packssdw(mm3, mm4);
x86.packssdw(mm5, mm6);
x86.packuswb(mm3, mm5);
x86.movq(qword_ptr[eax],mm3);IanB

[squid_80]

I wasn't really giving an example of better code, just a different method that should give the same answer IF the 32-bit sums are < 2^30. But it gives different results. In fact the softwire isse, softwire mmx, assembler isse and assembler mmx algorithms all seem to give slightly different results. Mainly because they all assume the two MSBs of the sums are 0. Same goes for your code sample using packssdw; values that should be 0 seem to be coming out as 0xFF due to the dword->word conversion saturating to 0x7FFF and the following word->byte conversion saturating that result to 0xFF.

I think I'm going to have to wade into this with the debugger.

[IanB]

And you have given me the answer. Some of the coefficents are negative, particularly from Lanczos, which given the right image, ones with sharp black/white transitions, will have some ringing which may overshoot negative.

The psrld's should be psrad's so that negative results stay negative and get saturated to zero.

Thanks
IanB

P.S. I am going to have to talk to Wilbert about being allowed to swear in this forum, I really to right now. Don't all programmers speak fluent profanity. :D

[squid_80]

And you have given me the answer. Some of the coefficents are negative, particularly from Lanczos, which given the right image, ones with sharp black/white transitions, will have some ringing which may overshoot negative.

Sounds exactly right. When I said above to try it on a bright clip, I should have said try a clip with closely contrasting pixels, or something like that. The clip I'm using is the start of a movie with white credits being displayed over a dark screen. It's the gaps between the letters that are coming out wrong.

The psrld's should be psrad's so that negative results stay negative and get saturated to zero.

Looks good... I think. Still a bit puzzled about some of the discrepancies the original softwire code was spitting out, like how can 0x0E become 0x11 via a single or operation? Maybe I'm seeing things.
FilteredResizeV::GetFrame might need to be modded as well. Although it looks immune since it shifts to the left, not the right.

Thanks
IanB

P.S. I am going to have to talk to Wilbert about being allowed to swear in this forum, I really to right now. Don't all programmers speak fluent profanity. :D
Do what I do, save it for the source code comments (although Wilbert probably won't like it there either). :p

[IanB]

Have you got a YUV->RGB conversion in there somewhere.

0x0E = 15 rgb -> 29 yuv = 0x1D
0x11 = 17 rgb -> 31 yuv = 0x1F
0x1D | 0x03 = 0x1F

All the Horizontal YUV code has the fault, the RGB and Vertical look okay. Fortunately the effect is invisible to the eye. Well spotted, thanks again.

IanB

[squid_80]

No conversion that I'm aware of, the script serves YV12 to vdub set for direct stream copy (no compression) into an avi. Checking the avi file by going to file information says it is uncompressed YV12 and the file size indicates the same. Most binary differences are of the expected form (incorrect value == correct value | 0x3) but every now and then there would be one like I mentioned. It's a very nice theory though. ;)

It was very visible when using the mmx (not isse) code, I'm surprised no-one's mentioned it before. Maybe they passed it off as extreme ringing or perhaps it's because I was enlarging the frame rather than reducing, which is what most people probably tend to do for compressing etc.

[IanB]

Maybe there is a secondary fault. Let me know when you find it. :D

Cheers :)
IanB

[mp3boy]

No conversion that I'm aware of, the script serves YV12 to vdub set for direct stream copy (no compression) into an avi. Checking the avi file by going to file information says it is uncompressed YV12 and the file size indicates the same. Most binary differences are of the expected form (incorrect value == correct value | 0x3) but every now and then there would be one like I mentioned. It's a very nice theory though. ;)

It was very visible when using the mmx (not isse) code, I'm surprised no-one's mentioned it before. Maybe they passed it off as extreme ringing or perhaps it's because I was enlarging the frame rather than reducing, which is what most people probably tend to do for compressing etc.


hi dude, I was wondering if you can port VFapi to 64bit? I use it almost everyday and it is very important thing for me.

thanks

[squid_80]

What exactly do you use VFAPI for? I don't see the need for a 64-bit version.

[mp3boy]

I use it to watch dvd ripped in subtitle without doing re-encoding and make my subtitle and recompile the dvd back again, thats a very fast way to make a virtual avi from a DVD that can easily played in any video player to test my subtitle with actual dvd

[squid_80]

Unless all the programs you use to do this are 64-bit (I don't know of any 64-bit video players, unless you include virtualdub) there's no point making a 64-bit version of VFAPI. Why isn't the 32-bit version sufficient? Or why can't you use avisynth?

[mp3boy]

Unless all the programs you use to do this are 64-bit (I don't know of any 64-bit video players, unless you include virtualdub) there's no point making a 64-bit version of VFAPI. Why isn't the 32-bit version sufficient? Or why can't you use avisynth?

any 64bit video player? I'm actually confused about this, I tried to play Vfapi in BSPlayer/Viplay/VideoLan but no luck, or maybe is it suppose to be played and I have some misconfiguration?

thanks

[squid_80]

Only true 64-bit programs can use 64-bit dlls. If I compiled a 64-bit version of VFAPI, only true 64-bit programs would be able to use it. BSPlayer/Viplay/VideoLan are all 32-bit programs, so they wouldn't benefit. But they should be able to use the regular 32-bit version, if it's not working for you then I'm guessing there's a configuration error somewhere. You don't say why it doesn't work, if there is sound but not video try changing the video card drivers, many people seem to have this problem.

[mp3boy]

the file doesn't have sound but virtualdub 32bit also cannot play the file, when I tried to open in device manager it says: "Cannot load the VFAPI 1.05 Driver. the driver may be missing. Try installing the driver agian, or contact your system administrator".

I tried to reinstall the coded for many times.

I also like to add that I have xvid 32bit installed but VirtualDub doesn't detct it and Device Manager (video codec) open its properties with no error.


thanks

[squid_80]

How is the VFAPI driver installed? With an exe or an inf file?

[mp3boy]

it installed with a batch file containing this:

rundll32.exe advpack.dll,LaunchINFSection vifp.inf,DefaultInstall

and this inf file content which is installing fine:


[Version]
Signature="$CHICAGO$"

[DefaultInstall]
CopyFiles = CodecCopyFiles
UpdateInis = vifp.UpdateIni

[DefaultInstall.NT]
CopyFiles = CodecCopyFiles
AddReg = RegCodecNT

[DestinationDirs]
CodecCopyFiles=11

[vifp.UpdateIni]
system.ini, drivers32,,"VIDC.VIFP=VFCodec.dll"

[RegCodecNT]
HKLM, "Software\Microsoft\Windows NT\CurrentVersion\Drivers32","vidc.vifp", ,"VFCodec.dll"
HKLM, "Software\Microsoft\Windows NT\CurrentVersion\Drivers.desc", "VFCodec.dll",, "VFAPI 1.05"

[SourceDisksNames]
1="VFAPI Reader Codec v1.05 install","",1

[CodecCopyFiles]
VFCodec.dll

[SourceDisksFiles]
VFCodec.dll=1


and this is the other inf file which has problem to load:

[Installable.Drivers]
VIFP = VFCodec.dll, "VIDC.VIFP", "VFAPI Reader Codec 1.05" , , ,

[squid_80]

That's the problem. Win64 thinks it is a 64-bit driver and is trying to install it as such. Try changing the line in the batch file to:
c:\windows\syswow64\rundll32.exe advpack.dll,LaunchINFSection vifp.inf,DefaultInstall

You might need to change the c:\windows part, depending on where your windows installation is. Let me know if it helps.

[mp3boy]

thanks mate, its working now, I dont know why it was not working before. however the video codec in device manager for vfapi still gives error which doesn't matter anyway.

actually I thought that I need every single codec to be converted to 32bit in order to be able to use, but virtualdub32 still doesn't detect Divx3,4,5 and xvid even though i have installed the codec

[squid_80]

Decomb (http://home.iprimus.com.au/ajdunstan/decomb.zip) (source (http://home.iprimus.com.au/ajdunstan/decomb64src.zip))
UnDot (http://home.iprimus.com.au/ajdunstan/undot64.zip) (source (http://home.iprimus.com.au/ajdunstan/undot64src.zip))

[Calculon]

Are these files no longer available? I keep getting a 404 error and I would like to try this version.

[squid_80]

Give me a few days, had to change ISP. I'll post new links soon.

[squid_80]

I've quickly setup a FTP server: ftp://squid80.no-ip.com

Should be available most of the time, might be down now and then between reboots.

[Calculon]

Thank you. :)

[wiak]

Squid can you compile lanczos4 for x64?
lanczos4 is faster to ;)

[squid_80]

Lanczos4 should already be working, did you try it?

[Bluedan]

Hm. Squid, have you given up on this project? Your ftp server is unavailable and the temporary avisynth64 compile also.

Unfortunately, I am unable to code by myself. :(

[squid_80]

Just started getting back to it, I've just finished doing levels and overlay.

See http://okejl.dk/dunstan/ for latest builds. (Note that filters.txt in the zip file is probably not up to date, if you want to know if something works just try it and see what happens.)

[Bluedan]

Just started getting back to it...
Glad to hear.

See http://okejl.dk/dunstan/ for latest builds. (Note that filters.txt in the zip file is probably not up to date, if you want to know if something works just try it and see what happens.)
Will do that. Thanks for your efforts! Really appreciated!

[BoNz1]

Hi, I just got myself a new AMD64 x2. So, I'm running Windows XP Pro x64 on it. I put avisynth.dll in the windows/system32 dir and ran the reg patcher. My avisynth script looks like this:

loadplugin("E:\Video\DGDecode.dll")
mpeg2source("E:\A_NEW_HOPE\VIDEO_TS\A New Hope.d2v")

When I load this avisynth script into Virtualdub 1.6.15 AMD64 I get this error:

"This application failed to start because libmmd.dll was not found."

I also have squid_80's latest xvid64 release installed. I have placed the libmmd.dll in my virtualdub folder with the dgdecode plugin in the same directory. This gives the same error. When I place it in the system32 dir I also get this error. Can anyone help me out? Cheers.

[squid_80]

Where did you get that copy of libmmd.dll? It would need to be a 64-bit version of Intel's math library, which I can't seem to find out on the net. I have it here on my machine of course, but I can't find anything that says I'm allowed to redistribute it.
-------
OK, apparently I am allowed. Unfortunately it's a great big whopping thing of 1.36mb, so in the future I'll make sure to stick to multi-threaded builds instead of multi-threaded dynamic.
http://okejl.dk/dunstan/libmmd.zip
Clear out all the other copies, stick this in \windows\sytem32 and everything should work.

[BoNz1]

Hi,

That fixed it, thanks :).

[nibbles]

Nice work on the 64bit port. Any chance we'll see a TcpDeliver.dll for it?
I have a huge file I'd like to serve over the network.
TDeint running on 1, DeGrainMedian64 on the other.
Ok, thanks.

[squid_80]

Any chance we'll see a TcpDeliver.dll for it?
It's harder than it sounds because of the compression libraries used. But as soon as I get some decent time I'll try again.

[Bluedan]

Are there any plans on updating the x264 cli 64bit version on a regular basis?

[squid_80]

I normally update it when I want to use it. Unfortunately that's not very regularly. :) Probably about once a month.

EDIT: I just had a look at x264's recent changes and there's a patch for amd64's motion compensation functions which changes most of the "ret" instructions to "rep ret". I looked at it and said "huh? that doesn't make sense..." then googled and found this:
AMD's guidelines to compiler writers recommends this particular combination to avoid making the ret instruction be the target of a conditional jump instruction. This is the case here, because it is preceded by a jg instruction, and in the event the jump condition does not hold, the program "falls through" to the return. According to AMD, the processor does a better job predicting the outcome of the branch if it does not have a ret instruction as a target. This rep instruction will have no effect, since it is not followed by a string manipulation instruction. Its only purpose is to serve as a branch target.
If this proves true it could also be very useful for avisynth64's resizing functions, which I have been recently tuning to try and beat the originals (or just equal, in the case of softwire's horizontal yv12 algo. It's damn fast!). So expect a new avisynth64 build sometime this week too.

[Kostarum Rex Persia]

Wow, that's really great news, squid_80.

[Bluedan]

Sweet! I'm looking forward to it. :)

[G_M_C]

Besides a 64-bit AviSynth Ii would be very interested if AviSynth will work on Vista.

I'm curious about that because i understand that Vista does not use vfw-as-we-know-it anymore. And since Vista is nearing its release, it would be nice to know if we can keep using our favorite video-tool on this new OS too :)

[foxyshadis]

Virtualdub works fine, so avisynth must. I believe MCI, VFW, and all the other deprecated APIs will be built on a "virtualized" platform of the new APIs, WASAPI. Maybe it'll be slower, maybe noticeably so, but it'll still work like always. (Barring new bugs.)

[Prettz]

Virtualdub works fine, so avisynth must. I believe MCI, VFW, and all the other deprecated APIs will be built on a "virtualized" platform of the new APIs, WASAPI. Maybe it'll be slower, maybe noticeably so, but it'll still work like always. (Barring new bugs.)
Do you mean that WASAPI will act as an abstraction of the OS's actual API?

[foxyshadis]

No, WASAPI is the new bare-metal level API. (Or rather, a whole stack from bare metal to high level.) All the rest will be reimplemented on top of it. The only one I'm not sure about is DirectAudio, I don't know if they're one and the same or if they're separate but joined somehow.

[Richard Berg]

DirectSound sits on top of WASAPI, yes.

@squid80 - where is the code for avisynth64 stored?

[Wilbert]

@squid80 - where is the code for avisynth64 stored?
http://avisynth2.cvs.sourceforge.net/avisynth2/avisynth/src/?pathrev=Avisynth64

[Richard Berg]

Strange -- that doesn't show up in TortoiseCVS' list of tags.

[Bluedan]

<cough slightly>
Well, Squid80 - is it 1980, year of birth? - it is not that I am not satisfied with the current situation. Just you recently mentioned an update on avisynth64 and perhaps x264 for the last week, that's why I am asking for the current state of progress.
Hope you're doing fine, bye.

[squid_80]

I got distracted with something else. No new x264 for now, but I've uploaded my current build of avisynth64. Changes:
- Faster YV12 resizing
- YUY2 resizing works
- DirectShowSource plugin is included. Don't bug me for 64-bit splitters or codecs. Celtic_druid has 64-bit compiles of Gabest's mp4 and mkv splitters, he also has an old 64-bit ffdshow build for codecs (h264 decoding seems slightly broken, I searched and found a 64-bit build by videomixer9 that worked).

I also uploaded a fixed build of undot64, the old one sometimes missed the final few pixels on the top and bottom lines.

[Audionut]

Hi squid_80.

First thanks for your work. Much appreciated.
Second. I searched (obviously not good enough) and couldn't find Celtic's 64bit compiles. Could you provide a link.

Thanks.

[squid_80]

The splitters (mp4splitter and matroskasplitter, a few others but they're the common ones): http://esby.free.fr/CelticDruid/mirror/Media%20Player%20Classic/external%20filters/x64//
celtic druid's 64-bit ffdshow: http://ffdshow.faireal.net/mirror/ffdshow/ffdshow64-rev2546.exe
videomixer9's 64-bit ffdshow: errr, I found the post but it's gone. I have the rev. 2504 build, maybe try the others listed in this search: http://forum.doom9.org/search.php?searchid=1247582

If they have the same h264 decoding bug pm me with an email address and I'll send the one I'm using.

[Bluedan]

Hi squid80.

I'm still curious if there's something in work with a new x264 build. The latest is rev557 and is working very well over here.
Now rev600 barrier has been reached with a lot of contributions since then.

Again: just a question, no demand.

BTW, is it Avisynth related that the avisynth creator within MEGUI won't open my d2v file stating no dgdecode_mpeg2source function known? AFAIK that 64bit version from you should be able to handle the ..._ prefix .

[squid_80]

(I'm getting really sick of these $#@ing "The server is too busy" error messages.)

Rev 602 of x264cli for windows x64 is available @ http://members.optusnet.com.au/squid_80/x264cli_x64.zip . I haven't tested it much so it may be unstable.

I don't use MeGUI so I can't be sure where the error message is coming from.

[Bluedan]

Thanks alot.
Obviously MeGUI crashed during last nights encode with x264_rev602_64bit.
I found the PC this morning being stuck in a power saving mode, so the screen was off and never revivable. So I had to cut the currency the hard way...

It seems MeGUI quit at one third of the 2nd pass according to the size of the resulting unplayable mp4 file.
I rather blame some memory timing settings in the BIOS I was playing with than the applications involved in encoding,
for my PC is overclocked which is risky, I know.

I will try again and will report later.

[Romario]

Try omion 64-bit build from http://omion.dyndns.org/x264x64/604-omion.rar

[Blue_MiSfit]

This has all come a long way. Thanks squid_80 and all others who have worked so hard to provide an encoding platform on x64!

~MiSfit

[Bluedan]

OK. Squid80s build worked very well now. Great!

[squid_80]

Tdeint plugin for avisynth64: http://members.optusnet.com.au/squid_80/tdeint64.zip
The source I used is a little old (before there were asm optimisations) but at least it exists. I'll see if I can update it.

[Bluedan]

@squid80

Got the 64bit versions of TDEINT v1.0b4 and EEDI2 v0.92 from the usual place. I renamed EEDI2_imp.dll to EEDI2.dll
Both filter reside in the same plugin folder for the avisynth64.

When trying to run this script in MeGUI, the function EEDI2 wasn't found.

DGDecode_mpeg2source("F:\house of flying daggers\hofd.d2v")
edeintted = last.SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=-1,edeint=edeintted)
crop( 2, 76, -2, -76)
LanczosResize(704,288) # Lanczos (Sharp)

When I change lines 2 and 3 to just TDeint(order=-1) it works.
Where is the culprit? Why did you name it ~_imp?

(BTW, which revision is the current x264_x64 now from 03-01-2007?)

[squid_80]

When I try that script, I get an error saying tdeint doesn't have a edeint option. This is because it's based on an old version. The EEDI2 function works fine and the dll is called EEDI2_imp.dll to distinguish it from the non-multithreaded build.
64-bit x264 is a build from somewhere between 614-618, there were no functional changes between them (and only one tiny change up to current r622).

[Bluedan]

Tdeint plugin for avisynth64: http://members.optusnet.com.au/squid_80/tdeint64.zip
The source I used is a little old (before there were asm optimisations) but at least it exists. I'll see if I can update it.

:) OK.

Will you update TDEINT64 then? The TDEINT/EEDI2 deinterlacing method seems to be the best one around AFAIK.

[squid_80]

Will you update TDEINT64 then? The TDEINT/EEDI2 deinterlacing method seems to be the best one around AFAIK.

Probably, but there's a whole stack of inline assembly in the later versions that will take a fair bit of time to wade through. A lot of it appears to be based on frame size (e.g. for i=0 to height {for j=0 to width {do stuff} } ) so I might see if I can do it with softwire.

[foxyshadis]

TDeint/TIVTC still include the C++ versions of every function, though, so if you want you could just strip all that assembly back out and give it a compile. With all the fixes and new modes it's quite worthwhile!

[squid_80]

May as well do it right the first time. If I get it right with softwire it might (possible but not likely) make 32-bit faster as well.

[chiklit]

Which files do I need to install to get this working? I've installed the main avisynth64 dlls as per the instructions earlier in this thread, but still every program that tries to open an avisynth file either crashes or freezes. Is there something else I need? Or is there a way to get the 32-bit version of avisynth to work on Vista x64? I also have the 64-bit version of ffdshow installed.

Also, if one thing is 64-bit then does everything in the process now need to be 64-bit? Since meGUI, being a .NET app, automatically runs in 64-bit mode does that mean I then must have the 64-bit version of everything it uses? Avisynth, x264, etc.?

Specs:
CPU: Intel Core 2 Duo R6400 (Overclocked - 2.8GHz) | Mobo: EVGA nForce 680i SLI | GPU: XFX nVidia GeForce 8800 GTX 768mb GDDR3 | Memory: 2gb DDR2 PC5400 667MHz Dual Channel | PSU: Antec Neo HE 550w | Sound: SoundBlaster X-Fi Xtrememusic | HDD: 950gb total SATA3 | OS: Windows Vista Ultimate 64-bit

[squid_80]

Which files do I need to install to get this working? I've installed the main avisynth64 dlls as per the instructions earlier in this thread, but still every program that tries to open an avisynth file either crashes or freezes. Is there something else I need? Or is there a way to get the 32-bit version of avisynth to work on Vista x64? I also have the 64-bit version of ffdshow installed.I don't have experience with vista but 32-bit avisynth should work fine as long as the host program is also 32-bit. Crashing or freezing would seem to be a different problem rather than an installation error.
Also, if one thing is 64-bit then does everything in the process now need to be 64-bit? Since meGUI, being a .NET app, automatically runs in 64-bit mode does that mean I then must have the 64-bit version of everything it uses? Avisynth, x264, etc.?
Yes 64-bit programs can only use 64-bit dlls (avisynth, plugins, codecs etc.), however MeGUI has a special flag that makes .net run it as a 32-bit app (for exactly that reason). Unless the flag has been left off when it was compiled, which happened once not long ago. When it is running check the image name in task manager, it should have *32 at the end to show that it's a 32-bit process.

[chiklit]

Yes 64-bit programs can only use 64-bit dlls (avisynth, plugins, codecs etc.), however MeGUI has a special flag that makes .net run it as a 32-bit app (for exactly that reason). Unless the flag has been left off when it was compiled, which happened once not long ago. When it is running check the image name in task manager, it should have *32 at the end to show that it's a 32-bit process.

Ah, I guess I must've been thinking of that version. It's running in 32-bit mode now. I wonder what would be causing the crashes then...

With the 32-bit version of avisynth and MPC, when I try to open an avs file in it, it'll sit there at 50% CPU but never play anything. And when I try to open it in the 32bit VirtualDub 1.7.0 I get this error:
Avisynth open failure:
Avisynth: script open failed!

Opening it in megui gives this error:
The file D:\Captures\Adventure of English.avs cannot be opened.
Please make sure it's a valid AviSynth script and that AviSynth is properly installed.
You can check the validity of your script and AviSynth installation by opening the file in your favorite media player.
If that works, try opening the video in VirtualDub(Mod) as well. If the former works and the latter doesn't, install a YV12 codec.
Error message for your reference: External component has thrown an exception.

The script:
audio=directshowsource("E:\Captures\Adventure of English T01 DELAY 62ms.wav", video=false, audio=true)
video=DGdecode_mpeg2source("E:\Captures\Adventure of English.d2v")
audiodub(video,audio)
Trim(1246,13907) ++ Trim(14893,31362) ++ Trim(34432,53650) ++ Trim(54575,66708) ++ Trim(67335,87660)
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)
crop( 6, 30, -16, -38)
Levels(25, 1, 255, 0, 255, coring=false)

LanczosResize(640,416) # Bilinear (Soft)
Trim(52230,52430)
#denoise

[Bluedan]

I've installed the main avisynth64 dlls as per the instructions earlier in this thread [...]

If you follow these instructions (http://forum.doom9.org/showthread.php?p=909401#post909401) and probably also those in the posts below that one it should work.

I assume you didn't install avisynth 32 bit correctly? Try a fresh reinstall. avisynth 64 bit will only be used if it is called by a 64bit encoder.

It still works fine over here. :)

BTW: EDEINT won't work currently in 64bit flavour, as I found out recently, see post above!

[squid_80]

Something new: MipSmooth for x64 (http://members.optusnet.com.au/squid_80/MipSmooth64.zip). (Don't feed it rgb or you'll get an error about resizers only supporting YUV. Whoops.)

[tjmitchem]

First off, major major thanks to squid_80 for doing all this work :thanks:

I currently have virtualdub64, avisynth64 and dgdecode64 working well together. Unfortunately, whenever I try to use the decomb64 plugin, virtualdub crashes. According to VS2005 Pro, the crash is happening in decomb.dll.

Is there anyway I can get a debug version of decomb.dll and a pdb file so I can track down where this is happening?

Terry

[squid_80]

The source code can be found at http://members.optusnet.com.au/squid_80/sources/

I recommend using yasm r1591, later versions sometimes give errors.

[andersa]

squid, first of all, thanks for all the great work you've done on 64-bit video handling!

I have just installed Vista x64 and have a slight issue with the xvid64, i.e. I get this error message when attempting to install xvid64: "The INF file you selected does not support this method of installation". Any idea how the INF file can be tweaked to support vista?

[squid_80]

Don't have vista, don't plan on getting it.
Try celtic_druid's exe based installer available here (http://ffdshow.faireal.net/mirror/XviD/).

[andersa]

Thanks squid. That version works indeed.

[Bluedan]

Well, the usual question: any further developments in the 64bit camp meanwhile?
The usual place (http://members.optusnet.com.au/squid_80/) is happily still available but no updates for months...

I'm still highly interested in TDEINT64 :)

[squid_80]

It's only been 3 months since I made mipsmooth64 :)
I have an updated build of avisynth64 using 2.5.6's cache which makes it much more comparable in speed to the currently available 32-bit versions, new tdeint64 and motion64 (from clouded's source code) will hopefully be projects for this weekend (if I can fight the temptation to hack into ffmpeg; on my new q6600 it only uses ~50% cpu, even with 4 threads).

[Bluedan]

Promising!

I'd be glad to be prime tester on monday! :p

[squid_80]

New 64-bit avisynth.dll and tdeint are available. Tdeint's double height ELA modes (-2 and -1) get a pretty big speed increase over the 32-bit version but the other modes actually seem a tiny bit slower. I think that's because even though intel's x64 compiler allows inline assembly, it acts very cautiously around it (dumps all parameters passed in registers onto the stack, even if they're being put back into the same registers).

Motion.dll will have to wait - Clouded's fluent use of template functions seem to confuse the hell out of the compiler and I can't get it to play nice.

Edit: Ok, got motion.dll working. The problem was the compiler was inlining the template instantiations, then when another part of code tried to use them it couldn't find them and was too stubborn to create another instance. It's FAST - nearly 20% faster - but there's a bug somewhere so I'll have to fix it before releasing.

[Bluedan]

Great!!

[squid_80]

Ok, I've uploaded another new build of 64-bit avisynth.dll which includes reduceby2, horizontalreduceby2 and verticalreduceby2. Also available are 64-bit ports of masktools v1.5.8 (http://members.optusnet.com.au/squid_80/masktools64.zip) and motion.dll (http://members.optusnet.com.au/squid_80/motion64.zip) which should be everything needed for the motionprotectedfps script to work. I've tried it here and get ~10% speed increase above standard 32-bit. But everything new is fairly untested so if there's any problems please let me know. If no-one finds anything wrong with masktools or motion I'll add them to the main page at the end of the week.

[Wilbert]

@squid_80,
but there's a bug somewhere so I'll have to fix it before releasing.
Is that bug also present in the "32 bit" source? If so, did you correct that too?

[squid_80]

Is that bug also present in the "32 bit" source? If so, did you correct that too?No, it was a bug in my 64-bit translation. There were a couple of possible bugs in masktools that I corrected, but I can't be sure if they were real bugs or just a misunderstanding on my part. I will post my source code ASAP.

[Blue_MiSfit]

Dude, squid_80, thanks so much for all your hard work! Something worth running in 64 bit is always welcome!!!

~MiSfit

[squid_80]

But wait there's more: 64-bit TCPDeliver (http://members.optusnet.com.au/squid_80/TCPDeliver64.zip). If you get a message about versions not matching, here's a 32-bit build (http://members.optusnet.com.au/squid_80/TCPDeliver.zip) that should work with it. (Yes, of course it's possible to send from a 64-bit program to 32-bit and vice versa.)

[squid_80]

DeFreq for x64 (with 64-bit fftw3.dll): http://members.optusnet.com.au/squid_80/defreq64.zip

Approx 20% speedup.

[Bluedan]

How do I have to change this script (it's generated with megui) to make the TDEINT/EEDI thing work? This way x264 32bit is called, not the 64bit compile, though I have put the 64bit filters in the usual place... which indicates to me that everything in use is 32bit.

# Set DAR in encoder to 47 : 20. The following line is for automatic signalling
global MeGUI_darx = 47
global MeGUI_dary = 20
DGDecode_mpeg2source("F:\Casino Royale\cr.d2v")
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,edeint=edeintted)
crop( 0, 74, -2, -76)

Lanczos4Resize(720,432) # Lanczos4 (Sharp)
#denoise

[lariva]

First and foremost - thanks for all the work.

Do you have any plans to look at dgindex for 64-bit? The version that you currently have up is 1.4.6, which works great for everything other then DTS, 1088 (instead of 1080) width for .ts streams.

Sidebar: http://www.nvidia.com/object/tesla_gpu_processor.html

I'm curious if this could actually be a universal solution - the only problem i see is 128 parllel threads.




DeFreq for x64 (with 64-bit fftw3.dll): http://members.optusnet.com.au/squid_80/defreq64.zip

Approx 20% speedup.

[squid_80]

aWarpSharp (http://members.optusnet.com.au/squid_80/awarpsharp.zip) for x64.

[Ferux]

Hi, i'm trying to use Avisynth x64 (actually just for making x264 work as a 64-bit app), but it doesn't work. I putt the avisynth.dll in my I:/Windows/system32/ folder, double-clicked the registry-file and rebooted, but Virtualdub64 still can't open the most simple AVS-script (script with only 'avisource' and with the audio disabled). What do I do wrong? Or do I need ffdshow64?

[squid_80]

but Virtualdub64 still can't open the most simple AVS-scriptWhat does veedub64 say and what operating system are you using? Have you checked with windows explorer (not total commander or any other crap) that avisynth.dll is in windows\system32 and not windows\syswow64 by mistake?

[Ferux]

Veedub64 says:

VirtualDub Error

AVI Import Filter error: (Unknown) (80040154)


Avisynth.dll is in the right folder as you say.

My OS is Windows XP x64

[squid_80]

First install the vs2005 sp1 redistributable package to make sure that's not the issue: link (http://www.microsoft.com/downloads/details.aspx?FamilyID=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da&DisplayLang=en).

Make sure you're not double-clicking the .reg file from inside an archive manager program - extract it to somewhere first then double click from explorer. Same goes for avisynth.dll - don't extract directly to \windows\system32, extract to somewhere else then copy it into system32 (I know you've said it's there already, this is just for anyone else getting the same problem).
Please let me know how you get on.

[Ferux]

I tried to install the software in your link, but the installer seems to exit few seconds after I accept the agreement. I don't think this is normal...

I'm starting to think something is wrong with my system since ffdshow64 won't install either. It's weird because I formatted this PC last week.

[Ferux]

OK, I found the solution:


The problem is the ATI 'Catalyst' driver. I terminated ccc.exe (Catalyst Control Center I guess) with the Task Manager. When trying to open my AVS-script I got an AVS-error, so from this point, AVS64 was working. I installed ffdshow64 (apearantly ccc.exe was also the reason why this didn't install) and now everything is going fine.

Anyway, thanks squid_80 for your help (and the 64-bit apps :)).

[squid_80]

I hate that program. It crashes at random, requires a download of some ridiculous size (something like 30 megs last time I checked) and is so slooow at changing screens - especially unforgivable since it's written by a graphics manufacturer. Then again it uses .NET so I'm not that surprised.

It's going on my naughty programs list (right below windows messenger (http://forum.doom9.org/showthread.php?t=125960)).

[XBoy]

Where can I get the source for 64bit avisynth?

Mainly I need the avisynth.h file to port a plugin over to 64bit.

[squid_80]

http://avisynth2.cvs.sourceforge.net/avisynth2/avisynth/src/?pathrev=Avisynth64

Avisynth.h lives under \core.
I haven't been able to work on the main code for a long time.

[XBoy]

http://avisynth2.cvs.sourceforge.net/avisynth2/avisynth/src/?pathrev=Avisynth64

Avisynth.h lives under \core.
I haven't been able to work on the main code for a long time.


Any plans to port the MT plugin over to 64bit?

My AMD X2 3800+ can't keep up :(

[Prettz]

squid_80: Thanks so much for taking the time to compile all this stuff for us! I have no idea how long it takes you to recompile someone else's project, but I'm wondering if you plan to do the latest version of DGDecode (1.4.9), since the version on your site is 1.4.6? I'm only asking because I'd like to take advantage of the improvements in DGIndex 1.4.9 in the near future.

Also, for what it's worth, here's some filters that I always use. Not meaning to sound demanding, just putting these out there as suggestions for when you've got time to recompile more filters:
FluxSmooth
Unfilter
RemoveGrain (it's got an SSE3 implementation with a mode that's meant to replace Undot)
MSharpen

I really wish I could help you out with recompiling old stuff to 64-bit, but the best compiler I've got on my computer is the first version of VS .NET. It's probably of no use for making optimized 64-bit builds. :(

[IanB]

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

Ask Squid, it is anything but trivial to port inline assember into a form usable in the 64 bit environment. Inline assemblers greatest attraction is you can write all the use once frilly code in C++ then you get to do raw inner meat in assembler complete with still being able to reference all the C++ variables.

Remember MMX code is already 64bit and SSE2 is 128bit. Porting the frilly code to 64 bit effectivly gains you nothing. Note! I am not saying writing fresh in 64bit gains you nothing, hell for a start you get twice as many registers, I am just saying porting to 64 bit is a pain.

Blame Micro$oft they chose to remove the inline assembler feature from their 64bit compiler.

[squid_80]

Intel's compiler does support inline assembly, that's how I was able to do tdeint, masktools, clouded's motion.dll and awarpsharp in quick succession (although awarpsharp took extra work since it has no source code!). Unfortunately my version is old and won't integrate with VS2005 so I have to do everything from the command line.
After 2.6 gets released I planned to do a proper build of the core with all built-in functions included using ICC. I know it's not nice having code that can only be compiled by a certain (expensive) compiler but I consider that MS's fault, not mine.

[XBoy]

What about using custom build rules to integrate into VS2005 similar to how YASM integrates?

also, could you put mt_masktools and fft3dfilter on your list to do? :) (It's for my vista media center :) http://www.avsforum.com/avs-vb/showthread.php?t=719041)



BTW, you know when's 2.6 coming out?

[squid_80]

I don't really see the point having a 64-bit media center. (I don't see the point of 64-bit vista full-stop.)

[Leak]

I don't really see the point having a 64-bit media center. (I don't see the point of 64-bit vista full-stop.)
While I agree with you on the media center bit, the latter has a point as soon as you slap 4 or more GB of RAM into a machine.

Or did you mean that Windows XP 64bit still exists as an upgrade choice for Vista 64bit? :D

np: Autechre - IO (Quaristice)

[squid_80]

Or did you mean that Windows XP 64bit still exists as an upgrade choice for Vista 64bit? :D
That's what I meant - if you're going to use >4gb ram and want faster speed, it's stupid to use an OS that's a memory hog and runs slower than it's predecessor.

[XBoy]

That's what I meant - if you're going to use >4gb ram and want faster speed, it's stupid to use an OS that's a memory hog and runs slower than it's predecessor.

I got more than 4gb of ram :)

anyhow...


One question, does 32bit vista running on a 64bit processor allow 64bit data manipulation, or is it moot since optimized code would usually just use the MMX/SSEx (64/128bit) registers?

[squid_80]

It's mainly moot (ok that sounds odd) because SIMD (single instruction multiple data i.e MMX/SSE) code can already do 64/128 bits processing, but:
- 64-bit mode has 8 more SSE registers
- 64-bit mode has 8 more general purpose registers which can be helpful in SIMD loops which use many pointers/counters
- for x32 non-SIMD code, 64bit data manipulation is still possible (with C/C++ at least, using the __int64 type) but two 32-bit registers are used. Typically this means 2-3 times as many instructions as the same operation performed in 64-bit mode.
Also because the general purpose registers are larger it's possible to do tricks like horizontal adding via multiply that weren't possible before.

[Prettz]

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

Ask Squid, it is anything but trivial to port inline assember into a form usable in the 64 bit environment. Inline assemblers greatest attraction is you can write all the use once frilly code in C++ then you get to do raw inner meat in assembler complete with still being able to reference all the C++ variables.

Oh I know. I've looked at a lot of the avisynth code before (pre-SoftWire at least), and have a decent amount of experience doing inline assembler with VC++ 6.0.


Remember MMX code is already 64bit and SSE2 is 128bit. Porting the frilly code to 64 bit effectivly gains you nothing. Note! I am not saying writing fresh in 64bit gains you nothing, hell for a start you get twice as many registers, I am just saying porting to 64 bit is a pain.
But to use 64-bit you need all the .dlls used to be 64-bit, right? So since every script I've ever written uses FluxSmooth, I'm stuck with 32-bit everything right now.


Blame Micro$oft they chose to remove the inline assembler feature from their 64bit compiler.
Did they ever give an official explanation on why they did this?

[squid_80]

I will do fluxsmooth if you promise to give me feedback on whether it works properly or not.

Edit: FluxSmooth thread (http://forum.doom9.org/showthread.php?s=&threadid=38296) has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

[Prettz]

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

I just occurred to me to ask: are you sure about this? I had read long, long ago that Intel made their C++ compiler specifically to be compatible with VC++, and I assume their agreement continues to this day. Ignoring the practical question of "can you afford buying Intel's compiler?", isn't it technically still possible to compile C++ code with inline assembly (assuming you convert the assembly code to its 64-bit equivalent manually)? I assume squid doesn't have any version of Intel's compiler, but I'm asking this just generally.

The assembly won't take advantage of the added registers, sure, but it's a hell of a lot better than nothing; since the asm algorithms using MMX/SSE tend to already do things impossible through C/C++ code without using VC/ICL-specific mnemonics.

I will do fluxsmooth if you promise to give me feedback on whether it works properly or not.

Edit: FluxSmooth thread (http://forum.doom9.org/showthread.php?s=&threadid=38296) has version 1.1b available but I can only find source code for 1.1a. Anyone have it?
I only just got my Vista 64-bit box up and running and my first overclocking experience is going poorly. But I'll try.

[squid_80]

I just occurred to me to ask: are you sure about this? I had read long, long ago that Intel made their C++ compiler specifically to be compatible with VC++, and I assume their agreement continues to this day. Ignoring the practical question of "can you afford buying Intel's compiler?", isn't it technically still possible to compile C++ code with inline assembly (assuming you convert the assembly code to its 64-bit equivalent manually)? I assume squid doesn't have any version of Intel's compiler, but I'm asking this just generally.I think you missed my post from a bit higher up:Intel's compiler does support inline assembly, that's how I was able to do tdeint, masktools, clouded's motion.dll and awarpsharp in quick succession (although awarpsharp took extra work since it has no source code!). Unfortunately my version is old and won't integrate with VS2005 so I have to do everything from the command line.

[Rodger]

Just to let you know...

since there is no localization for WinXP 64bit it is a big pain for non-english version users to work with it.
A lot of directories are different and some software even denies installation on those "MUI"-Versions.

WinXP 32bit is a damn great OS, I know.
But WinXP64bit is no alternative to Vista64bit! And as much as I can tell....vista runs surprisingly round and smooth on my system.

[Klipper]

Edit: FluxSmooth thread (http://forum.doom9.org/showthread.php?s=&threadid=38296) has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

You can find it here -> http://bengal.missouri.edu/~kes25c/FluxSmooth-1.1b.zip w/ source

[Humbula]

squid_80: Thanks so much for taking the time to compile all this stuff for us!

Where can I find the new 64 bit version? And is it v2.5.7?

[XBoy]

Is there a new version of avisynth for x64 yet?

[XBoy]

I'm trying to compile the version here: http://avisynth2.cvs.sourceforge.net...rev=Avisynth64

but I'm running into some missing links:

avisynth.obj : error LNK2001: unresolved external symbol "struct AVSFunction * Levels_filters" (?Levels_filters@@3PAUAVSFunction@@A)

Where are these?

Also, where's the directshow dll portion?

[Humbula]

Is there a new version of avisynth for x64 yet?

See my post. Prezz said squid_80 compiled a "new" one...

[bestsoft666]

There was a workaround too to force the optimizations anyway and then AMD performed very well indeed.

[Rodger]

So is there a 64bit build/realease to download and test?

[squid_80]

http://www.members.optusnet.com.au/squid_80
Unless someone else has done their own work, that's as recent as it gets.

[Rodger]

How do I "replace" the 32bit version with the files included in ZIP-file.

Is there a how to?

[BiOSsCZ]

Please help :

http://img231.imageshack.us/img231/3525/vd64de3.png

[Adub]

Did you even read your own error message? It is pretty self explanatory.

[squid_80]

The 64-bit version of DGDecode is based on 1.4.8 (or possibly 1.4.6). You have to use that version of DGIndex to create the .d2v.

[BiOSsCZ]

The 64-bit version of DGDecode is based on 1.4.8 (or possibly 1.4.6). You have to use that version of DGIndex to create the .d2v.

I have version 1.4.6.0
Where this version find? Thank you. (1.4.8)

[squid_80]

Actually it is based on 1.4.6. The .d2v file should start with "DGIndexProjectFile13".

[BiOSsCZ]

Actually it is based on 1.4.6. The .d2v file should start with "DGIndexProjectFile13".

I am not from USA, too I don't understand..
Please send last version DGDecode64.dll

THX

[squid_80]

http://members.optusnet.com.au/squid_80/DGDecode64.zip

[kemuri-_9]

since x264 does not currently have feasibly usable x64 windows version,
for those using x64 avisynth, it would be necessary to pipe to x86 x264 using an avs2yuv x64 version which i have built:
avs2yuv_x64.exe (http://kemuri9.net/dev/avs2yuv/avs2yuv_x64.exe)