New ffdshow build (?)

[Blkbird]

Since the ffdshow thread has been closed, I've having trouble finding information about new builds. Maybe this thread could serve that purpose.

[Sirber]

http://www.aziendeassociate.it/cd.asp?dir=/ffdshow

[CiNcH]

Guess he was asking for information on those builds, like changelogs aso.

[bourtzovlakas]

http://m17n.cool.ne.jp/freeware/mpc/

[Blkbird]

http://m17n.cool.ne.jp/freeware/mpc/

Thanks for that, but a list of comments from a version control system is about the worst kind of changelog - hardly better than none at all. No non-developer can read that kind of stuff. So what I look for is really those human-readable sentences about what has been changed (that affects user in a noticable way), as they were reported in the old ffdshow thread.

[bond]

there is no such changelog for development builds available afaik

[celtic_druid]

Most are pretty self explanatory anyway, like:
MMX libtheora postprocessing
experimental DV output
updated libavcodec

[Shirokuu]

Changes made to the updated libavcodec library (which is incorperated in ffdshow) can be found here (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFMpeg). Posted just for your convenience.

[Blkbird]

Appearantly there has been a recent fix for some subtitle issues (which I have). But I can't find any build newer than 20050803. Anyone?

[Tirges]

What the difference between:
ffdshow-20050822.exe & ffdshow-20050822MSVC71.exe

Does one (or the other) explicitly need MSVC71.dll ? Or not, as it's included in the build or something?

[Liisachan]

Appearantly there has been a recent fix for some subtitle issues (which I have). But I can't find any build newer than 20050803. Anyone?
I mirrored it already, right after celtic_druid compiled ffdshow-20050822.exe

I was too lazy to post about that, but you can check
http://ffdshow.faireal.net/

Afaik, ffdshow-20050822.exe & ffdshow-20050822MSVC71.exe = the same code, different compilers (ICL vs. VC), there might be speed difference.
Also, altho this should be rather exceptional or accidental, IIRC there was at least one file in the past that doesn't play with the ICL version but does play with the MSVC version of ffdshow.

[Koti]

Appearantly there has been a recent fix for some subtitle issues (which I have). But I can't find any build newer than 20050803. Anyone?Here (http://forum.doom9.org/showthread.php?p=698124#post698124)

What the difference between:
ffdshow-20050822.exe & ffdshow-20050822MSVC71.exe
Does one (or the other) explicitly need MSVC71.dll ? Or not, as it's included in the build or something?
Here (http://forum.doom9.org/showthread.php?p=702556#post702556)

[Tirges]

Ah, thanks!

As I take it: if errors occur, try the MSVC version, might be slower but probably more stable (especially on AMD's...)

[bob0r]

Ah, thanks!

As I take it: if errors occur, try the MSVC version, might be slower but probably more stable (especially on AMD's...)

Agreed, just tested ffdshow-20050822.exe and it crashes mpc with my x264 encodes (AMD XP 1800+ CPU).
With ffdshow-20050822MSVC71.exe no playback problems.

NOTE: ffdshow-20050822.exe on x264.nl is really ffdshow-20050822MSVC71.exe (i just renamed it for layout and general purposes, like stability comes first) !

[Liisachan]

Is the file in question AVC-in-AVI? Or does the same happen for MP4 too? Are there any known 'risky' x264 options? FAQ says Pyramid + Older decoder = doesn't work, but that should be fixed by now. Another report I read was about RDO + Exhausitive
http://forum.doom9.org/showthread.php?p=680780#post680780
Anyone knows any specific options in x264 that ffdshow doesn't like?

[Sharktooth]

high profile stuff...

[Liisachan]

Which options in High Profile? I've tested quite a few AVC files in MP4 with --analyse all --8x8dct (and --bframes 6 --b-pyramid --ref 15), but all of them play fine with the latest ffdshow ICL version. (Although, QuickTime 7 apparantly doesn't like High Profile if complicated)

[Koti]

Anyone knows any specific options in x264 that ffdshow doesn't like?

custom matrices , aside from that it does well I think

[Liisachan]

custom matrices But that's not a bug, but just a known limitation of the current version of ffdshow, isn't it?

aside from that it does well I think Indeed, that's my experience too.

But my experience is still limited, and there seem to be some more complicated options that advanced users are testing... x264.exe has really many switches.

[LigH]

But not enough! (Still missing "-interlaced".) ;) ;)

[Koti]

But that's not a bug, but just a known limitation of the current version of ffdshow, isn't it?
True - Nero does decode, but it's a option ffdshow doesnt like yet.
But not enough! (Still missing "-interlaced".) ;) ;)
Dang , forgot about interlaced since it's not in x264 encode options ( or is it and I missed it ? ) but is spec'd in avc hp.

[LigH]

AFAIK (and bond confirmed), x264 does not yet provide interlaced encoding (Ateme does). But that's already mentioned in the thread about "x264 development"...

[Mug Funky]

interlaced would be a cool thing to have...

[celtic_druid]

Just noticed this: http://cutka.szm.sk/files/ffdshow-20050828.exe
I'll try and put up a new build tonight though, Been a lot of changes since the last one.

[azsd]

downloaded~~thx
the upcoming one with x264 decoder's CQM support?

[celtic_druid]

x264 doesn't have a decoder, it is for encoding only and it already supports CQM's in ffdshow for some time. AVC decoding in ffdshow is done via libavcodec which doesn't support CQM decoding.

http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/h264.c?cvsroot=FFMpeg
When you see CQM decoding support there, then libavcodec supports it and it can be added to ffdshow.

[Liisachan]

Just noticed this: http://cutka.szm.sk/files/ffdshow-20050828.exe
This build is buggy for me.
(1) MP4 (x264) plays too fast. Unusable.
(2) BSPlayer crashes for MKV: BSPlayer is buggy anyway, I don't like it, but I just keep testing it. It should play MKV if you use Haali's splitter (not Gabest's), but it doesn't.
--
Those 2 problems are gone if I reinstall 20050822 back.

[Egh]

Well, according to changes in last weeks milan cutka was mainly doing 64bit enhancements. So i guess that 28th august build is testing-only indeed, unless he used an older source for it.

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

Date: 2005-08-29 05:06
Sender: milan_cutka
Logged In: YES
user_id=547197

Disabling YV12 works for me. Try this build: http://cutka.szm.
sk/files/ffdshow-20050828.exe

and more importantly, from the same day:

Date: 2005-08-29 16:36
Sender: milan_cutka
Logged In: YES
user_id=547197

Sorry for the h.264 problems. I forgot to remove code intended
only for development purposes. Fixed now.

[celtic_druid]

Well cvs builds are always potentially buggy. Not sure if I will have time to put up a new build tonight. New mplayer/mencoder builds are up though.

[Liisachan]

Okay, I commented out the link on the 'mirror' site.
This build doesn't seem to be meant for wide use, and nothing good will come out of it if betanews.com/free-codecs.com etc. find it.
Thanks for the cautions.

[azsd]

sorry,I had read hellfred's posts yesterday and misunderstand it's added in mplayer (mplayer use libavcodec as x264's decoder,the same of ffdshow)

[celtic_druid]

[2005-09-09]

SIMD softlight
UINT8->uint8_t
VYUY support in XviD colorspace conversion routines
better support for 8 bit palettized images input in VFW
correct MMX SAD
don't use shuffle instruction in 3dnow! code
dotproduct.asm
successfully compiled 64-bit version - untested
updated libavcodec, x264
don't always enable YV12 output in VFW mode
fallback C idct and fdct for DCT filter
few 64-bit compatibility fixes
a step closer to x64 build
don't crash with zero delay in dolby decoder
few vobsub fixes,
fixed YUY2 levels crash
updated libtheora to alpha5
updated vs 2005 project
working on avc in mpeg support
x264 patches from Sharktooth's builds
2xSai and hq2x resizers
Don't try to always get output buffer size for audio samples - use last known value. Should fix compatibility problems with some applications, hopefully won't break other.
libtheora decoder supports radlight parser
maybe not very useful and not fully correct but: h.263 and mpeg quantization and dequantization in DCT filter
aspect ratios in OSD
display current quantization matrices when available
use xcm extension for supplied quantization matrices,
cqm extension support
updated libavcodec
updated VS 2005 projects

[Inventive Software]

Anybody know where I can get the sources for the builds Celtic_druid so kindly provides? I'm keen to look into them and see what's there...

[celtic_druid]

View here:
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/

To get:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffdshow login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffdshow co -P ffdshow

or cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffdshow co -P -d"2005-09-09" ffdshow if you wanted the exact sources for 2005-09-09 and the cvs had been updated since.

[moonman]

ffdshow 2005-09-09 mirrored here (http://svartling.hopto.org/index.php?q=2005/sep/ffdshow-2005-09-09) .

[Chaos Creator]

It seems to be something wrong in ffdshow with theora! I am doing a 2 pass encode and no matter what value I choose for the filesize in the second pass, I always end up with videos that have the same exact filesize! There is no problem with previous releases of ffdshow!!! The only reason that I use the latest ffdshow 20050909 is because it has theora-alpha-5 in it!!!

Sorry for my bad english!

[azsd]

IMHO the -d"2005-09-09" options will only put newest (2005-09-15) source into overided "2005-09-09" folder,it can't do a snapshot from 2005-09-09

[celtic_druid]

Yeah, should be -D2005-09-09.

[hellfred]

It seems to be something wrong in ffdshow with theora! I am doing a 2 pass encode and no matter what value I choose for the filesize in the second pass, I always end up with videos that have the same exact filesize! There is no problem with previous releases of ffdshow!!! The only reason that I use the latest ffdshow 20050909 is because it has theora-alpha-5 in it!!!

Sorry for my bad english!
For encoding videos with Theora codec on win32, one can use ffmpeg2theora, too. It will take any input video supported by libavcodec in quite a lot of containers. If you want to give it at try, get it here (http://www.v2v.cc/~j/ffmpeg2theora/) .

Hellfred

[Chaos Creator]

I want to use ffmpeg2theora but it doesn't accept AVS files and it doesn't support 2-pass!!! :( :( :(
AviSynth support in our days is a must have, I believe!

[celtic_druid]

2nd pass filesize set to 5,000kB
results:
avi = 5,014kB
ogg = 5,042kB

2nd pass filesize set to 2,000kB
results:
avi = 2,154kB
ogg = 2,161kB

Seems to be working ok to me.

[Chaos Creator]

For me:

2nd pass filesize set to 8,192kB
results:
8,164

2nd pass filesize set to 12,288kB
results:
9,116

2nd pass filesize set to 10,240kB
results:
9,116

2nd pass filesize set to 20,480kB
results:
9,116

2nd pass filesize set to 5,120kB
results:
5,136

I tried many different filesizes! It seems that if you set a filesize that ffdshow thinks is much more than needed, then it cut it down to what it believes that is better, but the quality of video is always bad!!!! :confused: :confused: :confused:

[LigH]

Do you understand the meaning of "saturation"? 9,116 KB seems to be the size for a constant lowest-possible quantization, therefore maximum quality possible. So, try to compare with CQ more if the results are similar -- if not, then it may indeed be wrong.

[Chaos Creator]

Do you understand the meaning of "saturation"? 9,116 KB seems to be the size for a constant lowest-possible quantization, therefore maximum quality possible. So, try to compare with CQ more if the results are similar -- if not, then it may indeed be wrong.

I will post some frames to see your self!!! ;)

[LigH]

Would be nice.

And, BTW: Please, don't misunderstand me - sometimes I sound a bit demanding, but just accidently, I'm not a native english speaker...

[Chaos Creator]

Hey, I am not a native english speaker either!!! :D
I didn't misunderstood you!

Ok, let's see!!!

Source
Source (http://img310.imageshack.us/img310/8117/source9gg.png)

--------------------------------------
Filesize Set to 20,480
Actual filesize 20,496
encode1 (http://img310.imageshack.us/img310/5294/204802vj.png)

--------------------------------------
Filesize Set to 25,600
Actual filesize 23,368
encode2 (http://img310.imageshack.us/img310/3777/256002tp.png)

--------------------------------------
Filesize Set to 30,720
Actual filesize 23,368
encode3 (http://img310.imageshack.us/img310/1899/307205bt.png)

Yes, the last two results (which have the same exact actual filesize) are similar! It seems that we have the maximum quality possible!
Then the only thing I've got to say is that I am really dissapointed from the quality! :( :( :(
The first time I saw all this detail to go away, I thought that I've done something wrong!!!!

[movax]

That loss might be what it looks at max quality or whatnot...you still don't want to saturate the codec. Try using some filters to fix it up instead.

[Chaos Creator]

That loss might be what it looks at max quality or whatnot...you still don't want to saturate the codec. Try using some filters to fix it up instead.

I wanted to see how good can this codec compress a video! Using filters to saturate more, is not an option for me! I don't like to put filters in my dvd backups for any reason! I really prefer to wait a year or two of development and see the codec to encode better and to keep more detail on its own!! I know, it might sound strange what I am saying, but that's me!!! ;)

[Chaos Creator]

I tried to make some videos with ffmpeg2theora 0.15 with (--videoquality 10) and the video quality I got was really great! I think now that there must be something wrong with ffdshow. Maybe in the 2-pass mode it provides! Ffdshow doesn't keep any quality, even at highest filesize I set to it. Ffmpeg2theora gave me great results!!!

[Liisachan]

celtic_druid's 20050920 is out.

I got 500GB/mo bw for this mirror, but (it's a darn cheap server and) might be slower.
http://ffdshow.faireal.net/

This server might be faster, tho the bw is more limited here:
http://m17n.cool.ne.jp/freeware/mpc/

[movax]

I just compiled a ffd yesterday for the CCCP, waiting on test reports on that one to see how it turned out. :) And I can provide a 300GB/mo, avg. 500kb/s mirror if you really want one.

[Liisachan]

You can mirror the files.
That is your right, not your duty.
Those are free software.

[Egh]

I wouldn't haste too much to upgrade to a newer build (0920).

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

I experienced problems with h264 playback, and according to log, several fixes were applied to that part of the ffdshow, as i recall. Maybe it's only due to some optimisations not working or so (athlon xp cpu). But 0920 does play same video fragment encoded in avc noticable slower than 0909 does (or at least on my system it did), so I rolled back to 0909 atm.

[celtic_druid]

Well for 0920 I am testing icl/gcc for libavcodec. As a rule I just use gcc. If it turns out to be slower I will simply switch back.

[clsid]

Here are some alternative compilations:

http://www.megaupload.com/?d=QZCV2JJ8

Comments on stability and speed are very welcome. Don't forget to mention your cpu brand, type and clockspeed.

[bob0r]

Mirrors aren't really a problem.
I got plenty on x264.nl

ffdshow-20050920.exe is a big file again, i assume its ICL?
Can you compile a MSVC71.exe version again too?
I really prefer stability over speed.


Creating x264 revision 295 test files now (.avi/.mp4/.mkv/.264)

[movax]

Well for 0920 I am testing icl/gcc for libavcodec. As a rule I just use gcc. If it turns out to be slower I will simply switch back.

In the past week or two, bug reports have come floating in about module violations in ffdshow.ax, which have been fixed by going to the libavcodec.dll full, not the libavcodec_dec.dll. As of 9/18 or so, it still seems to borkened. Not too big of a deal really, except adding 500kb of filesize + the encoders.

[Liisachan]

clsid: How can I download the RAR file from that page? Nothing happens for me. I'm on Firefox and JavaScript is enabled (but Flash is disabled).

bob0r: My problem is huge sites such as betanews.com direct-link to my poor pages, hogging the servers' resources. They should link to powerful servers like yours. I got a cheap virtual dedicated server for this but it's not powerful enough. Maybe I should get a real dedicated server. big ouch money-wise...

[celtic_druid]

I just pressed the press here to download button and it worked. Had to wait ~45secs first though.

[Liisachan]

Worked. :) Testing...

[Egh]

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

http://sourceforge.net/tracker/index.php?func=detail&aid=1296582&group_id=53761&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]

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 :devil:

[bob0r]

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]

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 :thanks:

[dimzon]

So please create us a complete ffdshow installer :thanks:
:thanks: :thanks: :thanks: :thanks: :thanks: :thanks: :thanks:

[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 (http://movax.org/s/).

[yaz]

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 (http://movax.org/s/).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]

Coz i forget to mirror those folders :(
The files are being uploaded...
Oh, thanks!! Now I see them ....

[movax]

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

[Kostarum Rex Persia]

celtic_druid,can I ask you something? Now,ffdshow doesn't support custom quantization matrices,but do you planing to add support for it,in the newer builds?

[celtic_druid]

Assuming you are talking about AVC decoding. I already answered this somewhere around here.

ffdshow will support decoding AVC CQM's when libavcodec supports it.

[clsid]

Updated compilations:

http://www.megaupload.com/?d=UF9N98C5

[celtic_druid]

Are the unicode and encoder changes finished? Because there have been a fair few major changes lately. I would wait until they are finished before trying a new build.

[PeterPan]

Hi,

I doen't know if this is the right thread, but I will try to ask here.


I use ffdshow with Microsoft Stream Buffer Engine (SBE)
in Meedio. It works fine.
The only problem i have, is to ff/rew in the Timeshift
buffer.

Do ffdshow support the IStreamBufferMediaSeeking-Interface?

[Liisachan]

The new files (ffdshow-20050930.exe, ffdshow-20050930MSVC71.exe) by celtic_druid are mirrored here (http://ffdshow.faireal.net/). Happy testing :)

[mOOb]

Playback seems fine but vfw portion is crashing in everything.

[Liisachan]

ff_vfw.dll is buggy for me too.
example: VirtualDub -> Video -> Compression -> ffdshow Video Codec = Crash

[bob0r]

ff_vfw.dll is buggy for me too.
example: VirtualDub -> Video -> Compression -> ffdshow Video Codec = Crash

Confirmed.

I was about to mirror it, but lets wait a bit now.

Also x264 revision 307 has artifacts in playback, it could be the encoder, but it could also be libavcodec decoder needing an update.

Edit:
the x264 revision 307 problem comes from x264 itself, at least thats what i understand.

So we just need a stable ff_vfw.dll, untill i mirror it, in meanwhile, you may all suffer the bandwidth :sly:

[Sharktooth]

mirrored

[Egh]

But iirc one can easily change the dll for that build from previous one?

Tested newer build -- doesn't have that problem which [unfixed] 0920 had. And it's vfw decoder works also fine (so you can watch avc stream in vdub).

UPDATE:

Tried dll from eariler builds. It still crashes. So I guess the problem is not dll here at all.

[bob0r]

..
UPDATE:

Tried dll from eariler builds. It still crashes. So I guess the problem is not dll here at all.

What build may that be?

ffdshow-20050909.exe ff_vfw.dll = ok
ffdshow-20050909-MSVC71.exe ff_vfw.dll = ok
ffdshow-20050920.exe ff_vfw.dll = ok
ffdshow-20050920-fixed.exe ff_vfw.dll = ok

ffdshow-20050930.exe ff_vfw.dll = virtual dub 1.5.10 crash
ffdshow-20050930MSVC71.exe ff_vfw.dll = virtual dub 1.5.10 crash

builds by celtic_druid

[Egh]

I tried build from 0921 movax rar. I'll try now from 0920 cd's one.

[obieobieobie]

I notice that there's nothing to choose under postprocessing -> h264 postprocessing.. Before one could choose among different things via a drop down-menu but with the september 20th build (fixed) by cd, the menu doesn't contain anything.

[madman1980]

How much slower is the mscv version? Is it really significant?

[clsid]

I find it significantly slower on my AMD Thunderbird 1.33 Ghz. Specially for decoding H.264.

[Kurtnoise]

@Celtic_Druid: may I suggest you to create a decoder only package ? I've seen that there is already a bat file to build this in the sources. Thanks...

[movax]

The libavcodec_dec was borked at least 2 weeks ago, causing module violations often while playing back AVC content, don't know if that's been fixed. And the H264 dropdown menu should have reappeared now I think, Milan said he broke it accidentally while working on other things. :)

As for the ff_vfw bug, my 921 package seems to function without and borks. Perhaps a change to libavcodec or the ffdshow.ax might be causing the borks.

[Egh]

The libavcodec_dec was borked at least 2 weeks ago, causing module violations often while playing back AVC content, don't know if that's been fixed. And the H264 dropdown menu should have reappeared now I think, Milan said he broke it accidentally while working on other things. :)

As for the ff_vfw bug, my 921 package seems to function without and borks. Perhaps a change to libavcodec or the ffdshow.ax might be causing the borks.

I honestly didn't notice any bugs on h264 playback. As for ff_vfw.dll, yeah i think it's not what causing those crashes, it's the change somewhere in another module.

Movax, do you have any newer builds?

[movax]

I'll make one now. (Link (http://www.filefarmer.com/movax/s/ffdshow20051002.rar))
The GCC compiled components are of course in /gcc. It'd be interesting to see how those fare on a SSE system, as I've heard that they don't function at all on a plain SSE system. (Any system that lacks SSE2 in fact).

[Egh]

I'll make one now. (Link (http://www.filefarmer.com/movax/s/ffdshow20051002.rar))
The GCC compiled components are of course in /gcc. It'd be interesting to see how those fare on a SSE system, as I've heard that they don't function at all on a plain SSE system. (Any system that lacks SSE2 in fact).

OK, let's see. In fact I tried to use one of SSE builds (iirc it was 09 21-22 from clsid), it worked fine.

Update: I might be imagining things, but it could be that GCC version actually plays even *slightly* smoother (quite subtile difference) than celtic's builds on my pc. I hope that those file put in "gcc" subdir are gcc compiled, of course.

And as usual, no problems with SSE only CPU. I use my own test to check that. Quite powerful CPU eater -- my own version (marginally better than Fluffy's in some scenes^^) of Hellsing Ultimate OVA trailer. 704*480 avc (by nero) high profile + AC 448kbps sound. And picture correction is "on" in ffdshow (eats several % of cpu), plus VMR9 used (also eats some % compared to overlay), high quality conversion to RGB is enabled (and output is in RGB, ofc). And the last but not the least -- software resizing and AR correction in ffdshow (bicubic). All is smooth, and it's only 1800+ :P

Update2:

weeeeeeeee!!! The problem "compression dialog opening crash" has dissappeared!!!

Moreover, the two month old (at least i first noticed it in 0820) bug in huffman encoding routine is no longer there!!! (it used to crash on the first frame).

[major_kerensky]

Hi

I am having problems with AC3 Playback since installing ffdshow-20050930. The sound is "stuttering", it is somewhat difficult to describe. The strange thing is that I don't even use ffdshow to decode AC3 - I pass it directly to my DD-amp via SPDIF via the appropriate option in Media Player Classic. But since the problem started right after updating ffdshow it seems like a safe bet to seek the problem there. Are there any know problems with current builds ? Is it safe to try a downgrade to an earlier version ?

Bye

[obieobieobie]

Thanks for the info on the h264 pp in ffdshow issue, movax

[movax]

@obieobieobie, no problem :)

@major_kerensky, are you sure ffdshow did not take over ac3 decoding after you upgraded? Even if it did, I believe it has an option for SPDIF out.

[clsid]

Originally Posted by movax
I'll make one now. (Link)
The GCC compiled components are of course in /gcc. It'd be interesting to see how those fare on a SSE system, as I've heard that they don't function at all on a plain SSE system. (Any system that lacks SSE2 in fact).
I have a problem with gcc builds of liba52. It gives illegal instruction on my AMD Thunderbird (no SSE/SSE2). Other libs seem ok.

Originally Posted by Egh

OK, let's see. In fact I tried to use one of SSE builds (iirc it was 09 21-22 from clsid), it worked fine.
That was a MSVC71 SSE build, not a GCC one.


I see finally "successfull unicode build" in CVS now. Submitted 3 hours ago. I will make some fresh compiles too.

[bob0r]

I'll make one now. (Link (http://www.filefarmer.com/movax/s/ffdshow20051002.rar))
The GCC compiled components are of course in /gcc. It'd be interesting to see how those fare on a SSE system, as I've heard that they don't function at all on a plain SSE system. (Any system that lacks SSE2 in fact).

x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
(AMD XP, 1534MHz, 256KB)

/ff_vfw.dll does Not crash in virtualdub 1.5.10
/gcc/ff_vfw.dll Does crash in virtualdub 1.5.10

Playing my x264.313.mp4 sample video works fine when i copy /gcc/* to C:\Program Files\ffdshow (overwrite all)

[movax]

Heh, as soon as I get back home from school, I'll make the promised Unicode compile. Would be fun to just make a macro for ffd compilation :P

The reason I asked about the GCC borks is that during some CCCP testing, we found that libdts broke on non-SSE2 systems (Fault of simd.h maybe?). Compiling it with GCC make NOINTRIN=1 seemed to fix it, but iirc, all of my things in /gcc were just plain. I'll make a more detailed test RAR later. :)
As for liba52, well it won't compile with make + nointrin, but only with make, therefore breaking that on non-SSE2 systems.

[bob0r]

When i have mingw/msys with gcc 3.4.2

I grab ffdshow:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffdshow co -P ffdshow

cd ffdshow....

How easy or how hard is compiling all of ffdshow only using this?
If its easy to explain, someone please do, so i can test some updates myself too.

If its a very complicated process, then i guess ill wait for someone to ever put online a How to compile ffdshow guide for all compilers :)

[movax]

It's not very hard at all, I can make a guide later if you wish.
Quick outline, though:
1. Compile components w/ msvc, they will appear in /bin, move these into a /msvc directory. (Not the .ax though.)
2. Then, just open up mingw, and for example: (I don't guranatee the dir structure from memory)

cd g:\coding\ffdshow20051002\src\codecs
cd libdts
make clean
make
(repeat for all, I don't trust the giant makefile in /src).


There's more stuff, but I'm off to eat lunch.

[CiNcH]

How about updating ff_libmad to latest 0.15.1b sources?

http://sourceforge.net/project/showfiles.php?group_id=12349

[movax]

I updated the ffmpeg in one of my builds, I can try updating all later.

[bob0r]

..

1. Compile components w/ msvc, they will appear in /bin, move these into a /msvc directory. (Not the .ax though.)

..



Oh ok, so you cant only use mingw/msys, you need msvc (MicroSoft Visual C++ i assume), i have that, but that makes it even more clueless for me :(

[bob0r]

libmpeg2:
In file included from libmpeg2/idct_sse2.c:2:
./../../simd.h:292: error: `size_t' does not name a type
./../../simd.h:478: error: `size_t' does not name a type
./../../simd.h:607: error: `size_t' does not name a type
make: *** [libmpeg2/idct_sse2.o] Error 1

This failed in mingw/msys, requires something created by msvc? or ffdshow cvs bug?

wmv9 (ofcourse this one fails, without the proper header files, i copied them
from Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include, but that wont work, fails too :D)

[Egh]

The reason I asked about the GCC borks is that during some CCCP testing, we found that libdts broke on non-SSE2 systems (Fault of simd.h maybe?). Compiling it with GCC make NOINTRIN=1 seemed to fix it, but iirc, all of my things in /gcc were just plain. I'll make a more detailed test RAR later. :)
As for liba52, well it won't compile with make + nointrin, but only with make, therefore breaking that on non-SSE2 systems.

IIRC those SSE2-related bugs in DTS lib and in liba52 were reported weeks ago and even fixed since then.

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

Looking forward to unicode build :P

[Egh]

x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
(AMD XP, 1534MHz, 256KB)

/ff_vfw.dll does Not crash in virtualdub 1.5.10
/gcc/ff_vfw.dll Does crash in virtualdub 1.5.10


I copied all dlls from /gcc subfolder to ffdshow folder. All crashes related to VfW dissappeared, including even that huffman encoding crash (aka http://sourceforge.net/tracker/index.php?func=detail&aid=1301390&group_id=53761&atid=471489)

I tested on VDub 1.6.10

P.S. BTW, our CPUs are same :P

[bob0r]

I manages to double click ffdshow.dsp, and build it, but its giving me errors, i see a lot of .dll files in /bin, but no ffdshow.ax to be found, some help with that please ;)

Let me know if what i am doing is right or wrong...

[celtic_druid]

Well when you opened ffdshow.dsp it would have opened ffdshow.dsw since it has the same name, then since just about everything is a dependency of ffdshow you would have built all the other dll's.

As for what is wrong, you would need to post the errors.

[bob0r]

errors:
http://x264.nl/errors.txt

What it all did:
http://x264.nl/ffdshow.txt

Edit:
ff_x264 also fails (guess some have to be done manually. like ff_vfw too):
" ff_x264 error PRJ0019: A tool returned an error code from "Assembling g:\msys\1.0\home\user\ffdshow_msvc\src\codecs\x264\common\i386\quant-a.asm"
"

[movax]

Oh shit, sorry I forgot to mention what else you need:
* nasmw (link to it in MSVC Settings, Executable Files Dir) < That's your missing tool error.
* DirectX SDK (Oct 2004 seems to be the lucky one), add its Include and Lib dirs to MSVC as well.
* stlport as well, I recommend just placing it in C:\program files\stlport, as that's the explicit location specified in the sln anyways. (Of course you can change it if you want).
* Removing the stlport additional include from wmv9 in msvc will allow it to compile.
And of course, Release target, not Debug.

And when using mingw to compile some of the dlls, you will need nasmw handy as well (just dump it in the dir, and it'll be fine).

[bob0r]

Oh shit, sorry I forgot to mention what else you need:
* nasmw (link to it in MSVC Settings, Executable Files Dir) < That's your missing tool error.
* DirectX SDK (Oct 2004 seems to be the lucky one), add its Include and Lib dirs to MSVC as well.
* stlport as well, I recommend just placing it in C:\program files\stlport, as that's the explicit location specified in the sln anyways. (Of course you can change it if you want).
* Removing the stlport additional include from wmv9 in msvc will allow it to compile.
And of course, Release target, not Debug.

And when using mingw to compile some of the dlls, you will need nasmw handy as well (just dump it in the dir, and it'll be fine).

- nasmw i got (linked and called it nasmw)
- DirectX SDK (http://download.microsoft.com/download/7/e/9/7e9f48c6-f28a-469b-9b8e-cc84032efbd4/dxsdk_sum2004.exe)
- stlport just extract http://www.stlport.org/archive/STLport-4.6.2.tar.gz to program files?

Removing the stlport additional include from wmv9 in msvc will allow it to compile.
And of course, Release target, not Debug.

How to remove and what?
How to set Release target, not debug?

[clsid]

Compiling with Visual Studio works without STLport. Is there a specific reason for using it anyway?


Updated builds:
http://www.megaupload.com/?d=DYWA1X1B

[bob0r]

Compiling with Visual Studio works without STLport. Is there a specific reason for using it anyway?

..

Hehe good:

STLport/src
make -f gcc-mingw32.mak clean install
make: *** [../lib/obj/MINGW32/ReleaseD/dll_main.o] Error 1
:p

[bob0r]

Think i got all of ffdshow compiled.

Now the next question:
How to compile libavcodec.dll and libmplayer.dll?

I have /home/user/main (mplayer) and /home/user/ffmpeg latest CVS, what commands do i run to produce the .dll files (mingw/msys)?

[movax]

You don't, you goto src\ffmpeg and run make, as well as src\mplayer and run make.

[bob0r]

You don't, you goto src\ffmpeg and run make, as well as src\mplayer and run make.

Oh ill be damned, thats where they are :)

Scary but true, i managed to get myself a working ffdshow installer:
http://mirror05.x264.nl/public/ffdshow-20050911-test20051004.exe
After a fresh ffdshow cvs checkout I used the original ffdshow.nsis2 to create the installer, that script is not updated and therefor the output file is named ffdshow-20050911.exe, i added -test20051004.exe so you know when i compiled it.

All ffdshow components compiled with Microsoft Visual Studio .NET 2003 (msvc7.1 i guess),
except libavcodec.dll and libmplayer.dll are compiled with gcc 3.4.2.

ff_vfw.dll does not crash (virtualdub 1.5.10 and 1.6.11), please let me know if this build is any good, so i can make future builds if wanted.

[movax]

So many builders now, I bet Milan is off chuckling somewhere :P

I think it'd be interesting to make some kind of huge chart to figure out what combination of DLLs works on what systems/SIMD instructions. Of course, pull out those ol' probability skills, and figure out the possible number of combos. :)

[mpioner]

@bob0r
@movax

Milan provide a HOWTO for compiling ffdshow
http://sourceforge.net/tracker/index.php?func=detail&aid=1277820&group_id=53761&atid=471490

[movax]

Um, yes, my method is the exact same as that. I was just too lazy to look for the HOWTO at the start, and as a result, am familiar with the process.

[midiboy]

Hi !

Big problem with that latest ffdshow-20050930.exe. As you can see on the pic, all of my dvr-ms files crash Zoomplayer with this access violation when in customized media mode using ffdshow.

Reinstalling any of the earlier ffdshow versions solves that (tried the ffdshow-20050920_fixed.exe)

Could this be solved easily for the next version?
I am using a P4, not AMD.

Thanks,
Alex

[movax]

Is it a libavcodec_dec.dll, or libavcodec.dll in your ffdshow directory?

[CiNcH]

Hi,

I just made a compilation of the latest libmad 0.15.1b sources (optimized for accuracy) using gcc 4.0.1/nasm 0.98.39.

http://members.aon.at/cinch/ff_libmad.dll

(MAD = MPEG Audio Decoder; fully MPEG Layer-1/-2/-3 compliant)

[midiboy]

Is it a libavcodec_dec.dll, or libavcodec.dll in your ffdshow directory?

Do you mean me, movax ?

libavcodec.dll :-)

Bye,
Alex

[SeeMoreDigital]

Does anybody know whether it's possible to configure FFdshow's filters to play MPEG-2 video streams in MP4?

Currently I can only play these files using VLC player!


Cheers

[movax]

ffd only has 3 primary config places,
rundll32 ffdshow.ax,configure
rundll32 ffdshow.ax,configureAudio
rundll32 ffdshow.ax,configureEnc

I'd guess it to be under the first one, codecs, MPEG2, and set it to use libavcodec. FFD should probably then be called in the graph unless you have another MPEG2 decoder with higher merit.

[SeeMoreDigital]

I've been able to get FFdshows filters to play MPEG-2 video streams in .MPG, .TS and .PS and even in .VOB..... And by selecting FFdshow's MPEG in AVI option, I've also been able to play MPEG-2 video streams in AVI :)

But so far I've been unable to get MPEG-2 in .MP4 to work.... Shame FFdshow does not offer an "MPEG in MP4" option ;)


Cheers

[movax]

Weird. So you don't have anything decoding MPEG2 in MP4, or some standalone decoder? (or MPC internal or something).

[SeeMoreDigital]

Weird. So you don't have anything decoding MPEG2 in MP4...Nope... all I get from MediaPlayer Classic "Unsupported Stream" :confused:


Cheers

[clsid]

Are you using Haali's splitter? Perhaps he needs to add support for MPEG-2 streams in his splitter.

[SeeMoreDigital]

No.... I'm not using Haali's splitter, although I have tried it as recently as a few weeks ago!


Cheers

[zajc]

Hello!

I'm using ffdshow-20050920_fixed.exe (previous versions have the same "problem") and I'm wondering if there is a bug in "VFW codec configuration" in a tab "Decoder". I can't find filter "resize" or I can't find the way to include the "resize" filter in the list (except via avisynth). Is this a bug or it is missed on purpose?

Thanks.

[clsid]

No.... I'm not using Haali's splitter, although I have tried it as recently as a few weeks ago!

Cheers
I just tested a MP4 file containing mpeg2 that I found on some test cd and in fact Haali's splitter supports mpeg2 in MP4 :D

mp4info version 1.3.2
mpeg2.mp4:
Track Type Info
201 video MPEG-2 Main, 10.000 secs, 0 kbps, 720x288 @ 25.000000 fps
2 od Object Descriptors
1 scene BIFS

[SeeMoreDigital]

Interesting...

Could you try this sample (http://homepage.ntlworld.com/seemoredigital/Temp_Test_Files/MPEG-2+2ChAAC-LC.7z) please?


Cheers

[MarkCoolio]

@SeeMoreDigital:

I just tested your sample with Haali's splitter from 18.09.2005.
It works! :)

[SeeMoreDigital]

@SeeMoreDigital:

I just tested your sample with Haali's splitter from 18.09.2005.
It works! :)Cool.... I guess I better give Haali another go!


Cheers guys

[Inventive Software]

So remind me. What exactly do I need to compile ffdshow, bearing in mind all I have at the minute is MSYS, MinGW 3.4.2 (i'm working on updating this to 4.0.1), and NASM 0.98.39.

Also, is there any specific instructions that I need to take account of. Usually with most packages, I just do "configure", "make all", and if necessary, "make install".

[bob0r]

@SeeMoreDigital

Maybe it doesn't play because its PIRATED video? :goodpost:

It works here too, just try latest haali media splitter next time you lazy ass :sly:

[SeeMoreDigital]

@SeeMoreDigital

Maybe it doesn't play because its PIRATED video? :goodpost:

It works here too, just try latest haali media splitter next time you lazy ass :sly:LOL... you're right... I've gone with the flow and installed the very latest version of Haali's Media Splitter (http://haali.cs.msu.ru/mkv/) and it appears to be working fine (yet another icon is displayed in the system tray, albeit a useful one)

I'm moved to ask though... why do Matroska call the "Haali Media Splitter" the "Matroska Splitter". Why not call it "Matroska's Haali Media Splitter" ;)


Cheers

[bob0r]

ffdshow-20051006.exe added to my site.

changelog: http://cia.navi.cx/stats/project/ffdshow
Looking at some changes, i figured a new build was welcome (to test).

Enjoy!

[Egh]

So if unicode build by cutka was called "successful", can anyone build it?

[Liisachan]

20051006 installs, and no VfW problem. So far so good :)

[stephanV]

I'm moved to ask though... why do Matroska call the "Haali Media Splitter" the "Matroska Splitter". Why not call it "Matroska's Haali Media Splitter" ;)


"Matroska" is not a person... Haali is and develops this splitter. So it's Haali's media splitter.

[clsid]

So if unicode build by cutka was called "successful", can anyone build it?

There is a Debug Unicode configuration, but there is no Release Unicode configuration. So I guess it isn't ready yet for the general public.

[IgorC]

If I'm not mistake right word will be "Matrioshka" ;) as pronunces

[SeeMoreDigital]

"Matroska" is not a person... Haali is and develops this splitter. So it's Haali's media splitter.Yep.... I'm aware of that. However, this does not explain why, on Matroska's web site, we see this: -

http://img123.imageshack.us/img123/9891/haali3gy.png

....This sort of thing has got to be confusing to newbies?


Cheers

[clsid]

At first it was only a splitter for Matroska. Now it also supports AVI and MP4.

But I agree that it is confusing.

[Selur]

1st I thought that it seemed like ffdshow had sometimes a problem selecting the right idct if it is set to 'auto' and the video stream (original Xvid) is muxed into a mp4 shell, but after changing the idct I had to release that all the options besides auto decode the file fine.

avi:
http://forum.gleitz.info/attachment.php?attachmentid=76070
mp4:
http://forum.gleitz.info/attachment.php?attachmentid=76072

screenshot:
http://forum.gleitz.info/attachment.php?attachmentid=76079 (3ivx)
http://forum.gleitz.info/attachment.php?attachmentid=76080 (libav 'auto')
http://forum.gleitz.info/attachment.php?attachmentid=76081 (libav 'xvid mmx')
http://forum.gleitz.info/attachment.php?attachmentid=76082 (nero)

=> What does happen if one selects 'auto'? (I thought it would automaticly decide if to choose e.g. Xvid MMX, integer or ..., but it seems like it does something else.)

Would be cool if someone could clear this up. :)

Thx

Cu Selur

[tedgo]

This "IDCT-problem" in ffdshow only happens with xvid encoded with a cqm or mpeg-matrix in mp4, not with h263-quantization or xvid cqm/mpeg in avi.
Is xvid cqm/mpeg-matrix in mp4 currently not "really" supported in ffdshow?

[hpn]

"Matroska" is not a person
(Sorry for the OT) Actually it is. It's an wooden figure usually representing a peasant Russian girl in traditional dress. The correct name is Matryoshka (or Matrioshka), but the original developer renamed it to "matroska" to make it sound better for the English speaking world. Here is more
http://en.wikipedia.org/wiki/Matryoshka

[stephanV]

Actually it is.
Yes i know where the name originates from, but I wouldn't call a type of doll a person. Certainly in this context, where the name "Matroska's Haali media splitter" was proposed the term Matroska can't be related to any person. There is not someone called "Matroska" in the Matroska team. The name is used for the container and I doubt a container format has ever developed any software for itself. :)

[Inventive Software]

....This sort of thing has got to be confusing to newbies?

Yup, I was confused as well. No thanks to my Aspergers!

[ExtraEye]

any feedback about the new ffdshow?

[clsid]

The configuration windows don't work.

rundll32 ffdshow.ax,configure
rundll32 ffdshow.ax,configureAudio
etc.

[SeeMoreDigital]

According to Matroska's web site "A Matroska Muxer is now included in the package (ie: the 05/10/2005 "test" version)....... But I'm unable to see where this installation contains anything new?

New 05/10/2005 "Test" version: -

http://img31.imageshack.us/img31/121/matroskatest7in.png


Previous 28/09/2005 version: -

http://img85.imageshack.us/img85/5535/haalifilter5kx.png


Cheers

[MarkCoolio]

The splitter.ax has increased in size (~ twice as big).. so the muxer is included there.

[SeeMoreDigital]

The splitter.ax has increased in size (~ twice as big).. so the muxer is included there.Is that common practice... Why are they not separate?


Cheers

[CruNcher]

i think its a cool idea if you have decoder multiplexers splitters from different companies it can really get alot and you lose overview bringing more stuff into 1 big .dll can reduce this chaos alot especialy multiplexers or other special filters as they only get used when needed most times by a special application and when you want to use it for a special purpose like muxing you just open the config dialog and click on mux mode i think a perfect idea more should do it this way :)

[vidhead]

So remind me. What exactly do I need to compile ffdshow, bearing in mind all I have at the minute is MSYS, MinGW 3.4.2 (i'm working on updating this to 4.0.1), and NASM 0.98.39.

Also, is there any specific instructions that I need to take account of. Usually with most packages, I just do "configure", "make all", and if necessary, "make install".

try here:

http://sourceforge.net/tracker/?group_id=53761&atid=471490&func=detail&aid=1277820

i did. unsuccessful with specified mingw/msys. :(

any ideas?

edit: http://72.14.203.104/search?q=cache:LSGdNPwSoqEJ:www.zszoi.glog.pl/Home/KazubskiJ/help/compilation.html+ffdshow+compile+mingw+msys&hl=en

google cached copy looks possible but atm don't've all the tools.

[clsid]

You don't need MSYS. That's a unix emulator. Since ffdshow will be build for Windows, you only need MingW.

Also, not all files will compile with GCC. For example ffdshow.ax won't. So don't use the main Makefile. Just go to the directory of each library and run "Make clean" and then "Make CC=gcc".

You need to compile ffdshow.ax (and some other files) with Visual Studio 2003.

-----

Does anyone know how I can run a Visual Studio 2005 compilation of ffdshow.ax on Windows XP? I have put the correct version of msvcr80.dll and Microsoft.VC80.CRT.manifest in the same folder as ffdshow.ax (to act as private assembly), but registering ffdshow.ax always gives an error.

[Egh]

BTW, for those who doesn't know yet: 20051006 build (hosted by x264 and already on free-codecs.com) suffers from same playback slowdown problem as [unfixed] celtics's 20050920.

Compling comrades, please do pay more attention to libmplayer.dll builds!!! :P

1006 is better build than 1002 due to lots of changes in ffdshow source, so I use 1006 but put into ffdshow folder that dll from movax's 20051002.

[movax]

Does anyone know how I can run a Visual Studio 2005 compilation of ffdshow.ax on Windows XP? I have put the correct version of msvcr80.dll and Microsoft.VC80.CRT.manifest in the same folder as ffdshow.ax (to act as private assembly), but registering ffdshow.ax always gives an error.

Everytime I've compiled the VS2005 project, I get a .ax that will never display video, so basically a null .ax. Don't bother with that project.

I've been busy lately, but I'm still working on the mutant mongrel build of it with the latest cvs of each lib/component.

[clsid]

BTW, for those who doesn't know yet: 20051006 build (hosted by x264 and already on free-codecs.com) suffers from same playback slowdown problem as [unfixed] celtics's 20050920.

Compling comrades, please do pay more attention to libmplayer.dll builds!!! :P

1006 is better build than 1002 due to lots of changes in ffdshow source, so I use 1006 but put into ffdshow folder that dll from movax's 20051002.
Exactly. For mplayer.dll and libavcodec.dll the GCC builds should be used. The MSVC71 builds are too slow.

[bob0r]

Exactly. For mplayer.dll and libavcodec.dll the GCC builds should be used. The MSVC71 builds are too slow.

Affirmative.

I compiled libavcodec.dll with gcc (because msvc does not work)
But i guess libmplayer.dll is causing slow playback?
On slow CPU? on certain samples (any online?)?

libavcodec.dll + libmplayer.dll gcc 3.4.2
(compile ff_vfw.dll with gcc = crash in virtual dub)

Any more files should be compiled with gcc?

[Egh]

Affirmative.

But i guess libmplayer.dll is causing slow playback?
On slow CPU? on certain samples (any online?)?


Not if you consider 1800+ XP slow CPU for playback.

I can't get smooth playback with that faulty dll of any avc stream. And i play the same stream on proper dll with software _bicubic_ resizer on.

As a test i always use TheFluffy's Hellsing Ultimate OVA trailer. That one was encoded w/o [de]blocking in-loop filter, btw. And I always have "skip deblocking always" enabled in ffdshow. So if i get slowed and certainly nonsmooth playback of that video [VMR9, RGB output] (without resizing enabled, with resizing it's more like quick slideshow and causes audio/video desync) == fault.

That behaviour was originally discovered by me, btw. See entry on ffdshow tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1296582&group_id=53761&atid=471489


Also, if you're sure that compiling ff_vfw.dll with gcc causes crash, then probably better report there: http://sourceforge.net/tracker/index.php?func=detail&aid=1310982&group_id=53761&atid=471489

But, iirc movax 1002 build was gcc and i didn't have any problems with vfw crashes there.


Edit: BTW, checked 1009 build -- no that problem like in 1006. Though i somehow feel (though that could be only my imagination, since i didn't measure actuall performance with anything specific) that full gcc build (1002) was the smoothest one in terms of playback speed (and also mpc reaction time to user actions). But that's only an impression, there could be many factors contributing there on comparison.

[movax]

Some of them shouldn't be compiled with GCC, like a52 for sure. libavcodec and libmplayer should both be always compiled with GCC for sure.

Making a chart of the DLL combos and their results would be very useful. Using GCC for things like libdts allows you to do things like "make NOINTRIN=1", therefore allowing it to function normally on a non-SSE2 system.

[bob0r]

@Egh

Anyway i can get my hands on that video?

I have AMD XP 1800+ too, with 1024MB ram.
The only slow videos i have are HD 1280x720, but only a stutter now and then, never a slide show.

As for the 2 dll files i compiled with gcc, i just did make clean and make, no extra optimizing flags, if any exist, gcc version 3.4.2

[celtic_druid]

Was there ever a verdict on the speed of libavcodec compiled by icl/gcc vs. a pure gcc build?

[Revgen]

Was there ever a verdict on the speed of libavcodec compiled by icl/gcc vs. a pure gcc build?

I haven't noticed a difference at all as far as performance.

SPP deblocking performance is about the same as the last one. At least to my eyes.

Then again I have an AMD X2 4600+. Even though you removed Intel's CPU detection parameters out of the ICL build, it's improvements most likely benefit Intel processors than AMD.

Hopefully Milan could release a mutithreaded version in the near future.

[marcellus]

Hi,
I have an Athlon XP 2600+ and I use ffdshow to record live from my TV tuner in DVD PAL format (Mpeg2, 720x576, 25fps). The only image processing I enable is KernelDeinterlacing.
The latest build I can use is celticdruid's 20050930 (not msvc71 one). 20051006 and 20051009 are slower enough to make the capture program (whitch, BTW, it's using DirectShow interface, not VFW) to constantly drop frames getting the CPU at 100% usage. 20051009 is a little faster than 20051006 but not by much (not enough to stay below 100% permanently). With 20050930 the CPU usage stays at 82-88%, I recorded even 5 hours without a dropped frame.

[bob0r]

@marcellus
Interesting, that build 0930 is made with ICL, guess ill have to look into that aswell :) :(

@celtic_druid
whats the difference between icl/gcc and "pure" gcc?

[celtic_druid]

Well in one case all files are compiled via gcc, in the other those that can are compiled with ICL, the rest are compiled with gcc. Have a look at the libavcodec dsp file.

[clsid]

Could you give some more detailed instructions on how to create such a mixed build?

[Egh]

@Egh

Anyway i can get my hands on that video?

I have AMD XP 1800+ too, with 1024MB ram.
The only slow videos i have are HD 1280x720, but only a stutter now and then, never a slide show.

Are those videos AVC? Cause really noticable slowdown (not percents, but more like dozens of percents on 1800+, 512MB ram).

For testing, download trailer from bt.animeasy.net (the fluffy one, though no objections to getting anything else:). That trailer was encoded with Nero AVC, no deblocking inloop used.

I use: (not only for testing, for casual watching too:)
MPC (last celtic's build), ffdshow.
In mpc -- VMR9 is used, in ffdshow -- RGB output and "high-quality conversion" enabled. "Skip deblocking always" used.

Try two modes: playing w/o any resizer (including mpc one) and then going to ffdshow Resizers, enabling bicubic/lanczos for let's say 1024*768 resolution. [damn, when milan cutka finally makes normal resizer interface in ffdshow????!!!!! I keep bugging him for months :)].

In my case, some playback slowdown [mostly in complex scenes] and very slow reaction to user actions [like right-click menu appearance] is present in first mode. In second mode, it's not exactly slideshow, but real FPS (according to OSD meter) are usually below <16 [in complex scenes] and audio/video desync is caused.

Also ffdshow OSD's cpu meter is recommended. With "fault" libmplayer.dll you see CPU usage higher on average than on gcc dll. In fact now i see faulty dll practically at once on playback seeing CPU meter in ffdshow osd. In normal library CPU meter jumps a lot, but with nongcc dll it almost always @ 100%.

[Egh]

The latest build I can use is celticdruid's 20050930 (not msvc71 one). 20051006 and 20051009 are slower enough to make the capture program (whitch, BTW, it's using DirectShow interface, not VFW) to constantly drop frames getting the CPU at 100% usage. 20051009 is a little faster than 20051006 but not by much (not enough to stay below 100% permanently). With 20050930 the CPU usage stays at 82-88%, I recorded even 5 hours without a dropped frame.

I'd suggest you to try movax 1002 build (the one which is in \gcc folder in .rar archive). Can you confirm that that's the fastest for Athlon systems amongst last builds?

@Movax:
Can you please build yours? Would be interesting to compare it with 1009.

[movax]

Yep, school is letting up, so I'll work on making a MSVC/GCC bin of files for people to mix and combine (and hopefully not crash. :) ).

[Revgen]

@CelticDruid

The september 20th fixed build has issues when capturing with Huffyuv. The captured video starts to deteriorate into colored blocks right when the capture starts.

Is this being caused by ICL or Milan's new code?

I'll stick with the Sep. 9th build for now.

[Egh]

Yep, school is letting up, so I'll work on making a MSVC/GCC bin of files for people to mix and combine (and hopefully not crash. :) ).

Please do same build as in \gcc folder in 20051002 archive :) Was it really fully gcc compiled then?

[movax]

Got a little tired of the source combine, so here's a direct from CVS ffd build, separated again into gcc and msvc folders, plus the distrib folder in case you want to make a exe installer.

ffdshow 2005-10-10 (http://www.filefarmer.com/movax/s/ffdshow20051010.rar)

And yeah, those are all GCC compiled (should be anyways :P), and you can check with the dependency walker: a GCC build will depend on the OS file MSVCRT.dll, whereas a MSVC build will depend on the runtime dll msvcr71.dll.

And if I forgot any files, tell me so I can add them to the rar, please.

*EDIT* After some testing my a friend of mine on an old Win9x system, seems like compiling without "NOINTRIN=1" will break SSE/Win9x boxes.

[marcellus]

I'd suggest you to try movax 1002 build (the one which is in \gcc folder in .rar archive). Can you confirm that that's the fastest for Athlon systems amongst last builds?

I just tried latest movax's 20051010 (the files in gcc folder). It is faster than 20051006 and 1009, the CPU stays at about 90-95% so I can use it for live recording but it is definitely not faster than celtic_druid's 20050930 compile. And when I exit the VFW config panel it gives this error:
RUNDLL
<<An exception occured while trying to run "ff_vfw.dll,configureVFW">>

[bob0r]

@Egh

I play [VeryFluffy]_Hellsing_Ultimate_OVA_DVD-trailer_v2_(English_Subs)_[6E888601].mkv
just fine, this the file?

I just install ffdshow, only enabe h.264, x264 and vorbis/ac3/dts/aac , disable post processing and disable volume normalization.

I am also using MPC default settings.

Edit:
I have a NVIDIA GeForce FX 5200.
Also i must say, if i downloaded the correct sample, and this is indeed Nero AVC, its bloody hell ugly and blocky (yes filter disabled)

I set output to VMR9 (in MPC)

I dont use any resize stuff, never used it, never needed it.

[Inventive Software]

You don't need MSYS. That's a unix emulator. Since ffdshow will be build for Windows, you only need MingW.
Got it, thanks.
Also, not all files will compile with GCC. For example ffdshow.ax won't. So don't use the main Makefile. Just go to the directory of each library and run "Make clean" and then "Make CC=gcc".
OK, thanks for that!
You need to compile ffdshow.ax (and some other files) with Visual Studio 2003.
That's gonna be a bit difficult, bein's I use Windows 98, and will not fork out £100 for Visual C++. Even the VC Toolkit 2003 won't install on Windows 98.

[movax]

If you run Win98, you can definitely run Win2K. (hardware-wise, at least)

[Inventive Software]

Yeah, sure. It's just acquiring a legal version of Win2K. Microsoft tend to charge about £50 for a license.

[esby]

Microsoft tend to charge about £50 for a license.

Well that's ouf of this thread. I bet you are talking of an educational licence, here microsoft licences (oem, not market or enterprise negociated) are available for 150-200 euros, for windows 2000 or windows xp pro. ~~
Now the point is compiling ffdshow, and it can be done by using only gcc, like CelticDruid already did.
Now I don't know if microsoft compiler can give a better performance, that's not my problem,
anyway, buying a new os or buying vstudio to perform only that, while someone can do for you, is a waste of money.

esby

[Liisachan]

mirrored (http://ffdshow.faireal.net/) celtic_druid's 20051013 build :)

[tedgo]

Like Selur mentioned some posts before there is still a strange quality issue (i would call it a "ringing impact" and smearing on one-coloured backgrounds) with xvid created with mpeg/cq-matrix with or without qpel in mp4-container when ffdshow's iDCT detection is set to "auto". Choosing any other iDCT-option solves the problem, but shouldn't it be automatically set a proper option with "auto"?

This issue only happens with xvid mpeg/cqm in mp4, not in avi and not with nerodigital mpeg/cqm or divx in mp4. Is it a problem of ffdshow's iDCT detection or xvid? Has ffdshow problems when xvid in mp4 is detected as MP4V? As mentioned before, xvid in avi plays fine with iDCT "auto".

Btw. there are no problems with NeroDecoder, vlc or mplayer instead of ffdshow.

EDIT:
I made some tests tonight. Would anybody make it too to confirm, please?

Try the following:
- Create a xvid.avi with Jawor's 1CD-matrix (the described issues are best visible with).
- mux the xvid.avi into mp4
- set ffdshow's iDCT detection to "auto"
- DISABLE ALL POST-PROCESSING (to avoid errors caused by it)!
- play both files (xvid.avi and xvid.mp4) with your favourite directshow-player
- you'll see what i mean - the xvid.avi plays fine the xvid.mp4 is borked

This issue happens with all mpeg/custom-matrices but is best visible with jawor's 1cd-matrix but only when the xvid-file is muxed in mp4.
Setting ffdshow's iDCT detection to any other than "auto" solves the problem.
With nerovideodecoder, neroshowtime, vlc or mplayer the xvid.mp4-file plays fine.
Files created with nerodigital mpeg/custom-matrices plays also fine with ffdshow, so what's wrong?

[bob0r]

Compiling ffdshow with gcc 4.0.2
I managed to compile most files:

#compiling ffdshow with gcc 4.0.2
#ffdshow/ffacm/ff_acm.acm
#ffdshow/src/imgFilters/KernelDeint/ ff_kernelDeint.dll
#ffdshow/src/codecs/liba52/ ff_liba52.dll
#ffdshow/src/codecs/libdts/ ff_libdts.dll
#ffdshow/src/codecs/libmad/ ff_libmad.dll
#ffdshow/src/codecs/realaac/ ff_realaac.dll
#ffdshow/src/audioFilters/resample/libsamplerate/ ff_samplerate.dll
#ffdshow/src/codecs/theora/ ff_theora.dll
#ffdshow/src/codecs/tremor/ ff_tremor.dll
#ffdshow/unrar/ ff_unrar.dll
#ffdshow/ffvfw/ ff_vfw.dll, crashing in virtual dub (used msvc 7.1)
#ffdshow/src/codecs/wmv9/ ff_wmv9.dll (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/src/codecs/x264/ ff_x264.dll
#ffdshow/ffavisynth/ ffavisynth.dll
#crashing when playing videos ffdshow/src/ ffdshow.ax (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/ffvdub/src/ ffvdub.vdf
#ffdshow/dscaler/ FLT_ffdshow.dll (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/src/ffmpeg/ libavcodec.dll
#ffdshow/src/codecs/libmpeg2/ libmpeg2_ff.dll
#ffdshow/src/mplayer/ libmplayer.dll
#ffdshow/makeAVIS/ makeAVIS.exe
#ffdshow/src/imgFilters/TomsMoComp/ TomsMoComp_ff.dll
# can't compile (no Makefile): ffdshow/verinc/ verinc.exe (used msvc 7.1)

#compiling fixed with dx9 include/lib = edit ff_wmv9.dll/FLT_ffdshow.dll Makefile, ffdshow.ax makefile.inc and add -I"/dx/Include" -L"/dx/MingLib" -ldx9 to CFLAGS+=
#Based on: http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6939

Anyway to compile ffdshow.ax and verinc.exe with gcc 4.0.2, or because there are no Makefiles for these, its just not possible?

(post regarding: http://cia.navi.cx/stats/project/ffdshow/.message/6032697 > can be compiled using GCC 4.0.2)

[celtic_druid]

I managed to compile ffdshow.ax some time ago with gcc, however it didn't do anything other than crash. Interesting to note is that you get a cli version of makeavis.

[bob0r]

I managed to compile ffdshow.ax some time ago with gcc, however it didn't do anything other than crash. Interesting to note is that you get a cli version of makeavis.

Yup, i managed to compile it too, but it indeed crashes.

Interesting to note is that you get a cli version of makeavis. > why?

[celtic_druid]

Because with MSVC, etc. you get the GUI version. With everything else if you use gcc or MSVC you basically get the same thing.

[movax]

Everything but the .ax compiles with GCC. Making SSE compatible builds with GCC is another story.

[bob0r]

Everything but the .ax compiles with GCC. Making SSE compatible builds with GCC is another story.

Wrong, but compiling ffdshow.ax with gcc is quite useless:

Quote Milan Cutka:

And FYI: I used gcc 4.0.2 build from
http://oss.netfarm.it/mplayer-win32.php.

But even if you'd be finally able to build ffdshow using gcc too,
don't expect too much. I was able to run configuration dialog,
but the playback crashed at the beginning.

[bob0r]

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

I found out some more details when ff_vfw.dll crashes:

After some more testing i have found out:
Compiling all files with gcc is no ff_vfw.dll crash.
Compiling ffdshow.ax with msvc 7.1 and ff_vfw.dll with
gcc, ff_vfw.dll crashes in virtualdub.

[movax]

After some more testing i have found out:
Compiling all files with gcc is no ff_vfw.dll crash.
Compiling ffdshow.ax with msvc 7.1 and ff_vfw.dll with
gcc, ff_vfw.dll crashes in virtualdub.

Your compiles are either borked then, or your computer configuration is.

[bob0r]

Your compiles are either borked then, or your computer configuration is.

Then so are celtic_druid's, Sharktooth's and a lot of other people's!

Kinda stupid unmotivated answer.... please leave those to me :sly:

[Egh]

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


Good, maybe it will be fixed then ;)

Now more about libmplayer.dll, different builds and speed.

I installed last CD's build, works fine. Although the size of libmplayer.dll grow up to 570kb (but there were some changes to it recently).

(@Celtic: what compiler was used in this build?)

As for speed, i didn't notice much difference with 20051013 build working with new dll or the one from movax 1010 build.

Also, since b0b0r didn't like previously suggested video (are you sure you didn't get v1 of that trailer instead of v2?), i made more interesting test.

http://bt.animeasy.net/ [air creditless OP, first entry in the list]. It's from progressive source and thus 29.97fps all the way, so it is *quite* CPU hungry. In fact on my system (cpu same as b0b0r ;)) it is very close to maximum i can play w/o frame drops (of course using VMR9, and inloop filter disabled). So those who have Athlon XP (i.e. SSE only, no SSE2 system) might try and see if they can get smooth playback using various builds of ffdshow.

[bob0r]

@Egh:
ok :cool:

Edit:
That build you installed from c_d must be ICL, because of the bigger file sizes.
If you were talking about [PSNR]Air.Creditless.OP.[avc][vorbis].mkv, i ran it twice, simultaneous, both played perfect without dropping frames :D
Do note, i have disabled all visual effects in WindowsXP, even thought i do run a lot of programs, the file plays just fine.


@Celtic_Druid:

I installed ICL 9.0 and integrated it with MSVC7.1.

When i had converted all ffdshow.sln to ICL, i build all 22 projects, the only files that appear in ffdshow\bin are:
ff_acm.acm, ff_realaac.dll, ff_vfw.dll, FLT_ffdshow.dll and verinc.exe

You have any tips how to compile ffdshow using ICL 9.0?
And if you already know, let us know which files can and which files cannot be compiled with ICL 9.0.

[Egh]

@Egh:
If you were talking about [PSNR]Air.Creditless.OP.[avc][vorbis].mkv, i ran it twice, simultaneous, both played perfect without dropping frames :D
Do note, i have disabled all visual effects in WindowsXP, even thought i do run a lot of programs, the file plays just fine.


That is strange. PPL reported 50% cpu usage on Athlon64 3200+ on ffdshow playing this file. So CPU usage 50% on athlon 1800+ would be kind of miracle. Please tell us your settings :) Or is it due to some good hardware acceleration?

Are you sure you play them with all options enabled in MPC? Especially the subtitles (first subtrack, not second).

Update: Some more test results from that special came in.
System: 2200+ XP, cccp 0923. Usage close to 100% in mpc + ffdshow (and that's in overlay mode, in vmr9 it lags and drop frames :P). Though less in zp + ffdshow + vsfilter, but with karaoke effect >90% cpu usage reported.

[clsid]

You have any tips how to compile ffdshow using ICL 9.0?
And if you already know, let us know which files can and which files cannot be compiled with ICL 9.0.
Everything except libavcodec compiles with ICL9 :D

You need to add to linker input: libircmt.lib libmmt.lib svml_dispmt.lib
C/C++ command line: /QaxKWNPB (=optimize for all processors)
C/C++ general: warning level = 0 (otherwise VS might crash)

Don't forget to patch libircmt.lib ;)

http://www.swallowtail.org/naughty-intel.html

[movax]

You can tell GCC compiles by running the dependeny walker on them like I mentioned earlier. MSVCRT.DLL = GCC, MSVCR71 = MSVC. Not sure about ICL, I'd assume you can differentiate that from the others through filesize.

[bob0r]

@clsid

I did run intel_check_executable_patch.pl libircmt.lib, that seems to work :)

If i run intel_check_patch.pl
File 'libirc.a' not found! This file is nowhere on my system, please let me know what to do! Or is it not important?


Edit:
Ah never mind, i got it working, i needed to linker/input and edit all projects seperately, probably a way to fix them all together, but i have no idea how to :)

[celtic_druid]

I use MSVC6 with ICL9, so no msvcr71. libmplayer was the only thing that I didn't compile with ICL9. It was compiled with gcc, although as mentioned earlier, parts of libavcodec are compiled with gcc to.

[bob0r]

ffdshow-20051015

gcc = gcc 4.0.2
icl = icl 9.0
msvc = msvc 7.1

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015.exe (all files gcc, except ffdshow.ax and ff_vfw.dll are msvc) (recommended and online version)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-gcc.exe (all files gcc, playback will 99% crash ffdshow)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-icl.exe (all files icl, except libavcodec.dll is gcc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-msvc.exe (all files msvc, but playback can be very slow)

[ Note x264 has server (nameserver) problems, working on backup nameserver so you can keep accessing the mirrors ]

Happy testing!

[canuckerfan]

what's the difference between celtic_druid's builds and bob0r's builds?

[celtic_druid]

((always_inline)) -> ((__always_inline__))
SPP deblocking doesn't depend on libavcodec
can be compiled using GCC 4.0.2
fast SPP imported
use image filters in VFW decoding

[videomixer9]

if there are nameserver problems why don't you just add the IP address of the mirror in the link instead of using it's DNS name. That way anything should work fine, not like you cannot link to the IP addresses, you can always change it back later ...

[bob0r]

The mirrors are all apache virtual hosts, but ill past you the full paths:

http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015.exe (all files gcc, except ffdshow.ax and ff_vfw.dll are msvc) (recommended and online version)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-gcc.exe (all files gcc, playback will 99% crash ffdshow)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-icl.exe (all files icl, except libavcodec.dll is gcc)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-msvc.exe (all files msvc, but playback can be very slow)

Enjoy

[videomixer9]

thanks, works fine!

the builds are actually quite funny, the first build has high peak CPU usage for me than the full ICL build. If suddenly on h264 video high motion scenes kick in, the peak uses goes upto 67% on my tested encode, ICL peaks at 54% for those scenes, on regular motion scenes GCC is also a bit more CPU consuming, however on low motion it has much lower CPU usage down to 23%.

Quite amusing ... especially as libav is both GCC compiled ...

[Egh]

I tried first and third builds on that heavy cpu load video. First one seems to be a bit better than ICL compiled, but that i already noticed with movax builds (iirc there .ax is compiled with msvc and the rest with gcc).

@b0b0r: it seems that the CR/LF pairs in the "about" section of your ffdshow builds are b0rked. Other builds have proper line breakes in that text. I noticed it earlier but forgot to report :)

[Liisachan]

Thank you for your hard work :D
Tested with x264-video-only.mp4 on P4 3.4GHz,
In this test -msvc was significantly slow, the other 3 were about the same.
-gcc didn't crash.

http://subforge.net/image/2005/20051015mp4.png

Edit:
Same clip in SNOW. It doesn't play with -msvc. [ "This graph can't play. Unspecified error (Return code: 0x80004005)" ]
The other 3 are about the same again.

http://subforge.net/image/2005/20051015snow.png

Edit2:
CPU load-wise, I don't see any real differences between celtic_druid's 20051013 and this 20051015, tho the former may be slightly more optimized for my CPU.
http://subforge.net/image/2005/20051015c.png

[midiboy]

Hi Guys,

I hope you don´t keep ignoring me ... I am getting crashes with ALL versions since the ffdshow-20050920.exe. That was the last one that worked for me. All the versions since that one crash with my TV recordings I make with MediaPortal, no matter which compiler is being used. Since I am not using ffdshow for the MPEG2 video decoding it must be the ffdshow audio part that is crashing.



Here´s the result with with the versions released on the 15th:

ffdshow-20051015.exe:
http://members.chello.at/afmusic2/ffdshow-20051015.JPG

ffdshow-20051015-gcc.exe
http://members.chello.at/afmusic2/ffdshow-20051015-gcc.JPG

ffdshow-20051015-icl.exe
http://members.chello.at/afmusic2/ffdshow-20051015-icl.JPG

ffdshow-20051015-msvc.exe
http://members.chello.at/afmusic2/ffdshow-20051015-msvc.JPG

I am using Zoom player 4.51, customized media mode, VMR9 windowless, ffdshow for the MPEG2 Audio profile (using the NVIDIA Audio decoder also fixes the crashing)

The ffdshow audio decoder (20050920 version) reports this:
http://members.chello.at/afmusic2/Screen05.JPG


I have uploaded a small recording here (http://members.chello.at/afmusic3/rec.dvr-ms) so you can see for yourself !

Could you please fix this for the next versions, thanks !! :cool:


Bye,
Alex

[clsid]

Try libmad instead of mp3lib.

[bob0r]

@midiboy

I suggest you submit this bug to http://sourceforge.net/tracker/?group_id=53761&atid=471489

I get the crash with Windows Media Player 10 too, however when i try to play the file with Media Player Classic 6.4.8.4, it says it cannot find a connectable filter. (funny when i start the video with WMP10, then at the same time with MPC6.4.8.4, it does play the audio (only the video is lighter, brightness wise, as usual :)))

Disabled mp1/mp2 via start/programs/ffdshow/Audio decoder configuration/Codecs > set MP1/MP2 disabled, will play the audio part for me, WMP10 says its InterVideo Audio Decode.

So submit the bug and let the ffdshow developers know!

[bob0r]

Try libmad instead of mp3lib.

Same problem, WMP10 crashing, MPC6.4.8.4 saying it cannot find a connectable filter

[marcellus]

Hi bob0r, thanx for your builds.
I tested 3 of the 4 builds for mpeg2 (25fps/720x576/2000 kbps) encoding speed on my athlon xp 2600+ (with Kernel Deinterlace as image processing enabled).
-The fastest by far the icl one, (85-95% cpu); is not as fast as celtic_druid's latest build but is very close, with a difference of about 4-6 percent.
-The regular (recomended) build is slow, it gets the cpu at 100% and it drops more frames than actually manages to capture.
-The pure gcc build crashes right away.

(I mentioned the bitrate in the mpeg2 capture specs because I noticed that the higher the bitrate - the more CPU it needs (for the same motion search parameters). For example I manage to capture safely in realtime with my CPU at about 2-3000 kbps, higher it's a gamble. I think this is true for libavcodec in general, not only for ffdshow).

[multiblitz]

Is there any version / developer out there which supports dual-cores ?

[bob0r]

http://cia.navi.cx/stats/project/ffdshow
http://cia.navi.cx/stats/project/ffdshow/.message/6044320
use __stdcall in internal VFW interface - not backward compatible change, but allows GCC<->MSVC interoperability

The gcc ff_vfw.dll and msvc ffdshow.ax crashing is fixed.

@marcellus
Yup ICL is faster, and celtic_druid probably uses some optimizations.
The GCC is not that much slower, and some of you people really manage to get frames dropped, where i can run some clips twice, maybe disable all XP visual stuff? :)

Thanks for the testing, but for now the default online build will be all files gcc + ffdshow.ax msvc.

[clsid]

Where can I find a (windows) binary of GCC 4.0.2 (for use with mingw)?

[bob0r]

Where can I find a (windows) binary of GCC 4.0.2 (for use with mingw)?

Extract
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-core-4.0.2.tar.gz
and
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-g++-4.0.2.tar.gz
(both will be gcc-4.0.2/) then:

1. cd gcc-4.0.2/
2. mkdir obj
3: cd obj
4: ../configure --prefix=/usr/local
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
6: make install

As for step 4, that failed on me, so i copied:
C\msys\1.0\local\include dir to:
C\msys\1.0\ (seems it searches for /usr/include and its subdirs/files)

[marcellus]

The GCC is not that much slower, and some of you people really manage to get frames dropped, where i can run some clips twice, maybe disable all XP visual stuff? :)

My main interest in ffdshow is dvd compatible capturing (encoding) and not playing CPU demanding formats (as I like to watch what I capture on my standalone and TV set). Maybe in the encoding case the difference in speed between icl and gcc is more important. I'm just guessing, as I am a simple user.

[midiboy]

Hi Guys,

I have created a bug report as suggested. Thanks for your help !

Bye,
Alex

[bob0r]

http://cia.navi.cx/stats/project/ffdshow is currently down, i believe there are some more sites doing something similar to check for ffdshow updates, anyone has that/those site(s) URLs?

[Liisachan]

how about this?
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/?sortby=date

[Egh]

http://cia.navi.cx/stats/project/ffdshow is currently down, i believe there are some more sites doing something similar to check for ffdshow updates, anyone has that/those site(s) URLs?

Nah, only site i know besides sf's CVS and CIA site (which is down atm) is changelog on http://m17n.cool.ne.jp/freeware/mpc/ But that's not regularily updated one :)


Heh, amongst very latest updates from cvs one quite interesting:

" possible to build ffdshow using GCC without requiring SSE2"

Seems that pure gcc builds might be more sensible now.

Seems that http://sourceforge.net/tracker/index.php?func=detail&aid=1326883&group_id=53761&atid=471489
and
http://sourceforge.net/tracker/index.php?func=detail&aid=1326921&group_id=53761&atid=471489
are fixed in source now.

[Egh]

Interesting last fix:

(file) TffdshowDecAudio.cpp 1.159 6 hours milan_cutka fix encoder input colorspace forcing I remember that there were some problems with input colorspace, but i didn't know they are in audio decoder .... :P

[Liisachan]

cia.navi.cx is up again.
cvs changelog on ffdshow.faireal.net / m17n.cool.ne.jp / etc. is just manually copy-and-pasted from cia. so it doesn't work if cia. is down.

[bob0r]

Yeah thanks, indeed up again.

I do remember seeing some other cia.navi.cx like site with the same updates.

Via google or doom9, i dont remember anymore, just cant find them.

Anyways looks like we gonna test full gcc build + all updates :D

@celtic_druid:

... Interesting to note is that you get a cli version of makeavis.
http://cia.navi.cx/stats/project/ffdshow/.message/6056690
have a GUI built with makeAVIS when using GCC (patch by Kurosu)

[Inventive Software]

Hehe. :D I'm gonna have to get the sources at some point to actually try to build this thing next week. Trouble is, CVS doesn't like me. All the computers are getting Windows XP installed (I say good luck to the technicians!) and as such they're gonna be unusable from about Thursday (20/10/05) onwards until they get the bugs ironed out.

Can somebody be so kind as to provide a mirror for the sources for ffdshow please? Any build in October will be fine. I've tried numerous solutions for getting the sources and none have worked. It seems that the software I've tried has problems getting through the proxy server.

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.7z
Source current as of a few minutes ago. I compiled ffdshow with gcc earlier and it worked. No crashes.

[bob0r]

http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.7z
Source current as of a few minutes ago. I compiled ffdshow with gcc earlier and it worked. No crashes.

To compile ffdshow.ax without sse2 thus without crashing:

Quote Milan Cutka:

Yes, you have to edit src/makefile.inc and src/makefile_c.inc.
Search for -msse2 switch and remove it.

[bob0r]

Test Build ffdshow-20051017.exe:
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051017.exe

Compiled only with gcc 4.0.2.

Manually edited:

ffdshow/src/makefile.inc
ffdshow/src/makefile_c.inc
(removed -msse2 from CFLAGS+=-mmmx -msse -msse2)
This so you can use ffdshow.ax on a CPU without SSE2 support, without crashing, may still not work on a CPU not supporting SSE.
based on:
possible to build ffdshow using GCC without requiring SSE2 > http://cia.navi.cx/stats/project/ffdshow/.message/6056513

ffdshow/dscaler/Makefile
added -I"/dx/Include" -L"/dx/MingLib" -ldx9 behind CFLAGS+= -I. -I../src

ffdshow/src/codecs/wmv9/Makefile
added -I"/dx/Include" -L"/dx/MingLib" -ldx9 behind CFLAGS+= -I. -I../.. -I../../cygwin -I../../baseclasses -Iinclude -DSUPPORT_INTERLACE

These are Direct X 9 header files, required to build these files.
(copied from C:\Program Files\Microsoft DirectX 9.0 SDK (Summer 2004), and based/convert on: http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6939)

Quick Test, with (from x264) using cpu capabilities MMX MMXEXT SSE 3DNow! (AMD XP 1800):
xvid/divx/x264
All files playback perfectly, even my x264.333.mp4 runs way smoother than before, when i skip the video, the Sync Offset (avg and dev) both remain 0ms.
So far no crashes, this may not be the fastest version one can build, but i hope it has the best ratio between speed and stability.
And since its fully gcc, i can easily built a new build on a weekly bases or on demand. (Run mingw > ffdshow_gcc.sh and done)

Please test this build!

[movax]

I'll expand on your idea a bit, and upload a RAR with gcc_sse and gcc_sse2 in a few minutes :) Nice work. I'm pretty sure NOINTRIN=1 does something similar to your makefile editing though.

[clsid]

I have finally updated gcc from 3.4.4 to 4.0.2

What I have noticed so far:

All compiled libs are a bit bigger in size, except for libavcodec which is a little bit smaller.

ff_kernelDeint.dll and TomsMoComp_ff.dll came out much bigger (1057 and 1279 KB) as before (656 and 660 KB). I also noticed both were much slower compared to my ICL9 builds, but also compared to my old gcc builds.

[bob0r]

All tests are ok, ffdshow-20051018.exe online! :cool:

[vortex_hl]

All tests are ok, ffdshow-20051018.exe online! :cool:
it's crashes when opening "version details" window.

[NoX1911]

crashes here as well... (AmdK7/XPSP2)

I tested some versions (not 18102005 yet) on AmdK6. None worked. Any chance to see a generic build in near future?

[bob0r]

it's crash when opening "version details" window.

Confirmed, bug submitted.
https://sourceforge.net/tracker/index.php?func=detail&aid=1329122&group_id=53761&atid=471489

crashes here as well... (AmdK7/XPSP2)

I tested some versions (not 18102005 yet) on AmdK6. None worked. Any chance to see a generic build in near future?

Are you only talking about the Version Details crashing?
This seems a bug and will probably be fixed any time soon then.

Most importantly is audio/video playback, if you come up with any crashes of those please report them.


My personal goal is to test as many as possible with GCC and forget about icl/msvc.

Thanks for testing and keep it up! (the testing :p)

[NoX1911]

Are you only talking about the Version Details crashing?
No, generally trying to get ffdshow running on a K6 cpu. Either it doesn't even install (cannot register ffdshow.ax - msvc version) or crashes on playback attempt (filtergraph initialisation - non-msvc version). Manually disabled all cpu extensions (mmx, sse,...) but doesn't help...
.NET(sp1) is installed (maybe some libs are useful) and all ms updates. GFX driver is a generic XPSP2 nVidia TNT though. Original DivX and XviD codecs are working without problems.

[flanger216]

I get a crash when I use Denoise3D in 'high-quality' mode, and even normal Denoise3D is much slower than HQ-mode used to be. Was Denoise3D optimized for SSE2...?

Chris

[bob0r]

No, generally trying to get ffdshow running on a K6 cpu. Either it doesn't even install (cannot register ffdshow.ax - msvc version) or crashes on playback attempt (filtergraph initialisation - non-msvc version). Manually disabled all cpu extensions (mmx, sse,...) but doesn't help...
.NET(sp1) is installed (maybe some libs are useful) and all ms updates. GFX driver is a generic XPSP2 nVidia TNT though. Original DivX and XviD codecs are working without problems.

Try to submit your finding as bug report to the ffdshow development team, because if its for all versions, i can't help you.
http://sourceforge.net/tracker/?group_id=53761&atid=471489

[bob0r]

I get a crash when I use Denoise3D in 'high-quality' mode, and even normal Denoise3D is much slower than HQ-mode used to be. Was Denoise3D optimized for SSE2...?

Chris

Crash confirmed!
---

http://forum.doom9.org/showthread.php?p=683104#post683104
and
http://forum.doom9.org/showthread.php?p=683246#post683246
Seems it is optimized for SSE2(which i removed to prevent crashing)

Edit:
For those who wondered, like i did:
start/programs/ffdshow/Video decoder configuration/Blur & NR > Denoise3D and enable HQ.

Crashes on ICL/GCC, MSVC seems to work.

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