DG NV tools

[elguaxo]

Originally Posted by hydra3333

Well, yes, spatially, although not the temporal (and probably most useful) aspect per Didee's finding ... I suspect chopping up a frame into fragments for individual threading (which is what MT does) may not be all that happy a choice in a number circumstances.

Try it with a big enough overlap. Filters like TempGaussMC for example work great with an overlap of 16.

[hydra3333]

Could do. Spatial MT can be a tad difficult to code with lots of filters, and possibly not go well with motion compensation and the likes of MDepan.

I'm hoping neuron2 may come back with some good news, as "simple" multi-threading is a direction everyone is heading.

[Clumpco]

Originally Posted by neuron2

Why would I jump on you? You've been very helpful to me in the past by your testing and reporting of issues. You're the kind of guy I want to keep real happy.

Aww gee shucks

Originally Posted by neuron2

You want DGIndexNV to output a D2V file? Hmm, that cannot be done as the formats are quite different.

OK I get that

Originally Posted by neuron2

Hasn't anybobody gotten the DGNV tools to work with those programs? I would send manono a PM. He's my johnny on the spot for anything (A)GK.

Cheers for the info, I will do.

Originally Posted by neuron2

Anyway, if you make a D2V file, that would imply you want to use mpeg2source() (the DGMPGDec source filter). What would you gain from DGNV, given that indexing is not done on the GPU?

Aha, a very valid point that I had missed (see now why I was scared of being jumped upon?)

Originally Posted by neuron2

If DGNV can't be used with (A)GK, maybe you can wean your community friends onto a more recent, still supported tool, like MeGUI, that is known to work with the DGNV stuff.

This would indeed be probably the best option.

Thanks for everything!

[LeXXuz]

I noticed some flickering in one of my latest encodes and after investigating this, I noticed a difference between DGIndex and DGIndexNV handling erroneous frames in the source material.

While DGIndex shows only a small distortion in that frame (notice the shifted macro block line in the lady's hat to the left):



DGDecNV seems to refuse to decode the rest of that frame. What is shown in the bottom part in the Avisynth preview window is the picture from where I jumped to the erroneous frame 11087:



This is what happened during frameserving this to x264. I think the rest of that frame belong to the first frame of that GOP:




EDIT: Switched Image Hoster. Pictures should work now.

[Didée]

Yesterday, by accident I found the following: (Under Windows 7,) if you have DGindexNV registered and running, then happen to install the dotNET 1.1 framework (needed to install another older piece of software), then DGIndexNV will welcome you with "invalid licence", requiring to generate a fresh license key.

Dunno if it has been mentioned before, this thread is very long.


@ elguaxo
> Try it with a big enough overlap. Filters like TempGaussMC for example work great with an overlap of 16.

Still, SetMTmode is preferable. overlap=16 is the bare minimum to avoid noticeable artifacts. Quality-wise, I'd go with 32. But that's the crux of spatial MT: the overlap is increasing the spatial area that a filter has to work on. Example:

MT() with 4 Threads, overlap 16, on 480i/p content: 20% more area
MT() with 6 Threads, overlap 32, on 720p content: 33% more area

I'm going to make some tests later, but ... 20 to 30% more frame area for MVTools to process, compared to 10-15% (15-20%) CPU usage for *CPU* decoding of 720p (1080p) streams on my i860 ... that's not a promising figure. These simple numbers suggest that the overhead of MT is bigger then what possibly can be saved by offloading the decoding to GPU.

[Guest]

EDIT: Uhm. Why are the thumbnails/links not showing???

Your links are dead. I cut them and paste into a browser and nothing shows.

[LeXXuz]

Originally Posted by neuron2

Your links are dead. I cut them and paste into a browser and nothing shows.

You're right. It seems Imagebanana has some problems. All recent uploads are blanc. However, it should work now with Imageshack.

[Guest]

Originally Posted by LeXXuz

I noticed some flickering in one of my latest encodes and after investigating this, I noticed a difference between DGIndex and DGIndexNV handling erroneous frames in the source material.

It looks like different error recovery in the decoders. Can you post a segment of the source that includes this, so that I can investigate and ask nVidia about it? Thank you.

[Guest]

Originally Posted by Didée

Yesterday, by accident I found the following: (Under Windows 7,) if you have DGindexNV registered and running, then happen to install the dotNET 1.1 framework (needed to install another older piece of software), then DGIndexNV will welcome you with "invalid licence", requiring to generate a fresh license key.

It must have changed the info returned by the system call I use. No big deal, I suppose, because you can simply make a new license.

[LigH]

Originally Posted by LeXXuz

I think it's not. MeGUI sets the wrong SAR to x264. The aspect ratio of the output is slightly too small and the picture looks slightly narrowed in width. With DGIndex everything is fine.

EDIT: It is the DAR Megui is having trouble with. Sorry for any confusion.

Just opened a 16:9 anamorphic encode and MeGUI sets DAR to 1,25 instead of ITU 16:9 PAL. As a result, x264 encoder is fed with SAR setting of 5:4 instead of 31:17 as it should.

Never feed MeGUI with a manually made script if you try to encode anamorphically. You must use the "Clever AR" feature of the integrated AviSynth Script builder. Or insert the required global AviSynth variables too:

PHP Code:

global MeGUI_darx = 16
global MeGUI_dary = 9 


[LeXXuz]

Originally Posted by LigH

Never feed MeGUI with a manually made script if you try to encode anamorphically. You must use the "Clever AR" feature of the integrated AviSynth Script builder. Or insert the required global AviSynth variables too:

PHP Code:

global MeGUI_darx = 16
global MeGUI_dary = 9 


Please read the rest of my posts. That was not the issue. I always use "Clever AR" for anamorphic encodes. However, when MeGui does not detect the correct source AR, "Clever AR" is useless as well.

[Groucho2004]

I just tried to shrink a DVD with Procoder. It crashes right away (something nvcuda.dll) when I load the script with the DGDecodeNV source filter. Works fine with the normal DGDecode.

Could this be the same problem that crashed HCEnc, Don?

[stax76]

Could also be the problem I had, opening AVS with avifile API, reading some parameters like frame rate, image size etc. and then closing without reading a frame/image, you always have to read a frame/image before you close. I don't know why but DGDecNV is the only decoder that requires this, maybe neuron2 knows more, it was easy to workaround for me, just took me a while to figure out why it was crashing all the time.

[Guest]

Could be either one. I don't have Procoder so I don't know.

[Groucho2004]

Originally Posted by stax76

Could also be the problem I had, opening AVS with avifile API, reading some parameters like frame rate, image size etc. and then closing without reading a frame/image, you always have to read a frame/image before you close.

Yes, I had the same problem and came to the same conclusion. Unfortunately, this doesn't help me with the Procoder problem.

Luckily there is DGDecode so I have an alternative, albeit a slower one.

[stax76]

Are you confusing DGSource with MPEG2Source? There is DGSource of DGDecNV, AVCSource of DGAVCDec and MPEG2Source of DGMPGDec, if you mean DGMPGDec, for SD there is not much gain since it don't take much CPU time or do you have HD MPEG-2? ffms2 is a little bit faster then DGMPGDec, it's also handy if you have a MKV container from MakeMKV or from eac3to.

[Groucho2004]

Originally Posted by stax76

Are you confusing DGSource with MPEG2Source?

No. I was referring to the names of the DLLs.

[stax76]

OK, then I was confusing something.

[Sharktooth]

Originally Posted by LeXXuz

Please read the rest of my posts. That was not the issue. I always use "Clever AR" for anamorphic encodes. However, when MeGui does not detect the correct source AR, "Clever AR" is useless as well.

When MeGUI does not detect the source AR you can specify it manually selecting the correct AR from the dropdown list (in avs script creator).

[AlekseiV]

I just bought this, and is there any way to make it crash less?
I can't analyze any files in MeGUI's script creator. The indexer works, and the AVS Script Creator opens and shows the video, but hitting Analyse nearly instantly causes a crash. It very, very rarely can get through a whole video.
If I manually set up the AVS, even loading it into MeGUI (or MeGUI x64, or StaxRip) will crash them.

I can't encode using anything but feeding a hand-made AVS into the pure x264.exe. That works great, though.

My sources are a variety of files that have nothing in common, so I'm assuming it's a problem with either DGNV or maybe my hardware/drivers.
The crash is associated with "nvcuda.dll"

(Lenovo Thinkpad W510 with a Quadro FX880M, based on the GT216, 258.96 drivers)