Video stutters as TFF and BFF, what's going on?

[Chainmax]

I finally got my hands on "City of God" and promptly started trying to rip it, but it gave me a weird problem at the very first stage. When using assume[X]ff().separatefields() it stutters on both TFF and BFF, although the problem isn't as bad with TFF. Also, when stepping through the video, some frames are completely green and some display something like a "green-colored deinterlacing motion map". What do you guys think is causing this? I'm using DGMPGDec v1.0.12a, Avisynth v2.55 build Mar 18 2004 and my YV12 decoder is Helix, BTW.

Here's a vob sample (http://www.31012.com/~stuff/CoGClip.vob).

[Kika]

I don't see anything weird on your sample. Looks fine... and it is progressive, not interlaced.

[Chainmax]

I already knew it's a common 3:2 telecine. The problem is that while it seems to be TFF I can't say for sure because it still stutters when using AssumeTFF().SeparateFields().

[tritical]

Another way to determine field order if your using a d2v file is to look at the value of the first trf flag in the d2v. If it is a 2 or 3 then the video is tff, if it is a 0 or 1 then it is bff. Might try using this method and see what it indicates if your not sure when using the separatefields() method.

[Chainmax]

I should use DGParse in order to do that, right? In any case, what do you think could be causing both problems I'm experiencing?

[tritical]

Or just open the .d2v file in notepad. The line your interested in is the first line after the Location= line (not the blank line but the next one). Using dgindex it should look similar to this (this is from another vob not your sample):

Location=0,0,0,7FFAA

7 0 2048 1 1 12 12 12 12 12 12 12 12 12 12 12 12

The first number is always 7, the second number is the file #, the third number is position, the fourth number is the vob, and then the fifth number is the cell. All the numbers after that (the 6th number on) are trf flags. Though with dgindex it can add an extra 1 before the trf flags for decoding purposes. In the above case, the sixth number is 12, so just ignore the first digit, I'm counting the left most digit as the first digit, (if the number has two digits) and look at the second digit (it is the actual trf flag). If that digit is 2 or 3 (it is 2 in the above example) then your video is tff, if it is a 0 or 1 then it is bff. If you use dvd2avi 1.76 or early versions of dvd2avidg, which you aren't but just want to be clear, then you will not have the vob/cell numbers in the lines. Thus, the trf flags would start as the 4th number and will never have a 1 preceding them.

For your other problem I don't know, and I pretty sure you would have already tried everything I would suggest. Things you might try are using dvd2avi 1.76 and mpeg2dec3 and see if the problem is still present, though I highly doubt that would be the problem, or try opening the vobs directly in vdub/vdubmod and see if the problem is present. If you think it might be due to your yv12 decoder try converting to yuy2 at the end of your script. I did not have any decoding problems with your sample vob.

[Chainmax]

The number that appears on the d2v is 10, so I'll assume BFF then. I have two more questions:


1) How can I tell if the field order is wrong?
2) How can I tell if DGIndex added the extra 1?


As for the rest of your answer, yes, I did try using DVD2AVI 1.76 and Mpeg2Dec3 v1.10. Funny thing is, the green artifacts don't seem to appear when stepping through the final avs :confused:.

[Kika]

Why do you want such things like separatefields()? It's a progressive Movie.

And yes, i'm still using DVD2AVI 1.76 and older Versions of MPEG2Dec3 or m2v.vfp. Just because they are working without any problems...

[Chainmax]

It's just a temporary step that allows me to find out the field order so that I can correctly perform IVTC. It's not on the final script. The method suggested by tritical is faster and less subjective (how "stuttery" it feels), so I'll be using it from now on.

[scharfis_brain]

huh?

this one is a progressive movie!

no need for IVTCing here!

check forced FILM in DGIndex / DVD2AVI

so no separatefields() for motioncheck needed.

it is progressive!!!

[Kika]

it is progressive!!!

Yes, Chainmax, i said it two times... it is a progressive Movie. :rolleyes:

No IVCT, no deinterlacing - just correct decoding and progressive encoding is needed.

[Chainmax]

Kika, I thought you were referring to progressive telecined material, now I get what you meant. Sorry :o.

As I already said, I can see a "3 progressive frames, 2 interlaced ones" pattern when stepping through the movie in VDubMod. Isn't that a clear sign of 3:2 telecining? Wouldn't a progressive movie only have progressive frames? Also, isn't Force Film a way to reverse telecining? I'd rather IVTC with Decomb and KernelDeint than use Force Film.

[tritical]

If you decode the movie w/o any field operation in dvd2avi it will be telecined so you would need to ivtc later. What they mean is that the telecining for this movie has been achieved by correct use of the rff flag and not by telecining the movie prior to putting it on the dvd. The sample vob you put up is 100% film (by dvd2avi's definition), the trf flags repeat in the 0 1 2 3 pattern the entire time. If this is the case for the entire movie then you can safely use force film in dvd2avi w/o any worries (dvd2avi/dgindex will give the video type as plain FILM, no percentage).

You can tell whether dgindex added an extra 1 by whether or not any of the numbers from the 6th number on over have 2 digits. If they have two digits then dgindex added a leading 1 to the trf flag, if not it did not then it is simply the trf flag by itself.
1) How can I tell if the field order is wrong?
The separatefields() method is the easiest AviSynth method I think. Though, assuming your using a d2v file, the d2v method of checking the first trf flag should always give you the correct field order... personally I dunno how it could be wrong since 0 or 1 means the tff flag is 0 and a 2 or 3 means the tff flag is 1. If you do use this method I would recommend always using neuron2's fixd2v to check for illegal field order changes. Actually, I would always recommend using it when using d2v files.

[Chainmax]

Ok, now I completely understand. I always made the assumption that Force FILM was not to be used because IVTCing was always a better choice. Re-reading the last parts of the IVTC tutorial, I see that this assumption is wrong when DVD2AVI shows 100% FILM. I read that tutorial many times, I can't believe I missed that :o :o

I'd like to thank everyone for being so patient, and especially to tritical for being so thorough in his answers. You guys rock :).

[Chainmax]

This is so weird, the movie is composed of 5 vobs, the first one being a 1sec black clip. If I include that in DGIndex, then the scene corresponding to the sample doesn't show as plain FILM. If I exclude that first vob, I get an "Opening GOP is not closed. The first few frames may not be decoded correctly" error but the scene corresponding to the sample does show as plain FILM :confused:.
Anyway, even in the latter case, the movie ends up reverting to 99% FILM. Should I stick to Force Film even in this case?

[DarkNite]

It's pretty safe to assume force film as good for anything 95% or above.

[Chainmax]

Yeah, I know about that, but according to the IVTC tutorial, sometimes even 99% FILM streams can have some issues when forcefilmed. Also, later on the movie changed to 2% NTSC on some spots. What strikes me as odd is the other problem I described. Maybe I'll try ripping the movie again.

[Aktan]

You can try using IT.dll to deinterlace. That seems to work fine if it really is pure "FILM"

[MasterYoshidino]

ignore the bobbing, it's obviously bff.
try forcing bff like below
MPEG2source("test.d2v",cpu=0,cpu2="000000",iPP=true,idct=3)
telecide(order=0,guide=1,chroma=true,vthresh=30.0,dthresh=10.0,gthresh=10.0,post=1,blend=false,hints=true,back=0)
IT(fps=24,diMode=2,ref="BOTTOM",blend=false)
crop(8,0,704,480).lanczosresize(640,352)