Compiling AviSynth

[Fizick]

official Avisynth 2.5.7 compiler environment is VC6.
Other is not officially supported.
But some people can compile it with vc7 - vc8 (?)
For other compiler you must recompile some libraries (soundtouch etc).
It is partial mess, but it is so. This world is not perfect. :)
Try re-read whole this thread.
Migration to more new compiler of next version 2.6 is currently considered and discussed.
http://forum.doom9.org/showthread.php?t=112138

Final question: WHY you want compiler avisynth? :)

[foxyshadis]

The only reason I have a debug avisynth.dll sitting around is it makes it a lot easier to debug memory leaks in plugins (caused by using the API wrong, not just forgetting a delete/free) and places where the crash occurs when the plugin calls avisynth with bad input.

You have to put "LIBC" in the "ignored specific library" in linker input, otherwise that happens. libc.lib won't work. I guess you already got all the compiler errors worked around.

[Jocko Homo]

Final question: WHY you want compiler avisynth? :)Good question. I want to try something really crazy... I'm a little afraid to announce it prematurely but I suppose there's little harm...

I want to change the Avisynth language syntax. I want to change it in a very big way. In fact, I'm planning on embedding Ruby (http://www.ruby-lang.org/en/) into Avisynth as the language implementation.

Pretty crazy, eh?

[Jocko Homo]

The only reason I have a debug avisynth.dll sitting around is it makes it a lot easier to debug memory leaks in plugins (caused by using the API wrong, not just forgetting a delete/free) and places where the crash occurs when the plugin calls avisynth with bad input.

You have to put "LIBC" in the "ignored specific library" in linker input, otherwise that happens. libc.lib won't work. I guess you already got all the compiler errors worked around.That's what I was talking about when I said weird things are happening. I did put libc.lib in the "ignore specific library" linker option and the linker chose to ignore me and link against it anyway! What the hell is that? Talk about a compiler bug...

[Fizick]

Note.
Recently some files on CVS tree were changed from being binary type to normal text type:

avisynth.dsw, avisynth.dsp, pfc.dsp

It is not a problem for fresh CVS update to new empty local folder.

But if you update to existing local folders with cvs (hidden) subfolder, these files will be updated as (now wrong) binary type, you will get unix LF instead of CRLF lines ends.
Bad news: MS Visual Studio do not understand files with LF.

Reason: Text files are always stored as unix type (with LF) at CVS server and automatically converted from and to windows type (CRLF) by TortoiseCVS (CVSNT).
Binary files are not converted.

Workaround 1. Edit and change your file locally from LF to CRLF with some text editor Ultraedit, Akelpad, etc. But it is temporary solution.

Workaround 2 (Better):
1. Go to your hidden CVS subfolder and edit "Entries" file,
delete "-kb" from the line (or remove this line completely):
/avisynth.dsw/1.6/Sat Sep 8 20:32:55 2007/-kb/
2. Delete your local avisynth.dsw
Same for other files (avisynth.dsp, pfc.dsp)
3. Update from CVS server.
New file will have correct type.

[kemuri-_9]

I've been using AVS for a good bit of time and wanted to see what was coming up in to-be-released official versions so i started about compiling it on my machine.

I've successfully done the current CVSs of the 2.5 and 2.6 branches in MSVC9 (.NET 2008), but am having some problems with 3.0 since the boost library doesn't seem to work with MSVC9.
Is there any workaround for this, because i don't want to have to get MSVC8 for AVS 3.0 when i have previous versions working in MSVC9.

I just built 2.6 and am going to start experimenting, but have been using 2.5.8 without any problems.

Any help would be appreciated.

[Ajax_Undone]

There is a new version of boost 1.35.0 I have beee successful in compiling both boost and AVIsynth give em a try...

[tacman1123]

@ajax -- were you able to compile all of Avisynth under boost? What version of avisynth did you use, and can you share any details about the process? Were you also able to compile plugins? Actually, I'm more interested in the plugins than the main avisynth program itself, and while there's lots of information about creating plugins, I'm still not sure what tool/tools I'd need to create one for 2.57 or 2.58.

[Gavino]

while there's lots of information about creating plugins, I'm still not sure what tool/tools I'd need to create one for 2.57 or 2.58.
Hola, tac. See here (http://avisynth.org/mediawiki/Filter_SDK/SDK_necessaries).

I have been successfully using the (free) Visual C++ Toolkit 2003.

[kemuri-_9]

I just got a fresh cvs of avs 2.6 and i had to modify the vc8 projects and a bit of code to get it to be able to even build

things i can remember doing are
aften_static
Source Files > x86_cpu_caps_detect.nasm
Custom Build Step
Command Line > Remove directory from nasm(w).exe
- (should be in the vc++ bin directories, so shouldn't need the directory for it)

Source Files > x86_cpu_caps.c
"asm_support.h" non existent, use #undef HAVE_CPU_CAPS_DETECTION
before #ifdef

libmp3lame
Source Files > Asm
all files > discrepency in 'nasm.exe' vs other projects using 'nasmw.exe'
commands switched to
nasm -f win32 -I i386\ -DWIN32 "$(InputPath)" -o $(OutDir)\$(InputName).obj
to build properly

C/C++ > General
Additional Include Directories > add > .

SoundOut
Source Files > convertaudio.cpp
add #include <limits.h>
change MIN_INT to INT_MIN
change MAX_INT to INT_MAX

vorbis_static
C/C++ > General
Additional Include Directories > add > ..\..\..\h & ..\..\..\..\h
(some items are in deeper than the others)

vorbisenc_static
C/C++ > General
Additional Include Directories > add > ..\..\..\h

so if this could be taken care of in any way, would be appreciated.

[bigboss97]

I followed the intruction in wiki and googled through all my problems. Now I'm stuck in:
TCPDeliver
LINK : fatal error LNK1104: cannot open file 'nafxcwd.lib'

I can only find the file under 64bit directory of my SDK. Is this something from MFC?
I read that MFC is not in the SDK. I can compile avisynth 2.57 with 2005 Express?


Here is another problem in the project:
avisynth
Project : error PRJ0019: A tool returned an error code from "Assembling c:\work\CPP\avisynth_257\src\convert\convert_a.asm..."


Thanks
Phuoc

[Fizick]

for second, you need in Masm (download masm8 from microsoft).

[xxthink]

I download the latest avisynth2.6 from cvs. When I build it by vs 2005 express, the DirectShowSource project can't be built.
This is the error message.
http://pastebin.com/J5PZuBps

Would someone like to help me?

Thanks in advance.

[Jeremy Duncan]

Try my src and visual studio 2010. It compiles directshowsource. link (http://forum.doom9.org/showthread.php?t=160230)

[ryrynz]

Are there any performance improvements to be had if 2.58MT was compiled for a Sandy Bridge CPU?

[Groucho2004]

Are there any performance improvements to be had if 2.58MT was compiled for a Sandy Bridge CPU?

I did some tests with different compilers (VC6, VC7.1, VC8, Intel 10.1 with IPO and PGO) some time ago but none of them nor any of their optimization options yielded any improvements worth mentioning (tested on C2D and Sandy Bridge).

[IanB]

Most of the performance critical code in Avisynth is hand coded assembler, so no compiler will make any difference to that code.

There are a small number of inbuilt filters that only have a C++ code path, these might benefit slightly from a cleverer code generator, but as they haven't warranted assembler attention they are probably not performance critical.

[Groucho2004]

Most of the performance critical code in Avisynth is hand coded assembler, so no compiler will make any difference to that code.

There are a small number of inbuilt filters that only have a C++ code path, these might benefit slightly from a cleverer code generator, but as they haven't warranted assembler attention they are probably not performance critical.

Here's an example where the c++ code "slightly" benefits by using the Intel compiler:

Script:
LoadPlugin("DGDecodeNV.dll")
DGSource("test.dgi") //720p testclip
Sharpen(0.2, MMX = true)
VC 7.1 compiler: 168 fps
Intel 10.1 compiler: 170 fps

Script:
LoadPlugin("DGDecodeNV.dll")
DGSource("test.dgi") //720p testclip
Sharpen(0.2, MMX = false)
VC 7.1 compiler: 92 fps
Intel 10.1 compiler: 165 fps (!)

[IanB]

I am impressed the compiler was able to get within spitting distance of the MMX code, but I also suspect foul play and someone turned on the loop threading, not a fair comparison.

Given the Intel compiler is $2000+ I cannot get very interested in it seeing I already give my time for free, which I am very happy to do. I am just not prepare to spend big money on that hobby when that money does not directly make the hobby a lot more fun.



As an aside, I am getting a lot tired of people quoting reciprocal speed as a useful comparative measure. I know it is rife on this and other forums. The right measure is time.

168 fps is 5.95 milliseconds reference
170 fps is 5.88 milliseconds 1.1% faster
92 fps is 10.87 milliseconds 182% of reference
165 fps is 6.06 milliseconds 1.8% slower

[Groucho2004]

Given the Intel compiler is $2000+ I cannot get very interested in it seeing I already give my time for free, which I am very happy to do. I am just not prepare to spend big money on that hobby when that money does not directly make the hobby a lot more fun.

You already made your point in a previous post that there are just a few un-optimized functions which are rarely used. I just tried to demonstrate what's possible with a modern compiler. Also, these kind of improvements are very rare from my experience, it's usually just a few percent. So, all the work you did with MMX and SSE optimizations is not in vain and certainly appreciated.

As an aside, I am getting a lot tired of people quoting reciprocal speed as a useful comparative measure. I know it is rife on this and other forums. The right measure is time.
That reminds me of shops here in Spain where they displayed their prices in Euro and Pesetas years after the introduction of the Euro because people had a hard time doing the "conversion" (there are still shops which do that :D).
It's hard to break a habit.

[SEt]

Intel and GCC compilers quite often like to bloat the code. Combine it with hand-written assembler for actually time-critical stuff and you can get even few % slowdown due to less efficient L1C usage. (Unless you do PGO, but how many people use that?)

[IanB]

As I have always said, ask the compilers for an assembly listing when doing C wrapped __ASM. Make sure the wrapping C code is playing nice with your nice shiny asm. More often then desirable the compiler is a smart arse and spits out wrapping code that can be detrimental to overall performance.