Need IVTC guru input on animated DVD

[omf]

I have an interlacing pattern on an out-of-print NTSC DVD from 2007. The animated film was released in 1997.

The pattern is mostly, but not always, like this:

PPPP-I-PPPP

Four progressive fields followed by a single interlaced filed.

Here's a 14-second clip that includes this pattern and a couple of variations:
https://drive.google.com/open?id=1meeCLD2RkuYiEO8tjPXwIUSOqk7JC8cH

The pattern I described starts right at the beginning of the clip. There are a few spots where the pattern changes:

At field 91 we see II-PPP, two interlaced fields followed by 3 progressive (which is what I'd expect throughout the video).

At field 310 it looks like we have PPPPP-I, five progressive followed by single interlaced field.

At field 322 it looks like we have PPPP-II, four progressive follwed by two interlaced fields.

I'm really curious how this got to be this way - is this a normal, known pattern?

And, of course, I'd love to know how to properly deinterlace it. A straight tfm/tdecimate(mode=1) looks mostly okay, but does result in some noticeable artifacts. VLC automatic deinterlacing seems to do a better job, but I don't know what it's doing.

[manono]

A straight tfm/tdecimate(mode=1) looks mostly okay, but does result in some noticeable artifacts.
it looks okay to me as well. What kind of artifacts? I noticed some chroma problems, but nothing serious.

I'm really curious how this got to be this way
It's animation with repeated frames.

[omf]

it looks okay to me as well. What kind of artifacts? I noticed some chroma problems, but nothing serious.


Thanks for taking a look.

It's not serious, but I thought there might be a better way to do it that I don't know about.

I took a closer look at VLC's deinterlace, and it's actually very similar, but just different enough to be less noticeable.

Here's the frame at 00:01.710 in that clip using tdecimate(mode=1):
https://i.imgur.com/sBgpOrA.png

Here's the same frame in VLC:
https://i.imgur.com/9FVBZBZ.png

The VLC version doesn't have the horizontal banding, which I think is what catches my eye as I'm watching the tdecimate version.

It's animation with repeated frames.

Having single interlaced fields seems weird. I guess it's a way of maintaining temporal resolution while adjusting for different frame rates? I've never seen mention of this kind of pull-down conversion, especially since it changes patterns a lot.

[manono]

Having single interlaced fields seems weird.The video was hard telecined normally. But when fields are taken from 2 adjoining frames that happen to be duplicates of each other, those two fields create a third duplicate frame. So, instead of having 2 interlaced frames out of every five as with live action videos, you get one in five in those cases.

I don't know of any way to remove that chroma problem, but I wouldn't worry about it. Maybe someone else has a suggestion.

[ChaosKing]

With vivtc.VFM(clip, 0) it looks like the chroma plane is not processed at all and this is why it looks so weird on some frames (like chroma blending). QTGMC is very similar.
But the file looks "very good" in PotPlayer without some weird chroma shifted/blended frames, just like regular blending.
https://i.imgur.com/GGOAOZs.jpg

[manono]

Here, try this:

TFM(field=1, mode=5)
TFM(field=0, mode=5)
TDecimate(mode=1)

I didn't check all of the sample but it seems to fix the frame you showed as well as some others.

[ChaosKing]

I only found one broken frame when the door is opened, otherwise it's perfect.

[omf]

The video was hard telecined normally. But when fields are taken from 2 adjoining frames that happen to be duplicates of each other, those two fields create a third duplicate frame. So, instead of having 2 interlaced frames out of every five as with live action videos, you get one in five in those cases.


Ah - thanks for cleaning that up.


Here, try this:

TFM(field=1, mode=5)
TFM(field=0, mode=5)
TDecimate(mode=1)

I didn't check all of the sample but it seems to fix the frame you showed as well as some others.

Interesting! That does look very clean compared to the plain tfm/tdecimate. Starting at about 03.045 it starts matching the output from the plain tfm/tdecimate, though (the same horizontal banding), so it's cleaner only up until that point.

https://i.imgur.com/AdXyTbl.png
https://i.imgur.com/CdSEIlb.png
https://i.imgur.com/oYtOl2Q.png
https://i.imgur.com/VkOVH3F.png
https://i.imgur.com/NSw0GuC.png

I'll try running the whole video this way and see how it compares overall. At least this gives me something to try - thanks!

[manono]

Yeah, you're right. Sorry, then, not much help.

[ChaosKing]

I only found one broken frame when the door is opened, otherwise it's perfect.

I should've said that I tested it with VapourSynth:
clip = core.vivtc.VFM(clip, 0)
clip = core.vivtc.VFM(clip, 1)

@omf have you used DGDecode/MPEG2Source? ffms2 is not frame accurate for vob files.

[real.finder]

did you tried animeivtc(1,chrfix=true) or chroma_rep/chroma_rep2 (https://forum.doom9.org/showthread.php?p=1778955#post1778955)?

[SaurusX]

Similar problem with solution: https://forum.doom9.org/showthread.php?t=171134

[ABurns]

@omf have you used DGDecode/MPEG2Source? ffms2 is not frame accurate for vob files.

Hold up. Can you elaborate on that? That's the first time I've ever heard that, and I'm currently using ffms to decode mkv rips that contain mpeg2 streams. Is this something specific to the VOB container, or mpeg2 streams in general?

[manono]

Hold up. Can you elaborate on that?
Decrypt using a proper decrypter. Use the DGDecode.dll together with MPEG2Source to open the video. It's all well explained in the docs included in the DGMPGDec (https://www.videohelp.com/software/DGMPGDec) package.

If all you have is an MKV (not repackaged by you from VOBs or some other kind of MPG), then demux before using DGIndex to index the video. Do NOT use DGIndex on an MKV. This is probably more important for NTSC sources than for PAL, but I still wouldn't do it any other way.

[ABurns]

Decrypt using a proper decrypter. Use the DGDecode.dll together with MPEG2Source to open the video. It's all well explained in the docs included in the DGMPGDec (https://www.videohelp.com/software/DGMPGDec) package.

I'm familiar with the package, but I thought once the stream is indexed, whether d2v, ffindex, lsmashindex, or whatever, that the AVS stream is then frame-accurate.

Sorry, I don't mean to go OT, but...

The reason I'm using the ripper I am is the sheer volume of discs in my library (thousands). A lot of them are awkwardly authored with multiple episodes in a single VOB, and there is no quick way to separate them out from a single IFO while preserving subs, chapters, etc. without a lot of manual intervention that makes the process too slow. MakeMKV makes that quick and easy, and then I can do my encode.

Until recently I've done everything manually with DVDDecrypter, DGIndex, and manual encoding, but at the rate I've been going it's going to take years - already about 3 years in. I'd like to finish before I'm ready for the old folks home, so I've started looking at tools like MeGUI 1-click, StaxRip, and MakeMKV to speed things up. So I'm looking for the optimum workflow to get this done sometime before I die without trashing my encodes.

[videoh]

Do NOT use DGIndex on an MKV. This is probably more important for NTSC sources than for PAL, but I still wouldn't do it any other way. Good advice of course but there is another way: DGIndexNV has similar functionality and can open MKV directly. It requires an nVidia GPU so may not be an option for some.

[manono]

DGIndexNV has similar functionality and can open MKV directly. It requires an nVidia GPU so may not be an option for some.
Not that your work isn't well worth it, but it should be pointed out that DGIndexNV (http://rationalqm.us/dgdecnv/dgdecnv.html) requires a small investment. For ABurns with his MKVs and his thousands of videos, if he has the right GPU it should be worth the nominal charge.

[ABurns]

Not that your work isn't well worth it, but it should be pointed out that DGIndexNV (http://rationalqm.us/dgdecnv/dgdecnv.html) requires a small investment. For ABurns with his MKVs and his thousands of videos, if he has the right GPU it should be worth the nominal charge.

I do. I've already made a donation and waiting on my email. :thanks:

[ChaosKing]

Hold up. Can you elaborate on that? That's the first time I've ever heard that, and I'm currently using ffms to decode mkv rips that contain mpeg2 streams. Is this something specific to the VOB container, or mpeg2 streams in general?

Vob is not frame accurate with ffms2 https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md#video
I just tested ffms2+Mkv+mpeg2 (remuxed my vob) and it is only frame accurate with seekmode=0 and only for newer ffms2 builds. Lsmash is fine! And is most of the time the better choice anyway.

See also https://forum.doom9.org/showthread.php?t=176231