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.

 

Go Back   Doom9's Forum > General > DVD2AVI / DGIndex

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 7th January 2005, 00:32   #1  |  Link
Cyberia
Moderator
 
Cyberia's Avatar
 
Join Date: Nov 2002
Location: Inside
Posts: 718
DGMPGDec (DVD2AVI) F.A.Q.

DGMPGDec (DVD2AVI) F.A.Q.


Part 1: Intro and Versions
Q01: What is DGMPGDec (DVD2AVI) and what does it do?
A:
The primary function of all versions of DGMPGDec (DVD2AVI) is to create an index of the location of each frame in an MPEG2 stream and some information about each frame.



Q02: How does DGMPGDec (DVD2AVI) relate to DGDecode (MPEG2DECx)?
A:
DGDecode (MPEG2DECx) reads the .d2v project file from DGIndex (DVD2AVI) and decodes the video into AviSynth.



Q03: What versions of DGMPGDec (DVD2AVI) exist and which version should I use?
A:
There currently are at least 9 versions of DGMPGDec (DVD2AVI):
  • DGMPGDec 1.2.1: Based on DVD2AVIdg v1.3.0. Has a new icon and naming convention: DVD2AVI.exe -> DGParse.exe; MPEG2DEC3.dll -> DGDecode.dll; VFAPI.vfp -> DGVfapi.vfp. Adds auto AVS file generation, raw PID detection, and can demux MPEG audio and AAC from transport streams. Now walks the dog and cleans your house. Plus many bug fixes. (by Don Graft)

    ALL VERSIONS LISTED BELOW ARE OBSOLETE! STOP USING THEM!

  • DVD2AVIdg v1.3.0: Greatly enhanced and updated version which combines all the features of the other various builds of DVD2AVI: GUI rebuilt, CLI, transport streams, D2F compatibility and much more. This version also fixes a number of issues affecting ALL of the other builds, such as dropped frames and incorrect LBA addresses. Based on DVD2AVI v1.77.3. (by Don Graft)
  • DVD2AVI v1.86: Enhanced version. (by Gloval)
  • DVD2AVI v1.83.6: Enhanced version, based on Save-OE, which supports DVB or ATSC transport streams. It also has some nice optimizations for P4's. Should be used together with mpeg2dec3.dll v1.08+ (by trbarry and Nic)
  • DVD2AVI v1.82: Enhanced version which also forms the basis for the Save-OE project, a not very active Sourceforge project. (by Ogo)
  • DVD2AVI v1.77.4: This is a modified version of v1.77.3 that can save v1.76 style d2v files.
  • DVD2AVI v1.77.3: This is a new enhanced version from Jackei that has a lot of new features and enhanced crop/resizing etc. (by Jackei)
  • DVD2AVI v1.76 CLI: This version supports a Command-Line Interface, which is required for use with some GUIs like DVD2SVCD. (by DVD2SVCD)
  • DVD2AVI v1.76: Original version. (by Jackei)


Part 2: Video menu
Q04: What are the different iDCT Algorithms and which one should I use?
A:
First, understand what an iDCT algorithm does. iDCT stands for Inverse Discrete Cosine Transform. It is the method by which digital data in an MPEG stream is decoded into analog video data for your TV or computer screen. Which iDCT to use depends on what CPU you have and possibly on how accurately you want to decode the frames. These are the available options:
  • 32-bit MMX - Requires at least a Pentium MMX and should be much faster than the IEEE -1180 Reference iDCT. High precision, but slightly (imperceptibly) imprecise.
  • 32-bit SSE MMX - Requires at least a P3 or Athlon (Thoroughbred) and should be faster than 32-bit MMX or 64-bit Floating Point. High precision, but slightly (imperceptibly) imprecise.
  • 32-bit SSE2 MMX - Requires at least P4 or Athlon64 and should be the fastest algorithm. High precision, but slightly (imperceptibly) imprecise.
  • 64-bit Floating Point - Will work on any processor and should be faster than 32-bit MMX. Very high precision, producing output closest to the IEEE -1180 Reference iDCT.
  • IEEE -1180 Reference - The official standard algorithm. It is very slow, but by definition should produce nearly perfect output.
Most people will not be able to tell the difference in quality between these algorithms but they can be easily observed by using the AviSynth filters Subtract and Levels.
NOTE: DGDecode (MPEG2DECx) supports several more iDCTs which can override the specified DGIndex (DVD2AVI) value.



Q05: What are the different Field Operations and which one should I use?
A:
This is a complicated question, but is perhaps the most important one to understand when using DGIndex (DVD2AVI). First, let's describe the differences:
  • None - Outputs constant 29.970 frames/sec. The RFF flags are honored, i.e, pulldown is performed according to the flags, and the flags are stored in the D2V file.
  • Force Film - Outputs constant 23.976 frames/sec. Will possibly add or delete frames to maintain this frame rate (when there are more/less RFFs than implied by exact 3:2 pulldown). The RFF flags are not honored, i.e., pulldown is NOT performed, but the RFF flags are stored in the D2V file.
  • Raw Encoded Frames - Outputs (possibly fluxuating) source frame rate. No frames are added or deleted to maintain a film frame rate. RFF flags are not honored, i.e., pulldown is NOT performed, but the RFF flags are stored in the D2V file.
    NOTE: This option is only available in DGMPGDec.
  • Swap Field Order - Reverses field order by swapping Top and Bottom fields.
    NOTE: This option is not available in DGMPGDec. You can use the AviSynth SwapFields filter or Simon Walters' Reverse Field Dominance filter if you need to reverse the field order.
Most users should first attempt to generate a d2v project using the Force Film option. If the Video Type field in the Information window indicates FILM 95% or higher, everything is probably OK. If the percentage is lower or the Video Type indicates an NTSC percentage, you should recreate the d2v project using the None option, and then perform IVTC (Inverse Telecine) using your encoder or an AviSynth plug-in.

The Raw Encoded Frames option should be necessary only for advanced users who want to see just the exact coded pictures in the MPEG stream.

You should also read this article for additional information on using Force Film vs. IVTC (Inverse Telecine).



Q06: Which Colorspace option should I use?
A:
RGB if you are going to frameserve to VFAPI. Use YUV in all other cases.
NOTE: The Colorspace option is not available in DVD2AVIdg or DGMPGDec because these versions set the colorspace automatically.



Q07: What does the "YUV -> RGB" option do?
A:
First, understand that this option is ONLY used in two cases: when you use DGDecode's internal RGB conversion filters, or when a 3rd-party application requests an RGB frame.

PC Scale: YUV [16,235(Y)/240(UV)] -> RGB [0, 255]
TV Scale: YUV [16,235(Y)/240(UV)] -> RGB [16, 235]

Only use TV Scale if you are using TMPGEnc with the "Output YUV Data As Basic YCbCr Not CCIR601" option checked (it's UNchecked by default), or CCE with the "Luminance Level 0 To 255" option provided you are feeding it RGB.

Otherwise, always use PC Scale.



Q08: Should I use the Luminance Filter?
A:
This is entirely up to you to decide. If you feel to video to too dark or too light, you can use this option to correct the Luminance.
NOTE: The values specified here are performed using the DGDecode (MPEG2DECx) LumaFilter filter. There is no advantage to performing this operation in DGIndex (DVD2AVI) except that you can use the GUI and visualize the output.



Q09: Should I use the Crop Filter (aka: Clipping)?
A:
This is entirely up to you to decide. If you feel the need to crop the video (possibly to remove black bars) you can use this option to perform cropping.
NOTE: The values specified here are in fact performed using the AviSynth Crop filter. There is no advantage to performing this operation in DGIndex (DVD2AVI) except that you can use the GUI and visualize the output.



Part 3: Audio menu
Q10: What are the differences between Decode and Demux?
A:
The Decode function will decode the raw audio (including DRC, Downmixing and Normalizing) and produce a 2 channel wav file. The Demux function will extract the raw audio format entirely and save it as a file. You can then use this file for whatever purposes you want.



Q11: What audio formats can be decoded by DGIndex (DVD2AVI)?
A:
AC3 and LPCM



Q12: What audio formats can be demuxed by DGIndex (DVD2AVI)?
A:
AC3, MPA, DTS (not available before v1.77.3. Read this thread for info about how to handle DTS audio.)



Q13: Why isn't the DELAY value the same when I demux an AC3 file with v1.76/1.77.3 and 1.3.0dg/DGMPGDec?
A:
Because there is one or (usually) two more video frames at the start of the video in neuron2's version (See Q34 below). This will account for up to 83ms difference. But it may also mean that a different starting position is chosen for the audio, which in itself may introduce a few ms of delay and the total effect may be as much as 100ms or more.



Q14: Should I decode or process the audio in DGIndex (DVD2AVI) at all?
A:
No, decoding and processing are now better handled by an external program such as BeSweet. Therefore, just have DGIndex (DVD2AVI) demux the audio to a file. This will generate one or more audio files containing "DELAYxxxms" in the filename. You can then process these files externally, if necessary.



The following questions assume that you have decided to use the internal audio processing of DGIndex (DVD2AVI) despite the previous question.



Q15: Should I use the Dynamic Range Control option?
A:
This is entirely up to you to decide, but it's usually a good idea. Dynamic range is the difference between the loudest and softest sounds in an audio stream. The Dynamic Range Control option compresses the dynamic range so the quieter sounds are audible yet the louder sounds do not get distorted.



Q16: Should I use the Dolby Surround Downmix option?
A:
Leaving it unchecked will only decode the two main front channels, left and right. If it is checked, the center and surround channels will be encoded into the resulting wav file, but with Pro Logic encoding. This may distort the audio somewhat when played back on a non-Pro Logic capable playback system.



Q17: Should I use the 48 -> 44.1 KHz option? (aka: Downsampling)
A:
Maybe, if you are doing (S)VCD's. Read the DVD2SCVD FAQ, Q14.



Q18: Should I use the Normalize option?
A:
This is entirely up to you to decide, but it's usually a good idea.

Last edited by Cyberia; 27th February 2005 at 05:39.
Cyberia is offline  
Old 7th January 2005, 00:33   #2  |  Link
Cyberia
Moderator
 
Cyberia's Avatar
 
Join Date: Nov 2002
Location: Inside
Posts: 718
Part 4: Display Window
Q19: Why does the video seems stretched/squashed in the preview window and not show in the correct aspect ratio?
A:
Because DGIndex (DVD2AVI)'s preview window does not resize the video. All DVD's store the video as 720 pixels wide and 480 (NTSC) or 576 (PAL) pixels high. For a better explanation read Doom9's article on Aspect Ratios.



Q20: What is the purpose of the [ and ] buttons?
A:
They mark the start and stop points for the project.



Q21: Why does the video jump every time I use the < > buttons?
A:
Because the preview window only displays I-frames, which usually appear every 12th or 15th frame, so the video does indeed jump instead of moving smoothly. This is also because project files need to start with a I-frame, so DGIndex (DVD2AVI) has made it impossible to select anything but I-frames as starting points. NOTE: Versions before 1.3.0dg cannot use the < button to pass from one vob file to another.



Q22: Why do I get green blocks all over the window?
A:
You may be trying to open encrypted vobs. Decryption is not built into DGIndex (DVD2AVI), so opening vobs directly off the DVD will not work. You will need to use an IFO-parsing ripper like DVDdecrypter or SmartRipper to get the decrypted vobs to the HD before opening them in DGIndex (DVD2AVI). If you have done this, check your settings in those programs or try vStrip.



Q23: Why do I see bright random pixels in the dark areas of the picture when I have both DGIndex (DVD2AVI) and VirtualDubMod open at the same time?
A:
"Sparklies" are a display problem, not an encoding issue. The "sparklie" pixels are being treated as transparent and the underlying picture is showing through. This is most likely a Microsoft DirectX bug. Future versions of DirectX may not have this problem. More information can be found in this thread.


Part 5: Information Panel
Q24: What does video type (NTSC/FILM/PAL) stand for?
A:
See the answer to Q05.



Q25: What does the % next to video type (NTSC/FILM/PAL) stand for? (Alternatively: Why isn't there a % next to the video type?)
A:
This % represents the percentage of FILM or NTSC video in the video stream, i.e. how much of the video that has been telecined or not. FILM 95% is the same as NTSC 5%. (FILM + NTSC = 100%) If no % is shown then it means that the whole video is of the type shown.



Q26a: What does the info field tell me?
A:
  • T: Top field first video
  • B: Bottom field first video
  • V.E.: Video Error
  • A.E.: Audio Error
  • P.E.: Picture Error or Picture type Error (printed when picture type isn't I,P or B.)
  • 1: Numbers seems to be the normalization level for the audio.


Q26b: Do I need to know that?
A:
T/B is only pure information, as is any number displayed so that can usually be ignored.T/B can be interesting if you intend to filter interlaced video in AviSynth and need to sendT/B info as parameter to filter.

V.E. is more serious: that means that there is a problem decoding the picture, and may result in a lot of problems such as dropped frames, unsynched audio, blocks, etc.

A.E. Depending on what you do,A.E. will give you unsynched audio or blips in the audio, or similar. It isn't always serious, but can be quite annoying.

P.E. may result in dropped frames and unsynched audio. AFAIK it will not give blocks in the picture.


Part 6: Frameserving and projects
Q27: What versions are there of the D2V file format?
A:
V1.76 style, v1.77.3, and v1.3.0dg style. V1.76 is the most common one. V1.77.3 changed the headers but retained the same information about the individual frames. V1.3.0dg will in many cases have more frames in the D2V than the other formats and will contain far more information about the source video.



Q28: Why doesn't GordianKnot or AviSynth or... accept my .d2v file?
A:
Usually this is because you are using an earlier version of MPEG2DEC that is incompatible with the version of DGIndex (DVD2AVI) that created the .d2v project. Make sure you use a DGDecode.dll (MPEG2DECx.dll) version that is compatible with your D2V format! This is best accomplished by using the DGDecode.dll (MPEG2DECx.dll) that came with the DGIndex (DVD2AVI) or your integrated solution. If you are using DGMPGDec, remember that your AVS script must reference DGDecode.dll, NOT MPE2DEC3.dll.



Q29: Why doesn't VFAPI accept my .d2v file?
A:
First see the answer of Q28. Then make sure you used Video->Colorspace->RGB. VFAPI reads this setting to check RGB status. If you are used DVD2AVIdg to create the d2v file, then you might have to press convert twice in the VFAPI Converter to create the fake AVI. The problem is described in the readme.txt file of DVD2AVIdg.



Q30: What do the first lines of the .d2v file mean?
A:
Here's the start of a typical v1.76 .d2v
Code:
DVD2AVIProjectFile
2
45 D:\PATH\VTS_01_1.VOB
45 D:\PATH\VTS_01_2.VOB
Stream_Type=1,0,0
iDCT_Algorithm=2
YUVRGB_Scale=1
Luminance=128,0
Picture_Size=0,0,0,0,0,0
Field_Operation=0
Frame_Rate=25000
Location=0,4A2DB,0,4C401
The first line is always 'DVD2AVIProjectFile'.

The second line defines the number of video files included in the D2V project file, and equals the number of the following lines defining the location of those video files, before an empty line.

Each one of these lines is made up of 2 parts. The number indicates the length of the path name in the same line. Then we find the absolute (not relative) path of the video file. As we are counting only the number of characters defined in the beginning of the line, we can use directories and files with spaces in their names.

If we need to move the video files to another location, we can rewrite these lines using the new path, but we must change the length of the path name, or the parsing application will fail.

The files will here after be referenced with a number corresponding to the place in this list, so that the first file is number 0.

And the rest are some flags used for decoding the video:
  • Stream_Type: The four choices are (0) Elementry MPEG-2 (i.e. a M2V/MPV File), (1) Program Stream (i.e. a VOB/MPG File), and (2) Transport Stream File
  • iDCT_Algorithm: iDCT algorithm selected in DGIndex (DVD2AVI). You can override this in most DGDecode.dll (MPEG2DECx.dll) versions. (See part 3 for descriptions for each iDCT)
  • YUVRGB_Scale: PC or TV scale. PC scale uses the full 0-255 values for Y (luminance), where TV scale uses the reduced - but TV suited 16-235.
  • Luminance:Luminance controls. (not available in v1.76)
  • Picture_Size: Crop/Resize values. (not used by v1.76/mpeg2dec)
  • Field_Operation: The four choices are (0) None, (1) Force Film, (2) Raw Encoded Frames, and (???) Swap Fields.
  • Frame_Rate: Final framerate *1000 after Field_Operation. i.e. 23976 for FILM, 25000 for PAL, and 29970 for NTSC.
  • Location: used to define start and end points (as file/sector offsets) when you cut out a portion of the video.


Q31: What are all those numbers inside the .d2v file?
A:
Some typical lines of the .d2v file looks something like this:

Code:
7 0 120B 2 3 0 1 2 3 0 1 2 3 0 1 2 3
7 0 12E0 0 1 2 3 0 1 2 3 0 1 2 3 0 1
7 0 13BB 2 3 0 1 2 3 0 1 2 3 0 1 2 2
7 0 14A7 2 2 2 2 2 2 2 2 2 2 2 2 2 2
The first number is always 7, and represents a keyframe. The second number is a reference to the filenumber, as defined in the first few lines of the .d2v. The third number is the sector offset, a reference to how far into the vob DGIndex (DVD2AVI) should look for the keyframe (1 sector = 2048 bytes). The remaining numbers of the file is a reference to how the frames should be interpretated with reference to top/bottom-first (tff) display and repeated fields (rff).

Code:
trf = 2*tff + rff
0 0 0 (bottom first without repeated field)
1 0 1 (bottom first with repeated field)
2 1 0 (top first without repeated field)
3 1 1 (top first with repeated field)
A correctly telecined video should have the sequence ...012301230123...

A long list of 2's (or 0's) indicates interlaced video OR 25/30fps progressive OR a movie telecined before encoding.

(Thank's to Nic and neuron2 for the excellent explanations.)



Q32: What happens if the repeated fields sequence is not correct? (i.e. a frame with repeated field is followed by a frame with same polarity (top/bottom)

A:
DGDecode (MPEG2DECx) will switch the fields resulting in bad video. Nicepants described it like this: "I get areas where frames repeat, or it will seem that it plays a few frames & then repeats a frame from a second or so earlier." Neuron2 has written a small app that can fix this kind of problems, FixD2V. Alternatively, use his version of DGIndex (DVD2AVI) to create the D2V.



Q33: Is there an easy way of making sense of the .d2v file?
A:
Yes there is. Use neuron2's ParseD2V application.



Q34: Does DVD2AVI/MPEG2DEC Lose Frames?
shortA: Yes, unless you use DVD2AVIdg or DGMPGDec.
longA:(by neuron2 as a reply to this thread)

Leaving aside the fixed versions I recently released (see below), yes, frames are lost. This can cause serious problems with audio sync and authoring with some tools. Not only that, but random frame access is not handled correctly and incorrect frames can be returned when navigating on the timeline via MPEG2DEC (and its clones). There are three causes for the frame loss in the faulty versions.
DVD2AVI fails to flush out the final frame's digit to the D2V file before writing the 9 and closing. This causes one frame to be lost at the end.
MPEG2DEC cuts two frames from the frame count as a workaround for 3 below. This is a kludgy hack that should not be necessary. Thus, this together with 1 above, means that 3 frames will always be lost. They are lost at the end.
If the opening GOP has B frames before the first P frame (IBBPBBP...), then DVD2AVI generates an incorrect D2V file, in which the first digits for the orphaned B frames are not written and all the remaining digits are written out of place (shifted up by the number of orphaned B frames). Also, MPEG2DEC cannot decode the B frames prior to the first P frame, and so discards them. A number of frames will be lost equal to the number of B frames prior to the first P frame. They are lost at the beginning.
So, for example, if you edit a VOB and the resulting file has an IBBPBBP... opening GOP, you will lose a total of 5 frames, with 2 lost at the start and 3 lost at the end.
In addition to the lost frames, MPEG2DEC does not implement random frame access correctly. In fact it always throws away the first B frames in the seeked-to GOP prior to the first P frame. If they are (say) frames 12 and 13 (in display order) and you try to seek to 12, MPEG2DEC will toss them and return frame 14 to you, without any warning or indication about it.

Finally, when 3 above applies, the TFF/RFF flags in the D2V file are misaligned to the frames.
I have created fixed versions of DVD2AVI and MPEG2DEC3 that solve these problems. They are available at my site.
To fix these things, I started with DVD2AVI 1.77.3 and the MPEG2DEC3 from Nic's site. I rewrote the D2V file generation to be correct, even when the first GOP is of the form IBBPBBP.... I added a pop-up message box that appears if the first GOP is open. This warns that the first few frames may be decoded incorrectly.
I modified MPEG2DEC to not truncate B frames prior to the first P frame when seeking and to not unconditionally reduce the frame count by two. I rewrote the decoding and random access code to work correctly with the D2V files generated by the fixed DVD2AVI.
NOTE: Given a stream with an open first GOP, the correct frame count is returned and seeking works, but (of course) you'll get garbage for the orphaned B frames. That seemed the best thing to do. If the first GOP is closed, everything is perfect.


Appendixes

Appendix A: Collected Links

DOWNLOADS
FORUM LINKS
Appendix B: Acknowledgments
  • Doom9 for these forums and all of his greatly appreciated work in this field.
  • Jackei for creating this wonderful application.
  • Don Graft (aka neuron2), Tom Barry (aka trbarry), and Nic, for their work in developing DVD2AVI and MPEG2DEC.
  • Wilbert, manono, jorel, surreal120, nicepants and probably a lot of other people who remain unnamed.
  • Hakko for maintaining this excellent FAQ.
  • Everybody who has posted questions and suggestions that have led to an entry or correction of the FAQ.

FAQ LINK
The FAQ in RTF and PDF formats

MEGA LINK
Doom9.net - The definitive DVD backup resource
______________
/Cyberia

Last edited by Cyberia; 11th February 2005 at 19:35.
Cyberia is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:55.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.