dffshow filter

[Rick83]

yes, ffdshow is really great!!!
and i´m very lucky with it now, i´m only afraid what would happen when for example a new divx-version comes and ffdshow could not play it and milan would not make new versions... we would have to use the shitty divx-decoder...
oh no, let us hope that will never be the case. ;-)

[milan]

ffdshow development isn't stopped. I'm updating sources almost daily (ffdshow is somewhere around 50th place in SourceForge's activity list), but it's not ready for a relase now. As you can see from TODO list, there are many tasks to finish. This doesn't mean ffdshow is unusable now. For me it works better than any previous version.
Now when ffvfw is operational, I can go back to ffdshow development. For example yesterday I imported smoother filter from VirtualDub. It's slow for realtime playback, but since it is mainly intended for image preprocessing when ffdshow is used by ffvfw it is acceptable.
Top priority for me now is to add the ability of ffdshow image processing filters to use other colorspaces than YV12 or at least to avoid unnecessary conversions. For example now when ffdshow processes external raw video (libavcodec and xvid decoding is fine) which came in YUY2 format and output should be in YUY2 format too, it is still internally converted to YV12 even when no processing is done. This has to be fixed.
Related to this is the usage of mplayer's colorspace conversion routines. They seem to be faster and have higher quality than those from XviD.

If anyone is willing to provide ffdshow compiles, it would great. At SourceForge I would like to release only stable versions.

And about possible new DIVX: I think new DIVX will be MPEG4 compatible and libavcodec should be able to decode it. If not, I'm sure Michael Niedermayer (main libavcodec developer) will implement new features as he did for DIVX 5. And in that case only new libavcodec.dll would be needed, so update could be prepared very quickly.

Thank you for using ffdshow and interesting in its development.

P.S. As a proof, that sometimes I don't want to do something important, but I like to just toying with code is feature introduced recently upon request of one user. ffdshow can now hook keyboard input and process it, so some of it's features can be controlled by keyboard. For example CTRL+ALT+S toggles subtitles. This is very experimental feature and doesn't work always - sometimes ffdshow looses that keyboard hook, but maybe it will be included in next release if i would be able to fix it. The most interesting effect is ability to seek in movie with keyboard and even in WMP 6.4 - I wouldn't believe that decoder filter can do such things.

[athos]

It's pretty small, i'll just attach it here.

Again, keep in mind that this is not a stable version. It works great for me though.

[oddball]

Hey Milan. Great stuff! Glad to hear you are still working on this. Can I add a request please? :)

I'd like to see a feature of moving the image vertically and horizontally in order to help with overscan compensation on TV outs. My TV has an annoying right shift on S-Video in which I cannot correct without affecting other video sources. I'd like the ability to shift the image to the left. Also the ability to zoom the image outside the frame would be cool too. At present you can zoom the image but only within the frame. It does not affect anything outside the borders. Cropping does not fix it either. Aspect ratio helps but is not the same thing. You can only adjust aspect ratio to create either black borders top and bottom or left and right but not at the same time. Resize also has no impact on TV out. Thus my request for the zoom and positioning functions to compensate for TV overscan (Basically I am talking about zooming and positioning the overlay I think).

In the utility DiVXG400 there is an overscan compensation where you can input a percentage. Unfortunately it does not work very well for me in 16:9 mode for widescreen TV output. I'd like to see something a bit more configureable.

Hope you understand what I mean by this :)

[mwillberg]

@oddball:

This is a bit OT, but have you tried ZoomPlayer? It sounds like just the problems it is designed for...

[athos]

Trying to attach...

[-h]

Trying to attach...

I take it you built this with .NET ..

-h

[athos]

Originally posted by -h
Trying to attach...

I take it you built this with .NET ..

-h

Yes, does it require some special dlls? I built it according to milan's compile instructions, using latest cygwin, latest nasm, Visual C++ .Net and ICL for the MS dshow SDK.

[avih]

it runs out of the box for me.
i have xp-pro (no sp1 installed), msvc6 + sp5 + pp installed.
no other 'system' upgrades.
and it runs fine.

@milan:
filters (postprocessing / temporal) seems to be MUCH slower than in the 22-6 build.

great work for the features though.

cheers

[-h]

It requires msvcrt70.dll, which only comes with the .NET runtime or Windows XP. Or if it's distributed separately of course.

I don't see why though, all the functions it's calling are the same as the older msvcrt.dll versions. I guess M$ just likes to force upgrades :)

-h

[Yusaku]

@milan: it'd be also neat if you could consider including DVobSub's subbing capabilities to ffds. I know that it does have subs, but still there's quite a difference between jaggy .SRTs and nicely animated, alpha-blended Advanced SSA. And removing DVobSub from the graph would definitely at least remove the need to copy whole picture data once.

Of course, you'd have to ask gabest if he'd allow you to include his (freely available) source in GPL program...

[Defiler]

Including DVobSub functionality would also make it easier to point people at the tools required to play something a friend has given them.

[oddball]

Athos: This latest version is GREAT! The new black borders in the aspect menu is just what I was looking for. The ability to shrink the image to compensate for overscan.
But can you do one last thing in that area? Can we have independant left/right/top/bottom instead of or as well as vertical/horizontal black borders? The ability to unlock or lock is very usefull for vertical and horizontal black borders. But if there was independant on all sides I could push the right margin without affecting the left margin (When adjusting horizontal black borders independantly of vertical black borders,it shrinks the image both sides. What I also want to do is be able to shrink the image from right to left without changing the left side whatsoever).

Hope that makes sense :)

[athos]

Originally posted by -h
It requires msvcrt70.dll, which only comes with the .NET runtime or Windows XP. Or if it's distributed separately of course.

I don't see why though, all the functions it's calling are the same as the older msvcrt.dll versions. I guess M$ just likes to force upgrades :)

-h

I'll just post that one too so everyone can use this. I assume you mean "msvcr70.dll" because i could not find "msvcrt70.dll".

btw, i have a strange problem. With my regular user profile, everything works fine. But if i switch user, postprocessing is very slow. If i disable postprocessing, everything runs fine here too..

[athos]

Originally posted by oddball
Athos: This latest version is GREAT!
This should be adressed to Milan, hes the coding genious :) I merely compiled it. Milan will release a precompiled version on the sourceforge page as soon as it is stable.

[cult]

i cant find the option to enable/disable the codecs like milan's ffdshow.Only when it installs.I am missing smthing?

[oddball]

Sorry Milan. Thanks athos.

Same request as before aimed at Milan. Independant left/right/top/bttom black borders (Maybe an extra advanced option in the aspect ratio menu?).

Big thanks!

[athos]

Originally posted by cult
i cant find the option to enable/disable the codecs like milan's ffdshow.Only when it installs.I am missing smthing?
this _is_ Milan's ffdshow, only a later version. the enable/disable codecs are in the configuration, as before. I have not changed anything, just compiled the sourcecode.

[gulikoza]

The overlay does not work for me in 16bit color mode, neither with xvid of ffdshow filter but divx decoder does not have any problems with it...Is there a possibility this could be fixed?

[milan]

I'd like to see a feature of moving the image vertically and horizontally in order to help with overscan compensation on TV outs


I think offset filter could handle this.


filters (postprocessing / temporal) seems to be MUCH slower than in the 22-6 build.


I can understand why temporal smoother is slower: it's C++ code and its speed depends on compiler. But I don't know why postprocessing should be slow: it is heavily MMX optimized code and should be equaly fast with almost all compiler options. It seem some profiling is needed... Maybe the problem is in some other part of ffdshow.


It requires msvcrt70.dll, which only comes with the .NET runtime or Windows XP. Or if it's distributed separately of course.


This is the reason, why ffdshow releases are compiled with VC6.


it'd be also neat if you could consider including DVobSub's subbing capabilities to ffds. I know that it does have subs, but still there's quite a difference between jaggy .SRTs and nicely animated, alpha-blended Advanced SSA. And removing DVobSub from the graph would definitely at least remove the need to copy whole picture data once.

Of course, you'd have to ask gabest if he'd allow you to include his (freely available) source in GPL program...


I haven't seen DVobSub's subtitles yet (most of time I use MicroDVD format), so I can say anything about possible support in ffdshow. I need to see some samples and VobSub source code first.


But can you do one last thing in that area? Can we have independant left/right/top/bottom instead of or as well as vertical/horizontal black borders?


It should be easy to add, but it will propably require new config page, because there isn't much space left in resize&aspect page.


btw, i have a strange problem. With my regular user profile, everything works fine. But if i switch user, postprocessing is very slow. If i disable postprocessing, everything runs fine here too..


This is realy strange. I will have to look, what I've changed in postprocessing since last release. And just to be sure: do you mean postprocessing page (deblocking, deringing) or ffdshow image filters as a whole?


The overlay does not work for me in 16bit color mode, neither with xvid of ffdshow filter but divx decoder does not have any problems with it...Is there a possibility this could be fixed?


ffdshow uses xvid's code for DirectShow interface with only very small changes. If there is someone who could help me with DirectShow handling, please contact me.

P.S. Another unusual feature was added during weekend: video delay. On misc. page you can set video delay in miliseconds. It can be negative or positive and can be used for correcting badly created AVI's with A/V desync (I had one with almost one second difference between audio and video). However I tested it only in WMP 6.4 and I'm not sure how other players would handle this.

[Didée]

Just to mention postprocessing speed, too:

My older PC, an Athlon 700 classic, can´t catch up any more with even one single postprocessing field enabled. (yes, deblocking stuff)
With 2002-06-17, I could crank up everything to the max, and it runs smooth.
So, something definetly has become worse.

Keep up the good work - I can hardly remember the time when we had no ffdshow ;)

[Yusaku]

I haven't seen DVobSub's subtitles yet (most of time I use MicroDVD format), so I can say anything about possible support in ffdshow. I need to see some samples and VobSub source code first.
DVobSub, filter and source, are all at http://vobsub.edensrising.com

it handles almost any subtitle format, the best of them being Advanced SSA for the moment (animations support, alpha-blending etc.) and straight VOB to video VobSub format. See PM for both formats examples.

[milan]

I just performed some speed tests of ffdshow (in graphedit with null output and "use clock" unchecked). Sample video was decoded in about 18 seconds without postprocessing and in ~22 seconds with postprocessing (deblock H, deblock V, dering). I need to check visually (difference seems too low to me) if postprocessing is done correctly, but now I don't know what could cause reported slowdown.

[avih]

@milan:
regarding the filters slow-down, i'm playing an xvid (448x288) with mp2 audio (tried with 'decode using xvid' either checked or unchecked). all settings at default.

without postproc, i get 25fps playback. when i enable postproc (only luma deringing) i get 3(!)fps. when i uncheck the postproc checkbox, the decoding speed jumps to 50/100 fps (fast toggling) for a while, and then back to 25fps.

btw, if i enable the postproc checkbox, but leave all checkboxes on this tab unchecked, it plays normally, but as soon as i enable the 1st checkbox ( either h/ v/ deblock/ dering/ luma/ chroma/ temporal/ luminance/ full_luma_range) the playback gows down to 3fps (according to the info panel).

hope it helps.

ps1: when trying any filter that's NOT in the postprocessing tab, it's working like charm.

ps2: when decoding using xvid, the motion vertors are invisible, so maybe it should be disables in that situation.

ps3: i see that the deinterlacing doesn't double the frame(/field) rate. do u have any plan for this? even a simple bob (practically 0% cpu needed for that) would be much better at 50fps (pal) than any 25 fps motion-zelus-compensated-deinterlacing ;)

keep up the great work
avi

[-h]

ps3: i see that the deinterlacing doesn't double the frame(/field) rate. do u have any plan for this? even a simple bob (practically 0% cpu needed for that) would be much better at 50fps (pal) than any 25 fps motion-zelus-compensated-deinterlacing ;)

I don't believe ffdshow can do this - the fps should be set by the AVI parser in the filter chain, not the decompressor. You'd have to be extremely sneaky to pull it off.

-h

[gabest]

It's not hard to double the frame rate, I've already tried this deinterlacing thing in dvobsub and it worked fine. Each sample needs to be sent twice with the right timestamps attached (start -> (start+end)/2, (start+end)/2 -> end)

[athos]

Originally posted by milan
This is the reason, why ffdshow releases are compiled with VC6.

I compiled the MS DirctShow samples, which are used in ffshow, with the Intel C++ Compiler. I could not get it to work with the main ffdshow project (Visual Studio would crash when i tried to load the "solution" converted with Intels slnconverter.exe). I suppose this should be possible to work around in some way.

Do you think there could be anything to gain from this? Or are most of the cpu-intesive parts in libavcodec, and thus already assembly optimized?
Originally posted by milan
This is realy strange. I will have to look, what I've changed in postprocessing since last release. And just to be sure: do you mean postprocessing page (deblocking, deringing) or ffdshow image filters as a whole?

I mean just the postprocessing page, like avih described. By user profile, I mean different users in Windows XP.

[sherpya]

CVS snap compiled with vs6 (no need for msvcrt7)
However this is an unofficial release so do not bug Milan
ffdshow-20020903.exe (http://forum.doom9.it/software/other/ffdshow-20020903.exe)

[milan]

@avih
Thank you for informations, it should be easier now to find the problem.
XviD doesn't export motion vectors information. You are right, I should disable options which aren't available or doesn't do anything depending on other settings.

@gabest
I thought about this too, but I'm not sure if it will be possible now when ffdshow is based on CVideoTransformFilter class. Maybe it will be needed to derive it from CTransformFilter. Please, could you help me with this? BTW there were some ideas of including DVobSub functionality to ffdshow, but I think DVobSub is very good standalone filter and copying its sources to ffdshow would be just waste of time.

@athos
I compiled ffdshow with Intel C++ Compiler recently, but in VS6. It doesn't need any project conversion. Binaries were workable, but bigger. I haven't tried to use ICC in VS.NET.
ICC could speedup some ffdshow image processing filters which aren't MMX optimized: levels, time smooth, smoother,...

@sherpya
Thank you for this compile. I hope it will help to find (and fix) more ffdshow issues.

[gabest]

Originally posted by milan
@gabest
I thought about this too, but I'm not sure if it will be possible now when ffdshow is based on CVideoTransformFilter class. Maybe it will be needed to derive it from CTransformFilter. Please, could you help me with this? BTW there were some ideas of including DVobSub functionality to ffdshow, but I think DVobSub is very good standalone filter and copying its sources to ffdshow would be just waste of time.Basicly, to double the frame count you have to completly override CTransformFilter::Receive and copy the same code twice into your own class. CVideoTransformFilter::Receive also overrides everything just to add its own extensions, of which I'm not sure if they are any useful to you.

[Yusaku]

The problem of DVobSub is that it makes one "unnecessary" copy of uncompressed video data from input to output that eats a few percent of processor usage (so that it can overlay subs on a known field). But I am aware that the performance hit is not too big, so... it doesn't really matter.

Consider it a suggestion not worth the time to implement it :)

[gabest]

Actually, that copying is needed to do faster alpha blending. If the output buffer is a dd surface in vmem, then it becomes very slow to read those pixels back.

[athos]

I have made a new compile with a fresh CVS checkout from today. This time I managed to use ICL for the main ffdshow files too. I have installed VC++ 6, but after hours of trying I could not get it to compile properly, so this is Vc++ 7. I also changed the -O4 and -O2 gcc options to -O3, because it is supposed to be more aggressive optimization than -O2, and I could not find -O4 in the documentation.

It runs fine on my system.

My intention is not really to produce new builds every day, but I wanted to try and compile it in Vc++ 6, which failed, and then I wanted to compile all VC projects with ICL, which I did.

My problem with VC++6 is that it cannot find "C:\Program Files\STLport\lib\stlport_vc6_static.lib" which is hardcoded in the project file (VC++7 has no problem with this), and the compiler cannot find max and min functions in std namespace (again, no problem in VC++7). I suspect these might be beginner problems, so I beg those more experience to help me here.

Also I managed to open the solution file after having converted it to Intel compiler, after removing libavcodec from the workspace. i think it is not needed in the project since ffmpeg and mplayer are compiled separetaly using gcc's make.

Edit: I am not allowed to attach this, too big. Send me a PM if you want it.

[KyleK]

I had the same problem. you need to compile the lib manually before you can compile the ffdshow project. for this just go to the stlport/src dir and type "make". If you've installed gcc 3.xx it should work fine. After that you should be able to compile the project.

[athos]

Originally posted by KyleK
I had the same problem. you need to compile the lib manually before you can compile the ffdshow project. for this just go to the stlport/src dir and type "make". If you've installed gcc 3.xx it should work fine. After that you should be able to compile the project.

thank you, but where is this lib? i cannot find it in ffdshow or cygwin. is it supposed to be installed with cygwin?

and what about the problem with std::max and std::min? they are supposed to be declared in the standard library (according to msdn documentation) and i assume they have be #included properly. perhaps i have the wrong order of included dirs in Visual Studio?

[KyleK]

Take a look at the readme.txt or install.txt which comes with STLPort. It says that you need to compile the libraries by yourself.
There's a step-by-step description also, but it's really not that complicated. I'd send you the file, but i uninstalled vc6 already (which by the way fucked up my XP ;/).

PS: Remember to include the cygwin\bin path in your windows PATH variable.

PPS: Regarding your min/max problem. Did you update your VS6 with Service Pack 5? I ask because i did right after a clean installation of VS6, and i never had any error about a min/max function. I got some other errors though, which i fixed manually ;)

[gabest]

Originally posted by athos
and what about the problem with std::max and std::min? they are supposed to be declared in the standard library (according to msdn documentation) and i assume they have be #included properly. perhaps i have the wrong order of included dirs in Visual Studio? The Standard C++ Library definition of _MIN and _MAX changed from:
#define _MAX _cpp_max
#define _MIN _cpp_minto:
#define _MAX (max)
#define _MIN (min)This makes definitions of std::_MIN invalid.

The following sample compiled in Visual C++ 6.0, but fails on the indicated line in the current version:#include <xutility>
#include <stdlib.h>
using namespace std;
void main()
{
std::_MAX(3,4); // error
_MAX(4,5);
}
@MSDN / Visual C++ Concepts: Porting and Upgrading

[milan]

I had to use STLport for VC6 compile because I use std::map and it's constructor always crashed ffdshow. Maybe I did something wrong, some switches or defines weren't right, but instead of trying to fix usage of not standard conforming VC6 STL, I downloaded STLport and used it. Path to that library is hardcoded in dsp file, but it's to problem to change it in project configuration dialog.
std::min and std::max seems to be missing from VC6 STL, but C macros min and max aren't present in GCC. So I had to decide and result is the usage of STL templates: ffdshow is a C++ project :)

[gabest]

milan: Are you using DllEntryPoint from the dshow baseclasses directly? I have been doing that for a long time (like the dshow examples), but after I added the c++ lib to the list, it was crashing dvobsub. Try to declare your own DllMain and hook up DllEntryPoint from it.

[milan]

Yesterday I implemented fps doubling (it's a quick hack, but seems to work). I tried it with one sample THX vob file with DVD2AVI -> AviSynth -> ffdshow with raw video processing. In first frame first field was displayed, in second the second field. Height of fields was doubled by ffdshow internal software scaler. This is surely very simple method of deinterlacing and the results weren't very good, but what's the most important, it worked. However on my AMD Athlon 850 with ATI Radeon, the CPU load was about 80%. Of course it's because of need to handle 50 frames per second and the software upscaling. It should be possible to replace SW scale by HW by setting the aspect ratio of overlay (DIVX 5 can do this) but I don't know how.
If you think this could be useful, I can try to implement some better deinterlacer: would TomsMoComp be suitable for this?

[athos]

Ok now i get it, sorry if im a bit slow. I have to download STLPort separetaly. std::min and std::max are defined in STLPort (and they are not macros). Its a bit weird that VC7 compiles with no problem, but perhaps it has better standard compliance, and defines these functions, and thus does not need STLPort?

Anyway, why does M$ have to make such trouble over these simple and basic functions.. Well, "The paths of Gates are intricate and strange". :)

@milan: I think you made a wise decision, to stick the standard STL.

[sherpya]

A hint: I've used stlport without compiling the lib just edit
stl_user_config.h
and uncomment
# define _STLP_NO_OWN_IOSTREAMS 1

[sh0dan]

Originally posted by milan
I had to use STLport for VC6 compile because I use std::map and it's constructor always crashed ffdshow. Maybe I did something wrong, some switches or defines weren't right, but instead of trying to fix usage of not standard conforming VC6 STL, I downloaded STLport and used it. Path to that library is hardcoded in dsp file, but it's to problem to change it in project configuration dialog.


A wild shot: In avisynth development we had some unexplained problems on some machines (mainly win98), with out VC6 compiled binaries. By a lot of testing we found out that it was caused by a compile error, when we used "__declspec(align(8))" to get proper 8 byte alignments of int64's. I don't know if this could be related to your crashes.

[milan]

@sherpya
Thank you very much.
I added this define directly to dsp, so there is no need to modify any file. It will be in CVS in a few hours.

@sh0dan
I'm using __declspec(align(8)) too, but I'm not sure if this could be the reason. However it was solved for me by using STLport.

P.S. CVS is now a little bit messy. fps doulbing is hardcoded and I'm preparing to add MPEG2 decoding support. So it may be possible ffdshow CVS version will not be usable sometimes. Maybe I should learn how to use branches :)

[sekxx]

Athos Compile can be find here:
http://www.sekxx.org/ffdshow/

[LordDethstar]

I have an idea about presets. Would it be possible to implement automatic preset loading based on the properties of movies? That way you could define a preset for whenever a movie has a resolution of 352*240 or 352*288 and blow it up to 640*480 with heavy filtering. Movies with different resolutions would remain unaffected.

[oddball]

I'm having a big problem with the latest Athos compiles. Playback is very slow on my PIII 700 system. A 640x480 res DiVX plays back at 100% CPU and my mouse jerks around.
I have found that if I set the IDCT to Xvid things become a lot better and although it still peaks at 100% CPU usage it is not always at 100% and I can still use my system to a degree.
Both simple and simple deprecated are extremely slow. Even normal is faster than those two IDCT modes.

I didn't have this problem with the last official Milan compile. I might have to reinstall it and test it out.

New info: OK just tested and with the Milan 20020617 build CPU usage stays below 50% on average with the occasional jumps above up to and including 100% but mostly sits under 50%. Simple IDCT is enabled. Gonna reinstall the new build now and try again.

OK now I know what the cause is. Adding black borders (To compensate for my TV's overscan) in ffdshow adds a CONSIDERABLE impact on the CPU. Typically Milan's official 20020617 also has a lower CPU usage than the newest Athos compile. The new compile adds at least a 10% CPU usage jump with no processing options like black bars etc enabled. If I enabled black bars CPU usage jumps to 100%!

I am sure DiVXG400's overscan compensation does not add any CPU hit although it's not as good *SIGH* :(

Any ideas why the latest buid is slower than the last official release? Also why does black borders increase so much CPU?

P.S. Changing aspect in ffdshow also appears to have an impact on CPU usage. Probably because both aspect and black borders do similar things. I would love to know how DiVXG400 does it's overscan compensation without impacting CPU usage. Hmmm. If only it had more control though :P

Edit: Been having a think about this one. Could it be that by adding black borders it resizes the video? Even though the playback window size does not change? Is it like resizing the overlay from say 640x to say 720x? I noticed any DiVX that are 720x tend to be heavy hitters on the CPU. Excuse me if I am totally wrong :)

[milan]

It seems I found reason for performance degradation when postprocessing in applied.
When processing strength isn't default (100%), quantizer array passed from libavcodes gets modified. But in the inner loop one old debug message was left. It was the DEBUGSx macro. These debug macros are activated in file ffdebug.h at 4th line (#if 1). This was set on. I'm sorry for this, but sometimes it's useful for me even in release build. So for the next time: when you will compile ffdshow, please check that file line is set to #if 0. This should fix some of reported slowdowns.
About black borders: yes, video gets resized. ffdshow can't set output video resolution during playback and aspect ratio changing and adding black borders are done by scaling source image and drawing black borders around it. Drawing black borders is optimized to draw it only when needed, but maybe I did it wrong and it is drawn one every frame under some conditions. If you would like to test it, please download dbgview from www.sysinternals.com and run ffdshow version with DEBUGS macros enabled and watch the messages. If messages like "clearBorder" appears too often (without subtitles it should be only once on first frame), contact me.
Btw if you want only to add black borders, set desired output resolution and set the resize method to none. No aspect ratio correction or resizing will be done, source image will only be copied to the center of destination frame.

[avih]

@milan
from the above link, built at 03-09-02 (3 days ago) it didn't have that slowdown in postprocessing. maybe he disabled the debug in that build?

[milan]

Maybe he did, maybe I. I'm changing this often and commiting to CVS with other files.