Log in

View Full Version : TDecimate failure, but only on long clips


johnmeyer
12th May 2016, 20:06
I captured a sports film from a laserdisc. It has standard 3:2 pulldown. However, when I use:

tfm()
tdecimate()

to remove that pulldown, TDecimate drops frames. I have looked at the original telecined video, field-by-field, and there is no interruption of the 3:2 pattern, and the fields look clean.

But here's the important part of the story ...

I created a test clip to upload with this post by doing a "smart render" (i.e., no re-render) of the DV video, taking about ten seconds on either side of one of the places where the IVTC failes.

However ...

The IVTC works OK on this test clip!

Here's the test clip, just to show you what I'm dealing with:

Test Clip (https://www.mediafire.com/?zhce5ms9s0o3u2x)

As I said, the IVTC works fine on this short clip. It is only when I do the entire 30 minute video that TDecimate fails.

To show you where the problem happens in the full video, when I IVTC the entire clip, one frame that is dropped is the same as frame 60 in this test clip.

So, if TDecimate's default Cycle is only 5 frames, why would feeding it a much longer clip cause a problem? I tried putting Requestlinear both before and after the TFM/TDecimate calls, but that made no difference (I understand what the documentation says about Requestlinear, but I don't fully understand when to use it).

So, does anyone have any suggestions on what TFM or TDecimate settings to change in order to get this to work? I have tried using Cycle=10 and CycleR=2, and that at first appeared to help, but all it does is move the dropped frame problem to a different frame. It does not cure the problem. I have experimented with different modes in both TFM and TDecimate. I've used TIVTC at least a hundred times, and never had a problem like this.

My version of TIVTC is v1.0.5.

Thanks. [edit] See next two posts for additional information. [/end edit]

Oh yes, here's the entire script:

loadPlugin("c:\Program Files\AviSynth 2.5\plugins\TIVTC.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")

AVISource("E:\fs.avi").KillAudio().converttoYV12(interlaced=true).AssumeBFF()

tfm()
tdecimate()
source=AssumeFPS(23.976, false)

output=MDegrain2P(source,4,2,0)

return output


#-------------------
function MDegrain2P(clip source, int "blksize", int "overlap", int "dct")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker

super = source.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 1, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 1, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
MDegrain2(source,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=200)
}

johnmeyer
12th May 2016, 20:29
I turned on debug for TDecimate. I've copied a small snippet from that dump. "useframe = 4703" is roughly where the frame was dropped that shouldn't have been. This is the same frame as I described in my initial post (it is where the runner's helmet with the cardinal logo disappears behind defensive player #74).

[2644] TDecimate: 4695: 30.01 30.33 34.47 32.50 2.75
[2644] TDecimate: 4695: p c c c l
[2644] TDecimate: 3756: Dropping Frame: 4699
[3472] video - 4706
[2644] TDecimate: inframe = 3756 useframe = 4695
[3472] video - 4707
[2644] TDecimate: inframe = 3757 useframe = 4696
[3472] video - 4708
[2644] TDecimate: inframe = 3758 useframe = 4697
[3472] video - 4709
[2644] TDecimate: inframe = 3759 useframe = 4698
[3472] video - 4710
[2644] TDecimate: 4700: 35.07 40.38 34.48 35.07 38.49
[2644] TDecimate: 4700: p c c c u
[2644] TDecimate: 3760: Dropping Frame: 4702
[3472] video - 4711
[2644] TDecimate: inframe = 3760 useframe = 4700
[3472] video - 4712
[2644] TDecimate: inframe = 3761 useframe = 4701
[3472] video - 4713
[2644] TDecimate: inframe = 3762 useframe = 4703
[3472] video - 4714
[2644] TDecimate: inframe = 3763 useframe = 4704
[3472] video - 4715
[3472] video - 4716
[2644] TDecimate: 4705: 0.00 38.32 38.94 39.95 1.68
[2644] TDecimate: 4705: p (mdup) c c c p (mdup)
[2644] TDecimate: 3764: Dropping Frame: 4705
[3472] video - 4717
[2644] TDecimate: inframe = 3764 useframe = 4706

johnmeyer
12th May 2016, 20:41
I may have come up with a workaround/fix, but this doesn't make sense. The video is NTSC DV, which is bottom field first. As you can see from the script I added what is probably an unnecessary AssumeBFF(). (I removed it, and it doesn't make any difference, as I would expect.)

However, if I change:

tfm()

to

tfm(order=1)

which tells TFM to treat the clip as TFF. This seems to fix the problem.

I ran into this many years ago, and had forgotten about it until now. Is it a bug, and if so why did it surface on this very straightforward telecined source?? And, why does the problem only show up with I feed the script the 30-minute video, but when I feed it a 20-second clip that is exactly identical to the original, it correctly decimates??

Motenai Yoda
12th May 2016, 22:25
take the source

put assumeTFF() and separatefields()
if the frames don't do forward-back-forward it's tff

maybe even converttoyv12(interlaced=true) is useless, if avisource returns an yet yv12 clip, if is in yuy2 or rgb, yuy2 will be better.

johnmeyer
13th May 2016, 00:08
put assumeTFF() and separatefields()
if the frames don't do forward-back-forward it's tffThanks! Good suggestion. It is the first thing I do with every clip I work on because I've been burned too many times by having the wrong field order. However, the problem with telecined material is that you don't get that backwards/forwards dance the way you do with 29.97 (or 25) fps interlaced video that has the wrong field order specified.

Also, with video (as opposed to telecined film), if you get it wrong, the results are completely hosed (technical term) and you can't miss it. By contrast, this was pretty subtle, and I actually watched most of the thirty minute film before I sent it to the client, and missed the few places where there were dropped frames. I guess part of the problem is that I'm getting too used to watching streaming video, and dropped frames are just a way of life when watching YouTube via Flash (fortunately YouTube and Amazon streaming are perfect when viewed on my son's old XBox).

I'm just finishing the revised project and will ship it off to the client tomorrow, but I'd still like to know if there is something else going on here. I don't want to repeat this mistake again.

johnmeyer
13th May 2016, 00:36
Darn!!

The problem is still there. I'm getting duplicated frames in some places and drops elsewhere.

In trying to troubleshoot this problem, I walk through the original telecined (29.97) video, and go to places where the IVTC fails. I see absolutely no interruption in the 3:2 pulldown cadence.

So, changing the order parameter didn't work, and merely moved the problem to another location.

I'm still stumped.

johnmeyer
13th May 2016, 00:56
OK, this looks more promising, and makes more sense than what I posted above.

TFM has a cthresh parameter that controls comb detection. There is no combing in this telecined film, but it looks like comb detection kicks in some places, causing the matching to fail. I just did some tests with cthresh=255 (i.e., comb detection turned off). All the problem areas I've detected so far look OK.

I'm going to created the IVTC film version, and then run that through a script I use to detect near duplicates. If there are drops, there also have to be duplicates, so I think this will help me find any problem areas. I should have run this detection script in the first place.

I'll report back.

johnmeyer
13th May 2016, 04:55
Sorry that this ended up as a soliloquy, but I did end up finding the problem: cthresh. Setting that to 255 fixed everything. I put this in my lab notes, but then discovered that I found this same thing about five years ago. I feel pretty dumb for not remembering to check those notes ...

ChiDragon
13th May 2016, 05:14
So the problem is actually with TFM and not TDecimate?

johnmeyer
13th May 2016, 05:56
So the problem is actually with TFM and not TDecimate?Yes.

I tried TDecimate alone, without TFM and the "hints" it passes along to TDecimate, but that didn't work.

TFM, with just the defaults, uses a relatively low cthresh. I understand that many people deal with telecine that has combed frames, but in my work, I almost never see this. Thus, when dealing with clean 3:2 pulldown, I think cthresh needs to be set to 255.

Sharc
13th May 2016, 07:32
You may want to try
telecide().tdecimate()

Same problem with this combo?

Motenai Yoda
13th May 2016, 12:28
the order shoul be effective even if telecined as the fields should are in sequence, unless there is some bad change of pattern.

IIRC tdecimate don't read the hints from tfm, but compare each frame with the prev in the same cicle and drop the one with less difference, maybe you should try differents settings of tdecimate

the combed threshold is about the interlaced decection of post processing, putting it to 255 can relax tfm too much, imho better to set pp=0.

johnmeyer
13th May 2016, 17:24
I think cthresh is used for more than the pp setting, at least that has been my experience. I've used TFM/TDecimate for some "off label" situations, such as recovering film frames from a 24 fps shutterless projector captured with a 60i NTSC camcorder. I have to drop the field where the film is blurred from pulldown and then recombine surrounding fields into stable frames. This requires using almost every setting in TFM to get the desired result, and I learned quite a bit about what the combing detection and the post-processing (the "pp" variable) does.

In the end, setting cthresh to 255 was the key, and I went back to all my TFM/TDecimate scripts yesterday and added a comment next to the TFM line that suggests setting this to 255.