ffdshow development [Archive] - Page 23

Leak

20th May 2004, 23:19

Originally posted by athos
Thanks for the feedback.

Since the changelog mentioned SPP deblocking being fixed on SSE2 machines I just had to try it out - only to find that it eats my 2.4GHz P4 for breakfast playing a 720x400 XviD encode. It'll use 80-90% CPU when I let it deblock luma only, but if I go any higher it starts getting jerky as hell... whoa... :eek:

Does it somehow not use SSE2 instructions at all or is this the expected behaviour? :confused:

np: While - Spark (Lock)

Xenoproctologist

21st May 2004, 16:57

Originally posted by Leak
Does it somehow not use SSE2 instructions at all or is this the expected behaviour? :confused:

It looks like it's just SSE at the moment. Not to say that it isn't expected behavior as well -- it appears to be doing a boatload processing per frame, relative to the fairly-lightweight mplayer postprocessing. I wouldn't count on this being practical for realtime use until GPUs become practical for general-purpose computing.

Andy2222

22nd May 2004, 03:23

Originally posted by Xenoproctologist
It looks like it's just SSE at the moment. Not to say that it isn't expected behavior as well -- it appears to be doing a boatload processing per frame, relative to the fairly-lightweight mplayer postprocessing. I wouldn't count on this being practical for realtime use until GPUs become practical for general-purpose computing.

yeah it realy consume lots of cpu power, btw for the intrest the code is not using SSE instruction's. Like 90% of all asm ffdshow routines they are written for MMX/MMX2 mostly. So most function's dont use the SSE/SSE2 or SSE3 registers/instructions.

PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it?

avih

22nd May 2004, 09:43

Originally posted by Andy2222
...PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it?

i'd second that. it got me interested after Neo Neko said he's using it, but i don't quite get what it does. (btw, Neo, if you're reading this, i totally missused the filter, so my images on the other thread with SPP are meanningless, sorry ;) )

it seems to reduce the resolution quite heavily (4x on each axis imo) where there's noise, but i'd like to read some more about it. has a very interesting potential imo.

Vitos

22nd May 2004, 10:18

Originally posted by Andy2222
PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it? [/B]

Google sometimes can be very helpful:
http://www.hydrogenaudio.org/index.php?showtopic=19578&

And for those who want to go straight to the source:
http://www.utdallas.edu/~aria/papers/vlsisp99.pdf
http://www.utdallas.edu/~aria/papers/spl03.pdf

avih

22nd May 2004, 10:36

thx Vitos. i did google, but appearantly, not well enough (shame on me). thx again.

ps.
welcome to the forum ;)

Xenoproctologist

23rd May 2004, 00:12

It doesn't look like turning deringing on with SPP deblocking actually does much of anything -- the filtering effect of SPP deblocking is strong enough to clear the dering threshold.

Thoughts:
1). SPP deblocking is sabotaging deringing. Swap filter order when using SPP deblocking.
2). SPP deblocking does a good enough job of deringing on its own, and deringing with SPP deblocking has issues beside that (see below). Disable deringing when SPP deblocking is enabled.

Approx. CPU Penalty for SPP @ 640x480@24fps (Athlon XP Barton):
Horiz Luma Deblock = 400 MHz
+ Vert Luma Deblock = 700 MHz
+ Horiz Chroma Deblock = 1500 MHz
+ Vert Chroma Deblock = 2100 MHz
+ Luma Dering = 6000 MHz(!!) (guesstimated from framerate)
+ Chroma Dering = 11500 MHz(!!!) (guesstimated from framerate)

Unless I'm missing something (entirely possible -- my C knowledge extends to interpreting from context only), SPP deblocking isn't using it's own deringer -- it's just using the standard Mplayer deringing filter, which is pretty light-weight. If this is so, what the heck is eating up so many CPU cycles when deringing is turned on while using SPP deblocking? Something is very not-right here.

avih

23rd May 2004, 00:28

actually, after reading both papers (pdf), and watching spp-filtered results, i can't see a direct relation of the papers to this spp filter. for my eyes, when using strong spp filter (slider to the right) it reduces the resolution. on the other hand, maybe that's the effect of many averaging over 4:3 px range, don't know. the spp entry on the mplayer man say's it's a 'simple postprocessing' (i wouldn't call it simple though) and it has the option to force quants (which does support the idea that it's indeed based on those papers).

yaz

24th May 2004, 13:25

i use this cute litte stuff for awhile for serving my avisynth scripts to command line (libavcodec) encoders. but with the newest releases i got only a steady ICDecompressError only. the very last compile being able to serve was 040424 no success since then. what'd been changed in this respect & how can i follow that changes. say, how should i modify my mencoder codecs.conf for making the new ffdshow.ax work ? or should i make configuration trick ?
what i noticed, the avis made by the newest makeavis (0405020) can be served with any(!) ffdshow before 040501, so, i guess sg's changed within ffdshow. but what?
the bests
y

malkion

25th May 2004, 22:29

guys, help, there are like 56 pages to ffdshow development.

would it be possible to request ffdshow read the aspect ratio info generated by xvid 1.0 and auto resize the video?

Neo Neko

26th May 2004, 01:05

Originally posted by malkion
guys, help, there are like 56 pages to ffdshow development.

would it be possible to request ffdshow read the aspect ratio info generated by xvid 1.0 and auto resize the video?

Yes. You can do it already. Just not with the AVI container. Encode your video to AVI as always. Then convert it to MP4 either using GPAC or the Graphedit->3ivxMux->MP4 methods. When played back in WMP, Quicktime, Real Player, or Mplayer the video will scale to the correct AR.

malkion

26th May 2004, 11:37

Thanks for the quick response Neo Neko.

I have a 2.4ghz 533FSB P4. With mp4's have u noticed there's a bigger cpu hit? This is in reference to HDTV source encodes. I can play avi's seamlessly, but mp4's will freeze now and then. However, DVD res can still play rather well. This was the reason I was hoping ffdshow can read AR information from an avi. Might my request still be valid then?

igor1st

28th May 2004, 06:52

Originally posted by athos
Neo Neko, that might be due to the -mfpmath=sse flag. Perhaps I should loose that one for next build.

Also, I noticed that at least mplayer is being built with -ffast-math flag (frome the makefile in the CVS). Perhaps that is not soo good, could lead to rounding errors?

Thanks for the feedback.

I confirm the blocking-problem with latest p3-build reported by Neo Neko. This not exist with regular build.

Also I want to notice some other problem with different compiles: most versions ffdshow have problems with mplayer's pp on some xvid-encoded cartoons/anime - flickering image. The strength of flickering can decrease by switching decoder to xvid and/or switching another method of pp (SPP hasn't flickering at all). Only one version of ffdshow with which flickering not occure - build 20040514.

Didée

28th May 2004, 08:30

This I wanted to ask for a pretty long time now, but never gotten around:

Can someone confirm that there are problems when ffdshow is set to decode "Raw video", to hook it up after mpeg-2 decoding? I have the biggest problems with this, since ... dunno, half an eternity :( (for about a year, with any version of ffdshow)

Test sources:

- DVB captures
- ffmpeg/QuEnc encodes
- CCE encodes

Decoders:

- CyberLink
- InterVideo

Possible results:

- Player vanishes (both decoders)

- Garbled green video (only /w InterVideo)

- Audio plays, but video freezes on first I-frame. On random access, again freezes on I-frame (both decoders)

- [sometimes] works as expected (both decoders - more often Cyberlink, very seldom /w InterVideo)

That behaviour is about the same on my two machines (Athlon-XP, Celeron-2600), and it's driving me nuts! I just cannot get ffdshow to work reliable as post-processor, if it is hooked after the mentioned mpeg-2 decoders.

That's a major concern for me, since playing video files without ffdshow makes me feel like ... do you know those white jackets with the very long sleeves ? ;)

I've tried all input/output colorspace options of ffdshow, overlay settings as well, and a good variety of different players. No success.

Are my machines joking on me, or does anyone have the same problem?

- Didée

Andy2222

28th May 2004, 09:43

Thats a know problem with those decoders, for the intervideo decoder u have to add a dmo filter (normal abstract at setting 0) beetwen the decoder and ffdshow. For the cyberlink decoder im not sure but there was a fix also.

so u can use:
windvd decoder->abstarct dmo filter->ffdshow
sonic decoder->ffdshow
elecard decoder->ffdshow (if u can live with the red chroma bug)
opensource mpeg2dec->ffdshow

all this works

Didée

28th May 2004, 10:15

Thanks for pointing that out, Andy. I wasn't really aware of that issue, since I never heard anyone complaining about it. (But 50 complaints each month about XviD over/undersizing :rolleyes: )

Okay, I think I'll get the combo InterVideo/ffdshow working then - will check this weekend.

However, I'd be more interested in getting the Cyberlink filters to work with ffdshow. For example, I notice that the WinDVD filters tend to produce pulsation in dark sequences (frequency = GOP length), sometimes even annoying. With the Cyberlink filters, the same sequences appear much more calm...

Why is everything related to mpeg-2 so cumbersome !?

- Didée

Neo Neko

28th May 2004, 10:27

Originally posted by malkion
Thanks for the quick response Neo Neko.

I have a 2.4ghz 533FSB P4. With mp4's have u noticed there's a bigger cpu hit? This is in reference to HDTV source encodes. I can play avi's seamlessly, but mp4's will freeze now and then. However, DVD res can still play rather well. This was the reason I was hoping ffdshow can read AR information from an avi. Might my request still be valid then?

I have not noticed more CPU required with MP4. But I don't have HDTV material to test with. :p There can be some hackery done with AVI headers to have working AR resizing. But there is no standard method which causes problems. Native FFMPEG and MPLAYER can read MPEG4 streams in AVI and do AR resizing. Directshow based players can't. An unfortunate simple fact of life.

malkion

29th May 2004, 00:33

thanks, neo neko for your view point.

however, i dont think programming AR resizing into ffdshow to recognize avi streams would be that difficult. believe me, i am requesting this because i've already tried existing AR resizing methods and players for HDTV sources. mplayer and VLC can not playback without stutters for 1280x720 material for my computer.

ffdshow can playback avi's at 1280x720 without any stutters whatsoever, except during high cpu usage. it would be just fantastic if ffdshow can resize according to AVI AR pixels.

Andy2222

29th May 2004, 02:59

oki im finaly happy with some of my asm optimized code and want to share the result with u all.

PLZZZ keep in mind that this is a prerelease version for testing only (pls dont make the download link public or at least use a own mirror)

NEW ffdshow build ffdshow-20040529a.exe (the "a" stand's for testversion, so dont kick me if it crash)

Whats new in this version? (its a i686 build and u need MMX2)

- MMX2 optimized denoise3d filter (only the "HQ" version for testing)
- some minor asm codechanges wich "should" improve performance
- xvid IDCT as default
- AC3 ffdshow audio filter disabled by default
- my old overlaymixer fix

- libavcodec memory leak fix by Andrew Ivanov
- DwString memory leak fix by Andrew Ivanov

Now i need your help! Post bugs&problems here.... i mainly need input how the new denoise3d code work (if it's faster on your machine or not) best is u use the filter AFTER the resize for testing.

I need input how the filter run's on P4 and P3 CPU's since i could just test on my AMD-XP. I tryed to avoid some P4 problematic code but not sure if it works 100%....

u can grab my version here:
http://mitglied.lycos.de/ieggei2/ffdshow/

PS: if the version runs fine i will release a full version (with some more code optimisation) and send the code to athos too.
Im working on the resizer now, my goal is to get the cool lanczos4 code from avisynth in ffdshow and see what i can do for speed. If im realy lazy i might try to build and code some AMD64 stuff since i like this CPU and want to play around with it :)

Neo Neko

29th May 2004, 03:35

Originally posted by malkion
thanks, neo neko for your view point.

however, i dont think programming AR resizing into ffdshow to recognize avi streams would be that difficult. believe me, i am requesting this because i've already tried existing AR resizing methods and players for HDTV sources. mplayer and VLC can not playback without stutters for 1280x720 material for my computer.

ffdshow can playback avi's at 1280x720 without any stutters whatsoever, except during high cpu usage. it would be just fantastic if ffdshow can resize according to AVI AR pixels.

Ok correct me if I am mistaken here. You are trying to play mp4 in VLC or the dog slow Win32 Mplayer binaries. Would that be correct? Would it further be correct to assume that you are saying that in both of those players at that resolution the system can't handle playback and resize. And that it has nothing to do with the container format per say.

If all that is the case have you tried the 3ivx directshow filters from http://3ivx.com? Did you know that they allow playback of MP4 in WMP and that in conjunction with them ffdshow will get the queue to resize on playback to the propper AR? If you have tried this and it still is a problem let me know as I would like to know. But from what I am seeing this is something you have not tried.

Andy2222

29th May 2004, 05:22

hi all, i have a question about the AMD64. Im about to get me this cpu today :)

If i use this free WindowsXP 64 version from the MS site will the AMD64 run in long mode? (the mode i can use the extra registers?)

What about all my old Software? Can i run any "old" 32bit software without penalty in this "long" 64bit mode or do i have to worry about something?

Btw what about drivers? Can i use "old" 32bit drivers on this 64bit OS or mix 32/64 drivers?

malkion

29th May 2004, 06:19

@neo neko, again, thanks for your views, but i believe we have a failure to communicate. i am not requesting AR auto-resize for a container which already recognizes it. please re-read my first post regarding this matter. i would like to request ffdshow be able to read AR info from an avi stream and resize. however, thank you very kindly for your time.

best wishes.

Andy2222

29th May 2004, 06:32

malkion

29th May 2004, 07:13

thanks andy, say this, an avi stream anamorph size is 960,720 encoded with xvid using 16:9 sized pixels. having ffdshow directly resizing it to 1280,720 from the AR info.

as neo neko has pointed out, this already works with a mp4 stream, as yet still unavailable with avi stream.

crlorentzen

29th May 2004, 08:17

Milan, or anyone else, do we happen to have an idea when then next official release will be? One that is compiled and placed on SourceForge.

besides when it's ready.

Sorry if anyone feels that I am out of line, but I do not feel confortable downloading any of these "third-party" compiles.

Andy2222

29th May 2004, 08:40

Originally posted by crlorentzen
Milan, or anyone else, do we happen to have an idea when then next official release will be? One that is compiled and placed on SourceForge.

besides when it's ready.

Sorry if anyone feels that I am out of line, but I do not feel confortable downloading any of these "third-party" compiles.

Those "third-party" compiles base on milans "official" work and they are out of the cvs wich milan updates. Athos add's some fixes/settings and compiles the code for u. The version's Athos release are as official as the old one on the SourceForge page. Milan just dont update the compiles anymore, i bet he has enuff work to do with the code already.

Besides Milan would take the same steps Athos do to compile ffdshow...

PS: My version adds some new code and if it works well i will send those changes to milan and the code will be integrated in later "official" versions.

esby

29th May 2004, 08:44

Andy2222 went first on the reply...
but i noticed only when i posted the message :)

Well there is not s really a matter of downloading third parties build....

Do you get your xvid from xvid.org (getting source) and build it,
or do you use koepi, gomgon or nic build (or add any official third party site.)

That's the same here.
Milan does not have much time to compile and provide builds,
and since Athos and the others are providing them, it works.

esby

PS: Of course, that won't remove the fact, they are just 'builds' and
might inherit the bug or problems linked to the cvs branch they are from.

pankov

29th May 2004, 10:13

I've been following this thread for a long time but I'm a little bit lost now and I'll be happy if someone can clear a few things for me.

1. A long time ago a "green" problem when resizing with FFDShow was discused and I'm not sure it was fixed. Or atleast I still see it on my NVidia card using the latest builds

2. I'm not sure if that's not connected with the previous but when I use FFDShow to decode XviD content I get worse quality than when I use the XviD Decoder. Is this normal?

3. It's probably the same as the problem mentioned from malkion but I'll explain it my way.
Often I make captures from my DVB card (using MyTheatre) and they have non 4:3 AR (for example 720x576) when I try to play them using the Elcard MPEG2 Decoder + FFDShow for PP I get the picture stretched vertically. When I use Intervideo's DirectShowFilters everything is OK. If I use only the Elcard decoder there is no problem too. So I suppose the problem is in FFDShow. Is this true or I'm making some kind of mistake?

4. Is there a place where I can find some options of FFDShow explained? I'm talking about the "Preset Autoloading" priorities and the "Remote control API"

I hope someone will be able to help me in my "quest for knowlage"
:)

Andy2222

29th May 2004, 11:16

1. the green bug was fixed, but caused a new "horizontal line" bug (just use "bicublin" or resize Y to a direct multiple from the org. resolution, to avoid this new bug)
The green u see comes prolly from the VMR9 render mode, i dont see green using the overlay mixer on my nvidia card.

2. Its a libavcodec problem but im not sure what cause this, it also is only visible on very rare movies/encodes. U can use the xvid decoder for decoding and ffdshow as raw filter. On fast cpu's the diff. using libav over xvid decoder is just about 5-10% lesser cpu usage. (be sure xvid deblock is disabled)

3. Its an ffdshow problem, just make sure u have "use overlay mixer" enabled at the output pane and try use "keep org. Aspect ratio" at rezise settings.

4. dunno :)

Neo Neko

29th May 2004, 11:26

Originally posted by malkion
@neo neko, again, thanks for your views, but i believe we have a failure to communicate. i am not requesting AR auto-resize for a container which already recognizes it. please re-read my first post regarding this matter. i would like to request ffdshow be able to read AR info from an avi stream and resize. however, thank you very kindly for your time.

best wishes.

:| I know what you are asking. But it is basically not gonna happen. :| FFMPEG through Mplayer can playback AVI containing MPEG4 streams with the propper AR. And perhaps you are aware that ffdshow is based heavily off Mplayer and FFMPEG. So if they can do it and they are largely what ffdshow is why can't ffdshow do it? The answer is simple. It can. It's not ffdshows fault. Ffdshow can do what you want just fine. It is a Microsoft Windows or more specifically Microsoft Directshow problem. And it pertains specifically to the AVI parser. A parser which Microsoft is never going to update since they don't use AVI any more. And a parser that basically no one else is going to update since no one should really be using AVI for MPEG4 anymore. So I guess what I am saying is that if you stick with AVI you are thurroughly up the creak without a paddle.

I generated my own HDTV resolution material from video I captured on my own PC. I then encoded it and put it in an MP4 file. Under the latest publicly avalible win32 Mplayer binary the video was so choppy as to be unwatchable. With the latest VLC there was a slight jerk every so often as a few frames were skipped to catch up. Under WMP using the 3ivx MP4 splitter with ffdshow decoding the actual video it played back smooth as silk with the correct AR and no skipped frames. This was on an Athlon XP 2500+ Barton core. So yes it is a bit faster than yours. But with WMP and the same content in either AVI or MP4 CPU usage was about the same. The only difference being that MP4 allows for propper AR.

malkion

29th May 2004, 17:59

@neo neko, thanks for your atttention to my query. your last post was very informative and thoroughly answers my question. u didnt have to go to the lengths of verifying HD encodes through mplayer or vlc, but i appreciate it very much. thanks for clarifying.

best wishes.

Andy2222

30th May 2004, 05:31

mhh so no1 with a P3/P4 can test my version for the denoise3d speed, i realy need feedback on this?

Defiler

30th May 2004, 06:58

I've tried it on all my non-Xeon P4 CPUs, and:
A) Denoise3D works properly, and has a noticeable effect on the video.
B) Enabling it costs almost no additional CPU time. At least, nothing noticeable with the usual tools, on a P4 2.4GHz Northwood.

Andy2222: While you are updating the ffdshow code, could you put some comments in? The #defines are nested so deep that it's hard to understand what is going on without a major time investment.

One bug: When you click on the "preset" ComboBox (the one that has 'default' as the only entry, after a clean installation), the width of the drop-down is much larger than it needs to be. The width of that dropdown should be ("width_of_text" * "screen_dpi") + "width_of_scrollbar"

Edit: Yes, I had "HQ" enabled for the Denoise3D filter.

Coroner

30th May 2004, 07:09

Andy222

I have tried your build as well. My findings are much the same as Defiler's.

On a 640x480 Divx5.1 encoded file with denoise3d default settings HQ I am seeing a small perf hit of 5%-10% on a P4B (533Mhz) 2.8Ghz. Very good speed no visual anomalies detected with it on so far. The perf hit was taken from Taskmanager figures, so please take it with a very large pinch of salt.

Now can have it on all the time, thankyou very much for this optimisation.

Andy2222

30th May 2004, 07:23

Originally posted by Coroner
Andy222

I have tried your build as well. My findings are much the same as Defiler's.

On a 640x480 Divx5.1 encoded file with denoise3d default settings HQ I am seeing a small perf hit of 5%-10% on a P4B (533Mhz) 2.8Ghz. Very good speed no visual anomalies detected with it on so far. The perf hit was taken from Taskmanager figures, so please take it with a very large pinch of salt.

Now can have it on all the time, thankyou very much for this optimisation.

ah thats nice i was not sure how the code perform on P4 ... i still hate writing asm code for a CPU i dont own and cant test on.
To bad my new AMD64 system wont run... no video.. prolly broken mainboard or bad memory. But this fault gave me time study the AMD64 techpapers and im realy excited what i could do on this machine. As soon as i get it working and winxp 64 installed i will try rewrite the laczos resizer for AMD64, i want to see what 64bit AMD power can do for ffdshow :)
I realy dont like how all the HTPC guys proclaim that u need a P4 cpu with 400+ Mhz DDR ram to run ffdshow ... I just know its all a matter of clever coding not hoursepower. So lets support AMD :)

@Defiler could u be more specific what u mean with more comments? (hich partss?) There are about 200 cpp files... and prolly 500 defines
Btw u are not alone it took me months to get a small clue whats going on in ffdshow...

Defiler

30th May 2004, 07:41

Originally posted by Andy2222
@Defiler could u be more specific what u mean with more comments? (hich partss?) There are about 200 cpp files... and prolly 500 defines
Btw u are not alone it took me months to get a small clue whats going on in ffdshow... Coming into ffdshow "cold", the hardest part (for me) is understanding how the incoming video "flows" through the code. It's hard to separate the "DirectShow pin connects from here to there" code from the "Video gets decoded here" sections.
ffdshow's core portions seem to be totally obscured by the vast number of post-processing features.
I really just need a roadmap to the critical decoder features, since those are the ones that truly matter to me.

Thanks for your optimizations. The more assembly I learn, the more respect I have for those who practice it. Heh.

Coroner

30th May 2004, 07:44

ah thats nice i was not sure how the code perform on P4 ... i still hate writing asm code for a CPU i dont own and cant test on.
To bad my new AMD64 system wont run... no video.. prolly broken mainboard or bad memory. But this fault gave me time study the AMD64 techpapers and im realy excited what i could do on this machine. As soon as i get it working and winxp 64 installed i will try rewrite the laczos resizer for AMD64, i want to see what 64bit AMD power can do for ffdshow

Well, you've just taken all the indecision out of my next upgrade. AMD64 definitely now! :D Might make SPP PP useable, atm it's pretty slow but it sure looks nice. Good luck with getting your new system going.

Cheers

Defiler

30th May 2004, 07:45

Someone buy Andy2222 an Itanium2 development machine. Heh.

athos

30th May 2004, 19:19

Great work, Andy2222! Did you send your code changes to Milan?

Andy2222

31st May 2004, 10:02

Originally posted by athos
Great work, Andy2222! Did you send your code changes to Milan?

Not yet need some more feedback fist, i also want to profile the code on the AMD64 cpu tomorrow first. I will send u both the new version soon, just want to make sure that its bugfree or we possibly end up like the mplayer resizer. Aka 1 bugfix result in a new bug hehe

Blkbird

2nd June 2004, 03:12

I'm facing a strange out-of-sync problem with ffdshow (various versions from 20031128 to 20040520).

The media files in question are AVI's with DX50 video (29.97 fps for one video and 23.97 fps for the others) and MP3 audio (128 kbps stereo CBR). I use ffdshow's libavcodec to decode the video and would like to use ffdshow to decode the audio as well, but no matter if I choose mp3lib or libmad the video runs ahead of the audio (or the audio trails behind, I can't say which is the case). If I skip to somewhere in the file, the video and the audio are synced for the moment and starts to getting out-of-sync from there on.

If I deactivate ffdshow's handling over MP3 audio and use Frauenhofer, the problem disappears. Unfortunately I can't tell if the video runs slowlier then or the audio runs faster.

I use Zoom Player 3.30, but I've tried Windows Media Player 6.4 with the same result, so I'm pretty convinced the problem is somewhere within ffdshow.

Shinobu

2nd June 2004, 14:57

Hello,
i've recently spotted a bug with ffdshow vp31 decoding.
keyframes are well decoded but between keyframe it's look like broken frame (moving parts are sheeted a lot).

VP3 decoded by vp3 codec
http://satsuki.yatoshi.free.fr/imgforum/vp3.png

VP3 decoded by FFdshow
http://satsuki.yatoshi.free.fr/imgforum/vp3ff.png

i've cherched but not found this bug so if you know how to debug it ^^, i don't encode in vp3 for a long time but i've some vp3 file so if i can use ffdshow for decoding, I can skip the vp3 codec installation (sory for my bad english)

++

timeismoney

2nd June 2004, 15:39

Agree

Most of VP3 video decoded by ffdshow will show chroma block

Please take a care

Andy2222

7th June 2004, 21:55

new versions are up, a normal and a new P4 and AMD64 only version
feel free to test them :)

2004-07-06 22:00 Andy2222

* SSE2 optimized denoise3d filter (only the "HQ" version)
* new SSE2 optimized FLT_Sharpness_SSE2.dll included with ffdshow (dscaler sharpen)
* fixed memcpy ref. to the faster SSE2 version

2004-07-06 9:00 Andy2222

* fix for WinDVD CLSID crash
* set xvid as default IDCT
* disabled mlib AC3 decoder as default decoder

2004-06-06 8:00 Andy2222

* small fix in denoise3d filter (again)

2004-06-05 12:00 Andy2222

* small fix in denoise3d filter

PS: maybe some1 can provide a mirror? (or Athos can u copy those to your location too?)