Parse D2V file syntax

[Daner]

I've searched around and have been unable to find a detailed explanation of how to interpret the file generated by the ParseD2V tool. Here's a sample excerpt:

[GOP]
61418 [B]: 76733,76733..........2 *
61419 [B]: 76734,76734,76735....3 *
61420 [I]: 76735,76736..........0 *
61421 [B]: 76736,76737,76737....1 *
61422 [B]: 76738,76738..........2 *
61423 [P]: 76739,76739,76740....3 *
61424 [B]: 76740,76741..........0 *
61425 [P]: 76741,76742,76742....1 *
61426 [P]: 76743,76743..........2 *
[GOP]
61427 [I]: 76744,76744..........2
61428 [B]: 76745,76745..........2
61429 [B]: 76746,76746..........2
61430 [P]: 76747,76747..........2
61431 [B]: 76748,76748..........2
61432 [B]: 76749,76749,76750....3 *
61433 [P]: 76750,76751..........0 *
[GOP]
61434 [B]: 76751,76752,76752....1 *
61435 [B]: 76753,76753..........2 *
61436 [I]: 76754,76754,76755....3 *
61437 [B]: 76755,76756..........0 *
61438 [B]: 76756,76757,76757....1 *
61439 [P]: 76758,76758..........2 *
61440 [B]: 76759,76759,76760....3 *
61441 [B]: 76760,76761..........0 *
61442 [P]: 76761,76762,76762....1 *


Now, I understand that [GOP] represents the start of a new group of pictures, I know what I/B/P frames are, and I understand that an asterisk at the end of a line indicates that the frame fits within a 3:2 pulldown pattern.

What I don't understand is the rest. Are the comma-delimited numbers field numbers? Why are there sometimes 3 for a single frame? Do the numbers at the beginning of each line represent the pulled-down frame number? What exactly do the numbers 0, 1, 2, and 3 at the end of each line indicate?

[neuron2]

I'll deconstruct it for you...

61418 [b]: 76733,76733..........2 *

This represents picture number 61418 of the coded MPEG stream (not the display frame numbering, which can be different due to pulldown). It is a B picture. Its fields appear together in display frame 76733. The 2 at the end is a bitmapped indication of the TFF/RFF flags. Bit 0 is RFF, bit 1 is TFF, so 2 = binary 10, which means this picture is TFF and is not pulled down. That is why there are only 2 display frame numbers shown.

61419 [b]: 76734,76734,76735....3 *

This represents picture number 61419. It is a B picture. Two of its fields appear in display frame 76734, and one (pulled down) in 76735. TFF=1 and RFF=1.

[Daner]

Thanks, Donald, for your reply. That certainly explains things for me.

Now this raises another question in my mind. In the case of a soft-telecined hybrid DVD source (that is, one which is not reported as 100% VIDEO by DGIndex, but rather contains mostly 3:2 pulled-down material with a few occasional breaks in the pulldown pattern), shouldn't it be possible to exactly reconstruct the proper progressive frame sequence by using this information?

Currently, it appears that DGIndex can either do all FORCE_FILM for the entire sequence, or no FORCE_FILM for the entire sequence, either of which will result in some combed frames when performed on a sequence that is not 100% FILM. Yet, the RFF and TFF flags tell you exactly how to translate between the display frames and the source pictures, so why can't DGIndex make use of this information to perform inverse telecine (FORCE_FILM) on the pulled down material, and a simple deinterlacing filter on the nonfilm material, and then output a timecode file to indicate where the 24fps vs. 30fps frame sequences are, to be used in a variable framerate MKV container?

[neuron2]

You could cobble that together by doing this:

1. Use Ignore Pulldown Flags for your project.
2. Massage the Parse D2V log into a timecode file.

This will work only for cases where there are good 3:2 sections mixed with video sections. I will consider adding a function to generate the timecode file.

[Daner]

1. Use Ignore Pulldown Flags for your project.
2. Massage the Parse D2V log into a timecode file.

I see. So at what point, and through which method, would the IVTC be done on the pulled-down material?

[neuron2]

So at what point, and through which method, would the IVTC be done on the pulled-down material? If you ignore the pulldown flags of a pure 3:2 soft telecined section, that is equivalent to a perfect IVTC. The video portions are unaffected. If you want them deinterlaced, you can use some deinterlacer that touches only combed frames, such as FieldDeinterlace(full=false). TDeint() can do that also. I don't see DGIndex as the right place to do deinterlacing.

[Daner]

If you ignore the pulldown flags of a pure 3:2 soft telecined section, that is equivalent to a perfect IVTC.

Oh right, that makes sense!

If you want them deinterlaced, you can use some deinterlacer that touches only combed frames, such as FieldDeinterlace(full=false). Deint() can do that also. I don't see DGIndex as the right place to do deinterlacing.

Well the reason I suggested doing it in the DGIndex stages rather than in the AviSynth stages is because DGIndex has access to the RFF and TFF flags, so it knows exactly where the nonfilm sequences are. FieldDeinterlace and Deint, on the other hand, can only rely on image analysis to detect combed frames, so their decisions will always be imperfect.

[neuron2]

The TFF/RFF flags are stored in the D2V file, so they are available. I believe TDeint() has a mode that can read the flags and deinterlace conditionally as you describe, IIRC. You could also use the known frame ranges (from the D2V file) to create an override file to FieldDeinterlace() or TDeint(). Finally, we can't assume that non-film must be interlaced, because it could be full rate progressive. So maybe it is better to use image analysis to determine if frames are actually combed.