TDeint and TIVTC

[manolito]

Thanks a lot for the tip, I will give it a thorough test run tonight...

Cheers
manolito

[manolito]

Alright, here's what I've come up with:

First of all, setting up QTGMC really was a little difficult, because my CPU (P3 Coppermine) does not support SSE2. Some of the plugins Vit provides are SSE2 plugins, and of course I got a floating point error. So I had to replace the SSE2 plugins with different versions while still trying to not brake LSFMod or LimitedSharpenFaster. Took me some time, but it works now.

Now for the speed tests:

I took an interlaced TFF DVD source, no filters except the deinterlacer, feeding it to QuEnc. These are the speeds for the different deinterlacers:

TomsMoComp:                                    11.77 fps
Yadif:                                         11.02 fps
YadifMod(edeint=tdeint(mthreshL=0,mthreshC=0)): 6.34 fps
QTGMC very fast:                               less than 1 fps
QTGMC draft:                                    4.65 fps

QTGMC is only usable with Preset="Draft" on my machine, and I do have my doubts if the resulting quality can match the quality of "yadifmod(edeint=tdeint(mthreshL=0,mthreshC=0))". I don't have the knowledge to analyze the QTGMC script enough to understand what the "Draft" preset really does, but it seems to use Yadif with Yadif's own spatial prediction, and I have the feeling that YadifMod using TDeint's prediction might do a better job....


Cheers
manolito

[-Vit-]

"Draft" is an extremely cut-down version of the core TGMC algorithm. It doesn't use Yadif, it performs a motion-compensated temporal binomial smooth to remove shimmer, but it only uses a bob as an interpolate, does not mask against creating blur and does no resharpening. As it's name implies it's not intended for final usage. QTGMC only really becomes useful at "Super Fast" and above IMO.

No offense intended, but you can't really ask for the "state of the art" if you intend to use a Pentium 3.

[OvejaNegra]

Hi: I'm trying to create a tool for simplify the process of creating VFR with 59.97, 29.97 and 23.97 fps using the metrics output of tivtc.
Can anyone explain to me what the metrics of TDecimate means:
0 0 0
1 1824 470069
2 1296 322363
3 1328 316633
4 1563 299634
5 2136 447795
6 2617 397772
7 3621 471805
8 3872 508060
9 5221 487823
10 5963 546645

Also, what the h matching means on TFM metrics?

And one more question:

(sorry the quote button does not works on my explorer, probably the antivirus is blocking scripts on the page):

This is from tritical:
"It might actually be easier to create a separate filter/program to do it based off tfm stat file and tdecimate stat files from tfm output and bobbed output."

"tfm output and bobbed output" mmmm why? and how can i give two outputs to tdecimate (or is actually about apply bob to the tfm output and give it to tdecimate? that is a mess i think? can anyone elaborate a little more please.

english is not my language, maybe i'm not undertanding properly.
thanks

[cretindesalpes]

Originally Posted by OvejaNegra

Can anyone explain to me what the metrics of TDecimate means

"Each line will include a frame number, plus the difference metric, and the scene change metric." IIRC the metrics are not scaled, they are more or less proportional to the picture area (they are sums of absolute differences or something related).

Originally Posted by OvejaNegra

Also, what the h matching means on TFM metrics?

From the TDecimate source code:

#define ISDB 0x00000005 // l = (deinterlaced c bottom field)
#define ISDT 0x00000006 // h = (deinterlaced c top field)

[OvejaNegra]

And how TDecimate goes from something like:
1 1824 470069

To calculate the video threshold or dup threshold (wich is something like 1.1 , 2.8, etc).

I just want to parse a tdm metrics file to get the video and film sections by myself. tfm metrics are clear to me but not the tdm.

Another question please:
why tfm has out of order matching modes like:
5 = 3-way match + 4th/5th matches on combed (p/c/n + u/b)

because hard telecine sources have field order changes because bad edits or cuts?
but such changes wont produce jumpy movement when displaying on tv set?
or to reformulate my question: Why mode 0 is not enough?

And another one:

Why tdm detects 17 fps ranges? (i'm talking about mode 5 with timecodes output).
Thanks.

[j7n]

I just got a recurring error in Avisynth v2.5.8 and TIVTC 1.0.5:

TDecimate: mode 2 internal error (ret less than 0). Please report this to tritical ASAP!

I was trying to trim and further process the output of TDecimate(mode=2,rate=25.0,maxndl=30,m2PA=true,chroma=false). The error occurred after the end of the decimated clip.

Whops. I was trying to request more frames than there actually were after decimation. Scaling back the trim range by a few frames did away with the error.

I could reproduce the same message just by having a script with two lines and playing it from start to finish. The source was progressive with dupe frames, running at 29.97 fps.

[SubJunk]

I'm trying to get rid of some residual combing. Here's the result after just doing TFM + TDedimate:

http://i.imgur.com/evbdoDn.png

I tried default settings and mode=1 but no change, the only thing that fixed it was cthresh=-1.
Other than taking longer to process, are there any problems with using cthresh=-1? Could it reduce quality? Any suggestions?

[DeathAngelBR]

I used to use 2-pass encodes with retarded awful sources. Something like this:

# 1st pass
tfm(d2v=_d2v,order=-1,slow=2,mode=4,pp=1,cthresh=5,mi=20,blockx=128,blocky=128,output="tfm.txt")
tdeint(slow=2,mi=20,cthresh=5,blockx=128,blocky=128)
tdecimate(hybrid=2,mode=4,expp=true,output="decimate.txt")

# 2nd pass
tfm(d2v=_d2v,order=-1,slow=2,mode=4,pp=1,cthresh=5,mi=20,blockx=128,blocky=128,input="tfm.txt",ovr="over.txt")
tdeint(slow=2,mi=20,cthresh=5,blockx=128,blocky=128)
tdecimate(hybrid=2,mode=5,expp=true,input="decimate.txt",mkvout="mkv.txt")

[OvejaNegra]

Usually, using cthresh=1 is enough for me to detect all the residual combing (on anime sources).
Using cthresh=-1 sets all teh frames as interlaced and applys deinterlacing on all the frames.

SubJunk: ARE YOU USING COLOR MATRIX?
If you are usign it, please set the interlaced parameter to true, because if dont, it creates those artifacts if the source is interlaced.

Try this:

#this is a deinterlacer that gives very good results, even on false positive detection
interp = full.separatefields().eedi2(field=-2)
deint = full.tdeint(mode=2,edeint=interp)
TFM(display=false,micout=0,mode=6,pp=2,slow=2,mChroma=true,chroma=false,cthresh=1,micmatching=0,clip2=deint)

#set chroma=false is your source has many chroma problems like rainbow or dot crawl

Good luck

[SubJunk]

Thanks guys Neither of them worked though. Anyway the rest of the clip is fine with the regular defaults, it's just that one part which only lasts for less than a second so it will be OK. Thanks anyway!

[osgZach]

If you set cthres=-1 then it treats all frames (pixels really) as combed and would be deinterlacing every frame in the clip. This can certainly lead to quality loss if you are throwing out good data.

The proper thing to do is to use an overrides file and specify the frame numbers (or frame range) in question for deinterlacing.

[sikboy1029]

Hey guys, you mind helping my out on the script for this one? The interlacing is pretty significant & I can't get rid of it.

http://www.mediafire.com/?u2buiev9awsgsdt

[LigH]

One of your mistakes was uploading not the original video, but the result of a failed filtering; yet, a frame-by-frame forward stepping still reveals a 3-2 pattern; and it has NTSC framerate. Therefore I would expect it being telecined (3:2 pulldown). In this case, "Deinterlacing" is wrong, "Inverse Telecine" (IVTC) is right.

[sikboy1029]

It's actually a cap of a netfix stream, been noticing the same issue with a lot of the animation they have on the service & it was bugging me. You would think they would have some sort of QA...it is visible with the naked eye watching it on TV & very distracting...I did try this

Telecide(guide=1)
Decimate(cycle=5)

Any recommended change?

[johnmeyer]

I have found that captures from Netflix often contain dropped frames, so you may need to deal with that. What surprises me is that the original was sent as 29.97 rather than 24 or 23.976. Did you force your capture card to capture 29.97? If the original was normal NTSC film rate (23.976), I have always found that this is what Netflix sends. Therefore, perhaps you have the wrong capture settings.

[sikboy1029]

I also capped in 23.976 & it looks the same, when you say I need to deal with the dropped frames what do you mean?

[johnmeyer]

Originally Posted by sikboy1029

I also capped in 23.976 & it looks the same, when you say I need to deal with the dropped frames what do you mean?

I said you may need to deal with dropped frames. I have observed dropped frames in video I have captured from the analog port on my XBox. They do not occur at a regular interval, and probably depend on many things, including my local connection speed as well as issues at the Netflix server. Some services, like Hulu, can be even worse.

I don't know what more clarification I can provide as to what I mean: a dropped frame usually results in a discontinuity in the video (a "jump") and is usually followed by a duplicate frame in order to keep the sound from drifting out of sync.

Netflix may also be using variable frame rate encoders that respond to connection speed changes, in which case I don't know what to recommend.

[Lenchik]

Can anyone create build of TFM and TDecimate (or whole TIVTC package) that supports YV24, please? Or maybe there is one already?

[turbojet]

Currently there doesn't seem to be any way to multithread tdecimate. Would anyone have interest in trying to implement it? Tritical has said in the past that openmp might work.

Also some combed frames slip through with tfm default mode=1, while they don't with mode=3 with no noticeable drop in speed. Any consideration on changing the default mode?