New ffdshow build (?)

[LoRd_MuldeR]

I´m having trouble downloading builds on googlepages. The download suddenly stop at bout 1.7 Mbs and reports "Download completed", but of course the .exe is broken. It´s happening with bobor´s and vm9´s builds. Yet vcredist_x86 and audxlib.dll download properly. Anybody having this problem?

Yeah, here to. Needed to use FDM (http://www.freedownloadmanager.org/) for downlaod. Then it worked fine.

[videomixer9]

I dunno what's the problem with googlepages, could download thing myself just fine, maybe they got some probs due to magic running out of capacities like google likes it or they throttle on purpose. It happens with bob0r's builds too? then it's sth. else :p

aWarpSharp is kinda broken, I dunno what that is, and iirc it is broken with downsample etc. for longer time now, if you disable those it's fine though. MatMaul build e.g. it doesn't even work at all. issa build has the same problem as mine. But besides that I notice on some movie that it has a watermark that shows up using this, heh :P

PCM processing seems to be broken on some part, but I don't want to enforce e.g. 16bit processing cause all others would be broken then and I personally like 24bit :O That problem should be common in most builds.

[Liisachan]

I can't reproduce the "googlepages" pb either. Download is fast and uninterrupted here (i.e. even resume is neededless)
Thanks for your great works btw :)

[Skelsgard]

aWarpSharp is kinda broken, I dunno what that is, and iirc it is broken with downsample etc. for longer time now, if you disable those it's fine though. MatMaul build e.g. it doesn't even work at all. issa build has the same problem as mine. But besides that I notice on some movie that it has a watermark that shows up using this, heh :P
Don´t know if u´re answering to my posting, but with "the .exe" i meant the installer, not any of the program´s utilities.

Downloading it with no problem with FDM :).

[videomixer9]

If you had read the rest of the posts you'd known for who that is, doh.

besides at Link00y, milan is the programmer of this so ask him for features, besides you can swap channels already with ffdshow, and I don't know if the mixer doesn't work for mono audio, I don't have anything from the ages when mono was still used.

Besides you also misunderstood Creative's CMSS features, Stereo Surround doesn't mean pseudo-5.1 sound but it just mirrors the stereo signal to the back and mixes two channels together for the center. For music etc. this is imo better as pseudo-5.1 is mostly lousy and way too much audio on the center channel.

Besides you can automatically load a specific preset based on the number of channels in the input, the input type etc. already. Just create a new preset and set the matrix how you want it and select an fitting autoload condition.

btw. someone requested my gcc params earlier:
-march=athlon-xp -mtune=athlon-xp -mmmx -msse -mfpmath=sse,387 -fforce-addr -ftree-loop-linear -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-loop-ivcanon -funsafe-loop-optimizations -ftree-loop-im -ffast-math -fprefetch-loop-arrays -fmerge-all-constants -falign-functions=64 -falign-jumps=4 -falign-loops=4 -O3 -fomit-frame-pointer -finline-functions -finline

:p works properly on other too even though it has athlon, but I bet it runs better on athlon thx to this :P

[foxyshadis]

XP just means it's made for midsize L1/L2 caches and short pipelines, like P3/Core, pretty much the exact opposite of older P4 but should perform fine on other processors without broken architectures.

[videomixer9]

yeah Athlons have way larger L1 caches than most of their Intel companions, 8kb vs. 64kb, that's the most significant thing. Another point many Intel models are bad with is the old 387 FPU modell that is used combined with sse.

btw. if you want to use optimized parameters better skip using GCCs loop unroller. Horrible crap, in fact GCC is imo still one of the worst compilers if you compare MSVC, ICL and GCC. Well of course it's a open and free compiler unlike the other two.

[foxyshadis]

videomixer, can you enable 7z on the installer if it's available? I rar'd up the file to email to a friend, just to wrap it, and lo, it was 2 megs smaller.

[celtic_druid]

!ifndef COMPRESSION
!define COMPRESSION lzma
!endif

Should get lzma by default.

[videomixer9]

The compression used for my installers is lzma solid. The installer should contain like 17.3 MB of stuff and is only 4.1 MB, I doubt you got it really down another 2 MB that easily.

[foxyshadis]

Wait, I'm stupid, I was looking at the wrong field. Ngg, never mind.

[Liisachan]

Agreed

2006-05-15 12:01 4,353,629 ffdshow-20060513-rev2546-icl91.7z
2006-05-15 12:00 4,300,562 ffdshow-20060513-rev2546-icl91.exe
2006-05-15 12:01 4,300,660 ffdshow-20060513-rev2546-icl91.rar


This installer looks cool but unfortunately this version doesn't work for me. Just trying 2 open a normal AVI via any DS player causes crashing. VfW encoding app can't even start either. Is this supposed to work only for HT or some special CPUs?

[videomixer9]

Only works with SSE, welly ou prolly have that, other than that no special requirements. The automatic parallelization code ICL produces seems to not work on some funny processors, it does on AMD Athlon XP/64 just fine as it seems. And anything except for libmplayer and libavcodec is compiled with ICL. Well as stated it could be that it doesn't work on some Intel processors maybe, function alignment is optimized for 64kb L1 cache, most Pentiums only got 8.

As stated on the website I don't care even one bit if it works on Intel CPUs :P If you got one of those I'm afraid that I cannot help you.

[Liisachan]

Yep, it's Prescott. And it's ok if it's a compiler-side pb. I just wanted to confirm that problem was not in ffdshow itself. I'll just use another build. Thanks anyway even if your build doesn't mix well with my CPU. :)

[videomixer9]

Now I'd rather expected older Intels to have problems, especially the code generated by ICL I wouldn't expect Intels to crash it, though whoever buys Intel should be punished :p would be nice to find out how it breaks so that I can break it even more for all Intel CPUs :p

Usually reclock output nice crash infos incl. the part of ffdshow that really crashed or if it were e.g. runtime libs as usually crash dialogs show up ffdshow.ax as the culprit.

Besides this I might skip a bit on ffdshow building, currently no changes anyways and other than that my need for the filters in it is very low and I got a neat other decoder to test by someone.

[_xxl]

libavcodec.dll can be compiled with
Microsoft.Visual.Studio.2005 + INTEL 9.1 + GCC 4.0.2!

[videomixer9]

I'd rather have the _mm_flags unresolved fixed to compile it all with ICL. Also must be a miracle that a linker puts together that mix. Odd enough e.g. my x64 has a fully ICL compiled libavcodec.dll, only win32 makes probs.

full ICL compile always ends with these linker errors:
vp3.obj : error LNK2001: unresolved external symbol _mm_flags
mpegvideo.obj : error LNK2019: unresolved external symbol _mm_flags referenced in function _get_vissual_weight
ratecontrol.obj : error LNK2001: unresolved external symbol _mm_flags
utils.obj : error LNK2001: unresolved external symbol _mm_flags
vcr1.obj : error LNK2001: unresolved external symbol _mm_flags
h263dec.obj : error LNK2001: unresolved external symbol _mm_flags
huffyuv.obj : error LNK2001: unresolved external symbol _mm_flags
mjpeg.obj : error LNK2001: unresolved external symbol _mm_flags
mpeg12.obj : error LNK2001: unresolved external symbol _mm_flags
asv1.obj : error LNK2001: unresolved external symbol _mm_flags
dv.obj : error LNK2001: unresolved external symbol _mm_flags
faandct.obj : error LNK2001: unresolved external symbol _mm_flags
ffv1.obj : error LNK2001: unresolved external symbol _mm_flags
dsputil.obj : error LNK2019: unresolved external symbol _dsputil_init_mmx referenced in function _dsputil_init
mpegvideo.obj : error LNK2019: unresolved external symbol _MPV_common_init_mmx referenced in function _DCT_common_init

oddly enough mm_flags isn't even referenced in all those files. The other function properly compiled but are missing in the object files.

[foxyshadis]

From dsputil.h, which all those files include...

extern int mm_flags;

which should be defined in dsputil_mmx.obj. Is that file not getting linked? _dsputil_init_mmx should be in there too. _MPV_common_init_mmx should be in mpegvideo_mmx.obj.

[_xxl]

ffdshow-20060516
http://rapidshare.de/files/20613041/ffdshow-20060516.exe.html

[haruhiko_yamagata]

So basically ffdshow needs to be re-engineered to do multithreading all the way through, presumably by pre-buffering several frames of audio or video data (which can decide how to best parallelize that part), decoupling the filtering engine from the decoding engine and feeding into a worker thread per core like vm9 says, then having a pool at the renderer that ensures frame order and timing are correct. Shouldn't be too hard... for server engineers. ;) I wish I knew more about implementing threading, I'd love to work on it. I'm curious how much of that structure is already done.

Until then, having portions of it multithreaded is still better than nothing, though.
Now I've cleaned up my debug queue, I'm begining to think of your request. Having a queue of samples just before sent to downstream would improve sporadic frame drops. Though I'm far from server engineer and I'm not sure if I can make it.
Thank you for your request. Sorry to respond late.

I updated my patch. Minor bug fix.
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

patches for patches would be nice, the most recent one needs almost all stuff restored or produces funny results otherwise like double passages of code.

Whatever, this (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build includes those changes.

[flanger216]

I installed Celtic's x64 build, but when I try to play a movie, Zoomplayer reports that it is "unable to create the ffdshow filter;" in other words, I get a graph error for the video and audio ffdshow filters.

So the question is: in order to use 64-bit ffdshow, does one have to use a 64-bit media player?

[celtic_druid]

Yes. You can have both 32bit and 64bit versions installed at once though. I actually tested the 64bit version in Graphedit64. Are there any 64bit media players?

The other thing is that I didn't add any FourCC selection type options, so you need to configure ffdshow after installing.

Some other notes:

Apparently Inno Setup's browse for file feature doesn't work in x64 mode, so VDub's plugin gets installed to ffdshow's directory. If you want to use it, copy it over.
The AVISynth plugin and AVISynth VfW support is disabled unless there is a HKLM\Software\AVISynth key with the plugin path. Installing via the .inf doesn't add this.

[Lemonzest]

videomixer9, now your builds are done with ICL9.1 have the intel cpu only checks been removed? so it runs full speed with sse/sse2 etc on AMD's CPU's?

[videomixer9]

It's not using automatic detection but forced one, so it should be fine without any patches, though it might not. I don't know of any patches for 9.1 though. Does it also use checks if you use /QxN e.g. ? I read that it doesn't. Btw. this SSE thing is getting redicolous, 9.1 should also already come with SSE4 support ... teh ... hail the codebloat.

The /Qax checks weren't removed, it seems Intel still wants to hide that their processors are crap and fear their own compiler producing dozen times superior code on AMD. An easy thing is to boycott Intel on the processor part and also companies like Dell which get bribed for using their crap.

[Paul Oblomov]

I'm having biig problem with almost all builds I've tried - when playing apple HD trailers (1080i) I got sudden CPU usage drop. For ex. it plays smooth for 30 sec and CPU usage 80-90% and suddenly it drops to 15-20-30%, totaly slowing down decoding :( Seeking 5 seconds back is enough to make it "eat well" again... for 10 seconds. :( Any ideas ?

P.S.
A64 3200 with AMD latest driver + 2gb ram + x800pro + win2k3 sp1
+
haali splitter + xvid + divx + x264 + any ffdshow + zoom player 4.51 and 5 pr.6

ffdshow-20060513-rev2546-mt_bugfix-SSE2.exe

And the next one - some AAC streams makes ffdshow's faad or realaac kinda hiss. It reports 96Khz (audigy2 zs). CoreAAC works like a sharm.

[videomixer9]

GCC optimizations MatMaul uses on his builds breaks libfaad and maybe realaac too.

The drop issue is simply that your PC seems to be to slow. CPU usage isn't constant for decoding, on various parts that make use of certain codec features it might need more processing power. If ffdshow is overloaded it usually does this stalling to kick in at a later point again. Weird effect but also the case here with things that overwork my CPU. You might wanna try VMR7 output, usually the fastest.

Only thing that solved this for me was using CoreAVC ;)

[Paul Oblomov]

Slow ?! Damn :( I remember NASA trailers - played smooth. but not with ffdshow :(

[videomixer9]

well dunno, here at least xmen 3 hd trailer in 1080p plays fine (well barely okay) with ffdshow. might be something else on your setup that maybe slows down the playback, or maybe try another build. And I got an Athlon XP 3000+ only.

[MatMaul]

GCC optimizations MatMaul uses on his builds breaks libfaad and maybe realaac too.

Can you tell to me what optimizations breaks libfaad and realaac please ?thanks!

[videomixer9]

If you only use the switches mentioned on your page I'd guess that it's fast-math that break it. You might need to apply different CFLAGS to libfaad and realaac. The loop unroller might be the culprit though too, it depends on the version of GCC. GCCs loop unroller mostly seems to suck anyways. Also note that you can only break parts of libavcodec with specific flags, e.g. the vorbis decoder in libavcodec easily breaks without other parts being affected.

[issa]

It's not using automatic detection but forced one, so it should be fine without any patches, though it might not. I don't know of any patches for 9.1 though. Does it also use checks if you use /QxN e.g. ? I read that it doesn't. Btw. this SSE thing is getting redicolous, 9.1 should also already come with SSE4 support ... teh ... hail the codebloat.

The /Qax checks weren't removed, it seems Intel still wants to hide that their processors are crap and fear their own compiler producing dozen times superior code on AMD. An easy thing is to boycott Intel on the processor part and also companies like Dell which get bribed for using their crap.

ICL will product CPU ID check when you use optimize flag other then K or W. It will check your CPU ID to ensure it is Intel CPU, otherwise it will quit the code immediately. It also true on the Qx flag. The ICL check depend on CPU ID, not the CPU Extension.

[Paul Oblomov]

AXP 3000 ?!?! WOW
I've got twice more powerfull CPU... Damn!
There's smth strange with my system :( X-men 3 1080p - 10seconds -- fine. Then - slow as hell. Tried CoreAVC - the same sh*t.

[MatMaul]

for libfaad and realaac I use the last snapshot of gcc 4.1.1.
for my next builds I disable the loop unroller.

[videomixer9]

Well better try it before if it's really the culprit, doesn't take to long to do a compiling test, faad and realaac compile in 30 secs or so.

Athlon 64 3200+ twice as powerful? heh. 64bit doesn't mean it has twice the speed, an X2 would be a different thing but libavcodec doesn't do multithreading for h264 yet properly. Try to check for weird filters in your system and e.g. check filter graphs for anything weird being active or your player not using proper acceleration.

[videomixer9]

ICL will product CPU ID check when you use optimize flag other then K or W. It will check your CPU ID to ensure it is Intel CPU, otherwise it will quit the code immediately. It also true on the Qx flag. The ICL check depend on CPU ID, not the CPU Extension.

So any easy patch for ICL 9.1 libs there?

[LoRd_MuldeR]

I get extreme CPU usage when I enable KernelDeinterlacer with your latest builds. I even can't used it for real-time playback on my AthlonXP 2800, because I get too high CPU usage and A/V dysnc plus stuttering. With TomsMoComp it works fine! And remember I used KernelDeinterlacer in ffdshow some time ago with "normal" CPU usage. This makes me think there's something wrong with KernelDeinterlacer code in latest builds. Maybe it's ICL specific problem?

[videomixer9]

maybe, kerneldeint regularly get icl into new dimensions of memory usage.

I'll update the latest builds with a new kerneldeint. Dunno what it was but should work fine now probably. Must've been ICL being out of memory again before. This (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build should have a fine kerneldeint now.

[LoRd_MuldeR]

maybe, kerneldeint regularly get icl into new dimensions of memory usage.

I'll update the latest builds with a new kerneldeint. Dunno what it was but should work fine now probably. Must've been ICL being out of memory again before. This (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build should have a fine kerneldeint now.

Damn, you are fast! That fixed the problem perfectly :)

[clsid]

So any easy patch for ICL 9.1 libs there?
You can do it rather easily with a hex editor. Just search for 'genu', 'inei' and 'ntel'. Then replace 3d47656e75, 3d696e6549 and 3d6e74656c with a900000000.

[videomixer9]

nice, that's easy, nicely obscured :p

[MatMaul]

Well better try it before if it's really the culprit, doesn't take to long to do a compiling test, faad and realaac compile in 30 secs or so.

Athlon 64 3200+ twice as powerful? heh. 64bit doesn't mean it has twice the speed, an X2 would be a different thing but libavcodec doesn't do multithreading for h264 yet properly. Try to check for weird filters in your system and e.g. check filter graphs for anything weird being active or your player not using proper acceleration.
The problem is I don't have any problem to decode aac file with faad and my pentium M with my last builds (SSE and SSE2 builds work on my pc).

@Paul Oblomov : Can you try my last build please (20060517)?

[Egh]

This build should have a fine kerneldeint now.

Yet it seems new build crases on MP3 if mp3lib is used on Athlon XP here.

[Paul Oblomov]

videomixer9
K8 faster that K7. Linear x2 boost.

MatMaul
The same sh*t :( I'm switching back to CoreAAC.

BTW - videomixer9 latest build does the same sound. Since I don't know if there's anything like frame editor for aac, I can rip this track of and share, so you can find a solution.

edit
Extracted it out. Winamp plays well ;) 58Mb
Size: 61644528 bytes
Format: AAC
MPEG-2 LC-AAC
Sample Rate: 48000
SBR: Not Present
Channels: 6 Mode: 5.1
Bitrate: VBR

edit once again
Cutted with hexworkshop ~2mb
http://rapidshare.de/files/20812918/Track21.rar.html

[issa]

Rev. 2546 pure GCC 4.1.1 testing build,

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20817522/ffdshow-2546-gcc-sse2-20060519.exe.html) (updated)

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20818308/ffdshow-2546-gcc-sse-20060519.exe.html)

I am trying a different optimize flags to see if there is any speedup on pure GCC build.

Compiler: ICL 9.1.22 (msvcrt 8 included + patched intel lib) + GCC 4.1.1
CPU Extension: SSE2 (Compiled with -QxN -QaxP)
Download: RapidShare (http://rapidshare.de/files/20824815/ffdshow-2546-icc-sse2-20060519.exe.html)

People have AMD CPU with SSE2, please help me to test if the patched work, since I don't have AMD CPU.

[Paul Oblomov]

I found a problem with my HDTV speed! Seems like my NTFS partition where those trailers placed is f**king fragmented OR bad mft table. Maybe old or whatever. Recopying to just another folder - and all them played nice and sweet!!! :D Really weird! So it's not my "slow" PC or whatever nor ffdshow! Sorry, for the inconvinience :(

[JarrettH]

Admittedly, issa's builds are the only ones that don't crash when I use my image settings (live tv, divx/xvid, DVD). I don't know what's different about them, but they consistently work for me. Using rev2546 ICL9 SSE

[videomixer9]

Yet it seems new build crases on MP3 if mp3lib is used on Athlon XP here.

Yeah I broke it with GCC but libmad is usually set as default for my installer and I just hate mp3lib so much :p The sound libs in libmplayer are just way to easy breakable. Cannot optimize the video part without the crappy audio codecs breaking all the time. I usually benchmark it for video on my system and am happy if it's very fast, not a filterfreak and not a fan of audiocodecs in libmplayer.

Okay now I'm seriously pissed off by this, got no fucking clue which of the switches breaks mp3lib since removing most of them didn't help a bit. Gotta love this.

[Livesms]

Rev. 2546 pure GCC 4.1.1 testing build,

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20817522/ffdshow-2546-gcc-sse2-20060519.exe.html) (updated)

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20818308/ffdshow-2546-gcc-sse-20060519.exe.html)

I am trying a different optimize flags to see if there is any speedup on pure GCC build.

Compiler: ICL 9.1.22 (msvcrt 8 included + patched intel lib) + GCC 4.1.1
CPU Extension: SSE2 (Compiled with -QxN -QaxP)
Download: RapidShare (http://rapidshare.de/files/20824815/ffdshow-2546-icc-sse2-20060519.exe.html)

People have AMD CPU with SSE2, please help me to test if the patched work, since I don't have AMD CPU.

I've got AMD Sempron 3000+ x64 (SSE2 SSE3) - and in hour or two I'll tell you result.

[videomixer9]

wow I finally found what broke mp3lib. If nothing breaks again I stop fiddling around with GCC params too much now. Thanks for the report again. But I just love fiddling around with GCC params to try and squeeze out some more performance on decoding for my box :P

other than that i'd be interested if the patched lib really works though I'd prolly use the combination of QxK and QaxN

The thing with libavcodec compiling and why it didnt fail on x64 target with ICL was btw. very easy after I remembered that usually ffmpeg gets configured before compiling, on x64 HAVE_MMX is undefined and thus handcoded MMX stuff won't be compiled, if I remove it from config.h it of course works then. Though, this prolly means that if you change it when doing x64 compiles it will be slower than most other compiles, it seriously slower without the handcoded MMX stuff.