New ffdshow build (?)

[Sharktooth]

it doesnt crash on my box, but produces weird artifacts.
i use the latest CD build though.

[Egh]

My observations on recent builds:

1. GCC plain build -- slow as t3h hell. I don't know what kind of magical system you have, b0b0r, but on same CPU i have tremendously slowed down playback of AVC even w/o resizing (on VMR9 ofc, and *RGB*, not YV12 output).

2. b0b0r's ICL+gcc is not _that_ bad. But seems in highly CPU intensive operations, it still sucks. One of those high-CPU-eater operations is software resizer. I.e. with that build i can't actually get non-drop-frame playback even on 640*480 xvid encoded video resized to 800*600 by lanczos in ffdshow :)

3. Last celtic build == t3h win. That's the one which doesn't slow down in all my tests done. I don't know why exactly, but that's the truth :) IIRC movax builds (msvc ax + gcc dlls) are similar in speed too.

[movax]

MSVC .ax + GCC DLLs do seem to work the best. Trying to find my ICL7 (and then upgrade version ICL8->ICL9 :P) to see what happens with ICL .ax + GCC DLLs.

[Kurosu]

The following only happens for gcc.

1) To allow building for non-SSE2 computers, -msse2 must be removed from CFLAGS; but then gcc builtins for SSE2 are undefined, leading to errors whenever those are used. As a consequence, SSE2 code has to be inhibited through defines
2) But then, if you have a SSE2-able computer, and some code is left activating the (now-empty) SSE2 functions, you get of course garbage at the output
3) Inhibiting code through ifdef's is a tedious and boring work; therefore SSE code was not inhibited, and -msse flag left. This yields a build where SSE opcodes are used (much like SSE2 when -msse2 was used) and therefore K6, Pentium 2, first Athlon/duron and weird CPUs are not supported. This is not going to be fixed, not only because of the boring task but also because it clutters source code.
4) All code accessing MSVC-compiled binaries (ie Avisynth or any dll using MSVC C++ ABI) just won't work and has to be converted to a C equivalent, if any, or get deactivated. Therefore ffavisynth.dll and the avisynth processing filter are not working and will just crash. You can't use either a MSVC version of those because, again, ABI are incompatible.
5) (update) btw, the sluggishness in some dlls is due to gcc not inlining builtins, but actually making function calls out of them. You hardly get slower.

[Inventive Software]

@Celtic_druid: Thank you SO much!

For the record, I'm gonna try compiling ffdshow entirely with GCC, and with ONLY SSE enabled, thus making it work on my CPU without much trouble (hopefully!)

[clsid]

Here is another build:
http://www.megaupload.com/?d=5HWWOXB0

libavcodec.dll and mplayer.dll are compiled with GCC 4.0.2
everything else with ICL9

[bob0r]

@Kurosu
Very intesting, maybe someone will be up to do the hard dirty work for old and new cpus.
Any recommendations about how files should be compiled to reach the most people?
Also if you had to advice the ffdshow developer(s), what would your advice be?

@celtic_druid
When you get a fresh CVS source, can you explain to us, step by step, what actions you take, what files you edit, and what possible (directx) header files you use? Then how you edit some files and ofcourse how do you compile your ffdshow builds, like what settings and optimizes, if any.

@all
Blur & NR > Denoise3D and HQ crash icl/gcc
fixed HQ denoise3d crash > http://cia.navi.cx/stats/project/ffdshow/.message/6073914
Comment by Milan: "Fixed."

ffdshow/about/version details crashes (gcc 4.0.2)
http://sourceforge.net/tracker/index.php?func=detail&aid=1329122&group_id=53761&atid=471489
Comment by Milan:
"I think it crashes on Avisynth version check. ffdshow invokes
VersionString command, but avisynth C++ interface is
incompatible with GCC."

This may be fixed in the future hopefully, but it's not that bad we can't use this :o

[celtic_druid]

Currently I am running Microsoft DirectX 9.0 SDK (October 2005) which doesn't include dshow and isn't supposed to install on win2k and 2003 SP1 Platform SDK (or was it the PSDK that isn't supposed to work with 2000?).

[bob0r]

Currently I am running Microsoft DirectX 9.0 SDK (October 2005) which doesn't include dshow and isn't supposed to install on win2k and 2003 SP1 Platform SDK (or was it the PSDK that isn't supposed to work with 2000?).

Okay...... some more info about how you use them (like i did in some above thread), or are you saying October 2005 header files should speed up ffdshow a lot over Summer 2004? (I btw got the latest platform sdk installed, any reason i should use those for building ffdshow, if so, how?)

[celtic_druid]

Well the reason I am using it is because the DX SDK for Oct doesn't include dshow.
I think the reason for the speedup is ICL9 although gcc with cpu specific flags could maybe beat it. It can for libavcodec anyway.

I compiled everything with ICL9 except for mplayer and part of libavcodec.

[cc979]

just tried 02dfe422f480810944852f55dea8db83 *ffdshow-20051018.exe xvid/x264 decode is very slow compared to 52e5e5a5008760ecfbedbd209f964182 *ffdshow-20051015.exe

i have nforce2 ultra mobo with an athalon2400

[Kurosu]

@Kurosu
Very intesting, maybe someone will be up to do the hard dirty work for old and new cpus.
Even if someone was, I think Milan would not like to do this, because of the code bloat. Anyway, it's just too much of a mess: gcc doesn't make the difference between mmxext and sse, so builds can only be plain MMX using intrinsics. But I did try this, and gcc was generating goofy opcodes (movl $0, mm0 in h264 chroma loop filter). It's a pity, because that code may not be used in the end because of CPU detection.

Fixing by not using compiler defines would require to undo most of the templatization, which is certainly not something Milan would bother to do now that the code is templated.

Any recommendations about how files should be compiled to reach the most people?
Milan chose the intrinsic way because gcc, icl and cl are able to understand it (producing optimized code from it is another matter). But gcc is geared towards targeted builds. In that end, using only gcc to build the most compatible software yield builds that have to use the lowest common factor: sse. Otherwise, it's just a matter of what assembly syntax is used that should determine the compiler to use.

Also if you had to advice the ffdshow developer(s), what would your advice be?
I'm already discussing with Milan. The non-SSE2 fixes are based on a patch I made that proved it was feasible. But I never went through testing all filters.

"I think it crashes on Avisynth version check. ffdshow invokes
VersionString command, but avisynth C++ interface is
incompatible with GCC."
That's one of the last, most obvious, gcc-compatibility fixes needed. Fixing makeAVIS was an incentive and an example on how to do this. Milan has particular plans on this subject, though. Time will tell.

[bob0r]

@celtic_druid:
Yes i understand WHAT you use to compile ffdshow, BUT how, unless its some secret please share with us how you compile your builds, with as many details as possible.

Because some people are saying my ICL builds are slower than yours, when we both use ICL9.

It could be indeed the different DX SDK files, but, not including dshow, what benefit does this have?

When you say you partly compile libavcodec.dll with gcc, what do you do?

People have asked you this already, i think its time for the ultimate-celtic_druid-guide :D

@Kurosu

Understood and thanks.

[bob0r]

just tried 02dfe422f480810944852f55dea8db83 *ffdshow-20051018.exe xvid/x264 decode is very slow compared to 52e5e5a5008760ecfbedbd209f964182 *ffdshow-20051015.exe

i have nforce2 ultra mobo with an athalon2400

gcc = gcc 4.0.2
msvc = msvc 7.1

ffdshow-20051015.exe = (all files gcc, except ffdshow.ax and ff_vfw.dll are msvc)
ffdshow-20051018.exe = (all files gcc)

I was told ffdshow.ax (and ff_vfw.dll for that matter) only are a frontend for the encoders/decoders.
If i am wrong, i am sure the experts will correct me.

So this may be caused by possible libavcodec.dll updates, between 15 oct and 18 oct ( http://cia.navi.cx/stats/project/ffdshow )

Maybe someone with a CPU like yours can test this too.

I must have some weird system, all versions, all combinations, all just play very smooth!

[videomixer9]

CPU usage on 20051018 is low for me with h264, no difference to the celtic builds. I have nForce2 Ultra 400 1024 MB DDR333 Dual Channel with AMD Athlon 3000+ (Barton), GeForce FX 5600, WindowsXP and tested with Zoomplayer with Overlay Mixer (not using VMR9 because of nasty Luma Shift and various other reasons like high cpu usage for not better quality :), my name may suggest I do the exact opposite hehe). Xvid performance is quite good too and not much different from what I saw with the latest celtic_build.

[NoX1911]

not using VMR9 because of nasty Luma Shift and various other reasons like high cpu usage for not better quality :)Enable 'Color Controls' in Zoom Player and leave to standard values. Picture (luma) is exactly like Overlay Mixer after that. I hate that Luma shift as well (0-255 <-> 16-240). Maybe has something to do with TV luma restrictions. 'Color Controls' are finally working in every situation in latest Zoom Player (i think).

Back to topic:
Is there any way to determine exact speed variations between different ffdshow builds, some kind of benchmark or something? Maybe a huge template benchmark video (2048x2048x30fps) that should stress even the biggest cpus and ffdshow is counting/logging fps so ppl can compare results? I mean.. better than just 'feeling' the difference...

[cc979]

bob0r:
i've re-test the builds
52e5e5a5008760ecfbedbd209f964182 *ffdshow-20051015.exe
e0983d0fdaee4d123abcd57ee379d61b *ffdshow-20051017.exe
02dfe422f480810944852f55dea8db83 *ffdshow-20051018.exe

using the latest mpc using hardware-overlay with a xvid-file

all these builds work fine when post-processing is off (cpu 25%) but
spp deblocking cpu usage (cpu 85%) is a lot more with ffdshow-20051017.exe and ffdshow-20051018.exe

i could test more if you want.

[cc979]

just tested build:
866c5aca7188f9040f28e6408c6eb4e0 *ffdshow-20051017-clsid.exe

spp deblocking is ok on this

[Blkbird]

I've got a similiar 100% CPU problem with the 20051018 (02dfe422f480810944852f55dea8db83) build, even without SSP deblocking.

Computer config: Athlon 2000, Windoes XP SP2, Radeon 9000, Catalyst 5.8.

Playing 1000 kbit/s XviD, CPU goes about 100% with my regular postpocessing options: Presets highest auto, Strength 100%, Method mplayer accurate luma full range, Nic's 20*40.

When I deselect Nic's CPU goes back to around 20%.

With 20051015 (52e5e5a5008760ecfbedbd209f964182), CPU is about 35% even with Nic's.

[NoX1911]

If you want to benchmark more seriously...

- enable 'OSD' with 'CPU load' and 'Save to' option
- Play your video
- open the resulting .csv file in excel
- insert =AVERAGE(A:A)*100 in field B
- repeat this under same conditions with different ffdshow builds and compare the results

Restart player or re-open file (eg. drag&drop) to reinitialize ffdshow to reset statistics. Stopping/restarting same video still uses same statistic file.

[Liisachan]

for instance:
buildA gives the max CPU load 90%, avarage CPU load 85%
buildB gives the max CPU load 100%+ (unusable), avarage CPU load 80%
If you really mean it, don't blindly calclate the avarage

[clsid]

Another benchmarking method is to take a short clip, lets say about 3 minutes. Open your taskmanager. Play the entire clip and note the CPU time consumed by your player. Close the player. Replace some files (or the entire build) and repeat.

[Leak]

Because some people are saying my ICL builds are slower than yours, when we both use ICL9.
Could it be that those people are using AMD CPUs? If so, you should probably have a look at this (http://yro.slashdot.org/comments.pl?sid=155593&threshold=5)... :(

np: Thomas Fehlmann - Hana (Lowflow)

[clsid]

The GenuineIntel check can be patched. I posted a link for it a few days ago.

[cc979]

i've tested ffdshow-20051015-icl.exe (65c727897c98792b70154603ea09e6c4), it just crashes

ffdshow-20051015.exe (52e5e5a5008760ecfbedbd209f964182) does'nt use ICL but it works best for me

ffdshow-20051018.exe (02dfe422f480810944852f55dea8db83) is all GCC but it does not work as good as ffdshow-20051015.exe

bob0r have you tried compile all files gcc, but use ICL for ffdshow.ax and ff_vfw.dll ?

[bob0r]

...
bob0r have you tried compile all files gcc, but use ICL for ffdshow.ax and ff_vfw.dll ?

My goal is to make a full GCC build of ffdshow, so it can be compiled on a weekly bases and on demand.

I dont think using ICL ffdshow.ax and ff_vfw.dll should speed things up, meaning if they do, something must be broken with the gcc versions.

So if a ICL/MSVC ffdshow.ax (ff_vfw.dll) will speed things up, i will report this as a question/bug.
But maybe some readers can shed some extra light on this.

Even msvc ffdshow.ax + the rest gcc, does not speeddown, while generally msvc is very slow. For now i am focussing on GCC only, but i guess i can make some ICL/MSVC files in the future, but compiling with ICL takes very long and you need to add linkers in ffdshow, which is kind of annoying.

Speaking of gcc and fixed:
it's crashes when opening "version details" window.

release avisynth_c environment > http://cia.navi.cx/stats/project/ffdshow/.message/6086170
Seems it got fixed, its not crashing me for.

Compiled a new TEST build, all files gcc 4.0.2

http://cia.navi.cx/stats/project/ffdshow (last = 13:58 on Oct 19, 2005)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051019-test.exe (78ff930250380514ec36e8e9b92e2f0d)

[Inventive Software]

Right, at the risk of sounding completely dumb: Is ICL free?

[cc979]

bob0r
sounds a bit compilcated, do you compile the GCC stuff on linux enviroment?

but keep up the good work

[lazyn00b]

Recent builds of FFDshow (audio) cause MCE 2005 w/Rollup 2 to crash when decoding MP2 and AC3. 20050930, 20051013, and 20051015 are all affected with this problem. 20050822 and 20050920 still work fine.

Did something change in the audio decoder code between 9/20 and 9/30?

EDIT: I should mention that it's just the Media Center app that crashes, not the whole OS. I am running a Pentium D 820 (2 x 2.8 Ghz) with 1 GB of memory and my sound card is on-board Realtek ALC882 (Intel HD Audio).

[vortex_hl]

@bob0r
All .txt files in ffdshow directory are incorrect at your builds. No problem on CD and clsid ones.

http://img22.imagevenue.com/loc54/th_507_ffd.jpg (http://img22.imagevenue.com/img.php?loc=loc54&image=507_ffd.jpg)

[Egh]

@bob0r
All .txt files in ffdshow directory are incorrect at your builds. No problem on CD and clsid ones.


http://img22.imagevenue.com/loc54/th_507_ffd.jpg (http://img22.imagevenue.com/img.php?loc=loc54&image=507_ffd.jpg)

heh, i was mentioning that couple of days ago, but CR/LF are stil broken :)

[cc979]

bob0r:
just tested the ffdshow 051019-test.exe (78ff930250380514ec36e8e9b92e2f0d)
everything works smooth when postprocessing is off
i tested the deblocking functions on there own found that the luminance deblock(h) is using a lot more than usual on my system.

do you know if there was any recent changes with the standard deblocking code?

[movax]

Right, at the risk of sounding completely dumb: Is ICL free?

Nope, the Intel Compiler costs a pretty penny.

[NoX1911]

Anyone able to enter negative delay values in audio decoder? Seems that only positive values are accepted... Maybe i'm wrong but wasn't it implemented already before?

[bob0r]

bob0r
sounds a bit compilcated, do you compile the GCC stuff on linux enviroment?

but keep up the good work

Windows XP Professional, Service Pack 2 (5.1 - 2600)
Mingw/msys is what i compile on. (same for x264 builds)

@bob0r
All .txt files in ffdshow directory are incorrect at your builds. No problem on CD and clsid ones.

http://img22.imagevenue.com/loc54/th_507_ffd.jpg (http://img22.imagevenue.com/img.php?loc=loc54&image=507_ffd.jpg)

heh, i was mentioning that couple of days ago, but CR/LF are stil broken :)

I don't have it this way, maybe CD and clsid can explain to me what i should do (if its not ffdshow.ax being icl and not gcc as in my case)

bob0r:
just tested the ffdshow 051019-test.exe (78ff930250380514ec36e8e9b92e2f0d)
everything works smooth when postprocessing is off
i tested the deblocking functions on there own found that the luminance deblock(h) is using a lot more than usual on my system.

do you know if there was any recent changes with the standard deblocking code?

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

Have a look for yourself, i will make some ICL/MSVC ffdshow.ax (and ff_vfw.dll) files later, maybe the cause is there.

Anyone able to enter negative delay values in audio decoder? Seems that only positive values are accepted... Maybe i'm wrong but wasn't it implemented already before?

Good question, ill test this later on aswell :D

[vidhead]

Windows XP Professional, Service Pack 2 (5.1 - 2600)
Mingw/msys is what i compile on. (same for x264 builds)


i've read and followed your guide/steps (above) to compile ffdshow with mingw/msys on winxp...but it's not working out. i'm either too dumb or too busy or both, please do a detail breakdown of steps, no matter how trivial too.

[celtic_druid]

Not working out? What exactly does that mean? Compiled, but doesn't work? Won't compile? If you can give details about what isn't working then it should be possible to do something about it.

[Liisachan]

ffdshow-20051019-test.exe is too slow for me when I play an ordinary xvid clip with VMR9 renderless + ffdshow-side RGB32 output. The problem is gone with default (YUY2) color spaces.

The same problem exists in ffdshow-20051017.exe and ffdshow-20051018.exe

The last good for me is celtic_druid's ffdshow-20051013.exe

[Inventive Software]

Nope, the Intel Compiler costs a pretty penny.
At a guess, the pretty penny is likely to break the bank balance, right? I.E, more than £200

[clsid]

The linux version of ICL is free. For Windows there is an evaluation version.
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/index.htm

[Sharktooth]

are you sure linux compiler is free? http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219937.htm

[dimzon]

Does anybody tried Open Watcom C++ Compiler (http://www.openwatcom.org/)?
Watcom C/C++ compiler v 10.x was THE BEST C/C++ compiler in the middle of 90's. Wide range optimization etc...

[Leak]

are you sure linux compiler is free? http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219937.htm
As long as you don't use it for commercial purposes... (http://www.intel.com/cd/software/products/asmo-na/eng/download/download/index.htm)

np: I'm Not A Gun - Every Moment Is Ours (Our Lives On Wednesdays)

[Sharktooth]

Does anybody tried Open Watcom C++ Compiler (http://www.openwatcom.org/)?
Watcom C/C++ compiler v 10.x was THE BEST C/C++ compiler in the middle of 90's. Wide range optimization etc...
Yep it was widely used for games and other stuff that required performance.
However i dont know the actual status...

[dimzon]

Yep it was widely used for games and other stuff that required performance.
However i dont know the actual status...
Just test it!

[madman1980]

I'm on a nf4 + a64 and I too have the slowdown (unplayable) with SPP deblock lum H+V with version 20051018

[Egh]

ffdshow-20051019-test.exe is too slow for me when I play an ordinary xvid clip with VMR9 renderless + ffdshow-side RGB32 output. The problem is gone with default (YUY2) color spaces.

The same problem exists in ffdshow-20051017.exe and ffdshow-20051018.exe

The last good for me is celtic_druid's ffdshow-20051013.exe

I'm glad I'm not alone :)

VMR9 renderless really requires a bit more CPU. I guess some of those instructions benefit greatly from optimisation, and if a build is unoptimized then playback is slow. A sheer guess would be that here the reason is YV12-->RGB conversion, which is applied on every pixel in this mode, uses some kind of that optimisation.

Other filters, like previously mentioned software bicubic/Lanczos resizers (and SPP deblocking, as others reported) also seem to have such behaviour.

Lisachan: what DX version / video card do you have?

[Liisachan]

ffdshow-20051017-clsid.exe works fine with MPC VMR9 renderless + ffdshow RGB32 too. (Thanks clsid!!)
DirectX 9.0c (October 2005) / Quadro FX 500 / NVidia ForceWare 78.01 WHQL

[Sharktooth]

RGB... why ppl still use RGB...

[Liisachan]

Overlay has its forte, greatly, but still:
"I still feel software-side RGB32 is more beautiful, but that may be just my imagination."
"I was comparing using ffdshow with force rgb32 (high quality) output versus using the hardware (geforce 6) do the color conversion, both using VMR9. I noticed that using ffdshow gives better colors which you clearly see on bright objects, especially red objects."
http://forum.doom9.org/showthread.php?p=719923#post719923

[bob0r]

RGB... why ppl still use RGB...

Yeah, why people use filters and postprocessing anyway? Because they can? Okay okay i have a slow CPU, i admit it :o

Anyways, it seems indeed the ICL builds are the best (those who clsid and celtic_druid already used to make) speedwise, and if they dont crash, you are lucky.

I will keep by builds with GCC only, because stability goes over speed.
I mirror ffdshow as a decoder for x264. If you guys want a new ffdshow build with ICL, because of some notable updates, i guess its wise to just request it here.

Since celtic_druid, after aksing 3x, wont explain EXACTLY how he compiles his builds, you will just have to ask him for a new build now and then... which he already does.

Hopefully the source will be so updated, that compiling with gcc will be the best option, where a decoder or filter detects your CPU and acts on that, but i guess adding that to the messy source, isn't gonna be easy :)

[Egh]

ffdshow-20051017-clsid.exe works fine with MPC VMR9 renderless + ffdshow RGB32 too. (Thanks clsid!!)
DirectX 9.0c (October 2005) / Quadro FX 500 / NVidia ForceWare 78.01 WHQL

Not exactly, though clsid's build is certainly faster than b0b0r's ones. Software resizing is b0rked in that build (though I think it's due to code used, not compliation itself).

[clsid]

I will try to post an updated version today or tomorrow.

ICL uses a LOT of memory (1.3 GB just for VS/ICL) during some stages in the compilation. And with only 512 MB ram that means a swap file of 1 GB which makes compilation very slow. I guess it's time for an upgrade :P

[Egh]

Yeah, why people use filters and postprocessing anyway? Because they can? Okay okay i have a slow CPU, i admit it :o

Anyways, it seems indeed the ICL builds are the best (those who clsid and celtic_druid already used to make) speedwise, and if they dont crash, you are lucky.



Well. In fact, ppl use filtering and post-pro to increase the quality, not to increase CPU% load :P

1800+ is enough to play AVC 720*480 with softsubs in VMR9[RGB] and even with software resizing to fullscreen using Lanczos.

And, IMO, Lanczos -- b3st postprocessing ever :P Seriously, on many sources, especially old blurry rips, it makes very noticable difference. Certainly better. Recommended. No other post-pro is needed :P

About different builds -- strangely enough, but I like also movax builds. Which are probably somewhat slightly slower than celtics' ones, but no serious problems at all during playback. IIRC .ax is built by MSVC, the rest is build by gcc. But I didn't notice any serious speed difference during playback compared to let's say clsid build.

[ExtraEye]

egh,
your last comment was interesting...
I have a 3000+ and with some videos cannot resize without jerky playback.
what kind of resizing do you use with lanczos? X2?
also,
does using VMR9 make any difference for the resize? i heard it increases cpu load so i use overlay mixer.
my graphic card is geforce 6600GT.

[bob0r]

3 test builds coming up, but here is some info.
First i uninstalled DirectX SDK Summer 2004, then installed DirectX SDK October 2005. If its an update or not, compiling ffdshow (ffdshow.ax, ff_wmv9.dll and FLT_ffdshow.dll) is impossible with just the header files from Microsoft DirectX 9.0 SDK (October 2005)\Include
So i first compiled with ICL(libavcodec.dll is gcc) and then a MSVC build (all files), so when i tried to compile the gcc build, it said it had mising files, i checked with the header files from Summer 2004, and indeed a lot were missing.
So what i did was, copy Summer 2004 include, then overwritten header files from October 2005.

So the following was done:

ICL = ICL 9.0
- Open ffdshow.sln Right mouse on Solution and Convert to use Intel...
- Right mouse on a project > Properties:
Configuration Manager > Active Solution Configuration: Release, (so for all)
- Right mouse on a project > Properties (can keep open, just change project), for all projects:
C/C++ > General: Warning Level: Off
C/C++ > Command Line, added: /QaxKWNPB, (=optimize for all processors)
Linker > Input: added "libircmt.lib libmmt.lib svml_dispmt.lib" (without quotes) to Additional Dependencies
- Patched libircmt.lib ( http://www.swallowtail.org/naughty-intel.html )
- Right mouse on Solution > Build Solution, (may want to clean solution first)
Don't forget libmplayer.dll (ffdshow\src\mplayer) and libavcodec (ffdshow\src\ffmpeg) require the same steps, they are seperate projects, only libavcodec.dll will fail, yet never hurts to try.

MSVC = MSVC 7.1
- Open ffdshow.sln Right mouse on Solution > Build Solution, (may want to clean solution first)
Don't forget libmplayer.dll (ffdshow\src\mplayer) and libavcodec (ffdshow\src\ffmpeg) require the same steps, they are seperate projects.

GCC = GCC 4.0.2
First convert the DirectX SDK Lib files (Based on Summer 2004 and October 2005) (2 tips google and dxsdk_sum2004.exe, dxsdk_oct2005.exe)
Read up about complications.
Script i used:

#!/bin/sh
# Generates x86 directx9 lib files compatible with gcc

# Setup initial environment
export PLATFORM=x86
cd /d/utils/Microsoft\ DirectX\ 9.0\ SDK\ \(October\ 2005\)/
mkdir MingLib
cd MingLib
rm -f *
echo "Generating mingw libs for $PLATFORM"

## !! Remove the x86 for Summer 2004 (cp ../Lib/*.lib .)
cp ../Lib/x86/*.lib .

# Get all libs and perform conversion
export LIBS=`ls *.lib`
for lib in $LIBS
do
echo "Converting $lib..."
reimp $lib
done

# Clean out the old stuff
rm -f *.lib
echo "Done."

based on: http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6939

Then:
- Edit ffdshow/src/makefile.inc:
behind -Iacm -I../acm -Ixiph -I../xiph -Ifilters -I../filters -Imuxers -I../muxers add -I"/dx/Include" -L"/dx/MingLib" -ldx9
- Edit ffdshow/dscaler/Makefile:
behind CFLAGS+= -I. -I../src add -I"/dx/Include" -L"/dx/MingLib" -ldx9
- Edit ffdshow/src/codecs/wmv9/Makefile:
behind CFLAGS+= -I. -I../.. -I../../cygwin -I../../baseclasses -Iinclude -DSUPPORT_INTERLACE add -I"/dx/Include" -L"/dx/MingLib" -ldx9

the /dx/Include and /dx/MingLib dirs are made from:
copy Microsoft DirectX 9.0 SDK (October 2005)\Include to C:\msys\1.0\dx
copy Microsoft DirectX 9.0 SDK (October 2005)\MingLib to C:\msys\1.0\dx
( Note copied them from Summer 2004 first!! )
( C:\msys\1.0\ = mingw/msys ROOT (cd /)

Files:
http://mirror05.x264.nl/public/?dir=./ffdshow/ffdshow-20051021/gcc4.0.2 (removed sse2 optimizing)
http://mirror05.x264.nl/public/?dir=./ffdshow/ffdshow-20051021/gcc4.0.2-sse2/
http://mirror05.x264.nl/public/?dir=./ffdshow/ffdshow-20051021/icl9.0/ (missing libavcodec.dll (test gcc(best) or msvc)
http://mirror05.x264.nl/public/?dir=./ffdshow/ffdshow-20051021/msvc7.1/

Installers:
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-msvc-test.exe (all files msvc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-gcc-test.exe (all files gcc, without sse2)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-gcc-sse2-test.exe (all files gcc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-icl-test.exe (all files icl, except libavcodec.dll = gcc)

Please try an installer, and replace some files from other compilers and see what results you get.
(note ff_vfw.dll is in C:\WINDOWS\system32)

Good luck :D

Edit:
Edited "Files:" (Directory listing) links to show the x264 logo :sly:

[clsid]

Software resize is indeed a bit broken. Regardless of the compiler used.

Or is resizing only supposed to be applied correctly after restarting the player?

[Liisachan]

bob0r, you are really great! Thanks so much for you exhaustive (extensive) works!
And that RGB32 problem is solved at least in ffdshow-20051021-icl-test.exe (the problem is still there in ffdshow-20051021-gcc-sse2-test.exe). I'll report more if I find anything interesting. The files are mirrored here (http://ffdshow.faireal.net/ffdshow-20051021-bob0r/) just in case.
Thanks again :D

[videomixer9]

As the CPU load on regular decoding wasn't much different for me I tried using postprocessing which I usally do not use. I used full postprocessing (mplayer, accurate). The ICL build really surprised me then, it went upto 50% CPU usage for this task on the same xvid file as I tried the full GCC build with, the full GCC was almost unimpressed by the postprocessing and did the job with below 20% CPU time near the original decoding performance it needed anyways.

However, software RGB32 conversion was slow as hell, and I dunno if you provide libmpeg2 in your pack too, but if used it also uses up terrible amounts of cpu time and is thus unusable, wonder if others got that too with gcc only builds.

[canuckerfan]

what's the difference between bob0r's builds and celtic_druid's builds? or is there really no difference?

[MacAddict]

Wow! Regular decoding on my XP SP2 using VMR with the ffdshow-20051021-gcc-test.exe build is about 40% faster compared to the ICL or MSVC builds. First time I've tried a gcc build and I'm very pleased with initial testing. Thanks to bob0r and all of you providing these builds!

AMD XP TB 2.1Ghz

[Egh]

Well, nice to have more builds to test.

So, *VMR9*Renderless* with RGB32 output (YV12 and YUY2 should be DISABLED in order to ensure it's really RGB!).

1. gcc-only test. Absolute underdog, same as previous gcc-only test. Playback FPS is slashed down *THREE* times. Speed doesnt' differ whenever "high-quality conversion" is enabled or not.

2. ICL9 only build. Plays quite ok.

3. MSVC plays quite ok :)

4. And now the last but not the least -- MSVC .ax + gcc .dlls -- no such behavour like in [1]. And speed is similar to ICL9 and plain MSVC.

In YUY2 mode, worth mentioning, [1] doesn't produce terrible slowdown either. Since in all cases the file was one and same (my AIR COP, 720*480 AVC @ 29.97fps), the problem lurking is NOT in decoder part of ffdshow. It's likely, as I previously mentioned, to reside somewhere in rendering/colorspace_conversions subroutines.

Damn, gotta sleep atm :) But later I'll take more tests, i hope.
The things need testing is postprocessing performance and software resizing, and also more throughful testing in YUY2 mode.

[Liisachan]

2. ICL9 only build. Plays quite ok.

3. MSVC plays quite ok :)


Same here, for MPC VMR9 Renderless + RGB32 on my P4 3.4, Win2k, playing an MPEG-4 Part2 (xvid) clip.

Average CPU load: ICL < MSVC (ICL is slightly faster)
Peak CPU load: ICL > MSVC (MSVC is a bit slower but 'stable' in the sense of 'less variation')

http://subforge.net/image/2005/20051021.png

[PatchWorKs]

...and what about encoding ?

[Zephir]

Some annoyed bug. In OSD "Remaining time" show wrong time after seeking.

[videomixer9]

I dunno if those almost daily builds are a good idea, for daily usage I still rely on celtic_druid builds.

What I wonder about is, milan announced that he won't deliver any new compiles himself untill he can build it on GCC4 iirc, this seems to be the fact now ... wonder if he'll give us an official release compile again someday ... especially as he fixed the SF website which seemed to be broken for long time now I wonder if he'll present us official compiles again someday ...

[ExtraEye]

using VMR9 with RGB conversion works for me except for some cases in which the video isn't show and there's only music.

[clsid]

My test results for the all gcc build:

Playback is b0rked and slow with VMR-9 (renderless) and default ffdshow settings. Disabling rgb32 output fixes it. No problem when using Overlay mixer or ICL build.

I sometimes get an illegal instruction error. So something is trying to use SSE or SSE2 instructions on my AMD Thunderbird (which doesn't support SSE/SSE2). Problem seems to be in mp3lib and realaac.

TomsMoComp and kernelDeint are much slower as their ICL versions.

PP: level6 + mplayer accurate deblocking + Nic
More than two times more cpu usage compared to ICL version of ffdshow.ax


General remarks:

Resizing works correctly for me when I use VMR-9, but not with Overlay mixer.

[Egh]

My test results for the all gcc build:

Playback is b0rked and slow with VMR-9 (renderless) and default ffdshow settings. Disabling rgb32 output fixes it. No problem when using Overlay mixer or ICL build.

TomsMoComp and kernelDeint are much slower as their ICL versions.

PP: level6 + mplayer accurate deblocking + Nic
More than two times more cpu usage compared to ICL version of ffdshow.ax


Try now plz that variant i noted before: leave ALL dlls from gcc build, but change .ax file into MSVC build. Would be interesting to see filters performance in this hybrid variant as well


I sometimes get an illegal instruction error. So something is trying to use SSE or SSE2 instructions on my AMD Thunderbird (which doesn't support SSE/SSE2). Problem seems to be in mp3lib and realaac.


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

Could it be that bug? If, so it's seems it's gcc specific, so special measures need to be taken upon building:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809

[Egh]

Some annoyed bug. In OSD "Remaining time" show wrong time after seeking.

Can you tell how to reproduce that bug? BTW, dont' think that forum is being often read by Milan Cutka :) So if you found a bug which is really a bug, a best place to post it is sourceforge bugtracker for ffdshow.

[Kurosu]

So something is trying to use SSE or SSE2 instructions on my AMD Thunderbird (which doesn't support SSE/SSE2)
You are already lucky: gcc builds are not meant to support non-SSE CPUs. So ffdshow barely manages on your CPU because you have MMXEXT, which is almost identical to integer set of SSE (except for pavgb <-> pavgusb and a few others).

I don't think that adding -mmmx -msse -march=athlon-tbird -mfpmath=387 to CFLAGS would help. But give it a try.

My test results for the all gcc build:
TomsMoComp and kernelDeint are much slower as their ICL versions.

Some intrinsics don't get inlined properly with stock gcc 4.0.2 includes. The intrinsic headers in lib/gcc/mingw32/4.0.2/include have to be patched so as to be declared __attribute__((__always_inline__)) __inline
That may also be problematic in some other cases. But the 2 you quoted are the ones struck the worst: when properly built, they should be around 270 and 244 respectively, while they end without the fix at around 1MB IIRC.

[cc979]

very good work, bob0r :thanks:

all tested by uninstall then install

(a) df892a0cc564d17c69568f09be6c004f *ffdshow-20051021-icl-test.exe
(b) ea71d543e31559cf955f6d6f6861fa05 *ffdshow-20051021-msvc-test.exe
(c) d608fdb7446865e94d3eddd33689521d *ffdshow-20051021-gcc-test.exe
(d) 685a2a1e85cd72f2685a872a0299e17a *ffdshow-20051021-gcc-sse2-test.exe

(d) crashed

the ICL build is the fastest with no postprocessing and SPP,
the MSVC build is was about 50% of the ICL build,
the GCC build as fast as the ICL build with no postprocessing and standard postprocessing but is really slow with SPP.

how did you build the GCC4.0.2 i get stuck at the .balign check is it better with profiledbootstrap?

[bob0r]

...

how did you build the GCC4.0.2 i get stuck at the .balign check is it better with profiledbootstrap?

I explained how i did this, but:


ffdshow_gcc.sh (without sse2):

http://mirror05.x264.nl/public/ffdshow/ffdshow_gcc.sh
1: Don't forget to edit the script to meet your paths.
2: Be sure to use the correct and full DirectX SDK files (Summer 2004 + overwrite October 2005 files is what i did)

@all
Thanks for the test results, i guess having all files as GCC but ffdshow.ax as MSVC seems the best ratio between speed and stability.
If you want a build with other compiler files, just let any of us know and i am sure we can create one for you ;)

As reply to "why so many builds", its obviously we are testing. I think we got a lot of new information and ways to test/build ffdshow.

For x264.nl i will mainly upload new builds when libavcodec.dll is updated (for x264) or when there are mayor fixes or other nice updates. (Or just once a month if we get bored :D )

[bob0r]

Horrible slow playback when you enable SPP deblocking confirmed, on my system ICL/GCC/MSVC all use 100% CPU and make using my system completely useless (TIP use a small video and turn off repeat)

Even better tip, just never use postprocessing :cool:

If anyone feels like submitting this as a bug, with more details than i know, go to:
http://sourceforge.net/tracker/?group_id=53761&atid=471489

---

My test results for the all gcc build:

Playback is b0rked and slow with VMR-9 (renderless) and default ffdshow settings. Disabling rgb32 output fixes it. No problem when using Overlay mixer or ICL build.



I can confirm these crashes, however on my system ffdshow will crash also when i use the ICL build.
Also "Disabling rgb32 output fixes it." does not change that it keeps crashing.

I am talking Media Player Classic 6.4.8.4 compiled by celtic_druid 2005.08.13 here (View/Options/Playback/Output/VMR9 (renderless).

How ever Windows Media Player 10.00.00.3646 does NOT crash ffdshow (uses VMR9 also)

So it may be a Media Player Classic bug?

---

My builds will remain gcc, as we plan on using that only, and its the best way to get bug reports and continues support for it.
Again, requests can be made for other builds.

[Egh]

I can confirm these crashes, however on my system ffdshow will crash also when i use the ICL build.
Also "Disabling rgb32 output fixes it." does not change that it keeps crashing.

I am talking Media Player Classic 6.4.8.4 compiled by celtic_druid 2005.08.13 here (View/Options/Playback/Output/VMR9 (renderless).



The only thing I still don't get: which crashes? :O

I don't have any and iirc there were no reports about that on SSE-capable CPUs.

I personally use same build of MPC, celtic_druid 2005.08.13 (the one which doesn't have XP themed controls in Windows XP :P). Didn't have any crashes with slow gcc build (it's very slow in VMR9, but quite normal in YUY2). And it works well as soon as .ax file is changed into MSVC one.

[Liisachan]

i'm not sure if this is the right thread to post this, but this is something about audio decoding options in ffdshow: if you use libfaad2 to decode AAC, PS (aacPlus v2) is ok, but if you select realaac, PS is played as mono in my test. Just for your information...

[azsd]

Celtic Druid build version 20051013

if use libfaad2 for decoding aac track which have 24khz sample rate will playback interrupted and have double tone
seems to be play at twice speed and mute half time every sencond.
use standalone coreaac or realaac in ffdshow have no problem.

[Egh]

G00D.

I reported this night the bug on bugtracker for ffdshow and milan cutka already put some changes in code to have some kind of workaround for that (3 hours ago).
CIA is d0wn though, but on http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/?sortby=date you can see those changes. So bob0r might try to build yet another gcc build :PP

Hint to bug reporters btw (azsd and others). I don't actually think Milan Cutka reads this forum branch :P At least not too often. So if you have some confirmed bug and know how to reproduce it, just post it on ffdshow bugtracker. Luckily, Milan Cutka reacts quite fast if bug is serious (causes crashes and so on).

[clsid]

I can confirm these crashes, however on my system ffdshow will crash also when i use the ICL build.
Also "Disabling rgb32 output fixes it." does not change that it keeps crashing.

I am talking Media Player Classic 6.4.8.4 compiled by celtic_druid 2005.08.13 here (View/Options/Playback/Output/VMR9 (renderless).

How ever Windows Media Player 10.00.00.3646 does NOT crash ffdshow (uses VMR9 also)

So it may be a Media Player Classic bug?
I don't have any crashes. I am using Media Player Classic 6.4.8.4 final, not a recent cvs build.

Here is a screenshot of the b0rked output:
http://img120.imagevenue.com/loc267/th_f85_vmr9b0rked.jpg (http://img120.imagevenue.com/img.php?loc=loc267&image=f85_vmr9b0rked.jpg)

[Liisachan]

@Egh realaac not being able to handle PS is prolly not a bug but a known limitation (possibly darn patent-related). Real Player itself can't either.
but i'd file a bug report in sf whenever needed. Thank you for advice.

edit: sorry, a typo in nick

[clsid]

I have compiled a fresh ICL build and rgb32 output causes high cpu usage just like with bob0r's gcc build. I didn't have this problem with my previous build, so I guess some bug has been introduced in the past few days.

[Thomas_AR]

@clsid
Confirmed, same here. No crashes, but 'Strange' lines in 'all' videos using this build (bob0r) and MPC.

[Egh]

@clsid
Confirmed, same here. No crashes, but 'Strange' lines in 'all' videos using this build (bob0r) and MPC. [IIRC those lines are not present in YUY2 mode]

and @clsid

I first noticed those lines in 20051017, when using software resizer in some modes.

In current build, aka 1021, those lines dissappear if you enable "high-quality YV12-->RGB" conversion. Milan Cutka knows about those lines, he noticed them even w/o me telling him that. Those are caused by miscompile of the conversion code, as far as I got it. More about that in the entry http://sourceforge.net/tracker/index.php?func=detail&aid=1335052&group_id=53761&atid=471489

In accordance with my previous theory, all that slowdown behaviour (including SPP and Software Resizer) are in fact caused by same bug. So in the next build all those issues supposed to dissappear.

[bob0r]

@bob0r
All .txt files in ffdshow directory are incorrect at your builds. No problem on CD and clsid ones.

http://img22.imagevenue.com/loc54/th_507_ffd.jpg (http://img22.imagevenue.com/img.php?loc=loc54&image=507_ffd.jpg)

convert unix line endings to DOS for dialog hint texts
http://cia.navi.cx/stats/project/ffdshow/.message/6137309

Fixed :)

[bob0r]

... you can see those changes. So bob0r might try to build yet another gcc build :PP ...

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

gcc...
gcc...
gcc...
+ more and more, will compile a new one soon, probably tomorrow :goodpost:

[movax]

Back by popular demand :P (actually Egh just poking me), it's the ffdshow "mix and match your components" RAR. Get it here. (http://j.movax.org/ffdshow20051023movax.rar)
Compiled with the usual suspects, MSVC, GCC and ICL9.

*EDIT* Appears Milan is working on 64-bit optimizations too. Good news for Athlon64/Opteron people. :)

[Egh]

Back by popular demand :P (actually Egh just poking me), it's the ffdshow "mix and match your components" RAR. Get it here. (http://j.movax.org/ffdshow20051023movax.rar)
Compiled with the usual suspects, MSVC, GCC and ICL9.

Yeah, and I still confirm bug with libmad.dll (gcc build). It seems the sound output is b0rked there. As for speed, no problems whatsoever (i mean .dlls as gcc and .ax as msvc, hybrid mixed build :)

[movax]

What about the ICLs? Wake up and test :P

[bob0r]

By pengvado
http://students.washington.edu/lorenm/src/x264/ffh264_cqm.0.diff
ffmpeg (libavcodec.dll) cqm decoder patch.

Tried path on:
cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg co -P ffmpeg
cd ffmpeg/libavcodec/ ## copy ffh264_cqm.0.diff here
patch -p0 < ffh264_cqm.0.diff
cd ..
configure --enable-shared --enable-memalign-hack
make
cd libavcodec/
strip avcodec.dll
## then copied avcodec.dll to C:\Program Files\ffdshow\, renamed to
## libavcodec.dll, this does not work with the current ffdshow CVS.

So my question is, can someone who knows more about programming and these patches to manually patch ffdshow/src/ffmpeg/libavcodec/ with ffh264_cqm.0.diff so we can test x264 cqm decoding via ffdshow, thanks.

[bob0r]

I have a problem, since 23 october, when i compile ffdshow(without sse2) with gcc, i cant play video's anymore, ffdshow.ax crashes :confused:

AppName: mplayerc.exe AppVer: 6.4.8.4 ModName: ffdshow.ax
ModVer: 1.0.2.3 Offset: 001907c2

Any clue which update this could be?

fixed Skl_IDct16_SSE calling convention
http://cia.navi.cx/stats/project/ffdshow/.message/6140557
Possibly?

[zeflash]

Hey .. Not sure if it's the right place to report a bug or what, but to confirm what I read in the lastest pages, resizing has a tendancy to crash - at least when trying to resize with value less than 1 (I use 0.95 to compensate my TV overscan).
On some video files it works, on others it doesn't & crash the playback app, whichever it is.

Now I've seen a *lot* of builds from a *lot* of people. Do those builds differ only by the method of compiling? are they touching the sources? can they fix bugs?
Which release / version is the more likely to be the most stable? I'm not that interested in speed - provided one isn't twice as slow as the other that is.

[Thomas_AR]

@Egh
In current build, aka 1021, those lines dissappear if you enable "high-quality YV12-->RGB" conversion

Where do i find this configuration, i think i have to consult my eye-doctor :) ?

[marcellus]

Is in the "output" section, you have to scroll down, it's right before the "about" section.

[Thomas_AR]

Thanks, found it at last. By the way is there a userguide available for fddshow?

[cc979]

hi bob0r,

i successfully compiler gcc-4.0.2 tuck my while i am bit rusty after 14 years
thanks for all the help :thanks:

TortoiseCVS makes it a lot easy for getting cvs's

compiled these, but i'm struggling with ffdshow.ax

if anyone would like to try for me - just copy them into your ffdshow directory

TomsMoComp_ff.dll ff_kernelDeint.dll ff_liba52.dll ff_libdts.dll ff_libmad.dll ff_realaac.dll ff_samplerate.dll ff_theora.dll ff_tremor.dll ff_vfw.dll ff_x264.dll libavcodec.dll libmpeg2_ff.dll libmplayer.dll makeAVIS.exe

http://rapidshare.de/files/6705452/24102005-bin.7z.html

tested output colorspace: yv12,adj
works with xvids,mpeg1,mpeg2,dx5,avc1

spp is a bit funny works fine on always settings

but when playing and you turn it off, it goes slow :confused:

[Egh]

Thanks, found it at last. By the way is there a userguide available for fddshow?

With 1023 I think that problem with lines is fixed, so you dont' really need that.

@Someone who reported "Remaining time" bug:

It should be fixed by now, but Milan said that it's not possible to have it always right. So some clips might still produce weird results.

[Egh]

Hey .. Not sure if it's the right place to report a bug or what, but to confirm what I read in the lastest pages, resizing has a tendancy to crash - at least when trying to resize with value less than 1 (I use 0.95 to compensate my TV overscan).
On some video files it works, on others it doesn't & crash the playback app, whichever it is.


Well I personally very rarely use resizing <1.0. But as for >1.0, I have yet to see a crash. In fact, I yet have to see ANY crash with any last build of ffdshow DEcoding (this month for example :P). You can report a problem, but if it's not quite reproducible it's of not so much value. So try researching, if you can find a way (specific settings and so on) to reliably reproduce it.


Now I've seen a *lot* of builds from a *lot* of people. Do those builds differ only by the method of compiling? are they touching the sources? can they fix bugs?
Which release / version is the more likely to be the most stable? I'm not that interested in speed - provided one isn't twice as slow as the other that is.


Nah, builders don't actually deal with source. They have enough concerns with three different compilers (ICL9, GCC, MSVC). Plus large possibilities with hybrid builds :P

It's the actual developer who makes changes to the source. See cia or cvs on sf for actual changes. By the way, the difference between 1021 and 1023 is quite big.

In your case i actually would advise to grab movax 1023 build, and unpack those files which are in MSVC subfolder into ffdshow's install folder. It's not too slow, but widely considered to be most stable one.

If you want a bit more speed, do like me: copy all files from *gcc* subfolder, but use ffdshow.ax from msvc subfolder. This results in having hybrid build (msvc+gcc). And in both stability and speed, it can rival celtic's hybrid (ICL9+gcc).

Those who can do more or less precise tests are welcome to compare the actual speed in different modes between those two hybrids :P

[movax]

Egh, can you check my ICL9s + GCC? I think I might have forgotten to patch some intel libs, which would adversely affect those with AMD cpus. Hopefully not though.

[clsid]

New build:
http://rapidshare.de/files/6712868/ffdshow-20051024-clsid.exe.html

libavcodec/mplayer are gcc 4.0.2
Everything else ICL9

[cc979]

hi bob0r

did some further testing with x264-334b using quality mode and automated 2pass high profile.

avi's encoded with this work fine in your icl,gcc,msvc builds with there dll's and with mine.

mp4's encoded with this work fine in your msvc,gcc builds with there dll's and with mine.

but mp4's encoded with this did'nt open in your icl build, i thought it was hali's latest splitter or mpc but it turned out to be after various mixs to be your icl-ffdshow.ax, because i tested your icl dll's with your msvc and gcc builds and they worked fine - spp still dodgy tho.

sorry for the bad gramma...lol

[Thomas_AR]

OFFTOPIC:
@cc979
What is 'Clipman 3' ?

[clsid]

@cc979

Could you upload a mp4 file that you encoded? I would like to test it.

[cc979]

New build:
http://rapidshare.de/files/6712868/ffdshow-20051024-clsid.exe.html

libavcodec/mplayer are gcc 4.0.2
Everything else ICL9

i got the same problem with your ffdshow.ax and clues what it could be as msvc/gcc version work fine?

[cc979]

i got the same problem with your ffdshow.ax and clues what it could be as msvc/gcc version work fine?

http://rapidshare.de/files/6716594/ClipMan3.7z.html

its a good little clipboard manager good for screen grabs and the like.

[bob0r]

libavcodec.dll (ffdshow) + pengvado's cqm patch, anyone? :script:

edit:
http://students.washington.edu/lorenm/src/x264/ffh264_cqm.1.diff
"fixes non-high-profile and lossless"

[cc979]

@clsid and bob0r

it maybe a false alarm, i enabled nero splitter - it crashes %50 of the time
i will do more testing to be sure

[thuan]

Movax I have a prob with your 1023 liba52.dll gcc compile. It don't play any vid file (mkv, avi and ogm) with ac3 audio and tell external error, libac3 icl and msvc is fine though.

PS: wait for a while and no one post this so I post. And why I can't find libmplayer in your compile?

[movax]

libavcodec.dll (ffdshow) + pengvado's cqm patch, anyone?

If you're just patient, I'm sure it'll be integrated into the ffdshow CVS in a day or two.

@thuan:
Um, thuan, what CPU do you have? liba52 has repeatable crashes on non-SSE2 processors when compiled with GCC.

And the reason you can't find mplayer DLL is because I forgot to include it :P I just added it to the RAR, so go ahead and regrab. http://j.movax.org/ffdshow20051023movax.rar :)

I'll make a checklist of things now, and recompile on Wed. or so when school lets up.

[thuan]

Yeah, I have a Sempron 2200+ (1.5 GHz), so it have to crash.
About the speed of icl+libavcodec(gcc) it's faster than msvc+gcc. Don't have the time to test if it crash on some special file or not but I can say this I like the msvc+gcc+liba52_icl one better, the avarage speed is a little slower but it seeks faster with file that hard to render (h.264 and high resolution xvid files). I think it's because the way icl use CPU time is not as stable as msvc+gcc one, icl have more CPU spike.

Anyway thanks for your work. If I have some more time, I will test more (have midterm test in uni now) and maybe compile one myself like once I did (actually it came out terrible) :D

[bob0r]

@movax

Yeah, but it was not meant as impatience for using it my my builds, but to test it. Meaning the CQM patch(es) need to be tested, and the sooner we can test it, the sooner we can find bugs, if any, so pengvado can create the perfect cqm supporting decoder.

It is now, we got people testing and interested in ffdshow, better use that to fix as many bugs as possible :cool:

[bob0r]

updated libavcodec: h.264 custom quantization matrices support
http://cia.navi.cx/stats/project/ffdshow/.message/6163813

Will compile a new test build for this, once ffdshow.ax compiling with gcc has been fixed.

[Revgen]

Is it absolutely neccessary to use GCC?

Can't MSVS or ICL be used instead?

[clsid]

http://rapidshare.de/files/6752494/ffdshow-20051025-clsid.exe.html

[bob0r]

Is it absolutely neccessary to use GCC?

Can't MSVS or ICL be used instead?


MSVC = buyware and slow
ICL = buyware and not so stable
GCC = free (after optimizes fast(er)) and easily used with mingw and thus easy to automate, and most stable.

absolutely neccessary, no, but its just what we rather use.

@all
"gcc + VMR9 + RGB slowness"
YV12->RGB32 conversion should be fixed now. GCC wasn't
correctly initializing 64-bit __m64 constants.

Getting faster and faster :)

[Revgen]

http://rapidshare.de/files/6752494/ffdshow-20051025-clsid.exe.html

Thanks! :)

I just encoded a file with Sharktooth's EQM matrix. It plays fine with this version.

[Koti]

updated libavcodec: h.264 custom quantization matrices support
Great news , works perfect so far . Thx to all involved and clsid for the compile. :)

[canuckerfan]

glad to see this project getting attention and dev time. keep it up :D

[Sharktooth]

if you have hard times downloading clsid ffdshow build from rapid share here an alternative download link: http://www.webalice.it/f.corriga/temp/ffdshow-20051025-clsid.exe

[cc979]

@cc979

Could you upload a mp4 file that you encoded? I would like to test it.

the new builds x264 work for me or was it just one of those windows things

but you could test this little.mp4 for me - just to see

because this older.mp4 crashes nero splitter and hali's

test.mp4 (http://rapidshare.de/files/6769906/dodgy_customquant.7z.html)

[marcellus]

Hi, I tried to encode to mpeg2 ("Libavcodec DVD PAL" preset) with ffdshow-20051025-clsid.exe and I get this error:
http://img458.imageshack.us/img458/6964/clipboard015dl.th.png (http://img458.imageshack.us/my.php?image=clipboard015dl.png)
I got the same error with the previous clsid's build but after I installed a later bob0r icl build (and the error wasn't there) I thought it was a problem with ffdshow itself that got solved and I didn't report anything. But I see I was wrong, the latest clsid build shows the problem too, so it has something to do with the compile itself.

[dimzon]

http://rapidshare.de/files/6752494/ffdshow-20051025-clsid.exe.html
You are forget about ff_libfaad2.dll again :devil: :devil: :devil:

NOTE! RealAAC DOES NOT SUPPORT ParametricStereo SO WE NEED ff_libfaad2.dll

[clsid]

@marcellus
It's an assertion error. I don't think it's a compilation issue. More likely a bug in the code. You should post a bug report at the ffdshow sourceforge page.

[marcellus]

Yes, that's what I thought in the first place, but why it happens only with your compiles? :confused:
Anyway, I need more details about your compile if I am to forward a bug report.

[videomixer9]

amazing enough someone still encodes to mpeg2 hahaha ...

[dragongodz]

amazing enough someone still encodes to mpeg hahaha ...
do you encode with xvid or divx ? how about one of the h264 codecs such as x264 or the one with nero recode ? if you answered yes then YOU are encoding to mpeg aswell, part 2 and part 10(respectivly).
or how about all the people using DVD-Rebuilder or DVD2SVCD etc ,are they not "someone's" ?

my point ? your post was not only pointless but also nieve at best.

[videomixer9]

sorry the 2 got lost somewhere, don't take me as a n00b :devil: ... I really need a new notebook this ones keyboard is full of food ...

as for gcc compiles ... maybe try some newer snapshots ak.a. 4.0.3 prereleases ... may fix sth. gcc 4.0 itself is just software too and some ppl even manage to break their compiles of gcc ;)

[Sharktooth]

You are forget about ff_libfaad2.dll again :devil: :devil: :devil:

NOTE! RealAAC DOES NOT SUPPORT ParametricStereo SO WE NEED ff_libfaad2.dll
http://www.webalice.it/f.corriga/temp/ff_libfaad2.7z

[dimzon]

Does anibody know how to use FFDSHOW as MPEG2 Video decoder for DVD playback?
It work's fine when I open single VOB using MPC but don't work when I open IFO!

[Leak]

Does anibody know how to use FFDSHOW as MPEG2 Video decoder for DVD playback?
It work's fine when I open single VOB using MPC but don't work when I open IFO!
Well, I've just given it a go with clsid's latest build and an image of GITS:SAC 2nd GIG Vol. 1 mounted with Daemon Tools - works fine if you

- deactivate the MPEG2 filter in MPC (duh... ;))
- choose "libmpeg2" or "libavcodec" as MPEG2 codec in ffdshow
*and*
- activate "DVD decoding (not working yet)" below the list when MPEG2 is selected in the list and make sure "enable speedup tricks" is off if you use libavcodec...

Yeah, you'll get a few glitches until the next keyframe when seeking or at the very end of a VOB or when changing menus, but beside that it plays fine. Using KernelBob with threshold 0 and a 60Hz refresh rate makes it look almost like TV on my TFT... :D

np: Michael Mayer - Slowfood (Touch)

[dimzon]

activate "DVD decoding (not working yet)" below the list when MPEG2 is selected in the list and make sure "enable speedup tricks" is off if you use libavcodec...
WOW !!!!!!!!!!!!!!!
Thanx a lot !!!

[clsid]

the new builds x264 work for me or was it just one of those windows things

but you could test this little.mp4 for me - just to see

because this older.mp4 crashes nero splitter and hali's

test.mp4 (http://rapidshare.de/files/6769906/dodgy_customquant.7z.html)

It crashes here too. MPC/Haali/ffdshow ICL9.

BUT... it plays fine if you first play some other file (that uses ffdshow) and then this clip (in the same player instance).

[cc979]

It crashes here too. MPC/Haali/ffdshow ICL9.

BUT... it plays fine if you first play some other file (that uses ffdshow) and then this clip (in the same player instance).

clad its just not me, but still weird - what do you think it is - mpc crashing the splitter or something else, thing is it opens in vlc everytime

do you think it should be sent as a bug? to hali/ffdshow/mpc

[videomixer9]

duh can't you use sth. else than rapidshare ... it damn sucks, you just wanna collect stupid points anywhere ... bleh ...

[clsid]

Haali says it's a bug in ffdshow. I posted the same problem in the Matroska splitter thread over two months ago.

ndparser.ax + nero = ok
ndparser.ax + ffdshow.ax (ICL) = ok
haali + nero = ok
haali + ffdshow.ax (ICL) = crashes ffdshow

[MacAddict]

duh can't you use sth. else than rapidshare ... it damn sucks, you just wanna collect stupid points anywhere ... bleh ...

You come in here with 16 posts and that sort of attitude?!?! Be grateful new builds are available. Perhaps you would like to supply some web storage or new builds yourself for the community? :rolleyes:

[cc979]

duh can't you use sth. else than rapidshare ... it damn sucks, you just wanna collect stupid points anywhere ... bleh ...

sth. ?

[kurt]

he meant "something" ... perhaps: http://www.badongo.com/ <-- no need to wait for downloading :)

[bob0r]

You are forget about ff_libfaad2.dll again :devil: :devil: :devil:

NOTE! RealAAC DOES NOT SUPPORT ParametricStereo SO WE NEED ff_libfaad2.dll


Milan removed or forgot it:
new cvs checkout
ffdshow/src/
make clean

make -C codecs/libfaad2 clean
make: *** codecs/libfaad2: No such file or directory. Stop.
make: *** [clean] Error 2


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

Edit:
Fixed:
libfaad2 -> faad > http://cia.navi.cx/stats/project/ffdshow/.message/6184363

[cc979]

he meant "something" ... perhaps: http://www.badongo.com/ <-- no need to wait for downloading :)

never tried that yet, is it ok

i've trying to compile gpac but i get a zlib not found, any help from anyone would be grateful

[kurt]

never tried that yet, is it ok
it seems so... take a look in here: http://forum.doom9.org/showthread.php?t=101608

[bob0r]

...

i've trying to compile gpac but i get a zlib not found, any help from anyone would be grateful

http://www.zlib.net/
http://www.zlib.net/zlib-1.2.3.tar.gz (source)
Extract, then:
cd zlib-1.2.3
configure
make
copy zlib-1.2.3/libz.a to C:\MinGW\lib
copy zlib-1.2.3/*.h to C:\MinGW\include

then go to gpac dir
make clean
make lib
copy gpac/bin/gcc/libgpac_static.a to C:\MinGW\lib
copy gpac/include/gpac (the whole dir gpac) to C:\MinGW\include

[cc979]

@ bob0r

cheers

[Blue_MiSfit]

Wow. Nice to see CQM's are supported for H.264 now :)

THANKS A MILLION DEVS!!!

[ExtraEye]

audio decoder has problems with freeverb filtering. no sound when enabled.

that on celtic druids 25/10 build

[Egh]

audio decoder has problems with freeverb filtering. no sound when enabled.

that on celtic druids 25/10 build

Are you sure there's such a thing like Celtic's 2510 build? :)

[ExtraEye]

oh
my bad then...
the name seemed to me like a shortcut for it for some reason...
sorry
the build im refering to is clsid's build...

[thuan]

Try the newest ffdshow 20051027msvc+gcc (on mininova and freecodecs.com) and it runs fine with CQM (not have the problem like clsid's 1025) and freeverb.

[Egh]

Try the newest ffdshow 20051027msvc+gcc (on mininova and freecodecs.com) and it runs fine with CQM (not have the problem like clsid's 1025) and freeverb.

It's a strange build.

Am I crazy or all modification dates on .ax and .dll there are 2004-12-31? :P

Though build itself says it's 27 oct.

Also, it seems this build is msvc, so a bit slow.

[thuan]

Yeah I knew it, maybe because the one who compiled it set the clock on his com wrong. About speed it's faster than clsid's 1025 with ASP and a little slower with AVC IMO and that happens with all msvc+gcc on my com (a sempron 2200+) so I think it's normal. The strange thing is how small its binary is, maybe he use different cml switchs than other people.

[Egh]

Yeah I knew it, maybe because the one who compiled it set the clock on his com wrong. About speed it's faster than clsid's 1025 with ASP and a little slower with AVC IMO and that happens with all msvc+gcc on my com (a sempron 2200+) so I think it's normal. The strange thing is how small its binary is, maybe he use different cml switchs than other people.

Yeah, I also noticed that .ax is extremely small. And it seems to be compiled by msvc exclusevely? Then it's really not bad build.

Though movax 2310 msvc .ax + gcc .dlls will be still faster (VMR9 RGB output, Lanczos Software resizer).

[canuckerfan]

shouldn't ffdshow get its own forum by now? :(

[thuan]

1027 crash with 6ch AAC SBR with libfaad2 decoder (my CPU doesn't have SSE2). When I said its binary is small, I mean every dlls of it eg: libavcodec.dll with gcc is usally bigger that what is strange.

[cc979]

has anybody had anyluck compiling latest cvs and have ffdshow.ax not crash with gcc?

@of topic
whats the best way to copy the difference from to directories?

[Liisachan]

WinMerge?
http://winmerge.sourceforge.net/

[cc979]

WinMerge?
http://winmerge.sourceforge.net/

i got winmerge, its for text files not folders

[bob0r]

has anybody had anyluck compiling latest cvs and have ffdshow.ax not crash with gcc?

...

The answer is: No
thread: http://sourceforge.net/tracker/index.php?func=detail&aid=1336820&group_id=53761&atid=471489

[Liisachan]

i got winmerge, its for text files not folders
on Explorer select 2 folders you want to compare, then right click -> winmerge
--is possible, but you meant Copy, so probably winmerge doesnt help :(

[cc979]

on Explorer select 2 folders you want to compare, then right click -> winmerge
--is possible, but you meant Copy, so probably winmerge doesnt help :(

i'll check thanx

[DeeGee]

I have had a strange problem with ffdshow and mp4 for some time now. ffdshow doesn't seem to respect/understand the aspect ratio info in mp4 (altough mpeg2 etc. seems to work fine). I have one musicvideo in mp4 that has heavily distorted aspect ratio (480x576 -> 4:3 -> 720x576) and it shows as it should. But my anamorphic movie backups (black borders cut out 16:9 aspect ratio) show up forced into 4:3 window like this:
http://students.oamk.fi/~t3paja01/sekalaista/ffdshow.png
Oh, and they do show up with the intended aspect ratio on mplayer, vlc and nero showtime.

[gaekwad2]

@DeeGee: see here (http://forum.doom9.org/showthread.php?t=97313)

(Used to drive me mad as well, until I noticed I'd forgotten to set Override Aspect Ratio to Default in MPC.)

[DeeGee]

I just updated the screencapture... As you can see MPC's settings should be ok.

[edit]

the aspect ratio panel in ffdshow (lower part in resize) is always active ! it's strange but true. just try to play w/it wout activating. it drove me mad while i figured it out.

This seems to be true. The aspect ratio is adjusted by this setting, even if resize is disabled. I guess this shouldn't work like this?
http://students.oamk.fi/~t3paja01/sekalaista/ffdshow2.png
Anyway, now it works for me. Just pulled the setting to the left = default.

[gaekwad2]

As you can see the checkbox on the actual pane only applies to Resize.

The way it's shown in the list on the left is misleading.

[Egh]

As you can see the checkbox on the actual pane only applies to Resize.

The way it's shown in the list on the left is misleading.

yeah true.

I bugged Milan Cutka couple of times to redo Resizing. ATM he agrees that the whole section needs major overhaul, but hasn't done anything yet in last 3 months or so :P

Check my entry in the ffdshow tracker (not bugs but feature suggestions).

[bob0r]

Trying ffdshow with Microsoft Visual Studio 2005
(will report this also as bug(s) when sourceforge allows me)

Building all 22 projects:
Error 13 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory D:\utils\Microsoft Visual Studio 8\VC\PlatformSDK\include\strmif.h 21826
Error 14 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory D:\utils\Microsoft Visual Studio 8\VC\PlatformSDK\include\strmif.h 21826
Error 44 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory g:\msys\1.0\home\user\ffdshow_msvc8.0\src\baseclasses\streams.h 47
(when its done it says ff_x264 is unavailable)

When i reload ff_x264 and try build it:
Error 168 error LNK2001: unresolved external symbol _x264_deblock_v_chroma_intra_mmxext frame.obj
Error 169 error LNK2001: unresolved external symbol _x264_deblock_h_chroma_intra_mmxext frame.obj
Error 170 error LNK2001: unresolved external symbol _x264_deblock_v8_luma_mmxext frame.obj
Error 171 error LNK2001: unresolved external symbol _x264_deblock_h_luma_mmxext frame.obj
Error 172 error LNK2001: unresolved external symbol _x264_deblock_v_chroma_mmxext frame.obj
Error 173 error LNK2001: unresolved external symbol _x264_deblock_h_chroma_mmxext frame.obj
Error 174 fatal error LNK1120: 6 unresolved externals g:\msys\1.0\home\user\ffdshow_msvc8.0\bin\ff_x264.dll 1

project ff_wmv9:
Error 1 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory D:\utils\Microsoft Visual Studio 8\VC\PlatformSDK\include\strmif.h 21826
Error 2 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory D:\utils\Microsoft Visual Studio 8\VC\PlatformSDK\include\strmif.h 21826

project ffdshow:
Error 4 fatal error C1083: Cannot open include file: 'ddraw.h': No such file or directory g:\msys\1.0\home\user\ffdshow_msvc8.0\src\baseclasses\streams.h 47

Its quite obvious Visual Studio 2005 is not finding the correct path to ddraw.h
Any easy way fix this?

Edit 01:
Please follow:
https://sourceforge.net/tracker/index.php?func=detail&aid=1346134&group_id=53761&atid=471489

Extra added:
ffdshow error:
Error 1 fatal error LNK1181: cannot open input
file 'dinput.lib' ffdshow

Fixed by adding x86 to the DirectX SDK lib path (see instructions below)

Edit 02:
new error:

Error 407 error LNK2019: unresolved external symbol _simple_idct_mmx_P referenced in function "private: void __thiscall TimgFilterPostprocSpp::filter(unsigned char *,unsigned char const *,int,int,unsigned int,unsigned int,signed char const *,int,bool)" (?filter@TimgFilterPostprocSpp@@AAEXPAEPBEHHIIPBCH_N@Z) TimgFilterPostproc.obj
Error 408 fatal error LNK1120: 1 unresolved externals bin\ffdshow.ax

Fixed "finally correct vs.net 2005 project" > http://cia.navi.cx/stats/project/ffdshow/.message/6276280

Edit 03:
Still a bug left:
From the same thread:
Error 408 error PRJ0050: Failed to register
output. Please ensure you have the appropriate permissions
to modify the registry. ffdshow

Reported.

[bob0r]

1027 crash with 6ch AAC SBR with libfaad2 decoder (my CPU doesn't have SSE2). When I said its binary is small, I mean every dlls of it eg: libavcodec.dll with gcc is usally bigger that what is strange.

Confirmed, my simple stereo .aac in x264.352.mp4 file now crashes too with ff_libfaad2.dll gcc (msvc 7.1 version works fine, as does msvc 8.0)

reported:
https://sourceforge.net/tracker/index.php?func=detail&aid=1346184&group_id=53761&atid=471489

[clsid]

@bobor

Add the path to the DirectX SDK Include folder to the VS2005 path settings.
Options > Projects and Solutions > VC++ Directories > Include Files

[SeeMoreDigital]

I just updated the screencapture... As you can see MPC's settings should be ok. Do you not have this option: -

http://img108.imageshack.us/img108/66/ffdshowanamorphicoverlaysettin.png

These are the settings I use and all my encodes with anamorphic signalling AR perfectly ;)

I do not bother using the "Resize and Aspect" settings you showed....


Cheers

[Leolo]

Hi,

There's something I don't understand: Why does ffdshow automatically select YUY2 when you're playing a DivX or XviD file?

Shouldn't YV12 be the closest matching colorspace?

Also, what are the advantages in forcing RGB32 output? Is the quality better? Why?

What does the "adj" word mean in "YV12,adj"? Adjusted? Adjusted to what?

If you force YV12, where exactly is the conversion to RGB done? In the VMR renderer? Or in the graphics card drivers?

I'm all in doubt!

Many thanks in advance,
Best regards.

[bob0r]

@bobor

Add the path to the DirectX SDK Include folder to the VS2005 path settings.
Options > Projects and Solutions > VC++ Directories > Include Files

Was about to update my post, you need to add PlatformSDK too :), here goes:
(https://sourceforge.net/tracker/?func=detail&atid=471489&aid=1346134&group_id=53761)

It indeed seems Visual Studio 2005 is lacking files Visual Studio 2003 does have.
Even though PlatformSDK is installed D:\utils\Microsoft Visual Studio 8\VC\PlatformSDK it does not have amvideo.h

Error 8 fatal error C1083: Cannot open include file: 'amvideo.h': No such file or directory g:\msys\1.0\home\user\ffdshow_test\src\codecs\wmv9\videoenc.cpp 19
Error 9 fatal error C1083: Cannot open include file: 'amvideo.h': No such file or directory g:\msys\1.0\home\user\ffdshow_test\src\codecs\wmv9\ff_wmv9.cpp 13


Both missing files issues can indeed be "fixed" by installing PlatformSDK and DirectXSDK seperately.

Tip for those who want to know:
1: open Microsoft Visual Studio 2005
2: Tools/Options
3: Projects and Solutions
4: VC++ Directories
5: Select "Show directories for:" (right top)
6: Include files, to the bottom I have added:
D:\utils\Microsoft DirectX 9.0 SDK (October 2005)\Include
D:\utils\Microsoft Platform SDK\Include
- Set your own path here
7: Library files, to the bottom I have added:
D:\utils\Microsoft DirectX 9.0 SDK (October 2005)\Lib\x86
D:\utils\Microsoft Platform SDK\Lib
- Set your own path here
8: Click OK and try compiling again, it worked for me!

Thanks clsid

Edit:
Microsoft DirectX 9.0 SDK (October 2005)\Lib\x86 <-- note the extra x86 dir

[thuan]

With bob0r's ffdshow20051102 libfaad2 don't run at all. It's not even show up in the about of ffdshow audio decoder and when I open a video with aac audio it's just don't load ffdshow audio decoder. And by the way my CPU don't have SSE2.

Will test more. Thanks for your hard work.

[Inventive Software]

@thuan: There's your problem, in part. most of the builds that people make require SSE2 to run it. I am working on an SSE only build, but this may take some time.

[Egh]

@thuan: There's your problem, in part. most of the builds that people make require SSE2 to run it. I am working on an SSE only build, but this may take some time.

I thought b0b0r himself is on SSE-only cpu :)

Also, it's plain MSVC build now, right? No other compilers this time?

[videomixer9]

Hi,

There's something I don't understand: Why does ffdshow automatically select YUY2 when you're playing a DivX or XviD file?

Shouldn't YV12 be the closest matching colorspace?

Also, what are the advantages in forcing RGB32 output? Is the quality better? Why?

What does the "adj" word mean in "YV12,adj"? Adjusted? Adjusted to what?

If you force YV12, where exactly is the conversion to RGB done? In the VMR renderer? Or in the graphics card drivers?

I'm all in doubt!

Many thanks in advance,
Best regards.

This behaviour is only like that if you use VMR9 Renderless in MPC, otherwise the output colorspace is YV12. I dunno how it connects the filter graph but when using VMR9 Renderless it enforces YUY2.

VMR9 has this stupid coloring bug for many ppl, it has a luma shift that makes colors look a bit shitty. To compensate for this you set the output colorspace to the one your screen usually uses for graphics output, and that's RGB32 for most ppl, this way the reduced luma range of YV12 isn't as obvious for the viewer as the colors range is broader on RGB. YV12 usually doesn't have black, it starts with a dark grey and goes upto a not really white.

I noticed that the nero decoder automatically seems to select RGB32 output for VMR9 renderers as it doesn't have the shifting effect.

So to say VMR9 is too good for video output???

[bob0r]

Yeah ffdshow gcc 4.0.2, ffdshow.ax msvc 7.1, ff_libfaad2.dll msvc 8.0 is what i used (ffdshow-20051102.exe), who knows what msvc 8.0 does with it, thats why i put it there :)

Anyways, only one file left to fix for both gcc and msvc 8.0, ffdshow.ax

Edit:
ffdshow.ax with gcc 4.0.2 was "fixed" by using "make SSE2=no;"
ffdshow.ax with msvc 8.0 almost works, it compiles, only a registering bug left.

[Smiff]

hi, um keep up the good work on ffdshow. if anyone can list the best builds by cpu type (i have an athlon sempron 2600+ (K8 SSE2 but not 64bit) that would be most helpful (if not exists already?)

Can someone answer all of Leolo's Qs please, i'd really like to know all that aswell.

i use VMR9 with ffdshow's levels (luma only) and it seems to give a good result - what's wrong with that? why does videomixer9 say "colouring bug" and then imply its a luma bug (as i believe it is also).

[bob0r]

I had the same, reinstalling fixed the problem, the not loading the config part.
(always uninstall old version)

BUT, indeed ff_libfaad2.dll is not used to decode the AAC part of my x264.358.mp4, i will update a new build soon. (First it crashed, then i figured it was fixed using make SSE2=no (which should fix it). But if it isn't used to decode, we can't test :) (Media Player Classic AAC decoder took over :o)

Try ffdshow-20051103.exe
ffdshow gcc 4.0.2, ffdshow.ax msvc 7.1

Edit:
Removed link to old ffdshow-20051103.exe, i finally understand how to compile ffdshow with gcc 4.0.2 again.

Simply said:
cd ffdshow/src/
make clean
make SSE2=no

Adding SSE2=no to the main Makefile creates a full gcc ffdshow release.
(you still have to add the DirectX SDK header files)

A full gcc 4.0.2 ffdshow-20051103.exe version is online now :helpful:

[QQ]

i'm also lost as to which is latest SSE2 optimised version :(

[bob0r]

i'm also lost as to which is latest SSE2 optimised version :(

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051103-sse2.exe
compiled fully with gcc 4.0.2
Just for you :)

[Liisachan]

:thanks: bob0r !!

celtic_druid's new build is out too :)
ffdshow-20051103.exe (http://ffdshow.faireal.net/ffdshow-20051103.exe)
i'm mirroring bob0r's builds too.

btw, in case some of you didn't know yet, Media Player Classic 6.4.8.5 was released,
supporting .mp4 splitting (without haali's filter), meaning, for instance,
(x264+faac).mp4 ->MPC->ffdshow
is possible even without haali's filter.
a known limitation: MPC's internal AAC decoder is not new enough to handle HE-AACv2 perfectly. (but you can disable it and then ffdshow audio decoder will be called)

[bob0r]

@Liisachan
Hehe damn same filename :)
And thanks, added mpc2kxp6485.zip to the site :)

[Slave01]

x264 decoding in new celtic's druid doesn't work for me (Sempron 3000+ socket a only sse)...anyone with same glitch?

John Slave

[Revgen]

x264 decoding in new celtic's druid doesn't work for me (Sempron 3000+ socket a only sse)...anyone with same glitch?

John Slave

Which Version?

How does it not work?

No video?

Bad Video?


Can you for provide a sample of the video for download?

[Egh]

@Liisachan
Hehe damn same filename :)
And thanks, added mpc2kxp6485.zip to the site :)

there's also new cvs build of 6485, check the thread for mpc on this forum.

Did you put that version or older build from sf.net?

[QQ]

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051103-sse2.exe
compiled fully with gcc 4.0.2
Just for you :)

thanks a lot! but now that i think about it, if i have p4, ICL compile would give even better performance, or am I wrong about it? or perhaps ffdshow ICl doesnt even exist..?

[celtic_druid]

My builds have always been ICL unless otherwise stated. Only libmplayer and parts of libavcodec are gcc.

[Slave01]

Which Version?

How does it not work?

No video?

Bad Video?


Can you for provide a sample of the video for download?


x264 last version high profile no mixed ref (or newer features). Error in ffdshow.ax...mkv container...haali splitter...

[bob0r]

there's also new cvs build of 6485, check the thread for mpc on this forum.

Did you put that version or older build from sf.net?

I put the original 6.4.8.5 from the MPC sourceforge page on my website.

Off Topic:
New x264.nl nameserver is working, but its not loading all IPs, hopefully it will be fixed soon :o

For now, use http://www.infra-services.com/~x264/public/ and/or http://www.infra-services.com/~x264/ to find your favourite builds (still working on MSVC 8.0 :D)

[signatory]

hi, um keep up the good work on ffdshow. if anyone can list the best builds by cpu type (i have an athlon sempron 2600+ (K8 SSE2 but not 64bit) that would be most helpful (if not exists already?)



x2
Yeah I love the work by you guys on ffdshow and mpc etc.
Perhaps it would be a nice idea for a mini-faq now concerning all the
updated releases.

I believe most people are interesting in decoding and it would be helpful what builds can be recommended to different CPU's.

Sadly i'm stuck on a Athlon Thunderbird 1400 where every percent less load on the CPU is welcomed... :(

[bob0r]

For a full msvc 8.0 ffdshow build we have to wait untill Milan himself has installed Visual Studio 2005.

Unless someone else knows a solution to:
http://www.infra-services.com/~x264/public/ffdshow_msvc8.0_compiling.jpg

(details on: https://sourceforge.net/tracker/?func=detail&atid=471489&aid=1346134&group_id=53761)

[clsid]

Bob0r's gcc build of realaac doesn't work on my AMD Thunderbird.

[bob0r]

Bob0r's gcc build of realaac doesn't work on my AMD Thunderbird.

Can you put the aac audio file online?

with my x264.mp4 both
realaac (mono, because it does not support PS) and libfaad2 (stereo, supporting PS) play the audio just fine.

[movax]

I'll bet that if bob0r did not use "make NOINTRIN=1" whilst compiling those files in GCC, it won't work on your thunderbird. Though if that's true, a few other DLLs with SIMD extensions shouldn't function either.

And about VS2005, I once burned about 8 hours or so trying to compile ffdshow with it...always got the "Could not Register output" errors, and had to scrounge up the version 8 runtime from the Platform SDK. Release_64 builds should hopefully function soon.

[Egh]

And about VS2005, I once burned about 8 hours or so trying to compile ffdshow with it...always got the "Could not Register output" errors, and had to scrounge up the version 8 runtime from the Platform SDK. Release_64 builds should hopefully function soon.

BTW, where's your build? :)

Also, on of the last entries in ffshow development is "finally correct vs.net 2005 project" .

So I guess it should be possible to build it with vs2005 now. Also, I still don't get where all those promised unicode builds :P

[Thomas_AR]

It's getting confusing for me. Can somebody tell me which is the last SSE2 Version recomendet (if ffdshow SSE2 ist the best for a SSE2 compatible Pentium 4) ? Perhaps a download link? Thanks folks.

[Egh]

It's getting confusing for me. Can somebody tell me which is the last SSE2 Version recomendet (if ffdshow SSE2 ist the best for a SSE2 compatible Pentium 4) ? Perhaps a download link? Thanks folks.

specifically SSE2 compiled (i.e. it doesn't work normally on Athlon XP and earlier processors) is from b0b0r.

http://mirror05.x264.nl/public/ffdshow/

Naturally, it's only for testing purposes. The build put on the frontpage of x264.nl (aka http://mirror01.x264.nl/x264/ffdshow-20051103.exe) is a universal one, i.e. can be used on nonSSE2 CPUs.

Celtic uses ICL9 for his builds, so there SSE2 should be working well. Probably for Pentium4 it should be best build. But try all variants and tell us the speed difference, if any discovered :P

[Thomas_AR]

Ok i will test them. Is there a special measure software regarding to the speed of the different Builds?

[Shirokuu]

As far as i know the only testing method is displaying the CPU load (and possibly the framerate) to determine the speed of the different builds. Of course it's not really a scientific method, and you have to keep the testing environment exactly identical when testing different builds.

[Egh]

As far as i know the only testing method is displaying the CPU load (and possibly the framerate) to determine the speed of the different builds. Of course it's not really a scientific method, and you have to keep the testing environment exactly identical when testing different builds.

well, framerate is not very precise measurement. though cpu % reported by ffdshow might be not trustworthy either.

what is g00d though, is that you can enable logging cpu % values to a file, and later load them into Excel tab, and thus to aggregate the data, as someone else already shown there.

Though I would like to know if there's a software like Process Explorer or something similar which can display % for an application and then log the data?

[celtic_druid]

MSVC 2005 is working fine here:
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.20051105.msvc8.7z
ffdshow.ax only. msvcr80.dll included.

[signatory]

MSVC 2005 is working fine here:
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.20051105.msvc8.7z
ffdshow.ax only. msvcr80.dll included.

Please tell me what's the difference between your ffdshow-20051103.exe and the one above? ty

[videomixer9]

that one above has the most cpu usage for the ffdshow splitter.ax thread in pse for me, the ICL9 build is a tad better but is totally beaten by the GCC only build on my athlonxp.

[signatory]

My impression is the gcc only (non sse2) is the best for AMD family of cpu's.

[Egh]

heh, the only question is which build you used "as gcc only non sse2" for testing? :)

i mean where ALL the files are gcc built, including .ax.

[signatory]

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-gcc-test.exe (all files gcc, without sse2)

bob0r's own words.

[_xxl]

http://mirror05.x264.nl/celtic_drui...051105.msvc8.7z
MSVC 2005 is not working:error R6034!

[Egh]

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-gcc-test.exe (all files gcc, without sse2)

bob0r's own words.

that's VERY old.

And as you can easily see, that gcc build has MANY slowdown issues, such as yv->rgb conversion, resizing, spp deblocking and so on.

and of course no new functionality in that build like custom matrices and so on. It was two weeks ago, that's it :) Since that I don't see any newer plain gcc build.

As for current builds speed on Athlon XP, i seriously don't see any difference between b0b0r and celtic now.

[Egh]

http://mirror05.x264.nl/celtic_drui...051105.msvc8.7z
MSVC 2005 is not working:error R6034!

Confirmed, same for me. On startup gets me same error, (bad attempt to load C runtime library or something like that). Then repeats it again and again :) The dll supplied in the archive was put in the same directory where ffdshow is. Or should it be in system32 folder?

[bob0r]

MSVC 2005 is working fine here:
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.20051105.msvc8.7z
ffdshow.ax only. msvcr80.dll included.


Hmm indeed does Not work.

I already reported this "bug" to Milan.

This is what i get when i compile ffdshow:
http://mirror05.x264.nl/public/ffdshow_msvc8.0_compiling.jpg

the report:
https://sourceforge.net/tracker/?func=detail&atid=471489&aid=1346134&group_id=53761

The .dll goes into C:\WINDOWS\system (weird dir to start with?), but this has no effect.

[_xxl]

yes,winsys dir:msvcr80.dll 8.0.50727.42 and msvcp80.dll 8.0.50727.42 error R6034!

[_xxl]

ffdshow 20051027 MSVC 2005 version is working!ffdshow.ax 1.0.2.5 26/10/2005 - 21:07:25UTC 2,052,096 bytes tested OK!

[_xxl]

MSVC 2005 version is not working!
ffdshow.ax 1.0.2.5 26/10/2005 OK!
libavcodec.dll error files are missing:coredll.dll,mmvcp70.dll and mmvcr70.dll.
files:
http://www.dll-files.com/dllindex/dll-files.shtml?coredll
http://www.dll-files.com/dllindex/dll-files.shtml?mmvcp70
http://www.dll-files.com/dllindex/dll-files.shtml?mmvcr70
All files in WinSys dir.
Media player 2:ordinal 1346 could not be located in the dynamic link library coredll.dll.

[celtic_druid]

Hmmm, it worked fine earlier here with several AVC samples.

[bob0r]

C Run-Time Error R6034
http://msdn2.microsoft.com/en-us/library/ms235560(en-US,VS.80).aspx

I got this link from a guy who PMed me, maybe he hit the wrong button or he has a reason not to post publicly, anyways, this is what he said:

Is this still an issue?

The release version of Visual Studio 2005 now requires the manifest files it generates to be in the same dir as the compiled code that tries to load crt dlls. More details are at MSDN (http://msdn2.microsoft.com/en-us/library/ms235560(en-US,VS.80).aspx).

I'm assuming the regsvr32 error is from the ffdshow.nsis2 installer code that's trying to register ffdshow.ax.

You might try adding the ffdshow.ax.manifest that VS2005 generates to the nsis packaging script or manually running regsvr32 from the ffdshow.ax build dir.

(You might have to overwrite/delete the existing ffdshow.ax.manifest from cvs that provides xp theming for the dialogs.)

But now this part:
You might try adding the ffdshow.ax.manifest that VS2005 generates...

Who What Where?

Edit:
Tried in Visual Studio
- right mouse on ffdshow/properties/linker/manifest file > Generate manifest file [yes]
- right mouse on ffdshow/properties/manifest tool/input and output > Embed Manifest [yes] (when i tried the default, [no], the ffdshow installer would fail)

ffdshow.ax.manifest can be found in ffdshow/Release after compiling.

However the installer does work, when i try to play some video/audio then i get the R6034 error again (requested by mplayerc.exe)

[bob0r]

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051021/ffdshow-20051021-gcc-test.exe (all files gcc, without sse2)

bob0r's own words.

x264.nl's build ffdshow-20051103.exe is 100% GCC also.

[o2xygen]

What is the best for PIII? I am on PIII coppermine on 1Ghz and supports SSE.
Should I bother with GCC builds? Because most here have AMD processors that doesn't have SSE2... Do we fall in the same boat, or should I stay with ICL instead?

[_xxl]

MMX capable CPU

Intel :

Pentium MMX
Celeron
Pentium II
Pentium III
Pentium 4

AMD :

K6
K6-2
K6-3
Athlon
Duron

SSE capable CPU

Intel :

Pentium III
Celeron 533A and above (with Coppermine core, a.k.a. Celeron II)
Pentium 4

AMD :

New Duron (with Morgan core)
Athlon XP (with Palomino core)

SSE2 capable CPU

Intel :

Pentium 4

AMD :

Athlon 64

ffdshow-20051103.exe gcc sse

[bob0r]

updated VS 2005 project files to work with msvcr80.dll > http://cia.navi.cx/stats/project/ffdshow/.message/6301620

Ahh, enable embeded on ALL files, will compile a working version soon, (when CVS updates) :)

[clsid]

Afaik it is NOT recommended to place msvcr80.dll (and other VS2005 dlls) in the system32 folder. It should either be placed in the app folder or installed as a shared assembly in c:\windows\winsxs.

[bob0r]

Afaik it is NOT recommended to place msvcr80.dll (and other VS2005 dlls) in the system32 folder. It should either be placed in the app folder or installed as a shared assembly in c:\windows\winsxs.

I see so that's why people recommend it to c:\windows\system (Milan and online msvcr80.dll readme.txt files)


Anyways, to all:
http://mirror05.x264.nl/public/ffdshow/msvcr80.dll (for msvc 8.0) copy to c:\windows\system

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-gcc4.0.2.exe (all files gcc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-gcc4.0.2-sse2.exe (all files gcc, and sse2 enabled)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-msvc8.0.exe (all files msvc 8.0)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-msvc7.1.exe (all files msvc 7.1)

Edit 01:
"Wanted to put a ICL 9.0 build here, but ofcourse... it failed.
Will test and report more tomorrow."

Oh it was compiling, i ran out of memory *red face*, fixed page file (was small for some previous tests)

Will update later as libavcodec.dll may still not compile with ICL 9.0, so will mix with gcc 4.0.2 later

These are all test builds, do with them what you want (ffdshow-20051105-gcc4.0.2.exe could be a x264.nl build, but from now on i will only update ffdshow when some notable decoder/encoder updates are made, and if compiling keeps working)

Edit 02:
I have submitted compiling libavcodec.dll with icl 9.0 as bug report, so lets hope this last file, libavcodec.dll, can be fixed compiling with ICL 9.0 too:
https://sourceforge.net/tracker/index.php?func=detail&aid=1349335&group_id=53761&atid=471489

[celtic_druid]

It has always compiled ok here. I use the msvc6 project file though. Didn't know that the MSVC7 project file had release ICL.

[zilexa]

OK I've read part of this topic...

just to be 100% sure:

bobor released a SSE2 optimized version, but CelticDruid says his builds are always iCL. So what is the difference between:
http://m17n.cool.ne.jp/freeware/mpc/ffdshow-20051103.exe

And bobors release?
is ffdshow-20051103.exe (http://m17n.cool.ne.jp/freeware/mpc/ffdshow-20051103.exe) the best for both SSE2 capable CPU's as non-SSE2 capable CPUs?

And is 20051103 a stable version? because on the site: http://m17n.cool.ne.jp/freeware/mpc/ at some builds "stable" is written, and at some nothing is written...

[thuan]

celtic_druid do you patch the lib of your icl to remove the CPU check to make SIMD work on non_Intel CPU?

[Seed]

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-gcc4.0.2-sse2.exe (all files gcc, and sse2 enabled)

I have Pentium 4 (Northwood). So it is the most optimised (fastest) version for my use, isn't it?

[bob0r]

I have Pentium 4 (Northwood). So it is the most optimised (fastest) version for my use, isn't it?

If the Pentium 4 (Northwood) supports SSE2 and you only mean my builds, yes.

celtic_druid's ICL build may be fast too, but when it comes to gcc, yes that build is fastest for SSE2 supporting CPUs.
My ICL build come when ICL is supported by Milan (or at least ICL 9.0), libavcodec.dll fix quote from Milan:

ICL is supported but only in Visual Studio 6. I'll probably
change that soon.



Do note, from now on, if compiling keeps working, i will only update the GCC (no SSE2) version, but when requested, i can built other builds too, that is no problem.

New builds should only come when ffdshow has significant encoder/decoder updates.

[zilexa]

ok...
I see so that's why people recommend it to c:\windows\system (Milan and online msvcr80.dll readme.txt files)
Anyways, to all:
http://mirror05.x264.nl/public/ffdshow/msvcr80.dll (for msvc 8.0) copy to c:\windows\system

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-gcc4.0.2.exe (all files gcc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-gcc4.0.2-sse2.exe (all files gcc, and sse2 enabled)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-msvc8.0.exe (all files msvc 8.0)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051105-msvc7.1.exe (all files msvc 7.1)

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

Here it says the ffdshow-20051105-gcc4.0.2-sse2.exe is SSE2 enabled..
But Drevil_xx doesn't mention this one:

ffdshow-20051105-gcc4.0.2.exe best for non-sse2 cpu's
50-60% cpu H.264 AVC decoder
ffdshow-20051105-msvc7.1.exe
80-90% cpu H.264 AVC decoder

--> So ffdshow-20051105-msvc7.1.exe should be best for SSE2 CPUs and ffdshow-20051105-gcc4.0.2.exe best for nonSSE2 CPU's.
Then what is "ffdshow-20051105-gcc4.0.2-sse2.exe" for?

--> And if I understand correctly, CelticDruids build is good for both SSE2 and nonSSE2, but not the fastest for either one of them.

I would like stable ffdshow, should I choose the optimized versions or stick with Celticdruids ones?

Sorry for so much questions, but so many builds.... I understand testing is neccesary for development... but it would be nice if there was a site were one could find THE ffdshow of the moment...

[bob0r]

celtic_druid's version is ICL, ICL is/was considered less stable, especially on AMD machines, test it yourself.

GCC can/should be as fast or faster than ICL.

ffdshow-20051105-gcc4.0.2-sse2.exe is perfect for CPUs supporting SSE2, but it crashes on CPUs NOT supporting SSE2 (Like my AMD XP 1800+)

ffdshow-20051105-gcc4.0.2.exe is good for NONE-SSE2 CPUs, (should still be faster than CPUs which dont have SSE2 support anyway), but as said above, it might be a slower compared the SSE2 build (depending on how the library uses SSE2, and what SSE2 can do over SSE).

MSVC 7.1 (8.0 probably too) builds are/were considered the slowest of them all.

Best way to find out is to test!

GCC builds can be considered the best when you look at the ratio of speed and stability.

GCC is is the "ultimate" goal, because its free and can be supported very well, as recent development has shown.

As for ONE NEW stable ffdshow build, thats up to the author, but that might be a long time from now.

All i now can say is: TEST TEST AND TEST, and when you find a version that suits you, stick with it!

[signatory]

Thanks bob0r. I experience just what you say, but I can't test on a sse2 machine so will not speak for these (lucky) people.
I like your gcc-none-sse2 builds :) and always liked GCC.

So what is the reason to use MSVC ? just easier?

[Dark_Angel_PT]

(...)

SSE2 capable CPU

Intel :

Pentium 4

AMD :

Athlon 64

ffdshow-20051103.exe gcc sse

You forgot to add the Pentium-M as a SSE2 capable cpu from Intel....

[bob0r]

Thanks bob0r. I experience just what you say, but I can't test on a sse2 machine so will not speak for these (lucky) people.
I like your gcc-none-sse2 builds :) and always liked GCC.

So what is the reason to use MSVC ? just easier?

MSVC was chosen over ICL, as it was more stable.

If the GCC builds are stable, i guess there is no need for MSVC anymore :p

GCC is just as easy/hard as msvc, all you need to do is fix the DirectX SDK header files, then just make SSE2=no from ffdshow/src/ and you are done.

The script i use:
http://mirror05.x264.nl/public/ffdshow/ffdshow_gcc.sh
(for SSE2 support just change "make SSE2=no;" to "make;")
(http://nsis.sourceforge.net/ used to create the ffdshow installer)

Search this thread for a guide how to create the DirectX SDK header files, or click here (http://forum.doom9.org/showthread.php?p=727041#post727041)

[ExtraEye]

what about AMD athlon 64?
mine's supposed to have SSE2 support(and even SSE3)

[canuckerfan]

yea, any chance of an sse3 build? or are those not possible?

[videomixer9]

Problem with ICL is still that even with patching to the libs it's biased by intel trying of misusing their compiler to have better results on benchmarking by not using seperate optimizations trees. ICL builds are usually large because they contain different compiled regions and the optimizations are selected when the apps runs. For anything but Pentium CPUs this selection mechanism selects in disadvantage for the CPU, even if the libs are patched to remove thus checks it misses patching on the total end result. Thus ICL should imo die in hell, MS at least doesn't use such a selection mechanism but is generally slower.

GCC is a total free compiler and optimizes for any CPU without any bias to give a specific company a better benching result or whatever. That's why for anything but P4 GCC builds are the best to choose, they support any optimization and many libs are actually programmed to be compiled with GCC and use specific switches as seen with libavcodec. GCC was a quite slow compiler in the past, however since those versions many things changed.

So generally I'd see GCC as the default compiler for ffdshow and the libs, and I think that Milan wants it to be like this too. Optimizing ffdshow for ICL compilation is imo wasted time ... not like sane ppl that assemble their PCs themselves would buy Intel anyways, only stupid bought companies like Dell or HP still do ...

GCC support SSE3 optimization too, but I doubt that libav etc. already make much use of this, even though GCC supported SSE3 even before ICL.

[canuckerfan]

would it be possible to have a build which supports SSE AND SEE2? or is it useless since SSE2 is superior?

[zilexa]

Thanks a lot, it is all clear now! I will keep my eye on x264.nl for new versions of the GCC nonSSE2 and SSE2 builds.
unfortunately sites like afterdawn.com and freecodecs.com don't give the info about the different builds. That was why I liked to know more. now I know :)

[clsid]

ICL is very similar in speeds to the recent GCC builds, even on AMD cpus. And CelticDruid's last ICL build is rock stable.

I agree that GCC is the way to go in the (near) future, but atm I prefer ICL because it is more compatible with non SSE cpus like my thunderbird.

[Egh]

ICL is very similar in speeds to the recent GCC builds, even on AMD cpus. And CelticDruid's last ICL build is rock stable.

I agree that GCC is the way to go in the (near) future, but atm I prefer ICL because it is more compatible with non SSE cpus like my thunderbird.

Exactly. As I mentioned before, I don't really see now any serious difference in speed between ICL and GCC builds. Actually, same goes even for previous speed winner aka hybrid build "msvc .ax + gcc .dlls". All three types are somewhat equal in speed on Athlon XP CPU.

About stability issues -- ICL builds instability imo is just like UFO -- everybody talks but no one actually seen :) As for myself, I never seen any instability in ICL builds which could be attributed to build itself, not to a particular bug in ffdshow.

BTW, note that it's not entirely correct to consider Celtic's builds to be purely ICL. Some parts are gcc there.

So, now to simply put it, it became irrelevant which compiler to use for .ax itself. Whenever it's MSVC, ICL or GCC, speed and stability are pretty much same. Compiling dlls is another matter though, and still needs more testing. Though plain msvc dlls are of course big slowdown.

@ some newbies who asked about ICL: the point of using ICL might be in the fact that according to some year old or so tests ICL builds fastest code for Intel CPUs, at least considerably faster than MSVC. Whenever gcc reached same level of optimisation by now, I have no idea. But agree that ideally builds for common purposes should use gcc simply to use free compiler.

[videomixer9]

Of course the .ax doesn't matter much for the overall speed, decoding is mostly done by libavcodec and most filters etc. should be in the libmplayer or some other dlls. Though I dunno about copy operations etc. done by the .ax to get the actual video into the dshow filterchain.

Important is, e.g. on celtic_druid builds, for the plain decoding performance, that libavcodec is still compiled with GCC. libavcodec is written to be compiled with GCC and has many by hand optimizations for the specific CPU features, thanks to those by hand optimizations it is similar in speed with many compilers, however those routines may be broken or not initialized by other compilers but GCC, thus you get a drop in speed if managed to compile with other compilers.

[oddball]

ffdshow audio decoding annoyances.

When decoding Ogg or AAC 5.1 from MKV it does not have an option to send to SPDIF as a resampled and transcoded signal. Instead you have to set those options for all PCM output which is a bit crap as you then have 2.0 PCM from everything transcoded. I like to avoid downsampling wherever possible, but I put up with it for a 5.1 Ogg or ACC encoded movie as I prefer to have the surround.

All it needs is a drop down option like AC3 and DTS have under the audio codecs section to allow those codecs to be output seperately to SPDIF as resampled and AC3 transcoded where 5.1 is detected.

[Egh]

Of course the .ax doesn't matter much for the overall speed, decoding is mostly done by libavcodec and most filters etc. should be in the libmplayer or some other dlls. Though I dunno about copy operations etc. done by the .ax to get the actual video into the dshow filterchain.


Heh, "of course" is "of course, but in theory". :P In practice, as you can see both in this thread and on the ffshow bugtracker, there were several issues (mosly badly initialized constants and stuff) which caused terrible slowdown in some operations (colorspace conversion, resizing, spp deblocking) if plain gcc build was used. And they were all magically cured if main .ax was changed into msvc and all libs remain same aka gcc :P

It seems that now all those issues were corrected by Milan. That's why we say there's practically no evidence to suggest any serious difference in speed [or stability] on playback amongst three common types of builds (celtic hybrid, plain gcc, msvc + gcc hybrid). And if some difference there is, it's most likely could be caused by similar problems with code, and can be corrected.

[Egh]

ffdshow audio decoding annoyances.

When decoding Ogg or AAC 5.1 from MKV it does not have an option to send to SPDIF as a resampled and transcoded signal. Instead you have to set those options for all PCM output which is a bit crap as you then have 2.0 PCM from everything transcoded. I like to avoid downsampling wherever possible, but I put up with it for a 5.1 Ogg or ACC encoded movie as I prefer to have the surround.


Use AC3 filter for straight SPDIF output from AC3 (and decoded vorbis and aac streams by ffdshow) :)

As for PCM output, I don't understand your worries. I like to avoid downsampling <-- WHERE do you see any downsampling with PCM output ?

Btw I personally even use 32bit PCM output from ffdshow audio. It doesn't slow down anyway :P

[oddball]

AC3 and DTS are handled by ffdshow fine. The problem is with ANY PCM material. I do not want any PCM material sent to SPDIF via transcoding to AC3 'except' Ogg 6 channel and AAC 6 channel. If I set manually to get both those formats to output to 6 channel AC3 via SPDIF it does it for *ALL* PCM codecs including MP3 etc.

[bob0r]

would it be possible to have a build which supports SSE AND SEE2? or is it useless since SSE2 is superior?

Not possible, because when you enable SSE2 the ffdshow build will crash on CPUs not supporting SSE2 (i guess the ffdshow developer(s) may have to code something like CPU detection)

Thanks a lot, it is all clear now! I will keep my eye on x264.nl for new versions of the GCC nonSSE2 and SSE2 builds.
unfortunately sites like afterdawn.com and freecodecs.com don't give the info about the different builds. That was why I liked to know more. now I know :)

On x264.nl i will only update and mirror GCC SSE builds (not SSE2).
In this thread you can request SSE2 (and other) builds, and pray someone will compile it for you :D

sorry for the wrong post...
...

You can delete messages by hitting Edit.

[ExtraEye]

i have the ffdshow-20051105-gcc4.0.2-sse2.
since i have an amd athlon 64 i understand from your explanations that this build will be best for me.
unlike on celtic druid's build i expirience a couple of problems with that build.
first is using the avisynth filter crashes player(fixed once filter was disabled).
secondly, using crystality produces a wierd sound with no conection to the played content. even if all the filters in it where reduced to 0 the sound stayed(fixed when disabled).

that's about it for now.
thx for the great work bob0r

[bob0r]

Milan is going too fast for me http://cia.navi.cx/stats/project/ffdshow

ffdshow-20051107.exe online (see signature)

Compiled files up to:
17:55 on Nov 07, 2005
"fixing presets page"
http://cia.navi.cx/stats/project/ffdshow/.message/6323763

Main reason for update:
21:27 on Nov 06, 2005
"use SSE math in GCC build"
http://cia.navi.cx/stats/project/ffdshow/.message/6313663

All files gcc 4.0.2 (SSE2 Disabled)

Enjoy.

[SeeMoreDigital]

Excuse me for my ignorance but do any of the new FFdshow builds offer (6Ch)WMA Pro to (6Ch) AC3 transcoding?


Cheers

[Thomas_AR]

Quote:
Anyways, to all: http://mirror05.x264.nl/public/ffdshow/msvcr80.dll (for msvc 8.0) copy to c:\windows\system

Questions:
1. Why not (WinXP) to the system32 folder? All 'Microsoft® C Runtime Library' dll's - up to version 7 - are in that folder, not in the system folder.
2. Does ffdshow need this runtime dll, and if yes for what?

[clsid]

http://blogs.msdn.com/martynl/archive/2005/10/13/480880.aspx

[Inventive Software]

@SeeMoreDigital: At a guestimate, no. WMA Pro is essentially WMA 9 with extensions. ffdshow doesn't support WMA 9.

Your best bet is to WAV it, then encode to AC3. Hope this helps.

[SeeMoreDigital]

@SeeMoreDigital: At a guestimate, no. WMA Pro is essentially WMA 9 with extensions. ffdshow doesn't support WMA 9.Shame....

Some of the beta versions of AC3Filter provided support for WMA9Pro-to-AC3 transcoding.... And while I'm not a big fan of Windows Media codecs, it would be quite handy to see the feature incorporated ;)


Cheers

[stephanV]

Excuse me for my ignorance but do any of the new FFdshow builds offer (6Ch)WMA Pro to (6Ch) AC3 transcoding?


Cheers
If you set ffdshow to also handle uncompressed audio, maybe it would work. It will then normally connect itself to the audio decoder in the filter graph.