New ffdshow build (?)

[videomixer9]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

[Flexy]

http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html


Bug Fixed:
Huffyuv,Vorbis/libavcodec.dll.
Please test h264/libavcodec.dll decoder.

looks all good here extcept that in the vfw-encoder section the "wmv" entries still only say "W" or "I". No problems with huffyuv or h264.

[Flexy]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

looks good. Can even read wmv3 now :)

Please note i do very quick and dirty testing...right now only short encoding runs huffyuv...and then install/uninstall and checking my codecs.

Oh yeah...ffdshow.ax was locked again here - otherwise this looks very good to me especially with the wmv3 support. No problem with Huffyuv. ALso, the vfw/encoder drop-down list looks all right.


I dont know...but i assume this stuff works only when you dont enable SSE optimizations for libavcodec, right ?

[videomixer9]

Well no fancy optimization stuff for the kids that are always crying cause they need optimized pseudo-speed :P No fancy optimizations = no fancy crashing for no reason.

Reading 2ch.net especially japanese are the super optimization trolls, I think I'll just retag a generic build as Core2 Duo build and they go droll days over it even though Intel Compiler 9.1.028 got Core2 Duo optimizer now ;P However pretty senseless as libavcodec cannot be really compiled again with ICL and I doubt it gives really more speed. And what's the optimizations worth if everybody comes back crying that it's unstable.

Btw. I love this bullshit about generic builds having SSE or whatever disabled, that is plain bullshit. ffdshow libavcodec will always use automatic CPU detection whatever parameters you will specify on compiletime and it will use 3dnow or SSE, MMX etc. assembler optimized routines if available. It'll just not have useless routines use SSE. As I explained earlier almost only useless stuff is vectorized by Intel Compiler or GCC autovectorizes, and without vectorization that code is even more worthless to gain speed. E.g. the most useless parts of the sound mixing in ffdshow is vectorized in the most useless parts, loops that are only to check GUI elements are vectorized and other stuff. That's just useless and also results in them breaking.

Besides I doubt that using SSE all the time for anything speeds things up, rather it will probably slow it down as everything is getting stuffed with SSE while the regular execution units got nothing to do.

As seen almost all errors that appear are related to these instruction sets being made of use of for the most idiotic stuff. I guess it's time to do as Dirk Paehl and declare all generic builds as "runtime cpu detection" build, as that is what libavcodec and many other filters do.

And also you can build non-SSE needing builds with MingW properly, the only thing will probably be libdts or liba52 crashing as milan enabled sse2 in the makefiles per default there iirc or whatever else it was.

[_xxl]

It seems to me that generic builds are the fastest and stable!
Maybe we can test to see the difference between a generic libavcodec.dll and SSE(SSE2) one?
There is no need to compile SSE(SSE2) versions of libavcodec.dll?
Some new speed tests between builds are welcome!

[videomixer9]

Just go ahead and test it on a SSE2 CPU. I doubt there'll be any major difference except for some minor test fluctations you always get.

[clsid]

I already made a test build containing several different libavcodec.dll compilations. Difference between fastest and slowest was very small, less than 3%.

Changing -march=i586 to -march=i686 in makefile_c.inc gives a 2% performance boost on my (old) system. So that could be added to SVN.

[videomixer9]

did this stay like that around multiple tests? timeCodec.exe e.g. can vary quite a bit depending on the surrounding apps running and also on caching that may be used the second time you test a file. Other than you could have SVN access if you had an SF account, or do you have one?

But oh well as said the general thing is that there's not much profit with special versions.

[_xxl]

Generic ffdshow build:
http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html
Tested h264/libavcodec decoder.
generic:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 63.3
mmx,sse:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.5, dfps: 63.1
mmx,3dnow,sse,387:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 62.7
Video Sample:
bbc_m420p.mp4
http://rapidshare.de/files/28813683/bbc_m420p.mp4.html

[videomixer9]

getting worse haha :P

[clsid]

did this stay like that around multiple tests? timeCodec.exe e.g. can vary quite a bit depending on the surrounding apps running and also on caching that may be used the second time you test a file.Yes, I did multiple timecodec runs with each build.

[MatMaul]

Generic ffdshow build:
http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html
Tested h264/libavcodec decoder.
generic:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 63.3
mmx,sse:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.5, dfps: 63.1
mmx,3dnow,sse,387:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 62.7
Sample:
bbc_m420p.mp4

what flags do you use for generic build please ?

[_xxl]

Generic:
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions
mmx,sse:
gcc -c -O3 -march=i586 -mtune=i686 -mmmx -msse -mfpmath=sse -fomit-frame-pointer -finline -finline-functions
mmx,3dnow,sse,387:
gcc -c -O3 -march=i586 -mtune=i686 -mmmx -m3dnow -msse -mfpmath=sse,387 -fomit-frame-pointer -finline -finline-functions

[MatMaul]

thanks

[Flexy]

looks good. Can even read wmv3 now :)

Please note i do very quick and dirty testing...right now only short encoding runs huffyuv...and then install/uninstall and checking my codecs.

Oh yeah...ffdshow.ax was locked again here - otherwise this looks very good to me especially with the wmv3 support. No problem with Huffyuv. ALso, the vfw/encoder drop-down list looks all right.


I dont know...but i assume this stuff works only when you dont enable SSE optimizations for libavcodec, right ?


VM9, i think i judged too quick.

The above still stands...but i discovered crashes when i use the *external* X264 codec....i also had some problems with Koepi's Xvid.

I am now back to the one yamagata build and i haven't seen any of those problems.

Also...well hell yeah you're all right, SSE, SSE2 *sounds* all great but it's worthless if it dont work..then better generic and relabel it whatever....at least as long as everything works :)

ReCap, from *my* quick testing...what has to be looked at is installer/uninstaller (codecs) {which i think is fixed now).....libacvodec especially HuffyUV, H264....AND external ones like X264/Xvid. (This just from what i looked at)

[videomixer9]

so what does ffdshow have to do with x264 or xvid? nothing really ... looks more like another bs problem related to something else. And not that "i had problems" is some useful info too. I wonder why people think that others are magic mind readers.

Besides I got a nice error report elsewhere to by some guy who overclocked his CPU which is really useful if you want to aritifically make many things crash especially with FSB overclocking. Don't even dare to report me video corruptions or anything with overclocked broken hardware :P

And HuffVuy might be broken because of the libavcodec updates the haruhiko build doesn't have ... don't compare apples with eggs :P Would be better to test builds that feature these updates too and also get sure it's not the avi splitter that crashes, gabest one might easier crash then ms or haali do as I noticed for this earlier when i captured stuff from analog input.

And also not that huffyuv may decode slowly or eating very much cpu on playback (though that's the ff variant mostly) and framedrop function may crash it, or even the output queue sampling depending on the footage. That said everything works fine for me on that.

[Flexy]

so what does ffdshow have to do with x264 or xvid? nothing really ... looks more like another bs problem related to something else. And not that "i had problems" is some useful info too. I wonder why people think that others are magic mind readers.

Besides I got a nice error report elsewhere to by some guy who overclocked his CPU which is really useful if you want to aritifically make many things crash especially with FSB overclocking. Don't even dare to report me video corruptions or anything with overclocked broken hardware :P

And HuffVuy might be broken because of the libavcodec updates the haruhiko build doesn't have ... don't compare apples with eggs :P Would be better to test builds that feature these updates too and also get sure it's not the avi splitter that crashes, gabest one might easier crash then ms or haali do as I noticed for this earlier when i captured stuff from analog input.

And also not that huffyuv may decode slowly or eating very much cpu on playback (though that's the ff variant mostly) and framedrop function may crash it, or even the output queue sampling depending on the footage. That said everything works fine for me on that.


i am aware that external xvid or x264 basically has not much to do with ffdshow...although it might be interesting to know that with some builds the external codecs work...and with others they dont. It's not that i deliberately try to blame errors on sepcific builds...i am just reporting what's happening :)

As it is i the external codecs are the same since nothing gets changed....EXCEPT ffdshow....so if the calls dont work...its *likely* it's something with ffdshow ?!

[foxyshadis]

A good bug report indicates the software you're using (eg, vdub), the action you're making (encoding, decoding, playing), the video format, the exact build used, and the crash message if any. vdub is great, puts together this spiffy text file for you and everything.

If you're getting a crash in vfw it may be related to the recent vfw patches, but it might be something entirely different.

[Egh]

New build from VM9 seems to be good:

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

At least fixes previously reported crashes in vdub for me.

P.S. I wonder why there's no date for each build on ffdshow-tryout download page :)

[thuan]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download
This build crash when playing vorbis audio (in ogm, mkv, ogg audio only too) with libavcodec, tremor is fine.

[foxyshadis]

Yeah, and it's in some of the new assembly code just added to ffmpeg. Non-asm builds aren't susceptible. Unfortunately I don't know how to debug with gdb - not to mention the interface is classic 1970's terminal emulation, so I don't really care to try.

[_xxl]

careful with drevil_xxl autodetect builds, it deleted all my FFDShow config... uguu <_<
Bug fixed.

Installed it...did some tests. Loaded *any* video and then used the ffdshow builtin Huffyuv to decode. First run looked ok, second time i seletcted a part of the video and tried to encode (save as avi) with ffdshow/huffyuv again and vdub crashed. Tried again to encode the whole movie (because i thought it might only happen when i select a section)...but crashed again.
Uninstalled ffdshow and...BOOM ! I have the proof here, guys :(
Bugs fixed.
Vorbis/libavcodec bug fixed.
Added an option (defaulting to no):
Don't use ffdshow in WMP9 & Windows Explorer.
Autodetecting best optimizations:
http://rapidshare.de/files/28868885/FFdshow-20060810-rev2546.exe.html
Inno Setup:
http://rapidshare.de/files/28871336/inno.rar.html

[Peuj]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

I still have the issue http://forum.doom9.org/showthread.php?p=860774#post860774

and on some video like this one http://www.megaupload.com/?d=7BURSN0S the image freeze like if I have 100% CPU usage and I don't have this problem with wm3 disabled.

Thanks

[MatMaul]

I still have the issue http://forum.doom9.org/showthread.php?p=860774#post860774

and on some video like this one http://www.megaupload.com/?d=7BURSN0S the image freeze like if I have 100% CPU usage and I don't have this problem with wm3 disabled.

Thanks

Actually wmv3 decoder isn't finished and the developpement of this decoder is related to ffmpeg project.

So please report your bug at the mailing list of ffmpeg, ffmpeg-devel@mplayerhq.hu (archives of this mailing list (http://archives.free.net.ph/list/ffmpeg-devel.en.html))

[Peuj]

Actually wmv3 decoder isn't finished and the developpement of this decoder is related to ffmpeg project.

So please report your bug at the mailing list of ffmpeg, ffmpeg-devel@mplayerhq.hu (archives of this mailing list (http://archives.free.net.ph/list/ffmpeg-devel.en.html))

ok thanks

[MatMaul]

please wait 1h please before report, I download and test your samples with vlc to be sure it's ffmpeg related.

edit : you can report for the jeuxvideo.fr sample, I have the same color problem with vlc.

Your second sample (warhammer.wmv) works good (but it's slow) with vlc and ffdshow on my computer.
I think your computer is too old to decode wmv3 720p video with ffmpeg decoder (ffmpeg wmv3 decoder is actually slower than microsoft wmv3 decoder)

[MacAddict]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?

[clsid]

ffdshow_rev2546_t63_20060812.exe (http://rapidshare.de/files/29155628/ffdshow_rev2546_t63_20060812.exe.html)

Automatically uses MMX, MMXExt, SSE, SSE2, SSE3, SSE4, 3DNow! and 3DNow!2 SIMD instructions when available and supported*. :devil:

In other words a generic build, which means it is as stable as the source code allows it to be. Has decoding performance comparable to so-called optimized builds, which are usually unstable.

[multiblitz]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?
Yes, I de-istalled th 3008 version, even though I would loved to have the exact rounding. It crashed immediately if you wanted to jump in ZP by clicking on the bar in ZP

[haruhiko_yamagata]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?
One of the bugs of swscaler was fixed at rev 52. Please try ffdshow-tryouts-rev60.exe or newer.
At rev 63, I posted long life worker thread of swscaler.

[thuan]

Has the libavcodec vorbis decoder problem solved yet in t63? I guess not looking at the changelog.

[MacAddict]

One of the bugs of swscaler was fixed at rev 52. Please try ffdshow-tryouts-rev60.exe or newer.
At rev 63, I posted long life worker thread of swscaler.
Thanks for the fix:) I'm happy to report that clsid's new 't63' build works wonderful now with resizing.

One thing I noticed though and I'm not sure if it's expected or not is that the CPU usage almost doubles when resizing is set to 720x480 compared to just resizing to 640x480. So 640x480 is averaging about 28% CPU usage while 720x480 is averaging almost 50% CPU time. Is this expected?

[haruhiko_yamagata]

Thanks for the fix:) I'm happy to report that clsid's new 't63' build works wonderful now with resizing.

One thing I noticed though and I'm not sure if it's expected or not is that the CPU usage almost doubles when resizing is set to 720x480 compared to just resizing to 640x480. So 640x480 is averaging about 28% CPU usage while 720x480 is averaging almost 50% CPU time. Is this expected?
No, it's not expected. I have no idea why...:confused:

[Facct]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?

I'm afraid I can't really help pinpoint the problem It was a few weeks ago now so I don't remember the specifics and I've gone through all the recent July builds pretty much without keeping track.

I tried first VM9's build: possibly 20060711 which caused some problems crashing on certain scripts (lancszos4 resize before limitedsharpen) but only some variations, I tried then XXL's which I remember having more success with but still crashing.

I think it was either this or the next build (ver # I dont recall, possibly 20062207, but was VM9's build) which i noticed resizing wasn't working, and it was also one of these where I lost all the codecs. I tried the 29/07 builds (VM9 and Q, I think XXL too) and then the 30/07 VM9 but still always had the same problems with crashing: as soon as I pressed play zoomplayer would hang, but not always - sometimes the exact same configuration would work on different times. And if it crashed once (say using a 'bad' configuration), it would always crash even when using a previously working preset, unless I rebooted, but this also didn't always fixed it. As far as I could tell in my limited testing it was quite random and I gave up in frustration and went back to 20060530 (iirc this is VM9's build) which I don't recall whether or not I ever tested, but the multithreading performance is great, I can watch DVD's with See-Saw & LimitedSharpen & Lanczos4 1920x1080 resize.

[_xxl]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?
1).PLEASE make detailed, accurate bug report.
2).Please tell us:
a).the system type(CPU,MB,Ram...)
b).the exact version of ffdshow(generic,sse,sse2)
c).the options given when ffdshow was configured
d).media player,ax filters,video sample...

[Flexy]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?



not sure..just guessing according what drevil said. First, create a new windows restore point for the current date.

You can restore your system with the system restore utilty in XP to an earlier date (where everything worked)...and export the following path from that old registry:

backup:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]

Then restore your system back to the current date...and import/merge those back.

That's what i would try.

[Px]

ffdshow_rev2546_t63_20060812.exe (http://rapidshare.de/files/29155628/ffdshow_rev2546_t63_20060812.exe.html)

Automatically uses MMX, MMXExt, SSE, SSE2, SSE3, SSE4, 3DNow! and 3DNow!2 SIMD instructions when available and supported*. :devil:
What about adding more checkboxes for SSE3/4 to "Info & debug" window? :rolleyes:

[B.F.]

I think UI and installer in ffdshow need a lot more then just few checkboxes.

FFDshow grow in a quite big programm, with a tons of options, but UI is still the same as before.

[SeeMoreDigital]

I think UI and installer in ffdshow need a lot more then just few checkboxes.

FFDshow grow in a quite big programm, with a tons of options, but UI is still the same as before.Personally I would be happier if it there were no check-boxes at all during the installation..

It's far more straight forward to select the decoders (and other options you require) after FFDshow has been fully installed....

[clsid]

FAAD2 v2.5 has been released.
http://www.audiocoding.com/modules/mydownloads/

[igor1st]

FAAD2 v2.5 has been released.
http://www.audiocoding.com/modules/mydownloads/
Nothing changes since 2006-08-08 source code (that comes in my builds) except include file with version. :)

BTW, I communicate with Menno now about this "speed playback problem". I'll inform the results later.

[Facct]

1).PLEASE make detailed, accurate bug report.
2).Please tell us:
a).the system type(CPU,MB,Ram...)
b).the exact version of ffdshow(generic,sse,sse2)
c).the options given when ffdshow was configured
d).media player,ax filters,video sample...

Sorry for the lack of specifics.

a) AMD x2 4400+, Abit AN8 SLI Fatal1ty, 2GB Corsair XMS3500-LL, NVIDIA 7800GT running Windows XP SP2

b) ffdshow-20060722-rev2546 either XXL AutoDetect (SSE2) or videomixer9 (SSE)

c) H.264 disabled, Raw Video set to YV12

Resize: 1920x1080 Lanczos4
Avisynth: LimitedSharpenFaster (no supersampling)
Overlay: YV12, Queued Output Samples

Putting Resize after LimitedSharpen worked sometimes without crashing, but I noticed resizing often didnt work (I don't recall a single time where it played without crashing, that resizing worked, but I didn't check always as my interest was in resizing before LSF)

I don't use the Administrator account in XP (recall posts regarding this mentioning resizing this around that time)

d) Zoomplayer Pro 4.51, NVIDIA PureVideo Decoder, any DVD

have i forgotten anything?

[clsid]

Nothing changes since 2006-08-08 source code (that comes in my builds) except include file with version. :)Could you make a patch/diff file? Then I can include it in my builds as well.
BTW, I communicate with Menno now about this "speed playback problem". I'll inform the results later.I have uploaded a small test file that exhibits the problem. Download (http://www.mytempdir.com/864866).



A new build:
* Tryout SVN 63
* H.264 MBAFF support enabled (optional in installer)

Download (http://www.mytempdir.com/864857)

[nfm]

please don't forget about Aud-X support in new builds (audxlib.def and audxlib.dll).

[B.F.]

Personally I would be happier if it there were no check-boxes at all during the installation..

It's far more straight forward to select the decoders (and other options you require) after FFDshow has been fully installed....
But most of ffdshow users don't know anything about advansed settings.
They want to install a programm, and see a result.
And what do they see?
1)List of supported video codecs in install dialog is about a quater of supported by ffdshow.
2)Some codecs need postprocessing, others not.
Postprocessing is good on low bitrate mpeg(1,2,4), but on high bitrate and uncompressed video it only make picture look worse.
On install dialog I can enable postprocessing, but try to watch HD AVC video after that (automatic quality control is disabled, and postprocessing on max by default (cpu load x2)). :)
Ffdshow can save and load profiles.
How about a option to set different profiles to different codecs. (not unique profile to each codec, but some profiles like "no PP","debloking only" ets..).

[foxyshadis]

I remain of the opinion that PP should be permanently globally disabled in AVC and WMV/VC-1, and perhaps any non-"standard" dct codec. (Deringing is better handled by avisynth if you have 2+ cores anyway.) But since no one else seems to care, I'm hesitant to make such a change.

Codecs that could use it:
MPEG-1/2/4 (asp) (perhaps switching off based on quant)
SVQ3, Indeo, FLV1/VP31, maybe DV at low bitrates.
All others either include inloop filtering or have artifacts unrelated to DCT's.

[SeeMoreDigital]

I care... I'm with you Foxy ;)

At the end of the day FFdshow is a powerful codec suite and should really be targeted toward more skilled users who have a good working knowledge about about what most of its functions do/provide.

Inviting beginners/new users to select options via a installers GUI without knowing what they do, could lead to user disappointment, confusion and eventual deletion.

In my opinion FFdshow users should be encouraged to delve deeper into its functions so they can see exactly what's in there.... And if they are ready for it.

[KoD]

Could you make a patch/diff file? Then I can include it in my builds as well.
I have uploaded a small test file that exhibits the problem. Download (http://www.mytempdir.com/864866).

It looks like libfaad in either ffdshow, coreaac or foobar2k is detecting that file as having 2 audio channels when in fact it has only one.

[haruhiko_yamagata]

I remain of the opinion that PP should be permanently globally disabled in AVC and WMV/VC-1, and perhaps any non-"standard" dct codec. (Deringing is better handled by avisynth if you have 2+ cores anyway.) But since no one else seems to care, I'm hesitant to make such a change.

Perhaps no one around here knows better about PP than you. I think you don't have to hesitate to do something about PP. Though I can't comment individual codecs.

[igor1st]

Could you make a patch/diff file? Then I can include it in my builds as well.
diff file for ffdshow-tryout rev49-63 (http://d.turboupload.com/d/879658/faad2.zip.html)