TDeint and TIVTC

[tritical]

Well I made a new motion adaptive deinterlacer/smart bobber called TDeint. The main three reasons for its existence are it is bi-directionally motion adaptive... meaning if you have the following field and pixel sequence, where '-' is the pixel position to be filled:

a d g j m
c f - i l
b e h k n

Then TDeint will try either weaving the average of f and i, or simply f or i based on the motion in the surrounding pixels. Afaik, the only deinterlacer that currently does this is scharfis_brain's intellibob. All other motion adaptive deinterlacers currently only weave whatever pixel gets weaved into the current frame by default. That means that all pixels will be detected as moving in the first frame after a scene change. (If I am wrong about this and another deinterlacer already does this please tell me!).

Second, this filter is using a new form of modified ELA interpolation that I have been working on recently. It takes into account the direction of the normal line to the gradient vector when deciding in which direction to average, and attempts to tune the interpolation so that it can adapt to any edge direction within its range. In terms of quality, it is better then plain 5+5 tap ela as in tomsmocomp, but not quite as good as some other techniques such as NEDI or edge post processing as in antialiasing that sangnom uses. The nice thing about this method, though, is that it is still pretty fast (running about 30fps in dumbbob mode on 720x480 images on my comp). For comparison, here are a few images of a simple dumbbob (no motion adaptation), the first was made using this modified form of ELA, the second was made using tomsmocomp(-1,-1,0) (5+5 tap ela w/ clipping), the third was made using AviSynth's built in bob which uses cubic interpolation, the fourth was made using sangnom(aa=0), and the last was made using sangnom().

modified ELA (http://bengal.missouri.edu/~kes25c/modifiedELA.PNG)
tomsmocomp(-1,-1,0) (http://bengal.missouri.edu/~kes25c/tomsmocomp.PNG)
AviSynth's Bob (cubic) (http://bengal.missouri.edu/~kes25c/cubic.PNG)
sangnom(aa=0) (http://bengal.missouri.edu/~kes25c/sangnom0.PNG)
sangnom() (http://bengal.missouri.edu/~kes25c/sangnom.PNG)

Third and finally, it has support for user overrides. Not only allowing the user to set which frames should be deinterlaced as fielddeinterlace() does, but also allowing the meaningful parameters to be adjusted for single frames or ranges of frames. Also, when working as a same frame rate deinterlacer it allows the user to control which field is kept and which field is interpolated.

Anyways, the reason I posted this in the development forum was that I don't really have much if any true interlaced material to test with, aside from what I can capture here in my dorm room. Thing is, we have about the worst cable reception known to man so its hard to tell if a deinterlacer is any good. I was hoping someone with some true interlaced material would be inclined to test it a little or someone could send me a few interlaced clips to test with to make sure everything works alright. It does seem to work great as a per pixel field matcher, as I have only been testing it with telecined material from dvds. With default settings the filter runs around 45-55fps on my 2.2Ghz p4.

TDeint v1.1 (http://bengal.missouri.edu/~kes25c/TDeintv11.zip)

TIVTC v1.0.5 (http://bengal.missouri.edu/~kes25c/TIVTCv105.zip)

EEDI2 v0.9.2 (http://bengal.missouri.edu/~kes25c/EEDI2v092.zip)

TMM v1.0 (http://bengal.missouri.edu/~kes25c/TMMv1.zip)

avi_tc_package v1.5 (http://bengal.missouri.edu/~kes25c/avi_tc_package.zip)

If you're looking for older versions try: old_stuff (http://bengal.missouri.edu/~kes25c/old_stuff/)

[scharfis_brain]

in mode=1 it only returns the half number of frames of the video. the framecount is the one of the bobbed video, but it stops moving after the half of the length.

could you make it optional, whether, both fields are weaved or only one of both, even if low motion allows it?

btw. great work!

I will test it more intensive tomorrow.
I was hoping for such plugin for along time :)

[tritical]

Sorry about that, stupid bounds checking, really not sure how I missed that one when I was testing it :o. There was also a problem with one of the motion checks being incorrect (not getting set to false) on the very first and very last frame of a video. Hopefully, there isn't anything else wrong... I actually tested it and looked over the code quite a bit before I released it, so much for that :).

Yeah, I can add the option to have it only weave from previous or only weave from next... I had tried to keep the # of options as low as possible for this filter as compared to some of my other filters.

[Mug Funky]

wow, this is a really f***ing good bobber.

i've gotta go rip one of my field blended animes... i might finally have something to give it that (a) doesn't make odd block artefacts (intellibob is great, but i get strange bits unpredictably so i can't use it for serious stuff), and (b) is fast enough.

hmm... i've got some PAL interlaced DVD crap if you want to see it. interlaced fade-ins and outs cause hell with anything, but it might be worth seeing how this performs anyway.

will post a clip in a few mins (what's the max length of a sample i can post to avoid being flayed alive by the MPAA? i doubt the publishers of this DVD really care, but i'd like to keep things legit)

[edit]

here's 20 sec or so from the start of John Safran's Music Jamboree. i left the sound in cause it's pretty funny...

rightclicksavetargetas, or you'll end up with plain text garbage (at least i did when i tested it).

if it's dead, tell me because i'm new to apache...

http://210.49.108.136:8080/safran.vob

14.4MB

[edit edit]

the default thresholds are a little too high for field-blended anime - it gets chunky very fast. here's a sample of the Chobits intro, r4 pal (field blends up the whaazoo)

http://210.49.108.136:8080/chobits_intro_chunk.m2v

hope these are enough to start tweakage...

by the way, i'm hosting these on my machine, so the links will go dead when i go to bed...

[edit 3]

changed URLs in the hope that they will work properly...

[tritical]

@Mug Funky
Just tried the links and they didn't work... but maybe your comp is still off? I would very much like to run a few tests on those samples.

@scharfis_brain
When you said make it optional if both fields are weaved, do you mean make it so that it can be set to only be motion adaptive in one direction? or that it should not use the avg() of the two center pixels but just one or the other?

As for the filter, I'm implementing another mode for motion detection that requires a 5th field worth of no motion in order to declare a pixel position stable. It will be slightly slower, but should help eliminate any of the stray artifacts from the usual 4 field motion check. Have to see how it performs...

[scharfis_brain]

forget about that anti-averaging request.

but it would be good IMO, if the filter decides for the whole plane, whether the next or prev field is used, instead of doing this pixelwise.
I ask for this, cause fieldblended video always swaps its phase, so the pixel of the wrong-phased (non-fitting) field would not be relevant (the sum up to less than 1% of the whole weaved pixels).

the next thing I would think, that it would be good, is kernel-interpolation.

it is not as jaggy-free as edge-directed interpolation, but it produces a much more stable (lesser flickering) image in bobbed areas, cause my intellibob uses a one-way kernel, that is turned to fwd or bwd direction to fit the in-phase-field. (but I think, this would be hard to implement)

EDIT:

my very raw intellibob() replacement with hardmatching, when fields are near to equal:

function matchbob(clip c, int "combth", bool "show")
{
show = default(show, false)
global cth = default(combth,6)

ord = c.getparity() ? 1 : 0
odd = c.doubleweave().selectodd().telecide(order=1-ord,post=0)
even = c.telecide(order=ord,post=0)
tel = interleave(even,odd).duplicateframe(0)

analyse = tel.greyscale()

tel = show ? tel.subtitle("fieldmatched") : tel

bobbed = c.TDeint(mode=1, order=ord, mthreshL=8, mthreshC=6,type=2)
bobbed = show ? bobbed.subtitle("bobbed") : bobbed

conditionalfilter(analyse,tel,bobbed,"iscombed(cth)","==","false")
}

[tritical]

k, I wont do the non-avg option. On the kernel interpolation I will definitely try it... probably the one-way and one-way sharp kernels from kerneldeint. An easy way to switch between using the prev or next field in the kernel would be to simply subtract each field from the curr field and use whichever one is most similar. Its not super complex, but should be a little better then always using the previous field. The per field weaving instead of pixelwise weaving I think I'll leave alone for now because it would effectively make it a field matcher and probably a rather poor one :D. Atm, this filter is more intended for true interlaced material or material where you can't do pure field matching as opposed to a combination of each like your matchbob function.

[Chainmax]

So, this filter followed by a decimation results in IVTC? In any case, I could provide you with some samples of the "Spawn 1º Season" DVD if you're interested.

[Mug Funky]

@ tritical:

sorry... looking at the time you posted, it was 4:38 AM my time.

i'll leave my machine on tonight. i just hope apache is behaving itself... it works when i click the links myself, but if there's firewalls and stuff happening i might have to set up one of those port redirect things.

post again if you can't get them and i'll see what i can do.

[tritical]

@Mug Funky
Just tried them an they wouldn't work :(. Internet explorer just says it can't establish a connection to the server.

I posted v0.9.2, I added kernel interpolation... the one way sharp and normal kernels from kerneldeint. It switches between using the forward or backward field based on which one is most similar to the current field. In terms of flickering it was definitely a large improvement. I also added the 5 field motion check, well... half way added it. I got the extra 2 field checks in there to make it 5 field, but didn't implement any of the 4 field checks I was planning and which would be the most effective with fades. The other thing about the 5 field check, is that it can deal with having duplicated interlaced frames in the video where the 4 field can't. Anyways, still have things to test.

[Mug Funky]

try again :)

just changed the links.

i wish i had 2 computers working on different lines so i could test these things myself... the only current test i have is to give people links over instant messenger progs and ask if they worked...

[edit]
just got a friend to test it on his machine and the link seems to work fine. i suppose any other problems will be from firewalls blocking port 80 and 8080.

[edit edit]

oh, and Chainmax:

in theory it's a simplified IVTC on the pixel level, but in reality it'll deinterlace parts that can be IVTC'd. it works spectacularly in conjunction with BlendBob though - it handles the black orphan field in the Eva renewal NTSC intro sequence perfectly! no blurring or anything.

so i'd say that Tdeint bobbing + blendbob + decimate will get you a pretty good IVTC. i'd prefer to use it as a fallback for that though.

my main interest is in pure interlaced and field-blended stuff.

Tritical: assuming the links work now, would you like some other samples? i've got a lot of crap DVDs lying around, and a small amount of home-shot DV footage.

[Chainmax]

I repeat my offer to post some samples from my Spawn DVD then.

[tritical]

@Mug Funky
Yeah it worked this morning, I had to leave before they finished dling but they should be done. I have enough samples to mess with for now... was searching through some of the assorted clips I have and found a small vob piece of ranma ep 1 which is quite horrible and has blended fields :).

@Chainmax
Thanks for the offer, but I have plenty of plain dvd type material... I was mainly interested in pure interlaced samples which I have none of other then a few very bad tv caps. About the other stuff... like Mug Funky said you could do an ivtc by following TDeint with decimate()... which would work with any deinterlacer. It would not be nearly as good as using a pure field matcher + decimate though if your video can be cleanly ivtced. This filter is just a pure and simple per-pixel, motion adaptive, deinterlacer as in kerneldeint, smoothdeinterlace, alignfields, etc... the main difference being that TDeint detects motion both backwards and forwards instead of just backwards.

[scharfis_brain]

hey trictical!

great work!

now I have the ultimative bobber for my fieldblended crap.

many thanks.

edit:

and again: a request.

could you knock out the order-parameter?
tdeint should be able to detect the correct fieldorder itself by reading the avisynth fieldorder flags, which are set using AssumeTFF() and AssumeBFF().

[Chainmax]

tritical, the Spawn DVDs can be called everything but plain. Quoting Gizmotech:

I have seen a vob sample of this cartoon from a friend.

The series contains real interlacing, as well as full frame blending (in spots).

You can read more about it in this thread (http://forum.doom9.org/showthread.php?s=&threadid=70353&highlight=Spawn) (the clips posted in there are no longer online, BTW).


Anyway, I'm going to try TDeint's bobber along with BlendBob as soon as I can and report back.

[joshbm]

I downloaded your TDeinterlacer. Gives me an error message and I can't open VirtualDubMod anymore! How do I fix that?


AVISource("G:\0829 TV.avi")
Trim(94104,-389)

converttoyv12()
TDeint(order=FOrder())
converttoyuy2()

[Mug Funky]

you need to define Forder...

try it with just "order=1"

[edit]

oh, if you're using DV as a source, you should go "order=0" i think.

or use this to determine it:

#assumetff()
assumebff()

order = (last.getparity==true)? 1 : 0

tdeint(order=order)

unless you're making a customized function, there's probably not much need for all that, and a simple 1 or 0 would suffice.

[joshbm]

It works now lol. It was because I was working on a function and I didn't debug it yet and it contained errors. It was in the plugin folder and was trying to be loaded into VDubMod and AviSynth. Didn't work too well :p.

Thanks Though!
Josh

[tritical]

I will make the filter use the internal parity if the user does not set the order parameter, and also add the option to read telecide's hints and set the field to 0 if the user does not specify it since telecide matches off the bottom field.

Been busy the last few days, but I should get a new version up this weekend with the above options, and a completed 5 field motion check which includes the 4 field distance checks to help with fades and motion adaptive related artifacts in general. That will of course make it even slower then it already is :D.

@Chainmax
Didn't realize it was so screwed up ;). If you do test out TDeint on it I would be interested in the results, but I'm not sure it would be much better then anything else if its a really bad source.

[Chainmax]

I am uploading a 17MB Xvid clip. Here's the script I used on it:

TDeint(mode=1,order=1,mtnmode=1)
BlendBob()
Decimate(cycle=5,mode=2,quality=3)
Crop(8,0,706,480,align=true)
LanczosResize(640,480)

Once it's finished uploading, you can get it from here. If you want, I can also make some vob samples available as well.

[tritical]

Put up version 0.9.3, changes:

+ Added order = -1 option, will detect parity from avisynth (this is now the default)
+ Added hints option for reading telecide hints for interlaced/progressive (use hints=true,post=1 in telecide)
+ 5 field motion check now includes checks over 4 field distances
- Fixed a bug in YUY2 type = 1 deinterlacing

Also, after testing on the sources Mug Funky sent, I would not recommend using type=1 (modified ELA) on non anime/cartoon material. Either go with kernel or cubic interpolation for natural sources. I will probably change the default in the next version.

@Chainmax
I'll take a look at the clip and see just how bad it is :p.

[Didée]

Originally posted by tritical
after testing [...] I would not recommend using type=1 (modified ELA) on non anime/cartoon material.
Some description about why you wouldn't recommend that?

Actually, I'm working on a Live recording (DVB source) where the upper fields are just plain unusable - they are fieldblends of the shifted bottom fields (!). The experts from television :devil:
So, I've just one field for upscaling available. After trying out lots of things, I got the best results on jaggy-ness reduction, shimmer reduction and keeping things as sharp as possible with
TDeint(mode=1).TomsMoComp(1,-1,1).LanczosResize().
That's the best base filtering I could come up with so far.

(And BTW, it's astonishing how good a 464*208 source can look at 704*512, with some dedicated slow filtering ;) )

[scharfis_brain]

didée: for you purpose (completely missing information of one field) the ELA is the best way to go.

but for bobbed deinterlacing of natural video, the ELA produces more flickering (but lesser jaggy diagonals) than the kernel interpolation method.

this is caused due to the nature of the kernel: it just has some information from the other fields. the ELA in opposite works blind.

[
I've done something, too some months ago. the television-experts sometimes knock out one of the fields and interpolate this field by line averaging (like shifting the remaining field by 1/2 pixel).
They seem intend to get the film-look, but I say, they produce a "pop-sta(i)r-look".
for exactly this scenario I wrote a function, that detects this kind of pseudo progressive and interpolates those blurred fields using tmc(-1,-1,0). video-overlays, that are interlaced/true progressive are not touched using my function.
]

[erratic]

I compared the speed of TDeint(mode=1,order=1,type=2) with Leak's KernelBob(order=1,sharp=true) and KernelBob was nearly 4 times faster. The source was normally interlaced PAL (not telecined stuff). Is there any way to make TDeint as fast as KernelBob? Or should I just use KernelBob for normally interlaced stuff and TDeint for fieldblended crap (as scharfis_brain calls it)?

[Leak]

Originally posted by erratic
Is there any way to make TDeint as fast as KernelBob?

Well, a quick peek at Tritical's sources shows that he's using pure C++ while my implementation of KernelBob uses MMX to speed things up; I'm not sure if you'll get a 4x speedup out of using MMX here (didn't look at the algorithm closely enough), but it sure would make things faster.

Then again, I don't have the intention to MMXise yet another deinterlacer in the near future, so somebody else would have to do it...

np: Arovane - Cry Osaka Cry (Lilies)

[tritical]

@erratic
There is one thing I can say with absolute certainty... it will never be as fast as Leak's MMX optimized kernel deint :( even if it was MMX optimized. Its simply a matter of complexity... in terms of the motion checking (which is substantially more involved then kernel deint's), weaving from either the prev or next field (goes back to the motion checking), the motion map denoising (though it is pretty weak atm), the switching of the one way kernel between forwards and backwards, etc... There is also the fact that I pretty much refuse to code or even try to make MMX/iSSE versions of things anymore... mainly out of laziness :) and not having the time, but also because it tends to limit how much you can test new ideas since a major algo change can cause you to have to rewrite all that assembly code. I am still testing/changing quite a bit of the main code atm... I may look into doing optimizations for some functions when things get more stable... but don't count on it. I'm actually surprised it was only 4x slower... try mtnmode=1, maybe we can get it 8-10x slower :devil:.

@Didee
I probably generalized that statement too much. Like every edge adaptive interpolation scheme this one suffers from problems/artifacts in very detailed areas with multiple edges/lines. Usually anime does not have as much fine detail like this compared to movies, etc... except for kanji and some other things off course. So I'll take back what I said and simply say that if ELA interpolation is causing a lot of artifacts try using kernel or cubic interpolation instead. Kernel interpolation is definitely much better when it comes to flickering in almost static areas, this can even be noticeable when doing same framerate deinterlacing on noisy sources.

@Chainmax
Aside from being noisy I didn't think the sample looked that bad, it was better then what I was expecting. In terms of getting progressive frames I thought it was pretty good for how it was decribed in the other thread.

[Chainmax]

Well, the description in the thread corresponds to the (unfiltered) vob samples. The clip you downloaded was compressed using the script I posted earlier. That's why I offered to post some vob samples so that you could make a comparison.
And yeah, the results are very impressive. Did you see the scenes with close-ups of Spawn's face? In all the other methods I tried, the eyes showed a lot of jaggyness. TDeint is the only filter that almost eliminated that :). I think I have finally found an adequate script for ripping this DVD (just need to throw some deen at it):) :).

[joshbm]

Originally posted by Didée
Some description about why you wouldn't recommend that?

Actually, I'm working on a Live recording (DVB source) where the upper fields are just plain unusable - they are fieldblends of the shifted bottom fields (!). The experts from television :devil:
So, I've just one field for upscaling available. After trying out lots of things, I got the best results on jaggy-ness reduction, shimmer reduction and keeping things as sharp as possible with
TDeint(mode=1).TomsMoComp(1,-1,1).LanczosResize().
That's the best base filtering I could come up with so far.

(And BTW, it's astonishing how good a 464*208 source can look at 704*512, with some dedicated slow filtering ;) )

I attempted your TDeint(mode=1).TomsMoComp(1,-1,1).LanczosResize(). It said that the video framerate's did not match. Except when I set the mode=0. BUT I want to bob my video to get double the framerate, so this does not help. What am I doing wrong here?

Thanks!
Josh

[Didée]

Aaargh. I swapped parameters when recalling from my (poor) memory.
Of course I used TDeint(mode=0, field=1), since there is nothing in my stream that could be bobbed ... and the blends are in the bottom's, not in the top's. *Cough*.

Joshbm, I assume the framerate mismatching you're experiencing comes from the one-line-script with bobbing. Try to separate it:

TDeint(...)
TomsMoComp(1,-1,1)
LanczosResize(...)

Although TMC should not bother, since with (1,-1,1) it does spatial-only interpolation without field matching ... but you never know. There are worse things in life.

***

However, with spatial-only interpolation, I never got anything out of any deinterlacer that *really* satisfied me. At least not in "directly" applying the filter. There's always way too much jaggyness left for my taste - though it gets (much) better if one first blows up the fields to double the height.

So, here's another thought that's wandering through my mind for quite some time now. It's about spatial-only interpolation of missing fields, to avoid jaggyness. Perhaps this is already sort-of-implemented in any filter, perhaps it's not. I just don't know...

I think that all methods so far start out to work on each single pixel, and then examine a more-or-less small area around the current pixel to gather information - be it 5x5 tap, modified or unmodified ELA, or whatever.
Well, as far as jaggyness is concerned, it is only an issue on edges close to "horizontal". Starting with edges having a slope of "2", like

____XX
__XX__
XX____

the problem already starts to go away, and on 45° edges a simple resize() works near-to-perfect. So, what we do have to conquer are only the edges "below" 45°.

Now, what about ... a "scanline search"? A filter that searches 2 complete scanlines at a time, finds the correlating areas between them, and interpolates accordingly?
Searching (sort of "parsing", in this respect) basicly would enable something like the following, relatively easy:


..........XXXXXXXXXXXXXXXXXX...........
....::::::.::::::::::::::::.:::::::....
....XXXXXXX................XXXXXXXX....

..........XXXXXXXXXXXXXXXXXX...........
.......xxxoxxxx........xxxxoxxx........
....XXXXXXX................XXXXXXXX....

o = found area match between scanlines
: = not-matching area of a "matched feature"
x = interpolation around matches

where the "horizontal length" of the interpolation is based on the length of the not-matching area. Could be 1/3 of the not-matching area in "dumb mode", or could be adaptive based on the scanlines +2 and -2, if it can be afforded to include even these into evaluation.

For areas, or "features", that have no "matching" on one side or the other, a simple (lanczos) resize would be appropriate, then.

Now, that's draft, crude & basic, and needs of course some more comparing & computing. But basically, it seems not too unreasonable to me. Or is that already something like an "ultra-primitive ELA"?

I even tried to script something in that direction ... but you now, *directional* searching is almost impossible in an avisynth script. :/

[joshbm]

@Didée:

Weird, it still doesn't work... lol.. but this works:

TDeint(...).AssumeFps(last.framerate).TomsMoComp(1,-1,1).LanczosResize(...)

Whatever works :p.

Thanks!
Josh

[tritical]

@Didee
Your idea is very similar to plain n+n tap ela, though your probably thinking of a slightly larger scale. Plain 5+5 tap ela works like this (where o is the pixel to interpolate):

a b c d e
. . o . .
f g h i j

Take the absolute value of the differences of pairs (a,j), (b,i), (c,h), (d,g), and (e,f). Then simply average the two pixels that have the lowest difference and use that for o. This is exactly what tomsmocomp uses, except that it clips the calculated value into the range of +-2 or 3 of min and max of c and h. The reason being that this method is insanely prone to artifacts since the minimum difference can easily have nothing to do with edge direction. i.e. the edge runs through (b,i), but (f,e) has a minimum value. etc... However, this clipping eliminates a lot of the benefits of the algorithm since on most edges interpolated values need to be outside this range. It is easy to see why this method can't be used to search more then a few pixels away.

DCDi (directional correlational deinterlacing), which is very similar, uses the same technique but uses horizontal vectors of 2 pixels when doing the minimum difference comparisions and also does a couple of extra pixel difference comparisons to make sure that the direction is along that of the edge. This helps to reduce artifacts somewhat and gets closer to what you are probably thinking of. You can expand on that idea and use 3 or 5 pixel horizontal vectors to search for corresponding areas in the above and below scan lines. This works well except when you start expanding the search area to say 8-10 or more pixels to either side. If there is only one line in the surrounding area then your probably ok, but in detailed areas you'll get all kinds of mismatches. I've actually tried out this exact idea... using 5 pixel groups to search the above and below scan lines while limiting the search to edge areas only) it works well in areas with only one major edge. Another problem is that both of the above algorithms are limited to a small set of angles to which they can accurately adapt, since they use linear interpolation with only one pixel from each of the scan lines.

Now, what TDeint uses and what I've been calling modified ELA, I should probably just call edge-directed interpolation since it does exactly that. It doesn't do any direct pixel comparisons at all. It literally finds the direction of the gradient vector via the local partial derivatives of the surrounding pixels in the above and below scan lines and then rotates it 90 degrees to get the isophote direction or direction of least change. It also calculates gradient magnitude and local variance and drops back to linear interpolation in non-edge areas. Once it has the direction, it then uses linear interpolation on the above and below scan lines to obtain the points at which a line passing through point o with the calculated direction would intersect each line and then averages those values together. The main problem with this method is it will almost always mess up in detailed areas where two lines intersect, since the gradient vector will most likely end up pointing in the isophote direction. However, I think I have finally come up with a simple way to fix this and eliminate some spurious directions due to noise. In general I've found that this method usually surpasses that of pixel matching/searching. However, since it calculates the derivatives in the x direction in a small area (only over 3 pixels) it can't accurately detect the direction of nearly horizontal edges (it simply says they are purely horizontal). Atm, I allow it to use directions that would go out to 4 pixels to either side, which corresponds to rougly 15 degrees. However, it is really only good for edges with around 25-30 degrees slope or more. I'm currently working on improving this method around areas where lines intersect, and an obvious improvement would be to calculate the directions for the 4 other surrounding pixels which would give a better indication of the local geometry. Handling edges with smaller slopes could also be done by calculating approximations of the local partial derivatives over a wider area.

So your method would be pretty similar to DCDi or plain ELA, though with a slightly enlarged search area and possibly search group, maybe 3-5 pixels instead of 1. TDeint's method isn't really that similar to ELA except for the fact that it still does the interpolation using pixels that correspond to the intersection points instead of computing the final value by tuning the coefficients of the neighbor pixels as in NEDI or some other methods. I have been looking into edge directed methods of interpolation for deinterlacing (read... faster then NEDI) quite a bit recently and am quite interested in any ideas anyone has...

[MfA]

Does DCDi do a lerp between the 2 horizontal pixels before doing the average between the 2 lines or something? ELA with a wider aperture doesnt necessarily have to pick 2 opposing pixels to average straightaway ... you could first find the best match between two opposing X pixel vectors, and then do subpixel search. Just a couple more lerps.

BTW you might want to try local centered moments to determine isophote direction (can be implemented with running averages, so the amount of operations per pixel is pretty low ... it is probably cheaper than using DoG convolution masks greater than 3x3 for getting the gradient).

[Didée]

Thanks for the thorough explanation, tritical :) - It's much clearer now.

Well, the words of my description probably were a bad expression of my thoughts. What I was thinking of is, in some way, more like analog signal processing (better, a digital simulation of that). A "tension" between the scanlines, that "tears" everything to the right places ... dunno how to explain it better.

Perhaps a comparison to "the travelling salesman problem" is appropriate. You can throw a supercomputer at that and let it calculate hours and days. Or you can get the result within just some moments from a dedicated analog system that more or less lets the problem optimize itself (any given "start" routing modifies itself by moving towards a routing with lower overall tension).
However, the trick of analog systems is that they are working - analog ... :|

[tritical]

@MfA
Your right, DCDi first averages the two pixels from each line together and then averages those values together... I had forgotten. And sub-pixel search for ela with larger apertures is possible as well. Image moments I hadn't really thought about, mainly cause I don't know much about the subject. However, I'm not actually planning to use larger then 3x3 masks for the derivatives, it's just a possibility. Also, in the normal deinterlacing case, the derivatives are only calculated for about 15-20% of the pixels to begin with since most are handled by the motion adaptation or are within +-3 of both the above and below pixel in which case I just leave it. So the advantage to being able to use running averages wouldn't be that much.

@Didee
I see what your saying, there is probably a good way to do that but I can't think of one. At least not one that could work for lines with both very small and very large slopes without dynamically adjusting the aperture.


@All
I posted version 0.9.4. I haven't been able to work on this much the last week, but here are the changes:

+ Added auto detection of hints (if you don't set a value for hints manually, then TDeint checks the first frame to determine if hints are present and sets the value accordingly)

+ Added mtnmodes 2 and 3... these accomplish what I think scharfis_brain was suggesting earlier in the thread. They act like 0 and 1, but wherever 0 and 1 would have used the avg() of two pixels, 2 and 3 instead use the pixel value from the field that is most similar to the current field.

+ Added clip2 parameter. When using TDeint as a postprocessor for telecide you can get weird results since telecide changes the order of the fields (that's not good for a motion adaptive deinterlacer). So you can specify clip2 for the actual deinterlacing to be done from... here's an example of how it works:

mpeg2source("c:\mysource.d2v")
orig = last
telecide(guide=1,order=1,post=1)
tdeint(order=1,clip2=orig)

Then TDeint reads the hints and output from telecide as usual, but whenever a frame needs deinterlacing it does it from clip2. It also preserves the hints in case any filters later on need to read them. If you don't specify a clip for clip2 then the deinterlacing is done from the input clip as usual.

- Fixed field differencing in kernel interpolation using the wrong fields, and not correctly adjusting the direction of the kernel to that of the field that is most similar to the current field.


I'm still planning on improving the edge directed interpolation in TDeint. Also plan on improving the motion map denoising and adding built in combed frame detection.

edit:
Posted v0.9.5, right after posting 0.9.4 realized that I was doing mtnmodes 2 and 3 the hard way instead of the simple, faster, and blatantly obvious way. So now 2 and 3 aren't any slower then their 0 and 1 forms.

[tritical]

Well, either no one has had any problems or no one uses it :).

I just posted v0.9.6, haven't had time to work on improving the edge-directed interpolation, but I did manage to add built-in combed frame detection and per-field weaving.


Changes from v0.9.5:

+ Added full parameter, allows for ivtc post-processing. full defaults to true.
+ Added cthresh, chroma, and MI parameters... these are used when full=false and with tryWeave option
+ Added tryWeave option, allows TDeint to adaptively switch between per-field and per-pixel motion adaptation. tryWeave defaults to true.
+ Improved field differencing
+ changed mtnmode default to 1


Some explanations...

Full works the same way as the full parameter in fielddeinterlace(). If set to false, then all input frames are first checked to see if they are combed. If a frame isn't combed, then it is returned as is. If it is combed, then the frame is processed as normal. Full can only be used when mode = 0. Full defaults to true.

tryWeave, if set to true, works like this... The most similar field to the current field (either prev or next) is calculated. A new frame is then made by weaving this field with the current field. This new frame is then checked for combing. If it isn't combed then it is returned. If it is combed, then normal processing (as if tryWeave=false) is done. This allows TDeint to adaptively switch between per-pixel and per-field weaving. This idea is taken from scharfis_brain's suggestion earlier in the thread and his matchbob() function. tryWeave defaults to true.

[Mug Funky]

you rock.

...that's all i've got to say until i test this a little further.

[edit]

shit, man, you REALLY rock. i barely need IVTC anymore now :):):):)

[edit 2]

seems to be some odd field-order problems with the new matchbobbing... perhaps when it does the weaving it doesn't re-set the original field-order? i'm getting havoc with the intro sequence to Lain, which has a mix of interlaced, 30p and telecine.

i suspect some of the interlaced stuff off this disc to be b0rk field order to begin with (there's bits shot on DV cam in the show where the field-order is obviously wrong, but it was probably an effect, as it's that kind of show). however, assumeTFF().bob() is returning different stuff from tdeint(1,1).

i can post a sample if you like.

[tritical]

Yeah, if its not too much trouble a sample would be helpful. On normal material I can't produce the problem you described. I do have some weird clips that have what I would call "out-of-order" fields every once in a while, that might be what your clip suffers from. Even when the field order is set correctly, if you do a separatefields() and step through a field at a time it will jump backwards on some fields. This will cause major problems for any motion adaptive deinterlacing approach. If there are entire sections of the clip that have a different field order from the rest of the clip that will obviously produce garbage output as well. Even on this type of input though, TDeint should preserve the same field as bob().

Providing a work around for clips that have single out-of-order fields or weird stuff in general would not be that difficult, just need to test the output frame to see if it is combed and if it is, deinterlace it w/o motion detection. That isn't ideal though since it would end up detecting some good output frames as well. If a clip has whole sections with a different field order that is a tougher problem, probably have to just process it in sections...

[pdottz]

I read the readme file but can't understand it to clearly
what would be the settings to use for ntsc captured tv? i cap at 720x480. this is the script i use.


LoadPlugin("C:\PROGRA~1\GORDIA~1\TomsMoComp.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\undot.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\FluxSmooth.dll")
AVISource("D:\captures\maincap\eene.avi")
TomsMoComp(1,5,1)
Crop(0,0,720,480)
LanczosResize(512,384)
Undot()
FluxSmooth(7,7)
ConvertToRGB()



tomsmocomp does an awesome job but leave me with some aliasied line that are clearly noticeable on the capped toons.
i want to try this new filter and would look to try it on this file.
can anyone help?

[Mug Funky]

hmm... looks like my bad. i tracked the problem down to MPEGsource rather than MPEG2source. looks like there's some oddness in the repeat-field flag handling, causing chaotically reversed fields.

everything works fine using DGdecode. (pity, because every little bit of speed is useful to me, so the very small decoding speed difference of nic's mod was useful to me).

here's the sample anyway, if you want it - it contains some good testing material besides the field-order oddness that turned out not to be a bug in your plugin (sorry... but i'll let nic know about this).

http://210.49.108.136:8080/lain_intro.m2v

[xappy]

Hi!

Thank you for the great plug-in. I have used it for bobbing my interlaced MiniDV PAL material before creating amazing slow motions ;)

The plug-in (0.9.6) still produces some very disturbing bobbing artefacts. I know the reason, why artefacts are produced and I can send you some images about it. There is one havily compressed image as an attachment.

I was thinking to make some modifications to your code, but when I tried to compile your source code without any modifications I got the following errors:

--------------------Configuration: TDeint - Win32 Release--------------------
Compiling...
TDeinterlaceYUY2.cpp
E:\TDeint\TDeinterlace.h(199) : error C2065: '_aligned_malloc' : undeclared identifier
E:\TDeint\TDeinterlace.h(500) : error C2065: '_aligned_free' : undeclared identifier
TDeinterlaceYV12.cpp
E:\TDeint\TDeinterlace.h(199) : error C2065: '_aligned_malloc' : undeclared identifier
E:\TDeint\TDeinterlace.h(500) : error C2065: '_aligned_free' : undeclared identifier
Error executing cl.exe.

TDeint.dll - 4 error(s), 0 warning(s)

What am I missing?

[Wilbert]

There is one havily compressed image as an attachment.
You should be able to post attachments again. But I don't see any?

[tritical]

@xappy
Hm, afaik it should compile fine as long as you have malloc.h included, and since it didn't say it couldn't find it I'm not sure, but I'm no expert. You could go ahead and change the _aligned_malloc and _aligned_free to just plain malloc and free, won't make much difference, or use new and delete instead like I probably should :). If you know some obvious improvements to make I'd be grateful if you would share them... the few things I've attempted to use as a post-processing to clean up left over bob artifacts do work, but also end up messing with good frames more then i would like. Either setting an ap threshold as in dgbob or testing the output frame for combing and then dumbbob deinterlacing it or storing the previous output frame from TDeint and using that to do motion adaptive deinterlacing from.

@Mug Funky
I'll still try to grab the sample if you don't mind... problem is I'm never at my own comp when you seem to have yours up and running.

[Mug Funky]

it's up now. i'm installing some software and have had to reboot a few times, but i'll refrain from that for a while.

think i'll leave this box on for a good day or so, hopefully that will give you time to d/l it.

[xappy]

@Wilbert
I tried to send the image again, but got the following error:

You have already attached this image to a post. Please refrain from uploading duplicate images. If you need to refer to this image it can be found in this thread: Another motion adaptive deinterlacer and smart bobber

@tritical
_aligned_malloc and _aligned_free do not exist in my malloc.h. Should I install some SDK or some other package? I'm using MS VC++ 6.0, but I'm totally newbie with it. However, I managed to compile some other filters...

Can I send you some (small ~10kB) pictures about those artefacts I mentioned before to your email seen in your home page?

[tritical]

@Mug Funky
Finally getting that sample, thanks :).

@xappy
An email is fine... though I can see the attachment now. It would actually be easier if I could get a small sample of the video. Just looking at the pictures leaves a lot of guessing, but I'm fairly certain what caused the artifacts in the attached image. With VC++ 6.0 I think you need the processor pack to use _aligned_malloc if you don't have it. Should have mentioned that before, but I always forget that not everyone uses the same compiler I do :D.

[lordreign]

Hey Mug Funky, I'm just curious as to settings u use with TDeint... so I could perhaps see if they work for some of my anime. Bad field blended PAL anime that is.

Cheers.

[Mug Funky]

sure thing... i rarely do anything other than Tdeint(1,1) for top-first bobbing.

i'll only really tweak it when i get too much coming left over - i'll set Cthresh to 5 or 4 (default is 6), and/or MI to about 20 (default 32). this is only when i get combs left over, as it also risks getting shimmer on good frames.

[edit]

the last few anime encodes i did were disc 1 and 2 of Azumanga Daioh. i just left it bobbed and at 50fps, and let Xvid sort it out.

512x384, lanczos4resize, limited removedirt (just to stop removedirt from removing actual motion - i'll post the script in a jiffy.. it's probably sub-optimal, but doesn't hurt things) and encoded with CQ 3, and 4 b-frames instead of 2 (i figure 50fps has twice the redundancy, so i could get away with it). all other settings are at default.

episodes are coming out at around the 110MB mark (sans sound) which is quite acceptable to me.


by the way, speaking of Azumanga Daioh, you should see the rating disc 1 gets... the stupid australian office of film and literature classification gave it an MA 15+ rating... disc 2 is a G. that puts a _very_ tame anime on the same rating as Kill Bill 2, which is utterly stupid. however, it costs Madman several thousand dollars to have these discs re-assessed.

[Chainmax]

tritical: I finally was able to encode the clip I promised in my "need help IVTCing..." thread. You can download it here. I'd appreciate it if you could comment on the image quality of it besides assessing TDeint's work as a fieldmatcher.

Have you considered posting this thread in Avisynth usage? I bet more people would see it in there than in here.

[tritical]

I'd appreciate it if you could comment on the image quality of it besides assessing TDeint's work as a fieldmatcher.
I'm not sure exactly what you mean, but after looking at the clip it seemed like all the fields had been matched correctly where possible and the ones that couldn't be were deinterlaced (the fades). On the subjective side, I thought it looked pretty good considering the source :D.

As for posting it in usage, I plan too, but I still haven't been able to find a good method of post-processing to remove left over artifacts as in xappy's picture. In the end, I think I may simply add an optional artifact threshold as in dgbob and be done with it. The major problem is that those type of artifacts are inherent to motion adaptive deinterlacing/bobbing, and detecting them will also detect lines/edges pretty much mitigating the benefits of motion adaptation. I've also been working on a new method of edge-directed interpolation that is considerably better then TDeint's current method, but haven't gotten all the kinks worked out just yet. I would like to get the above two items finished and added before posting it in usage.

On a side note about field matching, the blind field matching of TDeint is actually better then that of Telecide, especially when it comes to the small movement problem (flapping mouths, etc...). TDeint's field matching is currently lacking one improvement that would optimize it for field matching of telecined sources vs finding the overall most similar field for deinterlacing as it does now. For that reason, and that I was a little tired of working on TDeint :p, I started working on a stand alone field matcher called TFM a day or two ago. The only other field matcher I've seen that can match small flapping mouths in anime as well as it is bruteivtc. Its main advantage over bruteivtc is that is it about 9-10 times faster and supports user overrides like telecide. Anyways, that's probably more then you wanted to know... but I wanted to show that I'm still working on this filter.

[Mug Funky]

your efforts are very much appreciated :)

if you need some problem samples (i've got some flapping mouth stuff that even bruteIVTC baulks at), you know where to get them. i'll just have to remember to leave my computer on longer (maybe i'll start some encodes :))

[Chainmax]

Originally posted by tritical
I'm not sure exactly what you mean, but after looking at the clip it seemed like all the fields had been matched correctly where possible and the ones that couldn't be were deinterlaced (the fades). On the subjective side, I thought it looked pretty good considering the source :D.

As for posting it in usage, I plan too, but I still haven't been able to find a good method of post-processing to remove left over artifacts as in xappy's picture. In the end, I think I may simply add an optional artifact threshold as in dgbob and be done with it. The major problem is that those type of artifacts are inherent to motion adaptive deinterlacing/bobbing, and detecting them will also detect lines/edges pretty much mitigating the benefits of motion adaptation. I've also been working on a new method of edge-directed interpolation that is considerably better then TDeint's current method, but haven't gotten all the kinks worked out just yet. I would like to get the above two items finished and added before posting it in usage.

On a side note about field matching, the blind field matching of TDeint is actually better then that of Telecide, especially when it comes to the small movement problem (flapping mouths, etc...). TDeint's field matching is currently lacking one improvement that would optimize it for field matching of telecined sources vs finding the overall most similar field for deinterlacing as it does now. For that reason, and that I was a little tired of working on TDeint :p, I started working on a stand alone field matcher called TFM a day or two ago. The only other field matcher I've seen that can match small flapping mouths in anime as well as it is bruteivtc. Its main advantage over bruteivtc is that is it about 9-10 times faster and supports user overrides like telecide. Anyways, that's probably more then you wanted to know... but I wanted to show that I'm still working on this filter.
Well, you wanted the clip in order to see how the clip looked with TDeint+Decimate. I wanted you to comment on the IQ of the clip as well which you did, that's all. Anyway, if you release TFM what will become of TDeint? Will future releases of it be composed just of its bobbing functionality? Also, could TFM have decimation capabilities? It would be nice to finally have an alternative to Decomb and SmartDecimate for automatic IVTCing...

[tritical]

@Chainmax
I'm not sure about adding decimation mainly cause I don't know of any real improvements to make over decimate, aside from maybe using 3 sets of offset blocks at +16x, +16y, and +16x+16y to better catch small movement (but it would make it slower) and making a small change to mode=2 decimation to fix an inherent limitation that can cause jerkiness when going from panning to still and still to panning scenes. I don't think TFM will change TDeint much at all, it will still have the option to weave fields, but I will probably turn it off by default and make the defaults of TDeint better for true interlaced material as opposed to how they are atm with the defaults being a compromise between settings for several different types of material.

@Mug Funky
Would always take any problem samples your willing to send :).

[Chainmax]

If you can find the time to do it I'm sure it would be appreciated. Some time ago, I saw some VHS captures that were IVTCed via Decomb, SmartDecimate, TDeint (old version, 0.9.2 IIRC)+BlendBob and TMPG manual IVTC. The manual IVTC looked showed much more fluid motion than the other options. I know it's pretty much impossible that an automatic method yields equal results than a manual one, but any improvement is welcome in my opinion.

[tritical]

TFM v0.9[link removed, new version is linked farther into thread], its a field matcher like uncomb/bruteivtc/telecide... It supports 2-way, 3-way, 2-way + 3rd on combed, 2-way + 3rd on combed + 4th/5th on combed, and 3-way + 4th/5th on combed matching strategies. It doesn't atm do any post-processing so if no good match exists it will output combed frames. Also, there is no included decimation function atm either so you'll need to follow it up with decimate() or something similar to achieve an ivtc. It does support quite extensive manual overrides (specific frames, patterns over frame ranges, changing field/order/mode for ranges of frames, etc...). There are really only two parameters that require setting, order (the field order) and mode (sets the matching strategy). Anyways, its just a start... and TDeint development isn't dead yet either. Also, if anyone has some hard to correctly field match clips (mouth problems, small movement, etc...) that TFM doesn't correctly handle I'd definitely appreciate a small sample.

[Mug Funky]

hmm.. seems to work good on my initial test.

but i inadvertently found a bit that may not even be possible to match... i'll send it if i can't find a good setting for it. as you might have guessed, it's from the same show as the other samples i have difficulty with (this is like Hell's Impossible To Backup DVD Of Doom, and i still haven't even been able to do a straight encode without a crash :().

also, is it possible to get double-rate output? this is useful for standards-conversion for PAL DVD (best way to maintain maximum vertical detail on hybrids). i guess i could use the same trick as with telecide for now.

thanks for this plugin :)

[edit]

btw, maybe this should have it's own thread?

[edit 2]
hmmm... that awful sample i mentioned seems to be a result of poor compositing - the sparkly bits look like they were added at editing time, but were moved up 1 pixel, reversing their field order with respect to the film underneath. ouch. it might still prove useful for Tdeint, though.

[Chainmax]

Thanks for this release Tritical :). Unfortunately I don't have any difficult stuff to try it on other than the Spawn DVD and seeing what a POS it is, probably TDeint bobbing+BlendBob is the only way to go.

I concur with Mug Funky about TFM needing its own thread. I see that you are considering adding a decimation function, will that be similar to vanilla Decimate or FDecimate?

[Mug Funky]

Chainmax - if you can find the R1 release of Astroboy from the '80s, that'll give you IVTC nightmares. you'll think Spawn was a pleasant walk in the park on a mild summer's day. my advice for discs like these is to not buy them... (the R4 one is okay though, and the R2 one is the best).

[Chainmax]

There's a DVD release of the 80s Astroboy? :eek: Any ideas where can I find the R2 version?

[Mug Funky]

huh. i can't find it through the normal means, but i know it exists. i'll ask around for you :)

[tritical]

@Mug Funky
Double rate output can be added pretty easily so I'll go ahead and do that. The other options that TFM is currently missing and that will be added at some point are post-processing of combed frames and an exclusion band for ignoring subtitles or a logo.

@Chainmax
My original idea was for something similar in operation to fdecimate/changefps with a few modifications (mainly dealing with the radius around the calculated frame in which it will look for the frame to return). The nice thing about it is it is simple, pretty fast, and allows decimation to any framerate. However, there are downsides of such a method compared to 1-in-N decimation when you can achieve the desired framerate with 1-in-N decimation. Namely, 1-in-N decimation doesn't require setting a duplicate threshold or even trying to find duplicates if simply removing the most similar frame in each N frame cycle. This type of method usually works well with normal movies, but not anime/cartoons where for correct decimation you do need to detect duplicates. Also, when doing 1-in-N decimation and tracking duplicates (requires a duplicate threshold like the first method) you can correctly handle scenerios like this: http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=134&highlight=decimate+pattern which is not possible with a changefps/fdecimate type of method or with simply removing the most similar frame in a cycle. User overrides of the decimation would be easier to support with 1-in-N decimation then the other method, as well. So after thinking about it, I am planning on adding both an arbitrary frame rate decimation mode and a 1-in-N decimation mode since they each have advantages. I am also planning a two-pass mode for use with hybrid material (film, 60i, and 30fps progressive in one clip) and mkv's vfr support. If anyone else has ideas for a decimation filter don't be shy :p.

A new thread might be useful, but thats more work then simply posting in this one :D. Once TFM gets double rate output, post-processing, and an exclusion band I will definitely start a new one.

EDIT: Forgot to mention this, but there is also the possibility of having an N-in-M decimation mode, where like the 1-in-N method (and unlike the fdecimate/changefps method) you consider full cycles at a time. It would offer some advantages (maybe the best of both worlds?), but also has new problems and I haven't had time to think about it enough.

[Chainmax]

Mug Funly: thanks, I appreciate it :).

tritical: damn, you sound like you'll have your hands full for some time. Keep ut with the awesome work :):).

[Dali Lama]

Hi Tritical,

I am getting excellent results with TFM on Rurouni Kenshin anime. That one is not as easy as most people think, but TFM is able to do a good job on mouth movements, scene changes, and panning. BruteIVTC also does a good job, but is a lot slower as you mentioned. The only thing I notice is some very slight jerkiness in a rare scene or two, even using mode 2, but I think that is inherant in the source.

In addition, by doing a proper IVTC, I am able to reduce general noise and especially rainbowing in the source (an added benefit).

Something interesting is when I apply Guavacomb before IVTC as directed, TFM produces errors in "telecide" operation, such as missing a stray interlaced frame it would otherwise detect. Any ideas why this might be the case?

In any case, I also think that anime needs the decimation you described above. Interestingly, when I was using Telecide on the material, I noticed that proper decimation was the "rate-limited step" in achieving proper IVTC as duplicates in the source tend to have weird rainbows, stray interlacing, ghosting and the like.

So keep up the good work and thanks,

Dali

[tritical]

Thanks for the feedback Dali Lama. On the guavacomb issue would you mind putting up the exact script you used. It is hard to determine the possible causes without a little more info, but using guavacomb before tfm should tend to improve accuracy and not hurt things as long as the settings are resonable. Also, when you say it works correctly w/o guavacomb does that mean it works if you convert to yuy2 and then use tfm or if you leave the clip in yv12 colorspace?

And yeah, kenshin has some problems, at least the first couple r1 dvds have blended fields :devil: if I remember correctly. I don't know about later on in the series...

[Dali Lama]

Nice suggestion:

After looking into the color space conversions I noticed that neither GuavaComb or TFM is the problem. Since I am using GuavaComb before IVTC, the source is interlaced and ConvertToYUY2() and ConvertToYV12() need to be ConvertToYUY2(interlaced=true) and ConvertToYV12(interlaced=true).

I checked TFM under YUY2 and YV12 and it works fine as long as interlaced=true is used. Interestingly, I don't get the interlaced frames when I use ConvertToYUY2() before TFM, but I do if I use:

ConvertToYUY2() then ConvertToYV12() before TFM

Perhaps ConvertToYUY2() doesn't benefit from the interlaced=true option?

And you're right, the first few episodes had blended fields (where's Scharfi :D ), especially in the opening trailer, but it improves in later DVDs.

-Dali

[Chainmax]

Dali Lama: From what I recall, Kenshin is a 24/30 fps hybrid, so regular IVTCing isn't really the best option (it might be what leads to the sporadic jerkyness you mention. Why don't you try VFR encoding?

[Dali Lama]

Hi Chainmax,

I don't see any 30 fps progressive sections in kenshin. Are you sure about that?

-Dali

[tritical]

Glad that you got the problem worked out. interlaced=true in the yuy2 conversion was my first thought about what might be wrong. Even if you didn't get interlaced frames with converttoyuy2() it definitely makes a difference. How big depends on the specific frames... the combination of converttoyuy2() and converttoyv12() would increase the effect.

On a side note I had some free time this week and was able to make quite a bit of progress. M-in-N decimation is working (most similar and longest string), arbitrary framerate decimation is working... post-processing for tfm is added, mainly just working on some small details atm. Probably the next release will include the decimation function, but it will only have one-pass capabilities... two pass vfr stuff I haven't gotten too yet.

In my tests the arbitrary frame rate decimation algorithm is fast, but is simply too dependent on the duplicate threshold being correctly set (both too high or too low will cause duplicates to be retained). M-in-N works much better since you can consider full cycles at a time, but is slower and still can't acheive all decimation ratios w/o having a very large N so I'm still gonna keep the other method around.

One question for anyone still reading... are single framerate methods of handling vfr content worth having? i.e. blend decimation or special field decimation for decimating 30fps progressive or 60i down to 24fps. While mkv's vfr capabilities are a much better alternative imo there are still some occasions where a single framerate or non mkv alternative might be needed.

[Aktan]

From what I have seen, only the first few kenshin dvds are problematic. I think like vols 1-5. After that, IT, at least for me worked perfectly. Sorry for the off topic.

[Leak]

Originally posted by tritical
One question for anyone still reading... are single framerate methods of handling vfr content worth having? i.e. blend decimation or special field decimation for decimating 30fps progressive or 60i down to 24fps. While mkv's vfr capabilities are a much better alternative imo there are still some occasions where a single framerate or non mkv alternative might be needed.

You know, that would have been exactly the next thing I'd have tackled myself when I had some time for it... :)

I've found that Decomb's Decimate using mode=2 just drops the first frame of a row of duplicates, whereas dropping the frame with the lowest metric would probably avoid errors in cases where erroneous duplicates were found - after all, if it's all duplicates, you can choose any of those and drop it.

I'd really love to have a Decimation filter that can blend 30FPS or 60FPS material down to 24FPS, as my standalone player can't cope with VFR material. Currently, I'm doing those blend-downs by hand if it's just the opening or ending, but doing it that way for every scene is overkill.

[Mug Funky]

perhaps some kind of hinted convertfps blending would work - it could take hints from TFM determining whether to pass through 24p content, or blend-convert 30 or 60fps stuff. scenechange detection also, maybe?

hell, i'd settle for a YV12 update of convertfps (with scenechange detection), but i guess that's a core avisynth function, not a plugin. this would also mean avisynth can be used more in DVD production, not just backup.

[Leak]

Originally posted by Mug Funky
hell, i'd settle for a YV12 update of convertfps (with scenechange detection), but i guess that's a core avisynth function, not a plugin. this would also mean avisynth can be used more in DVD production, not just backup.

Well, it's not as if AviSynth weren't opensource - anyone can update ConvertFPS and send Sh0dan a patch... :)

np: Fennesz - Codeine (Field Recordings 1995-2002)

[tritical]

perhaps some kind of hinted convertfps blending would work - it could take hints from TFM determining whether to pass through 24p content, or blend-convert 30 or 60fps stuff. scenechange detection also, maybe?
That's exactly what it would be... I already have the needed hinting in place :D. The decisions would be made based off tfm's matches, combed/deinterlaced frames, and frame metrics. Blend decimation would need scene change detection as well, but that can be gotten pretty much for free from the metric calculations. For 30fps progressive blending would be used, for 60i I was thinking what neuron2 posted in his journal some time ago might be better then blending: http://neuron2.net/journal/journal2003.html ("6-1-2003: A Digression: The Holy Grail of Hybrid Rendering"). Basically smart bob the fields to frames and then decimate in a 1-2-1 pattern. Though 60i detection and handling is more problematic then just film/30fps progressive. The hybrid stuff will have to be limited to M-in-N decimation and probably only 1 in 5 since I'm really not sure how it should work in other scenarios.

Leak, what patterns do you use for blending down 30fps progressive and 60i to 24fps? The following method produces pretty smooth results for 30 fps progressive, it is based on cycles of 5, but there is probably a slightly better way... here's a short example:

original (10 frames) = 0 1 2 3 4 5 6 7 8 9
new (8 frames) =
[0 100% 1 0%] [1 75% 2 25%] [2 50% 3 50%] [3 25% 4 75%]
[5 100% 6 0%] [6 75% 7 25%] [7 50% 8 50%] [8 25% 9 75%]

[scharfis_brain]

hi trictical your progress so far sounds very nice.
but I have another, very interesting idea.
Again: standards conversion!

lets assume the following pseudo conversions:

input=avisource("hybrid24p30p60i")

video60i=input.mvbob().mvconvertfps(47.952)
video30p=input.telecide(post=0).mvconvertfps(47.952)
film24p= input.telecide(post=0).decimate(5).changefps(47.952)

tfm(input,video60i,video30p,film24p)
assumefps(25)


this would be my very dream configuration for standards conversion!

the sync between the 29.97fps input and 47.952fps streams should be doable with the timestamps/codes, I think.
tfm should/could do this automatically?!?

would such a thing be possible with the current architectures and/or your plans for tfm?

[Dali Lama]

Originally posted by Leak

I've found that Decomb's Decimate using mode=2 just drops the first frame of a row of duplicates, whereas dropping the frame with the lowest metric would probably avoid errors in cases where erroneous duplicates were found - after all, if it's all duplicates, you can choose any of those and drop it.


I concur 100%. I've actually started a thread about this a while back, but couldn't explain it as clearly.

I hope TFM will implement this idea or perhaps an equivalent.

[tritical]

@scharfis_brain

The general idea is definitely possible. If I follow correctly what you really want is a filter that takes a hybrid input stream, determines what parts are what (24p/30p/60i) and then chooses between already converted streams as needed. That really isn't where I was headed (atm the conversions are also done inside tfm/tdecimate for everything but 60i where the user will need to give tdecimate an already bobbed stream). However, your idea could be done by just ripping out the detection from tfm/tdecimate and making a filter out of that.

Actually, your idea is pretty good... the big thing standing in the way atm is the detection of 60i/24p/30p, which is heavily integrated into the actual conversions right now. I've mainly been ripping off the code from some ivtc filters I wrote before and they only did 24p/30p detection so if there were combed frames after field matching they were deinterlaced. Trying to cram 60i detection into that framework is not working well (i.e. if an output frame from tfm is combed it is 60i). Going back and doing the detection on the field level (look for duplicated fields to separate 60i from 24p/30p) would probably work better.

One thing I don't get in your example though is the 47.952 framerate? If the final output framerate is 23.976 why not just have mvconvertfps(23.976), leave the 24p alone and then input those? Most likely I am missing something here :D.

[scharfis_brain]

my script is slightly incomplete.

input=avisource("hybrid24p30p60i")

video60i=input.mvbob().mvconvertfps(47.952)
video30p=input.telecide(post=0).mvconvertfps(47.952)
film24p= input.telecide(post=0).decimate(5).changefps(47.952)

tfm(input,video60i,video30p,film24p)

separatefields()
selectevery(4,0,3)
weave()

assumefps(25)

my aim is to produce 48p for 60i and 30p contents.
24p is filled up to 48p by frame duplication to match the framerate of the formerly 60i and 30p sequences.

afterwards, I reinterlace 48p to 48i and then i do a speedup to 50i. this means, formerly 24p contens become 25p in the output.

[Leak]

Originally posted by tritical
Leak, what patterns do you use for blending down 30fps progressive and 60i to 24fps?

Well, I'm doing it the mathematically correct way; if you go from 30 to 24 FPS you need to fit 1 1/4 source frames into a destination frame, i.e.


Fr. Src.A Amt.A Src.B Amt.B
0 0 4/5 1 1/5
1 1 3/5 2 2/5
2 2 2/5 3 3/5
3 3 1/5 4 4/5

4 5 4/5 6 1/5
5 6 3/5 7 2/5
6 7 2/5 8 3/5
7 8 1/5 9 4/5

...

which I was doing this way:

a=source.SelectEvery(5,0)
b=source.SelectEvery(5,1)
c=source.SelectEvery(5,2)
d=source.SelectEvery(5,3)
e=source.SelectEvery(5,4)

return Interleave( \
a.Overlay(b,mode="blend",opacity=0.2), \
b.Overlay(c,mode="blend",opacity=0.4), \
c.Overlay(d,mode="blend",opacity=0.6), \
d.Overlay(e,mode="blend",opacity=0.8))


This way, you'll get evenly spaced intervals in the blend, with every source frame getting used for a total of 80%. With your method, you get 100% of frame 0 and 75% of the other frames. Of course, this means you'll get a totally unblended frame per cycle, but I find it adds too much jerkiness for my taste, while I don't care as much for ghosting blending brings with it.

I do think that scharfis_brain is on to something here, even though MVConvertFPS will not work with anime; in that case blending like the above will probably be preferable - but if you can feed it 3 clips so the processing is configurable, everybody can do it the way they like... :)

np: Frankie Goes To Hollywood - Relax (New York Mix) (Twelve Inches (Disc 1))

[tritical]

@Leak
All with 80% weight would probably be preferable, even though it means all frames will be blends it would be smoother. Thanks for the info.

@scharfis_brain
It all makes sense now. The idea is definitely a good one, but I've decided for the moment to not specifically handle 60i in tfm/tdecimate for a couple of reasons so it will not be able to accomplish the type of processing you want. I think the idea would be better off in its own filter anyways. Maybe someone else will take up the idea and try turning it into a filter. It would mainly be about accurate detection of all the different types, the merging and sync to create the final output stream would not be that difficult.

@All
And here is TFM v0.9.1[link removed, new version is linked farther into thread], this one includes all the features I originally planned... post-processing has been added, exclusion band was added, user overrides for post-processing was added, and some other small changes (default values and what not). Like I said above I decided to not try to specifically handle 60i for the moment so any frames that come out of tfm combed are simply deinterlaced resulting in 30p. PP includes blending and modified-ela (which I stole from tdeint), both motion-adaptive and dumb modes. The motion adaptivity and deinterlacing in general is different then that in tdeint and is geared for cleaning up combed frames that come through field matching because of orphaned fields or missing fields. If you don't like either blending or ela then I included the ability to specify an externally deinterlaced clip (i.e. deinterlaced with another filter) from which TFM will grab deinterlaced frames. This option will also work in conjunction with TFM's motion adaptivity so only pixels in moving areas are taken from the external clip. (see the "clip2" option for details).

TDecimate is also coming along pretty fast and should be finished soon, just need to add two-pass stuff, input/output options, and user overrides.

@Mug_Funky
I decided not to add double rate output since it would be hard to get it all working correctly with overrides and everything. I think the best solution would just be a script based one instead of having double rate output inside of TFM.

[Leak]

Originally posted by tritical
TDecimate is also coming along pretty fast and should be finished soon, just need to add two-pass stuff, input/output options, and user overrides.

About two-pass - couldn't you also do a one-pass mode where it'll output as many frames as in the source video, but with all black frames at the end, and some out-of-band-signalling (like via a small text file) that contains the number of the real last frame, so one can just chop off the file at that position?

This might not be feasible if you're doing a 2-pass encode with XviD, but it might speed things up if you're using HuffYUV or a similar lossless codec or 1-pass encoding.

np: Frankie Goes To Hollywood - Relax (New York Mix) (Twelve Inches (Disc 1))

[tritical]

Yes, that would be possible, but one of the reasons for doing it two-pass was one of the options for 30p detection is a minimum # of consecutive cycles detected as 30p. That number can be anything while in actual processing only 1 or 3 cycles at maximum is tracked depending on the current mode. If the # is not greater then the currently tracked cycles then your idea for one-pass processing would work. The other option would be to process through the entire video on load as in the decombvfr mod, however I would prefer not to do it that way.

Currently what I had planned for two-pass hybrid processing was you run TFM with the output option enabled and TDecimate in metrics only mode with output enabled for the first pass (and don't use any filters after tdecimate so things run pretty fast), and then on a second pass TFM uses it output file and TDecimate analyzes TFMs output file and the metrics file, does all the processing of the entire video on load from that (which takes only a second or two) and then just makes a lookup table of the frames to deliver. However, I know messing with text files and doing two-passes is not preferable. Though to accomplish some of the options having access to all metrics and matches for the entire clip is needed, which means processing through the entire file on load would be required for a one pass solution.

Like I said above though, your one-pass solution would be possible w/o processing the entire clip if the # of consective cycles option was required to be 2 or 1. Would that work for you?

[Chainmax]

So, TFM and TDecimate will be separate filters? Also, once you finish TFM and TDecimate, what will happen to TDeint (i.é: will you strip its fieldmatching and deinterlacing capabilities)?

[edit]Nevermind, I just read the readme.

[tritical]

Yes, they will be separate filters, but will both be in the same dll (not sure what the dll will be called yet). I don't have plans to remove anything from TDeint atm, but will probably disable trying to weave by default. TDeint still needs to have a new edge-directed deinterlacing method added and gonna add the ela method from tomsmocomp as well since a lot of people seem to prefer it. I was never able to come up with a useable post-processing fix to what xappy posted earlier (one that didn't also touch most of the frame), and pretty much consider those type of artifacts as inherent to motion adaptive deinterlacing.

[AS]

Running risk of being off-topic, I would like to request a feature for Tdecimate: being able to choose a fixed numbered duplicate to drop; say should tdecimate detect a row of duplicate, I can selectively drop every 2nd duplicate, rather than always dropping the 1st one in a fixed cycle, which is what decimate mode=0, mode=2 does.

[tritical]

Could you explain a little bit more about why that option would be useful? To me it seems like that would go with user overrides (manually specifying a decimation pattern). Also, mode 0 of decimate just drops the most similar frame in each cycle, it doesn't look for duplicates like mode 2 so I'm not sure how it would work in that context.

A couple things about longest string decimation. There is a reason for removing in order from first to last in duplicate strings. It's so that when you calculate the length of duplicate strings in the next cycle you get an accurate count going back into the previous cycle (if any duplicate strings run back into the previous cycle). Since the duplicate string tracking goes across 3 cycles: previous, current, and next. But as Leak said, their all duplicates, so there are workarounds possible. Currently what TDecimate does is it removes in order of lowest metric from duplicate strings, but when it calculates the length of the duplicate strings for the next cycle it acts as if it had decimated in first to last order in the previous cycle (which shouldn't make any difference since they are all duplicates). It requires a little more code, but it accomplishes both goals. TDecimate's longest string decimation is already quite a bit more involved then Decimate's since it needs to work for M-in-N decimation and not just 1-in-N.

[AS]

I thank you for the correction of my misunderstanding and the explanation with regard to longest string decimation. I will try with your suggestion of manual override.

Just a clarification, for my personal understanding, if you don't mind.

Currently what TDecimate does is it removes in order of lowest metric from duplicate strings...

Do you mean it drops the duplicate with the lowest metric, then the one with the 2nd lowest metric and so on?

If I am correct, then there is a case there you do not want to drop the one with lowest metric first but start with the one of the highest metric. Suppose you have an ordered duplicate set/string of AA', I am not sure about you, but in my experience A' is always cleaner than A; A might have chroma shift and/or key-frame corruption if A is a key-frame; A' has none of that and has less compression artifacts by the nature of lossy video compressions. In this scenario, A would have a higher metric than A', would it not? Should you have a longer duplicate string with this high-metric bad frame somewhere in the string, you would end up keeping the frames you don't want and losing the frames you want.

Unless I have misunderstood it again ^^;

[Mug Funky]

to change the subject slightly, would it be possible to include something like a matroska timecodes file after decimation, so that hybrid streams could be left untouched but the advantages of having less frames could be exploited?

i guess this would need 2 passes, as VfW needs to know how many frames it will be dealing with.

what i'm doing right now is going 3 passes with dedup, 1 after the other in a VDM job list - the first is null output (done with ffdshow set to uncompressed and no output) which gathers dup metrics, the second is xvid 1st pass, using the dup metrics to decimate, and the third is xvid 2nd pass.

[tritical]

@Mug_Funky
If your talking about doing vfr with mkv by decimating frames in film portions and leaving 30p alone and then outputing the needed matroska timecodes file I have been planning that since the beginning. The blending of 30p to 24p for a single framerate method of dealing with 30p I didn't initially plan to add, since I use matroska almost exculsively with the vfr method I just described, but it is added now as well. If your talking about also adjusting the timecodes file to remove all frames with metrics below a specific threshold like dedup then no, I am not currently planning to do that. I had originally planned the mkv vfr stuff to be two-pass, but a one-pass version based off Leak's earlier suggestion will probably also be added.

@AS
You are correct about how it works. Your suggestion that A' would be a cleaner frame then A in an AA' dup scenerio is also something to consider. However, doing what you said for duplicate strings would pretty much eliminate the benefit of doing it in the lowest to highest order... which was that you will still get correct decimation in cases where frames are incorrectly declared as dups when they aren't due to low metrics (this happens on very slow panning scenes among others). I guess things could just be changed to decimate the frame before the frame with the low metric (both in most similar and in longest string decimation) instead of the low metric frame itself. For the moment I'm not going to do it, but I will put it on my things to test list.

@Leak/All
I was thinking more about the one-pass mkv vfr mode (with addition of plain black frames onto the end to pad as needed and including the actual ending frame number as a comment in the timecodes file), and aside from the consecutive cycle limit needing to be 2 or 1, it would also require completely linear access from start to finish to work correctly. If these requirements aren't too much to deal with I will add it.

Hybrid handling through blending of 30p sections will also be able to be done in 1 pass with the requirement that the required number of consecutive cycles is limited to 2 or 1 as in the mkv vfr 1 pass case. The blending one pass does not have the requirement for completely linear access though and will work correctly when seeking.

[Mug Funky]

that's music to my ears, tritical :)

i wonder if using avs processing inside of ffdshow would be a way to overcome the problem of needing the final frame count? i suppose directshow needs the frame count as well.

[Chainmax]

I am testing TFM(mode=2) and noticed slight jaggyness on some frames. After reading the readme, will altering any of the parameters eliminate this issue?

BTW, would there be any chance to replace blend for interpolation as a deinterlacing method?

[tritical]

It depends on whether or not the jaggyness is caused by deinterlacing or bad matching. I can't tell whether or not you meant it is from deinterlacing or not in your post, if so just ignore this next part. Could you run TFM with "display=true" and see wether the bad frames have been detected as combed and deinterlaced or are just bad matches? After that it'll be easier to find out whats wrong.

There is already a non-blending option in tfm, its the interpolation from tdeint... but you could use the "clip2" parameter and basically get any type of deinterlacing you want. If you want cubic interpolation try something like this:

mpeg2source("c:\mysource.d2v")
deinted = last.bob().seleteven() #assuming tff source
tfm(clip2=deinted)

You can expand that to use deinterlacing from another filter or whatever. When using clip2 you do need to make sure that the field that is kept by the deinterlacer is the same as the field that tfm is matching from. See the clip2 description in the help file of tfm for more info. If many people think tfm should have linear or cubic interpolation built in I guess I could add it, but its not currently on my todo list.

[Chainmax]

I'll try the display option soon and report back.

[tritical]

Alright, well here is [link removed, look farther into the thread]. Yeah, I have no imagination for names. It includes TFM and TDecimate. I've tried to test everything to make sure it all works, but there may still be a couple things that slipped by. The options for TDecimate are not well organized and a little chaotic atm, but it gets the job done. The only thing that is not implemented is hybrid handling for cycleR > 1 (cycleR is the M in M-in-N decimation), all hybrid handling is currently limited to cycleR = 1 only. I have a plan for how hybrid handling for cycleR > 1 should work, but it would take a while and I'm not sure that there is even any need for it. Mainly just need some willing testers and feedback about what needs to be changed. The zip includes a "common usage examples" file that shows the syntax to use for most of the basic cases.

The one pass vfr w/ mkv timecode output can be done with the following script for example:

mpeg2source("c:\mysource.d2v")
tfm(d2v="c:\mysource.d2v")
tdecimate(mode=3,mkvOut="timecodes.txt")

The d2v option in the above script was added to TFM, among a few other fixes/changes, it scans the d2v file for illegal field order transitions (such as Fixd2v or DGFix) and will create a fixed version if anything wrong is found, and also will determine the field order from it if order is set to -1. The d2v option will work with d2vs from dvd2avi 1.76 and variants, dvd2avidg, and dgindex.

I'm also interested in feedback about the file input/output options if anyone uses two pass mode. Currently the filters do not check if a file with the same name already exists for output files (if there already is one it is overwritten), and for input files neither filter does any internal checking to make sure the file goes with the current video (such as calculating a crc for the first few frames).

EDIT: Decided to add the crc checking to output/input files. Now, whenever an output file is created TFM/TDecimate create a crc32 value based off the first 15 frames of the clip and store the value in the output file. On loading a file for input the value from the file is tested to make sure it is the same as the value for the current clip.

Also added a "batch" parameter to TDecimate that will disable some checks and memset two arrays to fake values allowing for a script with tdecimate(mode=5, ...) to be loaded when the input and tfmIn files have no entries. This allows you to set up vdub's job control with both scripts (a first pass script and a second pass script) at the same time and run them, meaning you don't have to be there when the first script/pass finishes.

[Mug Funky]

this looks very very cool. i can't test it right now unfortunately, but i will as soon as i can (provided the computer isn't too hot... just coming into summer here).

good work, as always :)

[igor1st]

TFM v0.9.3 crashs when mode=3.

[tritical]

Sorry about that, forgot to adjust the conditions of an array allocation for the PP parameter when it was added. That was causing modes 0 and 3 of TFM to crash if PP was greater then 0. Here's TIVTC v0.9.2 (http://bengal.missouri.edu/~kes25c/TIVTCv092.zip), it fixes it.

[Mug Funky]

nice! i finally got past 30000 frames on Lain and there was no crash. perhaps the illegal field-order stuff in the d2v was the culprit?

at defaults i still got 1 combed mouth in the ~30 minutes of footage passed through it. not bad.

question: does Tdecimate treat static scenes as 30p or 23.976 when set to output mkv timecodes? there seemed a lot of bits at 30p in the test i did, even though the whole thing (except the intro and one or two special effects) is a hard-telecine. perhaps i should mess with the thresholds some?

[tritical]

It depends on the vidDetect setting. You can read about it in the readme, but it can be set to detect video sections either off matches, metrics, matches or metrics, or matches and metrics. At default it is set to the last option, metrics and matches. Which means that for a cycle to be detected as video both the matches used by TFM indicate there are not duplicates and the metrics calculated by TDecimate are all above vidThresh. The other option that controls video detection is conCycle, even if the above requirements of vidDetect are met for one cycle the conCycle parameter sets a minimum consecutive cycle limit before any cycle will be marked as video. On default settings it should detect static sections as 23.976 film since all frames need to have metrics above vidThresh... unless the vidThresh value is too low for the clip. The metric parameters (dupThresh and vidThresh) i set relatively low and are geared toward pretty clean material at defaults. You might try using display=true in mode 4 and then go to a static section of the clip to set a more appropriate value for your specific clip. Or you could do it in two pass mode and set a higher conCycleTP value, by defaults conCycle is set to 2 which is its maximum and conCycleTP also defaults to 2.

Also could I bug you for a little sample containing the mouth movement that wasn't matched correctly? :p

[Mug Funky]

ach! i deleted it to make room for some urgent DVD copying. i had 20 gigs worth of backup on crap discs, and i have to get them copied onto good discs before they die completely... there's one spinning in the only drive that will read it now, and windows says there's 17.8 million minutes remaining... that's my priority at the moment, but i'll try to find that bit again when my data's safe :)

[tritical]

@Mug_Funky
If you already deleted it don't worry about, you sound like you have enough to do already :D.

@All
Here is [link removed, look farther down the thread] nothing big, changes:

TDecimate:
- fixed mishandling of the last cycle of a clip when in mode 3
and the last cycle was film
+ write blockx and blocky sizes into tdecimate metric log files
+ timecode v2 format output support

TFM:
+ significant speed up (30-50%) to modes 1, 2, and 4 with
PP > 0, due to some missing logic the output frame would
needlessly get checked twice for combing

[Chainmax]

I was going to use the following lines in an encode:

X=MPEG2Source("wherever\somesource.d2v")
Y=X.Trim(1,0)
ConditionalFilter(X,X,Y,"IsCombed","<","14")

and then wondered if the IsCombed parameter could be replaced with IsCombedTIVTC so that I'd have one less plugin to load on the script. I know that both functions hould be the same, but since IsCombed only has one parameter and IsCombedTIVTC has more I'm not sure if what I'm asking can be done.

[tritical]

Yeah, you should be able to replace it, but I'm not sure exactly what your script is suppose to do. Cause IsCombed and IsCombedTIVTC each only return true or false, but in your script you are testing if the result is less then 14 which it always will be since it can only be 0 or 1.

The number of parameters doesn't really make a difference, to call it with multiple parameters just do:

conditionalfilter(X,X,Y,"IsCombedTIVTC(MI=32,blocky=8,blockx=8,chroma=false)", "=", "true")

as an example.

[Chainmax]

This script portion is supposed to reduce jumpy lines on combed frames and was suggested by scharfis_brain to BoNz1 a long time ago in this thread (http://forum.doom9.org/showthread.php?s=&threadid=69565&highlight=jumpy+lines). I'm guessing that the 14 in the conditionalfilter line is related to the threshold parameter in IsCombed.

[tritical]

I think he probably meant something like this:

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

Cause you can test the original version:

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed","<","14")

And it will always return x, since the result of iscombed is always less then 14.

[Chainmax]

I don't think so because he said this as well:

you'll maybe have to replace < with > and adjust 14 up or down.

Maybe he can explain it himself? I'll PM him and ask what he meant.

[scharfis_brain]

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

wherever this script snipplet is from, I can remember it was questioned for a functionality, that replaces a combed frame with its predecessor. (maybe useful for low-fps telecined anime, not suited for 24fps or so footage)

that's all the magic behind.

[tritical]

I am not questioning the functionality of this line:

conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

but this line:

conditionalfilter(x,x,y,"iscombed","<","14")

That line is nothing more then a slow way to return all the frames from the "x" clip. The operator and value strings "<" and "14" have nothing to do with any parameters the function takes. They are used only in conjunction with the return value from the function to see if the statement is true. And in the case of IsCombed the return value is only false or true (0 or 1). So testing if the return value is less then 14 will always return true and that line will always return the frame from source 1 (x). You can test it yourself, any "<" or ">" test won't make a difference (it will always either return all source "x" frames or all source "y" frames) for IsCombed unless it differentiates between 0 and 1 (true or false).

[scharfis_brain]

the line
conditionalfilter(x,x,y,"iscombed","<","14")

is pretty much useless, cause iscombed does not return comb-amount-values.

it only returns true/false if the current frame reaches the given threshold.
the threshold has to be set within iscombed, not outside.

[Chainmax]

That's exactly the line you recommended in the thread I linked to...what did you mean to recommend then?

[scharfis_brain]

which thread?

[Mug Funky]

http://forum.doom9.org/showthread.php?s=&threadid=69565&highlight=jumpy+lines

that one.

you also said you hadn't tested it... :)

[Chainmax]

You posted the answer before I could...bad, bad Mud Funky :P ;). This goddamned computer keeps hanging up constantly. I'm gong to have it checked, I swear.

scharfis_brain: the link to that thread is nine posts above this one.

[scharfis_brain]

WTF....

Did I really wrote this?

hmm...
This occurs, if one is doing direct stream copy form brain to keyboard without AVS-Check :(

obviously the condfilter-line I posted about one year ago is WRONG. Stupid me...

[Leak]

I was wondering - will you be adding MMX or SSE code to this plugin?

This would be a great way to make it waaay faster than Decomb, and I guess that the parts which do the frame metrics calculation and blending (where the filter most likely spends the most time in) aren't gonna change much anymore, right?

If you want, I can give it a try. :)

np: Yasushi Ishii - Musical Play Smiling Rebellious Flower (Hellsing Original Soundtrack Raid)

[tritical]

I wasn't planning on it. If you want to take a look and try speeding parts of it up be my guest :). Assuming normal processing (non-combed frames, etc...) the majority of the time is spent in only three routines:

match comparison (TFM)
combed frame detection (TFM)
diff metric calculations (TDecimate)

TDecimate is usually slower then TFM by a good bit when there aren't a lot of frames that need deinterlacing or need extra matches tried. The frame blending routine in tdecimate is also ridicously slow... I didn't spend any time on it cause I never use blending, but it would be by far the easiest one to make an mmx version of, and could probably give a good speed up if a lot of blending is taking place.

[tritical]

Said I wasn't going to, but the frame blending routine was very simple to make an mmx version of so I went ahead and did it. I'm definitely not gonna try to do mmx or isse versions of the other main functions though. This version also includes a few minor fixes to TDecimate having to do with incorrect mkv timecode v2 format output in modes 3 and 5. Here it is... [link removed, look farther into the thread]. Changes:


TDecimate:

- fixed outputting of a few extra timecode entries when using
tcfv1=false (v2 format) in mode 3 or mode 5 and the last
frame was not a cycle boundary
- fixed incorrect formatting of the first 2 lines of the
mkvOut file when in mode 3 and using tcfv1=false (v2 format)
+ added mmx and sse2 blending routines (used when hybrid = 1)

[Leak]

Originally posted by tritical
Said I wasn't going to, but the frame blending routine was very simple to make an mmx version of so I went ahead and did it.

Whoa - that would have been the first thing for me to do come this weekend... :)

I'm definitely not gonna try to do mmx or isse versions of the other main functions though.

Well, I'll do that, then...

Also, would you mind me adding a "forceCPU" parameter as seen in my plugins? If I manage to introduce bugs into the MMX or SSE code (and I know I will, at least at first... :)) it would let everybody and their dog fall back to the plain C++ versions.

np: K-Taro Takanami - Love Of Babble (Chobits Original Soundtrack 001)

[tritical]

Nope, I wouldn't mind... you can add whatever you feel like :D.

[Leak]

Originally posted by tritical
Nope, I wouldn't mind... you can add whatever you feel like :D.

Ugh. Well, I would have already done something if I hadn't underestimated the time marking 24 MicroJava-compilers for my part-time tutor job at the university takes... :(

I'll try to start on it this weekend even though I have to come into work on Saturday.

Anyhow, I just tried TIVTC on the first episode of Ghost In The Shell: Stand Alone Complex and found that there was a duplicate frame causing a stutter after a few scenechanges, just as it happened with Decomb on other sources.

I'm wondering - since you're already doing scene change detection for the video parts, would it be possible to detect them for the film parts as well and treat them specially?

I was thinking about something like this:

If you find a scenechange and on one side of it there are more than <cycle> dups in a row, look for a frame to drop on the opposite side of the scenechange first and drop a frame there if you can find one - this would take care of scenechanges that go from a still scene to a moving one.

On the other hand, if the scenechange is badly edited so you'd have to drop a duplicate on both sides (which might be detectable by looking ahead and back a bit and finding out the used pattern, or just by checking if there's 2 or more candidates within <cycle> frames of the scenechange in both directions) you could drop the one closest to the scenechange on each side and insert a new frame at the scenechange's position that blends the 2 neighbouring frames so audio & video stay in sync. IMHO that would be much less noticeable than a sudden jerk in a pan that just started or ended.

I tried cutting out a scene or two to illustrate this, but everytime I cut out a part with Cuttermaran, run it through DGIndex and load it in an AviSynth script, I get different metrics in TDecimate due to different combing... :confused: (and yes, I did cut at an I-frame and chose starting points that didn't cause a shift of the cycles that TFM gets...)

Well, this is just a suggestion; I'll see if I can find a way to cut out parts reliably (help, anyone?) and upload you an example or two if I manage to do it - if you want, of course. :)

np: Autechre - Latent Quarter (Envane)

[tritical]

Well, a few minutes investigation into Leak's observation revealed that longest string decimation mode in v0.9.4 and before has a couple bugs causing it to not work correctly (i.e. not at all for what it is intended to do)... There is a reason why this filter isn't 1.0 yet :D. Anyways, I've fixed the above mentioned bugs, but am gonna wait till I get a chance to check out Leak's sample before posting a new version. So I would recommend no one use longest string decimation in TDecimate for the time being.

[BangoO]

Hi tritical and the others.

First of all, thx for these great filters.
TFM() works like a charm, a lot better than Telecide() from what I tested.
TDecimate() works also better than Decimate(), but it's awfully slow, I don't know whether it's normal or not.

The source is an HDTV 1080i file that I'm trying to IVTC.
With a TFM() followed by a Decimate(), I encode in WM9 at around 8fps.
Just replacing the Decimate() with a TDecimate(), I encode in WM9 at around 2fps.

Both Decimate() and FDecimate() use the default values.

Is this normal ?
If not, what should I do ?

Thx a lot ;)

PS: I use this version TIVTCv094-1.zip
PS2: I have a P4 3.2

[tritical]

In a word, yep :(. The main things that make it so much slower are:

1.) by default decimate only checks luma while tdecimate checks both luma and chroma (set quality = 3 in decimate to sample both)
2.) tdecimate uses overlapping blocks while decimate doesn't
3.) tdecimate can use user defined block sizes in metric calculations (the blockx and blocky parameters) while decimate uses fixed 32x32 blocks

I am suprised it was that much of a drop off, though it would make more difference with larger frame sizes. I could try adding a quality setting like decimate has (to do subsampling) or having a metrics mode that does not use overlapping blocks or both. Though then tdecimate would be pretty much the same as decimate for most similar 1-in-N non-hybrid cases.

[BangoO]

Thx for the fast answer :)
It would be nice to have a TDecimate as fast as Decimate, but then it would be Decimate... so...

I'll try playing with Decimate() parameters to check if I can get something perfect.
It works perfectly 99% of the time, TDecimate worked on the last 1%, too bad :)

[tritical]

[link removed, look farther down], changes:


TDecimate:

- Fixed problems with longest string decimation and static to
panning and panning to static scene workarounds in longest
string decimation
+ added se parameter (causes mode 3 to stop early once the last
actual frame is delivered)
+ mmx and sse2 blending routines now work with any width (not
just mod 8 and mod 16)

This version should fix all problems with longest string decimation and correctly handle Leak's clip (whichever way it is decoded :D).

[BangoO]

triptical, I have a file (29.97fps 3:2 pattern, that I'm trying to IVTC) with a glitch in the middle resulting in a field order change (bff to tff).

When I was using Telecide, my script looked like that:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = Telecide(a,order=0,guide=1,post=2)
a = Decimate(a)
b = Telecide(b,order=1,guide=1,post=2)
b = Decimate(b)
return a + b


So, with your filters, I thought I could use:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = TFM(a,order=0)
a = Decimate(a)
b = TFM(b,order=1)
b = Decimate(b)
return a + b

But it does not work, the second part of the clip goes "forward and backward".


So I tried this:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM()
Decimate()

But it displays lots of interlaced frames in the second part since the field order is wrong.


So, then, I tried to play with the options of TFM and tried this:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM(mode=3)
Decimate()

It seems to work just fine, and does not care about the field order.


What do you think about all this ?

Thx again ;)

PS: I'm using TIVTCv095.

[tritical]

Not really sure off hand, but I do have a couple questions:

First, in this script where the second part is messed up:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = TFM(a,order=0)
a = Decimate(a)
b = TFM(b,order=1)
b = Decimate(b)
return a + b

If you set order = 0 in the second TFM call does it also produce bad results on the second part?

Second, if you use this script:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM(d2v="D:\test.d2v")
Decimate()

Does TFM pop up an error about illegal transitions? If so, does the resulting fixed d2v file produce correct output with that script?
Also, the reason setting mode=3 seems to fix things is because, as you said, it really doesn't care about the field order since mode 3 does 3-way matching.

[BangoO]

Originally posted by tritical
If you set order = 0 in the second TFM call does it also produce bad results on the second part?
Yes it does.

Originally posted by tritical

Does TFM pop up an error about illegal transitions? If so, does the resulting fixed d2v file produce correct output with that script?
It does pop up an error about illegal transition, and the fixed d2v works !

This is GREAT !

Just so I know, what does it fix in the d2v so that the field order is now the same all along ?
I'm concerned about this as I don't want to loose some frames even if they look like crap because of the glitch, otherwise the sound will be off synch.

[Dreassica]

Or use dgindex to create d2v, since that fixes fieldorder changes.

[Leak]

Originally posted by tritical
This version should fix all problems with longest string decimation and correctly handle Leak's clip (whichever way it is decoded :D).

Yes, it does... :D

Now, how Bandai managed to b0rk the telecine in this part so there's a cycle of 5 frames with no dup right after the cycle containing the scene change (with the pan going at the same speed per new frame as in the cycles after it) so that it'll pan faster during that cycle when viewing it on a TV is beyond me - now IVTC would have to drop a frame that really isn't a dup or blend the frames down, but what can you do?

It plays smoother with conCycle=1, though, so I'll use that. Also, Last Exile for instance had a few blend transitions where they faded quickly from one pan into another with the telecine patterns not matching up where blending down looked much better (it's a fade after all) than a dropped field in the middle...

np: Autechre - PIOBmx19 (Garbage)

[tritical]

Or use dgindex to create d2v, since that fixes fieldorder changes.
Actually, dgindex can still produce d2vs with illegal transitions... though the only time I've seen them is on vob boundaries. Also, I don't think dgfix, which only supports dgindex's d2vs, would be included with dgindex if it never suffered from this problem?

Just so I know, what does it fix in the d2v so that the field order is now the same all along ?
I'm concerned about this as I don't want to loose some frames even if they look like crap because of the glitch, otherwise the sound will be off synch.
It changes the rff flags in places where two consecutive top or bottom fields are called for (which is what changes the order). It wont cause any syncing problems, a single field may be added (repeated) or eliminated (not repeated) at each of the illegal transition points, but that is it. So no frames will be dropped or anything like that. For more info look here (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=88&highlight=fixd2v).

[BangoO]

Ok, thx a lot for those explanations, and for those great filters ;)

[acrespo]

I have too many jagged lines with TFM. I already tried all modes but I have the same ammount of jagged lines to all modes.
My source is anime (Inuyasha TV Episodes).

My actual script is:
LoadPlugin("d:\encodes\filtros\removegrain.dll")
LoadPlugin("d:\encodes\filtros\removedirt.dll")
LoadPlugin("d:\encodes\filtros\dup.dll")
LoadPlugin("d:\encodes\filtros\dgdecode.dll")
LoadPlugin("d:\encodes\filtros\mpasource.dll")
LoadPlugin("d:\encodes\filtros\masktools-v1.5.5.dll")
LoadPlugin("d:\encodes\filtros\tivtc.dll")
LoadPlugin("d:\encodes\filtros\degrainmedian.dll")
LoadPlugin("d:\encodes\filtros\mvtools.dll")
LoadPlugin("d:\encodes\filtros\hqdn3d.dll")

import("d:\encodes\filtros\degrainMC.avs")
import("d:\encodes\filtros\LimitedSharpen.avs")
import("d:\encodes\filtros\FastLineDarken_1.3.avs")

video=MPEG2Source("d:\inuyasha117.d2v")
audio=MPASource("d:\inuyasha117.mpa")
AudioDub(video,audio)
Trim(107,10213)++Trim(10369,21066)++Trim(21224,36415)

TFM(mode=1)
TDecimate(mode=1,hybrid=1)

Crop(2,18,-6,-16,align=true)
LimitedSharpen(dest_x=320,dest_y=240)
DeGrainMC()
hqdn3d()
FastLineDarken()
dup(threshold=1,blend=true,maxcopies=8)

[Mug Funky]

could you post a small sample of the m2v where it exhibits this problem?

i've noticed that some telecines are inherently a little jaggy (though not as bad as you get from field-discarding), like Evangelion Platinum (better than the old release, but could be better) and Serial Experiments Lain. so even with correctly matched fields there might still be some jaggyness from a rough telecine.

[Didée]

Originally posted by acrespo

Crop(2,18,-6,-16,align=true)
LimitedSharpen(dest_x=320,dest_y=240)
DeGrainMC()
hqdn3d()
FastLineDarken()
dup(threshold=1,blend=true,maxcopies=8)
Ouch, the pain.

Jagginess might come from applying too much filtering on a *too small resolution*. I'd have a particular suspect on FastLineDarken for that respect.
And instead of calling LimitedSharpen before all those denoisers, you can completely drop it as well and spare its CPU time: everything it has done will be 100% destroyed by the aftercoming filters ...

What about

Crop(2,18,-6,-16,align=true)
DeGrainMC()
hqdn3d()
dup(threshold=1,blend=true,maxcopies=8)
FastLineDarken()
LimitedSharpen(dest_x=320,dest_y=240)

[acrespo]

No, it's not the filters, because I tried Kernelbob+BlendBob and the problem is not occurring.
The jagged problem is really from TFM.

[ObiKenobi]

Try turning off postprocessing and see if that helps.

[acrespo]

Yes!! PP=0 resolve the jagged problem but I need PP because I have too many interlaced parts now. What can I do?

[tritical]

@acrespo
Could you provide some more information, such as if the problem is there are too many false combed frame detections (in which case try setting chroma=false), or if combed frame detections are ok but you just don't like the results from cubic deinterlacing (in which case try using PP = 5 for blending or PP = 7 for ela). Using display=true in tfm could help with determining which is the case. If you could provide a small sample clip that would be even better.

@All
Well there was another problem with hybrid detection, it was from not correctly differentiating between deinterlaced frames and c matches when checking for duplicates via matches in tdecimate. It would cause some cycles that had combed frames that were deinterlaced to not be detected as video when they should have been. Also, I haven't been invoking a cache between TFM and TFMPP when PP>4, which was making things slower when frames needed deinterlacing.

On the non bug related side, I've added handling for the case when 2 dups need to be dropped when there's a change from a panning scene to another panning scene. In the case of vfr (hybrid=2) both dups are dropped and the timecodes are adjusted for that cycle to compensate and in the cfr case either 1.) both dups are dropped and the frame before the scenechange is repeated or 2.) if tdecimate doesn't know exactly where the scenechange is it drops the lowest metric frame and replaces the other with a blend of its two neighbors. If anyone has any other ideas or suggestions for what to do in such a case feel free to post them.

[Leak]

Would you happen to have a link for your latest version? If nothing terrible happens tomorrow, I'm going to dig into it and try to come up with some MMX/SSE/SSE2 code - which probably would be a good idea to do on the latest code... :)

np: Autechre - Dial (Gantz Graf EP)

[DarkNite]

Just wanted to drop in and say that I've been getting great results with TIVTC. TFM is working well and TDecimate is coming along great.

Keep up the good work, and best of luck on future optimizations.

[tritical]

Was gonna post this last time, but there was one lingering problem I didn't get fixed before I had to leave. So here is [link removed, look farther down], pretty much just the changes/fixes mentioned before:

TFM:
- Fixed not invoking a cache between TFM and TFMPP when PP > 4
+ Some internal additions to allow TDecimate to tell the
difference between c matches and deinterlaced frames
+ Added debug output to d2v checking... when debug=true and a
d2v file is specified it will report the type of d2v
detected, the detected field order from the d2v if order = -1,
and report the errors if any are found

TDecimate:
- Fixed not differentiating between c matches and deinterlaced
frames when hybrid > 0 and checking for dups via matches
- Fixed crash with debug=true and large cycles (> 50) due to
too small of a string buffer
- Changed default sceneThresh to 13
- conCycle and conCycleTP now default to 1 when vidDetect = 3
and still default to 2 when vidDetect != 3
+ Added handling for cycles around scene changes which need 2
dups removed
+ Some other internal changes

@DarkNite
Thanks for the comments, glad to see someone got some use out of it, and hopefully Leak will work some mmx/isse magic to improve the speed a little.

[tritical]

Minor bug fix release [link removed], changes:


TDecimate:
- Fixed a problem with timecode file generation that would occur
in mode 5 with tcfv1 = true. If the cycle following a cycle
that needed 2 dups removed was detected as video then an
erroneous line would be written to the file.
- Fixed not initializing mkvOutF file handle

TFM:
- Fixed passing AsClip() a NULL argument during TFM and TFMPP
object creation if no clip was given for clip2. This would
cause assertion failure when compiled in debug mode.

Thanks go to Leak for spotting most of those.

[BangoO]

Originally posted by tritical
It changes the rff flags in places where two consecutive top or bottom fields are called for (which is what changes the order). It wont cause any syncing problems, a single field may be added (repeated) or eliminated (not repeated) at each of the illegal transition points, but that is it. So no frames will be dropped or anything like that. For more info look here (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=88&highlight=fixd2v).
Well, on the file I tested, it adds some fields, and then when I use TFM()/Decimate(), there are some places where I have repeated frames that don't have if I don't fix the D2V.
Therefore, the audio gets out of synch :(

I tried with DGIndex, DGFix and DGDecode, and I don't have the repeated frames anymore, but I still have to check the whole thing for possible out of synch audio.

In the file I tested, there are 2 field order changes, but TFM(d2v=...) fixes a lot more than that.
Maybe that's the cause, I don't know...

[BangoO]

I did some more tests...
If I correct the D2V created by DVD2AVI and correct it just where there is the FO change, the audio stays in synch all along.
In this case, it was a 0 1 0 sequence, replaced by a 0 0 0 sequence.

I assume TFM fixes the following sequences:
0 3
1 0
1 1
2 0
2 1
3 2
3 3

The question is... which ones can produce an FO change (I know from my example that "1 0" can) ?

Thx ;)

[tritical]

And here comes another release... [link removed], the changes:
TDecimate:
- Fixed incorrect setcachehints call due to checking the value of
the wrong argument
+ Faster and more accurate mmx/sse2 blending routines, thanks to
Leak
+ Optimized the metric calculation routines a little. Exactly
how much of a speed increase is dependent on the source
being processed.
+ Some other optimizations and internal changes.

TFM:
- Changed the d2v method of fixing illegal transitions to one
that doesn't alter the total # of fields in the clip.
- Changed default value for the chroma option to false
+ Some other optimizations and internal changes.
The new d2v fixing method is in response to BangoO's questions... a thread on the subject can be found here: http://forum.doom9.org/showthread.php?threadid=87267. While this version doesn't have any major optimizations, it does give a noticeable speed increase (mainly from TDecimate). How much is dependent on the source, but I can say that it dropped the one pass time on an episode of Last Exile from 20 minutes to 15 minutes 30 seconds on my comp.

[BangoO]

Great !
Thx tritical ;)

I just tested, TDecimate() is still very slow compared to Decimate() on HD material.

[tritical]

And another release... [line removed]. Finally got the last thing on the todo list taken care of, a chroma option for tdecimate. Changes:

TDecimate:
- Fixed mode 4 display output saying "mode 3" instead of "mode 4"
+ Added chroma parameter
+ mode 4 display and debug output now display the sceneChange
metrics along with the block difference metrics
The chroma option can disable consideration of chroma planes when caculating metrics (similar to quality=2 in decimate, which is its default), which can give a speed up (not huge, but noticeable). The metrics will tend to be slightly higher for chroma=false then chroma=true, so I adjusted the defaults for dupThresh, vidThresh, and sceneThresh. They still default to 1.1, 1.1, and 13 when chroma=true, but if chroma=false they default to 1.4, 1.4, and 15. Getting close to a 1.0 version.

EDIT: whoops.. I lied, there was one more thing to add. An improvement to longest string decimation that should improve its operation/accuracy quite a bit... so thats v0.9.7.1.

[Mug Funky]

you is da man, tritical.

[BangoO]

Originally posted by tritical
The chroma option can disable consideration of chroma planes when caculating metrics (similar to quality=2 in decimate, which is its default), which can give a speed up (not huge, but noticeable)
TDecimate(chroma=false) seems to be as fast as Decimate().
So... which one is the best ? :D

[scharfis_brain]

I tried to replace smartdecimte with tdecimate in restore24.

without success.
tdecimate causes steady jerkyness, due to its fixed threshold.

I used mode=2,rate=23.976 with 50fps input.

would it be possible for you, trictical, to make mode2 working with an adaptive threshold?
the pattern of the 23.976 video in the 50fps video is irregular, max. number of dupes is 3 and minimum is one.

smartdecimate is able to do this without any jerk, but it needs reinterlaced contents for its analysis.


I intend to replace this:


video=last
analyse=last.separatefields().selectevery(4,0,3).weave()
analyse.smartdecimate(6250,2997,bob=video,weave=video)


with this:


tdecimate(mode=2,rate=23.976)

[tritical]

@BangoO
If your just using TDecimate(chroma=false) vs decimate() there honestly is hardly any difference. The only thing will be in the metric calculations with tdecimate's overlapping blocks vs decimate's non-overlapping blocks, and I doubt this would cause any noticeable difference when doing most similar decimation. I would probably just stick with decimate since it will be faster.

@Mug Funky
Thanks :p.

@scharfis_brain
Yep, mode 2 sucks quite a bit as it is now. I haven't touched it since the very first version of tdecimate. Like you pointed out, it is far too dependent on one threshold. An adaptive threshold would help... I can think of a few other changes that would help it quite a bit as well. Would it be possible for you to send me part of that clip to test on?

[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.

[tritical]

[link removed], changes from v1.0 beta 1:

+ Added modes -2 and -1... will upsize vertically by a factor of 2 using ELA or ELA2
+ Call SetCacheHints()
+ Some small optimizations, should give a very small speed up Ok, no new features after this release... only changes will be bug fixes if any are necessary before v1.0 final here in a few days.

This doesn't mean the end of TDeint development for anyone who might be concerned (I am probably the only who qualifies)... v1.1 plans currently include adding motion compensation, though not in the usual way. TDeint is very modular, meaning each step is separated (motion map, linking, denoising, interpolating), which is part of the reason it is so slow, but which also makes it easy to add new interpolation types and intermediate steps. My plan is to add optional motion compensation as an intermediate step between motion map creation and interpolating. That is, use the current motion mapping to identify static areas, and then use motion compensation to try and get values for the pixels that are marked to be interpolated (moving). Any pixels that can't be recovered via motion compensation will then be interpolated as usual. Just imagine how slow that will be :D. However, that is a ways away... gonna spend some time on TIVTC now.

[Marius-the-Mad]

Originally posted by tritical

This doesn't mean the end of TDeint development for anyone who might be concerned (I am probably the only who qualifies)...No way. :) Tritical, your deinterlacer is just great. :) Thank you very much for it! I have some NIN videos here (from the new 'The Downward Spiral' remaster) and I don't know what I would do with them without TDeint. :)

In other words: thanks a lot! :D

[warath]

Aye, I love your TIVTC, works wonders on my Star Trek backups!

[LigH]

Due to the recommendation of scharfis_brain, I just tested TDeint 1.0b2 on the VQEG (PAL) test samples, where many deinterlacers clearly show flaws (e.g. KernelDeint leaves "stripes" of not deinterlaced, or even apparently totally unrelated, content). We discovered that even TDeint hat to fight hard here, I had to lower the "AP" parameter even below 10 to suppress such artifacts; even at AP=5, there are still some hints of stripes visible, especially in the part 08 with the scrolling text, when the background liquidly waves forth and back.

[tritical]

Is there a link where I could get those test sequences? Or what is the name of the part 08 sequence? Anyways, from your description it sounds like standard motion adaptive artifacting. Setting AP at 5 you almost might as well do a dumb bob.... though there isn't really anything you can do to prevent motion adaptive artifacts besides turning to a spatial combing metric. Out of curiosity, were you testing by viewing deinterlaced clips during playback or single frames in vdub?

[MacAddict]

Impressive results here with Tdeint doing a typical deinterlace film. I'm thinking of using it full-time in place of KernelDeInt now. Many thanks for your effort tritical!

[tritical]

@Marius-the-Mad, warath, and MacAddict
thanks for the comments :).

@LigH
I found a place to get those sequences and downloaded sequence 8. It is definitely a killer for a motion adaptive deinterlacer.

[LigH]

I once downloaded all the PAL sequences (1 .. 10). A few are progressive (#1 is even a "long still" - but e.g. QuEnc gets crazy about that content), but most are interlaced.

scharfis_brain told me, especially "short shutter" material is hard to compensate, because such algorithms seem to rely on the last bit of motion blur during one field. And computer generated frames often have a duration of 0, not (near) 1/fps seconds - no motion blur at all.

Another "killer" is the "rugby game" (#9), which might also have short shutter, and in #6 - Formula 1 - scharfi told me about possible flaws in the { hoarding | perimeter advertising } ("FOSTERS").

Here a short overview over the VQEG sequences:

ftp://ftp.crc.ca/pub/crc/vqeg/TestSequences/Reference/

1: Tree (25p, long still)
2: Stadium (50i)
3: Harping (50i)
4: EBU Ant (50i, CG)
5: Kayak (50i)
6: Formula 1 (50i) -- btw: M. Schumacher does fail sometimes... ;)
7: Fastfood (25p)
8: Scroller (50i, CG)
9: Rugby (50i; short shutter?)
10: Toy train (50i)

If someone prefers, you may add NTSC clip descriptions here, too. But unfortunately, the download there is sloooowwww (and the files are huge, because they are plain UYVY).
__

Okay - just downloaded the NTSC files, too:

13: Fun fair (TC)
14: Skyscrapers (60i)
15: Toy train (60i - similar to 10)
16: Jungle (30p, CG)
17: Letters (2x15p)
18: Waterfall (60i?)
19: Football (60i)
20: Sailing ship (? - too less motion)
21: Blonde@phone (60i)
22: Flowers+leaves (60i)

[tritical]

Yep, that was the site I eventually found. Sequence 6 I got and tested and it suffers from the same thing, the motion of the FOSTERS sign occurs at just the right rate/frequency that each field appears stationary on a single pixel level. Increasing the length of the static area detection from 5 to 6 fields could help, but wouldn't eliminate all artifacts, would be slower, and would sacriface some true static areas. I am still playing with the idea that in a majority of these cases, especially with the FOSTERS sign, most of the artifacts occur in areas where a majority of the pixels are correctly detected as moving and thus interpolated. Perhaps a dilation type operation on the motion map, or an AP mode where it identifies pixels with an ap value over the threshold and a majority of the pixels inside a window around it are set to be interpolated could help. Or perhaps overlapping block based static area detection. Will have to think about it some more, those samples are definitely nice for testing... thanks for mentioning them.

[rkk44]

Dear Tritical,

I cannot get TIVTC 0.9.8.5 to work in mode 5. Here is the pertinent portion of my script (based on your examples) that deals with TIVTC:

V=mpeg2source("c:\sg1614.d2v",cpu=4,idct=7,ipp=true).assumetff()
A=MPASource("c:\sg1614 MPA T01 DELAY 0ms.mpa",normalize=false).BufferAudio()
AudioDub(V,A)
ConverttoYV12(true)
clp=last.rgbob().selecteven() #Bob Deinterlace then 60 => 29.97 fps
tfm(pp=4,clip2=clp,output="matches.txt")
tdecimate(mode=4,output="metrics.txt")
tfm(pp=4,clip2=clp,input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=0,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")


When I try to run this in VDubMod it gives me the following error:

"Tdecimate: Input Error: Mode 5 -- All Frames Must Have Entry"


However, if I replace the above "TFM/Tdecimate" script with clp.tdecimate(mode=2,vfrDec=0) it works. I also tried directly replacing the clip2 with the d2v but I get the same error.

Thanks for any help which you can provide.

[tritical]

I guess it is not that clear in the documentation, but for mode 5 it needs all the stats so it can calculate everything at the beginning, which means two passes need to be made. In the first pass use/run this script:

mpeg2source("c:\sg1614.d2v",cpu=4,idct=7,ipp=true)
assumetff()
converttoyv12(true) <= is your source 4:2:2?
clp = last.rgbob().selecteven()
tfm(pp=4,clip2=clp,output="matches.txt")
tdecimate(mode=4,output="metrics.txt")
crop() <= change this to crop the image down to 32x32 or 16x16 to speed things up

That pass is only to allow tfm/tdecimate to gather the needed info (i.e. create the output files), so the actual video output of that pass doesn't matter.

Then on the second pass use:

V=mpeg2source("c:\sg1614.d2v",cpu=4,idct=7,ipp=true).assumetff()
A=MPASource("c:\sg1614 MPA T01 DELAY 0ms.mpa",normalize=false).BufferAudio()
AudioDub(V,A)
ConverttoYV12(true)
clp=last.rgbob().selecteven() #Bob Deinterlace then 60 => 29.97 fps
tfm(pp=4,clip2=clp,input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=0,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")

If you are encoding to a loseless file first there is a one pass vfr mode (mode 3), but it will not have the correct # of frames.

Even though the above process requires two passes it can all be set up in vdub's job control to execute at once. That is, load the first script and save it to job control then load the second script and save it. You will need to add the parameter batch=true into the tdecimate() line of the second script for tdecimate to allow it.

However, I think vdub's avi handling has been changed somewhere along the line so that if you load a script once and save it to job control, and then run the process later, while having altered the script to return a different number of frames then when you originally loaded it, vdub still sets the frame count to that of when the script was first loaded. That means loading both scripts at once into job control wont work, because the first time you load the second script tdecimate uses junk info and the framecount is not the same (it will be less) as when it gets loaded later with the real info. I'm not sure exactly which versions of vdub do that (v1.6 does, and probably v1.5.10, not sure about v1.5.4/v1.5.1), but I still use a rather old version of vdubmod (v1.4.13.2) and it works fine.

Not sure if all of that made sense, it is rather difficult to explain easily.

[rkk44]

Tritical,

Thanks for the help. That did the job.

[Just for your information, I am using VDubMod (VDub) Build 1.5.10.]

[tritical]

Alright, I lied about no new features in TDeint. After testing on those VQEG sequences I decided to add two new AP post-processing modes that take motion of surrounding pixels into account and allow for low AP values w/o completely sacrificing static areas or reverting to a plain spatial deinterlacer.

Specifically, sequence 6 (racing w/ fosters sign) is handled much, much better with TDeint(type=3,AP=7). Sequence 8 is tougher but most of the major (visible) artifacts are removed while leaving the logo intact using something like TDeint(type=3,link=3,AP=7,APType=2).

Complete changes:
05/14/2004 v1.0 beta 3
+ Added APType parameter, adds 2 new AP post-processing modes that take surrounding
motion into account
+ Small changes (hopefully improvements) to type 3 (ELA-2) interpolation
TDeint v1.0 beta 3 (http://bengal.missouri.edu/~kes25c/TDeintv1b3.zip)

EDIT: there was a little off by one loop bug in the AP pp routine.. updated the zip archive with a fixed version.

[Mug Funky]

there seems to be some horizontal (!!) artefacts showing up with "TDeint(1,1,type=3,link=3,AP=7,APType=2)".

i'll try narrow it down a little... right now it's happening on an NTSC anime sample (the ADV trailer for "cromartie high school").

[edit]

my apologies... it's in the source. now THAT's weird.

i can anticipate this series giving deinterlacers hell though - all the characters have thin horizontal lines as shading - it flickers like hell on an NTSC TV.

[scharfis_brain]

Mug Funky, would you like to show me a short sample?
(cannot imagine how that should look like)

[Mug Funky]

sure. i'll send you the trailer if you PM me your Gmail (if you got it...)

[edit] oh. it's over 60 megs... maybe i'll just cut the start bit out :)

[scharfis_brain]

this kind of flickering seems to be caused by bad interlaced scaling and rotating of this letter.
so the characters became more flickery.

[tritical]

And another new version... [link removed]. Finally got the new mode 2 added to tdecimate. It is definitely a different approach to arbitrary decimation. It works by applying a series of M-in-N decimations that recursively minimize the error to the required ratio, ensuring decimation is evenly spread throughout the video. Its behavior is controlled with 3 settings. "rate", which sets the decimated output rate as before, "maxndl", which controls how much non-uniformity is allowed in the decimation (for dealing with clips with uneven duplicate distribution), and "m2PA", which removes the default 100 frame look ahead restriction and allows tdecimate to look as far ahead as needed (that enables it to produce the same results as if the metrics were available from an input file).

Anyways, I have not gotten to extensively test it so if anyone finds clips/settings that make it crash, blow up your comp, or do other weird things please report :). It should deal well with clips that regular M-in-N decimation usually doesn't, especially clips that do not have uniform duplicate distribution (as long as maxndl is tweaked to fit the requirements).

Complete Changes:
TDecimate:
+ First cut at new mode 2 operation.
+ Added maxndl/m2PA parameters, go with mode 2.

[MOmonster]

first of all, sorry for my bad english. I´m new to these things and don´t speak it so often.
I´live in germany and all my interlaced material seems to be bad telecined. I tried some filter combinations, like matchbob with unblend and fdecimate or for matchbob the doubletelecide function with tfm(mode=2, pp=7) and also one time restore24, but all these functions and combinations have big disadvantages. First of all, the speed, but also the accurate deblending and the right decimating isn´t a small problem. Of course tfm and telecide are fantastic filters, but for such weird material we have to live with such functions till now.

Tritical, if you could implement such features in your TIVTC, it should work also great for bad telecined material.
Please read this text and also tell me my mistakes.

[MOmonster]

Oh, sorry, here is the text:


Before I will explain how these features should work, I give you four
points, that say us how the material has to be, that the feuture could
work:

1. If 1, 2, 3... are the frames, a1, a2, a3... are the
top-fields and b1, b2, b3... are the botton-fields, there
shouln`t be a match from b2 and a1 (for top-field first),
because b2 would step back in movement. (no float pictures)

2. a blending-field should be between to clear fields
(between the both source-fields for the blending), becouse
otherwise it wouldn`t be possible to detect the blending.

3. If a 0-step means the step between two matching fields,
a 1-step is the step of a whole frame and a 0.5-step is
the step between a clear and a blended field, there
shouldn´t be a 1.5-step in the source (because of point two)

4. Between two matchings (0-steps) there should be only one
(max.) full step (1-step) between two fields, otherwise
audio and video would be asynchron.

Ok, somebody could say, that for his source this four points
aren´t all right, but for this source also restore24 shouldn´t
work correctly.

Now I try to explain how this noblend-feature could work
(for top-field first).

All posible matchings in a source should be found, just by
trying to match the top-field (or botton-field, depends on
the parity) with the previous and the next field. All other
searchings for matching should be useless (so, TFM(mode=0)
should be enough, I don´t know for what the 4. and 5. way
are, maybe as debugger for a wrong parity of some frames,
but should be normally useless). But mode=0 is not enough
for bad telecined material. Let me explain:
If there is a c-match in frame 1, a2 could be a
blending-field. In this case it would be good to look for
a match for b2 with the next field.

a1 a2(b) a3 a4...
l /
l /
b1 b2 b3 b4...

match: c u


But this is only useful after a c-match (not after a p-match).

And now to the bigger problem. A frame has no matching-fields.
It´s time for the postprocessor! But what field should be
choosen for postprocessing. We have to find out what fields
are clear and what are blends. There are many methods for
detecting blends. We could compare the number of edges, the
complexity, the number of colours or for example the
sharpness. Also we can do like unblend, but all these methods
aren´t accurate enough or just need to much time.
I thought about a method, that use the possibility of a
matcher and that should solve this problem. So easy it sounds,
so good should it work.

To detect a field as blended (or not), we just blend the both
fields around together and try to match this new field with
the tested field. If both fields really match, the tested
field is blended.
This is the theory.
To make it more practicable, we just have to test both fields
after the last possible match. The clear field is the field
where the match results in more combing than the other.

I try to make it more clear with some examples:

A. a1 a2 a3(c) a4 a5...
/ l
/ l
b1 b2(b) b3(b) b4 b5...

match: p c


1. frame 3 gives no c- or p-match
(u is unneccessary, because of the p-match)

2. less combing for matching b2 with blend of a2
and a3

3. more combing for matching a3 with blend of b2
and b3, so a3 should be reproduced.

B. a1 a2 a3(b) a4 a5...
/ /
/ /
b1 b2(c) b3 b4 b5...

match: p p

1. frame 3 gives no c- or p-match
(u is unneccessary, because of the p-match)

2. more combing for matching b2 with blend of a2
and a3

3. less combing for matching a3 with blend of b2
and b3, so b2 should be reproduced, through
it is a field of frame 2.

C. a1 a2 a3(c) a4(b) a5...
/ /
/ /
b1 b2(b) b3(c) b4 b5...

match: p p

1. frame 3 gives no c- or p-match
(u is unneccessary, because of the p-match)

2. less combing for matching b2 with blend of a2
and a3

3. more combing for matching a3 with blend of b2
and b3, so a3 should be reproduced.

4. also frame 4 gives no c- or p-match

5. more combing for matching b3 with blend of a3
and a4

6. less combing for matching a4 with blend of b3
and b4, so b3 should be reproduced.

D. a1 a2(b) a3(b) a4(c) a5...
l l
l l
b1 b2(c) b3(c) b4 b5...

match: c c

1. frame 2 gives no match (also no u-match)

2. less combing for matching a2 with blend of b1
and b2

3. more combing for matching b2 with blend of a2
and a3, so b2 should be reproduced.

4. also frame 3 gives no match (also no u-match)

5. less combing for matching a3 with blend of b2
and b3

6. more combing for matching b3 with blend of a3
and a4, so b3 should be reproduced.

There could be much strange pattern in bad telecined material, but
with such a feature TFM should be able to reproduces also such weird
material. I´m no coder and knowledge about the functions and filters
of avisynth is to bad, to be able to create a function, that would
enable this feature. It would be great, if you could implement such
a thing in your filter, tritical.
The advantages over restore24, matchbob, doubletelecide and so on
are clear. It would be really faster and should be a bit more
accurate against blends.


And there is also an other feature for your tdecimate.
If the tfm would have the possibility to tell tdecimate, what matched
frames use a same field, for example if after a c-match follows a
p-match. This could be possible for example with the hints
(an use_hints option for tdecimate).
With such an option tdecimate could work a lot faster, if there
are given enough frames for decimating. And tdecimate should also work
better, because it would prefer these frames more then other, what
maybe are doubled just because of no motion.

It would be great, if this text could help you to tweak your
fantastic filters.

[tritical]

@MOmonster
Sorry for not getting back to you sooner, but I was on a trip the last four and a half days with no internet access. I read through the text and didn't quite follow some of the specifics, mainly the assumptions about which comparisons would produce more or less combing, but I think I got the general idea. Would you mind sending me a sample to test on? I don't have any clips with blending patterns as you describe. If so just pm me.

@All
[link removed]. This version adds iSSE optimizations for the default metric calculation case of TDecimate. That is when blockx = 32, blocky = 32, nt <= 0, and width and height are mod 16. The speed up is pretty significant. On a 10,000 frame test clip tdecimate went from running about 120fps to 1200fps on my comp, so roughly a factor of 10. Your mileage may vary. The optimizations are for both YV12 and YUY2, both with and without chroma.

[Chainmax]

I have an interlaced clip that gives TDeint some trouble. I will try to upload it somewhere soon.

[MOmonster]

Sorry for my late answer. I only have internet on weekend till now.
I have a sample of 8 mb for you, but I don´t know how to upload. This sample is so bad telecined, that tfm and telecide use the postprocessor on really many frames. But many of this postprocessed frames are blendings, because your filter just choose the first field to recreate the progressive frame.

Can anybody help me to upload the short sample?

[LigH]

Free uploads:

http://rapidshare.de

[MOmonster]

Thank you, LigH.

Here is the sample (http://rapidshare.de/files/2014414/sample.m2v.html).

[tritical]

@MOmonster
Thanks. After looking at it I think your idea could work well. I'm gonna implement it into tdeint first though cause it will be easier. Bascially, add a new mode that outputs at same framerate but instead of always using the top or bottom field it will choose adaptively based on your blend detection by comparing combing idea. Will see how it goes.

@Chainmax
Any luck uploading that clip? If you don't have a spot I can just give you my ftp info.

[Chainmax]

I have a place to upload it to, but I had a virus infection a couple of weeks ago and want to make sure I'm clean as a whistle before uploading anything anywhere. It will take a few more days (basically, I need to find someone willing to scan any file from my machine which should be infection free now).

[MOmonster]

@tritical
Oh, I havn´t expected, that it will be easier to implement it into Tdeint.
I´m really happy, that you try to implement this blend-detection. :D
Will it also work together with your tryweave option? If yes, this should work similar to my idea for your tfm filter (maybe not in all cases same good, but of course really nice).

Thanks for your attention.

[tritical]

I'm not sure exactly how it's all gonna work in the end, but as of right now I think it will be achieved via a tfm+tdeint combination. A script like:

deinted = tdeint()
tfm(clip2=deinted)

So far, I've added a new 3-way match mode into tfm that is like mode 4, but with all matches that go against the field order removed. So for a tff stream, matching off top field, it first tries c/p, if the best of those two is detected as combed then it tries u and if u isn't combed it uses that else it goes back to the best of c/p and does PP.

I've tested the blend detection method you mentioned above and while it seems good in principle it doesn't work that well in practice. The major problem is that the blend ratio is not a constant and that screws up the comparisons. Instead, I decided to try a method that simply checks to see if the current field is a blend of the previous/next field. Since the two surrounding fields should be clean, simply determining that the current field is a blend should be enough. To do that it creates 5 frames, assume we have the following fields:
B <= top field
A C <= bottom fields
and we want to know if B is a blend of A/C. The five frames it creates are:
0 1 2 3 4 <= frame #

B B B B B <= top field
A (25%A/75%C) (50%A/50%C) (75%A/25%C) C <= bottom field
It then checks the overall combing level of those five frames. If min(1,2,3) is less than min(0,4) by a significant margin then it decides that B is a blend of A/C. The extra 25/75, 50/50, and 75/25 frames are to account for uneven blend ratios. It seems to be working quite well so far, but will need more testing. Of course the above method will not work for true interlaced material, as it assumes that B either matches with A or C or is a blend of those two.

[Revgen]

@Chainmax

Try to use http://www.yousendit.com to send the file to Tritical.

You can upload any file up to 1 GB to their server for somebody to download, and the file will stay on their server for seven days.

It costs nothing to use. It also scans files for viruses, so you don't have to worry.

I hope this helps.

[MOmonster]

@tritical
Oh, I also thought about this problem, but I wasn´t able to test it before. I thought, we still get the blended field, if we compare the combing levels for both fields, but I seem to be wrong.
If MIN(0,4) is really significant higher than MIN(1,2,3), would you also test the field C and than compare the differences or would you use a combing difference parameter to decide, if the test of field C is really necessary.
Your method seems to be accurate enough to find the blend fields.
By trying to match A & B or B & C we get the the combing levels for 0 and 4 and now compare it with MIN(1,2,3) to find the blending.
Maybe you could make this method a bit more effective.
If B is really a blend of A and C, maybe we could compare the combing levels from matching A with B and B with C to find out how strong the blending factor is.
If B is for example an A:C => 30:70 blend, the combing level from matching B with C should be much higher than for matching A with B.
So, it shouldn´t be necessary to create three new frames. We should be able to use an adaptive blend factor by comparing the combings. The rest would work how you said it.
Maybe it is possible to choose the right blendfactor a bit more differenced, for example choose between 20, 35, 50, 65 and 80 percent, but it is only an idea.
If C is the blend and not B, the blending factor should be unimportant, because the combing level should be still much higher than for the blended field, so we could work the same way.

Thank you for your work, tritical.

[Didée]

Hardly I dare to mention Restore24, but its blend detection works pretty good. Of course it is slower, since it works with edgemasks. But the percentage of blend reckognitions in not-static parts is usually >95%.
The idea is free to use, that's why Restore24 once was posted at all :)

(And also, that's why some are waiting for a suited decimator, less unstable than SmartDecimate, to fall from heaven.) ;)

[MOmonster]

Hi, Didee

You´re right, the blend detection of restore24 is really good.
But that is not the reason why I search for another way to make a good restoring.
restore24 has many disadvantages, not quality wise, but there are many other things, like maximum video length, the stability of this complex function and of course the speed.
The most important point is the dividing of the operations like deblending, decimating and so on. There is no need to search for blends on matched frames because there shouldn´t be any blending. Another thing to look at, is the fact that only, if there are blends, there are no possible matches, so this way, we only have to decide what of two fields is the blended field and don´t have to find out the less blends on the whole bobbed source. Also it is harder to decimate a bobbed source right than source with same framerate. We could tweak the decimating also if the decimater would be able to read the informations from the matcher and so on.
One more time, I don´t think restore24 works bad, no, it is an amazing function, that gets clear with nearly all bad telecined material. But there are other things, I said before, why I look for an alternative and this here seems to be also a good way.

[Chainmax]

Revgen, thanks for the tip, I'll use that.

tritical, yousendit needs a recipient email adress. Please create a temp account in a free mail and send me your adress in it via PM so that I can upload the file for you.

[MOmonster]

@tritical
I use the display info from Donald A. Graft´s Telecide to get something like a combing level for the different matches. You said, you don´t have such bad telecined material, so I´ll try to test a little bit on my sources. Till now my idea should really work, but I have to make many more tests, till I´ll come to a conclusion. It will need some time, but I hope it will help you. I don´t know, if the combing levels of Donald A. Graft´s Telecide are that much useful for you, maybe one of your filters could also display something like the combing level, that you could use the results better for you, but first I´ll try it that way.

@all
Does anybody know a good possibility to show the combing level of the current picture on the display?

[MOmonster]

@tritical
I wait for your next tivtc version, because I want to test you new three way mode.
So far so good, for today I stop with my test. I have learned a lot from testing the different sources. First of all my idea that after a clear field without a match can follows a second clear field without any possible match seems to be wrong. BUt my special mode for tfm I thought of wouldn´t be useless.
I made tests on ten different sources and more then eighty different motion scenes. On four of ten sources, there are sometimes (really seldom and only light) two blended fields, that stands together, so bad are the conversations.
It is possible, that if we have an u-match after an p-match, we lost a clear field.
This simply means, that we only should have a look to the next two fields after the last possible match. If we have a p-match and no possible c-match (there are maybe both matches possible, but p is better) we just should try to match the next two fields (second field from the previous frame and first field frame the frame we try to restore). That means only c- or p-match would be recommed. With a possible c-match of the previous frame also an u-match would be useful. The other thing is of course, that only this two fields should be used for the postprocessing with blend detection.
If we use tdeint as postprocessor after tfm we won´t solve this problem. Maybe you can think about the implemetation of such a mode in the feature.

But now to the more important thing, the blend detection tests.

Sorry tritical, but your idea also wouldn´t work that good. In nearly all scenes I looked at, I found some blends with blend factors between 10 and 15%, so the difference between MIN(0,4) and MIN(1,2,3) wouldn´t be that high or clear and sometimes we would detect the wrong field as blended.
A better method seems to be, that we compare the MIN(1,2,3) from testing the first field with the MIN(1,2,3) from testing the second field. In some cases this seems to work better, but also not for all absolut right.
I´m happy that my idea seems to work pretty good in all cases, I tested till now. To find the right blend factor by comparing the matches 0 and 4 seems to work really fine (till now not tested on really noisy and blocky source) also for the different sources. I still would prefer to compare the combing levels from the matched blend creations with the test of the other field. In some cases this seems to work better than compare the differences from MIN(0,4) with this combing level.

I made a list of the blending factors depends on the combing level ratio (0,4). I made it that accurate, clear because this should work better. Depening on the source the variance to the real blend factor isn´t higher than 3% (for my tests). I think this sounds not bad. I´ll make some more tests in the feature and maybe will modify the list a little bit, but till now this seems to work good. I hope these tests would help you a little bit.
So, here is the list :o


A = the ratio between the both matches with the blended field
(used the match values displayed from telecide)
B = the percentage of the blend factor from the field with the lower match values


A B A B
(value:1)

1 50% 2.5 29%
1.02 49% 2.6 28%
1.05 48% 2.7 27%
1.08 47% 2.9 26%
1.12 46% 3.0 25%
1.16 45% 3.2 24%
1.20 44% 3.4 23%
1.24 43% 3.6 22%
1.28 42% 3.8 21%
1.33 41% 4.1 20%
1.38 40% 4.4 19%
1.44 39% 4.7 18%
1.5 38% 5.0 17%
1.6 37% 5.4 16%
1.7 36% 5.8 15%
1.8 35% 6.3 14%
1.9 34% 6.7 13%
2.0 33% 7.2 12%
2.2 32% 7.7 11%
2.3 31% 8.2 10%
2.4 30%

[Chainmax]

tritical, did you get a chance to examine the sample?

[tritical]

@Chainmax
Yep, I took a look at it. I can't really give any suggestions or think of anything to improve the result significantly. It is just one of those tough clips to handle for a per-pixel motion adaptive deinterlacer. Hopefully handling of such cases will improve in the next version. Thanks for sending the clip, I will definitely keep it for future testing.

@MOmonster
Thanks for those tests. Indeed the 3 cases for the blend detection method I mentioned aren't always enough, smaller steps are needed.

I have been thinking more about the overall process and how it will work. After thinking about it, I am less and less inclined to try and include this in tfm/tdeint, and am thinking it would be easier to make a separate filter (that internally uses tfm/tdeint) specifically for handling such video. After looking at restore24 a little more in depth (I have never had any material that needed it) I think it's general approach is quite good. Turning restore24 into a filter (or making a filter that works like restore24) and adding some of the ideas from here (field matching, matching patterns, alternative choices for blend detection, etc..) seems like the best way to go. The filter would be able to grab the needed info about matches from tfm/tdeint since they already hint all relevant information. Anyways, I haven't had much time the last few days to work on it, hopefully that will change.

[scharfis_brain]

Hi tritical, I am currently playing wit TDecimate within restore24 :)

it works like it should!


Is there room for some minor impovement?

Restore24 delivers mainly this pattern:

Filmframes 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ...
inputframes xd xd xd xd xd xd xd xd xd xd xd xdn xd xd xd xd xd xd xd xd xd xd xd xdn xd xd xd ...


x - new frame
d - absolute duplicate
n - near duplicate (is a duplicte, but affected by noise and deinterlacing artifacts)

currently tdecimate chooses one of x, d or n when it detect such a triple
(I didn't examine which one it choosed..)

is it possible to force tdecimate to mix all near-duplicates to get noise and artifacts reduced?

In the case of Restore24 for frames 11 and 23 either x&n or d&n should be mixed.

This duplicate-blending should also help on normal IVTCes,
because noise and/or comression artifacts will be reduced be half.

[tritical]

Yep, that is possible... but how do you want to define near duplicate? I mean, how will tdecimate know which frames are near duplicates and not simply different frames with a small amount of motion? I guess it could be by looking at each frame that isn't dropped and seeing if its neighbors were dropped and are less than a certain difference threshold?

[scharfis_brain]

mean, how will tdecimate know which frames are near duplicates and not simply different frames with a small amount of motion?

Tdecimate already knows, that x, d AND n are duplicates of each other, because I only see one of them in the final output.

So blending the most un-similar duplicates should be possible, because the string of duplicates (here xdn) is already known..

[tritical]

That is only true under perfect conditions, which is definitely not always true. There is the possibility that there are more non-duplicates in a given sequence then there should be given a specific decimation ratio. In the star trek voyager sequence you sent me a while ago there were a few places where this was the case. That means one of the dropped frames could actually be a non-duplicate and blending it will produce ghosting. Also, you want the blending only when there are triples? Or blending for all dups?

[scharfis_brain]

That means one of the dropped frames could actually be a non-duplicate and blending it will produce ghosting.

But it also will reduce jerkyness a bit, if tdecimate is unsure about which frame to choose.

Also, you want the blending only when there are triples? Or blending for all dups?

No.

I had this idea: blend all most different duplicates of one row.

examples of duplicate chains (non-real-world):
n1,n2,n3 -> slight different near/new duplicates
d -> bit identical, or better said: almost identical duplicate of the preceding frame

this x d n1 will blended to: x+n1 OR d+n1
this x d n1 d1 will blended to: x+n1 OR x+d1 OR d+n1 OR d+d1
this x d n1 n2 n3 will blended to: x+n1+n2+n3 OR d+n1+n2+n3

Most duplicates after R24-processing are bit-identical. So a near-duplicate(s) should be detectable...
Of course, this assumtion does not fit for other sources,
as well as for the ST-Yoyager sample I sent to you because I compressed that one, so the duplicates arent identical anymore.


I hope I didn't cause too much confusion.

[MOmonster]

@scharfis_brain
Nice idea. Reduce jerkiness by blending the near doubled frames. But wouldn´t it be better just to choose the frame with better quality, because the blending will also produce a little softness in many cases (in some sources I tested some time ago). Also the reducing of the jerkiness wouldn´t be so strong just by blending the frames together.
In most cases the second duplicated frame is the frame with the better quality. Another point is that the match with less combing also seems to have the better quality. Maybe the decimater could read the informations from the matcher, that he could decide what frame to choose. But as I know restore24 use telecide to match the fields, don´t know if something like this is possible. But in sources I tested last time it would be better just to choose the right frame than blending them together.
It´s just an idea.

@tritical
I can understand you. We will see, what is going on in the future. I have begun learning C and C++, maybe in the future I will make my own filters. We will see.

[tritical]

Well, here is [link removed] ... it adds the new matching mode (new mode is mode 2, old modes starting at mode 2 have been bumped up one so old mode 2 is now mode 3 and so on). It also adds support for the new dgindex d2v files (v9). Gonna see about adding a general purpose combing measure output filter based on the 5 point metric. Currently tfm can output the match statistics it calculates via outputdebugstring() if debug=true, but those statistics are match specific (i.e. can't be compared to statistics from other matches).

@scharfis_brain
So I'm still not exactly clear on how tdecimate will know which frames are near duplicates. You're saying to look for two bit identical (or very close) frames and then consider all frames after and up to the next pair of identical frames to be near duplicates?

[MOmonster]

Hi tritical,
it took some time, but some minutes ago I finished my function. I tried to create a function, that realize my idea of a blenddetection and here it is. :eek:

LoadPlugin("C:\program_me\dgmpgdec\DGDecode.dll")
LoadPlugin("C:\program_me\filters\TIVTC.dll")
LoadPlugin("C:\program_me\filters\FDecimate.dll")
#LoadPlugin("C:\program_me\filters\TDeint.dll")
LoadPlugin("C:\program_me\filters\leakkerneldeint.dll")

#AVISource("D:\video\inu\[Ingow] Pirates Of Japan (Trailer).avi")
#OpenDMLSource("C:\Dokumente und Einstellungen\Benutzername\Eigene Dateien\Eigene Videos\film.avi")
#DirectShowSource("D:\video\inu\[Ingow] Pirates Of Japan (Trailer).avi")

MPEG2Source("D:\dvd.d2v",cpu=4,iPP=false)


#trim(0,0)

crop(8,8,-8,-8)


a = Cdeint()

tfm(order=1, mode=0, display=false, slow=false, pp=2, clip2=a)

fdecimate(rate=23.976,threshold=1.0,metrics=false) # or another decimater


function Cdeint(clip clp)
{

###### PREPARATION ######
global sourceclip = clp.leakkernelbob(order=1, sharp=false, twoway=false, threshold=7, map = false)
global testclip = sourceclip.duplicateframe(0)

###### FRAMES FOR BLENDPARAMETERS ######
global combing_n0 = testclip.selecteven()
global combing_n1 = testclip.selectodd()
global combing_n2 = combing_n0.trim(1,0)
global combing_n3 = combing_n1.trim(1,0)

###### POSSIBLE OUTPUTS ######
out = sourceclip.selecteven()
out_1 = sourceclip.selectodd()

###### Conditional Function Chain, evaluated from bottom to top (!) ######
c99=ConditionalFilter(clp, out_1, out, "btest/Min(combl_0, combl_1)", "lessthan", "btest_2/Min(combl_1, combl_2)")

c9=FrameEvaluate(c99, "global btest_2 = LumaDifference(blendmade_test, blendpic_test)")
c8=FrameEvaluate(c9, "Evaluate_test()")
c7=FrameEvaluate(c8, "global blendl_test = combl_1 < combl_2 ? 0.5 * Exp(0.66 * Log(combl_1 / combl_2)) :
\ 1 - 0.5 * Exp(0.66 * Log(combl_2 / combl_1))")
c6=FrameEvaluate(c7, "global btest = LumaDifference(blendmade, blendpic)")
c5=FrameEvaluate(c6, "Evaluate()")
c4=FrameEvaluate(c5, "global blendl = combl_0 < combl_1 ? 0.5 * Exp(0.66 * Log(combl_0 / combl_1)) :
\ 1 - 0.5 * Exp(0.66 * Log(combl_1 / combl_0))")
c3=FrameEvaluate(c4, "global combl_2 = LumaDifference(combing_n2, combing_n3)")
c2=FrameEvaluate(c3, "global combl_1 = LumaDifference(combing_n1, combing_n2)")
c1=FrameEvaluate(c2, "global combl_0 = LumaDifference(combing_n0, combing_n1)")
return(c1)
}


# (running inside of the Conditional Environment)

function Evaluate()
{
vid = testclip.selecteven()
vid_1 = vid.trim(1,0)

global blendmade = MergeLuma(vid,vid_1,blendl)
global blendpic = testclip.selectodd()
}

function Evaluate_test()
{
vid_2 = testclip.selectodd()
vid_3 = vid_2.trim(1,0)

global blendmade_test = MergeLuma(vid_2,vid_3,blendl_test)
global blendpic_test = testclip.selecteven().trim(1,0)
}

function Min(float a, float b)
{
temp = a < b ? a :b
return(temp)
}



Yes, I know there are still many tweaks possible. Till now, I don´t use a special mode to save more clear fields (the mode I explained some posts ago), there is no noise parameter till now, we can´t change the bobber and the most important point is, that the used values are still tweakable.
But also this early version seems to work really good.
I just post it here, that you could have a look on it. We spoke about it some posts ago.

[Chainmax]

I am trying to rip one of my DVDs, but my current script crashed VDubMod (or Avisynth, don't know). After checking filter by filter, I discovered that TFM was causing the crash. Any idea why? Here's the script:

MPEG2Source("X:\wherever\Test.d2v",cpu2="ooooxx")
DeDot()
TFM(d2v="X:\wherever\Test.d2v",mode=3,PP=7,mChroma=true,chroma=true,mi=50)
TDecimate(mode=1)
FixChromaBleeding()
LumaYV12(lumoff=-2,lumgain=1.0)
ColorYUV(levels="pc->tv")
HQDering()
Crop(12,0,700,476,align=true)
BicubicResize(640,480,0,0.5)
BlindPP(quant=0,cpu=0,cpu2="ooooxx")
LimitedSharpen()

[tritical]

I'm gonna guess that you are using a very recent version of dgindex? If you open your .d2v file in notepad and look at the first line what is the version number (DGIndexProjectFilexx, the xx)? If it is 10, then I haven't gotten around to releasing a version with support for that yet, and tfm will throw an error when it finds that it isn't a supported d2v version. Actually, I added support for v10 a while ago (only needed to change 1 line), but also added a few new features to tivtc and haven't been able to force my self to update the docs so it can be released.

On a side note, when you say crashed... does that mean vdubmod disappears without an error msg? If you're on xp sp2 and using a 2.5.6 beta, try replacing the avisynth.dll in your system directory with the one from this zip (http://bengal.missouri.edu/~kes25c/avisynth 2.5.6 - 6.22.2005.zip) (save a copy of your current one if you want to revert back), it should correctly report the error. If it is indeed a problem with supporting the d2v version.

[Chainmax]

Yes, I'm using the latest DGIndex and it uses v10. VDubMod does disappear without an error message and I am using an updated WinXP and Avisynth v2.5.6b3. I will try the dll, even though it's kinda evident from your post that it's a problem with DGIndex v10 since I really miss the error messages.


[edit] do I only have to replace the avisynth.dll, or the directshowsource.dll and TCPDeliver.dll files too?

[tritical]

Just avisynth.dll should do the trick. Nothing of significance has changed in tcpdeliver since beta 3, and the only change in directshowsource was a fix for rmvb getting stuck at 100%.