Bad IVTCs and GOPs

[borghe]

I am using avisynth to IVTC my Star Wars laserdiscs back to 24fps. It works beautifully 99.9% of the time. The other .1% of the time it mixes two incorrect fields together for one frame. Decomb will merge one field from the previous scene and one field from the new scene. The result almost looks like a fade wipe, except that it's only for one frame.

The problem is that TMPEG will detect a scene change on the merged frame, thus starting a GOP with the bad picture. I would like to figure out a way to fix the bad frame, either during IVTC or during encoding, so that during direct cuts like that it will end with the one scene and start with the new scene. The one solution I've figured out myself is to maybe flag the frame in TMPEG as a P frame copy from a previous I,P frame, then flag the frame immediately before it as a P frame. This would essentially give you two identical frames in a row which for the most part should be fine (and compress better).

The one solution I don't know how to do is to fix it in Decomb/avisynth. Is there a way I can inform Decomb of those fields and to tell it to repeat a frame?

Just looking for a little help.

[SLK001]

DECOMB does have the ability to override settings you have set by frame number (I believe that it is the "ovr= " switch). You can create a file of these overrides, and read it into the filter.

You don't tell us how you are IVTC'ing. Are you doing it with three passes? I have noticed that if you use multipasses, that sometimes frames do get messed up like this (happened to me on my SW LD conversions). What I did was have a separate single pass IVTC'ing run at 9Mbps that did only the IVTC'ing - no other filters, which can confused the proper field matching. Once I have a good 24fps video, I then run three passes with all the other filters that I want to add. This takes longer, but the result is well worth the effort.

Make sure that you are using the latest version, and not the BETAS, as I have had problems with the BETAS.

[borghe]

the problem was in Decomb's decimate.. I had set it to mode=3 which should be used for mixed film and video. It was leaving such frames in instead of correctly removing those frames. Going back to mode=0 (all film) has cleaned up all of those frames. I just have to wait until I get home to check out the actual jerkiness of the supposed video segments. Although if it does turn out to be a little jerky I may actually be willing to put up with that as opposed to just as much time in junk frames and bad GOP I frames.

[SLK001]

There is no MODE=3 in DECIMATE (valid range is 0-2). However, you can still override DECIMATE's decision with an override file.

You might want to add the QUALITY=3 option, which will cause the decision process to more exacting.

[borghe]

hehe... I have been through this before in another thread. There is a mode=3, but only on the avisynth2.5 version, not the legacy 2.0 version. I am using avisynth2.5 and decomb 4.10b4

[SLK001]

Okay... I've been holding off moving to 2.5+ versions until it was out of BETA. 2.5.2 is the first non-BETA version, so I'll be moving to it soon.

[DJRumpy]

LOL..that does sound familiar. Borghe, there is a switch for the decomb function to tell it not to mix the fields from a scene change. This would handle your issue. Let me see if I can find it.

I'll post the details when I do.

[DJRumpy]

For the life of me, I couldn't find the specific post, although I'm sure I read it somewhere. The only other close match had to do with the Threshold setting in the Decimate command. If your using Mode0 however, this param has no effect.