dffshow filter

[NoLogo]

@milan

One short question: will asharp (by MarcFD) be included in ffdshow ? Sounds like it works pretty well, and I'd love to give a try :)
Whatever, your filter is great, keep on the good work :)

NoLogo

[Shayne]

Hi since ur here Blight i am having a problem with zoom player and the latest ffdshow

aspect ratio source 4:3 AND 16:9 no matter what set to stays at source with no resizing.

Xvid bframes is what it is decoding. I switchs to nic's dsf and the vid resizes no problem so the trouble is between ffdshow and zoom player.

[NiTroGen]

Originally posted by athos
Also note that this build is optimized exclusively for pentium4, and probably doesnt work/works bad on other processors. I wanted to try if targeting a specific processor makes any difference. If you have a P4, give it a try and say what you think. I used -march=pentium4 -mcpu=pentium4 -O3 for gcc and /G7 /O3 /QaxW /QxW for ICL 7.
Is it possible to compile the same ffdshow snapshot for pentium3? I think there are many pentium3 users out there who would like to test it. And also, P4 users could compare these two compilations and see if there is any performance improvement.

[NoLogo]

@Shayne

Maybe it's the same than with WMP6.4: have you try to change the aspect resize ratio (4:3, 16:9), then close your video and re-open it. I thought it didn't work too, untill I open one day a 16:9 movie in 4:3, a few hours after i change the ratio for another one.
Have a try :)

NoLogo

[athos]

Originally posted by NiTroGen
Is it possible to compile the same ffdshow snapshot for pentium3? I think there are many pentium3 users out there who would like to test it. And also, P4 users could compare these two compilations and see if there is any performance improvement.

Your wish is my command :) Same snapshot, P3 optimizations: http://ffdshow.sekxx.org/ffdshow-20021125-p3.exe. Should work on Pentium 4 and probably AthlonXP too.

Edit: Corrected spelling and grammar errors.

[oddball]

Corrected link http://ffdshow.sekxx.org/ffdshow-20021125-p3.exe

[NiTroGen]

Originally posted by athos
Your will is my law :) Same snapshot, P3 optimizations: http://ffdshow.sekxx.org/ffdshow-20021125-p3.exe. Should work on Penitum 4 and probably AthlonXP too. Thanks a lot, man. You're great!:D

[oddball]

Here are my results using Windows XP Pro SP1 on a P3 700 with 640MB PC133 SDRAM and a Matrox G400 32 dual head video card. Player is BSplayer 490 with overlay mode 2 enabled. All other pre-processing options are off in ffdshow and BSplayer.

Playing a DiVX5.02 anime clip at 640x480 res.

Performance monitor graph with official alpha build 13 Nov 2002 from sourceforge. Green line is CPU usage
http://www.oddball.nildram.co.uk/ffd13th.jpg

Performance monitor graph with unofficial P3 optimized version
http://www.oddball.nildram.co.uk/ffdp3.jpg

Also I tried the unofficial build from the 18th on that site and it crashed BSplay on exit and refused to play some DiVX5.02 content. Just got a blank screen with no movement of the playback counter.

[oddball]

Milan|Athos: Any chance of a rework on black borders? It eats CPU and could do with more control as suggested before.

Thanks! :)

[Shayne]

@ NoLogo

Thankyou for the response but yes i have tried that. With Nics dsf changing aspect ratio is no problem. With ffdshow it is no go. There is sometime in the direct show filter buggering up zplayer.

I have tried un n install but maybe i should do it again and make sure the house is clean.

[omol]

Originally posted by NoLogo
@milan

One short question: will asharp (by MarcFD) be included in ffdshow ? Sounds like it works pretty well, and I'd love to give a try :)
Whatever, your filter is great, keep on the good work :)

NoLogo

It is in the athos's p4 build, probably in p3 build too, and it looks great.

regards,
omol

[athos]

For this compile, ICL was only used for the main ffdshow project, and not for libavcodec. Therefore, any gains from the optimizations would be for non (hand-)optimized image filters.

For the next release I will also compile libavcodec with ICL and use the /QaxW switch for using extended instructions (while not breaking compability with other IA-32 processors). Perhaps this will make a difference for the decoding part.

[milan]

I just want to mention, that ICL compiled libavcodec won't contain any hand-optimized assembly. Only C will be compiled. I needed to compile libavcodec to have debug info which could be used by VisualStudio and other tools (BTW is it possible to generate microsoft compatible debug info with gcc?). I used it to find sources of few memory leaks in libavcodec (yes, there is >200KB memory leak after each decoded movie). However it could be interesting to compare speed of ICL optimized libavcodec and hand-optimized version.

[kilg0r3]

@milan

did you have a look at the rainbowy :) screenshots

[milan]

I know that libavcodec has problems with clips encoded with latest XviD versions (qpel, b frames in packed streams, this rainbow effect), but I'm not sure what's causing this: do these development XviD builds produce not fully MPEG4 compatible streams or it's libavcodec fault?

If you are 100% sure that XviD encoded clips are OK, send these bugreports to libavcodec developers. Sample clips can be uploaded to mplayer ftp, instructions are available at http://mplayerhq.hu. BTW are mplayer windows binaries available somewhere? It would be helpful to compare clips decoded in mplayer and clips decoded by ffdshow to be sure that problems are caused by libavcodec and not by ffdshow or mplayer.

I'm sorry for this, but I have enough work fixing and enhancing ffdshow (and maybe ffvfw) and I don't want to solve possible libavcodec bugs.

[athos]

New unofficial build is up: http://ffdshow.sekxx.org/ffdshow-20021127-icl.exe. This time libavcodec is compiled with ICL 7. I have used /QaxW switch which should make use of cpu extensions (mmx/sse etc) while still being compatible with all ia-32 processors.

You might also need this file: http://ffdshow.sekxx.org/libmmd.dll (put in ffdshow install dir).

On my computer (p4-1.3ghz) libavcodec seems slower when compiled with icl. on the bright side, the memory leak problem should be fixed, according to milan.

Edit: I also put up the same build, but libavcodec compiled with gcc for comparison: http://ffdshow.sekxx.org/ffdshow-20021127-gcc.exe. Note the new filenames, -icl resp -gcc.

[milan]

I'm sorry, but there are two memory leaks in libavcodec:

One is "by design": when libavcodec is first run, it allocates some tables which would be used for next decoding too. But ffdshow unloads libavcodec.dll after each decoding and when new movie is opened without closing/reopening player, libavcodec.dll is loaded again. But this memory still remains allocated, because libavcodec has no function to free it. Propably on Linux it gets freed on unloading dynamic library, but not on windows. I informed ffmpeg developers and maybe they'll rework this one-time initialization. If not, I'll try to do this. BTW mplayer scaling code has similar 160 bytes memory leak too.

Second memory leak seems to be caused by mingw dll initialization code. libavcodec, libpostproc and libmpeg2_ff dynamic libraries are compiled by gcc and linked using binutils' dllwrap utility. You can check makefiles if I'm doing this correctly, but when unloading any of these dlls, there is call to fflush which seems to leak some memory too. I'm not sure about the details right now, because I'm testing in on other computer. However this second leak is not present when ffdshow uses libavcodec.dll compiled and linked with Microsoft/Intel tools. Today I managed how to replace that mingw dll initialization code and will test it whether it solves the problem and can be used (I'm not very sure, because I replaced 5KB original file with one function just returning TRUE :) ). I hope it will work.

BTW all these leaks were reported by Compuware DevPartner 6.

EDIT: I'm unloading libavcodec after each movie, because next movie could be decoded by xvid or libmpeg2 and I don't want to keep libraries loaded when they aren't used. And I'm trying to not use any static or global variables in ffdshow. Everything should be created/destroyed for each instance of decoder.

[oddball]

Perhaps you could make use of this code and temporarily add it as a dll unloader on ffdshow exit?

http://lists.jammed.com/forensics/2001/10/0093.html

[milan]

I'm not sure whether this would help. libavcodec.dll gets unloaded (or at least it should be - there are still some reports about unability to play more movies without closing the player), but memory which was allocated is not freed. I think it's because the memory is allocated in "calling application space" (this is propably wrong term, but I hope you understand what I want to say) and it's freed only after closing the "calling aplication" (media player). The best solution would be if libavcodec would deallocate all memory it uses.

[NoLogo]

@milan

You talked about putting asharp (by MarcFD) into FFDSow, and I'd like to know if it's on the way, or maybe you have other priorities ?
That's not a request, just for curiosity :)

PS: your filter rocks hard !

Regards
NoLogo

[athos]

@NoLogo:Originally posted by omol
It is in the athos's p4 build, probably in p3 build too, and it looks great.

regards,
omol

[oddball]

There is something seriously screwed in the new builds icl and ccs. If I install the icl build withouth libmm.dll in the same folder it complains. If I install the ccs build without libmm.dll it also complains. If I use the icl build and drop the libmm.dll in the install folder it installs without error but then gives an error if you try to play a DiVX in BSplayer. It then nearly locks the computer up and takes several minutes of moving a jerky mouse to task manager to try and kill the player.
If I drop the libmm.dll into the ffdshow folder I don't get the error about a missing dll when I try to play a DiVX in BSplayer but I still get the near lockup and spend several more minutes trying to kill the process.
If I try to install an earlier version of ffdshow it still complains about the libmm.dll for some reason. I have to uninstall new ffdshow first.

Basically I am unable to use the latest builds. I find the fact that a dll file has to be in the install folder AND dropped into the ffdshow folder a pain in the butt.

[athos]

The libmmd.dll file is needed for some processor extensions. i meant it should be in the folder where ffdshow is installed, ie C:\Program Files\ffdshow. Or you can put it in C:\Windows\System32.

oddball: are you using an Intel processor? Because these optimization are done specifically for intel processors, and therefore might not work well on amd. Note: the libmmd.dll is used for the ffdshow.ax, ie the main ffdshow project, which is the same for both compiles. it is not used by libavcodec compiled with ICL.

I havent tried it much for using image filters, but if it doesnt add anything but trouble, i will of course not use it for alpha builds. Good thing i tried some unofficial compiles :)

[oddball]

I'm using an Intel P3 700. I am going to uninstall ffdshow and try the icl build again.

EDIT: OK things are working now. Must have been some other problem. Tried both the icl and ccs builds and they ran fine this time. However noticed that if you uninstall either of them. Even if the libmmd.dll is in the ffdshow folder the uninstall routine complains it cannot find the dll. Strange.

P.S. asharp appears to be working very well in these new builds. Previous test builds by athos for p4 and p3 had very odd artefacts in asharp mode.

[athos]

New unoffical alpha build (i'm trying to find faster yet stable and compatible compile settings): http://ffdshow.sekxx.org/ffdshow-20021129.exe.
No additional .dll should be needed, mingw memory leak should be fixed. Compiled with /QaxW (for mmx, sse etc) and /Qip (for interprocedural optimizations).

[duartix]

I really don't know from which version, but a few of my old rips now show increasing subtitle desynchronisation being OK a while back.

They are moving ahead with a 23.976 fps rip and falling behind with a 29.970fps one. Ok at 25 fps.

If could say what the problem was I'd say they are fixed at 25fps.
I'd really appreciate this issue being adressed because since the moment I started using ffdshow, I'm taking full advantage of the subtitle feature.

Keep up the great work!

(EDIT)
Well this is a strange one.
Off I was installing VobSub (just the directshow stuff) to get working subtitles (ST) again. So things were like this:

Ffdshow ST not OK.
Deactivated ffdshow ST.
Loaded Vobsub dshow.
Vobsub ST OK.
Unloaded Vobsub dshow.
Activated ffdshow ST.
Ffdshow ST OK. ?????????
Uninstaled Vobsub.
Ffdshow ST still OK.

[Smiff]

i get an instant Access Violation in ffdshow.ax with these latest unofficial alphas (AMD Duron 1.2Ghz with SSE)

[ChronoReverse]

Read: Pentium 3 and pentium optimized alphas

[MaTTeR]

Originally posted by ChronoReverse
Read: Pentium 3 and pentium optimized alphas Exactly, which means in theory it should run fine on an Athlon with SSE support.

[sillKotscha]

Originally posted by MaTTeR
Exactly, which means in theory it should run fine on an Athlon with SSE support.

and it does :D

[Smiff]

not for me it don't


edit: i'll try clearing reg

...

yep soz peeps my bad, seems it is necessary to uninstall old versions now.

works on AMD with and without SSE

[athos]

Can someone confirm that AMD support is broken in these builds? The documentation says that the code should be compatible with IA-32 processors, but I guess Intel is not too concerned with AMD compability.

I guess I should go back to the normal compile flags.

[Caleb666]

i have a few questions :)

Why would i want to replace my official DivX5 codec with ffdshow?

IS the xvid decoder that in ffdshow is the same as NIC's? if not, what are the differences? (aren't they taken from the same source code?)

thx

[MaTTeR]

Originally posted by athos
Can someone confirm that AMD support is broken in these builds? All of them have worked just fine on my dual AMD XP system. I have noticed some slight color smearing at the bottom of the screen during playback but it's rare. That problem even happens on my PIII system though but not with Xvid's filter.

[Blight]

Just a note, on the latest "official" alpha (11/13) post processing is broken. Works ok on the 10/29 alpha.

[athos]

Originally posted by Caleb666
i have a few questions :)

Why would i want to replace my official DivX5 codec with ffdshow?

ffdshow is faster, it can handle all divx and xvid versions. It has a lot of built in filters, and support for more filters and MPEG1/2 is on the way. You dont have the annoying "fastforward" effect (from DivX 4, 5) when seeking, and seeking is a lot faster than both DivX5 and DivX3.

But it is only a decoder filter, so you cannot encode with it. Use Xvid for that.


IS the xvid decoder that in ffdshow is the same as NIC's? if not, what are the differences? (aren't they taken from the same source code?)

thx

ffdshow uses the decoder from ffmpeg (libavcodec). However NIC's postprocessing code is in ffdshow, and if you have xvid installed you can optionally use the xvid routines for decoding of divx4,5 and xvid (because new improvements of xvid might not be supported yet in libavcodec).

[Pasqui]

@ Blight
Only Nic's PP is broken. MPlayer's one is working perfectly.

[Blight]

Pasqui:
No, it's not, in that build both are broken.

[Pasqui]

Actually I had no problems at all with XviD encodes and ffdshow-20021113.exe while activating mplayer's PP. My video was ugly enough (macroblocks and noise) to see it was effective.

[Caleb666]

wow athos, that's cool!

But may i ask one thing, the DivX5 codec is not open source, so how exactly does ffdshow decode it?


And may i ask what is ffmpeg/libavcodec?

thanks!

(Note: i don't encode movies yet, all i do is watch some divx's and xvids :))

[NoLogo]

I have a request that may sound a bit strange, cause it's not what's made today with FFDShow, but I think this could be quite usefull to improve decoding visual quality.

I have seen that post-processing uses to blur the images, actually, when it's at level 6, a lot (ok, maybe I'm paranoid) of details (e.g. faces, walls or roads textures) are lost in some blurred colors (especially on sharp movies). For the moment, the idea is to allow max PP on quiet scene, when CPU load is quite low, and to decrease it on hi-motion scene.
But when do we need highly detailled scenes ? On low-motion scenes, where we have time to see sharpness, whereas high PP can make macroblocs dissappear on hi-mo scenes.

So my idea (tell me if it's stupid or already implemented, but I haven't seen this with FFDShow or any PP-filter - Nic's or DivX's ones) would be to have a 'special quality mode' which would only activate PP for hi-motion scenes, to kill Mblocks, and allow max details on static scenes without adding PP. Of course, this could be mixed with a '100% cpu load' limit, for weak processors.

I hope what I have told is clearly understandable (it's late, I'm preety tired right now, and english isn't my mother's tongue) :)

Best regards
NoLogo

[Blight]

Caleb666:
DIVX isn't a closed format, it's an implementation of MPEG4 Advanced Simple profile. Same as XVID. So the bits are well documented.

NoLogo:
Doing deringing will blur your image. If your source was clean and the compressor good, you won't really see many ringing effects in the first place.

Personally, I only do Luma-Deblocking (2 notches) and don't mess with chroma and deringing.

[NoLogo]

@Blight

I agree with you, but blurring the video a little is pretty usefull on low birates and hi-mo scenes, and there's no way (or no way I know), to have full PP only with that kinda ones (where, at 650 kbps, Mblocks may be quite visible). But you should see a XviD 650kbps Ghost Dog to really understand what "progressive-PP" I'd like (love) to have. :)

Regards
NoLogo

[Vern Dias]

Has anyone else tried the asharp filter on the scrolling titles at the beginning ow either of the Star Wars DVD?

The asharp does wierd things to the letters in the intro scroll on both SW titles when the "unsharp masking threshold" is raised above 0.

This is using ffdshow with Cineplayer 1.5 and the Zoom Player front end...

Vern Dias

[Suikun]

@milan: could you add an option to the OSD which displays the quantizer of the current frame or is that technically impossible?

[drebel]

@vern dias
welcome aboard!You certainly arent a "junior" here.Hope you 'll continue contributing to this forum as with others...:)

About asharp+ffdshow+sonic(video)+windvd(sound)+zoom2.90 all i can say is that i notice a "stairstepping" effect during credits decoding,but i cant remember if the threshold was the reason.My cpu could afford asharp (duron 1GHZ)+ i really wanted to take advantage of the latest WinDVDPlatinum filters(sorry for going OT),so i had to remove ffdshow from the graph's chain (there seems to be an incompatibility either with ffdhow or with the new navigator..)

My suggestion is to post to MarcFD ,the author of asharp cause i have the feeling that is has something to do with the latest optimisations
Avisynth thread here (http://forum.doom9.org/showthread.php?s=&threadid=38436)


regards,
george

[NiTroGen]

Originally posted by MaTTeR
All of them have worked just fine on my dual AMD XP system. I have noticed some slight color smearing at the bottom of the screen during playback but it's rare. That problem even happens on my PIII system though but not with Xvid's filter.
After some tests I've done, I found that this color smearing problem (which was not rare at all) occurs with all ffdshow builds after 29/10/2002, only when the video was encoded with QPel option activated. Decoding with build 14-10-2002 is fine. I think that I read somewhere that this is a libavcodec bug.

@Athos or Milan:
Do you have a libavcodec compilation of 14-10-2002? If yes, is it posible to compile a special version of ffdshow that uses this libavcodec version to decode video, but has all new additions since that date?
I've tryied to just replace latest livavcodec.dll with the one dated 14-10-2002, but the results were funny!!!

[MaTTeR]

@NiTroGen

I haven't used Qpel in any encodes for a few weeks now and the color smear problem still occurs with the latest ffdshow builds. If I decode using xvid.dll then the problem goes away. So I suspect your right, it's a bug somewhere in libavcodec. Yes, the 13-10-2002 build works perfectly for me as well.

[NiTroGen]

@MaTTeR

I haven't noticed this problem with my "non-qpel" encodss. But just try to encode a small video with Qpel option activated and you'll see this color bleeding in almost every deltaframe.

[KyleK]

athos, since everyone suggests using the 10/13 build of ffdshow, could you please put that on your private ffdshow site? I can't find this particular build anywhere.

Thanks ;)