TDeint and TIVTC

[Chainmax]

This is awesome. Keep up the good work, tritical :). I'm going to try this version on my Spawn DVD as soon as I can.

[tritical]

[link removed], changes:
TDecimate:
- Fixed SetCacheHints being called incorrectly and always
defaulting to CACHE_ALL
- Small change to protect against overflow in mmx/sse2 blend
routines when one of the weights is 1.0
TFM:
- Fixed SetCacheHints being called incorrectly and always
defaulting to CACHE_ALL
It seems I was trying to invent a new way to call SetCacheHints, and it was not working :D. Thanks to Leak for spotting that. That one change for TDecimate seemed to make a pretty large difference in encoding time on his comp, but hardly any on mine so your mileage may vary.

Also, mode 2 is probably gonna be scrapped here soon, as it just isn't working. I have another idea for doing arbitrary frame rate decimation using cycles with automatically varying cycle/cycleR values throughout the clip. The good thing about such a method is it will be free of dependence on a threshold, but basing it off cycles means it does have to make some assumptions about how often so many duplicates are present. I have not been able to test it yet to see if it will work out, but it can't be any worse then mode 2 is now :p.

[PlazzTT]

EDIT: problem solved

[BangoO]

tritical, have a look here, there is an example in which your TD2VFix does not work :(
http://forum.doom9.org/showthread.php?s=&postid=593083#post593083

[scharfis_brain]

probably a bug:
chroma is always getting included in the Y-comb mask.
even if chroma=false is used to make 'sure' that chroma isn't inculed in the luma mask.

this can be prooved using a video with rainbowed static subtitles.
they always do show heavy bobbing.
Only if I set mthreshc to incredible high values like 100, the bobbing stops.

[tritical]

Its not really a bug, but lack of a feature. The chroma option only controls whether chroma is used in the combed frame decision, which is only used if full=false or tryWeave=true. When making the comb mask the chroma and luma planes are always linked. When I get around to working on TDeint again I'll add in a link parameter to let the user control how the planes are linked (no linking, Y to UV, UV to Y, or full).

[tritical]

TDeint v0.9.7 (http://bengal.missouri.edu/~kes25c/TDeintv097.zip), changes:

+ Added link and denoise parameters
+ Added ELA interpolation (tomsmocomp version) as type = 3
+ Hints option can now read hints from tfm as well as telecide
+ map = 2 now sets the chroma pixels that are to be interpolated to 255
and not just the luma
- Changed default type value to 2 (kernel interpolation)
- Changed default tryWeave value to false
Figured it had been long enough and might as well do the quick things. The new link option defaults to only linking Y to UV, whereas before each plane was linked to every other.

[Mug Funky]

excellent :)

would you recommend the ELA or kernel method as a generic deinterlacer? i've been using the ELA and haven't had any trouble (field-blended anime seems to come out very well regardless of what's used, which is awesome as field-blends are usually a deint killer rather than an easy case).

[BangoO]

How come the new version is 0.9.7 and the previous one is 0.9.7.2 ?
Shouldn't this one be 0.9.7.3 ?

[acrespo]

#BangoO:
TDeint: 0.9.7
TIVTC: 0.9.7.2

You are confused ;)

[tritical]

Should probably start another thread for tivtc since it is rather confusing having both it and TDeint in this one, but I'm still trying to wait till it gets to 1.0. Only things left are addressing the d2v fixing, mode 2 of tdecimate, and better use of the field matching information in the decimation routines. TDeint is almost there as well... I've pretty much given up on getting a new edge-directed interpolation routine working so there doesn't seem to be anything left on its todo list.

@Mug Funky
For same frame rate deinterlacing there isn't as much difference between the types... type=1 ELA is usually what I use for that case especially with anime/cartoons. For bobbing, kernel interpolation has always seemed to be better because of how it acts in stationary areas that don't get caught by the motion detection. Of course, kernel is also slower then the other types since it computes field differences... but doubt anyone concerned with speed is using TDeint to begin with :p.

[Mug Funky]

but doubt anyone concerned with speed is using TDeint to begin with

i don't know about that. it's actually quite fast when using it to IVTC to 59.94fps. this is useful in some circumstances (hybrid->pal fieldblend for DVD).

[tritical]

Well, if it isn't slow enough now I've got another interpolation type I could add. NEDI based with 6 tap linear interpolation instead of 4 (taking into account the middle pixels since its only upscaling by 2 in the vertical direction) with an 8x8 (really 15x8 with the extra pixels) window size and antialias prefilter... along with some light isophote smoothing based post-processing. It produces some very nice results with a wide range of images, but is well under 1 fps doing a dumb bob on a 720x480 frame :D.

[BangoO]

Originally posted by acrespo
#BangoO:
TDeint: 0.9.7
TIVTC: 0.9.7.2

You are confused ;)
Oops, I misread :D

[Mug Funky]

...is well under 1 fps doing a dumb bob on a 720x480 frame

bring it on :devil:

[akapuma]

Originally posted by tritical
TDeint v0.9.7 (http://bengal.missouri.edu/~kes25c/TDeintv097.zip), changes:
- Changed default tryWeave value to false

Hello,

I read, that it seems better to use tryWeave=false, when using TDeint as smartbobber. Is this the cause to set the tryWeave-default to false? Are there bad experiences with tryWeave=true in mode 0? If not, what's about a case sensitive tryWeave-default:

tryWeave-default = true if mode=0
tryWeave-default = false if mode=1

[Mug Funky]

i think the only real issue with tryweave is that it takes longer to do - if you already know the source is pure interlaced (not telecine), then it helps to prevent tdeint from checking for pure progressive frames.

also, it means that very small interlaced motion doesn't get passed through - the full frame field-matching in tdeint has different metrics to the "per pixel" matching, so where one would pass through a very slightly combed frame (which would be fine for shaky film), the other will catch the very slightly combed bits and treat them appropriately, while not touching the static bits.

(tritical - are my assumptions correct? i wouldn't want to give out misinformation)

[tritical]

Yep, your right Mug Funky.. and those are the main reasons I set the default to false. With natural interlaced video there is hardly ever a frame without at least some small amount of motion in which case weaving will leave behind artifacts. That said, there are some cases where weaving can produce better results then per-pixel approach, it mainly depends on the source material. Also, sometimes the added gain in detail from weaving out weighs letting a very small amount of combing through. One thing I'm thinking of is if your deinterlacing field blended anime... in the still sections you can still sometimes weave and get good frames. Anyways, the sensitivity of the combed frame detection should be lowered (the settings right now are not much different then ones that could be used for detecting combed frames in a stream that is assumed to be progressive). For example: cthresh=5, MI=20 would probably catch most anything you would spot watching at full speed playback. I will change those values for the next release, forgot to the last time.

[rawr]

I have a particularly tricky merged NTSC source I wonder if someone could help me with. I've had some succes with TDeint, blend and decimate, but looking at the fields think I should be able to manage better.

First is an approximation of what each frame consists of, the second what each field contains. ABCD are the 24fps frames, and Z is the D of the last pattern.Frames:
|ZZ||ZA|AB|BB|CC|DD|
|ZZ||AA|BB|BC|CD|DD|

Fields:
|ZZ|ZZ||ZA|AA|AB|BB|BB|BC|CC|CD|DD|DD|
1 2 3 4 5 6 7 8 9 10
Note that each sequence contains 3 blended fields... if these get into a final frame they'll mess things up horribly. However, I only lack two good fields for A and C, and TDeint makes up a pretty good frame from one field.
Basically I reckon I could get something quite good with A from TDeint on field 2, B from fields 4 and 5, C from TDeint on 7, and D from 9 and 10. Finally as all the frames are a bit messed up, some kind of nice post proc. is probably needed as well...
Now, the problem is I have no idea how to automate this, my attempts with Decimate etc have got me nowhere - the best I've mangage has A, B and C all as merged frames, and only D clean. Also, tackling this across scene and order changes might be an absolute nightmare.

As this is a little tough without pictures, have a look at my hastily set up lamehost (http://www.geocities.com/rawrsub/) - there's a vob piece on their for anyone who's feeling hyper helpful.

rawr.

[scharfis_brain]

@rawr:

restore24 will become your friend.

look for a thread called "restore24 revisisted"
there you'll find a package.

[rawr]

Bah, text searches never work the same way my brain does. None of my variations on the topic 'blending' turned that post up at all. I'll keep this post here for the moment as it's still somewhat about TDeint.

Right have tried Restore24 on my vob piece, and it failed - completely but promisingly. I have managed to get it to make some frames from TDeint, and some from normal melding of two fields, but never in a fixed pattern, and never reliably the same ones. Nor does it succeed in detecting the underlying pattern and adhering to it. I'll post my avs when I get home later. If you could download the vob on the site above and suggest some parameters, I'd be greatly grateful.

The main issue really is that the decision making is in a closed... and slow... loop. Not only the problem that if I run a multi-pass encode (and possibly more than once in the case of errors) it runs the same decision-making maths, but also I can't correct mistakes if I spot them. Now this is where I display my lack of knowledge of the vob format and Avisynth inner workings... As the encode itself only needs 6 out of 10 fields, and only two of those need TDeint-ing it would seem sesible to do all the decision making only once, and write to a plain text format. Not only does this mean subsequent passes are quicker, but also the decisions can be manually edited if you're crazy enough.
Seems to me there are four things you might want to do with a field. Use it as the top part of the next frame (T), use it as the bottom part of the next frame (B), upsample it to a whole frame with TDeint (U) or junk it completely (D). So, my sample would need a TB|DUDBTDUDTB - where each of the (worst) merged fields are discarded. You could record this as a key-per-frame as per d2v projects with T|SBDFT - upsample second field (S), use bottom field to this frame and top of next (B), junk frame (D), upsample first field (F), use frame as normal (T).
I'm sure this works in theory, but whether this kind of thing is at all possible in the avisynth framework I have no idea.

rawr.

[scharfis_brain]

I wasn't able to DL the VOB.
your site has reached its transfer limitation.

[Didée]

Scharfi: try here (http://x3.putfile.com/videos/3407563894.mpg)

rawr: Basically, R24 should work very good with your source. However, it could be that the internal metrics must be adapted: contrast on the blended fields is pretty strong - and to make things worse: the "clean" fields show a good amount of artefacts from a temporal softener, which makes them, in a sense, look like "blends" as well.

BTW, Restore24 does (currently) never adapt to any pattern. It doesn't need to do that. In a nutshell: it reckognizes single blends, replaces them with a neighbor field, and then tells SmartDecimate to cut the complete double-framerate dup sequence down to the destination framerate.

[rawr]

Wow, free hosting really is bad. I'll PM you a ftp link to my pc when I get back from work...

rawr.

[scharfis_brain]

restore24 works very nice with this sample video.

use


a=r24kernelbob()
b=tdeint(mode=1,type=2)

restore24(a,b,24,60)


it restores 23.976fps without any blends.
every 2nd frame is fully combined out of two fields while
the other frames are restored from the fields.

as you wished.

[rawr]

Try as I might, just can't get these results. At least one final frame remains blended, and up to three in the sequence can be.

My avs from you advice (minus comments and plugin loading):

mpeg2source("...chunk.d2v",cpu=4,iPP=true)
Crop(8,0,-8,0)

a2=r24kernelbob(0)
b2=TDeint(mode=1, type=2)

restore24(a2, b2, 24, 60)
LanczosResize(640,480)

Full thing, a test xvid and other bits are on my ftp, link PM-ed to you, and any other interested parties. I'm certainly interested to see if r24 can reliably detect and handle patterns, I just can't get it to play, nor does it seem to be at all front-end tweekable.

rawr.

[scharfis_brain]

hmmm...

I don't know exactly, why it fails on your side...

- did you really use all the plugins of the r24-package?

- putting plugins into
C:\Program Files\AviSynth 2.5\Plugins\
is probably a bad idea, cause they are getting autoloaded.
move all dll's from this directory into another one.

- use dginex/dgmpegdec instead of dvd2avi/mpeg2dec3

[rawr]

Hmm... tried the suggestions, no difference. Avs is obviously *working* - it even does the right thing from time to time. To be clear, I got the pack linked at the top of your restore24 revisited page (# # Restore24 v0.4c), put in new directory, generated new d2v with dgmpegdec... and get much the same. Is there anyway to get eh decimate to *mark* rather than destroy the frames? That way I can see if the field matching is working, but the decimate failing due to noise or something.

rawr.

[scharfis_brain]

hm.. it could be possible to write a pattern detector for your current clip. but I dont know, whether it will work reliable.

notation:
o -> original field (clean field)
d -> dupe of clear field
b -> blended field

your pattern is like this:

bodbobodbobodbobodbobodbobod

this means, after double_telecide , one gets this pattern

notation:
c -> combed
p -> progressive

cppcccppcccppcccppcccppcccpp

this means, one need to detect two progressive frames surrounded by two interlaced ones.
if this is the case, we know, that the first progressive frame is in sync with the first clean field and the middle combed frame is in sync with the other clean field.

but IMO it will fail on no-motion (moth moving) video ranges.

[rawr]

Right, had some time this evening so wrote a fix-this-specific case thing first (leaning new scripting languages is fun... ;_; ):

sf = clip.TDeint(mode=1, type=1).LanczosResize(640,480).SelectEvery(5,2).AssumeFPS(23.976)
dw = clip.DoubleWeave().LanczosResize(640,480).SelectEvery(5,4).AssumeFPS(23.976)
ConditionalFilter(clip, sf, dw, "current_frame % 2", "=", "1")

That takes the two weaves it can in this clip, and TDeint-s from two clean fields for the others. As just doing specific pattern is rude, made another version that can make four frames from whatever, you decide.

output_w = 640
output_h = 480
output_fps = 23.976
global offset = 0

frame_a = 2
frame_b = 4
frame_c = 7
frame_d = 9

method_a = clip.TDeint(mode=1, type=1) #.ShowFrameNumber().Subtitle("A")
method_b = clip.DoubleWeave() #.ShowFrameNumber().Subtitle("B")
method_c = clip.TDeint(mode=1, type=1) #.ShowFrameNumber().Subtitle("C")
method_d = clip.DoubleWeave() #.ShowFrameNumber().Subtitle("D")

method_c = BlankClip(method_c, length=10) + method_c
method_d = BlankClip(method_d, length=10) + method_d

fa = method_a.LanczosResize(output_w,output_h).SelectEvery(10,frame_a).ChangeFPS(output_fps)
fb = method_b.LanczosResize(output_w,output_h).SelectEvery(10,frame_b).ChangeFPS(output_fps)
fc = method_c.LanczosResize(output_w,output_h).SelectEvery(10,frame_c).ChangeFPS(output_fps)
fd = method_d.LanczosResize(output_w,output_h).SelectEvery(10,frame_d).ChangeFPS(output_fps)

ScriptClip(fa, "f = (current_frame - offset) % 4" + chr(13)
\ + "(f == 0) ? fa : (f == 1) ? fb : (f == 2) ? fc : fd")

Next step is to function-it-up, so you can pick a pattern for a range, and get the frames across it. However it seems though AviS has WriteFile(), it has no way of reading from them. So my nice list of scene change frames from SClavc may not be much use. At any rate, I certainly think trusting the pattern is probably wiser than running time-expensive anaylsis, that may well be confused by noisy source and small movements. Comments and such welcome.

rawr.

[manono]

Hi-

Although this is getting farther and farther off topic (I'm sorry, tritical), I have to agree with rawr. Although Restore24 does a decent job with field blended 25->30fps, I find it pretty much useless for field blended 24->30fps. I'm wrestling with one at the moment. I also believe that locking onto the pattern is the way to go, something like scharfi's UnblendPattern, but with pattern change detection. If you're really anal about this video, rarw, and have hours and hours to kill, you might try it.

[rawr]

To return slightly on topic, TFM() actually comes darn close to doing everything I need. Has all the interface I need (2-pass, first to editable plaintext, avs pattern overrides, smart matching... etcetcetc) problem is it doesn't acknowledge that fields exist, nor that you can do anything other than four weaves and one decimate in a cycle.

As this is anime, I actually have a lot of identical frames in a row, problem is you get reasonably noticable jitter between the weave and the tdeint frames. Doesn't matter for pans, but can be distracting on still frames. ATM I'm using Dup() with blend on - main problem is that even denoised there's a fair difference between weave and bob frames, compared to some teeny mouth movements, so hitting the 'right' frames to blend can be tough. Having a kill-this-frame, use-next-instead (or previous) is probably the last sensible thing I can do with this.

With a few other minor tweeks an field matched encoded version of that clip is on the lamehost (http://www.geocities.com/rawrsub/) - I upped the vertical res so the bob/weave matching problem is more obvious.

Work on a 'use this pattern for this range' function is pretty well set, bar annoynaces with the ChangeFPS() bug (http://forum.doom9.org/showthread.php?s=&postid=612045) - adding blank space to the start isn't a good solution for offsets. Main problems are I *still* want to do this two pass, and avs just doesn't want me to read from file. I might have to try to compile some dll that just does some fileread function wrapping.

rawr.

[tritical]

To return slightly on topic, TFM() actually comes darn close to doing everything I need. Has all the interface I need (2-pass, first to editable plaintext, avs pattern overrides, smart matching... etcetcetc) problem is it doesn't acknowledge that fields exist, nor that you can do anything other than four weaves and one decimate in a cycle. Was this just a general comment or did you have a specific feature in mind that would be useful to have? Atm, tfm allows for changing which field is matched from (and thus which field is maintained after post-processing) and allows for this to be controlled via overrides to vary on a per frame basis. Also, tfm actually supports 5 possible weave combinations, which include all the possible configurations that can be formed using the top or bottom field from the current frame with fields from the two surrounding frames. It also allows for using frames from an external deinterlacer to replace frames that are detected as combed after field matching (instead of using one of its in built pping types) and to even motion mask those external frames. I'm just wondering what other per field aspect you are looking for?

On a side note, the next version of tivtc is just about ready. Fixed the d2v fixing stuff (it is currently broken for non 100% 3:2 pulldown films), and added d2v support for the new dgindex project files (v7 and v8). The d2v option now also uses the rff flags to help detect duplicates in tdecimate and identify 24p sections when doing hybrid detection. Most similar decimation in tdecimate now takes duplicate via matches info into account as well. Wont be getting to mode 2 of tdecimate in this release though...

[rawr]

Oh, my main problem with it is probably that I have a very specific thing I want to do, and this isn't really set up for it. The standard run gave 4/4 blended fields, and my attempts with overrides just lead to confusing the idiot decimate even more. I can't override the decimate... or can I? Either way, I just have no idea how to apply TFM() to my problem - I've provided the vob if you care to try. It worries me that I can't even get the override to produce blank (unprocessed output), no decimate at all.

So, anyway, my main concerns are: It's not set up for following a set pattern at all - this means it misses small problems when it shouldn't need to. I can't control what frame will get dropped, nor have I succeeded in getting the override to actually match the right fields. There's no 'this frame is bad, but similar to the next - use that instead' facility as far as I can see.

At any rate, I could probably set up a clip2 that would have the right field to TDeint and replace when there's a blend, but TFM doesn't seem to like the idea of finding duplicates and using the better option, which is my other aim.

Trying to map my current system to yours, I think this is right:
TFF
Z|ZA A|AB B|B BC|C CD|D
0]1 [2]3 [45] 6[7] 8[9
P- C+ C- C+ (U-)
Now, if I could just force the decimate to fall on the (U-) and ensure that the top field is fed to the first blend, and the bottom to the next blend, AND maintain this across different overrides for different scenes, then this should work. Maybe.

rawr.

[Edit: Using (U-) rather than (P+) should make it easy for the decimate maybe...]

[tritical]

Yeah, most of that is too specific as far as functionality goes. However, you can override tdecimate's decisions using an overrides file and can specify a decimation pattern to be used over a specific range of frames, but it works off frame numbers only, so you wouldn't be able to set it up too look for a specific match such as U- to drop. You would have to identify the pattern and any pattern changes within the file.

For copying the next or previous frame instead of using the current that will never be a feature of tfm because trying to have it work automatically would create about 5000x more problems then it would fix. You could however use stickboy's remap frames filter, or something similar, after tfm and before tdecimate and specify the copying/replacing manually.

Now, if I could just force the decimate to fall on the (U-) and ensure that the top field is fed to the first blend, and the bottom to the next blend, AND maintain this across different overrides for different scenes, then this should work. I don't understand what you mean by "ensure that the top field is fed to the first blend" ?

Anyways, in the end tfm is, as you pointed out before, not really intended to handle this type of specific case, same for tdeint... unless you want to do the entire thing with manual overrides :D.

[KaiserS]

Hey tritical, I really enjoy TIVTC and use it almost exclusively now for doing IVTC. But recently I was going to make some encodes of my Patlabor DVDs but it completely trips up from the start and just passes out bad matches all the way through, which can be fixed with manual overrides but thats quite a pain (maybe TIVTC can be intergrated into YATTA one day?). I think the problem has to do with what appears to be a real rough telecine for the first couple of seconds (even if good matches come through the video has tons of aliasing) then it smoothes out. I've tried Decomb and it works reasonably well. It provides better matches but leaves alot of combing in the mouth flaps, has that problem with alot of anime, and requires going through manually as well which is why I chose TIVTC cause it didn't have this problem. Would it be possible to get a clip to you to see if you can work it out? I'm having a hell of a time trying to get it to work right. Thanks.

[tritical]

KaiserS, I sent you a pm with an ftp address where you can upload the clip if you are willing to. I'd very much like to run a few tests on it.

[KaiserS]

Had a problem uploading it to your ftp, so I sent you a PM where you can download it from mine. Thanks.

[tritical]

[link removed], changes:

TFM:
+ Added support for new dgindex d2v project file versions 07/08 (dgindex v1.2)
to the d2v option.
- Fixed the d2v method of fixing illegal transitions.
+ TFM now uses the rff flags from the d2v to help tdecimate identify duplicates
and 24p film.
- Changed default MI value to 100.
- Fixed the readme file indicating chroma=true, when it actually defaults to false

TDecimate:
+ Most similar decimation mode now takes duplicate via match info into account
+ Match duplicate info and d2v duplicate info is shown with debug/display options
+ rff info from d2v option in tfm is now taken into account when doing hybrid
detection
+ Increased the maximum possible cycle value to 300 One note about KaiserS's problem. It turned out that the problem was the incorrect field order was being used by tfm. The reason why though, was that the clip violated the d2v field order rule. The first trf flag was a 0 but the stream was actually tff. Seems the video was hard telecined as tff, but was stored as bff in the mpeg2 stream... very strange. Anyways, I have been thinking about changing the default mode value for tfm from 1 to 3 so that it will by default handle videos with field order changes or cases when the order parameter is set incorrectly, but decided not to for now. Anyone have an opinion on this?

Still on the todo list for TIVTC are mainly TDecimate features.

1.) The rff d2v info is currently only used to help identify 24p sections when doing hybrid detection... need to have it taken into account when deciding what frame to drop as well.
2.) Redo/Improve mode 2 of tdecimate.

[DarkNite]

Anyways, I have been thinking about changing the default mode value for tfm from 1 to 3 so that it will by default handle videos with field order changes or cases when the order parameter is set incorrectly, but decided not to for now. Anyone have an opinion on this?

I don't mind. If it causes jerkiness (is that even English?) in certain sources then people can simply follow the suggestions in the documentation and change the mode parameter to one that makes more sense for their situation/source.

The only time I've observed obvious jerky behavior was when trying mode=4 with a hybrid source using the one pass method of blend decimation. It's beautiful when jerky motion is ghosted as well. ;)

[Leak]

One suggestion:

Looking at my standard testbed for TIVTC (GITS:SAC Ep. 1), there's a scene where the camera pans horizontally across a cityscape followed by a vertical pan across a street. The metrics for the 5 frames including the scene change are the following:

6250: 11.96 c (new)
6251: 12.98 b (new)
6252: 13.47 b (new)
6253: 14.13 b (new) \the scene change is
6254: 41.04 h (new) /between these 2 frames


Now, if I'm using mode=1, hybrid=1 and conCycle=2 I'm getting a noticeable jerk in the horizontal pan because TDecimate decides that it should drop frame 6250. If I use conCycle=1 and a low enough sceneThresh (10 in this case), it'll treat this cycle as video, but will still only drop frame 6253, which looks quite perfect.

Now, of course I could use conCycle=1, but this produces an unneccessary blend that I'd rather avoid - shouldn't frame 6253 or 6254 (i.e. one side of the scenechange) get dropped here no matter if it was treated as video or film, i.e. if there's a scenechange in a cycle that wasn't treated as video because of conCycle being 2 or more, and it's a deinterlaced half-frame to boot, why not drop that (or at least one of the 2 frames around the scenechange) since obviously no other duplicate was detected? (Or something along those lines...)

I don't want to use a low sceneThresh since that produces not-so-good results on the parts that really are video, but have rather low motion... :(

np: Banco de Gaia - Not In My Name (You Are Here)

[tritical]

The simplest change would be when using concycle>=2, having tdecimate handle single cycles that are detected as video and have a scene change detected in them as video even though they are standalones. That would (should) fix the problem above.

This type of special handling around scenechanges is only active for hybrid=1 handling atm and will probably never be used for hybrid=0 (hybrid=2, of course, doesn't have to worry about it) for two reasons... 1.) because any cycle where it is necessary to do so I consider to be hybrid (in this case 30fps progressive) thus needing hybrid handling and 2.) making it work for hybrid=0 would be difficult cause tdecimate obviously doesn't do video detection in that case which is the main key to knowing that it is needed.

As for the scenethresh issue, you may get better results if you set chroma=false in tdecimate. Currently the scenechange metrics are computed from the block metrics to save time, so whether or not they include chroma depends on that setting, and the scenechange metrics w/o chroma should be much better. Making a change internally so that the scenechange metric is always calculated using only luma regardless of the chroma setting would be easy for yv12 but impossible for yuy2. There would have to be a separate calculation routine for yuy2 in the case that chroma=true. It might be worth it though, and I doubt many people use it in yuy2 to begin with.

[tritical]

@Leak
I made those two changes [link removed]... single video cycle with scenechange and concycle>=2 and scenechange metrics are now always calculated via luma only regardless of the chroma setting. Whenever you have time could you test that version on that gits:sac clip and see how it handles it?

Also, having that type of handling around scenechanges for hybrid=0 might be worthwhile. Something like what you mentioned above, if all the frames in the cycle have metrics above a specific threshold, check if there is a scenechange present and drop a frame on the scenechange instead of the frame with the lowest metric. Only problem is it adds another threshold, I may just set that internally to a value large enough that it would never trigger accidently (4.0 or so) and see what happens. Anyways, that wont be added for a while probably...

[Leak]

Originally posted by tritical
@Leak
I made those two changes tivtc test (http://bengal.missouri.edu/~kes25c/TIVTCb.dll)... single video cycle with scenechange and concycle>=2 and scenechange metrics are now always calculated via luma only regardless of the chroma setting. Whenever you have time could you test that version on that gits:sac clip and see how it handles it?

Yes, it works. :)

Anyhow - another idea: could you make it possible to suppress scene change detection in "long" (that is, 2 or more cycles) video parts, since everything is getting blended there anyway? In the intro there's a few spots where 2 consecutive video cycles get frames dropped even though there really wasn't a frame change, and I'm not sure this won't be noticeable in the output - I'd rather have the whole intro blended down equally.

I.e. why detect scene changes in the "real" 30 FPS parts, where the special handling is rather bound to stand out among the rest? Getting a non-blended frame now and then doesn't really do much, does it?

np: Andrew Pekler - Unidentified (But Then Again)

[tritical]

It could be disabled in that case... though I very much dislike when a blend comes across a scenchange, even if there has been blending up to that point.

Out of curiosity, would forcing the constraint that for a scenechange to be detected there must be only one frame with a metric above sceneThresh in all three cycles (prev, curr, next), help with that clip? Currently it is required that there be only one frame above sceneThresh in the current cycle for it to be detected as a scenechange. Forcing there to be at max one per three cycles would probably help eliminate false detections in areas with lots of motion.

[scharfis_brain]

tritical, after tweaking a lot with may motion adaptive deintlacers, I found many various real world videos that are causing them to produce weird combing artifacts.

pleaso take a look at SMDs Thread:
http://forum.doom9.org/showthread.php?s=&threadid=90896&perpage=20&pagenumber=1

these weird artifacts are produced because the motion in the fields is causing a stable on/off pattern within the field sequence, which lets the motion map think, that they are static.

maybe an ADDITIONAL motion vector check could help to differenciate between true static and pseudo static (moving patterns) structures ?!?

[tritical]

Did you have a specific check in mind? Cause to me it seems the only thing that would do it is comparing the opposite parity fields in some way instead of only comparing same parity fields. Either direct or indirect by comparing to an interpolated value.. i.e. a spatial combing metric which currently tdeint completely avoids. Also, as soon as it goes the combing metric route you might as well use an area based deinterlacer since almost any combing metric is only gonna spare the non-detailed areas to begin with, which you mentioned in the other thread. I'm open to any new ideas though... I sure don't have any for eliminating that type of artifacting besides the old combing metric routine.

Actually, you might be able to retain some of the benefits of motion adaptation if you switch between using inter-field and intra-field differencing on a block basis. Usually those types of artifacts occur in areas where most of the surroundings are moving as well (and are detected as such). Just an idea.

[tritical]

Small bugfix updates that I meant to post last week, but forgot about...

[link removed]

[link removed].

The changes mentioned above for Leak's issue were also included in this version of TIVTC. Complete change list:

TIVTC:TDecimate:
+ Scene change metrics are calculated using only luma, regardless of the chroma option
+ There can only be one change above sceneThresh within the current cycle as well
as the surrounding two cycles for it to be detected as a scene change
+ D2V rff duplicate info is taken into account when deciding what frames to drop,
instead of only for hybrid detection
+ When hybrid > 0 and concycle or concycleTP is greater then 1, single cycles that are
detected as video and that have a scene change detected in them are treated
as video

TFM:
- Fixed a crash that would occur if the d2v option was enabled and trim() or some
other filter that altered the number of frames was used prior to tfm()TDeint:
+ Fixed not correctly reading hints from newer versions of tivtc or if colorimetry
hints were present from dgdecode.

[tritical]

Alright, here we go again :)... [link removed]. This mainly focused on adding some missing logic (assuming match info from tfm is present) in most similar decimation mode. It can now handle panning->static and static->panning transitions like longest string. It can also detect when a cycle needs two frames dropped. I also tweaked longest string decimation a little (this is for when extra info such as match info or rff info from tfm is present). It should make slightly better decisions and be more accurate at finding cycles that need two frames dropped. Complete changes:
TDecimate:
+ Added missing logic to most similar decimation mode. It can now correctly handle
panning->static and static->panning areas like longest string. It can also
detect cycles that need two duplicates dropped. Assuming match info is present.
+ Tweaked decimation decisions for both longest string/most similar.
+ Added isse luma diff calculation routine for yuy2
- Fixed a bug in the longest string decimation decision that utilized match info
from tfm.

TFM:
+ Post-processing now only links luma->chroma on the motion map, instead of doing
full luma->chroma, chroma->luma, and chroma->chroma linking.

[tritical]

Four posts in a row, :D! Well, I've been unusually busy lately and haven't been able to work on TIVTC or TDeint hardly at all, but here is one minor update... [link removed]. The only change is the addition of a new filter called MergeHints() that allows the use of denoisers and other such filters inbetween tfm and tdecimate while still allowing tdecimate to get tfm's hints. I think a little example will best explain how to use it (it will work with any filter that hides hints in the lsb of the first 64 pixels, such as decomb, dgdecode, and others):

This is a script where TFM's hints would normally be destroyed and never reach TDecimate:

mpeg2source(d2v="source.d2v")
tfm(d2v="source.d2v")
temporalsoften(3,3,5,15,2) #destroys the hints
blur(0.25) #destroys the hints
tdecimate(mode=1)

To fix this, and preserve the hints (they can greatly aid decimation, especially if using hybrid detection), use MergeHints as follows:

mpeg2source(d2v="source.d2v")
tfm(d2v="source.d2v")
savedHints = last
temporalsoften(3,3,5,15,2)
blur(0.25)
MergeHints(hintClip=savedHints)
tdecimate(mode=1)

The only thing remaining for TIVTC before v1.0 is the new mode 2 operation for tdecimate, which should be added within the next few days (thanks to scharfis for sending a clip to test with).

Also, after considering some possible solutions for handling motion adaptive artifacts in TDeint, I've decided to take the only way out I can think of and add an optional post processing mode. It will scan the final output frame using the 5-point combing metric from tfm with a user controllable threshold (set relatively high). Any pixels detected will then be interpolated. Its not an optimal solution, but should provide a means with which very visible artifacts can be prevented. That is the only thing left on the todo list for TDeint before it reaches v1.0.

There is also a new ela method I've been working on, but atm it doesn't look like I'll be merging it into TDeint or TIVTC for a while. However, there is a reason that they each have a clip2 option.

EDIT (April 22nd):

Still haven't had time to get the new mode 2 for tdecimate added to TIVTC or the post-processing added to TDeint :(. However, I have made a few smaller, mainly bugfix releases:

[link removed]
[link removed]

TIVTC changes from v0.9.8.3:
TFM:
+ Debug and display options now output a value called MIC (the value that is
computed and compared against MI to check if a frame is combed) to make
tweaking the MI parameter easier.
- Changed default MI value to 85 (also changed to 85 in IsCombedTIVTC)
- Fixed the white box drawn on combed frames when PP=1 sometimes being drawn
in the incorrect spot when mode was set to 1, 2, or 4

TDecimate:
+ Added exPP parameter, fixes handling of interlaced frames marked in tfmIn
files when PP=1 in tfm and an external post-processor is used to deinterlace
the combed frames.
- Fixed crash caused by above circumstances
TDeint changes from v0.9.7.1:
- Fixed not correctly using the field information from tfm's hints when acting
as a post-processor for it. Also fixed not correctly altering the match
info of tfm's hints when acting as a post-processor for it (PP=1 in tfm).
+ Improvements to type 3 interpolation, renamed to modified ELA-2

EDIT (April 24):

[link removed]

Got some free time and finished up a v1.0 beta 1 of TDeint. It adds the artifact protection (AP) threshold and post-processing (yes, the AP name was stolen from DGBob), which can be used to help prevent very obvious motion adaptive artifacts, and variable window size during combed frame detection (blockx, blocky). I called it beta 1 as I'm gonna wait a week or two and see if anyone spots a lingering bug... though I seem to be the only one posting in this thread anymore :D. Anyways, it only took ~ 7 months to get to v1.0.