DGAVCDecNV 1.0.13: GPU decoding on Nvidia

[Guest]

I've published my development dialog with Nvidia. It will be interesting to developers.

http://neuron2.net/dgavcdecnv/cuda/cuda.html

I have also rolled out the licensed version.

http://neuron2.net/dgavcdecnv/dgavcdecnv.html

There will not be any more free versions of DGAVCDecNV available after the current alpha expires next month.

[Dark Eiri]

Hey neuron2, do you plan on doing a version of DGIndex for MPEG-2 with GPU decoding anytime soon? I know it wouldn't be a massive improvement since MPEG-2 decoding is not that CPU intensive as H264, but it would be nice, since the deinterlacer would be GPU processed.

DGAVCdevNV is really impressive. Totally worth the $15!

[Sagekilla]

Just curious, is the licensing fee a fee that nvidia requires, or is this towards you? I don't mind either way, but if it's towards you I'm all the more eager to donate :)

@Dark Eiri: True that MPEG-2 doesn't require as much CPU, but when you deal with very high bitrates (the early blu-rays) there's still some benefit.

[Guest]

Just curious, is the licensing fee a fee that nvidia requires, or is this towards you? I don't mind either way, but if it's towards you I'm all the more eager to donate :) There is nothing payable to Nvidia:

http://developer.download.nvidia.com/licenses/general_license.txt

[Guest]

Hey neuron2, do you plan on doing a version of DGIndex for MPEG-2 with GPU decoding anytime soon? I know it wouldn't be a massive improvement since MPEG-2 decoding is not that CPU intensive as H264, but it would be nice, since the deinterlacer would be GPU processed. I plan to enable it for MPEG2 and VC1.

DGAVCdevNV is really impressive. Totally worth the $15! Waiting for your donation...

[Sagekilla]

Aha, well I'll be sending some money your way in a bit :)

[rebkell]

I just tried to make a contribution from the link you have with a Credit Card, but I don't think it went through, but the message is a little confusing: I'll check my email for the next day and if nothing shows up, I'll do it again.

The message I got when I submitted:


Sorry — your last action could not be completed

If you were making a purchase or sending money, we recommend that you check both your PayPal account and your email for a transaction confirmation during the next day.

If you came to this page from another website, please return to that site (don't use your browser's Back button) and restart your activity.

If you came from PayPal's website, click the PayPal logo in the upper-left corner to return to our home page and restart your activity. You might have to log in again.

[Guest]

Let's see what happens and I'll call PayPal tomorrow too. Thanks for letting me know.

BTW, the licensed version has a fix for the bug with non-detection of the GPU that required a reboot. Nvidia sent it to me today.

[Guest]

@rebkell

I just called PayPal and they say everything is fine and in fact a donation arrived from someone else while I was on the phone with them. They think it is some problem with your account or credit card info.

I'd prefer people to PM or email me with issues like this, so we can keep to technical things in the thread.

[tre31]

I've published my development dialog with Nvidia. It will be interesting to developers.

http://neuron2.net/dgavcdecnv/cuda/cuda.html


Interesting read, quality support!
and finally well done neuron2 - good too see that gpu power being used for something, and if you do the same for mpeg-2 (au dvb-t = mpeg-2) there is no doubt in my mind that nvidia gets my vote for my next gfx purchase.

Been interesting watching this thread, and the speed (and enthusiam) with which you have working prototypes - impressive. :)

[Deinorius]

I plan to enable it for MPEG2 and VC1. Will that be as one program or a program for each codec?
As one program, you can call it later DGGPUIndex. :devil:

[SeeMoreDigital]

As one program, you can call it later DGGPUIndex. :devil:Works for me....

[Atak_Snajpera]

There will not be any more free versions of DGAVCDecNV available after the current alpha expires next month.
I hope you are not planing to do the same for DGAVCDec (powered by libavcodec) ...

[Comatose]

Yup...

Anyway, I'm looking into getting a job now :P

[lucassp]

Will that be as one program or a program for each codec?
As one program, you can call it later DGGPUIndex. :devil:

"Free" and high quality MPEG2 Deinterlacing sounds good :)

[jj666]

Donated. Professional software at a budget price.

Thanks a lot!

-jj-

[CruNcher]

Wow nice to see Nvidias open approach here though i wish you would also get in contact here with ATI and give them a chance to react, but still im a little surprised why Nvidias approach for Windows is so open though for Linux nothing is being done yet :( , never the less it's great to see Nvidia cares about this support and also Open Source approaches even if it's currently only the case for 1 Platform in terms of Video Support :)
Also it shows that Nvidia cared about 100% spec compliance and that most problems are coming from the streams themselves :)

btw neuron2

1- If decode runs in the same thread than display (ie: calling map() directly from within the display callback), the video processor will be idle (frequently happens, especially for frames where display order == decode order) In this case, the amount of performance drop depends directly on the speed of the transfer to sysmem and the speed of the GPU.
Is this currently what happens when Display is Enabled and Playback Speed drops from 45 fps down to roughly 12 fps ?


When getting full VP utilization, without any 3D bottleneck, the perf of the 8500GT should be very close to a 9800GTX, since IIRC the video processor is clocked at the same speed on both, though this could depend on the manufacturer (usually it is running at 450MHz, but some low-end GPUs are only running VP at 400MHz).

Does this also suggests that there is something in Nvidias Firmware that controls this clockspeed aside of the Shader clock itself ?

[Guest]

You didn't read the dialog carefully! You missed the places where Nvidia talks about how they are making a cross-platform version and cutting the connection to DX/D3D.

To be honest, I have had very bad experiences with ATI products. I am not all that keen about it. Also, I see some posts elsewhere saying that the required API is not yet exposed, and may not be.

To answer some other questions:

I will try to integrate MPEG/AVC/VC1 but if not feasible they will be separate.

I have no plans to license the libavcodec version (though I could because I access the GPL part via a DLL).

I'm not going to get rich through my stuff, I just thought it would be nice to cover my website hosting and keep the beer flowing while I do my coding. :)

[Ranguvar]

What?? The GPU indexer will not be FOSS?

Wouldn't be such a bad thing if NVIDIA didn't announce that they were making the CUDA decoding multi-platform, as you said. Now at the same time there's both hope for a GNU+Linux port, and it is lost.

/me hopes NVIDIA's CUDA support is as good as you say, because the sooner there's a FOSS fork or patch to DGIndex/DGAVCIndex with GPU decoding, the better.


Please don't take this as unappreciative for the great work you've done, or too critical of your decision. I understand your reasons. I am just a very big advocate of FOSS.
By the way, how are you planning on copyrighting it? If I'm not mistaken, jackei also did work on the original DVD2AVI, and some code is likely still in DGAVCIndexNV... are you planning on rewriting it, or on simply using a one-size-fits-all FOSS GUI and CLI interface to a FOSS old-style decoder, and your copyrighted GPU decoder if they paid up, the decoders as DLLs?

[Bitowzky]

Can someone provide me the link to apha 3 version? I'd like to test it, before i buy it. Thanks

[DarkZell666]

Wouldn't be such a bad thing if NVIDIA didn't announce that they were making the CUDA decoding multi-platform, as you said. Now at the same time there's both hope for a GNU+Linux port, and it is lost.

Did I miss something or isn't it also allowed to write closed-source + commercial products for linux ? Or did I misunderstand your statement ?

[Inventive Software]

People are quite within their rights to make a program run on Linux and charge people for the privilege of doing so, without making the source available. Intel's compiler for example. :)

@donald: I was surprised to find you'd employed a "license" strategy for DGAVCDecNV, but I guess you're the one writing the program, originally in response with PAFF hassle (i.e no response from libavcodec devs), so you're quite within the right to ask for a small charge as "beer money", as you so succinctly put it. ;) All power to you, and if you end up making 5 figures out of it, that shows the user base you have. :)

As Ranguvar has loosely written, I hope ATI are not only taking note, but wanting to add support alongside NVIDIA in this program. :D

[Guest]

Wouldn't be such a bad thing if NVIDIA didn't announce that they were making the CUDA decoding multi-platform, as you said. Now at the same time there's both hope for a GNU+Linux port, and it is lost. You think I'm incapable of coding for Linux platforms?

There's nothing recognizable left from DVD2AVI in my current DGAVCIndexNV code base, and DGAVCDecodeNV is written from scratch. But DGMPGDec as it currently stands could not be closed.

[G_M_C]

Good for you Neuron2, no shame in trying to keep some costs down. Alas, i don't own a NV card, and don't plan to. So my hopes still lay with a software and/or Ati version. In the mean time i stick to alpha 35 for the software-version; But congrats on this first mile-stone :)

[Atak_Snajpera]

I was going to add DGAVCIndexNV to RipBot package but since this software won't be free I had to abandon this idea. I will also stay with my 4850 and libavcodec...

[tre31]

As Ranguvar has loosely written, I hope ATI are not only taking note, but wanting to add support alongside NVIDIA in this program. :D

Going from my experience with ATI and their dxva and deinterlacing technologies as they currently stand, I would say they would need too change quite a few things within the SDK and their driver model too even have access too the UVD chip, its not undoable I don't think, but do they have the desire too allow access too it? time will tell. ATI has only recently gotten behind opensource and their Windows drivers have followed the 'locked down' path pretty much since their initial catalysts - perhaps a change of thought processes is in order.

Another thing too also consider that is if they open up a UVD api via their Stream SDK is their implementation of protected video path's secure - may be the real reason why they can't/won't allow access to it.

[Warrex]

There will not be any more free versions of DGAVCDecNV available after the current alpha expires next month.

Wow, did not see this coming. :eek: I think this is really a bad day for the doom9 community. Asking for donations is totally fine especially if someone needs the money to be able to continue his great work but I doubt that licensing models are the right way to go.

IMHO the software/code contributed here should stay free. This is escpecially important for other people offering free software who rely on your work like Atak_Snajpera (Ripbot264) or others. If more people choose to go that way it will slow the community down and might destroy what it is now. Btw.: I also own a Radeon 4850. Just my 2 cents on the whole licensing idea.


Something like the following is even more annoying considering how many DRM infested programs require doing things when you change your PC: "Your activation is tied to your system drive that carries the C: partition. So if you replace that drive, please email me for a new license file."

Source:
http://neuron2.net/dgavcdecnv/dgavcdecnv.html

See here also: http://forum.doom9.org/showthread.php?t=141409

[Guest]

I don't want this thread to devolve into an argument about how I make my work available. It's for technical discussion of the program. That is a warning that OT strikes can follow. Send me a PM or open a new thread in General about it, but don't further pollute this thread.

[Warrex]

Okay, sorry, I did not know that this was purely technical here. I opened a thread for anyone willing to discuss licensing models in software/code contributed on Doom9.net here:


http://forum.doom9.org/showthread.php?p=1187889#post1187889

[Zwitterion]

some issues with dgavcdecnv100a3:

- when doing "bobbing-with-two-dgavcdecnv-instances", only the use_top_field=true frames are correctly deinterlaced. The use_top_field=false frames look interpolated.
http://img255.imageshack.us/img255/6240/gpudeintth4.th.png (http://img255.imageshack.us/my.php?image=gpudeintth4.png)http://img255.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)
Also, when adding more instances like:
a=DGAVCDecodeNV_AVCSource("00014.dga", deinterlace=true, use_top_field=true)
b=DGAVCDecodeNV_AVCSource("00014.dga", deinterlace=true, use_top_field=false)
c=DGAVCDecodeNV_AVCSource("00014.dga", deinterlace=true, use_top_field=true)
d=DGAVCDecodeNV_AVCSource("00014.dga", deinterlace=true, use_top_field=false)
Interleave(a,b,c,d)
... only 'a' will be correctly deinterlaced from the top field, all other instance will be interpolated from the bottom field (even 'c').

- when bobbing, going forward in the stream too fast can result weird artifacts. I'm no expert, but I guess the instances desyncronize at higher fps, or the video processor/CUDA gets overloaded or something like that.

- more than four instances crash virtualdubmod instantly without error message.

- when using a single instance of DGAVCDecodeNV, use_top_field=false results in the same stream as use_top_field=true. IIRC this was a CUDA bug, though.


Great work so far, I'm looking forward to VC-1 and MPEG2 decoding and will donate soon.

[Guest]

Yes, there are some issues with the bobbing solution and the current implementation is a hack due to an nvcuvid.dll deficiency. When I update the dialog with the recent correspondence you will see what is going on in that regard. Engineer O has said that he will try to get it working properly. And given what he has done so far, I expect it to be resolved.

I'm working on MPEG integration and MKV container support right now.

[xopowo]

Intel Xeon X3360
nVidia GeForce 8600GTS
2GB RAM (who cares)
Windows XP Professional SP3

I installed it (couldn't figure out the whole missing license thing), but I gladly paid since I've been using free stuff for years and its the least I could do. Got the license, I can demux files fine.

**EDIT** I had to drop the nvcuvid.dll in the system32 dir to get it to work**

Couple of Questions if I may:

#1 - When I 'encode' , 'transcode' (whatever), my h264 content to, say xvid, in vdubmod ... I'm seeing same exact fps than what I normally see (with same CPU usage). so, "how" do I know if I'm using anything correctly or not? Or perhaps better stated ... I don't know what I'm doing.

#2 - when one turns deinterlace=true after the .dga file in the AVCSource line in my .avs file; will that actually deinterlace the file, or do I still need a plugin to perform that action?

#3 - when people are stating that they are getting 60fps at 0% CPU usage ... what are they referring to? Just the rendering of the AVC file itself? In other words, it has nothing to do with 'encoding/transcoding' (I don't know the correct vernacular).

Thanks for answering, and thanks Donald for everything you do (rule violation??)

[Guest]

**EDIT** I had to drop the nvcuvid.dll in the system32 dir to get it to work** As described in the Quick Start document. :)

#1 - When I 'encode' , 'transcode' (whatever), my h264 content to, say xvid, in vdubmod ... I'm seeing same exact fps than what I normally see (with same CPU usage). so, "how" do I know if I'm using anything correctly or not? Or perhaps better stated ... I don't know what I'm doing. If you have a powerful machine, the gains in terms of transcoding performance may not be significant. You can read the thread and see who gets boosts and who doesn't. Even without the boost, you have correct decoding (libavcodec is still deficient), and you have the deinterlacer. You will also have VC1 and MKV soon. There is no existing frame accurate server for VC1!

#2 - when one turns deinterlace=true after the .dga file in the AVCSource line in my .avs file; will that actually deinterlace the file, or do I still need a plugin to perform that action? Yes, it will deinterlace even if you haven't saved the project with it turned on in DGAVCIndexNV. I thought of linking them but thought "Why?".

#3 - when people are stating that they are getting 60fps at 0% CPU usage ... what are they referring to? Just the rendering of the AVC file itself? In other words, it has nothing to do with 'encoding/transcoding' (I don't know the correct vernacular). We were talking about playing the file in DGAVCIndexNV with the display disabled in the Video menu. That should be comparable to the serving through Avisynth. If you are encoding then obviously that is added on top.

[xopowo]

ok, by adding:

AVCSource("1.dga", deinterlace=true)

The output file (lagarith) was deinterlaced (what seems to be very well) [I'm working with a 1080i h264 source file]

Is there something else I can add that will provide frame decimation so that I don't have to use 'any' plugins at all in my script for sources that require IVTC?

If that were the case, I would be a happy guy here (less work for me in backing up my shows).

Additionally, when dealing with 720p content, I have been reading this thread, and it seems that one can do this:

a=AVCSource("file.dga",deinterlace=true,use_top_field=true)
b=AVCSource("file.dga",deinterlace=true,use_top_field=false)
Interleave(a,b)

???

To achieve 29.97fps (from 59.94)?

Please be kind to me, I'm new at this stuff for the most part.

[Guest]

Is there something else I can add that will provide frame decimation so that I don't have to use 'any' plugins at all in my script for sources that require IVTC?Just to be clear, you wouldn't want to use the deinterlace option for IVTC. The 3:2 support in PureVideo is not currently exposed via the CUDA interface. I will ask Nvidia if there are any plans to do that. So for now, IVTC must be done externally. For soft telecining, you can do it by ignoring pulldown flags in DGAVCIndexNV. Do you have hard telecined sources?

Additionally, when dealing with 720p content, I have been reading this thread, and it seems that one can do this:

a=AVCSource("file.dga",deinterlace=true,use_top_field=true)
b=AVCSource("file.dga",deinterlace=true,use_top_field=false)
Interleave(a,b)

To achieve 29.97fps (from 59.94)? No, that's for getting 59.94 from 29.97.

Tell me more about your source material. Better yet, post an unprocessed source sample. Then I can advise you properly.

[xopowo]

http://www.megaupload.com/?d=RI51NIK1

Two files there.

1080i which requires deinterlace (of course) and decimation (since it should be 23.976fps).

720p which requires halving the framerate to bring it "back" to 29.97fps.

Not sure if this is what you were asking for?

Bottom line - I tried with deinterlace=true in the line with the 1080i (subsequently had to decimate in the script as well) and it turned out really well. I'm asking if one can add something (in addition to) that will allow for decimation as well as deinterlace (without having to use a filter in my script).

I understand what you wrote above, so I guess that's not possible. But, what is needed in order to get the 59.94fps down to 29.97, other than separatefields()? Are there options?

[Guest]

1080i which requires deinterlace (of course) and decimation (since it should be 23.976fps). It's hard telecined, i.e., 3:2 pulldown without flags. You shouldn't deinterlace that. You should do IVTC in your script. As I said the PureVideo 3:2 engine is not yet accessible.

720p which requires halving the framerate to bring it "back" to 29.97fps. It's progressive at 59.94 without dups, i.e., every frame is a new picture. If you want 29.97, just put SelectEven() in your script. It has essentially no overhead.

[stax76]

Sorry if this was asked before but I don't get the point of hardware decoding, isn't the decoder mostly used for transcoding and shouldn't rather the encoder use the hardware instead?

[lexor]

Sorry if this was asked before but I don't get the point of hardware decoding, isn't the decoder mostly used for transcoding and shouldn't rather the encoder use the hardware instead?

The point is in freeing up CPU for encoding by moving source decoding to GPU. As for encoding needing hardware, CUDA in its current state is no good for that (as per x264 dev experience, and DS actually saying he'd rather learn GPU assembly then use CUDA for encoding)

[Zwitterion]

Another bug (affects both DGAVCDecNV and DGAVCDec):
When indexing the M2TS of Die Hard (over 2 hours long, nearly 30 GB big), an error message appears at frame 138187 (or at frame 162775 for DGAVCDec) that says:
"Could not allocate memory: AllocPPS: slice_group_id"

At this point, memory usage for DGAVCIndexNV.exe is at 137148 kilobytes. Maybe this is a limit? Trying to use the same instance of DGAVCIndexNV.exe again fails right at the start of the indexing with the same error message.

I couldn't cut out a sample, because the error doesn't appear with small streams.

[Dark Shikari]

The point is in freeing up CPU for encoding by moving source decoding to GPU. As for encoding needing hardware, CUDA in its current state is no good for that (as per x264 dev experience, and DS actually saying he'd rather learn GPU assembly then use CUDA for encoding)I'd less so say its "no good" and moreso say that the effort required would be very large and require a much larger team with much more CUDA expertise. Its certainly possible, but it would just be an enormous amount of effort, since the hardest part is you simply can't port just "one function" of the encoder due to the latency.

Plus, well, we saw what happened with Badaboom.

[Guest]

Another bug (affects both DGAVCDecNV and DGAVCDec):
When indexing the M2TS of Die Hard (over 2 hours long, nearly 30 GB big), an error message appears at frame 138187 (or at frame 162775 for DGAVCDec) that says:
"Could not allocate memory: AllocPPS: slice_group_id"

At this point, memory usage for DGAVCIndexNV.exe is at 137148 kilobytes. Maybe this is a limit? Trying to use the same instance of DGAVCIndexNV.exe again fails right at the start of the indexing with the same error message.

I couldn't cut out a sample, because the error doesn't appear with small streams. Tell me what DVD to buy and I'll get it and duplicate the issue. Is it the BluRay version available in the USA? And how did you rip it? In the meantime, I'll look at my PPS management code. It shouldn't need all that memory.

[Guest]

Sorry if this was asked before but I don't get the point of hardware decoding, isn't the decoder mostly used for transcoding and shouldn't rather the encoder use the hardware instead? In addition to what the others have answered, I'll say again why I did it:

1. Speedup of transcoding for some machines.

2. Correct decoding of streams that libavcodec still has problems with.

3. Access to the PureVideo deinterlacing and possibly the 3:2 engine to come.

4. Decoding of VC1 to come.

5. Integration of MPEG, AVC, and VC1 into one application.

[Inventive Software]

Sorry if this sounds completely pointless, but on the filter page on your site, do you periodically update the correspondance between you and NVIDIA?

[Guest]

At this point, memory usage for DGAVCIndexNV.exe is at 137148 kilobytes. OK, I found the memory leak. I'll release new versions this evening.

[Guest]

Sorry if this sounds completely pointless, but on the filter page on your site, do you periodically update the correspondance between you and NVIDIA? I plan to. I published that right after I got the multi-instance working. There is some more back-and-forth since then that I will add soon. I'll try to keep it current.

[Inventive Software]

Excellent! I must be going mental then, cos I swore there was some new material in that page... I only read it yesterday! Ah well.... time to section meself! :D

[sh0dan]

Congrats on your new software, Donald. You seriously deserve some beer money for all your hard labour!

May I humbly suggest, that you put a slightly more informative text into your "Missing License" dialog; as usual I didn't RTFM, and I had no idea what to do. Maybe you could also allow it to decode the first 10% of a given clip, just as a teaser. MP4/MOV parsing would also be exceptionally useful, since MPEG4 seems to become a quite common container.

CUDA development is very interesting - especially if they get their async interface working optimally. Keep up the great work!

[Guest]

I can use the "beer money" to buy the MP4 spec I need. I've just used some it at lunchtime to buy the BluRay Disk I need to test memory leak issue reported above.

You suggestion on the licensing is a good one. I will do something about that.

[Zwitterion]

I've just used some it at lunchtime to buy the BluRay Disk I need to test memory leak issue reported above.
It's this one (http://www.blu-ray.com/movies/movies.php?id=557). Sorry, after I read your post #395 I thought you wouldn't need the Blu-ray after all so I didn't respond. :o
I'm using AnyDVD 6.4.6.9, "rip to image", "keep protection", then Virtual CloneDrive to load the image. This way I don't need the physical disc the whole time.