DG NV tools

[Karyudo]

I've just had a frustrating--but ultimately rewarding--experience troubleshooting an "error" while using DGIndexNV that I thought I'd document for posterity, just in case somebody else needs it.

I recently built a new Windows 7 (64-bit) machine, and installed DGIndexNV, build 2009, under 'Program Files (x86)'. I then went online and generated a license for my new machine, and added it to my 'license.txt' file using copy and paste.

After this was all done and I'd installed AviSynth 2.58 and VirtualDub 1.9.9, I tried to run an AviSynth script I'd created and run before on my old machine, and got this error:

VirtualDub Error [ <-- title of window ]

Avisynth open failure:
DGSource: Invalid license.
(\\HOMESERVER\Users\Karyudo\_Video Render Projects\final.avs, line 20)

A reboot didn't help (not too surprisingly, but one never knows with Windows...). Neither did any of the other editing of the .avs that I tried. So I contacted neuron2, who helped me troubleshoot the issue:

• DGIndexNV appeared to work fine when creating new projects, which implied that the 'license.txt' file was correct and working as it should.

• Irritatingly, everything also worked fine if I started an entirely new DGIndexNV project from the new computer, and then opened the resulting .dgi with DGSource().

• The same .avs that worked, edited to point to a .dgi created on my old machine, did NOT work. This indicated that something was wrong with my .dgi files.

After I sent off some sample .dgi files, neuron2 very quickly found my issue: The path to the license file stored in the (human-readable) .dgi was pointing to 'Program Files' rather than to 'Program Files (x86)' as it needed to be under my 64-bit OS!

Once I added those few characters, all was well. All done, and in less than 8 (overnight) hours from initial contact to successful resolution.

Moral(s) of the story? Neuron2 provides excellent support of his products... and I'm clearly sort of an idiot.

[Guest]

Originally Posted by Karyudo

and I'm clearly sort of an idiot.

Don't be too hard on yourself, because the info on that string is buried in an obscure appendix of the users manual.

Thanks for the report that may benefit others.

[Karyudo]

I'm being hard on myself because I'm usually the sort of guy who thinks, "Moron! Don't you know the info on that string is buried in an obscure appendix of the users manual??"

[Clumpco]

Originally Posted by WasF

Sorry for the lousy "report", I know how unhelpful that is, but I can't actually reproduce the error at will. 'Rather hoping to "ring some bells" maybe..
But wait; you mean with DGMultiSource() I can start two instances?! I'm missing something then, cause I use DGMultiSource() exclusively, and I always get this on second instances: Failed to create video decoder (100).
I'm admin on an XP SP3 with the latest patches, Comodo FW, Antivir Premium using a GeForce 8600 GT, Driver version 6.14.11.9621.

I think that I might have found the circumstances to re-create this error...
Build 2009 - if you encode from an DGIndexNV avs using MeGui and then leave MeGui open, when you restart DGIndexNV and open another file you get "Failed to create video decoder (100)".
Close MeGui and try again and all is fine.

Does this ring any bells for the original poster?

Incidentally I sometimes get the same error at the start of the second pass - this is relatively new but I wouldn't like to say if it is since a DGI update or a MeGui one.

[Guest]

Sounds like something for Zathor to look into as nothing has changed in DGDecNV that would account for that.

[Clumpco]

Originally Posted by neuron2

Sounds like something for Zathor to look into as nothing has changed in DGDecNV that would account for that.

Yes, smells of an unreleased file handle to me (or whatever is the equivalent for a frameserver).

[WasF]

Originally Posted by Clumpco

Does this ring any bells for the original poster?

No, I don't use MeGUI at all (I make my own .bat with x264 options, edit cuts with VDub, and build AVS Trim() instructions - and Adobe Audition's .scp script - from VDub's .vcf file using a small AWK script of my invention). I like getting my hands dirty

neuron2's explanation actually made perfect sense (lack of memory in my video card, I have 256MB).
The only issue was "corruption" of current instance when a second one was launched. But I haven't faced the issue ever since, so I'm rather thinking my system was somehow instable at the time, and this has nothing to do with DG Tools.

[tormento]

Is there a way to disable audio demux from a m2ts thru the GUI, thus creating the dgi only?

[Guest]

I could say RTFM...

Audio/Audio Demux/Clear All/Done

[tormento]

It was just a bit hidden

I was asking that as I usually transcode dts and ac3 to lower bitrates to create mkv from BD. Could be nice to interface DGNV to eac3to and let it make all the work...

[Clumpco]

Originally Posted by neuron2

Audio/Audio Demux/Clear All/Done

Feature request: Checkboxes ! Much faster than clearing/selecting when there are multiple streams.

[tormento]

If we are in the request day, I'd like a mpls parser too...

[Guest]

MPLS parsing is already on the to-do list. GUI stuff I don't get too excited about.

I'm working on next generation security to fight the serial gens and exe crackers. I want to at least make it a bit hard for them, so they get bored putting so much work into a $15 program and give up.

[Mixer73]

Originally Posted by neuron2

3. DGDecNV had PureVideo deinterlacing and GPU resizing. Unless you really need 3, there is no compelling reason to use DGDecNV *for MPEG2*.

I'm considering DGDecNV myself, honestly I should just donate for all the good works you've done, I must have done thousands of videos with your tools built into various GUIs over time.

My question is this: will the GPU decode faster than software for HD MPEG2 streams? I have an i7 965, maybe I'm just impatient but I want it to be faster in the indexing stage

[Guest]

Originally Posted by Mixer73

My question is this: will the GPU decode faster than software for HD MPEG2 streams? I have an i7 965, maybe I'm just impatient but I want it to be faster in the indexing stage

Indexing does not use the GPU, so it can provide no boost. Decoding alone will likely not be faster on the GPU.

Possible gain comes from transcoding (decoding plus encoding), not simply decoding, as described several times. Offloading decoding to the GPU can free up CPU for encoding.

But any performance gain is secondary to the other advantages, also described several times: reliable random access, GPU deinterlacing, GPU resizing/cropping, correct decoding of AVC and VC1, consistent integrated solution to AVC/MPEG/VC1.

[tormento]

Originally Posted by neuron2

But any performance gain is secondary to the other advantages, also described several times: reliable random access, GPU deinterlacing, GPU resizing/cropping, correct decoding of AVC and VC1, consistent integrated solution to AVC/MPEG/VC1.

One of the feature I used most is GPU deinterlacing.

One of the feature I need most is GPU denoising which is a killer for CPU but should be easily parallelized with CUDA or so. Film grain is something abused that increase bitrate for free.

Neuron: do you have the skills to implement some advanced noise filters such as MCTD or MDegrain into DGNV?

[Renzz]

I've hit a problem using dgindexnv 2009 trying to index a particular MPEG2 TS file. It's reporting "malformed GOP" (twice, then it stops), however, if I run the same file through dgindex, it indexs it fine. For what it's worth, Videoredo also reports no errors in the stream, either when editing it or using QuickStreamFix.

I've cut the offending part out and it can be found at http://www.mediafire.com/?y5j2nziqmgj . It would be good to know if this is a bug in dgindexnv, or a real corruption in the stream that the other tools miss.

Thanks in advance.

[Guest]

Originally Posted by Renzz

I've hit a problem using dgindexnv 2009 trying to index a particular MPEG2 TS file. It's reporting "malformed GOP"

It's caused by GOPs like this:

SH
GOP
I
B
B
P
B
B
P
B
B
SH
P
B
B

It's unusual to have a sequence header (SH) appear before a P frame like that within a GOP. I detect boundaries for sorting into display order using the SHs in DGIndexNV, while in DGIndex I use the I frames (can't remember why I changed that). I actually have an old scribbled note here warning about this but I didn't worry because I never saw this in the wild. I'll have to change it to use the I frames as in DGIndex. It may take a few days.

Thanks for your report.

[Renzz]

Thanks for the quick response, it's much appreciated.

[Renzz]

Originally Posted by Clumpco

Yes, smells of an unreleased file handle to me (or whatever is the equivalent for a frameserver).

I too get the "Failed to create video decoder" error intermittently using MeGui. It's much worse using dgmultisource, but less frequent when using Cuvidserver. I originally put this down to my ancient Nvidia card (8600 with 256MB) but I recently installed a 9800GT with 1GB of memory - but I still get the problem. It's also worse when your source is H264, and almost non-existant when it's MPEG2.

MeGui is definitely holding onto something - if you run GPU-Z and monitor memory usage of the GPU, you can see that whenever you open the AVS in MeGui, memory goes up, but is never fully released. However, I only ever get to around 400MB before hitting the problem, so it must be some other resource issue. Odd that it's worse with DGMultiSource as opposed to Cuvidserver - I would have expected them to be the same, maybe?