DG NV tools

[Fotis_Greece]

It's already 258.86, I thought it was meant as I just yesterday downloaded it and installed it.
I will try uninstalling and reinstalling the drivers and come back to you.

[Fotis_Greece]

I uninstalled, redownloaded and installed again. Unfortunately the same error comes again.
Any idea?

[Guest]

First, regenerate your license with the machine ID currently reported by DGIndexNV.

Second, use GPU-Z to check your memory usage before starting DGIndexNV.

Third, are you just opening DGIndexNV directly or trying to use a 3rd party GUI?

Fourth, try build 2024. There is always a chance I hosed up something in 2025, though it works for me.

Fifth, does DXVA work properly?

If it remains a problem, I will make a debug build for you this evening.

[Fotis_Greece]

Thanks for the tips, I regenerated the license file and now everything works perfect.
What has the license file to do with the gpu decoder???

[Guest]

It triggered an anticracking mechanism. You should have gotten an "invalid license" error popup, though. I will look into why that did not happen.

[mastrboy]

having some "issues" with audio after demuxed by DGNVIndex, eac3to reports the following: "This track is not clean" and trying to encode it with FFAudioSource just fails with "unable to open ...", NICAudio also fails at some point.

The audio file is a AC3/TrueHD from a m2ts blu-ray disc.

Mediainfo on the demuxed file:

Format : AC-3
Format/Info : Audio Coding 3
Format profile : TrueHD / Core
File size : 509 MiB
Duration : 2h 38mn
Overall bit rate : 448 Kbps

Audio
Format : AC-3
Format/Info : Audio Coding 3
Format profile : TrueHD / Core
Mode extension : CM (complete main)
Muxing mode : After core data
Duration : 2h 38mn
Bit rate mode : Variable / Constant
Bit rate : Variable / 448 Kbps
Maximum bit rate : 4 800 Kbps / 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 509 MiB (100%)


After it has been demuxed it reports Duration: 2h 38mn, but the audio is really only 20,9min...

[Guest]

Please post a sample of the m2ts cut with DGSplit that I can use to duplicate the issue. Please provide full instructions for how to duplicate the issue *with the sample you give me*. Thank you.

[mastrboy]

Please post a sample of the m2ts cut with DGSplit that I can use to duplicate the issue. Please provide full instructions for how to duplicate the issue *with the sample you give me*. Thank you.

Sample: http://www.mediafire.com/?z9nhougxo59qu54

Process to replicate issue:
- Start DGIndexNV.exe 32bit 0.25
- Press F2 and select m2ts file
- Answer "NO" to cropping question
- Activate cropping on LEFT and RIGHT, value=240 on both
- Press F4 to save project
Result: weird behavior on AC3 files

By the way, the autocrop buttons totally fails, pressing autocrop to mod16 results in the following:
http://img13.mediafire.com/c06b0382cd893df3fcba8b1bc7cf69ab4g.jpg

[Guest]

Thank you. Can you please also give me the eac3to line that gives the error you mentioned?

[mastrboy]

Sure, you need the nero aac encoder in the same directory as eac3to. eac3to still encodes the file, but reports "This track is not clean".
- eac3to.exe track1.ac3 track1.m4a

[Guest]

Autocrop works fine on your sample. Did you try it?

I will wait to look at the audio problem until you assure me the reported problems happen *with the sample you uploaded*.

Also, can you please give me the command line to demux the track using eac3to so that I can do a binary compare? Thanks.

[Guest]

Using your sample, I demuxed PID 1100 using Manzanita Muxer and DGIndexNV. The resulting files were binary identical.

Please advise.

[Shevek]

By the way, the autocrop buttons totally fails, pressing autocrop to mod16 results in the following:...

You need to find a frame in the video which has the most contrast between the black bars and content, i.e. as much white as possible.

If you try to autocrop on the first (usually all black) frame it will crop all of it and give you the result you saw.

[mastrboy]

Using your sample, I demuxed PID 1100 using Manzanita Muxer and DGIndexNV. The resulting files were binary identical.

Please advise.

Well i forgot to include some information, after checking it out i remember i cut the original within DGNVIndex so that the OP and ED of the episode was cut out and only the episode itself remained.

So it only happens of you change start and end in DGNVIndex, example output from eac3to:

X:\Video_Encoding\Apps\eac3to-3.24>eac3to.exe x:\test_cut_track.ac3 x:\del.m4a
AC3, 5.1 channels, 0:00:45, 448kbps, 48kHz, dialnorm: -29dB
The Nero decoder doesn't seem to work, will use libav instead.
Removing AC3 dialog normalization...
Decoding with libav/ffmpeg...
Remapping channels...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.50> with NeroAacEnc...
This track is not clean.
eac3to processing took 1 second.
Done.

X:\Video_Encoding\Apps\eac3to-3.24>eac3to.exe x:\uncut.ac3 x:\del.m4a
TrueHD/AC3, 5.1 channels, 48kHz, dialnorm: -29dB
(embedded: AC3, 5.1 channels, 448kbps, 48kHz, dialnorm: -29dB)
Extracting TrueHD stream...
Removing TrueHD dialog normalization...
Decoding with libav/ffmpeg...
Encoding AAC <0.50> with NeroAacEnc...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 1 second.
Done.

See image so there is no misunderstanding:
http://img14.mediafire.com/d9f4dc59c5f0691874319985b73e13be5g.jpg

The auto-crop "issue" only happened when on the first frame, i assume that is because the entire first frame is pure black?

Edit: and yes, the audio issue also occurs on the sample i sent. The eac3to output above is from the sample.

[Guest]

Yes, you must navigate to a frame showing a distinction between the video and the black bars, because the software scans in from the edge looking for the first non-black pixels. The users manual says this:

"For best results, navigate to a frame with high contrast between the video and the black bars before entering the cropping dialog."

A fully black frame will have rather low contrast. ;)

Regarding the audio issue... You cut the sample you gave me or you cut from a larger sample? If the latter, then I'll need that larger sample, please.

[mastrboy]

i cut from the sample i gave you.

[LigH]

I decided to give ivfenc a try and make some WebM video. Downloaded the Blender movie 1080 PNGs (ED: 21 GB / BBB: 30 GB), created an AviSynth script with ImageSource ... but the reading of the source PNGs was already the slowest part of the recoding. So I created intermediate AVC files with very low compression and then used DGDecNV to read those as "good enough semi-original" to be delivered to ivfenc.

Funny result: For each of the 2 passes, I got a Windows XP error message that the encoder crashed, but it kept running and finished with an acceptable result. The console window (I called a "start *.bat" command for a batch file running both passes in a row) closed after closing both crash dialogs.

Is that related to the issue e.g. stax76 mentioned - about "programs which open AviSynth scripts only briefly and close them without reading even one frame" which seems to crash one instance of DGDecNV?

[Guest]

Is that related to the issue e.g. stax76 mentioned - about "programs which open AviSynth scripts only briefly and close them without reading even one frame" which seems to crash one instance of DGDecNV? Hard to say. It could be, or they could be using Avisynth incorrectly like we fixed in HCEnc. Or it could be some new bug unique to what they are doing. Without their source code it's hard to say. Is the code available?

@mastrboy

OK, thank you. I will try to duplicate it.

[Groucho2004]

Is that related to the issue e.g. stax76 mentioned - about "programs which open AviSynth scripts only briefly and close them without reading even one frame" which seems to crash one instance of DGDecNV?

It appears to be a common problem. For example, Procoder 3 and CCE 2.7 crash as well. I only fixed this recently in my programs that process scripts after I started using DGDecodeNV.

Apparently, nobody seems to know if this is a problem with Avisynth, DGDecodeNV or the Nvidia API.

[Guest]

It appears to be a common problem. For example, Procoder 3 and CCE 2.7 crash as well. I only fixed this recently in my programs that process scripts after I started using DGDecodeNV.

Apparently, nobody seems to know if this is a problem with Avisynth, DGDecodeNV or the Nvidia API. It should be possible to debug it with the source code for all the pieces. If somebody can give me source for a simple app that invokes the problem I can at least determine if it is in Nvidia or not. If not, then we could fix it. If it's in Nvidia, we could contact them. My problem is I don't have a simple app that invokes the issue. Don't even mention .NET to me. :)

[LigH]

I believe Nic has the sources available for his AviSynth mod of ivfenc.

And stax76 mentioned that something happened to him too because he used to open the Script in StaxRip only to obtain the dimensions and frame count first. But when not reading even one frame, and closing, DGDecNV used to crash ... if I remember correctly.

[Groucho2004]

It should be possible to debug it with the source code for all the pieces. If somebody can give me source for a simple app that invokes the problem I can at least determine if it is in Nvidia or not. If not, then we could fix it. If it's in Nvidia, we could contact them. My problem is I don't have a simple app that invokes the issue. Don't even mention .NET to me. :)

VC6 project here: Here (http://www.iol.ie/~schubert/AVSInfo102.zip)

Set your breakpoint on "delete env;" at the end of _tmain.

If you want to reproduce the problem, comment out these lines:

"frame = clip->GetFrame(0, env);" (line 63)
and
"frame = clip->GetFrame(i, env);" (line 68)

Have fun :)

[Guest]

You should not be doing delete env!

That is the big no-no that we fixed in HCEnc and elsewhere.

I'll look at it though and see if anything else is going on. Thanks for providing it.

[Groucho2004]

You should not be doing delete env!

That was actually not supposed to be there. Too much experimenting...

Edit: Funny thing is - now I can't reproduce it anymore.

[Guest]

I'm a :helpful: that gets lucky now and again.

BTW, just looking at the CUVID API and knowing from experience what I do about the behavior of CUVID I can't even imagine a mechanism by which this could be caused by the CUVID code.

[Groucho2004]

I'll send you a program with which you can reproduce the problem later.

I just checked and double-checked. I wasn't dreaming after all. :rolleyes:

[Groucho2004]

Don, check your inbox.

[Sharktooth]

ok, probably found a bug. Source: MKV file with x264 video and Vorbis (aoTuV b5) audio. DGIndexNV (2025) correctly indexes the MKV but even if the option is set it doesnt demux the audio.
mkvextract correctly extracts the audio track. is it a known problem or you need a clip?

[Guest]

@Groucho2004

Thanks. Investigating...

@Sharktooth

I never saw Vorbis audio and would have to add support, so if you can provide a clip it would be helpful.

[Sharktooth]

sure. ill upload it as soon as i finish sending the list (it may take a while... about 32.000 emails)

[tormento]

Which avisynth filters do you think is better to apply after a deinterlace=2 (bobbing) to convert from a 60i (60p by bobbing) to a 30p, retaining as much details as possible? Don't know how the Nvidia bobbing works when "espanding" temporal resolution.

[Guest]

Hmm, good question.

I don't think you can do much better than simply SelectEven() or SelectOdd(). You may want to check them to see which is better, because sometimes sources have artifacts limited to, or more prevalent in, one field.

But also, have a look at simply using deinterlace=1, i.e., not bobbing.

I'm always open to be corrected by Didée, of course. :)

[tormento]

I have read lot of docs about 60i interlacing and doing a deinterlace=1 is a no-way as you discard half frame of information. Unless NVIDIA provides a smarter way of deinterlacing. I suppose you should ask your "informer" ;)

[Guest]

Bobbing followed by SelectEven() will also lose half the temporal resolution. I don't see anyway to avoid it.

[Didée]

Of course you cannot have 60Hz information in 30Hz progressive frames. Except for simple field blending, but nobody really wants that. (Hopefully.)

So far I've only had a brief look at Nvidia's deinterlacing. After checking with a few of my standard test samples, I quickly lost interest. Sure it is fast, but that's about it. Quality-wise, I can't see any particular magic in there; it's about in the same league as tdeint/yadif/etc. When you want blazing speed, then it's for you. When you aim for maximum detail/stability (and inherently, compressibility), then it's no replacement for TGMC. Which is still in a leage of it's own - regarding the result:), as well as as the needed CPU-time:(.

[Guest]

then it's no replacement for TGMC. Which is still in a leage of it's own Of course TGMC is the quality champ! Nobody's claiming PV as a replacement for TGMC. It's just a useful sweet spot for the quality/performance tradeoff, as you say.

[Didée]

But I had hoped that Nvidia would pull a little more out of the hat. It's not easy to get deeper information, however the video engine generally offers 3 ways of deinterlacing: "spatial", "temporal", and "vector adaptive". Spatial probably is a simple interpolator, temporal probably is interpolation with weaving acc. to some kind of usual motion-check. vector adaptive could be like temporal, by using source's motion vectors to judge if there "is" or "is not" motion. I'm pretty sure that no kind of active motion compensation is used: the results simply do not look like that.

Sample for demonstration is encoding right now. Check in a few minutes.

[Guest]

I thinks it's a relatively simple EDI, but I could be wrong. We can ask Nvidia about it, but it may not be something they want to discuss.

[Didée]

Quite possible. As long as the curtain isn't pulled, the illusion can persist there would be something special underneath.:D - Still, asking wouldn't hurt ... perhaps someone has a weak moment and actually leaks some insight.
Also, what I gathered from the internet: the video engine automatically uses the "highest" method, according to the capabilities of the card, as well as the actual content. Particular example: the GT220/240 is said to use "vector adaptive" deinterlacing only up to SD resolution, but for HD resolution it uses only "temporal" deinterlacing. Such behaviour is understandable, given that the usual application is realtime-playback. Though, for offline processing it could be interesting if it were possible to choose the deinterlacing method to liking. If you contact Nvidia again, maybe you could ask about that, too.

Okay, the comparison ...

Here's a quickly produced sample, from a realworld source: "Lord of the dance", native PAL DVD. To demonstrate clearly, the content was first bobbed, then upscaled 200% with pointresize, and slowed down from 50fps to 12.5 fps. Just to make it easy to see what's really going on.

<sample> (http://www.mediafire.com/?i7znn4nfpvr8nwe) (MediaFire, ~9 MB)

Three of them are more or less about the same. Hard to tell why one of the three should be preferable to the other two. They are exchangeable.

Hence ... if you're in a hurry, then it doesn't matter too much which one you pick. When calling for quality even if it takes longer, then there's not much of a choice.

[hydra3333]

My goodness, that is rather confronting as a demonstration. Is there a link to the latest TGMC which you use ?

[Guest]

Good news. I have found and fixed the dreaded "crash if you don't get a frame bug".

It was a race condition between CUDA init and the destruction of the filter instance. Putting a frame fetch in there gave CUDA long enough to finish initializing before the application deinstantiated the filter. I've mitigated that in DGDecodeNV.

Will test a bit more and then release. Hopefully it will make DGNV work with CCE, Procoder, etc.

Thanks to Groucho2004 for providing the simple test app I used to recreate the crash.

[lych_necross]

I have a quick noobish question: does TGMC == TempGaussMC?

[tormento]

Didée, Neuron2, please keep us informed about your VP deinterlacing. Are NVIDIA GPUs capable of some noise reduction too or other video manipulation in hardware? DGNV is such a useful program that some other features would be welcome ;)

[LigH]

@ lych_necross: Yes. The exact source might be important, though...

[stax76]

It was a race condition between CUDA init and the destruction of the filter instance. Putting a frame fetch in there gave CUDA long enough to finish initializing before the application deinstantiated the filter. I've mitigated that in DGDecodeNV.

That explains the arbitrary behavior it had.

http://forum.doom9.org/showthread.php?p=1417168#post1417168

[Guest]

* Fixed a race condition between CUDA init and filter deinstantiation that could cause
a crash when DGDecodeNV is instantiated and then deinstantiated without a call
to GetFrame(). Some third-party applications do that to get the video clip properties
returned by an Avisynth script.

http://neuron2.net/dgdecnv/dgdecnv.html

[Guest]

Are NVIDIA GPUs capable of some noise reduction too or other video manipulation in hardware? DGNV is such a useful program that some other features would be welcome ;) Sure they are capable of it but these things are not currently exposed in the CUVID API.

Since I now know how to write postprocessing functions that run on CUDA (I use it for the NV12->RGB conversion in DGIndexNV), I could contemplate writing some filters. At first, spatial only. Would you like to suggest any specific spatial denoising algorithm that I could implement?

[LigH]

Surely a "median" filter would be useful, and possibly rather simple to implement (hopefully).

a) "careful" method: capping a value to the range of the direct neighbors except self (not exactly the meaning of the term "median", but often used in filters with such a name)

b) "strict" method: setting a value to the middle value of the sorted list of self and neighbor values (the mathematical meaning of the term "median", but with stronger effect and "plateau" side effects)

[Guest]

Do you think a 3x3 kernel is sufficient?

[LigH]

Hmm ... well ... in general yes. But GPUs may have enough power to try a 5x5 kernel too. But they will have side effects, that can get quite heavy. I used Median with 5x5 kernel to simulate mesas in Terragen (the statistical filters in the "SOPack" are based on my suggestions to its author).