TDeint and TIVTC

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