DG NV tools

[Guest]

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

Please note that the DG NV tools require a supported Nvidia graphics card. Also note that the DGNV tools are not free; a small donation is required as described at the link above.

[Turtleggjp]

Looks like pulldown flags in progressive streams are not properly supported yet. Will you be able to support these as well in the future?

[Guest]

Looks like pulldown flags in progressive streams are not properly supported yet. Will you be able to support these as well in the future? Sure. Can you post a link to a sample? I may find one in my collection of test files, but if not, it will be helpful to have yours.

[Turtleggjp]

uploading a sample now. This is a good one, it has both single and double repeats (according to the .d2v file created by DGIndex), and it causes Beta3 of DGMPGIndexNV to generate combing artifacts.

EDIT: Here is the link: http://www.mediafire.com/?sharekey=3abf0b101b3952f007258ee67c679e4ae04e75f6e8ebb871

[Guest]

I updated beta 3 to support it, so please redownload it to get the changes. Please advise on your results.

[Turtleggjp]

My test clip looks good now. I take it I need to re-index my files again after this change. I am now indexing the entire 2 hour capture file, and if it looks good I'll run a pass through x264 and see how it comes out. Thanks for fixing that so quick!

EDIT: BTW I noticed that the de-interlacing bug I pointed out before is still there. Is this going to take an updated Nvidia driver to fix (or rather, the problem is not with your program)?

[Demn]

I know I haven't responded to any previous NV tools threads, but I've been excitedly testing them out myself for some time. I really appreciate your work.

Moving on from that, I have an anime mpeg-2 vob source that was previously not providing correct timing in it's dgm with pulldown flags ignored (compared to audio stream and the d2v project file). Now with pulldown flags honored the timing seems right on with audio. However, I get this nVidia PureVideo deinterlacer (what I see as the neatest part of DGMPGIndexNV) error now:
DGSource: Cannot use PureVideo deinterlacer with field repeats.
My AVS is simple:
LoadPlugin("C:\...\DGDecodeNV.dll")
DGSource("anime.dgm",deinterlace=1)

Will the deinterlacer have issues with certain video streams? I have not tested another interlaced mpeg-2 source yet, I will get around to that eventually. This source is admitedly a very ugly NTSC source.
BTW, If you already explained this problem I'm very sorry for wasting your time, as I love your work and know you're busy.

[Guest]

I have an anime mpeg-2 vob source that was previously not providing correct timing in it's dgm with pulldown flags ignored (compared to audio stream and the d2v project file). Now with pulldown flags honored the timing seems right on with audio. Great. That was the point of implementing it, so it's reassuring to know that it is working.

However, I get this nVidia PureVideo deinterlacer (what I see as the neatest part of DGMPGIndexNV) error now:
DGSource: Cannot use PureVideo deinterlacer with field repeats.
My AVS is simple:
LoadPlugin("C:\...\DGDecodeNV.dll")
DGSource("anime.dgm",deinterlace=1)

Will the deinterlacer have issues with certain video streams? I have not tested another interlaced mpeg-2 source yet, I will get around to that eventually. This source is admitedly a very ugly NTSC source. OK, let's break it down. Field repeats can be used only on progressive video. It is not correct to apply a deinterlacer to progressive video. Instead you should recover the original progressive frames, either by ignoring the pulldown or via an external IVTC (inverse telecine) operation.

Anyway, NVCUVID leaves pulldown to the display process, which comes after the deinterlacing, so it would not be possible to honor the pulldown and then deinterlace the pulled-down frames.

So, let me throw this back at you. Why are you deinterlacing a progressive video? A sample of your unprocessed source will be very helpful in understanding your case.

It may be a case where we need a forced film mode, but I can't tell until I see your source material.

[Demn]

OK, let's break it down. Field repeats can be used only on progressive video. It is not correct to apply a deinterlacer to progressive video. Instead you should recover the original progressive frames, either by ignoring the pulldown or via an external IVTC (inverse telecine) operation.

Anyway, NVCUVID leaves pulldown to the display process, which comes after the deinterlacing, so it would not be possible to honor the pulldown and then deinterlace the pulled-down frames.

So, let me throw this back at you. Why are you deinterlacing a progressive video? A sample of your unprocessed source will be very helpful in understanding your case.

Ah that makes sense I guess x.x Didn't realize it was progressive. Looked pretty interlaced. Anyway here's a clip from it (http://www.megaupload.com/?d=REOAAX3T) with a bit of motion (pans between comic strips).

[Guest]

OK, it's field blended. Deinterlacing field blended video is a last resort solution. You can do a search on "blended fields" to find alternative approaches for restoring the progressive source. I don't get into that because I vomit every time I see such things. I prefer to keep my food in my stomach. :) Still, you could repost your sample in the Avisynth Usage section and there are lots of people there that get their jollies from fixing field-blended video. A longer clip with maximum motion will be preferred.

Bear in mind that true interlaced animation is very rare. Some CGI does it, but hand drawn animation is drawn as frames, not fields, so it is progressive. The problem with your source is that it has gone through a field-blending standards conversion.

[Guest]

EDIT: BTW I noticed that the de-interlacing bug I pointed out before is still there. Is this going to take an updated Nvidia driver to fix (or rather, the problem is not with your program)? It's not clear yet. I have been in discussion with Nvidia and they cannot duplicate it while I cannot find any issue in my code. So investigation continues. I still think it is an Nvidia problem but I have to find a way to prove it one way or the other.

[rack04]

I have noticed that DGIndex and DGIndexNV report different audio delays. For example:

DGIndexNV:
20090622213601 PID 088 3_2ch 48KHz 384Kbps DELAY 0ms

DGIndex:
20090622213601 PID 088 3_2ch 384Kbps DELAY 32ms

Here is a sample:

http://www.megaupload.com/?d=7QWXX4SA

[Kurtnoise]

Don, any chance to have min/max/avg bitrate values into the dga/dgm/dgv files ?

:thanks:

[Turtleggjp]

It's not clear yet. I have been in discussion with Nvidia and they cannot duplicate it while I cannot find any issue in my code. So investigation continues. I still think it is an Nvidia problem but I have to find a way to prove it one way or the other.

Thanks for continuing to look into it. I know you said before you were having trouble getting deinterlace=2 to work, when you said:

Both instances returned the same field, so I wrote to Nvidia about it. It may be a CUDA bug.

And since it does show problems when using "use_top_field=false" I would think it would be easy for Nvidia to reproduce. Unless of course you're doing some kind of special tricks to get "use_top_field=false" to work.

I re-indexed my 2 hour long clip, and it appears to be handling the repated frames correctly, since the trim commands in my script now produce what looks to be a perfectly edited clip. Previously, when I opened the clip, the first frame was a few seconds into the episode. As far as I know, there are no repeated frames during the episode, only during the commercials (like the sample clip). So I don't think it's worth re-encoding the whole thing for testing purposes. Soon, I'll try with some of my 1080i shows that do have pulldown during the episode. Thanks again!

Matt

[Guest]

Don, any chance to have min/max/avg bitrate values into the dga/dgm/dgv files ?
It's in the log file already. Is that not enough?

[Kurtnoise]

Well, logfile can be disabled. It's just that could be great to have such extra infos into them (ex: for a parser)...



me and my random ideas you know. :p

[lansing]

when i try to use the same dga file for 2 instances in Avsp, Avsp and CUVID server both froze.
the server can only run one file at a time?

[Guest]

That is correct. You can have only one instance of DGSource().

[Guest]

It's not clear yet. I have been in discussion with Nvidia and they cannot duplicate it while I cannot find any issue in my code. So investigation continues. I still think it is an Nvidia problem but I have to find a way to prove it one way or the other. In the process of investigating, I upgraded to Nvidia driver 186.18 and let my tools use the nvcuvid.dll installed by the drivers, rather than the one I ship, and I find that it works fine now. Please try that and advise whether it now works correctly for you too.

[Turtleggjp]

Looks good here now. Took a little effort, since the latest drivers for my laptop's card (9650m) are only 185.85, and they cause all kinds of problems. Asus (maker of my laptop) doesn't even list these drivers on their website. They only have 179.30 listed, and so far these have worked just fine for most things (CoreAVC's CUDA acceleration doesn't work at all with this driver, and it performs terribly with the 185.85 driver). I was able to install the 186.18 drivers on my main system which has a GeForce 7600GT and is running Windows 2000. Not exactly a good system for running your tools, but I was able to snatch the nvcuvid.dll file from the system folder and copy it over to my laptop. My test clip looks good, and I'll give the full episode a run through as soon as I can get the full clip ready to go again. Give Nvidia a big thank you for me!

Matt

[Guest]

You'll also need to re-download NVbeta3.zip and update the DGDecodeNV.dll. I found a bug that caused the clip to hang at the half way point when deinterlace=2.

http://neuron2.net/misc/NVbeta3.zip

[lucassp]

Do you know if nVidia fixed the MPEG2 Deinterlacing problems people reported around here? Thanks!

[Guest]

Yes. Please read this *entire* thread starting from here:

http://forum.doom9.org/showthread.php?p=1299326#post1299326

[laserfan]

Could someone please take a look at the .h264 snippet below (11Mb) and tell me if the source is corrupt somehow (I can't see any problem), or if it's my system that's not decoding it properly. On opening/preview I see a visual glitch at what appears to be the 3rd or 4th I-frame in, just as the MGM lion appears and is about to growl.

At first I used DGAVCIndexNV 1.0.14 beta 4, with attendant DGDecode.dll, then I tried 1.0.13 and it does the same thing. Posting here cuz this thread deserves a bump anyway! ;)

I am using latest NVidia driver 186.18 and its ncuvid.dll (though I did try the older one too to the same result). Maybe my BD rip/extract is corrupt or something? But this has happened to me before (a single glitch at the very beginning of a movie, last time at the Warner "studio flyover" logo) which I didn't spot until after re-encoding, but I was able to just cut it out. Any ideas welcome...

http://www.mediafire.com/file/mnmnm2nndjm/snip.h264

EDIT: Only after writing this post did I think to try DGAVCIndex (non-NV) and it doesn't glitch! So now I'm worried my Nvidia card is maybe broke?

[Guest]

No glitch here. Are you sure it is not just the fading in of the ribbons etc? Step through it by frame and you see that what look like artifacts fade into elements of the ribbon. That's how the stream is encoded. If that's not what you are referring to, please post a screenshot of the artifacts.

[laserfan]

No glitch here.Ouch! Well, many thanks for looking DG. No, it's a real glitch--I'd had like 5 or 8 tries w/DGSplit (to get the smallest filesize that showed the glitch for my slow-uploading ISP) and every check of the file always shows a glitch after opening w/a NV tool, at exactly 5 right-arrow clicks-in. Sometimes it just have the top of the logo e.g.:

http://www.mediafire.com/imgbnc.php/140e3e97f7bda5c70ededc5e575f999f5g.jpg

and other times it shows hash as here:

http://www.mediafire.com/imgbnc.php/636fa865ca48d72dcec06ffd912925f05g.jpg

On playback the glitch seems to take a few frames to go away (subsequent frames are somewhat corrupt), and I think the arrows only take me these steps anyway, i.e. my assumption is it's an I-frame that NV doesn't like. I guess this bodes ill for my Nvidia setup (a 9600GT 512Mb) unless you have some other ideas for me, or things to check??? :o

I'll do some hunting for maybe rogue nvcuvid.dlls. Thanks for the forum--typing these msgs out always gives me new thoughts...

[Guest]

System details?

[laserfan]

System details?Let me know what I forgot:

Mobo: MSI P7N SLI Platinum LGA775 NVIDIA® nForce 750i SLI+430i v1.1 BIOS
CPU: Intel Core 2 Quad Q6600 / 2.4GHz 1066MHz (not overclocked)
RAM: Corsair TWIN2X4096-6400C5 (x2 for 8Gb total)
Video: MSI N9600GT 512M OC (not overclocked) driver v186.18
Monitor: Viewsonic Q241WB 24" 1920x1200
PSU: Antec TruePower Trio TP3-650 +5V/30A, +12V1/19A, +12V2/19A, +12V3/19A, +3.3V/24A
Two Maxtor HDD PATA, one Pio DVD writer PATA, one LG DVD writer SATA
Windows XP Pro x64 64-bit SP2

System is new this year as is my exposure to XP 64-bit so I'm always suspicious of x64; not everything works with it. Other than this the only other comment I can make is that the couple of times I've seen this, the glitch has occurred right up-front and then all is perfect to the very end of 2+ hour movies! :confused:

But again, this seems clearly (now) to have something to do w/NV as your non-NV tool doesn't show this problem.

[7ekno]

Windows XP Pro x64 64-bit SP2


Possibly related also to this (http://forum.doom9.org/showthread.php?t=148304) Windows XP64 issue? The "glitch" in that thread doesn't appear on my test Vista x64 box, but does on my test XP64 box (ok ok, they are the same box, will eventually add a boot option for Win7 x64 also for testing!) ..

sorry, didn't realize you were the same poster in both threads :P

7ek

[laserfan]

Possibly related also to this (http://forum.doom9.org/showthread.php?t=148304) Windows XP64 issue? The "glitch" in that thread doesn't appear on my test Vista x64 box, but does on my test XP64 box (ok ok, they are the same box, will eventually add a boot option for Win7 x64 also for testing!) ..

sorry, didn't realize you were the same poster in both threads :P

7ekThanks 7ek, that's good info I think. I'm trying to determine if the problem is strictly related to XP Pro x64 i.e. if it does NOT appear in Vista x64 or in upcoming Win7 x64, I expect I will have a very difficult time getting neuron2 or nvidia to take a look at it! :o

Do you agree neuron2--no hope if it's solely related to XP Pro x64? Or can you ask nvidia about it anyway i.e. maybe they will analyze?

[Guest]

I will ask Nvidia about it.

[laserfan]

I will ask Nvidia about it.I appreciate that you're reporting it. Maybe they can squash a bug somewhere--which is the only reason I reported it in the first place (I can work around the glitch no problem).

[GZZ]

Offtopic question, will the licens file work for both DGmpgNV, DGavcNV, DGvc1NV or should I donate 15$ for each version ? (getting a nvidia cuda gfx tomorrow).

[laserfan]

From the DGAVCDecNV page at neuron2.net: "Your activation includes all future versions of the program at no cost. Also, please note that only one donation is required to enable all of my licensed tools. You don't need to make multiple donations."

IMO an incredible bargain given all that neuron2 has given to enthusiasts (for free) already...

[GZZ]

yea - already ordered my licens.

[GZZ]

Got my Licens file, but having some issues. If I make a dga (AVC) file and put it into my AVS file and start x264 encoding (64 bit version using avs2yuv) it runs just fine and getting real time speed on 1 pass, so this is great.

But if I then stop the encoding by closing the console window and then start it again, it just hang. My encoding window shows this:

x264 [info]: 1280x720 @ 23.98 fps
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile Main, level 4.1
d:\Encoding\...\720pScriptAVCNV.avs: 1280x720, 24000/1001 fps, 166034 frames

it never continue, showing the progress bar. I have tried to restart the cuda server, but the only two solution I have found working is:
1) Just wait, after some time it works again (dont know how long, but 30 min seems to work)
2) reboot my computer to get it working again.

Its just my encoding that hangs, I can still start DGIndex and index a new file, but just cant start my encoding. But I cant play my AVS file, when I try it opens mediaplayer classic and show the length of the movie, but it just stays at 00:00:00 and if I try to jump it just freeze mediaplayer classic.

Software:
Frameserver: Avisynth 2.5.8
X264: 1184 (newest 64 bit on x264.nl)
NVBeta4 package using cuda server 1.04 and the recommended nvidia driver.
OS: Vista 64 bit.

Hardware:
GFX: http://www.gainward.net/main/vgapro.php?id=125 (Nvidia 9500 GT, 1 GB ram)
CPU: Core2quad Q9450 2.66 Ghz (not OC)
Ram: 6 GB Kingston.
Computer isnt OC or anything.

Hope someone know what is wrong.

PS: It also hangs after 1 pass has completed and it want to start on 2 pass.

[Guest]

64 bit version using avs2yuv I don't know anything about this application. Have you tried MEGUI?

[GZZ]

it seems to only affect the 64 bit version of x264 together with avs2yuv and its properly avs2yuv fault.

It works just fine using the 32 bit version of x264 and simple frameserving without avs2yuv.

[GZZ]

this is my script using 64 bit x264 and avs2yuv (avs2yuv can be found in ripbots program).
@SET IN_TITLE=d:\Encoding\...\720pScriptAVCNV
@SET IN_BITRATE=4220
@SET OUT_EXT=264
@SET FPS=24000/1001
@SET PIPE_PATH=d:\Tools\avs2yuv\pipebuf.exe
@SET AVS2YUV=d:\Tools\avs2yuv\avs2yuv.exe
@SET X264_PATH=d:\Tools\x264\x264_x64.exe
@SET RESOLUTION=1280x720
TIME /T
%PIPE_PATH% %AVS2YUV% %IN_TITLE%.avs -raw - : %X264_PATH% --bitrate %IN_BITRATE% --fps %FPS% --level 4.1 --sar 1:1 --aud --vbv-bufsize 14745 --vbv-maxrate 17500 --filter 0,0 --bframes 3 --direct auto --keyint 24 --min-keyint 1 --subme 2 --b-pyramid --b-adapt 1 --aq-mode 2 --me dia --partitions none --threads auto --thread-input --progress --no-psnr --no-ssim --stats "%IN_TITLE%.log" --pass 1 --output NUL - %RESOLUTION% : 4
TIME /T
%PIPE_PATH% %AVS2YUV% %IN_TITLE%.avs -raw - : %X264_PATH% --bitrate %IN_BITRATE% --fps %FPS% --level 4.1 --sar 1:1 --aud --vbv-bufsize 14745 --vbv-maxrate 17500 --filter 0,0 --bframes 3 --direct auto --keyint 24 --min-keyint 1 --subme 7 --b-pyramid --aq-mode 2 --me umh --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --ref 3 --mixed-refs --weightb --trellis 1 --progress --no-psnr --no-ssim --stats "%IN_TITLE%.log" --pass 2 --output "%IN_TITLE%.%OUT_EXT%" - %RESOLUTION% : 4
TIME /T

[kemuri-_9]

I don't know anything about this application. Have you tried MEGUI?

avs2yuv is generally used to pipe the yv12 data from avisynth to x264.
useful for when wine'ing avisynth or piping from avisynth x86 to x264 x64.
It's written by x264's primary developer as well.

Hope someone know what is wrong

have you tried closing and restarting the CUVIDServer?

its been a while since i looked at the source code for avs2yuv,
but i don't recall it doing any avisynth deconstructing after it finishes, this could likely be the reason.

[GZZ]

yea - rebooting the cuda server didnt always work, sometimes it still didnt work after restarting it, then you have to wait.

[buzzqw]

Hi Pals!

don't want to hijacking but i added experimental support to great NV Tools in HDConvertToX

while i am a registered user of NV tools (a well deserved license!), my developing pc cannot use this tools (i use a virtual winxp on Fedora)

anyone is welcome to make some tests

please download the full HDC package and then use http://www.64k.it/andres/data/hdconverttox/HDConvertToX-DG.exe, then unzip nvtools beta 4 in \applications , BUT put dgdecodenv.dll in \filters folder

also make bug report in HDC thread -> http://forum.doom9.org/showthread.php?t=145577

thanks to all!

and a BIG : thanks: to Neuron2 for these great framework!

BHH

[GZZ]

Will it be possible for that DGDecode.dll auto start the CUVIDServer.exe when its being access. I sometimes starts a encoding and then it crash because CUVIDServer.exe isnt running. Was just thinking if this could be done automatically ?

[Guest]

I'll put it on the to-do list.

[SomeJoe]

I've been working with NVTools Beta4 and I'm still running into the previously reported problem where after the halfway point in the video, deinterlace=2 is not working correctly.

When using the DGDecodeNV.dll from the NVTools beta 4 off your website (.dll file dated 07/01/2009), blank frames are returned for frames past the halfway point.

I also tried to use DGDecodeNV.dll from the NVTools beta 3 package (.dll file dated 06/29/2009). In this case, frames past the halfway point are returned, but they are returned at 1/2 the proper frame rate and/or audio is out of sync.

I have tried them under NVidia drivers 186.18 as well as the current 190.38 version on NVidia's site, and the result is the same.

My test file is a 48-second MPEG-2 TS file from HDV camcorder footage (154 MB), edited in Avid Media Composer.

Other than this deinterlace=2 issue, the remainder of the beta 4 package appears to be working correctly, including the honoring of pulldown flags from MPEG-2. I have used this on several soft-telecined .m2v files and the resulting encoded stream is in perfect sync with the original audio.

[Revgen]

I've been working with NVTools Beta4 and I'm still running into the previously reported problem where after the halfway point in the video, deinterlace=2 is not working correctly.

When using the DGDecodeNV.dll from the NVTools beta 4 off your website (.dll file dated 07/01/2009), blank frames are returned for frames past the halfway point.

I also tried to use DGDecodeNV.dll from the NVTools beta 3 package (.dll file dated 06/29/2009). In this case, frames past the halfway point are returned, but they are returned at 1/2 the proper frame rate and/or audio is out of sync.

I have tried them under NVidia drivers 186.18 as well as the current 190.38 version on NVidia's site, and the result is the same.

My test file is a 48-second MPEG-2 TS file from HDV camcorder footage (154 MB), edited in Avid Media Composer.

Other than this deinterlace=2 issue, the remainder of the beta 4 package appears to be working correctly, including the honoring of pulldown flags from MPEG-2. I have used this on several soft-telecined .m2v files and the resulting encoded stream is in perfect sync with the original audio.

http://forum.doom9.org/showthread.php?p=1310386#post1310386

[Guest]

The fix will be out later tonight. It's already working but I have to do the version numbers and docs and stuff.

[Guest]

Here is the fix. Please beat on this.

http://neuron2.net/dgavcdecnv/NVbeta5.zip

There are two changes:

1. Now has D3D9-less operation. That should be more robust and perform better on low-end adapters.

2. Fix for the stream truncation by half with DGMPGDecNV and DGSource(...,deinterlace=2).

[rack04]

Did something change in CUVIDServer.exe with the updated package? I get the following error message:

http://i11.photobucket.com/albums/a199/rack04/dg.jpg

Previous versions worked fine.

[Guest]

Yes, it was updated to remove the dependency on D3D.

Please report your OS.

You can continue to use the old one until we resolve this.