DGIndex vs. DGIndexNV

[Marin85]

Hi,

I am wondering about the following thing. From what I gather, DGIndex is intended for work only with MPEG-1/2 streams, while DGIndexNV is intended for usage with H.264 streams. In this regard, I have the following questions:

1) Can DGIndexNV also be used for MPEG-1/MPEG-2 streams? And, similarly, can DGIndex be used for H.264 streams? Can any of these be used for VC-1 streams as well?

2) In case both tools are complimentary, should both DGDecode.dll and DGDecodeNV.dll be placed in the Avisynth folder or does DGDecodeNV also cover the functionality of DGDecode (assuming suitable nVidia card installed)? Is DGSource() then automagically associated with the correct .dll, depending on the nature of the source?

Thanks in advance for any input!

[Guest]

DGMPGDec = DGIndex + DGDecode : supports only MPEG1/2
dgdecode.dll
MPEG2Source()

DGDecNV = DGIndexNV + DGDecodeNV : supports MPEG2, AVC (H.264), and VC1
dgdecodenv.dll
DGSource()

So you can place both DLLs in plugins without conflict.

[Marin85]

Ah, I see. Thank you for clearing that up for me, much appreciated! One last question, though. Since both tools support MPEG-2 streams, is there any reason why one should prefer DGMPGDec over DGDecNV for MPEG-2 streams (say, in terms of functionality) or vice versa? In my case, I have nVidia card and I would like to utilize DGDecodeNV for frame-serving for performance reasons. Also, if I am not mistaken, DGSource() can load and read index files created with DGMPGDec, is that correct?

[Asmodian]

I don't think DGSource() can load index files from DGMPGDec. I could be wrong, try it! ;)

Usually you prefer DGDecNV unless you do not have an Nvidia card as it uses hardware to decode, keeping the CPU free to do other things.

Edit: If you have a fast CPU and do not want to do much besides the decoding you might be limited by the speed of the hardware decoding, about ~40fps for 1080p on a VP4 card. In this case DGMPGDec could be faster.

[Guest]

VP5's are way faster but nVidia hasn't yet released a high-end card with VP5 as far as I know.

The index files are not cross-compatible.

DGMPGDec can do a few things that DGDecNV can't and vice versa. E.g., DGMPGDec supports 4:2:2 chroma while DGDecNV does not. DGDecNV can do deinterlacing and resizing on the GPU while DGMPGDec cannot. I'll ask you to read the respective documentation for more details.

[nevcairiel]

The GTX680 is a high-end card with VP5.
Pure decoding performance is around twice that of VP4 (for H264, didn't compare other formats much).

40 fps seems incredibly slow, even VP4 should be much faster then that.

[Guest]

The GTX680 is a high-end card with VP5. Ah, time for me to get one then. Also, I understand it has SM 3.0, which will require a new version of DGDecNV.

EDIT: Can't find one in stock anywhere! :(

[hajj_3]

Ah, time for me to get one then. Also, I understand it has SM 3.0, which will require a new version of DGDecNV.

EDIT: Can't find one in stock anywhere! :(

Which country are you in?

[Guest]

I'm in the USA, but why do you ask?

If someone has a GTX680 and wants to help, I can create a test build with SM 3.0 support.

[hajj_3]

apparently newegg keeps getting them in and sells out fast so you might want to refresh their website regularly.

[Rattenjaeger]

I just found this thread while trying to find a answer to my question:
DGIndex always loads the ColorMatrix.dll into the AviSynth skript to check if the color is Rec.709 and would change it to Rec.601. DGIndexNV does not check it and just leaves it?!
Is there any reason to worry about this subject? Or can I totally ignore what DGIndex does and just use DGIndexNV for MPEG2 and h.264 without worrying about this?

[Groucho2004]

DGIndex always loads the ColorMatrix.dll into the AviSynth skript
No, it does not. Unless you have configured your AVS template that way. The same goes for DGIndexNV.
Read the manual(s).