ffdshow development

[athos]

Originally posted by ummon
I have the same Problem as moko. With the 20030418 version of ffdshow I can only select the Codecs played by xvid.dll everything that should be played by libavcodec is not selectable. Has anybody an idea why this happens? The older versions of ffdshow don't show this problem.
I use Win98SE, DirectX 9.0a, ffvfw-20030325

I just checked and for me it's the opposite! But i think this is because i dont currently have xvid installed ... ;)

Check to see that libavcodec.dll is in the ffdshow dir.

[HarryM]

Originally posted by athos
I just checked and for me it's the opposite! But i think this is because i dont currently have xvid installed ... ;)

Check to see that lobavcodec.dll is in the ffdshow dir.

libavcodec.dll, maybe?

This library I have in ffdshow dir, but only XviD, Div4, DivX5 is selectable. For decoding is using xvid.dll. I cant deactivate 'use xvid.dll for decoding', it is forced!


I have Win98SE.

[iago]

Originally posted by drebel
... No smearing though... Yep, qpel smearing indeed seems to have gone when decoding with the latest ffdshow, and that's great!

[ECY]

did anyone get ffdshow-20030418 running on Win98 ?
There seems to be a problem that ffdshow can't use the "libavcodec.dll" on Win9x/me
can someone confirm this ?

[Gaia]

Originally posted by ECY
did anyone get ffdshow-20030418 running on Win98 ?
There seems to be a problem that ffdshow can't use the "libavcodec.dll" on Win9x/me
can someone confirm this ?

Works great with Win98se! So somenthing else is wrong.

[ECY]

Originally posted by Gaia
Works great with Win98se! So somenthing else is wrong.


you're sure you're not using XVID to decode ?
cause i get it running using the xvid option but not with libavcodec.dll

[drebel]

This ffdshow build use forced-using xvid.dll for decoding. Logically- it can't q-pel smearing no more.
It using (only) external xvid.dll for decoding!

No probs in Win2ksp3.Decodes all mpeg4 material without any codecs installed.Only a reliable (not damaged ang new) version of Libavcodec.dll is needed

GMC use is being reported fine...

[Gaia]

Sorry i was wrong, this really seems to be strange OS problem because i am forced to use Xvid as well and yes i have Libavcodec.dll in ffdshow directory.

[Mistar Muffin]

It seems that Mplayer pprocessing is broken in this release. Is it just me? (Win XP Pro SP1, Athlon 1.4ghz)

[ummon]

I just checked, all files including libavcodec.dll seem to be installed right. I also uninstalled XviD only with the result that Huffyuv and Raw video remain the only formats ffdshow can decode.
Seeing the other people having the same problems with Win9x/ME too I think libavcodec decoding under these OSs is broken. :( Regarding that milan said that he is currently changing ffdshow's COM interfaces, so that ffdshow, ffvfw and ffdub can cooperate, (http://forum.doom9.org/showthread.php?s=&threadid=42710&perpage=20&pagenumber=10) I guess the problem has something to do with the changes and will be hopefully fixed soon.
Or did anyone see a better solution than waiting and hoping for the next alpha?

[Blight]

I hope milan is still reading this, I've found two somewhat severe bugs (that exist prior to this release and still exist in it):

1. Using FFDShow as a post-processor along with VMR9 in a format that contain an internal AR flag (MPEG1/MEPG2, maybe WMV) will break the AR control for that format.
2. When trying to open the VMR9 property dialog, it will throw off a Division by Zero exception.

[oddball]

Are the options to playback MPEG2 in ffdshow a no go? I tried it and all I get is a blank screen and a blank screen with occasional colored blocks if I enable libmpeg2 as well.

Just curious as to why the options are there if they do not work. Or do they? Am I missing something?

[Rober2D2]

Mmm I'm getting the same problem as Moko,
All i can encode to with ffvfw is:
Theora, Mpeg1 & Mpeg2

It's like if choosing an encoder discard the possibility
of using a default encoder profile,
one allowing div3 etc.

esby


I have tried Theora and Xvid with no problem, but was unable to encode any MPEG1 nor MPEG2

[athos]

I have looked around a bit in the ffdshow code to see if it would be easy to fix the ffvfw dependency. I will try to do it later today using a proper "debug" compile, but i feel a little uncomfortable even if i could fix it as i might just introduce new bugs. i'd rather see milan do it. from what i understand ffdshow is supposed to check to see if ffvfw is present, but right now it seems it assumes it.

[Zarxrax]

I was going to try the MakeAVIS utility, but when I run it I get an error "failed to initialize avisynth". Do you have to have Avisynth 2.5 or something?

[athos]

I made a new build today. As Web1000 seems very unreliable (I cant even get in myself now!) I have asked Swede to mirror this.

It is the same CVS checkout as the last build, since there have been no updates to the CVS since 20030416. Therefore libavcodec.dll, libmpeg2_ff.dll, libmplayer.dll and TomsMoComp_ff.dll are exacly the same, not recompiled.

This time I did use the flag /QaxW to let ICL use processor extension (MMX/MMX2/SSE) which might provide some speed increases for non-optimized filters. Most likely there be few or no noticable improvements from this. Also, the usage of these extensions are not required, so it should still work on older processors.

I also managed to get the config page working without ffvfw! However, this is done through a pretty ugly hack, it seems the problem was in a function that tries to load ffvfw.dll to see if it is present, and if so, returns "true", else "false". I simply changed it to always return "false". I think this will only affect the jpeg output of the Grab function, but there might be other bugs. You might want to wait for milan to do a proper fix for this bug.

To conclude: bugs in this release might be caused by me.

Edit: uploaded it to SourceForge (http://sourceforge.net/project/showfiles.php?group_id=53761&release_id=154364)

[Gaia]

Just a little note, if you're using Win98se/Me you're still forced to use Xvid decoding in this latest build.

[Swede]

Originally posted by athos
Edit: uploaded it to SourceForge (http://sourceforge.net/project/showfiles.php?group_id=53761&release_id=154364)
Ah, then you might not need my mirror but I'd put it there anyhow. http://athos.leffe.dnsalias.com/ is for your builds.

[Animaniac]

Is chroma level fixing going to be implemented again? I believe it was in a much older build, and I'd like to see it again. Luminance level fixing alone seems to cause a lot of image loss in bright sections of the video, and maybe chroma level fixing would fix that. I hate the white fuzz DirectShow filters cause. >.< Thanks and awesome work.

[((( atom )))]

i still get smearing with ffdshow from 21.04.03 and simple idct using koepis build of 05.04.03 and ffvfw from 15.04.03.

does anybody know if the qpel-situation is solved under linux meanwhile? i personally don't use anything else for watching my movies and just for editing i don't care..

[athos]

Update: I took a deeper look at the code, and I think I managed to do a better fix to the ffvfw problem, a fix which should allow ffvfw to be used if present. I have mailed my solution to milan. I also compiled using ICL7.1 which allows the compiler to create separate code for MMX, SSE and SSE2 and then choose at runtime which to use. There is also generic code for processor which have none of these. This should allow Pentium MMX/II/III and Athlon (with SSE) users to take whatever benefit this compiler can create. Previously it only created Pentium4 and generic code.

I screwed up when sending this file to sourceforge, so for now it is only available at http://athos.leffe.dnsalias.com

Good night everyone.

Edit: Up on sourceforge now.

[Animaniac]

I'm not sure what to make of this, whether it is a bug or if is the correct behavoir. ffdshow seems to choose the YUY2 colorspace over YV12 colorspace even when video is encoded in YV12 (XviD). Is this what should expected? Thanks.

[athos]

Good news: milan has fixed the Win98 vs libavcodec bug, will be in next release.

[ECY]

wow that's great news.
hope it will be release soon

[esby]

My problem with the config was gone with reinstalling ffvfw without theora & mpeg1/2 support.

But anyone experienced a '1 frame lag'
when using ffvfw as decoder.
Meaning it will put as first frame
the one it has somewhere in buffer. ( from last clip decoded)
and for the second the first that should be used, etc.?

(I noticed that with dvx5 decoding)

esby

[MoonWalker]

Originally posted by Animaniac
I'm not sure what to make of this, whether it is a bug or if is the correct behavoir. ffdshow seems to choose the YUY2 colorspace over YV12 colorspace even when video is encoded in YV12 (XviD). Is this what should expected? Thanks.

Are you using DVobSub for subtitles?? If so, try changing the colorspace order at the config tab of DVobSub..

MoonWalker

[sapient]

Hi,

The new version of ffdshow has all the codecs (except the last 2) greyed out. I have win98, and I haven't installed ffvfw, divx or xvid. All previous versions worked without any of those installed, making ffdshow all anyone needed if he only wanted to watch and not encode mpeg4 clips. Why the change?

sapient

[Animaniac]

Originally posted by MoonWalker
Are you using DVobSub for subtitles?? If so, try changing the colorspace order at the config tab of DVobSub..

MoonWalker

Hm you were right, the order was backwards there, but it still chooses YUY2. I didn't think that it would affect the video when subtitles aren't present. I'm also using Tobais's SubTitDS. That filter seems to always load, could it be the problem?

Edit: Yeah, uninstalling that fixed it. DVobSub can handle OGMs on it's own now, so that's great. Thanks.

[athos]

Originally posted by sapient
Hi,

The new version of ffdshow has all the codecs (except the last 2) greyed out. I have win98, and I haven't installed ffvfw, divx or xvid. All previous versions worked without any of those installed, making ffdshow all anyone needed if he only wanted to watch and not encode mpeg4 clips. Why the change?

sapient

If you read just a few posts up you will see that this is a known problem with ffdshow and win98, and it has been fixed and will be in the next release.

[Alxemi]

Hi all
I´ve been reading the forum and i´m a little confused..
I use win98 and i know the libacodec bug, the question is
It´s because this bug i can´t change the IDCT (forced to Xvid)?
The Qpel improvement in xvid decoding is only active using Simple IDCT, is´nt it?

Thank you all, and especially to ffdshow/ffvfw developers

[Alxemi]

I have mirrored ffdshow-20030422, maybe it helps somebody

http://alxemi.cjb.net//ffdshow-20030422.exe

[CruNcher]

im useing the new ffdshow-20030422.exe and experienced a strange problem with an older XviD encode 0.9 release stable simple profile it only displays Grey no picture only Grey could somebody test his old 0.9 encodes ? viewing through xvid.dll unstable works fine but ffdshow fails

Edit: Ok got around the problem useing ffdshows autodetect feature thx Cult for the tip :)

[athos]

I put up a new build on SF:
fixed dll checking = ffvfw not required, libavcodec works under Win9x

[Alxemi]

Great News!

I confirm that libavcodec is fixed. Now I´ll make QPEL comparisons :o)

Thank you athos and all developers

[gamr]

divx5 decoding under win2k (with and without use xvid ticked) not working. divx 5.02 installed, when i untick all the divx's it plays fine again. was working with 20030418.

on a lighter note, xvid works well :)

Edit: fixed, autodetect had to be ticked (unticked it playing with xvid goodies)

[TNM]

Originally posted by athos
I put up a new build on SF:
fixed dll checking = ffvfw not required, libavcodec works under Win9x
I couldn't access sourceforge :( Is there any other place where I can get this new build ? Thanks :)

[kilg0r3]

I would really love to see adaptive postprocessing implemented into ffdshow. IMO this is about the only advantage the rv9 has over xvid and the like.

Adaptive PP would mean that the strength of PP is tied to the amount of compression applied to a frame, which is indicated by the quantizer. So there is no need for difficult calculations involving resolution, motion and bitrate.

It would have to take into account the difference between b-frames and p-frames because b-frames usually look better at higher quants (never understood why btw). This could be accomplished by a simple offset parameter.

I like the idea:)

[milan]

But this is already present in ffdshow. Quantizer array is passed to postprocessing routines (both mplayer and Nic's) and it's their responsibility to properly use it. mplayer postprocessing routines even handle the b frames differently.
However, the quantizers for whole frame are constant unless you use some adaptive quantization during encoding which AFAIK common in MPEG2 and available in XviD and ffvfw, but not widely used.

Or do you mean that more image processing routines (like sharpenning) should be controlled by quantizers?

[kilg0r3]

It is _very probable_ that I am just making a fool of my self again.

I always thought that the amount of PP applied to a frame depends only on the values entered in the config dialog. In this case a frame with mean quantizer 2 would have been post processed in the same way and to the same degree as a frame with a mean quant of say 8. If this is not the case, I should better shut up and start actually using and experimenting with PP.

I have not really used PP very much, but I remeber having strange problems with it. For example, instead of making blocks less visible, it caused them to flicker.

Does anybody know what's the difference between mplayer's and Nic's PP on the one hand and RealOne's on the other. IMHO the PP of R1 hides blocks much better than the other two. :confused:

[milan]

The "processing strength" slider on the postprocessing page controls how ffdshow modifies the quantizer array before passing it to postprocessing routines. This is primarly targeted for mplayer postprocessing routines, because Nic's postprocessing has X and Y threshold controls. Mplayer postprocessing routines have some other parameters (not exposed in GUI currently), but my tests showed, that it's not possible to fine control, for example, the deblocking using them.

I'm not using Real so I can't compare its postprocessing to ffdshow's.

[kilg0r3]

Thanks for the explanations. :)

[Rober2D2]

I have made some test with Xvid + BFrames + Packed bitstream.

ffdshow version: 21-04-2003
xvid: Koepi 05-04-2003

Packed bitstream problem seems to be semi-solved now. Frames are displayed in correct order when xvid library is used to decode.

It is not completely solved without xvid, as ffdshow already makes a mess with frames order. Anyway I noticed an improvement as it doesn't happen with every sequence containing b-frames (It seems that is solved for some cases only)

[Valky]

Hmm..this latest build very well with divx and xvid codecs. Mpeg1 doesn't still work.

But something weird is happening..how come all my encodings and other movies look so much better now? I mean I have some poorly made films with older divx 3.11 movies where I know there is lot of trash on some scenes. I was going to test these blur/soften -filters, but all the movies look better already..I dont say that this is a bad thing, but it's almost like there is already some luma soften used even without any post processing?

Also the default PP-strength is set to 256 by default instead of 100. Any reasons for that? And I also noticed that using soften or luma soften in blur/soften section they all need much higher values to do anything than previous ffdshow I had from 2002. They are working, but e.g. Luma soften in previous version began to blur too much at settings above 100, but now movies are still watchable at setting 1500.

So what was the ratio compared to previous version from last december?

My main concerns is however, why all movies so look good now? (I can't believe I am actually complaining about this) :)

It's like there is some heavy post processing hiding somewhere inside the software..

[CavalloPazzo]

What about internal XVID deblocking? As anyyone tested it?I've done a little test and I like it: it seems it only smooth where it's necessary. I've tried to reach the same results with nic PP changing the X and Y Thr. value, but without success. It smooth more and sometimes has more blocks.
Is it possible to include that algo?
Could it be possible to use, for example deblocking from Nic and deringing from mplayer? I'm asking this because I found Nic's method better for deblock, but too aggressive for deringing, and it's not possible to configure deeringing with Nic.
I know Milan is working on FFVFW, and I know feature request is probably very long, so thanks anyway for your great work.

[mf]

Originally posted by kilg0r3
I have not really used PP very much, but I remeber having strange problems with it. For example, instead of making blocks less visible, it caused them to flicker.
I've had this too. I simply switched to Nic's instead. For anime I usually overpostprocess like a bitch cause it doesn't really matter anyway (not much detail to be lost), but mplayer's PP really coughs on that. The deblocking gives flickering blurred macroblock edges on seemingly random places, while Nic's just gives a smooth postprocessed picture. Btw milan, I love the AVISynth function, I now have a Conv3D in my ffdshow by default! :D

[codecmax]

OK guys, I managed to download ffdshow-20030424 and I am wondering if this is the best codec for playing video files now?

I am kind of confused over whether if there is a need for the FFVFW now or if there is another version in a few days time.

I like many others would like the best way to get the best video. So any help rendered is much appreciated. :D

[Psych]

Is it just me being stupid, or is that even when ffdshow is set for all raw video, it doenst come up in bplayer's filter list?
this is a real pain since for some reason all my mpeg's play upside down in here, and ffdshow's flip would be the solution...
is this a bug in bsplayer or ffdshow?

[athos]

Originally posted by codecmax
OK guys, I managed to download ffdshow-20030424 and I am wondering if this is the best codec for playing video files now?

I am kind of confused over whether if there is a need for the FFVFW now or if there is another version in a few days time.

I like many others would like the best way to get the best video. So any help rendered is much appreciated. :D
IMO ffdshow is the best decoder for mpeg-4 files. It is fast, has lots of options, postprocessing etc and it handles all mpeg-4 (divx345+xvid etc). ffvfw is _not_ needed with this latest release.

[oddball]

I'd like to see something changed in the way ffdshow does it's resize. Currently you can set it to resize if it meets a specific criteria, like being larger than 640x480 etc. The problem is that if you set this with widescreen sources it messes up the aspect ratio. To give an example.

Movie is 704x384. I wish to resize it to 640x while maintaining aspect ratio. Now I can manually set that using a resize option but I have to work it out and it's a pain. If resize is left at default of 640x480 the aspect will look wrong for this movie ratio.

What I would like to see is an extra resize option that does a resize on the horizontal that you can specify like 576x or 640x and ffdshow auto resizes the vertical resolution to maintain aspect ratio.

Am I making any sense here?

It would save me messing about all the time with resize settings.

[Blight]

oddball:
There is a maintain AR setting in that resize dialog...

So, while you may resize a 320x160 to 640x480, it will in reality be resized to 640x320