New ffdshow build (?) [Archive]

celtic_druid

9th September 2005, 12:56

[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

9th September 2005, 13:10

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

9th September 2005, 13:30

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

10th September 2005, 11:14

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

Chaos Creator

14th September 2005, 22:47

azsd

15th September 2005, 09:08

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

15th September 2005, 10:47

Yeah, should be -D2005-09-09.

hellfred

15th September 2005, 13:17

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

15th September 2005, 15:11

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

15th September 2005, 15:43

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

15th September 2005, 21:14

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

15th September 2005, 21:34

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

15th September 2005, 21:47

LigH

15th September 2005, 22:02

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

15th September 2005, 22:37

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

15th September 2005, 22:40

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

15th September 2005, 22:53

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

16th September 2005, 10:25

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

20th September 2005, 17:23

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

20th September 2005, 18:32

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

21st September 2005, 00:09

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

Egh

21st September 2005, 01:02

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

21st September 2005, 01:56

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

21st September 2005, 12:54

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

21st September 2005, 13:56

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

21st September 2005, 13:57

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

21st September 2005, 14:41

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

21st September 2005, 15:18

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

Liisachan

21st September 2005, 15:47

Worked. :) Testing...

Egh

22nd September 2005, 04:14

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

22nd September 2005, 13:38

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

22nd September 2005, 15:50

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

celtic_druid

22nd September 2005, 16:10

dimzon

22nd September 2005, 16:37

bob0r

22nd September 2005, 16:54

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

22nd September 2005, 18:04

Thanx.

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

clsid

22nd September 2005, 22:11

ICL9/GCC/MSVC71 builds of current CVS:

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

celtic_druid

23rd September 2005, 02:13

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

23rd September 2005, 04:03

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

23rd September 2005, 10:03

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

23rd September 2005, 10:06

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

Inventive Software

23rd September 2005, 12:41

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

23rd September 2005, 19:55

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

23rd September 2005, 21:11

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

26th September 2005, 11:48

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

26th September 2005, 11:57

@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

26th September 2005, 13:37

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

Jalavera

26th September 2005, 15:14

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

movax

26th September 2005, 18:58

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

26th September 2005, 23:47

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

27th September 2005, 03:34

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

27th September 2005, 20:17

Updated compilations:

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

celtic_druid

28th September 2005, 03:33

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

29th September 2005, 12:54

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

1st October 2005, 05:07

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

mOOb

1st October 2005, 08:25

Playback seems fine but vfw portion is crashing in everything.

Liisachan

1st October 2005, 10:46

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

bob0r

1st October 2005, 13:30

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

1st October 2005, 14:02

mirrored

Egh

1st October 2005, 16:12

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

1st October 2005, 16:45

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

1st October 2005, 20:14

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

obieobieobie

2nd October 2005, 01:11

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

2nd October 2005, 15:47

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

clsid

2nd October 2005, 16:25

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

Kurtnoise

2nd October 2005, 18:03

@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

2nd October 2005, 18:21

Egh

2nd October 2005, 19:08

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

3rd October 2005, 00:04

Egh

3rd October 2005, 02:56

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

3rd October 2005, 03:45

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

3rd October 2005, 04:03

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

movax

3rd October 2005, 04:19

@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

3rd October 2005, 16:05

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

3rd October 2005, 16:14

movax

3rd October 2005, 16:52

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

3rd October 2005, 16:55

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

3rd October 2005, 16:56

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

3rd October 2005, 16:56

How about updating ff_libmad to latest 0.15.1b sources?

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

movax

3rd October 2005, 17:00

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

bob0r

3rd October 2005, 17:24

..

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

3rd October 2005, 17:47

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

3rd October 2005, 17:50

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

3rd October 2005, 17:53

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

3rd October 2005, 18:03

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

3rd October 2005, 18:18

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

3rd October 2005, 19:05

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

3rd October 2005, 19:28

bob0r

3rd October 2005, 20:37

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

3rd October 2005, 21:16

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

3rd October 2005, 21:35

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

3rd October 2005, 22:37

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

3rd October 2005, 22:39

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

bob0r

3rd October 2005, 23:07

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

4th October 2005, 01:31

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

4th October 2005, 04:15

@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

4th October 2005, 05:47

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

4th October 2005, 09:27

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

4th October 2005, 17:06

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

CiNcH

4th October 2005, 17:08

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

4th October 2005, 19:41

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

Do you mean me, movax ?

libavcodec.dll :-)

Bye,
Alex

SeeMoreDigital

4th October 2005, 19:50

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

4th October 2005, 20:06

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

4th October 2005, 20:22

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

4th October 2005, 20:52

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

SeeMoreDigital

4th October 2005, 21:12

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

Cheers

clsid

5th October 2005, 10:32

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

SeeMoreDigital

5th October 2005, 10:37

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

Cheers

zajc

5th October 2005, 12:46

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

5th October 2005, 20:11

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

5th October 2005, 20:47

Interesting...

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

Cheers

MarkCoolio

5th October 2005, 20:58

@SeeMoreDigital:

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

SeeMoreDigital

5th October 2005, 21:53

@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

6th October 2005, 09:51

bob0r

6th October 2005, 13:06

@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

6th October 2005, 13:22

@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

6th October 2005, 17:33

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

6th October 2005, 18:14

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

Liisachan

6th October 2005, 18:24

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

stephanV

6th October 2005, 18:40

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

6th October 2005, 19:10

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

6th October 2005, 19:10

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

SeeMoreDigital

6th October 2005, 20:40

"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

6th October 2005, 22:09

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

But I agree that it is confusing.

Selur

6th October 2005, 23:29

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

7th October 2005, 01:45

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

7th October 2005, 03:20

"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

7th October 2005, 08:59

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

7th October 2005, 11:21

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

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

ExtraEye

7th October 2005, 12:34

any feedback about the new ffdshow?

clsid

7th October 2005, 16:28

The configuration windows don't work.

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

SeeMoreDigital

7th October 2005, 20:17

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

7th October 2005, 20:29

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

SeeMoreDigital

7th October 2005, 20:41

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

7th October 2005, 22:57

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

8th October 2005, 02:49

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

8th October 2005, 13:12

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

8th October 2005, 22:53

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

9th October 2005, 04:42

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

9th October 2005, 12:15

bob0r

9th October 2005, 15:25

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

10th October 2005, 01:55

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

10th October 2005, 03:40

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

10th October 2005, 04:29

@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

10th October 2005, 06:03

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

Revgen

10th October 2005, 07:36

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

10th October 2005, 09:46

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

10th October 2005, 14:51

@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

10th October 2005, 15:59

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

10th October 2005, 16:55

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

Egh

10th October 2005, 19:39

@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

10th October 2005, 20:00

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

10th October 2005, 20:09

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

10th October 2005, 21:57

@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

11th October 2005, 01:05

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

11th October 2005, 03:14

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

11th October 2005, 09:43

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

11th October 2005, 19:59

@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

12th October 2005, 16:21

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

12th October 2005, 17:13

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

Inventive Software

13th October 2005, 12:21

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

esby

13th October 2005, 14:07

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

13th October 2005, 15:35

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

tedgo

13th October 2005, 18:29

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

14th October 2005, 15:37

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

14th October 2005, 16:08

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

14th October 2005, 16:15

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

14th October 2005, 16:44

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

14th October 2005, 16:50

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

bob0r

14th October 2005, 17:08

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

14th October 2005, 17:09

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

14th October 2005, 18:28

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

14th October 2005, 18:37

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

14th October 2005, 19:14

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

14th October 2005, 19:49

@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

14th October 2005, 20:25

@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

14th October 2005, 23:20

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

15th October 2005, 01:15

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

15th October 2005, 01:18

@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

15th October 2005, 03:39

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

15th October 2005, 05:19

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

15th October 2005, 06:14

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

celtic_druid

15th October 2005, 07:30

((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

15th October 2005, 13:55

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

15th October 2005, 14:27

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

15th October 2005, 14:30

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

15th October 2005, 14:54

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

15th October 2005, 15:59

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

15th October 2005, 17:40

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

15th October 2005, 18:06

Try libmad instead of mp3lib.

bob0r

15th October 2005, 18:09

@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

15th October 2005, 18:10

Try libmad instead of mp3lib.

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

marcellus

15th October 2005, 18:53

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

15th October 2005, 19:28

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

bob0r

15th October 2005, 19:28

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

15th October 2005, 20:03

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

bob0r

15th October 2005, 20:12

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

15th October 2005, 21:35

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

16th October 2005, 10:41

Hi Guys,

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

Bye,
Alex

bob0r

16th October 2005, 16:28

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

16th October 2005, 19:08

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

Egh

16th October 2005, 20:25

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

17th October 2005, 01:30

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

17th October 2005, 06:11

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

17th October 2005, 07:02

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

17th October 2005, 14:18

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

17th October 2005, 15:08

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

17th October 2005, 18:14

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

17th October 2005, 21:32

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

17th October 2005, 22:43

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

17th October 2005, 22:49

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

18th October 2005, 00:54

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

vortex_hl

18th October 2005, 01:07

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

NoX1911

18th October 2005, 01:36

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

18th October 2005, 02:08

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

18th October 2005, 02:25

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

18th October 2005, 02:37

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

18th October 2005, 03:05

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

18th October 2005, 03:15

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

Sharktooth

18th October 2005, 03:48

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

Egh

18th October 2005, 04:32

My observations on recent builds:

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

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

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

movax

18th October 2005, 05:21

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

Kurosu

18th October 2005, 12:14

The following only happens for gcc.

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

Inventive Software

18th October 2005, 12:52

@Celtic_druid: Thank you SO much!

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

clsid

18th October 2005, 13:00

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

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

bob0r

18th October 2005, 14:26

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

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

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

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

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

celtic_druid

18th October 2005, 14:39

bob0r

18th October 2005, 14:43

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

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

celtic_druid

18th October 2005, 14:59

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

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

cc979

18th October 2005, 15:06

Kurosu

18th October 2005, 15:48

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

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

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

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

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

bob0r

18th October 2005, 16:38

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

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

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

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

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

@Kurosu

Understood and thanks.

bob0r

18th October 2005, 16:50

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

i have nforce2 ultra mobo with an athalon2400

gcc = gcc 4.0.2
msvc = msvc 7.1

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

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

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

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

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

videomixer9

18th October 2005, 19:51

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

NoX1911

18th October 2005, 21:07

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

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

cc979

18th October 2005, 22:44

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

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

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

i could test more if you want.

cc979

18th October 2005, 23:05

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

spp deblocking is ok on this

Blkbird

19th October 2005, 00:17

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

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

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

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

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

NoX1911

19th October 2005, 02:16

If you want to benchmark more seriously...

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

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

Liisachan

19th October 2005, 03:02

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

clsid

19th October 2005, 11:23

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

Leak

19th October 2005, 11:35

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

np: Thomas Fehlmann - Hana (Lowflow)

clsid

19th October 2005, 12:23

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

cc979

19th October 2005, 19:54

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

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

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

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

bob0r

19th October 2005, 20:16

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

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

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

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

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

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

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

Compiled a new TEST build, all files gcc 4.0.2

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

Inventive Software

19th October 2005, 20:27

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

cc979

19th October 2005, 20:59

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

but keep up the good work

lazyn00b

19th October 2005, 22:56

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

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

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

vortex_hl

20th October 2005, 00:12

Egh

20th October 2005, 00:16

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

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

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

cc979

20th October 2005, 00:34

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

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

movax

20th October 2005, 01:23

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

Nope, the Intel Compiler costs a pretty penny.

NoX1911

20th October 2005, 03:02

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

bob0r

20th October 2005, 04:37

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

but keep up the good work

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

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

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

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

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

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

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

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

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

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

Good question, ill test this later on aswell :D

vidhead

20th October 2005, 05:00

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

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

celtic_druid

20th October 2005, 07:07

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

Liisachan

20th October 2005, 08:12

Inventive Software

20th October 2005, 09:38

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

clsid

20th October 2005, 11:51

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

Sharktooth

20th October 2005, 13:00

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

dimzon

20th October 2005, 13:58

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

Leak

20th October 2005, 14:21

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

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

Sharktooth

20th October 2005, 14:54

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

dimzon

20th October 2005, 15:39

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

madman1980

21st October 2005, 00:06

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

Egh

21st October 2005, 04:09

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

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

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

I'm glad I'm not alone :)

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

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

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

Liisachan

21st October 2005, 15:00

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

Sharktooth

21st October 2005, 15:18

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

Liisachan

21st October 2005, 15:36

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

bob0r

21st October 2005, 15:38

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

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

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

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

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

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

Egh

21st October 2005, 16:46

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

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

clsid

21st October 2005, 18:36

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

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

Egh

21st October 2005, 20:42

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

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

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

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

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

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

ExtraEye

21st October 2005, 20:48

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

bob0r

21st October 2005, 21:02

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

So the following was done:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Good luck :D

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

clsid

21st October 2005, 22:38

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

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

Liisachan

22nd October 2005, 00:33

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

videomixer9

22nd October 2005, 02:00

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

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

canuckerfan

22nd October 2005, 04:47

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

MacAddict

22nd October 2005, 04:48

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

AMD XP TB 2.1Ghz

Egh

22nd October 2005, 05:29

Well, nice to have more builds to test.

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

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

2. ICL9 only build. Plays quite ok.

3. MSVC plays quite ok :)

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

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

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

Liisachan

22nd October 2005, 06:08

2. ICL9 only build. Plays quite ok.

3. MSVC plays quite ok :)

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

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

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

PatchWorKs

22nd October 2005, 09:44

...and what about encoding ?

Zephir

22nd October 2005, 16:09

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

videomixer9

22nd October 2005, 17:21

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

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

ExtraEye

22nd October 2005, 18:04

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

clsid

22nd October 2005, 19:13

My test results for the all gcc build:

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

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

TomsMoComp and kernelDeint are much slower as their ICL versions.

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

General remarks:

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

Egh

22nd October 2005, 20:57

My test results for the all gcc build:

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

TomsMoComp and kernelDeint are much slower as their ICL versions.

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

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

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

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

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

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

Egh

22nd October 2005, 21:00

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

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

Kurosu

22nd October 2005, 21:08

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

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

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

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

cc979

22nd October 2005, 21:38

very good work, bob0r :thanks:

all tested by uninstall then install

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

(d) crashed

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

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

bob0r

22nd October 2005, 23:45

...

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

I explained how i did this, but:

ffdshow_gcc.sh (without sse2):

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

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

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

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

bob0r

23rd October 2005, 02:36

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

Even better tip, just never use postprocessing :cool:

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

---

My test results for the all gcc build:

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

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

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

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

So it may be a Media Player Classic bug?

---

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

Egh

23rd October 2005, 04:35

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

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

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

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

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

Liisachan

23rd October 2005, 06:34

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

azsd

23rd October 2005, 11:12

Celtic Druid build version 20051013

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

Egh

23rd October 2005, 11:54

G00D.

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

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

clsid

23rd October 2005, 12:40

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

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

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

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

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

Liisachan

23rd October 2005, 13:54

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

edit: sorry, a typo in nick

clsid

23rd October 2005, 14:59

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

Thomas_AR

23rd October 2005, 16:04

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

Egh

23rd October 2005, 16:18

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

and @clsid

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

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

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

bob0r

23rd October 2005, 23:44

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

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

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

Fixed :)

bob0r

23rd October 2005, 23:46

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

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

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

movax

24th October 2005, 03:47

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

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

Egh

24th October 2005, 03:56

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

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

movax

24th October 2005, 04:08

What about the ICLs? Wake up and test :P

bob0r

24th October 2005, 11:39

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

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

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

bob0r

24th October 2005, 12:40

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

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

Any clue which update this could be?

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

zeflash

24th October 2005, 14:27

Thomas_AR

24th October 2005, 15:31

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

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

marcellus

24th October 2005, 16:04

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

Thomas_AR

24th October 2005, 16:22

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

cc979

24th October 2005, 19:16

hi bob0r,

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

TortoiseCVS makes it a lot easy for getting cvs's

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

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

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

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

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

spp is a bit funny works fine on always settings

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

Egh

24th October 2005, 19:50

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

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

@Someone who reported "Remaining time" bug:

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

Egh

24th October 2005, 20:06

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

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

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

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

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

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

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

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

movax

24th October 2005, 20:10

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

clsid

24th October 2005, 21:31

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

libavcodec/mplayer are gcc 4.0.2
Everything else ICL9

cc979

24th October 2005, 22:00

hi bob0r

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

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

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

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

sorry for the bad gramma...lol

Thomas_AR

24th October 2005, 22:09

OFFTOPIC:
@cc979
What is 'Clipman 3' ?

clsid

24th October 2005, 22:58

@cc979

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

cc979

24th October 2005, 23:00

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

libavcodec/mplayer are gcc 4.0.2
Everything else ICL9

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

cc979

24th October 2005, 23:18

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

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

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

bob0r

24th October 2005, 23:47

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

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

cc979

25th October 2005, 01:44

@clsid and bob0r

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

thuan

25th October 2005, 02:22

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

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

movax

25th October 2005, 04:20

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

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

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

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

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

thuan

25th October 2005, 05:33

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

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

bob0r

25th October 2005, 12:31

@movax

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

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

bob0r

25th October 2005, 17:18

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

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

Revgen

25th October 2005, 18:01

Is it absolutely neccessary to use GCC?

Can't MSVS or ICL be used instead?

clsid

25th October 2005, 19:54

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

bob0r

25th October 2005, 20:09

Is it absolutely neccessary to use GCC?

Can't MSVS or ICL be used instead?

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

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

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

Getting faster and faster :)

Revgen

25th October 2005, 22:53

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

Thanks! :)

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

Koti

25th October 2005, 23:57

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

canuckerfan

26th October 2005, 03:15

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

Sharktooth

26th October 2005, 03:27

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

cc979

26th October 2005, 05:52

@cc979

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

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

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

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

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

marcellus

26th October 2005, 08:42

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

dimzon

26th October 2005, 10:04

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

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

clsid

26th October 2005, 10:45

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

marcellus

26th October 2005, 12:14

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

videomixer9

26th October 2005, 12:37

amazing enough someone still encodes to mpeg2 hahaha ...

dragongodz

26th October 2005, 12:46

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

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

videomixer9

26th October 2005, 12:51

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

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

Sharktooth

26th October 2005, 13:11

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

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

dimzon

26th October 2005, 13:53

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

Leak

26th October 2005, 16:12

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

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

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

np: Michael Mayer - Slowfood (Touch)

dimzon

26th October 2005, 16:17

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

clsid

26th October 2005, 16:42

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

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

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

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

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

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

cc979

26th October 2005, 20:11

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

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

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

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

videomixer9

26th October 2005, 20:27

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

clsid

26th October 2005, 21:20

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

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

MacAddict

26th October 2005, 21:35

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

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

cc979

26th October 2005, 22:36

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

sth. ?

kurt

26th October 2005, 22:44

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

bob0r

26th October 2005, 23:53

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

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

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

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

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

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

cc979

27th October 2005, 08:30

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

never tried that yet, is it ok

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

kurt

27th October 2005, 10:54

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

bob0r

27th October 2005, 11:49

...

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

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

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

cc979

27th October 2005, 14:27

@ bob0r

cheers

Blue_MiSfit

28th October 2005, 00:45

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

THANKS A MILLION DEVS!!!

ExtraEye

28th October 2005, 14:39

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

that on celtic druids 25/10 build

Egh

28th October 2005, 19:08

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

that on celtic druids 25/10 build

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

ExtraEye

28th October 2005, 22:21

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

thuan

29th October 2005, 01:16

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

Egh

29th October 2005, 01:36

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

It's a strange build.

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

Though build itself says it's 27 oct.

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

thuan

29th October 2005, 02:06

Egh

29th October 2005, 03:08

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

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

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

canuckerfan

29th October 2005, 04:25

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

thuan

29th October 2005, 09:57

cc979

30th October 2005, 01:02

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

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

Liisachan

30th October 2005, 05:31

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

cc979

30th October 2005, 10:21

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

i got winmerge, its for text files not folders

bob0r

30th October 2005, 12:08

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

...

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

Liisachan

30th October 2005, 12:11

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

cc979

30th October 2005, 14:34

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

i'll check thanx

DeeGee

31st October 2005, 13:50

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

gaekwad2

31st October 2005, 15:26

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

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

DeeGee

31st October 2005, 15:55

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

[edit]

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

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

gaekwad2

31st October 2005, 20:00

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

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

Egh

31st October 2005, 20:47

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

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

yeah true.

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

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

bob0r

2nd November 2005, 17:40

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

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

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

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

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

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

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

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

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

Edit 02:
new error:

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

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

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

Reported.

bob0r

2nd November 2005, 18:54

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

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

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

clsid

2nd November 2005, 21:33

@bobor

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

SeeMoreDigital

2nd November 2005, 22:08

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

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

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

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

Cheers

Leolo

2nd November 2005, 22:39

bob0r

2nd November 2005, 22:47

@bobor

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

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

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

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

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

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

Thanks clsid

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

thuan

3rd November 2005, 04:55

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

Will test more. Thanks for your hard work.

Inventive Software

3rd November 2005, 10:25

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

Egh

3rd November 2005, 13:11

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

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

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

videomixer9

3rd November 2005, 13:24

Hi,

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

Shouldn't YV12 be the closest matching colorspace?

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

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

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

I'm all in doubt!

Many thanks in advance,
Best regards.

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

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

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

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

bob0r

3rd November 2005, 15:42

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

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

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

Smiff

3rd November 2005, 20:03

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

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

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

bob0r

3rd November 2005, 20:03

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

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

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

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

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

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

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

3rd November 2005, 21:13

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

bob0r

3rd November 2005, 23:23

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

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

Liisachan

3rd November 2005, 23:27

:thanks: bob0r !!

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

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

bob0r

3rd November 2005, 23:57

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

Slave01

4th November 2005, 00:41

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

John Slave

Revgen

4th November 2005, 04:11

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

John Slave

Which Version?

How does it not work?

No video?

Bad Video?

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

Egh

4th November 2005, 05:46

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

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

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

4th November 2005, 08:31

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

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

celtic_druid

4th November 2005, 08:57

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

Slave01

4th November 2005, 09:57

Which Version?

How does it not work?

No video?

Bad Video?

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

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

bob0r

4th November 2005, 13:16

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

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

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

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

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

signatory

4th November 2005, 13:33

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

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

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

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

bob0r

4th November 2005, 16:29

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

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

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

clsid

4th November 2005, 17:51

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

bob0r

4th November 2005, 17:56

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

Can you put the aac audio file online?

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

movax

4th November 2005, 18:00

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

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

Egh

4th November 2005, 20:30

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

BTW, where's your build? :)

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

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

Thomas_AR

4th November 2005, 20:38

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

Egh

4th November 2005, 21:35

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

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

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

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

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

Thomas_AR

4th November 2005, 21:57

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

Shirokuu

4th November 2005, 22:54

Egh

5th November 2005, 00:34

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

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

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

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

celtic_druid

5th November 2005, 05:25

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

signatory

5th November 2005, 11:41

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

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

videomixer9

5th November 2005, 12:01

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

signatory

5th November 2005, 12:50

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

Egh

5th November 2005, 13:51

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

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

signatory

5th November 2005, 13:56

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

bob0r's own words.

_xxl

5th November 2005, 15:34

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

Egh

5th November 2005, 15:50

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

bob0r's own words.

that's VERY old.

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

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

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

Egh

5th November 2005, 15:52

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

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

bob0r

5th November 2005, 15:55

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

Hmm indeed does Not work.

I already reported this "bug" to Milan.

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

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

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

_xxl

5th November 2005, 15:59

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

_xxl

5th November 2005, 16:04

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

_xxl

5th November 2005, 16:31

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

celtic_druid

5th November 2005, 16:39

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

bob0r

5th November 2005, 16:52

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

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

Is this still an issue?

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

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

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

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

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

Who What Where?

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

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

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

bob0r

5th November 2005, 17:42

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

bob0r's own words.

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

o2xygen

5th November 2005, 18:01

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

_xxl

5th November 2005, 18:07

MMX capable CPU

Intel :

Pentium MMX
Celeron
Pentium II
Pentium III
Pentium 4

AMD :

K6
K6-2
K6-3
Athlon
Duron

SSE capable CPU

Intel :

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

AMD :

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

SSE2 capable CPU

Intel :

Pentium 4

AMD :

Athlon 64

ffdshow-20051103.exe gcc sse

bob0r

5th November 2005, 18:33

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

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

clsid

5th November 2005, 20:14

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

bob0r

5th November 2005, 21:40

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

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

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

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

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

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

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

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

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

celtic_druid

6th November 2005, 07:36

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

zilexa

6th November 2005, 12:43

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

just to be 100% sure:

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

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

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

thuan

6th November 2005, 12:46

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

Seed

6th November 2005, 16:18

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

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

bob0r

6th November 2005, 17:46

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

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

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

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

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

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

zilexa

6th November 2005, 18:28

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

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

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

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

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

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

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

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

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

bob0r

6th November 2005, 18:56

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

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

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

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

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

Best way to find out is to test!

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

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

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

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

signatory

6th November 2005, 19:14

Dark_Angel_PT

6th November 2005, 19:25

(...)

SSE2 capable CPU

Intel :

Pentium 4

AMD :

Athlon 64

ffdshow-20051103.exe gcc sse

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

bob0r

6th November 2005, 20:03

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

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

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

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

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

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

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

ExtraEye

6th November 2005, 20:30

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

canuckerfan

6th November 2005, 21:27

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

videomixer9

6th November 2005, 22:29

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

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

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

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

canuckerfan

6th November 2005, 23:13

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

zilexa

7th November 2005, 00:18

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

clsid

7th November 2005, 00:43

Egh

7th November 2005, 05:36

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

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

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

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

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

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

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

videomixer9

7th November 2005, 10:17

oddball

7th November 2005, 16:04

ffdshow audio decoding annoyances.

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

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

Egh

7th November 2005, 16:05

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

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

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

Egh

7th November 2005, 16:08

ffdshow audio decoding annoyances.

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

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

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

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

oddball

7th November 2005, 16:15

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

bob0r

7th November 2005, 16:27

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

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

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

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

sorry for the wrong post...
...

You can delete messages by hitting Edit.

ExtraEye

7th November 2005, 17:25

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

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

bob0r

7th November 2005, 20:41

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

ffdshow-20051107.exe online (see signature)

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

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

All files gcc 4.0.2 (SSE2 Disabled)

Enjoy.

SeeMoreDigital

7th November 2005, 20:50

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

Cheers

Thomas_AR

7th November 2005, 22:09

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

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

clsid

7th November 2005, 22:27

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

Inventive Software

8th November 2005, 13:33

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

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

SeeMoreDigital

8th November 2005, 15:49

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

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

Cheers

stephanV

8th November 2005, 17:29

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

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

SeeMoreDigital

8th November 2005, 18:09

If you set ffdshow to also handle uncompressed audio, maybe it would work. It will then normally connect itself to the audio decoder in the filter graph.Just tried it.... and it works a treat with both WMA9 Pro and 6Ch WAV streams :)

Very nice thank-you

bob0r

8th November 2005, 19:00

16:55 on Nov 08, 2005
updated libavcodec
http://cia.navi.cx/stats/project/ffdshow/.message/6335701

I see what files are updated, but i dont see what what exactly in libavcodec is updated. Is there anyway to see a CURRENT CVS changelog via cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffmpeg co -P modulename ?

also:

17:24 on Nov 08, 2005
autoupdate version for GCC builds
http://cia.navi.cx/stats/project/ffdshow/.message/6336306

What is that support to mean, autoupdate??

marcellus

8th November 2005, 19:31

Kurosu

8th November 2005, 20:13

16:55 on Nov 08, 2005
updated libavcodec
http://cia.navi.cx/stats/project/ffdshow/.message/6335701
I see what files are updated, but i dont see what what exactly in libavcodec is updated. Is there anyway to see a CURRENT CVS changelog
cvs -H log to see how to check the unreadable log.
Or alternatively, use something like cvs2cl.pl with perl installed somewhere.

autoupdate version for GCC builds
[...]
What is that support to mean, autoupdate??
If you check the Makefile, you see that now bin/verinc.exe gets build with gcc. This updates src/version.ver which gets included by src/version.h
This allows updating the ffdshow version displayed in the About part of the ffdshow dialog window.

bob0r

8th November 2005, 20:38

...

If you check the Makefile, you see that now bin/verinc.exe gets build with gcc. This updates src/version.ver which gets included by src/version.h
This allows updating the ffdshow version displayed in the About part of the ffdshow dialog window.

You mean this?
http://mirror05.x264.nl/public/ffdshow_version.jpg

It already updates on a new compile?

Edit:
Quote by Milan:

It was enabled for VS builds only.There is pre-link action
which increases version stored in src/version.ver and I tried to
add similar behavior to makefile too.

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

It already did this, thats why i was confused, thanks.

Edit2:
Quote by Milan:

It's about different version number: the one stored in dll file
which isn't displayed anywhere in ffdshow, but can be used,
for example, by installers to compare file versions.

Its all clear now.

Lemonzest

8th November 2005, 22:27

any chance of a regular SSE2 GCC build? it works great on my Athlon64

Rash

9th November 2005, 01:31

Whoosh! It's hard to keep up! It seems the ffdshow development is in its full force right now. :D And for that I only came here to express my real gratitude to the developers. Thank you very much guys.

And not just ffdshow, of course. Doom9 and MeGUI, the x264, MPC amongst many others. You guys rule it!

Czarek Kwasny

9th November 2005, 07:08

i hope i won't be ignored. If it's wrong place for posting please correct me.
I tried playback of HDTV content via MPlayer and after some optimizations it plays fine. I find FFDShow much more versatile thus I'd like to switch to it. The problem remains in performance. If I playback files in MPlayer with parameters: -vfm ffmpeg -lavdopts lowres=0:fast:skiploopfilter=all I get very good performance. Is it possible to implement or somehow turn on such optimization for FFDShow?

videomixer9

9th November 2005, 12:53

skiploopfilter ... isn't that turning of all h264 deblocking ... you can select in ffdshow to skip deblocking and increase h264 playback performance. You find that option in the codec selection page, select h264 in the list and two checkboxes appear, check "skip deblocking always" there. However the video may now suffer from macroblocking, especially if it's encoded with x264. dshow doesn't like to drop frames very much and pretty many players don't offer to drop frames, cannot help on that trick mplayer usually does when it starts lagging. If you're talking about usual MPEG4 or MPEG2 HDTV content I wouldn't know much of a way to speed up decoding. However if your PC is too slow, don't use VMR9 for playback, VMR is a total CPU muncher. mplayer pretty much offers the same things as ffdshow, it also comes with many filters you can use via -vf but which are almost all not documented well. The drawback is the crappy DVD menu support and the crappy subtitle renderer.

Egh

9th November 2005, 13:22

skiploopfilter ... isn't that turning of all h264 deblocking ... you can select in ffdshow to skip deblocking and increase h264 playback performance. You find that option in the codec selection page, select h264 in the list and two checkboxes appear, check "skip deblocking always" there. However the video may now suffer from macroblocking, especially if it's encoded with x264.

Well, depends on the bitrate of the video and [de]blocking filter settings used. As a rule of thumb, the higher is bitrate for same frame size, the less is impact on macroblocking. With something like 1600kbps bitrate it's safe to turn of blocking inloop filter completely.

Also there's an option "skip when safe". It uses a bit more resources than skipping always, but doesn't produce any artefacts.

Czarek Kwasny

9th November 2005, 13:53

Thank you very much for the inforamation!
"skip deblocking always" works just great! I tried Skip when safe but i got a little jerky playback so decided to stay with "always". Now I get the mplayer's performance with support for subtitles, and AAC 5.1 sound :). Makes me happy. I had troubles with setting up mplayer for QuickTime HD trailers (H.264 + 5.1 LC-AAC), this seems to be the problem no more... I also switched from VMR to Overlay Mixer in MPC setup to speedup the performance.

bob0r

9th November 2005, 17:24

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

ffdshow-20051109.exe online (see signature)

Compiled files up to:
08:54 on Nov 09, 2005
"remember virtualdub plugins folder"
http://cia.navi.cx/stats/project/ffdshow/.message/6343176

Main reason for update:
16:55 on Nov 08, 2005
"updated libavcodec "
http://cia.navi.cx/stats/project/ffdshow/.message/6335701

+ all other many updates

All files gcc 4.0.2 (SSE2 Disabled)

Enjoy.

(SSE2 build for those interested: http://mirror05.x264.nl/public/ffdshow/ffdshow-20051109-gcc4.0.2-sse2.exe)

signatory

9th November 2005, 17:56

Thanks Bob0r ! :D

MacAddict

9th November 2005, 18:08

Cool! Thanks for the new builds.

asasadad_1

9th November 2005, 18:19

libmpeg2_ff.dll(gcc) had a higher cpu usage than libmpeg2_ff.dll(msvc or icl 9) :confused:

ExtraEye

9th November 2005, 18:24

thx for the new (SSE2) build bob0r.
i still have the problem with the avisynth filter.

Lemonzest

9th November 2005, 18:56

(SSE2 build for those interested: http://mirror05.x264.nl/public/ffdshow/ffdshow-20051109-gcc4.0.2-sse2.exe)

Thanks :)

madman1980

10th November 2005, 02:08

Is there any chance you could make these settings default in future ffdshow builds?

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

It enables the aspect ratio to change to the ratio specified in the file, which might be different from the ratio according to the pixel ratio. This should really be natural behavior, just look at MPEG2, both DVD and SVCD data need the aspect ratio info to play correctly. I have a big problem now with divx/xvid files that have big black bars vertically and horisontally and look really squeezed.

MacAddict

10th November 2005, 02:12

Does the overlay mixer have to be selected though?

Sharktooth

10th November 2005, 03:25

LoRd_MuldeR made me notice milan restarted his daily builds:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

Egh

10th November 2005, 04:48

Does the overlay mixer have to be selected though?

IIRC you need to make it half-on :) aka not checked and not unchecked.

But, imo, then it doesn't use software resizer to do actual resizing. Since i prefer quality (and my card doesn't support PS 2.0 anyway :P) I use ffdshow software resizer both to resize the frame to fullscreen and to adjust aspect ratio. Keep on bugging Milan to implement using DAR automatically :P

Thomas_AR

10th November 2005, 04:53

The last build from Milan is amazing. The setup file is 1MB smaller and testing the same avi video with other last ffdshow builds (same configuration) i have 15% less CPU usage.

madman1980

10th November 2005, 07:17

Does the overlay mixer have to be selected though?

Yep, to clarify, those two marked boxes are not checked by default.

marcellus

10th November 2005, 09:23

The last build from Milan is amazing. The setup file is 1MB smaller and testing the same avi video with other last ffdshow builds (same configuration) i have 15% less CPU usage.
Yes, I got about the same result (~10% lower CPU usage). FFDshow gets faster and faster. A few days ago the fastest build for my Athlon XP was still celticdruid's 20051103. But now the top looks like this:
1. milan's 20051109 (by far)
2. bob0r's 20051109
3. celticdruid's 20051103 <-- which is fast anyway
Conclusion: a) GCC gains speed vs. ICL, b) milan has a "magic" trick in his sleeve when it comes to compiling.
Anyway, good bye dropped frames :cool: :cool: :cool:
Big :thanks: to everyone involved!

bob0r

10th November 2005, 10:54

Do note, most of Milan's compiled files seem to be ICL 8.
Celtic_Druid's compiled files are mostly ICL 9.

Milan does not support ICL 9, so this might be the reason why ICL 8 builds are faster than ICL 9.

As for GCC, we are getting there :cool:

celtic_druid

10th November 2005, 12:07

gcc with specific CPU flags might be faster. I guess I could re-install ICL8 and see if there is indead some magic involved or it is just faster than ICL9. I guess on Intel chips ICL9 should be faster.

Smiff

10th November 2005, 15:13

are we getting consistently stable builds yet? is Milan's good for Sempron K8 SSE2? i've stopped on 2005-10-06 build (not sure whose, oops) becuase that was stable, but would like to update again when its safe :p

Sharktooth

10th November 2005, 15:49

get it ... find it by yourself...
if you dont like it reinstall your old version.

Smiff

10th November 2005, 18:13

heh thanks but no thanks, friends and family like to be able to watch movies without crashes, if it was just on my own machine for my amusement, yeah.
was just a friendly request for anyone who's done the research on similar CPU, no point everyone repeating the trouble.. sorry but i don't have time to contribute to everything i would like to. i just think it would be worthwhile, someone maintaining a list of which builds are confirmed good on which CPUs, this is only a suggestion for someone with the time so don't get all angry please. and thanks again to everyone spending time making compiles etc etc, love you even when they don't work so well, 'cos i couldn't do it :)

i can (only) confirm the 2005-10-06 build with installer MD5 hash 5B9F67AA1ACE3049FEA7AB6527025E1D
is stable on K8 SSE2 Sempron, for DVD levels and MPEG4
as long as you don't use resizers etc, then things get iffy.

Egh

10th November 2005, 18:33

i can (only) confirm the 2005-10-06 build with installer MD5 hash 5B9F67AA1ACE3049FEA7AB6527025E1D
is stable on K8 SSE2 Sempron, for DVD levels and MPEG4
as long as you don't use resizers etc, then things get iffy.

There were plenty stable builds after 1006. E.g. 1013 celtic's. And most instability/slowdowns problems were with gcc builds. Once those gcc-specific issues were fixed, gcc now is as good or excels ICL builds.

So just grab 1109 b0b0r's one :)

videomixer9

10th November 2005, 21:38

I wonder what ppl got with the resizers, imo the hardware resizer used on overlay mixing is enough with any modern graphics card and also uses zero CPU. All those 3D Hardware using renderers are total bloat anyways, and they rarely deliver real better quality, it's just a solution to render the video into the same colorspace as the rest of the screen and obviously shows how reduced the colorspaces used for videos are. Basically it just eats up performance that modern graphic cards are handling internally usually. There are a few bonuses, but they aren't really worth it.

For me the last gcc build works great and still has better performance than milans build on athlon xp (barton). After some issues it had before with libmpeg2 using too much CPU it works great and stable now, never crashed. But for decoding I don't use all those stupid toys anyways, as I have no need for them, nvidia drivers correct tv out overscan perfectly for me, resizing is done in the hardware just fine too, and postprocessing on most videos just make them lose all details, with the most cpu intensive spp postprocessing being the most crappy one even, but it was always crap since it hit mplayer.

oddball

10th November 2005, 22:11

For anyone like me who likes to transcode 6 channel Ogg or 6 channel AAC rips to AC3 SPDIF output (To be played by on your AC3 reciever) whilst leaving 2 channel PCM untouched. Here is a great tip from Milan.

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

Socio

11th November 2005, 14:13

_xxl

11th November 2005, 14:23

http://www.elecard.ru/movies/Olesya/OLESY_SIF_90kbps.mp4
ffdshow avc h.264 mobile
Microsoft Visual C++ Runtime Library
Assertion Failed!
Program...Media Player Classic 6.4.8.6 and Media Player 2
File libavcodec/h264.c
line 7755
EXPRESSION Pict--Data[0]
Amd XP 1600+ winXP Sp2
Tested with:
Milan's compiled fdshow-20051109.exe ICL8 and bob0r's fdshow-20051109.exe sse GCC.

Egh

11th November 2005, 15:03

I don't know if it has been reported yet but I found a bug in the ffdshow-20051109-gcc4.0.2-sse2 version I am using , I don't know if it is just this this version or if it is happening with the other 200051109 version.
The bug is with Gradual denoise, if I try to enable it, it will crash any program I am using ffdshow with.

Are you sure you have SSE2 cpu? :P At least generic build 20051109 doesn't have that problem (tested on Athlon XP).

@ Earlier reporters comparing daily build and b0b0rs:

WHERE the hell you see any speed *increase*? As for playback of avc streams, I didn't notice any and if not some DEcrease was actually spotted.

Anyhow, plain gcc build is now terrific in speed :) I managed (but with all quality options disabled) only in YUY2+overlay and no softsubs, no resizing to playback a video. But WHAT a video! :P 960*544 *HIGH-PROFILE-AVC*!!! [ref=3,b=1]. Used separete fields on .TS [1088i] source and then resized horizontally. So that's 960*544 and 29.97fps all the way with average bitrate 2500kbps! And was able to play it without any frame drops on 1800+ XP (though somehow only with b0b0r build, with same settings Milan build was somewhat slower). That's terrific improvement in speed in the last month for gcc!

Edit
BTW, just now experemented a bit and somehow managed to play normally (though 99% of times cpu usage is 100%) in VMR9 renderless mode in RGB32 colorspace. Heh, I thought that wasn't possible for my cpu at all :P

IgorC

11th November 2005, 15:39

marcellus

11th November 2005, 15:53

@ Earlier reporters comparing daily build and b0b0rs:
WHERE the hell you see any speed *increase*? As for playback of avc streams, I didn't notice any and if not some DEcrease was actually spotted.

I'm sorry, ffdshow seem to have many uses (not only many users) and sometimes maybe we are comparing apples to oranges. I use ffdshow almost exclusively for encoding/recording (as I don't like to watch anything on my PC, I watch on standalone + TV set). It's in fact the most customizable libavcodec based encoder (besides mencoder) that has also a DShow interface that makes it suitable to work with capturing applications.

So, to be exact, my chain is(In general, when I post in this thread, this is what I'm talking about):
PAL TV capture -> leakkerneldeinterlace -> mpeg2 encoding. This is (way) faster with milan's build.

At some point it may be useful to make a test of speed for different builds but all made on the same CVS version and the same filterchain for decoding/encoding. There are so many cases that I'm scared (CPUs, compilers, codecs, audio, video, filters) but this is ffdshow and we love it for what it is :)

ExtraEye

11th November 2005, 16:54

Egh

11th November 2005, 18:43

bah... avisynth filter not working for me at any of the recent versions.
am i doing something wrong?
about the colorspace...
it used to take much less cpu to convert to RGB32. now it makes playback jerky for me (AMD 64 3000+).
is there any profit from making the output yuy2 instead of yv12?
last question, what's the advantage in playing the video through VMR9 renderless?

w00t? Well, no idea why you think RGB32 conversion is taking more. In fact for gcc builds there was a problem until last October builds which caused terribly slow and screwed YV12-->RGB conversion. Now VMR9+RGB32 playback prooly a bit faster than even Celtic builds. As I said already, I was shocked to discover practically non-framedrop playback of avc 960*544@29.97fps in RGB VMR9. Judging from previous builds performance, I thought that it would be slightly out of reach for my 1800+, but last b0b0r build prooved I was wrong :P

About VMR9 :readguid: . In short [for MPC] : VMR9 subtitle rendering plugin, DirectX9 rendering (means PS 2.0 support if your card has it). For at least older cards, VMR9+RGB32 typically has better quality than overlay. My card is GForce4MX (128MB DDR), so no pixel shaders but i still use VMR+RGB cause it simply has better quality (better colors and sharpness of the picture).

ExtraEye

11th November 2005, 19:10

hmmm
o.k thx for the info.
i tried switching to bob0r's latest instead of milan's and now it works great.
umm egh, does avisynth filter work for you?

Socio

11th November 2005, 21:47

Are you sure you have SSE2 cpu? :P At least generic build 20051109 doesn't have that problem (tested on Athlon XP).

Yes I have a P4 3.06 which has SSE2,

Liisachan

12th November 2005, 00:46

I'm getting this "Assertion failed!" for AVC.mp4 too:
File: libavcodec/h264.c
Line: 2590
Expression: pic->data[0]

Tested: milan 20051109, celtic_druid 20051103, bob0r 20051109 etc,
with or without Haali.

x264 settings (a shorter test clip with the exatctly same settings IS OK!):

"x264.exe" --pass <1|2> --bitrate 1150 --stats "stats.log" --keyint 240 --min-keyint 24 --ref 16 --bframes 1 --filter 3:0 --subme 7 --weightb --trellis 2 --analyse all --8x8dct --qpmin 8 --qpmax 30 --qpstep 12 --ipratio 1.3 --pbratio 1.4 --me umh --merange 32 --threads 1 --progress --scenecut 35 --fps 23.976 --output <NUL|"out.mp4"> "in.avs"

I used celtic_druid's 361M, and i think it ended normally with this msg "encoded 34259 frames, 1.56 fps, 1150.02 kb/s"

Egh

12th November 2005, 01:00

umm egh, does avisynth filter work for you?

Date: 2005-11-11 20:02
Sender: milan_cutka Project Admin

Fixed. Thanks for reporting this, it was very stupid mistake.

BTW I rewrote calling of avisynth to make in compatible with
GCC and this might introduce another bugs.

Also for those who not actively watches ffdshow development trackers would be interested in this info from Milan concerning different builds:

Date: 2005-11-11 16:36
Sender: milan_cutkaProject Admin

I'm sure ffdshow build with GCC won't run on Athlons without SSE. With -msse option which is required to compiler ffdshow using GCC, it generates code which use SSE registers. And with recently added -mfpmath=sse almost all floating point calculations use SSE.

Please report any problems which might be specific to GCC build, because I'm almost sure there are still some present. I'll be glad to replace ICL with GCC when GCC build won't contain more bugs than those created by Intel's compilers. However, ICL will still be needed for building versions which wouldn't require SSE.

I didn't get it :) I thought that plain gcc generic builds work on casual Thunderbirds, right?

So though developer is surely trying eventually to use only gcc for builds, but as for now he is not sure if gcc compilations are safe enough (though i personally think they are :P)

tritical

12th November 2005, 01:06

@Liisachan
I recently had the exact same problem with a number of x264 encodes produced with x264cli (r362 and few r350's, sharktooth's and x264.nl builds). I got the exact same error you posted with both my own compiles of ffdshow and celtic druid's. Through process of elimination I have found it too be a problem with x264cli's mp4 output... because if I redid the exact same encodes with the exact same settings, but used raw .264 output from x264cli and then muxed the result into mp4 with mp4box it would play perfectly. Another interesting result was that the second pass with raw output was noticeably faster than with mp4 output. The problem with mp4 output from x264cli doesn't seem to always happen as I could also make shortened encodes of the same clips, or other clips, with the same settings and they would play correctly.

Thomas_AR

12th November 2005, 01:43

@IgorC
Same here, MPC with ffdshow (tested various builds) alone won't play this video. But...
i installed 'Nero Digital MPEG 4 AVC h.264 dshow decoder v2.02'. Even with this codec installed the video is playing badly in MPC, only 4 seconds of 21 as it says in properties and no sound. Looks like a bad cut of a whole mp4 video. Possible?

Liisachan

12th November 2005, 03:06

@tritical
Thank you very much I'll try that :)

Axed

12th November 2005, 08:18

I didn't get it :) I thought that plain gcc generic builds work on casual Thunderbirds, right?

I've still got one of these egg cookers, ill try it and tell you.

Yep Milans correct, the GCC builds just crash straight away on an Thunderbird.
It is possible to get it to run XviD movies by turning off Post Processing and MP3 decoding albeit very, very, slowly.

Alternatively, i tried Milans build and it ran the XviD movie, handling the audio decoding and all at an average of 50% CPU usage using mplayer deblocking, brightness enhancement and a stereo - 5.1 upmix.

bob0r

12th November 2005, 13:40

I was planning on making ffdshow-2005Nov11.exe yesterday (new filename)
Now i wanted to make it today, but ffdshow sourceforge CVS is not updating anymore :confused:

Maybe its time to move over to SVN? :)

Expect a new build, with a new filename for less confusion, when CVS is updating again!

Edit:
http://sourceforge.net/docs/A04/

Project CVS Service: Partial Outage In-Progress Last updated: 2005-11-11 Pacific

( 2005-11-11 12:47:03 - Project CVS Service ) As of 2005-11-11 developer CVS is back online and operational. Anonymous CVS will be out of sync throughout the weekend as updates are processed.

( 2005-11-11 06:27:36 - Project CVS Service ) As of 2005-11-11 developer CVS service is presently offline for unplanned maintenance, estimated time of service restoration to be determined.

Guess can update after the weekend again :goodpost:

_xxl

12th November 2005, 17:52

http://cutka.szm.sk/files/ffdshow-20051111.exe

clsid

12th November 2005, 18:00

I think it is wise to add "-sse" to the filenames of GCC builds from now on.

Sharktooth

12th November 2005, 18:39

bah... i think SF should install and move everything to SVN... before they all collapse into a singularity...

videomixer9

12th November 2005, 22:37

I think there is a reason that many larger projects abondoned using SF and got their own CVS/SVN servers.

Sharktooth

13th November 2005, 15:55

yes, the problems SF have with CVS...

Socio

14th November 2005, 01:48

Egh

14th November 2005, 03:31

Is there a trick to get Virtualdub to show up in ffdshow?

During ffdshow installation I have tried pointing it to the main Virtualdub folder and to the Virtualdub plugin folder but either way it does not show up.

I am currently running ffdshow version ffdshow-20051111 if that helps.

It should be there. Both as an encoder (that's natural, ffdshow has vfw plugin so it should appear not only in vdub) and as an image processing filter (that what you need plugin for). Make sure you operate in RGB32 [Full Processing] mode in vdub first. And the name of the plugin as it appears in vdub filters list will be ffvdub, not ffdshow :P

And, the last but not the least, you need ffvdub in plugins folder, not main program one.

Liisachan

14th November 2005, 13:04

Audio decoder config box says "low accuracy mode enable(d)" for Vorbis.
Does anyone know what this "low accuracy mode" is and if it is possible to disable (?) it to make it high-accuracy?

celtic_druid

14th November 2005, 13:10

Commenting out #define _LOW_ACCURACY_ in os_types.h should do it. You could also use libavcodec instead of termor.

Leak

14th November 2005, 13:44

Is there a trick to get Virtualdub to show up in ffdshow?

During ffdshow installation I have tried pointing it to the main Virtualdub folder and to the Virtualdub plugin folder but either way it does not show up.
Ummm... if you really mean that you want to use VirtualDub's filters in ffdshow - that's not possible.

What this does is install a VirtualDub plugin to use ffdshow's filters in VirtualDub...

Liisachan

14th November 2005, 14:07

Commenting out #define _LOW_ACCURACY_ in os_types.h should do it. You could also use libavcodec instead of termor.
Thanks for the tip. I get a small but noticeable bzzzzzz noise when decoding vorbis in a specific OggFile by "termor", so I have to say "termor" is not as good as CoreVorbis. However, using libavcodec in ffdshow as vorbis decoder fixes the problem too.

celtic_druid

14th November 2005, 14:28

http://celticdruid.no-ip.com/test/ff_tremor.7z
compiled without #define _LOW_ACCURACY_

Liisachan

14th November 2005, 16:12

Thank you very much :) This sure fixes the problem.
I also ABXed 2 WAVs I got by:
Vorbis Decoder (ffdshow) -> WavDest -> .wav
using tremor, 20051103 normal against ff_tremor replaced,
and got 14/15. So _LOW_ACCURACY_ makes the decoded result significantly low-quality
at least in this specific sample.

EDIT
Still I think both tremor and libavcodec are not as reliable as CoreVorbis.

canuckerfan

15th November 2005, 03:54

shouldn't ffdshow get its own sub forum? it's hard keeping a track of everything ffdshow-related on one thread.

esby

15th November 2005, 09:01

@canuckerfan:
Your question is a recuring troll.
There were two ffdshow related thread, one got closed when the second was opened, the problem being that the thread was too long to be followed by 'new user'.
The second got closed some months ago in the goal of having the respective problem threated in the corresponding parts of the forum.
In theory, this thread should only talk of availability of the (recent) builds and their inner changes.
Now I don't want to enter the 'troll'.

esby

_xxl

15th November 2005, 11:35

http://cutka.szm.sk/files/ffdshow-20051115.exe

yester

15th November 2005, 11:40

ExtraEye

15th November 2005, 14:27

http://cutka.szm.sk/files/ffdshow-20051115.exe
no SSE or SSE2?

thuan

15th November 2005, 16:15

icl8 so SSE and SSE2 should be supported

bob0r

15th November 2005, 20:03

hello ffdshow fellows,

want to post an bugreport...

since the mid 2005 every new ffdshow alpha build crashes on my k6-2+ in the libavcodec (regardless which build)... ffmpeg lib was not affected but later removed ... so i want to ask if the developers (celticdruid?) may take an look into this topic ... (perhaps some problem with the 3dnow+ support without extended mmx support like athlon on the k6-2+ & k6-3+)

some other k6 or k6+ user got this problem?

Although celtic_druid is a great coder, he is not the ffdshow developer.

Please report your bug to the ffdshow developer straight, via source forge, here is the link:
http://sourceforge.net/projects/ffdshow
Bugs (report it here):
http://sourceforge.net/tracker/?group_id=53761&atid=471489

@all
Hmm, sourceforge has new outlook, CVS is still out-to-date though :(
Updating layout when your servers are slow and out-to-date to start with, who ever manages sourceforge, needs to be updated aswell :cool:

Egh

15th November 2005, 22:04

hello ffdshow fellows,

want to post an bugreport...

since the mid 2005 every new ffdshow alpha build crashes on my k6-2+ in the libavcodec (regardless which build)... ffmpeg lib was not affected but later removed ... so i want to ask if the developers (celticdruid?) may take an look into this topic ... (perhaps some problem with the 3dnow+ support without extended mmx support like athlon on the k6-2+ & k6-3+)

some other k6 or k6+ user got this problem?

are you sure you tried fully ICL build? I mean those recent daily builds from milan cutka himself. I believe those should support the biggest range of CPUs. most likely it's "shuffle" command iirc there was one bug related to that already. try browsing thru bugtracker.

btw, ffdshow now uses 3DNow! in a very limited way, and probably that is already redundant due to sse/sse2 support on all good more or less modern processors :)

Egh

16th November 2005, 14:43

http://www.torrentspy.com/directory.asp?mode=torrentdetails&id=449079&query=ffdshow
k6-2 cpu's maybe...

if chap previously tried full MSVC build from movax or b0b0r (he says he tried most latest builds as I understood) then this one will be no difference.

Though slow, I think MSVC builds should have no problems on K6-2. Test it and report :P

bob0r

16th November 2005, 20:54

ffavisynth compileable with GCC
http://cia.navi.cx/stats/project/ffdshow/.message/6426679

Yet this is not the case.
CVS finally updated and i tried to make a new build.

I have reported this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1358380&group_id=53761&atid=471489

My plan was to compile ffdshow-20051116-x264.nl.exe :sly:

Egh

16th November 2005, 23:10

ffavisynth compileable with GCC
http://cia.navi.cx/stats/project/ffdshow/.message/6426679

Yet this is not the case.
CVS finally updated and i tried to make a new build.

My plan was to compile ffdshow-20051116-x264.nl.exe :sly:

The explanation might in fact be quite simple -- it hasn't been updated yet :P
I mean CVS on SF. Last entry there is 32 hours ago (from atm, naturally), whilest there were two more entries after that (gcc compilation and DCT filter). Those are not shown at http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/?sortby=date
but shown at http://cia.navi.cx/stats/project/ffdshow .

bob0r

16th November 2005, 23:56

Nah you are wrong here

http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/imgFilters/?sortby=date

Is indeed updated. (finally (?) fixed DCT filter is the last update)

The files are updated, but something is broken.

Next build will have new filename, with even more info:
ffdshow-2005xxxx-gcc4.0.2-sse-x264.nl.exe

I also added

!define COMPRESSION "/FINAL /SOLID lzma" (instead of !define COMPRESSION lzma) which creates a smaller file.

Now we just have to wait for Milan to fix this bug and a new GCC build will be online ;)

_xxl

17th November 2005, 09:36

Best GNU License executable file compression and decompression utility that supports many executable file formats is UPX.It can be used for FFdshow.ax
and *.dll.
30-70% compression ratio!
upx.exe --best ffdshow.ax 2,883,584 bytes---upx=879,104 bytes
ratio 30.49%
upx.exe --best libavcodec.dll 2,674,176 bytes---upx=914,944 bytes
ratio 34.21%

madman1980

17th November 2005, 10:27

signatory

17th November 2005, 10:43

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.

celtic_druid

17th November 2005, 10:53

The nsi script could easy be changed to do it.
If you use upx, then the installer will most likely be larger.

cc979

17th November 2005, 12:36

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

what do you use to play videos, if mpc do you have touch from inside enabled on video frames options?

videomixer9

17th November 2005, 13:12

Do we really need to compress the ffdshow.ax and libavcodec.dll? My expierence is that compressing especially files build as dll introduce strange behaviour when they are compressed. Besides I don't think ppl got that less disk space nowadays, and the installer shouldn't be affected if you compress these files as it does pretty good compression itself.

dimzon

17th November 2005, 13:15

Do we really need to compress the ffdshow.ax and libavcodec.dll?
No! Please, stop compressing this files!

Inventive Software

17th November 2005, 13:22

The nsi script could easy be changed to do it.
If you use upx, then the installer will most likely be larger.
Not necessarily. The installer uses compression as well. UPX is streamlined for executables, LZMA is uniformly available for all file types. By using UPX on the already compressed installer, you are only getting a small payback with UPX. By using UPX on the components it supports and then using a suitable compression technique, you may well have more compression.

This is just theory, and my theories are usually flawed! :D

dimzon

17th November 2005, 13:51

Not necessarily
Wrong!

madman1980

17th November 2005, 13:59

what do you use to play videos, if mpc do you have touch from inside enabled on video frames options?

Yes I do, but this does not take into account the aspect ratio that is defined in the divx/xvid file if that is different from the resolution AR.

celtic_druid

17th November 2005, 14:02

If you UPX the ax/dll's then the installer won't be able to do as good a job at compressing them, so overall the filesize should go up, one installed though it will take up less space. Part of the installer is compressed with UPX by the way.

madman1980

17th November 2005, 14:03

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.

No, the reason is not special. The reason is something that everyone should care about. If an aspect ratio is specified in a xvid/divx file, it is not used with ffdshow by the default. This is what I want to change. If an AR is specified in the file, it usually is for a good reason. Take a look at SVCD, it would be unwatchable unless the decoder took the specified AR into account as its resolution is 480x480 or 480x576 while the AR is 4:3 or 16:9. I want ffdshow to do the same with divx/xvid that is not encoded in a way where resolution AR corresponds to the AR of the material. You see?

kurt

17th November 2005, 15:19

madman1980 is right - "overlay mixer" and "allow output format changes during playback" should be default...

if you do anamorphical encodes and set the AR to 16:9 (for example in mmg) ffdshow doesn't read the flag properly with default settings (mpc, zoomplayer, tcmp....).

I think various people use ffdshow like that...

marcellus

17th November 2005, 15:41

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.
I agree with signatory.
@madman1980:
Make the changes you like, click on 'Export all settings', save ffdshow.reg somewhere and double click it whenever you install a new ffdshow version. That would be all.

I think a debate on what setting should be default or not in ffdshow would take forever and has no point. Anybody can make his own 'default' settings.

Egh

17th November 2005, 15:55

Generally speaking, compressing .exe/.dll files is quite stupid idea nowadays. It saves disk space a bit, but doesn't save you memory usage :)

in fact it likely uses more system memory than without it!

And there were several problems with UPX on XP SP2 systems. So better drop this idea :) Though who is interested may simply pack .ax/.dll himself.

madman1980

17th November 2005, 16:06

I agree with signatory.
@madman1980:
Make the changes you like, click on 'Export all settings', save ffdshow.reg somewhere and double click it whenever you install a new ffdshow version. That would be all.

I think a debate on what setting should be default or not in ffdshow would take forever and has no point. Anybody can make his own 'default' settings.

Why? If you think debate is useless you at least have to say why. You present no reasoning whatsoever, so I can't even tell if you know what the issue is. Can you name one disadvantage enabling this setting would have?

I have explained why this setting would be useful, and in fact, I can't see any disadvantages to it. If a setting for AR is stored in a divx/xvid file, it is intended to be used, and that's what I want. This will benefit everyone.

I've been using this setting without problems for a good while now, while not using it gives me problems with the files that are not encoded with a pixel resolution that correspond to the AR, like the anamorphic example kurt reffered to.

celtic_druid

17th November 2005, 16:12

Maybe Milan knows of a reason? Could be that he didn't make it default for a reason.
It isn't hard to change the settings anyway though. Couple of mouse clicks and you are done.

No reason why others can't edit the nsi script for their builds though to make it default.

madman1980

17th November 2005, 16:19

celtic_druid

17th November 2005, 16:23

Try: http://sourceforge.net/tracker/?group_id=53761&atid=471489

madman1980

17th November 2005, 16:31

Thanks, I'll submit a request.

signatory

17th November 2005, 19:43

Yep, I'd very much like to know what he (is he the lead (or only) developer?) has to say, but I haven't been able to get an answer.

It's very easy to enable the setting manually, but I've still yet to find out a good reason why it shouldn't be enabled by default, so that's why I'm asking about it. Why should we really have to? I'd be really glad to see a build with it if it is confirmed that there are no problems.

I think there is a way to resolve this issue in a excellent way for all of us. Personally I don't want it as default.

But hopefully milan will go with a checkbox option for these overlay settings in the installer. Just like there are checkboxes for what formats and filters to use. And then as one would install updated packages the settings would be pre-selected.

Revgen

17th November 2005, 21:54

Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

The last time I emailed Milan he responded in about 3 days. When did you last email him?

esby

18th November 2005, 11:15

Well about the upx discussion:
Since the installer is compacted, you'll gain no space on it if you compact the executables with the same type of compacting algorithm.
The only gain you could have is if the algorithm used for compacting the executable is better than the one used for the executable, in fact, it will not happend, they both are at the same level.
Now the real question is: Do we want smaller executable installed? I would say it does not matter anymore, space is never a problem now. Now something that could be done (in theory) is putting a dialog option, add upx to the installer, and compact the executables installed during the installation, if the user wants to install executables in their compacted form.
Now for the upx 'problems' with executable, the only problem I encountered with exectutable is when accessing resources with hackish method, since the exe is compacted, the hackish methods will most likely not work properly, for example, try reading a string from the executable resource, while acessing the exe, you'll most likely end with a different result than what you were expecting.

esby

madman1980

18th November 2005, 14:01

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

Got a reply!

signatory: Still you haven't said why you don't want is as default. Is it too much to ask why? I'd like to learn more about it, and they way you wrote it seemed it was because of you personal preference, not because you thought it would introduce bugs. I'd like to hear why you don't want it regardless.

An option during the install process would be great, but I still don't see any disadvantages (except perhaps technical ones that can be sorted out) why it shouldn't be default. So please enlighten me.

bob0r

18th November 2005, 18:30

http://sourceforge.net/docs/A04/

( 2005-11-16 05:35:18 - Project CVS Service ) As of 2005-11-16 the sync between developer and anonymous CVS services is still disabled. This is as a result of a hardware failure that we are actively working on, and the sync will be restarted as soon as the hardware issues are resolved.

I just compiled ffdshow-20051118-gcc4.0.2-sse-x264.nl.exe, and ffavisynth compiling works again.
(updated to: dynamically link avisynth.dll from ffavisynth - http://cia.navi.cx/stats/project/ffdshow/.message/6451522)

Two more updates:
- option to connect to any filter but allow output format changes only on supported ones - a new default
- fast SPP deblocking

My build worked, but i'd like to include these last 2 updates (and possible more if CVS stays out-to-date again)
But the update 'dynamically link avisynth.dll from ffavisynth' was today, so with any luck, a new build soon!

MacAddict

18th November 2005, 18:36

Wow, fast SPP deblocking. The new GCC SSE2 build will be very nice :-)

madman1980

18th November 2005, 18:44

How much faster are the SSE2 builds in general?

ExtraEye

18th November 2005, 18:54

how do i dowload this new release bob0r?

bob0r

18th November 2005, 20:33

how do i dowload this new release bob0r?

I said i put a build online after those 2 fixes are updated on ffdshow CVS also.

BUT. libmpeg2_ff.dll fails to compile with gcc (3.4.4).

./../../simd_instructions.h: At global scope:
./../../simd_instructions.h:53: error: expected `,' or `...' before '&' token
./../../simd_instructions.h:53: error: ISO C++ forbids declaration of `__int64' with no type
./../../simd_instructions.h: In function `void csimd::psadbw(int)':
./../../simd_instructions.h:53: error: `dst' undeclared (first use this function)
./../../simd_instructions.h:53: error: `src' undeclared (first use this function)
In file included from include/mmx.h:30,
from libmpeg2/idct_mmx.c:36:
./../../csimd.h: At global scope:
./../../csimd.h:30: error: expected `,' or `...' before '&' token
./../../csimd.h:30: error: ISO C++ forbids declaration of `__int64' with no type
./../../csimd.h: In function `void csimd::movq(int)':
./../../csimd.h:30: error: `dst' undeclared (first use this function)
./../../csimd.h:30: error: `src' undeclared (first use this function)
make[1]: *** [libmpeg2/idct_mmx.o] Error 1
make[1]: Leaving directory `/home/user/ffdshow_gcc/src/codecs/libmpeg2'
make: *** [../bin/libmpeg2_ff.dll] Error 2

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

We will have to wait until this is fixed again.

BTW, i am using gcc 3.4.4 again, it is the fastest for both ffdshow and x264 builds.

ExtraEye

18th November 2005, 21:33

will you make an sse2 version too?
thx anyway

cc979

19th November 2005, 00:10

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

i see what you mean now, i just made a test xvid with 16/9 AR but its not displayed right with mpc it thinks its a 4/3 AR but its works fine with VLC so not sure if its a ffdshow or mpc bug

videomixer9

19th November 2005, 01:28

hm, imo wmv9 (4cc wmv3) should be enabled again as an codec option in ffdshow, as it works just fine if you enable it via the registry trick. Didn't have one wmv video that didn't work yet, except that it's not that good with broken files, but the original isn't really either. Anyone tried this too and had similar success?

btw. I had one xvid encode that had the same error ... hm ... also played as 4:3 without me enforcing that or anything ... but nothing to do with anamorphic encoding but something else and not fixed by overlay mixer thingy whatever heh ...

_xxl

19th November 2005, 10:07

Libavcodec.dll can be compiled with Microsoft Visual Studio 6 + Intel compiler 9?

celtic_druid

19th November 2005, 11:57

That's how I usually compiled it.

celtic_druid

19th November 2005, 13:29

Should be "-mtune=i686"

lrms

19th November 2005, 20:55

gcc vp3dsp_sse2
cc1.exe: invalid option `tune=i686'
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions -DHAVE_AV_CONFIG_H -pipe -mno-cygwin -mdll -I. -I.. -I../codecs -I../imgFilters $(InputPath) -o $(IntDir)\$(InputName).obj -Ilibavutil
I'm using GCC 3.2.3.

"-mtune" is for GCC 3.4 and up. For version 3.2 you should use "-mcpu="

bob0r

20th November 2005, 03:03

Download from x264.nl

Compiled up to:
15:01 on Nov 18, 2005
option to connect to any filter but allow output format changes only on supported ones - a new default
http://cia.navi.cx/stats/project/ffdshow/.message/6454339

I can switch between gcc 4.0.2 and 3.4.4 instantly now, so until ffdshow can compile on gcc 3.4.4, i can still give you new builds :sly:

SSE2 build for the girls:
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051120-gcc4.0.2-sse2-x264.nl.exe

Enjoy!

celtic_druid

20th November 2005, 04:07

The project file is probably still missing some source files.

issa

20th November 2005, 05:56

gcc vp3dsp_sse2
cc1.exe: invalid option `tune=i686'
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions -DHAVE_AV_CONFIG_H -pipe -mno-cygwin -mdll -I. -I.. -I../codecs -I../imgFilters $(InputPath) -o $(IntDir)\$(InputName).obj -Ilibavutil
I'm using GCC 3.2.3.

Your GCC is too old, the GCC 3.4.x replace "-mcpu" with "-mtune".
You either upgrade you gcc, or replace "-mtune" with "-mcpu" in the
Makefile, makefile.inc and makefile_c.inc under the "src" directory.

Valeron

20th November 2005, 07:17

The 1120 build makes ffdshow first time over nero avc decoder in AVC decoding. Well done! x264 guys :cool:

breez

20th November 2005, 11:52

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

bob0r

20th November 2005, 12:58

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

Do some tests, more clips, then post your findings to Milan

http://sourceforge.net/projects/ffdshow
Bugs > http://sourceforge.net/tracker/?group_id=53761&atid=471489

Give him all info you can, CPU, build used, what video/audio you used etc etc...

Or/and wait for other to test it first and compare findings!

LigH

20th November 2005, 14:51

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

PatchWorKs

20th November 2005, 15:42

There's a really interesting discussion @ Hydrogenaudio.org around SSE/SSE2 optimization on the Ogg Vorbis optimized for speed (http://www.hydrogenaudio.org/forums/index.php?showtopic=29161) 3ad.

Here's some interesting posts (in my opinion):
What the ICC compiler does is a process called autovectorisation, it's a very clever piece of software that examines routines and attempts to implement them using the faster SSE(2) instructions. At least, that is how i understand it.

What lancer does is replace certain standard routines in vorbis with hand written SSE implementations. This is not assembly (i think), but it is vectorisation (making use of SSE) done by a human.

The SSE instruction set works at a lower precision than the regular x87 instructions, but i don't think that's ever reduced sound quality in a noticeable way.

I'm not an expert on this, but i hope this explanation is accurate enough to answer your questions.

To explain:

3DNow, SSE, SSE2 are alternate instruction sets for floating point processing. These instruction sets have some major advantages over the old x87 mode:

1) They have register based access, instead of stack based
2) They have the *possibility* to operate on 2 or 4 values at the same time (vectorisation)

SSE and 3DNow have 32 bit accuracy, SSE2 has 64 bit accuracy. x87 has 32 or 64 bit accuracy and a possibility (that shouldn't be used and I'm pretty sure vorbis doesn't use it!) to do 80 bit accuracy arithmetic.

Using these instruction sets can be done in the following manner: code for them manually (in assembler or with instrinsics), use a compiler that can use the SSE(2) instructions for floating point instead of x87, or use a compiler than can *vectorize* computations for SSE/SSE2.

Currently (besides manually writing in assembly), ICC is the best at vectorization, and some very recent GCC's have the possibility too. MSVC2005 and older GCC's have the possibility to generate SSE(2) floating point instructions (without vectorisation).

Here's the Ogg Vorbis acceleration project (http://homepage3.nifty.com/blacksword/index_e.htm) website, and its author email: blacksword8192 (at) ｈｏｔｍａｉｌ (dot) ｃｏｍ

Egh

20th November 2005, 17:11

Hm... At the first glance h264 is decoded somewhat faster than before in new build. Great to know :)

videomixer9

20th November 2005, 17:19

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.

It's major crap anyways, ffdshows postprocessing which comes from mplayer mostly is total crap. It does not improve quality at all, all it does is lose major details on the video, even the accurate deblocker does a real bad job.

here an example of a 600kbps video:

first without any filter or postprocessing (click for full size):
http://xs55.xs.to/pics/05460/without_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=without_spp.jpg)
here with fast SPP:
http://xs55.xs.to/pics/05460/with_fast_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_fast_spp.jpg)
with regular SPP:
http://xs55.xs.to/pics/05460/with_spp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_spp.jpg)
with regular accurate deblocking still better:
http://xs55.xs.to/pics/05460/with_accurate_pp.jpg.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=with_accurate_pp.jpg)

in the same order as above in one png:
http://xs55.xs.to/pics/05460/together.png.xs.jpg (http://xs.to/xs.php?h=xs55&d=05460&f=together.png)

Result = SPP wastes much CPU and totally wrecks the picture! in actually video SPP even produces this flickering effect with many videos. postprocessing is wasted cpu time! That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.

Egh

20th November 2005, 23:06

It's major crap anyways, ffdshows postprocessing which comes from mplayer mostly is total crap. It does not improve quality at all, all it does is lose major details on the video, even the accurate deblocker does a real bad job.

Result = SPP wastes much CPU and totally wrecks the picture! in actually video SPP even produces this flickering effect with many videos. postprocessing is wasted cpu time! That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.

I was never fan of SPP at all. It ruins details of the picture by smoothing the frequency domain. Something like FFT3DFilter works far better (and slower). In fact FFT3DFilter implemented on GPU should have best quality post-processing. [and still reasonable speed to be used real-time]

But, of course, the best thing is to have video which DOESN'T require post-processing at all :) And any deblocking, whenever casual or h264 one, is totally redundant nowadays. It was good on something like 512*384 videos encoded in single-pass DIV3 :P Which were somewhat a norm several years ago. Now 720*480 avc is just a norm and loses competition with hdtv videos. On something like 1024*576 with sufficient bitrate any deblocking is totaly redundant and eats far too much CPU.

Anyway, thanks for testing :)

Leak

21st November 2005, 00:04

Fast SPP deblocking doesn't quite live up to it's name. It is a lot slower than regular SPP @ level2 preset.
Fast SPP deblocking only supports levels 4 and 5; I guess it's a lot faster than using those with regular SPP... :)

Here's the beef (http://thread.gmane.org/gmane.comp.video.mplayer.devel/25213)

np: Bring Back The Buffalo - Checkerboards (Bring Back The Buffalo)

bob0r

21st November 2005, 00:39

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

I tried
make SSE=no
make SSE=no SSE2=no
make SSE1=no

Tell me how to disable SSE2 AND SSE and ill build you one :)

dragongodz

21st November 2005, 13:09

That's a reason I care like shit about most ffdshow filters anyways, postprocessing makes bad encodes even worse and makes them mostly lose all details.
if you dont care then why are you spouting off about it ? i can easily show you a bad/blocky/low bitrate encode where SPP clearly makes the picture more watchable and easily better than the other deblockers included. what it comes down to though is if you dont like it then dont use it. its not as if someone is making you turn on filters and forcing you to watch the output.

But, of course, the best thing is to have video which DOESN'T require post-processing at all And any deblocking, whenever casual or h264 one, is totally redundant nowadays.
redundant ? depends on what you are trying to encode and how. of course having enough bitrate that no deblocking is needed will always be the (dare i say it)best. however if you are targeting an encode with something like a size limitation then that is not always possible.

movax

21st November 2005, 20:04

I tried
make SSE=no
make SSE=no SSE2=no
make SSE1=no

Tell me how to disable SSE2 AND SSE and ill build you one :)

You have to change the CPU flags in the makefile. Note that the CVS is supposed to have proper CPU capabilities detection.

ExtraEye

21st November 2005, 22:16

bob0r - i just noticed in your latest build - no awarpsharp?

lrms

22nd November 2005, 01:07

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

http://cia.navi.cx/stats/project/ffdshow/.message/4561c

Time for YAFB (yet another ffdshow build)? ;)

issa

22nd November 2005, 04:07

bob0r - please don't forget the poor non-SSE people. Your SSE ffdshow crashes after a while on my Duron; no surprise, I'd say. So I'll wait for milan's next build.

Here is the cvs build with sse turn off when compiling.
URL: http://rapidshare.de/files/7977898/ffdshow-20051121.exe.html

22nd November 2005, 13:20

1120 crashes for me as soon as i touch gain/offset in picture properties (sorry, don't remember exact name).

w2k3, p4 htt enabled

not sure what else should be given :/

bob0r

22nd November 2005, 16:27

New URL for my and other ffdshow builds.

Mirrored (and renamed to *-username):
http://files.x264.nl/ffdshow/ffdshow-20051121-issa.exe
http://files.x264.nl/ffdshow/ffdshow-20051121-drevil_xxl.exe

Kurosu

23rd November 2005, 02:02

bob0r - i just noticed in your latest build - no awarpsharp?
awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.

Here is the cvs build with sse turn off when compiling.
I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

issa

23rd November 2005, 10:58

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.

I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

I would like to know where is "milan's code" located. Also, where to get all the PSDK header files, for example, uuid.h, dvdmedia.h, etc, for gcc.

I think the "intrinsics" is fine as long as the program check the CPU flags before it use, just like libavcode did. However, the "-mfpmath=sse" or "-arch:SSE" tell the compiler to use SSE instruction instead of x87 instruction for FP operation, and this will crash on CPU that do not support SSE.

cc979

23rd November 2005, 16:12

anybody got problems anamorphic xvid avi's not working with system-overlay but they work with vmr9 renderless

Egh

23rd November 2005, 19:05

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.

As for awarpsharp, i dont' see any troubles there. Anybody who have avisynth installed may simply use aWarpSharp() filter thru it (typing it into "Avisynth" window of ffdshow). As for speed, since I just learnt it's closed source, so i don't think there's any difference between those two filters (built-in in ffdshow or using avisynth one).

Are there any other closed source parts of code in ffdshow? I actualy thought it was fully open source, but it prooved to be wrong.... :P

Kurosu

23rd November 2005, 20:37

I would like to know where is "milan's code" located
You are probably not referring to CVS so I guess you wonder which code could be troublesome. I meant it like "code which is troublesome for a gcc build for K6/P2 users". So this code would be:
- any code using SSE or simply MMXExt
- some C code doing float/double operations

milan's code is mostly based on intrinsics. SSE ones requires -msse, but then this not only activates support for intrinsics but also builtins. They can partially be disabled/controlled with -mfpmath=387. However the later kind of code gets compiled when using -msse with SSE builtins.

My referring to Athlon-XP was due to the fact that with -march=athlon-xp -mfpmath=387 -msse -msse2, gcc used sse2 instructions for some double<->int operations, which is basically the same with K6/P2 where it is SSE1 and float<->int

Also, where to get all the PSDK header files, for example, uuid.h, dvdmedia.h, etc, for gcc.
I'm not sure what's get used. baseclasses uses stuff coming from DirectX. I have both DX8.1 SDK installed and the headers used for compiling mplayer (http://www.mplayerhq.hu/DOCS/HTML/en/windows.html):

I think the "intrinsics" is fine as long as the program check the CPU flags before it use, just like libavcode did
Yes, though gcc compiles C code with -msse without you having a say on where it uses builtins. Such granularity:
0) Use no SSE builtins
1) Handle builtins when intrinsics are used
2) Use SSE math builtins
3) Use any SSE built-ins
would be could, while we only have 0) and 3). 1) is what is needed for ffdshow.

However, the "-mfpmath=sse" or "-arch:SSE" tell the compiler to use SSE instruction instead of x87 instruction for FP operation, and this will crash on CPU that do not support SSE.
Yes. I guess -arch:SSE is cl-specific?

i don't think there's any difference between those two filters (built-in in ffdshow or using avisynth one).
Except for a little bit of speed, as the use of awarsharp has to go all the way through the avisynth layer. I don't know what kind of speed/memory impact it has.

Are there any other closed source parts of code in ffdshow? I actualy thought it was fully open source, but it prooved to be wrong.... :P
All is open source (as in "source available"), but the reuse of this code isn't that clear. In fact, many parts are not GPL free software:
1.0) baseclasses
"Copyright (c) 1992-2002 Microsoft Corporation. All rights reserved."
Basically, a part of DirectX SDK. Code is really available, but I'm not sure it can be included in a GPL program. Granted, it's easier for everybody to compile it this way.
1.5) wmv9 stuff
Part of it is "Copyright (c) 1992-2001 Microsoft Corporation. All rights reserved". Probably same level of concern as 1.0
2) realaac
I don't want to read up the RPSL (http://www.helixcommunity.org/content/rpsl) and RCSL (http://www.helixcommunity.org/content/rcsl) licences but there may be some unregular stuff with it being included in ffdshow
3) Skal's MPEG-4 encoder: LICENSE.TXT license is missing, probably GPL though
4) awarsharp: closed source. Author explicitely states in the header it can only be used with ffdshow
5) FAAD2. License is GPL+some additionnal requirements, which makes it open source but not GPL-compatible. (http://www.hydrogenaudio.org/forums/index.php?s=showtopic=35535&st=25#)
6) Unrar: not sure. The available license makes me think it isn't, while this page (http://www.unrarlib.org/license.html) seems to say it's ok (though I'm not sure this is the same thing actually).
and maybe more FUDesque stuff.

Not really showstoppers, though. It's up to Milan Cutka to see what to do with them but most people will agree he has better things to do.

DeathTheSheep

23rd November 2005, 21:50

New URL for my and other ffdshow builds.

Mirrored (and renamed to *-username):
http://files.x264.nl/ffdshow/ffdshow-20051121-issa.exe
http://files.x264.nl/ffdshow/ffdshow-20051121-drevil_xxl.exe

Hmm...the issa.exe doesn't properly register ffdshow.ax. The installer prompts me with the "can't register..." error, and then simply exits.

drevil.exe "works" but avisynth doesn't recognize the video stream and H.264 deblocking is disabled by default (!! what good is inloop now?!)!

Still, thanks for the builds! :thanks:

bob0r

23rd November 2005, 22:05

@DeathTheSheep

Try putting http://files.x264.nl/ffdshow/msvcr80.dll in your c:\windows\system\ dir and try issa's build again.

_xxl

24th November 2005, 00:44

http://rapidshare.de/files/8069150/ffdshow-20051121.zip.html
ffdshow-20051121 is for testing!

bob0r

24th November 2005, 02:52

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

I finally managed to compile ffdshow with gcc 3.4.4, but on my system it crashes.

Please test this build and let me know if it crashes or not, this could help if Milan can't see the problem right away. Thanks.

http://rapidshare.de/files/8069150/ffdshow-20051121.zip.html
ffdshow-20051121 is for testing!
What's different from your other ffdshow-20051121.exe ?

thuan

24th November 2005, 08:32

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe
Crash here too (CPU T-bred 1.5Ghz and crash in ffdshow.ax). Replace ffdshow.ax with the one in your 1120 compile run fine and maybe faster.

_xxl

24th November 2005, 09:27

drevil.exe "works" but avisynth doesn't recognize the video stream and H.264 deblocking is disabled by default (!! what good is inloop now?!)!
Still, thanks for the builds! :thanks:
ffdshow-20051121 H.264 deblocking is enabled by default.
fixed reg errors on install.

madman1980

24th November 2005, 09:48

Why is there such a hassle with ffdshow and cpu instruction sets compared to other codecs? Why can't it just work with them all and detect accordingly?

breez

24th November 2005, 11:01

http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

Crashes here too (ffdshow.ax). Athlon XP (Thoroughbred-b).

bob0r

24th November 2005, 13:54

We can stop testing ffdshow gcc 3.4.4 builds. Milan is quite clear on this:

I'm happy you managed to compile ffdshow using GCC 3.4.4,
but I don't think I'll check reports about bugs in this
build. GCC 3.4.4 simply isn't supposed to be used for
building ffdshow.

Just today I tested a mpeg 1 file created by tmpgenc
(finally ffdshow is able to deliver video to tmpgenc, audio
will hopefully follow), but the image was distorted. The
problem was in ff_libmpeg2 compiled by GCC 3.4.4. When
compiled using GCC 4.0.2 or MSVC, the results were fine.
Maybe it'd be possible to make ffdshow work when compiled
using GCC 3.4.4 (compiler switches,...) but it'd take too
much time and I think there are other areas of ffdshow where
it should be spent.

Clarity is what i like, so move on with gcc 4.0.2 :cool:

bob0r

24th November 2005, 14:04

Why is there such a hassle with ffdshow and cpu instruction sets compared to other codecs? Why can't it just work with them all and detect accordingly?

Quotes from Milan:

My "daily" builds should work on all CPUs which
support MMX
instructions set and don't require SSE. That's because
I'm
still using Intel C++ compiler to build them. bob0r uses GCC
which has its own limitations which would require many
changes in ffdshow source code to make it able to create
ffdshow which wouldn't require SSE support.

me:
I hope one day you can realize the same for gcc as is
possible on icl

So there is no way to disable SSE (only SSE2), ok.

Milan:

I know about two possible ways of making GCC builds support
MMX-only CPUs:

1. moving all SSE and MMXEXT functions in ffdshow.ax sources
to separate source files
2. outcommenting all SSE and MMXEXT code as I did it for
SSE2

First approach would make ffdshow source tree a mess (or at
least much less maitainable). Second approach would require
a bunch of #ifdef and #endif preprocessor stataments which
would also make source code less readable.

Personally I'd prefer second approach. However, this would

result in ffdshow.ax using MMX instruction only even on
Durons which support MMXEXT instructions (average, min, max
).

So to answer your question, for GCC this requires quite a lot of work, and will make ffdshow source messy.

Just get Milan's ICL 8 builds if you have problems with SSE/SSE2 and possible other CPU optimizes:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

But again, when a build works, and does what you want it to do, stick with it.

CruNcher

24th November 2005, 16:29

ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe <- crashing here too on a Athlon 64 Venice

DeathTheSheep

24th November 2005, 17:40

ffdshow-20051124-gcc3.4.4-sse-x264.nl.exe

"An exception occured when trying to run ffdshow.ax"

Yep, this is a true crash--no doubt about it. Hope it "gets well soon!" :p

4.0.2 builds should work, eh? I think a test is in order... ;)

bob0r

24th November 2005, 21:36

ffdshow builds compiled with gcc 3.4.4 will not be supported, only gcc 4.0.2, and higher i guess.

Here is a new build with ff_vfw.dll working again + the other updates/fixes:
ffdshow-20051124-gcc4.0.2-sse-x264.nl.exe download from x264.nl, and SSE2 build:
http://files.x264.nl/ffdshow/ffdshow-20051124-gcc4.0.2-sse2-x264.nl.exe

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

ExtraEye

24th November 2005, 21:58

thx bob0r!

LigH

24th November 2005, 22:11

And again - "non-SSE" only from milan?

clsid

24th November 2005, 22:32

There is a new build from Milan online now too.

DeathTheSheep

24th November 2005, 22:34

Ah, yes, this one works like a charm!
Thank ye kindly!

bob0r

25th November 2005, 00:42

msvc 7.1:
http://files.x264.nl/ffdshow/ffdshow-20051124-msvc7.1-x264.nl.exe
msvc8.0
http://files.x264.nl/ffdshow/ffdshow-20051124-msvc8.0-x264.nl.exe
icl 9.0 (libavcodec.dll from Milan's ffdshow-20051124.exe build, assuming icl 8):
http://files.x264.nl/ffdshow/ffdshow-20051124-icl9.0-x264.nl.exe

For testing one more time, and none-SSE i guess :sly:

DeathTheSheep

25th November 2005, 00:43

MPEG4 quantizer noise shaping is broken...
And many codecs only encode at 25fps...

bob0r

25th November 2005, 00:56

MPEG4 quantizer noise shaping is broken...
And many codecs only encode at 25fps...

Give more details, and please report to http://sourceforge.net/tracker/?group_id=53761&atid=471489

(More info like, where to find MPEG4 quantizer noise shaping in the settings, as i have no clue)

DeathTheSheep

25th November 2005, 01:04

bob0r

25th November 2005, 01:12

@DeathTheSheep

How is it not working?

I tried 300 frames encoding with those settings, and its working, encode and decode.

DeathTheSheep

25th November 2005, 01:21

Chainmax

25th November 2005, 01:31

What's the status on Vorbis decoding? Is libavcodec still a better alternative than tremor?

Egh

25th November 2005, 01:39

What's the status on Vorbis decoding? Is libavcodec still a better alternative than tremor?

i don't think there were any updates to tremor in last months...

As for decoding vorbis, I prefer libavcodec for quite some time. Don't even use CoreVorbis and similar stuff.

Rash

25th November 2005, 01:55

Just a question. Celtic Druid is making "yes-SSE" compilers, right? :)

I seriously feel a difference on perfomance with and without SSE, and I don't have one tiny little problem with stabilty.

Oh, OK, just one more question. :) Are the CPU flags shown on "Info & Debug" displayed correctly? Somehow I think they are always checked, all of them, but they are not exactly in use.

celtic_druid

25th November 2005, 03:30

I compiled termor with low accuracy mode disabled. Link is a few pages back I think.

issa

25th November 2005, 04:46

Here is the CVS build of gcc 4.0.2, these should work on all CPU unless
milan's use SSE/SSE2 without checking CPU flags.

http://rapidshare.de/files/8121185/ffdshow-20051125-gcc.exe.html

videomixer9

25th November 2005, 10:24

Oh? It consistently crashed VirtualDub with the GCC4.0.2 build, but it works fine with the ICL9.0 build (EDIT: and the msvc71 build is fine, too, but the slowest of the three)...? I'll try a reinstall.

By the way, I downloaded msvcr80.dll into my system and system32 and ffdshow directory, but the new msvc8 build gives this error message upon installation:
http://www.myfilehut.com/userfiles/5120/msvc8.PNG
Even when the system is restarted, and the old ffdshow is uninstalled, the message persists. Is there just something wrong with my computer?
Thanks for all the help :)

EDIT: Reinstall produces both of the same errors. Screenshot of failed Quantizer Noise shaping can be found here (http://www.myfilehut.com/userfiles/5120/gcc402.PNG)

You're not working as admin as it's supposed to be? non-admins cannot register filters without special rights, thus it throws an error. I'm not working as admin either and just use the "run as" feature with the installer as I do with almost any installer for anything, as my own account I work with has like no writing rights except for my personal folder and my data disk. Cannot explain this in many other ways if the installer works for anybody else.

Would be rare though that the person without admin rights to not know it and if it works with any other build it's prolly a loading error.

yaz

25th November 2005, 11:42

just found
Daily builds

ffdshow-20051124.exe

wait untill tray icon thread is created
don't rebase some libraries,
re-added resources to ffvdub in gcc build
fixed green artifacts when using chrominance smoother
correct guid for IID_IQualityControl - fixes tmpgenc video
change base addresses of dynamic libraries after building them
correct timestamps with haali/theora/libavcodec combination
remove languages dir on uninstall
don't use __int64 type in csimd.h
option to connect to any filter but allow output format changes only on supported ones - a new default
fast SPP deblocking
dynamically link avisynth.dll from ffavisynth
finally (?) fixed DCT filter
ffavisynth compileable with GCC - ffdshow avisynth filter uses now avisynth C interface, you have to load it using LoadCPlugin
fixed querying for ansi interfaces in unicode build (and vice-versa)

it may (re)solve some problems listed above

the bests
y

yester

25th November 2005, 12:01

tested the k6 build on an k6-2+ 500 & windows98se ... won't even install, crash in selection menu. latest milan builds work on k6... (except the cpuload, which goes wrong on second started media to constant 100%)

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.

I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

LigH

25th November 2005, 12:43

There is a new build from Milan online now too.For testing one more time, and none-SSE i guess :sly:
:o Yes, you are right... For your efforts, many :thanks:
__

BTW: Although you disabled it, there is still a text readable "low accuracy mode enabled for tremor" (both in milan's build, and bob0r's ICL9). Probably only a non-changed label.

issa

25th November 2005, 21:15

Latest CVS build on 11-26-2005.

SSE2 build (using SSE2 for FP operation instead of x87):
GCC :- http://rapidshare.de/files/8167977/ffdshow-20051126-gcc-sse2.exe.html
MSVC :- http://rapidshare.de/files/8168051/ffdshow-20051126-msvc-sse2.exe.html

x87 build (it should work on all CPU >= i586):
GCC :- http://rapidshare.de/files/8167763/ffdshow-20051126-gcc-x87.exe.html MSVC :- http://rapidshare.de/files/8167872/ffdshow-20051126-msvc-x87.exe.html

Please let me know for the build working or not.
Notice: I had updated the SSE2 build since anonymous cvs got update today for 20051124 build.

MacAddict

25th November 2005, 21:46

@issa
The GCC SSE2 build is running _very_ smooth here for me. In fact, almost seems to use a few percent less CPU than previous SSE2 builds. Maybe it's just me though :-) Many thanks for the efforts!

Chainmax

26th November 2005, 02:01

i don't think there were any updates to tremor in last months...

As for decoding vorbis, I prefer libavcodec for quite some time. Don't even use CoreVorbis and similar stuff.

I wonder why if Vorbis decoding is enabled then tremor is selected by default...

falcon2000eg

26th November 2005, 08:15

You're not working as admin as it's supposed to be? non-admins cannot register filters without special rights, thus it throws an error. I'm not working as admin either and just use the "run as" feature with the installer as I do with almost any installer for anything, as my own account I work with has like no writing rights except for my personal folder and my data disk. Cannot explain this in many other ways if the installer works for anybody else.

Would be rare though that the person without admin rights to not know it and if it works with any other build it's prolly a loading error.
I have the same problem and im the admin ,with msvc8 builds only gcc builds are fine.

ptiJean

26th November 2005, 12:02

Hello all,

I have a problem on my PCHC : tried several (about 10 !) versions of ffdshow, using it with ZoomPlayer 4.5 registered and overlay (for my DVD).

I want to force ffdshow output in RGB32 with high quality conversion YV12 -> RGB, but ZP claims that it is impossible to connect pins from ffdshow out to overlay in.

Am I missing something ?
Can you help me ?
Thank you.

PS: ZP 4.5 + AMD 64 3000+, ffdshow overlay RGB32 output, NVidia pure video mpeg2 decoders YV12, I wish ffdshow and overlay could connect :thanks:

Leak

26th November 2005, 12:32

Am I missing something ?
Yep. Hardware video overlay on graphics cards is YUY2/YV12 only - it just doesn't support RGB.

np: The Dolls - Motor City (The Dolls)

ptiJean

26th November 2005, 13:56

At home I Have 2 PCs with NVidia cards (5600 & 6200) : impossible to connect ffdshow RGB32 to overlay renderer.

But at work, I have one PC with ATI 9600 card, and the connection is possible !

So ?

thuan

26th November 2005, 16:57

If you select the output colorspace in ffdshow is RGB32 then the com won't need OverlayMixer I think (because it has been rendered direct to your destop colorspace and I can't find the OverlayMixer filter in the filter chain). On my com(GF4MX) it's work fine with MPC with OverlayMixer selected and in Zoom4.51 is the same with a weird prob (ffdshow output vid in "RGB32,modified" don't know what that's is and the vid looks bad with severe staircase for a few secs, after that ffdshow output in normal RGB32 and the vid plays fine then anyone have the same prob?)

videomixer9

26th November 2005, 18:16

Why convert to RGB32 in software anyways with overlay mixing, just to waste CPU cycles on things while your graphics adapter can do everything in hardware for you?

ps: just to remind you, overlay mixer does a conversion to RGB for output on screen within your graphics hardware. If you want to emulate the high quality conversion from ffdshow with this, convert the picture to YUY2 before, that's how ffdshow does it with HQ conversion ... YV12 -> YUY2 -> RGB32 while graphics hardware does a direct YV12 -> RGB which seems to be bad for some cards, however some expect YV12 or YUY2 as input as internal conversion seems to fail if the source is already RGB, driver bug or so most probably.

ffdshow often comes out using less cpu for pure decoding work as many other codecs, this is most prolly often the case because most other decoders do not output n YV12 and convert to YUY2 before. I think both DivX and Xvid do so per default.

issa

27th November 2005, 00:35

I try to fixed the problem of msvc build, please try this build and let me know if it work or not.

SSE2 build:
http://rapidshare.de/files/8224664/ffdshow-20051127-msvc-sse2-try4.exe.html

Note: Just try another method, and download link update.

DeathTheSheep

27th November 2005, 00:41

lol, sorry 'bout that :)

Actually, I submitted that post at exactly the same time you submitted the other builds, and it works with icl9.

It's in the VFW settings. Here's a screenshot:
http://www.myfilehut.com/userfiles/5120/ffdshow.PNG

However, the ICL9 is 2 times slower than the gcc4.0.2 build on my Intel Celeron D 2.93ghz (I just ran an ASP decoding test with mplayer deblocking).

So, the icl9 version's noise shaping works, but ffdshow in general is much, much slower for me.

Thanks 4 all the builds!
This problem persists with the above 11/26 gcc4.0.2 sse2 build. Make sure to input a "1" in the lowest box ("Quantizer Noise Shaping"). It consistently crashes with the [faster] gcc build but works fine with the [slower] icl9 build. Additionally, the latest above msvc build fails at the same place I described above: "Error while registering ffdshow.ax". I have administrative privilages.

Here are my ffdshow registry settings (Dumped directly by ffdshow): ffdshow_reg.7z (http://www.myfilehut.com/userfiles/5120/CollectedBuilds/ffdshow_reg.7z)

Has anyone been able to reproduce either of these problems? Thanks, y'all.

NoX1911

27th November 2005, 02:36

@Thuan: I think i have the same behaviour when using 'Standard Renderer'. Are you not using WinXP (Win2k/9x use 'standard renderer')? There's already a thread at SourceForge: https://sourceforge.net/tracker/index.php?func=detail&aid=1360669&group_id=53761&atid=471489

Regarding software YUV->RGB usage.. Isn't it a must-have if you want to use VMR9 since there is no luminance correction (yuv->rgb) due to missing overlay mixer? At least i didn't manage to get rid of the luminance problem without converting to RGB with ffdshow... hardware overlay doesn't work with VMR9 renderless anymore. It's rendered as texture instead of overlay.

thuan

27th November 2005, 03:24

Well, I use XPSP2 and that prob only happen with Zoom not MPC so I think it's not ffdshow fault maybe Zoom.
About VMR9Renderless with MPC I think I have the same color result with YUV2 and RGB32 but RGB32 is certainly slower.

zilexa

27th November 2005, 04:03

Why does the "Downloads" page of the official ffdshow site (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php) only shows ffdshow builds up to 2004, while the "Daily Builds" page and the "getting FFdshow" link on the homepage show all the builds after 2004? (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow)

Nobody uses the 2004 build anymore.. on the site the daily builds are even promoted as "Getting FFDshow".
An update to this part of the site, with the latest most stable build would be nice!

Elic

28th November 2005, 09:47

ptiJean

28th November 2005, 09:49

Can u tell us where to find it ? (20041012)
Thanks.

marcellus

28th November 2005, 10:10

FFDShow is permanently developed and improved by milan. In the the mean time the same thing is happening to libavcodec and mplayer, on which ffdshow is partly based. Using ancient versions is not the way to go, IMHO. The way to go is to report issues to milan so he can find sollutions.

Egh

28th November 2005, 17:06

zilexa
> Nobody uses the 2004 build anymore..
Hmm, I use ffdshow-20041012 only - the last one from sourceforge and IMHO the most stable and bug-free version. Sporadically, I download and try some new version from aziendeassociates, or from freecodec, or so; but they are almost always so buggy and unstable so I return back to 2004 build :(

> with the latest most stable build would be nice!
Sincerely second. :)

It might be *very* stable... But how do you play AVC streams then? :P

Iirc such things for avc like 8x8dct and qp=0 are supported only from late june 2005 builds. Moreover, it still contain nasty crash bug for high-profile avc streams, and if one parameter was present in stream, that could easily crash ffdshow. That bug was corrected only in middle august 2005 builds :)

So while 2004 old ffdshow might be stable, it lacks some important features as well.

And i think most last builds are actually pretty stable anyway :P

celtic_druid

28th November 2005, 17:25

Also if I recall correctly there was a bug with the installer for ffdshow-20041012. If installed on an NT based windows it doesn't correctly install VfW. So no VfW decoding/encoding. Easy to fix by changing program files to progra~1 in ffdshow's vidc entry. But hardly what I would call bug free.

DeathTheSheep

28th November 2005, 20:25

ExtraEye

28th November 2005, 20:56

when i use video renderer 9 + output to RGB32 i have a problem with mkvs and ogms with soft subtitles.
the subtitles aren't displayed correctly and are transparent to the video in a way... (unreadable).

to fix the problem i enable colorspace yv12.

is this only me or it's supposed to be like this?

Egh

28th November 2005, 22:49

issa

29th November 2005, 00:58

DeathTheSheep

29th November 2005, 07:46

Which version of MSVC build that you are using for comparison?
This one. ;) (http://forum.doom9.org/showthread.php?p=742955#post742955)

ExtraEye

29th November 2005, 12:40

depends on how you define "not displayed correctly". Haven't noticed such behaviour though on ffdshow.

like i said, trasparent or black - unreadable.
you do see there are subtitles, but there's no way to actually read them.

videomixer9

29th November 2005, 12:42

depends on how you define "not displayed correctly". Haven't noticed such behaviour though on ffdshow.

Yeah I know this problem and it's yet another reason for me not to use VMR9. You can see the border of the subs but the subs, especially with styled subs quite funny are see-through ones. They flicker a bit and keep one picture transparent and the video in the back doesn't fit anymore. Though I think that's something broken in vsfilter.

FFDShows internal softsub filter is the same crap as mplayer/VLC sub renderers. They just stink with styled subs (though they stink all the other time too as shadow etc. all just are looking fucking ugly) which are mosten used in anime only though.

Of course all of the arrogant rest of ppl there wouldn't bother cause they prolly watch movies dubbed to their language or are fanatics of non-styled subs as they have a hard time already reading a single line without any styles. :)

ExtraEye

29th November 2005, 12:53

Yeah I know this problem and it's yet another reason for me not to use VMR9. You can see the border of the subs but the subs, especially with styled subs quite funny are see-through ones. They flicker a bit and keep one picture transparent and the video in the back doesn't fit anymore. Though I think that's something broken in vsfilter.

FFDShows internal softsub filter is the same crap as mplayer/VLC sub renderers. They just stink with styled subs (though they stink all the other time too as shadow etc. all just are looking fucking ugly) which are mosten used in anime only though.

Of course all of the arrogant rest of ppl there wouldn't bother cause they prolly watch movies dubbed to their language or are fanatics of non-styled subs as they have a hard time already reading a single line without any styles. :)

so... no way to fix this?

p.s - why call yourself VMR9 if you don't use it? lol.

darkavatar1470

29th November 2005, 13:14

hmm, I think I read about that bug on Doom9 sometime ago.... probably in the container section if it's MKV/OGM specific.

Egh

29th November 2005, 18:44

Yeah I know this problem and it's yet another reason for me not to use VMR9.

I don't use anything but VMR9 for subs. But I use mpc internal renderer and comparing VSFilter with MPC... Well MPC is far better (though more CPU % as well).

And subs renderer in ffdshow could be better, for sure.

P.S. btw i noticed two corrections for subtitles in ffdshow's log today. But with no messages given hard to tell what exactly was br0ken/fixed :P

_xxl

29th November 2005, 20:26

Has anyone else noticed that sse2 GCC-compiled builds are a lot faster than ICL9 builds, even on Intel processors?

decoding speed on XviD w/mplayer accurate PP on a Pentium 4 2.4ghz
ICL9: 41fps
MSVC: 69fps
GCC: 76fps
Sender: nobody
Libmplayer.dll and libavcodec.dll compiled with ICL9 are
wrong?

Sender: milan_cutka
Yes. Both libraries were developed primarly for Linux
projetcs (ffmpeg and mplayer) and to be compiled using GCC.
Hand-optimized SIMD code is written using GCC inline
assembly syntax which isn't supported by ICL9 (on Windows)
nor Microsoft C++ Compiler. To make those libraries compile
with these compilers it's required to disable functions
written in inline assembly. Only libavcodec.dll and
libmplayer.dll built using GCC can benefit from hand-
optimized MMX, SSE and SSE2 code in these libraries.
Only libmplayer compiled with GCC features SIMD optimized
versions of its functions. Otherwise only C versions will
be used resulting in lower performance and, as in this case
shows, limited functionality.
In blockCopy function in postprocess_template.c only SIMD
versions perform lumince levels fixing, C version does
simple copy only.

Egh

29th November 2005, 20:35

Only libmplayer compiled with GCC features SIMD optimized
versions of its functions. Otherwise only C versions will
be used resulting in lower performance and, as in this case
shows, limited functionality.

Yes, and that was the reason why one of the celtics' build in
September was slow in some modes. It was due to libmplayer
compiled with ICL, not gcc.

And since that code is hand-written... I afraid it's not properly
optimized for SSE1-only cpus, btw. So SSE2 is a must if you want
some exceptional speed :)

videomixer9

29th November 2005, 21:50

so... no way to fix this?

Only if you use MPCs inbuilt subtitle renderer, that one shouldn't be affected by this, if it's too then there's no fix except for fixing vsfilter :/

_xxl

29th November 2005, 22:02

ICL Linux is supported?
Which files can be compiled with ICL (on Windows)?
http://cutka.szm.sk/files/ffdshow-20051124.exe
ICL8 + GCC?
Sender: milan_cutka
I haven't tested ICL on Linux and I don't think it can
be used as cross-compiler anyaway. But if it can, it'd be
worth of trying.
With ICL9 you can compile all files which are in projects
included in ffdshow workspace. Additionally libavcodec can
be compiled using ICL and GCC: ICL to compile file
containing C code only and GCC to compile rest.
All files in my builds are compiled using ICL 8.1 except for
libavcodec.dll and libmplayer.dll which are compiled with
GCC 3.4.4.

_xxl

30th November 2005, 08:35

tested with:1280 x 720 .mp4
ffdshow-20051129 + nero h.264 parser
ffdshow h.264 decoder 100% cpu,no postprocessing
http://www.moviemaze.de/media/trailer/delivery/66344456615ca7c620887f52fae9156c9bb341959b/king_kong-alookinside_h720p.mov
Win XP Sp2,Amd XP 1600+ 512MB ddram.

Elic

30th November 2005, 09:26

ptiJean
> Can u tell us where to find it ? (20041012)
I use this one (http://sourceforge.net/project/showfiles.php?group_id=53761&package_id=59355&release_id=274595).

Egh
> how do you play AVC streams then? :P
I don't like AVC much and I don't encode into AVC, I prefer XviD. And I didn't see any good AVC rip so far, at least these rips were not so good so I would be needy in good AVC decoder for everyday use.

> i think most last builds are actually pretty stable anyway :P
Can you please advise me your favorite build? :) My internet connection is relatively expensive, and I can't download few megabytes build every time it publishes :(

celtic_druid
> there was a bug with the installer for ffdshow-20041012. If installed on an NT based windows it doesn't correctly install VfW. So no VfW decoding/encoding. Easy to fix by changing program files to progra~1
I even didn't know about this bug because I never install soft into "Program Files" - only to directories with 8.3 names (I treaded on such errors on past :( ).

Apropos, who can explain why development of ffdshow on sourceforge was freesed?

dimzon

30th November 2005, 09:37

Apropos, who can explain why development of ffdshow on sourceforge was freesed?
It was not! But there are not more fresh binaries on SF...

videomixer9

30th November 2005, 11:04

I don't use anything but VMR9 for subs. But I use mpc internal renderer and comparing VSFilter with MPC... Well MPC is far better (though more CPU % as well).

And subs renderer in ffdshow could be better, for sure.

P.S. btw i noticed two corrections for subtitles in ffdshow's log today. But with no messages given hard to tell what exactly was br0ken/fixed :P

I usually watch videos via the fullscreen mirror function on my tv. MPCs internal renderer draws to VMR9 thus there will be no subs in the mirrored video, besides that mirror doesn't work on VMR9 renderless at all anymore.

Egh

30th November 2005, 19:03

ptiJean

Egh
> how do you play AVC streams then? :P

Apropos, who can explain why development of ffdshow on sourceforge was freesed?

AVC is g00d enough to be used. And trust me, despite that it's very much overrated by Nero and other codec producers ("avc main profile 2x better than ASP" -- complete *BS* and only for lamas to buy it, it might be true comparing avc with Div3 single pass though :P). But in many cases it's better at same bitrate, I'm encoder myself and choose nero avc for most of my releases.

High profile AVC has many features like 8x8dct, which are supported on playback by Nero Decoder and libavcodec (the latter is what ffdshow uses). Iirc the first build of ffdshow to support this particular feature was 10th of June 2005 or something like that. And such thing like custom QM was introduced in ffdshow very very recently (not that many releases use that feature anyway so far).

As for recommended build, b0b0r's gcc are best choice for me (I have SSE1 only capable CPU aka AthlonXP). 20051115 is best option now, since 20051124 is not really good if you play some 29.97fps avc in VMR9 mode with subs on :) Since if your CPU is not enough, some samples are dropped. And it worked all nicely before 1124, but in that build it can cause assertion fault in libavcodec :O In fact I once had 2 assertion errors whilst watching one 24 min episode :P

development never stopped, is that developer doesn't want to create so-called "stable" builds. So all builds available are considered to be alpha tests. Recently Milan Cutka started posting so-called "daily" builds again on his website. http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

Those are no way any "stable" releases, but they work (well in most cases).

zatt

30th November 2005, 20:07

I have ffdshow-20041012 and i use mp cl 6.4.8.7 and my dvd is "hanging" if i downloaded the last ffdshow 20051103 will that mayby fix it ?
If i download the new ffdsh must i uninnstalled the old one first ? Do mp cl find this new ffd by itselvs ?
hehe mr "green" is asking big time :p

I`m very happy for a answer or a soloution on my quiestions
Have a nice day to all of you !!

issa

1st December 2005, 02:42

LigH

1st December 2005, 10:27

"x87 only" probably not anymore; but "MMX/iSSE only" could be nice (having an AMD Duron here).

_xxl

1st December 2005, 10:34

Only libavcodec.dll and libmplayer.dll built using GCC can benefit from hand-
optimized MMX, SSE and SSE2 code in these libraries.
Libavcodec.dll and libmplayer.dll are sse or sse2?
http://cutka.szm.sk/files/ffdshow-20051129.exe
ICL + GCC sse or sse2?

Yong

1st December 2005, 12:55

Latest CVS build,

SSE2 (using SSE2 instruction for FP operation):
MSVC Build: http://rapidshare.de/files/8412975/ffdshow-20051201-msvc-sse2.exe.html
GCC build: http://rapidshare.de/files/8413549/ffdshow-20051201-gcc-sse2.exe.html
For SSE only user, replace the dll after you install the GCC SSE2 build.
SSE DLL: http://rapidshare.de/files/8413991/dll-20051201-sse.7z.html
Milan daily builds is still the fastest.
ive tried above 2 GCC/MSVC SSE2 build in my p4 2.4ghz machine,
play with my super crap quality Divx4.0 video clips(512x384 24fps), with ffdshow hqdenoise3D, 2xsai/Super2xsai and some minor postpreocessing options.
MSVC is a little bit faster than GCC build.... ;)
With Milan's build, i can use untill hq2x with no drop frames.

bob0r

1st December 2005, 17:15

reason for update: handle multiple pps in avc header
changelog: http://cia.navi.cx/stats/project/ffdshow
what you have to do: enjoy

_xxl

1st December 2005, 19:39

ffdshow x64 version?

ExtraEye

1st December 2005, 20:08

reason for update: handle multiple pps in avc header
changelog: http://cia.navi.cx/stats/project/ffdshow
what you have to do: enjoy
any chance to get an SSE2 version?

madman1980

1st December 2005, 21:29

Half of my HDTV mpeg2 .ts streams won't show any picture in mpc with milan's -24 and -29 versions. The others stutter every 5 seconds although CPU usage is only at 20%.

Rash

2nd December 2005, 03:31

I tried to google for Tremor but didn't find any website. Could someone tell me (or point me to) what is the point in using low accuracy for Vorbis?

celtic_druid

2nd December 2005, 06:40

--enable-low-accuracy enable 32 bit only multiply operations

Kostarum Rex Persia

2nd December 2005, 16:03

ffdshow x64 version?

Yeah,it's time for Ffdshow x64 version.Celtic_druid,what do you think about it,can you or somebody else try to compile working build of ffdshow 64-bit?

Sirber

2nd December 2005, 16:13

@Kos

Wht do you keep bugging for 64bit stuff when you have a 32bit CPU?

http://forum.doom9.org/showthread.php?t=103008

Kostarum Rex Persia

2nd December 2005, 16:36

Because, I buy 64-bit machine two days ago.Athlon 64 3800+ Venice core.

Sharktooth

2nd December 2005, 16:44

And let me guess, you have 32bits winxp, right?

celtic_druid

2nd December 2005, 16:56

I already tried a 64bit version of ffdshow. It didn't work and I don't boot into X64 that often so I don't think I will try again for awhile. Nothing stopping anyone else from having a go though.

videomixer9

2nd December 2005, 20:45

Does video decoding profit much from 64bit anyways?

LigH

2nd December 2005, 22:28

Before you don't know what "64 bit" really means, you won't understand why you may get speed gains, and where in the algorithm.

Read this thread (http://forum.doom9.org/showthread.php?t=89719) about speed gain of 64bit AviSynth, DGDecode, XviD and VirtualDub. It is ... more marginal than revolutionary.

Rash

3rd December 2005, 01:44

--enable-low-accuracy enable 32 bit only multiply operations
OK, right. But isn't this good? Why "low accuracy"?

_xxl

3rd December 2005, 12:28

Is inline assembly supported?
Inline assembly is only supported by the Intel® IA-32 C++ compiler (icc and icpc). GNU gas* and Microsoft MASM* formats are available. There is no support for inline assembly on the Itanium® architecture.

_xxl

9th December 2005, 00:00

http://rapidshare.de/files/8842490/ffdshow-20051208.zip.html

DeathTheSheep

9th December 2005, 02:19

Currently the fastest working build yet! Thanks to you and milan!

Hylas

9th December 2005, 11:00

bob0r

9th December 2005, 12:29

Hmm coincidence, i did 1208 too :)

SSE:
ffdshow-20051208-gcc4.0.2-sse-x264.nl.exe
http://x264.nl/

SSE2:
ffdshow-20051208-gcc4.0.2-sse2-x264.nl.exe
http://files.x264.nl/ffdshow/ffdshow-20051208-gcc4.0.2-sse2-x264.nl.exe

NO-SSE(2):
ffdshow-20051208-msvc7.1-x264.nl.exe
http://files.x264.nl/ffdshow/ffdshow-20051208-msvc7.1-x264.nl.exe

hellfred

9th December 2005, 12:39

I installed the latest daily build from the ffdshow-sourceforge page (ffdshow-20051129), but encoding to MPEG4-libavcodec seems to be a lot slower than with the build I used previously (ffdshow-20041012-sse2). I am using the same settings (interlaced encoding, denoise3d, bicubic resize), yet whereas CPU-load stayed below 80% with the old version, it's about 95-100% now and some frames are dropped.

I wonder, is this performance loss due to compiler optimisation (no sse2?) or changes in libavcodec? What is the fastest build (for P4) that is reasonably up-to-date?
ffdshow-20041012-sse2 is quite old, and AFAIK, some defaults have been changed for encoding MPEG4-ASP in libavcodec. You can try to compare the speed with exactly the same settings in both ffdshow versions (including motion estimation search algorithm and its parameters, mbd/vhq etc.) to check for different defaults. Some parameters may have changed names (e.g. vhq to mbd). See mplayer manpage (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html#CODEC%20SPECIFIC%20ENCODING%20OPTIONS%20(MENCODER%20ONLY)) in the section "lavc (-lavcopts)" for latest paramete description. Frame dorps should not occure, though. Try another, quite up to date build, too.

Hellfred

ExtraEye

9th December 2005, 12:52

thx for the new builds. especially for the SSE2 :D
by the way, how do you guys check the speed of the decoding? do you check how much CPU the player you use takes when you play a file or do you have some sort of program that measures the speed?

Hylas

9th December 2005, 13:48

ffdshow-20041012-sse2 is quite old, and AFAIK, some defaults have been changed for encoding MPEG4-ASP in libavcodec. You can try to compare the speed with exactly the same settings in both ffdshow versions (including motion estimation search algorithm and its parameters, mbd/vhq etc.) to check for different defaults.
I figure, it must be something like that. I'm using "rate distortion", no "4 MV", no chroma ME. Everthing else seems to be set to the simplest option anyway.

I tried celtidruid's last compile (ffdshow-20051103), but apparently the installer fails to register ffdshow.ax correctly, as it is not used for playback and the uninstall process hangs up while unregistering. I'll try another build later.

On a possibly unrelated note: An old Xvid decoder (XviD-1.0-RC3-29022004) cannot play interlaced files produced with the new ffdshow; keyframes are fine but motion creates huge swimming blocks). It has no problem with the older one.

Hylas

9th December 2005, 15:26

SSE2:
ffdshow-20051208-gcc4.0.2-sse2-x264.nl.exe
http://files.x264.nl/ffdshow/ffdshow-20051208-gcc4.0.2-sse2-x264.nl.exe

I get a protection fault in KRNL386.EXE after I click "next" in the "choose components" step of the installation. Is your version compatible with Win98?

signatory

9th December 2005, 15:26

when I use ffdshow as VFW to edit xvid and divx5 the video is upside down, but the switches to 'flip video' don't do anything. I installed xvid codecs instead and they work fine and use ffdshow for only playback. Anyone got some suggestions as to the upside down issue?

my w2k is pretty clean... just ffdshow and xvid.. latest DX beta.

Egh

9th December 2005, 17:38

BTW after installing someone's build 20051208 i lost all the settings in ffdshow. Have anybody noticed similar thing?

Also, in recently posted here ffdshow-20051208.zip ffdshow installation file itself is dated 2005-01-01. Is this kind of joke or what? ^^

breez

9th December 2005, 18:09

SPP deblocking in 8 Dec build is improved. It blurs details less than before although it is somewhat heavier on the CPU (using drevil_xxl's icl9+gcc build, not too much difference to milan's latest in terms of cpu usage, but celtic's oct 13 build is still the fastest with around 7% less cpu usage w/ XP 1.9GHz).

MacAddict

9th December 2005, 18:30

Too bad you guys dont have your system specs in your signature. It would be helpful for the rest of us when determining the 'fastest' build for our system as well.

So far no problems with any of the latest December builds here.

madman1980

9th December 2005, 23:21

Is there any chance you can make a version that detects SSE/SSE2 by itself so there's no reason for two installer files?

Egh

9th December 2005, 23:33

Is there any chance you can make a version that detects SSE/SSE2 by itself so there's no reason for two installer files?

It was answered before. In short -- it's possible but require too much manual job on those files [and milan doesn't want to do that]. Also, some parts of ffdshow work *only* if SSE is found. There was one entry on the ffdshow bugtracker about that. Like if no SSE is not present in the system, instead of one filter only simple copy is used.

falcon2000eg

10th December 2005, 14:07

bob0r your sse2 build crash with every movie type using overlay or vmr9 on my pc
P4-2.4 Ati-radeon 7000 384MB DDR windows XP pro sp2

ExtraEye

10th December 2005, 15:00

for me i think bob0r's latest was slower(SSE2 build). right now using drevil_xxl build.

Ye110man

10th December 2005, 16:11

Athlon64 2800+ here. Which build is the best for me?

Inventive Software

13th December 2005, 14:17

What's the core name? Something like Venice or Newcastle?

bob0r

13th December 2005, 16:48

bob0r your sse2 build crash with every movie type using overlay or vmr9 on my pc
P4-2.4 Ati-radeon 7000 384MB DDR windows XP pro sp2

Please report all info + more to the ffdshow Developer:
http://sourceforge.net/tracker/?group_id=53761&atid=471489 (Bug reports here)

I only compile the ffdshow source, i can't test SSE2 builds myself, maybe others can confirm your problem.

Ye110man

13th December 2005, 18:36

What's the core name? Something like Venice or Newcastle?
I have a Newcastle.

Inventive Software

15th December 2005, 10:50

Look for an SSE2 build. I think SSE3 was only implemented in the Venice cores, but I may be wrong. ;)

IvS

15th December 2005, 13:46

SSE3 is included in the Venice, Newark, San Diego and Toledo cores.

Inventive Software

15th December 2005, 13:55

Not the Newcastle then. ;)

So I was right. SSE2 you are looking for, or *gulp* SSE or non-SSE.

Jorgosch

15th December 2005, 14:17

http://www.afterdawn.com/software/video_software/codecs_and_filters/ffdshow.cfm

signatory

15th December 2005, 16:01

Can anyone confirm that the Flip Video setting works? I'm using ffdshow-20051129
and MPC 6.4.8.7 and the switch doesnt do anything.

Yong

15th December 2005, 19:04

Can anyone confirm that the Flip Video setting works? I'm using ffdshow-20051129
and MPC 6.4.8.7 and the switch doesnt do anything.
Its work for me, tested with MPEG1 and x264 video clips.

bob0r

17th December 2005, 20:45

http://download.microsoft.com/download/9/4/2/9428d199-bf6b-4bf4-8c45-89a439199278/dxsdk_dec2005.exe

Might be useful.

_xxl

22nd December 2005, 13:02

http://rapidshare.de/files/9627377/ffdshow-20051221.zip.html

_xxl

22nd December 2005, 16:18

http://rapidshare.de/files/9636739/ffdshow-20051221.zip.html

DeathTheSheep

22nd December 2005, 17:13

A faster, better mirror for your build, drevil ;)
(drevil_xxl ICL9+GCC4.0.2) ffdshow-20051221.zip (http://www.myfilehut.com/userfiles/5120/CollectedBuilds/ffdshow-20051221.zip)

Your last ICL9 build (12-08) had the noise shaping feature working perfectly, but this one shows the crashing behavior I mentioned before. Perhaps if you compiled the noise shaping code with ICL9... :D

Kurosu

22nd December 2005, 19:25

I had a build automation script for years (when Athos was still around) and I finally put enough effort into it to have it running more or less clean. What it does:
- get ChangeLog
- do cvs update
- compile the targets set in the configuration files
- generate the HTML page linked below
- upload files

You can check the result over at http://kurosu.free.fr/ffdshow.htm

Prerequisits for it to work are probably:
- gcc 4.0.2 from sherpya or your own compile
- mingw (my version is a patchwork, so I can't be more precise)
- msys and its DTK (mostly for perl)
- a large upload space available through FTP
- NSIS. 2.02 probably
- upx in the path
- apply the patch listed here (http://sourceforge.net/tracker/index.php?func=detail&aid=1379941&group_id=53761&atid=471491) as some libraries wouldn't be remade without it
- a FFDShow CVS tree; its folder name must be ffdshow, and this script should be put in its parent folder

I tested it both through the "task scheduler" in Windows, and a cron job + cross-compilation under linux, and it worked at some point. I don't know if it does now.

There would be many additional things to say about how to use and set it up, but I'm just going to say, like many funny people: the documentation is the code, so enjoy. As far as I'm concerned with this script, I'm done.

thuan

23rd December 2005, 13:01

Kurosu I can't find your Athlon 1225 build?

canuckerfan

23rd December 2005, 23:02

Kurosu, I noticed that your builds also have SSE3. However, your builds don't work on my system. The option dialogues for ffdshow don't open and whenever I play something in MPC, it says something along the line of cannot render and try downloading a codec.

MacAddict

25th December 2005, 17:46

I've got the same problem as canuckerfan above. No properties dialog and MPC gives the rendering error, then XviD Decoder kicks in and works. That problem only existed with the K8 A64 build though. I tried the 12-21 P4 build and it seems to work great.

Many thanks

IvS

25th December 2005, 18:11

Same here with a Venice core Athlon 64 3200+.

DeathTheSheep

26th December 2005, 00:39

Same problem as those above, but I don't have SSE3 (...probably. Celeron D 2.93ghz with 533FSB). But still, it's the exact same problem as the folks above have. :)

issa

30th December 2005, 03:10

Latest CVS build,

Here is Intel C++ Compiler build with '-arch:SSE2' (some dll compiled with gcc 4.0.2).

http://rapidshare.de/files/10074282/ffdshow-20051230-icc-sse2.exe.html

Could someone to test it working or not on non-Intel CPU?

IvS

30th December 2005, 04:02

issa: It works.

cyberyeye

31st December 2005, 19:25

Hi :)

Sorry to ask this if this already answer but what build is fine or optimized for A64 (3700+, san diego, 90nm) ???

Gcc build post on http://x264.nl/ seems broken to me because seeking has some "freeze" during 10 sec. this not systematic but really boring.

Don't have this problem with xvid decoder from 1.1.x only with ffdshow.

so wich build is better for A64 (on win32) ?

ps: happy new year to everyone ^^

39 pages to read, maybe it's time to put this info "wich build for..." on sticky or at least on the 1st page no ?

ExtraEye

3rd January 2006, 17:14

cyberyeye,
im using that build with no problems.
also my processor is athlon64 3000+.

from what i recall the best build for athlon64 is gcc with sse2 (and also from what i understood sse3 woun't improve the performence).
so what i do is stick to bob0r builds(unless someone else made a more updated gcc with sse2 ability) that use sse2.

cyberyeye

3rd January 2006, 18:53

Thanks for your reply :)

Bob0r build = http://x264.nl ???
mean for example this build: http://mirror01.x264.nl/x264/ffdshow-20051221-gcc4.0.2-sse-x264.nl.exe
build linked on x264.nl

but this build is "marked" sse, and not sse2...

If i'm wrong where's sse2 bob0r build on 264.nl I see only sse build ?

ExtraEye

3rd January 2006, 20:42

sometimes he doesn't make an sse2 build.

btw
nice nick ;)

DeathTheSheep

4th January 2006, 01:00

What, are we mustn't be sheepy about our eyes--they can lead to our untimely death ;)

cyberyeye

4th January 2006, 01:59

Thanks for the info ExtraEye ^^
Now we should just wait for SSE2 build from bob0r !

:goodpost:

videomixer9

4th January 2006, 19:49

Libraries only, replace with existing ones in ffdshow directory, no ffdshow.ax

GCC 4.0.3 for Athlon 64 SSE3 non-x64 (may also work on SSE2 only)
ffdshow-20060104-gcc4.0.3-athlon64-sse3-x86.7z (http://rapidshare.de/files/10396650/ffdshow-20060104-gcc4.0.3-athlon64-sse3-x86.7z.html)
GCC 4.0.3 for Athlon XP SSE
ffdshow-20060104-gcc4.0.3-athlonxp-sse-x86.7z (http://rapidshare.de/files/10399396/ffdshow-20060104-gcc4.0.3-athlonxp-sse-x86.7z.html)
both contain x264, libmad, libmplayer, libavcodec, libdts, liba52, theora, tremor, realaac, faad

cyberyeye

5th January 2006, 17:18

GCC 4.0.3 for Athlon 64 SSE3 non-x64 (may also work on SSE2 only)
ffdshow-20060104-gcc4.0.3-athlon64-sse3-x86.7z
Thanks I tried and it works fine ; replaced over 21122005 gcc build from x264.nl, now sse3 in ffdshow should be activate and now no "freeze" when seeking an xvid or divx files :-)

ExtraEye

5th January 2006, 22:46

thx videomixer but how do i check if it works now? i mean the libraries and the SSE3?
(it doesn't have a box for sse3)

Rash

6th January 2006, 00:09

Celtic Druid is not releasing builds anymore?

Oh, and just a question. I notice here SSE, SSE3, Athlon64... releases. So that information available on "Info & Debug" while a video is playing, that shows which optimizations are available, are worthless?

Romario

6th January 2006, 01:27

Celtic Druid is not releasing builds anymore?

Sad to hear that:(

signatory

8th January 2006, 19:16

Can someone be so kind to share their ffdshow settings for good xvid playback ? I used the default but get a bit jumpy playback. (frame skippin' ) hit the bug switches, a little bit better. But still not perfect. libavcodec is codec I don't want to install xvid stand alone codecs cos they suck for me.

What IDCT should I use ? Any other ideas? much appreciate help

EDIT: I figured it out. A bug in ffdshow vfw.

issa

9th January 2006, 10:58

Inventive Software

9th January 2006, 15:22

http://forum.doom9.org/showthread.php?p=764952#post764952. Hopefully this will be a more up to date catalogue of ffdshow builds.

ExtraEye

9th January 2006, 16:05

good idea
now what will become of this thread...

videomixer9

9th January 2006, 16:36

Where did you find the GCC 4.0.3?

www.reactsoft.com

had this idling on my disk for month so ... doesn't seem to be official but the compiled code said 4.0.3 too so I just used that ... guess they made it 4.1.0 later or maybe it's only late bugfixes ... whatever it worked fine so I kept using it.

Romario

9th January 2006, 21:16

Is SSE3 FFDSHOW really work? I doubt it.

videomixer9

10th January 2006, 18:42

just used those compiler options, I doubt it uses SSE3 really though, however there weren't much (if any at all) changes anyways but it seemed to do the job in not crashing in certain situations, only reason I did it and tagged it that way to make only ppl with those athlon cores get it :) not that i'll do any fruther compiles anymore as CoreAVC totally killed my reason for using ffdshow ...

cc979

13th January 2006, 22:02

has anybody tried compiling gcc-4.1 yet ?
and compiling ffdshow with it ?

bob0r

19th January 2006, 08:18

Can you compile gcc 4.1 on mingw/msys then?

cc979

19th January 2006, 19:43

Can you compile gcc 4.1 on mingw/msys then?

not had time try, well do tonight

cc979

21st January 2006, 02:25

Can you compile gcc 4.1 on mingw/msys then?

rumours that is possible, with some earlier builds but not with svn

to many errors for me

just did a test rebuild of ffdshow, nsis2 give me a strange error and theres no dts - help

DigitalDivide

23rd January 2006, 02:34

I downloaded the latest Milan build and seem to be having a problem with the Preset Automatic Loading.

I have two presets. One for my DVD's and one for avi's. One loads on Filename Match with wildcards using *.avi and the other video_ts*. For some reason which ever preset is highlighted is the one that gets loaded regardless of the filename. I've tried uninstalling and reinstalling and no matter what the same preset always loads regardless. I know I used to have this working with an earlier one but I don't remember what version I had installed previously. Anyone have this problem? Any idea how to fix it.

lithoc

23rd January 2006, 02:42

I'm using my friend PC the other day.

It's a Celeron 500mhz + Intel i810g chipset(s370, integrated graphics), WinXP SP2, 128MB SDRAM.

Having tried,

1.) ffdshow-20051221-gcc4.0.2-sse-x264.nl.exe from x264.nl.
2.) ffdshow-20051109.exe from x264.nl.
3.) (drevil_xxl ICL9+GCC4.0.2) ffdshow-20051221.zip

Crashed when:
1.) Playing audio dshow is use. Happen to any audio codec.
2.) Opening up the video dshow configuration screen. It play the video tho.
3.) Any filter in video dshow will crash.

Need expert oppinion on this.

Do anybody build ffdshow for old machines (eg Pentium-MMX, Pentium 2, older Celeron)?

I still have Pentium-MMX(overclocked) to watch movies sometimes(for sake of torturing it :devil: )
It plays perfectly on Linux + mplayer via VESA 2.0 output.

issa

23rd January 2006, 03:34

issa

23rd January 2006, 06:46

Latest CVS build,

SSE2 build (icl 9 + gcc): http://rapidshare.de/files/11624452/ffdshow-20060123-icc-see2.exe.html

Egh

23rd January 2006, 16:38

Latest CVS build,

SSE2 build (icl 9 + gcc):

Were there any serious changes in ffdshow cvs last 3-4 weeks or so? ^^

clsid

23rd January 2006, 17:35

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

No updates since Dec 21, 2005 ... until today. I guess Milan is back from vacation :)

videomixer9

23rd January 2006, 18:05

anyone willing to do a more general build?

clsid

24th January 2006, 00:01

Look in this topic for ffdshow builds:
http://forum.doom9.org/showthread.php?t=105386

Lemonzest

24th January 2006, 01:21

with the icl9 builds are the non-pentium checks removed?

clsid

24th January 2006, 01:39

Yes. GenuineIntel check has been patched.

lithoc

24th January 2006, 03:41

Yes. GenuineIntel check has been patched.

Audio filters is not working. Output statics when enabling it.

cc979

24th January 2006, 05:09

anybody get this error building todays cvs,

TglobalSettings.cpp: In member function 'virtual CodecID TglobalSettingsDecAudio::getCodecId(DWORD, FOURCC*) const':
TglobalSettings.cpp:994: error: 'WAVE_FORMAT_DSPGROUP_TRUESPEECH' was not declared in this scope
make[1]: *** [ffdshow_settings_all.o] Error 1
make: *** [lib] Error 2

OutsiderX

24th January 2006, 10:18

issa,:thanks: for your effort to supply us with the lastest build of ffdshow...

but I found that ffavisynth.dll is not workin' at all....maybe b/c your compiled it with gcc
for anyone who has the same problem like me
you can use
this
http://files.x264.nl/force.php?file=./ffdshow/ffdshow-20051021/icl9.0/ffavisynth.dll
or this one
http://files.x264.nl/force.php?file=./ffdshow/ffdshow-20051021/msvc7.1/ffavisynth.dll

clsid

24th January 2006, 15:34

Audio filters is not working. Output statics when enabling it.
I did some quick tests. Only Freeverb doesn't seem to work. However if I enable Dolby Decoder too, then Freeverb works.

lithoc

25th January 2006, 02:38

I did some quick tests. Only Freeverb doesn't seem to work. However if I enable Dolby Decoder too, then Freeverb works.

Try Equalizer, anything higher than 0db will output statics.

Volume filter works, but the Normalize percentage is not correct.
Sound weird as well, it's not smooth. The sound level suddenly jump from soft to loud and vice versa.

issa

25th January 2006, 06:26

OutsiderX

25th January 2006, 08:44

I just tried your new build and I still get the same error...But 10X for trying to fix it though.
I just did some search and found that I'm not the only one who has this problem,Thank God for that :D

http://forum.doom9.org/showthread.php?t=104633

Esc

26th January 2006, 04:07

ffdshow-20060125-icc-sse2.exe says "Error while registreing ffdshow.ax" on installation. Where do I address that?

Razorholt

26th January 2006, 07:16

If you have any version already installed, uninstall it, reboot and try again.

- Dan

namchik

26th January 2006, 07:46

ffdshow-20060125-icc-sse2.exe says "Error while registreing ffdshow.ax" on installation. Where do I address that?
Make sure you have MS runtime libraries in your sys32 or ffdshow folder... To be more precise i guess you need "msvcr71.dll"

signatory

26th January 2006, 14:55

ffdshow-20060125-icc-sse2.exe says "Error while registreing ffdshow.ax" on installation. Where do I address that?

I have encountered this error message too, in the past and with this one.
OK it's easy to fix by uninstalling the old ffdshow but it would be pretty terrible if one would forget to save the ffdshow.reg settings first....

LoRd_MuldeR

27th January 2006, 01:46

Latest CVS build (icl 9, msvc, gcc [libmplayer, libavcodec]): http://rapidshare.de/files/11775390/ffdshow-20060125-icc-sse2.exe.html

Is there a build for non-SSE2 CPUs aviable yet?

issa

27th January 2006, 03:19

ffdshow-20060125-icc-sse2.exe says "Error while registreing ffdshow.ax" on installation. Where do I address that?
Sorry for the problem.... Here is the lastest CVS build and the installation should be fixed.

Updated 02-02-2006, all the DLL outside the ffdshow directory, libavcodec & libmplayer are compiled with gcc.
SSE2 Build (icl 9, msvc 8, gcc): http://rapidshare.de/files/12367610/ffdshow-20060202-icc-sse2.exe.html
SSE Build (icl 9, msvc 8, gcc): http://rapidshare.de/files/12429903/ffdshow-20060203-icc-sse.exe.html

LoRd_MuldeR

27th January 2006, 03:40

Sorry for the problem.... Here is the lastest CVS build and the installation should be fixed.

SSE2 Build (icl 9, msvc 8, gcc [libavcodec & libmplayer]): http://rapidshare.de/files/11916301/ffdshow-20060126-icc-sse2.exe.html

and SSE1 ???

CeeJay.dk

1st February 2006, 02:16

Sorry for the problem.... Here is the lastest CVS build and the installation should be fixed.

Installation should be fixed.
SSE Build (icl 9, msvc 8, gcc [libavcodec & libmplayer]): http://rapidshare.de/files/12073437/ffdshow-20060129-icc-sse.exe.html

This gives me the error R6064.
"An application have attemted to launch the C Runtime library incorrectly" .. or something like that.
It keeps bringing up that errormessage when ffdshow tried to load and if I click OK it keeps comming back .. forcing me to reset the PC.
So the errormessage might not be exact word for word.. that just what i remember it said.

issa

2nd February 2006, 13:20

This gives me the error R6064.
"An application have attemted to launch the C Runtime library incorrectly" .. or something like that.
It keeps bringing up that errormessage when ffdshow tried to load and if I click OK it keeps comming back .. forcing me to reset the PC.
So the errormessage might not be exact word for word.. that just what i remember it said.

Sorry for the error of the last build. It may case by installing msvcr8.dll on system32 directory on the last build. The lastest build will not do that since those dll were compiled with gcc and will not depended on msvcr8.dll.
Please try the lastest build upstair.

CeeJay.dk

3rd February 2006, 00:15

I tried the new SSE build .. it crashes MPC when I try to watch something.

It also crashed on me , when I click the Output or the Grab or the section of the Video decoder configuration of ffdshow

LoRd_MuldeR

3rd February 2006, 00:16

Updated 02-02-2006, all the DLL outside the ffdshow directory, libavcodec & libmplayer are compiled with gcc.
SSE2 Build (icl 9, msvc 8, gcc): http://rapidshare.de/files/12367610/ffdshow-20060202-icc-sse2.exe.html
SSE Build (icl 9, msvc 8, gcc): http://rapidshare.de/files/12373865/ffdshow-20060202-icc-sse.exe.html

I tried the latest SSE build (ffdshow-20060202-icc-sse.exe) and it seems to work fine so far ;)

Nevertheless it seems to me like the audio quality is not as good as in the older builds. Anyone noticed the same? (I noticed it with MP3 audio in an AVI video)

issa

3rd February 2006, 01:08

I tried the new SSE build .. it crashes MPC when I try to watch something.

It also crashed on me , when I click the Output or the Grab or the section of the Video decoder configuration of ffdshow
What's kind of cpu you have?

LoRd_MuldeR

3rd February 2006, 01:14

What's kind of cpu you have?

I was able to reproduce the crash CeeJay.dk mentioned :(
CPU is AMD AthlonXP (Barton)

issa

3rd February 2006, 04:28

Fixed SSE CVS Build.

SSE Build (icl 9 + msvc 8, gcc): http://rapidshare.de/files/12429903/ffdshow-20060203-icc-sse.exe.html

I did tried the installation. It's seem to work fine, no crash. Sorry for the problem on last build.

CeeJay.dk

3rd February 2006, 11:20

I was able to reproduce the crash CeeJay.dk mentioned :(
CPU is AMD AthlonXP (Barton)

So is mine.

CeeJay.dk

3rd February 2006, 11:32

CeeJay.dk

3rd February 2006, 11:53

I've tested all the options briefly and I can only find one other flaw besides Xvid not working.

When you rightclick in the codecs list in the audio configuration you get the option of setting all to either libavcodec or Xvid .. which is probably carried over from the video configuration.
That's hardly a fault with the compile but rather with the sourcecode.

Matrics

3rd February 2006, 16:45

A suggestion: issa, can you change the version from title bar? I'm still seeing ffdshow-20051216...

LoRd_MuldeR

3rd February 2006, 17:44

issa

3rd February 2006, 19:55

I found out why it crashes (still does) MPC.
I had decoder set to XVID because IMO the quality of the decoder is better (better deblocking mostly)
When I set it to libavcodec it does not crash MPC.

The Xvid decoder relies on the xvid.dll .. might be a problem with your compile of that dll.

Did you try my latest build? The xvidcore.dll were compiled by msvc 8 with SSE support turn on.
I did try it on my computer; however, I didn't get crash. I am using intel cpu.

clsid

3rd February 2006, 20:33

Why include xvidcore.dll with ffdshow? If someone wants to encode with XviD, they should install XviD. And for playing XviD with ffdshow that dll isn't needed.

issa

4th February 2006, 02:46

Why include xvidcore.dll with ffdshow? If someone wants to encode with XviD, they should install XviD. And for playing XviD with ffdshow that dll isn't needed.
I would like to know how many people want my build to include xvidcore.dll with ffdshow installation. If there is more people perfer not to include/should not include it, I will remove it on next build.

hellfred

4th February 2006, 10:16

I would like to know how many people want my build to include xvidcore.dll with ffdshow installation. If there is more people perfer not to include/should not include it, I will remove it on next build.
I do not need xvidcore.dll. I usually dl latest xvid binaries from Koepi and ffdshow usually finds those. Therefor I prefere to just have one dll and smaller download size for ffdshow.

Hellfred

CeeJay.dk

4th February 2006, 18:42

Did you try my latest build? The xvidcore.dll were compiled by msvc 8 with SSE support turn on.
I did try it on my computer; however, I didn't get crash. I am using intel cpu.

Yes , I used ffdshow-20060203-icc-sse.exe.

clsid : AFAIK It is needed if you want to decode with Xvid's decoder instead of libavcodecs .. and Xvid's decoder provides better quality.

But as hellfred just let us know if the xvidcore.dll is not included ffdshow will find xvidcore elsewhere on the computer (like in my Xvid directory).
I just tried this and it works .. the koepi xvid i'm using causes no problems.

Issa , I think you should leave xvidcore.dll out .. ffdshow will find and use xvid if its installed anyways.
If you want to compile xvid then just make a xvid install just like koepi's.

Lemonzest

4th February 2006, 22:05

what's the latest build? i cant dl from any of the rapidshare mirrors, and would like a updated gcc sse2 build. thanks.

Lemonzest

LoRd_MuldeR

4th February 2006, 22:48

what's the latest build? i cant dl from any of the rapidshare mirrors, and would like a updated gcc sse2 build. thanks.

Lemonzest

What's the problem with downloading from Rapidshare ???

Lemonzest

5th February 2006, 00:57

well my isp uses transparent proxies and it says I'm already downloading a file, or i have reached my limit.

japouleripeur

5th February 2006, 01:46

well my isp uses transparent proxies and it says I'm already downloading a file, or i have reached my limit.Yes, same problem for me too:confused:

LoRd_MuldeR

5th February 2006, 02:48

To the guys that can't download from Rapidshare:

Try Free-Codecs mirror. Up-to-date builds can be found there:
http://www.free-codecs.com/FFDShow_download.htm

Lemonzest

5th February 2006, 03:09

thanks, any word on the gcc sse2 builds?

canuckerfan

5th February 2006, 04:54

^my comp likes gcc better than icc:rolleyes:

Lemonzest

6th February 2006, 00:01

for gcc builds i sometimes get them off here

http://kurosu.free.fr/ffdshow.htm

last few builds used to crash when using the OSD but todays seams fine (using the P4 sse/sse2 Build)

B.F.

6th February 2006, 11:13

I would like to know how many people want my build to include xvidcore.dll with ffdshow installation. If there is more people perfer not to include/should not include it, I will remove it on next build.
I don't need a xvidcore.dll in ffdshow.
Actually I also don't need any encoding dll's in ffdshow.

cc979

6th February 2006, 11:43

@bob0r

i just successfully built gcc-4.1 if ya interested, i can you the binaries - if it fails for you

LoRd_MuldeR

6th February 2006, 16:42

But as hellfred just let us know if the xvidcore.dll is not included ffdshow will find xvidcore elsewhere on the computer (like in my Xvid directory).
Issa , I think you should leave xvidcore.dll out .. ffdshow will find and use xvid if its installed anyways.
If you want to compile xvid then just make a xvid install just like koepi's.

I don't have XviD installed, since I now use x264 for encoding. Therefore I think it's fine to have the xvidcore.dll included with ffdshow :D
If there is any problem on compiling that DLL, why not just include the one form koepi's build?

cc979

6th February 2006, 23:19

@bob0r

been doing some compiling, `WAVE_FORMAT_DSPGROUP_TRUESPEECH' still broke for me

baseclasses not build using gcc-4+, but builds fine with gcc-3.4.5

any ideas ?

issa

7th February 2006, 03:52

@bob0r

i just successfully built gcc-4.1 if ya interested, i can you the binaries - if it fails for you

Did you get all the DLLs compiled with gcc-4.1?

Also, I will remove xvidcore.dll from my build. Sorry for any trouble causing from my build.

Eretria-chan

7th February 2006, 10:59

I noticed in ffdshow-20060203-icc-sse.exe, that SPP Deblocking is still extremely slow and my computer is barely able to handle fast spp deblocking. In windowed, it's fine - but in fullscreen is another matter. It starts to lag sometimes.
But I suppose this might be due to my weak Athlon XP 2800+ processor and my high resolution of 1920 x 1200.

CeeJay.dk

7th February 2006, 11:40

SPP deblocking have always been slow, the new fast SPP is a welcome addition but as you point out, even that can be too much for some computers.

My 2500+ barton is clocked at 2170 mhz and while it can just handle fast SPP i don't use it, because I prefer having noise- and sharpening- filters on instead.

This is hardly a problem with the compile - To make real improvement in this area, someone will have to code a faster SPP deblocker.

Eretria-chan

7th February 2006, 11:43

I know it probably isn't a problem with the compile, but worth mentioning anyway...
There are always faster methods to do something, although it doesn't mean it has to be implemted...

cc979

7th February 2006, 12:59

Did you get all the DLLs compiled with gcc-4.1?

Also, I will remove xvidcore.dll from my build. Sorry for any trouble causing from my build.

not had much look, does not even compile the baseclasses

bob0r

10th February 2006, 15:30

cc979

11th February 2006, 22:05

I have not tried gcc 4.1 pre builds yet.
Simple compile guide for mingw should be enough.

I myself are clueless about fixes.
Just report the bugs like you did on sourceforge and hope Milan awakens soon :)

Untill Milan is active, i will just lay low and use CoreAVC for h264 decoding :p

i've just tried cygwin - gcc 4.1 compiles no problems at all
seems fairly fast compiling to, been trying to do a cross-platform compile using cygwin to make gcc for mingw - no luck yet

also been trying to compile ffdshow with cygwin gcc 4.1 - cant compile the baseclasses not sure how to get the dxsdk into cygwin any hints ?

cc979

13th February 2006, 21:30

@bob0r could you upload the last compile-able version of ffdshow i've lost it, thanks

cc979

14th February 2006, 13:01

@bob0r could you upload the last compile-able version of ffdshow i've lost it, thanks

think i managed to get it of cvs

max-holz

18th February 2006, 15:33

cc979

20th February 2006, 00:05

Egh

20th February 2006, 23:09

I used Kuroshi last build (for Athlon, SSE1 only) but recently discovered problems with it. It's either build problem or new updated libavcodec in ffdshow. Essentially the problem is some kind of instability in ffdshow audio playing vorbis streams. E.g. using new (test) haali splitter causes crashes in ffdshow audio (more accurately libavcodec.dll) on playback. Haali checked it out and seems it's not his problem :) Works with 20060130 splitter but fails with new version, though he didn't change anything which could cause crashes since last official build.

So has anybody did any other successful builds of ffdshow in january? Would like to try them to see if it's really libavcodec probem (and need to be reported) or just particual build.

B.F.

21st February 2006, 07:57

bob0r

21st February 2006, 10:05

I got this error during compilation of gcc-4.1

gcc.exe: gengtype-lex.c: No such file or directory
gcc.exe: no input files
make[2]: *** [build/gengtype-lex.o] Error 1
make[2]: Leaving directory `/home/Proprietario/gcc-4.1/obj/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/home/Proprietario/gcc-4.1/obj/gcc'
make: *** [bootstrap] Error 2

Anyone could help me? I downloaded the source from an official mirror, so I don't understand

GCC snapshots are not made mingw ready.

However
ftp://ftp.nluug.nl/mirror/languages/gcc/prerelease-4.1.0-20060219/gcc-core-4.1.0-20060219.tar.gz
ftp://ftp.nluug.nl/mirror/languages/gcc/prerelease-4.1.0-20060219/gcc-g++-4.1.0-20060219.tar.gz
Are made mingw ready, i was able to compile this gcc 4.1.0-20060219 with gcc 4.0.2 (which already compiled on mingw)

So i guess soon we can expect gcc 4.1.0, hopefully not before i have submitted a x264 make fprofiled bug :P

For cygwin i don't know

Egh

22nd February 2006, 00:59

Same here.
Some Vorbus steam in video cause player to crash.
Also instead first keyframe in XviD video I see the second one two times.

Using kuroshi builds? Btw i didn't found difference in that aspect between athlon and p3 (both sse1 only) builds. I tried both 0123 and 0127 (which are the last builds after Milan dissappeared :)

zambelli

24th February 2006, 08:21

Egh

24th February 2006, 15:20

Here's an interesting bug I found in ffdshow:

If you use the Avisynth module in ffdshow to resize the video (i.e. Lanczos(width*2, height*2) ), ffdshow never updates the video image size when passing it on to the renderer. If using a player such as WMP or MCE, this will result in the video being zoomed in and cropped off because the renderer will perform scaling based on the old video resolution.

Can someone else try to repro this? Just enable the Avisynth module, enter "Lanczos(width*2, height*2)" as the script, and then play some video handled by ffdshow in WMP10.

Hmm, first, not Lanczos but LanczosResize :) Second, yeah i've seen some difficulties on resizing. But which build are you using? In my case the video stops updating after resizing turned on. (But size displayed is correct one). Though it's usually enough to seek video to bring back video updating. Btw problems with updating occur here with MPC (don't use other players :P).

zambelli

25th February 2006, 10:27

Hmm, first, not Lanczos but LanczosResize :) Second, yeah i've seen some difficulties on resizing. But which build are you using? In my case the video stops updating after resizing turned on. (But size displayed is correct one). Though it's usually enough to seek video to bring back video updating. Btw problems with updating occur here with MPC (don't use other players :P).
Sorry, I was writing shorthand... :)
MPC is one of the few players that handles this well, actually, although I can see it update its window size once the first video frames are decoded. It starts with a video window size based on the input file information, but then it adjusts its window size to whatever the correct processed video size is.

The reason why I'm pretty sure this is a bug in ffdshow and not in the players is because ffdshow's own internal resizing module doesn't exhibit these problems. I haven't checked ffdshow's code, but I'm guessing the image properties are updated throughout the pipeline. Apparently, however, this doesn't happen after the video goes through Avisynth.

vlada

27th February 2006, 10:32

There is also a bug in FFDShow when switching on and off 4:3 letterboxing in subtitle filter. It is especially annoying, if FFDShow doesen't load subtitles automatically. If I load them manually then, the video gets vertically squeezed, because neither MPC nor ViPlay will resize their window to 4:3 AR.

Also how far is implementing of DVD support? Is Milan working on it? Does anybody know?

LoRd_MuldeR

28th February 2006, 03:20

Also how far is implementing of DVD support? Is Milan working on it? Does anybody know?

ffdshow already decodes MPEG-2 as well as AC3/DTS
What more is needed ???

Zarxrax

28th February 2006, 04:06

There is a bug in ffdshow, such that when it is installed, it causes Adobe After Effects to crash when starting! If you select to install the Video For Windows part as well, then it fixes the problem.

I'm not sure why installing the VFW part would fix it, but regardless of that, ffdshow shouldn't be causing applications to crash!

Could anyone check into this?

vlada

28th February 2006, 11:10

ffdshow already decodes MPEG-2 as well as AC3/DTS
What more is needed ???

It is impossible to use FFDShow as a DVD decoder. Try it yourself. The DVD graph is not a common DirectShow graph.

Choose Video decoder -> Codecs -> MPEG-2. In the right bottom corner you'll see a checkbox saying DVD decoding (not working yet). I talked about supporting DVD decoding with Milan before. He said he'll be working on it, but unfortunately it is still not finished yet.

LoRd_MuldeR

1st March 2006, 03:36

It is impossible to use FFDShow as a DVD decoder. Try it yourself. The DVD graph is not a common DirectShow graph.

Choose Video decoder -> Codecs -> MPEG-2. In the right bottom corner you'll see a checkbox saying DVD decoding (not working yet). I talked about supporting DVD decoding with Milan before. He said he'll be working on it, but unfortunately it is still not finished yet.

I can playback Video-DVDs in MPC using ffdshow for audio- and video decoding...

zambelli

1st March 2006, 03:43

I can playback Video-DVDs in MPC using ffdshow for audio- and video decoding...
That's probably because MPC is using internal DVD source filters.
I'm pretty sure ffdshow can't handle CSS either.

vlada

1st March 2006, 10:42

Yes, it works in MPC, but it crashes ViPlay. But now I tried it in WMP10 and it works. But with libav as MPEG-2 decoder, the video is very choppy (uses 50% CPU). Mith libmpeg2 it plays smoothly, but still uses 50% CPU on my AthlonXP 2000+. But VLC is using 50% CPU with this DVD too, don't know why.
So it seems the DVD support is already implemented, but not very stable. ViPlay works flawlessly with other DVD (MPEG-2) decoders, my default is DScaler 5.

bob0r

1st March 2006, 11:49

February 28, 2006
GCC 4.1.0 has been released.

ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.1.0/

Let the testing/support begin! :D

Poutnik

1st March 2006, 16:08

What FDDShow release/binary would you recommend me for W2000 SP4 + SSE Celeron 600 ?

I have recently installed on my PC W2k SP4. I tried to see a movie - at that time it was still standard mplayer2 v 6.4 (Now using my favorites MV2playerRC2 or MPClassic ).
Without FFDShow it played fine.
I had fresh install of one of latest FFDShow ( not remember time of release yet, downloaded more ones ) with default settings. I thought W2K is said to be the most stable MS OS, but it caused complete OS freezing.
I know FFDShow is known to cause trouble at some circumstances so I would like you to advice me a good one by your experience.

Egh

1st March 2006, 17:32

What FDDShow release/binary would you recommend me for W2000 SP4 + SSE Celeron 600 ?

I had fresh install of one of latest FFDShow ( not remember time of release yet, downloaded more ones ) with default settings. I thought W2K is said to be the most stable MS OS, but it caused complete OS freezing.

You could easily have some odd build. Try using last "official" one i.e. Milan's build from sf.net. and try kuroshi P3 build as well.

Lemonzest

2nd March 2006, 01:46

how about a cvs all gcc 4.1.0 sse/sse2 build?

Egh

2nd March 2006, 02:41

how about a cvs all gcc 4.1.0 sse/sse2 build?

I second :goodpost:

But anyhow cvs is last updated on 27th of jan, so no newer features or bugfixes since then.

cc979

2nd March 2006, 04:08

I second :goodpost:

But anyhow cvs is last updated on 27th of jan, so no newer features or bugfixes since then.

just tried with gcc 4.1, no luck with the latest ffdshow cvs

LoRd_MuldeR

3rd March 2006, 23:28

ffdshow 2006-02-26 (http://www.free-codecs.com/FFDShow_download.htm) ;)

clsid

4th March 2006, 03:16

ffdshow 2006-02-26 (http://www.free-codecs.com/FFDShow_download.htm) ;)
The free-codecs .com site is bullshit. Latest CVS is still January 27th.

Egh

4th March 2006, 07:25

The free-codecs .com site is bullshit. Latest CVS is still January 27th.

they apparently put date of build, not actual CVS snapshot used, which is quite sensible.

ExtraEye

4th March 2006, 10:08

ah this build isn't very good for me. makes video and audio desync when i use the settings i had on my former ffdshow build.

Matrics

4th March 2006, 20:03

What you say about this page (http://www.paehl.com/open_source/?FFDSHOW)?

LoRd_MuldeR

5th March 2006, 14:00

ah this build isn't very good for me. makes video and audio desync when i use the settings i had on my former ffdshow build.

Same problem here!

Must be the audio-part of ffdshow that is broken in 2006-02-26 build, since I used CoreAVC for the video decoding...

cc979

5th March 2006, 16:48

looks like there's an offical pre-release of gcc 4.0.3 going to try it

http://www.mirrorservice.org/sites/sources.redhat.com/pub/gcc/prerelease-4.0.3-20060303/

haruhiko_yamagata

5th March 2006, 16:57

Hello. This is my first post.

For multi-thread resize support, I have modified swscaler(libmplayer.dll). Thank you for your thread I have succesfully build libmplayer.dll. It is fast on dual-core and working as far. I sent E-mail to milan cutka a week ago, waiting for the reply.

I tryed to build ffdshow.ax with MSVC 2003.net standard edition, which does not support optimize, I got very slow one. It looks like "simd.h" is not compiled to MMX.

Next, I tryed with GCC-MingW 4.0.3. ,which was very complicated thing to me. I struggled for 3 days and finaly got ffdshow.ax. It was faster than the former, but slower than build20051221 or 20060202.

Would you kindly guide me how to compile better?

I installed Direct X SDK February 2006. I am a beginner to MSYS+MingW.

My environmental variable
C_INCLUDE_PATH = CPLUS_INCLUDE_PATH = C:\mingw\include;C:\Program Files\Microsoft DirectX SDK (February 2006)\Include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include
LIBRARY_PATH = C:\MingW\lib;C:\Program Files\Microsoft DirectX SDK (February 2006)\Lib\x86

Please help me.

cc979

5th March 2006, 19:53

check this guide: compiling gcc for mingw

http://forum.doom9.org/showthread.php?t=108215

haruhiko_yamagata

6th March 2006, 12:44

Thank you, cc979.
I updated include files and library.

Oh shit, wrong was my code. I modified the code meant to be faster, but it was much slower. I could compile Original code poroperly, I think.

Thank you.

zilexa

8th March 2006, 21:48

I recently discovered FFDShow makes my CPU go crazy when playing 720p XViD, while I can play it
normally with lower CPU load using XViD codec instead of FFDShow.

Howcome?
Could this be because I use the version from the official ffdshow site (dates nov 2005)?
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow
So perhaps using a cpu specific build would solve it?

Egh

9th March 2006, 01:10

max-holz

17th March 2006, 15:35

I have compiled succesfully but I have problem during the creation of the installer, I got error from line 981 of the ffdshow.nsis2:

!insertmacro testcodec ffdshow XVID ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow DIV3 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow DIVX ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow DX50 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow MP43 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow MP42 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow MP41 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow WMV1 ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow wmv2 ${IDFF_MOVIE_LAVC} 0
!insertmacro testcodec ffdshow _3iv ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow mpg1 ${IDFF_MOVIE_LAVC} 0
!insertmacro testcodec ffdshow mpg2 ${IDFF_MOVIE_LAVC} 0
!insertmacro testcodec ffdshow h263 ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow h264 ${IDFF_MOVIE_LAVC} 1
!insertmacro testcodec ffdshow mjpg ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow dv ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow hfyu ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow png1 ${IDFF_MOVIE_LAVC} $R0
!insertmacro testcodec ffdshow rawv 1 0

Romario

21st March 2006, 17:21

What's going on, no FFDSHOW new build for a long time.

sillKotscha

21st March 2006, 17:43

What's going on, no FFDSHOW new build for a long time.

hey Dude,

I haven't read all of your posts but the last 2 I have seen (including this one) really sound a little bit too demanding respectively too disrespectful (http://forum.doom9.org/showpost.php?p=802855&postcount=4).

just my 0,02 €

celtic_druid

21st March 2006, 17:53

Must be related to Kostarum Rex Persia or something.

Egh

24th March 2006, 15:44

still wondering where Milan dissappeared ^^

videomixer9

24th March 2006, 22:21

prolly just not anymore in the mood for ffdshow development with all the stupid stuff about SMP etc. or busy with sth. else. Say bye bye to ffdshow, hehe :O

Egh

25th March 2006, 00:06

prolly just not anymore in the mood for ffdshow development with all the stupid stuff about SMP etc. or busy with sth. else. Say bye bye to ffdshow, hehe :O

bye to development, but not to ffdshow itself. I don't think in the nearest future anything superior to it appears. Yeah, CoreAVC might be better than ffdshow already, but that's commercial anyway. In terms of free software ffdshow might be on top for months to come.

Liisachan

25th March 2006, 01:00

Exactly, it was weird to see ffdshow was not in the list in the voting for 2006 Community Choice Awards.
maybe I will make some donation for ffdshow too anyway.
(I might have paid some money for CoreAVC too if it were free. It might be really nice free software...)

ExtraEye

25th March 2006, 23:30

does CoreAvc do everything ffdshow does? i mean post-processing, all the filters, etc?

dk75

25th March 2006, 23:46

No.
CoreAVC is H264 decoder only. Nothing less, nothing more.

videomixer9

26th March 2006, 00:09

Romario

26th March 2006, 00:35

i'd wish there was a clean directshow implementation for libavcodec, ffdshow has all the stupid junkfilters from mplayer and more implemented that are totally useless to me or maybe proper SSA/ASS support for libav players and them not just stopping playback when moving the window, having major crappy GUIs or other annoyances?

Well, ffdshow certainly have few bugs, but I like ffdshow very much.:) Full directshow implementation, however, sounds very good. But, we will see what Milan thinks about that.:(

Egh

26th March 2006, 02:41

i'd wish there was a clean directshow implementation for libavcodec, ffdshow has all the stupid junkfilters from mplayer and more implemented that are totally useless to me or maybe proper SSA/ASS support for libav players and them not just stopping playback when moving the window, having major crappy GUIs or other annoyances?

most filters in ffdshow are useless for most indeed, but you can just disable all of them. Lack of proper styled subs support is more concerning, I agree.

bob0r

30th March 2006, 02:01

19:34 yesterday ffdshow Commit by milan_cutka :: ffdshow/src/codecs/wmv9/ff_wmv9.vcproj:
don't require strmiids.lib #
18:32 yesterday ffdshow Commit by milan_cutka :: ffdshow/ (34 files in 14 dirs):
few 64-bit fixes #
18:25 yesterday ffdshow Commit by milan_cutka :: ffdshow/src/simd.h:
updated libmpeg2 #
18:22 yesterday ffdshow Commit by milan_cutka :: ffdshow/src/codecs/libmpeg2/libmpeg2/ (4 files):
updated libmpeg2

I wonder if he will look at the old bug reports...

breez

30th March 2006, 09:40

ff_wmv9.vcproj

There is a WMV9 decoder in works? Or what is it?

clsid

30th March 2006, 11:04

There is a WMV9 decoder in works? Or what is it?I think it is used for encoding WMV9.

videomixer9

30th March 2006, 11:35

there is a wmv9 decoder in ffdshow even for longer now, in the registry add under HKEY_CURRENT_USER\Software\GNU\ffdshow a value type REG_DWORD named "wmv3" and set it 1 to enable ffdshow wmv3 decoding, this worked for me with older versions. ffmpeg's wmv9 decoder isn't called wmv3 or wmv9 in their sourcetree, it was either vc1 or vc9 ...

Shapierian

30th March 2006, 23:07

I noticed that ffdshow still seems to build if you replace h264.c, h264idct.c and h264dsp_mmx.c with files from the latest ffmpeg. This may be useful for people looking for a quick update to ffdshow.

dk75

31st March 2006, 22:45

Or they could look at http://www.paehl.com/open_source/?FFDSHOW

videomixer9

31st March 2006, 23:22

prolly has only the updates from last cvs changes though, and that was no update to the libavcodec code. But beware, there is also h264 assembler code, last time I tried replacing the stuff it didn't work smoothly, but well maybe i should try again

I still wonder about the text describing ffdshow though nowadays ... DivX 6.1 decoder without postprocessing doesn't really use more cpu nowadays for me at least than ffdshow and also supports smp ...

max-holz

1st April 2006, 09:15

Where is possible to find a good tutorial how to build ffdshow and create the installer? Like the one that is present in the x264 compilation thread for eample.

videomixer9

2nd April 2006, 23:52

I tried updating the libavcodec code from ffdshow with new one from ffmpeg project and there were still a lot of problems, I then replaced quite some part in the ffmpeg code and used the ffdshow makefile for it with the original ffmpeg but there were always many linker errors in the end with missing links. Even just replacing the few parts about h264 failed.

Whatever I found out that GCC 4.1.1 produced a libavcodec that had a bit better performance than my old one ... lousy result of trying for hours how to fix up libavcodec for ffdshow ... but you also have to add skals code etc.

Negi

3rd April 2006, 01:44

Is milan the only coder on ffdshow?

videomixer9

3rd April 2006, 02:01

yes ... and he even though it is open source there seem to be some mysterious about some things, like there could be a patch or batches or notes about what to do to e.g. modify libavcodec ... but it's not like open source would mean that you get insides on anything without trying to figure it out all by yourself really. After all open source is usually well known for bad documentation upto none at all.

BoNz1

3rd April 2006, 02:11

CVS looks abandoned to me. However, there is some recent activity in the SVN (http://svn.sourceforge.net/viewcvs.cgi/ffdshow/)

Liisachan

3rd April 2006, 03:24

@BoNz1
Right... and what was stopped at Revision 2476 (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2476&sortby=date&view=rev) @ Jan 27 2006 restarted on Mar 29 2006 as Revision 2477 (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2477&sortby=date&view=rev), and since then updates have been quite frequent, several times a day; as of writing this, the newest one is Revision 2496 (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2496&sortby=date&view=rev)

Egh

3rd April 2006, 04:30

@BoNz1
and since then updates have been quite frequent, several times a day; as of writing this, the newest one is Revision 2496 (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2496&sortby=date&view=rev)

yet that last one happened about 16h ago already.

Plus most those revisions are quite marginal, mostly dealing with x64bit tweaks (changing data format definitions and such). Seems Milan was able to make ffvdub and ffvwf 64bit as well :) And, of course, updating libavcodec and libmpeg.

So can anyone try to build the project now? :P

Liisachan

3rd April 2006, 04:42

yet that last one happened about 16h ago already. Come on, milan has to sleep and eat and do real life too... When I said "updated several times a day" I didn't mean "evey 3 horus"...

Negi

3rd April 2006, 07:30

So milan took a 2-month leave? Good thing he's back on the job. I was getting worried that he'd abandon FFDSHOW. Thanks milan!

PatchWorKs

3rd April 2006, 11:20

So milan took a 2-month leave? Good thing he's back on the job. I was getting worried that he'd abandon FFDSHOW. Thanks milan!

I can't see the problem: isn't ffdshow open source ?
So, everyone can update it... :goodpost:

Negi

3rd April 2006, 22:09

Anyone can contribute to the CVS but an admin (milan) has to commit the patches. If someone wanted to continue it without milan, they'd have to fork it. I think. I could be wrong.

Egh

4th April 2006, 01:31

Come on, milan has to sleep and eat and do real life too... When I said "updated several times a day" I didn't mean "evey 3 horus"...

Yeah, I understand that. But, last change atm is 37 hours ago :) I was merely wondering if milan came back for a long time or just to do some quick fixes :)

Liisachan

4th April 2006, 15:09

i bet 'for a long time'
svn was updated again anyway (twice as of now)

videomixer9

4th April 2006, 15:40

updated libmpeg2 to 0.5.0, the rest is vs2005 project changes.

is there a page on CIA for SVN projects?

Liisachan

4th April 2006, 16:25

http://ffdshow.faireal.net/bakaupdates.php
^^;

LoRd_MuldeR

4th April 2006, 20:39

updated libmpeg2 to 0.5.0, the rest is vs2005 project changes.

is there a page on CIA for SVN projects?

This (http://cia.navi.cx/stats/project/ffdshow) one ???

videomixer9

4th April 2006, 21:06

amazing, suddenly also svn changes appear ... ? ... checked a while ago and it did show only cvs

Liisachan

5th April 2006, 01:21

true, that changelog had been stopped & I un-bookmarked it a few days ago. then it is alive again...

Egh

5th April 2006, 16:41

Good build :approved:

http://kurosu.free.fr/ffdshow-20060403-23H17-athlon.exe

Kuroshu is superior again:0 So far I don't have any problems with it (and yes, it uses latest SVN)

(well latest for 3rd april of course :P I think upto 2496 revision is included)

Shapierian

5th April 2006, 18:53

I noticed that for the Makefile based build systems -msse2 seems to be on by default. This seems kind of dangerous to me considering Athlon-xp doesn't support sse2. Am i missing anything?
Also why is -msse on but it is set to -march=i586? I don't thunk there are any 586 class cpus that support sse?

videomixer9

5th April 2006, 22:05

I usually replace this and used this here:

-D__SSE__ -D__MMX__ -O3 -ftree-vectorize -ffast-math -funsafe-math-optimizations -msse -m3dnow -mmmx -mfpmath=sse -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer -finline-functions -finline

and for others i get rid of the sse2 part as it otherwise would crash. Dunno about other ppls libavcodec etc. compiles. Dunno what milan thinks with those settings, but I think that it's made for general public, and the optimizations are runtime detected mostly anyways.

Egh

6th April 2006, 04:27

Updated build :approved:

Kuroshu r00x0r :P

http://kurosu.free.fr/ffdshow-20060405-21H28H42-athlon.exe

Kostarum Rex Persia

6th April 2006, 18:14

Updated build :approved:

Kuroshu r00x0r :P

http://kurosu.free.fr/ffdshow-20060405-21H28H42-athlon.exe

Please, post change log for that build.

Egh

7th April 2006, 00:27

Please, post change log for that build.

upto ffdshow SVN rev 2501, which is just one before the current one (2502, which apparently added "20 bit lpcm support" :confused:).

So, if you need, check http://cia.navi.cx/stats/project/ffdshow and see the entry named "new vs2005 projects configurations", that's the revision which was used for that last atm Kuroshu build.

P3 build (no SSE2 (?)) http://kurosu.free.fr/ffdshow-20060405-21H28H42-P3.exe

Athlon64 build (gcc+sse1+sse2)
http://kurosu.free.fr/ffdshow-20060405-21H28H42-k8.exe

max-holz

7th April 2006, 08:19

Is there any updated build for P4?

videomixer9

7th April 2006, 09:31

is this a game like "whoever has the most stupid question wins?" or are you ppl just way too lazy to just visit http://kurosu.free.fr/ffdshow.htm and check for yourself. Some people are just too much for me ...

magnusr

7th April 2006, 14:23

My athlon 64 x2 4200+ supports sse3 also.

But im sticking with the k8 version. Waiting for a athlon64 version with sse3 also then ^^.

videomixer9

7th April 2006, 15:09

libavcodec nor any of the other libs have sse3 optimizations, autovectorization in gcc is shit and most libs are written for it, so using intel compiler for the libs will give you autovectorization but make you lose most other optimizations. I guess you will see SSE3 once ffmpeg implements it fully, not much of a speedup though as it seems and mostly wasted time.

madman1980

7th April 2006, 17:48

Yeah, from what I've read there seems to be little if nothing to gain from SSE3 in this department..

Egh

7th April 2006, 19:04

atm iirc there's no point in SSE3 support in ffdshow.

I know very few filters in AVS which actually use SSE3. The difference between SSE1 and SSE2 is quite huge in terms of video processing, but SSE3 can hardly add much gain to that, imo.

Kostarum Rex Persia

7th April 2006, 19:21

Commit by milan_cutka :: r2504 /trunk/ (120 files in 22 dirs):

64-bit strides in x64 build #

Commit by milan_cutka :: r2503 /trunk/ (7 files in 4 dirs):

add "release unicode" configuration to vs 2003 solution,
compute ac3 and dts average bps only from valid frames

Very good, finally he add necessary 64-bit strides. So, someone can compile new build today.

foxyshadis

7th April 2006, 21:49

magnusr, even if ffdshow was optimized for sse3, a64 still executes sse2/3 as (roughly) multiple sse instructions anyway. :p

videomixer9

7th April 2006, 22:16

SSE, SSE2 and SSE3 are lousy instruction sets to begin with, the vector units in most x86 cpus are quite much of a joke. powerpc or ultrasparc have far better vector units ...

Rash

9th April 2006, 04:34

Humm, I think they've changed that. Apple showed some benchmarks and it seems P4 is really faster than PowerPC nowadays.

foxyshadis

9th April 2006, 04:59

Anyone can make up benchmarks that show that one processor is better than another, or vice versa, depending on what tests you choose or how optimized the software (and underlying libraries) is for the instruction sets. That has nothing to do with the sanity and ease of programming for them, and x86 is a boar. Even x64 is only marginally better (much less named register pressure).

ckjnigel

11th April 2006, 08:06

I just watched a high quality XviD encode with
ffdshow-20060407-19H04-k8.exe
and that's the first time ever that ffdshow rendering seemed a tad better than what I get using whatever is Koepi's latest XviD.
I'm on Win x64 -- a 3.3+ GHz 64-bit-enabled Sempron with an nVidia 6600GT.
Thanks, kurosu!

videomixer9

11th April 2006, 08:31

first ... 3300+ doesn't mean the CPU has 3.3 GHZ, not even near. Second, that build is for Athlon 64, but it's no x64 compile.

Shirokuu

11th April 2006, 09:07

Vm9, he just means he has a 3.3 Ghz EQUIVALENT Sempron. No need to moan about that.

videomixer9

11th April 2006, 11:17

not sure about that, plenty of people think the ratings are equal to mhz. Also the rating was measured in comparision to other CPUs performances, for a while it was the thunderbird, I think AMD changed that though. So saying it's a 3.3 ghz equal, and especially as it is a Sempron I wouldn't count on that comparing to Intel CPUs e.g.

LigH

12th April 2006, 04:32

:(

Most happy people out there get their well optimized build for their current CPUs.

Only very few have to stick with older, but not too optimized (or "generic") builds (having a CPU that supports MMX and ISSE only) until milan may publish the next one...
__

But in general, good to see that some people are interested in keeping this project up-to-date. Well done, go on!

:thanks:

videomixer9

13th April 2006, 10:13

there are plenty of builds optimized for MMX and SSE only, many of them though also for 3dNow! as Athlon-XP e.g. has MMX/SSE and 3dnow. And if you got an Intel CPU you're alone out there as most it seems that most computer nerds and encoding folks have AMD. At least in my little world of people not buying crappy complete PCs from Intel-blackmailed companies like Dell. Other than that P3 optimized builds should also have SSE ...

Besides clsid's build of rev 2405 should be MMX only. Nothing changed since then. We're still at rv. 2405, and if you don't even have MMX I don't think you have a PC that can really decode modern videos ...

Optimization is kinda useless anyways as GCC doesn't do much of a vectorization, it's just hand optimized code in libavcodec that can adjust to anything really. So optimized builds for any CPU are kinda overkill anyways. Most speed is gained simply by using compiler that produce better code. Thus newer GCC usually mean a tad more speed, only Intel Compiler can do proper and good vectorization, GCC verbose mode on this still finds way less parts that can be optimized. ICL also has the bonus that it can produce code optimized for any CPU into a single binary. You just have to enable them all with /Qax, I'm still waiting for GCC to do this, along with automatic vectorization you would have larger ffdshow binaries, but universal ones. However, libavcodec can make use of all units like SSE/SSE2/MMX etc. without optimization switches while compiling, just like mplayer can with automatic detection (the reason to optimize is that there's other things than just libavcodec involved).

celtic_druid

13th April 2006, 11:47

Actually on my poll currently it is
Intel Pentium 4: 655
AMD Athlon-XP/MP: 326
AMD K8 (Opteron, Athlon64, Athlon-fx): 301
Even if you combine the XP's and 64's the P4 is still infront.

LoRd_MuldeR

13th April 2006, 12:32

:(

Most happy people out there get their well optimized build for their current CPUs.

Only very few have to stick with older, but not too optimized (or "generic") builds (having a CPU that supports MMX and ISSE only) until milan may publish the next one...

There are checkboxes in ffdshow to disable CPU features like SSE2 or 3DNow!. Don't know if they have any effect in optimized builds, but have you tried to simply disable the features not supported by your CPU ???

videomixer9

13th April 2006, 17:11

Question is, were those poll participants just viewers or just the random turds happily buying intel as they love shitty core design. Or maybe it's just that my surrounding on irc etc. has too many AMD users ... only Intel users are usually people that buy complete boxes.

bob0r

13th April 2006, 17:28

filename: ffdshow-20060413-gcc4.0.3-sse-x264.nl.exe
url: http://x264.nl

sse2 version: http://files.x264.nl/ffdshow/ffdshow-20060413-gcc4.0.3-sse2-x264.nl.exe

LoRd_MuldeR

13th April 2006, 17:37

filename: ffdshow-20060413-gcc4.0.3-sse-x264.nl.exe
url: http://x264.nl

Seems to work fine here. Thx.

videomixer9

13th April 2006, 18:02

Negi

13th April 2006, 19:35

filename: ffdshow-20060413-gcc4.0.3-sse-x264.nl.exe
url: http://x264.nl

sse2 version: http://files.x264.nl/ffdshow/ffdshow-20060413-gcc4.0.3-sse2-x264.nl.exe

The SSE2 version breaks on WMV3 (WM9) (decoding it or just running it through uncompressed) with vmr9 while the plain SSE build doesn't.

Athlon 64 3200+ socket 754
Windows XP SP2
DirectX9
Media Player classic with all internal filters off.

Egh

13th April 2006, 19:36

What is strange with all these compiles is the sound libs ... you can hear a difference in kurosu's athlon compile and this one with all gcc. It's seems that compiling can somehow affect decoding precision and quality, I managed to compile libmad e.g. in a way that channels got swapped O_O Or maybe i'm imagining things ...

first kuroshu is all gcc as well iirc, just 3 different versions used to build a whole package :P

As for sound, what sounds better and with what codecs? vorbis i suppose? tremor or libavc?

Shapierian

13th April 2006, 20:07

filename: ffdshow-20060413-gcc4.0.3-sse-x264.nl.exe
url: http://x264.nl

sse2 version: http://files.x264.nl/ffdshow/ffdshow-20060413-gcc4.0.3-sse2-x264.nl.exe

Are these with low accuracy tremor?

bob0r

13th April 2006, 21:40

@Negi
Submit bugs @ ffdshow project:
http://sourceforge.net/tracker/?group_id=53761&atid=471489

@Shapierian
Test and find out.... i compile ffdshow direct via ffdshow/src > make.
I add only directx stuff, i do not edit anything.

celtic_druid

13th April 2006, 21:56

Unless things have changed, you have got low accuracy. You need to edit ogg_os.h or whatever it is.

breez

13th April 2006, 22:41

Is there anything wrong with using libavcodec for Vorbis? Any practical difference to tremor (when not in low accuracy mode)?

videomixer9

13th April 2006, 23:14

iirc I wanted to fix this in ffdshow when compiling but it wasn't defined. Not sure.

Liisachan

14th April 2006, 06:35

Is there anything wrong with using libavcodec for Vorbis? Any practical difference to tremor (when not in low accuracy mode)?
Using livavcodec for decoding vorbis is ok.

The problem, if anything, is:
(0) Many of those evil codec packs use ffdshow to decode vorbis without thinking carefully.
(1) If vorbis decoding is enabled while installing ffdshow, the default decoder which will be used will be tremor.
(2) Playing vorbis, he or she will then feel "Hmm, Ogg Vorbis is not as high-quality as they say... it's even noisy... vorbis sucks..."

That's not "my" problem, but I don't want to see that happening.

celtic_druid

14th April 2006, 08:00

So perhaps changing:

!insertmacro testcodec ffdshow_audio VORBIS ${IDFF_MOVIE_TREMOR} 0

to:

!insertmacro testcodec ffdshow_audio VORBIS ${IDFF_MOVIE_LAVC} 0

would work better?

Liisachan

14th April 2006, 10:15

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.

dimzon

14th April 2006, 10:43

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.
Agreed 100%

Egh

19th April 2006, 00:18

g00d :) Milan actually now even corrects bugs from time to time:P

But i don't recall anyone recently reporting this one:

Revision 2506 - Directory Listing
Modified Tue Apr 18 19:20:55 2006 UTC (3 hours, 51 minutes ago) by milan_cutka
fixed mplayerc crash on exit when audio OSD enabled

haruhiko_yamagata

19th April 2006, 13:12

I uploaded a patch to support multithreading of video playback. Please test.

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

Egh

20th April 2006, 15:24

Lots of updates recently to ffdshow SVN, including updated x264 and libavcodec. So maybe time for a new build? :P

bob0r

20th April 2006, 17:03

SSE: http://x264.nl
SSE2: http://files.x264.nl/ffdshow

Slave01

20th April 2006, 17:43

CEC

20th April 2006, 20:38

haruhiko_yamagata

20th April 2006, 23:43

Egh

21st April 2006, 01:57

Many people use ffdshow lanczos resize to obtain better quality expecially on great displays. However unfortunately this ffdshow resize eats great cpu so why don't put a shader window like media player classic in which insert small shaders to be executed by graphics card? Is this possible?

a) This question is old and at least on bugtracker Milan already responded to that. No, ffdshow is NOT a video renderer per se, thus currently it doesn't have access to shaders.

b) Can't you use Haali renderer with proper bicubic resizer? The difference between lancz and bicubic (with proper adjustment) is quite marginal in many cases. Haali renderer does entirely shaders-based resizing.

c) On my FX5500 and Athlon XP (with just SSE1 !) lanc resizing in software is considerably faster than bicubic in hardware. I dont' haver trouble playing 720p videos and applying lanczos to them (just xvid though, not h264 :P). Thus on anything less than some good 6xxxx or better ge-force the speed in hardware will still be worse compared to CPU-based one.

foxyshadis

21st April 2006, 02:01

bob0r, would it be possible to make a build with that patch included? I'd like to give it a workover but I can never get ffdshow to compile properly.

Rash

21st April 2006, 03:57

Thanks b0bor, your builds are great. ;)

Egh

21st April 2006, 04:34

Thanks b0bor, your builds are great. ;)

Kurosu counter-released though :P

April 16
* Using accuracy over speed for tremor and libmad (not tested whether that matters, but ffdshow always report low accuracy mode - code shows it's hard coded)
* Patching source whenever possible; modify FPATCHES in update.cfg

So is it higher accuracy now for vorbis decoding by tremor in this kurosu build or not? :confused:

And what kind of patches were applied?

of course his builds are available at http://kurosu.free.fr/ffdshow.htm for those who still don't know :P I use sse1 only http://kurosu.free.fr/ffdshow-20060420-14H04-athlon.exe

bob0r

21st April 2006, 08:52

bob0r, would it be possible to make a build with that patch included? I'd like to give it a workover but I can never get ffdshow to compile properly.

gcc -c -I. -I.. -I../imgFilters -Ilibvo -w -ffast-math -mno-cygwin -mdll -mthreads -pipe -DNDEBUG -UDEBUG -DWIN32 -D_WIN32 -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline-functions -finline -o postproc/swscale.o postproc/swscale.c
postproc/swscale.c:80:30: error: swscale_multicpu.h: No such file or directory
make[1]: *** [postproc/swscale.o] Error 1
make[1]: Leaving directory `/home/user/ffdshow_gcc_mt/src/mplayer'
make: *** [../bin/libmplayer.dll] Error 2

http://google.com/search?q=swscale_multicpu.h
Your search - swscale_multicpu.h - did not match any documents.

Doh!

issa

21st April 2006, 09:04

SVN REV.2523 Build with gcc 4.1.1 (20060421), please test it to see if the gcc 4.1 produce faster code.

SSE: ffdshow-20060421-gcc-4.1.1-sse.exe (http://rapidshare.de/files/18549439/ffdshow-20060421-gcc-4.1.1-sse.exe.html)
SSE2: ffdshow-20060421-gcc-4.1.1-see2.exe (http://rapidshare.de/files/18549758/ffdshow-20060421-gcc-4.1.1-see2.exe.html)

The following build compiled with auto vectorize turn on,

SSE: ffdshow-20060421-gcc-4.1.1-sse-vectorize.exe (http://rapidshare.de/files/18554087/ffdshow-20060421-gcc-4.1.1-sse-vectorize.exe.html) [vectorize information log (http://rapidshare.de/files/18554177/vect.sse.7z.html)]
SSE2: ffdshow-20060421-gcc-4.1.1-sse2-vectorize.exe (http://rapidshare.de/files/18550046/ffdshow-20060421-gcc-4.1.1-sse2-vectorize.exe.html) [vectorize information log (http://rapidshare.de/files/18575684/vect.sse2.7z.html)]

Please someone give it a try, and test to see if the auto vectorize break any part of the ffdshow.

videomixer9

21st April 2006, 09:42

As ICL GCC can tell you when it does vecotrization, would've been nice to have the compile logs for this build to see if it actually vectorized something useful, last GCC 4.1.1 build from march had horrible auto vectorization. Cannot test yours, don't have SSE2. I only noticed that TomsMoComp and KernelDeint dramatically increased compile time with auto vectorization on.

ExtraEye

21st April 2006, 10:29

SSE: http://x264.nl
SSE2: http://files.x264.nl/ffdshow

bob0r for me your build doesn't run mpg, only avi.
changing to libavcodec makes it run again but libmpeg doesn't work as far as can tell.

im using the sse2 version if it matters.

EDIT: same happens with issa's vectorize build. im trying the vectorize off version to see if it has anything to do with it.

videomixer9

21st April 2006, 13:21

thanks issa, as i can see from the log there wasn't much vectorization done. I hoped for some advance in the vectorization stuff for this new version of gcc 4.1.1. Intel Compiler still vectorizes much more successful.

Other than that it is like the time I tried the -ftree-vectorize switch, the decoder doesn't really crash, but it just doesn't work. It builds the graph several times and fails and then falls back to another decoder or none.

So the vectorized build is unusable.

foxyshadis

21st April 2006, 14:29

Drat about the SMP. It isn't in my MSVC either, so maybe it's ICL.

Vectorized SSE2 runs fine on mine. Core Duo, XP SP2, latest MPC. (And I did ensure that it's actually ffdshow doing the decoding.) I have no idea how useful it actually is, though, haven't benchmarked anything. Except wma audio, which I causes a crash every time. (Not sure if it's 7, 8, or 9.)

libmpeg is totally broken, but is there a compelling quality or speed reason to use it? Since it seems to break every other compile I've always left it on lavc.

haruhiko_yamagata

21st April 2006, 15:55

Hello foxyshadis and bob0r.
Thank you for testing and report.
I'm very sorry. It was a terrible mistake.
I uploaded the fixed version.

ExtraEye

21st April 2006, 16:23

libmpeg is totally broken, but is there a compelling quality or speed reason to use it? Since it seems to break every other compile I've always left it on lavc.
from my perspective there is. and a pretty big one.
i use zoom player and i use it to remember the last place i got to on the file im watching (like - closing the movie on 31:20, and when loading it again it starts from 31:20).
when using that option with libavcodec, the player crashes. with libmpeg it doesn't.
it's true that it's not rare for builds to have broken versions of libmpeg but that's just a reason not to move to them.
right now i changed back to "ffdshow-svn2503-20060407-unicode" build and it works so if you want look for it somewhere on this thread.

bob0r

21st April 2006, 18:44

used patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

SSE and SSE2: http://files.x264.nl/ffdshow/ look for -mt- in the filenames.

ExtraEye

21st April 2006, 18:54

works for me except for the problem with libmpeg2 already mentioned before

foxyshadis

21st April 2006, 20:49

Hmm, I've been pushing it as hard as I could (surprisingly difficult!), resizing, enabling many different filters & avisynth plugins, and it just refuses to use more than 50% cpu, even when it's stuttering. I used "ffdshow-20060421-gcc4.0.3-sse2-mt-x264.nl.exe".

igor1st

21st April 2006, 21:13

works for me except for the problem with libmpeg2 already mentioned before
I made quick test today for using ffdshow with dvd-video (it crashs on navigating menu year ago).

MPC rev592, ffdshow rev2523 (bob0r sse build).
libmpeg2 with selected "DVD decoding" works almost perfectly.
libavcodec as a decoder didn't work properly at all in this case.

haruhiko_yamagata

22nd April 2006, 01:22

Thank you, bob0r.
As foxyshadirs said, it seems multithreading is not used in the build.
I checked out svn newly, applyed the patch, and just typed make for gcc 4.0.3 on MSYS and created an instraller. No problem found.
I use directX9 header and library.

TheShadowRunner

22nd April 2006, 04:28

Hey all, I have a bug to report for :
http://kurosu.free.fr/ffdshow-20060420-14H04-P3.exe
Each time i open a video with "Subtitles" > "Vobsub" enabled it crashes the player (upon exit for WMP or as soon as the video starts with Zoom Player).
Previous build didn't have this bug.
Later,

TSR

haruhiko_yamagata

22nd April 2006, 10:33

Hello, bob0r.

I found ffdshow-20060421-gcc4[1].0.3-sse-mt-x264.nl.exe
works on multi-thread.

foxyshadis

22nd April 2006, 11:43

Yep, I can confirm SSE/MT works (should have tried that one too). It maxed out around 75%, could be because of using limitedsharpenfaster or just some combination of filters that aren't multithreaded yet. But at least it works! Horray!

haruhiko_yamagata

22nd April 2006, 12:28

Originally Posted by foxyshadis
Yep, I can confirm SSE/MT works (should have tried that one too). It maxed out around 75%, could be because of using limitedsharpenfaster or just some combination of filters that aren't multithreaded yet. But at least it works! Horray!

Thank you for testing.
Ok it works. I feel relieved.
Go beyond 75% is difficult because threads depend each other. Optimization is required for scenarios used by many people.

bob0r

22nd April 2006, 18:06

LOL, you both missed the "look for -mt- in the filenames." part :)

Very good, because i was sure i did everything right.

Now lets see what Milan thinks of it eh? :cool:

Liisachan

22nd April 2006, 19:03

LOL, you both missed the "look for -mt- in the filenames." part :) What do you mean? You made -sse2-mt- and -sse-mt- and apparantly the only -sse-mt- works.

Now lets see what Milan thinks of it eh? :cool: I see no reason not to merge... If the patch makes it faster even by .5% it's really precious :D

foxyshadis

22nd April 2006, 19:07

LOL, you both missed the "look for -mt- in the filenames." part :)
I used "ffdshow-20060421-gcc4.0.3-sse2-mt-x264.nl.exe".
???

I'm sure that's the one I used, since I tried to redownload it and reinstall it when it didn't spill over 1 cpu, just in case I had screwed up and used the wrong one. Blargh.

JarrettH

23rd April 2006, 05:22

what is auto vectorize? :devil:

JarrettH

23rd April 2006, 06:21

is there something i have to do to enable multithreading in the ffdshow options? mine never goes above 50%

also...

these latest SSE2 builds (13th, 20th) crash Media Player Classic and Got All Media when I try to use my image settings. the SSE versions work fine though

Liisachan

23rd April 2006, 06:59

is there something i have to do to enable multithreading in the ffdshow options? mine never goes above 50% It is supposed to work automatically.

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

2. Configuration

There is no configuration to stop multithreading
currently. If your CPU is single core and non hyper-
threading, multithreading is avoided.

zilexa

23rd April 2006, 15:05

Just wanted to say, THANK YOU KUROSU for creating (and maintaining)
THE ffdshow downloadpage... (http://kurosu.free.fr/ffdshow)
It is the only website I found listing the CPU-specific Ffdshow builds so clearly!
_______________________________________________

Do have one q: Can't there be just 4 builds?
instead of:# Build Athlon XP (has 3DNow, SSE1 but no SSE2), 20060420-14H04 (3826 KB)
# Build Pentium4 (has SSE1 and SSE2), 20060420-14H04 (3644 KB)
# Build Pentium 3 (only has SSE1), 20060420-14H04 (3994 KB)
# Build Prescott (has from SSE1 up to SSE3), 20060420-14H04 (3680 KB)
# Build Athlon 64 (has 3DNow, SSE1 and SSE2), 20060420-14H04 (3843 KB)for AMD:

3dNow! & SSE1
3dNow! & SSE & SSE2

for INTEL:

SSE1
SSE1 & SSE2

--> Why is there a build for Prescott? ffdshow doesn't use sse3.
And couldn't there be just 1 build? One build with 3dNow! & SSE1 & SSE2 if it would be used on AthlonXP then the SSE2 optimizations would not be used. If it would be used on a Pentium, 3dNow! wouldn't be used, if it would be used on a P3 only SSE1 would be used.
Seems more logical to me :)