64 bit avisynth?

[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