New ffdshow build (?)

[bob0r]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[MacAddict]

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]

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]

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]

...and what about encoding ?

[Zephir]

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

[videomixer9]

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]

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]

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]

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]

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]

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]

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]

...

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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

[Egh]

@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]

@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]

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

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]

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]

What about the ICLs? Wake up and test :P

[bob0r]

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]

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]

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.

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.

[Thomas_AR]

@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]

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

[Thomas_AR]

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

[cc979]

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]

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]

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]

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]

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

libavcodec/mplayer are gcc 4.0.2
Everything else ICL9

[cc979]

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