New motion compensated deinterlace filter (TomsMoComp)

I've just released my new TomsMoComp.dll deinterlace filter. This is a first cut at doing motion compensated deinterlace of video source material, but still doing it at a reasonable speed. There are actually 2 versions in the zip file; one each for Avisynth and DScaler 4.0. See the ReadMe file at or get the source and DLL at . The Avisynth filter also offers a fancy new line doubling option to verically double the size of a (progressive) clip in a way that I think offers a bit more apparent detail than regular scaling. I'll post some samples and some more about that later. Note this is NOT for film source, only video (ATSC, PAL, or NTSC). Use ForceFilm, DeComb, or GreedyHMA for telecined film material. This is brand new so any feedback appreciated. - Tom

great tom :) i'll test it. how about moComp temporal filter now? ;) best regards avi ps add '.txt' to your readme link

Avih - Thanks. Link fixed now. - Tom

Too sweet! I'm with avih also about the MC-temporal filter (as previously begged for here :) ) I did some simulations in photoshop, and the really noisy source I referred to in the post above went from about 40% pixels being 'locked' with a threshold of 20, to about 90% of the pixels being locked when the previous frame was moved to compensate for motion in the new frame.

tom, I get a "Internal Error: MMX state left on: T:\projects\virtualDub_old\main\VideoSource.cpp:1101" I have no idea where that path comes from. It's not present on my system. I have a SSE-enabled Athlon.

(dashing back, panting and sweating) 

Milkman Dan - I can't find an exit from the program that has this error. (of course I'm as blind as the next guy) Could you verify that it happens with all other filters removed? - Tom

Sorry for taking so long. I removed all other filters. The error still occurs. I didn't notice before that there is an AVIsynth read error just before the MMX state error. The address changes each time though.

Just tested your filter. Quality seems very good. However, I had some access violations too. It only occurs with some combinations of parameters and clip properties, but I didn't find a pattern. For example, with res of 720x480 it only works with TopFirst=0 and SearchEffort<6. If I resize it to 704x480 it works for other parameters, but if I crop it to the same resolution it doesn't. Maybe pitch related? Also it sometimes cause a line of gargabe pixel at the bottom, particularly in "double height" mode (SearchEffort=-1) but not only.

Grrrrrrrrr...... I have not been able to reproduce the error yet, much less fix it. Could someone post a script that causes the error? And say what kind of machine and input file it is? I certainly believe that it happens, it just does not yet happen here. - Tom