|What is DGDecode?||Table of Contents|
DGDecode, part of the DGMPGDec package, is an MPEG-1/2 decoder plug-in designed for AviSynth v2.6 or higher and Avisynth+. It's able to decode any MPEG-1 or MPEG-2 stream readable by DGIndex. Additional features include: YV12, I420, and YUY2 colorspace output (and RGB24 via DGVfapi), optimized iDCTs, post-process deblocking and deringing, luminosity filtering, and more!
DGDecode is based on MPEG2Dec3 v1.10, which itself is based on MPEG2Dec2 from the SourceForge project "save-oe".
Important Note: This filter was renamed to DGDecode to avoid naming confusions and to clearly link it with DG's version of DVD2AVI called DGIndex. DG wants to take great pains to acknowledge the origins of DGDecode as described by MarcFD in the text below! Yes, DG has continued the evolution and made some fixes, but he stands on the shoulders of the giants documented below in the Credits section.
You can get the latest binaries and source code of DGMPGDec at http://rationalqm.us/dgmpgdec/dgmpgdec.html
This is free software distributed under the terms of the GNU GPL v2 license. You must agree to the terms of the license before using the plug-in or its source code. Please see the License section for details.
|Filter Syntax||Table of Contents|
|MPEG2Source()||Table of Contents|
MPEG2Source(str "d2v", int "idct", int "cpu", bool "iPP", int "moderate_h", int "moderate_v", str "cpu2", int "upConv", bool "iCC", bool "i420", int "info", bool "showQ", bool "fastMC")
|LumaYV12()||Table of Contents|
LumaYV12(clip, integer "lumoff", float "lumgain")
Y = (y * lumgain) + lumoff
|BlindPP()||Table of Contents|
BlindPP(clip, int "quant", int "cpu", bool "iPP", int "moderate_h", int "moderate_v", str "cpu2")
|Deblock()||Table of Contents|
Deblock(clip, int "quant", int "aOffset", int "bOffset", bool "mmx", bool "isse")
|Usage Examples||Table of Contents|
|AviSynth LoadPlugin() Example||Table of Contents|
LoadPlugin("[PATH\]DGDecode.dll")Note: PATH can be ignored if DGDecode.dll is in the default AviSynth plug-in directory, otherwise PATH must be specified.
|MPEG2Source() Examples||Table of Contents|
MPEG2Source("[PATH\]project.d2v")Note: PATH can be ignored if "project.d2v" is in the same directory as your AviSynth (*.avs) script.
MPEG2Source("project.d2v", cpu=4, iPP=true, moderate_v=20)
MPEG2Source("project.d2v", idct=5, i420=true)
|LumaYV12() Examples||Table of Contents|
|BlindPP() Examples||Table of Contents|
BlindPP(cpu=4, iPP=true, moderate_h=10)
|Deblock() Examples||Table of Contents|
Deblock(quant=32, aOffset=16, bOffset=24)
|APPENDIX A: BlindPP() Notes||Table of Contents|
Blocks result from the 8x8-pixel DCT used by the MPEG encoder. So first, you must be sure that the blocks that you want to deblock are still aligned at 8-pixel boundaries. That means no cropping and no resizing before you apply BlindPP(). If your source is encoded interlaced, set iPP=true, if it's progressive then the default is already correct (iPP=false).
The parameters are: quant, cpu2, moderate_h, and moderate_v.
quant specifies the overall strength at which the deblocking process is to perform.
Set cpu2 to "xxxxoo" for horizontal and vertical deblocking on luma and chroma, to "xooxoo" for horizontal luma and vertical chroma deblocking, etc. You get the idea.
moderate_h and moderate_v specify the horizontal and vertical sensitivities, that is, where to perform deblocking, and where not to. They control the sensitivity for recognizing that a block is present.
quant=2, moderate_h=35-45, moderate_v=45-55 will give you a very gentle softening on strong, clearly visible blocks only. It will retain very much detail and sharpness, but will also leave intact weaker blocks, and not totally kill stronger ones.
quant=16, moderate_h=15-20, moderate_v=20-30 will perform rather strong deblocking on almost anything that perhaps could be a block, but will also smooth away a lot of detail and sharpness.
The rest is up to you, your taste, and your source material.
One other example... Since the excellent denoiser PixieDust() may sometimes cause blocking by itself in moving areas, I sometimes do this:
PixieDust(2).BlindPP(quant=8, cpu2="xxxxoo", moderate_h=45, moderate_v=55)
This takes away a good amount of the most visible blocking, if and only if PixieDust() has produced some. On the remaining 99.8% where PixieDust() didn't block, this will do almost nothing, as desired.
|APPENDIX B: iDCT Algorithm Notes||Table of Contents|
The FlasKMPEG readme file contains an excellent technical description of iDCTs. It states:
"The video information inside MPEG files is stored in the frequency domain rather than in the spatial domain (the images we see). That way, the information gets compacted and that compaction can be used to compress (reduce) the amount of information you have to send over the transmission channel. MPEG uses the DCT (Discrete Cosine Transform) to translate spatial information into frequency information. To bring back the spatial information from the MPEG stream you have to apply the iDCT, that is, the Inverse Discrete Cosine Transform, that undoes the DCT that was used during encoding."
"Although MPEG is almost deterministic (given a MPEG stream the output should be identical in all decoders), the standard has a degree of freedom when choosing the iDCT to use. That way, the decoder can be more easily implemented depending on the hardware below it. What the standard requires from the decoder is that the iDCT meets IEEE-1180 specs, or in plain words, that the error from the iDCT doesn't go beyond that the ones pointed out in the IEEE-1180."
Which iDCT you should use depends primarily on what CPU you have and to a lesser degree, on how accurate an iDCT you desire. Most people will not be able to tell the difference in quality between these algorithms but they can be easily observed by combining the AviSynth filters Subtract() and Levels(). All of the available options are IEEE-1180 compliant, except for SSE/MMX (Skal).
Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD) > Remaining iDCTs.
Speedwise: SSE2/MMX and SSE/MMX (Skal) are usually the fastest. The IEEE-1180 Reference is easily the slowest.
|APPENDIX C: SIMD Instructions||Table of Contents|
SIMD is an acronym for Single Instruction, Multiple Data. It is a term that refers to a set of operations for efficiently handling large quantities of data in parallel. This is especially productive for applications in which video or audio files are processed. What usually required a repeated succession of instructions can now be performed in one instruction.
There are seven different sets of SIMD instructions available to Intel and AMD processors, but not every CPU supports all of these advanced instruction sets. This is why many of DGDecode's functions provide options for specifying which set of optimizations to use. The table below lists the SIMD instructions supported by DGDecode, and the processors required utilize them.
|Required Intel CPUs||All Intel CPUs||Unsupported by Intel CPUs||Pentium 3, Pentium 4||Pentium 4|
|Required AMD CPUs||All AMD CPUs||All AMD CPUs||Athlon XP, Athlon 64||Athlon 64|
|Credits||Table of Contents|
|License||Table of Contents|