Inverse mode1 decimate in decomb

[MrBunny]

Hi neuron2 and everyone else,

I was thinking about the processing of hybrid sources espcially DVDs like Star Trek TNG and Babylon 5, which are mostly progressive, but have the occasional interlaced sequence. As it stands now, the best approach is to use decimate's mode=1 option to replace the progressive stream's duplicate frame with an interpolated frame, while passing through interlaced frames intact. However, it seems to be a bit of a waste to leave a the framerate at 29.97fps when 90% of source is progressive.

What I was thinking was that we could use the same concept as mode1, but in reverse. If a frame is below the threshold (hopefully a progressive frame), it is dropped (just like mode0). If it's above the threshold, every frame in that cycle is replaced with an interpolated frame (of the source's previous and next frames), thus also dropping a frame. Thus, the hybrid material would be dealt with, as well as being able to lower the framerate (and hypothetically get a more accurate reconstruction since the progressive material would be IVTC'd as normal)

I'm not sure how good the quality of this would be, or the implementation, or even the usefulness, it's just something that came to mind.

Thanks,

Mr B.

[Guest]

I did some experiments along these lines and found the result very painful to watch, so I abandoned it.

[InfoCynic]

What about...

Where you have (as part of a hybrid, mostly FILM clip as the Bunny said)

ABCDE all interlaced ->
A(BC')(CD')E

where BC' and CD' are interp frames because C was the "most similar" as determined by Decomb's algorithms? I.E., Replace the 3 most similar frames to each other with 2 interp frames and past the other two through unaltered.

The timing between A and BC' would be a little off compared to the FILM portions but maybe it wouldn't be noticable? Or did you include this in your painful experiments? :)

[Guest]

I didn't try that specifically. But I don't suppose it would be much better than what I did try: A B (CD) E. It was just jerky as heck. You're welcome to continue the experiments if you think I'm jumping to premature conclusions. :)

[MrBunny]

Actually, I guess I wasn't that clear in what I meant.

If you have a sequence ABCDE,
If it's below the threshold and C is the frame chosen by decimate, then the result would be ABDE (just like mode=0).
If it's above, then the output would be (AB)(BC)(CD)(DE).
All four of the frames would be interpolated frames, and not just the one that was chosen.

I realize the quality of four interpolated frames in a row might suffer greatly, and it would probably require a lot of computing power, but if it's only for a small percentage of the entire source, it might be worth it. There'd still be a small jerk leading into the interlaced segment, and a small one leaving it, but that's a lot better than 2 jerks for every cycle. Does this make any sense in practice? I'm known to think too much in theory ;)

Mr. B

[Richard Berg]

I too deal with a lot of clips that are 90% film, 10% video (though not truly "interlaced" -- sourced from CG, not a video camera, so there's no temporal difference between fields). Currently I decimate and just deal with the jerkiness in the computer-animated sections, but if there were a way to reduce the jerkiness without introducing blending in the other 90% then I'd certainly use it.

[Xenoproctologist]

I've been doing this manually, lately. E.G.:
function ntsc(clip last)
{
return last.fielddeinterlace().convertfps(23.976)
}

function ivtc(clip last)
{
return last.telecide(post=false).decimate(mode=2).fielddeinterlace()
}

mpeg2source("vts_01.d2v",cpu=6)

ivtc(trim(0,6025)) +
\ ntsc(trim(6026,6190)) +
\ ivtc(trim(6191,15317)) +
\ ntsc(trim(15318,15437)) +
\ ivtc(trim(15438,16295)) +
\ ntsc(trim(16296,16385)) +
\ ivtc(trim(16384,40402)) +
\ ntsc(trim(40403,40567)) +
\ ivtc(trim(40568,41451)) +
\ ntsc(trim(41452,41586)) +
\ ivtc(trim(41587,57399)) +
\ ntsc(trim(57400,57969)) +
\ ivtc(trim(57970,61852)) +
\ ntsc(trim(61853,62212)) +
\ ivtc(trim(62213,66607)) +
\ ntsc(trim(66608,80856)) +
\ ivtc(trim(80857,0))
Anything that could automate this would make you that much more my hero.


if ( all_five_frames are combed ) {
all_five_frames = fielddeinterlace(all_five_frames);
output = invoke(convertfps(all_five_frames, end_framerate));
}
else if (( all_five_frames are uncombed ) && ( all_five_frames have no_duplicates )) {
output = invoke(convertfps(all_five_frames, end_framerate));
}

[Guest]

OK, I'm convinced something along these lines will be valuable.

One possibility is to apply the ConvertFPS() transform on any cycles that do not contain a duplicate. I will experiment along these lines.