Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
24th October 2006, 22:14 | #1 | Link |
Registered User
Join Date: Dec 2004
Posts: 24
|
Parse D2V file syntax
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:
Code:
[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 * 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? |
24th October 2006, 22:41 | #2 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
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. |
31st October 2006, 08:50 | #3 | Link |
Registered User
Join Date: Dec 2004
Posts: 24
|
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? Last edited by Daner; 3rd November 2006 at 23:39. |
4th November 2006, 19:30 | #4 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
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. |
4th November 2006, 23:39 | #6 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
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.
Last edited by Guest; 5th November 2006 at 03:44. |
4th November 2006, 23:46 | #7 | Link | |
Registered User
Join Date: Dec 2004
Posts: 24
|
Quote:
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. |
|
5th November 2006, 03:46 | #8 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
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.
Last edited by Guest; 5th November 2006 at 03:50. |
11th January 2017, 04:05 | #9 | Link | |
Registered User
Join Date: Jan 2015
Posts: 1,056
|
I just learned about this function and I am THRILLED. One question: I know what TFF and BFF are, but what the hell is "RFF"?
Quote:
EDIT: I just learned something interesting. When parsing a .d2v file, the frames that are marked with * aren't guaranteed to actually be progressive. Correct switching between film and NTSC sections can only be done manually using the parse files as a rough guide.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. Last edited by Katie Boundary; 11th January 2017 at 06:30. |
|
12th January 2017, 12:15 | #10 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
|
12th January 2017, 14:45 | #12 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
I stand corrected.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
13th February 2017, 04:28 | #13 | Link | |
Registered User
Join Date: Jan 2015
Posts: 1,056
|
Thanks. New question. In the "fix.txt" files like this...
Quote:
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. |
|
13th February 2017, 05:22 | #14 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
The section in DGIndex User Manual outlining this is "D2V Format - Data Section ".
Dont think anything intended for human extraction, perhaps some tool exists but not aware of any. Basically just gives file, and byte offset type stuff, nothing about frame numbers or clip time. Usually (in my experience), field order transition occur when somebody has added some clip to beginning or end of clip, eg black leader or trailer, or some kind of credits. Only guide I have ever used is which file it belongs to (see above mentioned docs) and byte position (ie near end of beginning of file). More often than not, I would just ignore them (especially at end) and let it fix the problem, or could try to estimate position (based on byte offset) and investigate after a Separatefields. Perhaps someone knows of some tool to scan d2v's to give a better frame estimate.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
17th February 2017, 02:17 | #15 | Link | |
Registered User
Join Date: Jan 2015
Posts: 1,056
|
I figured it out 12 hours ago. The fix file is written in more or less the same format as the D2V files themselves. As per the dgindex instructions, each line roughly corresponds to one GOP, and the first seven information slots per line are for information about that GOP or its i-frame. Each two-character combination after that is a frame. I haven't yet figured out what all of the first characters mean, and I'm not 100% sure that they matter for the purpose of correcting illegal field order transitions. The second characters, however, are always in the range of 0-3, and they often occur in long repeating 0-1-2-3-0-1-2-3-0-1-2-3 patterns, which means that they're the TFF/RFF flags. So, when you have a fix file that says this...
Quote:
1-2-2-3-0-1-2-3-0-1-2-0-1-3-3-0-1-2-3-0-1-2-3 ...got automatically "corrected" to this... 1-2-2-3-0-1-2-3-0-1-3-0-1-2-3-0-1-2-3-0-1-2-3 ..when anyone with a functioning brain can see that the result should be this... 1-2-3-0-1-2-3-0-1-2-3-0-1-2-3-0-1-2-3-0-1-2-3 Such corrections can be made without having ANY idea what the images look like or where they are in the video.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers. |
|
17th February 2017, 21:09 | #16 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
The way I understand it (which could be wrong), for just the underlined section, it's effectively:
1-2-2-3-0-1-2-3-0-1-2-0-1-3-3 = bff - bff+rff - tff - bff - bff+rff - tff+rff - tff+rff Which was automatically corrected to 1-2-2-3-0-1-2-3-0-1-3-0-1-2-3 = bff - bff+rff - tff+rff - bff - bff+rff - tff - tff+rff When anyone liking nice orderly patterns can see the result should be: 1-2-3-0-1-2-3-0-1-2-3-0-1-2-3 = bff+rff - tff - tff+rff - bff - bff+rff - tff - tff+rff And without ANY idea what the images look like or where they are in the video? Seems dubious to me, but it's not the sort of thing I'd tend to think about. Isn't that what TFM() is for? Last edited by hello_hello; 17th February 2017 at 21:23. |
Thread Tools | Search this Thread |
Display Modes | |
|
|