New ffdshow build (?)

[issa]

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.

Which gcc flags break the mp3lib?

[videomixer9]

doubt you use it but it was -fforce-addr. I originally added this after reading that it may be useful on gentoo forums, obviously not that useful with mp3lib.

Another tip, try the resize filter if you use aggressive optimizations, it may produce weird blocky video with some switches. Other thing is libfaad, it will produce weird sound if you use too aggressive optimizations. In libavcodec the vorbis decoder may break.

Yeah I broke a lot of stuff already :p

[issa]

doubt you use it but it was -fforce-addr. I originally added this after reading that it may be useful on gentoo forums, obviously not that useful with mp3lib.

me too... maybe it's not good on windows.

[Egh]

Yeah I broke a lot of stuff already :p

Not that I use libmp3 much but still was worth reporting :)

Now it seems to work.

BTW, I think some MPEG-1 playback was b0rked as well in previous build, don't remember whenever it was libavc or libmpeg2 responsible (was reproducibly crashing with one of these).

Now that file seems to work OK>

[videomixer9]

Probably due to the same reason, I used that flag for some time. libmpeg2 is now ICL which produces pretty reliable code, so I guess it may have been libavcodec, per default the installer will enable libmpeg2 if you enable it on install.

[MatMaul]

Finally I have problem with libfaad2 too on my pc, the file of Paul Oblomov sounds crap with ANY builds : I tried to compile libfaad2 without optimizations flags with 2 gcc versions (4.0.3 4.1.1), that don't work
and that don't work also with the last build of videomixer9 (ffdshow-20060519-rev2546-icl91.exe), the last celtic druid build.
This sample works great with the internal aac mpc decoder

[videomixer9]

it indeed has problems with both realaac and libfaad ... it works fine in winamp e.g. this must have to do with the code.

Well e.g. this is fucked up http://www.mplayerhq.hu/MPlayer/samples/A-codecs/AAC/faad2-fail.mkv too ... guess I lookup mplayer archives for a fix before posting a bug report or try to acquire some other versions of the code that already has the real entrypoints needed for ffdshow.

used a dll from rarewares.org and it has the same problems, so the error must be somewhere in the ffdshow code.

[dk75]

clsid svn2546 MSVC71/GCC345 and no problem with this faad2-fail.mkv when using realaac, libfaad2 or CoreAAC.
But you should download "[Shinsen-Subs] Ergo Proxy - 06 [H264 AAC].mkv".
It have AAC/MPEG2/SBR-LC audio stream that crash libfaad2 on this clsid build and report audio to be 6ch 96kHz (it is 6ch 48kHz) and playback in slowmotion with CoreAAC (build upon faad2) or with mplayer.
But encodes of earlier episodes with AAC/MPEG2/SBR-LC audio stream plays fine.

[videomixer9]

The example was fucked up before but now it plays back fine too, must've been some sideeffect or I mixed it up with another example, hm. It's an older failure thing too, ah whatever. Will try the shinsen release.

Try to enable 32bit output mode with the shinsen release, works for me then oddly, otherwise it's just silent, it shows bitrate etc. though properly and all other infos. CoreAAC doesn't work either, it sometimes has some sound, MPC internal AAC decoding is also mostly just silent.

[Paul Oblomov]

I'm a BuG Man ;)

[Bathrone]

ffdshow-20060519-rev2546-icl91.exe - Crashing on explorer.exe from libavcodec.dll since installing WMP 11 BETA each time Im playing back avi's containing xvid video.

[foxyshadis]

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.
64bit build? 3dnow? o.O Everything's crashing from trying to execute prefectw now (a 3DNow!/x64 instruction). Anything change lately?

Last version to work correctly is 20060513, as far as I can tell. Which is bizarre, because I'm sure I was using 5/17. Huh, guess not.

[issa]

Rev. 2546 GCC OPTIMIZE FLAGS test build, -fforce-addr removed;

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

Compiler: GCC 4.1.1 (All Files build by GCC)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20908884/ffdshow-2546-gcc-sse2-20060520.exe.html)

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20908693/ffdshow-2546-icc-sse-20060520.exe.html)

Please someone help me to test if the optimzie flags help to improve speed, and also if it break any part of ffdshow.

[videomixer9]

Sounds like the ffdshow-20060519-rev2546-icl91.exe build actually got some 3dnow instructions in it, if it does I don't really care as I give shit about Intel processors, I won't fix that :p KernelDeint crashing from 3dnow would be odd though cause ICL doesn't generate 3Dnow code.

And Xvid and WMP11 beta runs fine here so I bet you got an Intel too.

[Episode]

Ahem.. still there's no need to be extremely rude for those who do use intel processors.. and please try to keep your language clean :D

[videomixer9]

Your fault buying processor from a company that needs to rig tests to win, use stupid cpuid checks instead of trying to built a decent FPU unit which is specially useful for this kind of thing.

Intel buyers mostly fell for the stupid marketing of a big company that cannot get around the fact that their processor designs cannot compete fairly against others.

You see their fear of AMD and others everywhere, e.g. with 3DNow! units, in certain cases using them kicks Intels ass so much that they will buy up any tester trying to use special 3dnow! code. Intel's old style 387 FPU even sucks so much that most people tell you to stay away from using it nowadays ... kinda sad for a company fussing all about their new processors coming soon that will suck again but win rigged tests in integer competition but horribly lose in most FPU tests while costing twice the money.

[foxyshadis]

Well yes, that's why I mentioned that it was a 3dnow instruction; it's a core duo. At least label current builds non-intel. Oh well. (lol @ using ICL to generate amd-only code, even if it is GCC or inline that does it.)

The instruction is during the lavc initialization, so anything using it is affected, no matter what filters.

It's also an official amd64 instruction now though, which is why I wonder if it didn't get accidentally compiled as a 64-bit build. (Not supported on em64t, oddly. Then again, an SSE instruction does the same thing. Could be a preprocessor define on the new deint update that bases its value on the march.)

btw, did you update with kerneldeint, or leakkerneldeint?

Edit: AMD's architecture is still only slightly less broken than Intel's current, from the high view. Yes, its native x64 functions better and it has a better memory controller, but it's as stuck with the legacy crap as Intel is, and even transitioning to 64 only drops some of the problems. Comparitively, power and solaris are significantly better architectures, although you end up with the exorborant cost (and ibm's recent mis-development of power, leaving other companies to do its job better). Altivec has shown to be stronger than any of the x86 simd extensions, when given a good compiler or asm guru.

[videomixer9]

3dnow! and 3dnow!ext should be the same in 64bit and 32bit only processors from AMD. It works all fine on my Athlon-XP. I didn't update with anything external.

Altivec as superior tech made me wonder the most about Apple changing to Intel, must've been enough money involved besides IBM being to slow on delivering new versions, though xbox360 makes you wonder about that too. Problem is x86 to some other tech is a hard change to do, even though I think that MS e.g. could magically come out with a Windows for PowerPC and others as they got such versions in the past already, Linux e.g. supporting other tech anyways.

However AMD does way better standard x86 design, their 64bit clou included. Their regular FPU is way better.

[Alante]

I don't get it,...why didn't he fixed "Error while registering FFDshow.ax" I have their latest build FFDshow 2006.05.13 rev2546,..:(

[LoRd_MuldeR]

I don't get it,...why didn't he fixed "Error while registering FFDshow.ax" I have their latest build FFDshow 2006.05.13 rev2546,..:(

Reading the instructions might help :rolleyes:

vcredist_x86.exe (runtime libs needed for these builds to work)

[Bathrone]

While I appreciate your efforts Videomixer9, I think the builds should be labelled as AMD only if thats the way it is.

Yes, Im using an old Northwood P4.

If your going to not address this problem it will leave a gap for all Intel users to find other builds with the same performance and patches.

[issa]

If I remember right, Intel build a faster FPU unit then AMD.
However, on recent AMD CPU, ie 64bit CPU, it have the fastest vectorize unit. Therefore, using SSE2 for FP operation on AMD 64bit CPU should be faster than using FP operation.
Just for information, using SSE2 for FP in GCC, ie -msse2 -mfpmath=sse, will product code pass "Kahan's Floating Point Test".
MSVC, ICC produce code that not pass all the "Kahan's Floating Point Test" when turn on optimize flag, ie -O1 -O2 -Ox.
MSVC produce code pass all "Kahan's Floating Point Test" when turn off optimize flag or turn on optimize flag with "-arch:SSE2".
Intel compiler will produce code pass all "Kahan's Floating Point Test" when turn on "-Op" flag.

[bitcore]

I agree with Bathrone, I too use an intel in my primary computer. At the time, I built this for low power consumption to go in a car, now it's my primary machine. My laptop is an intel chip and with most all laptops you have no choice what chip goes in it.

I too am a firm believer in AMD as the best price per preformance chip maker, my main server has an old 1800+ in it for example, but not all computers use an AMD chip. I see no reason to start a chip war with FFDShow builds, if you want the builds to be AMD only, label them as such so people who have an intel chip who don't care or who own a mixed goup of computers wont run into headaches like I did....

The 5/05 build that I got from free-codecs.com crashed my machine and locked it up with a garbled display. I lost work when that happened and it pissed me off. Just letting you know.

[Bathrone]

For those with Intel cpu's, the work Issa is doing is top notch. Im using his following build:

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2

Great stuff Issa, all works mate

[foxyshadis]

The 5/05 build that I got from free-codecs.com crashed my machine and locked it up with a garbled display. I lost work when that happened and it pissed me off. Just letting you know.
Do you have up-to-date video drivers? Or Win98? A codec or even a media player should never be able to take down 2k/xp like that, unless perhaps it was set on realtime priority, but even that wouldn't matter for a straight crash.

[videomixer9]

He just made up that crash anyways to try and pressurize me cause he was so stupid to buy an Intel processor :p Though I'd also maybe recommend Intel user issa's build, he seems to also optimize nicely, not like I'm in a war to gain as much users of my build as possible.

[Livesms]

Rev. 2546 GCC OPTIMIZE FLAGS test build, -fforce-addr removed;

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

Compiler: GCC 4.1.1 (All Files build by GCC)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20908884/ffdshow-2546-gcc-sse2-20060520.exe.html)

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20908693/ffdshow-2546-icc-sse-20060520.exe.html)

Please someone help me to test if the optimzie flags help to improve speed, and also if it break any part of ffdshow.

Nothing of this are'nt working on my WinXP SP2

I cant play no video - "Error - like codec not installed".

[breez]

Aspect ratio setting in 'resize & aspect' seems to be in effect always even if the 'resize & aspect' isn't enabled. Is this a bug or desired behavior? Using a rev 2546 compile (by who? can't remember).

[videomixer9]

a bug that's in ffdshow since longer already iirc, it's not always like that but appears under some random conditions.

[Episode]

He just made up that crash anyways to try and pressurize me cause he was so stupid to buy an Intel processor :p

Now could you please stop this. You have absolutely no right to call anyone stupid because of their choice of processor, everyone has a freedom to do what ever they want with their money.

I did notice that smiley on the end of that sentence, but it really didn't feel like a joke since you are just making people with Intel processors very unhappy with those comments.

Just label your builds with AMD only tag and everything will be fine again, don't use this thread to start another Intel vs. AMD war.

Thanks.

[issa]

Nothing of this are'nt working on my WinXP SP2

I cant play no video - "Error - like codec not installed".

Did your CPU support SSE at least?
If so, I assume uninstall the previous ffdshow before install the
new one. Sometime we need to reboot the system after uninstall
the ffdshow because the ffdshow.ax still lock by the system in
some resone that I don't know. Please try reboot your system
after uninstall the old ffdshow before install a new one if you
find an error message that said cannot write the file ffdshow.ax
or msvcr8.dll.

[videomixer9]

Intel whiners edition - here (http://bittekeinspam.googlepages.com/ffdshow-20060521-rev2546-icl91.exe) (yeah I have pity for crybabies and they may have fallen for intel rigged tests after all, poor creatures)

And after all which company started e.g. with loser behaviour like cpuid checks ...

[Nic]

@videomixer9: Keep your posts polite and cut out the swearing or you'll be striked.

@all: Enough about Intel & AMD now. Keep thread on topic, or it will be closed and offenders striked.

@Episode: Good posts. Thanks for trying to keep the peace.

-Nic

[obieobieobie]

Thank you, Nic.

[Lemonzest]

whats diffrent in the whiners edition?

[videomixer9]

It may run on Intel processors if ICL didn't break things on it's part again like it did before with auto parallelization which runs independant from any checks but crashed on Intel processors but worked fine on all others. If a current build runs fine no need for any updates. h264 you lose upto 2-3fps on high profile 720p decoding with this build just by changing from AMD to Intel profile @ Athlon XP 3000+ e.g.

[bob0r]

@videomixer9

Can you explain to me how i can fix DTS audio for the latest ffdshow revision?

I want to host a SSE and SSE2 on my page and i am tired of waiting for Milan :p

(also any other needed fixes/patches if possible please)

[videomixer9]

I didn't do much but replace the sources with the one from the libdca project on videolan.org found at svn://svn.videolan.org/libdca/trunk/libdts.

It may actually be a step back but at least that code properly works on anything I tested.

In parse.c at the very end you find a function named getVersion added to the code, copy that function and recopy it to the parse.c of the checked out code that you use to overwrite the code of libdts in ffdshow source tree.

I didn't really analyse what is broken, probably just removing the changes from with the dscaler merge would've been enough.

However, here (http://bittekeinspam.googlepages.com/dts.patch) is a patch you can apply to the libdts dir.

Only other patch is 6ch vorbis thing here (http://bittekeinspam.googlepages.com/ffdshow_vorbis6ch.patch), accuracy patch from kurosu here (http://bittekeinspam.googlepages.com/ffdshow_accuracy.diff), updated multithreading patch is on sf.net (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491). GCC params are everyones own buisness though current one for me is here (http://bittekeinspam.googlepages.com/ffdshow_gccoptimization.diff) and runtime cpudetect just a preprocessor added which doesn't do much anyways. No clue on the LPCM problem.

[Avish]

Just out of curiousity I did this small comparision:

No PP & no other filters are on,
VMR9 Renderer,
CPU= 1.91Ghz Athlon XP 2600+

Sample
Video: DivX5 656x480 29.97fps 1005Kbps [Video 0]

Results:
Milan's ffdshow-20041012-sse:
User: 11s, kernel: 11s, total: 23s, real: 29s, fps: 85.8, dfps: 67.9

VM9's ffdshow-20060519-rev2546-icl91:
User: 11s, kernel: 11s, total: 23s, real: 29s, fps: 86.7, dfps: 67.4

Issa's ffdshow-2546-gcc-sse-20060520:
User: 11s, kernel: 11s, total: 23s, real: 30s, fps: 85.7, dfps: 65.6
Interesting results!!

[bob0r]

@videomixer9

Thanks! It worked.

ffdshow-2546-gcc4.0.3-sse-x264.nl.exe
ffdshow-2546-gcc4.0.3-sse2-x264.nl.exe

are now both hosted on x264.nl.

For now i'll do updates manually, as ffdshow development is not changing that much that i can't keep up.

[_xxl]

http://rapidshare.de/files/21101285/ffdshow-20060522.exe.html

[videomixer9]

Just out of curiousity I did this small comparision:
[...]
Interesting results!!

SHOCKING! I was so shocked I fiddled a bit around and got ready a 1337 speed edition! (mirror (http://www.filepoint.de/download/4711-dl-ffdshow-20060522-rev2546-sp33d1337edition_exe), mirror (http://www.load.to/?d=cVLr1pW1Tg))

If this here (http://bittekeinspam.googlepages.com/ffdshow-20060522-rev2546-sp33d1337edition.exe) is slower than the previous builds I'm going to cry!

milan 20041012-sse
User: 80s, kernel: 0s, total: 81s, real: 90s, fps: 433.3, dfps: 389.4
milan 20051129
User: 77s, kernel: 0s, total: 77s, real: 86s, fps: 453.7, dfps: 407.9
my own 20060519 amd:
User: 74s, kernel: 1s, total: 75s, real: 83s, fps: 466.3, dfps: 422.3
sp33dedition v2 :p
User: 73s, kernel: 1s, total: 74s, real: 81s, fps: 471.2, dfps: 430.8

puh ... save. slight glitch in the first try.

[Egh]

SHOCKING! I was so shocked I fiddled a bit around and got ready a 1337 speed edition!

If this here (http://bittekeinspam.googlepages.com/ffdshow-20060522-rev2546-sp33d1337edition.exe) is slower than the previous builds I'm going to cry!




The bandwidth limit for this site has been exceeded.


I guess you need a better hosting or prooly mirroring releases on rapidshare or whatever :)

I can open the main page but attempt to download any binary atm leads to that nasty message.

[Kostarum Rex Persia]

I guess you need a better hosting or prooly mirroring releases on rapidshare or whatever :)

I can open the main page but attempt to download any binary atm leads to that nasty message.

Yes, you are right, same massage shows to me.

Not rapidshare, please:scared: Use megaupload or mytemdir, videomixer9.

[Avish]

No PP & No Filters used,
VMR9 Renderer,
CPU= 1.91Ghz Athlon XP 2600+,

Sample Video: DivX 5 720x560 25.00fps 1151Kbps

Results:
Milan's ffdshow-20041012-sse:
User: 8s, kernel: 9s, total: 17s, real: 19s, fps: 55.8, dfps: 50.8

VM9's sp33dedition:
User: 7s, kernel: 10s, total: 17s, real: 19s, fps: 57.4, dfps: 51.5
BTW VM9, how do u get such high fps? Can u please post all the related specs?

OK. Me too got high fps when I used smaller resolution video sample. XVID 352x208 25.00fps 1564Kbps.

User: 1s, kernel: 0s, total: 1s, real: 5s, fps: 446.9, dfps: 143.0So now it leavs dfps... can anyone explain?

[videomixer9]

I use null renderer cause I don't want to test how fast Microsoft renderers are, besides they always end up framelimited here, the test video is xvid 640x352 23.98fps. It's a 24 min thing though and I use this lower res to have more gap in fps to not get into having too less difference to see if just something was suddenly active in the background.

Stupid google, but porbably too many warez turds used it again, eh?

[Avish]

I use null renderer cause I don't want to test how fast Microsoft renderers are, besides they always end up framelimited here, the test video is 640x352 23.98fps. Stupid google, but porbably too many warez turds used it again, eh?OK, that explains it.

Another thing I wanted to ask u is that with Milan's build I get this http://img90.imageshack.us/my.php?image=sbuild4ic.jpg
And with ur builds I get this http://img90.imageshack.us/my.php?image=sbuild1bk.jpg
Look at the buttons, slider bars, drop down arrow etc. See the difference? What's causing it? & What should be done to fix it?

Strange! When I open it through MPC, all the buttons are skinned nicely, but when I open it through Start->ffdshow->video decoder configuration, all the buttons are flat again.

[videomixer9]

I removed the external manifest from the installer as one should be embeded, however that one makes the styles go old style somehow. guess I should include it again or adjust the included one as it seems there is some adjustments to be made to make it look new style. Just copy the external manifest and it should look styled again. You don't need to uninstall other builds when installing another btw.

[Avish]

I removed the external manifest from the installer as one should be embeded, however that one makes the styles go old style somehow. guess I should include it again or adjust the included one as it seems there is some adjustments to be made to make it look new style. Just copy the external manifest and it should look styled again. You don't need to uninstall other builds when installing another btw.ffdshow folder already have one "Microsoft.VC80.CRT.manifest", anyway I copied one from another folder & put it in ffdshow folder. Now should I name it "ffdshow.ax.manifest" to work properly?

OK. renaming it "ffdshow.ax.manifest" works fine. All is skinned nicely.

Hmmm. It isn't working when VFW configuration is opened.

OK. Prob solved. First I installed older build which workd OK, then I installed your build over it & now everything is skinned properly.

Thanks.:)

[videomixer9]

I meant ffdshow.ax.manifest and not renaming the microsoft runtime manifest, well you got it anyways now :p The manifest seems to include some infos about the common dialog controls to be used, with this info missing it uses another version it seems which results in no skinning, next builds I'll include the original manifest again, though this isn't really a major issue, but the manifest isn't large anyways.