TDeint and TIVTC

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