New ffdshow build (?)

[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.