ffdshow and ffdshow_tryout Builds Listing

[SeeMoreDigital]

Is the ff_x264.dll decoder the most up-to date libavcodec version?


Cheers

[LotharZ]

@videomixer9

Perfect, problem solved.

thx

[videomixer9]

ff_x264 is an encoding lib and was last updated long ago.

[LoRd_MuldeR]

ff_x264 is an encoding lib and was last updated long ago.

Why not using x264 from SVN for compiling that lib?

[videomixer9]

you cannot just use the official lib, needs changes and without knowing them it's fiddling around for something prolly very few people even use and I guess milan picks the candy for updates and not too much borked code.

[clsid]

SVN: 2006-05-13 (rev. 2546)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Patches:
- high accuracy tremor
- high accuracy libmad
- MT fixes
- libavcodec 6ch vorbis fix
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/20360880/ffdshow-20060513-rev2546.exe.html)

I'll make a ICL9.1 build later this weekend.

[Liisachan]

mirrored ffdshow64-rev2546.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow64-rev2546.exe)

BY: celtic_druid
FOR: x64

[celtic_druid]

Not the default nsis installer either. Used InnoSetup since it supports x64 better.

[clsid]

Here is another ICL9.1 build:

ffdshow.ax (rev2546) (http://rapidshare.de/files/20717549/ffdshow_ax_rev2546_icl91.rar.html)

[Kostarum Rex Persia]

Please use megaupload or mytempdir servers, Rapidshare is bad.

[SeeMoreDigital]

Please use megaupload or mytempdir servers, Rapidshare is bad.Agreed ;)

[Inventive Software]

Never had any problems with rapidshare... then again I have a good ISP!! ;)

I've seen a lot of people using ICL 9 to compile things that GCC can't handle. Would I be right in assuming that ICL 9 costs mega-bucks, and that there isn't a free version, except for Linux?

[videomixer9]

You can get discounted versions, regularly it costs quite too much just for compiling some free software.

Things GCC cannot handle, well, Intel Compiler is probably the best compiler available, it generates very fast code and it can automatically vectorize quite good, also it can now automatically produce code that makes use of dualcore features. That's more of a reason that people use it.

GCC is actually not a that good compiler, it has many quite annoying bugs and glitches. Consistency is very bad, what worked in a previous version can break easily in another, Linux distributions often have to carefully chose a version. Many of the optimizations can easily lead to broken code.

Microsoft's Compiler is a good compromise between compatibility and speed. Microsoft was blamed often for MS specific extensions, however this is the case for GCC, ICL or other compilers too. Microsoft Compiler however misses some of those neat automatic optimizations, however the code is usually quite good considering it's very fast compile times. Besides it hardly ever produces failures just through compilation.

Intel Compiler is a clear winner on speed of compiled code usually, the drawback is that it can easily takes hours to compile some things as extended code optimizations need long analyzing runs that eat quite much CPU power and memory.

There's also another thing, different compilers like to produce different quality of floating point code. ICL seems to produce fast operating code that is still very precise, you can notice this with things like tremor, libfaad and others, especially faad likes to break and make AAC sound worse just due to compiler glitches, especially GCC, using ICL or MSVC dramatically decreases this risk. milan's default makefiles are very basic probably for this very reason.

And of course Intel let's people pay for this, not too bad, considering you can easily gain some speed without doing anything it's an good deal.

Of course there is the ideal of compiling free software with free software, but my experience so far shows that ICL/MSVC had way less problems and errors due to the compiler. I dunno how often I redid a GCC compile sometimes cause some switch totally broke random code.

[Shapierian]

There's also another thing, different compilers like to produce different quality of floating point code. ICL seems to produce fast operating code that is still very precise, you can notice this with things like tremor, libfaad and others, especially faad likes to break and make AAC sound worse just due to compiler glitches, especially GCC, using ICL or MSVC dramatically decreases this risk. milan's default makefiles are very basic probably for this very reason.

Tremor is integer only. See: http://en.wikipedia.org/wiki/Tremor_%28software%29

[clsid]

SVN: 2006-05-26 (rev. 2546)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Patches:
- high accuracy tremor
- high accuracy libmad
- latest MT patch
- libavcodec 6ch vorbis fix
- LPCM fix
- DTS fix
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/21433224/ffdshow-20060526-rev2546.exe.html) (rapidshare)

[videomixer9]

ffdshow rev. 2546 2006-05-26

requires: SSE or better
compilers: ICL 9.1.022, GCC 4.1.1
specials: high accuracy tremor, high accuracy libmad, libavcodec 6ch vorbis fix, newest mt patch, lpcm fixes, dts fixes, some changes from ffmpeg merged, more gcc optimizations, includes aud-x libs
download: here (http://www.fileking.to/download.php?n=fCT2Fcg5IB) or here (http://rapidshare.de/files/21595503/ffdshow-20060526-rev2546.exe.html) or here (http://www.filepoint.de/download/5378-dl-ffdshow-20060526-rev2546_exe) or here (http://s6.simpleupload.de/f5c9c52b1/ffdshow-20060526-rev2546.exe.html)

If no other errors will appear my hopefully last 2546 build.

[clsid]

Could you post a patch/diff for the ffmpeg and libfaad2 changes that you merged? Thanks.

[videomixer9]

libfaad2 you can just check out from sf.net and replace the files with the one in the ffdshow directory, any random compile of libfaad2 2.1 beta would even work with ffdshow if it uses the same def file, it'd only throw an error trying to show version info. I merged ffmpeg stuff per hand as the patchfiles I got of ffmpeg SVN server didn't wanna apply, wonder if I remember which files I changed hm, nothing major, let's see if i get them right, though prolly just run patch over the whole dir will work. Though it's just some files where I removed forced asserts and some minor changes to h264 code.

http://bittekeinspam.googlepages.com/ratherfunnyffmpeg.patch

some unneccessary things as I removed some lines accidently.

[SeeMoreDigital]

The "Installer" says "DivX4" but the "Video Decoder Config" says "Generic MPEG4": -

http://img157.imageshack.us/img157/1317/installer0ts.png

By-the-way, is there any reason why the "Other MPEG4" FourCC's aren't bundled together with the "Generic MPEG4" FourCC's?


Cheers

[Liisachan]

@clsid Thanks very much!!!

@all
Please update libfaad carefully. Celtic_druid and I have good reason to belive sbr_qmf.c revision 1.29 is buggy (can't decode some HE-AAC properly) and 1.28 is a good one.

The situation is still unclear and hypothetical but the best guess so far is: menno tried to make it faster by changing 32-point DCT-IV + DST-IV to DCT-IV 2 times (simpler - more optimizable), but he forgot to change the positive/negative. Just changing k -> 31-k is not enough. Signs should have been properly modified. This explanation may or may not help. Honestly I dont know what I'm talking about; I'm just repeating what I was told by someone who knows better. What I know for sure is, the newest libfaad doesn't decode this sample (http://www.minkymomo.info/~meroko_deathnote/tmp/he_aac_problem/pocket_1.aac).

[videomixer9]

bleh. fixed the issue with the sbr stuff and just changed to new links.

[Liisachan]

libfaad thing _is_ a bug, confrimed by menno.
already updated.
sbr_qmf.c 1.30 is basically the same with 1.28
in sbr_dct.c 1.17 the DST4_32 macro restored too
So you can now just use the newest CVS, at least that's what is supposed to be.

[videomixer9]

ffdshow rev. 2546 2006-05-30

requires: SSE
compilers: MSVC 2005, GCC 3.4.5
specials: high accuracy tremor, high accuracy libmad, libavcodec 6ch vorbis fix, newest mt patch, lpcm fixes, dts fixes, includes aud-x libs
download: here (http://www.filepoint.de/download/5859-dl-ffdshow-20060530-rev2546_exe) or here (http://rapidshare.de/files/21875771/ffdshow-20060530-rev2546.exe.html)

traditional style with maybe less side-effects and not much really worse decoding performance, down to 2.99 MB with possible more saving when removing aud-x and msvcrt, like 2.59 MB :o

[LoRd_MuldeR]

ffdshow rev. 2546 2006-05-30

requires: SSE
compilers: MSVC 2005, GCC 3.4.5
specials: high accuracy tremor, high accuracy libmad, libavcodec 6ch vorbis fix, newest mt patch, lpcm fixes, dts fixes, includes aud-x libs
download: here (http://www.fileking.to/download.php?n=X54L8NdnWd) or here (http://rapidshare.de/files/21796474/ffdshow-20060530-rev2546.exe.html) or here (http://www.filepoint.de/download/5713-dl-ffdshow-20060530-rev2546_exe)

traditional style with maybe less side-effects and not much really worse decoding performance, down to 2.99 MB with possible more saving when removing aud-x and msvcrt, like 2.59 MB :o


This one fixed the "libfaad2" problem with MPC.

[Inventive Software]

Is there ANY possibility that when building, people remove dependancies on DLLs and libs that are NOT compatible with 98? It kills me that I wanna try a new build SO BADLY and yet, it's not compatible with 98. Please don't tell me to upgrade, cause that's not an option at the moment!

@SeeMoreDigital: I'll take a look at the NSIS script tonight and see if it can be updated.

[Liisachan]

This one fixed the "libfaad2" problem with MPC.
What's that problem? Is it a MPC-side problem, and is it the same pb that was in CoreAAC+HE-AAC?

Btw, I'm using videomixer9's now too, as it's now ok with P4. Thanks a lot!

[SeeMoreDigital]

@SeeMoreDigital: I'll take a look at the NSIS script tonight and see if it can be updated.That would be cool.... many thanks ;)

EDIT: I'm sure somebody recently released a build that said "Generic MPEG-4" within the install page!

[videomixer9]

I did ... and then immediatly forgot about it an used the unchanged script for the next one again as I reverted the sources :p

[LoRd_MuldeR]

What's that problem? Is it a MPC-side problem, and is it the same pb that was in CoreAAC+HE-AAC?

Btw, I'm using videomixer9's now too, as it's now ok with P4. Thanks a lot!

Dont know. FAAD2 was broken for some videos with AAC audio (for example Superman trailer). With RealAAC there was no problem. But the FAAD2 problem was only there in MPC! In Graph Edit or WMP it worked fine with ffdshow & faad2.

[SeeMoreDigital]

Well here's my GUI proposal. Sorry I could not stop myself ;) : -

http://img312.imageshack.us/img312/3339/ffdshowgui1ia.png

[foxyshadis]

MSMPEG4v3 should cascade to the other two, which are hardly seen anyway, no reason to have all three listed. Maybe even all cascaded from Divx3 since they're the same codec. And no one would have a clue what Generic MPEG-4 Part 10 meant :p "AVC, H.264" would work.

If you're going to change it around, you might as well add Flash Video (FLV), maybe ZMBV, and "Legacy Codecs" (Sorensen, Cinepak, Indeo3, old MS stuff).

[SeeMoreDigital]

MSMPEG4v3 should cascade to the other two, which are hardly seen anyway, no reason to have all three listed. Maybe even all cascaded from Divx3 since they're the same codec.

And no one would have a clue what Generic MPEG-4 Part 10 meant :p "AVC, H.264" would work. Well they "bloody well should do" ;)

Here's another effort: -

http://img200.imageshack.us/img200/3885/ffdshowgui7vf.png

[videomixer9]

Hm, okay I did some small changes to the installer and added a funny WMV3 box too as way too many people seem to be interested in that "hack". Compressing one option into three isn't that easy with the current installerscript. Needs multi-4cc assigning to things and registry writing stuff and so on ... considering the importance of this screen rather useless. Also someone might want to enable only MPEG3v2 by MS, oddly some open movie people love this 4cc even though they obviously don't use MS MPEG4. Btw. this isn't the discussion thread :p

[Avish]

Dont know. FAAD2 was broken for some videos with AAC audio (for example Superman trailer). With RealAAC there was no problem. But the FAAD2 problem was only there in MPC! In Graph Edit or WMP it worked fine with ffdshow & faad2.Yes. It's fixed allright. What did u fixed reagrding this problem VM9? Can u shed some light? Can u tell us what was the problem?

[videomixer9]

It's just the old sources. Was there actually anything that didn't properly decode with those for anyone? besides new source didn't work with GCC somehow.

[Negi]

Perhaps someone could write some sort of script that adds new builds to an RSS feed. That would be awesome.

[LoRd_MuldeR]

@VM9: Why gone back to old GCC 3.4.5 in latest builds?

[videomixer9]

Actually I was told using 2.95 might even be a better choice. Also one mplayer dev told me gcc is shit. Also GCC 4.x had this weird random problems, so for a stable build I though I'd choose 3.4.5. Maybe I'll try 2.95 next time if it works :P For the hardcore optimization I might go GCC 4 again, but I dunno if I'm upto more fishes appearing in the video for several people and all this other stuff :p Also GCC is kinda contraproductive with optimization, the more you use the crappier the code, even the default -O3 is shitz ...

I encourage everyone to use an whatever built, no need to upgrade to the one with the newest date if your current one is fine, it's identical revisions after all. Also we got lots of people now doing builds in tons of flavours! :p

The newest ones this time might be a bit slower than the other ones as it's a stability build. Not much fancy.

[sillKotscha]

This one fixed the "libfaad2" problem with MPC.

yeahh, exactly!!!

now my problem described here (http://forum.doom9.org/showpost.php?p=833842&postcount=1431) is gone :)

thank you

[LoRd_MuldeR]

Actually I was told using 2.95 might even be a better choice. Also one mplayer dev told me gcc is shit. Also GCC 4.x had this weird random problems, so for a stable build I though I'd choose 3.4.5. Maybe I'll try 2.95 next time if it works :P For the hardcore optimization I might go GCC 4 again, but I dunno if I'm upto more fishes appearing in the video for several people and all this other stuff :p Also GCC is kinda contraproductive with optimization, the more you use the crappier the code, even the default -O3 is shitz ...

Hmm okay. And why no ICL for latest builds as you used some time ago?

[thuan]

Because there's crash with the sample in this post (http://forum.doom9.org/showthread.php?p=833602#post833602), msvc ffdshow.ax and gcc one works fine (but gcc has stupid bug in some filter like gradual denoise).

BTW vm9, according to my testing and available ffdshow compiles then libavcodec compile with gcc 3.4.x is the fastest (don't know about 2.95 no one compiled with it) about libmplayer then your gcc4.1.1 compile is the fastest, libmad fastest with gcc 3.4.5 (this one I just look at Task manager so not so sure). The others haven't tested yet.

[Inventive Software]

Does nobody care about supporting Windows 98?????? (Except me.:()

GCC 2.95.1 would be the most stable 2.9 series of GCC, though for the 3 series, I'd recommend the latest in the 3.3 series, as 3.4 seems to induce a lot of unwanted hassle!

[videomixer9]

Why support Win98? I totally see not a single reason to support a part of the DOS based Windows Versions, use Windows NT, that one was released 1996 and is still way better than 98, or use Win2k which runs on older PCs fine too, it just requires a bit more RAM to install. Some NT Servers even made it to over 7 years uptime.

[foxyshadis]

Inventive, your best chance of getting a win9x install is getting mingw and making one. (Pretty sure you can do a pure gcc build, right?) Otherwise an old copy of VC6 or VC7.1 from someone. No one who builds it now can even test it on 9x before release, knows where the pitfalls are, or which libs may be non-9x compatible, or wants to deal with the frustration of patching working code to resucicate a dead OS with 5% marketshare and so many driver problems. At the least, it would probably mean installing old platform and directx SDKs, an old compiler, and excising any nt-specific code.

[celtic_druid]

Biggest problem would be unicode. At least I always did unicode builds. I would imagine that others do to.

[clsid]

My build will work on Win9x. It will need msvcr71.dll though.

[videomixer9]

Newer MSVC though still has a special switch that enables Win98 compatbility. But seriously, Win9x was so bad ... though i hopped onto NT 1996 already ... so no clue. There should be also an unicode addon for win98 ... *shudder*

[Inventive Software]

@foxyshadis: I tried, but there are elements of the .ax filter that aren't compilable with GCC. I do have MinGW, haven't used it for ages cause I restored my Ghosted partition a few months ago, but the last time I tried to compile GCC 3.4.5, it choked. Compiling the rest of ffdshow wasn't a problem, getting the .ax to compile was (and that's the critical part!). I don't have access to MSVC6 or 7. I'd use the VC Toolkit, which is free, but that's only for 2000/XP.

@clsid: It's your build I'm using now, cause I can't get VM9's builds to work in 98. Time to go looking for your latest I think...

[videomixer9]

Try installing this http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ED06-4F0D-80A4-2A7EEAEE17E2&displaylang=en

[Inventive Software]

Wow, thanks! I'll try that later, and see if that helps...

I pinpointed the problem to do with 2 DLLs that aren't included in the standard 98 SE install, userenv.dll and apphelp.dll. If they're not used, I wonder if dependancies on them can be removed...