New ffdshow build (?)

[ExtraEye]

how do i dowload this new release bob0r?

[bob0r]

how do i dowload this new release bob0r?

I said i put a build online after those 2 fixes are updated on ffdshow CVS also.

BUT. libmpeg2_ff.dll fails to compile with gcc (3.4.4).


./../../simd_instructions.h: At global scope:
./../../simd_instructions.h:53: error: expected `,' or `...' before '&' token
./../../simd_instructions.h:53: error: ISO C++ forbids declaration of `__int64' with no type
./../../simd_instructions.h: In function `void csimd::psadbw(int)':
./../../simd_instructions.h:53: error: `dst' undeclared (first use this function)
./../../simd_instructions.h:53: error: `src' undeclared (first use this function)
In file included from include/mmx.h:30,
from libmpeg2/idct_mmx.c:36:
./../../csimd.h: At global scope:
./../../csimd.h:30: error: expected `,' or `...' before '&' token
./../../csimd.h:30: error: ISO C++ forbids declaration of `__int64' with no type
./../../csimd.h: In function `void csimd::movq(int)':
./../../csimd.h:30: error: `dst' undeclared (first use this function)
./../../csimd.h:30: error: `src' undeclared (first use this function)
make[1]: *** [libmpeg2/idct_mmx.o] Error 1
make[1]: Leaving directory `/home/user/ffdshow_gcc/src/codecs/libmpeg2'
make: *** [../bin/libmpeg2_ff.dll] Error 2



Reported:
http://sourceforge.net/tracker/index.php?func=detail&aid=1360477&group_id=53761&atid=471489

We will have to wait until this is fixed again.

BTW, i am using gcc 3.4.4 again, it is the fastest for both ffdshow and x264 builds.

[ExtraEye]

will you make an sse2 version too?
thx anyway

[cc979]

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

i see what you mean now, i just made a test xvid with 16/9 AR but its not displayed right with mpc it thinks its a 4/3 AR but its works fine with VLC so not sure if its a ffdshow or mpc bug

[videomixer9]

hm, imo wmv9 (4cc wmv3) should be enabled again as an codec option in ffdshow, as it works just fine if you enable it via the registry trick. Didn't have one wmv video that didn't work yet, except that it's not that good with broken files, but the original isn't really either. Anyone tried this too and had similar success?

btw. I had one xvid encode that had the same error ... hm ... also played as 4:3 without me enforcing that or anything ... but nothing to do with anamorphic encoding but something else and not fixed by overlay mixer thingy whatever heh ...

[_xxl]

Libavcodec.dll can be compiled with Microsoft Visual Studio 6 + Intel compiler 9?

[celtic_druid]

That's how I usually compiled it.

[celtic_druid]

Should be "-mtune=i686"

[lrms]

gcc vp3dsp_sse2
cc1.exe: invalid option `tune=i686'
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions -DHAVE_AV_CONFIG_H -pipe -mno-cygwin -mdll -I. -I.. -I../codecs -I../imgFilters $(InputPath) -o $(IntDir)\$(InputName).obj -Ilibavutil
I'm using GCC 3.2.3.

"-mtune" is for GCC 3.4 and up. For version 3.2 you should use "-mcpu="

[bob0r]

Download from x264.nl

Compiled up to:
15:01 on Nov 18, 2005
option to connect to any filter but allow output format changes only on supported ones - a new default
http://cia.navi.cx/stats/project/ffdshow/.message/6454339

I can switch between gcc 4.0.2 and 3.4.4 instantly now, so until ffdshow can compile on gcc 3.4.4, i can still give you new builds :sly:

SSE2 build for the girls:
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051120-gcc4.0.2-sse2-x264.nl.exe

Enjoy!

[celtic_druid]

The project file is probably still missing some source files.

[issa]

gcc vp3dsp_sse2
cc1.exe: invalid option `tune=i686'
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions -DHAVE_AV_CONFIG_H -pipe -mno-cygwin -mdll -I. -I.. -I../codecs -I../imgFilters $(InputPath) -o $(IntDir)\$(InputName).obj -Ilibavutil
I'm using GCC 3.2.3.

Your GCC is too old, the GCC 3.4.x replace "-mcpu" with "-mtune".
You either upgrade you gcc, or replace "-mtune" with "-mcpu" in the
Makefile, makefile.inc and makefile_c.inc under the "src" directory.

[Valeron]

The 1120 build makes ffdshow first time over nero avc decoder in AVC decoding. Well done! x264 guys :cool:

[breez]

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

[bob0r]

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

Do some tests, more clips, then post your findings to Milan

http://sourceforge.net/projects/ffdshow
Bugs > http://sourceforge.net/tracker/?group_id=53761&atid=471489

Give him all info you can, CPU, build used, what video/audio you used etc etc...


Or/and wait for other to test it first and compare findings!

[LigH]

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

[PatchWorKs]

There's a really interesting discussion @ Hydrogenaudio.org around SSE/SSE2 optimization on the Ogg Vorbis optimized for speed (http://www.hydrogenaudio.org/forums/index.php?showtopic=29161) 3ad.

Here's some interesting posts (in my opinion):
What the ICC compiler does is a process called autovectorisation, it's a very clever piece of software that examines routines and attempts to implement them using the faster SSE(2) instructions. At least, that is how i understand it.

What lancer does is replace certain standard routines in vorbis with hand written SSE implementations. This is not assembly (i think), but it is vectorisation (making use of SSE) done by a human.

The SSE instruction set works at a lower precision than the regular x87 instructions, but i don't think that's ever reduced sound quality in a noticeable way.

I'm not an expert on this, but i hope this explanation is accurate enough to answer your questions.


To explain:

3DNow, SSE, SSE2 are alternate instruction sets for floating point processing. These instruction sets have some major advantages over the old x87 mode:

1) They have register based access, instead of stack based
2) They have the *possibility* to operate on 2 or 4 values at the same time (vectorisation)

SSE and 3DNow have 32 bit accuracy, SSE2 has 64 bit accuracy. x87 has 32 or 64 bit accuracy and a possibility (that shouldn't be used and I'm pretty sure vorbis doesn't use it!) to do 80 bit accuracy arithmetic.

Using these instruction sets can be done in the following manner: code for them manually (in assembler or with instrinsics), use a compiler that can use the SSE(2) instructions for floating point instead of x87, or use a compiler than can *vectorize* computations for SSE/SSE2.

Currently (besides manually writing in assembly), ICC is the best at vectorization, and some very recent GCC's have the possibility too. MSVC2005 and older GCC's have the possibility to generate SSE(2) floating point instructions (without vectorisation).


Here's the Ogg Vorbis acceleration project (http://homepage3.nifty.com/blacksword/index_e.htm) website, and its author email: blacksword8192 (at) ｈｏｔｍａｉｌ (dot) ｃｏｍ

[Egh]

Hm... At the first glance h264 is decoded somewhat faster than before in new build. Great to know :)

[videomixer9]

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

It's major crap anyways, ffdshows postprocessing which comes from mplayer mostly is total crap. It does not improve quality at all, all it does is lose major details on the video, even the accurate deblocker does a real bad job.

here an example of a 600kbps video:

first without any filter or postprocessing (click for full size):
http://xs55.xs.to/pics/05460/without_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=without_spp.jpg)
here with fast SPP:
http://xs55.xs.to/pics/05460/with_fast_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_fast_spp.jpg)
with regular SPP:
http://xs55.xs.to/pics/05460/with_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_spp.jpg)
with regular accurate deblocking still better:
http://xs55.xs.to/pics/05460/with_accurate_pp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_accurate_pp.jpg)

in the same order as above in one png:
http://xs55.xs.to/pics/05460/together.png.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=together.png)

Result = SPP wastes much CPU and totally wrecks the picture! in actually video SPP even produces this flickering effect with many videos. postprocessing is wasted cpu time! That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.

[Egh]

It's major crap anyways, ffdshows postprocessing which comes from mplayer mostly is total crap. It does not improve quality at all, all it does is lose major details on the video, even the accurate deblocker does a real bad job.

Result = SPP wastes much CPU and totally wrecks the picture! in actually video SPP even produces this flickering effect with many videos. postprocessing is wasted cpu time! That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.

I was never fan of SPP at all. It ruins details of the picture by smoothing the frequency domain. Something like FFT3DFilter works far better (and slower). In fact FFT3DFilter implemented on GPU should have best quality post-processing. [and still reasonable speed to be used real-time]

But, of course, the best thing is to have video which DOESN'T require post-processing at all :) And any deblocking, whenever casual or h264 one, is totally redundant nowadays. It was good on something like 512*384 videos encoded in single-pass DIV3 :P Which were somewhat a norm several years ago. Now 720*480 avc is just a norm and loses competition with hdtv videos. On something like 1024*576 with sufficient bitrate any deblocking is totaly redundant and eats far too much CPU.

Anyway, thanks for testing :)

[Leak]

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.
Fast SPP deblocking only supports levels 4 and 5; I guess it's a lot faster than using those with regular SPP... :)

Here's the beef (http://thread.gmane.org/gmane.comp.video.mplayer.devel/25213)

np: Bring Back The Buffalo - Checkerboards (Bring Back The Buffalo)

[bob0r]

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

I tried
make SSE=no
make SSE=no SSE2=no
make SSE1=no

Tell me how to disable SSE2 AND SSE and ill build you one :)

[dragongodz]

That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.
if you dont care then why are you spouting off about it ? i can easily show you a bad/blocky/low bitrate encode where SPP clearly makes the picture more watchable and easily better than the other deblockers included. what it comes down to though is if you dont like it then dont use it. its not as if someone is making you turn on filters and forcing you to watch the output.

But, of course, the best thing is to have video which DOESN'T require post-processing at all And any deblocking, whenever casual or h264 one, is totally redundant nowadays.
redundant ? depends on what you are trying to encode and how. of course having enough bitrate that no deblocking is needed will always be the (dare i say it)best. however if you are targeting an encode with something like a size limitation then that is not always possible.

[movax]

I tried
make SSE=no
make SSE=no SSE2=no
make SSE1=no

Tell me how to disable SSE2 AND SSE and ill build you one :)

You have to change the CPU flags in the makefile. Note that the CVS is supposed to have proper CPU capabilities detection.

[ExtraEye]

bob0r - i just noticed in your latest build - no awarpsharp?

[lrms]

http://sourceforge.net/tracker/index.php?func=detail&aid=1362149&group_id=53761&atid=471489

http://cia.navi.cx/stats/project/ffdshow/.message/4561c

Time for YAFB (yet another ffdshow build)? ;)

[issa]

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

Here is the cvs build with sse turn off when compiling.
URL: http://rapidshare.de/files/7977898/ffdshow-20051121.exe.html

[QQ]

1120 crashes for me as soon as i touch gain/offset in picture properties (sorry, don't remember exact name).

w2k3, p4 htt enabled

not sure what else should be given :/

[bob0r]

New URL for my and other ffdshow builds.

Mirrored (and renamed to *-username):
http://files.x264.nl/ffdshow/ffdshow-20051121-issa.exe
http://files.x264.nl/ffdshow/ffdshow-20051121-drevil_xxl.exe

[Kurosu]

bob0r - i just noticed in your latest build - no awarpsharp?
awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.

Here is the cvs build with sse turn off when compiling.
I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

[issa]

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.


I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

I would like to know where is "milan's code" located. Also, where to get all the PSDK header files, for example, uuid.h, dvdmedia.h, etc, for gcc.

I think the "intrinsics" is fine as long as the program check the CPU flags before it use, just like libavcode did. However, the "-mfpmath=sse" or "-arch:SSE" tell the compiler to use SSE instruction instead of x87 instruction for FP operation, and this will crash on CPU that do not support SSE.

[cc979]

anybody got problems anamorphic xvid avi's not working with system-overlay but they work with vmr9 renderless

[Egh]

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.





As for awarpsharp, i dont' see any troubles there. Anybody who have avisynth installed may simply use aWarpSharp() filter thru it (typing it into "Avisynth" window of ffdshow). As for speed, since I just learnt it's closed source, so i don't think there's any difference between those two filters (built-in in ffdshow or using avisynth one).

Are there any other closed source parts of code in ffdshow? I actualy thought it was fully open source, but it prooved to be wrong.... :P

[Kurosu]

I would like to know where is "milan's code" located
You are probably not referring to CVS so I guess you wonder which code could be troublesome. I meant it like "code which is troublesome for a gcc build for K6/P2 users". So this code would be:
- any code using SSE or simply MMXExt
- some C code doing float/double operations

milan's code is mostly based on intrinsics. SSE ones requires -msse, but then this not only activates support for intrinsics but also builtins. They can partially be disabled/controlled with -mfpmath=387. However the later kind of code gets compiled when using -msse with SSE builtins.

My referring to Athlon-XP was due to the fact that with -march=athlon-xp -mfpmath=387 -msse -msse2, gcc used sse2 instructions for some double<->int operations, which is basically the same with K6/P2 where it is SSE1 and float<->int

Also, where to get all the PSDK header files, for example, uuid.h, dvdmedia.h, etc, for gcc.
I'm not sure what's get used. baseclasses uses stuff coming from DirectX. I have both DX8.1 SDK installed and the headers used for compiling mplayer (http://www.mplayerhq.hu/DOCS/HTML/en/windows.html):

I think the "intrinsics" is fine as long as the program check the CPU flags before it use, just like libavcode did
Yes, though gcc compiles C code with -msse without you having a say on where it uses builtins. Such granularity:
0) Use no SSE builtins
1) Handle builtins when intrinsics are used
2) Use SSE math builtins
3) Use any SSE built-ins
would be could, while we only have 0) and 3). 1) is what is needed for ffdshow.

However, the "-mfpmath=sse" or "-arch:SSE" tell the compiler to use SSE instruction instead of x87 instruction for FP operation, and this will crash on CPU that do not support SSE.
Yes. I guess -arch:SSE is cl-specific?

i don't think there's any difference between those two filters (built-in in ffdshow or using avisynth one).
Except for a little bit of speed, as the use of awarsharp has to go all the way through the avisynth layer. I don't know what kind of speed/memory impact it has.

Are there any other closed source parts of code in ffdshow? I actualy thought it was fully open source, but it prooved to be wrong.... :P
All is open source (as in "source available"), but the reuse of this code isn't that clear. In fact, many parts are not GPL free software:
1.0) baseclasses
"Copyright (c) 1992-2002 Microsoft Corporation. All rights reserved."
Basically, a part of DirectX SDK. Code is really available, but I'm not sure it can be included in a GPL program. Granted, it's easier for everybody to compile it this way.
1.5) wmv9 stuff
Part of it is "Copyright (c) 1992-2001 Microsoft Corporation. All rights reserved". Probably same level of concern as 1.0
2) realaac
I don't want to read up the RPSL (http://www.helixcommunity.org/content/rpsl) and RCSL (http://www.helixcommunity.org/content/rcsl) licences but there may be some unregular stuff with it being included in ffdshow
3) Skal's MPEG-4 encoder: LICENSE.TXT license is missing, probably GPL though
4) awarsharp: closed source. Author explicitely states in the header it can only be used with ffdshow
5) FAAD2. License is GPL+some additionnal requirements, which makes it open source but not GPL-compatible. (http://www.hydrogenaudio.org/forums/index.php?s=showtopic=35535&st=25#)
6) Unrar: not sure. The available license makes me think it isn't, while this page (http://www.unrarlib.org/license.html) seems to say it's ok (though I'm not sure this is the same thing actually).
and maybe more FUDesque stuff.

Not really showstoppers, though. It's up to Milan Cutka to see what to do with them but most people will agree he has better things to do.

[DeathTheSheep]

New URL for my and other ffdshow builds.

Mirrored (and renamed to *-username):
http://files.x264.nl/ffdshow/ffdshow-20051121-issa.exe
http://files.x264.nl/ffdshow/ffdshow-20051121-drevil_xxl.exe

Hmm...the issa.exe doesn't properly register ffdshow.ax. The installer prompts me with the "can't register..." error, and then simply exits.

drevil.exe "works" but avisynth doesn't recognize the video stream and H.264 deblocking is disabled by default (!! what good is inloop now?!)!

Still, thanks for the builds! :thanks:

[bob0r]

@DeathTheSheep

Try putting http://files.x264.nl/ffdshow/msvcr80.dll in your c:\windows\system\ dir and try issa's build again.

[_xxl]

http://rapidshare.de/files/8069150/ffdshow-20051121.zip.html
ffdshow-20051121 is for testing!

[bob0r]

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

I finally managed to compile ffdshow with gcc 3.4.4, but on my system it crashes.

Please test this build and let me know if it crashes or not, this could help if Milan can't see the problem right away. Thanks.


http://rapidshare.de/files/8069150/ffdshow-20051121.zip.html
ffdshow-20051121 is for testing!
What's different from your other ffdshow-20051121.exe ?

[thuan]

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe
Crash here too (CPU T-bred 1.5Ghz and crash in ffdshow.ax). Replace ffdshow.ax with the one in your 1120 compile run fine and maybe faster.

[_xxl]

drevil.exe "works" but avisynth doesn't recognize the video stream and H.264 deblocking is disabled by default (!! what good is inloop now?!)!
Still, thanks for the builds! :thanks:
ffdshow-20051121 H.264 deblocking is enabled by default.
fixed reg errors on install.

[madman1980]

Why is there such a hassle with ffdshow and cpu instruction sets compared to other codecs? Why can't it just work with them all and detect accordingly?

[breez]

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

Crashes here too (ffdshow.ax). Athlon XP (Thoroughbred-b).

[bob0r]

We can stop testing ffdshow gcc 3.4.4 builds. Milan is quite clear on this:


I'm happy you managed to compile ffdshow using GCC 3.4.4,
but I don't think I'll check reports about bugs in this
build. GCC 3.4.4 simply isn't supposed to be used for
building ffdshow.

Just today I tested a mpeg 1 file created by tmpgenc
(finally ffdshow is able to deliver video to tmpgenc, audio
will hopefully follow), but the image was distorted. The
problem was in ff_libmpeg2 compiled by GCC 3.4.4. When
compiled using GCC 4.0.2 or MSVC, the results were fine.
Maybe it'd be possible to make ffdshow work when compiled
using GCC 3.4.4 (compiler switches,...) but it'd take too
much time and I think there are other areas of ffdshow where
it should be spent.

Clarity is what i like, so move on with gcc 4.0.2 :cool:

[bob0r]

Why is there such a hassle with ffdshow and cpu instruction sets compared to other codecs? Why can't it just work with them all and detect accordingly?

Quotes from Milan:

My "daily" builds should work on all CPUs which
support MMX
instructions set and don't require SSE. That's because
I'm
still using Intel C++ compiler to build them. bob0r uses GCC
which has its own limitations which would require many
changes in ffdshow source code to make it able to create
ffdshow which wouldn't require SSE support.

me:
I hope one day you can realize the same for gcc as is
possible on icl

So there is no way to disable SSE (only SSE2), ok.

Milan:

I know about two possible ways of making GCC builds support
MMX-only CPUs:

1. moving all SSE and MMXEXT functions in ffdshow.ax sources
to separate source files
2. outcommenting all SSE and MMXEXT code as I did it for
SSE2

First approach would make ffdshow source tree a mess (or at
least much less maitainable). Second approach would require
a bunch of #ifdef and #endif preprocessor stataments which
would also make source code less readable.

Personally I'd prefer second approach. However, this would

result in ffdshow.ax using MMX instruction only even on
Durons which support MMXEXT instructions (average, min, max
).


So to answer your question, for GCC this requires quite a lot of work, and will make ffdshow source messy.

Just get Milan's ICL 8 builds if you have problems with SSE/SSE2 and possible other CPU optimizes:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

But again, when a build works, and does what you want it to do, stick with it.

[CruNcher]

ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe <- crashing here too on a Athlon 64 Venice

[DeathTheSheep]

ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

"An exception occured when trying to run ffdshow.ax"

Yep, this is a true crash--no doubt about it. Hope it "gets well soon!" :p

4.0.2 builds should work, eh? I think a test is in order... ;)

[bob0r]

ffdshow builds compiled with gcc 3.4.4 will not be supported, only gcc 4.0.2, and higher i guess.

Here is a new build with ff_vfw.dll working again + the other updates/fixes:
ffdshow-20051124-gcc4.0.2-sse-x264.nl.exe download from x264.nl, and SSE2 build:
http://files.x264.nl/ffdshow/ffdshow-20051124-gcc4.0.2-sse2-x264.nl.exe

changelog:
http://cia.navi.cx/stats/project/ffdshow

[ExtraEye]

thx bob0r!

[LigH]

And again - "non-SSE" only from milan?

[clsid]

There is a new build from Milan online now too.