Possible Decomb 5 Decimate bug

[madoka]

As seen from the screen shot (may need to copy & paste link, since GeoCities is hosting it), Decimate() doesn't seem to decimate the same frame from the same source clip all the time.

http://www.geocities.com/ayanami_rei_ii/f109252.jpg

[neuron2]

Judging by the frames on display as well as the metrics, it appears that the two instances of the Decimate() filters are receiving different input. Is the script IDENTICAL in both cases?

[madoka]

Originally posted by neuron2
Judging by the frames on display as well as the metrics, it appears that the two instances of the Decimate() filters are receiving different input. Is the script IDENTICAL in both cases?
Yes. I had VDub & VDubMod open the exact same file, maze.avs, which consists of:

mpeg2source("maze.d2v")
Telecide(order=1, post=2, vthresh=0, blend=true)
Decimate(mode=2, quality=3, show=true)
Crop(0, 0, 360, 0)

Crop() serves no purpose other than making the screen shot smaller.

I'm pretty sure that it's not a bug in VDub or VDubMod. The reason I didn't just use 2 instances of VDub (or VDubMod) is because I have a hard time reproducing the bug consistently, at least in places where there's an abrupt scene shift; I happen to spot it this case. Furthermore, the bug only manifest itself "locally"; VDub & VDubMod displayed the same frame for frame 38358 and frame 217295.

[neuron2]

I need your entire script, including the load plugin lines. Are you using random access or playing through in a linear fashion to the comparison frame? If the former, how are you doing it?

Instead of speculating about who is at fault, please tell me the exact procedure you used to obtain the result.

[madoka]

Originally posted by neuron2
I need your entire script, including the load plugin lines. Are you using random access or playing through in a linear fashion to the comparison frame?
That is the entire script. LoadPlugin() is not in the script, since I have all my plugins in the auto load directory. Here are the plugins I have in it:

AutoCrop (version unknown)
Decomb (version 5.00)
MPEG2Dec3 (version 1.01)
MSharpen (version 1.10b2)
MSmooth (version 2.00b1)
VSFilter (version 1.005)

Oh, I have 2 new screen shots, this time both using VDub. Although the script is slightly modified from the one given above (I tried to use StackHorizontal() to see if I can get the bug to show in the window; it hasn't worked yet), the *exact* same script is used for the 2 screen shots.

http://www.geocities.com/ayanami_rei_ii/frame.jpg
http://www.geocities.com/ayanami_rei_ii/frame_prime.jpg

[neuron2]

Please answer all my questions. Thank you.

"Are you using random access or playing through in a linear fashion to the comparison frame? If the former, how are you doing it?"

[madoka]

Originally posted by neuron2
Please answer all my questions. Thank you.

"Are you using random access or playing through in a linear fashion to the comparison frame? If the former, how are you doing it?"
Oops, I guess I was too hasty in reading your reply. Sorry about that.

In any case, I'm not sure if I arrive at the comparison frame the same way for all my screen shots, for I didn't think random or linear access would make a difference. However, this is how I spot a discrepancy initially:

I guess where a scene change is by random access (using the "Go to..." command in VDub). Depending on how far I'm off, I jump forward or backward (using either the "Go to..." command again, or "Foward/Back 50 frames"). Finally I use the arrow keys to step forward/backward frame by frame until I pinpoint the scene change. I record the frame number.

Later when I'm ready to encode, I jump to the frame number that I recorded earlier. Sometimes, however, I notice that the scene change didn't happen at the frame I recorded, but rather at the next/previous frame.

[neuron2]

Please try with Decimate(mode=0) and report back. IIRC, for mode=2, the result depends upon how you reach the frame.

[madoka]

Originally posted by neuron2
Please try with Decimate(mode=0) and report back. IIRC, for mode=2, the result depends upon how you reach the frame.
With you hint that frame accessing method may affect result, I have came up with a semi-reliable way to reproduce the problem. And so far the problems seems to be gone with mode=0.

However, since most of the material I work with is anime, isn't using mode=0 sub-optimal?

[neuron2]

With mode=2, things are similar to pattern guidance, you have to start a ways ahead and then play through linearly. This is not an issue during encoding, because you start at the beginning and play through linearly to the end.

Note: mode=2 is only needed for anime that is rendered with low motion, such as 12fps doubled up to 24fps. Much of Princess Mononoke is like that. In any case, you'd need to be something of a purist to care about the difference.

[madoka]

Originally posted by neuron2
With mode=2, things are similar to pattern guidance, you have to start a ways ahead and then play through linearly. This is not an issue during encoding, because you start at the beginning and play through linearly to the end.
Hmm, this may be a problem for me, since I usually don't start encoding from the beginning; usually, I cut out the opening & ending songs by finding the range of frames the episode is in (using the above mentioned method), then later encode only that segment.

Note: mode=2 is only needed for anime that is rendered with low motion, such as 12fps doubled up to 24fps. Much of Princess Mononoke is like that.
I thought most anime are like that, except for some with heavy CG.

In any case, you'd need to be something of a purist to care about the difference.
Do you mean that in most cases mode=0 and mode=2 produces comparable results, even for anime?

[Leak]

Originally posted by madoka
[B]Hmm, this may be a problem for me, since I usually don't start encoding from the beginning; usually, I cut out the opening & ending songs by finding the range of frames the episode is in (using the above mentioned method), then later encode only that segment.

Well, I guess it comes down to at most 10 or 15 extra frames you'd have to leave at the beginning, so why not just trim off 10 or 15 frames less before decimating and then use another trim to get rid of those extra frames after decimating?

(If you leave an extra 15 frames, a trim(12,0) after decimating should take care of it...)

np: Banco De Gaia - Kincajou (Duck! Asteroid) (Last Train To Lhasa)

[Asmodian]

I have noticed that mode=0 works very well with most anime content, If you notice problems it is possible they could be corrected using mode=2 but I have also seen problems with mode=2 that were corrected with mode=0.
The IVTC process is all about what problems you mind less ;) (especially with anime) or you could do it manually :P

[madoka]

Alright, I'll just use mode=0 instead then. Thanks for the time.