New ffdshow build (?)

[Egh]

IT IS NOT ffdshow.ax problem!!! See there, i tested it.

http://sourceforge.net/tracker/index...61&atid=471489

It's either bad compilation of libmplayer.dll, or there was some kind of bad code around that time.

I got hold of 0922 build of that dll with different size, and now it works nicely (and the size is similar to the one used in 0909 build, aka 370kb).

Both other versions (140kb and 470kb) failed, cpu load really crazily increases (dozens of per cent)

[celtic_druid]

Yeah, I don't know what I did with libmplayer. I just rean make clean && make and got a 363k dll instead of the 464k one packaged.

[bob0r]

@CD:
Okay, does this mean i should wait putting 0920 up?
Also, you compile it with gcc now? no more MSVC?

[celtic_druid]

The only part I ever compiled with MSVC was ffdshow.ax in some builds. Everything else was always ICL or gcc. This time I compiled libavcodec with ICL/gcc and screwed up libmplayer.dll. Previously I compiled libavcodec with gcc only and libmplayer was (to my knowledge) ok. I replaced the installer on my server with one containing a different compile of libmplayer which should be ok.

[dimzon]

Originally Posted by celtic_druid

The only part I ever compiled with MSVC was ffdshow.ax in some builds. Everything else was always ICL or gcc. This time I compiled libavcodec with ICL/gcc and screwed up libmplayer.dll. Previously I compiled libavcodec with gcc only and libmplayer was (to my knowledge) ok. I replaced the installer on my server with one containing a different compile of libmplayer which should be ok.

Your build dos not include libfaad2 again

[bob0r]

Originally Posted by celtic_druid

The only part I ever compiled with MSVC was ffdshow.ax in some builds. Everything else was always ICL or gcc. This time I compiled libavcodec with ICL/gcc and screwed up libmplayer.dll. Previously I compiled libavcodec with gcc only and libmplayer was (to my knowledge) ok. I replaced the installer on my server with one containing a different compile of libmplayer which should be ok.

Yes, because MSVC did less crashing on AMD machines no? Slower but more stable. Is this still the case? If so can you please fix us a stable version too (which ill mirror) and look at what dimzon said

As most people have no clue what your site is, including me, can you please fix them up to your mirror05 dir too?
Edit: about the link, i see its http://m17n.cool.ne.jp/freeware/mpc/ (i hope)

[Egh]

Thanx.

"fixed" build works. At least doesn't produce the problem same as "nonfixed" one.

[clsid]

ICL9/GCC/MSVC71 builds of current CVS:

http://www.megaupload.com/?d=3DGNRTNL

[celtic_druid]

You can always use libfaad from an older build. Nothing has changed. I just forgot to compile it and uncomment the faad line from the installer.

[Mug Funky]

not sure, but i think uyvy decoding in ffdshow is b0rk when decoding to yuy2 in avisynth. chroma comes out fine, luma comes out twice the width, interleaved with flat grey samples. avisynth reports the resulting pitch as 1440 instead of 720.

also, yv12 output with uyvy input will use progressive downsampling (which i guess isn't really a bug)

[edit]

disregard that... i installed the latest build and all's well. false alarm (i'm all happy now )

[bob0r]

Originally Posted by celtic_druid

You can always use libfaad from an older build. Nothing has changed. I just forgot to compile it and uncomment the faad line from the installer.

But thats what i want to put online, a complete, as stable as possible, working ffdshow installer, so when people uninstall an old version, the new version should work the same or better.
So please create us a complete ffdshow installer

[dimzon]

Originally Posted by bob0r

So please create us a complete ffdshow installer

[Inventive Software]

I'll grab the sources and see if I can compile it myself. It will be interesting to see if me and celtic_druid and the other compilers get the same results!

[Egh]

Finally right comment! :P

>Comment By: Milan Cutka (milan_cutka)
Date: 2005-09-23 20:50
<b>
Message:
Logged In: YES
user_id=547197

When libmplayer.dll is build with ICL or MSVC no MMX nor
SSE optimized code is used. That's why resulting binary is
much slower.</b>

So, ppl, just don't build that library with those compilers :P
But i wonder, do you use optimisations in other builds?

I use SSE optimised one (but the library is still should be used from gcc complilation!)

[movax]

I build libavcodec, libmplayer, and the other projects except a52 with GCC 3.4.3, and ffdshow.ax with MSVC 2003. A few resultant archives laying around from cccp stuff is here.

[yaz]

Originally Posted by movax

I build libavcodec, libmplayer, and the other projects except a52 with GCC 3.4.3, and ffdshow.ax with MSVC 2003. A few resultant archives laying around from cccp stuff is here.

two (stupid) questions :
- how to install packs like that ? they are just series of dlls. should i register each by hand ?
- what are that extra files in your packs ? (say, flt_ffdshow.dll, aso)

thx
y

[Jalavera]

@Celtic_druid:
Why NOT all versions in News section from http://celticdruid.no-ip.com/xvid/ ARE NOT downloadable (eg. DVDMenuXtractor v0.9.10, mpeg4iptools 1.3.6cvs, ...) ??? and others YES.

[Sharktooth]

Coz i forget to mirror those folders
The files are being uploaded...

[Jalavera]

Originally Posted by Sharktooth

Coz i forget to mirror those folders
The files are being uploaded...

Oh, thanks!! Now I see them ....

[movax]

Originally Posted by yaz

two (stupid) questions :
- how to install packs like that ? they are just series of dlls. should i register each by hand ?
- what are that extra files in your packs ? (say, flt_ffdshow.dll, aso)

thx
y

That was just a complete rar for testing purposes, you should use an installer if you plan on using it as your main decoder. (regsvr32 ffdshow.ax will suffice most of the time, rundll32 ffdshow.ax,configure, rundll32 ffdshow.ax,configureAudio, and rundll32 ffdshow.ax,configureEnc for configuration).