FDecimate2 v2.00 - 28 Apr 2018

[StainlessS]

FDecimate2, mod of FDecimate v1.02.

Dll's for Avisynth v2.58 x86, v2.60 x86 and x64.



FDecimate2 by StainessS, based on FDecimate v1.02 by Donald A. Graft (c) 2004.
Requires CPP runtimes from VS 2008.

FDecimate2, fixes some problems with bugged metrics in FDecimate v1.02.
EDIT: Also adds support for RGB32/24 and 8 bit v2.60 Planar colorspaces.


FDecimate2(clip c,Float "rate"=23.976,Float "Threshold"=1.0,Bool "Metrics"=False,
\ Bool "Show"=False,Bool "Debug"=False,Bool "Chroma"=True)

All Args up to Debug, are exactly same as in FDecimate v1.02
(See doc in OriginalFDecimateSource(v1.02)\fdecimate102.zip)

Additional arg Bool "Chroma"=true, if False, will not scan chroma when differencing YUV frames.

The additional args added in FDecimate v1.05 [EDIT: Should read v1.10] are not supported, they apparently introduced problems into the plugin.



Use "FDecimate2.Def" [See Docs section:- Changing FDecimate() Parameter Defaults] instead of "FDecimate.Def",
All other functionality exactly the same as v1.02 FDecimate.

ssS


Zip includes below script

########################################################################
# Script to test metrics of MultiDecimate, FDecimate and MDec2. #
# MultiDecimate v1.07 & FDecimate v1.02/v1.10 metrics are both bugged. #
########################################################################

#Loadplugin("MDec2_x86.dll")
#Loadplugin("Multidecimate.dll")
#Loadplugin("FDecimate.dll") # v1.05 [EDIT: Should read v1.02]
#Loadplugin("FDecimate2_x86.dll")

MODE=3 # Testing Mode, 0 = MDec2 : 1=MultiDecimate : 2=FDecimate (All four should show metrics as 100.0%)
# 0) MDec2, any valid 8 bit ColorSpace. Metrics shown on frame. (only 100.0% @ PC Levels)
# 1) MultiDecimate YUY2 ONLY, Metrics stored script directory MFile.txt. (YUY2, Shows 108.51% Qual=2, 217.02% Qual=3)
# 2) FDecimate v1.02: YV12 and YUY2, Metrics shown on frame. (Shows 187.68% for YV12, 112.61% YUY2)
# 3) FDecimate v2.00: any valid 8 bit ColorSpace. Metrics shown on frame. (only 100.0% @ PC Levels)

C="YUY2" # Choose Test Colorspace (must be valid for the called dll)

MDQUAL=2 # MultiDecimate Quality setting default 2. 2=Luma Only : 3=Luma+Chroma
CHROMA=True # FDecimate (v2.00)

IsRGBClip=FindStr(C,"RGB")!=0

W=(IsRGBClip) ? BlankClip(Pixel_Type=C,Color=$FFFFFF) : BlankClip(Pixel_Type=C,Color_YUV=$FFFFFF)
K=(IsRGBClip) ? BlankClip(Pixel_Type=C,Color=$000000) : BlankClip(Pixel_Type=C,Color_YUV=$000000)
Interleave(W,K) # White/Black(RGB) or Pink/Green(YUV) alternate frames

MODE==0 ? MDec2(rate=25.0,create=true,Show=true,dir="",Ver=True,Chroma=true) : \
MODE==1 ? MultiDecimate(Pass=1,Show=True,quality=MDQUAL) : \
MODE==2 ? FDecimate(Rate=25.0,Metrics=true) : \
FDecimate2(Rate=25.0,Metrics=true,Chroma=CHROMA)
Return Last


See MediaFire or SendSpace below in my sig (~102KB).
(incl original source from FDecimate v1.02)

EDIT: For YUV and Chroma = true, Combined Chroma weighted at 50%.

EDIT: Requires CPP runtimes from VS 2008.

[StainlessS]

@ Manolito,

Can you give it a whirl, not much tested but should be at least as good as v1.02.

I decided bump up to v2.00 and add a 2 to the name ie FDecimate2(), so as to avoid problems due to added Chroma arg.

[GMJCZP]

Thank you TinMan for your contribution!

[manolito]

Just finished my small Decimators Comparison test... :cool:
Download the resulting clips here:
https://www.sendspace.com/file/idx005

First of all it took me a while to find a clip where I could see any differences at all. Clips with "normal" brightness and contrast all worked well, so I had to use a very dark and low contrast clip (45 sec from "Sphere").

The original is flagged as interlaced (common for commercial PAL DVDs), but the content is progressive. Next I converted it to NTSC using the DUMB method just adding dupes (no telecine). This "dupes" clip was the source for the decimators.

I compared FDecimate2, the old FDecimate 1.02, TDecimate mode=7 and just for laughs also ChangeFPS.

Except for ChangeFPS all the conversions look pretty good to me. You can see differences when stepping through the frames, but they are surprisingly small.

Some things I noticed:
FDecimate2 is about 10% slower than the others on my machine.
The converted files have a different total frame count. No idea which number is correct, though. I also found that VDub and MediaInfo do not agree on the total frame count.


Cheers
manolito

[StainlessS]

FDecimate2 is about 10% slower than the others on my machine.

Original, sampled horizontally 4 pixels, skipped 8 pixels, and repeat, so samples vertical stripes, no idea why other than for speed, F2, samples every pixel,
so 10.0% speed drop is not so very bad. [dont know if builtin ChangeFPS and/or TDecimate use asm].

but they are surprisingly small.
Yep, despite the problems, seemed to do pretty good just the same, I did not expect to find much dfference.

I will not have time to look at samples until about Wednesday, I shall try to recreate your results, I'm curious about the number of frames mismatch thing.

Thanx for your efforts. :)

I might change chroma arg to float 0.0 -> 1.0 as chroma weight rather than bool.

EDIT: I did not change frame selection algorithm at all, only sampling for metrics and debug/metrics on frame rendering stuff.

EDIT:
I did not expect to find much dfference
Although metrics added chroma diff to wrong luma diff, would do similar on adjacent frames, and as adjacent frames mostly
alike, so the overall results would (I presumed) be not too much in error.
Some frames greatest block diff might be skewed too high, and some skewed too low, but when compared to alike adjacent frames with
similar skewing, decimate decision would not be too eroneous.

FD v1.10 is a whole different story. I (some years ago, cant even remember doing it) tried adding some debug stuff and according to
some notes I made, it does produce some real weird results, dont think a good idea to re-follow that path again, v1.10 should best be
left to its demise.

EDIT: Some notes I embedded in the source, from way back when (no idea what it all means, but it dont look encouraging)

// SJ, Is below a !!! BUG !!!, " || inframe == last", surely last is the
// SJ, pre-decimated input frame number and inframe is the post decimated
// SJ, output frame number, (chalk & cheese)
// SJ, Should it perhaps be " || dec_data[inframe] == last"
// SJ, so, the "dec_data[inframe] == last" condition will only rarely if
// SJ, ever met.
// SJ, ADDENDUM
// SJ, Have tested out, and found no detrimental effect if below suspect bug
// SJ, is left in-situ, if you however corrected it as noted above, it outputs
// SJ, thousands of duplicate frames (access to the same input frame numbers)
// SJ, whereas, if left as is, then if produces zero duplicate frames.
// SJ, Neither way around does it backwards frame step except where the output
// SJ, decimated rate is higher than the input frame rate.
// SJ, So, leave it as is although I dont know what it's supposed to do.
// SJ, METHOD:- last < 0 condition only met on start-up.
// SJ, so, really only decision made using metrics.
// SJ, If diff between calculated frame & last output frame > thresh then output
// SJ, calculated frame OTHERWISE, outputs calc frame + 1, so if multiple duplicates
// SJ, are present, the first duplicated (2nd identical) is skipped and the 2nd dupe
// SJ, is output regardless. Even if multiples skips are executed, it will eventually
// SJ, get back into some kind of sync because the calculated frame will skip the
// SJ, odd frame. If threshold set as 0 then will decimate regardless of metric
// SJ, and output will be based on luck. Setting the threshold too low, will
// SJ, only skip almost exact dupes and will resort to luck if there are no dupes
// SJ, within the input group. Setting threshold too high and it may skip significantly
// SJ, different frames and end up skipping

seems to be some parts of notes missing.

[manolito]

If you just wanted to change the framerate, and did not care too much about whether it was upwards or downwards, then FDecimate was just the job,
I had no idea that it was bugged until I purloined the source for use in Mdec2.

Always learning new stuff... :p
I had never thought that FDecimate can also increase the frame rate. The term "decimate" certainly does not imply it, and the manual also just talks about reducing the frame rate.

But whatever, I just used it to bring a 25fps clip up to 29.97fps, and the result looks every bit as good as using ChangeFPS.

This is from the other thread started by Katie, but now I found that this is plain wrong.

You also said it in your notes:
// SJ, Neither way around does it backwards frame step except where the output
// SJ, decimated rate is higher than the input frame rate.

Bottom line:
Never use FDecimate for increasing the frame rate. It will add duplicates at the wrong place, i.e. the dupes come from a backward frame making the output jumpy. The behavior is the same for FDecimate 1.02 and FDecimate2.


Cheers
manolito

[StainlessS]

Its my guess that v1.02 is basically using same method as ChangeFPS but with the 'try to skip dupes' stuff added.
Unfortunately the combination is not without problems (with/without the inframe/dec_data[inframe] bug), and
the additional static protect stuff of 1.10 made things even more weird.
I did not want to change anything in v2.0 (relative to v1.02) other than where result effect would be known,
ie fix the metrics bugs and re-do all of the debug (to debugView) and metrics to frame output stuff. I did not want
to add my own bugs to v2.0 before understanding the effect, and definitely did not want to start with v1.10,
perhaps way too complicated to fix everything all at once.

Now that we basically have a new v1.02 (without metric bugs), I, or someone else could try find a better method,
think I'll add back some debug stuff to output a 'frames used' file, perhaps together with some 'reason' code (ie which path in code
was taken to achieve the result), so that can peruse/scan result external to debugger.

Also, if upping framerate, may be best to simply forget all about the decimation stuff and follow a path which only uses ChangeFPS
method, avoid all of potential problems (I think I shall do that last bit for sure).

EDIT: I'll change the Chroma thing to a chroma weight, and add the 'use ChangeFPS only method" if upping FPS, then put out v2.01.

[manolito]

EDIT: I'll change the Chroma thing to a chroma weight, and add the 'use ChangeFPS only method" if upping FPS, then put out v2.01.

Yes, please, and make this option the default...

If you do it this way I would probably write a small wrapper AVSI to replace ChangeFPS completely with FDecimate2.

[manolito]

If you do it this way I would probably write a small wrapper AVSI to replace ChangeFPS completely with FDecimate2.

Uh oh, this seems to be much harder than it sounds... :(
Trying to write a Proof of Concept script I hit several roadblocks already.

What I want to do:
Write a "ChangeFPS.avsi with a function "ChangeFPS".
The docs say that user defined functions always override internal functions.

Get the source fps and the desired target fps.
The problem is that the internal ChangeFPS has several calling conventions. The target fps can be either specified as float, or it can use ints for nominator and denominator. In both cases I need the fps value as a float because FDecimate requires it.

Compare source fps with target fps. If target fps is smaller then call FDecimate, if it is bigger then call the internal ChangeFPS function.
But how can I specify to use the internal ChangeFPS instead of my user defined ChangeFPS? For plugins I do know that you can specify which function you want to use by preceding the function name with a "{plugin-name}_". Does this work for internal functions too by calling it with "AviSynth_" ?

It looks like this task is way over my head - obviously I am still a little "AviSynth Challenged".

Cheers
manolito

[StainlessS]

For the 3rd one above, I've already implemented separate handling if out fps greater than in fps, where should do pretty much exactly the same as ChangeFPS (next ver$, v2.01_Beta_1).
(if you find any difference, do tell).

EDIT: For num, denom style setting of fps, could let Avisynth assist in that.

BlankClip (clip clip, int "length", int "width", int "height", string "pixel_type",
float "fps", int "fps_denominator", int "audio_rate", int "channels",
string "sample_type", int "color", int "color_yuv")


BlankClip (clip clip, int "length", int "width", int "height", string "pixel_type",
float "fps", int "fps_denominator", int "audio_rate", bool "stereo",
bool "sixteen_bit", int "color", int "color_yuv")


fps: the framerate of the resulting clip.

fps_denominator: you can use this option if "fps" is not accurate enough. For example: fps = 30000, fps_denominator = 1001 (ratio = 29.97) or fps = 24000, fps_denominator = 1001 (ratio = 23.976). It is 1 by default.



EDIT: Consider FDecimate2() transient and in Beta, just in case we decide to change args or something.
Have pretty much also changed metrics Chroma arg to CW (ChromaWeight, 0.0 -> 1.0), 0.0 = luma only, 1.0 = chroma only.

[StainlessS]

Mani, find temporary, v2.01_Beta_1:- http://www.mediafire.com/file/9p49rm5ldxo3vo1/FDecimate2_x86_x64_dll_v2-01_Beta_1_20180503.zip
(all 3 ver$, 2.5, 2.6 x86 and x64 + source.)

Implemented up framerate same as ChangeFPS.
Most of the remainder is same output as 1.02.

I've downed your samples and shall take a look soon.

EDIT: I'll add a rate_denominator arg, behaving same as eg BlankClip or ChangeFPS.

EDIT: Chroma changed to 'CW' ie ChromaWeight, default at present 0.5, [0.0->1.0]).
FDecimate2, "c[rate]f[threshold]f[metrics]b[show]b[debug]b[cw]f"

EDIT: I'm thinkin' bout removing the 'Take defaults from FDecimate2.Def file in plugings' whotsit from the plug, any objections ?

[manolito]

Sorry for the late reply, but with the weather we got now my motorcycle and the neighborhood beergarden are a little higher on my todo list... :devil:

Just tested the latest version, but something with the new CW parameter is broken.

I tried the default of 0.5, then tried CW=1.0, and then also CW=0. As the source I used the "Dupes.mpg" file from my upload and tried to bring it down to 25fps.

All three results looked very similar, and they all looked much much worse than the previous version or the original version by Mr. Graft. Right at the beginning of the clip every 5th frame is still a dupe after the conversion. The previous version only kept two dupes and then succeeded in removing almost all of the dupes.

In the previous version it did hardly matter if Chroma was set to True or False. With this source clip the results were a little bit different, but nothing you could put your fingers on while viewing the converted clip. With Chroma=False the speed was only a tad faster, so I always kept it at the default Chroma=True.

Anyways I am curious why you want to implement the ChromaWeight param. Can you imagine any situation at all where the dupe detection will be better when you discard luma and only use chroma?

About the DEF file I do not have an opinion. I never used it, so I really do not care.


Whatever, this latest Beta of FDecimate2 does not work for me. Waiting for the next version...


Cheers
manolito

[manolito]

Played a little with a sample from Mr. Graft's own forum, and it is very clear that the out of order frames are only a problem in FDecimate 1.10. Version 1.02 works correctly in this respect.


So my request for a fixed version would be very simple:

1. Fix the bugged metrics (even if they do not cause a lot of damage).

Original, sampled horizontally 4 pixels, skipped 8 pixels, and repeat, so samples vertical stripes, no idea why other than for speed, F2, samples every pixel, so 10.0% speed drop is not so very bad2. Don't bother. Sampling every pixel instead of vertical stripes does not improve the result IMO, it just makes it slower.

3. Do not bother about chroma. Keep the original code, disregarding chroma is only marginally faster.

4. When trying to increase fps either just throw an error (like tdecimate), or switch to the internal ChangeFPS.

You probably won't like my proposals, but I think that keeping this plugin as simple and fast as possible has a lot of merit...


Cheers
manolito

[StainlessS]

Thanks Mani forgive me for not
answering sooner, me been busy
I shall try rectify probs but might be while, sorry.

Love & kisses, ssS

edit, above a bit screwed up, sorry auto correct can start wars!.

EDIT: above mostly cleaned up.

[manolito]

Hey, I don't think that we could ever start a war... :D

Take your time, I am quite happy with the current state of things.

OT:
Planning a short motorcycle trip with my brother to Scotland by mid June, really looking forward to it. It has been 18 years since my last trip to Scotland, I loved it. This time it will be Edinburgh, Ullapool, Inverness and Glasgow. Too little time, but still...


Take care
manolito

[StainlessS]

Yeh, dont forget your brolly, always rains when I go up there (land of the Scots).
Can be brilliantly sunny day, not a cloud in sight, but with simultaneous and constant drizzle.

Have a nice holiday, ol' chum :)

[manolito]

Sorry I don't mean to push you, but I also do not like to be left hanging in limbo...

I think we can agree on discarding FDecimate 1.10, and the test version 2.01_Beta_1 from May 3rd 2018 is also no contender, it just leaves too many dupes.

So it is about comparing the original version 1.02 with FDecimate2 from April 28th 2018.

I did quite a few tests comparing these two versions, and even if your version fixes the buggy metrics of Mr. Graft's version, the conversion results are almost identical. And the original version is a little faster too, so I tend to prefer Mr. Graft's original version 1.02.

I would like to ask if this project is dead for the time being, or if we can expect a stable FDecimate2 version which beats the original version any time soon. I know that you are busy with other projects, but I would like to have this case closed... :cool:


Cheers
manolito

[StainlessS]

I'm still busy on it, although pretty much nothing left of the original source, with possible exception of Grafts copyright thing, which I'll leave in
for no other reason than I am using the same name (and as I know how much of a kick he gets out of seeing his name everywhere,
part of that God complex he is blessed with, I guess :) ).

I will not be using the 'stripe metrics' thing, I just dont like it, even with the bugs fixed.
Currently, (using your samples), outputs 1158 frames in uprate (same as avs+ 26 ChangeFps) and as original when downrating the uprated result, ie 1133 frames.
NOTE, In downrate, I get original rate for ChangeFPS whereas your changefps sample suggests lower frame count.
[Actually, I get 1132 frame count for your changefps sample in VDubMod, and I think that was also the case for previous version of VirtualDub2, but in my
currrent version of VD2 am getting a frame count of 1331 (VD2 build 41768)].

This is currently how the functions are registered with AVS,

env->AddFunction("FDecimate2", "c[rate]f[threshold]f[metrics]b[show]b[debug]b[ver]b[cw]f[linear]b", Create_Float, 0);
env->AddFunction("FDecimate2", "ci[denominator]i[threshold]f[metrics]b[show]b[debug]b[ver]b[cw]f[linear]b", Create_Int, 0);
env->AddFunction("FDecimate2", "cc[threshold]f[metrics]b[show]b[debug]b[ver]b[cw]f[linear]b", Create_Clip, 0);
env->AddFunction("FDecimate2", "cs[threshold]f[metrics]b[show]b[debug]b[ver]b[cw]f[linear]b", Create_String, 0);


The Linear thing may disasppear in final.

I have not forgotten you but have not been able to spend the time required, and dont know just how much longer it may take, sorry.

EDIT: The Frame counts were on ffmpeg conversions of your mpegs to AVI.

EDIT: The 'ver' arg will show Version & Graft (c) thing, 'show' will only show metrics without (c).
You said you wanted to make a Wrapper, I'm making that un-necessary or at least easier.

EDIT: The 'cs' registering stuff has String preset, same as ChangeFPS, ie

const char *Standard[17]={
"ntsc_film","ntsc_video","ntsc_double","ntsc_quad",
"ntsc_round_film","ntsc_round_video","ntsc_round_double","ntsc_round_quad",
"film","pal_film","pal_video","pal_double","pal_quad",
"drop24","drop30","drop60","drop120"
};
int arr[17][2]= {
{ 24000, 1001 },
{ 30000, 1001 },
{ 60000, 1001 },
{ 120000, 1001 },
{ 2997, 125 },
{ 2997, 100 },
{ 2997, 50 },
{ 2997, 25 },
{ 24, 1 },
{ 25, 1 },
{ 25, 1 },
{ 50, 1 },
{ 100, 1 },
{ 24000, 1001 },
{ 30000, 1001 },
{ 60000, 1001 },
{ 120000, 1001 }
};


EDIT: The 'cc' ie clip arg for framerate, will require both clips explicitly, else would likely try to use the 'c[rate]f' format
where rate is optional defaulting to 23.976 [that might depend upon order in which the alternate function specs are registered].
[Explicit clip same as for BlankClip where need explicit clip to take framerate etc from the supplied clip, and not using implicit Last]

[nji]

Being a newbie at AviSynth I recently needed to decimate a silent movie (1919),
nominal 29.97 fps, to the supposed abt. 18 fps.

First method I found was FDecimate http://avisynth.nl/index.php/FDecimate
I took the newest version v1.1.0.
Now by chance in this thread I read about that version being buggy.
(Actually with me it sometimes outputs 1-frame-stepbacks!!).
==> To prevent the pitfall for others I would suggest to remove the link to v.1.1.0.

Next I found FDecimate2 http://avisynth.nl/index.php/FDecimate2
But in this thread it turns out it is worse than orig DG's,
and moreover dev stopped 2018.
==> So maybe remove all links to it too?

Next I found TDecimate http://avisynth.nl/index.php/TIVTC/TDecimate
This seems to be the so-far best decimate function?
How does it compare to DG's FDecimate 1.0.2?

[johnmeyer]

First of all, you need to go frame-by-frame, though at least 100 frames of your source. The first thing you do is make sure that each frame is clean and not blended in any way.

Next, you need to start counting duplicates in order to discover how the film was telecined. Since your source is 29.97, it is probably interlaced. Therefore, to do this properly, you need to either use bob(), with the correct parameters, or separatefields(), in order to look at the source field-by-field. This is mandatory because film that has been telecined to NTSC 29.97 has usually had fields duplicated, not entire frames. If you don't verify if that this is so, and you start applying FDecimate or any other algorithm, you're going to get bad results.

You want to count the number of fields you view and as you're going along, make a running count of the number of duplicated fields. It's a little tedious, but doing this right is, once again, mandatory.

You can then use some decimation tool, using the parameters for the number of fields you counted and the number of duplicates you observed, to recover the original progressive frames, with no duplicated frames or fields.

However, you won't be done yet.

Once you have the original film frames, you need to re-time the playback. For film from 1919 there is no standard playback rate, even for commercial film. A lot of early movie cameras were hand-cranked, and the speed is completely arbitrary. You'll have to use your judgment. As a guideline, when speed standards did start to get adopted, silent 16mm film was usually shot at 16 fps. It was virtually never more than that, but it is often less. Here is some backyard football from 1928 which I timed to play back at 12 fps. I did not interpolate between frames when I posted it, so it is pretty jerky, but that's how it is supposed to look.

1928 Backyard Football (https://youtu.be/1YekFxBYKNM?si=SSxdc3afJeTqnBK5)

To change the playback speed using AVISynth, without re-encoding, you use AssumeFPS(). So, for the film above, the last statement in my script was:

AssumeFPS(12)

[nji]

Thank you very much for your valuable information!

I didn't want to be OT with the details of my movie
(was about to post a thread on its own).
The aim with my post above was to prevent further misleading
(as I have been; see above), and to have the links to
FDecimate v.1.1.0 and to FDecimate2 removed.
Maybe somebody will do this?

BUT
if after years over the rainbow nobody minds,
I could well continue in this thread:

My 1919 movie:

The information about using interlacing when "blowing-up" fps
was new to me.
The digital copy of the movie is (technical) progressive;
also frame-wise stepping through the movie doesn't show the typical
effects of interlacing.
Morveover if I bob deinterlace with field seperation there are no
2 neighboured pairs that differ - only one pair.
Doesn't this mean it isn't interlaced?

What I did was to check the pattern and ratio of dupe frames
(at different positions in the movie).
The pattern was 122.
Mostly, not always...
Inbetween sometimes "disturbed" by single 113, and sometimes little shifts.
However all in all a ratio of (about) 3/5.
29.97 * 3/5 equals about 18.

With FDecimate 1.1.0 I identified a diff thresh of about 30.
(Although it's not perfect:
- some intermediate text tables vary more due to disturbances (false positive)
- some content-wise different neighbours have less (false negative))

When applying FDecimate to this, the overall result is OK (esp. 18fps);
BUT quite often there are "single-frame-stepbacks"
(output of frame numbers: 123434567...).

When using TDecimate(mode=7, rate=18) there are no "step-backs",
but the fitting of the dupe patterns seems to be worse than FDecimate's.
Not very satisfying.
It's a pity for that the nice movie.

I don't see how it would be better with your hints...
but maybe I don't get you right?

Edit:
ffmpeg's idet states only progressive frames.

[johnmeyer]

Sounds like you're on the right track. You sometimes have to fiddle with the decimation parameters to get a good result. You can always try a different section of film and repeat the process of observing the number of duplicated frames that you get.

Interlaced vs. progressive can only be determined by deconstructing into fields, as you have done, and looking to see if there is any motion between fields. If there is no motion (other than the slight up/down bobbing that you get because the fields are spatially separated by a scan line), then it is progressive. This is true even if the video gets reported as interlaced by a tool such as Mediainfo. The interlaced flag is meaningless.

[nji]

Again: Thank you!

Still there remains the question, which decimation function to use.
FDecimate1.1.0 seems to be buggy (still it has been introduced by DG
to circumvent fails of his first version).
FDecimate2 seems to be worse than orig FDecimate1.02 and dev seems
to have stopped.
So... take alive TDecimate?

[johnmeyer]

I've always used TDecimate, but I'm old and often don't learn newer stuff, unless I can't get the old stuff to work.