ffdshow development

[arno]

Originally posted by Andy2222
BTW i found the error, the color conversion bug is caused my the libmplayer.dll. If i use the libmplayer.dll from athos releases i have that green color bug described. if i use the libmplayer.dll from Kurosu release i dont have that bug. Strange is that both releases are v2.3 but Athos is much bigger 420k and 74k? What compile settings u used Kurosu and where u got that new libmplayer from?

The color conversion bug is shown here and happen's with all ffdshow releases from 05-11/2003:
http://img17.photobucket.com/albums/v50/Andy2222/colorcheck.png

If i just copy Kurosu libmplayer.dll into the installed version of Athos the color bug is gone. Seems something is diff. with Kurosu version.

I just installed the Kurosu release aswell and guess what? Both the bad performance problem (stuttering) is fixed & Nic's Postprocessing method no longer crashes my player (BS player). Great! Thanks, man!

I think there's a serieus compiler problem with the Athos builds? Maybe Athos could talk to Kurosu about the possible cause(?)

[Andy2222]

Originally posted by arno
I just installed the Kurosu release aswell and guess what? Both the bad performance problem (stuttering) is fixed & Nic's Postprocessing method no longer crashes my player (BS player). Great! Thanks, man!

I think there's a serieus compiler problem with the Athos builds? Maybe Athos could talk to Kurosu about the possible cause(?)

I think the problems was caused by the mplayer.dll, maybe something little with big impact changed there. Im trying to build a new ICL8.0 build with the actual cvs. Compiling seems to work so far with some little modifications. If i tested the compile maybe i will post it here to for download.

[Andy2222]

oki some more infos about the green colro conversion bug. Its 100% caused by the /mplayer -> libmplayer.dll

If u compile the dll with VC6 or ICL 7.1/8.0 u dont have that bug but the rezisers are damm slow (about 50% slower) if u use the make in min-gw with gcc the speed is nice but that color bug appers.
Im not sure what exact cause the error maybe some stuff in the more optimized gcc version or some diff. linked libs?


Still no luck i tryed now compile the mplayerlib.dll with gcc from version 3.2.2 to 3.3.2 under mingw and cygwin with many diff. speed and -O options, with sse,mmx,3dnow disabled and i386 mode. I cant get a compile out wich dont produce that color bug.... The ICL7.1 ICL8.0 and VC 6.0 compiles work fine but even the fastest ICL8.0 compile is 50% slower than the gcc compiles....? I could realy use some advices? Also how can i get older version/revs from
cvs system? I tryed around with "cvs co -r ..." but only get the version i see on the webcvs system. Athos is it maybe also possibel to get the .configure file for ffdshow and the mplayer? Also where do i have to look to get a new mplayer.lib?

[CruNcher]

thx Gabest and Andy2222 for helping me out ok i could fix that dxguid problem but new linking errors arised :(


Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
Tffvfw.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowPageEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
reg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Tffvfw.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TffdshowPageEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
reg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_traits@
D@std@@V?$allocator@D@2@@std@@2IB)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_
traits@D@std@@V?$allocator@D@2@@std@@2IB)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_traits@
D@std@@V?$allocator@D@2@@std@@2IB)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
bin\ffdshow.ax : fatal error LNK1120: 9 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 37 error(s), 72 warning(s)

[Andy2222]

realy strange u have the latest "cvs update" and u using VC++ 6.0?

Can u make a screenhot of your includes/libs and also what compile settings u use aka wich linking settings? Or post it here. Its easy to see that some files got not liked/included but why...


ADD: ah i see u try compile the ICL release? What ICL u use 7.1 or 8.0? Maybe try the normal release first with teh vc 6 compiler.
For the ICL try also add the "libirc.lib" to the link lib modules.

[CruNcher]

yeah i figured it out now only those last link problems here and im done :)


xilink6: executing 'C:\PROGRA~1\PROGRA~1\VC98\Bin\link.exe'
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
bin\ffdshow.ax : fatal error LNK1120: 2 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 4 error(s), 0 warning(s)


Andy2222 im useing icl 8
edit: tried to compile with vc6 the same 4 errors :(
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx81_c/directx_cpp/htm/cvideotransformfiltercvideotransformfilter.asp
strange i compiled it and added it to dxsdk/lib and still those 4 errors :(

[Andy2222]

realy no clue... i hate those linking errors. If u can manage to get it work pls tell me how the performance on your system is with lanczos rezise at 1152x768 or up. On my ICL 8 compiles its so damm crappy... To bad cvs system is down atm cant check a other revision for my tests.

What compile switches u use? /G6 /O3 -Qxi ? Some vector optimize stuff too?

[CruNcher]

Andy2222 could you attach your .dsp file i don't know what im doing wrong i reinstalled dx9b and still the same 4 linking errors :(

those are my linking settings

msvcrt.lib strmbase.lib libircmt.lib libirc.lib kernel32.lib user32.lib advapi32.lib winmm.lib ole32.lib uuid.lib oleaut32.lib comctl32.lib gdi32.lib shell32.lib comdlg32.lib dinput.lib dxguid.lib oldnames.lib /nologo /entry:"DllEntryPoint@12" /dll /pdb:none /machine:I386 /def:".\src\ffdshow.def" /out:"bin\ffdshow.ax" /implib:"Release_ICL/ffdshow.lib"



Edit:

Ok i solved that also i was useing the Release_Unicode strmbase.lib wich was wrong now only 1 link error is left :)


Linking...
xilink6: executing 'C:\PROGRA~1\PROGRA~1\VC98\Bin\link.exe'
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
bin\ffdshow.ax : fatal error LNK1120: 1 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 2 error(s), 0 warning(s)


any idear ?

[Andy2222]

hehe i just downloaded all releases from the cvs :)

Lemme try compile the latest, seems the V1/V2 and other releases are outdated, will check that later.

@Athos i dont want check all the ffdshow code, but what functions classes are mainly called from mplayerlib.dll wich are used in rezise and swscaler wich might cause that color bug?

[Kurosu]

I've seen most of the linking errors reported here, but I hardly remember what I've installed to get it to work. As for the speed difference, it's obviously the compilation by nasm of the .asm files, enabling MMX/iSSE code; Athos had already noted that problem.

I don't know what's possibly causing the other bugs, nor what my build fixes or breaks.

[Andy2222]

@CruNcher u have the dx9b sdk installed and the windows nt platform sdk and included all libs/includes to the vc++ dirs?

Im getting now this for the ICL compile

ec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(

i had this error already on ym first trys... forgot what i was changing hehe :)

[Andy2222]

and some luck CruNcher?

I was lucky and finaly found the bug with the green, its the "#define ARCH_X86" in the swscale.c seems something is messed up with the includes and the #defines seems also that cpudetect.c has some trouble on Athlon systems. I will check this out. I will try use the latest mplayer/ffmpeg and libavcodec for teh new compile. also using nasm and gcc with cpu flags. Will play a bit with the defines and see what speed i can get and maybe compile a AMD and intel SSE version.
I will try what i can to to see what that aspect ratio and overlay problem is releated too. Also the postprocessor could need some work :)

[Coroner]

Wow!

It's great to see this sort of activity in this thread. I was starting to worry that ffdshow might be dead, which it still could be. It would be nice if the niggling bugs were fixed and it's brought in line with Xvid latest.

Keep up the good work people.

[Gaia]

Originally posted by Coroner
Wow!

It's great to see this sort of activity in this thread. I was starting to worry that ffdshow might be dead. It will be so nice when the niggling bugs are fixed and it's brought in line with Xvid latest.

Keep up the good work people.

Cheers

Coroner

Development might be still dead... This discussion is about compiling.

[Coroner]

I do realize that, although it is nice to see some bugs being discussed and some possibly squashed.

I have rephrased the post above as I was using wills instead of woulds. I shall try to prevent my enthusiasm from over taking my posts in future.

[dapipa]

hi!did any1 find out(yet),what causes the DOESN'T_KEEP_CORRECT_ASPECT_RATIO_WHEN_RESIZING bug,which a couple of people(including me)were complaining about in this thread?all builds after 20030523 are suffering from it:-(

[Andy2222]

aye i also hate this bug. Maybe im able to build a working version with AR and without that green rezise bug. Still working on my release its damm hard to compile and to update. Im still trying to fix that green bug its 100% in the swscale_template.c if u "#undef RUNTIME_CPUDETECT" in the config.h and also #undef all speed optimizations u get a green free rezise (buts unusable slow) thats what mainly happens if u compile teh lib with vc++ since speed defines dont work and just a plain x86 version is generated thats why its so slow, but also dont have this bug.

@DEV's any tip what in the swscale_template can cause that? If its in the assembler code im out of business....

[dapipa]

@Andy2222:i'd like to help u,but i stopped programming in ASM/C++ a long time ago,under MS-DOS,so i've got no idea how it works under new WIN(or linux)platforms:-(

[Andy2222]

It is not that hard to "try" translate that asm code, its more that the code use mmx/3dnow/mmx2 optimized instructions and finding that little value wich cause the trouble can be a pain. Im trying to checkout if the mplayer also have the bug using scaling, if not than its something in the ffdshow swscale call routines. If its also in mplayer i will try mail the mplayer devs since the swscaler is not coded by the ffdshow dev i guess (or i try find an old rev wich dont have the bug but might be a bit slower :) )

Im realy enjoying it, its slow progress but funny if u finaly get your compile working. Its also funny to see the org. ffdshow in the firstrelease stage, cool interface.

[Andy2222]

oki found the error for the green problem, the new mplayer revs use a new
#define VROUNDER_OFFSET "11*8+4*4*256*2+8"

uint64_t vRounder __attribute__((aligned(8)));" definition in
struct SwsContext{}

Just add the new defs and "c->vRounder= 4* _u64(0x0001000100010001);" at the call and the green problem is solved.

But seems its already integrated in the latest cvs.

[Andy2222]

wrong info

[Blight]

Andy:
While you're at it, can you fix that bug that prevents the filter's property dialog from opening if the filter is not connected to an active graph (pressing the config buttons in ZP for example)

[bond]

and plz add support for the small character "mp4v" again to the source, its needed to make ffdshow work with .mp4 and native matroska files! :D

[Andy2222]

Originally posted by bond
and plz add support for the small character "mp4v" again to the source, its needed to make ffdshow work with .mp4 and native matroska files! :D

oki that should be easy :)

[bond]

great it was commented out because there were too many 4ccs used it seems:

In TffDecoder_reg.cpp:

// I had to comment few media types, because graphedt was crashing when listing directshow filters
// Most probably there were too many registered media types by ffdshow's input pin
const TffdshowDecVideo::TmediaType TffdshowDecVideo::inputMediaTypes[]=
{ (...)
{ &MEDIATYPE_Video, &CLSID_MP4V ,FOURCC_MP4V},
//{ &MEDIATYPE_Video, &CLSID_mp4v ,FOURCC_mp4v},
(...)
NULL,NULL,0
};
maybe its better if you comment MP4V out (i dont know a codec that uses it) or any other strange 4cc, mp4v is more important imho

[Andy2222]

Originally posted by Blight
Andy:
While you're at it, can you fix that bug that prevents the filter's property dialog from opening if the filter is not connected to an active graph (pressing the config buttons in ZP for example)

i will see what i can do, atm i mainly try get the following things fixed

1. swscale chroma rounding problems (aka no more green if u rezise)
(that is a mplayer problem)
2. get the correct AR if u rezise (bug in the newer versions)
3. speed optimizations and fully working asm code of the integrated parts from other projects (xvid color conversiosn and co)
4. get the code build with cygwin since i can set more speed stuff with gcc compared to ICL or VC6

so far i have 2 options use the latest cvs version and try fix all stuff or use a older rev and try integrate xvid4 + denoise3d + all new bugfixes/support

So far i could code a simple hack for the aspect ratio problem in the latest cvs version, in the old version overlay + overlay AR + normal Ar works fine. Still have no clue why overlay/AR in teh new versions not working...

I also try get a fix for the green + rezise chroma bug by reporting it to the mplayer devs. Problem is the new vrounder introduced in the latest dev mplayer version fixed the green problem but also cause a new bug, wich is already in the 10/11 versions Athos compiled.
Since its ASM code i cant realy do much...

maybe found the rounder bug could be compiler option related

BTW: if some1 want code a denoise3d asm/mmx2/sse code that would be a realy huge speed buff for ffdshow :)

[dimzon]

Originally posted by bond
great it was commented out because there were too many 4ccs used it seems:

In TffDecoder_reg.cpp:

// I had to comment few media types, because graphedt was crashing when listing directshow filters
// Most probably there were too many registered media types by ffdshow's input pin
const TffdshowDecVideo::TmediaType TffdshowDecVideo::inputMediaTypes[]=
{ (...)
{ &MEDIATYPE_Video, &CLSID_MP4V ,FOURCC_MP4V},
//{ &MEDIATYPE_Video, &CLSID_mp4v ,FOURCC_mp4v},
(...)
NULL,NULL,0
};
maybe its better if you comment MP4V out (i dont know a codec that uses it) or any other strange 4cc, mp4v is more important imho

Maybe best way is to split ffdshow into 2-3 separate filters (in one *.ax file of couse) with exatly same implementation(using inheritance from base class) but with different fourCC set (to avoid max fourCC per filter limitation)

[Andy2222]

@ the other compiler dudes

Is some1 able to build the baseclasses with gcc? Im using the dx9b sdk and seems the .diff file dont patch fully..

Some1 has a working set and can provide me with a working .diff patch file for the dx9b sdk and maybe a working makefile?

Or has the old dx9a sdk basecalesses wich work with the .diff?

problem solved

[Andy2222]

will repost later

[oddball]

ffdshow seems to have a jerky problem with XviD RC1 encodes. I tried with May 23 2003 version too just to be sure. Using XviD RC1's own decoder they playback smoothly.

[bond]

ffdshow doesnt handle more than 2 packed bitstream b-frames, as produced with the default settings with the latest xvid builds

its a bug in ffdshow

[Andy2222]

damm its a pain to rewrite all that inline __asm code from intel to AT&T standard for gcc...
some1 maybe know a working converter? ATm im using intel2gas v1.3.3 but it has some trouble with some commands. Is there a other script or tool?

Or is it possible to set a gcc option so it accept also intel inline asm code without rewrite the code?

found a solution
now i need test how the gcc 3.3.3 or 3.4beta vs ICL8.0 compiles perform.

[LigH]

I did not see such a problem with the build from 2004-01-13; maybe it was fixed, maybe the movie I used did not use (m)any packets with 3 B frames.

My dynamic mirror: http://www.ligh.de/software/mirrors.phtml

[Andy2222]

Originally posted by oddball
ffdshow seems to have a jerky problem with XviD RC1 encodes. I tried with May 23 2003 version too just to be sure. Using XviD RC1's own decoder they playback smoothly.

Im not sure what that bug is but in teh actual cvs a special xvid4 code was implemented i guess that bug is fixed.

[oddball]

Yeah but the newer builds have an inherent jerkiness of their own compared to the 23/5 build when playing back vids encoded in any other codecs.

[hellfred]

@LigH
Looks like you are the only one serving and talking about ffdshow buil 20040113.
(At least that is my conclusion after googling and searching this forum)
Did you compile this version yourself?
I have problems using this build on my Win98 system (with an Intel PIII Katmai CPU). ffdshow complains about a dll missing whenever it try to run the configuration after running the installer. ffdshow is not an selectable dshow filter, registering the ffdshow.ax fail, too. Sadly the error messages does not include which dll is missing.
On anothere system that i can access (Intel PIV with WinXP) the ffdshow build works fine. Is this yet another problem with the missing unicode on Win98? If you are the compiler of this version and the problems are due to the unicode support, i would like to ask you: Is it possible that you make a version not using unicode? I really like to use ffdshow on my PIII-550, as it it the only codec/dsfilter that allows me to view high resolution (>640x480) mpeg4 videos without stuttering. And it would be a shame to have to do without it because somewhere in the dialogs the unicode chars cannot be displayed. (At least that is a guess of mine).
Or am i missing something else? ffdshow 20031128 is working on my Win98 system.

Yours
hellfred.

[filewalker]

During the installation, one .dll was also missing, but a dialog popped up and showed me that "msvcp70.dll" is missing...( I found it here (http://www.dll-files.com/) )


Cu filewalker

[Koepi]

You also need msvcr70.dll, find it in the same location above as msvcp70.dll.

Regards
Koepi

[hellfred]

Thanks for the tipps. After coppying those two dlls next to ffdshow.ax configuration worked again and directshow based player can use ffdshow now. But neither the installer nor starting configuration gave me the name of the missing dll. I have confirmed that. The installer does not output any warinings or errors at all.

hellfred

[bond]

Andy2222,
i hope you didnt lost interest in ffdshow, people are really starving for a new ffdshow version with fixes :)

maybe you can ask trbarry (or milan if he answers) for getting your things added to the official ffdshow sources

[Andy2222]

Originally posted by bond
Andy2222,
i hope you didnt lost interest in ffdshow, people are really starving for a new ffdshow version with fixes :)

maybe you can ask trbarry (or milan if he answers) for getting your things added to the official ffdshow sources

nope, atm im tyring some compiler related stuff. The ICL8.0 version is already working, the speed is at least the same or a "bit" better than the 09/2003 version.
Atm im messing around with some asm stuff in the code for the gcc compiler. Im hoping the new gcc 3.3.3 or 3.4 maybe can get a bit more speed out of the code. The biggest bottleneck is still the denoise3d filter. But i have to rewrite/alter some code and defines for gcc.

What is already fixed?

"configure" crash in zoomplayer
aspect ration and overlay not working/connecting correct
some speed optimized code wasnt used in some filters, if compiled with VC++. (need recheck if the code might bug/crash those filters)
chroma rounding bug aka movie gets green if u use rezise filters, was most noticeable with lanczos and sinc
changed to "mp4v" fourcc -> (info from bond)


What im still working on?

gcc compile with all intel asm code used correct
overlay reset button not working
delinking nic's and mplayer postprocessor filters, so u can use deblock and dering seperate from both filters (example: using only nics deblock and only mplayer dering)
some minor changes for the "keep org. aspect ratio" button


If the gcc compile is finaly fully working and i can compare the speed vs the intel version, i will than release a first bugfixed version. The stuff im working on will need some more time.
Im aiming for bugfixes and most possible speed atm. Since i dont want rewrite the routines atm i can just work at the compiler end. "Maybe" i update my asm knowledge with some SEE/MMX2 stuff and see if i can update some bottlenecks with optimized versions, but i dont think i have that much time atm.

[bond]

great! and plz dont forget to uncomment the "mp4v" fourcc, as described above :)

[avih]

Andy2222, thx for your work, sounds very good so far.
good luck

avih

[mikeX]

updating nic's postprocessor with xvid4 (new nic's) versions

is that the same as xvid's >=beta code?
if so, won't that raise cpu usage tremendously? (that's what xvid's postprocessing does to me)

[Andy2222]

Originally posted by mikeX
is that the same as xvid's >=beta code?
if so, won't that raise cpu usage tremendously? (that's what xvid's postprocessing does to me)

Will review that, old xvid's revs used nic's wich has optimized asm code. The new beta just use simple c++ code, wich seems just grabbed from mplayer. If i cant find a new asm version of nic's i will keep the old one and just update the mplayer version.

Was sure there was an updated asm version of nic's in a xvid version i downloaded...

[Blight]

Andy, there is also AR information saved into XVID streams now, if ffdshow could pass that info down the line using the VIDEOINFOHEADER2 structure, that would make ffdshow the only decoder other than the nero one that could handle anamorphic xvid content (I think).

[Andy2222]

Originally posted by Blight
Andy, there is also AR information saved into XVID streams now, if ffdshow could pass that info down the line using the VIDEOINFOHEADER2 structure, that would make ffdshow the only decoder other than the nero one that could handle anamorphic xvid content (I think).

I can try implement this, the code is already in the overlay part since for overlay+rezise mode VIDEOINFOHEADER2 is used for the AR correction. Have to check if there is already code to get the AR out of the stream.

PS: atm some strange things happend here, the latest Intel 8.0 compiler produced code wich runs 30% slower than plain O2 code compiled with VC 6.0? Seems the Intel Compiler have some problems with verctorizing and inlineing. But even if i disable ipo aka /Ob2 the code is much slower than the VC6.0 version... I was thinking Intel produces always faster code than the old MS compiler, at least that was what latest compiler benches showed. Something is messed here.

[athos]

Andy> It's very cool to see that you are involved in this project! I havent followed this thread for a while, because, well, i forgot ;) I do check the CVS regularly though, still nothing from milan. I was wondering, as you seem to have been getting to know the code some, have you figured out how to update the mplayer and libavcodec parts from those projects? milan gave me the impression that it shouldnt be hard to do, but i havent managed to get it working myself. especially the libavcodec would be good, because i think there are some stuff that has been improved since the latest version being used in the current CVS.

Keep up the good work, and let me know if I can help you with anything. I do know some c/c++, but i have only been compiling the project, and made no code contributions.

[Andy2222]

hehe so we sit in the same boat :) I also know c/c++ but never coded extensive dshow filter like ffdshow :)

The mplayer parts are kinda simple, for the swscaler and noise not much changed. I have to take a look into the libavcodec myself but im concentrating on other stuff first since its working fine atm.I think rather use ffdshow as raw filter than as decoder. Im still not happy with the compiler speed..

What compiler options and compiler did u used for the 09/2003 version wich seems to be the fastest from your compiles?

PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.

[Soulhunter]

Wow, ffdshow resurrection... :D

Bye