IVTC issues: bad frames are being chosen

[Chainmax]

I am currently trying to make a watchable rip of my 1992 X-Men DVDs. For some reason, on certain spots peppered throughout the intro (which I chose as a sample), a pretty messed-up frame is chosen instead of a considerably cleaner version of it. The IVTCing portion of the script is this one:

AssumeTFF()
Interp = nnedi(field=1)
Deinted=TDeint(order=1,field=1,type=1,edeint=Interp,emask=TMM(order=1,field=1))
TFM(d2v="X:\wherever\Sanctuary1.d2v",mode=6,order=1,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

You can download a sample with the intro here:
http://rapidshare.com/files/92404386/Intro.demuxed.m2v.html

[Chainmax]

Anyone?

[Zarxrax]

This is very unusual. When I try to index the file with dgindex, it appears that dgindex is having some difficulties with it--outputing bad d2v file, crashing, etc.

[45tripp]

Yeah, I confirm.

I (eventually) managed to get it working, sectioning out the end of the file in dgindex before indexing.

that aside, it's a horrendous source.

[scharfis_brain]

knock out all order - parameters.

[Chainmax]

Zarxrax, Immersion: indeed, that happened to tritical and I as well. The m2v loads fine by itself in VDubMod, so maybe it can be picked up by DirectShowSource.

As for the quality of the source, you can thank FOX for the importance they give to consumers when creating these DVDs :mad:.

scharfis_brain: the source is TFF, how would deleting all order switches do any good?

[scharfis_brain]

scharfis_brain: the source is TFF, how would deleting all order switches do any good?
Triticals filters can read the parity automatically.
Since you already set it via AssumeTFF(), the the 'field' & 'order' - parmeters are obsolete.

RTM!

AssumeTFF()
Interp = nnedi()
Deinted=TDeint(edeint=Interp,emask=TMM())
TFM(d2v="X:\wherever\Sanctuary1.d2v",mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

EDIT: If you use mpeg2source() then even AssumeTFF() is obsolete.

[Chainmax]

It hasn't made any difference.

[Guest]

I (eventually) managed to get it working, sectioning out the end of the file in dgindex before indexing. It was caused by a bad cut at the end. Just as DGIndex was trying to read extra_information_picture, the file ended, and the loop was tight. It's fixed in my private build and will be fixed in the next release.

One day I may implement a timeout kill on the decoder thread. :p

[Chainmax]

Should I try cutting at a different point or will that not make a difference?

[Guest]

If you cut the end differently, it will likely be OK. This will be fixed in the next release.

[scharfis_brain]

@Chainmax: the source has suffered too much by the compression in order to be automatically decimatable.

I only had success with this manual method:

mpeg2source("C:\forum\chainmax\Intro.demuxed.d2v",cpu=6)
Interp = nnedi(field=-2)
TDeint(mode=1,edeint=Interp,emask=TMM(mode=1))
selectevery(10,2,4,6,9)

you will need to change the offset for every scen which shows the horrible blocking artifact again.

the offst I gave you here is valid for about the first half of this intro.

[Chainmax]

And do that for each of the 10+ episodes?

:eek:

...I'm speechless. Speechless and sad :(. And more than a little angry too :mad:.



[edit] Could you please explain why does this DVD's bad compression make a decimator screw up its decision so badly?

[scharfis_brain]

film is usually telecined via an 3:2 pattern.

this makes 4 Frames A B C D
become 10 Fields: a A a B b C c C d D
but due to this bad kind of compression the weird blockyness looks more like a new frame to the decimator than the REAL new frame.

in your case this is the case for 10 fields:
(bad fields marked with an *)
a*A*a B b C c C d D

so the telecined frame a*A* looks like an individual frame to the fieldmatchers as well as it does to the decimator.
that's why it chooses this frame.

it's up to you: either live with the bad frames being selected or go for manual pulldown.
also it is not ensured that manual pulldown will help, cause if a bad frame fits only a double telecined frame instead of a triple telecined frame, than you will get a bad frame in the output no matter what you do.

[Guest]

Could you please explain why does this DVD's bad compression make a decimator screw up its decision so badly? The decimator is not screwing up its decision. A decimator should remove the frame that is most like its predecessor, i.e., the duplicate. It doesn't examine your video content and try to guess what is a "bad frame".

[Zarxrax]

It sounds like you'd be best off using Yatta to manually do this thing.

[Chainmax]

I see, thanks for the replies.