exist any filter specially done for (deinterlace) flicker

[Didée]

Alas, but no. Those settings are completely deactivating everything that is suspected to be sped up. In/Deflate is used in the safety-repair section, which here is completely switched of (the 2nd triple: "0,0,0"). And SVthin=0.0 also does deactivate that feature - and if it's not used, then it can't benefit from a faster median.

[aegisofrime]

Oh I see. Well, hopefully with the speedup, a higher quality setting will give me the same speed as the ultrafast setting.

I have always been using TGMC(2,1,1,EdiMode="NNEDI2"), and that gives me about 10 fps. A bit ridiculous especially for 2 hours long DVD footage, but that's the price I have to pay for quality I guess!

One disadvantage of the ultrafast setting was that the encoded file is bigger than the "TGMC(2,2,1,EdiMode="NNEDI2")" one, but that's normal behavior right?

[Didée]

Sorry for I didn't post the mentioned update yet. I started with fiddling a "lossless" mode into TGMC (i.e. a mode that leaves the original fields untouched), and don't want to post a flood of new revisions every few days.
The inherent problem is the same old one ... you can easily get some residual combing, and measures to completely avoid this issue are very likely to also harm good detail, and/or to lose some of the temporal stability. Compromises of some sort have to be made.

The current implementation was made-up rather quickly. Visually, there is only little difference to TGMC-beta1. When things start to look very similar, numbers become more interesting, and so I made a quick test with MSU's measuring tool, compairing the bob-deinterlaced 576i Streams with the 576p50 reference.

Using the Stockholm sequence:

YadifMod(NNEDI2) :    avg.PSNR = 34.779

TGMC(1,1,1,bicubic) : avg.PSNR = 36.135  (beta1u)

TGMC(1,1,1,bicubic) : avg.PSNR = 41.489  (beta2: "lossless")

It's only a "snapshot test", but it seems there is potential.

[Revgen]

^Sounds like this "lossless" version can be used appropriately with functions like Srestore since it leaves the original fields unchanged.

Even if it misses some fields, I'm sure a quick vinverse() afterwards won't hurt much.

I'll be waiting to see it released.

[Didée]

Can't tell yet how it'll work with fieldblended footage, that's quite another game to play. For the moment I evaluate only with normal video-interlacing footage.
The code is knotty, but it's fun to finally see in "scientific" numbers what the eye has seen for a long time already. The current TGMC, even tough it gets "respectable" numbers in PSNR/SSIM tests, gets pretty much underrated by those. No wonder, because in the trade for stability it changes 100% of the frame. Other deint's may flicker and whatnot, but they have 50% of the frame correct to start with. And PSNR/SSIM don't care at all about temporal relations, while in the case of bobbing this is one of the most important factors! (Have told this already like ~10 years before when I came to digital video as a newbie ... everybody was so keen on PSNR back then, I told about the missing but important temporal relation, and of course nobody listened ...)

In any case, it's fun to see bobbers X-Y-Z doing ellbow-fighting in [the midrange of] 30db land, while TGMC happily roams in [the lower half of] 40db land, mostly.

I've one or two more things to try, and then the big knot in the script must be cleaned.

[Terka]

Hi Didee,
1. looking forward what the mastercook will serve us.
2. tried the 'noise bypass' technique using 2 mdegrains (both on bobbed=progressive clip)
where "limit" was different. so the most filickering parts
got away. (mostly horizontal lines). after that classical tgmc can be used. know that this is slow (2mdegrain), think that mvtools could be quite simply changed limit-> limitMIN, limitMAX so 1mdegrain will be needed

[tritical]

The results of TGMC are impressive, but it has to be stated (probably has been) that if there was ever a clip born to show the advantage of mc'd deinterlace it is that stockholm sequence . Very high level of sharp detail, very slow stable pan (pure translation, just fast enough that motion-adaptation is useless) with no complicated motion to confuse mc.

[Didée]

Quite true, the Stockholm sequence is a dream of a perfect showcase example. However, the most important feature is that the dis/advantages are perfectly visible on this sequence. But the basic characteristics are pretty much the same on most other sequences, too. There's so many different things that can be tested. E.g. even when you have a source that has been very strongly lowpassed before interlacing (flicker reduction), so that the bobflicker is so much reduced that it's hardly visible anymore - if two bobbers look "almost the same" on such a source, but one bobber requires 25%~50% more bitrate on mpeg-compression compared to the other, what does that mean?
Also, at the very end of the Stockholm sequence the camera is still. Just a very few small objects are moving very slowly. Not much to do for MC there ... yet the new TGMC is still 1.5~2.0 db PSNR ahead over YadifMod(NNEDI2).
Another funny test is to simply knock out all original fields in a final comparison (since they're the same unchanged fields anyway), and compare only the interpolated fields to the respective reference. Guarantees for some funny numbers. (Or in the same spirit: bob-deinterlace, make a fresh interlaced source from only the interpolated fields, then bob-deinterlace *that*. Seriously, try that with a plain Yadif! Horror result!)

[Didée]

OK, another little test. A relaxed scenario, to not get accused of using "extreme" or "cherry-picked" sources that no filter except TGMC could ever handle.

Contestants: TGMC-b2 lossless, tdeint(nnedi2), Yadif, YadifMod(nnedi2)

Source is ParkRun2 720p50, downsized to 576p for faster comparison.

The progressive source has been lowpassed before interlacing, to make things easier for the contestants. (So don't say the ultra-sharpness from not-lowpass'ing is the cause for the results.)

The snip is from the end of the sequence, frames 400-450. There is almost no motion in that snip, the camera is almost still. The overall scene shows minor subpixel-movement in the first half, the 2nd half is perfectly still. There is some slow motion in the water waves, though.
(So don't say it's the perfect horizontal translation which causes the results.)

Used Avisynth script:

RawSource("720p50_parkrun_ter.yuv",1280,720,"I420").assumetff()

spline16resize(720,576)   # make 576p

blur(0,1).sharpen(0,0.75) # lowpass before interlacing

crop(40,0,-40,-0,true)    # better preview on 1280-wide displays...

p = last                  # safe progressive reference

i = separatefields().selectevery(4,0,3).weave() # interlace

#-------------------------------------------------------------------

nnedi = i.NNEDI2(field=-2)

td   = i.tdeint(mode=1,edeint=nnedi)    #  try a bobber
yad  = i.Yadif(mode=1)                  #  try another bobber
ydm  = i.YadifMod(mode=1,edeint=nnedi)  #  and yet another bobber
tgmc = i.tempgaussmc_beta2(lossless=3)  #  and this one, too


comp1 = compare(yad, p)
comp2 = compare(ydm, p)
comp3 = compare(td,  p)
comp4 = compare(tgmc,p)

  stackhorizontal(comp1,comp2)
# stackhorizontal(comp3,comp4)
# comp1
# comp2
# comp3
# comp4

trim(400,450)

PSNR Results:

Yadif:    starts with ~38.5db, ends with ~40.0db. oPSNR = 38.94

YadifMod: starts with ~39.5db, ends with ~41.0db. oPSNR = 39.68

tdeint:   starts with ~36.0db, ends with ~41.8db. oPSNR = 37.44 

TGMC-b2:  starts with ~44.8db, ends with ~44.9db. oPSNR = 44.86

Video Sequences with PSNR measurements: LINK (Mediafire, ~16MB)


Let me repeat this isn't a cherry-picked example. That PSNR difference really is typical. I found only few cases where the difference is less, and quite a few where the difference is even bigger.



Temporal stability results:

(Encode to Xvid, q2, no Bframes, "flat-8" matrix. A practical way to watch out for switch-swatch bob shimmer.)

                size      % of TGMC  % of ref

576p reference: 8760 kb    (124%)     100%

TGMC-b2:        7023 kb    100%        80%

Yadif:         11148 kb    159%       127%

YadifMod:      10530 kb    150%       120%

tdeint:        10123 kb    144%       116%

Conclusion:
Compared to TGMC, all contestants have a noticably lower quality. (PSNR surely isn't the holy grail - but hey, a difference of 4~8 db is a darn lot, isn't it?)
Compared to TGMC, all contestants are remarkably less compressible. So in a realworld scenario, you start with a lower-quality source to begin with, and then would even need to compress it more strongly to achieve any given filesize, thereby reducing the quality even more.

Makes me wonder ... people happily use slow, slower and evenslower x264 settings to improve 2 percent here, another percent there. But when it's about vastly improved frame quality at vastly reduced birate, then no, thanks, it is too slow. Let's rather use the poor Yadif to quickly turn the source into a psychedelic something, then compress with insane x264 settings to no avail. Strange world.

[tritical]

The interesting thing to me is that in your second test the psnr difference between tdeint+nnedi2 is 37.4 vs 44.8 (7.4) and yet I can hardly tell the difference just watching the sample with the two side by side (maybe I have bad eyes and a crappy monitor). Whereas with the stockholm sequence the psnr difference is 34.7 vs 41.4 (6.7) and the difference is night and day. Actually, it doesn't surprise me since I have seen the same thing developing nnedi2 using squared error to train. Sometimes large psnr gains translate to almost zero visible improvement, whereas sometimes small gains translate to very visible differences (i'm talking gains over cilps containing frames from 50-60 sources). The hvs is very sensitive to differences in certain areas (clear defined structure) more than others ("busy" but somewhat random areas, like the trees and grass in that second sequence). Actually, if you have the time I'd be interested in the psnr numbers for nnedi2() alone and nnedi2 with qual=3 if it isn't too slow. (maybe tdeint(mthreshL=-1,mthreshC=-1) also for just cubic interpolation with original fields preserved for kicks). Plus I am in no way trying to say that yadif is going to beat tgmc except for a rare clip or two, in fact I know its and tdeint's horrible scores on psnr tests well.

[Dogway]

Im having a problem setting qual=3 in tempgauss:

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)

The encoding crashes at second pass. Its strange because qual=2 works nice, and qual=3 works nice on yadifmod. Do I have to call it as a variable? Do I have a wrong version? How do I know the version I have?

EDIT: Also when you say TGMC, is it the another version, or you just changed the function name?

[aegisofrime]

Great comparison videos there Didee. As far as I'm concerned TGMC has no competitors. Back when I was starting out in video editing, I tried a few trial versions of some commercial deinterlacing plugins for After Effects. None of them worked as well as TGMC.

Also, JoshyD seemed to have gotten TGMC running in 64-bit mode and is reporting significant speed differences. Should be interesting

Originally Posted by JoshyD

Alright, I think I've got that temporal soften bug squashed, test it and let me know if there are any issues

I have TempGaussMC running . . . I'm showing some significant speed differences, anyone care to try there hand at it? I've got a four core machine, and telling AviSynth to use ~8 threads seems to be the sweet spot for processor utilization for me.

[Boulder]

Is the recommended way to deinterlace with TGMC (keeping the original frame rate) to simply use SelectEven or SelectOdd afterwards? Has anyone tested how it fares against other deinterlacers or is it expected that the results are very similar to Didée's tests?

[Didée]

tritical - will do those nnedi2 PSNR's, too. In fact, I definetly would be apt to do a more extensive comparison test, like you did in the past. But you know it's quite an effort to do ... and the fact that my PC is from the beginning of this century doesn't exactly help. Would take me like half a year, and so I probably won't.

The results of PSNR often don't correlate well with HVS, that's oh so true. But that's known for long, and I don't feel like explaining the what-it-means, what-it-means-not, what-it-can-mean, and what-is-it-all-about every time such (mini-)tests are posted. People should know by now that PSNR does tell something, but is to be taken with a BIG grain of salt, and has to be interpreted in context. If they still don't know, so be it.


Dogway - no idea about the qual=3 issue with NNEDI2. Perhaps tritical has. "TGMC" of course is just a shorthand for quicker typing, and for using less space by subtitling. The new version still noone has, except me.


aegisofrime - I'm far from being concerned with 64bit world (well, perhaps later this year, who knows...), but in any case, it seems JoshyD is doing a monster job there! Someone order him free beer for the rest of the year!


Boulder - yes, selecteven/odd is the only way to get samerate. It doesn't even create additional overhead. If "samerate" would be integrated as a feature into TGMC, it would be done in the very same way. The motion engine has to work with all fields anyway, so there's not really much chance to take any sort of "shortcuts" to achieve same-rate deinterlacing. SelectEven/Odd is fine.

Regarding the to-be-expected testing scores of same-rate deinterlacing: The PSNR scores will stay pretty much the same. PSNR/SSIM metrics work only spatially, so it doesn't matter all too much whether all frames are evaluated, or only every other frame. The actual numbers will change only little, the overall figures stay the same.

The "temporal stability", related to "compressibility", is another story. When bobbing, the major part of additional bitrate (compared to TGMC) comes from the flip-flop effect, which causes relatively big changes from one frame to the next. When doing same-rate, the effect is much smaller: the result no more goes flip-flop-flip-flop-.., but either flip-flip-flip,.. , or flop-flop-flop-... i.e. the switching-effect between frames is (mostly) not present anymore. That's much easier to encode.


In numbers:
With the settings given above, Yadif needed 50% more bitrate than TGMC. When doing same-rate, it needed 15% more bitrate. That's much less of a difference, but it's still not trivial. Also, see it in combination with visual quality, as follows.

In moving pictures:
"Shields" sequence, lowpass was done before interlacing, then doing same-rate deinterlacing.
(The shields sequence is nice because it features horizontal translation, static parts, and zoom-motion at the end. Zoom is a tricky situation.)

Sample: Yadif vs. TGMC.selecteven (~36MB, sorry it got a little big)

Look close, then tell me why Yadif is so "widely recommended" ... to me, it is visually much worse than any PSNR or compress numbers would ever suggest.

[Dogway]

XD I was about to ask what version was that too.

Actually something had to be on cache on tests because now not even qual=2 works after rebooting, ah, and it crashes just starting first pass. Strangely Avsp shows preview perfectly, can even framforward.
I narrowed my script so the error must be somewhere in there, I post it for if someone can lend a hand.

global MeGUI_darx = 257
global MeGUI_dary = 200

setmemorymax(768)
SetMTmode(5)
Loadplugin("C:\Windows\system32\MT.dll")

SetMTmode(2)
DGDecode_MPEG2Source("D:\MyLovely.d2v")
ColorMatrix(dest=2,hints=false,interlaced=true)

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)
SRestore(FRate=23.976)
Dup(threshold=9,blend=false,copy=true,chroma=false,blksize=8,show=false)

trim(12281,22105)

[Boulder]

First of all, move the SetMTMode(2) line after the MPEG2Source. I'm also unsure whether SRestore works properly when multithreaded, weren't global variables a no-no?

[Didée]

tritical, here the PSNR results for NNEDI2 with qual=1|3, for non-adaptive tdeint with kernel interpolation, and for good old BOB(). Testbed setup was the same.

Filter settings:
- NNEDI2(field=-2,qual=1)
- NNEDI2(field=-2,qual=3)
- tdeint(mode=1,mthreshL=-1,mthreshC=-1)
- bob(0,0.5)


Quick numbers: (overall PSNR)

Parkrun2:
--------
NNEDI2(1)  33.10
NNEDI2(3)  33.29
tdeint     33.81
bob        33.45

Shields:
-------
NNEDI2(1)  38.47
NNEDI2(3)  38.62
tdeint     38.10
bob        37.96

Stockholm:
---------
NNEDI2(1)  39.15
NNEDI2(3)  39.26
tdeint     40.19
bob        38.63

Result screens: CLICKME


Lesson learned: on my rusty 1core, running 2 times NNEDI2 in parallel is about the same speed as running TGMC.

[Didée]

I'm getting tired of it, so throw it out in the wild ...


TempGaussMC, version beta-2.


Hope I've ruled out all mistakes, but you never know. If you find something, do speak.


What's changed:

- additionally requires VerticalCleaner.dll by kassandro!! (->Info)

- speedup by replacing slow-ish generic filters with faster alternatives. Depending on settings, 15% ~ 40% faster. Affected are several repair modes (tr0,tr1,tr2 parameters), and SVthin operation. When those are deactivated, there is no speedup either.

- introduced new "lossless" parameter:
-- lossless=-1 deactivates (default, same behaviour as has been)
-- lossless=0 is a dumb weave of original/TGMC fields. (Not for using! Just for demonstrating why it can't be done that easily.)
-- lossless=1 is a dumb weave with simple spatial correction.
-- lossless=2|3 use temporal compensation, followed by spatial correction. 2 is faster, 3 is calmer.

- optional "edeint" (clip) parameter. Works as known from tdeint and YadifMod. Useful e.g. when comparing several bob filters that all want to use NNEDI2 interpolation. May also safe from unnecessary script hacking when tritical comes up with NNEDI53 and EEDI427.

- adjusted some MAnalyse defaults:
-- "search" default is now "4" (was "2")
-- shifted the not-truemotion defaults for params "lambda"+"pnew" a little towards truemotion values.


Another side-effect of the "lossless" modes is that it makes the inherent noise-reduction of TGMC much weaker. That's no surprise: if the original fields stay really original, then they keep their noise, too.

[poisondeathray]

Thanks Didee!

I'm getting an error: Invalid arguments to "pointresize" , line 147

which corresponds to this in the .avsi downloaded from the link above

edi =  default(edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ), edi)

[Stephen R. Savage]

@poisondeathray: You can just comment it out. It occurs because edeint was not set, resulting in it having the "void" type when PointResize expects the "clip" type for its first argument. Perhaps this is a 2.5.6 vs 2.5.8 thing.

Alternatively, I think the following works (why -4?):

edi = defined(edeint) ? edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ) : edi

I find that the new version is mostly similar to the original, but some of the characteristic ghosting artifacts of TGMC on cartoons are greater in this version.