Avisynth With VC-2008

[videophool]

Forgive me if this question has been asked before, but has avisynth been ported to VC-2008? I am really not excited about writing new plugins using VC-98. Thanks, Phool

[Guest]

Forgive me if this question has been asked before, but has avisynth been ported to VC-2008? I am really not excited about writing new plugins using VC-98. Thanks, Phool You can certainly make plugins with VC-2008, but what does that have to do with building Avisynth itself?

[videophool]

OK, the problem is bigger than plugin development. I prefer not to use a 10-year old dev environment, and am not sure where to find a 7+ year old MSDN, and work with a crappy debugger. I was hoping that somebody had moved this project forward a few years.

[Guest]

If you search you will find discussions about that and you'll see the technical reasons for things.

[Wilbert]

Forgive me if this question has been asked before, but has avisynth been ported to VC-2008?
AviSynth v2.6 can be compiled by VC-2005. Dunno about VC-2008.

[videophool]

A few years ago, I started to port, and got stuck with the asm part. I think the rest of the code would move easily, would it not? No doubt porting would be a challenge, but it is doable, and AviSynth is being used by too many people to be stuck in the 20th century.

[videophool]

AviSynth v2.6 can be compiled by VC-2005. Dunno about VC-2008.


if it can compile with 2005, it can compile w/2008. I will look into it. Thanks. Phool

[videophool]

is it usable?

[Guest]

She's dead, Jim.

[osgZach]

It was such a shame, but not surprising. A pretty big project to undertake.

I was thinking about it yesterday.. As I know Avisynth relies on VFW (I think?), I wonder if it were possible to port something like that to and Avisynth to .NET/MONO ?

That's the only realistic way I could see it happening, but I'm guessing that'd be more difficult than rewriting Avisynth alone to use a different "backend" (like they seemed to be doing) or whatever you call VFW type things...

Ah well

[videophool]

She's dead, Jim.

Is there any alternative to avisynth? I know that Avisynth is powerful, but relying on SW that is bound to 10-year old compiler is not a way to start building a new project.

[Wilbert]

That's the only realistic way I could see it happening, but I'm guessing that'd be more difficult than rewriting Avisynth alone to use a different "backend" (like they seemed to be doing) or whatever you call VFW type things...
It seems to me that the easiest is to use ffmpegsource as "backend" (or gstreamersource which was working once under avs3).

[osgZach]

Have to admit I am unfamiliar with ffmpegsource, or pros/cons vs FFdshow/VFW. have never really used it.

I am aware of Gstreamer, although some more knowledgeable people have expressed less than impressed opinions.. But if ffmpegsource works on Win32/Linux then yes that would be a sensible solution as well.

I think there are a lot of opportunities with .NET/MONO compatability for the future. Sure there are some caveats, but surely easier than rewriting the whole thing cross-platform from scratch?

[JoshyD]

I'm positive Avisynth compiles with VC2008's compiler. I've compiled and used my own builds with MSVS2008's compiler and with ICC 11. There's two idiosyncrasies with the straight up 2.58 source, for loop conformance, and if building with the Win7SDK the GUID's for KSDATAFORMAT_SUBTYPE_PCM and KSDATAFORMAT_SUBTYPE_IEEE_FLOAT are already defined, so the compiler complains when they're defined in main.cpp.

As for 2.6. for loop conformance is maintained, but the GUID thing still comes up. Comment out the lines and you get a working binary. You can compile and use 2.6 with VS2008, the Win7SDK, and ICC11.

VS2008 will still compile the inline asm as long as it's a 32bit dll you're after, otherwise, ICC11 will compile the inline asm 64bit, or have fun writing your own asm. (I have a 64bit port of Avisynth 2.58 hacked with my support here. (http://forum.doom9.org/showthread.php?t=152800))

Anyhow, the code isn't tied to old compilers, at least in my experience.

[TheFluff]

Have to admit I am unfamiliar with ffmpegsource, or pros/cons vs FFdshow/VFW. have never really used it.
pros:
- no funny VFW restrictions
- no reliance on windows-only API's, compiles and works fine on most unix systems
- support for most common formats out of the box, no systemwide codec installation required
- very simple API
- frame- and sample-accurate seeking (bugs aside)

cons:
- bad support for formats ffmpeg has bad support for (mostly mpeg ts/ps and ogg)
- requires indexing files before opening
- cannot easily be extended with support for arbitrary odd proprietary codecs the way dshow can
- no support for arbitrary funky filter chains ala dshow (and gstreamer)
- bugs