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]

Originally Posted by 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?

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=3...4e75f6e8ebb871

[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]

Originally Posted by Demn

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]

Originally Posted by neuron2

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 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]

Originally Posted by Turtleggjp

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 ?

[Turtleggjp]

Originally Posted by neuron2

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:

Originally Posted by neuron2

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]

Originally Posted by Kurtnoise

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.

[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]

Originally Posted by neuron2

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