ffdshow development

[bond]

Originally posted by MoonWalker
BTW why overlay mixer at ffdshow has 3 options?? One tick, one dash, and unchecked...because there are three options:
- use overlay mixer2
- use overlay mixer
- use non of both

[Owen]

Why does anyone want to enable Overlay mixer in FFDShow?
This caused problems with most builds of FFDShow.
I don’t understand why that option even exists.
The player sets the output renderer.


Owen

[skynetman]

Originally posted by Andy2222
if we cant reproduce the error its realy hard to fix those stuff.


Same crash error on another PC with an AthlonXP 2400+ and Nvidia Geforce TI4400 with latest drivers.

It definitely has something wrong.

Can u build a debug version? So i can check what line do i have the error in code.

[Wilbert]

Why does anyone want to enable Overlay mixer in FFDShow?
For playing mkv's with an ar different as 1:1.

Btw: Athlon XP 3000+ (also Abit KT7A I think), Nvidia Geforce TI4200 (WDM 30.72 drivers) and overlay mixer enabled works fine for me. DirectX 8.1 I think :) WMP6.4.

I will try to change the gain and offset when I'm at home.

[Andy2222]

Originally posted by skynetman
Same crash error on another PC with an AthlonXP 2400+ and Nvidia Geforce TI4400 with latest drivers.

It definitely has something wrong.

Can u build a debug version? So i can check what line do i have the error in code.

oki will do :) we should prolly take the chance that some1 has vc installed.

[Andy2222]

Originally posted by Owen
Why does anyone want to enable Overlay mixer in FFDShow?
This caused problems with most builds of FFDShow.
I don’t understand why that option even exists.
The player sets the output renderer.


Owen

Since i like the fast and easy way to set the overlay color settings and the latest build's should not make problem's in those modes. I can have it enabled without any problems in every player (zoom/mpc/bsplay/core/crystal)

The not "connecting" bug was smashed a while ago and the AR bug too.

[TheShadowRunner]

ffdshow-20040329 also crashes with SVQ3 (quicktime sorenson)contents, also caused by a problem with"libavcodec".
Later,

TSR

[Owen]

Wilbert,

What has Overlay mixer got to do with AR control? :confused:

Owen

[Kurosu]

Owen, please read about the Overlay Mixer 2 (http://msdn.microsoft.com/library/en-us/directx9_c/directX/htm/overlaymixer2filter.asp?frame=true#overlaymixer2filter) and the VIDEOINFOHEADER2 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/videoinfoheader2structure.asp) that were both mentionned in the few last pages

[skynetman]

@Andy2222: I think we found the problem thanks to that debug version.
Simply debug version DOES NOT CRASH while standard CRASHES.
As i suppose they are the same ffdshow version it is obviously a compiler optimization that makes athlons crash and that is not active when compiling in debug mode.
U could check project configuration and try disabling only one each time then send me link to as many version as u want to find the wrong param :)

Anyway debug version works ;) I'm using it for a high definition avi and is smooth on my 2000+ on static scenes (choppy on fast ones)

Waiting for someting to test....

[Wilbert]

I will try to change the gain and offset when I'm at home.
Plays fine for me.

edit: used W2K SP4

[Andy2222]

Originally posted by skynetman
@Andy2222: I think we found the problem thanks to that debug version.
Simply debug version DOES NOT CRASH while standard CRASHES.
As i suppose they are the same ffdshow version it is obviously a compiler optimization that makes athlons crash and that is not active when compiling in debug mode.
U could check project configuration and try disabling only one each time then send me link to as many version as u want to find the wrong param :)

Anyway debug version works ;) I'm using it for a high definition avi and is smooth on my 2000+ on static scenes (choppy on fast ones)

Waiting for someting to test....

mhh im confused again.. why a normal version crash for u but not for me or other's, i have an athlon-xp too (but i use windows-xp)
The second pc u tested it and it crashed what OS had it also win2000?
I have realy no clue why a simple VC version can crash on one athlon system but not on a other... damm this suck's big time.

I will compile some more version's tomorrow u can test, need a break atm.

PS: i dont think its a optimisation problem of the compiler cause the VC compiler is out for a long time and i never heared of athlon problem's, however i think it's one of the debug lib's ffdshow get's linked against, wich fix that problem. I tip on the strmbasd.lib, i will test this.
Did my ffdshow compile also crash like athos, if so we both have the same lib's than :)?

BTW: what crashes in graphedit? Cause u just wrote mplayerc.exe crashed. Can u try it in graphedit and tell me if graphedit or ffdshow.ax or libav or mplayer.dll crash?

[adx200]

Just for Athos' information, the 3-29 build also fixes the choppy playback issue on my machine. I'm using Zoom Player, with FFDShow's post processing options turned on, on an Intel chipset with a Pentium 4. The 3-25 build was just choppy enough to make me go running back to the 5-23-2003 alpha build, but this one's working fine for me. Thanks!

[Didée]

Confirmation: ffdshow 03-29-2004 plays smooth for me, too. Finally - hooray! AR control w/w/out resizing also seems to work as expected.
'Gain' in 'picture properties' is crashing, but I could not mind less (I never use it).
Going to check if something has changed in handling of high bitrate quant matrices.

- Didée


edit: forgot the 'hooray'

[oddball]

I used to have choppy playback too. But in the latest builds it is not as bad. I still get odd dropframes but not nearly as bad as a few builds back. Dunno.

[Arska]

Yep, the resize issue that I mentioned earlier is now gone.

[skynetman]

@Andy
The crash problem is on 2 pc with windows server 2003 on both.
The strange thing is that on one of those 2 pc when i installed ffdshow (over the previous one) explorer shell crashed (and under win 2003 NEVER happens) and i had to reboot.

Can u send me a graphedit project? I have an exam. at univ. tomorrow( entropic coding, DCT,FFT, VLC subband etc....), and now i don't have any space left in brain for graphedit manual :p

[Owen]

Please excuse my ignorance, but I am still trying to figure out what enabling Overlay mixer in FFDShow has to do with aspect ratio parsing.
Are people suggesting that if overlay mixer is NOT enabled in FFDShow that aspect ratio parsing is still broken?
Why should enabling overlay mixer in FFDShow be preferable to enabling it in the player?
Where does all this leave the people who are now using the better quality VMR9 renderer and who cannot enable overlay mixer in FFDShow?

Regards,

Owen

[Andy2222]

Originally posted by Owen
Please excuse my ignorance, but I am still trying to figure out what enabling Overlay mixer in FFDShow has to do with aspect ratio parsing.
Are people suggesting that if overlay mixer is NOT enabled in FFDShow that aspect ratio parsing is still broken?
Why should enabling overlay mixer in FFDShow be preferable to enabling it in the player?
Where does all this leave the people who are now using the better quality VMR9 renderer and who cannot enable overlay mixer in FFDShow?

Regards,

Owen

oki simple example: u want play a media file with anamorphic ar, or a ar wich isnt the pixel ar of the movie. If overlay mode is disabled ffdshow use VH1 and just send this to the render wich get x,y as normal pixel info's and nothing more, so the movie play's at wrong AR. If overlay is enabled ffdshow use VH2 and "try" to read the correct AR out of the movie and than send x,y and Ar info's to the overlay mixer. With this infos the player/OM can correct the movie and play's at correct AR.

"better quality VMR9 renderer" u cant say that, VMR9 is bugged and on my system looks very bad compared to overlay mixer. There is no "better" atm, what looks better for u might look bad for a other people.

U can still enable overlay usage + VMR9 to get the AR info's handed down.
Btw i say it again since every1 try to push so hard to get VMR9 working, its not the holy grail.

VMR9 does 2 thing's atm wich might be usefull:
1. Multiple display's can be opened/used at once, while OM just allow 1.
2. It "might" have a better scaling mode compared to the overlay mixer, but this depend's on the videocard. If u use ffdshow for resize than u dont have to care.

The other stuff u might notice like so called "smooth" aka better or "washed" aka bad effect's hardly depends on the implemetation of the videodriver and which color control setting's are used. I just say its kinda subjective since a couple of ppl like overlay over vmr9 and other couple like vmr9 over overlay.

Im not a dshow programmer but i already wondered why ffdshow cant use VH2 all the time? For 3ivx decoder i noticed that the output is always in VH2 format even if the movie has special AR in it or not. It just copie the x,y values to the AR values if no infos are found.

maybe this help's?

[Coroner]

VMR9 does another thing that is very usefull (the only reason I use it). It's the only way to display subtitles (SRT, SSA) on an MPEG2 stream in MPC.

[tato_uy]

Hi, i want to ask about the ffdshow audio filter.
Does anybody has problems with mp3 decoder (both of them libmad and mp3lib??.
Those twho doesn't work for me. I tested on 3 different machines and have no luck.
Did you know if this is gonna be solved? or the possible causes?.
thanks.

[shitowax]

3ivx output is VIH2 only if:
- it's required because the input contains non-square AR
- the force-overlay option is used.

Originally posted by Andy2222
Im not a dshow programmer but i already wondered why ffdshow cant use VH2 all the time? For 3ivx decoder i noticed that the output is always in VH2 format even if the movie has special AR in it or not. It just copie the x,y values to the AR values if no infos are found.

maybe this help's?

[gabest]

shitowax: If only AR info is needed, you could set the biXPelsPerMeter/biYPelsPerMeter members of BITMAPINFOHEADER, they are picked up by the older renderers too.

[Andy2222]

Originally posted by shitowax
3ivx output is VIH2 only if:
- it's required because the input contains non-square AR
- the force-overlay option is used.

oki my fault
mhh so we just have to add this too for ffdshow "- it's required because the input contains non-square AR"

this than should work with vmr7/9 render's and anamorphic encodes using VH2 without enabling "use overlay" in ffdshow

[skynetman]

Any news about non crashing ffdshow version, i'm still with debug :( ?

[P0l1m0rph1c]

Hi,

I don't know if anybody noticed this, or if its just me, but...

When decoding XviD content with ffdshow, using 'XviD 4' to decode it, the player just crashes when trying to decode the file. I tried changing iDct, enabling/disabling OM, but nothing of that worked. Using libavcodec to decode the file works just fine.

I don't have any post-processing or special filters activated in ffdshow, so that isn't the reason. This both happened in WMP6.4 and MPC 6.4.8.2. The stream i tested was an AVI with just video, so others streams aren't the problem either.

Btw, i'm using a P4 2.0 Ghz, 768 RAM, Win2k SP4, with latest Athos' build (29-03-2004). Using the one from 25th March does the same also.

[gitoshi]

I can confirm the GAIN crash bug in a Celeron 1GHZ , however the strange thing is that sometimes if I render the file in GraphEdit or play another AVI then in the next playback GAIN work fine.


@Athos:
What about a FFDSHOW lite build, without the encoder and Audio Filters parts??


G

[Andy2222]

Originally posted by gitoshi
@Athos:
What about a FFDSHOW lite build, without the encoder and Audio Filters parts??


I tryed this myself a while ago but one problem is to take all the encode/audio parts out and also resolving all the missing undefined object's and call's at linking time. If athos can manage this it would be nice but it wont fix any bug's or crashes and there will be also no speed gain.

@skynetman will build some test version's today maybe we can find out what's the problem.

[Andy2222]

@skynetman and co

oki 7 diff. compiled version's up at: http://mitglied.lycos.de/ieggei2/ffdshow/

If the libavcodec or mplayer dll crash try to use my version also.

good luck and post wich version's crash and wich dont


PS: since i build them from the latest cvs update i forgot to add some bugfixes (the overlay choppy playback) so just test them for the gain crash and stuff thx.

[skynetman]

Test Results:

Original libries:

ffdshow.ax.1 ---> CRASH
ffdshow.ax.2 ---> CRASH
ffdshow.ax.3 ---> CRASH
ffdshow.ax.4 ---> CRASH
ffdshow.ax.5 ---> CRASH
ffdshow.ax.6 ---> CRASH
ffdshow.ax.7 ---> CRASH


New libraries:

ffdshow.ax.1 ---> CRASH
ffdshow.ax.2 ---> CRASH
ffdshow.ax.3 ---> CRASH
ffdshow.ax.4 ---> CRASH
ffdshow.ax.5 ---> CRASH
ffdshow.ax.6 ---> CRASH
ffdshow.ax.7 ---> CRASH


Old libraries + old debug version ---> WORKING
New Libraries + old debug version ---> WORKING

U missed it this time, try again :(

[Andy2222]

@skynetman

dammit,

oki next round 5 new try's :)

[skynetman]

FOUND THE ONLY WORKING VERSION

Tested all 5 new build with both yesterday and today libs

ONLY ffdshow_5 works perfectly both with OLD(official) libraries and NEW libraries.
So libraries does not make any difference.

Did u compile ffdshow5 with same settings as the old "debug" version u gave me?
What was the problem? A compiler switch?

A new official version coming soon? :D

[Andy2222]

Originally posted by skynetman
FOUND THE ONLY WORKING VERSION

Tested all 5 new build with both yesterday and today libs

ONLY ffdshow_5 works perfectly both with OLD(official) libraries and NEW libraries.
So libraries does not make any difference.

Did u compile ffdshow5 with same settings as the old "debug" version u gave me?
What was the problem? A compiler switch?

A new official version coming soon? :D

oki its not a lib problem, its also not a problem with special debug defines or option's. I tryed every language switch wich is normaly on in debug mode.
The ffdshow_5 was compiled using /Os (all default optimization's off), while all other version's used /O2 or /O1.
Problem is i never ever had problem's in VS with /O2 and ffdshow will be crappy slow in /Os or /O1 mode.
I will compile some more version's where i turn off the default O2 switches one by one to find the problem. If we found the problematic switch i can than add a pragma optimize setting for just those 2 function's and disable the switch, so it should not impact the other functions.

[CruNcher]

Andy are you optimizing only for Athlon ?
in my latest test with Athos build vs XviD Decoder i can only see 1 fps gain for ffdshow but libavcodec should be alot faster then that hmmm at least that's what i hear is the situation natively under GNU/Linux

[arno]

Originally posted by Andy2222
oki its not a lib problem, its also not a problem with special debug defines or option's. I tryed every language switch wich is normaly on in debug mode.
The ffdshow_5 was compiled using /Os (all default optimization's off), while all other version's used /O2 or /O1.
Problem is i never ever had problem's in VS with /O2 and ffdshow will be crappy slow in /Os or /O1 mode.
I will compile some more version's where i turn off the default O2 switches one by one to find the problem. If we found the problematic switch i can than add a pragma optimize setting for just those 2 function's and disable the switch, so it should not impact the other functions.

I also have the crashing problem with luminance gain/offset for ages. Because I don't use the controls (anymore), since I use the settings in my videocard driver it's not a real issue for me. I know that in the past it used to work, if you like I can test with older versions of ffdshow were it exactly broke...

[Andy2222]

Originally posted by CruNcher
Andy are you optimizing only for Athlon ?
in my latest test with Athos build vs XviD Decoder i can only see 1 fps gain for ffdshow but libavcodec should be alot faster then that hmmm

What cpu u have? Since i did a similar test 2 night's ago and compiled myself a max. athlon-xp speed xvid.dll. I compared both version's with my normal ffdshow filter's and libav was around 30% faster, compare to the xvid version.

So i assume its a problem with the libavcodec for u? Or it could be a colorspace problem, did u used the xvid dshow decoder or did u set ffdshow to use the xvid.dll under codec's? Did u use yv12 enabled in ffdshow?

"Andy are you optimizing only for Athlon ?" There is no new special athlon code from me present in athos build's. My code still crash on p4 and some old pentium pc, on p4 there are also some speed problem's with my code. Im trying to fix this but i simple leak 10 yeahrs of assembler code knowledge :( and i dont want to add code wich add's more crashes/problem's to ffdshow. I realy try to get the denoise3d mmx2 code working since its one of the most used filter's, but its realy harder to code perfect asm code than i ever expected...

[Andy2222]

Originally posted by arno
I also have the crashing problem with luminance gain/offset for ages. Because I don't use the controls (anymore), since I use the settings in my videocard driver it's not a real issue for me. I know that in the past it used to work, if you like I can test with older versions of ffdshow were it exactly broke...

would be helpfull i can than look at the cvs system thx

[CruNcher]

i tested with 80 Mbit 1980x1080p ASP HDTV content and optimized the XviD version with icl 8 and definatly only 1 fps difference in playback speed where can i find your version of libavcodec.dll ?

P4 1.8 Ghz Williamette

actually it was the same result as with the old athos build i tested a while back

[Andy2222]

Originally posted by CruNcher
i tested with 80 Mbit 1980x1080p ASP HDTV content and optimized the XviD version with icl 8 and definatly only 1 fps difference in playback speed where can i find your version of libavcodec.dll ?

P4 1.8 Ghz Williamette

Just to understand your problem:

U compiled yourself a ICL8 version of xvid and compared this against the libav version in ffdshow right?

mhh the p4 is realy a strange cpu i have massive problem's with my code since some of the common used instruction's have hellish long vectorized cpu cycles.. so it could be that a special p4 version might help.

I will compile u a special p4 libav version for testing, might be intressting to see if this help's. Get it here in 5min's_: http://mitglied.lycos.de/ieggei2/ffdshow/

[CruNcher]

thx Andy i test with your version aswell heres the old test

http://forum.doom9.org/showthread.php?s=&threadid=71994

[Andy2222]

Originally posted by CruNcher
thx Andy i test with your version aswell heres the old test

http://forum.doom9.org/showthread.php?s=&threadid=71994

oki 3 version's up for testing

[arno]

Originally posted by Andy2222
would be helpfull i can than look at the cvs system thx

Here are my findings. The luminance gain/offset broke starting with Athos release 20031028, the previous release(s) (<= 20030816) work fine.... I hope it helps, Andy...

[CruNcher]

Andy here are the Results not much changed :)


Athos = 9,70 fps
Athos + libavcodec_P4 = Crash
Athos + libavcodec_P4_2 = 9,80 fps
Athos + libavcodec_P4_3 = 9,70 fps

XVID Rc4 = 8,00 fps

[Andy2222]

Originally posted by CruNcher
Andy here are the Results not much changed :)


Athos = 9,70 fps
Athos + libavcodec_P4 = Crash
Athos + libavcodec_P4_2 = 9,80 fps
Athos + libavcodec_P4_3 = 9,70 fps

XVID Rc4 = 8,00 fps


mhh strange that the P4 version crashed, whatever seems that the ICL8 compiler work's fine for P4 compiles and that gcc has some problem's to catch up. But i think its some hardcoded asm routines wich can be fast executed on athlon and p3 but cause a lot more troubles on P4 (u realy need to take care of what asm instruction's u use on p4 and wich better to avoid)

So the libav codec would need a review for P4 code to get the most out of it. To profile the code i would need a P4 CPU but i dont have one :) So i have no clue why on P4 the speed gain is just that low. Would be intressting to do the EXACT same test with an AMD or P3 CPU.

[Kurosu]

Did you compile libavcodec with -DHAVE_SSE2 (and maybe -DHAVE_CMOV)? Together with a bunch of other defines (like HAVE_3DNOW or HAVE_3DNOWEXT for AMD processors), some supposedly slower code is chosen.

[skynetman]

OK Andy New Test Results on 4 new builds:

ffdshow.ax.1 --> CRASH
ffdshow.ax.2 --> WORKING
ffdshow.ax.3 --> WORKING
ffdshow.ax.4 --> CRASH

Probably some ASM expert should look directly at assembly code cause i think compiler optimizes the wrong way some code.

are ffdshow_2 and ffdsow_3 optimized? Without any opt i lose many fps :(

@ALL: am I the only one testing? Hurry up, the party is almost over :p u will regret not having crashed your explorer shell at least 30 times :D

[Andy2222]

Originally posted by skynetman
OK Andy New Test Results on 4 new builds:

ffdshow.ax.1 --> CRASH
ffdshow.ax.2 --> WORKING
ffdshow.ax.3 --> WORKING
ffdshow.ax.4 --> CRASH

Probably some ASM expert should look directly at assembly code cause i think compiler optimizes the wrong way some code.

are ffdshow_2 and ffdsow_3 optimized? Without any opt i lose many fps :(

@ALL: am I the only one testing? Hurry up, the party is almost over :p u will regret not having crashed your explorer shell at least 30 times :D

oki its the /Og compiler switch than, aka global optimisation. I now try to check what this switch does for the code or just add a VC pragma and disable it for those cpp files.

[athos]

* win9x style install path
* Andy2222's fix for choppy OM playback
* Skal's codec
* Requires i686 (Pentium Pro) or better

[Sirber]

Originally posted by athos
* Skal's codecWhat is that? :confused:
[edit]
http://skal.planet-d.net/coding/mpeg4codec.html

forget it :)

[bond]

Originally posted by athos
* win9x style install path
* Andy2222's fix for choppy OM playback
* Skal's codec
* Requires i686 (Pentium Pro) or better cant install!
failure in ffdshow.ax during install