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

[Chainmax]

You were right, it's a DGIndex problem :).

[Guest]

You were right, it's a DGIndex problem :). Is there really a problem with DGIndex, or are you just trying to combine incompatible tool versions?

[Chainmax]

I was agreeing with him, and he didn't mention that DGIndex itself has an issue. I just phrased myself wrongly, sorry about that.

[tritical]

Here is [link removed], it supports dgindex v10 d2v files.

[Chainmax]

Works like a charm :).

[tritical]

Unfortunately, development on TIVTC/TDeint has slowed a lot due to my being busy and working on other projects, but I did have some free time earlier today so here is [link removed].

This version adds a new field matching mode to tfm (mode 6, so it doesn't change any previous mode numbers), and the ability for tfm to field match off the d2v flags (can be only in 0123, a.k.a film to dvd2avi/dgindex, sections or completely). With the addition of the d2v matching to tfm, tfm/tdecimate can now do ivtc completely off the flags in properly flagged sections. The decimation is not 100% strict to allow for hopefully better handling. How it works is tfm passes on the duplicate info, which is figured by taking into account the rff flags and the actual matches used, to tdecimate. TDecimate then checks that that frame's metric is indeed <= to the lowest metric in the cycle (which it should be) and that there is only 1 d2v duplicate in the cycle. If those conditions aren't met then it uses it regular handling. Field matching off the flags gives a very large speedup since no calculations have to be done.

Also, I finally went through and changed all the setcachehints calls for all filters in tivtc.dll to use a diameter instead of radius... so depending on script complexity it could give a pretty good speed up for most people.

Any feedback on the d2v flag based matching would be helpful, especially if it doesn't work correctly. I tested it a good bit, but the only material I have atm is either 100% film or 0.0% film, nothing that is split. I also have been doing some work on improving the field matching algorithm, and would be very grateful for sample clips that have matching problems (ideally where a good match exists between the normal matches - p/c or n/c).

Full change list:
TFM: Added new match mode (mode 6)
TFM: Added field matching from d2v file
TFM: Added "flags" parameter to control how d2v info is used or not used
FieldDiff: can use sse instead of sad
ALL: setcachehints diameter instead of radius

[BangoO]

tritical, what's the advantage of matching off d2v flags, only speed ?
How much faster is it ?

Thx ;)

[tritical]

The advantage is speed and also not risking incorrect matches due to mistakes by tfm's matching algorithm. The same reasons why it is recommended to use force film vs using an auto ivtc method when dvd2avi/dgindex report 100% film or a very high percentage film. In my tests on the movie castaway tfm ran about 6 to 7 times faster than when it had to actually calculate matches. In terms of raw numbers it jumped from about 130-150 fps to 1000-1100 fps. In cases where dvd2avi/dgindex report 100% film there is still no advantage to using tivtc, but in cases where it is <100 you get the benefit of flagged ivtc in most of it (assuming it all works correctly of course :D) and intelligent handling in the rest. TIVTC will still be slower than force film since tdecimate still does metric calculations, but tdecimate is extremely fast now for material that is mod 16 width/height since the isse optimized code for that path was added.

[BangoO]

Ok tritical, I'll give it a try then.
I'm just a bit "scared" to change my encoding method as the tfm I use is just so perfect right now... (TIVTC v0.9.7.2).

My concern is on sources that are supposed to be 99% "0 1 2 3" but which contain some drops in this sequence most of time caused by bad recording (something like "0 1 2 3 0 1 3 1 2 3", that's only an example).
In these cases, TIVTC v0.9.7.2 is just perfect... what about the new one ?

[tritical]

@All
Another new version: [link removed]. It adds a second slower matching fuction. The "slow" parameter is now an int instead of bool. The default is 1 so it uses the same matching function as previous versions with slow=true. Slow=2 may perform better in some cases where slow=1 fails.

@BangoO
It should behave exactly the same just going off what you gave as info. In the sequence "0 1 2 3 0 1 3 1 2 3" tfm would do field matching off the flags for the 0 1 2 3 0 1 then use its own comparisons for two frames where the fields from the 3 are and then go back to using the flags. TDecimate would get that info, but like I described before it will fall back into its own processing when it encounters more than one d2v marked duplicate in a cycle or on other strange scenarios.

Back in v0.9.7.2 of TIVTC (January 8, 2005) nothing was implemented as far as using d2v info, all it did was check for illegal transitions and the field order. You can get that same behavior with the current version by settings "flags=3" in tfm(). "flags=0" sets the behavior to what it has been doing since v0.9.7 of tfm (february 19th, 2005) up to now. That is check for illegal transitions/field order as well as pass rff info on to tdecimate to help duplicate/hybrid detection.

The current behavior with "flags=1" (which is the default)... is that it does all that flags="0" does plus in 0123 trf flag sections it does the field matching based off the flags. One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions. Atm this is not completely finalized as it needs more testing to see how well it works on a larger number of sources.

[Chainmax]

Good to see that TIVTC is still being worked on :). If you need a trouble clip for testing, you could download my Simpsons clip (http://www.31012.com/~azulftp/TestClip.vob). DGIndex reports it as NTSC, mostly interlaced with a few progressive spots. I have a couple of questions: first of all I'd like to know the difference between mode6 and mode3 (or match on combed and match (same order) on combed, for that matter). Also, I am going to try the following line on an encode:

TFM(d2v="X:\wherever\myd2v.d2v",mode=3,PP=7,slow=2,mChroma=true,chroma=true,mi=50)
TDecimate(mode=1)

That uses the default flags=1, but I'm using DeDot (dotcrawl remover) before TIVTC, that shouldn't screw up the flag switch operation, right? Also, if I understood correctly, the flags switch assumes that the source was correctly flagged, what could happen if it isn't and the flags switch is used?


P.S: if you download the Simpsons clip, could you confirm if the windows frames on the scene where Homer parks the car move up and down?

[Mug Funky]

@ tritical:

One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions.

this would be a reasonable assumption... any encoder that wrongly flags the stream with RFF etc would be giving glitchy output anyway (occasional jitters), and i wouldn't consider it TFM's job to fix this, as i've never heard of it happening (though theoretically it could happen on a 2-pass hardware encode when the playback deck glitches on the 1st pass but not the second, or other weird things like that. to be honest i don't know at what point the 3:2 detection happens in hardware encoders, but i imagine it happens on both passes).

[BangoO]

@BangoO
It should behave exactly the same just going off what you gave as info. In the sequence "0 1 2 3 0 1 3 1 2 3" tfm would do field matching off the flags for the 0 1 2 3 0 1 then use its own comparisons for two frames where the fields from the 3 are and then go back to using the flags. TDecimate would get that info, but like I described before it will fall back into its own processing when it encounters more than one d2v marked duplicate in a cycle or on other strange scenarios.

Back in v0.9.7.2 of TIVTC (January 8, 2005) nothing was implemented as far as using d2v info, all it did was check for illegal transitions and the field order. You can get that same behavior with the current version by settings "flags=3" in tfm(). "flags=0" sets the behavior to what it has been doing since v0.9.7 of tfm (february 19th, 2005) up to now. That is check for illegal transitions/field order as well as pass rff info on to tdecimate to help duplicate/hybrid detection.

The current behavior with "flags=1" (which is the default)... is that it does all that flags="0" does plus in 0123 trf flag sections it does the field matching based off the flags. One thing I didn't mention before was that when it does matching off the flags it also disables the post-processing check and just assumes the match is not combed to prevent bad post-processing decisions. Atm this is not completely finalized as it needs more testing to see how well it works on a larger number of sources.
Ok thx for the explanations, I'll give it a try...
I'll try TDecimate as well, I never used it as it was a lot slower than Decimate from the Decomb filters...
Is it a problem if I keep on using Decimate instead of TDecimate (if it is still faster) ?

[BangoO]

I'm having surprising speed results...
I encoded 1000 frames with the following configurations:
Option 1: TFM 0.9.9.5 + Decimate
Option 2: TFM 0.9.7.2 + Decimate
Option 3: TFM 0.9.9.5 + TDecimate

The script was the following:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("G:\pouet.d2v")
cropbottom(8)
TFM()
Decimate() # or TDecimate() for option 3
LanczosResize(1280,720)

Here are the results...
Option 1: TFM 0.9.9.5 + Decimate -> 226s
Option 2: TFM 0.9.7.2 + Decimate -> 220s
Option 3: TFM 0.9.9.5 + TDecimate -> 273s

The source is a 100% FILM source, so TFM 0.9.9.5 should have been faster than TFM 0.9.7.2, but maybe I used wrong parameters (all defaults)...
Moreover, TDecimate is still a lot slower than Decimate.

PS: I didn't compare the results, but the size of the 3 result files are exactly the same (19 869 696 bytes) so one can assume the result is the same...

[tritical]

@BangoO
For tfm to do matching off the flags and get a speed benefit you have to specify the d2v parameter... tfm(d2v=""). If you don't then there will be no difference speed wise between tfm from v0.9.7.2 and v0.9.9.5.

The reason TDecimate is slower than decimate is because of the cropbottom() you have there. It prevents the isse code from being used due to the height not being mod 16 anymore so the c code is used. The c code for tdecimate will be slower than decimate due to the extra processing it does. The isse code is definitely faster than decimate by a good bit (2x or more).

[BangoO]

@BangoO
For tfm to do matching off the flags and get a speed benefit you have to specify the d2v parameter... tfm(d2v=""). If you don't then there will be no difference speed wise between tfm from v0.9.7.2 and v0.9.9.5.
Ok i'll try again then ;)

The reason TDecimate is slower than decimate is because of the cropbottom() you have there. It prevents the isse code from being used due to the height not being mod 16 anymore so the c code is used. The c code for tdecimate will be slower than decimate due to the extra processing it does. The isse code is definitely faster than decimate by a good bit (2x or more).
Ah nice, I'll definitely try again :D

[BangoO]

And here are the results :D

Option 1: TFM 0.9.9.5 + Decimate -> 146s
Option 2: TFM 0.9.7.2 + Decimate -> 220s
Option 3: TFM 0.9.9.5 + TDecimate -> 110s :cool:

PS: the following script has been used:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("G:\pouet.d2v")
TFM(d2v="G:\pouet.d2v")
Decimate() # or TDecimate() for option 3
cropbottom(8)
LanczosResize(1280,720)

[tritical]

@Mug Funky
this would be a reasonable assumption... any encoder that wrongly flags the stream with RFF etc would be giving glitchy output anyway (occasional jitters), and i wouldn't consider it TFM's job to fix this, as i've never heard of it happening (though theoretically it could happen on a 2-pass hardware encode when the playback deck glitches on the 1st pass but not the second, or other weird things like that. to be honest i don't know at what point the 3:2 detection happens in hardware encoders, but i imagine it happens on both passes). That is good to know. The whole matching off the flags rests on the assumption that the encoded frames in the mpeg stream are progressive. That seems highly likely when there is a 0123 pattern, but if there have been long breaks in the pattern somewhere earlier there is the possibility for strangeness. For example, I once saw a stream that had some sections with 0123 and other long sections of just 2222... in the middle of the stream there was a short section looked like this (where it transitioned from a run of 2's into 0123):

x a b c d <= mpeg frame
a b c d e

0 1 2 3 0 <= trf flags

So it was flagged with 0123, but the actual frames were offset by a field... in such a case the matching off flags would fail. I think that was from an hdtv capture that had bitstream errors from transmission or something cause it also had many illegal field order transitions so it is probably not a normal occurence.

[tritical]

@BangoO
That is better :). The results were still the same hopefully?

[BangoO]

Seems so... the file sizes are still exactly the same, and I also checked some frames, it seems identical.
I will have to test it on a bad flagged material now...

Thx for your great work tritical ;)

[tritical]

@Chainmax
I have a couple of questions: first of all I'd like to know the difference between mode6 and mode3 (or match on combed and match (same order) on combed, for that matter). The difference between mode 3 and mode 6 is only the order in which the extra matches are tried if the original two candidates are combed. First, a little explanation about the same order thing...

Assume you have a tff clip. Based on the field order the only matches that should work are p/c if you match off the top field or c/n if you match off the bottom field. So if field=1 in tfm (matching off top field) then p/c should be the best choices... if both result in combed frames, the next choice that has the best chance of making a good frame is u (u off top field == n off bottom field). So match same order simply means that it will try the match that makes since field order wise first when the main two matches are combed. Mode 3 doesn't go for the field order wise match first, but goes for the only remaining match that would still match off the same field (either p or n, whichever wasn't tried before). Both strategies have advantages and disadvantages. The u match has a more likely chance of being a good match, but it will create a duplicate because if u works it means the next frame is a p match. The n or p match is less likely to be a clean match (actually, it will only work if there is no motion), but it wont create a duplicate in a scene with motion. For example, in a lot of anime there are pulldown pattern changes at almost every scenechange due to edits and that also means that at quite a few scenechanges there is an orphaned field. In most circumstances, using the same order on combed mode will find a good match but it will create a duplicate... while the n or p match won't do any good at all. That difference is kind of moot in modes 3 and 6 since both end up trying all 5 matches if no good frame is found.

I think the best explanation for the modes if from the readme:

0 = (p/c)
1 = (p/c + n)
2 = (p/c + u)
3 = (p/c + n + u/b)
4 = (p/c/n)
5 = (p/c/n + u/b)
6 = (p/c + u + n + b)

a "/" means it will compare the matches to see which one is best, a "+" means if the previous matches are detected as combed then it will try the following match(es) and if the follwing match(es) are good then it will take it else it will drop back and use the best of the original two matches. One thing that has to be known is that tfm is only capable of comparing two matches if they are both being matched off the same field... i.e. it can compare p to c to n and u to b, but it can't compare u to p/c/n or b to p/c/n and vice versa. So to walk through modes 3 and 6:

mode 6 compares p to c and checks the best match to see if it is combed. If it isn't then it takes it else it creates the u match and checks it. If u isn't combed then it takes it, else it creates the n match and checks it. If n isn't combed then it takes it else it creates the b match and checks it... takes b if it is good else it drops back uses the best between p/c and runs post-processing on it.

mode 3 compares p to c and checks the best match to see if it is combed. If it isn't then it takes it else it creates the n match and checks it. If n isn't comed then it takes it, else it compares u to b and then checks the best match to see if it is combed... if it isn't then it uses it else it drops back and uses the best between the original two matches (p and c) and runs post-processing on it.
That uses the default flags=1, but I'm using DeDot (dotcrawl remover) before TIVTC, that shouldn't screw up the flag switch operation, right? Also, if I understood correctly, the flags switch assumes that the source was correctly flagged, what could happen if it isn't and the flags switch is used? Using dedot before is fine. The only problem that could happen with flags=1 is if you have a very strange stream that has 0123 flagging on non progressive frames. That situation should be rather rare as the whole point of using rff flags in that way is so that only the original progressive frames have to be stored.

[DarkNite]

After that explanation I'm just itching to see how mode 6 handles some of the more interesting scenechanges in older anime captures that have been sitting in my "waiting for manual edit" bin.

[Chainmax]

I don't know if this will be useful, but here are two screenshots from a specific frame (both use TIVTC v0.9.9.5):

Script 1:
MPEG2Source("X:\wherever\SimpTest.d2v",cpu2="ooooxx")
DeDot()
TFM(d2v="X:\wherever\SimpTest.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")
FunkyDeblock()
VagueDenoiser(nsteps=6,chromaT=0)
HQDering()
aWarpSharp(depth=16,cm=1)
Crop(12,0,700,476,align=true)
BicubicResize(640,480,0,0.5)
BlindPP(quant=0,cpu=0,cpu2="ooooxx")
LimitedSharpen()
Result:
Link Removed



Script 2:
MPEG2Source("X:\wherever\SimpTest.d2v")
DeDot()
TFM(d2v="X:\wherever\SimpTest.d2v",mode=6,PP=7,slow=2,mChroma=true,chroma=true)
TDecimate(mode=1)
FixChromaBleeding()
FunkyDeblock()
HQDering()
Crop(12,0,700,476,align=true)
BicubicResize(640,480,0,0.5)
Unfilter(-20,-20)
LimitedSharpen()
Result:
Link Removed

[tritical]

Hm, it is hard to gather anything from that without the debug or display output or preferably both. One thing that matters when trying the extra matches is the combed frame detection is not very sensitive to really small areas of combing... so if it tries n and it has only a tiny bit of combing it might use it while match u could be completely clean. That is the real tradeoff to trying matches in different orders... the first ones tested have a higher chance of being used.

One option that should be added soon is to only allow u/b matches at scenechanges, which should work well with the orphaned field situation I described above.

[Chainmax]

I'll upload these screenshots again, this time with the debug and display output info, but would those explain the missing star in the second screen?
Also, could you please confirm wether TIVTC causes the issue I mentioned a couple of posts ago?

[Chainmax]

The star now appears with the second script :confused:. I must have screwed up somewhere.

[tritical]

Hm, if using mode=1 in tdecimate you'll have to run straight through the clip to get to that point cause mode 1 results can be different when seeking. Since it is only tfm that differs would it be possible to eliminate the rest of the script for the moment? Determining what exactly happened to cause the difference in the full script would probably require the tdecimate debug output as well.

I suspect the reason the star is gone is just because tfm used a different match in the two different modes, but the debug output will tell for sure.

I downloaded the clip, but didn't notice any window moving when he parks the car. You are talking about the part right around frame 450 correct?

[Chainmax]

I was using the "Go to" option, so it must have been the seeking issue then, because the window now appears. Thanks for the reply.

The problem in the indows should be somewhere between frames 320 and 400 after IVTC. The source doesn't display such problems. The problem was mainly caused by aWarpSharp, but I think in this case TIVTC might have contributed a bit which is why I'm asking you to double-check for me since I'm not 100% sure after several tests.

[tritical]

If it did I am either too blind to see it or am not looking for the right thing cause I don't see anything.

[Chainmax]

Do you know those times when you have a computer related issue and when you try to show it to someone else it goes away? That's what happened to (yet another time) here. First the "missing star", now this :o. I feel really stupid, sorry for wasting your time like this :(.


P.S: I didn't notice any difference at first glance when using the flags switch, but then again I'm not too perceptive at that sort of things. What were your impressions on how d2v flag based matching handled the clip?

[Moitah]

Does anyone else see a bunch of green stuff when using TDeint(type=1) with TDeintv1b3? Source frame (http://www.moitah.net/misc/nat-src.jpg), After TDeint(type=1) (http://www.moitah.net/misc/nat-tdeinttype1.jpg) (Sorry they are a bit blurred from the JPG compression)

[tritical]

Yep, it is a bug in YUY2 type=1 chroma interpolation... forgot to change three lines when ap was added in beta 3. All the YV12 routines and all the other YUY2 routines are ok. I'll try and fix that soon. Thanks for reporting.

[acrespo]

Can I trim video before use TFM with flags= 0 to 2 like this:

mpeg2source("smx.d2v")
Trim(449,32701)++Trim(35087,47956)
TFM(d2v="smx.d2v",mode=3,pp=7,slow=2,chroma=true,flags=3)
TDecimate(mode=1,hybrid=1)

[tritical]

You can, but it wont work correctly :D. For flags=0 to 2 there can't be any modification of the # of fields or the order of those fields between mpeg2source() and tfm()/tdecimate(). flags=3 as you have now will work ok though. If you want to use flags=0,1, or 2 you would need to move the trim to after tdecimate.

[tritical]

Here is [link removed].

This version adds a hybrid=3 option to tdecimate which is similar to hybrid=1 except that instead of leaving 24p sections untouched and blend converting 30p sections to 24p, hybrid=3 leaves 30p sections untouched and blend converts 24p sections to 30p. This version also adds isse optimizations for more blocksizes for tdecimate's metrics calculations. The last addition is a new parameter called "sco" to TFM which can be used to allow u/b matches only at scenechanges (good for dealing with the case of orphaned fields that only appear at scenechanges due to edits). The only thing left on the todo list for tivtc at this point is optional blending in mode 2 of tdecimate.

[tritical]

Here is [link removed].

Changes:
- SetCacheHints call to diameter instead of radius
- Fixed type=1 YUY2 interpolation routine giving messed up chroma output
(bug was introduced in v1.0 beta 3)

[Leak]

The last addition is a new parameter called "sco"[...]

Sure beats writing "Litigious Bastards" (http://www.sco.com/)... ;)

Anyhow, I'd have one request for TIVTC - while blending 30FPS sections down to 24 works fine, I've found that some of the CGI car scenes in GITS:SAC were oddly enough rendered in 15FPS, i.e. every frame is shown twice.

The problem here is that TIVTC decimates these scenes since it thinks it's material that had pulldown applied to it, and thus introduces jerkiness. Would it be possible to check if every other frame (or probably 2 out of 3 and 3 out of 4 frames) is a duplicate and in that case treat this scene as video instead of film?

Yeah, I know it's a rather odd case, but it exists nonetheless... :(

np: Richard Devine - Arc-Acid (Cautella)

[scharfis_brain]

Well, as I asked before:is it possible to code a mode switcher?
(modes: Film, 30p, 60i)

like this pseudo-code for standards conversion:


mpeg2source("NTSC-Hybrid.d2v")

a=bob().convertfps(50) # 60 to 50
b=telecide().changefps(50) # 30 to 50
c=telecide().decimate().changefps(50) #24 to 50
T-Switch(last,a,b,c)
resize(width,576)
assumetff().separatefields().selectevery(4,0,3).weave()

[Leak]

Well, as I asked before:is it possible to code a mode switcher?
(modes: Film, 30p, 60i)

like this pseudo-code for standards conversion:
Wouldn't that have the problem that there could be discontinuities at the points where the mode is switched? I.e. a frame might be repeated since both the film and 30P stream considered it essential at that spot, or a frame might be skipped for similar reasons; which could be prevented by a single filter that handles everything.

np: Jah Wobble - Fly 2 (I Could Have Been A Contender (Disc 1))

[scharfis_brain]

this could maybe be avoided by checking, which of the new rendered frames is closer to the before chosen one...

[tritical]

@Leak
Could you send me a sample from gits:sac to test on? Such cases are indeed not handled correctly with vidDetect=3. You would probably be better off using vidDetect=0 or possibly vidDetect=2, but I doubt it will fix everything.

@scharfis_brain
It is possible of course, but I've already got a lot to do on my existing filters and I have no material to test on that is a mix of 24p/30p/60i. Would you be able to send some samples?

[Leak]

@Leak
Could you send me a sample from gits:sac to test on?
Sure... give me a minute or five... :)

Here it is. (http://leak.no-ip.org/AviSynth/Stuff/GITS_SAC_02_Funny%20Framerate.m2v)

Actually, after taking a closer look at this sequence it's not simply 15 FPS animation, but something quite strange... :confused:
Such cases are indeed not handled correctly with vidDetect=3. You would probably be better off using vidDetect=0 or possibly vidDetect=2, but I doubt it will fix everything.
I doubt doing that for maybe 15 seconds of footage (if even) for a 24 minute episode is worth it...

np: Jah Wobble - Fly 2 (I Could Have Been A Contender (Disc 1))

[tritical]

I looked at the clip and to me it looks like plain 12fps animation. After field matching there is a 3 frames (1 new + 2 dups) followed by 2 frames (1 new + 1 dup) pattern and mode = 1 with tdecimate handles it fine. It did have some irregular rff flagging so using d2v="" in tfm with flags = 0, 1 or 2 lead to incorrect decimation in a couple cycles where mode=1 w/o the rff info picked the correct frames to decimate. I went ahead and added in some extra logic to prevent mode=1 using d2v dup info in such cases.

Here is the result (xvid const quant 2) after using the following script:

mpeg2source("C:\gits.d2v")
tfm(d2v="C:\gits.d2v")
tdecimate(mode=1)

gits clip (http://bengal.missouri.edu/~kes25c/gitstest.zip)

[Mug Funky]

yeah. GITS SAC sticks to 24fps all through except in the last couple of episodes, and the japanese intro sequence (which comes out slightly jerky in the PAL version due to decimation). i think towards the end of the show some shortcuts were taken in editing, so there's a mix of pure 24p and some 30p. but i can only say this based on the PAL conformed version (which has some full-frame blending in it on the last tape that wasn't on any of the others!).

kinda makes me wish there were a way to get the best of all worlds in standards-conversion. speed up the film bits, blend the 30p and 60i bits to 50i, and encode interlaced.

It is possible of course, but I've already got a lot to do on my existing filters and I have no material to test on that is a mix of 24p/30p/60i. Would you be able to send some samples?

the intro to Gantz has all three types of content. anywhere you want it uploaded? i'll grab it tomorrow (at home now...).

[tritical]

@Mug Funky

68.119.245.113
port 17252
upload/upload

If that wont work just pm me.

I've seen the intro sequence for the first gits:sac r1 dvd and it has 30p, but I think most of the actual ep is 24, if not all, though I couldn't guarentee it.

[scharfis_brain]

@MugFunky: DEFT converters can do this. (I don't know what their price is)
but they are still inperfect, because they are deinterlacing and blending the 30p to PAL
.
I prefer fieldmatched 30p, which has became telecined (changefps) to PAL.

[tritical]

[link removed]

Changes:
TDecimate:

+ mode=1 w/ d2v info and hybrid=3 decimation improvements

[B.F.]

New DGMPGDec is out.
d2v opinion don't work now.

[tritical]

Support will be added in the next release, but I am working on adding some other features so it won't be out immediately. For now, to use the d2v option with v11 d2v files just make a copy of the d2v file and in the copy change the very first line from:

DGIndexProjectFile11

to

DGIndexProjectFile10

and use that copy as the file for the d2v argument in tfm(). The only change in v10 to v11 was removing a number before the path entries and that wont make any difference to tfm's d2v parsing/reading.

[Mug Funky]

I've seen the intro sequence for the first gits:sac r1 dvd and it has 30p, but I think most of the actual ep is 24, if not all, though I couldn't guarentee it.

all of it except the last 2 episodes. don't know why it went that way (deadlines in production?).

[Leak]

all of it except the last 2 episodes. don't know why it went that way (deadlines in production?).
What do you mean? That the last two episodes were 30p? If so, I didn't really notice it... gotta check my R1 DVDs once I'm home...

np: Deadbeat - Let It Rain (Wild Life Documentaries)

[tritical]

[link removed], changes:
TFM:
+ Added v11 d2v format support
+ Field matching improvements (improved the code that decided which metrics to
use for picking the final match)
+ Added micout parameter

TDecimate:
+ Added fast isse routine for 50/50 blending case
- Fixed a bug in hybrid=3 operation that caused it to handle certain scenechange
situations incorrectly.

Added FrameDiff filter and CFrameDiff conditional function

Took a little longer than I thought it would to get this version out, but finally got it done. And a thank you to MaXi_TK96 for providing test clips where field matching failed.

[TheBashar]

Oops, I should have searched this forum first, but I posted a probelm I've been having with TDecimate over in the avs usage forum: http://forum.doom9.org/showthread.php?t=99414

Basically, for the last couple releases I've been getting unhandled exceptions from TDecimate in mode=5 when vfrDec=0. When in mode=4, this doesn't happen, and mode=5 with vfrDec=1 also doesn't cause a problem.

Would it be beneficial to give a truckload of other specifics or does that narrow it down enough?

[tritical]

Gonna need a little more info cause I can't manage to duplicate the problem here. Could you post the following:

full avisynth scripts used
TIVTC version (please test with v0.9.10.0)
avisynth version

It would also help if you could send me the tfm/tdecimate output files... you can upload them here:

68.119.245.113
port 17252
upload/upload

Finally, when do the exceptions occur? During script loading or does it actually manage to process a few frames?

[TheBashar]

AviSynth: 2.5.5
TIVTC: 0.9.10.0

ep.avs
LoadPlugin("C:\Multimedia\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\TIVTC.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\TDeInt.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\DeDup.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\fft3dfilter.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\TTempSmooth.dll")
LoadPlugin("C:\Multimedia\AviSynth 2.5\plugins\WarpSharp.dll")

function FirstPass(clip c)
{
orig = c
c = tfm(c,d2v="ep.d2v",mode=6,slow=2,PP=6,cthresh=8,chroma=true,MI=20,output="ep.tfm")
c = TDecimate(c,mode=4,hybrid=2,vfrDec=0,output="ep.dec")
return c
}

function SecondPass(clip c)
{
orig = c
c = tfm(c,d2v="ep.d2v",mode=6,slow=2,PP=6,cthresh=8,chroma=true,MI=20,input="ep.tfm")
c = TDecimate(c,mode=5,hybrid=2,vfrDec=0,tcfv1=false,input="ep.dec",tfmIn="ep.tfm",mkvOut="ep.dtc")
c = DupMC(c,log="ep.dup")
return c
}

function ThirdPass(clip c, int begin, int end)
{
orig = c
c = tfm(c,d2v="ep.d2v",mode=6,slow=2,PP=6,cthresh=8,chroma=true,MI=20,input="ep.tfm")
c = TDecimate(c,mode=5,hybrid=2,vfrDec=1,tcfv1=false,input="ep.dec",tfmIn="ep.tfm",mkvOut="ep.dtc2")
c = DeDup(c,threshold=0.3,threshold2=1.0,range2=2,trigger2=2.5,maxcopies=20,maxdrops=20,log="ep.dup",timesin="ep.dtc",times="ep.tmc")
c = Trim(c, begin, end)
c = FFT3DFilter(c,sigma=2.5,plane=0,ow=24,oh=24,kratio=1.2)
c = FFT3DFilter(c,sigma=2.5,plane=1,ow=24,oh=24,kratio=1.2)
c = FFT3DFilter(c,sigma=2.5,plane=2,ow=24,oh=24,kratio=1.2)
c = TTempSmoothF(c,maxr=7,scthresh=7.1)
c = Crop(c, 0, 0, -2, -2)
c = LanczosResize(c, 880,480)
c = XSharpen(c, 15)
return c
}

clip = MPEG2source("ep.d2v")

start1 = 92
end1 = 5476
end2 = 7063
end3 = 61874

start2 = end1 + 1
start3 = end2 + 1

ep-a.avs
Import("ep.avs")
clip = FirstPass(clip)
return clip

ep-b.avs
Import("ep.avs")
clip = SecondPass(clip)
return clip

I open ep-a.avs in VDM and play through to the end. Then I close it and open ep-b.avs. Before any frame displays, AVS catches the exception.

It would also help if you could send me the tfm/tdecimate output files... you can upload them here:

Sorry, I couldn't seem to get the transfer to work. You can download the files from here: http://s33.yousendit.com/d.aspx?id=2N2B43EG7YC261R5KUA5V4LQP6

Anything else I can provide?

[tritical]

When you say "catches the exception" does vdub crash/terminate or does it give you an error/exception message like "unrecognized exception" or a read or write error?

[TheBashar]

It pops up the "unrecognized exception" error box.

[Chainmax]

tritical, in a couple of days I might be able to have a problem sample for you. It's a sample capture which only manual TMPG IVTC has been able to handle as all other methods (Decomb, TIVTC, SmartDecimate) make lines alternate between noticeably aliased and normal.

[tritical]

@TheBashar
I was finally able to track down the problem. One of the routines that is called when vfrdec=0 wasn't checking the bounds of a loop that alters an array and it would occasionally cause a little heap corruption. That would then occasionally cause an access violation during a malloc() call later on. I was only able to trigger it using the output files you posted.

@Chainmax
Any samples are welcome.

[TheBashar]

I was finally able to track down the problem. One of the routines that is called when vfrdec=0 wasn't checking the bounds of a loop that alters an array and it would occasionally cause a little heap corruption. That would then occasionally cause an access violation during a malloc() call later on. I was only able to trigger it using the output files you posted.

Great! I'm glad to hear you were able to find the problem. Thanks for running it down!

[TheBashar]

I ran into another problem. Is this the best place to brin it up or should I start a separate thread?

I have been testing using TDeint to decomb frames that come out combed from TFM. Oddly, I've found a scene cut that is combed but TFM doesn't think it's combed. TDeint has no trouble detecting it's combed, but I'd prefer to use TFM hinting so I wonder why TFM doesn't see it.

orig = clip
deint = tfm(c,d2v="ep.d2v",mode=6,slow=2,PP=1,cthresh=6,MI=64,output="epd.tfm")
deint = TDeInt(deint,type=2,clip2=orig,full=false,debug=true)
return deint

I believe with the parameters I've passed to TFM, it should be using the exact same combind detection as TDeint defaults to using. Unfortunately, I can see in DebugView that TFM hints not combed. If I change TDeint to hints=false, it detects and correctly deinterlaces the scene cut.

Any ideas?

[tritical]

Most likely, the original frame (this is what tdeint would see when using clip2) does create a value greater than 64, but the frame that comes out of field matching by tfm, while still combed, doesn't create one as big. You could see for sure by using "debug=true" and "micout=2" in tfm. That would show you what match is delivered by tfm and the MIC values (what is compared against 64) for each of the 5 possible matches. In the next version of tivtc I am adding an option to consider mic values during field matching that should make the handling of scenechanges that need to have a u or b match used much better, but it will also slow things down (it will be like using micout=2 is now). I am also planning on using the mic values in the field matching process in a more complicated manner than what will be in the next version, but that wont be added for a little while due to lack of time.

Finally, bringing up problems with tdeint or tivtc in this thread would be easiest for me in terms of making sure I see it.

[TheBashar]

Thanks for the explanation tritical, but I think there's some other problem here. I turned on the tfm debugging like you suggested. Below is the debug output from tfm and tdeint (ignoring hints). I don't understand how it all works, but I think some field match something is short-cutting the combed decision.


TFM: frame 320 - final match = p (D2V) MIC = N/A (OVR)
TFM: mode = 6 field = 1 order = 1 d2vfilm = F
TFM: CLEAN FRAME
TDeint: frame 320: accumP = 67248461 accumN = 117154
TDeint: frame 320: field = bottom order = ttf
TDeint: frame 320: mthreshL = 6 mthreshC = 6 type = 2


I should have noted earlier, TFM was still not detecting combing even with MI=20. And that frame is heavily combed.

[Leak]

TFM: frame 320 - final match = p (D2V) MIC = N/A (OVR)
There you go - you're using a D2V file, and the flags in it are b0rked. Try setting flags=1 or flags=0 in TFM and see if that fixes it.

[TheBashar]

There you go - you're using a D2V file, and the flags in it are b0rked. Try setting flags=1 or flags=0 in TFM and see if that fixes it.

By default it's already using flags=1 which does a superset of flags=0. But, just to be sure, I tried flags=0 anyway. There was no change in the results. In both cases TFM reports (via debug) "no errors found in d2v." Any other ideas?

[tritical]

Leak is right, the debug output you posted shows that it is doing the matching off the flags for that frame and isn't doing any analyzing of its own. With flags=0 or flags=3 it shouldn't do any matching off the flags.

By default it's already using flags=1 which does a superset of flags=0. But, just to be sure, I tried flags=0 anyway. There was no change in the results. In both cases TFM reports (via debug) "no errors found in d2v." Any other ideas?
The "no errors found in d2v" message simply means that there are no illegal field order transitions in the d2v file, it can't tell you anything about whether or not the flags are reliable to match from. Could you run tfm with "debug=true" and the default value for flags, and then run it with "debug=true,flags=0" and post the two logs somewhere so that I could look at them? Just run it for the first 400 frames or so.

[TheBashar]

Looks like I need to put my dumbass hat back on and apologize to Leak. I really did try it with flags=0, ahh... I thought. But now, flags=0 shows correct output with no combing. I dunno if I forgot to save the AVS after I made the change or what. Damn. Sorry Leak.

In case it still helps, I've attached the logs you asked for tritical. In the file name hint0/hint1 signifies the true/false setting of hints for TDeint. The problem frame I've been testing with is 320 in the logs.

I don't really understand what this implies. Does this mean that DGIndex is outputting incorrect flag information or does it mean the wrong flag information has been encoded into the source?

[tritical]

[link removed], changes:
TFM:
+ Added micmatching parameter
+ micout now works with display output
- stricter checking for 0123 sections with flags=1
- fixed a few debug output format inconsistencies

TDecimate:
- Fixed vfrDec=0 crash due to heap corruption

I don't really understand what this implies. Does this mean that DGIndex is outputting incorrect flag information or does it mean the wrong flag information has been encoded into the source?
It doesn't have anything to do with dgindex, it simply means that the trf flags in the mpeg2 stream can't be used for field matching purposes... at least for that frame. What that really means is that the encoded frames in the mpeg2 stream are not progressive, because if they were the flags could be used to tell which fields are part of the same frame (i.e. what you need to know for field matching).

Out of curiousity, could you try TIVTC v0.9.10.1 with flags=1 and see if that frame is still combed? Also, see how much of it is reported as film from the d2v? One problem was that when tfm checked for the 0123 pattern it only checked if the current flag was part of a pattern, but that could lead to problems. For example if you had:

123012230123

There is a pattern break with the two consecutive 2s, but both are part of a 0123 pattern if you allow for only looking completely ahead or completely behind (the first would be "3012" and the second would be "2301"). tfm was considering that type of pattern to be all ok to use for matching. I've now changed it so that it requires the current flag to be part of a 0123 pattern that extends on both sides, so for the above example it would do its own matching for frames that included any fields from the "1223" part.

[TheBashar]

Out of curiousity, could you try TIVTC v0.9.10.1 with flags=1 and see if that frame is still combed?

Using the new build, my "320" frame is not combed anymore. 320 and many of the frames before it are no longer marked with the (D2V) flag.

Unfortunately, some of the other scenechange interlaces still exist. Frame 1307 used to be just like 320, but it has not been fixed by the new build. It's debug output shows it is still using the (D2V) flags. :(

Interestingly, with the new micmatching turned on:
320 - match c: Detected As NOT Combed! (29 <= 64)
320 - micmatching override: c to u
320 - final match = u MIC = 29
320 - mics: p = 256 c = 29 n = 29 b = 256 u = 0

But, micmatching does not save frame 1307. It appears that micmatching is not used when TFM is taking the field flag information for that frame from the d2v. In order to be helpful with needed u/b matches around scenechanges, I would think you'd need it to be always on, not just when out of pattern.

Also, see how much of it is reported as film from the d2v?

In the last relese of IVTC, it reported 93.8% film. This release (with stricter pattern matching) reports 89.7% film.

Is there anything in the way of logs that would help in tracking down what's happening at 1307?

Thanks for all your help!

[TheBashar]

+ Added micmatching parameter

I forgot to mention one thing. I know that micmatching incurs a performance hit and from the help file you only override the field match when an mic is "significantly lower" (lets say by at least X amount) than the current match.

A quick shortcut would be not to compute the extra mic values when the current match has an mic of <= X. I have lots of frames with regular match mic values of 0 or 1 and it seems a shame to calculate all the other mic matches anyway.

Cheers!

[tritical]

Is there anything in the way of logs that would help in tracking down what's happening at 1307?
If you could post the d2v file and a list of which frames show up combed when matched from the d2v flags with flags=1 that would help the most.

It appears that micmatching is not used when TFM is taking the field flag information for that frame from the d2v. In order to be helpful with needed u/b matches around scenechanges, I would think you'd need it to be always on, not just when out of pattern.
It then somewhat defeats the purpose of matching off the flags... which is to avoid needing to compare matches and check if frames are combed, but I might consider changing it in the future. There hasn't really been enough testing with flags=1 on sources that have film percentages in the 10 to 90 range (I don't have any atm) to determine exactly how everything should work.

[TheBashar]

If you could post the d2v file and a list of which frames show up combed when matched from the d2v flags with flags=1 that would help the most.
Sure thing! The following 1.3MB linked 7z archive contains:

ep.d2v - Self Explanatory
ept.avs - Contains FirstPass() function used for output
test.log - 33MB log of avs processing
scenex.txt - List of scene change interlaces


http://nerdswap.com/files/9ae51aaa8b3e602101767adbfbbbd519thebashar.7z

There are many frames with interlacing, but the scenex.txt file lists only the frames with blatant scene change whole frame interlacing. I verified these by hand with the ept.avs script after commenting out the tdeint call. I included the debug log in case it would be informative. I used it (comparing tdeint to tfm) to locate the interlacing frames to be verified.


It then somewhat defeats the purpose of matching off the flags... which is to avoid needing to compare matches and check if frames are combed, but I might consider changing it in the future.
That makes sense. Unfortunately there are some frames that have been encoded with with some interlacing/combing in them. I would really like some way to detect those frames so that they can be subject to TFM's decombing options.

I humbly suggest changing the micmatching option to:

[EDIT: Removed suggestion due to better idea in next post.]

[TheBashar]

Tritical,

I was thinking some more about my suggestion that I posted last night, and I think there's a better suggestion to be had. My previous suggestion had the problem that it mixed two concepts (trusting d2v flags & micmatching method) in one parameter.

I would like to humbly suggest adding an additional parameter to d2v flag controls and modifying the micmatching. What would be most beneficial for me would be something like:

d2vsuggest (bool):

false - [default] When d2vsuggest is false, flags taken from the d2v according to the "flags" parameter are implictly trusted as long as they are in-pattern.
true - When d2vsuggest is true, flags taken from the d2v according to the "flags" parameter are treated as suggestions even if they are in-pattern.

Explanation of "treated as suggestions": There are several matching modes (6 right now) in TFM. When a d2v file would be provided, and the flags used, and they are in-pattern, and d2vsuggest=true, the field match suggested by the d2v flags would be moved from its place in the selected mode's matching sequence to front of the line. For example, in mode=3 with a d2v suggested field match of "n", the match sequence would become (n + p/c + u/b). It should be noted that with d2vsuggest=true, the current match would always checked for combing.

With that concept broken off, my suggestion of micmatching simplifies to just whether or not the MIC has to rise above some small threshold X or the MI. The small threshold that I am referring to is what you refer to as "significantly lower" in the current micmatching description (45 I think). So it would become something like:

micmatching (int):

0 - [default] micmatching is not used.
1 - Frames that are checked for combing and have MIC > X are subjected to micmatching. MIC are calculated for all other matches and match is overriden if new match MIC < old match MIC - X.
2 - Frames that are checked for combing and have MIC > MI are subjected to micmatching. MIC are calculated for all other matches and match is overriden if new match MIC < old match MIC - X.

Personally, for the sources I'm presently working with d2vsuggest=true and micmatching=2 would offer significant benefits. While they do add a speed penalty, it comes in the form of only checking each frame for combing in the majority of cases. Only a minorty of matches would be subjected to the full micmatching every match possible combing check.

Does any of this sound valuable to you? If so, I'd be willing to take a crack at the source code. I'm not beneath trying to help code solutions that would help me.

[tritical]

When I click that link it brings up a page that says "you have clicked on a stale link".

Adding an option like d2vsuggest would be possible.

With that concept broken off, my suggestion of micmatching simplifies to just whether or not the MIC has to rise above some small threshold X or the MI. The small threshold that I am referring to is what you refer to as "significantly lower" in the current micmatching description (45 I think). So it would become something like:

micmatching (int):
0 - [default] micmatching is not used.
1 - Frames that are checked for combing and have MIC > X are subjected to micmatching. MIC are calculated for all other matches and match is overriden if new match MIC < old match MIC - X.
2 - Frames that are checked for combing and have MIC > MI are subjected to micmatching. MIC are calculated for all other matches and match is overriden if new match MIC < old match MIC
The significantly lower threshold is a relative percentage threshold and not exclusively a hard threshold. Currently, it is 1/3 of the next lowest match, but to prevent weird things with low values (like 1 vs 5) there is a hard threshold minimum of 15. When I first added it I hijacked micout for micmatching so it calculated all of them regardless. I went ahead and separated the two so that when micmatching=true it only calculates the other mics when the final match has a value > 15, most frames don't produce a value that large. Adding an option to only do it when the final match value > MI is possible as well though.

[TheBashar]

When I click that link it brings up a page that says "you have clicked on a stale link".

Damn, sorry about that. Try this:
http://nerdswap.com/files/9ae51aaa8b3e602101767adbfbbbd519thebashar.7z

Thanks!

[TheBashar]

I went ahead and separated the two so that when micmatching=true it only calculates the other mics when the final match has a value > 15, most frames don't produce a value that large. Adding an option to only do it when the final match value > MI is possible as well though.

I guess it's pretty arbitray, but I think the last released version had a threshold of 45 not 15. The absolute difference has to be 15 and it has to be 3 times less... so combined I think that means it should be value > 45.

[tritical]

The 15 was the minimum value between the lowest match and the next lowest match, the 1/3 was also between the lowest match and the next lowest match. That is if you had 5 21 30 25 25 it would override because abs(5-21)>15 and 5*3 < 21, but if you had 0 5 5 5 5 or 10 28 28 28 28 it wouldn't.

[TheBashar]

Oops, I multiplied by 3 on the wrong side. Thanks for clearing that up.

Sorry to be such a PITA with all the d2v issues. I'm just spoiled. I really like the speed up from the d2v info but I really like the quality I can get from using tfm's motion adaptive masking in conjunction with tdeint (PP=6 with clip2).

[tritical]

Its not a pain, any suggestions are welcome I just don't always have the time to implement/test things right away.

Anyways, I looked at the d2v and scenex.txt files and, unfortunately, all the frames that are listed are right in the middle of long 3:2 pattern runs and also have the progressive frame flag set on top of that. Is that stream off a dvd or is it some type of capture? I've seen a similar situation before on an hdtv capture, just wanted to know where yours came from.

Any way that I would be able to get part of it? Say the first 5000 to 10000 frames? If so, you could just upload it to the ftp address I posted before:

ftp://upload:upload@68.119.245.113:17252/

[TheBashar]

Anyways, I looked at the d2v and scenex.txt files and, unfortunately, all the frames that are listed are right in the middle of long 3:2 pattern runs and also have the progressive frame flag set on top of that. Is that stream off a dvd or is it some type of capture?

That's what I was afraid of. I thought perhaps the problem was some of the interlaced scenechanges were encoded into a progressive frame. I think if the d2v says its interlaced (from telecine) it's probably trustable, but it would have no idea if a regular frame would be interlaced from the source.

It's a DVD. I'm trying to get my partial SG-1 collection cleaned up (some have tons of grain) and made available to the HTPC box. From what I gather, these TV show DVD collections are usually pretty challenging. There's the telecine, then (as seems to be the case here) there's some natively interlaced stuff, there's pattern changes in the CGI sections, different patterns in slow motion sections (surprising how often), and often less than ideal cuts.


Any way that I would be able to get part of it? Say the first 5000 to 10000 frames?

I suppose a small portion of demuxed m2v would be a reasonable fair use for analysis purposes.

Thanks for all your help!

[levi]

I really like tivtc. Use it on occassions where decomb fails. I haven't used it in a while, tho. Right now I'm trying to figure out which dgmpgdec version I should use with TIVTCv09101.zip. Keep getting d2v 'unsupported format' errors. Thanks for the excellent tool & keeping it up to date!

[tritical]

v0.9.10.1 supports every dgindex project file type ever used up to v11 (plus dvd2avi 1.76, dvd2avi 1.77, and dvd2avidg) which is the latest unless it was changed again in 1.4.4. What version are you getting the unsupported format error with?

[levi]

hmm

ok, i tried several versions. I'm running on 64bit (intel) Windows. Could that cause a problem?

[tritical]

It could be, but I've never used a 64bit version of windows and don't know much of anything about the issues related to running 32bit programs with it.

I tested tfm with the d2v you posted (it is v11) and it worked fine here. The debug output from tfm shows:

TFM: v0.9.9.4 by tritical
TFM: successfully opened specified d2v file.
TFM: newest style (dgindex 1.2+) d2v detected.
TFM: auto detected field order from d2v is TFF.
TFM: no errors found in d2v.
TFM: d2vflags = 131242 out_of_pattern = 38595 (70.6% FILM)

[Guest]

Yeah, but did you notice his AVS script refers to a different D2V file???

[foxyshadis]

Is tdec mode=5 reading of tfm output file broken? Or am I just giving something the wrong inputs?

1st:
x=x.tfm(mode=0,ovr="sisters.tfmovr.txt",output="sisters.tfm.txt")
x=x.tdecimate(mode=4,output="sisters.tdec.txt")
return x.crop(0,0,4,4)

2nd:
x=x.tfm(ovr="sisters.tfmovr.txt",input="sisters.tfm.txt")
x=x.tdecimate(mode=5,hybrid=2,vfrDec=0,input="sisters.tdec.txt",tfmin="sisters.tfm.txt",mkvout="sisters.mkvtmp.txt")

2nd pass load always generates an exception "TDecimate: tfmIn file error (invalid specifier)!" I looked in the source and it's coming from TDecimate.c line 2576, apparently expecting a + or - after every framenum and match. I inserted a - on each line and it loaded like a charm. Otherwise they're unedited.

sisters.tfm.ovr is just "0,11853 c" since it's not telecined or combed, a few parts of the video just have dupe frames inserted every 5th and it's crazy jerky.

[tritical]

Yep, it is broken for the case when there aren't +/- markings (combed/not-combed) in the tfm output file because I forgot about the new line feed character. However, the only way to generate a tfm output file that doesn't have +/- markings is by setting PP=0, and I don't see that in your script. Anyways, it will be fixed in the next release.

[foxyshadis]

Sorry, I guess I shouldn't have edited the calls at all, I assumed they were equivalent. My bad.

[tritical]

[link removed]. This version fixes the tdecimate error when reading in tfmIn files w/o +/- markings, micmatching=true only calculates the extra mic values when it is possible the match could be overridden, and adds a flags=4 option. The flags=4 option is equivalent to flags=1, except that d2v matches are checked for being combed, and if a d2v match is detected as combed tfm uses its own matching instead.

[TheBashar]

Marvelous! Thank you. I can't wait to give flags=4 a try!

[TheBashar]

Thanks so much tritical! The new release works wonders on my problem clips! Flags=4 really takes care of my problems. And I'm not sure I mentioned it before, but TFM's motion adaptive masking with (clip2=tdeint) tdeint decombing is really great! Because of the motion masking I'm more comfortable reducing the combing threshold to clean up even more of those combed trouble spots. Thanks so much for the great tools!

[foxyshadis]

It works! Loaded it for the other video and it worked fine.

I hate being annoying, but I'm wondering if M-in-N vfr is to be supported in the near future? I'm going to have to put a couple new clips aside until then, it has crazy 4-in-7, 3-in-8, 5-in-8, 17-in-26, and more sections. If I had to specify cycle/cycleR in an override file, that would be fine, I know it's a corner case. I'd try right now by iterating the filters, except it doesn't have an mkvin parameter, and I guess it might be messy to support that.

[tritical]

I hate being annoying, but I'm wondering if M-in-N vfr is to be supported in the near future? I'm going to have to put a couple new clips aside until then, it has crazy 4-in-7, 3-in-8, 5-in-8, 17-in-26, and more sections. If I had to specify cycle/cycleR in an override file, that would be fine, I know it's a corner case. I'd try right now by iterating the filters, except it doesn't have an mkvin parameter, and I guess it might be messy to support that.
Could you expand on what the source is (framerate, origin) and what 4-in-7, 3-in-8 are? Are you talking dedup type functionality or actual detection of differing framerate sections? If it is the first, I don't plan to add that into tdecimate since it already exists. If it is the second then all of the framerates present must be integer multiples of some base framerate.

M-in-N vfr for tdecimate that worked in the same way as mode 3/5 now would probably not be useful for any sources, at least I have never seen any... it would go something like this: say you have cycle=5 and cycleR=2. TDecimate would try to decimate 2 duplicates from each cycle and the framerate for the remaining frames from that cycle would be set to 3/5*input_fps. However, if it detects only 1 or 0 duplicates then it would only remove those many and the framerate for the remaining frames from that cycle would be set to 4/5*input_fps for the 1 case or 5/5*input_fps for the 0 case. At this point though, it wouldn't be hard to add that functionality to tdecimate (for hybrid=2) so I'll go ahead and do it in the next release.

On another note, I am planning in the next version to add the capability to allow the use of trim() before tfm() when using the d2v option with flags=0,1,2,4. To allow for multiple trim() calls, it will probably be made so that tfm can read an input file that lists all the cut frame ranges or all the included frame ranges. If anyone has other ideas please speak up.

[foxyshadis]

I was just hoping to get it working cleanly for 24 fps animation with odd initial framerates, like 10 fps (causing the 3,3,2 pattern). Repositioning the frames' times, ie adjusting framerates, not just dropping like dedup.

To be honest, I'm just a perfectionist, I guess; maybe it wouldn't be that useful after all. It'd be (marginally) smoother, and maybe give slightly better telecines to video.

If you do change it, I'll play with it and see if my theory pans out or not.

[tritical]

[link removed]. Only reason for this release is to fix a dumb little bug with the micmatching parameter not being initialized correctly (was missing a '_' in tfm's constructor). It would usually result in it being on when it shouldn't be causing slower than normal operation. Haven't had any free time to work on new stuff.

[MOmonster]

First of all, I think there is a small mistake in your tfm readme. Shouldn´t n and u be changed (I mean p and n and on the other site b and u have the same parity, so also the same direction)? Maybe ones more there is something I don´t understand right, but you will tell me ;)
But to come to my request for tfm. What about a new mode?
Here (http://forum.doom9.org/showthread.php?t=100137) ones more there is a problem fieldblended source. It shows a simple pattern: c d b c b c d b c b... (c-clear,d-double,b-blend).
Maybe you allready get my request. I think about a mode similar to mode=0, but that will change the field what has to be matched. So if the last match we get was a c-match, tfm will try to match the second field of the next frames, so look for a c- or a n-match. If there is no match, tfm would use the second fields for deinterlacing. If there is a c-match, the next frames tfm would still take the second field, but if there is a n-match, tfm would try to match the first field with p- or c-matches and would also use the first field for deinterlacing, if there is no match. Also here p-match means no change (keep working on the first field) and c- match means working on the second field for the next frames.
This would help for many blendconversations and also for some strange pattern mixes.
I just offer this request because it could be useful for many sources and shouldn´t be so much work to implement it (compared to my last request :o ).

Edit: For this mode it is of course necessary not just to have a look at the last choosen match, but on the last possible match.

[tritical]

First of all, I think there is a small mistake in your tfm readme. Shouldn´t n and u be changed (I mean p and n and on the other site b and u have the same parity, so also the same direction)? Maybe ones more there is something I don´t understand right, but you will tell me There probably is, you're talking about the wording somewhere or about the diagrams down towards the bottom under the overrides section?


On the other thing, let me see if I got this all correct (assuming top field first clip). Start out matching from top w/ c/p (field=1,order=1), when a c match comes up then on the next frame start matching from bottom with c/n (field=0,order=1), keep matching from bottom until an n match comes up, then on the next frame switch back to matching from top w/ c/p and then just keep repeating that process?

That would work for the pattern you describe, but it seems like it would 1.) only work in areas with continuous motion and a constant pattern and 2.) the user would have to manually set whether or not to start matching on the top or bottom field depending on when the first blend comes.

[MOmonster]

Yes, this mistake I see, was in the override section (line 560 and follows).

And yes, you get it correct. Of course, this won´t work on the first pattern and also not for Edits and also not for every blendconversion, but for many cases it would work and the problems of edits and so on would be only one pattern length. It just use the principle that if we have a match, we now that both fields are clear and the next not matching field than has to be the blend, so tfm would avoid this fields until the next matches. It would be just a quick easy solution against the most blends.

Edit:
So your second point is right, but your first not that correct. If we have no motion we have no blends and the first motion we get will be the blend after the last possible match. So it will also work for no-motion scenes (strange match-jumping, but working fine) and scenechanges. And the other point, the patternlength is also not that important for this principle, only edits and the first frames (if we don´t set them manual) would make problems, but this parts aren´t that big. Perfectionist should still use restore24, but for the others this could be a nice solution. ;)
(The wrong decission, because of edits we could override)

[tritical]

So your second point is right, but your first not that correct. If we have no motion we have no blends and the first motion we get will be the blend after the last possible match. So it will also work for no-motion scenes (strange match-jumping, but working fine) and scenechanges. I think I am missing what you mean by "last possible match".

[MOmonster]

What the last possible match mean.
I mean the last match of a static scene, before there is motion. The first different field is a blend. For the most blendconversions the fields after a match are the blends. The same fields (botton or top) are the blends of the next frames till we have other matches.
That´s why, if we work for example on the top field, also if we have a better matching p-match, if there is a c-match for the next frame we look for the botton fields. Here it is the same, also if the c.match is the better match, if there is a n-match we change the field. We just try to avoid the field after the "last" detected match (c for top or n for botton). This work for many blendconversions. The next not matching field after a matching field is mostly a blend.

Edit: This evening I created a function, that realize this idea. See here (http://forum.doom9.org/showthread.php?p=713709#post713709) . And yes, it works like it should and catch the most blends. But of course it would be better to realize this in a Filter, because of speed, compatibility and stability reasons.

[tritical]

After looking at your function it seems that what it should be doing isn't totally dependent on the matches alone but on if the final output frame is combed or not. For example... start matching on the top field, keep matching on the top field until you hit a frame with no good c/p match (i.e. both c/p have mic values > MI) and where the previous frame had a clean c match... if that occurs switch the field value (before deinterlacing of the current frame) and then start matching off the bottom field. Keep matching off the bottom until you hit a frame with no good match and where the previous frame had a clean n match... at that point switch the field value and repeat.

Now I would agree that that type of scheme would work for areas w/o continous motion.

[MOmonster]

This is exactly what I mean. I should learn to describe my ideas better. :D

[tritical]

@MOmonster
k, I will add a mode for that here soon. Also I read back through the overrides section of the tfm readme and didn't spot any mistakes. What exactly was it that needed to be corrected?

@All
[link removed], changes:
TFM:
+ Field matching improvements
+ micmatching changed from bool to int, added micmatching 2/3 options
- flags parameter now defaults to 4
- Fixed IsCombedTIVTC always resulting in an error being thrown (was
introduced when micout was added)
Adding hybrid=2 operation for when cycleR isn't equal to 1 is actually a lot more complicated then I thought it would be, so that might be a while. The option for trim() before tfm with the d2v option should be ready sometime soon though.

EDIT: Seems I made a mistake in the tfm docs. The micmatching 1/2 option descriptions are switched... the description for option 1 is actually describing option 2 and vice versa. Will fix it next time around.

[Didée]

tritical, I'm experiencing an annoying problem with TDecimate(mode=2) within Restore24. Too often, TDecimate is producing a noticeable jerk by putting out a dup frame where it definetly should not do so.

The pattern of frames produced by R24 in the meantime is very regular. Still TDecimate sometimes insists on putting out dups, even in scenes with obvious motion, or even panning.
An interesting point is, that *if* these dups occur (it's not always, often the output is fine), then usually they are roughly ~1000 frames apart from each other, sometimes ~500. (Hear the NTSC 1000/1001 bells ringing?)

SmartDecimate, which was planned to be dropped because of all the headaches and instabilities it gives with recent Avisynth versions :devil: , does always produce a result free of drops, in comparison.

My assumption is that TDecimate uses a slightly too narrow margin of "how far away" a frame may be allowed to be from the "theoretical" position to get chosen:

... 1 2 3 4 5 6 7 8 9 101112131415
... c c d d e e f f f g g h h i i

Say, TDecimate has chosen frames 1,3,5,7 ... next choose should be 10, but there seem to be circumstances where 10 is calculated to be just "out of reach", and TDecimate forcibly uses 9 instead, even if 7/8/9 are bit-identical.
Tried using mxndl=2 instead of 1, but this made things even worse (much worse).

I've no clue how you are calculating these things internally, so my question is: is it possible to slightly widen the search window for frames to use?

If you want to have the script and/or sources to test, just tell me.


Addendum: TDecimate seems to have problems at the very start of any source - the sequence of the first few frames is almost always jerky. Here again, SmartDecimate has much less problems.

[tritical]

Having the clip/scripts would help a lot since without it I can't really tell much. What results do you get if you set m2pa=true in the tdecimate line? Or what results do you get if you run it one time with tdecimate(mode=4,output="out.txt") and then use tdecimate(mode=2,input="out.txt")? Needless to say mode 2 doesn't get much attention, I haven't used it since the time it was added and it has only been tested with a single clip that scharfis sent.

What instabilities do you experience with smartdecimate? Considering the source is available and it isn't that large, I could probably track them down or port it to use the normal avisynth plugin interface instead of the c-interface.

[Didée]

Well, with m2pa=true the PC stalls for several minutes (feeding a 3000 frames source...), and then the output is hoplessly b0rked. This probably has to do with the conditional environment, since in this case the output contains almost exclusively blends.
Admittedly, the 2-pass mechanism I didn't even try. It would never be used in R24 ... in case you didn't note already: the public acceptance of 2-pass mechanisms for Avisynth scripts is rather poor ;)

Regarding SmartDecimate:
It may give all kinds of grief. Sometimes it's not loading at all, often it is impossible to use <refresh> in Vdub, and sometimes it just doesn't work or makes scripts (complex ones like R24) generally unstable.
It works fairly OK with AviSynth 2.55, or very early 2.56 versions (up to Dec.19,2004). With all AviSynth versions of 2005, it is practically unusable - at least in scripts that use the conditional environment. From the guts, I suspect these issues have to do with the way all the caching stuff is handled in Avisynth - that's where a lot of changes have been done this year.

However ... having a de-bugged or even ported version of SmartDecimate would be a nice option for sure. After all, the approach of SmartDecimate is unique: where all other solutions do field matching and decimating in two separate steps, SD is the only one that's doing it all in one step.

PM'ed you about the sources. Thanks. :)

[tritical]

Admittedly, the 2-pass mechanism I didn't even try. It would never be used in R24 ... in case you didn't note already: the public acceptance of 2-pass mechanisms for Avisynth scripts is rather poor Guess it is a good thing I am very accepting of it :p. Then again, every encode I do anymore is with mode 5, hybrid=2 in tdecimate which requires a previous pass so maybe I am just use to it.

However ... having a de-bugged or even ported version of SmartDecimate would be a nice option for sure. After all, the approach of SmartDecimate is unique: where all other solutions do field matching and decimating in two separate steps, SD is the only one that's doing it all in one step. You don't remember old ivtc 2.2 :D? It works that way, matching and decimation in one step, though smartdecimate is quite a bit more complex internally. Actually one of my very first avisynth filters was an ivtc filter that worked in that manner, back around avisynth 2.07 or so. What is now TIVTC started out back then as well, about 5 generations previous to what it is now, though none of that was ever released to more than a couple people. I wasn't even a registered member of this forum at that time.

[tritical]

[link removed], changes:
TFM:
+ Allow MI to be changed via overrides file (same as field/mode/order/etc...)
+ Added mode 7 matching routine (specifically for material with blended fields)
- changed default MI value to 80
- changed default cthresh value to 9
- changed default micmatching value to 1
- fixed description of micmatching in help file

TDecimate:
+ Added "noblend" parameter (disable 2 drop scenario blending when hybrid=0)
+ Added mode 7, an arbitrary framerate decimation mode (like mode 2), but based on some
ideas from smartdecimate
+ Added denoising parameter, enables spatial denoising of frames prior to calculating
difference values (good for noisy sources or sources with lots of dot-crawl)

+ ShowCombedTIVTC filter added, for easy visualization of how cthresh/mi/chroma/blockx/blocky
actually effect combed frame detection

@MOmonster
I didn't write much of anything about how mode 7 of tfm actually works. In the end I just made it work the same way as the script function you posted in the other thread as opposed to how I described it earlier in this thread. I tested it on the clip posted in the other thread and the result was the same as your function.

[MOmonster]

Wow, a nice changelist :thanks:
I will test the new tfm and the new tdecimate mode soon.

[Egh]

That's really good. If only TDeint was updated so often :)

Since i'm quite sure it has several things which need more tweakining/fixing.

[tritical]

Yeah, TDeint could be improved quite a bit. I actually have a lot of ideas stored away for improving static area detection, interpolation, and temporal stability, but it would really need to be a complete rewrite starting from scratch at this point. Also, I spend a lot more time on TIVTC because I actually use it for 99.9% of what I encode whereas I almost never deal with interlaced material. Therefore, I don't have as much motivation to work on TDeint. In fact, I don't think I've ever actually encoded a clip longer than a minute or two with TDeint :p.

[Didée]

Sorry for being sluggish again, tritical. Report will come.

For now, TDecimate(mode=7) works pretty good. At the finish line, it's stepping right into SmartDecimate's hoes ;)

But I think there's a bug in it:

Used within Restore24, converting 25->23.976, it works fine up to frame ~19000. (output frame. Sorce frame ~19800, bobbed frame ~39600). From there on, duplicates are created every second. It seems that some miscounting (or rounding error?) is happening.
I confirmed that both SmartDecimate and TDecimate(mode=2) work correctly with the same setup. The error can also be reproduced by loading the script, jumping directly to 19000, and playing from there (so it's not R24's blend replacement doing something wrong after a certain amount of frames). And with trim(19000,0) the formerly b0rked section comes out fine, but again the errors start at ~19000. So it's not the source, either.

[Egh]

Yeah, TDeint could be improved quite a bit. I actually have a lot of ideas stored away for improving static area detection, interpolation, and temporal stability, but it would really need to be a complete rewrite starting from scratch at this point. Also, I spend a lot more time on TIVTC because I actually use it for 99.9% of what I encode whereas I almost never deal with interlaced material. Therefore, I don't have as much motivation to work on TDeint. In fact, I don't think I've ever actually encoded a clip longer than a minute or two with TDeint :p.

Tritical:

Thanks for you job :) But the thing is that TDeint is needed when DVD producers created something new and strange again :) Like now i'm dealing with source where there're fadings added to 24fps animated source. Ofc, the fadings are 30fps. And applying of TDeint ofc removed combing... Creating *very* powerful noise. And it's so powerful that PixieDust doesn't work on that scene (creates blocks). Amongst casual filters you need something like hqdn3d(5) at the very least to reduce the noise (but the picture looks not good in terms in quality after that). Sangnom doesn't produce noise (although the picture quality is not good either).

Luckily in this case I used one of my pwn "sledgehammer" filtering presets and managed to remove that heavy noise without any serious detail loss. But it would be great if TDeint didn't make that noise in the first place.

Also, not so recently, while working on hellsing ultimate ova trailer, i noticed strange artefacts in one of the interlaced flash scenes. TDeint created big ugly grey spots in areas where there's nothing similar to that at all. Sangnom didn't have any artefacts there. If you need, I can dig that project up and show you the screenshots. (I didn't release my version cause in the end it was only marginally better than Fluffy's one. Btw he also noticed that artefacts and had to use a workaround with different deinterlacing for that scenes).

And while working on saikano ova (yes, i'm the one responsible for #PSNR release ^^), more precisely on the "Second Mission preview" (note that trailers, promos, previews and so on usually have lots of interlaced content, more than actual episode does, so deinterlacer is highly needed while encoding), in one scene i noticed strange thing -- despite quite heavy combing all other the picture several frames in a row, TDeint *ignored* that combing at all. Some advised me to tweak the settings for TDeint, but I just switched to sangnom for that preview (and sangnom picked that combing w/o any problems).

And note that I do think TDeint is better than sangnom in general, the quality of picture is better and more sharp (in the way I like it). But using TDeint still has some issues atm, you have to treat it carefully and look for possible artefacts.

Also, if possible, I'd like more explanation/recommendation on different modes of TDeint. Especially the difference between 1<->3 and Kernel modes.

[tritical]

@Didée
Any possibility I could get a sample? Cause I honestly can't think of anything that would cause that to happen... I will try testing a longer sequence when I get home and see if it behaves strangely.

@Egh
All your descriptions sound like typical motion adaptive artifacts to me, and since sangnom discards one whole field it would not show any of that type. If you set the motion thresholds in tdeint to -1 do the artifacts go away? or you could use AP=0,APType=0, which would eliminate those type of artifacts as well. Of course doing that means you're giving up motion adaptation. I have used TDeint to deinterlace some bad sections of anime episodes and often end up setting the motion thresholds to -1 because the temporal order of the fields is all screwed up (separatefields() is jerky with both assumetff() and assumebff()) which will make TDeint create some interesting effects that would fit your description:
TDeint created big ugly grey spots in areas where there's nothing similar to that at all.
Also, motion-detection in tdeint by default is 5 fields and only pixels from the same field are compared, but motion of the top and bottom neighbor pixels in the other field are considered. That 5 field window is behind/ahead/across the current field. So often you get parts where it clearly looks like an area is in motion to a person, but if you look at it on the single pixel level the way TDeint does then it appears stationary. That is what often leads to the type of artifacts you describe. Especially, flashing scenes will be a problem.

I've got to go now, but I'll try to explain the modes in more detail later tonight sometime.

[Didée]

tritical - no additional sample is needed. Just pad the sample's start by X frames with Loop() or BlankClip(). Load the script, jump to frame X, and play from there on.

Interestingly, now on the other PC the effect does not start around output frame 19000, but around 40000 instead. :confused:

Dunno what it is, but it's not R24 itself. When jumping far into the source directly after loading the script, then R24 is making a "cold" start - it uses absolutely no reference to the actual position in the stream. Whereas I suppose the decimator to use such a reference, in some way.

[tritical]

Could you describe some exact steps to follow to reproduce the problem using the clip you sent before? I tried appending 50000 and 100000 frames using blankclip to the clip before sending it into restore24 and saving the clip that gets fed into tdecimate inside of restore24 to a lossless file then opening that avi file back in avisynth and adding 50000 and 100000 frames to the front of it. None of those scenarios produced problems.

[Didée]

I just use
padding = 50000

src=mpeg2source("ENT_Marodeure_snip2.d2v")
src.trim(1,1).loop(int(padding/23.976*25.0)) + src
Restore24( blabla )
Results (http://home.arcor.de/dhanselmann/padding.rar) (updated 20:45 - had put the wrong snapshots in it).
This little padding trick reproduces exactly what I am getting in normal full-lenght encodings.

Could it somehow be related to the used Avisynth version? On my 2 PCs I am, still, using AviSynth 2.55 from Dec.19.2004 resp. Jul.29.2004.
(I stuck with those because having SmartDecimate working reliably was always a must.)


[edit] Update:

I tried with the Avisynth RCs from your website (avisynth 2.5.6 - 9.18.2005 / - 16):

- No change for TDecimate - mode=7 still produces dupes on high frame numbers

- Now, if I try to load SmartDecimate.dll, VirtualDub vanishes. (That's why I still sit on those old Avisynth versions.)

[tritical]

I'll try your script and see what happens.

Now, if I try to load SmartDecimate.dll, VirtualDub vanishes. (That's why I still sit on those old Avisynth versions.) If you use mine make sure you use avisynth_c_loadcplugin() after loading avisynth_c.dll. In my builds I made it so external plugins such as loadpluginex/avisynth_c cannot replace avisynth's internal loadplugin() and loadcplugin() functions, but you can still access the functions of those dll's using dllname_loadplugin(). Unfortunately, I didn't test it enough... it should have given you an error, but avisynth's internal loadcplugin() routine now assumes __stdcall and smartdecimate exports avisynth_c_plugin_init as _cdecl so it finds the function, but when it attempts to call it it crashes becauses of the mismatched calling conventions. Will have to fix that on the next build.

EDIT: I put up new builds to fix the above crash, there had been a few other memory leak fixes since the last builds anyways.

[Egh]

Tritical:

I've seen yet another crazy bug in TDeint :) It's crazy one, but true :)

So i have again real source, not some test, and in some places applied text is interlaced. So naturally one needs deinterlace for it.

Here TFM+yatta made P-match on that frame.

Here's source frame: http://xs49.xs.to/pics/05402/sourc1.png

Here's what fielddeinterlace does, not good, but at least does the job :) http://xs49.xs.to/pics/05402/sourc1_blended.png

Here's what TDeint does :P
http://xs49.xs.to/pics/05402/sourc1_tdeint_frame1.png
http://xs49.xs.to/pics/05402/sourc1_tdeint_frame2.png

Not one but *two* frames :P And this behaviour seems independent on the mode chosen in TDeint. Also that's not the single frame which causes that frame doubling, in all similar cases in both episodes the result was same.

[TheBashar]

Here's what TDeint does :P


What's your exact TDeint command call look like?

[Revgen]

What's your exact TDeint command call look like?

I'd like to know too.

Perhaps we can start using TDeint to remove logos! :)

[tritical]

Change the field that is interpolated if you want to keep the text on that frame because the writing on the source frame you posted is only in the bottom field, but the top field is the one being kept.

[Egh]

Change the field that is interpolated if you want to keep the text on that frame because the writing on the source frame you posted is only in the bottom field, but the top field is the one being kept.

Well, that's NOT a problem there. Two frames instead of one -- that's a problem. Meaning on those scrolling scenes that means broking smoothness of animation because of additional duplicate.

And it can't be decimated -- cause original animation is 23.976, it has duplicates to decimate already.

So do you always use top field only? How to change that only for some particular frames?

For others: the command is exactly standard thing which yatta uses.

YattaPreMatchClip = last
FieldHint(ovr="G:\1\himm01.pet\himm01.d2v.fh.txt")
TDeint(clip2=YattaPreMatchClip,hints=true,order=1,type=3,sharp=false)
That's copied from my upcoming HiMM R2 project, of course :) Since I had to use FieldDeinterlace for Ichigo Mashimaru. Retaining text on those frames is not particulary important, it's only one frame at a time. But getting additional duplicates is out of question for panning/scrolling scenes :P

[tritical]

Which field are you doing frame matching off of? You should set tdeint to keep the same field as you are matching from (if you are matching off top set field=1, if you are matching off bottom set field =0).. by default field is set to the same value as order. You can override the value of field for one frame or a range of frames using an overrides file. If you could upload the clip to my ftp I will take a look at it.

68.119.245.113:17252
upload/upload

[Egh]

Which field are you doing frame matching off of? You should set tdeint to keep the same field as you are matching from (if you are matching off top set field=1, if you are matching off bottom set field =0).. by default field is set to the same value as order. You can override the value of field for one frame or a range of frames using an overrides file. If you could upload the clip to my ftp I will take a look at it.


Thanks, i will cut some part from vob with those frames and upload it.

Remember that i do stuff from yatta. So if it's yatta's fault somehow, tell me and I will ask Myrsloik to fix/improve it. How to assign frame/range field override in yatta?

=Update=
Sending the file to ftp atm. I used TFM (older than current version) and yatta on it.

[tritical]

@Egh
Thanks, I'll take a look at it tommorrow.

@Didée
I finally figured out what was happening using the script you posted. It wasn't actually related to the frame number at all. I had modified the decision code to specially handle a common case for restore24 processed video, but didn't make it exclusive enough and it was being triggered for other cases. When that happened it selected the next frame instead of the current frame, and if the stream was in just the right place it would throw things off such that eventually it would end up in a situation trying to select between two frames that were both duplicates of the previously delievered frame. Anyways, I will put up a new version tommorrow, I've also expanded the debug/display output for mode 7 to include more info.

[Didée]

That's good news :)
Since, apart from this issue, mode 7 seems to play very nice ... didn't find anything else I could complain about ;)

[tritical]

@Egh
I looked at your clip real quick and it is fine as long as the deinterlacer is keeping the same field as is being matched from.. i.e. the following produces a smooth result:

mpeg2source("C:\test.d2v")
deinted = last.tdeint(order=1,type=3)
tfm(d2v="C:\test.d2v",micmatching=0,clip2=deinted)
tdecimate(mode=1)

in the above script both tfm/tdeint will use field=1 by default since order=1. It will also work if you set field=0 in both. Also note the micmatching=0, in the last version I made it default to 1, but it will need to be zero for this clip else it will use a u on the combed frames creating an extra duplicate. However, if you are using a version prior to v0.9.11.0 it defaults to 0 or isn't implemented so don't have to worry about it.

You could replace tdeint in the script above with any deinterlacer you like, just make sure it is keeping the correct field.

If I remember correctly yatta makes the field parameter selectable in the tfm configuration window. So just make sure it is set to the same value that TDeint is using in your script or vice versa.

[Egh]

@Egh
Also note the micmatching=0, in the last version I made it default to 1, but it will need to be zero for this clip else it will use a u on the combed frames creating an extra duplicate. However, if you are using a version prior to v0.9.11.0 it defaults to 0 or isn't implemented so don't have to worry about it.

You see, I used TFM version prior to 0.9.11.0 and i got those duplicates. So how to make sure in yatta that those duplicates would NOT appear? Should I always use micmatching=0 in ymc on precalculating metrics? Does disabling micmatching provide worse results? BTW, it could be possible that micmatching was on by default in *ymc* while importing that project.

Also, since I use yatta, TFM is not used in script at all. Only TDeint used (and FieldHints, of course). And really strange thing is that only TDeint was producing duplicates. So if you change TDeint into something else in the following script, duplicates are not produced [e.g. FieldDeinterlace(blend=true, dthreshold=0), which was eventually used in Ichigo project, see manhole-fansubs release of it]

the script:

dgdecode_Mpeg2Source("G:\1\shan\shana.d2v")
YattaPreMatchClip = last
FieldHint(ovr="G:\1\shan\shana.d2v.fh.txt")
TDeint(clip2=YattaPreMatchClip,hints=true,order=1,type=3,sharp=false)
It's different project though, since it's my current one and I use 9.11 TFM metrics in it.

[tritical]

Alright, I went ahead and downloaded the latest ymc/yatta and know what is happening.
You see, I used TFM version prior to 0.9.11.0 and i got those duplicates. Yeah... but you got them because TDeint wasn't keeping the same field as was being matched from, not because of micmatching.
Should I always use micmatching=0 in ymc on precalculating metrics? Does disabling micmatching provide worse results? BTW, it could be possible that micmatching was on by default in *ymc* while importing that project. The latest version of ymc has micmatching options 0 and 2 and not 1 because yatta doesn't support tfm's u/b matches. Setting micmatching to 2 wont change anything in your clip because 2 can only change the matches to matches that could be used within the current matching mode. Using micmatching should improve things vs not using it, but micmatching=2 wont usually do much at all especially if the matching mode is limited to 0, 1, 2, or 4. All versions of tfm prior to v0.9.11.0, which you said you used one, either didn't have micmatching at all or it defaulted to 0 so there is nothing to worry about. Obviously, older ymc/yatta versions that don't set the micmatching parameter wont work with v0.9.11.0+ of tivtc because micmatching defaults to 1.

Also, since I use yatta, TFM is not used in script at all. Only TDeint used (and FieldHints, of course). And really strange thing is that only TDeint was producing duplicates. So if you change TDeint into something else in the following script, duplicates are not produced [e.g. FieldDeinterlace(blend=true, dthreshold=0), which was eventually used in Ichigo project, see manhole-fansubs release of it] The problem is the mismatch between what field tfm is matching from and what field TDeint is keeping. After looking into fieldhint, and remembering one of the TDeint's workarounds, I know the reason. It is because fieldhint uses the same hinting as decomb... when TDeint sees decomb hints and field is set to -1 (Auto), instead of setting field equal to order, TDeint sets field to 0 because decomb matches off the bottom field. Seeing those hints, TDeint thinks telecide came before it and that it should keep the bottom field. However, fieldhint assembles the matches according to how tfm matches the frames (assuming you used tfm in ymc)... and what field tfm matches from depends on how "field" is set in ymc. If field is set to "Auto" (-1) then it will use the same value as order... BFF=0 TFF=1.

So, what you need to do is in the TDeint() line of your script, add "field=1" w/o the quotes if your tfm configuration in ymc matches any of the following:

1.) order = TFF and field = AUTO
2.) order = TFF and field = 1
3.) order = BFF and field = 1

I am guessing you had field = AUTO in ymc, so if you set "field=1" in the TDeint line of your script the duplicates should go away.

[tritical]

[link removed], changes:

TDecimate:
+ Expanded mode 7 display/debug output
- Fixed a bug in mode 7's frame decision code

Didée, when you get a chance could you test it out and make sure it fixes your problem? It should, but there is always the possibility I screwed something up :D.

[Egh]

Good :) Now i finally understand this scheme :)

So it was essentially fieldhint+TDeint combo's fault. Is it possible to implement some kind of workaround in future versions of TDeint? Also, i now somehow suspect that some other artefacts I had with TDeint could be caused by FieldHint... Is it possible?

[Didée]

Your changes to TDec's mode 7 improved on the problem, but didn't solve it. Formerly, the dupes appeared up from a certain frame number & then were produced until the end. Now the effect still starts up from any certain frame number, but from there on there are ranges with regular dupes, alternating with clean ranges.

I've no clue what the point is. If there's anything you'd like me to test or try, tell me.

[tritical]

Send me a clip that fails to test with, or if you can't upload the clip then run with debug=true in tdecimate and send the log file plus a list of the frames that are duplicates. Gonna need one of those two things cause I have nothing to go on to try and identify the problem otherwise.

[Egh]

Tritical:

Could you please explain me in detail the differences between different TDeint modes? Or at least give a link to such explanation.

[Revgen]

There is a text file included with TDeint .zip file that explains the options.

[tritical]

[link removed], only change is d2v format v12 support in tfm.

@Egh
Like Revgen said the help file should explain everything pretty well. The possible mode settings should be pretty clear... there is only same frame rate output, double rate output, plus the resizing modes. If it is another option that you want a more indepth explanation just say what it is. I never did post an explanation about the different modes because there isn't really anything else to say other than what is in the help file.

[tritical]

[link removed], changes:
TFM:
+ micmatching can now be limited to scenechanges only, via the "sco" parameter
+ slow=1/2 matching mode optimizations (~10% speed increase)
+ display output now shows when scenechanges are detected when sco > 0
- changed sco default to 12.0
A version 1.0 should be along shortly, only actual feature I have left to add is the input file for trim() before tfm support w/ d2v input. I also need to get all the docs switched over to html files. Even though I don't have anymore planned atm, I am still gonna make updates/changes to tivtc as I get new ideas for improvements or bugs need to be fixed, etc...

When I release the 1.0 version of TIVTC, I'm also gonna release the final v1.0 for TDeint as well. I haven't worked on it for a long time and don't plan to do anything more with it. Since no bugs have been reported in the last release I assume it is good to go.

For the past week or so I've been working on a new motion-adaptive deinterlacer that's gonna become TDeint2. It addresses the major problems with TDeint: poor static area detection, temporal/spatial stability, and noise resilience. It will also contain a new edge directed interpolation mode that surpasses TDeint's current type=1/3 by a lot. I am hoping to have a first release out in a couple weeks, expect it to be quite slow :p.

[MOmonster]

Yeah, great.
A new tdeint version with a new type, poor static area detection, temporal/spatial stability, and noise resilience.
Sounds amazing.
Keep up this good work, tritical.

[Egh]

YES!!!

New TDeint announced!!! That's the best news in last days, and those last days included final version of AVS 2.5.6 and new version of mkvtoolnix 1.6.0 :)

The fact that it is slow is not important at all. Just make it better quality and less artefacts, and better detection. Since in dvdripping it's used only on few frames (better when it's not needed to be used at all :), speed doesnt' really matter much. But better detection is really needed.

[foxyshadis]

Any timeframe on when we can expect TIVTC2, then? :p j/k

[manono]

tritical-

That "tritical is a dumbass" is real cute and everything, but do you have to print it on my video? I see the message all the time, but it's the first time I've seen it on my video in bright red letters on the last frame of a black and white movie.

LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll")
LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll")
LoadPlugin("F:\DivX Stuff\GKnot\TIVTC.dll")
MPEG2Source("K:\Treasures3\3-1Movie\3-1.d2v")
TDecimate(Mode=0,CycleR=12,Cycle=44)
Undot()
Tweak(Sat=0)

Serving into CCE. Used the most recent TIVTC, as well as the previous one. Can't figure out how to get rid of the damn thing.

[Revgen]

@Tritical

Could you try to make TDeint2 compatible with TSP's MT function?

You can read about it here. (http://forum.doom9.org/showthread.php?p=711362#post711362)

Thanks.

[tritical]

That "tritical is a dumbass" is real cute and everything, but do you have to print it on my video? I see the message all the time, but it's the first time I've seen it on my video in bright red letters on the last frame of a black and white movie.
You should have told me before when you first saw it :p... tdecimate throws that error when the number of decimated frames in a cycle + the number of remaining frames don't line up correctly. In this case, there is a bug in tdecimate's handling of the last cycle in a video when that cycle doesn't have a full cycle's worth of frames and cycleR > 1. It effects modes 0 and 1 with cycleR > 1. I'll fix it in the next version, there isn't any way to work around it except to add extra frames to the video so that the last cycle isn't short.

Could you try to make TDeint2 compatible with TSP's MT function?
Work with which mode? TDeint2 eats a lot of memory and to save tons of repeated calculations stores temporary frames in its own buffers which are defined as class member variables... so it probably wont be compatiable with all modes.

[manono]

Hi tritical-

You should have told me before when you first saw it

Gee, I just figured that everyone got that message. It's never been a problem before, because the message wasn't imprinted on the video. Then thinking about it some more, I decided that previously I had been encoding AVI through VDubMod, and this was the first time that I had used the TDecimate Cycle Mode in CCE, as my usual silent film IVTC, SmartDecimate, wasn't working properly on this film. In this case, interestingly, the original DVD didn't go from the source framerate to 29.97fps via adding fields, but complete progressive frames. You hardly see that with silent films. So I just needed a good Decimator. Must be something about CCE that causes the message to be imprinted on the video. Although frustrated when I posted before (could you tell?), I've since solved the problem by first creating an uncompressed Lagarith AVI in VDubMod, and then frameserving that into CCE using AVISource. No more message. I'll remember your tip and Loop in some extra frames the next time the problem arises.

Anyway, thanks for the response, and I'll patiently await an updated version of TIVTC.

[tritical]

Having the error message reported (as in vdub) vs getting frames with the error message printed on them is dependent on the error handling of the external application... that is to say TIVTC has no control over it. In both cases TIVTC is simply calling env->ThrowError(). vdub/vdubmod are the only programs I know of that will present the actual error message instead of returning the error stream. If you open the script in a player such as mpc it will return the stream with the error message printed on the video.

I personally never have occasion to use cycleR>1 with modes 0 or 1, which is the reason the problem has managed to slip through. I have used it before on a few tests, but either missed the message or it happened that the length/cycle lined up correctly. The reason the message is worded the way it is (useless) is that I never thought anyone would get it (I originally used it for debugging purposes and it should never occur).

[manono]

Hi-

If you open the script in a player such as mpc it will return the stream with the error message printed on the video.

Yeah, I didn't actually see the message until testing the finished DVD in PowerDVD. It was definitely imprinted on the video. I opened the M2V in VDubMod to confirm. Lucky thing I checked, as I found it on another short silent film also. Strange, though, that CCE imprints it and VDubMod doesn't.

[Revgen]

Work with which mode? TDeint2 eats a lot of memory and to save tons of repeated calculations stores temporary frames in its own buffers which are defined as class member variables... so it probably wont be compatiable with all modes.

Preferably mode 1 or 2. They are the fastest. Modes 3 and 4 are slower. It doesn't really matter which one it works with as long as performance can improve. If TDint2 is as slow as you say it is, I would like to utilize any performance advantage that I can find.

TDeint for example gains about a 50% performance increase with Mode 2.

If you could explain how TDeint2 works to TSP he may have a better idea of what might work.

Thanks.

[Egh]

@tritical:

Just make it artifacts-free and I don't care about speed :) It can be 10 times slower than current mode 3, but what is really needed is artifact- and noise-free :)

In any way, during casual ripping process there are few frames (usually transitions, fadings and so on) which need to be deinterlaced, so actual speed here doesnt' matter much at all.

[tritical]

Still don't have the new docs done, and there were enough changes in this one that a beta before the final seems in order, so here is [link removed]. Changes:
TFM:
+ Added trimIn parameter (trim before tfm w/ d2v support)
+ Minor field matching improvement

TDecimate:
+ Added ssd parameter
+ Added vidDetect = 4 mode
+ Converted all metric storage/calculation to int64 to prevent possible overflow
on large frames
- Fixed mode 0/1 incorrect decimation of the last cycle of a clip when cycleR > 1
and the number of frames wasn't a multiple of the cycle length

FrameDiff:
+ Added ssd parameter (same as tdecimate)
I also reworded that error message slightly in case someone somehow gets it again :p.

[manono]

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.

[manono]

Been testing:

+ Added trimIn parameter (trim before tfm w/ d2v support)

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!" This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)

[Leak]

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.
Or you could just cheat and look at the source files... not that I would do or encourage it, of course... ;)

[TheBashar]

However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)


Isn't this exactly what the trimIn parameter is for?

[tritical]

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!"
Previous to this version tfm didn't require that the number of frames it had info for from the d2v file actually matched the input frame count. Instead, it simply used the first frame count number of entries (if the d2v had more) or it used nothing for the extras (if the d2v had less). That wasn't a very good solution, but it did stop tfm from crashing when filling the d2v info array if the d2v had more info. With the addition of the trimIn parameter I decided to require that the frame info from the d2v file match the input frame count (that is where the new error msg comes from). The whole reason that the trim before requires special support is that tfm has no way to determine if a trim statement actually came before it or not.

This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)
Trimming after tfm is a viable option, the only thing it messes up is that when TDecimate gathers the hint information from tfm it assumes that the incoming frames are in the same order as when they came out of tfm. For example, to determine duplicates via matches tdecimate looks at the frame matches delievered by tfm. It uses that info to see if the same field has been used in two frames in a row... i.e. if the current frame match is 'p' and the previous match was 'c' (and neither match was marked as combed and deinterlaced) then there was a repeated field. If you use trim() before tdecimate then those assumptions are no longer correct for the first frame after the cut position. TDecimate also considers rff duplicate info that is passed by tfm, and that information would also be incorrect for the first frame following a cut. Currently there is no way to disable tfm's hinting or to force tdecimate not to use the information if it sees that it is present.

Changing your script to use trimIn would work like this:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0,trimIn="trim.txt")
TDecimate(mode=0)

with trim.txt containing the following line:

0,449

Here 0,449 is marking the frames that were cut out (inclusive).

[manono]

Yep, manono is a dumbass. Thanks for the heads up, TheBashar, and for the detailed explanation, tritical.

[tritical]

Unfortunately, school and other things have set me back on getting TDeint2 completed, as well as getting TIVTC and TDeint released (but they will be out eventually). I have had a little bit of time to do some low level optimizing of TIVTC, which I have been putting off. Here is the first take which focuses on tdecimate... [link removed], changes:

TDecimate:

+ optimized c metric calculation routine (~2.5-3x faster)
+ removed width restrictions on isse yuy2 scenechange detection routine
+ added mmx yuy2 scenechange detection routine
+ removed all pitch and width restrictions on isse sad/ssd block metric
calculation routines
+ added mmx sad routines
+ require mmx and not isse for the assembly ssd routines because they use
only mmx instructions
+ removed width restrictions on mmx denoise routines
- fixed possible divide by zero crash with vidDetect = 4Next, I'm going to spend a little time on optimizing tfm and porting the above tdecimate changes into framediff/framediffc.

[MacAddict]

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.

Just to clarify, I could essentially turn off all extra video codec options I'd typically have on for this first pass right? For example I'll disabe Qpel, VHQ, Motion Search, B-Frames and even set a constant quant of 31 within XviD. I'm assuming that would be correct ;)

Edit- Thanks again for your effort on this project, greatly appreciated.

[tritical]

Yep, that would work. For the first pass when tivtc gathers info, literally anything that requests all the frames of the script will work... a getall() (from avstimer) at the end of the script, using preview in vdub, etc... whatever runs fastest for you. I usually just open the script (which after crop outputs 16x16 or 32x32 res) in vdub, select fast recompress with huffyuv as the codec (though at that size which codec you use doesn't make much difference), and then save as avi. That way is very fast and you can select the process priority.

[DarkNite]

I'm always happy about faster metrics calculation.

The funny thing is this news actually made my day several degrees better than it was. For a moment there I was about one spreadsheet or phone call away from DEFCON 4. This was just enough good news to lift myself out of a rut. :p

:thanks: I'd hand you a beer if I could.

[foxyshadis]

That way is very fast and you can select the process priority.
Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.

[MacAddict]

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.
Hmmm I'm not having any success using Vdub 1.6.11 doing 'run video analysis pass' feature. The analysis runs fine without error but then I go to run the 2nd pass and immediately get an error: Input Error(mode 5 & 6, all frames must have entries).

mpeg2source("D:\ep17.d2v")
assumetff()
#
#First pass VFR
#tfm(d2v="D:\ep17.d2v",order=1,output="matches.txt")
#tdecimate(mode=4,output="metrics.txt")
#crop(344,224,-344,-224)
#
#second pass VFR
tfm(d2v="D:\ep17.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=0,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")

Any ideas or am I just missing something obvious?

[tritical]

@DarkNite
Thanks, and I would definitely take the beer if I could :).

@foxyshadis
Didn't even know about or ever notice that function, will definitely have to try it out. :thanks:

@MacAddict
Gonna try out the 'run video analysis pass' function now, will report if it works for me or not.

EDIT: It worked fine for me. I don't see anything wrong in your scripts... does it work correctly if you actually use "save as avi"? If so, could you create the output files once using that method and then again using the "run video analysis pass" method and see how they differ?

[MacAddict]

@tritical
You read my mind. VdubMod 1.5.10 b2540 works flawlessly of course as we normally use it with different passes. Vdub 1.6.11 does work fine with the same script using "save as AVI" but unfortunately I'm in the middle of a 11 hour TDeint bob encode and can't do an analysis on the matchcode files. I'll try and reproduce the problem on another PC tomorrow and post my findings to see if a difference does exist between the two methods. Thanks for trying it out.

@foxyshadis
Thanks for the 1st pass tip in Vdub. Too bad VdubMod isn't being developed and including that feature, I prefer it for the extra functionality and configuration.

[ChronoCross]

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.
Additionally you can just hit the play button, that works well. Just diable previews. but a reminder to all who use this method you have to remember to close out of the avs when you finish the pass. any additionaly frame jumping will also be recorded into the metrics file which is bad.

[MacAddict]

I'm not able to reproduce the the issue I mentioned above, even using the same files/episodes and scripts on the same PC. I tested 2 other PCs and it appears to work fine. Only difference I can think of now is that I rebooted this PC. If all else fails reboot! Sorry for the waste of time tritical.

@ChronoCross
I noticed the same thing early on. It appears the text files aren't created until Vdub/VdubMod is closed. Good tip.

@all
I'm just starting to get my head wrapped around TFM/Tdeint finally and understanding the basic parameters for my material. Does anyone have examples thats worked well for them on standards converted movies where Restore24 and Cpackage has failed? I currently have some NTSC->PAL and vice versa film material thats driving me insane due to it not being smooth. Mode=7 helps in some cases on the blended fields but I'm still seeing some jerkiness on occassion. Combed isn't a problem at all so would it be safe for me to use PP=0 in order to prevent jerkiness?

[scharfis_brain]

tritical: is the a pre-build of TDEint2 somewhere to play with?

[tritical]

I'll try to put one up in the next few days. Currently, the motion stuff is in one program and the interpolation is in another... I just haven't had the time to merge it all and get everything working together.

I am gonna go ahead and release a standalone edge directed interpolation filter that resizes by 2x in the vertical direction using my new ela method. TIVTC has the clip2 option so it could make use of it already, and it would be very simple to add a clip2 type option to TDeint as well (and that is a feature I think it should really have).

[tritical]

Here's [link removed]... it resizes by 2x in the vertical direction by copying the current image to every other line in the resized image and then interpolating the missing field. Basically, it works the same way as "elaresize" which was a filter I posted on neuron2's forum some time ago. This filter is my latest edge-directed interpolation for deinterlacing attempt. The goals have been to preserve the filter's ability to connect edges and operate without the need for value capping (a sanity threshold), while at the same time eliminating the typical artifacts that usually produces. In order to do that it uses a two step process so that it can force spatial consistency and coherency of the direction map... in other words it is SLOW :p. While not as perfect as I would like it to be, it is, under most conditions, more stable then TDeint's type=3 or type=1 methods and does a much better job.

Anyways, here is a sample... I took this image from a thread on the virtualdub forums where it was posted by neuron2. In each case one field from the original image has been discarded, and the remaining field has been used to construct a new frame:

original:
http://bengal.missouri.edu/~kes25c/orig_1.jpg

avisynth's bob:
http://bengal.missouri.edu/~kes25c/bob_1.jpg

tdeint_type=1:
http://bengal.missouri.edu/~kes25c/td1_1.jpg

tdeint_type=3:
http://bengal.missouri.edu/~kes25c/td3_1.jpg

eedi2:
http://bengal.missouri.edu/~kes25c/eedi2_1.jpg

In this example EEDI2 easily beats both type=1 and type=3 of TDeint. The lines are too dark and small for type=1 to allow them to be connected (it's sanity threshold kicks in), and it drops back to cubic interpolation. Type=3 does a better job since it doesn't work by selecting one candidate and then testing it against the sanity threshold, but tests all other possible candidates as well. However, it still can't actually connect the lines due to the sanity threshold.

To build a dumb deinterlacer out of EEDI2 you can use the following:

1.) tff, keep top field:

separatefields().selecteven().EEDI2(field=1)

2.) tff, keep bottom field

separatefields().selectodd().EEDI2(field=0)

3.) bff, keep bottom field

separatefields().selecteven().EEDI2(field=0)

4.) bff, keep top field

separatefields().selectodd().EEDI2(field=1)

or to make a bobber:

1.) tff

separatefields().EEDI2(field=3)

2.) bff

separatefields().EEDI2(field=2)

In this manner it is possible to use EEDI2 in combination with TIVTC via TIVTC's clip2 parameter. For the moment it isn't possible to use EEDI2 with TDeint... but hopefully there will be a way to use it in conjunction with a motion-adaptive or motion-compensated deinterlacer sometime soon. Needless to say this filter was developed testing exclusively on anime and the sample image posted above... how well it works on real life images is still a mystery :).

[Mug Funky]

that's really impressive! it's finding diagonals that i didn't think it was possible to find with any reasonable speed.

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.

[edit]

it also makes a very good comb mask :)

[Guest]

Tritical, please explain the field parameter in detail. Thank you.

[Guest]

I see that the EEDI2 filter has these parameters:

mthresh
lthresh
vthresh
estr
dstr
maxd
field
map
nt

Would it be possible for you to explain them in detail?

Thank you.

[Guest]

Thanks for the great interpolator.

Please describe parameter 'nt'. It's not in the README.

EDIT: I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

[tritical]

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.
Yeah... junctions are still a problem, specifically those involving diagonal lines/edges. There are also some patterns that can cause it to mess up when they are present at the right spacing. I still have quite a few ideas for improving it (slowing it down more) though... haven't even gotten to testing for consistency of interpolated values among directionally corresponding neighbors or testing for consistency among the final interpolation directions.

Please describe parameter 'nt'. It's not in the README.
In certain places a starting value is given to the "min" variable when checking for the direction that minimizes the cost function. If no direction gives a value less than the starting minimum then no direction is used. The nt variable is used when setting that initial value. The cost function sums the abs() differences of pixels in the sliding vectors, so nt corresponds to a pixel difference and the min variable is usually set equal to: # of differences*nt. I normally use 50 (TDeint's type=3 uses the same thing), but for testing purposes I decided to make it alterable. I found that changing it didn't effect things much at all and decided to leave it out of the readme. Theoretically, increasing nt should allow better diagonal edge/line reconstruction while creating more artifacts, and decreasing nt should hurt diagonal edges/lines but decrease artifacts.

[AVIL]

@tritical

I'vi give to EEDI2 v0.9 a try as bobber. I'm very happy with the results. Far better as TDEINT even with the default values. My footage is real video, not anime. Only a word : chapeau

[scharfis_brain]

here my small contribution to produce artifact free motion adaptive deinterlacing:

function securedeint(clip i, int th, int l)
{ function staticmask(clip e, int th, int l)
{e0=e.motionmask(thy1=0,thy2=th,thc1=0,thc2=th,thSD=255)
e1=e0.trim(1,0)
e2=e0.trim(2,0)
e3=e0.trim(3,0)
e4=e0.trim(4,0)
e5=e0.trim(5,0)
e6=e0.trim(6,0)
e7=e0.trim(7,0)
ea0=logic(e0,e1,"OR")
ea1=logic(e2,e3,"OR")
ea2=logic(e4,e5,"OR")
ea3=logic(e6,e7,"OR")
eb0=logic(ea0,ea1,"OR")
eb1=logic(ea2,ea3,"OR")
ec=logic(eb0,eb1,"OR")
(l==0) ? ec. greyscale().duplicateframe(0).duplicateframe(0).duplicateframe(0) :\
(l==1) ? eb0.greyscale().duplicateframe(0) :\
(l==2) ? ea0.greyscale() :\
e0.greyscale()
}



i.converttoyv12(interlaced=true).separatefields()
e=selecteven().staticmask(th, l)
o=selectodd().staticmask(th, l)
interleave(e,o)
m=doubleweave().blur(0,1).binarize(upper=false)

b= getparity(i) ? i.separatefields().eedi2(field=3) : i.separatefields().eedi2(field=2)

d=i.doubleweave()

overlay(d,b,mask=m)
}

what it does:
creating two separate motionmasks for odd and even fields each. then combining them. so it is possible to identify static areas for sure.
but this will reduce detail in static areas, where a moving object recently has passed by.

parameters:
th = deinterlacing threshold:
0 -> stupid bob
6 -> a good value to start with
the higher the more residual combing

l = length of the combmask:
0 -> 16+2 fields are used for motion masking
1 -> 8+2 fields
2 -> 4+2 fields
any other value -> 2+2 fields

this large radius (l=1 or l=0) effectively helps against holes for linear moving, patterned structured, short shutter videos, that show deinterlacing holes with all other traditional deinterlacers.
(zilogjones, this one is for your games ;) )

[tritical]

@scharfis_brain
Nice function. Your motion masking effectively does what my motion masking for TDeint2 does, though it doesn't have a sliding window and I do some spatial denoising prior to testing temporal differences in order to deal with noisy clips. Somehow I could bet yours runs faster :p.

@All
So here come some releases. First is [link removed], changes:
TDecimate:
+ speeded up some of the mmx functions that were added in the last release
+ modes 0, 1, and 3 now pre-compute metrics for the next needed cycle while
delivering frames for the current cycle in order to evenly distribute cpu
usage

TFM:
+ Added mmx versions of the isse scenechange routines
+ Optimized combed frame detection routines
Second is [link removed], changes: + Added edeint parameter
edeint works the same as "clip2" in tfm. It can be used to specify and external clip from which to take pixels instead of using one of TDeint's own interpolation routines. That means TDeint could use EEDI2 in the following way:

see this post for setting combinations (http://forum.doom9.org/showthread.php?p=748199#post748199)

or for a combo of eedi2/tdeint for deinterlacing frames for tivtc you can use:

1.) tff

interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)

2.) bff

interp = separatefields().selecteven().EEDI2(field=0)
deinted = tdeint(edeint=interp,order=0,field=0)
tfm(clip2 = deinted,order=0)

Also, I noticed a mistake in the EEDI2 readme. Values 2/3 of the field parameter are switched. 2 actually starts with bottom and 3 actually starts with top.

Finally, I have been playing around with some possible ways of detecting junctions and corners in an image, which is where EEDI2 usually has problems, and a slightly modified version of the harris corner detection algorithm seems to do the job nicely. It completely avoids detecting plain diagonal lines while triggering on junctions and very complex areas. I'm probably going to add it as an optional step for avoiding artifacts.

[MacAddict]

Hmmm...Tdecimate is causing Vdub and VdubMOD to exit at the end of my scripts for some reason. This is the latest TIVTC v1.0 Beta 3. Using decimate() instead of tdecimate() resolves the issue on 2 film sources. Anyone else or do I have something strange going on?

I just went back to beta 2 and the script works fine. Perhaps the MMX speedups has caused this somehow in beta 3?

Edit-typo

[DarkNite]

Confirmed. It happens on both boxes here as well.

[tritical]

It is more likely the pre-buffering in modes 0, 1, and 3, cause the mmx speedups only effected ssd routines (requires ssd=true to be used) and one yuy2 luma difference routine. Plus, those mmx routines, if they are being used, get used on every frame so they would cause an error long before the end of the script. Also, I tested out all of the mmx routines on multiple clips, but didn't test a full encode (all the way to the end) with the pre-buffering :D. Will take a look.

EDIT:
Yeah it was the pre-buffering. I am guessing you both must be running windows xp sp2 cause TDecimate actually isn't crashing, it is throwing an avisynth error. Using a modified version of avisynth that doesn't have the little seh/c++ exception handling crash problem on sp2, this error reported in vdub:

"TDecimate: internal error during pre-buffering (%d,%d,%d)!"

Will put up a fix in a few minutes.

EDIT 2:

Here is a fixed version: [link removed]. Only change was one line of code to fix the end of clip processing in modes 0, 1, and 3. I will try to test things more thoroughly in the future :).

[DarkNite]

That was fast, thanks for the quick fix.

[manono]

Hi-

I don't know if I got the same thing or not. I didn't think much of it at the time, and didn't write down the error message VDubMod gave me, but after seeing the 2 other posts I thought I'd better report. This was with the new TDeint, using it as a bobber:

TDeint(Mode=1)
RePAL(Quality=3)

The message was something about VDubMod not responding and having locked. Can't really remember. The encode had completed, and near as I can tell, the video was complete. Using Win XP SP1.

[MacAddict]

Thanks tritical, that was very speedy indeed :-)

In all my cases Vdub/VdubMod was just exiting at the end of every script no matter how small or large the source file. Unfortunately my AVS version doesn't throw the exception here on XP SP2 :-\

[tritical]

@manono
I tried to reproduce your problem but wasn't able to... using tdeint(mode=1) both with and without repal in yv12 and yuy2. What was the rest of your script? and what was the source?

@All
I did notice another bug with TDeint though... it doesn't handle the edeint option correctly when mode=1. It checks for the edeint clip to have the same number of frames as the input clip, which is correct for mode=0, but should be 2x for mode=1.

@MacAddict
It actually does throw the exception... its just that due to a bug in one of xp sp2's dlls, mixing seh/c++ exception handling will cause a hard terminate. Avisynth no longer uses such a mix when the script is initially loaded (so any errors detected and reported by a filter in its constructor will be reported correctly in vdub), but still uses such a mix when requesting frames from the chain of filters (so any avisynth errors thrown by a filter during it's getframe() processing will cause vdub to hard terminate on xp sp2).

[Mug Funky]

@ manono: it didn't say "possible livelock" by any chance?

that's more a warning than an error - means at some point during the encode virtualdub didn't use any CPU cycles. this'll happen if some other program maxes out your CPU (and you don't have hyperthreading or something similar) for 10 seconds or more.

i get it a lot when i use virtualdub to export the audio out of an avs, and encode to mpeg-2 at the same time.

[manono]

Yes, that may have been it, Mug. I'll pay more careful attention the next time it happens. It happened after the encode had finished, I think. I wasn't around, and when I came back, the uncompressed Lagarith AVI was done and this message was sitting on the VDubMod screen. For what it's worth, here's the script:

LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll")
LoadPlugin("F:\DivX Stuff\GKnot\TDeint.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RemoveGrain.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RePAL.dll")
LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll")
mpeg2source("K:\March Of The Penguins\5-1\5-1.d2v")
Trim(0,94874)
TDeint(Mode=1)
RePAL(Quality=3)
Undot()
RemoveGrain()

Damn R1 March Of The Penguins has an extra that's a mix of 30fps interlaced footage and PAL2NTSC blended 25fps footage. I decided to RePAL the whole thing and see how it turned out.

[Chainmax]

I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

Really? I have an immensely crappy 160x112 video I want to resize to 320x256, how would I go about using this filter for that?

[Guest]

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

[mg262]

How about turnright().eedi2(...).turnleft()?

[Chainmax]

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

Ok, so how do I do that? Would mg262's method work?

[Guest]

Ok, so how do I do that? My way:

eedi2() # 160x112 -> 160x224
lanczosresize(320,256) # -> 320x256

Would mg262's method work? What he gave is not complete. I suppose he's just saying that you can resize the width by turning. But he still has to get from 224 vertical to your required 256. So maybe he means this:

turnright().eedi2().turnleft() # 160x112 -> 320x112
eedi2() # -> 320x224
lanczosresize(320,256) -> 320x256

[mg262]

I suppose he's just saying that you can resize the width by turning.Yes, that's all I meant. Sorry if I was too brief -- I was posting in a hurry. I would also try both variants:

turnright().eedi2().turnleft() # 160x112 -> 320x112
eedi2() # -> 320x224
lanczosresize(320,256) #-> 320x256

eedi2() # 160x112 -> 320x112
turnright().eedi2().turnleft() #-> 320x224
lanczosresize(320,256) #-> 320x256

There probably won't be a difference, but it's hard to be certain without knowing exactly how the filter works... and it doesn't take long to try both. For general resolutions, I would also try overshooting the target resolution and then downsampling... but in this case, 224 and 256 are so close that I don't think it's worth trying.

[Chainmax]

Ok, which one of these three you prefer:

http://img476.imageshack.us/img476/2795/14ha.th.png (http://img476.imageshack.us/my.php?image=14ha.png)http://img476.imageshack.us/img476/7403/22uz.th.png (http://img476.imageshack.us/my.php?image=22uz.png)http://img476.imageshack.us/img476/1940/30sv.th.png (http://img476.imageshack.us/my.php?image=30sv.png)

?

[mg262]

Definitely not the second -- horribly blocky. There's not much between the first and the third, but I think I prefer the third. But both emphasise vertical features more than I would like.

[Chainmax]

What do you mean by that?

[mg262]

It looks like everything has been painted by someone who only understood how to make vertical strokes. That may just be a feature of the scene, of course.

[Chainmax]

Well, the second picture is the source with just lanczos and addborders, does it show that issue as well?

[mg262]

Now that you mention it, looking again, I think it does.

[Guest]

The size is not 320x256 as you said you required. Why are you changing the game?

[Chainmax]

The actual picture size is 320x256, I'm just adding borders to reach a DVD compliant resolution.

[Guest]

@tritical

OK, first time I'm using Tdeint()... :)

You wrote:

That means TDeint could use EEDI2 in the following way (assuming clip is TFF):

interp = separatefields().selecteven().EEDI2(field=1)
tdeint(edeint=interp) I wanted to try this adaptive use of eedi2(). I had a BFF wedding DV clip. So I did this first:

interp = separatefields().selectodd().EEDI2(field=0)
return interp

The result is nice:

http://neuron2.net/misc/no-tdeint.jpg

Then I tried this:

interp = separatefields().selectodd().EEDI2(field=0)
tdeint(order=0,edeint=interp)

But the result is not so nice (note aliased diagonals):

http://neuron2.net/misc/tdeint.jpg

Can you set me straight, please? Thank you.

[tritical]

I stated things incorrectly and oversimplified into two scenarios when there are actually four same framerate deinterlacing cases that need specific handling. The configurations should be:

1.) bff clip, keep bottom field, interpolate top field:

interp = separatefields().selecteven().EEDI2(field=0)
tdeint(order=0,field=0,edeint=interp)

2.) bff clip, keep top field, interpolate bottom field:

interp = separatefields().selectodd().EEDI2(field=1)
tdeint(order=0,field=1,edeint=interp)

3.) tff clip, keep bottom field, interpolate top field:

interp = separatefields().selectodd().EEDI2(field=0)
tdeint(order=1,field=0,edeint=interp)

4.) tff clip, keep top field, interpolate bottom field:

interp = separatefields().selecteven().EEDI2(field=1)
tdeint(order=1,field=1,edeint=interp)


The settings you tried should be changed to either case 1 (just change selectodd to selecteven) or case 2.

There are also the configs for bobbing, but atm the edeint option is broken for bobbed output so I'll post those later when it is working.

[Guest]

Thank you for the clarification. I tried case 1. But the result is not as satisfying as I hoped. Please compare the sharp diagonals to the pure eedi2() picture in my previous post (especially over Ben's right shoulder). Is there anything I can do, perhaps lower the threshold?

EDIT: Even with thresholds at 0, it's not improved. Apparently it is the alternating of passed through content with interp'ed content, as can be seen via the map option, that causes this. I think we need to determine the combed areas and then use the interp'ed data on all scan lines within that area. What do you think?

case 1:

http://neuron2.net/misc/wedding.jpg

[tritical]

@neuron2
Any way that I could get that part of the clip for testing? Also, how fast is the background moving in that sequence? If you set the motion thresholds to -1 do those areas look as they do in the interp clip?

I think we need to determine the combed areas and then use the interp'ed data on all scan lines within that area. What do you think?
Expanding the motion map that way would probably help in this case, but I can't say for sure without seeing which pixels it is weaving and why.

@All
I was thinking last night about making an edeint type option for the motion map that would allow TDeint to take a motion map from another filter. I've realized that I don't want to reimplement all of the options and features of TDeint in TDeint2 (and the code in TDeint is so big and ugly that if I did I would rewrite it all) when the only real changes would be EEDI2 type interpolation, which can already be used in TDeint, and the new motion mapping. So instead, I am going to add an "emap" parameter to TDeint. Luckily, I already have my new motion mapping implemented in another filter :). The downside to doing everything in separate filters is it is slightly slower than if it was integrated and it makes it more complicated to use. On the plus side, allowing everything to be done externally opens up more possibilities and makes it easier to implement new ideas.

[Guest]

Thanks, tritical. I'll upload the clip when I get home tonight. Right now, I'm busy finding out how crappy all the H.264 tools are. How about this: a "Pro" transport multiplexer that won't let you set the PIDs or the transport mux rate (heck, it won't even tell you what rate it ends up with, so you have no way to know what rate to inject it at!). :mad:

[DarkNite]

I wouldn't worry about integration until you had both the time and desire to do so. Things aren't so complicated for those of us who know the lost art of "how to rtfm".

[Guest]

Any way that I could get that part of the clip for testing? Here it is:

http://neuron2.net/misc/short.zip

It's BFF DV. I've been using Cedocida. The snapshots are from frame 0.

Thank you for taking a look at this. I still think the motion areas need to use all the scan lines. I mean, how could that be wrong, since it would be copying whole areas of the good full interp'ed clip, which we know looks fine? I concede that it may not be necessary, but let's see if you find a weaving issue.

If you set the motion thresholds to -1 do those areas look as they do in the interp clip? No, it's fully combed! That suggests that your case 1 is set up wrong, or there is a weaving bug.

[Guest]

OK, I solved it. You need the field parameter on Tdeint() for case 1!

interp = separatefields().selecteven().EEDI2(field=0)
tdeint(order=0,field=0,edeint=interp)

It makes a very sweet adaptive deinterlacer. This results in the best deinterlacing I have ever seen under Avisynth. It blows away LeakKernelDeint(). And it's tolerably fast on my 64FX-55. Bravo, tritical!

Would it be possible for you to update your four cases above with the right field settings for Tdeint(), as this will serve as a reference for use of this outstanding method?

Sweet (who needs Faroudja?):

http://neuron2.net/misc/sweet.jpg

[Guest]

Interestingly, you can get comparable results with my VirtualDub filter. My code is a lot more naive so will produce more artifacts. But it still looks pretty good. Here are the settings:

http://neuron2.net/misc/sd.jpg

[tritical]

Thanks, I'll update the settings... it is quite funny that I can't keep the parameters right for my own plugins. I was assuming field got set to the same value as order by default (field=-1) in TDeint since that is how it works in TIVTC, but that is not true (it uses field=1 by default)... I should read the readme sometime :p. Now I am wondering how many times I have made that mistake when giving settings before.

[Guest]

Don't worry -- a foolish consistency is a hobgoblin of little minds.

[manolito]

It makes a very sweet adaptive deinterlacer. This results in the best deinterlacing I have ever seen under Avisynth. It blows away LeakKernelDeint(). And it's tolerably fast on my 64FX-55. Bravo, tritical!

I totally agree. Thanks very much tritical !

Just one (probably stupid) question:
Is there a general rule of thumb which field should be kept and which one should be interpolated? It would be nice to be able to narrow the four different cases down to just two.

Cheers
manolito

[tritical]

There really isn't any rule. I have heard some people claim that graphics and logos usually tend to be top field aligned.. in which case keeping the top field and interpolating the bottom field would give better results. Usually, it is simply a matter of whatever looks best to you and most of the time it is hard to tell any difference. I personally usually keep the top field for tff material and keep the bottom field for bff material out of habit.

[foxyshadis]

Tritical, is there any way to get TDecimate to create 120 fps files? (I doubt it, but I thought I'd ask.) I can import a timecode file and fill in frames based on the frame rate, so far that's looking like the simplest method. Unless someone can point me to something better?

(I'm trying to finish updating avisynth.org's vfr page with a 120 fps method that doesn't suck horribly. Even cooler would be something to insert drop frames into an avi/mp4 based on a timecode file, but I doubt that exists.)

[tritical]

Tritical, is there any way to get TDecimate to create 120 fps files? TDecimate could output 120fps, but then it would be up to the codec to insert "n-vops" or drop frames for the identical frames. If any processing was done later in the script it could make it such that the identical frames would no longer be identical leading to the codec not inserting drop frames.

The method for encoding 120fps currently described on the variable framerate page of avisynth.org does it such that the output from the avisynth script is a 29.970 fps file similar to what you get out of tdecimate(mode=5). A separate program (AVI60.exe) then goes through and modifies the final encoded file by inserting drop frames as needed. That process would be the same as having a separate program that goes through and inserts n-vops based on the timecode file output by tdecimate.

Even cooler would be something to insert drop frames into an avi/mp4 based on a timecode file, but I doubt that exists. If the source for AVI60.exe was available somewhere I could probably easily modify it to do this for avi, but I don't think that it is. Otherwise, I would have to spend a while looking into the file structures (which I have no clue about) in order to figure out how to do it and what needs to be modified. If there is someplace that has this information easily available I would be interested.

I can import a timecode file and fill in frames based on the frame rate, so far that's looking like the simplest method. Unless someone can point me to something better?
How are you doing this?

As far as 120fps encodes go I am not a proponent, but currently it is pretty much the only way to deal with 24/30 mixes without using mkv and without resorting to blending. I am hoping that mp4box will eventually get the ability to create vfr mp4 files based off a timecode file in the same fashion as mkvmerge.

[foxyshadis]

I use mkv was well, but I'm updating the page to help the people who need or want to use the different methods. Some of them were abominations, and this is the only one I haven't found a good substitute for. A method that requires Avisynth 2.0 and a variety of ancient plugins is just evil.

How are you doing this?
Right now I'm not; my thought was to parse a timecode file given by tdecimate via script or plugin to repeat frames, but as you say, that still depends on the grace of the encoder. :(

I found some information searching around, though; virtualdub can now write drop frames to raise the framerate (or lower it back), so I'm going to dig through the source and ask phaeron how it works. (If you want to see, set it to direct stream copy and change the framerate to, say, 119.88, 4 of every 5 frames will be drops hardly adding any size to the avi.) Of course it's always supported drop frames for captures, but this enables a nice quick comparison.

Edit: It looks as if it's simply a matter of creating zero-length frames, which are frame header "30 30 64 63" and then a 4-byte lenth "00 00 00 00". The index is composed of a collection of: the same frame header, a 4-byte keyframe flag, a 4-byte index (LSB), and a 4-byte length (LSB); drop frames simply enter zero for length. Oh, and a chunk in the beginning with fractional framerate and framecount, 16 bytes from the 4CC start. Otherwise the files are almost byte-identical, there's no groupings of frames like newer containers. I will investigate mp4 methods however.

[Guest]

@tritical

In EEDI2(), I'm confused by the field parameter. The readme says that field=0 should copy through the bottom field and interpolate the top. But this script shows no difference between a and b. If I change to field=1, a difference can be seen. This suggests to me that the field settings are 0=top and 1=bottom. Am I going astray?

a=assumebff.separatefields().selecteven() # bot fields only
b=a.eedi2(field=0).assumebff().separatefields().selectodd()
subtract(a,b) # should compare original bot to interp'ed top

[tritical]

@foxyshadis
Thanks for the info. Now you've got me really interested in making a tool to do this. I'll take a look at a converted file from vdub.

@neuron2
I can't run the script you posted without adding assumeframebased() before the second separatefields call (that was changed between 2.55 and 2.56 i think). Using the following script:

a=assumebff.separatefields().selecteven() # bot fields only
b=a.eedi2(field=0).assumeframebased().assumebff().separatefields().selectodd()
subtract(a,b) # should compare original bot to interp'ed top

definitely shows a difference here. While the following scripts:

a=assumebff.separatefields().selecteven()
b=a.eedi2(field=0).assumeframebased().assumebff().separatefields().selecteven()
subtract(a,b)

a=assumebff.separatefields().selecteven()
b=a.eedi2(field=1).assumeframebased().assumebff().separatefields().selectodd()
subtract(a,b)

show no difference as expected. Not sure what is happening to cause problems with your script.

[tritical]

@foxyshadis
Alright, so I've almost got a working program to do the drop frame insertion for avi. It can parse all the avi header info, modify framerate/count, parse all the frame chunks and insert drop frames, and parse and modify the index. To make it less complicated to code there are currently a few restrictions: the avi can only have one stream and it must be a video stream ("00dc"), the output must be 119.88 fps, the timecode file must be v1 and can only have framerates of 17.982, 23.976, 29.970, 39.960, 59.940, and 119.88 fps, and it only supports avi files with the "idx1" index type and not opendml avi's that have the "indx"+"ix##" index. However, given the relatively specialized use of such a program I don't think that those restrictions should be much of a problem.

[Guest]

I can't run the script you posted without adding assumeframebased() before the second separatefields call (that was changed between 2.55 and 2.56 i think). Adding that fixed my problem. I'm not sure why. According to the documentation, SeparateFields() should have no effect on frame-based clips, but it clearly does. I won't agonise about it since 2.56 apparently prevents one from going astray this way. Until I upgrade, I'll just adopt the policy of always doing AssumeFrameBased() before SeparateFields().

[tritical]

Finally got this thing working. [link removed]. Syntax is:

see here (http://forum.doom9.org/showthread.php?p=759253#post759253)

It will create a new 119.88fps file at "c:\path\avifile-120.avi". All restrictions mentioned above apply. So now it is possible to do a normal vfr encode with tfm/tdecimate(mode=5) with v1 timecode file output... encode the output from tdecimate to avi and then run this program on it to get a 120fps avi file. I'll give it a better name, make a readme, put the source with it, and release a full version sometime later this week. I've also fixed the edeint mode=1 problem with tdecimate and have gotten the external motion mask stuff working so there will be new version of TDeint soon too. Now it's time to sleep :p.

[foxyshadis]

Whoa! Cool! You had a busy sunday. ;)

Since it's meant to be used right out of avisynth rather than on pre-existing avis, that certainly makes sense. Not every tool can be a virtualdub. =p I'll wait for your final copy before I update the page.

[tritical]

Since it's meant to be used right out of avisynth rather than on pre-existing avis, that certainly makes sense. Not every tool can be a virtualdub. =p :confused:


Anyways, I would advise against using the version I linked above for now as it had some bugs in modifying the offsets for the index entries. I've also gotten quite a bit more done since then and expanded the functionality... I've added a PAL mode, that creates a 50.000fps avi file, that goes along with the current 119.880 fps NTSC mode. The possible framerates in the timecode file are now:

NTSC -- 119.880/n for n=1 to 25 (step=1)
PAL -- 50.000/n for n=1 to 10 (step=1)

It now accepts v2 timecode files as well as v1. It's also working in conjunction with mkv2vfr off haali's site, so you can take a vfr mkv file, extract the avi and timecode file using mkv2vfr, and then use this program to go straight to a 120fps avi file (assuming the framerates can be represented). The extra possible framerates also make it so you can use it in conjunction with Dedup (either with or without TDecimate) as long as the maxdrops is no greater than 5 and starting fps was 25, 50, 23.976, 29.970, etc...

Once a final version of this program is done I think I will also make one to go from 120/50fps avi to a timecode file and avi without drop frames (though I think a program to do this already exists :confused: ).

[Marsu42]

Your tfm filter from TIVTC v1.0 Beta 4 is missing mode=7, it throws an error pointing out that there's only up to 6. Beta 2 (fortunately, I it still exists unlinked on your site) is ok and has got this wonderful new mode e.g. for reversal of crappy PAL->NTSC transfers w/ decimation cycle 6. If this is not an error, you should update the documentation or people might wonder... on the other hand, nobody noticed since now :->

[tritical]

It is definitely a bug if it is telling you that. Could you post the exact script you are using to get that error and the exact error message? I can't reproduce the problem here (tfm(mode=7) works fine) and none of the code changes between beta 2 and beta 4 had anything even remotely to do with that functionality. Also could you use tfm(display=true) and make note of the version number for tfm that it shows? :thanks:

[Marsu42]

Damn (i.e. somehow embarrassing to me, good for you) - I cannot reproduce the problem either and I have upgraded avisynth and the script since then. While I am quite sure that I got this error message, it might be that avisynth somehow loaded an outdated dll w/o mode 7... I'll try to be more thorough next time :-o

And on the more productive side, I've got a question: Does it help TFM to process frames and/or speed up the process noticeably if any black borders are cropped before, or shouldn't I do it because it could break field matching? In other words, is crop().tfm().resize() faster or is tfm().crop().resize() safer?

[tritical]

As far as speed is concerned it depends on how much you are cropping and what the values are. If you are only doing something like (4,0,-4,0) then it would probably be faster to crop after tfm cause the 4 off the left side will throw off the alignment which makes a difference for simd routines. However, if your crop values for the sides are multiples of 8 then that wont be a problem, or you could use crop(,,,,align=true) which would also keep alignment for the rest of the script (but will cost a few bitblt's). You'd have to be cropping quite a bit off the frame for it to make a noticeable difference in tfm's processing time I think.

For how it effects field matching, cropping off black borders can't hurt, but how much it would help depends on how much noise the borders have and how big they are. tfm's field matching routine already ignores the first 8 pixels on the left/right sides and the first 2 lines off the top and bottom because it usually tends to be junk. And if the borders have no temporal noise then they wont be having any effect in the field matching anyway.

[Mug Funky]

i find cropping off hard subs is a big help :)

[manono]

Hi-

I was creating a Lagarith uncompressed AVI before feeding it to CCE. VDubMod got almost to the end before aborting with the error:

AviSynth read error: TDecimate: internal error during prebuffering (131727, 131728, 20)!

And the AVI came up 60 frames short of being complete. I had done a similar encode earlier with a larger Cycle, and it had come up 100 frames short. Here's the script:

LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RemoveGrain.dll")
LoadPlugin("F:\DivX Stuff\GKnot\TIVTC.dll")
LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll")
MPEG2Source("K:\Harold Lloyd Comedy Collection-Vol1-Disc1\1-1\1-1.d2v")
Trim(550,0)
TFM()
TDecimate(Mode=0,CycleR=10,Cycle=38,Chroma=False)
Undot()
RemoveGrain()

Using TIVTC v1.0 Beta 3 for AviSynth 2.5.x

Also, when using the Display parameter, it doesn't show all the frames in the Cycle before starting fresh again, so I can't see the information for most of the frames on the VDubMod screen. Did that make any sense? So I'm unable to see all the frames in the cycle to see what was kept and what was removed, and why. I don't really feel like running DebugView. I don't guess there's any workaround is there, when the cycles are large like that?

[tritical]

Try beta 4 and see if it works ok. Beta 4 fixed the problem prebuffering was having processing the last two cycles of a clip. That's why beta 3 only managed to last one day.

Yeah, atm the display info for large cycles doesn't really work cause any text that would be written off the frame (either vertically or horizontally) is just skipped. I'll try to change that in the next release and have it wrap around to multiple columns or something.

[manono]

Darn, and here I thought I was up-to-date. Thanks tritical.

[tritical]

[link removed], changes:
+ Added emask parameter
- Fixed edeint not working correctly with mode=1
- Changed field=-1 operation when hints=false
This version adds the motion mask from external clip ability and fixes the edeint problem with mode=1. I also decided to change the default behavoir for field=-1 so that it operates in the same way as tfm by setting field equal to order (except if hints=true, then field is still set to 0). This will hopefully be the last version before 1.0 final.

The configs for using eedi2 with tdeint's mode=1 are:

1.) tff

interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp)

2.) bff

interp = separatefields().eedi2(field=2)
tdeint(mode=1,order=0,edeint=interp)

[tritical]

[link removed], changes:TDecimate:
+ wrap display=true text to multiple columns and mark frames that will be
dropped with '**'
+ round to nanosecond accuracy for all v1/v2 timecode output files
+ slightly more efficient metric cycle calculation I have been working on adding internal caching to TIVTC... mainly for tdecimate because avisynth's internal cache doesn't work very well with TDecimate's access pattern. It isn't a problem for the typical cycle=5, cycleR=1 setup, but for large (>10) cycle sizes with cycleR > 1 it can be quite noticeable. I would probably recommend doing a metrics output pass in mode 4 first, and then using mode=0 with the metrics input file when using cycle sizes > 10 or 15.

Anyways, since the caching requires a good bit of internal tinkering I decided to go ahead and release a version with only the above changes first. Aside from the internal caching, the only things still to do are to port optimizations from tfm/tdecimate into fielddiff/framediff... though I may skip that since those functions are not used much.

[tritical]

Here is [See this post: http://forum.doom9.org/showthread.php?p=759253#post759253]. This is the full incarnation of aviparse.exe which I put up last week, a readme is included. The new syntax is:

tc2cfr out_fps input_avi_file timecode_file output_avi_file

out_fps specifies the framerate of the destination file, whose name/path are specified by the output_avi_file parameter. The timecode file can have any framerate corresponding to the following equation:

framerate = out_fps/n for n=1 to a large number step=1

The maximum value for n depends on what out_fps is, but for an out_fps of 119.880120 the max value for n is 340 at which point it can no longer adaquetly differentiate between fps values. The program will tell you what the maximum value is for the specified out_fps value when it starts. In the end I've made this about as general a tool as possible as it can handle just about any combination of framerates. It also allows one to go from a vfr mkv to a 120fps avi file simply by using haali's mkv2vfr tool (for v1 tc) or mkvextract (for v2 tc) to get an avi+tc file and the using those as input into tc2cfr. Or you can use tdecimate in a timecode file output mode and instead of going to mkv go to an avi file.

[foxyshadis]

Here is tc2cfr v1.0 (http://bengal.missouri.edu/~kes25c/tc2cfr.zip).
Awesome. I'm going to start playing with this now. Thank you so much, tritical!

Does the "no audio" rule still apply?

[tritical]

It does. More specifically, the avi can only have one stream in it and it must be a video stream. Also, it must use an "idx1" index (i.e. not open dml). The reason is I just didn't want to deal with the added complexity of handling multiple streams, and I can't think of why someone would use this on an avi with an audio stream already in it since such a file would be desynced. It seems to me that any avi you would be using tc2cfr on would be originally created with a single video stream in it.

[tritical]

[link removed], changes:TDecimate:
+ internal caching for modes 0, 1, and 3
+ show cycleR value in display output
- Fixed a problem with display output wrap around for the drop frame #'s listing
- Fixed metric prebuffering computing metrics for the incorrect frames within
a cycle after a seek to a random frame, causing a minor slow down when
seeking.
- Fixed requesting frames an extra time in modes 0, 1, and 3 when no field
matching hints from tfm were present in the stream.
The internal caching was actually much easier to add then I originally thought. It makes quite a difference for some cases, but not for others... your mileage may very. Found and fixed a couple other small bugs while testing it out as well.

EDIT:
Alright, I'm just gonna act as if Beta 6 was never released because it sucks horribly :devil:. The internal caching helped for rare scenerios, but it cut the speed by up to 4-5x for the typical cycle=5/cycleR=1 usage. The caching is needlessly doing a ton of bitblts when it doesn't have too (which is what is slowing things down). I'll put up a new version to fix the problems tommorrow.

[tritical]

[link removed]. Only change was fixing the slowness problem of tdecimate's internal caching. It is now at least as fast as it previously was for all cases, and much faster for those rare cases. That should be the last new version for at least a few days :p.

[Malow]

hi folks, i have one question: is bad to use tivtc in the "hybrid mode" for mkv vfr (using the examples avs in tivtc package) if the movie is pure film or pure ntsc interlaced video? (the speed is no problem..)

i really would like a "all purpose" script, for almost all kind of movie.. (not including anime)

or im asking too much? :)

[tritical]

If it's pure interlaced then you would definitely be better off processing it with a true deinterlacer. If it's pure film then it should be fine to use mkv vfr mode. I personally use the vfr mode for all material that isn't pure interlaced.

TIVTC's hybrid detection is pretty accurate/robust and by default it will favor film detection since vidDetect=3 requires no duplicates via matches and all differences above vidThresh. The major place it will fail is not detecting really slow 30fps pans due to the frame differences being below vidThresh, though usually those pans are so slow that it isn't noticeable. That problem can be corrected by lowering vidThresh or simply using vidDetect=0 (only require no match duplicates), but that can lead to some false detections on anime and cartoons. The reason being that when there are repeated frames there will be no difference between possible matches and you can get things like "ccccc" instead of the usual "cccpp" pattern out of tfm. That scenerio cannot occur in a scene with continous motion, such as a panning scene, but in a static scene or a scene where there is motion only every 2, 3, or 4 frames it could happen leading to such a scene being detected as video. A false detection of such a scene as video is usually unnoticeable though (it would only cause a negative effect for scenes that have motion every 2, 3, 4, etc.. frames, not on a completely static scene). The problem with vidDetect=0 shouldn't occur with real life material where there aren't repeated frames. Also, if you use the d2v option then the rff flags will be taken into account when detecting film/video sections.

[Malow]

wow, tnks for explanation and for your great work!!!! :thanks:

[tritical]

I put up a new version (v1.2) of tc2cfr on my website, it was mainly just internal changes and code cleanup. I also made a utility called cfr2tc that does the opposite operation... it takes an avi file with null frames and outputs a file with null frames removed and a v1 or v2 timecode file. cfr2tc can handle avi files containing multiple streams (2 audio streams + 1 video stream for example), but only one of the streams can be a video stream. The avi file it creates will contain only the video stream from the input file with null frames removed. It also has the ability to do timecode output only without creating a new avi file. Syntax for cfr2tc is:

cfr2tc input_avi_file output_avi_file timecode_file mode

Set mode to 1 for v1 timecode file ouput and to 2 for v2 timecode file output. Set it to 3/4 for v1 or v2 timecode output only. There are already a few programs to do this type of operation, but I decided to make this just to have something to do. I might make a little gui for them as well, haven't decided yet.

Links:

See this post: http://forum.doom9.org/showthread.php?p=759253#post759253.

[Egh]

I also made a utility called cfr2tc that does the opposite operation... it takes an avi file with null frames and outputs a file with null frames removed and a v1 or v2 timecode file. cfr2tc can handle avi files containing multiple streams (2 audio streams + 1 video stream for example), but only one of the streams can be a video stream. The avi file it creates will contain only the video stream from the input file with null frames removed. It also has the ability to do timecode output only without creating a new avi file.


Well, at least someone finally outside japan realized the convinience of such conversion :) Though more than one year after...

Good thing it's in one tool, not in two (aka avidelnul.exe and avi2timecode.exe tools).

I personally use that kind of conversion for hdtv raws, it's convinient to have no-null-frames avi in order to be able to use AVISource() on it (cause other way is to mux into mkv, therefore no AVISource() then).

[tritical]

I ended up making a gui for cfr2tc/tc2cfr called tc-GUI. I hadn't coded anything in c# before and decided this would be a good time to give it a try... it definitely beats doing win32 api programming for gui development :). It does require the .NET framework (1.1) to run. cfr2tc and tc2cfr have also both been updated to v1.3, mainly cosmetic fixes, plus the ability to specify the output fps as a fraction in tc2cfr.

cfr2tc, tc2cfr, and tc-GUI are now merged into one zip package for download. Link: avi_tc_package (http://bengal.missouri.edu/~kes25c/avi_tc_package.zip)

[Revgen]

Note to all EEDI2 users:

If you're going to use a EEDI2/TDeint combo in any form on any film-based TFF material, make sure to use AssumeTFF() before you deinterlace. I was trying to use it as a postprocessor for TFM but it wouldn't deinterlace properly unless AssumeTFF() was enabled. The progressive frames may have confused it.

I've not yet experienced this problem with pure interlaced content though.

[MOmonster]

@tritical
I don´t if it is a bug or just different internal settings, but for this (http://forum.doom9.org/showpost.php?p=762834&postcount=36) case, the newest tfm seems not to work correctly. The older version works just fine. I could not find something in the changelist that will cause this problem, maybe you know the reason for. Can it be because of the changed sco default or because of some optimizations?

Edit: Sorry my mistake. Indeed it was the different sco value that cause the different behaviour.

[tritical]

[link removed], changes:
TFM:
+ Support d2v format version 13
+ Write MIC values into output file
+ A few new mmx/isse optimizations
+ sse2 optimizations (only used on P4)
- Fixed clip2 crash caused by writing to a referenced frame [thanks tsp]
- Fixed rare crash on d2v input parsing caused by sometimes writing one entry past
the end of an array

TDecimate:
- sse2 optimizations (only used on P4)


Writing the MIC values into the tfm output file is in preparation for some two pass stuff in v1.1 of TIVTC. Main ideas atm are identifying combed frames by looking at relative MIC differences between neighboring frames and for identifying problem frames by running field matching twice using field=0 one time and field=1 the other time. Any places where the matches don't correlate between the two outputs would be identified as problem areas. Not sure it will allow much automatic correction, but would be a way to automatically identify areas where manual overrides may be needed.

I have had a new version of EEDI2 ready for a while now, but haven't released it due to various bug reports that I haven't been able to reproduce or nail down. The new version has interpolation direction consistency post-processing and corner/junction detection post-processing. Mainly trying to identify problem areas and then drop back to linear interpolation. I'll probably release that in the next couple days.

Finally, there is still the external motion-masking that was gonna go into TDeint2 but which I decided simply to make available in TDeint via the emask parameter. I haven't really touched it for the last month or more, but it will be done eventually. I haven't given it much priority since scharfis_brain has a similar script function and I rarely need to process true interlaced material.

TDeint v1.0 final will be out as soon as I have time to write the new doc (I've been saying that for too long).

[foxyshadis]

Oh, thanks for reminding me. Minor feature request: Would it be possible in the future to make tfm optional in TDecimate mode 5 (would default to all "c")? If not, perhaps removing the check on too many frames? I only ask because I use it often on progressive sources, where tfm's not useful. It'd be nice to have one huge file for those tasks.

Now, if that's exactly what the batch=true option does, that'd be cool, I just don't want to break it messily what with the warning.

EEDI2 is liquid luv. ;D

[tritical]

Yep, I'll make the tfmIn file optional for mode 5 (set to all c matches if not given) in the next version. batch does roughly the same thing but still requires a file to be specified.

Currently, if batch=true, then when the metrics input array is allocated all values are initially set to 0 (instead of ULLONG_MAX which is what I use for not set) and the check for having real values for each entry is disabled. Any valid difference metric values that are present in the specified input file are still read in as usual. Also, when the tfm info array is allocated all values are initially set to 'p' (instead of the not set value) and the check for having real values for each entry is disabled. Any valid match info that is present in the specified tfmIn file is still read in as usual.

[puffpio]

First time using progressive content..time to try out TDecimate!

I think I'm using it right (output looks right) but just want to verify

I have a 60fps (not exactly) 720p HDTV stream
the frames repeat like 'aaabbaaabbaaabb' etc

So I apply TDecimate(cycleR=3)

and that should do it right? (remove 3 out of 5 frames)
it appears to work and gets me to 23.97 film framerate, but I just want to be sure

[tritical]

@puffpio
Yep, what you have should work. If you want to see exactly which frames it is dropping you can use: TDecimate(cycleR=3,display=true).


@All
[link removed], changes:
TFM:
+ assembly optimizations

TDecimate:
- don't require input and tfmIn files for mode 5

From the readme:

As of version 0.9.11.8 of TDecimate, an input and tfmIn file are no longer required for mode 5. If an input file is not specified then a value of ULLONG_MAX-1 (the maximum value tdecimate has) is assigned to all metrics. Likewise, if a tfmIn file is not specified then all matches are assigned as 'c', not combed, and not a d2v duplicate.

So be sure that vidDetect is set correctly when not using an input or tfmIn file.

The assembly optimizations to tfm are plain x86 assembly (not mmx/isse). I hand wrote the code for the only two remaining routines that use a significant amount of cpu time (actually they are the two costliest) in the default tfm/tdecimate code path and are not already using mmx or isse (they have too many branch and early exit conditions to make simd useful). On my systems the code runs about 2.5x faster than the compiler generated code and lead to an overall speed increase in tfm of 30-50% :).

Weird, I've been changing the title of my first post in this thread for a while, but today is the first time it actually changed what title is seen in the forum.

[Egh]

TIVTC v1.0 Beta 9[/URL], changes:
TFM:
+ assembly optimizations

TDecimate:
- don't require input and tfmIn files for mode 5




I was quite suprised but seems new TFM (compared to the one even 2 builds ago ^^) is seriously faster. The gain for metrics calculation in yatta is likely +20% or so. But I didn't test that extensively. Have you measured speed improvement for new build?

[anton_foy]

As I post for the first time in this great thread I give two THUMBS UP for tritical and everyone who has made this Deinterlacer possible! Beautiful work guys!
It is also very fast IMO.

Yet I have a slight problem. The footage I use is mpeg2(d2v) interlaced 1440x1088 that i first upsize to 1920x1080 this is my script:

mpeg2source("C:\...\snow.d2v")
LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)
Lanczos4resize(1920,1088)
Crop(0,0,0,-8)
interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp)

The clip has very little movement in it, only a bit of wind blowing in the trees but on the branches it looks like the horizontal lines are jumping a bit up and down. I am guessing it is because the DeInterlacer interpolates the fields in a certain way. When there are some more movement it leaves small grains/pixels that are very distinct or contrasty.
This is not too bad but I just want to know if it is part of the DeInterlacer or just a bad scripting from my side.

[AS]

Best to deinterlace and then upsize.

[Chainmax]

tritical, you are awesome. I only wish there was something we could have done about those troublesome X-Men captures :(.

anton_foy: it is bad scripting on your part. Like AS said, if it's actually interlaced, either a) deinterlace and resize or b) separate fields, resize each of them and weave back. If it's telecined, IVTC and then resize. I don't know much about interlacing, but I heard many times here that directly resizing interlaced is a bad, bad idea.

[Didée]

Slowly, Chainmax & AS, slowly. What anton_foy does is fully OK. He is resizing only horizontally, thus leaving the interlaced structure completely untouched. Nothing wrong with that.

So far for protecting anton_foy ... now comes the bashing:

LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)

BOOO!! :D

[tritical]

@Egh
I was quite suprised but seems new TFM (compared to the one even 2 builds ago ^^) is seriously faster. The gain for metrics calculation in yatta is likely +20% or so. But I didn't test that extensively. Have you measured speed improvement for new build?
From beta 7 to beta 9 I got a speed up of about 30-40% for tfm on my laptop (pentium M). The sse2 stuff gave another slight improvement on my p4 system.

I would expect maybe even more of a gain from the last two builds with yatta than in normal operation since it uses micout=1. The new mmx/isse stuff in beta 8 was part of the checkcombed routine, which with default settings is usually only run once per frame, but with micout=1 is run 3 times per frame. The assembly optimizations in beta 9 effected the builddiffmapplane and comparefields functions which get used on every match comparison when slow=1 or 2 (builddiffmapplane isn't used with slow=0). Those 3 functions were also the ones taking up the most cpu time in tfm/tdecimate so speed improvements to them make quite a difference. I can probably still speed up slow=0 by a good bit, but not sure if anyone uses it.

@anton_foy
Your script looks ok to me, but even though you are only resizing horizontally it would still probably be better to deinterlace first and allow tdeint/eedi2 to work on the original image. And if nothing else, it will run faster (I don't even want to imagine how slow it runs on a 1920x1080 image).
The clip has very little movement in it, only a bit of wind blowing in the trees but on the branches it looks like the horizontal lines are jumping a bit up and down. I am guessing it is because the DeInterlacer interpolates the fields in a certain way. When there are some more movement it leaves small grains/pixels that are very distinct or contrasty.
This is not too bad but I just want to know if it is part of the DeInterlacer or just a bad scripting from my side.
Ususally bobbing does result in some jumpy horizontal lines since how a horizontal line gets interpolated will vary depending on which field is kept. It would probably be eliminated if you went for same framerate output (mode=0). The movement artifacts are most likely from imperfect motion-masking, if you want more resilient detection try using scharfis_brain's function that requires a longer static period.

@Chainmax
tritical, you are awesome. I only wish there was something we could have done about those troublesome X-Men captures . Me too, but I haven't had any insights about how better to deal with that particular problem. It's tough to come up with a reliable and automatic way for tfm to choose a match that every statistic it calculates says is worse than the other, and to only do it for the specific frames for which that happens. That's why I much prefer working with sane sources :D.

[foxyshadis]

Currently the state of hybrid->cfr decimation is pass most frames through, blend the recalcitrant segments. (Decimate mode 1/3, TDec's hybrid mode 1/3.) Is it possible to replace that with a motion-compensated clip (motion/mvtools 1.x) via the clip2 parameter in tfm? At worst they fall back on blending anyway. I'm not sure if I'm missing any special considerations or if it really is that simple. Also not sure how it would add a dup frame for tdecimate for every cycle in that case. Or would that have to be done to the clip2 clip beforehand?

I tried one clip with 60i and 24 telecine, and it seemed all right, but hard to tell. It has so little motion (and quality) in the 60i part, and the only dvd I knew was hybrid I sold. Maybe it's time to rip some more.

[DarkNite]

If you have any Excel Saga sitting around that would be a good start. ;)

Oh, the memories...

[Egh]

@Egh

From beta 7 to beta 9 I got a speed up of about 30-40% for tfm on my laptop (pentium M). The sse2 stuff gave another slight improvement on my p4 system.

I would expect maybe even more of a gain from the last two builds with yatta than in normal operation since it uses micout=1.

Well i didn't test that extensively, only ongoing projects. And as usuall I have background programs working, different priorities for metrics collector thread and most important -- there's also scene change detection filter working during ymc operation. So the gain from TFM metrics seems to be extraordinary, cause I was talking about gain in ymc step in general (I use ymc as default with TFM, slavc and TDecimate). Since metrics collection is only a fraction of that step then the speed of metrics collection just skyrocketed :P Overal time for one episode (720*480 24min) decreased from ~45min to approx. 32-33min. I guess that means metrics collection per se now is twice as fast as before :) And my cpu is Athlon XP 1800+, so SSE1 only. And even with only that, I'm close now to 1:1 ratio. So on something like 2200+ ymc should process one episode in real time then.

Btw, any suggestions for TFM setting as for ymc? I usually use TFF, mode=1, field=auto,slow=1,pp=7,MicM=0. That's pretty much default configuration in ymc. Still quite puzzled though with Chroma and mChroma parameters, seems doesn't have much effect...

[Chainmax]

Slowly, Chainmax & AS, slowly. What anton_foy does is fully OK. He is resizing only horizontally
...

Oh, I didn't notice that :o.

[anton_foy]

Thanks guys! Yes I dont think it would do any difference by rezising before or after TDeInt since deinterlacing is only a horizontal matter. I think I scripted it a bit better now...no jumpy or jittery lines and motion is stable but it is not using eedi2. New script:

mpeg2source("C:\...snow.d2v")
Crop(0,0,0,-8)
LoadVirtualDubPlugin("C:\...\plugins\DeBlock.vdf","Deblock", 0)
TDeint(mode=1,order=1,mtnmode=1)
Lanczos4resize(1920,1080)
LimitedSharpen(ss_x=1.0,ss_y=1.0,Smode=4,strength=150,soft=34)
ConvertToRGB32.Deblock(1, 1, 1, 1)

After treating the footage with this script it looks AMAZING! TDeInt is great and fast, 1,67 fps...hehehe it ten times faster than my previous deinterlacer. :)
BTW Didée, a bad choice of using DeBlock?

[Chainmax]

It's just that using VDub means converting to RGB and back, which unnecessary slows down the encode. Besides, there are many excellent deblockers for avisynth like DeBlock_QED or FunkyDeblock.

[tritical]

Currently the state of hybrid->cfr decimation is pass most frames through, blend the recalcitrant segments. (Decimate mode 1/3, TDec's hybrid mode 1/3.) Is it possible to replace that with a motion-compensated clip (motion/mvtools 1.x) via the clip2 parameter in tfm? At worst they fall back on blending anyway. I'm not sure if I'm missing any special considerations or if it really is that simple. Also not sure how it would add a dup frame for tdecimate for every cycle in that case. Or would that have to be done to the clip2 clip beforehand?
I think the better way might be to run the motion compensated conversion on the output from tfm (or you could leave out tfm or replace tfm with a deinterlacer), and then feed that to tdecimate. So a script for vfr->cfr with film and 30p would look like:

tfm()
newfps = mcChangedFPS() # 29.97 to 23.976
tdecimate(mode=1, hybrid=1, clip2=newfps)

I've thought about doing this before, but there are some problems. Mainly, most of the mc methods use a recursive approach that produces different results if you jump to random frames than if you run up to that frame linearly. In the above method, tdecimate wouldn't be requesting every frame but only random ranges of frames so it might cause problems. I am not up to date on all of the mc filters for avsiynth (the new mvtools and mg262's filter) and don't know how much that would really effect things. However, if it is a big problem tdecimate could easily be made to request every frame from clip2 in a linear fashion. I remember thinking about another potential problem with this before, but can't remember it now.

Btw, any suggestions for TFM setting as for ymc? I usually use TFF, mode=1, field=auto,slow=1,pp=7,MicM=0. That's pretty much default configuration in ymc. Still quite puzzled though with Chroma and mChroma parameters, seems doesn't have much effect...
Those settings seem fine to me. mChroma usually wont effect things much, especially in yv12 where there isn't much chroma information. Literally all it does is run the temporal/spatial differencing on the chroma planes and adds the results to the statistics gathered from the luma plane. The chroma results aren't multiplied up to adjust for the sub-sampling vs luma. If you want to see how much it actually changes things you can use debug=true with mChroma=true/false and check how much the match statistic numbers change. In the debug output it will also list the ratio between matches which indicates how well tfm could differentiate between the two matches (which is good and which is bad). The larger the number (>1) the better the recognition and the closer to 1 the worse.

chroma=true is pretty much only needed if there are frames that have chroma only combing. Otherwise, it usually just makes things worse due to false detections... a false detection in yv12 counts the same as finding 4 combed luma pixels since in the combed frame detection chroma is adjusted for the sub-sampling vs luma.

[foxyshadis]

I know motion can handle out-of-order access because of how its frame cache works, though it might have to recalculate an extra frame or two every time. It also plays havok with some conditional functions. Not sure if you have to access out-of-order (like TFM) but it would probably play a little nicer with them if you could do it sequentially.

Thanks for the pointers though, that helps me a lot. I didn't realize TDecimate had a clip2 as well, sicne it's not in the readme.

[tritical]

Thanks for the pointers though, that helps me a lot. I didn't realize TDecimate had a clip2 as well, sicne it's not in the readme.
It doesn't have such an option atm, that was just an idea. To me it seems like that would be the best way for things to work since the hybrid decision is made in tdecimate. Then when a hybrid section is detected it just requests the frames for that section from clip2 instead of doing the blend conversion on frames from the input clip.

For that matter, I had planned a while ago (I've forgotten exactly who asked for it) to allow decimation detection to be run on the input clip but to actually deliver frames from a second clip. I might tackle these two features after I finish optimizing slow=0 and write an mmx version of the isse comb checking functions. I think these new features would be suited to a v1.1 release.

[foxyshadis]

Another minor bug: "CFrameDiff does not have a named argument "ssd""

I look forward to a future version then, though I'm sure it'll be a little while until then.

[tritical]

Looks like I forgot to add ssd into the parameter string... it'll be fixed in the next version. I've completed all the optimizing stuff I wanted to do... so the next release will be v1.0 RC1 and I'll only do bug fixes on that version from now on. A v1.1 release will probably be out shortly after. Current things to add are:

1.) tdecimate clip2 for hybrid modes and to allow running decimation detection on one stream while delivering frames from another. These should be pretty quick/easy to add.

2.) ovrHelp file generation option for tfm. It would work such that you run field matching twice, once with field=0 and once with field=1, with output enabled. Then, tfm would take those two output files and generate a file that lists frame #'s where the matches don't correspond, where combed frame detections don't correspond, of possible missed combed frames or falsely detected combed frames (based on relative mic values of neighboring frames). It would also make a list of detected combed frames and frames where u/b matches were used.

The ovrHelp thing is mainly because I'm too lazy to go through and find things manually.

[tritical]

[link removed]. Only real changes were fixing the "ssd" parameter problem in CFrameDiff and fixing an issue with a few of the sse2 routines that were added to tfm/tdecimate in beta 8 (forgot that the count value for psrldq is # of bytes not bits). I also added an "opt" parameter to all the filters which allows forcing the use of c, mmx, isse, or sse2 routines (for testing purposes). The other changes were just optimizing slow=0 in tfm and porting assembly stuff from tfm/tdecimate into fielddiff/framediff.

[Chainmax]

tritical, would it be possible to make a faster version of EEDI2 for use as a standalone image enhancement filter like HQ2X (http://www.hiend3d.com/hq2x.html)?

[tritical]

A standalone version could be made, but it don't think that alone would really make it noticeably, if any, faster. Also, the nice thing about having it as an avisynth filter is I don't have to mess with opening/decoding sources, saving the result, etc... which is a big pain the ass :devil:. There are some potential areas for improving its speed, but only a couple of the routines in eedi2 lend themselves to simd implementations and they are the ones that use only a little of the current processing time. I could probably speed up the more intensive routines by writing the code in plain assembly myself, but that is a big job and I am still changing them some atm.

[Chainmax]

What about just making the standalone version without any optimizations? I'd love to see this implemented in emulators :).

[foxyshadis]

HQ4x looks a lot nicer (for sharp, low-res, high-contrast pixelly animation) and retains fine details, imho, and runs much faster than 2x2xeedi2. Eedi2 smooths edges somewhat, very similar to the much faster 2xsai or even cubic interpolation. It mostly outperforms others on curves on antialiased material.

HQ4x (http://foxyshadis.slightlydark.com/random/mmx_win_hq4x.png)
EEDI2 (http://foxyshadis.slightlydark.com/random/mmx_win_eedi2.png)

Not a representative sample, of course, and a bit of a matter of taste.

heh, I wonder if I could use isochroma's old neat image script to interface with photozoom pro, with its amazing (and amazingly slow) s-spline resize.

EEDI does have one significant advantage: You can use it as many times as you want, as far as I can tell. (Avisynth itself has problems with huge frames though; sucks since I'd love to use it as a poster-scan processor.) It's generally a very bad idea to chain HQXx, on the other hand, it causes bad haloing even on the second gen and just gets worse from there, along with uninterpolated areas standing out much more. It was created with one very specific purpose, and sucks for anything else, heh.

[Chainmax]

I don't like HQ4X much, in my opinion it makes the picture much too cartoonish. I prefer just using HQ2X and letting the video card scale up to monitor size (video cards use bilinear, right?). Therefore, for me it would be more interesting to see EEDI2 Vs HQ2X.

[tritical]

EEDI2 is really not that great for trying to enlarge a regular image. It takes too many risks, searches much farther than it needs to to find connections, and blurs too much. The same is also true of type=1/3 in tdeint. Interpolating a missing field in an image is a much different ballgame than normal resizing. I can think of a number of modifications that would improve how eedi2 performs when upsizing a normal pic. Also, I don't think EEDI2 could ever really compete with HQ2X or 4X on resizing those type of non-antialiased, blocky, high contrast video game images... that is specifically what HQ2X is designed for and it does a pretty good job. I am gonna try out a few modifications to improve how EEDI2 performs with normal images.

[foxyshadis]

Chainmax, I bet you would like something like 2xsai, eagle, or or even bicubic followed by a strong sharpen filter with few halos. I might ask at the zsnes board if that would be possible. HQXx are custom made for perfect sharpness, everything else fuzzy and unsharp, and you're right that it's quite annoying to have no middle.

Tritical, that would be awesome, I love it. =D I'm a little curious on how it works, since I get fuzzy on C algorithms. Does it fit a line/curve to each edge? Or try to create vectors from each point?

[Chainmax]

tritical: great, I hope you get some good results :).

foxyshadis: I never was much of a fan of image enhancement filters until HQ2X, but it's currently my favorite image enhancement filter for emulators. What do you mean by "followed by a strong sharpen filter with few halos", by the way?

[foxyshadis]

Tritical, I'm curious. I know EEDI has a very specific purpose, to double a field height, but as avisynth is currently without any really good vectorization functions this is about as close as it gets. Spline36resize is pretty decent too, sometimes even better, but overall it's all eedi. I've been toying around and found it can do amazing things, although artifacts build up after a few generations.

So I'm wondering if it would be possible to use the already calculated vectors to resize to any arbitrary width, interpolating as necessary, rather than repeated application and a final resize? I guess for too-large sizes it'd have to smooth out the vectors/curves more than normal. If that'd be too difficult or interfere with its primary use, then disregard.

Chainmax, I just meant to cut down the effect from the card's bilinear upsize, although I didn't find anything that's really preferable without being cartoony. HQ2x's (and 3/4) biggest issue is that it's limited to 3x3 blocks, which is why eedi and spline resizers look much smoother on long edges and curves, but are also significantly slower.

Quick comparison to the above 2 pics:
Photozoom Pro (http://foxyshadis.slightlydark.com/random/mmx_win_pzoom.png)

If I can compile it too, I'll add greycstoration's wavelet-ish resize, just for kicks.

Now that I look closer, eedi2 really does the best job by far on the background, even with a few generational artifacts.

[tritical]

I'm a little curious on how it works, since I get fuzzy on C algorithms. Does it fit a line/curve to each edge? Or try to create vectors from each point?
Basically, it finds a vector at each point and does linear interpolation in that direction, but it does it in two steps. It does an initial pass to get tentative directions at each point in the field and then it does smoothing/eroding/dialating of the direction map. When it interpolates the missing field off those directions it only connects pixels that are detected as having the same direction and matching in intensity. The directions are found using a 4 scan line vector matching method (which is a custom method that combines ideas from 3 or 4 papers I've read). The vector matching vs direction based off gradients (the tdeint type=1/pp=7 in tfm modes use a gradient direction method) is one of the differences when dealing with interpolation for deinterlacing versus normal resizing. The direction based of gradients method simply doesn't work very well for deinterlacing interpolation since half the signal is gone (poor detection as slope gets smaller), so vector matching is pretty much the only good method for connecting long edges/lines. Whereas if I was gonna make a normal resizer I would probably use a combination of gradient/vector detection.

So I'm wondering if it would be possible to use the already calculated vectors to resize to any arbitrary width, interpolating as necessary, rather than repeated application and a final resize? I guess for too-large sizes it'd have to smooth out the vectors/curves more than normal. If that'd be too difficult or interfere with its primary use, then disregard. It would be somewhat complicated, but if you simply used the direction of the point nearest to the interpolation point and then fit the desired curve or function in that direction it wouldn't be too difficult. Although, if you wanted to get sub-pel accurate on finding the desired points for interpolation it would definitely take a while to finish.

For the moment I've started working on the motion-mapping filter again (I am getting tired of seeing TDeint's motion-mapping failing all the time), but I've already added a directional based resizer for normal images to my todo list.

[Zarxrax]

@tritical or others:

With a mixed 24/30fps source, is it possible to create an output which preserves all frames but is NOT variable frame rate? This would essentially be like doing ivtc on the 24fps parts, and like an assumefps() on the 30fps sections.
This will produce an incorrect running time, but with the advantage of preserving all frames perfectly while still using a constant framerate.

This could be useful in some instances where the purpose is to do some kind of editing on the video stream, and you are only concerned with having all the frames look correct.

[foxyshadis]

Process as you normal would a hybrid in mode 4+5, and then use mkvout="nul". No timecodes, no problem! :D Set your fps as desired. (Will cause pain if you ever need to turn hybrid edits into watchable video though.)

120 fps is generally a better solution since durations and sync are preserved, and reverting it back to vfr or hybrid is relatively painless. Tritical made a neat little tool to turn a mode-5 decimated video into a super-fps one called avi_tc_package (http://bengal.missouri.edu/~kes25c/avi_tc_package.zip) you might like.

[Zarxrax]

Awesome, I should have thought of that :p

[Zarxrax]

@tritical: I have encountered what might possibly be a bug in tdeint... or maybe its a bug in blendbob, I really cant tell.

source = MPEG2Source("ep3.d2v", cpu=0)
deint = source.Tdeint(mode=1).BlendBob()
return deint


This script works fine for the most part, however there are certain frames where, while they will normally look correct, if I choose "refresh" in virtualdubmod, the frame will suddenly appear jagged like it was not being passed through blendbob. If you back up quite a ways and then come back, it will show fine again.

If I use a different bobber besides tdeint, this problem does not occur.


Edit: Also, there is a bug in cthresh of TFM. The documentation says that the minimum value is -1, and this should cause all frames to be postprocessed. However, -1 actually seems to do the opposite, and cause all frames to be reported as "clean".

[tritical]

Edit: Also, there is a bug in cthresh of TFM. The documentation says that the minimum value is -1, and this should cause all frames to be postprocessed. However, -1 actually seems to do the opposite, and cause all frames to be reported as "clean".
I'm not in a position to test atm, but it is probably a problem with the mmx/sse2 routines and negative values for cthresh. Try setting opt=0 in tfm and see if it works correctly.

I'll try to look into the problem with your blendbob script tonight sometime and see what's wrong.

EDIT: I took a quick look at the source and the assembly comb detection routines are indeed broken for cthresh values < 0. I'll fix it in the next release, thanks for reporting it.

[Zarxrax]

Regarding the tdeint problem, I *think* older versions of tdeint were working properly. I don't have an old version on hand to try it anymore though.

Edit: and here is a sample clip you should be able to see the problem with.
Open this script in virtualdubmod and look at frame 141. Then do edit>refresh.
http://zarxrax.kicks-ass.net/test.demuxed.zip

[tritical]

The reason the frame changes on reload is because BlendBob bases part of its decision about which frames to blend together on the average abs diff of the past 7 frames. When you run up to frame 141 linearly that history is completed filled, but when seeking to frame 141 it only has one valid value (from frame 140 which is processed before). This changes the result of the following if statement due to the fact that the average value calculation does not adjust for having less than 7 values (the unfilled entries are treated as 0 and bring down the average value substantially):

if ((pnThresh != 0.0) &&
(absDiffPN > (avgAbsDiff/5)) && // Don't freak out on plain Bob()
((double)usedDiff-(double)avgAbsDiff > (double)absDiffPN*pnThresh))

When run up to linearly that statement will be false for frame 141, but on seeking it evaluates to true and the average of P/N is used for frame 141 instead of P/C. I tried a quick hack of tracking the number of valid entries in the history when computing avgAbsDiff and then adjusting the calculation as necessary. After making the change it picked the correct blend for frame 141 when seeking. I'm afraid that Leak might have made it the way it is for reason though... so you might want to ask him about it. And even with the change, there is still the possibility for seeking to give different results than linear play.

[Zarxrax]

Ah, I see. Thanks for checking into it.

[rig_veda]

Does TTempSmooth have some effect on decisions of TDecimate further up in the filter chain?
I'm having a script that goes like (plugin loading part omitted):

mpeg2source("D:\Big\Project_Ghibli\Totoro.d2v")
TFM(PP=0,display=false,input="Totoro_TFM.txt")
TDecimate(input="Totoro_TDecimate.txt",display=true)

and another one

mpeg2source("D:\Big\Project_Ghibli\Totoro.d2v")
TFM(PP=0,display=false,input="Totoro_TFM.txt")
TDecimate(input="Totoro_TDecimate.txt",display=true)
TTempSmooth(maxr=7)

The TTempSmooth(maxr=7) is the only difference in the script.
Now TDecimate's output shows that even though it's running on the precalculated input files, it makes different decisions on one and the same frame in the first and in the second script. In one case, for example, it decided to use frame 336, in the other it to blend 334-336 (50.00,50.00). Now i thought that filters further down in the chain wouldn't effect the ones higher up, but just eat what they are fed with. And in this case, I was all the more surprised since i was using an input file with TDecimate. (Not using one doesn't make a difference in this case, though.)
What is going on here? :confused:

[tritical]

Would you be able to post the clip that causes the problem? You're right that having ttempsmooth shouldn't change things... I tested out that scenerio using the settings you posted on a clip on my computer but didn't encounter any problems.

[rig_veda]

I have no webspace to upload available atm, but I can send you a small version of the clip that exhibits the problem, if your mailbox handles large attachments. The size of the rar is 17.3 mbyte. You can contact me at fede2a01 at uni-trier.de
to give me your contact information, if you want to go that way. If not, I'll look into getting a space to upload.

[tritical]

You can upload the clip to my ftp if you haven't already found someplace else:

ip: 68.119.245.113
port: 17252
user/pass: upload/upload

as long as it's not larger than 2 or 3 GB's, any size is fine :). I don't think my email will take attachments larger than about 5 MB's.

[rig_veda]

Done uploading

[berrinam]

I've done a fair bit of searching and been unable to find anything said on this topic. I hope I'm not hijacking this thread by asking this here.


Is there a big difference between DeComb's combed frame detection and TIVTC's one?
Is TIVTC's more accurate?
Are the thresholds normalized to be consistent with each other?

I am asking because I am working interlace detection for MeGUI, and at the moment I'm using DeComb's IsCombed() function. I wonder if it would perhaps give better results to change to IsCombedTIVTC() for this.

[tritical]

@rig_veda
I looked at the clip and I was able to reproduce your results if I seeked to frame 268. If I ran up to frame 268 linearly from the beginning both scripts produce the same result.

Involved explanation of what happens
The difference is w/o ttempsmooth seeking to frame 268 causes only the cycle starting at frame 335, plus the previous (330) and next (335) cycles to be evaluated. However, with ttempsmooth in there to request extra previous frames, the cycle at 325 is also evaluated. The blend decision in mode 0 with hybrid=0 is based on seeing match dups + lowest metric'd frames at the right interval that it looks like an ivtc pattern change that produced two dups in one cycle. In this case the match dup in the previous cycle appears at pos 0 (frame 330), but without evaluating the cycle prior to that (starting at frame 225) it won't know the match used for frame 329 and therefore can't tell that frame 330 is a match dup. So with ttempsmooth it can tell frame 330 is match dup which triggers the detection and without it it can't so it doesn't trigger.

So the solutions are:
1.) don't seek
2.) if you don't want the blending for such cases when hybrid=0 then use "noblend=true" in tdecimate()
3.) Use "d2v=source.d2v" in tfm. In this case your source is almost entirely flagged (94% reported by tfm). With the d2v option enabled it doesn't try to blend in that cycle and picks up the correct ivtc pattern... plus it is faster :).

A problem though is that the following script should support seeking (assuming you use the output parameters on a previous pass to generate input files):

mpeg2source()
tfm(input="tfm.txt")
tdecimate(input="tdec.txt",tfmIn="tfm.txt")

but I seem to have made it so you can't use a tfmIn file with hybrid=0 for some reason... I'll have to fix that. I'm also considering making noblend default to false since most people would rather just keep the extra dup than see a blend in such cases.

[tritical]

@berrinam
They are mostly the same except that tivtc's function uses overlapping windows (the normal set plus 3 others offset at 0.5*blockx in the x direction, 0.5*blocky in the y direction, and 0.5*blockx in the x + 0.5*blocky in the y, the window size is variable (blockx, blocky) (fixed at 4x8 in iscombed), the window threshold amount is variable (MI) (fixed at 15 in iscombed), chroma parameter is adjustable (iscombed uses true), and it uses a different per-pixel combing metric.

Assume we have 5 pixels vertically and we want to know if 'c' is combed or not:

a
b
c
d
e

IsCombed's per-pixel metric:
val = (b - c) * (d - c);
if (val > threshold*threshold) it's combed;

IsCombedTIVTC's per-pixel metric:
d1 = c - b;
d2 = c - d;
if ((d1 > cthresh && d2 > cthresh) || (d1 < -cthresh && d2 < -cthresh))
{
if (abs(a+4*c+e-3*(b+d)) > cthresh*6) it's combed;
}

That pseudo code is not exactly how the metrics are implemented code wise, but is equivalent to what they do. So tivtc's cthresh and the threshold of iscombed() are both on a 0-255 scale, but will give differing results. IsCombed's threshold defaults to 20 and IsCombedTIVTC's cthresh defaults to 9... so it would seem to be more sensitive. However, tivtc's metric is tougher to trigger and it uses a larger default window size (16x16 vs 4x8), has to see more combed pixels (80 vs 15), and chroma defaults to false.

[scharfis_brain]

tritical, I have a question (or suggestion) regarding fieldmatching principles.

I want to discuss the low-motion (also no-motion) case.

The most fieldmatchers I know of will prefer a blind match on them even if the underlying video is true interlaced stuff thus risking the well known mouth combing.

How about introducing a threshold to identify these low/no motion scenes and the apply a motion adaptive deinterlacer on them?

The problem is pretty obvious with tdeint(mode=1,tryweave=true, full=false). -low motion interlaced scenes always are fieldmatched instead of being deinterlaced.

EDIT: IMO smartdecimate does something like this, in past I always wondered, why it started bobbing in low/no-motion scenes...

I mean fieldmatching should only be applied, if the algorithm is pretty sure that two fields are derived from one frame.
This is only the case with a reasonable amount of motion.

Of course, on can continue a running pattern (let the fieldmatcher adapt to a pattern), if the motion gets low or stops, but after a scene change it needs to reset this immediatelly.

[tritical]

@scharfis
Just a warning, I did a lot of rambling and thinking while writing this reply so it kind of jumps arounds. Also I was not sure whether you were specifically talking about TDeint or also TIVTC.

I mean fieldmatching should only be applied, if the algorithm is pretty sure that two fields are derived from one frame.
This is only the case with a reasonable amount of motion.

I think it depends on the material type. If you know the source is primarily telecined then I don't think having it use a motion adaptive deinterlacer in low motion areas is preferable because even the best ones aren't perfect and will give inferior results compared to pure field matching. However, if the source is primarily interlaced then it would probably give better results. I see the problem as one of combed frame detection and not field matching (which are two completely separate processes in TIVTC/TDeint). In fact, TIVTC's field matching has no notion of a frame being combed or not, it just decides which of two fields fits best to another field.

TIVTC's field matcher can handle low motion scenes (mouthes moving) pretty well (assuming a good match exists) because it uses temporal differencing in combination with field differencing (if it wants to compare matching two top fields A/B with a bottom field C, it first compares A/B to find where they are different and then only applies the spatial metric to the created A/C and B/C frames in those areas). That said, the field matching built into TDeint is much simpler than that of TIVTC's (though at this point it probably runs slower than tfm w/ slow=2). It doesn't use temporal differencing at all and just runs the spatial metric at every point and sums the result... so I would expect it to be much more inaccurate in low motion areas. Too check if the chosen match is combed the created frame is then passed off to the combed frame detection routine.

The reason the combed frame detection routine has such a hard time detecting frames which have very little combing or 'weak' combing (falls under the cthresh level) is simply that it is a tough problem. The comb metric isn't perfect and causes false detections due to noise and high frequency detail. Because of this, it cannot be made that sensitive (low cthresh and low MI values) without causing a lot of false detections.

In TIVTC, which works under the assumption that a large majority of the clip should be matchable, but that you will occasionally get a frame that isn't, it is usually better to let a few combed frames slip through every now and than to have a lot of false detections. However, in TDeint, which w/ tryWeave=true should work under the assumption that a majority of the clip is interlaced, it should be better to have a some false detections than to let a lot of combed frames slip through. So the low-motion idea might help. Or it might help to simply adjust the combed frame detection based on the motion level (the defaults for cthresh/MI/blockx/blocky are 6/64/16/16, so maybe use 6/15/4/8 in low motion areas). The filter could then vary the settings between those two ranges based on the measured motion level.

[tritical]

More thinking... Source type detection in areas without adequate motion is almost impossible. Therefore, the type of such areas must be determined based off assumption. TIVTC works under the assumption that the clip is mostly matchable. Therefore, it should assume that low motion areas are matchable. TDeint works under the assumption that the clip is mostly interlaced (not matchable). Therefore, it should assume that low motion areas are interlaced. Roughly speaking, the number of combed pixels present in frames from an interlaced clip is directly proportional to the amount of motion. Based on that, the amount of combing that the combed frame detection routine looks for (controlled by MI, blockx, blocky) when tryWeave=true should be based on the amount of motion, and it should be requiring less combing as the amount of motion decreases.

[MfA]

The directions are found using a 4 scan line vector matching method (which is a custom method that combines ideas from 3 or 4 papers I've read).You know it's funny, Ive only ever been able to find one other written account (admittedly a while ago) of somoene using vector matching instead of pel matching with an ELA type approach ... and that was in medical imaging to reconstruct dropped scanlines.

[Zarxrax]

I have a question about TDecimate modes 0 and 1. Do they both support random access, or do either of them expect the frames to come in a linear order?

[tritical]

You know it's funny, Ive only ever been able to find one other written account (admittedly a while ago) of somoene using vector matching instead of pel matching with an ELA type approach ... and that was in medical imaging to reconstruct dropped scanlines.
I'm not sure if my use of vector here is what you are referring to or not. By vector I just mean that instead of doing:

abcdefghi
o
jklmnopqr

diff = abs(h-k)
to test the +3 direction you do:
abcdefghi
o
jklmnopqr

diff = abs(j-g)+abs(k-h)+abs(l-i)

Or you can use 5, 7, 9, etc... pixels. Of the papers I read only one was using that method. However, that paper was still only using two vectors (one 1 line above and one 1 line below) and sliding them in the standard x+x tap ela style. One of the other papers was using single pel differences but kept points anchored above and below and added 2 extra taps (one 2 lines above and one 2 lines below) so that you then have 2 stationary points and 4 moving points. That helps quite a bit in preventing the line crossover tendency. My method just combines the vectors with the anchor idea and extended it to include additional anchors another scanline above and below the current anchors. So in total there are 10 vectors... 4 stationary (bolded below) and 6 moving.


abcdefghi

jklmnopqr
o
stuvwxyzA

BCDEFGHIJ

Of course, that alone still isn't accurate enough to be used without a sanity threshold. The processing/filtering of the resulting direction map helps eliminate most of the incorrect directions but is far from perfect.


I have a question about TDecimate modes 0 and 1. Do they both support random access, or do either of them expect the frames to come in a linear order?
Assuming that information from tfm (match info, d2v info, etc...) is not present in the stream:

mode 1 does not support random access. mode 0 does support random access.

Assuming information from tfm is present:

Currently, neither mode truely (i.e. 100% reliably) supports random access. Though once the next version of tivtc is out (so that tdecimate allows using a tfmIn file when hybrid=0) it will be supported in mode 0 by using:

tdecimate(input="metrics.txt",tfmIn="matches.txt")

Mode 1 can never 100% support random access since its decision's on the current cycle can be effected by what frame was dropped from the previous cycle.

Next version will also have an option to stop tfm from putting any information into the stream which is not possible atm (it will always put at least the match used and combed/not combed), and an option in tdecimate to ignore the extra information and go purely on metrics (also not possible atm). Unfortunately, I haven't had the time to work on avisynth stuff lately... should change soon.

[tritical]

I sat down last night and did some work on tivtc... I gave up on the having a separate 1.1 branch and only doing bug fixes to 1.0 because I'm too lazy to maintain both. So there might be quite a few more release candidates before a final 1.0. Current working changes:

- fixed cthresh < 0 problems (was broken for both assembly and c routines)
- allow tfmIn file when hybrid=0 in tdecimate
- if the field order of a d2v file does not match the user specified order an error is thrown
- noblend defaults to true
- added new spatial comb metric to tfm and is/showcombedtivtc (from decomb's iscombed/fielddeinterlace)
- added hint option to tfm to disable putting hints in the stream
- added hint option to tdecimate to disable reading of hint information
- replace all frame copying with env->makewritable() where possible
- seeking is fully supported for both modes 0/1 of tdecimate when a metrics input file and a tfmIn file (if hints=true) are used
- added clip2 option to tdecimate (metrics are calculated off the input clip but frames are returned from clip2, all modes supported)
- added hclip option to tdecimate (hybrid=1/3 take frames from hclip instead of doing blend conversion, modes 0/1)
- added RequestLinear filter (makes sure all requests for frames are linear and that all frames are requested)

There is one problem though, the hclip option works perfectly well for hybrid=1 by doing:

mpeg2source()
tfm()
mc = last.mcconvertfps()
tdecimate(hybrid=1,hclip=mc)

However, it is not possible to handle hybrid=3 in the same manner since the clip fed to the mc filter would first need to have the duplicates removed. That causes another problem because the resulting clip (w/ dups removed in film sections) after being fps converted would not have a constant relation to the frames in the input clip. Atm, it looks like for hybrid=3 it will take two passes and the following second pass setup:

mpeg2source()
tfm()
mc = last.tecimate(input="",tfmIn="",mode=8).mcconvertfps()
tdecimate(input="",tfmIn="",hybrid=3,hclip=mc)

where mode=8 would be a special mode for the purpose of dropping the correct frames. If anyone has any other ideas I'm all ears.

[tritical]

[link removed], changes:
+ Added mode 2, and blim parameter

After talking to Zarxrax, I decided to add a same frame rate mode to tdeint that is similar to Blendbob(). How it works is it bobs the input stream like normal mode=1. When asked to deliver frame n it grabs frames n*2-1, n*2, and n*2+1 from the bobbed stream (could be n*2, n*2+1, n*2+2 if field != order). It then differences the middle frame with the previous and next frames. If both differences are over the blim value then it delivers the source frame as is, otherwise it blends the source frame with the frame that produced the smallest difference and returns that frame.

The difference to blendbob is that it will never try to deliver a p/n blend (which is what makes blendbob not support seeking since the decision to blend p/n is based on previous differences) and that it has the max difference value at which point it will not blend the source frame with prev or next.

The main reason for mode 2 is pping for ivtc. Namely:

deinted = tdeint(mode=2)
tfm(clip2=deinted)

mode 2 can work with tdeint's edeint option perfectly fine (the edeint clip has to be as though it is being used in mode=1), so something like:

interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp)
tfm(clip2=deinted)

is also possible.

[Mr. Brown]

@tritical
i wanted to test Tdeint(mode=2) but it crashed always (avisynth 2.5.6a)

setmemorymax(384)
### Plugins ###
LoadPlugin("C:\dgmpgdec146\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Tdeint.dll")

### Source ###
mpeg2source("C:\fliegen\flying.d2v")

crop(4,0,-12,-0)

tdeint(mode=2,order=1)

Here is the source
http://rapidshare.de/files/15891931/flying.m2v.html

[tritical]

What type of cpu do you have? Also, when it crashes is it a hard exit or does it give you an error message?

[Mr. Brown]

1. Athlon XP 3000+ (Barton) look at my signature for more information
2. hard exit

my OS is wxp sp2

[tritical]

[link removed], changes:
+ output MIC values in debug info when tryweave=true or full=false
+ added value 70 to emask input
+ added mmx versions of isse/sse2 compare/blend routines for mode=2
- refactored/rewrote a lot of the code to clean up and simply things,
no changes that effect output... should give a slight speed up

@Mr. Brown
Unfortunately, I wasn't able to reproduce your problem. Does it crash if you use tdeint(mode=1,order=1)? Could you also put debug=true in the tdeint() line and use debugview to capture whatever it outputs before crashing?

[berrinam]

tritical, I just wanted to say that I tried out using IsCombedTIVTC instead of IsCombed for my Source Detection, and it performed much better. MeGUI now uses IsCombedTIVTC for its comb detection.

Thank you.

[DarkNite]

I see what you're talking about Mr. Brown. I'm using RC4 in AviSynth 2.5.6a with DGIndex 1.4.6 and VirtualDub 1.6.14 on an AthlonXP 3200+, Windows XP SP2.

mpeg2source()
deinted = tdeint(mode=2,debug=true)
tfm(clip2=deinted)


Here's what DebugView has to say:

[964] TDeint: v1.0 RC4 (03/19/2006) by tritical
[964] TDeint: mode = 1 (bob - double rate)
[964] TDeint: frame 1066: accumP = 1464846 accumN = 10990531
[964] TDeint: frame 1066: field = interp top (0) order = tff (1)
[964] TDeint: frame 1066: mthreshL = 6 mthreshC = 6 type = 2
[964] TDeint: frame 1067: accumP = 11032302 accumN = 1905505
[964] TDeint: frame 1067: field = interp bottom (1) order = tff (1)
[964] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[964] TDeint: frame 1067: accumP = 1308674 accumN = 1368299
[964] TDeint: frame 1067: field = interp top (0) order = tff (1)
[964] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2


Does it crash if you use tdeint(mode=1,order=1)?

Not here, or at least not within the 40544 frames my test source consisted of.

[Mr. Brown]

I wasn't able to make debug file because vdub(mod) close directly after loading the skript

Does it crash if you use tdeint(mode=1,order=1)?
No it works fine

and i try this
deinted=tdeint(mode=1,order=1,debug=true)
tfm(order=1,clip2=deinted)
now it load the skript but it crash after starting the encoding an no debug file was made

[AVIL]

@Mr. Brown

Have you tried without crop?

setmemorymax(384)
### Plugins ###
LoadPlugin("C:\dgmpgdec146\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Tdeint.dll")

### Source ###
mpeg2source("C:\fliegen\flying.d2v")

crop(4,0,-12,-0)

tdeint(mode=2,order=1)

certain filters don't work well on cropped clips

[Mr. Brown]

@Avil
also without crop it crashed

[tritical]

The fact that you don't get any output at all with debug=true is very strange. The first message it outputs is at the beginning of the constructor right after error checking for valid parameters (taken from DarkNite's post):

"[964] TDeint: v1.0 RC4 (03/19/2006) by tritical
[964] TDeint: mode = 1 (bob - double rate)"

If you don't at least get that then it isn't even getting through the constructor.

I'll put up a build here in a bit with some debug output strings that should identify which routine it is crashing in. If you and DarkNite could run the scripts that cause crashes with that build and capture the debug output it would help a lot. I am guessing it is a problem with one of the asm routines in mode 2, but I've run them all on my comp without problems.

Debug Build: [link removed]

The extra messages will be output w/ or w/o debug=true.

[DarkNite]

Here's what DebugView has to say now:

[2844] Create_TDeinterlace
[2844] Creating TDeinterlace object
[2844] TDeint constructor
[2844] TDeint: v1.0 RC4 (03/19/2006) by tritical
[2844] TDeint: mode = 1 (bob - double rate)
[2844] TDeint constructor returning...
[2844] Creating TDHelper object
[2844] TDHelper constructor
[2844] TDHelper constructor exiting...
[2844] TDHelper getframe
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1066: accumP = 1464846 accumN = 10990531
[2844] TDeint: frame 1066: field = interp top (0) order = tff (1)
[2844] TDeint: frame 1066: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1067: accumP = 11032302 accumN = 1905505
[2844] TDeint: frame 1067: field = interp bottom (1) order = tff (1)
[2844] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1067: accumP = 1308674 accumN = 1368299
[2844] TDeint: frame 1067: field = interp top (0) order = tff (1)
[2844] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDHelper subtract frames
[2844] TDHelper subtract frames isse

@Mr. Brown

You can get DebugView here (http://www.sysinternals.com/Files/DebugViewNt.zip). Just start it up, load your script in VirtualDub, and hit the play input button. The magic will happen on it's own. ;)

[tritical]

Thanks, I found the problem... had paddq's in the isse routine when it is an sse2 instruction. Unfortunately, it looks like I made that same mistake in a few places in TIVTC, but it only effects fielddiff() and a few of tdecimate's yuy2 routines. I'll put up fixed versions tommorrow.

[DarkNite]

:thanks:

[Mr. Brown]

my debug

00000000 0.00000000 [3744] Create_TDeinterlace
00000001 0.01130898 [3744] Creating TDeinterlace object
00000002 0.01135899 [3744] TDeint constructor
00000003 0.01139055 [3744] TDeint: v1.0 RC4 (03/19/2006) by tritical
00000004 0.01141737 [3744] TDeint: mode = 1 (bob - double rate)
00000005 0.01143441 [3744] TDeint constructor returning...
00000006 0.01146179 [3744] Creating TDHelper object
00000007 0.01149476 [3744] TDHelper constructor
00000008 0.01152381 [3744] TDHelper constructor exiting...
00000009 0.42560494 [3744] TDHelper getframe
00000010 0.42565188 [3744] TDeint getframe
00000011 0.42567924 [3744] TDeint getframe yv12
00000012 0.43208677 [3744] TDeint: frame 0: accumP = 0 accumN = 0
00000013 0.53284848 [3744] TDeint: frame 0: field = interp bottom (1) order = tff (1)
00000014 0.53289932 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000015 0.53293365 [3744] TDeint getframe
00000016 0.53295994 [3744] TDeint getframe yv12
00000017 0.54167360 [3744] TDeint: frame 0: accumP = 0 accumN = 0
00000018 0.64207071 [3744] TDeint: frame 0: field = interp bottom (1) order = tff (1)
00000019 0.64211595 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000020 0.64214361 [3744] TDeint getframe
00000021 0.65502572 [3744] TDeint getframe yv12
00000022 0.76859599 [3744] TDeint: frame 0: accumP = 3386725 accumN = 4707391
00000023 0.77290606 [3744] TDeint: frame 0: field = interp top (0) order = tff (1)
00000024 0.77300441 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000025 0.77540302 [3744] TDHelper subtract frames
00000026 0.80813426 [3744] TDHelper subtract frames isse

[tritical]

[link removed], only change was fixing the paddq problem.

[Mr. Brown]

@ tritical
now it works
thank you!

[tritical]

Glad it works :). Now time for the 4th release in four days... [link removed], changes:
+ optimized motion map and field comparison routines
+ added opt parameter
- fixed missing cache in mode 2

In my tests versus RC5, w/ default settings, I got the following speed increases:

mode 0 ~ 25-30%
mode 1 ~ 35-40%
mode 2 ~ 100%

For the amount of work it took I was hoping for a bit more, but it's still pretty good. The checkcombed routine could still be optimized (just need to bring over the code from tivtc), but I decided to put that off for another time. None of the changes effect output.

[DarkNite]

Nicely done! I would love to do more testing with this right away (there's a few sources I have that would love to meet mode 2), but Oblivion calls.

[Zarxrax]

Wow! Nice speedups!

A question on TIVTC:
Does using hybrid=1 or hybrid=3 with TDecimate affect random seeking in the file? Do the output files from either tfm or tdecimate store the metrics used to handle the hybrid stuff?

[hwti]

mode 1 ~ 35-40%
I gain 80% with mode 1 between RC4 and RC6.

But I wonder : does the opt parameter really work ?
opt=0 (C routines) is only 12% slower than opt=1, 2 or 3, which have the same speed.

My CPU is an opteron 144 (same as A64 SanDiego core) : MMX, SSE, SSE2, SSE3

[tritical]

@hwti
The opt parameter works, the reason there isn't much difference is because the routines that have simd versions just don't take up that much processing time overall. In mode 1, with default settings, there are only two routines that have simd versions, and there are only mmx/sse2 versions of those (I wouldn't expect much if any speed difference between them). Those two routines w/ c versions only take up about 10-15% of tdeint's total processing time.

Most of the speed gain in RC6 was from internal buffering of frame differences. Previously, the differencing/logic for motion mapping was all done at once in a single loop. Now, those operations are split up into separate functions which allows the differences to be buffered. This makes more of a difference for mode 1 then mode 0 since mode 1 processes each frame twice (just swap the value of field)... so the second time through on each frame it doesn't need to caculate any differences at all. For each new frame only a single frame needs to be diff'd and added to the buffer (same for mode 0). That makes more of a difference for mtnmode=1/3 which use 5 frames and test 2/4 field distances then for mtnmode=0/2 which only use 4 frames and test only 2 field distances.

@Zarxrax
Yep, the output files do include everything that is used for hybrid detection. Seeking with hybrid=1/3 and default settings will currently not work 100% even when using complete input files. Actually, it depends on what vidDetect is set too. If it is set to metrics only then seeking will work, but if it includes checking match/rff info from tfm then it will not. That will be fixed in the next release.

[tritical]

[link removed], changes:
TFM:
+ Added metric parameter and new spatial combing metric
+ Added hint parameter
- throw an error if the field order of a d2v does not match the user
specified field order
- replace frame copy with makewritable where possible
- fixed cthresh < 0 not working correctly

TDecimate:
+ Added clip2 parameter
+ Added hint parameter
+ Modes 0/1 fully support seeking when complete input/tfmIn files are
present (tfmIn file not required if hint=false)
- fixed a few mmx/isse routines containing paddq sse2 instruction
- replace frame copy with makewritable where possible
- fixed not allowing tfmIn file with hybrid=0
- changed noblend default to true

Other:
+ added new combing metric and metric parameter to is/showcombedtivtc
- fixed cthresh < 0 problem in is/showcombedtivtc
- fixed paddq in mmx functions in fielddiff()
+ added RequestLinear Filter

[berrinam]

Other:
+ added new combing metric and metric parameter to is/showcombedtivtcThe documentation doesn't say what the default value is -- I presume 0?

Roughly speaking, the number of combed pixels present in frames from an interlaced clip is directly proportional to the amount of motion. Based on that, the amount of combing that the combed frame detection routine looks for (controlled by MI, blockx, blocky) when tryWeave=true should be based on the amount of motion, and it should be requiring less combing as the amount of motion decreases.
Could this idea also be furthered through the use of motion masking?

Also, what is the reason for keeping TDeint separate from TIVTC? From what I've gathered, both can do field-matching and deinterlacing, just TDeint uses better deinterlacing and TFM uses better field-matching. Couldn't those different algorithms all be listed together so that there would be one TSourceFixer function, which could have a "ivtc" preset which focuses on field-matching and a "deint" preset which focuses on deinterlacing. I feel like I'm missing something...

[foxyshadis]

Cool! RequestLinear will make using certain functions with others a lot simpler, thanks! I haven't had any great ideas on how to use hclip better, short of psychic functions (maybe sse4 will come with that? :p). It's too bad, since the extra pain in the ass means people probably won't use it. On the other hand, conversion to 24p seems to be a lot more common than 30p.

[tritical]

@foxyshadis
The hybrid=3/hclip problem is the main reason hclip wasn't included. I've been thinking about just adding hybrid=1/hclip functionality since it is easy to do.

@berrinam
Yep, the default value is 0, forgot to put it in there. I'm not sure having metric 1 will be all that useful or not... the main reason I included it was so iscombedtivtc could be set to operate exactly as iscombed does, aside from the overlapping windows.

TIVTC and TDeint could be combined the way you mention. The main reason they aren't is just because I started them as separate filters. TFM may not have as good deinterlacing abilities as TDeint, but it can have access to them via the clip2 parameter. In fact, I prefer TFM having separate, faster functionality... tfm's pping could be made quite a bit faster using simd (it's the only part of tivtc that I haven't worked on optimizing), which I plan to do in the future. The main thing that isn't possible atm is TDeint having access to tfm's better field matching ability, but I could simply copy tfm's routines into tdeint. My plan for now is to make TDeint's field matching equal to slow=0 in tfm. The only change to make that happen is to have it difference at both a high/low motion level instead of just the low motion level. Obviously a big gain of combining the two would be not having to duplicate as much code.

[Fizick]

tritical,
Sorry, but why you afraid to release it as 1.0 without "RC99" ? :)
or 1.1.

"RC" is usually used for bug fixes only.

[tritical]

Any potential reasoning behind the version numbers was lost too long ago to remember, and I just like the way RC sounds I guess :p. Maybe I should downgrade it to v0.10.x.x for a while and just randomly increase the numbers (basically what I do now), since I don't plan to make a final v1.0 until there is nothing on the todo list. For some reason though, things keep getting added to it right when it's about to become empty.

[aichan]

tritical, i encoded dvd anime the castle of cagliostro and deinterlaced it with TIVTC RC1 2pass. but why the frame on 2nd pass is fewer than 1st pass (140k vs 180k) ?

i dont remember exactly but the script was :
mpeg2source("lupan.d2v")
tfm().tdecimate() # (i forgot the parameter, but i copy exactly just like '2 pass anime hybrid' example you include on the package)
crop()
fft3dfilter() #default parameter
limitedsharpen() #default paramater

the result of 2nd pass is the video length is shorter than the source.
source : 1 hour 40 minutes
result : 1 hour 22 minutes

what is wrong with my script?
sorry, but i'm really new in encoding with avisynth :)

[foxyshadis]

Second pass should always be less frames; for films it'll usually be near 1/5 less (unless it's really hybrid). But it shouldn't be shorter! Sounds like something else is setting the framerate wrong. You're muxing it with the timecode file after encoding, right?

[aichan]

no, the result file was not muxed yet. i encoded it using Megui (in x264 r477 package). encoded the first pass first, then the 2nd pass(result file). i encoded it in full length of the film so the output file was only 1 (video only).

i know 2nd pass frame is fewer cause x264 warned me that 2nd frame is fewer. i played the result and it has a shorter duration.

[foxyshadis]

Tritical, if you have time in the future, can you check on something for me? I get a lot of crashes using eedi2 on hi-res material ( > 500 lines or so, increasingly common the higher it goes, but sometimes it even works just fine on 2000 lines, eg, 1500x2000 images) in both yv12 and yuy2. They're not hard crashes, but Avisynth System Exception - Access Violations. I can provide samples where it consistently fails on almost every open (it usually works the first time, but not after), and if I dig around maybe less common ones. Trying it with a few large pics with imagesource should do it though.

Alternately, if it doesn't happen for you, I could try to debug, but I guess I'd need a debug avisynth? (I can make eedi2.)

fft3d does this sometimes as well, which is why I suspect it's an out-of-memory error (although I have 2gb, I'm not sure what avisynth can access), just weird that it happens at all different sizes.

[tritical]

[link removed], changes:
+ Added pp parameter and pp modes 1, 2, and 3
- A few minor internal changes
- Fixed some documentation errors (field parameter)
- do a vi.SetFieldBased(false) in constructor
- fixed a bug causing reads past the last line and incorrect interpolation
of the very top or very bottom line in some cases
I'd meant to release this two months ago, but forgot about it. I would bet that that last change fixes the access violations. In a couple of routines the y checks were off by one and could lead to reading past the last line. If it still occurs let me know.

For debugging those types of errors it's probably the best/easiest if you can make a debug build of the filter + a debug build of avisynth and then open the script that causes the problem in vdub with the vs.net debugger running. Make sure it is set to break into the debugger on win32 exceptions. A debug build of avisynth also does some tracking of the values immediately before and after vfb's which can help catch outside writes.

@aichan
Did you get your problem worked out or no? The second pass having fewer frames is normal unless the entire video is hybrid like foxyshadis said. If you are doing a two pass encode with a codec then you'll need to run the first/second pass for the codec on the second tivtc script (I gather from your post that you ran the first pass on the first tivtc script and the second pass on the second script).

[johnmeyer]

In this thread:

http://forum.doom9.org/showthread.php?t=106837

I described the unique method I have devised for transferring film to video at a full 24 fps. The one sentence description of what is in that thread is that I remove the shutter from a 16mm film projector; videotape the output using a high shutter speed in the video camera; and then use modified IVTC software (TFM) to recover the original frames.

Here is a link to a 5-second AVI sample of what the raw capture from the projector looks like. This is a free server, so the link will only be good for seven days.

http://download.yousendit.com/4769F7937CBF6A84

This film transfer process always guarantees two good fields of video for each frame of film. The field immediately after the two good fields can either be:

1. A third duplicate (rare, but can happen).
2. A good field of the next frame of film.
3. A "bad" field showing the film in motion between frames.

The TFM portion of TIVTC.dll is absolutely awesome, and the new parameters -- especially the metrics parameter -- have gotten me to the point where everything is almost working.

However, I need help in two areas.

First, is there a way to have TFM make its decisions on a modified version of the clip, but then operate on the original clip? Much of the film I am transferring has sections that were poorly exposed (low contrast). TFM's comb detection, which on normally-exposed film works well, fails on the portions that are low contrast. A solution to this problem is to use "Levels" to increase the contrast. (Actually, this improves detection even for normally exposed film.) However, I don't want to do the exposure correction in AVISynth, because I can do a far better job later in Vegas (my video editing program). Thus, I want TFM to do its detection based on a modified version of my clip, but than do its frame recovery on the original clip. Perfect comb detection is essential to this process because the only time it occurs is when a video frame contains a field that was captured during pulldown (#3 in my list above). If you download the clip, you'll see that these are normally very easy to see visually, and with normal contrast material, TFM catches them quite easily (although if the pulldown has just barely started, the combing can be pretty slight).

I think I can write values to a file in one pass (using the "output" parameter) and then read them back in the next pass (using "input"), but I thought I'd ask if there is an easier way to handle this. The "clip2" parameter seems like it might be designed to do this, but I am not quite sure whether it can do what I am trying to do.

Second, decimation in my film transfer system cannot strictly be "1 of n" because the ratio of the projector speed to camera capture speed is not synced and is not absolutely, perfectly constant. I can get pretty close using cycleR=9,cycle=44 in tdecimate, but I still end up with a few duplicate frames (obviously I want to err on the side of having duplicates rather than drops). My current solution is a real kludge: I write parameters to a file, and then based on those parameters, create a file that can be read by MultiDecimate. Given that AVISynth has to know the total number of frames when it loads a file, this may be the only way to make arbitrary decimation work, but I'd thought I'd ask.

[Fizick]

johnmeyer,
A little offtop, but do you know about my GetDups plugin?

[johnmeyer]

A little offtop, but do you know about my GetDups plugin?

No I don't, which is surprising because I thought I had used everything you've ever written. I'll go right now to check and see what it does.

[johnmeyer]

Very interesting plugin. It is close to what I was looking for, but it appears to be "hard-wired" for 16.67 fps. The projector I am using uses a synchronous motor that is set for 24 fps. Because of belt slippage, etc., it actually doesn't run precisely at that speed, so the decimation can't make any assumptions.

Even though I may not be able to use GetDups, I found HotSpot, which may help me eliminate the residual hot spot from the condenser/aerial lens arrangement I am using.

[Revgen]

@johnmeyer

The clip2 parameter allows you to use deinterlaced frames from another source instead of using TFM's own postprocessing. I typically use this feature to postprocess my clips with EEDI2.

However, it doesn't allow you to process a different video than the one you analyse.

I'm not a programmer, but I don't think it would be too hard for Tritical to add this. Just go to his website (http://bengal.missouri.edu/~kes25c/) and you can find his email at the bottom of the page.

[johnmeyer]

I think I just about have this figured out. With all the new controls in the latest versions of TFM, coupled with the "new" (to me) "Output" capability, I can output all the TFM decisions to an external file. From this, using my own software, I create an input file that MultiDecimate can use in the second pass. Since the whole thing has to be two passes, I use the Levels filter to increase the contrast on the first pass in order to get MUCH improved field matching and comb detection. I then, in the second pass, use the identical script, but without the Levels filter, but WITH the Multidecimate filter, using the external file I created as input.

The only thing I haven't yet figured out how to do is to get TFM to use all the decisions that it made during the first pass. The problem is that without the Levels filter, TFM wants to choose different fields. I'm still stumped on that.

Also, I'm posting elsewhere about a separate, smaller problem, namely that the film apparently wiggles sideways in the gate in the projector, sometimes causing the two good captured fields to not align. I need to figure out how to take each recovered frame from TFM and then re-align the two fields using Depan. I can get this to work field-to-field-to-field, but I don't want it to work between the second field of one frame and the first field of the next frame; I just want it to line up the two fields from one frame.

[foxyshadis]

input=YourOutputFile.txt

Thus, the results of the first pass are imported and no testing takes place (faster that way, too!).

I'm glad to know I'm not the only one who does things to filters they were never meant for. ;)

[johnmeyer]

input=YourOutputFile.txt

I'll work on that tonight and tomorrow morning and see how it works. Thank you!!

Yes, I'm definitely using this in a way that wasn't intended. I have a "Workprinter" for transferring 8mm movies, but when it came time to do 16mm, I couldn't bring myself to spend $2,000 for the equivalent machine in the larger format. I started to build my own, but after I took out the projector's shutter and started to think about things, it became clear that once the projector shutter is gone, if you captured using a REALLY fast video camera shutter speed (e.g., 1/1000 second), you would be absolutely assured of getting two consecutive fields of video for each frame of film. As I looked at the timing diagrams I drew, they looked identical to the IVTC problem, and that's how I ended up here.

The darn thing really works: "Workprinter" discrete frame film transfer, but at full 24 fps, including sound. My next step is to do the transfer with my HDV camera, something that cannot be done with workprinter (because HDV uses long GOP and therefore you cannot do frame-by-frame "grabs").

[tritical]

Running tfm with output="" on the adjusted clip and then using the generated file as input when processing the normal one will work (it will use the matches and combed frame decisions from the input file). The one thing you will probably have to do is adjust the crc value stored in the file as it most likely wont match the non-adjusted clip. To get the crc for the non-adjusted clip use the output="" option to generate a file for it (it doesn't need to process any frames, just load the script in vdub and then close it). Once that file is generated just copy the crc value from it into the other output file. The crc value is computed from the first 15 frames of the clip.

[foxyshadis]

Or just delete it like I do. :p

Anyway, Tritical, so far the new EEDI2 hasn't crashed on me yet, so I guess that was it. Thanks! I haven't strenuously tested it, if I do happen to catch anything later I'll give you a heads up.

[aichan]

@tritical
my 2pass problem not worked out yet, alternatively i used 1 pass NTSC hybrid. when i compare the picture quality,2 pass tivtc is better than 1pass. btw, 2pass tivtc script is mkv vfr right? but i used it on mp4, is that okay?

i think yes, Megui detected it as hybrid film interlaced.

i'm going to try your suggestion, doing the 2nd pass with 2nd tivtc script. but if i do this, what about the 1st pass tivtc script?

thx

[tritical]

I forgot that deleting it would also work. For backwards compatibility with super old versions a crc value isn't strictly required to be present :D.

@aichan
btw, 2pass tivtc script is mkv vfr right? but i used it on mp4, is that okay?
The 2 pass vfr mode will only work when muxing to mkv as the final container because the a/v sync is maintained by using the generated timecode file when you mux the video. Even though mp4 supports vfr, there is no way to do this when creating an mp4 file (that is, there is currently no way the user can directly specify frame durations for individual frames in the same way you can with an mkv timecode file). AFAIK, the only ways to create an mp4 file with this type of vfr are:

1.) encode each fps section separately to mp4 and then concatenate them.

2.) use my tc2cfr program with the timecode file that tdecimate generates as input to generate a 120fps avi file. Then mux that avi file into mp4 which should remove the null frames. Of course, this method requires the video to be in the avi container.

I would recommend reading http://www.avisynth.org/VariableFrameRateVideo if you haven't already.

i'm going to try your suggestion, doing the 2nd pass with 2nd tivtc script. but if i do this, what about the 1st pass tivtc script? My statement wasn't very clear. I just meant the relationship between tivtc passes (for 2 pass vfr) and codec passes (when doing a 2 pass encode with xvid/x264/etc...) needs to be:

1.) run 1st tivtc script - no codec pass
2.) run 2nd tivtc script - codec first pass
3.) run 2nd tivtc script - codec second pass

which you were probably already doing.

[tritical]

[link removed], changes:
TFM:
+ minor field matching improvements
+ optimized postprocessing (mmx/sse2 cubic/blend deint, mmx/sse2 motion
map creation, mmx/sse2 clip2 mask copy, faster link/denoise routines)
+ added ovr help information listing to bottom of output file
- call setcachehints for clip2 when used

TDecimate:
- fixed opt parameter not be respected in the blurring functions used
when predenoise=true

RequestLinear:
- fixed not testing if n <= rlim if the current request was <= to the last
request (it was only testing if rall=true)


The ovr help info that gets added to the end of tfm's output files lists the following:
1.) detected combed frames
a.) frame #, mic value
b.) ranges allowing small breaks with non-combed frames

2.) possible missed combed frames
a.) frame #, mic value

3.) u/b and against order (either n or p) matches
a.) frame #, match

[tritical]

[link removed], changes:
+ optimized combed frame detection functions (now match tivtc)
+ added second spatial combing metric and "metric" parameter (same
as tfm and is/showcombeditvtc)
+ optimized denoise routines
+ improved the field comparison routine (now equal to slow=0 in tfm)
+ mode 2 uses the field comparison routine instead of full frame
subtract for determining the best matching frame (more accurate)
- directly assign frames from emask clip (no need to copy)
- changed blim default to -2.0 (disabled)
- call setcachehints for emask/edeint clips when used

While working on tdeint I noticed a bug in one of tivtc's mmx routines that is used during combed frame detection on yuy2 clips in tfm/iscombedtivtc. It will only be used if you do not have a processor which supports isse or sse2... a workaround is to use opt=0 in tfm and iscombedtivtc. The bug will be fixed in the next version of tivtc.

As far as tdeint/tivtc go, the following are left on the list of things to do:

tdeint:
1.) possibly add slow=1/2 and mchroma field matching functionality so that tdeint matches tfm
2.) html doc

tivtc:
1.) hclip for tdecimate hybrid=1/3
2.) fix bug in mmx routine
2.) html docs

I would like to get that stuff done and release final versions sometime soon. I've made some improvements to eedi2 so there'll be a new version of that as well. After that I'm planning to finally get back to making a motion masking filter capable of producing longer masks (8 or more fields) to be used with tdeint via the emask parameter.

[malouf]

Hi,

I have a problem with TDeint. I'm using it to deinterlace an interlaced video, captured from a videogame with a capture card.

It works wonderfully, except on some frames (pretty rare), that I found are normal interlaced frames, but repeated 2 times or 3 times, probably a bug when the stream was captured.

The problem is that the 2 identical frames are interlaced, and handled like 2 different frames by tdeing, and it generates some very ugly artifacts... And if I just delete them, I have a sound that keeps getting more out of sync.

Is there any parameter that can be used to not have this problem, or something I can do on the video before deinterlacing it? A perfect thing would be a parameter on tdeint that tells it to ignore a frame when it is perfectly identical to the last, and just output a duplicate deinterlaced frame (to keep sound sync).

Anybody had this kind of problems?

Thanks.

[Fizick]

tritical,
thanks for update!

May be somebody can help you with html doc,
in order to you concentrate on programming?

[aichan]

@tritical

oh..okay.. i see now about it.

i'll try to mux it to mkv later..

thx :)

[DarkNite]

@malouf

Some things you could try are the functions mentioned previously in this thread using eedi2 in cunjunction with tdeint.

If all else fails: I use FreezeFrame (http://www.avisynth.org/FreezeFrame) for issues where I know the frames that are consistently giving me problems (or rather giving the automated solution problems). Then again, I'm used to using YATTA and most people just aren't that masochistic. FreezeFrame would be used best after deinterlacing and before anything else.

In bad game captures I would use it before the motion blur to replace the usual junk frames here and there with the previous or next frame. If it's a duplicate frame or static scene no one will ever know, but if it's a hard panning sequence it may introduce a stutter.

[malouf]

Hi,

I tried the method with eedi2 and tdeint, it produces the same artifacts at the same place...

And for freezeframe, the problem is that I need to have something that works automatically on every video, I make lots of videos, and don't want to review them frame by frame to correct them :-(

The ideal solution would be that tdeint, before deinterlacing, checks if the current interlaced frame is perfectly identical to the previous one. If it is identical, just output again the last progressive frame. I guess it wouldn't be difficult, but maybe I'm mistaken ?

I can post a small part of one of the videos that has the problem, maybe it would be more clear?

[johnmeyer]

[See last line of post, if you don't have time to read all this].

I am getting occasional failures in the TFM v0.9.12.1 matching. I have tried every mode, each option for slow, and each option for micmatching. What happens is that the MICS parameters show, for example

p=0, c=5, n=25, b=4, u=0

yet TFM chooses the current rather than the previous field. 99.9% of the matches are correct. Here is the script:

converttoYUY2(interlaced=false)
AssumeBFF()
colorYUV(autogain=true)
tfm(display=true,micout=2,mode=7,cthresh=115,mi=35,pp=1,field=0,metric=0,micmatching=3,slow=1,sco=-1,debug=false)

and here are two frames that are at the same point in the cadence. The first one shows TFM not doing what I want it to do; the second shows what I think is the correct operation:

[1568] TFM: mode 7 - non-linear access detected!
[1568] TFM: frame 10693 - comparing c to p (SLOW 1)
[1568] TFM: frame 10693 - nmatches: 547252 vs 827794 (1.5) mmatches: 106221 vs 128984 (1.2)
[1568] TFM: frame 10693 - match c: Detected As NOT Combed! (6 <= 35)
[1568] TFM: frame 10693 - match p: Detected As NOT Combed! (0 <= 35)
[1568] TFM: frame 10693 - final match = c MIC = 6
[1568] TFM: frame 10693 - mics: p = 0 c = 6 n = 256 b = 256 u = 0
[1568] TFM: frame 10693 - mode = 7 field = 0 order = 0 d2vfilm = F
[1568] TFM: frame 10693 - CLEAN FRAME


[1568] TFM: mode 7 - non-linear access detected!
[1568] TFM: frame 10704 - comparing c to p (SLOW 1)
[1568] TFM: frame 10704 - nmatches: 1186349 vs 1009180 (1.2) mmatches: 583070 vs 500389 (1.2)
[1568] TFM: frame 10704 - match c: Detected As NOT Combed! (10 <= 35)
[1568] TFM: frame 10704 - match p: Detected As NOT Combed! (5 <= 35)
[1568] TFM: frame 10704 - final match = p MIC = 5
[1568] TFM: frame 10704 - mics: p = 5 c = 10 n = 256 b = 256 u = 0
[1568] TFM: frame 10704 - mode = 7 field = 0 order = 0 d2vfilm = F
[1568] TFM: frame 10704 - CLEAN FRAME


As you can see, in the first case (frame 10693), p=0 and c=6, yet TFM chooses c. In the second case c=10 and p=5, and it correctly chooses p.

...

I just took a break before posting and looked some more. I think that any time either c=0 or p=0, TFM makes the wrong choice. It is as simple as that. Let me know if this is correct.

[Edit] Update a few minutes later. My input is NTSC DV (BFF). However, I tried changing field to field=1, and it seems to work better. So, field=0 and also field=-1 preceded by AssumBFF() both create the problem.

[tritical]

@malouf
The problem is that tdeint's motion check is only 5 fields, 2.5 frames, so if an interlaced frame is repeated one time the chance that interlaced areas will be declared static and weaved is high. If such a frame is repeated twice then it will definately be declared static. Having tdeint check for absolutely identical frames and consider all pixels to be moving would prevent the artifacts, but definitely wouldn't be good for normal operation. You could try using securedeint() which produces longer temporal masks (which should prevent the problem)... or you might be able to hack up a function in avisynth that checks difference to previous frame and if it is zero replaces the frame will all white (255), which should make it be detected as moving.

@Fizick
If someone wanted to help on the docs I definitely wouldn't say no :D. So far I have manged to convert most of the stuff for tivtc except for the two biggest readmes (tfm/tdecimate).

@johnmeyer
Would you be able to post a clip that I could test with? Your settings seem strange off hand... specifically mode 7 and cthresh=115. Also, the MIC values aren't normally used for selecting matches, but only for determining which frames are combed. The nmatch/mmatch numbers generated by the field matching routine are what determine which match is chosen (lower is better). With micmatching enabled the MIC's can override the match decision, but the 0 vs 6 difference in the first example isn't large enough to trigger it (with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).

@All
I found another little bug in eedi2 that could occasionally cause an access violation by reading/writing 8 bytes past the end of a buffer. The affected routine is only used if the input is yuy2 and the cpu supports sse2. I'll try to put up a fix sometime soon.

[johnmeyer]

Would you be able to post a clip that I could test with?
Here is a link (good for seven days) to a short DV AVI clip, along with the script I am currently using:

http://download.yousendit.com/16F3395A7B1B6689

Frame 9 is where the problem occurs. If you change the Field parameter from 0 (which is where I think it should be for NTSC DV) to 1, TFM works.

Your settings seem strange off hand... specifically mode 7 and cthresh=115.
Yes, I have changed those. If you look at the script in the above download, the TFM line that is commented out that is directly above the one that I made active just for your testing, is the one I'm actually using now. The reasons for the strange settings is that this is the script for recovering matched fields from my film to video transfer device (see my earlier posts). With this device, I will get two good fields for every frame of film. The next field will either be a field captured during pulldown, or will be a third matching field. If it is a field captured during pulldown, the resulting frame will appear combed. I throw that out.

(with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).
Would it be better to use blockx/y = 4?

I actually made a test DVD last night, and I almost have this working. I export the TFM parameters in pass one, import it to Excel, and use Excel formulas to look at the TFM values to create a decimate file. In pass 2, I feed that file to Multidecimate, and feed the almost-unaltered (after removing the CRC line -- thanks for that hint) pass-1 TFM parameters file back into TFM.

In the second pass, I remove the "colorYUV(autogain=true)" line.

Speaking of autogain, for anyone reading this thread, I found -- at least in my application -- that using autogain makes a HUGE improvement in the consistency of TFM's matching. Many of the movies I am transferring consist of poorly exposed, low contrast footage, and as the exposure and contrast changes, so do the TFM matching parameters. Using Autogain equalizes things sufficiently that I can use one script for the entire reel of film.

In fact, the improvement is so good that I suggest that if there is a way to feed an autogain version of a clip to one instance of TFM, and then have the resulting parameters be used by a second instance of TFM to actually operate on the clip it might be a very worthwhile addition. This way it wouldn't require two passes (although my application will still require a second pass because I don't have a predictable "n of m" decimation pattern).

In summary, now that I understand that MICmatching requires a bigger difference, I can try to deal with that, so I guess you don't need to look into that any further. However, I still think that there is something strange going on with the Field= parameter. I get all sorts of combing artifacts with Field=0, and none with Field=1, even though I am using a DV source.

Finally, I have read your documentation 100 times, and read through every post in this thread, but I can't find the answer to this:

What does "MIC" stand for?

[HOLiC]

Hello, I'm trying to encode hyrid video to mkv-vfr using megui as an encoder, and Tivtc filter. But I'm having a problem using one pass method as you can check in this post:
http://forum.doom9.org/showthread.php?p=814055#post814055

I don't know the reason for this error message in megui, but using two pass method, i was able to open the script via megui!!

in your read me:

7.) NTSC, two pass (enables use of conCycleTP parameter) mkv vfr for hybrid source.

First pass:

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",output="matches.txt")
tdecimate(mode=4,output="metrics.txt")

Second pass (anime or cartoon):

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=1,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")


I understand that I have to play the first pass to get the metrics, and then encode using second pass script.. What I don't know is.. is it okey if my output file is mp4? (but I plan to mux with aac, and timecode to MKV using mkvmerge) Or do I need to make output file to mkv right away? And I also plan to do 2pass encoding, and I read in the avisynth site, that vfr encoding will mess up the bitrate calculation..? Is this still apply?


from: http://www.avisynth.org/VariableFrameRateVideo

If you're encoding to a specific size using a bitrate calculator, vfr decimation will mess up the calculations. To make them work again add these to your script:

Before decimation:

oldcount=framecount # this line must be before decimation
End of script:

oldfps=framerate
averagefps=(float(framecount)/float(oldcount))*oldfps
assumefps(averagefps).Nicefps()


Do I have to apply above script if i want to do 2pass mkv-vfr encoding? but I tried nicefps(), and it just gives me an error message. Any feedback would be great! Thanks!!

[foxyshadis]

You don't need nicefps (which is a separate plugin, see warpenterprises) starting with Avisynth 2.5.7 alpha. All that part does is extend the length of your newly decimated video to be exactly as long as your old video, so that all bitrate calcs are kept in sync, so yes, unless you want to do the algebra yourself every time (or use a quality-based encode), you do need that, whether 1 or 2 pass.

You can output mp4, but you still have to mux to mkv. But see the updated version of the guide (http://www.avisynth.org/mediawiki/wiki/VFR) for a few more options if you want to end up in mp4.

1-pass vfr can't be seeked into, and megui always seeks to the middle frame if you open the preview, so set it to not open the preview and you should be okay. Another problem is you can't really correct the bitrate skew in 1-pass mode, so you might have to go quality-based for that.

[foxyshadis]

I'm just kind of curious, but what sort of improvements are in store for eedi? Anything I should wait around on, or just minor speed/quality tweaks? (I've been using it a lot lately on some too-small stuff, helps a lot.)

[HOLiC]

You save me again, foxyshadis!! :thanks:

[Fizick]

tritical,
again about html doc.

Do you know, that avisynth 2.56 includes Tdeind and TIVTC html doc ? :)
(outdated a little, of course, but formatted).

[swaaye]

I'm getting an error with TFM "Illegal Transitions found in dvd2avi file". It makes me a "fixed" file that still gives the error. 2 out of about 15 episodes have this issue, using identical settings.

edit: I think the fixed file is working after all.

[tritical]

First, sorry for the lack of responses... I've got a big project due in two weeks and I'm having to spend insane amounts of time on it.

@swaaye
It appears your problem was fixed? If you do have a d2v file that tfm generates a fixed version of and then says something is wrong with the fixed version could you post it somewhere?

@Fizick
Yep, I know that tdeint/tivtc html docs already exist.. I've been using those as the basis for the new ones (updating, rewriting, and layout changes).

@foxyshadis
The main changes are to making it more stable with larger search areas (new default for maxd will be 24) and better at connecting lines with very small slopes. I've changed some hard thresholds to relative thresholds based on the angle direction and added an extra gap/hole filling routine to the edge map filtering and directon map filtering. Due to the new defaults and extra processing it is a little bit slower.

@johnmeyer
I'll try to look at the clip tommorrow though it sounds like you've found a method to accomplish what you need. The problems you have with the field parameter may be related to using mode 7 in tfm. In mode 7 tfm internally switches the field parameter between 0/1 (it starts out on the initially set value) based on combed frame detections to try and follow a specific pattern found in some field blended material. In almost all other cases you want to always match of the same field to maintain smoothness. Try using matching mode 0 or 1 and setting field=0 and then field=1.

I guess MIC stands for "max (or maximum) interlacing count". Originally, tfm never kept track of the "MIC" value it just checked to see if any of the blocks in the image produced counts over MI. When I decided to start keeping track of the values I just added C onto MI to get MIC for a new variable name.

[johnmeyer]

I gave up on mode 7 shortly after my post and have been using mode 0. Still haven't been able to get reliable detection in low motion areas. However, I am now trying to create my own decimation routine that uses a form of guidance that is based on my unusual application. I'll post back here when I've either got it working, or have another question.

[Alizar]

Tritical:

I'm sorry to bother you, but I've noticed a weird output bug with tdecimate. Sometimes it simply refuses to write out the stats using mode=4 and specifying an output file. I run the pass to collect the stats, the file is created, but it stays blank. Any notion what I might be doing wrong?

[foxyshadis]

The file won't be flushed until virtualdub (or whatever is running the pass) is closed. Closing the video with ctrl-W and reopening off the recent menu is what I always do. Must have the biggest buffer in the world or something...

[JuanC]

TDecimate request: exclusion band of lines (y0/y1) as in TFM.
Hi Tritical, This is a humble request: I regularly do NTSC analog TV captures that are telecined material broadcasted with the original audio and the subtitles (interlaced!) with the translation blended on top of the telecined material. The exclusion band of lines (y0/y1) for TFM has allowed me to successfully match the fields correctly. This is great! But the subtitles are still causing me problems with TDecimate:

After using TFM, the telecined material is correctly matched, but almost every frame where each subtitle starts or ends (only the first and last frames where the subtitle appears) is detected as combed because of the subtitles. These “combed” frames (2 on each subtitle, with 2000+ subs gives more than 4000! on a 20 minutes capture) interfere with TDecimate metrics calculation resulting in the wrong frames being deleted, and if hybrid > 0 with unnecessary 30p to 24p frame blending processing.

I have also tried setting PP=0 and hints=false, but the metrics calculation on TDecimate gets confused by the subtitles, particularly if the subtitles starts or ends exactly on a duplicated frame (the ones that should be decimated).

Last night I discovered “MergeHints” on your TIVTC package, which allowed me to get better results by excluding from the TFM hints generation the lines where the subtitles are, using this AVIsynth script: (704x480 yv12 material)
Save_Hints=crop(128,64,480,288,align=true).Tfm(order=1, mode=0, PP=0)
Tfm(order=1, mode=0, y0=352, y1=448, PP=6, Hint=FALSE, opt=3) #, display=true)
MergeHints(hintClip=Save_Hints)
TDecimate(Hint=true, opt=3, hybrid=0) #, display=true)
One could of course get these or better results, easier and a lot faster, if there was an option in TDecimate to exclude lines that contain the subtitles when doing the metrics calculation, just like it is in TFM.

I hope you’re doing well with your project, and I’d like to thank you for the time and energy you devote to this filters you give us all.

Regards, JuanC

[minos5000]

I've a question concerning the speed. I use these settings for VDub to convert my captured movies into Xvid


LoadPlugin("c:\avisynth\dgmpgdec146b2\DGDecode.dll")

audio=MPASource("c:\Charmed.-.S03E04 T01 DELAY 96ms.mpa")

video=MPEG2Source("c:\Charmed.-.S03E04.d2v")

video=TDeint(video,order=1).lanczos4resize(720,540)

AudioDub(video,audio)



The quality is really great but I'm not so happy with the perfomance as it dropped by 50% from 30fps to about 16fps. Ist this loss normal or are there any improvements possible?


so long

[scharfis_brain]

every filter has an impact on encoding speed.
so will tdeint.

and 16fps still are a reasonable good speed.

So it seems you never got into the range of spf for your encoding speeds (spf == seconds per Frame)

[foxyshadis]

If your system can't handle realtime tdeint, try leakkerneldeint. It's much simpler and faster, even though it tends to have more issues than tdeint.

A couple of ways to speed up tdeint are, use mtnmode=0 or 2, denoise=false; you should try mtnmode first.

[tritical]

@Alizar
As foxyshadis said, the file is created in tdecimate's constructor, but the data isn't actually written into the file until the tdecimate object is destroyed (happens on script close). The main reason for doing it that way is that it ensures the metrics will be in order even if frames aren't requested in linear order. That point doesn't really matter for reading the data back in, but it helps if you want to manually examine the stats file. I could change it to write to the file each time a frame is processed, but I don't see any real advantage... if you want to see the results for a frame immediately use the display option.

@JaunC
An exclusion band for tdecimate is a good idea... though it's a little more tricky to do than for tfm. The other issue brought up by your example is that the y0/y1 bands in tfm currently only effect field matching comparisons and not combed frame detection which doesn't make sense. I'll change that in the next release.

[foxyshadis]

Alizar told me offline that it actually wouldn't write the stats even after closing, even after multiple open-play-close cycles, so I'm afraid it was something else. No error message came up.

[tritical]

I take it that there isn't a set of steps that always cause the problem? I've personally never had it happen. The only thing I can think to do is put up a special build with some extra debug output to see what happens. I'll try to put one up later tonight.

EDIT:
Test Build (http://bengal.missouri.edu/~kes25c/TIVTC.dll)

Just have debugview open to catch the output strings and post the log here or pm it to me... it should show why it is failing.

[johnmeyer]

Say, if you're going to do anything with extra debug output, is there any chance that you could include a "verbose" function for the output file that would include the MIC values? Currently I am having to output via the debug mode and then parse that file to get both the p, n, c decision made by TFM, along with the MIC values. In my application, I have created an external parsing application that looks at the MIC values and uses that to determine where to override the TFM decisions. This is not a huge deal, but it would save me some extra work of parsing the debug file. What I am proposing is taking the current TFM Output file that looks like this:
31 n - [56]
32 c - [8]
33 c - [0]
34 n - [3]
and add the MIC values:
31 n - [56] 96 83 56 0 104
32 c - [8] 104 8 71 56 61
33 c - [0] 61 0 20 71 91
34 n - [3] 91 79 3 20 56

[JuanC]

@JuanC An exclusion band for tdecimate is a good idea... though it's a little more tricky to do than for tfm. ... It's great you like the idea. I hope there could be a chance for it in the future. @JuanC ... The other issue brought up by your example is that the y0/y1 bands in tfm currently only effect field matching comparisons and not combed frame detection which doesn't make sense. I'll change that in the next release. You know, I found it convenient, so that I can use PP=6 to deinterlace the subtitles at the first and/or last frame(s) where they appear. Is there a chance 'combed frame detection' could be optional for the exclusion band ?

Thanks for your comments, Juan

[tritical]

@johnmeyer
Yep, I can add that.

@JuanC
I'll make using the exclusion band in combed frame detection optional.

I'm still busy working on stuff for school, but should finally have free time next week to do some work on tivtc.

[swaaye]

either TFM or TDecimate is crashing on me for the first ep of Stargate SG-1. It will run for a few mins of the D2V but then the encode will just stop and Staxrip will move to the next pass and this will stop out too. I switched to telecide/decimate and that works so it must be a TIVTC bug. Can I send anything to help with this?

I've also been having a problem with a interlaced frame sneaking in after every scene change. Telecide/Decimate seem to not have this problem. I read that it could be a frame order switch problem with the DVD.


tfm(d2v="%source_file%")
tdecimate(hybrid=1)


vs. (didn't bother setting it up properly for hybrids cuz it isn't very good at that anyway)

Telecide(guide=1).Decimate()

[tritical]

If you could post a clip that causes a crash it would help. Otherwise, I have no idea where to start looking for a bug. Also, does it crash if you open that script with only tfm+tdecimate in vdub and encode? If so, then try taking out tdecimate and see if it still crashes (would at least narrow it down to either tfm or tdecimate).

If combed frames are getting through then you need to tweak the combed frame detection settings (MI, cthresh)... using display=true in tfm will help.

[swaaye]

Well it's TFM that's crashing. With just MPEG2Source and TFM in the filter stream, the clip will crash within 20 seconds of the show. I'm not really sure how to send you a part of the VOBs though....

I don't know if this is useful or not, but DGIndex says "Warning! Opening GOP is not closed. First few frames may not be decoded correctly". I've ripped the DVD a few times and it always has this error. I also tried using Trim to force TFM to work on a piece deeper in and it still crashes in that area too.

[tritical]

You can upload the vob to my ftp:

ip/port = 68.184.14.253:17252
user/pass = upload/upload

If you want to you can cut a chunk from the vob using dgindex (save project and demux video) or just stop the transfer after enough has been uploaded to reproduce the problem.

The open gop warning from dgindex wont effect things.

[swaaye]

I uploaded a test set of D2V, M2V, and AVS to your FTP. swaaye prefix on the files. It will crash Vdubmod very quickly on you.

[tritical]

It doesn't crash here on my comp so I've got a few more questions... What type of cpu do you have? If you set opt=0 in tfm does it crash? If you set pp=0 in tfm does it crash? What version of avisynth and tivtc are you using?

[swaaye]

It doesn't crash here on my comp so I've got a few more questions... What type of cpu do you have? If you set opt=0 in tfm does it crash? If you set pp=0 in tfm does it crash? What version of avisynth and tivtc are you using?

Setting pp=0 solved the crashing. pp=3 crashes as well. All other levels of pp are stable. Opt didn't help.

AVISynth 2.5.6a (StaxRip installs it)
TIVTC - 2006/04/09 v1.0 RC 3

I'm running a dual core Opteron 165. I've encoded roughly a bazillion (:)) vids with this setup and I think this is the first time I've had crashing problems with your filter. Though I haven't used this version of TIVTC much.

[tritical]

Yep, it's a problem with the combination of field=0 and cubic deint (pp=3/6) due to a change made in the last release. I'll put up a fixed version tommorrow.

[tritical]

[link removed], changes:
TFM:
+ output file generation is now effected by the micout parameter
+ if micout > 0 then calculate/output mics even when an override
or d2v match is used
- fixed a bug introduced in the last release in cubic deint pping (pp=3/6)
- fixed a bug in one of the yuy2 checkcombed mmx routines

[swaaye]

... :) glad to help.

[johnmeyer]

tritical,

Many thanks for the verbose output option. Makes my job a lot easier.

[Chainmax]

In my latest encode, using EEDI2 v0.91, TDeint v1RC7 and TIVTCv1RC4 resulted in some artifacting on several scenes. Here are some sample comparison screenshots:

MPEG2Source + ConvertToRGB:
http://img339.imageshack.us/img339/2373/source9je.png (http://imageshack.us)

Filtered:
http://img429.imageshack.us/img429/1121/result3tc.png (http://imageshack.us)


Here's the script I used:
mpeg2source("X:\wherever\GNS.d2v")

ColorMatrix()

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

Crop(8,2,700,466,align=true)

Levels(0,1,255,16,235)

hqdn3d(0,0,3,3)

DeGrainMedian()

aWarpSharp(depth=16,cm=1)

Lanczos4Resize(656,448)

DeHalo_Alpha()

LimitedSharpenFaster(SMode=4,LMode=3,Strength=200)

AddBorders(24,16,24,16)

ConvertToRGB()

(I put the ConvertToRGB lines in both scripts for a more accurate comparison as I'm using VDubMod)

This is much more frequent and evident in a previous high motion scene. I'll be trying just TIVTC soon, and get back with results. In the meantime, what do you think is the cause of this?

[foxyshadis]

Try using upconv=true in the Mpeg2Source, that might be bad chroma sampling. You can convert back to yv12 progressive after ivtc.

Since it's R1 the chance of an interlaced resize is pretty slim, and the field-blending would be more noticable. That'd be the other main reason for the artifacts.

[Chainmax]

I'll try upconv=true (how do I convert back to progressive yv12 after ivtc?) and report back. By the way, this comes from an R4 NTSC disc.

Anyway, I tried to IVTC with this

TFM(mode=3,PP=7,slow=2,mChroma=true)
TDecimate(mode=1)

and got pretty much the same result. You can download a sample vob with this scene and the high motion one I mentioned here (http://rapidshare.de/files/21733359/Sample.vob.html).

[Chainmax]

What do you know, upconv=1 eliminated the issue, thanks :). Now let's see if I can eliminate that annoying blocking in the sample without oversmoothing...

[scharfis_brain]

I simple do not have this problem at all...

[tritical]

@Chainmax
Do those artifacts occur if you use

colormatrix(interlaced=true)

w/o using upconv=1 in mpeg2source()? For interlaced yv12 interlaced=true needs to be set, but for yuy2 it doesn't effect things (might be the reason upconv=1 in mpeg2source fixed the problem). Guess before that question I should ask if the artifacts still occur if you don't use colormatrix at all?

[Chainmax]

I didn't try that, will do so and report back.

[edit]Both eliminating colormatrix and using it with the interlaced=true switch solved the problem as well. I didn't know that switch existed, as all the references to it in threads only used defaults.

[tritical]

EEDI2 v0.9.2 (http://bengal.missouri.edu/~kes25c/EEDI2v092.zip), changes:
+ various internal changes to help reduce artifacts around repeated
patterns and to improve construction of lines/edges with small slope
- Changed map from bool to int
- Changed default maxd value from 12 to 24
- Changed default pp value from 0 to 1
- a few minor bugfixes

After some thinking, I've figured out how eedi2 could be changed into a general purpose resampler able to resize to any requested resolution in one step. I think this could provide much better results than chaining multiple eedi2 calls together. I am busy on other projects atm so it wont happen immediately, but it is on the todo list for eedi2... hopefully the next release of eedi2 will have a general resize mode.

[Guest]

Thanks for the new version! :thanks:

[Chainmax]

Yeah, thanks for this new release :). The next release should greatly help me out on some of the stuff I've been messing around with, can't wait for it :).

[Adub]

This new version is wonderful news Tritical, thanks for your work.

[Revgen]

This new version is wonderful news TSP...

Don't you mean Tritical?

[Adub]

Oops!!! Sorry about that, I am browsing to threads at once.

[foxyshadis]

btw Tritical, whenever you find time to pick this filter up again, here's an interesting approach that may or may not speed some things up: http://www.compuphase.com/graphic/scale2.htm However, his result isn't as good as NEDI, so it may not be suitible.

[tritical]

His method is definitely quick, but the results aren't all that great. Using the gradient direction doesn't work at all for eedi2's main use of deinterlacing (detecting directions on a single fields) and the area he considers is too small to really be effective. Also, normal first order gradient calculations have a hard time accurately detecting directions of lines/edges with small slope (since they consider only a 3 pixel neighborhood). In his method that doesn't really matter since he also limits the interpolation to 50/50 averaging of a set of the two nearest neighbors. That fact alone makes it unable to accurately adapt to lines and edges that have directions of less than 45 degrees. For comparison I made 2x enlargements of the lena image using eedi2 (http://bengal.missouri.edu/~kes25c/lena-eedi2.PNG), nedi (http://bengal.missouri.edu/~kes25c/lena-nedi.PNG), lanczos3 (http://bengal.missouri.edu/~kes25c/lena-lanczos.PNG), and spline36 (http://bengal.missouri.edu/~kes25c/lena-spline36.PNG) in avisynth. Gotta go for the moment, but more to add later :).

[foxyshadis]

Hmm, ah well. Just something I came across, looking for something else. ^_^ Maybe it'd be useful for coming up with an initial gradient, unless your method is already faster/more precise. Looking at calcDirections, it seems to be a lot more efficient than I first thought anyway. Cool.

BTW Lena. (http://foxyshadis.slightlydark.com/random/lena-ekg.png)

[scharfis_brain]

tritical, how can I tweak EEDI2 v0.9.2 to behave the same like v0.9.1 ?

cause the new version detects a lesser amount of short diagonales as edges.

[tritical]

@foxyshadis
What settings did you use for ekg? I tried to reproduce your result, but with default settings the output is definitely not the same :).

@scharfis_brain
maxd=12,pp=0. Could you post an image(s) where 0.9.2 doesn't connect short diagonals and 0.9.1 does?

[foxyshadis]

ImageSource("lena-org.png",end=0)
converttoyv12(matrix="PC.601")
LimitedSharpenFaster(SMode=4,LMode=3,Strength=100,special=true,wide=true,soft=25)
EKG(20,iter=2,bp=.75,sharp=.6,multi=2,gthresh=1.4)
spline36resize(256,256)
return ConvertToRGB32(matrix="PC.601")

With a dash of overkill. ;)

My original intuition was that sharpening should be applied harder at every successive step to make up for the larger image, but that turned out to severely distort the image, and the new limits placed on it are quite arbitrary. Perhaps I have it the wrong way around; I think I need to indulge in more research in that area.

[johnmeyer]

Does anyone know what the "h" match code signifies:

Here's the line from the TFM output file:

9225 h + [196] (181 196 203 0 125)

It always appears next to the combed frame match (+), but so do other match codes. It doesn't appear anywhere in the documentation.

Edit: OK, I think it means a combed frame, when matching to the current (c) frame. For some reason, in this situation, the "h" gets substituted for the "c." If a combed frame results when matching to the next frame, the usual "n" is used.

[tritical]

As there is no explanation for tfm's output file anywhere, I'll give a brief description and answer the h match question. The format and fields are a mess from hacking in spots to hold new info, and I've tried to go for quick and easy readability instead of data compaction.

basic line format is:

frame_# match combed_frame d2v_duplicate [mic_value] (verbose output)

match can be one of:
p,c,n,b,u,h,l

p, c, n, b, and u are all explained in the tfm readme. h indicates a combed c match where the top field is to be kept (bottom interpolated) and l indicates a combed c match where the bottom field is to be kept (top interpolated). The distinction isn't important for tfm, but is needed by tdecimate for hybrid detection.

combed_frame marker will be either '-' for not combed or '+' for combed. If pp=0 then no mark will be present.

d2v_duplicate will be 1 if the frame is considered a duplicate because of rff flags and will not be present at all otherwise. If d2v is not used or flags=3, then d2v duplicates will not be considered and thus not marked.

[mic_value] lists the mic value for the match used. It is the value before any deinterlacing (i.e. a combed frame should have a mic_value above MI).

(verbose_output) will optionally list the mic values for other matches as indicated by the value for micout.

If pp=0, then none of the mic fields will be populated.

[johnmeyer]

Much appreciated! I am using the additional info that you now put into the output file to do my own MIC override in order to perfect my pattern matching. It works really well (this is for the film projector to video project). I can't tell you how impressed I am with your work.

I'm now doing full 24 fps "Cintel-style" film-to-video, thanks to TFM.

John

[tritical]

@johnmeyer
I'm glad that tfm is useful for your project. If you need any other info just ask :).

@All
Going back to the eedi2 discussion... one of things I've noticed is that when chaining multiple calls together for resizing sometimes changing the order of the turn() calls can make a very large difference in line reconstruction. For example, the lena image (http://bengal.missouri.edu/~kes25c/lena-eedi2-2.PNG) again, but this time using:

turnleft().eedi2().turnright().eedi2()

as opposed to:

eedi2().turnleft().eedi2().turnright()

which is what I used to generate the one in the previous post. In this image (http://bengal.missouri.edu/~kes25c/lena-eedi2-diff.PNG), I've stacked the two images side by side and tried to highlight a few of the major areas of improvement. Notice that most of the areas are edges/lines of >= 45 degrees.

After thinking about it, the reasons for the improvement are pretty simple. First, the vector matching method currently used to detect directions has only single pel accuracy up to the previous and next scan lines. So the angle directions drop off very fast at first (90 at 0 steps, 45 at 1 step, 27 at 2 steps, etc...). This leads to poor accuracy when dealing with edges that have angles of >= 45 degrees. Second, the interpolation of the new pixels is limited to half pel precision at the previous and next lines.. so basically all edges/lines with an angle of >= 45 degrees will be lumped into 3 possible output pixel values. What happens when you rotate the image 90 degrees is that the lines/edges that were previously in the 45-90 degree grouping are now in the 0-45 degree range where the accuracy of angle detection and interpolation are much improved.

I think the most obvious solution is when initially calculating directions to do one pass horizontally (to get <= 45 degree lines/edges) as is done now, and then to do another pass vertically (to get >= 45 lines/edges). Also, when doing the final interpolation, directions of > 45 degrees should use pixels from lines further away than just the prev/next lines in order to get improved accuracy. Of course, there are some fine details to work out, but it shouldn't be too hard to implement. Hopefully this improvement will make it into the next version along with the one step, general resize method. The downside is that this improvement will slow things down to ~3/4 to 1/2 the current speed.

[scharfis_brain]

The newest version of eedi2:
http://home.arcor.de/scharfis_brain/samples/eedi2-new.png

The predecessor of the current version:
http://home.arcor.de/scharfis_brain/samples/eedi2-old.png

I used maxd=12 and pp=0 as you suggested.

[tritical]

The difference is most likely because of the extra filtering step I added to the direction map post-processing. Any way I could get the original clip from you?

[scharfis_brain]

this is the original clip.
http://rapidshare.de/files/23657792/doom9.avi.html

it is pretty good evaluating interpolation algorithms and motion/comb masks

[tritical]

[link removed], changes:
tfm:
- fixed crash in modes 0/4 when pp=0 and micout > 0
- fixed "possible missed combed frames" listing in ovr help information sometimes
including frames that were marked combed via an ovr file

tdecimate:
+ set fps to average value of the clip in mode 5 (so duration stays the same)
+ use 6 decimal places in v2 tc output

I had planned to include a lot more in this release, but I just haven't had the time to do much lately. Things that will eventually get added (as I have promised in various places):

1.) exclusion band in tdecimate+framediff
2.) exclusion band for combed frame detection in tfm+is/showcombedtivtc
3.) option to require 'x' number of blocks above MI for combed frame detection in tfm+is/showcombedtivtc
4.) pp option in tfm that would try to replace combed frames with clean neighbor frames if available

[JuanC]

wow! that's great!

And the features you're announcing will make it even greater !

Thanks again :)

[anonymez]

thanks a bunch tritical! :)

ps has to be said: tdeint is well past RC stages, make it 1.0 final already! ;)

[tritical]

@All
I also updated the avi_tc_package to v1.4. The main changes were:

1.) added avs output option to cfr2tc. The avs file will exactly duplicate the avi file you would get if you ran cfr2tc with avi output. Bascially, it generates a bunch of trim().selectevery().assumefps() lines and then appends the clips together. This eliminates the need to create a new avi file.
2.) added tcConv... it does v1<->v2 conversions.
3.) updated tc-GUI to match.

@anonymez
Yeah, it is pretty much done... though I still have plans to make the field matching and combed frame detection in tdeint exactly the same (working and parameter wise) as tfm. Currently, the field matching in tdeint is equivalent to slow=0+mchroma=true in tfm. The combed frame detection is the same as tfm's atm, but the new options I am going to add to tfm should get added to tdeint as well. At some point it might just be worth it to combine tdeint/tivtc into one.

The main reason I would like to have the improved field matching modes of tfm in tdeint is because it's used in mode 2, which I pretty much use all the time. My usual script these days for anime ivtc is:

mpeg2source("")
inter = separatefields().eedi2(field=-2)
deint = tdeint(mode=2,edeint=inter)
tfm(d2v="",clip2=deint,MI=60)
tdecimate(mode=4+5)

[foxyshadis]

@All
I also updated the avi_tc_package to v1.4. The main changes were:

1.) added avs output option to cfr2tc. The avs file will exactly duplicate the avi file you would get if you ran cfr2tc with avi output. Bascially, it generates a bunch of trim().selectevery().assumefps() lines and then appends the clips together. This eliminates the need to create a new avi file.

Sweet.

2.) added tcConv... it does v1<->v2 conversions.

Very sweet. Does it attempt to use standard framerates, if they're close enough?

[tritical]

No, it doesn't. To get the framerates for v2->v1 it just averages over the duration of the current range... which will get pretty close usually. Afaict, this is exactly what mkv2vfr does, since in my tests converting the v2 output of mkvextract to v1 resulted in fps numbers that matched mkv2vfr's output.

[Chainmax]

...
tdecimate(mode=4+5)

How is that possible? It's probably a typo, right?

[foxyshadis]

Just shorthard for carrying out the full mode 4 and mode 5 translations.

Certainly, it would be interesting to have a mode 9 to do it all, like decombvfr, if only for those generated scripts that don't need to be tweaked... but if we did that we'd have to document that the mode 8 that you seek is not among these modes... ;)

[Isochroma]

I seem to be having some difficulty with tc2cfr. I have an avi file of fps 23.976 which I would like to convert to one with a framerate of 119.880 by inserting null frames at the appropriate intervals. However, tc2cfr wants a timecode file.

It seems according to the documentation that this program will take an avi and add null frames, producing a timecode file in addition. What should I do?

[foxyshadis]

Use this as the timecode file:

# timecode format v1
Assume 23.967

Alternately you can just use vdub, which can do 24 or 30->120 in the same way. (But no hybrid, obviously, and you can't automate it.)

[Isochroma]

Thanks! But I found AVI60, this nice Japanese program to convert various framerate AVIs to 119.880. It works quite nicely, though it's all in Japanese.

Really, someone should make a simple tool that doesn't require in-depth knowledge of obscure file formats. Just something that adds a certain number of null frames to an AVI and doesn't require anything else to do its job.

More than what is needed; less than what is required.

[tritical]

I could make it use the default framerate of the input avi if no timecode file is given, but what is the point of making a 120fps avi out of a source that is all one framerate to begin with?

[Isochroma]

Because I have 3 source files:

#1: 23.976 fps
#2: 29.970 fps
#3: 23.976 fps

They must be merged sequentially. Therefore, they are all first converted to 119.880 fps, then #1 is opened in vdub, then the other two are appended and the resulting file saved as the complete. In direct stream copy mode, the null frames inserted by AVI60 are preserved in the final output AVI.

Next, your cfr2tc app is used with the complete AVI as source. It removes all null frames and generates a v2 timecode file and an AVI with null frames removed.

Finally, the AVI and timecodes file are muxed into a MKV via cmdline (note: the manual and cmdline parameters explanation for MKVMerge does not provide any information on the --timecodes "x:name" function; also undocumented is that despite x used to identify which media track the timecode file applies to, the --timecodes "x:name" string must be preceding the track it applies to, with no other tracks in between.

I found out that if it is listed after, the resulting file will not use the timecodes. Slightly offtopic, but despite its many revisions, MKVtoolnix remains sorely lacking in frontend support for timecode files, both in the GUI (no support or documentation) and the cmdline (support but limited documentation).

Your applications and their GUI are useful as well on another point: AVI60 is both impossible to understand due to Japanese labels and documentation, and has a minor defect: the AVI files produced have a trivial structural corruption that prevents their use in your applications. The manifestation of it is that at the end of processing with cfr2tc an error will be reported. The problem is solved by direct stream copy with vdub; the resulting file is slightly different in size (indicating structural change) but has the same number of frames. And being produced by vdub, of course it works with all apps, including yours. Thankfully vdub preserves null frames in direct stream copy mode as well.

Finally, AVI60 has very limited convert-to options - 60 and 119.880 fps only. The cmdline seems to have other options, but I cannot read Japanese. Your apps have an excellent method of framerate input - the native ratio x/y used in the AVI file structure. Thus they are the natural successors to AVI60 provided they can fully emulate AVI60's functionality.

[foxyshadis]

You know, if you're going to mkv anyway you can just add the first and append the rest into mkvmerge and it'll apply their respective timestamps to the resultant mkv. I just tested to be sure and it worked great.

You also did a good job of highlighting exactly why I asked for avi_tc, if you go back in the avisynth VFR page's history you'll see the rather insane procedure that existed for making 120 fps avis with avi60.

[Isochroma]

Yes, you're correct. However using that method is pretty crude and doesn't present the kind of usefulness that vdub or other vfw applications do.

The idea is to get all avi files to the same framerate via insertion of null frames, so they may be edited/joined/subbed together. Long mkvmerge commandlines just don't do it for me, if you know what I mean :)

[Haali]

mkvmerge discards null frames automatically, if you mux a 120fps avi directly to mkv, you get a vfr file in one step.

[Isochroma]

Ah! Thanks for the info, Haali. There are good reasons to generate a file with null frames first, though. Editing in VFW apps is just one of them...

Was playing around with a lowest common denominator calculator (http://www.murderousmaths.co.uk/books/BKMM4xlc.htm) today and noted that it would be practically impossible to insert enough null frames in a 25fps PAL AVI to get it to LCD with a 29.97fps one (5272378157511475 fps required!).

But it seems that with a 0.1% speedup to 30fps, the 29.97fps clip can be made compatible with everything :)

[foxyshadis]

No, the LCM of 25 and 29.97 is still 150fps - realistically, does 1/1000 of a second judder bother anyone? Cameras aren't even that precise. Although a 0.1% desync doesn't sound like a lot, after 30 minutes you already have a 2 second difference.

It's fairly easy to just switch the framerates and resave in vdub, using direct stream copy, compared to AVI60, and you have more choices as well.

[tritical]

I added the ability to simply specifiy an input fps value instead of using a timecode file in tc2cfr. I updated tc-GUI as well.

[Isochroma]

Thanks! You now have my gratitude & thanks x 2...

[Mug Funky]

yo, to shift the thread in a slightly different direction, i noticed that tdeint(mode=2) doesn't seem to support yuy2. no biggie, as i can either use mode 1 or just switch to tivtc.

also, tryweave and emask don't appear to get along with each other. also no biggie - i was planning to use this but ditched it in favour of another method. but thought you'd like to know regardless.

[tritical]

mode 2 should support yuy2 just fine, but there was a little typo causing it to mess up and throw an error. I'll try to put up a fixed version tommorrow. Also, what do you mean by tryweave and emask don't get along?

[Velocity 7]

I'm having trouble using TFM on this particular video (http://naomi.thewafflehouse.net/testvid.avi). A few of the frames are not getting matched up properly; the low motion seems to be screwing up combing, especially near the end of this panning sequence.

Script I'm using at the moment:

LoadPlugin("TIVTC.dll")
LoadPlugin("mpeg2dec3dg.dll")
MPEG2Source("haruhiep2_3.d2v")
TFM(mode=5, pp=5, d2v="haruhiep2_3.d2v")

Here's another example video (http://naomi.thewafflehouse.net/testvid2.avi) which TFM is having trouble with.

[puffpio]

Hello..
I've used your plugins for awhile now and they always do the job.
However I have clip now that I cant solve

It's 60 fps progressive HD clip
there are two types of video inside
1) 24fps video that has duplicated frames to 60fps in a 'aabbb' pattern
2) 60fps pure video with no duplicated frame

Using TDecimate(mode=1, cycleR=3) I can remove the duplicate frames from #1 segments..but the pure 60 fps video then comes out jerky...there is a hybrid parameter, but that is only when cycleR=1, so I can't blend the 60fps to 24fps..

Im gonna expierment with mode 2 and 7...currently on a mode 4 stats generation pass...

any ideas?

[tritical]

@Velocity 7
Thanks for the clips. I'll do some testing and see if I can get tfm to match them correctly.

@puffpio
Currently, tdecimate doesn't have any way to do what you want automatically. It is designed around 24/30 mixtures. Its hybrid operation could be extended to cases where cycleR != 1, but it would require significant changes that I don't really have time to make atm.

[puffpio]

there's always more than one way to solve a problem..got some good help in the other forum tackling the problem in different ways :P

[tritical]

If the clip2 processing is really slow, you could probably get away with using it on only the final pass without any problems. The only thing that could happen is that the difference metrics calculated by tdecimate happen to be changed enough by the pping difference that tdecimate decides to decimate a different frame or switches its decision about video/film for a certain section. Even if that did happen I don't think it would noticable.

[ChiDragon]

tritical:
Would it be possible to add an option to disable the CRC check for input files? I use output and input files in combination with black overlays as a way to IVTC without having moving channel bugs and bumpers interfere with the proper pattern.

I know it's possible to work around the check by deleting the CRC from the metrics file, but that means I can't do batch processing. As a workaround for batching, I've used this sort of thing in both the analysis script and the encode script:
BlankClip(last,length=20)++last
TDecimate()
Trim(16,0)
This obviously won't work for TFM with a d2v input though. It would also be easier and look cleaner to just have a parameter to set instead of adding and trimming video, of course.

Thanks for your time and for making such a great combination of filters, I use TIVTC and TDeint all the time! :thanks:

[CruNcher]

@tritical
can blends like this get better in future versions ?

http://cruncher.mufflastig.com/hdtv/horror.png

[tritical]

@ChiDragon
Yep, I can do that.

@CruNcher
Probably not. Do a separatefields() on that image and you'll see that the individual fields that make up that frame are actually interlaced. Where did that image come from?

[Carpo]

nevermind problem has been sorted

[rig_veda]

I noticed, that when producing VFR with a TDecimate override of for example

0,2729 v
2730,45863 f

my script produced a timecode that went like:

# timecode format v1
Assume 29.970030
2730,19145,23.976024
19146,19148,17.982018
19149,31912,23.976024
31913,31915,17.982018
31916,37234,23.976024

Now i got curious what internally happens to make it so. Why those sections of 3 frames each that use a fps of exactly 17.982018? Why is it always 3 frames and exactly 17.982018 fps and why isn't the output just plain 23.976024 fps for the whole part markt in the override file as film. I'm assuming it's to keep things in sync, but how does it work behind the scene?
And are these 17.982018 fps sections distributed by chance or do they have a reason to appear exactly where they occur?

[Mug Funky]

you'll get that from a 3-in-5 decimation of 29.97fps...

i suppose you've got anime there, and there's some characters moving once every few frames, a few of which happen to fall on the interlaced part of the 3:2 cycle...

[tritical]

The 17 fps parts are from when tdecimate detects an ivtc pattern change that results in 2 duplicates in the current 5 frame cycle that it is looking at. For example:

nndnn nndnd nnnnd

n = new
d = dup

Is one possible scenario that could occur due to a pattern change. IIRC, the specific things tdecimate looks for when trying to detect this and mode=0 (or mode 5 with vfrdec=0) are:

1.) previous cycle has exactly 1 dup (indicated by matches by tfm and that frame has the lowest difference metric in the cycle)
2.) next cycle has exactly 1 dup (same requirements as previous cycle)
3.) current cycle has exactly two dups (indicated by matches by tfm and those two frames have the two lowest difference metrics in the cycle)
4.) the dups in the current cycle are not directly next to eachother
4.) the position of the first dup in the current cycle equals the position of the dup from the first cycle
5.) the position of the second dup in the current cycle equals the position of the dup from the next cycle

for mode = 1 (or mode 5 with vfrdec=1) those same requirements apply plus a check that none of the frames surrounding the two match duplicates in the current cycle, or any other frames in the current cycle besides the two match duplicates, had metrics < dupthresh (i.e. were detected as metric duplicates).

[Chainmax]

I have a bad NTSC-to-PAL conversion that needs reverting to NTSC in order to regain motion smoothness in some slowed-down scenes that look horrible. In order to do that, the source will be bobbed and then decimated. What would be the difference between using TDecimate(cycleR=2003,cycle=5000) and TDecimate(mode=7,rate=29.97) on it?

[tritical]

TDecimate(cycleR=2003,cycle=5000)

This one will actually break the clip up into sections of 5000, get a difference metric for all frames in a section, and then determine which frames in the section to remove.


TDecimate(mode=7,rate=29.97)

This one doesn't work on sections. It calculates an offset into the stream based on the decimation factor and then based on the difference metrics of a few surrounding frames and how the previous frames that were processed up to that point were decimated, decides whether to keep the frame or not. So this one wont have to sit there for long periods processing chunks of 5000 frames, it also will request all frames in linear order.

I would say that if your clip actually has a strict cycle (i.e. the number of dups in every 5000 is evenly spread and doesn't' vary) then mode 0 would be better than mode 7.

[Chainmax]

I think the source doesn't show a strict cycle after bobbing. You can check a sample [link removed].


[edit]Nevermind, I get an error message saying that 2<=cycle<101 :(.

[tritical]

I forgot that I had it limited internally to a maximum of 300 (the 101 in the error msg is incorrect). I'll try and put up a new version tonight with that limit removed and an option to disable crc checking in tfm/tdecimate. Also a new version of TDeint with a fix for mode 2 with yuy2 input.

[Chainmax]

Great, thanks :). Do you want me to put the link to the sample again so you can check it out?

[tritical]

[link removed], changes:
TDecimate:
+ Removed maximum limit on cycle value (upper limit is now the # of frames
in the video)
+ batch option now disables input file crc checking (applies to all modes)
+ Minor changes to tfm match and d2v aided decimation routines
+ Display crc values in error msg when crcs don't match

TFM:
+ Added batch option (disables input file crc checking)
+ Display crc values in error msg when crcs don't match

For large cycle values (>30 or 40) I would definitely recommend doing an initial mode=4 pass to generate a stats file and then using that as input. Putting up the clip again would probably be a good idea... even if I can't help someone else might have an idea. I'd try modes 0/2/7 and see if any give satisfactory results... if not then give smart decimate a try.

TDeint will have to wait another few days.

[Chainmax]

I'll give this new version a try, thanks :). You can download the sample here (http://www.31012.com/~azulftp/VTS_01_4.demuxed.m2v).

[tritical]

[link removed], changes:
+ added expand parameter
+ added slow parameter and slow=1/2 matching modes from tfm
- fixed a typo causing mode 2 to crash with yuy2 input

expand will consider all pixels horiztonally within 'expand' distance of a combed pixel to be combed as well (default is 0). I saw Mug Funky mention that idea a few times and since it was quick to add I went ahead and did it. This should be the last rc release of TDeint, as I have nothing else planned that will actually go into it. I am still working on an improved motion detection algorithm, but it will be separate (though still usable within tdeint by the emask parameter).

[anonymez]

thanks tritical :)

[Chainmax]

Awesomeness, thanks :) http://smilies.vidahost.com/otn/wink/thumb.gif.

By the way, in which cases would TDeint(mode=1).TDecimate(to input framerate) be preferable to TDeint(mode=2)?

[foxyshadis]

Cool, a few new tweaks to test out.

[Mug Funky]

niceness! the expand feature works great!

the line:
tdeint(1,order,expand=4,tryweave=true,cthresh=3,mi=24,mthreshl=4,ap=2)

works exceptionally well, and believe me i tested it :)

one thing you might like to try is get some still footage (or even a still), and fade it out slowly.

like:

freezeframe(0,1000,500) #(or whatever frame)
separatefields().fadeout0(2*x).weave()

tdeint(whatever)

where x = the period of time you'd like to fade out.

i noticed without ap set, fades get passed through, even if they exceed the motion threshold (ie x = 256/mthreshl)

that's now really the only stumbling block of tdeint, and AP catches it pretty well, so i'm happy anyway :)

thanks again for the update

[tritical]

I'll look into the fade out problem. TDeint with mtnmode set to a 5 field check shouldn't weave anything that changes by more than the motion threshold over a two field (of the same parity) period, and defintely shouldn't weave anything that changes by more than that from one field to the next (of the same parity).

The new motion mapping should do much better on fade outs. It has an option that allows using a 6, 8, 10, 12, 14, or 16 field motion check... 6 checks one field and two field steps, 8 and up check one field and three field steps. Plus, instead of trying to weave everywhere it computes an inter and intra based edge or complexity mask and only attempts to weave where weaving would actually improve over using simple cubic or linear interpolation. Any of those pixels that can't be weaved are then interpolated using edi. I've been doing some experiments trying to train an edi for deinterlacing filter using a combination of sofm classifier and modular neural networks, but it hasn't been able to beat eedi2 yet.

[Chainmax]

Wow, TDecimate(cycleR=2003,cycle=5000) slows things down a lot :eek:. I'll stick to TDecimate(mode=7,rate=29.97) for now :D.

[Didée]

Something about "motion threshold" in related filters. Remember about the formerly mentioned two-thresholds method? Nah, how un-smart.

What I tried is: Instead of triggering motion just blindly "smallerthan [fix] is still, biggerthan [fix] is motion", make it adaptive as in "build E = {local max-min span}. smallerthan 20% of E is still, biggerthan 40% of E is motion, inbetween is inbetween".

Seems to work quite nice.:) For a scripted preview, just merge weaved and interpolated by the following mask:

mt_lutxy( motion_diff, min_max, "x 1 - y 1 + / 0.2 - 0.4 0.2 - / 255 *")

[tritical]

@Chainmax
Was that with or without first generating a stats file and using it as input?

@All
Well, I'm just about ready to release the new motion mask filter, but thought I'd explain the algorithm here and see if anyone has suggestions on improving it.

First, assume we have a sequence of top and bottom fields such as:
t t t t t t
b b b b b b

0 1 2 3 4 5 <= frame numbers

and that we want to generate a frame from the top field of frame 3... i.e. we need to create a bottom field to go with the top field of frame 3.

The first thing that happens is that an edge or complexity mask is created, using local variance, edge magnitude, and laplacian value, for the top field of frame 3. The mask marks each pixel as either 0 (flat) or 255 (not-flat). A slight dilation is then performed on the mask (any 0 pixel with at least 4 neighbors that are 255 is changed to 255).

Next, a mask for the bottom field is generated from the top field mask by marking any pixel whose 2 vertical neighbors in the top field are 255 as 255 and 0 otherwise. A pixel will also be marked 255 if either of the pixels in that location from the neighboring bottom fields has a difference to the two vertical neighbors in the top field of > fthresh. That last part is so that we don't miss detail that is present only in the bottom fields (say a single pixel tall horizontal line). The bottom field mask is then eroded (removes any 255 without at least 2 horizontal neighbors that are 255) and dilated (fills gaps up to 3 wide between 255 pixels).

At this point we have a mask of the bottom field indicating all pixels that are worth trying to weave (marked as 255). We then run the motion check on each of the indicated pixels. The motion check can be 6, 8, 10, 12, 14, or 16 fields (6 requires 3 static fields of each parity, 8 requires 4 of each parity, etc...)... it looks at all combinations behind, ahead, and across the current field. The motion check is optionally run on an externally denoised version of the input clip (if none is given it is run on the input clip itself). During the motion check, the threshold is adjusted on a per pixel basis based on the magnitude of the vertical gradient at the point we are trying to weave. In this case, that means for each bottom field pixel we difference its two vertical neighbors in the top field to get the vertical gradient. The threshold is adjusted between mt1 and mt2 based on ht1 and ht2... when the difference <= ht1 then the threshold = mt1, when the difference >= ht2 then the threshold = mt2, and if the difference is inbetween ht1 and ht2 then the value for the threshold is linearly interpolated between mt1 and mt2.

The output of the motion masking is a mask indicating at each point whether we should weave or not, and if so, from the previous field, the next field, or average of the two. If it was decided not to weave at a point, then it is marked to be interpolated using edi (plain linear or cubic is used for the flat areas). This mask is then post-processed to removed any pixels that are marked to be weaved but that don't have at least 2 horizontal neighbors that will be weaved. Optionally, the pixels to be interpolated with edi can be expanded outwards (i.e. mark all horizontal neighbors within 'expand' distance).

@Didée
Could you elaborate a little more? I don't exactly understand how you are making the min_max clip... is it the min and max differences for that pixel location within the neighboring 'x' amount of frames? Could you post the script lines you used to make the motion_diff and min_max clips?

[Chainmax]

@Chainmax
Was that with or without first generating a stats file and using it as input?
...

Without. I was not talking about the encode by the way, merely trying to jump to specific frames too much time as my machine is puny and the script is monstrous already.
How does the creating of the stats file work? If I need to make a whole encode that's out of the question as I have no HDD space for a lossless intermediate file.

[ChiDragon]

Thanks for adding the batch option. :D

I've just run into another problem though. The help file says:
"You can specify an ovr file and an input file at the same time. Matches and combed frames given in the overrides file will take precedence over those in the input file."

Shouldn't this also apply to frames set as clean in the overrides file? I'm trying to override the input file's setting of combed frames that really aren't, but it's using the input info. It works fine if I don't tell it to use the input file at all, but then I'll get some false matches.

You might wanna take a look at this scene too, it's using the clean D2V matches but finding them to have MICs around the 600-1000 range due to the fine lines on the ceiling.

[ChiDragon]

In fact the input file has "l" for those matches too, although they show up as "c (OVR)" and "p (OVR)" using display. How does TFM know whether to use c or p if the input says l?

I did get it to work, by also overriding the matches for those frames. Doesn't really make any sense to me why that would be necessary though...

Erm... now using an ovr file in TDecimate is causing it to ignore all hints. It sees every match as "p" and doesn't know where the d2vdups are. Using the previous version fixes this.

[tritical]

@Chainmax
By stats file I just mean tdecimate(mode=4,output="stats.txt"). To generate it, remove (or comment out) everything after tdecimate in your script, change the tdecimate line to the one above, open the script in vdub, and then go to "run video analysis pass"... no intermediate file is necessary. Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

@ChiDragon
I was able to reproduce the problem with tfm where combed frames marked as 'l' or 'h' in the input file (l/h basically mean c+) would not be overridden by an ovr file marking them as not combed. The reason is that it correctly sets the combed flag to 0, but it doesn't reset the match to 'c'. Therefore, when tfm grabs that frame's match during execution it sees 'l' or 'h' which it takes to mean c +. I'll fix that in the next version. For now you'll have to override the match for the frame as well.

Also, you said that the display info would show an 'l' or 'h' match as 'c' or 'p'? If it ever shows it as anything other than 'c' that is definitely a bug. Could you provide a step by step way that makes it show as something other than 'c'?

On the tdecimate problem could give the exact script you used? I can't duplicate the problem and I can't see any changes from the last version that would cause it.

[Chainmax]

@Chainmax
By stats file I just mean tdecimate(mode=4,output="stats.txt"). To generate it, remove (or comment out) everything after tdecimate in your script, change the tdecimate line to the one above, open the script in vdub, and then go to "run video analysis pass"... no intermediate file is necessary. Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

I will try it as soon as possible then, thanks for the tip :) http://smilies.vidahost.com/otn/wink/thumb.gif.

[tritical]

@Mug Funky
I looked into the fade problem and what's happening is that internally tdeint has a threshold such that if the pixel from either the previous or next field has an abs() difference of < 4 to both of the vertical neighbors in the current field it weaves it regardless of motion. So if mthreshL is 6, and you do:

blankclip(length=100,color=$ffffff,pixel_type="YV12")
separatefields()
fadeout0(2*73) # fades from 235 to 16 over 146 frames
weave()

the difference per field of the same parity is (235-16)/73 = 3. With the 5 field check, tdeint checks both single frame and two frame steps... so it should still detect all pixels as moving. However, since the per field (not same parity) difference is only 1.5, which is < 4, it weaves the pixels. In fact, with that < 4 limit the longest fade it would not weave is:

4 = (235-16)/x
x = 54.75

so roughly

fadeout0(2*27)

in this example. I removed that < 4 bit and it indeed handles everything up to

fadeout(2*73)

as expected. I'm not sure why I put that < 4 part in there, it might have been for speed, but I'll remove it in the next version. The reason AP tended to catch the fades is that all the pixels that were weaved due to the < 4 part, but that failed the motion check, were treated as moving for aptype=1/2.

[ChiDragon]

@tritical:
My mistake with the l/c/p thing, the "l +" matches show up as "c (OVR)" and "COMBED FRAME". The ones that show up as "p (OVR)" and "COMBED FRAME" are listed in the input file as "p +". The "p +" ones ARE shown as "l" in TDecimate's display listing though, except when PP=1 (then they're "p").

I just checked and the problem with TDecimate and hints only happens when batch=true in TDec (batch=true in TFM doesn't matter). For what it's worth, this occurs even if the ovr file is blank.

[tritical]

Reproduced it now. I originally added the batch parameter to tdecimate as a way to be able to load a script with tdecimate(mode=5,...) without having complete input files... that way you could set up the two pass mode=4/5 process in vdub's job control all at once. For that too work, it had to set some internal arrays to fake, but usable, values. The problem is that if mode isn't set to 5 then tdecimate thinks the values are good and uses them. Anyways, I forgot to have it check that mode is indeed set to 5 before setting the arrays to fake values. It'll be fixed in the next version. Thanks for the reports.

The "p +" matches showing as "l" in tdecimate is how it is suppose to work. Specifically, any combed frame, regardless of the match, should show up as either "l" or "h" in tdecimate if pp>1 in tfm. If pp=1, then only combed c matches will be translated into "l" or "h" and the others will stay as they are. It's not a pretty system, but it gets the job done :).

[Chainmax]

@Chainmax
...Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

I don't understand that. The stats file was created and the Mode2 and Mode0 scripts are:

MPEG2Source("X:\wherever\myvideo.d2v")

Trim(0,1982)+Trim(2355,0)

SeparateFields().DeBlock_QED().ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v =51.2,opt="coring").Weave()

Interp = SeparateFields().EEDI2(field=3,maxd=29,nt=80,pp=3)
TDeint(mode=1,order=1,type=3,mtnmode=3,tryweave=true,edeint=Interp,slow=2)

Crop(22,4,688,554,align=true)
Lanczos4Resize(656,448)

TDecimate(mode=2,rate=29.97,input="stats.txt")

MPEG2Source("X:\wherever\myvideo.d2v")

Trim(0,1982)+Trim(2355,0)

SeparateFields().DeBlock_QED().ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v =51.2,opt="coring").Weave()

Interp = SeparateFields().EEDI2(field=3,maxd=29,nt=80,pp=3)
TDeint(mode=1,order=1,type=3,mtnmode=3,tryweave=true,edeint=Interp,slow=2)

Crop(22,4,688,554,align=true)
Lanczos4Resize(656,448)

TDecimate(cycleR=2003,cycle=5000,input="stats.txt")

The Mode0 version, just like before, can't even load the video. The Mode2 version nets an access violation error pointing to the TDecimate line :(.

[tritical]

There seem to be a few logic errors in the mode 0/1 code making it still go through and request all the frames in the cycles even though it has all the stats info. I'll fix that.

On the mode 2 access violation, does it occur on load or during processing? and is it only if you use an input file?

[Chainmax]

The access violation occurs when trying to load the script. Upon editing the script and commenting out the stats loading portion the script loads fine.

[tritical]

Could you add "debug=true" into the tdecimate line, have DebugView open, and then try to load the mode 2 script that crashes? Post the output you get back here... should give some idea of where the problem is since I can't seem to reproduce it.

[Chainmax]

I bet it's just one of those random Avisynth issues, but I'll try your suggestion as soon as I can and report back.

[ChiDragon]

@tritical:
Would it be possible to add a "flags" option for D2V match use that only checks scene changes for being combed? Like a limited flags=4. Checking with flags=1, scene changes seem to be the only places where there are combed D2V matches in my files.

By the way, I've noticed some frames reported as d2vdups by TDecimate that aren't dupes at all. I haven't seen it actually decimate these frames, so I guess it doesn't matter, but I thought it was weird.

[tritical]

A flags option that checks the d2v matches for combing only around scenechanges would be possible to add.

To diagnose the d2v dup problem I'd need the d2v file and an output file from tfm generated with a run using:

mpeg2source("d2v.d2v")
tfm(d2v="d2v.d2v",output="output.txt",+any other options)

Also, a list of some of the frames being incorrectly reported.

The requirement to be a d2v dup is that the combination of the match used in tfm and the rff flags in the d2v file indicate that one field is present in both the current and previous frame.

[zoinbergs]

Hey guys! I got a quick question for ya.. hopefully it means a quick answer is on the other end...

I'm currently trying to field match some 25p footage that has been 3:2 telecined from 20fps, and it's fields are (unfortunately) blended.

Here's a quick example:

http://www.sendspace.com/file/zp3t0z


Could anybody possibly define some basic terms for TFM (I believe I would need to use) to give me a push in the right direction?

Somebody told me that TFM can match field blended frames, so I presume I'm in the right place, am I not?

I've been trying for days to get "restore24" to work, as that is exactly what I need to do (if one were to consider my footage 3:2 pulldowned from 23.976 to 29.97), but I just cannot seem to get my script to work with it! You can have a look at my thread here on it if you'd like:

http://forum.doom9.org/showthread.php?t=117006

I've almost given up on restore24, and am looking for any possible alternatives. TFM and TDecimate look promising I must say! Wow can you guys code!

.....................................................................

So I believe I can start with TFM(mode=7) right? I read that in the handy tutorial, but that's all I've figured out so far.

Any and all help is most definitely appreciated, and is considered to be priceless for me! I would be forever in debt to somebody who can help me figure this one out.

Thank you in advance, and keep up the AWESOME work. :)



EDIT: My prayers have been answered with the wonderful tool FixBlendIVTC!!!! Have a nice day guys, and thank you anyway!

[ChiDragon]

Well, I started opening a bunch of instances of VDub for the false d2vdups as I found them, until I noticed that they disappear when the script is reopened! This is true for the 7 or so that I found up to that point. What the...

[tritical]

Declaring a d2v dup requires that tfm knows the match that was used for the previous frame. If you reopen a script or seek to a frame without processing the frame before it (and you aren't using an input file), then it doesn't have that information... in which case it wont declare the frame a d2v dup. What is the script you're using?

[ChiDragon]

Actually, I was using an input file. I did try seeking once, forward and back, to see if the d2vdup would reappear and it didn't.

V = MPEG2Source("J:\PVR Extractions\211.d2v")
A = NicMPASource("J:\PVR Extractions\211 T01 DELAY 0ms.mpa")
AudioDub(V,A)
AmplifydB(15)

Trim(1589,4289)+Trim(8092,27742)+Trim(56212,75941)+Trim(81492,101986)+Trim(107616,109331)

TFM(d2v="J:\PVR Extractions\211.d2v",trimIn="cap3_TI.txt",mode=0,slow=2,micmatching=0,PP=5,blockx=32,blocky=32,MI=160,input="cap3_TFM.txt",ovr="I:\cap3_TFM_ovr.txt")
TDecimate(mode=1,dupThresh=0.4,hybrid=1,vidThresh=3,vidDetect=1,input="cap3_TDec.txt",ovr="I:\cap3_TDec_ovr.txt")

Crop(4,4,-18,-4)
LanczosResize(512,384)


I'm actually using the previous version of TIVTC BTW, to avoid that hints issue.

[tritical]

Could you send me the following:

211.d2v
cap3_TI.txt
cap3_TFM.txt
cap3_TFM_ovr.txt
cap3_TDec.txt
cap3_TDec_ovr.txt

Even if it goes away after moving around a few frames, if just getting it the first time (opening the script and requesting a set of specific frames in a specific order) is reproducible then that should be enough.

You can zip the files and email them to me as an attachment, or upload them to:

66.189.231.68:17252
user/pass: upload/upload

or if you have a place to host then that's fine too. I'd like to get this issue figured out before releasing another version as the d2v dup detection is a major part of the decimation routines. There are some safety checks in place that will keep it from doing anything really stupid (a d2v dup also has to have a difference metric <= to the lowest in the cycle for most stuff), but having it correct would be best.

[ChiDragon]

Sorry, I wasn't clear about the seeking thing. When I said "I did try seeking once, forward and back, to see if the d2vdup would reappear and it didn't" I meant that in reference to reopening the script in VDub via F2. Seeking back and forth when a false d2vdup does appear doesn't cause it to go away, only reopening the script does.

I thought I mentioned this before, but I guess not: the false dupes only seem to occur in cycles where there already is a real d2vdup.

I actually deleted those files once I was done with that encode, sorry... But I've found a place in another ep that I can reproduce by seeking a specific way.

Open the script in VDub, "Go To Frame" 4133 (all frame numbers are post-decimation), seek forward to 4275, then backward to 4147 and the first false d2vdup occurs, at the end of the cycle. Seek back further, to the next cycle, and there's another at the end of the cycle. The start of this cycle is at 4140 (2 cycles after the initial frame sought).

If you seek further in the initial forward-seeking, to say 4300, there are more false d2vdups, now appearing in the backward-seeking as early as 4195 and continuing each cyle backwards until 4140. More false dupes can be added by going further forwards and then backwards again, even without first reopening the script.

Those results are when an input file is used for TDec (input/no input for TFM gave the same results either way). If no input file is used, the false d2vdups appear "sooner" in the backwards-seeking (4133->4300=4243 rather than 4195).

Using this:
TFM(d2v="J:\PVR Extractions\212.d2v")
Trim(1709,4412)+Trim(8906,30480)+Trim(34974,50748)+Trim(55692,73536)+Trim(78932,101454)+Trim(107747,109462)
TDecimate(display=true)
Rather than this:
Trim(1709,4412)+Trim(8906,30480)+Trim(34974,50748)+Trim(55692,73536)+Trim(78932,101454)+Trim(107747,109462)
TFM(d2v="J:\PVR Extractions\212.d2v",trimIn="cap7_TI.txt")
TDecimate(display=true)
causes them to appear one cycle "sooner" still, at 4247.

Using that final script with no TrimIn file, I decided to try using Go for both 4133 and 4300 rather than seeking to 4300, and the result was d2vdups as early as 4295 (2 cycles before 4300) when I did backwards-seeking from there. Seeking backwards seems to be the key, at least in this instance; just jumping forward and backward with Go didn't cause it.

Weirdness all around... Hope my explanation of this isn't too confusing.

[tritical]

Could you test this build: [link removed] and see if it fixes all the false d2v dup detections? The false detections were caused by a combination of random access, hints, and a bug in the d2v dup decision code. It also has the fixes for all the other issues.

[ChiDragon]

It all appears to be fixed, thanks! :D

[tritical]

Only 18 months since v1.0 beta 1 ;)... here is [link removed]. Changes:
+ added blend deinterlacing option (type = 4)
- changed denoise default to false
- pixels detected as moving, but with absolute difference < 4 to both vertical
neighbors are no longer automatically weaved (should fix problems with slow fades)

[anonymez]

finally ;)

thanks tritical

[Mug Funky]

thanks tons!

will try it out immediately.

[edit]

awesome performance on fades! picture doesn't bob around, but smoothly comes up the way it should. excellent. i can significantly raise my thresholds now.

the uppermost line appears to behave strangely on odd fields (when deinting top-first stuff). it appears to be getting weaved.

[Terranigma]

Thanks for the awesome update to this great deinterlacer :cool:

[ChiDragon]

Hmm I tested TDeint with type=4 on telecined and 29.97 CGI material (which is all I have around at the moment) and it left artifacts all over.

[Mug Funky]

@ chidragon:

maybe check the field order? that's the obvious thing :)

only problem i have is the topmost line is being weaved at all times.

[tritical]

@Mug Funky
Yes, the top most line with field=0 and the bottom most line with field=1 is always weaved from the current frame. Its been that way since the beginning. I'll probably change it in the future.

@ChiDragon
Probably its not artifacts (in the sense that it's incorrect behavior) but just the fact that blur deinterlacing combined with motion-adaptation (especially bi-directional motion-adaptation) doesn't work that well or make a lot of sense. The current implementation, for pixels that are marked to be interpolated, simply weaves the pixel from the current frame and does a [1 2 1] vertical blur on it and its two vertical neighbors. With mthreshL=0/mthreshC=0 this gives identical results to blur(0,1) or blendfields(). If the the motion thresholds are > 0, then it ends up weaving stationary pixels and filling moving areas by averaging the current field and either the prev or next field (depending on whichever is weaved into the current frame).

It is possible to make the kernel more complicated... alignfields(mode=2) extends it out horizontally to become [1 2 1, 2 4 2, 1 2 1]... just apply a horizontal [1 2 1] to the vertical [1 2 1]. In fact, there is no reason to prefer averaging in only the field that happens to get weaved into the current frame... alignfields(mode=3) extends its mode 2 to include both the prev/next field in the averaging.

In my mind, the whole reasoning behind blend deinterlacing, like kernel interpolation, is to include information from the opposite parity fields. In the case that you are not using any form of motion-adaptation, this improves vertical resolution in stationary areas over using interpolation based solely on pixels from the current field. However, in moving areas you'll be averaging unrelated pixels and end up with a "ghosting" effect.

In the case of a motion-adaptive deinterlacer, you are already detecting stationary areas and weaving... so any place that you would apply the blending you already know is moving (except for incorrect detections). The same argument can be made for kernel interpolation. It includes information from fields of the opposite parity, which helps to improve resolution in stationary areas but creates "ghosting" in moving areas. The difference is that kernel interpolation doesn't average the other field in, but uses it for a sharpening effect (sort of like a [-1 2 -1] kernel). Therefore, it wont produce ghosting in flat areas like blending will, but it will produce ghosting around lines and edges in the opposite parity field. Generally, the effect is much less noticeable and ugly than blend deinterlacing, and is worth the added vertical resolution in stationary areas that are incorrectly detected as moving. Of course, some videos are naturally blurry and the ghosting creating by blend deinterlacing may not that objectionable.

Personally, I don't think blend deinterlacing has much place in TDeint, but it was requested so I added it :). Adding more complicated blending modes (sort of like alignfield's modes 2 or 3) could be interesting, but IMHO they would only really be useful without motion-adaptation.

[Terranigma]

Adding more complicated blending modes (sort of like alignfield's modes 2 or 3) could be interesting, but IMHO they would only really be useful without motion-adaptation.
Well could you perhaps add in a simple blending deinterlacer like blendfields(), one that works in YV12?

[tritical]

tdeint(type=4,mthreshL=0,mthreshC=0)

or

blur(0,1)

blur wont handle the first line or last line exactly the same, aside from that it is identical.


On another note about more complicated blurring kernels... taking the traditional blur deinterlacing, centering it on each field, generating the missing field pixel values by averaging pixels from the prev/next fields and then doing the [1 2 1] vertical blur has the added benefit of removing rainbowing/dot crawl in stationary areas. I'll probably go ahead and add that in the next release... it's basically alignfields(mode=3) but without the horizontal blurring.

[Terranigma]

thanks for pointing that out above. Then how about this: how about adding in a way we could use a custom sharpening filter (preferably tunsharpen) for deinterlaced frames.

perhaps something like this?
tdeint(full=false,slow=0,expand=0,sharp=true, sharpf="Tunfilter(62,10,60,0,0,256,3)",cthresh=3,ap=2,mthreshl=0,mthreshc=0,blockx=16,blocky=16,mi=64,type=4,
ovr="C:\Video.txt",ovrdefault=1)

to add sharpness back to the blended frames. :)
This is to speed things up, because I'd use ApplyRange(frame,frame,"tunsharp",62,10,60,0,0,256,3)
numerous times.
Just a suggestion.

[Didée]

how about adding in a way we could use a custom sharpening filter [..snip..] to add sharpness back to the blended frames. :)

Anyone ever noticed Vinverse (http://forum.doom9.org/showthread.php?p=841641#post841641)? It's just this: Make a small-range blur. Then, of this make an inverse blur at a wider range (speak: USM), /w configurable strength. Manipulate the result so that the 2nd one isn't allowed to add (remove) more than the 1st one previously did remove (add).
Compared to the ease of operation, the outcome is valuable. Try. One might say, it seems almost like a plugin function candidate. ;)

[tritical]

Would something like this work?

mpeg2source()
tdeint()
t1 = last.sharpener()
t2 = last.possiblysomeotherfunctionornothing()
tswitch(last,t1,t2)

where tswitch could read a hint from tdeint and then deliver frames from t1 or t2 based on whether the frame was deinterlaced or not. I think this would be more powerful and it would be slightly easier to implement.

[Terranigma]

Would something like this work?

mpeg2source()
tdeint()
t1 = last.sharpener()
t2 = last.possiblysomeotherfunctionornothing()
tswitch(last,t1,t2)

where tswitch could read a hint from tdeint and then deliver frames from t1 or t2 based on whether the frame was deinterlaced or not. I think this would be more powerful and it would be slightly easier to implement.

Yes that'd be great :cool:

[tritical]

[link removed], changes:
tfm:
+ preserve hints from dgdecode through tfm
+ added flags=5 option... same as 4, except that only frames around scenechanges
are checked for being combed
+ changed 'sco' to 'scthresh' and added 'ubsco' and 'mmsco' parameters.
Using u/b matches only around scenechanges and using micmatching only
around scenechanges are now controlled with separate parameters.
- fixed incorrect d2v duplicate marking by tfm when using hints and not using
linear, forward play
- fixed frames with 'h' and 'l' matches not being correctly overridden by an
ovr file

tdecimate:
+ auto detect hints on load if hint is not explicitly set to true or false by
the user
+ restore dgdecode hints passed through tfm when outputting frames
- fixed batch option setting arrays to fake values even if mode was not set to 5
- fixed unneeded requesting of frames under certain conditions due to some logic
errors
- a few caching changes/fixes

I decided to modify tfm to recognize hints from dgdecode and to preserve them if present. If hint=false in tfm then they will be restored in tfm's output, if hint=true they wont be restored until after tdecimate. There is one situation where the hints will not survive and that is if tdecimate modifies a frame. TDecimate only modifies frames when blending two frames together, so if noblend=false or hybrid=1 or 3 it's a possibility. The blending wont destroy the hints if the hints for the two frames that are blended together are the same, but it will if they aren't.

The other thing is that with the change to preserve dgdecodes hints, TDeint wont be able to correctly read tfm's hints (it'll say it doesn't find any). I can't really think of a reason to use TDeint after tfm instead of using it via tfm's clip2 parameter so it shouldn't be much of problem, but it'll be fixed when the next version of TDeint is released.

[canuckerfan]

Thanks, tritical!

Now that the hints from dgdecode will survive, I am curious to know of it is now possible to use ColorMatrix after ivtc'ing?

EDIT: just tested it, works great! Thanks!!

[G_M_C]

Firstly; I'd like to apoligize in forehand for this (probably) dumb question ;)

I'm currently trying to deinterlace a Pal 50i stream to a PAL 25p stream. I've read through the manuals of tdeint/eedi etc. several times, but i'' m no expert so it's hard for me to understand ;)

Does tdeint produce a 25p stream after deinterlacing (wich seems logical to me after "merging together" both fields) or not ?

I ask this question because i want to try to understand what im doing (and what to expect) before actually starting to expiriment.

Also; I'm @ work atm, and obviously cannot actually start expirimenting :D

But i can "learn how to" @ work

[acrespo]

It's my script with TFM in RC6 version:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
colormatrix(interlaced=true,hints=true)

AssumeTFF()
orig=last
TFM(mode=6,order=1,PP=1,slow=2)
TDeint(order=1,clip2=orig,slow=2)
TDecimate(mode=1)

In RC7, to use colormatrix, can I chage to:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)

AssumeTFF()
orig=last
TFM(mode=6,order=1,PP=1,slow=2,hints=false)
TDeint(order=1,clip2=orig,slow=2)
TDecimate(mode=1)
colormatrix(hints=true)

[tritical]

@acrespo
Not quite, but this will work, will do the same thing, and will be faster:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
AssumeTFF()
deint = TDeint(slow=2)
TFM(mode=6,slow=2,clip2=deint)
TDecimate(mode=1)
colormatrix(hints=true)

@G_M_C
Yep, with mode=0 (the default) you will get 25p out. Specifically, it will create one frame from either the top field or bottom field of each input frame (which depends on the 'field' parameter). mode=1 (bobbing) will give 50p out and will create one frame from each field in the input stream.

[acrespo]

@acrespo
Not quite, but this will work, will do the same thing, and will be faster:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
AssumeTFF()
deint = TDeint(slow=2)
TFM(mode=6,slow=2,clip2=deint)
TDecimate(mode=1)
colormatrix(hints=true)


@tritical
You said in previous post that need hint = false in TFM to use colormatrix(hints=true). Why you don't put this parameter above?
When I use clip2=deint TFM get deinterlaced frames from TDeint and don't use the internal deinterlace?

[tritical]

You said in previous post that need hint = false in TFM to use colormatrix(hints=true). Why you don't put this parameter above?
You only need hint=false in tfm if you are not following it with tdecimate. If you follow tfm with tdecimate, then you'll want to keep hint=true so that tdecimate gets the information from tfm... tdecimate will then remove tfm's hints and restore dgdecode's hints.

When I use clip2=deint TFM get deinterlaced frames from TDeint and don't use the internal deinterlace?
Correct, it grabs frames from clip2 instead of using one of its internal methods.

[Terranigma]

Thanks tritical for the update. Just curious: is AssumeTFF or AssumeBFF really necessary since tdeint uses the parity from Avisynth? Maybe for avi files, or other types of file that don't have info about which field order is assumed, but I'm talking about .d2v files.

[tritical]

Yes, generally you shouldn't have to add assumetff() or assumebff() when using mpeg2source() since it sets the field order. However, its rule for setting the field order based on the tff flag of the first frame is technically only correct for progressive sequence==0 && FRAME_PICTURE (see the known issues and limitations thread). Personally, I've only seen two clips where the field order set by dgdecode was incorrect.

[ChiDragon]

Thanks for flags = 5! :D BTW, you missed adding 5 as one of the modes that trimIn is used for in the TFM readme.

[anton_foy]

I am not sure this would be an improvement that would be added to Tdeint or if this should be done seperately afterwards.

These two pictures below are a comparison of the artifacts left behind from Tdeint+eedi2 and MvBob.
Artifacts (http://www.xtreem.nu/jonas/D-comp.png)

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.

I was thinking that maybe a smoothingfilter that works together with Tdeint right after the deinterlacing process occur. This could be activated by some memory function perhaps storing what pixels has been deinterlaced and smooth these areas like degrainmedian does. Being a total retard regarding programming this may possibly be stupid suggestion but hope it will be of some interest in the area.

Tdeint is so good and get almost the same quality on my footage as MVBob but about 3 times faster.

[Terranigma]

Hi. Is there anyway to use eedi2 with tdeint via external deinterlacing @ scene changes? I've tried to do a manual override, but it won't deinterlace, so in order to avoid that, i'd use tfm(flags=5,hint=true). Maybe there's something that i'm doing wrong?:o

[Revgen]

You can use the clip2 parameter.

Look here (http://forum.doom9.org/showthread.php?p=746020#post746020)

[ChiDragon]

tritical, sorry to bother you again, but I've got a new problem. I've specified a video section with an override file, and it properly overrides everything in the section except one cycle. My ovr line is "28779,29087 v". Frame 28806 is being dropped and none of the frames in its cycle are blended, although it does state VIDEO in the display stats. This cycle is also treated the same way without the ovr file, which is weird because it properly finds and blends 5 cycles before and 10+ after, and I have conCycle set to default (my vidThresh is 3). Not only that, but it doesn't even drop the frame with the lowest displayed metric (28809 has 10.45 vs. the 18.46 of 28806).

I'm using an input file on the actual encode, although I tested without the input file and found the same results. As a workaround I edited the second value for frame 28806 in the TDecimate stats file and it now properly blends all the frames in the cycle (I just copied the next frame's metric).

Original stats:
28805 67940 6099494
28806 62565 6437117
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493
Edited stats:
28805 67940 6099494
28806 62565 8689400
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493

Editing the first value increased the metric displayed by TDecimate but the frame was still dropped.

[tritical]

@ChiDragon
Try increasing the scenechange threshold in tdecimate. When using hybrid=1, and a scenechange is detected in a video cycle, it prefers to drop a frame one side of the scenechange over blending the cycle. For scenechange detection only one frame in the prev, curr, and next cycles can be over the threshold, so by changing the stats file as you did you probably made 2 frames be over the limit making it not detect a scenechange and thus blending the cycle.

@anton_foy
It would be possible to do what you propose, but it would also be quite a bit of work. Such artifacts are a result of poor motion detection, so I think improving motion detection is a better place to invest time than trying to filter the mistakes. I've had a new motion-masking filter finished for a while, but just haven't sat down and written the help file.

[Didée]

@ anton_foy ( & tritical, too)

Anton, from your post it is not too easy to gather what are the "good effects", and what are the bad ones. But after reading several times and looking at the zoooomed picture often, I think that you, tritical, got it the wrong way round. (Not sure, though.)

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.
Ah, language ... let's try to work it up. ;)

Mentioned are two different types of "artefacts": the "compressionlike" ones, and the combing artefacts. Truth is, both filters show good (read: bad) amount of residual combing, MVBob even more than TDeint. In this point, both filters are basically equal.
But the "compressionlike" artefacts of TDeint shall appear *opposed* to MVBob, so these can't be related to residual combing. Okay, there is this area on the shirt, right below the collar, where the residual combing of TDeint is most obvious ... but that's a small area only, and moreover nothing like this is to be seen in the face, where the "compressionlike" artefacts shall appear, too.

So, my guess is that the wording "compressionlike" is targetting at the, well, "chunky" look in those areas where TDeint did deinterlace: at the very edges of the face (cheeks), at the light-shadow transition of the nose bridge, and, especially in the left part of the picture, at the dark parts of the shirt's folds.
In these areas, TDeint did deinterlace, and interpolation left back this chunky look. MVBob, in comparison, did not deinterlace most of these areas, but decided (falsely, imo) to weave them. So, MVBob did create more residual combing, but in this scene, this did the visual trick of "dithering" the chunkyness that (probably) is inherent to the source from the start.

Now, what's good, what's bad, and what is to do?

But in any case: any filtering like "smoothing" or "noise reduction" of those areas that actually have been deinterlaced, this should not be the task of the deinterlacer (again, imo.) A deinterlacer should either weave or interpolate pixels, eventually do postprocessing to reduce residual combing. But active image processing is just not the job of a deinterlacer.

(BTW: while in *this* case MVBob's "residual-combing-denoising" visually worked out, there are instances where it will fail big time. You might check these short samples (http://rapidshare.com/files/659527/BobComparison_artefacts.rar.html) here.)


But while I'm babbling anyways :o , this brings up another point that has bugged me for quite some time: most of tritical's filters have these nice options to spit out visualizations of "what is done where". A really nice feature! ... but: often it's a pity, that from those relatively slow filters you can only have either the actual processing, or the visualization mask. Imagine, you want to have the actual processing, *and* the visualization mask in order to do further processing based on the mask. This means that you have to run the (relatively slow) filter *two times*, to get both the processing and the mask.
Wild suggestion: would it be possible to add an option, which would force to give out both the processing and the mask (say, stacked vertically)? Then one could simply do some cropping after calling the filter, and would have both outputs with only one call of the filter. :)

TDeint and TTempsmooth are the filters where I would love to have this feature, quite frequently ...

[Chainmax]

Hey Didée, there's still no match for SmartDecimate on Restore24, right?

[Didée]

Frankly, I can't tell. Last time I checked, I found TDecimate/mode7 not always reliable in long encodings - but that was a looong time, perhaps a year, ago ... things might have changed.

Since R24 offers the option to use either one or the other, feel free to test it out, and report back. :)

[ChiDragon]

@tritical:
Ah, scenethresh=16 also did the trick. Makes sense now how it would be appropriate to drop the scene change frame rather than blend where possible (although in this case it wasn't a scene change ;)). Thanks for clearing it up.

[akapuma]

Only 18 months since v1.0 beta 1 ;)... here is TDeint v1.0 Final (http://bengal.missouri.edu/~kes25c/TDeintv1.zip). Changes:
+ added blend deinterlacing option (type = 4)
- changed denoise default to false
- pixels detected as moving, but with absolute difference < 4 to both vertical
neighbors are no longer automatically weaved (should fix problems with slow fades)
Hello,

why the denoise default is changed from true to false?

Best regards

akapuma

[tritical]

@akapuma
I changed it to false because it is kinda worthless and just slows things down imo. All it currently does is remove individual pixels that were detected as moving but who had no immediate neighbors (8 surrounding pixels) that were. I originally wanted to expand it to do more, but I never found an algorithm that worked well.

@ChiDragon
I'm glad that something finally worked how it's suppose to :D.

@Didée
Yeah, I misinterpreted the artifacts he was talking about in the image. Though either way I'm not keen on incorporating postprocessing like that into tdeint. However, with AP > 0 TDeint internally creates a mask marking weaved pixels with AP value > thresh (also subject to APType conditions) vs. other pixels. Outputting that mask as part of the map parameter could make such processing possible externally.

Creating both the map and the regular frame and stacking them vertically or horizontally is a great idea. I'll add it in the next version of tdeint.

@Chainmax + Didée
As far as mode 7 goes, I have only one clip to test on and for me it produces no duplicates. Also, smartdecimate always crashes after processing only a few frames so I haven't done much in the way of comparisons. Though a few days ago I built avisynth_c v0.15 using an updated avisynth lib/header and then built smartdecimate v0.23 using the updated avisynth_c and it all works fine now. So I'd be happy to look at samples where mode 7 gives crappy results compared to smartdecimate.

[ChiDragon]

tritical:
What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one. I just noticed a scene where that would help (a bad edit between two actual film patterns).

On the other hand, I suppose the current method would be preferable if vidthresh is set too low and TDec sees a dupe at the scene change as being video. Then it would be better to keep the combed frame...

Just a thought. :P

[Livesms]

Can anybody tell me why when I use two pass deinterlace with

#1 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, output="matches.txt")
tdecimate(mode=4, output="metrics.txt")
and

#2 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, input="matches.txt")
tdecimate(mode=5, hybrid=2, vfrDec=0, input="metrics.txt", tfmIn="matches.txt", mkvOut="mkv-timecodesfile.txt") # not anime or cartoon

I'm getting 23.822fps instead of 25.000fps

And when I use
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname)
tdecimate(cycle=25)

it produses 24.000fps instead of 25.000fps.

Source is 25.000fps. How can get 25.000fps - deinterlace without changing fps?

PS. I'm looking for quality deinterlace of VHS video captured with DVD-Recoder MPEG-2 8000kbit/s. Here is another canidate MPEG2("Untitle.d2v", true)

interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)

But two pass or another IVTC for PAL gives more accurate results.

[ChiDragon]

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

[Livesms]

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

Should I skeep tdecimate both in first and second pass?

Will it cause in result quality?

[foxyshadis]

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

[Livesms]

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

I've got PAL (720*576) material with such frames (http://dump.ru/files/2/288457137/1.png). Source fps is 25.000

IVTC ADVICE in http://www.doom9.org/ivtc-tut.htm page mostly deal with NTSC. But I work with PAL DVD video.

[foxyshadis]

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.

[Livesms]

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.
Ok. Here is 10 frames from video http://dump.ru/files/3/379894795/PAL.rar (comporessd by Huffyuv)

If IVTC is wrong way, so why it gives me better results :)

[manono]

Hi-

As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.

[Livesms]

Hi-

As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.

Yes!

SeparateFields() gives me half height picture and all different (step by step) video. So it is pure interlaced video.

So what can you reccomend as deinterlacing filter. I have some variants
interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)http://dump.ru/files/8/826331359/0.jpg
2 pass TIVTC
first pass
tfm(d2v=d2vname, output="matches.txt")

second pass
tfm(d2v=d2vname, input="matches.txt")
http://dump.ru/files/0/0508170020/1.jpg
TIVTC for PAL
tfm(d2v=d2vname)http://dump.ru/files/1/100852183/2.jpg
Some samples from MeGui
#TDeint with EDI
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)http://dump.ru/files/6/6827235/3.jpg
#TDeint
TDeint(order=1,full=false)http://dump.ru/files/0/074818498/4.jpg
#FieldDeinterlace
AssumeTFF().FieldDeinterlace(full=false)http://dump.ru/files/4/4845181842/5.jpg
#FieldDeinterlace (no blend)
AssumeTFF().FieldDeinterlace(blend=false,full=false)http://dump.ru/files/4/4192710577/6_1.jpg
#LeakKernelDeint
LeakKernelDeint(order=1,sharp=true)http://dump.ru/files/2/223364508/7.jpg
#TomsMoComp
TomsMoComp(1,5,1)http://dump.ru/files/9/9263911186/8.jpg

Maybe there is other method, which will give me better/best results?

[foxyshadis]

How much time are you willing to spend on the project? SecureBob, MVBob, and MCBob (http://forum.doom9.org/showthread.php?p=892518#post892518) are very slow but very good at creating crisp 60 fps video without combing. You should try those you posted, however, and see if they might work well enough for a fast deinterlace. Especially TDeint and TomsMoComp.

[Livesms]

How much time are you willing to spend on the project? SecureBob, MVBob, and MCBob (http://forum.doom9.org/showthread.php?p=892518#post892518) are very slow but very good at creating crisp 60 fps video without combing. You should try those you posted, however, and see if they might work well enough for a fast deinterlace. Especially TDeint and TomsMoComp.

Time is not obligation. The main aim is quality.
Can you give working examples for quality/slowest and quality/normal speed scripts.

TDeint sometimes give some artifacts like lines and scratces, while TomsMoComp adds some blur in to picture.

What does it mean "creating crisp 60 fps" - i need 25P and my source is 25I(50p/2).

[foxyshadis]

Oh right, PAL - 50 fps then, to which you'd use SelectEven after if you only want 25. I can't really give you good arguments, but that's because I've always been able to get very good results without any parameters.

[Livesms]

Oh right, PAL - 50 fps then, to which you'd use SelectEven after if you only want 25. I can't really give you good arguments, but that's because I've always been able to get very good results without any parameters.

Yes, but SelectEven will lose half of frames.
I need good deinterlace :)

I've always been able to get very good results without any parameters.

Can you explaine it :)?

[Chainmax]

tritical, I didn't forget about the Mode0,2 and 7 tests. I'll get to them most likely today.

[foxyshadis]

Yes, but SelectEven will lose half of frames.
I need good deinterlace :)

You said you needed 25 fps, not 50, right? Bob.SelectEven means the same as Deinterlace. You end up with 25 fps either way, because bobbing doubles the frames.

[Livesms]

You said you needed 25 fps, not 50, right? Bob.SelectEven means the same as Deinterlace. You end up with 25 fps either way, because bobbing doubles the frames.

Is there any sence to search in parametres for Mvbob?

How can I found out what shell I use Mvbob().SelectEven or mvbob.SelectOdd()

[Mug Funky]

use selecteven unless you've got half a line of black on the top of the screen (in that case use selectodd)

[tritical]

What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one.
Choosing which frame, of the two around the sc, to drop based on only one of the two being combed is possible. Atm, it always selects to drop the frame before the sc since it has the lower difference metric. I'll add it in the next release. Requiring that it be the only combed frame in the cycle would probably help as well.

@All
I also came across some clips where the regular field matching function in tfm wasn't able tell the difference between two matches but the MIC values made the correct choice obvious (such as 85 vs 9). So I've extended micmatching modes 1/2/3 to include a post match comparison step that looks at the mic values and will change the match decision in such blantantly obvious cases.

[DarkNite]

@All
I also came across some clips where the regular field matching function in tfm wasn't able tell the difference between two matches but the MIC values made the correct choice obvious (such as 85 vs 9). So I've extended micmatching modes 1/2/3 to include a post match comparison step that looks at the mic values and will change the match decision in such blantantly obvious cases.

Thank you tritical. I was just about to post on that issue as it became apparent when I was running through an old torture test source that I would like to actually get respectable results on someday without scripting hundreds of FreezeFrame ranges again.

That still won't happen, but it's bound to help out in other cases.

[tritical]

[link removed], changes:
TDecimate:
- switch setfps() with muldivfps() for modes 0, 1, and 5
- use FloatToFPS() from assumefps/changefps/convertfps for modes 2 and 7

TFM:
+ micmatching modes 1, 2, and 3 now check each match decision for cases where the
correct match is obvious based off mic values but the field matching routine
is unable to distinguish the correct match
+ added micmatching mode 4, does the post match decision check and nothing else

For the moment, the override decision to switch from m1 to m2 is simply:

if ((mics[m2]*3 < mics[m1] || (mics[m2]*2 < mics[m1] && mics[m1] > MI)) && abs(mics[m2]-mics[m1]) >= 30 && mics[m2] < MI)

where m1 was the chosen match, m2 was the alternative, and mics[x] is the MIC value for match x. The >= 30 means the MIC value for match m2 doesn't need to be calculated unless m1 has a MIC value >= 30. Since that usually isn't the case, there shouldn't be much of a slowdown vs previous versions.

[tritical]

Anyone ever noticed Vinverse? It's just this: Make a small-range blur. Then, of this make an inverse blur at a wider range (speak: USM), /w configurable strength. Manipulate the result so that the 2nd one isn't allowed to add (remove) more than the 1st one previously did remove (add).
Compared to the ease of operation, the outcome is valuable. Try. One might say, it seems almost like a plugin function candidate.

Don't say I never did anything useful ;)... vinverse (http://bengal.missouri.edu/~kes25c/vinverse.zip).

[Didée]

Didn't ever say so ... your plugins eat much of my CPUs' cycles every day. ;)

Ah, the speed! With a 10fold call, pace is ~400% of the script function. (what, is that all? booo! :D ) Configurable 'scale' is nice, too. (I was lazy to silently fix it at .25)

Really great, thank you. :)

[Chainmax]

tritical, sorry to have procrastinated for so long. I downloaded SysInternals's DebugView and tried a slightly different mode=2 script:

[script deleted]

Which, upon loading gave me the following error message:
http://img292.imageshack.us/img292/8628/vderrzi3.png (http://imageshack.us)
(that would be the TDecimate line)

and the following DebugView log:
http://img355.imageshack.us/img355/7715/dbgvwerrpm8.png (http://imageshack.us)

The stats file was created from an earlier clip but it was made according to your instructions and in that regard the script didn't change.

[foxyshadis]

Open the stats files and delete the parts marked crc; they're normally designed to require exactly the same input as the first run, but you can override it that way. Once you do that, you'll be able to open to debug further if necessary.

[tritical]

Alright, I don't know where to put this so I'm putting it here: smartdecimate+avisynthc (http://bengal.missouri.edu/~kes25c/smartdecimate_avisynthc.zip). These are builds I made from the sources on Kevin Atkinson's site (avisynth_c 0.15/smartdecimate 0.23)... the normal version would always crash if weave/bob were the same... at least for me.

Ah, the speed! With a 10fold call, pace is ~400% of the script function. (what, is that all? booo! )
My first attempt was only about 1.5x the speed of the script function... luckily the second one was a little faster :).


@Chainmax
I'm definitely interested in the results of your tests.

[DarkNite]

Wow, that was straight out of left field... I haven't seen smartdecimate in a while. In fact, I haven't used it since I started using TIVTC regularly. :D

[Chainmax]

...
@Chainmax
I'm definitely interested in the results of your tests.

They are coming up soon, I decided to make a new stats file as I changed bobbing to SecureBob since it looked better.

[Chainmax]

tritical: Phew! Stats creation took over a day :D.
The tests were conducted with the following script:

SetMemoryMax(256)

LoadPlugin("X:\wherever\DGDecode.dll")

LoadPlugin("X:\wherever\ColorMatrix.dll")

LoadPlugin("X:\wherever\Corrector.dll")
LoadPlugin("X:\wherever\EEDI2.dll")
LoadPlugin("X:\wherever\LeakKernelDeint.dll")
LoadPlugin("X:\wherever\MVTools.dll")
LoadPlugin("X:\wherever\MedianBlur.dll")
LoadPlugin("X:\wherever\SangNom.dll")
LoadPlugin("X:\wherever\TomsMoComp.dll")
Import("X:\wherever\MVBob.avs")

LoadPlugin("X:\wherever\TIVTC.dll")

LoadPlugin("X:\wherever\MT_MaskTools.dll")
LoadPlugin("X:\wherever\DCTFilter.dll")
Import("X:\wherever\DeBlock_QED_MT2.avs")

LoadPlugin("X:\wherever\FFT3DFilter.dll")

LoadPlugin("X:\wherever\Deen.dll")
Import("X:\wherever\HQDering_MT2.avs")

LoadPlugin("X:\wherever\RemoveGrain.dll")
Import("X:\wherever\LimitedSharpenFaster.avs")
Import("X:\wherever\Soothe_MT2.avs")

LoadPlugin("X:\wherever\AddGrainC.dll")




MPEG2Source("X:\wherever\familytape.d2v",info=3)

Trim(0,1982)+Trim(2355,0)

ColorMatrix(hints=true,interlaced=true)

SecureBob()

TDecimate(cycleR=2003,cycle=5000,input="stats.txt",debug=true)
TDecimate(mode=2,rate=29.97,input="stats.txt",debug=true)
one of these per test, of course ;)

DeBlock_QED()

Crop(22,6,688,552,align=true)

FFT3DFilter(sigma=6,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v=51.2,opt="coring")

HQDering(255)

FFT3DFilter(sigma=1,bw=32,bh=32,bt=3,ow=16,oh=16,sharpen=0.3)

Lanczos4Resize(656,448)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=150,wide=true)
Soothe(sharp,dull,25)

AddGrainC(5,2)

AddBorders(32,16,32,16)

Levels(0,1,255,16,235)

a = ImageSource("X:\wherever\Otrarr.bmp")
ApplyRange(2354,2357,"Overlay",a)

b = ImageSource("X:\wherever\Frm3.bmp")
ApplyRange(2358,2393,"Overlay",b)

c = last.Trim(2395,2395)
ApplyRange(2394,2394,"Overlay",c)

d = last.Trim(72151,72151)
ApplyRange(72150,72150,"Overlay",d)

e = last.Trim(82220,82220)
ApplyRange(82219,82219,"Overlay",e)

f = last.Trim(152177,152177)
ApplyRange(152176,152176,"Overlay",f)

g = last.Trim(164536,164536)
ApplyRange(164532,164656,"Overlay",g)

h = last.Trim(164660,164660)
ApplyRange(164657,164659,"Overlay",h)

i = last.Trim(165675,165675)
ApplyRange(165676,165676,"Overlay",i)

j = last.Trim(165686,165686)
ApplyRange(165681,165686,"Overlay",j)

k = last.Trim(165687,165687)
ApplyRange(165688,165688,"Overlay",k)

l = ImageSource("X:\wherever\HiPay.bmp")
ApplyRange(171430,172184,"Overlay",l)

I'm happy to report that Mode=0 seemed to work perfectly, it loaded just fine and I could even drag the slider to jump around the video. You can download DebugView's log here (http://rapidshare.com/files/2730976/M0Dbgvw.LOG.html).

Mode=2, however, was not so lucky. I received the same access violation error that points at the TDecimate line. DebugView's log was as follows:

http://img204.imageshack.us/img204/3901/m2dbgvwdo0.png (http://imageshack.us)

I hope this helps.

[tritical]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?


EDIT:

I was able to run this script without any problems:

mpeg2source("C:\test clips\t4.d2v",idct=7,info=3)
assumefps(25,1)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
TDecimate(mode=2,input="test.txt",rate=29.970,debug=true)

and the same script without stats input.

[canuckerfan]

i have some dvd telecined footage with an altering field structure (most of the movie is TFF, but sometimes it will change to BFF, I know, it's bad). Is there any possibility of handling the TTF part of the footage as TFF, and the same with respect to BFF. Thanks.

[tritical]

You could use mode=4 or mode=5 in tfm, both of which can handle alternating field order since they use 3-way (p/c/n) matching. The alternative is to manually find the places where the field order changes and then either use a series of trim()'s to create a new clip out of each and field match them separately or keep it as one clip and use an overrides file in tfm to change the value for order over the necessary frame ranges.

[canuckerfan]

I see. So if I had TIVTC+EEDI2 called like this:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

Changing the modes wouldn't simply work, would it? TDeint params would have to change, right? Wondering if there's any quick way of finding out where the field order changes in the footage without manually scanning through DGIndex.

EDIT: well, initially I was using mode 6, and it left some combing in some scenes. however, mode 4 seems to leave almost none. so far, things seem fine without adjusting the TDeint params.

[ChiDragon]

tritical:
I've got a video that seems to require decimation by 184-frame cycles. Since the cycles are so large, some frames are incorrectly decimated (particularly at fades to black, where it will drop a bunch of black frames and leave duplicates in the real video). Anyway, I was trying to override these parts and TDecimate appears to be ignoring the override line past a certain point. It will only read this far:

0,1000 -++++-++++-+++++-++++-++++-++++-+++++-++++-++++-++++-+++++-++++-++++-+++

Adding anything to the end of this line doesn't actually change the decimation, whether it's + or -. The 72nd frame is where it stops following the override line.

[tritical]

I probably used an 80 byte buffer for reading each line so the rest gets cut off. I'll increase the size in the next release.

[Chainmax]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?
...

I'll try it and report back ASAP.

[Livesms]

What it the defference beatween
AssumeTFF()
interp = separatefields().selecteven().EEDI2(field=1)
tdeint(order=1,field=1,edeint=interp)

AssumeTFF()
Interp = SeparateFields().EEDI2(field=3)
TDeint(mode=1,order=1,edeint=Interp).selecteven()
AssumeTFF()
edeintted = SeparateFields().EEDI2(field=-2)
TDeint(mode=1,order=-1,full=false,edeint=edeintted).Selecteven()

[ChiDragon]

I tried increasing the fgets value from 80 to 300 myself, and now it's actually crashing when the ovr line is longer than 103 chars.

[tritical]

@canuckerfan
Sorry I didn't reply to your last post earlier, I must of missed it. You're correct on TDeint not working correctly in that script if the field order changes. I was thinking of tfm by itself (its pping doesn't depend on field order). If it is deinterlacing only a few frames it'll probably be fine though. I don't know of any automatic way to determine where the field order changes. It's interesting that you get field order changes without dgindex finding illegal tff flag transitions in the stream... what version of dgindex are you using?

@Livesms
The first two scripts are logically equivalent and should run at the same speed and produce the same output. The third script is the same as the first two except for the full=false part (it will check each input frame to see if it's combed or not).

@ChiDragon
That's strange that it crashes. I changed all the fgets() calls in tdecimate.cpp/tfm.cpp/tfmpp.cpp from 80 to 1024 and increased the linein[] arrays to 1024 bytes, and everything seemed to work fine. I did a short test with cycle=120, cycleR=2, and the ovr file marking frames 96/116 to drop and it worked fine. What are the cycle/cycleR values you are using? and what are the lines in the ovr file?

[ChiDragon]

Whoops, it never occurred to me to check the linein array declaration! I was busy checking over all the ovrArray stuff... As you may have guessed, I'm not actually a programmer. :P Changing that fixed it of course, thanks.

Weird that it managed to work up until the 104th byte though, when it was only set for 80...

[Livesms]

@Livesms
The first two scripts are logically equivalent and should run at the same speed and produce the same output. The third script is the same as the first two except for the full=false part (it will check each input frame to see if it's combed or not).


So what one can you reccomnd for deinterlace?

Or maybe you have some other variations?

[ChiDragon]

tritical, would it be possible to add a parameter such that no 2 dups may be closer to each other than "n" (when cycleR > 1)?

I think this would solve the problem I'm having with multiple drops at black frames, and dropping the wrong frames in general with a large cycle of this kind. I've had to do a lot of overrides so far since it's often dropping stationary new frames instead of the actual dups. I know with this video that there should never be two real dups less than 5 frames apart.

I was gonna attempt this for myself so I didn't have to bug you again, but I couldn't even find the specific code that takes the lowest cycle metric and declares it as a decimated frame (not for lack of searching...). :confused:

[tritical]

@Livesms
It really depends on the clip at hand and how long you are willing to let it take. I rarely have true interlaced material to process (I mainly work with anime), and primarily use tdeint(mode=2) w/ eedi2 for postprocessing. For true interlaced material I think people concerned the most with speed tend to use LeakKernelDeint() and those concerned the most with quality tend to use mvbob() or now mcbob(). TDeint and TDeint+eedi2 are somewhere in the middle.

@ChiDragon
You should be able to do it by changing this code in void Cycle::setDecimateLow(int num) inside cycle.cpp:


for (v=0, i=0; v<num-ovrDec; ++i)
{
if (decimate[lowest[i]] != 1)
{
decimate[lowest[i]] = 1;
u = lowest[i];
while (decimate2[u] == 1) ++u;
decimate2[u] = 1;
++v;
}
}

to


for (v=0, i=0; v<num-ovrDec; ++i)
{
if (decimate[lowest[i]] != 1)
{
bool update = true;
for (int c=max(cycleS,lowest[i]-LIM); c<=min(cycleE,lowest[i]+LIM); ++c)
{
if (decimate[c] == 1)
{
update = false;
break;
}
}
if (update)
{
decimate[lowest[i]] = 1;
u = lowest[i];
while (decimate2[u] == 1) ++u;
decimate2[u] = 1;
++v;
}
}
}

Replace LIM with the limit you want. I can't test it atm, but it should work... just make sure that lim isn't so large that it can't mark at least cycleR number of frames. To make it an actual parameter in tdecimate would take a little more work. You'd need to modify the cycle class, tdecimate class, and the env->addfunction() call in PluginInit.cpp.

The code in tivtc is definitely not easy follow, but that's what happens after two years of hacking a poorly planned initial design to add new functionality :). I've thought about rewriting it from scratch quite often, but have never found the motivation for that much work.

[Livesms]

@Livesms
It really depends on the clip at hand and how long you are willing to let it take. I rarely have true interlaced material to process (I mainly work with anime), and primarily use tdeint(mode=2) w/ eedi2 for postprocessing. For true interlaced material I think people concerned the most with speed tend to use LeakKernelDeint() and those concerned the most with quality tend to use mvbob() or now mcbob(). TDeint and TDeint+eedi2 are somewhere in the middle.


And what is the most common variant for deinterlacing using EEDI2+TDeint?

MeGui provide sample
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)

WorBry use such script
interp = separatefields().eedi2(field=-2)
tdeint(mode=1,order=1,edeint=interp)
and
interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp, AP=5, APType=0 )

Chainmax suggest
#For TFF Clips:
Interp = SeparateFields().EEDI2(field=3)
TDeint(mode=1,order=1,edeint=Interp) and #For BFF Clips:
Interp = SeparateFields().EEDI2(field=2)
TDeint(mode=1,order=0,edeint=Interp)

Another one
Interp = AssumeBFF().SeparateFields().EEDI2(field=3)
TDeint( mode=1, order=1, edeint=Interp, mthreshL=1, mthreshC=2 )

I just messed up

[canuckerfan]

@canuckerfan
Sorry I didn't reply to your last post earlier, I must of missed it. You're correct on TDeint not working correctly in that script if the field order changes. I was thinking of tfm by itself (its pping doesn't depend on field order). If it is deinterlacing only a few frames it'll probably be fine though. I don't know of any automatic way to determine where the field order changes. It's interesting that you get field order changes without dgindex finding illegal tff flag transitions in the stream... what version of dgindex are you using?
i'm using dgindex 1.4.9b3. well, it outputted two d2v files, one with a bad tag and one without the tag. the log for operation stated this:
D2V Fix Output

Field order transition: 0 -> 2
d00 1 0 2732797456 0 0 b0 b0 90 b0 b0 a0 b0 b0 a0 b0 b0 a0 b0 b0 a0
d00 1 0 2733054080 0 0 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
corrected...
d00 1 0 2732797456 0 0 b0 b0 90 b0 b0 a0 b0 b0 a0 b0 b0 a0 b0 b0 a1
d00 1 0 2733054080 0 0 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2

so i'm guessing dgindex somehow "fixed" the FO?

[ChiDragon]

That worked great tritical, thanks! :D

canuckerfan, if I'm not mistaken you should be able to treat the whole video as either TFF or BFF (whichever the D2V says) since DGIndex fixed the field order switch.

[canuckerfan]

^I see. so with the following ivtc method, with the above situation:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=4,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

TDeint's param's need not be changed? And I'm guessing mode 4 or 5 for TFM would still work the best? Thanks.

[Mug Funky]

@ tritical:

i just discovered the new compiles of smartdecimate et al.

excellent!

does this solve all the caching problems? because i've always had probs with the old smartdecimate (crash on 2nd pass start the most annoying one), but i just quickly hacked in into my auto-pal function and it worked a treat. massive speedup. and thanks to vinverse plugin no artefacts either!

[foxyshadis]

^I see. so with the following ivtc method, with the above situation:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=4,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

TDeint's param's need not be changed? And I'm guessing mode 4 or 5 for TFM would still work the best? Thanks.

When using dgdecode, overriding field order is superfluous, even dangerous. At the very least annoying needing two different variations, when one does fine.
Interp = SeparateFields().SelectEven().EEDI2(field=-1)
Deinted=TDeint(edeint=Interp)
TFM(mode=4,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)
Tritical, I'm curious, what is the logic behind setting TDeint's field to 0 if hints=true? I'd never noticed that before.

[Chainmax]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?
...

Yes, it still crashes with the error message pointing to the TDecimate line even removing everything after it, so I can't answer the firt part either.

[tritical]

@Chainmax
Yes, it still crashes with the error message pointing to the TDecimate line even removing everything after it, so I can't answer the firt part either.
The error msg is an access violation msg? To get the num/den values just remove tdecimate and put info() in its place:

MPEG2Source("X:\wherever\familytape.d2v",info=3)
Trim(0,1982)+Trim(2355,0)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
info()

and could you post the d2v file? Also, how big is the source file? ... the easiest way to debug the problem would be to have the source, but if it's really big I'll try with just the d2v file first.

@foxyshadis
TDeint sets field to 0 if it detects hints because telecide matches off the bottom field. TFM can match off either, but it includes the field that it matched from in the hints that it passes... so TDeint uses the field value in the hints in that case.

@Mug Funky
does this solve all the caching problems? because i've always had probs with the old smartdecimate (crash on 2nd pass start the most annoying one) Dunno. The only problem I specifically looked at was the crashing when bob and weave were set to the same clip. If you have any other problems just post a script causing it and I'll take a look.

@canuckerfan
The d2v file without the .bad extension should be free of field order changes, so the normal tdeint/tfm script should work fine. Also, mode 4 or 5 should be unnecessary if the field order doesn't change.

@Livesms
Reading the eedi2 and tdeint help files for descriptions of the parameters would be the easiest way to tell how the scripts you posted differ from each other. The default versions of tdeint+eedi2 are:

for same rate deinterlacing:

interp = separatefields().selecteven().eedi2()
tdeint(edeint=interp)

for bobbing:

interp = separatefields().eedi2(field=-2)
tdeint(mode=1,edeint=interp)

Then add assumetff() or assumebff(), whichever the video is, just before the interp line.

[Chainmax]

@Chainmax

The error msg is an access violation msg? To get the num/den values just remove tdecimate and put info() in its place:

MPEG2Source("X:\wherever\familytape.d2v",info=3)
Trim(0,1982)+Trim(2355,0)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
info()

and could you post the d2v file? Also, how big is the source file? ... the easiest way to debug the problem would be to have the source, but if it's really big I'll try with just the d2v file first.
...

Yes, the error message points to an access violation corresponding to the TDecimate line. The script you posted doesn't yield num/den values even if I add TDecimate in mode=7 before or after the info() line.
The source is a DVD and the VOBs occupy ~3.3GB, so unless you know of a place where I can upload at least 0.99GB at a time I'd have to snail mail it to you, which is ok y me if it comes to that. Anyway, you can download the d2v file here (http://www.31012.com/~azulftp/familytape.d2v). Let me know when you download it so I can delete it.

[Livesms]

I've got 720*480 29.970fps interlaced(telecined) video. Here is the sample (http://www.egoshare.com/63775068be522ecbf9b0803f9cad26f1/sampleavi.html).


I need to reencode it to play with PAL 4:3 25p

It's look like 4:2 pattern - 4 interlaced frames and 2 progressive frames, but it looks like this has been processed before - because the first of 2 progressive frames has some artifacts that look like a bad deinterlacing.

MeGui test analyse
http://j.foto.radikal.ru/0611/06513d2ba9b4t.jpg (http://foto.radikal.ru/f.aspx?j061106513d2ba9b4png)
And suggested script is
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=3)


But result is not good enough.

What can you suggest - is it possible to turn such video to 4:3 x 25p?

[Didée]

@Livesms - that's fieldblended crappola. The underlying "true" framerate seems to be 22 fps, perhaps 22.5 fps. (Not in the mood now to count exactly;) )
Pretty strange source. Qualified for cabinet of curiosities ...

[Livesms]

@Livesms - that's fieldblended crappola. The underlying "true" framerate seems to be 22 fps, perhaps 22.5 fps. (Not in the mood now to count exactly;) )
Pretty strange source. Qualified for cabinet of curiosities ...

You say 22fps source was telecined to 29.97 with 4:2 pulldown?

So is it possible to correct this source and make it 25fps progressive?

I tried
AssumeTFF()
ConvertToYUY2()
Bob(height=576)
BicubicResize(768,576)
ConvertFPS(50)
SeparateFields.SelectEvery(4,0,3)
Weave()

Look not bad 25i but now there is mixed video with some progressive frames and some interlaced.

[Didée]

Correcting myself: after having a 2nd look, it seems to have been standard 23.976fps film that has been blendconverted. (the source is so crappy, it's not trivial for the naked eye to decide what's a blend and what should be "assumed clean" :D )

Restore24 doesn't play too well with this source: result is jumpy. Try MOmonster's solutions, or the manual deblending approach (blow_up_fps plus SelectEvery(offset) ) that scharfis_brain did show several times.


Edit:

Seems like I'm telling nothing but nonsense this evening, and R24 is more reliable than my eyes. ;)
I got this result (http://rapidshare.com/files/3900394/livesms_R24.avi.html), using
Restore24(numr=2500,deno=5994,useLL=false,fulltriples=false,fra=1,frr=1,edgetype=1,r24size=0.7,nr=-5,ldmp=128.0)

[Livesms]

Correcting myself: after having a 2nd look, it seems to have been standard 23.976fps film that has been blendconverted. (the source is so crappy, it's not trivial for the naked eye to decide what's a blend and what should be "assumed clean" :D )

Restore24 doesn't play too well with this source: result is jumpy. Try MOmonster's solutions, or the manual deblending approach (blow_up_fps plus SelectEvery(offset) ) that scharfis_brain did show several times.

Ok. Thanks - I'll try.

Seems like I'm telling nothing but nonsense this evening, and R24 is more reliable than my eyes. ;)
I got this result (http://rapidshare.com/files/3900394/livesms_R24.avi.html), using
Restore24(numr=2500,deno=5994,useLL=false,fulltriples=false,fra=1,frr=1,edgetype=1,r24size=0.7,nr=-5,ldmp=128.0)
1.38 fps as a result - but total number of frames are correct for 25fps - so I should just andd AssumeFPS(25.00)?

[tritical]

@Chainmax
Could you try these two scripts and see if either crashes:

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,debug=true)

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,input="stats.txt",debug=true)

you'll have to generate a stats file for the second, but it should be very fast to make. The blankclip clip should be exactly the same as the clip going into tdecimate in your case except for the actual imagecontent. Both scripts work fine here.

[Terranigma]

tritical, will there be an update to Tdeint in the future, and if so, will it have this function Here (http://forum.doom9.org/showpost.php?p=889533&postcount=748) that you and I were discussing?
:D
It's seems like it'd function similar to the AdaptOvr (http://forum.doom9.org/showthread.php?t=117869) script I once requested, which i'll be happy with either or. :)

[tritical]

There will be one in the next week sometime. I've already added the tswitch function, fixed the problem with reading tfm's hints when passing through dgdecode's hints, and added a new blend deinterlacing mode. The remaining items are outputting a map and the deinterlaced frame at the same time (should be quick to add) and having the motion detection correctly handle the top/bottom lines (did about half of this already). Atm, I am messing other things.. neural network based edi, phase plane correlation motion estimation, and trying to improve some pso variations (clpso/dms-pso) for very high dimensional optimization (that last one is for school, but I'm using dms-pso/clpso to train the nn's for my nn-edi attempt).

[buzzqw]

i have a little problem

this script

Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)



and this is "createautodeintmovie.avs"

LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\dgdecode.dll")
LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\decomb.dll")
LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\TIVTC.dll")
movie = mpeg2source("C:\holding zone c\movie.d2v")
return movie

will produce some errors in "bautodeint_temp.data" (the log file), example (and all row are the same)

I don't know what "a" means-true
I don't know what "a" means-true
I don't know what "a" means-true


where is the error ?

thanks !

BHH

[Chainmax]

@Chainmax
Could you try these two scripts and see if either crashes:

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,debug=true)

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,input="stats.txt",debug=true)

you'll have to generate a stats file for the second, but it should be very fast to make. The blankclip clip should be exactly the same as the clip going into tdecimate in your case except for the actual imagecontent. Both scripts work fine here.

The first script works perfectly. I'll get to the second one soon.


The second one loads fine as well :confused:.
Maybe it's just some Avisynth weirdness on my end, so I guess I'll stick to either mode=0 or mode=7, could you tell me the pros and cons of either and on what kind of source they would perform better than the other?

[Wilbert]

Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
global diff=1.0
global a=true
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)

does that work?

[Chainmax]

Should I cut&paste that into a script and try to load it?

[buzzqw]

@Wilbert

Yes ! is working... now i will ask Berrinam to update BAutoDeint.exe

thanks again

BHH

[Livesms]

I'm sorry. Could anybody tell me what does it script for
Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
global diff=1.0
global a=true
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)

and where can I find createautodeintmovie.avs script. From script name I see it has some auto function for TDeint - does it mean this script analyse video and chose best setting for deinterlace?

[buzzqw]

http://forum.doom9.org/showthread.php?p=765485

not truly create an avs to deinterlace BUT analyze the clip, and find the "interlace pattern"

watch at result and then apply something like....

interlaced: LeakKernelDeint(order=xxx)
decimating: tfm(movie.d2v).tdecimate()
partly film: tfm(d2v="movied2v").tdecimate(hybrid=1)
film:tfm(d2v="movie.d2v").tdecimate()
partly interlaced:
edeintte=last.SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(full=false,edeint=edeintted)

(as automkv do...)

BHH

[Valeron]

hi, i'm new to tdeint and found it's not easy to tweak it for some stuff.

here's a sample
http://img205.imageshack.us/img205/7106/interlacesamplegr6.jpg

i've tried lowering the mthresh and cthresh to try catch the comb, type 1 and 3 are also employeed.
any parameter i missed can help improve the result?

btw, tomsmocomp(1,5,1) give me far better result, at least, no comb left, but i found the result a bit smeared.

[AVIL]

Hi,

Could be a problem of field ordering. To test it, use tdeint with only the parameter "order". Admits three value. -1, 0, 1. Try with 0 and 1. If the result is good with parameter 0 then your video is bff. If the resutl is good with parameter 1 your video is tff. In none is good, then really tdeint is not well suited. But is the first case I've heard of. Anyway is convenient post also the script used.

Good luck

[foxyshadis]

That pic is absolutely useless without some background, which would consist of posting at least both a short clip and your script.

[Chainmax]

Isn't animation usually telecined rather than interlaced?

[Valeron]

i'm sorry for forgetting post a short sample
here is a chopped vob

http://rapidshare.com/files/4665877/sample.vob.html

i simply use tdeint to deinterlace without any other filter, just lower the thresh and switch "field" to see if it help.

@Chainmax:
it's very source/scene dependent, some bad mixed dvd do exist.

btw, i've tried eedi2 as a same frame rate deinterlacer for this section and found it works excellent. but i can't leave it as 30fps cause it's so jerky. i'm considering a bobber.
anyway, i'm also looking forward a good settings with tdeint to see if the pixel based motion adaption would work more fantasy.

[foxyshadis]

I don't know where you got the idea that needs to be deinterlaced, but it is 100% telecined. It's a bit of an older telecine job, not perfectly smooth, bot tfm().tdecimate() does great on it.

Deinterlacing everything because a few hybrid dvds exist in the wild is a terrible idea, it'll cause all kinds of jerkiness and combing when ivtc is called for. That's why tdecimate has such good hybrid support.

[Valeron]

so sorry for missing checking the field patterns.....:stupid:
there's really something wrong with me these days......

now i see it's not interlaced but also not a popular telecined section with 3:2, since i can't find the matched field for some frames with decomb(i've overrided the matched field decision for any of the 3 field). do i have to go with postprocess? how does tfm+tdecimate solve this section?

and more, i don't deinterlace everything but just several scene i can't get rid of combs with ivtc(postprocess off)

thx

PS: i know this post is a bit off topic, if it really disturb the topics of tdeint, i'd like to see it splitted to the usage forum.

[foxyshadis]

When Decomb fails you, go straight to TIVTC before you start trying more esoteric solutions. There's a very good chance it'll detect or correct whatever problem your script has, and it'll give you more options for fixing it, without having to deal with manually override every movie. In fact, I never bother with Decomb at all anymore, TIVTC is almost as fast and so much better at handling hiccups.

I mean, using the defaults gave me excellent results on your clip; the pp took care of the residual combing from the bad post-telecine merge, even if it's not 100% smooth (which a deinterlacer will have just as much trouble on).

[Valeron]

@foxyshadis:
thx for the suggestion, tivtc sounds great.
i'll give it a try for my next rip

[tritical]

[link removed], changes:
tdecimate:
+ added sdlim parameter
- expanded file input line buffers from 80 bytes to 1024 bytes
- small change to debug output format of match/d2v duplicate info lines

tfm:
- expanded file input line buffers from 80 bytes to 1024 bytes

sdlim is the name I gave to the option ChiDragon asked for a few weeks ago. When using cycle based decimation with cycleR>1, tdecimate will not choose to remove any frames that are within "sdlim" distance of a frame that is already marked for decimation. Frames are marked for decimation in order from lowest to highest difference metric in the cycle (assuming it's not longest string mode). sdlim must be >= 0 and (sdlim*2+1)*cycleR must be <= cycle.

@Chainmax
I guess I'll stick to either mode=0 or mode=7, could you tell me the pros and cons of either and on what kind of source they would perform better than the other?
The major con of mode 0 is that it doesn't care about spreading out the decimation to maintain sync. If you have cycleR=10 and cycle=50, mode 0 could end up removing the first ten frames from the cycle if they happen to have the lowest difference metrics. Mode 7 will always spread the decimation and maintain sync pretty well, but it looks at only a small number of frames (usually 3-7) when deciding whether to keep or drop a frame. The addition of the sdlim parameter should help with the problems of mode 0, though in your case with cycleR=2003/cycle=5000 it wont have any effect. Mode 2 is a kind of hybrid method combining ideas from mode 0 and mode 7, but I haven't spent enough time developing or testing it to say how well it performs. Combined, I've probably tested mode 2 and mode 7 on a total of 4-5 clips.

[Chainmax]

Mode=7 it is then. Thanks for all the help :).

[ChiDragon]

Thanks for sdlim. If you don't mind my asking though, why are its possible values so constrained? I was able to set a limit of 3 with that code you gave me, but only 2 for sdlim (with cycleR=35, cycle=185). Doesn't seem like much but 3 vs. 2 really makes a difference in those black fades.

[tritical]

Actually, I got the formula slightly wrong. Instead of:

(2*sdlim+1)*cycleR <= cycle

it should have been

(2*sdlim+1)*(cycleR-1) < cycle

Allowing any larger sdlim size leaves open the possibility that tdecimate would not be able to mark a full cycleR worth of frames for decimation. That is worst case. Best case would be:

(sdlim+1)*(cycleR-1) < cycle

One possible option for allowing larger sdlim sizes would be to initially mark as many of the cycleR worth of frames as possible with the given sdlim value. If a point is reached such that there are still frames needing to be marked but it's not possible with the given sdlim value then decrease sdlim by 1 and try again to mark the remaining frames. Keep doing that until a full cycleR worth of frames are marked.

Another variation would be to try with the given sdlim value and if tdecimate runs into the problem of not being able to mark enough frames then decrease sdlim by 1 and start completely over. Keep decreasing sdlim until it reaches a value where it is possible to mark a full cycleR worth of frames.

When I say decrease sdlim I mean only for the current cycle being processed, not for the entire clip.

I think the second option would probably be more stable than the first option.

[ChiDragon]

What about doing the first run through with sdlim, and if there are still not enough frames marked, just disregard sdlim and place the extras at the lowest metric frames? That way the "properly" marked frames aren't disrupted, and if it's at a commercial edit point one of the black frames should be dropped. I think those should be the only places in my videos where sdlim would need to be lowered. If not, at least the extra necessary drop should be a fairly low metric. ;) I dunno how that would work for other people's usage of sdlim though.

This reminds me of something I was thinking about before and I believe was brought up at some point (maybe on the Decomb board), a different decimation mode where preference is given to drop frames whose neighbours have higher metrics, since duplicates in low motion are much less visible than duplicates in high motion. Maybe use dupThresh to mark dups, then find the differences between each dup's metrics and those of its previous and next frames (and average them?), and drop according to the highest of those.

What do you think?

[travisbell]

TIVTC v1.0 RC 9 (http://bengal.missouri.edu/~kes25c/TIVTCv1RC9.zip), changes:
tdecimate:
+ added sdlim parameter
- expanded file input line buffers from 80 bytes to 1024 bytes
- small change to debug output format of match/d2v duplicate info lines

tfm:
- expanded file input line buffers from 80 bytes to 1024 bytes

Hey guys, I don't know much about all this stuff but here's an issue I just discovered...

I have a 1080i source that, with the RC6 release of TIVTC.dll works properly. However, when I use the latest RC9 release, it doesn't. for whatever reason, it's not being IVTC'd.

I am using AutoMKV, so I am unsure his process, but you can see the discussion here: http://forum.doom9.org/showthread.php?p=909456#post909456

Is this a TIVTC.dll bug?

[tritical]

@travisbell
Could you post the actual avs script that AutoMKV generates? If you make your own avs script with just:

source()
tfm()
tdecimate()

Does it work? Between RC6 and RC7 I changed/removed/added some of tfm's parameters. That might be causing the problem. I'll try to look into later tonight.

@ChiDragon
Both ideas are possible. I am still not sure which method for the sdlim problem would be the best. I'm leaning towards the second suggestion I mentioned before, just because it would do the best job at evenly spreading the duplicate removal throughout the cycle. However, your suggestion would be better at handling uneven duplicate distribution. Your other suggestion could definitely be useful. Actually, mode 2 already does something similar to what you described, but it uses the minimum of the current/prev and current/next metric differences, as well as some absolute and relative thresholds. However, there are some problems with it.

[canuckerfan]

tritical, is TDeint2 in the works? just curious...

[buzzqw]

@tritical

this is the script used
http://forum.doom9.org/showthread.php?p=902705#post902705

bautodeint analyzing this log will decide to telecide or not... maybe the log produced is different from rc6 to rc7 ?

BHH

[tritical]

@buzzqw
Hm, the log produced by RC7+ should be the same as RC6 unless I managed to break IsCombedTIVTC... probably the most likely cause. I'm not at a computer I can test on atm though.

@canuckerfan
It is in various forms. I've worked on a new motion detection routine, heirarchical, overlapping, block based phase correlation motion estimation (all that I could figure out from a week of digging through all the bbc/wilcox/teranex patents I could find online), and edge directed interpolation using neural networks. The problem is that most of those pieces are only 50-75% complete.

In the short term, I almost have the next update for TDeint done. Besides the things I've mentioned before, I also added a 6 field motion check and the ability to run the motion detection on a clip other than the input clip.

[Terranigma]

@canuckerfan
It is in various forms. I've worked on a new motion detection routine, heirarchical, overlapping, block based phase correlation motion estimation (all that I could figure out from a week of digging through all the bbc/wilcox/teranex patents I could find online), and edge directed interpolation using neural networks. The problem is that most of those pieces are only 50-75% complete.

In the short term, I almost have the next update for TDeint done. Besides the things I've mentioned before, I also added a 6 field motion check and the ability to run the motion detection on a clip other than the input clip.

That sounds awesome; if it's not too much trouble, could you also add where it'd let us know which frame's considered progressive or interlaced like with Fielddeinterlace and/or telecide's show parameter? :D

[ChiDragon]

Terranigma, you can see whether a frame is being deinterlaced or not using the map parameter (any frame that doesn't have a map overlayed isn't deinterlaced, and vice versa). I agree that a real "display" parameter that would show the calculated MIC, the use of hints, etc. like the debug output would be nice though, eh tritical? :p

[Terranigma]

I know about the map function, but I'd prefer to get the info in text form.

[tritical]

Display output for tdeint is a good idea. Not sure it will make it in the next version though.

IsCombedTIVTC was indeed busted from RC7 on. When I changed the parameters of tfm I forced scthresh to be between 0 and 100 or an error would be thrown. Then I forgot to change the value that I was passing for scthresh when constructing the tfm object for iscombedtivtc (it was outside that range)... so tfm would throw an error, but avisynth just returned a clip with the error msg written on it. Then the script bautodeint uses would just get true all the time. I'll put up a fixed version tommorrow.

[travisbell]

Display output for tdeint is a good idea. Not sure it will make it in the next version though.

IsCombedTIVTC was indeed busted from RC7 on. When I changed the parameters of tfm I forced scthresh to be between 0 and 100 or an error would be thrown. Then I forgot to change the value that I was passing for scthresh when constructing the tfm object for iscombedtivtc (it was outside that range)... so tfm would throw an error, but avisynth just returned a clip with the error msg written on it. Then the script bautodeint uses would just get true all the time. I'll put up a fixed version tommorrow.

Good stuff man. Happy to see I wasn't on crack ;)

[Chainmax]

I tried to use avi_tc in order to conmvert a v2 timecode file to v1 and received an error message saying that a duration of <= 0.0 was detected. There is indeed a duration of 0, but even after deleting it or changing it to a positive value avi_tc gives the same error message. How can I solve this?

[tritical]

TIVTC v1.0 RC 10 (http://bengal.missouri.edu/~kes25c/TIVTCv1RC10.zip), changes:
TDecimate:
- sdlim changes

IsCombedTIVTC:
- fixed an error always being thrown by tfm on construction
resulting in it not working

For sdlim I changed it so that it must satisfy (sdlim+1)*(cycleR-1) < cycle. In the case that tdecimate can't mark a full cycleR worth of frames, if sdlim is entered as a positive number, then it uses ChiDragon's method. If sdlim is entered as a negative number, it uses my second suggestion.

@buzzqw/travisbell
The problem with IsCombedTIVTC always failing on construction is also what caused the "I don't know what "a" means-true" output in bautodeint's log. Therefore, this version should work fine without the need for declaring "global a =" elsewhere than where bautodeint defines it (it worked fine that way in my tests).

@Chainmax
Could you post the timecode file you're trying to convert?

[buzzqw]

tested on same source as posted by Travisbell , is all ok !

thanks Tritical !

BHH

[Chainmax]

Here's the timecode file:

http://rapidshare.com/files/6457377/street.fighter.the.later.years.1.txt.html

[IanB]

So it's a regular (30/1.001) fps exactly! file of 4470 frames with no temporal compression. The only anomaly is the last 2 frames have the same time index of 149082, probably a boundary bug in the encoder that was used.

[Didée]

Could it be there's a bug in TDeint's "APType" handling?

I just played a little with the sample given here (http://forum.doom9.org/showthread.php?p=913768#post913768), and it seems to me that

APType=0 : Artefact protection does exactly what it should
APType=1|2 : Artefact protection does nothing at all (not even with AP as low as 2|1|0)

[canuckerfan]

http://forum.doom9.org/showthread.php?t=119241

^anyone else experiencing discolourization during motion scenes using TIVTC?

[Thunderbolt8]

when using degrainmedian for denoising and fft3d for sharpening with commands Interlaced=true on an interlaced video and also using a command for deinterlacing, whats the order to place these commands ? degrainmedia and fft3d before the deinterlace command line ? or 1st the deinterlace command and then degrainmedian and fft3d, maybe even without interlaced=true, because then it should be already deinterlaced ? which way does preserve most quality ?

[DarkNite]

Most often it's deinterlace, denoise, sharpen. The reason for filtering interlaced is usually because you're leaving it interlaced.

[Thunderbolt8]

i cant keep it interlaced, it would cleary be seen later on when playing the video :S but does that mean, when deinterlacing the video, that the interlaced=true option is only restricted to the cases I actually want to keep it interlaced ?

[Isochroma]

Using the latest RC10, and the newest DGIndex (b7), I'm getting this error:

"TFM: d2v file is not a d2v file or is of unsupported format!"

I recently helped the author of DGIndex fix a problem with the d2v file format, and its version has incremented in b7, making it incompatible with previous versions. I assume TFM cannot parse the new format. Here (http://isochroma.com/Testfiles/Misc/doom9/Sample_b7_d2v.rar) is the .d2v file for your perusal.

[jmac698]

I was looking into the overrides file, but it's too limiting. Is there any way we could use an entirely external file of deinterlacing decisions? That would be really useful for multi-sourced video where one is progressive but a higher quality one has lost that information. For example digibeta tapes.

[DarkNite]

does that mean, when deinterlacing the video, that the interlaced=true option is only restricted to the cases I actually want to keep it interlaced ?

There are some occasions where denoising is called for before deinterlacing or IVTC, such as removing dot crawl, and a few other frequency interference noise types.

[tritical]

@jmac698
You could run tfm/tdecimate on one source with output enabled and then use those output files as input while processing another source. Of course, for that to work the two sources would have to sync exactly.

@canuckerfan
I checked the sample you pointed to, but I don't know what you mean by "discolourization." The artifacts are mainly from all the noise/dotcrawl causing tfm to choose the incorrect match or no good match existing. Maybe you could provide another sample clip?

@Didée
I looked at the clip you linked to and aptype works correctly for me. The problem is that on the bars a lot of the artifacts are in areas where many neighboring pixels were incorrectly detected as static. Aptype 1/2 wont trigger if less than 1/2 or 1/3 of the pixels surrounding the current pixel were detected as moving. Many of the smaller groupings are removed as expected with aptype 1/2.

@Isochroma
Thanks for the info, I'll put up a new version with d2v format v14 support today or tommorrow.

[buzzqw]

Thanks for the info, I'll put up a new version with d2v format v14 support today or tommorrow.

any news ?

thanks !

BHH

[tritical]

@buzzqw
Yep :).

[link removed]. Only change was d2v format v14 support.

Wanted to have the next version of TDeint out by now, but I've been busy. Will hopefully have some time over christmas to work on it.

[Terranigma]

Thanks for the update. I've been looking forward to a reply by you. Since you're here, I have a question.

How would I go about using tfm with an external deinterlacer such as securebob and tdecimate? When I deinterlace a frame, the current frame seems to be a clone of the new deinterlaced frame (using tdecimate modes 0 & 1) which results in jerky outputs; i'm obviously doing something wrong here. :D

A nice 'lil example would be sweet :)

Edit:
Here's an example of a script i'd probably use

Separatefields().DeBlock_QED().weave().TFM(mode=4,PP=0,slow=0).tdecimate(mode=1)
trim(0,4552)
interp = securebob().selecteven()
Tdeint(full=false,edeint=interp,mi=255,ovr="C:\Program Files\AVISynth Scripts\Defender.txt",ovrdefault=1)
vinverse()
Crop(14, 10, -14, -8)
bicubicresize(640,352)
TemporalSoften(2,4,5,15,2)
RemoveGrain(0,11)
backward_vec4 = last.MVAnalyse(isb=true, delta=2, pel=2, blksize=8, overlap=4, sharp=1)
forward_vec4 = last.MVAnalyse(isb=false, delta=2, pel=2, blksize=8, overlap=4, sharp=1)
last.MVDegrain1(backward_vec4,forward_vec4,thSAD=400)#, idx=1)
DeGrainMedian(limitY=0,limitUV=4,mode=1)
addgrain(1.5,0,0)
SeeSaw(NRlimit=2, NRlimit2=1, Sstr=1.4, Slimit=7, Spower=2, Sdamplo=8, SdampHi=10, Szp=10, bias=1, sootheT=30)

[canuckerfan]

@buzzqw
Yep :).

TIVTC v1.0 RC 11 (http://bengal.missouri.edu/~kes25c/TIVTCv1RC11.zip). Only change was d2v format v14 support.

Wanted to have the next version of TDeint out by now, but I've been busy. Will hopefully have some time over christmas to work on it.
Thanks. No worries, no one is any rush:)

Looking forward to it.

[Chainmax]

tritical, the latest version of dgmpgdec has bumped d2v to v15. Just a heads-up :).

[tritical]

@Chainmax
Thanks. I'll put up a new version soon. I may just take out the check for higher version numbers, since there hasn't been a change since about v8 that actually effected tfm's parsing of the d2v file.

@Terranigma
Your script looks fine to me. One problem might be that securebob doesn't behave well when frames aren't request linearly (maybe it does, I haven't tested). If you render these parts separately:

file1:
Separatefields().DeBlock_QED().weave().TFM(mode=4,PP=0,slow=0).tdecimate(mode=1).trim(0,4552)

file2 (file1 as input):
securebob().selecteven()

file3 (file1 and file2 as input):
avisource(file1)
Tdeint(full=false,edeint=file2,mi=255,ovr="C:\Program Files\AVISynth Scripts\Defender.txt",ovrdefault=1)
vinverse()

Does it work correctly?

[Didée]

Sorry for butting in with an OT comment, but now I've seen this

Separatefields().DeBlock_QED().weave().

thing one time too much. That's a BAD way of deblocking interlaced footage: 50% of all possible boundaries between vertically neighboured blocks are NOT deblocked this way!

The only correct way for interlaced sources is: (alas)

SeparateFields() .PointResize(width,height)
Deblock_qed() .AssumeFrameBased()
SeparateFields() .SelectEvery(4,0,3) .Weave()

[PuppZ]

DGMPGDec 1.4.9b10 is out. I can hardly wait the new TIVTC version which supports it. :-)

[tritical]

Luckily you didn't have to wait too long :D, [link removed]. Only change was d2v format v15 support in tfm. I also disabled the check for newer d2v formats (there hasn't been a change since v8 or v9 that actually effected how tfm parsed the d2v file). Currently, tfm wont correctly handle the d2v's of videos that have repeated frames (via the rff flags). However, since those should all be progressive tfm shouldn't be needed on them anyways.

I still had things on the todo list, but everything that was left would require a lot of changes to the current code that I don't want to make. Instead, I'm gonna start on a complete rewrite that will combine TIVTC/TDeint and be built from the ground up with all of the desired functionality in mind.

As far as TDeint, some of the new features I was planning I'm gonna hold off on for now. I'll try to release v1.1 soon with the following changes:

- new hints (handle new hints from tivtc that pass through dgdecode's hints)
- motion map check top and bottom lines (currently it doesn't check them)
- add tswitch()
- add new blend deinterlace mode
- output map and deinted frame at the same time

Since all of those things are already completed.

Not gonna give a time frame on the tivtc/tdeint combination filter... it might be next month or it could be next year :cool:.

[Chainmax]

Thanks for this new release :).

[Boulder]

I still had things on the todo list, but everything that was left would require a lot of changes to the current code that I don't want to make. As far as TDeint, some of the new features I was planning I'm gonna hold off on for now.Humm, was the option to multithread one of them?:scared: Since TDeint's one of the filters I use almost all the time, it would be a very useful one :) Nevertheless, thanks for your hard work!

[PuppZ]

Thanks :-)

[Zarxrax]

Wow, hardly anything changed but it seems like such a major milestone :)
I'm excited about the idea of the rewrite, I can't wait! Good luck with that.

[tritical]

Humm, was the option to multithread one of them? Since TDeint's one of the filters I use almost all the time, it would be a very useful one Nevertheless, thanks for your hard work!
It definitely is, since I have a dual core system now :).

[Adub]

Righteous! Thanks for the update tritical! And I await the next version, plus multithreading, with great anticipation.

[foxyshadis]

Ah, I guess the big painful blocking change that got 1.0 put off for a year or more was finally pushed aside for the next version (expect it by 2009!), I see. :(

I mean the conversion of the help to html, of course. ;)

I told you I'd have this to you some time back, but due to a couple of interesting functions and an accidental transposition of a single close parenthesis, it took much longer than it should have. (Side by side debugging of original vs modified is neat, but I could have done without it.) EEDI2 test MT version (http://foxyshadis.slightlydark.com/random/Eedi2mt.zip).

If anyone can get ICL to compile it, it's a good bit faster, but VC2005 SP1 broke mine.

[MacAddict]

Wow! Multithreading? I can hardly wait! Many thanks to all for the efforts.

[Moitah]

@foxyshadis: Very nice! On my E6600 it's faster than the normal version by a factor of 1.61, and the output is bit-identical.

EDIT: As for stability, I let it run for a few hours on over 80,000 frames and it didn't deadlock/crash.

[Adub]

links broken

Edit: fixed, thanks Foxyshadis.

[tritical]

TDeint v1.1 (http://bengal.missouri.edu/~kes25c/TDeintv11.zip), changes:
+ added TSwitch() filter
+ added new blend deinterlacing mode (type = 5)
+ expanded ovr line input buffers
+ added new map outputs (map=3/4) which output both a map and deinterlaced frame
+ map output works correctly with ap post-processing
+ map output works correctly with hints/ovr/full/tryweave
+ support passing through of dgdecode hints and tivtc's new hints
+ added ability to run motion detection on a separate clip (emtn parameter)
- motion map now checks top/bottom lines


@foxyshadis
Thanks for the mt'd eedi2. I'll put it up as version 0.9.3 on my site, if you don't mind, as soon as I get a chance. I don't have the intel compiler so I can't make an ICL build.

[Zarxrax]

Nice! Could you please describe how exactly the new deinterlacing mode works, what sort of situations it is good for, that sort of thing?

[tritical]

It's exactly the same as traditional blend deinterlacing, except that it averages temporally in the field not being kept (between prv/nxt) instead of just using whichever one happens to be weaved into the current frame. It's probably not good for much unless you want and/or need blend deinterlacing, in which case disable motion-adaptation (blend deinterlacing doesn't work well with motion-adaptation). Mode 5 should be slightly more compressible than mode 4. Mode 5 is similar to alignfields mode 3 minus the spatial blurring. Pretty much I just added it because I could.

[squid_80]

If anyone can get ICL to compile it, it's a good bit faster, but VC2005 SP1 broke mine.
Made an x64 build: http://members.optusnet.com.au/squid_80/EEDI2_imp64.zip

I had to comment out one of the #pragma omp lines (in EEDI2::fillGaps2X) since it gives VS2005's x64 compiler an internal error. I even installed SP1 (piece of crap!) to try and fix it, but no luck. Also tried ICL 9.0 and the results were poor compared to VS2005, so I just left the line out and decided to wear it.

[ChiDragon]

tritical, any chance of a fix for TIVTC still calculating all the metrics when it has them from input files? I'm working with over 200-frame decimation cycles on HD content -- seeking is excruciating! :eek:

[tritical]

Thought I had fixed that back in October :angry:. Is your script just the basic:

mpeg2source()
tfm(input="")
tdecimate(input="",tfmIn="")

?

[Isochroma]

Just noticed that b13 of DGIndex came out. One of the changes listed is:

* The Correct Field Order option is removed and the field order correction function is now available through the Tools menu: Fix D2V. I did this because this correction should not be applied to streams with frame repeats, and trying to prevent it via a code check runs into technical complications.

Will a wrong field order have any effect on TIVTC?

[ChiDragon]

Oh, I didn't know I had to use tfmIn for it to work! Sorry about that. It makes sense considering it would need to grab every frame to get the hints otherwise. The only mention I see of that in the TDecimate readme is in the Changes List section. Maybe you should add it to the tfmIn description for us dummies. :p (right now it says that it's only useful for hybrid > 0)

I get an invalid specifier error when trying to use tfmIn for files output with PP=0 in TFM though. :(

[tritical]

@Isochroma
If you use the d2v="" parameter in tfm, then it checks for illegal field order changes in the d2v (wont work with frame repeats, but tfm shouldn't be needed on those streams)... so it wont matter there. If you don't use the d2v parameter, use a matching mode that can't handle field order changes (only modes 4 and 5 can), and the stream does have field order changes, then there will be a problem.

@ChiDragon
An explanation in the tdecimate readme is probably a good idea. Another way to get around the need for the tfmIn file is to set hints=false in tdecimate. However, then tdecimate wont get to use any info from tfm. The basic chain of events when tdecimate runs is:

startup:
0.) If hints isn't manually set by the user, then grab frame 0 and detect if there are hints in it. If there are, set hints=true, else, set hints=false.

during operation:
1.) If there's a tfmIn file, don't read hints for frames that the tfmIn file has info for.
2.) else if hints=true, reads hints for frames that don't have info from a tfmIn file.
3.) else if hints=false, never read hints

I'll check out the problem with the pp=0 files.

[tritical]

Found and fixed the problem with tdecimate reading tfm output files created with pp=0. I'll put up a new version soon (a work around would be to just use pp=1 in tfm, though it will be slightly slower than pp=0 depending on the matching mode). I am also considering changing the sdlim default in tdecimate so that when cycleR > 1 it defaults to the largest possible value such that there would never be any cases where it couldn't mark a full cycleR worth of frames. I'm thinking that when someone uses cycleR>1 they are generally looking for the decimation to be spread throughout the cycle as sdlim allows instead of actually removing the cycleR frames with the lowest metric (which could all be next to each other).

[ChiDragon]

Thanks! Yeah, I've been using PP=1 in the meantime.

I'm not sure defaulting sdlim to the largest possible value is a good idea. With the videos I'm encoding now that need sdlim=2, setting sdlim to 3 (or -3) makes TDecimate drop non-dups often. Actually, it drops wrong frames every cycle, but most of them don't matter as it's simply dropping the first of two same-frames (they're only "wrong" since you'd normally want to drop the 2nd frame, with the low metric). The trouble comes at the start and end of the cycles, where it may drop an actual dup at the end of a cycle and then drop a new frame at the start of the next cycle.

[ChiDragon]

I've got a weird crash happening now... I'm using this ovr line: 80194,80303 ++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-+++-+++-++++-++++-++++-+++-+++-++++-++++-++++-++-++++-++++-++++-++
and whenever I try to seek to any of the frames in that cycle, VirtualDub crashes. It's the last cycle of the video, and it doesn't crash without that line. It also doesn't crash if the same line of specifiers is used for earlier frames.

[cacepi]

I've got a weird crash happening now... I'm using this ovr line and whenever I try to seek to any of the frames in that cycle, VirtualDub crashes.
Just a stab in the dark, but why is your ovr line so long? You have almost twice as many overrides as frames in the range.

[ChiDragon]

Well, I took the ovr line for a full cycle and just copied and pasted it to this partial cycle (partial because the video ends before it completes). I haven't had problems with redundant overrides before, and using that full line for the range "79992,80002" doesn't cause a crash.

[Terranigma]

tritical, I know this is offtopic, but I was wonderin' if you could perhaps compile speedier versions of Didée's filters such as SeeSaw, Deblock_QED, LimitedSharpenFaster, Mcbob, Soothe, Spresso like how you did for Vinverse?

Probably not gonna happen, but I thought i'd ask since it usually don't hurt to do so :D

btw, keep up the nice work. :)

Edit:
tritical, if you or someone else who's interested in porting these filters to .dlls need the scripts, (the latest versions), let me know.

[tritical]

The biggest problem is that I don't know the inner workings of a number of the scripts you metion, some of which are very complex, so it would take me some time to go through them before I could even start turning them into filters. Some of the simpler ones, like Soothe and Spresso, I could do pretty easily, but I don't think there would be much of a speed up since they are mainly just lutxy calls. Though in memory intensive scripts it might help since it would cut down on the number of filters/clips being created and thus cache instances.

Could you post a link to the latest versions of Soothe/Spresso, just to make sure I'm looking at the right ones? I might take a stab at them sometime.

[Terranigma]

Sure. Here (http://www.savefile.com/files/474238)'s a link for both soothe & spresso :)

[Chainmax]

I'm having a weird issue: when using the folloeing IVTC lines:

Deinted=TDeint(order=1,field=1,type=1)
TFM(d2v="C:\SimpS7\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

I receive the following error message:

http://img403.imageshack.us/img403/8568/errmsgba3.png (http://imageshack.us)

If I remove the "d2v=..." part in the TFM line, the .AVS loads without an issue. What could be causing this?

[Alain2]

It's written.. apparently you set order=1 and the d2v info probably says order=0...

[tritical]

Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.

[Chainmax]

Alain2: the video is TFF for sure and I even put an AssumeTFF() before the code snippet I posted. Alas, I upgraded to dgmpgdecv1.49b14 right before trying to load the scripts, whereas previous attempts used b13, so tritical is right on the money :).
I patiently await for news, master :D.

[foxyshadis]

Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.

It was punishment for your hybris in removing the version check. ;p

Perhaps it's time to create a well-defined format and some smarter shareable parser code to go with it? (Not to be an xml-solves-all-things sort, but it would make the parsing easier. But then you'd have to include expat, meh.)

[Terranigma]

I was gonna post about this other day, but I did'nt wanna bother tritical too much; but support for the latest beta version would be great.:p

[tritical]

@ChiDragon
Could you post the entire script you were using that caused the crashes? I tried to reproduce with:

blankclip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000)
tdecimate(ovr="ovr.txt")

where ovr.txt had the single line you posted, but it doesn't crash for me.

@foxyshadis
Yeah, I thought it was quite funny that the very next version after I removed the check wouldn't work. However, adding support for new d2v format versions isn't actually much of a problem atm (it took only 4 lines of code to support v16).

When you say create a well defined format and sharable parser code are you talking about creating a parser separate from tivtc and having it create a file that tfm could read instead of tfm parsing the d2v itself?

[Terranigma]

How are you guys actually using an ovr file with tdecimate? I'd try everything to specify a dropped frame or pattern, and it seems to be of no effect. The frame that i've specified to drop would still be there.

I'd use tfm with tdecimate sorta like this
tfm(mode=4,pp=1,slow=2,flags=1,hint=true)
tdecimate(mode=1,expp=true,ovr="C:\Myovr.txt")

The "ovr" file would read something like this
217 -

[tritical]

@Terranigma
ovr file works fine for me. Could you add display=true to the tdecimate() line, go to the cycle that includes frame 217 of the input (should start at frame 172 of the output), grab a pic of one of the frames, and post it here? It will show '**' next to whichever frame in the cycle has been dropped.

[Terranigma]

@Terranigma
ovr file works fine for me. Could you add display=true to the tdecimate() line, go to the cycle that includes frame 217 of the input (should start at frame 172 of the output), grab a pic of one of the frames, and post it here? It will show '**' next to whichever frame in the cycle has been dropped.
OK. when I entered 217 -, frame 172 was dropped.
I thought the way it works is, it'd drop whatever frame(s) I entered in the ovr file. Thanks for the help! :)

[ChiDragon]

@ChiDragon
Could you post the entire script you were using that caused the crashes? I tried to reproduce with:

blankclip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000)
tdecimate(ovr="ovr.txt")

where ovr.txt had the single line you posted, but it doesn't crash for me.

This should crash when you seek to any of the frames in the ovr cycle:


BlankClip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000)
TDecimate(cycleR=44,cycle=202,ovr="ovr.txt")

[tritical]

Thanks, when getting the ovr info it wasn't adjusting the maximum number of frames that could be dropped if the last cycle wasn't full length.

TIVTC v1.0.1 (http://bengal.missouri.edu/~kes25c/TIVTCv101.zip), changes:
tfm:
+ Support d2v file format v16
- fixed a bug in tfmpp destroying hints
- fixed generating ovr help info about combed frames in output files when PP=0

tdecimate:
- fixed reading in tfm output files created with PP=0
- fixed a bug in destroying hints on frame output
- fixed a bug in drop/keep frame overrides in the last cycle of a video if the cycle
was not full length

[Terranigma]

tritical. what can I say.... other than thanks?
Thanks for the updated release! :D

[Terranigma]

tritical, if you ever decide to release another update, could you perhaps add another mode for BFF material? Matches for only c & n frames? :)

[tritical]

Not sure I understand your request, since there shouldn't be any need for a field order specific matching mode. With bff material it only makes sense to match c/n if matching off the top field... just like it only makes sense to match c/n for tff material if matching off the bottom field.

If you have a bff clip and want to match off the top field use:

tfm(order=0,field=1,mode=0)

in which case tfm will only use c/n matches.

[Terranigma]

ok thanks. I figured it out yesterday. :)

[radar]

hi,im trying to clean up this clip...http://rapidshare.com/files/16554591/VTS_01_1.VOB.html.

im a noob to using filters and writing scripts.would TDeint and TIVTC work on this clip and if so how would the script be written.thanks

[foxyshadis]

I posted another compile of MT EEDI2, exact same source, but the latest version of ICL9 works with VC2k5 SP1 now. (That's what the i in imp stood for. :p) I patched it so hopefully it works on Athlons, I'd like some feedback, whether it works and if it's any faster than the VC one.

http://foxyshadis.slightlydark.com/random/Eedi2mt.zip

[Xesdeeni]

Using tivtc, I have a video that ends up slightly stretched in time. The video is the correct duration, but the last frame is not at the end of the source. As a result, my audio is out of sync with the video.

Details are in this thread (http://forum.doom9.org/showthread.php?p=956612#post956612), but the synopsis is:

I'm converting an OTA HD TS captured from ABC to HD DivX (our local ABC affiliate converts the 720p to 1080i, hence the need for tivtc). I used DGIndex 1.4.9 beta 14 to extract the AC3 and create the D2V file. I used AVISynth 2.57 and with some help, I was able to determine that the video was telecined at something like 23.2603 fps. For the best results, I'm creating a 23.2603 fps progressive video and remuxing it with the original AC3 using VirtualDubMod and the latest DivX codec.

I used the following script:MPEG2Source("Toy Story (WFAA).d2v")
AssumeBFF()
Crop(0, 0, 0, -8)
tfm() #mode=5
tdecimate(mode=2, rate=23.2603)
LanczosResize(1280, 720)When I view the video (in VirtualDubMod, but I had already encoded the video to DivX when I noticed the audio sync issue on the PC and on my Zensonic Z500), I see that although the duration of the video is correct, the video is not finished on the last frame. The credits fade to black in the source, but the fade is not there when viewing the telecined version. On this 1:19:37.96 video, a little more than 1 second is cut off. This is the cause, but the effect I noticed was that the audio was out of sync by a bit over a second at the end of the movie (it was fine at the beginning).

This is with your latest release, version 1.0 final.

I noticed in playing around, that if I use 23.976, it doesn't seem to end early.

FDecimate doesn't seem to do this, but it has serious problems picking the right frames to discard in this noisy (fairly significant pre-processing and MPEG-2 artifacts) source.

Xesdeeni

[Eggroll]

Hello, I noticed how trimin allows the trimming of the d2v prior tfm operation. Is there a way to add frames to the d2v before tfm instruction to do the exact opposite? Allowing for duplicateframe for instance.

Thank you in advance.

[tritical]

@Eggroll
There isn't, but it could be added as part of the trimIn parameter... could you give the exact details of what you are wanting to do?

@Xesdeeni
I'll try to figure out what's wrong with mode 2. It was never tested much with non-standard frame rates.

@radar
It's pure interlaced, so a basic script would be:

mpeg2source()
tdeint()

I would recommend that you search the avisynth usage forum and try out some other deinterlacers to see which is best to you in terms of speed/quality. Some common deinterlacers are: leakkerneldeint, tdeint, tdeint+eedi2, securebob, mvbob, mcbob. You'll also have to decide whether or not you want double framerate (bobbed) output or not. Sports footage with fast action and sharp lines/edges is probably the toughest type of video to get good deinterlacing results on.

[Terranigma]

Guys. what would be the correct way deinterlace ntsc film material? Doing a field blend or interpolation? When I do a interpolation deinterlace, the deinterlaced frame becomes a clone of the next frame causing jerky playback, so field blending seems to be the best way to go. Perhaps there's another way I should go about doing this? :rolleyes:

[radar]

hi tritical,thank you for your reply.

i have another question and sorry if its a dumb one.
i can see why you put tdeint() in the script but what is mpeg2source() for.again sorry if this is a dumb question.

thanks

i think i answered my question.im using dvd rb with the filter,and rb puts mpeg2source() in for me.if im wrong please correct me.thanks

[jeffy]

hi tritical,thank you for your reply.

i have another question and sorry if its a dumb one.
i can see why you put tdeint() in the script but what is mpeg2source() for.again sorry if this is a dumb question.

thanks
For loading your MPEG-2 file, after you indexed it with DGIndex:
http://www.neuron2.net/dgmpgdec/DGIndexManual.html#WhatIsDGIndex

http://neuron2.net/dgmpgdec/QuickStart.html
http://www.neuron2.net/dgmpgdec/DGDecodeManual.html#MPEG2Source

[Leak]

Guys. what would be the correct way deinterlace ntsc film material?[...]Perhaps there's another way I should go about doing this? :rolleyes:
If it really is film, as opposed to video, you need to do field matching followed by decimation to get back to the original 24FPS framerate, i.e. you need TIVTC.

TFM(order=0 or 1)

followed by

TDecimate(mode=1,hybrid=0 or 1)

should be a good starting point...

[Eggroll]

@tritical

I wanted to "edit" a d2v so the frames would match the ones from another d2v (r1 vs r2 in this case) prior tfm operation. Since to match r2 with r1 I need to trim some frames here and duplicates some frames there, it was impossible in this situation.

I used another approach though. I removed the d2v parameter and simply trim or duplicate frames between mpeg2source and tfm instruction. Works like a charm and I don't have to use a trimin file anymore.

I guess it could be a nice feature to add if you've got some time to waste... If you can trim so why not be allow to add duplicate frames? But since I seem to be the first to ask for such a thing and that I found a workaround, I guess there really is no need for such a feature at this time.

Anyway, thank you very much.

[Terranigma]

If it really is film, as opposed to video, you need to do field matching followed by decimation to get back to the original 24FPS framerate, i.e. you need TIVTC.

TFM(order=0 or 1)

followed by

TDecimate(mode=1,hybrid=0 or 1)

should be a good starting point...

Actually, it's ntsc video 30000/1001 that I ivtc'ed and decimated to film ensuring that each frame is different. I was wonderin' if i should deinterlace first, then decimate, or decimate then deinterlace.

[radar]

jeffy

thanks for your reply,and thank you very much for the links.

[manono]

I was wonderin' if i should deinterlace first, then decimate, or decimate then deinterlace.
Neither; field match followed by decimation (TFM().TDecimate()), just as Leak explained.

[Leak]

Actually, it's ntsc video 30000/1001 that I ivtc'ed and decimated to film ensuring that each frame is different. I was wonderin' if i should deinterlace first, then decimate, or decimate then deinterlace.
Well, what you *shouldn't* do in any case is to unconditionally deinterlace the result of fieldmatching and decimation, as that will only worsen the image quality

That's why TFM has postprocessing options to actually deinterlace combed frames that resisted field matching. Try to tweak those options to eliminate any interlaced remains.

[Terranigma]

Thanks Leak, manono. :)

[ChiDragon]

tritical, I've found another weird bug... :confused:

Try this:


BlankClip(pixel_type="YV12",length=11,fps_denominator=1001,fps=30000)
TFM(input="test1.txt")
TDecimate(input="test2.txt",display=true)

With test1.txt:
#TFM v1.0.1 by tritical
5 p - [60]
6 c - [118]
7 p - [6]
8 c - [17]
9 p - [3]


test2.txt:
#TDecimate v1.0.1 by tritical
4 21320 546816
5 7194 169921
6 23761 599224
7 5737 181105
8 13369 452464
9 2606 170827


Frame 5, with a metric of 2.12 is dropped instead of frame 9 (0.77). If TDecimate is set to mode = 1 instead of 0, or hint = false instead of true, the correct frame is dropped!

[tritical]

@ChiDragon
It happens due to one of the 'special handling' functions mode 0 uses over plain "drop the frame with the lowest metric mode." When match information from tfm is available, tdecimate will detect match duplicates and one of the things it then looks for are standalone duplicates (a frame that is a match duplicate and neither of its neighbor frames are). It then goes through the cycle and determines which of these standalone duplicates to decimate (assuming there is more than 1) based on the sum of the next frame's difference metric and the previous frame's difference metric... whichever standalone has the largest sum is chosen. The only extra check is that the selected frame has at least the n'th lowest metric in the cycle, where n is the number of standalone duplicates. In this case, there are 3 standalone duplicates, frame 5 has the largest sum, and it has the 3rd lowest metric in the cycle... so it gets decimated.

There should probably be a check related to the selected frames metric (either hard, or relative to the lowest metric in the cycle) before it can be chosen for decimation. Including the current frames metric in the decision about which standalone duplicate to choose would probably also be a good idea. Looking at the code, it seems I had included a variable to keep track of the selected frames metric, but it never gets used for anything :rolleyes:. Anways, I'll take a look at this later this week when I should have some free time again.

[Leak]

Hi tritical,

in case you're interested - I've written a patch for ffdshow's AviSynth filter (my latest build is here (http://forum.doom9.org/showthread.php?p=968844#post968844), more info here (http://forum.doom9.org/showthread.php?p=968561#post968561)) that allows you to use TFM/TDecimate (and of course a slew of other filters) on the fly during playback. Maybe you (or whoever else reads this, of course) would like to give it a try? :)

[tritical]

Awesome, I quickly tried it out on my laptop (the ffdshow version on here was from 2005 :eek:) and it worked great. If anyone has problems with tivtc using too much cpu, changing the following settings should speed things up without sacrificing much:

tfm(slow=0,mchroma=false,pp=2 or 3)
tdecimate(chroma=false)

While I was testing, the cpu load went to 100% briefly on a few complex scenes (my laptop has a 1.6Ghz pentium M) and averaged ~60-65%. With the changes mentioned above it never broke 85 and averaged ~50-55%.

Also, there might be the smallest bit of jitter due to tdecimate. Currently, while it is returning frames for the current cycle it computes the metrics for the next cycle one frame at a time (it does that so that it doesn't have to request and compute metrics for all 5 frames at the beginning of each cycle). However, that only takes care of 4 frames and at the beginning of each cycle 2 frames will have to be requested and computed. I couldn't notice it though. Probably tdecimate is fast enough that it doesn't matter (even on my laptop it runs > 1000fps, assuming no blending is required).

[Leak]

Awesome, I quickly tried it out on my laptop (the ffdshow version on here was from 2005 :eek:) and it worked great.
:D

It never really had a chance of working before as the old AviSynth filter implementation in ffdshow always returned the same frame no matter which frame got requested by AviSynth - so I set out to fix that... :)
While I was testing, the cpu load went to 100% briefly on a few complex scenes (my laptop has a 1.6Ghz pentium M) and averaged ~60-65%. With the changes mentioned above it never broke 85 and averaged ~50-55%.
It hardly goes above 30% on my Athlon 64 X2 4400+, but since that's a dual-core machine it means about 60% of one core is used. But hey - at least I can now watch my anime DVDs like they were meant to be watched, and using my tiny projector (http://www.samsung.com/uk/products/projectors/mobileprojector/spp300memxedc.asp) (don't laugh) to boot... :)

Now my patch only needs to get checked into the ffdshow-tryouts SVN...

[Chainmax]

tritical, here's a sample of a scene that's been giving me trouble:

http://www.bestsharing.com/files/HL7M0Yw241160/Sample.demuxed.m2v.html

The deinterlacing portion of the script is this:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,type=1,edeint=Interp)
TFM(d2v="C:\SimpS7\e3\Epi3.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted,micmatching=3)
TDecimate(mode=1)

which I think leaves some residual combing but I'm not sure wether it's that or the picture itself is just fux0red. Could you please take a look at it?

[Terranigma]

Could someone tell me, what are the advantages as to using/disabling mchroma?

[Leak]

Could someone tell me, what are the advantages as to using/disabling mchroma?
Well, this controls whether TFM takes the color information into account when matching fields, in addition to the luma information.

There's material out there where the chroma has been botched (rainbows, color delayed a field or three vs. luma, plus other stuff I don't even want to imagine) so disabling it for matching will probably give better results in those cases. That, and it of course takes some extra time for the extra checks.

Of course, if you have a scene where the luma stays the same and only the chroma changes the outcome will be pretty random - but that's rather unusual for normal footage.

[foxyshadis]

tritical, here's a sample of a scene that's been giving me trouble:

http://www.bestsharing.com/files/HL7M0Yw241160/Sample.demuxed.m2v.html
I think it's pretty safe to say it's not TIVTC/TDeint's fault... output of separatefields (http://foxyshadis.slightlydark.com/random/badsimpsons.jpg).

BTW, tritical, did you have a chance to test out my newer compile? I think it's worth replacing the old one, just because apparently it crashes for older cpus.

[Chainmax]

I think it's pretty safe to say it's not TIVTC/TDeint's fault... output of separatefields (http://foxyshadis.slightlydark.com/random/badsimpsons.jpg).
...

I had already seen those scenes, but take a look at this:


Result:
http://img473.imageshack.us/img473/7389/result47923hu3.th.png (http://img473.imageshack.us/my.php?image=result47923hu3.png)

Corresponding frame with AssumeTFF().SeparateFields():
http://img473.imageshack.us/img473/2695/corresp47931fh5.th.png (http://img473.imageshack.us/my.php?image=corresp47931fh5.png)

Previous frame:
http://img232.imageshack.us/img232/3313/47915di1.th.png (http://img232.imageshack.us/my.php?image=47915di1.png)

So maybe some parts could be slightly improved.

[rottweily]

I have serious trouble in deinterlacing this tennis sequence:
LineNastyness-Interlaced.mkv : http://www.mediafire.com/?5nkmnk2nzyd
LineNastyness-TDeint.mkv : http://www.mediafire.com/?ci2jiitbbmi
LineNastyness-TDeint+EEDI2.mkv : http://www.mediafire.com/?amdxqmymie2
LineNastyness-TDeint-Type4.mkv : http://www.mediafire.com/?0dyzdq3nv2n
LineNastyness-TDeint-Type5.mkv : http://www.mediafire.com/?djcyjd0enm3

You can't miss the artifacts.
I've always used TDeint with all the matches I've encoded and till now never noticed any obvious artifacts.
As you can see I've also tried using EEDI2, but it didn't help.
Any simple solution?

Edit: I already see that I have an outdated version of TDeint, time to upgrade. Already tested it, has the same problem.
The new blend interpolation already works a lot better type=4 or 5, but still not ideal.

[tritical]

Sorry for the lack of replies, I just haven't had much free time lately. Next week is spring break though :) (Yes, we have spring break 2 weeks after everyone else).

@rottweily
The links wouldn't work for me, but if you set mthreshL=0,mthreshC=0 do the artifacts go away? If so (I am guessing they will), then it's just standard motion-adaptive artifacts, and there isn't much you can really tweak as far as TDeint to make it go away other than mthreshL/mthreshC/mtnmode. You might try running vinverse() afterwards, but that might not help much if the artifacts are a lot stronger than normal residual combing. It might be worth giving securebob() a try.

@Chainmax
I must be blind, what exactly am I suppose to be looking at in the images you posted?

@foxyshadis
I haven't, but I'll try it soon. The link to your version that I have on my website just links to Eedi2mt.zip on your webspace so anyone who gets it from there should get the latest version. I need to put a link to it in the first page of this thread also.

[foxyshadis]

Oops, I never noticed that. Hah!

I think chainmax refers to this:
http://foxyshadis.slightlydark.com/random/sresult.jpg
But that comes from:
http://foxyshadis.slightlydark.com/random/sorig.jpg

There's a lot of large and small artifacts just in that short piece posted, whomever transferred it really did a great job of mangling it.

[Didée]

@ rottweily (& tritical not having seen the clips)

The problem here is just the usual threshold disease ("up to x is static, bigger than x is motion").
Remember the look of the scene when a tennis match is filmed from the usual bird's view camera position. When the camera is perfectly static, then the "deinterlaced" lines are 100% static. But heaven forbid that the camera starts moving even so slightly ... then hell breaks loose. (The "deinterlacing hell".)
In that regard, it's a worst-case scenario ... the lines are of very high contrast (white lines with a small black halo). Because of the high contrast, even with mini-minimal motion the usual motion thresholds are exceeded immediately. And because of the high white-to-black contrast, the wobbling seems so extreme and annoying.

SecureDeint won't help here ... it's more "anxious" about motion, hence it will produce even more wobbling. (Probably, didn't try it.)

Bigger thresholds won't help either, you'll loose the ball to blending land.

What would (and will) help is MCBob's smart thresholding, which is adaptive to local complexity.
(Have been wondering that there were no requests to combine this smart-thresholding with some not-mo'comped deinterlacing, à la MVBob-->SecureDeint ...) :)

***

BTW, the idea behind and justification of the smart thresholding in MCBob is very easy: at each pixel's location, there is a certain min-max value of the neighborhood - it's small for flat areas, big for detail areas. Now: If we consider up to 1/4 pel motion as "static", and 1/2 pel motion as "motion", then changes up to (max-min)/4 (+N) for that pixel are considered static, pixel changes bigger than (max-min)/2 (+N) are considered "motion", and inbetween is considered inbetween. (N is a small tolerance value to compensate for general flicker.)

One example with numbers: on a black-white transition of some high-contrast detail, the min-max-span is, say, (max-min)=200. Now, if there is some minor motion of only 1/4 pel (which is neglectable for the matter of deinterlacing), the pixel might change by already +/- 50. Fifty! With (fixed) motion thresholds being usable mostly/only in the range 2~10, it's no wonder that deinterlacing usually produces shimmering, flickering and wobbling ...

Hard thresholding obviously fails miserably here.

Smart thresholding is a simple idea, works out, and free to use. ;)

[Chainmax]

...
What would (and will) help is MCBob's smart thresholding, which is adaptive to local complexity.
(Have been wondering that there were no requests to combine this smart-thresholding with some not-mo'comped deinterlacing, à la MVBob-->SecureDeint ...) :)
...

Well, McBob seems to be the best available deinterlacer/bobber we have right now, and people who use it are willing to sacrifice speed for quality. Therefore, I don't see much use in trying to enhance MVBob as it's already very slow and apparently not as good. SecureDeint might be a better candidate for this enhancement, but my favorite candidate would be Tdeint as it's extremely fast in comparison and according to WorBry's tests it's pretty close to the big three.

[rottweily]

What would (and will) help is MCBob's smart thresholding, which is adaptive to local complexity.
(Have been wondering that there were no requests to combine this smart-thresholding with some not-mo'comped deinterlacing, à la MVBob-->SecureDeint ...) :)


Didn't help enough, I will keep the interlaced version.

[tritical]

I might add the smart thresholding idea to TDeint. When you talk about the min/max of the neighborhood do you mean within the same field or both fields? say the x's are the top field pixels, the o's are the bottom field pixels, and we're trying to create the missing pixel 'c'. The neighborhood for determining the min/max for the motion threshold for 'c' would consist of which pixels?

frame 0 frame 1 frame 2
xxxxx xxxxx xxxxx
ooooo ooooo ooooo
xxxxx xxxxx xxxxx
ooooo c ooooo ooooo
xxxxx xxxxx xxxxx
ooooo ooooo ooooo
xxxxx xxxxx xxxxx

Maybe you could just copy the above diagram and indicate the needed pixels by making them bold. I was thinking it would be the 3 x's above and below 'c', but want to make sure.

EDIT: I've been looking at this a little more and I don't quite understand why the threshold is based on the range (max-min) of the neighborhood. Let's say we have the following 9 pixel neighborhood from a single field:

abc
def
ghi

if we allow 1/4 pel motion for pixel 'e' and assume linear interpolation will give an accurate result for this motion. Then the possible values for the new 'e', assuming only vertical or horizontal motion for the moment, would be:

0.75*e+0.25*b
0.75*e+0.25*f
0.75*e+0.25*h
0.75*e+0.25*d

Which would mean the threshold for 'e' should be the max of:

abs(e-(0.75*e+0.25*b))
abs(e-(0.75*e+0.25*f))
abs(e-(0.75*e+0.25*h))
abs(e-(0.75*e+0.25*d))

i.e.

max(abs(e-b),abs(e-h),abs(e-d),abs(e-f))*0.25

and for half pixel motion it would be:

max(abs(e-b),abs(e-h),abs(e-d),abs(e-f))*0.5

That reasoning can then be extended to simultaneous motion in both vertical/horizontal directions.

[Didée]

First of all, generally: I don't claim that things should be done in exactly the way as they're done in MCBob; heaven forbid. In MCBob it's a rough compromise for speed's sake, because some things are just too inefficient when done by limited means of scripting.

What I want is to raise the general idea, because it seems quite feasable. If we have an idea of the local detail level - and that "idea" is rather easy to get by spatial evaluation -, then the allowed range for pixel variance can be derived from it. After thinking a little over it, making the thresholds dependend on the present local variance seems much more logical to me, compared to simply allow "this_fixed_value" for just everything ...


Specifically:

The neighborhood for determining the min/max for the motion threshold for 'c' would consist of which pixels?
...
I was thinking it would be the 3 x's above and below 'c', but want to make sure.
Hereby ensured. ;)


I've been looking at this a little more and I don't quite understand why the threshold is based on the range (max-min) of the neighborhood.

Using the maximum difference to the center pixel (like you suggested) theoretically is more precise. I used local min/max for two-andahalf reasons:

a) it was much faster. min/max I get with mt_lutxy(mt_inpand,mt_expand). for max-diff I'd need mt_lutxy(mt_lut_xy(clip,clip.mt_inpand),mt_lutxy(clip,clip.mt_expand)).

b) the center "doesn't exist" yet. The center is the pixel we want to construct.
Therefore: calculating the maximum difference of the neighborhood to the interpolated-from-the-neighborhood center value, in the end is the same as taking min/max of the neighborhood, and divide by 2.

c) the "double sized" value of min/max is levelled out trivially: if we want to allow 1/4 pel motion as being static, this means 1/4 pel between neighbored top/bottom fields. But the field motion check is done between same-parity fields, i.e. the doubled distance. So, to allow 1/4 pel between two directly neighbored fields, the motion check has to allow 1/2 pel between same-parity fields ... that's the point where the "bigger" result of min/max gets levelled out. (That's not fully exact science, sure ... but after trying, it seemed to suffice.)


Somehow, talking about it seems to make it more complicated than it really is ...

[tritical]

I made an initial implementation of an adaptive-threshold motion-mask that can be used with tdeint (mmask.dll (http://bengal.missouri.edu/~kes25c/mmask.dll)). Currently, it is just a bunch of separate filters: mthresh, mmask, mcombine, and buildMM, that can work with tdeint through the emask option. Be aware that this is straight c and completely unoptimized so it is rather slow. I've implemented it as a set of separate filters to make experimenting easier.

mthresh(clip child, int type) -

This filter takes in a field based clip and will output a threshold map, where the threshold for each pixel is based on it's 3x3 neighborhood. The output frames will be twice the size vertically of the input. The top half of the output is the 1/4 pel threshold and the bottom is the 1/2 pel threshold. 'type' can be 0, 1, 2, or 3 (default is 1). For type = 2, the thresholds are simply:

max(abs(cp-nmin),abs(cp-nmax))*0.25
max(abs(cp-nmin),abs(cp-nmax))*0.50

where cp is the current pixel value and nmin/nmax are the min/max of the current pixel's top/left/right/bottom neighbors. type=3 is the same as 2, but considers all 8 neighbors. type = 0 is the same as 2 but compensates for the 2x difference in distance between lines (due to it being only a field), as well as for the distance differences due to downsampling in chroma. type=1 is the same as 3, but with the compensation as in 0.


mmask(clip child, clip mask, int type, int nt, int minthresh, int maxthresh) -

This filter takes in the mask output by mthresh (the 'mask' clip should be set to this) and the field based video that was given as input to mthresh (each frame needs to be stacked vertically with itself) (the 'child' clip should be set to this). It will then output a mask indicating which pixels are moving (0) or static (255). A pixel is static if the difference between it and the pixel in the other frame is less than min(cthresh,othresh) where cthresh is the threshold determined by mthresh for the current pixel and othresh is the threshold determined by mthresh for the other pixel. type can be set to 0, 1, or 2 (default is 2). type=0 will do difference to previous frame, type=1 will do difference to previous/next, and type=2 will do difference to next. nt is the noise threshold (default 2)... nt will be added to min(cthresh,othresh). minthresh is the minimum threshold value (if min(cthresh,othresh) is less than minthresh then it will be increased to minthresh) (default is 0). maxthresh works the same way as minthresh but sets the maximum (default is 75).


mcombine(clip child, int cstr) -

This filter takes the output from mmask, which is still double size vertically and combines the 1/4 pel and 1/2 masks into one mask. Basically, if a pixel is marked as moving in the 1/4 pel mask but is marked as static in the 1/2 pel mask, then mcombine checks to see how many of that pixels neighbors in its 3x3 neighborhood are marked as static in the 1/4 pel mask. If at least 'cstr' of its neighbors are, than that pixel is considered static in the final mask (default for cstr is 4). All pixels marked as static in the 1/4 pel mask are also considered static in the final mask.


buildMM(clip tfields, clip bfields, int mode, int order, int field, int length, int type) -

This filter takes in two clips corresponding to top fields and bottom fields. These clips should be the output of running mthresh, mmask, and mcombine separately on the top and bottom fields of the video. buildMM assumes that type=2 was used when running mmask(). mode/order/field are exactly the same as the same parameters in tdeint and should match the settings you intend to use in tdeint (defaults are 0/-1/-1, -1 means the same as it does in tdeint). length specifies the static field period for weaving a pixel (to get a 5-field check as in tdeint use length=5, to get an 8 field check as in securedeint use length=8, etc...) (length must be >= 4 and <= 60, default is 8). 'type' specifies whether both neighboring vertical lines of the line attempting to be weaved have to agree on the direction (back, across, or forward) of the static period. If type=0 then they don't, if type = 1 then they do (default is 0). The output of buildMM is a mask usable by tdeint through its 'emask' parameter.


Here's an example of doing bobbing on a bff clip:

mpeg2source("C:\t4.d2v")
bot = separatefields().selecteven()
top = separatefields().selectodd()
topf = mmask(stackvertical(top,top),maskc=mthresh(top)).mcombine()
botf = mmask(stackvertical(bot,bot),maskc=mthresh(bot)).mcombine()
tdeint(order=0,mode=1,emask=buildMM(topf,botf,mode=1,order=0))

here's what it would be for tff:

mpeg2source("C:\t4.d2v")
top = separatefields().selecteven()
bot = separatefields().selectodd()
topf = mmask(stackvertical(top,top),maskc=mthresh(top)).mcombine()
botf = mmask(stackvertical(bot,bot),maskc=mthresh(bot)).mcombine()
tdeint(order=1,mode=1,emask=buildMM(topf,botf,mode=1,order=1))

and here's same rate deinterlacing on a tff clip (keeping top fields):

mpeg2source("C:\t4.d2v")
top = separatefields().selecteven()
bot = separatefields().selectodd()
topf = mmask(stackvertical(top,top),maskc=mthresh(top)).mcombine()
botf = mmask(stackvertical(bot,bot),maskc=mthresh(bot)).mcombine()
tdeint(order=1,field=1,mode=0,emask=buildMM(topf,botf,mode=0,order=1,field=1))


Any suggestions are welcome. I've been testing this on some difficult clips and it seems to work considerably better than tdeint by itself. Probably the part most up for change is mcombine(), as the method it uses to combine the 1/4 pel and 1/2 pel masks isn't exactly ideal.

mmask.dll also includes the following two filters:

dilate(clip child, int dstr)
erode(clip child, int estr)

dilate will mark any pixel that is 0 as 255 if >= 'dstr' of its 8 neighbors are not 0.

erode will mark any pixel that is not 0 as 0 if <= 'estr' of its 8 neighbors are not 0.

Those are there for possible processing of the intermediate masks.

EDIT: mthresh, mmask, mcombine, buildMM, dilate, and erode will all work with YV12 or YUY2.

[tritical]

Not sure if anyone else tested, but I found that there were still some artifacts on a couple sequences. Having mmask check differences both 1 frame forward and 2 frames forward and then anding those two masks fixed it though. Gonna post an updated version of mmask.dll later. Hopefully after a little more testing I'll start merging it all into one filter.


New version of mmask.dll (http://bengal.missouri.edu/~kes25c/mmask.dll). Changes from before:

mmask() -

The 'type' parameter can now be set to 0, 1, 2, 3, 4, or 5 (default is 3).

0 = diff to n-3
1 = diff to n-2
2 = diff to n-1
3 = diff to n+1
4 = diff to n+2
5 = diff to n+3

static vs moving is determined as explained previously. 'minthresh' now defaults to 5. This may result in a tiny amount of residual combing, but was needed to stop the background from wavering in the "scrolling text" test clip from http://media.xiph.org/vqeg/TestSeqences/Reference/.


andMasks(clip clip1, clip clip2, int dis) -

This filter will output an and'd mask of clip1 and clip2. clip1 should be generated with mmask(type=3) (i.e. single frame forward diff), clip2 should be generated with either mmask(type=4) or mmask(type=5) (two frame or three frame forward diff). dis should be set to 2 if you use type=4 or 3 if you use type=5 (default is 2). For the dis=2 case, the filter will grab frame 'n' from clip2 and and it with frames n and n+1 from clip1. If dis=3 then it will and frame 'n' of clip2 with frames n/n+1/n+2 of clip1.


buildMM() -

There is a new parameter called 'dis' (an integer) (default is 1), which if you use andMasks() to create the motion masks should be set to the same value as the 'dis' parameter of andMasks(). Basically, 'dis' tells buildMM how many frames forward a pixel is stationary if it is marked as 255 in the mask. Also, 'type' can now be set to 0, 1, or 2 (default is 1). 1 and 2 are the same as 0 and 1 were before. 0 is now a less restrictive version of 1... theoretically, 0 should weave the most but be the most artifact prone, 2 will weave the least but be the least artifact prone.

bobbing, tff, 1+2 frame diff:

top = separatefields().selecteven()
bot = separatefields().selectodd()
topm = mthresh(top)
botm = mthresh(bot)
tops = stackvertical(top,top)
bots = stackvertical(bot,bot)
topf1 = mmask(tops,topm,type=3)
botf1 = mmask(bots,botm,type=3)
topf2 = mmask(tops,topm,type=4)
botf2 = mmask(bots,botm,type=4)
topf = andmasks(topf1,topf2,dis=2).mcombine()
botf = andmasks(botf1,botf2,dis=2).mcombine()
tdeint(order=1,mode=1,emask=buildMM(topf,botf,mode=1,order=1,dis=2))

bobbing, bff, 1+2 frame diff:

bot = separatefields().selecteven()
top = separatefields().selectodd()
topm = mthresh(top)
botm = mthresh(bot)
tops = stackvertical(top,top)
bots = stackvertical(bot,bot)
topf1 = mmask(tops,topm,type=3)
botf1 = mmask(bots,botm,type=3)
topf2 = mmask(tops,topm,type=4)
botf2 = mmask(bots,botm,type=4)
topf = andmasks(topf1,topf2,dis=2).mcombine()
botf = andmasks(botf1,botf2,dis=2).mcombine()
tdeint(order=0,mode=1,emask=buildMM(topf,botf,mode=1,order=0,dis=2))

same rate, tff, keep top field, 1+2 frame diff:

top = separatefields().selecteven()
bot = separatefields().selectodd()
topm = mthresh(top)
botm = mthresh(bot)
tops = stackvertical(top,top)
bots = stackvertical(bot,bot)
topf1 = mmask(tops,topm,type=3)
botf1 = mmask(bots,botm,type=3)
topf2 = mmask(tops,topm,type=4)
botf2 = mmask(bots,botm,type=4)
topf = andmasks(topf1,topf2,dis=2).mcombine()
botf = andmasks(botf1,botf2,dis=2).mcombine()
tdeint(order=1,field=1,emask=buildMM(topf,botf,order=1,field=1,dis=2))

So far this has managed to get through every clip that tdeint, using its internal motion masking, produces motion related artifacts on.

Seems I spoke too soon. Defaulting to minthresh=5 in mmask() to fix the wavering on the scrolling text clip results in artifacts in another video. Those artifacts can be fixed by setting minthresh=2, but that causes problems for the scrolling text clip, or by setting length=10 in buildMM().

[Terranigma]

You and Didée makes this all seem like jibber-jabber. :p
I'll give the new mmask a try. Thanks for the .dll and thorough explaination. :D

[tritical]

I noticed two bugs in buildMM() that would cause it not to weave pixels when it should have. I updated mmask.dll (same link as above). I also changed the default for 'length' in buildMM() to 10. mmask() was also changed so that instead of requiring diff < min(cthresh,othresh) it's now diff <= min(cthresh,othresh) and the default for 'minthresh' was changed to 4 (was 5 previously).

[ChiDragon]

Cool, if I set length=12 with this mmask thing it fixes a short sequence that causes huge artifacting normally. I guess that's not really a test of the new thresholding though? I'm guessing if TDeint by itself could be set to 12-field check it would also be fine on these frames (but then I don't really understand most of this discussion).

[tritical]

I added a new filter to mmask.dll (http://bengal.missouri.edu/~kes25c/mmask.dll) called createMM(), which combines mthresh/mmask/andMasks/mcombine. Syntax:

createMM(clip, int type, int nt, int minthresh, int maxthresh, int cstr)

type is from mthresh
nt/minthresh/maxthresh are from mmask
cstr is from mcombine

dis is fixed at 2. The defaults are the same as for the separate filters.

Now things are a little simpler:

bobbing, tff:

topf = separatefields().selecteven().createMM()
botf = separatefields().selectodd().createMM()
tdeint(mode=1,order=1,emask=buildMM(topf,botf,mode=1,order=1,dis=2))

bobbing, bff:

botf = separatefields().selecteven().createMM()
topf = separatefields().selectodd().createMM()
tdeint(mode=1,order=0,emask=buildMM(topf,botf,mode=1,order=0,dis=2))

same rate, keep top field, tff:

topf = separatefields().selecteven().createMM()
botf = separatefields().selectodd().createMM()
tdeint(mode=0,order=1,field=1,emask=buildMM(topf,botf,mode=0,order=1,field=1,dis=2))


@ChiDragon
You're are probably correct. The longer the static period required the more resistant it will be to artifacts from repeated motion. I think a good example of the adaptive threshold in action is src20_ref__525.yuv from http://media.xiph.org/vqeg/TestSeqences/Reference/. TDeint requires mthreshL=13 to get the same level of stability as createMM()+buildMM(), and actually using mthreshL=13 on any material with motion will lead to lots of residual combing and artifacts which you wont get with createMM()+buildMM().

Would you be willing to upload the short sequence you mentioned earlier to my ftp?
12.216.251.99:17262
upload/upload

[ChiDragon]

I uploaded the clip. :)

[tritical]

@ChiDragon
Thanks :).

@All
I updated mmask.dll again, only changes were a few optimizations. Atm, using tdeint w/ createMM()+buildMM() is about 3x slower for me than using tdeint w/ its internal motion-masking. It can probably be sped up some more, but considering it's doing a 10 field check (by default) vs tdeint's 5 field check and is using per-pixel adaptive thresholding, 3x slower seems pretty reasonable.

[Adub]

Well, it looks like I might have to start checking this out.
Thanks alot for the new filter Tritical!

[tritical]

Updated mmask.dll again. Changes were all to mthresh(). 'type' now has options 4 and 5, which use 4 and 8 neighbors respectively, but use the range (max-min) of the neighborhood instead of diff to the center pixel. I also added four new parameters: mtqL, mthL, mtqC, mthC which can be used to set hard thresholds instead of using adaptive thresholds. mtqL sets the quarter pel threshold for luma, mthL sets the half pel threshold for luma, mtqC/mthC are the same but for chroma. If these parameters are set to -1 (the default) then an adaptive threshold is used, if they are between 0 and 255 inclusive then the value of the parameter is used as the threshold for every pixel.

The above changes to mthresh() were also included in createMM(), whose type parameter can be set to 4 or 5, and which now has mtqL, mthL, mtqC, and mthC parameters.

I'm planning to create one filter called tMM() that does everything internally so that deinterlacing would simply be:

tdeint(order=xx,mode=xx,field=xx,emask=tMM(order=xx,mode=xx,field=xx))

[tritical]

Didn't take long... TMM.zip (http://bengal.missouri.edu/~kes25c/TMMv1.zip). It includes a readme and source code. Basic usage examples:

bobbing, tff:

tdeint(mode=1,order=1,emask=TMM(mode=1,order=1))

bobbing, bff:

tdeint(mode=1,order=0,emask=TMM(mode=1,order=0))

same rate, keep top field, tff:

tdeint(order=1,field=1,emask=TMM(order=1,field=1))

same rate, keep bot field, bff:

tdeint(order=0,field=0,emask=TMM(order=0,field=0))

[Terranigma]

I'll try this out, thanks. Hey, any news on what we've discussed via pm? :D


Update:
Very nice work tritical. Would it be possible to use tmm with, lets say, bob() to make it adaptive? If so, how would I go about doing that?

By the way, you forgot to add another bracket at the end of the second example =P
tdeint(order=0,field=1,emask=TMM(order=0,field=1)

[tritical]

I've told about 5 people that I'd look into something for them and haven't gotten around to any of it due to working on this motion-mask thing. Anyways, I did download tprivtc earlier in the week to try and fix the problems you mentioned, but it turns out that it uses fstream.h functions for doing the file/text stuff so I couldn't get it to compile straight away with vs.net 2003 (which doesn't have fstream.h and switching to iostream+fstream didn't fix everything) so I put it away for later. I'll probably mess with it tommorrow.

Very nice work tritical. Would it be possible to use tmm with, lets say, bob() to make it adaptive? If so, how would I go about doing that? Not sure in what fashion you mean, but the main problem with using it in conjunction with bob() via some type of masking would be that bob shifts both fields. If you just want cubic interpolation with motion-adaptation then TMM w/ tdeint(mode=1,type=0) would work.

thanks for the heads up on the typo in the read me.

[Terranigma]

Not sure in what fashion you mean, but the main problem with using it in conjunction with bob() via some type of masking would be that bob shifts both fields. If you just want cubic interpolation with motion-adaptation then TMM w/ tdeint(mode=1,type=0) would work.

That's what I meant. I'll try your suggestion there instead. :thanks:

[Chainmax]

@ChiDragon
Thanks :).

@All
I updated mmask.dll again, only changes were a few optimizations. Atm, using tdeint w/ createMM()+buildMM() is about 3x slower for me than using tdeint w/ its internal motion-masking. It can probably be sped up some more, but considering it's doing a 10 field check (by default) vs tdeint's 5 field check and is using per-pixel adaptive thresholding, 3x slower seems pretty reasonable.

Only three times slower? That's still ~20% faster than SecureBob/Old TDeint+EEDI2, ~220% faster than MVBob and ~310% faster than MCBob! :eek: tritical, you're a genius :) http://smilies.vidahost.com/otn/wink/thumb.gif.

[foxyshadis]

You might still want to use eedi2 with tdeint's edeint parameter though, which will slow it down a bit more. Using emask+edeint, there's hardly any reason to keep tdeint around though. :p

[Chainmax]

Well, like I said, this is still ~20% faster than Old TDeint+EEDI2. Besides, someone here said that using EEDI2 with the edeint parameter yielded a softer picture than plain TDeint. Not to mention that EEDI2 has artifacts of its own.

[canuckerfan]

so are we better off leaving out EEDI2 or is it best left to our discretion?

[Chainmax]

I never noticed the differences myself, but then again I never conducted a test either. Theoretically speaking, using EEDI2 might have some benefits in specific situations so I'd advise you to conduct a few tests with a variety of sources (at least 1 real life clip and one animation clip) and see if you can spot a difference.

[tritical]

You just have to try it and see which you prefer, as every interpolation method (edge-directed or not) has it own good points and bad points. If you want to look at individual frames than eedi2 will usually look better (especially if there are high contrast diagonal lines/edges), but it also has worse compression (usually) and worse temporal stability (not really the correct term, but not sure what to call it). Also, since interpolation will mainly be used in moving areas, which people are less sensitive to during normal speed playback, the benefits of edi may not be that great. kernel interpolation will also tend to look better in areas falsely detected as moving or in very slow moving areas.

The other thing you have to consider, if you are encoding the result and have size requirements, is the compressibility of the output. A deinterlacer that looks great but whose output is much harder to compress will have to suffer more distortion to reach the same file size as the output of a deinterlacer that is more compressible.

I did some tests using two sources, the first combined srcs 3/6/8/9/10 from http://media.xiph.org/vqeg/TestSeqences/Reference/, and the second was just src 20 (from the same place) by itself. I bobbed both clips with a number of deinterlacers, and then encoded the result with xvid at constant quant 2 using my usual settings (motion 6, vhq 4, chroma motion, bframes: 1/1.5/0.75, no qpel or gmc, h.263). The results were:

deinterlacer - Size (KB) Time (Min:Sec)

source 1:
bob - 124,449 8:02
securebob(type=2) - 133,936 8:46
tdeint+tmm - 136,485 11:39
tdeint - 139,728 9:24
tdeint+tmm+eedi2 - 142,171 32:00
securebob(type=3) - 144,748 30:08
tdeint+eedi2 - 146,589 30:21
leakkernelbob - 148,618 8:21
tomsmocomp(x,5,0) - 162,642 7:59
yadif(mode=1) - 162,672 8:35
yadif(mode=3) - 164,219 8:34
dgbob - 185,154 9:13

source2:
tdeint+tmm - 8,975 1:53
tdeint+tmm+eedi2 - 9,386 6:40
yadif(mode=3) - 11,812 1:19
yadif(mode=1) - 13,271 1:20
securebob(type=2) - 13,746 1:22
securebob(type=3) - 14,579 6:10
leakkernelbob - 16,663 1:15
tdeint - 17,253 1:24
dgbob - 18,616 1:17
tomsmocomp(x,5,0) - 20,437 1:19
bob - 21,637 1:23
tdeint+eedi2 - 21,875 6:11

The first source was pretty much all motion (except for the scrolling text sequence which is stationary apart from the text, which takes up probably 1/4 of the frame). The second source is almost completely stationary, but does have some noise (TDeint would require mthreshL of about 14 to handle it well). I did the tests on my laptop which has a 1.6 Ghz Pentium M and 1 GB of PC2700.

[canuckerfan]

Thanks for those figures, tritical. Makes things easier around here. Looking forward to improvements to tMM:)

[ChiDragon]

tritical, Fizick's Yadif plugin doesn't create artifacts on that clip I sent you when the "spatial interlacing check" is enabled. Do you know if this is just the equivalent of enabling "AP" in TDeint, or something else?

[tritical]

Roughly speaking, it is. The thing about yadif is it works sort of in the opposite direction than tdeint. It starts with a spatial prediction (interpolated value) and then limits that value to be within p2 + diff and p2 - diff, where p2 is the temporal prediction (weaved value) and diff is (again roughly speaking) a measure of local temporal change or complexity (for mode = 0/1). If there are no temporal changes then you end up with p2, the more temporal change there is the more likely it is you will just get the spatial prediction value back out. Using only the temporal differences to generate the 'diff' value makes yadif as susceptible to motion-adaptive artifacts on repeated patterns as any other motion-adaptive deinterlacer with a 5-field check. On the other hand, it is less susceptible to residual combing because in such cases, the diff value will exceed the difference between the spatial prediction and the weaved value (which in the case of soft residual combing, such as on a fadeout, is usually < 4) and you'll just get the spatial prediction value (or close to it).

When you switch to mode 2/3 diff is also based on local, vertical spatial complexity between the current field and the temporal predictions of the current line and the above/below lines in the opposite parity field. Basically, that means diff will also be based on how large of a vertical gradient weaving will create (that is maxed with the temporal diff calculation). Therefore, areas that would experience the types of artifacts you get from incorrect weaving will have a large diff value and you'll get the spatial prediction value. The downside is that true static areas with lots of detail (specifically those with large vertical gradients) will no longer be weaved. This is pretty much exactly what 'AP' in tdeint accomplishes.

EDIT:

I actually find the idea behind yadif quite interesting, but the major drawback IMO is the edi method it is uses is overly prone to artifacts. It uses the typical two sliding window method which is highly likely to choose the wrong direction around anything more than a single, thick, lone edge. Every other filter/program that I know of that uses this method caps the output value to be within +-2 or 3 of the min/max of the vertical neighbors to prevent major artifacts. Just to see what would happen, I created a c only version with such capping and to me it looked much better. I also made it possible to take spatial predictions from an external clip. I have some results here: deinterlace_comparison.txt (http://bengal.missouri.edu/~kes25c/deinterlace_comparison.txt) from a comparison I am working on, which I think show the benefits.

I have also been thinking of testing out a filter that would take tdeint's output, along with it's motion-map, and then limit only the interpolated values using the same method as yadif, and I am still working on a new interpolation method that should give edi benefits without taking hits in psnr/ssim as most edi methods do now. Although, that project has been on going for almost 9 months now so it could still be a while.

[AVIL]

Hi:

I've tested Tdeint and Yadif in a very noisy video. Yadif have less jagged edged but more orphan pixel type artefacts. I prefer Tdeint results.

To eliminate all the residual combing (my main problem with tdeint) i've setted mtqL, mthL, mtqC and mthC to zero.

IMHO the sole thing it rests is fight against the aliased edged. But, anyway , I am very pleased whith the last addition.

Thanks.

[swaaye]

Does TIVTC use SSE2 on Core 2 CPUs? I ask because it says P4 only in the changelogs.

[Boulder]

It uses SSE2 instructions if your CPU supports them. So the answer to your question is : yes.

[tritical]

I changed it a little while ago, must have not added it to the changelog. It requires either:

1.) family code = 0xF
2.) family code = 0x6 and model number = 0xF or 0xE

So pretty much the only models excluded are pentium M/celeron M. I have those use iSSE/MMX as testing with my laptop (pentium M) showed it was slightly faster. Of course, you can force tivtc to use sse2 via the 'opt' parameters of tfm/tdecimate.

[ChiDragon]

tritical, could you please add TFM hints to TDeint with tryweave=true? I think it would make it a lot more clear what TDeint(mode=1,tryweave=true) is doing when followed by TDecimate(display=true) for videos with weird orphan field pulldown patterns.

EDIT: Actually, I guess what I'd really like is an output file that could be read with TDecimate's tfmIn option, since these patterns are part of large cycles.

[Asrial]

Tritical, did you get my e-mail about the problem I encountered with video sections being decimated in the later versions?

[swaaye]

I have a source that is identified by DGIndex as 100% video, but it still reacts favorably to an IVTC. This is a USA TV show and I did a frame by frame analysis manually to check the frame order and it is definitely telecined.

[ChiDragon]

swaaye... no offense, but what is your point? DGIndex's report about 100% video is just based on the lack of pulldown flags (i.e. it's ENCODED as video rather than film, not that the source itself wasn't telecined from film).

[swaaye]

Didn't know if you knew of that possibility.

[canuckerfan]

tritical, how's tMM development coming along? I'm looking forward to the speed improvements :)

[tritical]

@ChiDragon
I can do that.

@Asrial
I did, but I haven't gotten to it yet. I will though.

@swaaye
That scenerio is pretty much the norm in R1 anime. Though pretty rare as far as most movies goes.

@canuckerfan
It hasn't gone anywhere so far. I'm busy with work and school again. However, there really isn't a whole lot of optimization that can be done aside from making it multi-threaded and better internal caching.

[ChiDragon]

For now at least I've found that this seems to do the same job as TDeint(mode=1,tryweave=true) except that it gives hints:

Interleave(TFM(mode=0,slow=2,micmatching=0,PP=7),SeparateFields().Trim(1,0).Weave().TFM(mode=0,slow=2,micmatching=0,PP=7))

AVSTimer even shows it running at the same speed. Of course there's no way to get a useable output file for tfmIn from that so a real option would be preferable. :p

EDIT: Hmm... I'm attempting to use the above code with TDecimate(cycleR=2,cycle=4) before another TDecimate call so that I can use smaller cycles and sdlim with the second one. The first one detects and uses hints while the second doesn't (forcing hint=true doesn't help either). Shouldn't the first one be preserving the hints? I'm using v1.0.1.

EDIT 2: Darn, TDecimate(cycleR=2,cycle=4) doesn't quite work right for this anyway. It drops an extra frame for a cycle like this:

Z | A B | C
Z | A C | C

(frames on x, fields on y)

[Myrsloik]

Version 1.0.1 of TIVTC (no idea about earlier) seems to have a bug when TFM's d2v argument is used with mpeg2dec3 and dvd2avi 1.77.3.

Whenever I try to use it it says:

TFM: d2v frame count does not match filter frame count (1968 vs 1966)!

or similar where the difference in the number of frames always seems to be 2 in all tested files. If I use dgmpgdec 1.4.9b17 it works properly with all files.

[foxyshadis]

mpeg2dec3 and dvd2avi 1.77.3.
Why would you do such a thing to yourself.

[tritical]

@ChiDragon
TDecimate currently destroys tfm hints on output (it preserves dgdecode hints, i.e. colorimetry). The hints from tfm don't really make sense after tdecimate has removed frames. What hint information would still be relevant?

@Myrsloik
The 2 frame difference is due to the following reasons (taken from neuron2's dgmpgdec page):

2.) MPEG2DEC cuts two frames from the frame count as a workaround for 3 below. This is a kludgy hack that should not be necessary. Thus, thanks to this and 1 above, 3 frames will always be lost. They are lost at the end.

3.) If the opening GOP has B frames before the first P frame (IBBPBBP...), then DVD2AVI generates an incorrect D2V file, in which the first digits for the orphaned B frames and some remaining digits are written out of place. Also, MPEG2DEC cannot decode the B frames prior to the first P frame, and so discards them. A number of frames will be lost equal to the number of B frames prior to the first P frame. They are lost at the beginning.

So, for example, if you process a VOB that has an IBBPBBP... opening GOP, you will lose a total of 5 frames, with 2 lost at the start and 3 lost at the end.

In addition to the lost frames, MPEG2DEC does not implement random frame access correctly. In fact, it always throws away the first B frames in the GOP prior to the first P frame. If they are (say) frames 12 and 13 (in display order) and you try to seek to 12, MPEG2DEC will toss them and return frame 14 to you, without any warning or indication about it.

Finally, when 3 above applies the TFF/RFF flags in the D2V file are misaligned to the frames.

Specifically, the part about mpeg2dec3 subtracting 2 from the d2v frame count as a workaround for 3. You might be able to work around this using tfm's trimIn() option, but I wouldn't trust anything other than flags=3 (which doesn't require matching frame counts) with d2v files generated by 1.77.3. Especially due to the tff/rff flag to frame misalignment problem. I'm with foxyshadis, why use dvd2avi 1.77.3+mpeg2dec3?

[ChiDragon]

Well I use TDecimate's display mode with TFM's hints to see what both filters are doing, but I guess I understand if keeping them in would interfere with the second decimation.