DG NV tools

[Jeff Flowerday]

You mean in MPEG program streams?

The DTS audio from anything. VOBs in particular.

[laserfan]

I'm considering a Sony All-in-One PC for a guest bedroom which has an Nvidia GT240M (note: mobile) chipset. I can't find this chipset to be supported with Nvidia's latest 186.81 for Vista/7 64-bit. Instead, there's a download on Sony's site which is listed as 8.15.11.8647. I can't relate this to anything: does anyone here know if 8.15=186.81?

Alternatively, does anyone here have a GT240M and use it successfully w/DGIndexNV?

[turbojet]

Possibly, but it will have to wait for some more important stuff to get done.

OK thanks.

I'm considering a Sony All-in-One PC for a guest bedroom which has an Nvidia GT240M (note: mobile) chipset. I can't find this chipset to be supported with Nvidia's latest 186.81 for Vista/7 64-bit. Instead, there's a download on Sony's site which is listed as 8.15.11.8647. I can't relate this to anything: does anyone here know if 8.15=186.81?

Alternatively, does anyone here have a GT240M and use it successfully w/DGIndexNV?

That's 186.47. 186.81 driver version is 8.16.11.8681. As far as I can remember the last 5 digits match the setup version. Driver version can also be found in the inf files that are extracted.

I haven't used GT240M with DGNV.

[adiabatic]

Do a preview and if the number of fields repeats is not equal to half the number of coded frames, then it is irregular.

Is it also OK if the number of Field Repeats is 0? To see what you said for myself I opened a source that earlier converted without sync issues but the number of repeats is zero.

[Guest]

So there is no soft pulldown at all. Thus there is no pulldown to ignore and thus no possible AV sync issues due to ignoring irregular soft pulldown. The guideline I gave you applies only to streams with soft pulldown (pulldown using flags rather than hard field duplication).

[laserfan]

That's 186.47. 186.81 driver version is 8.16.11.8681. As far as I can remember the last 5 digits match the setup version. Driver version can also be found in the inf files that are extracted.

I haven't used GT240M with DGNV.Many thanks for your input. It appears therefore that Sony's specific driver is behind Nvidia's, which is to be expected of course. I will have to re-think my attraction to the All-in-One concept, as all the designs I've seen use "mobile" and/or proprietary components...

[Guest]

* Revise detection of scambled audio so that streams that are marked as scrambled in the PMT but which are not actually scrambled are not rejected.

* Fix crashes when upscaling streams with soft pulldown.

* Implement Force Film mode for MPEG2.

MPEG2 pulldown handling is now complete, including frame pulldown. Work is ongoing to complete full pulldown handling for AVC and VC1. Currently AVC can be Honor or Ignore but not Force Film, and VC1 can only be Ignore. Neither AVC nor VC1 yet support frame pulldown.

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

[olex99]

Is the force film mode meant to remove the 3:2 pulldown and change the framerate to 23.976? I've just tried it out and when looking at the output it still has the 3:2 pulldown, it also has the same number of frames as the input. From what i can see it has just changed the framerate to 23.976 as the video is now about 10 minutes longer than before.

When comparing to the same option in DGindex 1.5.6 my output is 61171 frames and around 42 minutes where as the NVTools version is 76464 frames and around 53 minutes.

[adiabatic]

I tried Beta3 with the problem capture (irregular pulldown) mentioned above. Used Force Film in DGIndexNV then encoded with

LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("SpeedNov03b_de.dgm",deinterlace=1, resize_w=1280,resize_h=720)
colormatrix()

and my 45:07 29.97 fps source video ended up as a 55:42 23.976 fps file... I think I'm misunderstanding what you said in Post #544.

[Guest]

When comparing to the same option in DGindex 1.5.6 my output is 61171 frames and around 42 minutes where as the NVTools version is 76464 frames and around 53 minutes. The field operation is applied only when serving through your script. I forgot to mention that. :)

[Guest]

I tried Beta3 with the problem capture (irregular pulldown) mentioned above. Used Force Film in DGIndexNV then encoded with

LoadPlugin("<path>\DGDecodeNV.dll")
DGSource("SpeedNov03b_de.dgm",deinterlace=1, resize_w=1280,resize_h=720)
colormatrix()

and my 45:07 29.97 fps source video ended up as a 55:42 23.976 fps file... I think I'm misunderstanding what you said in Post #544. As I said before and as the manual clearly states, if you set deinterlace=1 or 2, then DGSource() forces the field operation to Ignore Pulldown (but the frame rate is left at film rate). It's a wrong setup. To use the GPU deinterlacer you need to have pure interlaced video as source. Then either Ignore or Honor will get you what you need.

For your sample clip, because it has so much pure video and just sporadic soft pulldown, you should use field operation Honor Pulldown and then deinterlace with a filter in your script. There's no point to try to get to film rate with that clip because all the video parts will become jerk city.

I'll try to improve the user manual discussion of all this when the code settles down.

[olex99]

The field operation is applied only when serving through your script. I forgot to mention that. :)

yup i got it working now. I had an out of date DGDecodeNV.dll in my avisynth plugins directory. Put the latest one in there and everything is working fine now. Cheers.

[turbojet]

Thanks for the force film, worked for me as expected so far. Now that it's implemented do you plan on adding a Video Type FILM/INTERLACED like dgindex has?

Also is there a chance to get information window docking back in DGIndex(NV)?
It seemed to disappear around DGIndex 1.5.0 or so.

[Guest]

Thanks for the force film, worked for me as expected so far. Now that it's implemented do you plan on adding a Video Type FILM/INTERLACED like dgindex has? I removed that because people always used to to say "my video is interlaced because DGIndex says so". I got so tired of telling people that it just tells how the video is encoded, not how the actual content is, that I just removed it. I'm not totally opposed to restoring it, but let me ask you, what useful information would that give you?

Also is there a chance to get information window docking back in DGIndex(NV)? It seemed to disappear around DGIndex 1.5.0 or so. Yuck, I hated that. I suppose it could be a configurable option if a few others also would like to have it.

[turbojet]

I removed that because people always used to to say "my video is interlaced because DGIndex says so". I got so tired of telling people that it just tells how the video is encoded, not how the actual content is, that I just removed it. I'm not totally opposed to restoring it, but let me ask you, what useful information would that give you?

I made a typo instead of FILM\INTERLACED video type in dgindex reads FILM\NTSC. It helps determine to force film or not with ntsc dvd content.

Yuck, I hated that. I suppose it could be a configurable option if a few others also would like to have it.

With DGIndex it's not that big of a deal with undocked because the video display was always the same size unless ntsc vs pal. Now with HD and SD video sizes the info window might sit on the video window. Alternative to an option could be 'docking when touched' like ImgBurn and DVDDecrypter does.

Also I noticed DGIndexNV takes 3-4x longer to process then DGIndex with the same video\audio. Is there a chance to speed DGIndexNV up? Maybe by multithreading.

[olex99]

Also I noticed DGIndexNV takes 3-4x longer to process then DGIndex with the same video\audio. Is there a chance to speed DGIndexNV up? Maybe by multithreading.

Id say it is slower cause from what i can see there is more information in the index file. On a 40 minute episode my d2v file is around 300kb where the dgm file is a bit over 1mb. I don't think its that big of a deal though cause you easily make that time extra indexing time back, plus more, in the encoding stage so the overall indexing/encoding is faster with NV.

[Guest]

I made a typo instead of FILM\INTERLACED video type in dgindex reads FILM\NTSC. It helps determine to force film or not with ntsc dvd content. OK, I'll add that after I get things working for AVC and VC1.

Alternative to an option could be 'docking when touched' like ImgBurn and DVDDecrypter does. Please explain how that works.

Also I noticed DGIndexNV takes 3-4x longer to process then DGIndex with the same video\audio. Is there a chance to speed DGIndexNV up? Maybe by multithreading. I tested with the Stuart Little DVD, which I had lying on my hard disk. I got 1:30 for DGIndex and 2:19 for DGIndexNV so I don't know where you get 3-4 times slower. There is a speed penalty for the revised parsing architecture (much easier to understand!) I used in the NV tools. I'll have a look at optimizing it when the basic functionality settles down.

[turbojet]

Id say it is slower cause from what i can see there is more information in the index file. On a 40 minute episode my d2v file is around 300kb where the dgm file is a bit over 1mb. I don't think its that big of a deal though cause you easily make that time extra indexing time back, plus more, in the encoding stage so the overall indexing/encoding is faster with NV.

Ya it's not significant just thought that there could be more speed indexing than I was seeing (and I found a way to)

OK, I'll add that after I get things working for AVC and VC1.

Thanks. Also is there or can there be a value in the project file assigned to a frame that signifies film or ntsc?

This is very helpful for TIVTC's d2v parameter when there's some but not all FILM frames.

Please explain how that works.

Tough to explain in words but here's a video example (http://www.mediafire.com/?mnwymtwnioi)

I tested with the Stuart Little DVD, which I had lying on my hard disk. I got 1:30 for DGIndex and 2:19 for DGIndexNV so I don't know where you get 3-4 times slower. There is a speed penalty for the revised parsing architecture (much easier to understand!) I used in the NV tools. I'll have a look at optimizing it when the basic functionality settles down.

Speeds with DGIndex and DGIndexNV with task manager. (http://i37.tinypic.com/182j68.png)

I found out that if I minimize DGIndexNV it finishes the same set of vob's in 2:48 a huge improvement. I tried disabling display while the screen was showing and it made no difference. This is with Windows 7 x64. Any idea why minimizing DGIndexNV has such an impact?

Also a few things I see different between DGIndex and DGIndexNV (by design?):
- Force film still shows 29.97030 fps in DGIndexNV
- Saving a project auto adds .dgm (or .dgv/.dga) even if it's already in the file name in DGIndexNV

After some comparing dgnv resize to lanczos I found out dgnv kind of blurs the image and misses a lot of details. Kind of a bummer since most of the speedup comes from dgnv resizing but is there any chance of changing/improving the resizer that's used?

Here's an example, it's most noticable in the bushes (trees):


DGNV (http://i35.tinypic.com/166k8br.png)

Lanczos (http://i34.tinypic.com/4q29eo.png)

[nixo]

Hi neuron2

I'm experiencing a little weirdness with dgdecnv200b3. This (http://www.mediafire.com/file/hh1zdtzzwnm/sample.264) file indexes to 63 frames but DGDecodeNV.dll only appears to serve 62 frames.

--
Nikolaj

[Guest]

Post the DGA file. Probably you lose one at the end that is nondisplayable due to a bad cut.

[nixo]

It's from the very end of a Blu-ray.

http://www.mediafire.com/file/1ylzzztwi2b/sample.dga

--
Nikolaj

[shortkud]

Possible typo in DGDecodeNVManual.html?

use_pf: true/false (default: false)

Use the progressive_frame indication from NVCUVID. If deinterlace=1 or deinterlace=2, and use_pf=true, then only frames marked as progressive by NVCUVID will be deinterlaced. If deinterlace=1 or deinterlace=2, and use_pf=false, then all frames will be deinterlaced.

Why would it de-interlace progressive frames?

[Guest]

It's from the very end of a Blu-ray. Here is the end of the DGA:

IDR 109472
FRM 7 0
PIC 0
FRM 5 3
PIC 0
FRM 6 1
PIC 0
FRM 6 2
PIC 0
FRM 5 5
SIZ 1920 x 1088
FPS 25000 / 1000
CODED 63
PLAYBACK 63

You can see that the POCs for the last GOP's frames are:

0 1 2 3 5

4 is missing so 5 is discarded.

[Guest]

Why would it de-interlace progressive frames? Because the flag cannot always be trusted.

[shortkud]

Because the flag cannot always be trusted.

I thought the point of use_pf=true was to use the indication of progressive frames in a way so that only the interlaced frames would be de-interlaced and the progressive frames would "hopefully" be left alone.

use_pf: true/false (default: false)

Use the progressive_frame indication from NVCUVID. If deinterlace=1 or deinterlace=2, and use_pf=true, then only frames marked as progressive by NVCUVID will be deinterlaced. If deinterlace=1 or deinterlace=2, and use_pf=false, then all frames will be deinterlaced.

[Guest]

OK, I wrote progressive when I should have wrote interlaced.

Thanks for pointing it out.

[nixo]

4 is missing so 5 is discarded.

Makes sense. Thanks.

--
Nikolaj

[Turtleggjp]

As I said before and as the manual clearly states, if you set deinterlace=1 or 2, then DGSource() forces the field operation to Ignore Pulldown (but the frame rate is left at film rate). It's a wrong setup. To use the GPU deinterlacer you need to have pure interlaced video as source. Then either Ignore or Honor will get you what you need.

Here's my dilemma:

I would like to use deinterlace=2 for a particular TV show that is pure interlaced, except for a few places during the commercials. When the video is being served, none of these frames with soft pulldown will ever be served (because I edit the commercials out with Trim commands in my script), but because they are in the index file, if the pulldown is not honored it will obviously cause audio sync issues. Is there any way you can make it work in this situation, or would it be just as hard as getting honor pulldown working with deinterlacing in all cases? If it is, I know I can always fall back to another Bob filter in my script, but I really like using the Nvidia one. Thanks!

Matt

[Guest]

Yes, I see the dilemma. I'll see what I can do. It's easy for deinterlace=1 but for 2 there is a gotcha.

[Turtleggjp]

Thanks. They don't seem to be doing that anymore, as all my shows this season do not have any pulldown. Now that my tool to fix audio sync when there are glitches in the stream is almost done, I can finally start working on all the shows I have recorded from last year...

[whatever-ever]

I have a problem I'm not sure from where.

I have an AVS like so:
LoadPlugin("DGMultiDecodeNV.dll")
part1=DGMultiSource("1.dgm")
part2=DGMultiSource("2.dgm")
part3=DGMultiSource("3.dgm")
part4=DGMultiSource("4.dgm")
part5=DGMultiSource("5.dgm")
part6=DGMultiSource("6.dgm")
part7=DGMultiSource("7.dgm")
part8=DGMultiSource("8.dgm")
part9=DGMultiSource("9.dgm")
part10=DGMultiSource("10.dgm")
part11=DGMultiSource("11.dgm")
part12=DGMultiSource("12.dgm")
part13=DGMultiSource("13.dgm")
part14=DGMultiSource("14.dgm")
UnalignedSplice(part1,part2,part3,part4,part5,part6,part7,part8,part9,part10,part11,part12,part13,part14)
(it was originally longer, as I am putting together a small film project, but 14 seems to be enough to illustrate my problem)

While this AVS plays without any trouble in VLC - and opens/seeks in VirtualDub - it can not be compressed when I save it to XviD (nor x264). Both encoders fail about the same time as part14 begins.

The error I recieve is "Failed to create video decoder (100)."

I use DGIndexNV 2 beta 3. The video sources are all MPEG2 (which can all be encoded individually, and even with AVS of part1 to part13).

Maybe it's an AviSynth problem, maybe it's XviD/x264. I'm just posting in case this has something to do with DGIndexNV, or in case anyone has experienced the same and has resolved the issue.

Cheers.

[Guest]

There's a limit on the number of times you can instantiate DGMultiSource(), because each one consumes memory on the graphics card. The limit is determined by the frame size and the amount of memory on your graphics card. To be honest I'm amazed you made it up to 14. What is the frame size?

Anyway, you say it plays OK in VirtualDub but not when encoding. The only thing I can thing of is that somehow encoding consumes some extra GPU memory.

For lots of segments like that it would be preferable to load all the source files and make a single project and do things with trims in your script.

[whatever-ever]

There's a limit on the number of times you can instantiate DGMultiSource(), because each one consumes memory on the graphics card. The limit is determined by the frame size and the amount of memory on your graphics card. To be honest I'm amazed you made it up to 14. What is the frame size?

Anyway, you say it plays OK in VirtualDub but not when encoding. The only thing I can thing of is that somehow encoding consumes some extra GPU memory.

For lots of segments like that it would be preferable to load all the source files and make a single project and do things with trims in your script.

It has 1GB ram. I hear your point, however I am not sure if it would work if I use trim() on some sources, e.g. part1=part1.trim(0,50) and then do part2=part2.trim(0,50). That would cause problems, wouldn't it?

Or is there some "trim" in .dgm that I've been completely oblivious to?

Thanks for the quick reply

[Guest]

vid=DGMultiSource("fullproject.dgm")
aud=
stream=AudioDub(vid,aud)
part1=trim(stream,0,50)
part2=trim(stream,100,150)
return part1++part2

[whatever-ever]

Sorry, what i meant was, it is multiple MPEG2s. Do you mean that the dgm has all files included and then part2 = trim(stream,<number of frames in part1>+x,<number of frames in part1>+y) if part2 was normally trimmed like trim(stream,x,y) ?

[Guest]

What else could I have meant? :devil:

[VincAlastor]

Why don't you ask Kurtnoise about it?

he hasn't time. is there any gui which works with dgdecnv tools? i can't get it to run in staxrip. i need your support...

[Guest]

You can use Lord_MulderR's simple GUI. I've been using that with some local mods of my own.

[stax76]

There is one issue in StaxRip I've recently discovered due to feedback by a user trying to config StaxRip to use NV tools. Unfortunately I can't test it myself as I've a ATI 2400 card.

In case of dga files StaxRip checks if avcsource is present and if it's not it changes the source filter to avcsource. You can workaround this by editing the source filter and add avcsource as comment, here is what a profile would look like:

[Source]
AVC = #AVCSource%newline%DGDecode("%source_file%")

Instead of using this workaround you could also use a new build which fixes it:

http://www.stax76.bplaced.net/files/applications/StaxRip/StaxRip_1.1.2.1_beta_preview_1.7z

It will reset/overwrite lot's of profiles so you might want to use the Import/Export feature in the profiles dialog.

[laserfan]

You can use Lord_MulderR's simple GUI. I've been using that with some local mods of my own.Hmmm are you talking about Avidemux? Or another (avidemux doesn't look simple to me)?

[Guest]

This one:

http://forum.doom9.org/showthread.php?t=144140

Don't be confused, it works in a pure win32 environment as well.

[laserfan]

You can use Lord_MulderR's simple GUI. I've been using that with some local mods of my own.

This one:

http://forum.doom9.org/showthread.php?t=144140

Don't be confused, it works in a pure win32 environment as well.Thanks, I'm gonna try it...

[Jeff Flowerday]

I found out that if I minimize DGIndexNV it finishes the same set of vob's in 2:48 a huge improvement. I tried disabling display while the screen was showing and it made no difference. This is with Windows 7 x64. Any idea why minimizing DGIndexNV has such an impact?


I notice the exact same thing on Windows 7 x64, minimizing gives you a major performance increase.

[laserfan]

Using 2.0.0 beta 3, I just noticed that I can get CUVIDServer to stop working, by closing x264's command window (clicking on "X" close button) while it's running:

1. Make a .dga and create an avs e.g.

DGSource("videoIN.dga")

My DGDecodeNV.dll is in the Avisynth plugins folder.

2. Use this in an x264 command (mine 1342Modified)

3. After x264 processing has begun, click the X box to close the window (the x264 task stops according to Task Manager)

4. Try to restart the process by running the x264 command again; it hangs/stops after four lines, and creating videoIN.stats.mbtree.temp and videoIN.stats.temp files (zero bytes). The window is open but there's zero CPU activity i.e. nothing happening.

If I next try to open the .avs with Vdub, well I get a blank Vdub window i.e. it does not open and is "hung" as well, with an hourglass i.e. I have to CTL-ALT-DEL to kill it.

Closing CUVIDServer and re-running it allows everything to work again. Note[i] this only occurs when I close the x264 window while running. If I abort the x264 process by doing a CTRL-C and Y to "Terminate Batch job Y/N?" then I can re-start the process no problem.

Yeah this is (for me anyway) one of those "Doctor, it hurts when I do this. (Well, then Don't Do That!)" i.e. I can avoid the problem by not clicking the cmd.exe window's Close box. But thought I'd asked if anyone else has noticed the same behavior. Using XP Pro x64 here, but 32-bit x264.

[Guest]

At one point I had a timeout to detect that but it was kicking in when it shouldn't, so I removed it. My advice is "Don't do that." :)

[GZZ]

why not use the DGMultiSource, then you dont have to play around with CUVIDServer. I havent had one single issue since I started to use DGMultisource instead.. :)

[laserfan]

My advice is "Don't do that." :)I'm fine with that! Just glad I wasn't "seeing things"! :D

why not use the DGMultiSource, then you dont have to play around with CUVIDServer. I havent had one single issue since I started to use DGMultisource instead.. :)Good idea, though I wonder--DG do you use/recommend also? I mean, is DGMultiSource "the future" ie. I should be beating-up on that dll as much as possible anyway?

[Guest]

The CUVID Server was a hack to support MEGUI's bizarre script opening strategy. As MEGUI is now showing new issues with the NV tools, which nobody seems to have any time to address, I can't recommend MEGUI. And when that goes away, DGMultiSource() becomes the preferred solution. I always go to it for my needs.

[VincAlastor]

staxrip works with dgdecNV, now. great job stax76. thank you

[laserfan]

The CUVID Server was a hack to support MEGUI's bizarre script opening strategy... DGMultiSource() becomes the preferred solution. I always go to it for my needs.Thanks! I use my own .cmd files and not MeGUI.

Changing my templates to use DGMultiSource()...