DGAVCDecNV 1.0.13: GPU decoding on Nvidia

[Guest]

No problems on this file with the software version. Actually, it affects DGAVCIndex also.

I found two problems:

1. I assumed a too small size for the SPSs that I store. Your stream had bigger ones!

2. A later edition of the AVC standard added some new profile_idc values that I had to allow for.

With these fixes your streams play fine. I'll release fixes for DGAVCDec and DGAVCDecNV tomorrow.

[Audionut]

Thanks.

Unless the errors are somehow affecting the information display, this stream also has a max bitrate of over 60Mbps.
Way out of spec, for both the 4.1 level it's encoded at, and the blu-ray spec.

edit: I just checked the software version results, and it shows max bitrate 58.475Mbps.

[LigH]

Could you please add the hardware requirements to the documentation?

I remember differences in the grade of hardware support by the variants of the GeForce 8xxx family, and I wonder if this project requires a minimum variant (I mean, on-board / mobile IGPs and low-cost variants like 8300/8400{M} might not support DXVA enough to be of use for AVC decoding).

"Minimum hardware requirement: GeForce 8500" would be a probably sufficient example to know that one needs a stand-alone graphic card and may not get an on-board solution to work (if that is the case; but if IGP/Mobile are fine, let's say "8xxx").

TechARP - Desktop GPUs: Nvidia (http://www.techarp.com/showarticle.aspx?artno=88&pgno=3)
TechARP - Mobile GPUs: Nvidia (http://www.techarp.com/showarticle.aspx?artno=98&pgno=1)

[Audionut]

"Minimum hardware requirement:

Device supporting CUDA.

http://www.nvidia.com/object/cuda_learn_products.html

Looks like any 8xxx series hardware or higher.

ATTENTION: If you do not use an Nvidia graphics card 8xxx or higher, this thread is not for you!

[crypto]

@Quark.Fusion
@all

I ditched the COM idea because it's a PITA, with all the GUIDs, registry stuff, etc. I have to make shared memory anyway to pass the frame, so I'm using it also to implement an RPC mechanism. So that together with some events and a mutex gives me all I need without the COM insanity. The way it will look to the user is that you first open a CUDA decoder server application. You can minimize it but as long as it stays alive the CUDA decoder is available to clients, i.e., AVCSource() instances. The clients access it using the named shared memory, events, and mutex. I'll publish the interface, the server source code, and a basic client so that it can be re-used. My DG client applications will remain closed.
I like the new idea and I was sceptical with the COM idea (out-of-process) from the beginning. It is also great to have an open documented interface.

I also wanted to ask, if the current dgavcindex is open source, as a have read about it, but never found sources.

[Guest]

Unless the errors are somehow affecting the information display, this stream also has a max bitrate of over 60Mbps.
Way out of spec, for both the 4.1 level it's encoded at, and the blu-ray spec.. Can you tell me the stream and the exact steps you went through to get a display of that large a max bitrate? I can't get it to happen.

@crypto

Not open source at this time.

[Audionut]

This is from the full stream of the sample posted earlier. "Die hard 1. Region B"

Gathered using the software version.

I'll post the hardware version when an encode i have running is finished.

Stream Type: AVC Elementary
Profile: reserved [49]
Level: 4.1
Frame Size: 1920x1080
SAR: 1:1
Display Size: 1920x1080
Frame Rate: 23.976024 fps
Colorimetry: BT.709* [2]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 167235
Playback Number: 167235
Frame Repeats: 0
Field Repeats: 0
Bitrate: 0.097
Bitrate (Avg): 28.751
Bitrate (Max): 58.475
Elapsed: 0:22:38
Remain: 0:00:01
FPS:
Info: Finished!

edit: rip blu-ray to hdd with anydvd. demux .264 with tsmuxer. open with dgavcindex. save project.

[Guest]

demux .264 with tsmuxer What is the reason for this step versus opening the transport directly in DGAVCIndexNV?

[squid_80]

Looks like any 8xxx series hardware or higher....Except for the 8800 Ultra/GTX/GTS, Telsa S870/D870/C870, Quadro Plex 1000 and Quadro FX 5600/4600.
One of the cheapest cards available, the 8400, contains VP3 instead of VP2 like the others - but this makes no change to H264 decoding, only VC1 and MPEG2 are improved.

[Guest]

I just checked the software version results, and it shows max bitrate 58.475Mbps. We may be talking apples and oranges. The max bitrate displayed by DGAVCIndexNV is the highest rate seen in all the one second periods of the stream. So it's an "instantaneous" bit rate. When you speak of the "max bitrate" of a blu-ray, you may be referring to the largest allowed average bitrate. You can have high peaks without breaking the buffering. Note that your average rate is well within spec.

In any case, to compare the two they must be defined the same way, and I don't know how the spec defines "max bitrate". Do you?

[Audionut]

What is the reason for this step versus opening the transport directly in DGAVCIndexNV?

I've gotta demux the audio and subs, so might as well demux the video as well. Also, not all movies are stored in one TS. Tsmuxer will combine all parts into one stream.

[Guest]

Ah, thank you.

[Audionut]

and I don't know how the spec defines "max bitrate". Do you?

http://www.blu-ray.com/faq/

Section 2.4

[Audionut]

And here for h.264.

http://en.wikipedia.org/wiki/H.264

Under section levels. How accurate the wiki is though, is anyone's guess.

BTW. I've only seen 1 blu-ray so far out of about 35 that has had a max bitrate under the 40mbps of the spec.
And IIRC about 2 or 3 with max bitrates above 50mbps. The limit of level 4.1.

[Guest]

* Fixed a problem that could cause large SPSs to not be processed, resulting in decode failures.

* Revised the NALU parser to allow for some missing profile_idc values.

* Added lines CODED and PLAYBACK in the DGA file to provide the number of coded and playback frames.

* Added a workaround for the Windows bug that (rarely) caused the DGAVCIndexNV window to open off the screen.

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

[foxyshadis]

And here for h.264.

http://en.wikipedia.org/wiki/H.264

Under section levels. How accurate the wiki is though, is anyone's guess.

BTW. I've only seen 1 blu-ray so far out of about 35 that has had a max bitrate under the 40mbps of the spec.
And IIRC about 2 or 3 with max bitrates above 50mbps. The limit of level 4.1.

Your assumption is incorrect. A level specifies minimum necessary support. Any hardware spec can go beyond a strict level requirement, or throw levels out altogether, the hardware spec is the only thing that matters. The bluray specs aren't even public, so real VBV values required to even get a valid max bitrate for that purpose are only guesses at this point.

[Audionut]

Your assumption is incorrect.

On the contrary, the wiki clearly states, Max video bitrate for given levels. Max frame size, Max macroblocks per second.

How accurate the wiki is though, is anyone's guess.

A level specifies minimum necessary support.


A level is a specified set of constraints imposed on values of the syntax elements in the bitstream. These constraints may be simple limits on values.
Alternatively they may take the form of constraints on arithmetic combinations of values (e.g. picture width multiplied
by picture height multiplied by number of pictures decoded per second).

http://forum.doom9.org/showthread.php?t=138967&highlight=levels
http://akuvian.org/src/x264/ITU-T_H264.pdf.gz

[Guest]

Guys, I'd like to ask you to please take this to a new thread or PM. Thank you.

[Guest]

Some good news...

My local build is working with MEGUI. This is not the server version but rather just based on the current code but implementing a single D3D instance shared by floating contexts, as recommended by Nvidia.

I want to do a little more testing before releasing a beta for testing.

MEGUI does some real goofy stuff internally. It opens the script 7 times for a simple 2-pass encode!

[ultratoto14]

Fantastic news, this is what we need. Thanks for your great work neuron2.

[G_M_C]

[...]It opens the script 7 times for a simple 2-pass encode!

7 times :eek:

Might be time for me to automate things another way, without Megui :o

[rack04]

Some good news...

My local build is working with MEGUI. This is not the server version but rather just based on the current code but implementing a single D3D instance shared by floating contexts, as recommended by Nvidia.

I want to do a little more testing before releasing a beta for testing.

MEGUI does some real goofy stuff internally. It opens the script 7 times for a simple 2-pass encode!

Great news Donald. Well done.

[tre31]

Some good news...
MEGUI does some real goofy stuff internally. It opens the script 7 times for a simple 2-pass encode!

Dare I say it - yes I will, bit sloppy, even though I use MeGUI myself and like it, but 7 times, fair enough I could understand - once for the preview, and a few for the encode (depending on no# of cores), but that exceeds even that amount (would be 5 in a quad core machine). There is no reason too even have the preview open while encoding anyway .. and sorry neuron2 I know you want too keep the thread clean.

[screw]

Some experience with DGAVCIndexNV on NVIDIA Quadro NVS140M (Lenovo T61 notebook).
Although there is no certain info about V2 existence on this chip on NVIDIA site, I did give a try, since my previous attempt with GeForce 8800GTS failed (I had to read all discussion thread more carefully).

Well, back to Quadro NVS 140M - it works but not on full HD resolution. I could run DGAVCIndexNV on smaller sample videos:
720x400 ~ 200 FPS in preview mode,
1280x720 ~ 90 FPS.
When I did try to open 1920x1080 clip, DGAVCIndexNV fails to initialize video decoder:
"GPU decoder: Failed to create video decoder (100)"
Possibly it is some limitation of chipset, although DXVAChecker does report ability to decode H.264 up to 1920x1080.

Another issue - did try to encode to something else (Xvid, MPEG-2). Xvid went fine (I did use VirtualDub on .AVS script), but CCE SP2 Trial did fail with Exception 0xC0000005 in all attempts. Any ideas what might be the reason for this CCE crush?
The same clip when used with DGAVCIndex (libavcodec) and DGAVCDecode works normally on CCE.

Added later info 19.10.2008:

I did try also encoding to MPEG-2 with HC_enc (0.23) and QuEnc (0.72). Both failed exactly the same way - Exception 0xC0000005.
Can anyone report the success with MPEG-2 encoding if DGACVDecodeNV is used in .AVS script?

[Comatose]

Dare I say it - yes I will, bit sloppy, even though I use MeGUI myself and like it, but 7 times, fair enough I could understand - once for the preview, and a few for the encode (depending on no# of cores), but that exceeds even that amount (would be 5 in a quad core machine). There is no reason too even have the preview open while encoding anyway .. and sorry neuron2 I know you want too keep the thread clean.
I think it opens that many times to check for Avisynth errors before every step, so it can display them to you instead of x264 returning an error and all you get is "error" in the Queue tab.

[tre31]

I think it opens that many times to check for Avisynth errors before every step, so it can display them to you instead of x264 returning an error and all you get is "error" in the Queue tab.

Apologies again neuron2 (why is it your threads get hijacked - I guess its good that your work provokes discussion ;) )
----
I was under the belief that x264 can output too sout and serr (standard out and standard error streams) so therefore there isn't really a need for the extra as MeGUI could just monitor those streams and do whatever it wants with the info (it does already with the fps, time, etc), so it really doesn't justify extra avisynth processes running just for monitoring (actually it doesn't make much sense at all too me). Then again I haven't looked at the MeGUI code, so I may just be spouting crap. :D

[kemuri-_9]

sorry for helping the hijack here...

x264 writes the log information (debug, info, warnings, etc. depending on the level of info you want: see --verbose and --quiet) to stderr by default, and the code is hardcoded for that, so it can't output video data to stderr.
x264 can write to stdout though by specifying the out file as -

the thing is iirc,
A. megui already monitors the stderr stream for displaying the progress statistics and x264 error/info within megui
B. I don't recall megui natively supporting x264 writing to stdout, it wants x264 to write to a file.
C. megui handles more programs than just x264, so i believe point B is related to not all the programs it deals with having stdout support.

i have only a vague idea why megui would open the avs script that many times as i don't use it regularly; that would be to check the video parameters (AR, FPS, etc.) and then from opening it, it would find errors.
But of course this is just speculation within reason. would have to ask Sharktooth on why it actually opens that many times.

so a bit back on topic...
hows the progress on testing that floating context version build coming along?
because honestly once that stabilizes the whole multiopening conflict within megui and any other encoding programs, the problem becomes moot.

[Guest]

hows the progress on testing that floating context version build coming along? The floating context solution ran into problems. MEGUI starts a new thread for each frame request! That severely stresses the CUDA context switches. In addition, there were unexplained crashes that I could not debug due to lack of source code for nvcuvid.dll.

But there is good news. I went back to my server idea and just tonight completed the implementation of DGAVCDecodeNV based on the client-server model. It works just fine and MEGUI works without issues.

Interestingly, a global mutex was not required because MEGUI is well behaved about closing the script each time before re-opening it again. I may add one later anyway, but it's not required to support MEGUI.

I hope to roll this out tomorrow evening after doing a code review. I also plan to release the source code for the server as well as a primitive GUI client (though not the source code for DGAVCDecodeNV). That will enable other people to use the CUVID decoder in their own applications.

[lexor]

Neuron, I was following the CUDA dialogue you keep track of on your site with interest, and I was wondering if the code provided by NVidia engineer (NV12->YUY2) is under any form of licence or if it's otherwise inadvisable to just take it from there and use it. Also if it is free-for-all kind of a deal, your last recorded message reads that you are using an updated version of that function. Is that the second one posted there, or have they sent you an even newer one?

Thanks.

[Guest]

Neuron, I was following the CUDA dialogue you keep track of on your site with interest, and I was wondering if the code provided by NVidia engineer (NV12->YUY2) is under any form of licence or if it's otherwise inadvisable to just take it from there and use it. Also if it is free-for-all kind of a deal, your last recorded message reads that you are using an updated version of that function. Is that the second one posted there, or have they sent you an even newer one? It's the second version in the dialog. I understand that it is not licensed. You may want to test the interlaced/progressive handling, as I have not done that yet.

[Guest]

Things are still bubbling. The thing is that ideally I'd like to be able to support a script like this:

a=AVCDecode("file.dga").reverse()
b=AVCDecode("file.dga")
interleave(a,b)

...which with a file of frames 0-95 would give:

95 0 94 1 93 2 92 3 ...

In other words, a script should support multiple independent AVCSource() instances. The script above worked with earlier versions of nvcuvid.dll when opening with VirtualDub. But now there are two problems:

1. Doing this with the latest nvcuvid.dll crashes. Nvidia has been informed.

2. It never worked with the managed apps like MEGUI, which crashed when trying to instantiate a second decoder instance.

Assuming that Nvidia can fix 1 leaves us still with 2. 2 can be fixed either with the server model (working fine) or the floating context model (working with issues probably solvable). But both these solutions preclude ever doing the multiple independent decodes, because only one decoder is ever instantiated.

It seems like a big loss to give up multiple instantiation. So I'm tempted to hold off on the server model rollout and work the issues 1 and 2 some more in hopes of solving them. But then users won't have a MEGUI solution in the meantime.

Or I can rollout the server now and perhaps have to abandon it later. One advantage of the server model is that the decoder code is always in one place and fixing bugs there, or adding features there, fixes all applications that use it. And the server model is simple and robust. So there's something to be said for the server model.

So I don't know what to do. :( Your thoughts will be appreciated. Is it really so bad to lose multiple instantiation?

[Sagekilla]

Why would you have to abandon the server model though? It seems like it has no disadvantages.

[Guest]

Why would you have to abandon the server model though? It seems like it has no disadvantages. I'd abandon it if issues 1 and 2 were solved because it cannot support more than one AVCSource() in a script (i.e., cannot support multiple instantiation). You could not do this, for example:

AVCSource("fileA.dga")++AVCSource("fileB.dga")

There is a way to support that with the server model by forcing every GetFrame() call to do a full decoder reset. But the performance would be horrible.

[Sagekilla]

Well #1 seems like it could be, or should be, a very simple fix -- something that nvidia can resolve for us (hopefully). MeGUI on the other hand.. Perhaps we can work with the developers to make it not crash.

Both seems completely solvable, just requires someone to actually do it. I wish I knew enough code to help on #2 :(

[Guest]

MeGUI on the other hand.. Perhaps we can work with the developers to make it not crash It's not MEGUI's fault. It's something to do with managed code. It's still a mystery.

[kemuri-_9]

hmmm.....
the server model works for megui for a single instantiation call, but not for several and the 'normal' method (once fixed) supports multiple instantiation....
then how viable would it be to have both?

Seeing at how there are the people who would like to do complicated multiple instantiation and then the megui users.

probably hitting an over generalization here:
but i would say that the multiple instantiation users will probably encode the file to a lossless with filtering they will perform, which they will then use that in megui
- removing the necessity for DGAVCDecodeNV withing megui.
and then the megui users generally want to straight-shot convert a single video.
- without multiple instantiation capability.

sure if they both worked simultaneously people would be foaming out of the mouth in joy,
but hey if it absolutely requires two versions, i think people could live with that; we should be happy to get anything at all.

As for the file concatenating idea, what cuda restrictions are there in place to prevent you from doing
so within the project .dga and only having one AVCSource() call (like DGAVCIndex and DGIndex)?
is there any chance of getting it worked out with nvidia, or is it an absolute no-go?

- mp4box's stream concatenation feature can be used for files that have the same properties as a workaround for that if it doesn't ever work out....

.... geh, what a wall of text :<

[tre31]

hmmm.....
the server model works for megui for a single instantiation call, but not for several and the 'normal' method (once fixed) supports multiple instantiation....
then how viable would it be to have both?


Different solutions for different problems, perhaps once you do get a working nvcuvid.dll again, just have that for people who want multiple instancing, and they can encode manually via cmd line, and for the MeGUI folk use the server model.

Alternatively perhaps keep the code managed so that both can be contained within the same app even but selection via options/preferences too keep it all in one app rather than dividing it up based on what the end user wants too do, better too keep it in one imho (but may mean some code repetition - but honestly who's worried about memory/storage space these days on recent machines).

Just an idea...
----
edit: Just make sure that its documented (hell even well tool-tipped) what the difference's are and whats best for what use.

[Quark.Fusion]

Storage is still matters — shadow copies for example can eat space pretty fast if you will do massive writes. That requires separate storage for temporary data — it's not something that comes for free.

Memory also heavily matters in 32-bit apps, fft3dgpu for example eat allocation space in that way, so it's not possible to use it two times on HD content. If you add memory requirement for encoding and decoding, mvtools processing, etc — you will suffer from insufficient address space. (Sorry for my english)

[tre31]

Storage is still matters — shadow copies for example can eat space pretty fast if you will do massive writes. That requires separate storage for temporary data — it's not something that comes for free.

Memory also heavily matters in 32-bit apps, fft3dgpu for example eat allocation space in that way, so it's not possible to use it two times on HD content. If you add memory requirement for encoding and decoding, mvtools processing, etc — you will suffer from insufficient address space. (Sorry for my english)

Your english is fine, however I think you misunderstood what I meant, what I actually meant was - the size of the executable will increase, hence it will initially consume more memory as it has too be loaded into memory too be executed, as for the actual size of memory it consumes that won't really change as it is only executing either one or the other options (one being multi-instancing, the other being server based).

Anyway its up too neuron2, I was just offering an idea that encompases both, since both seem too be valid solutions too different problems. :)

[Guest]

Actually, it turns out that AVCSource()++AVCSource() works fine with the server because the uses of the decoder are serialized. It's only when you interleave their usage that problems arise. So I'll go ahead and release the server version tonight.

[Sagekilla]

How odd.. I don't suppose most people would realistically use two sources interleaved, would they?

[Quark.Fusion]

Overlay? Can be used in game video recordings for example. (using x264 instead of lossless as intermediate format before editing)

[Guest]

OK, I'm rolling out the server version. Nvidia already fixed problem 1 described above but problem 2 remains intractable for now. Some notes:

* I strongly recommend killing the MEGUI preview before starting the encode. You can leave it open if you want to be perverse, but if you navigate in it after starting encoding, kiss your life goodbye. And don't say I didn't warn you.

* DGAVCIndexNV still uses a built-in GPU decoder; the server does not have to be active. But again for the same reason as above, kill DGAVCIndexNV before trying to execute scripts.

* Don't even think about writing a script that in any way interleaves access to multiple instances of AVCSource(). It's OK if they are serialized, e.g., AVCSource()++AVCSource(). Note that normal PureVideo bobbing without multiple instances is coming.

* The server is licensed, so either put it in the same directory as DGAVCIndexNV.exe, or put a copy of your license.txt file with its executable.

* Tomorrow I will release a basic server client with source code, so that you can use the server in your own applications.

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

[blubberbirne]

great work. but i have some problem with megui. i encode some sample file. the encoded file don't play smooth. it lags

[Guest]

What have you done to try to diagnose your problem? I ask because you've given me nothing to go on. I doubt it has anything to do with DGAVCDecNV.

[blubberbirne]

oh sorry, have many work at the moment :( will test it more tomorrow.

I test some small Premiere HD Stream. I only load the dga project in avs script an encode it with dxva hq profile in megui. source file playes finde. but the encoded one has terrible lags.

and sorry about my english

[Guest]

Post a link to a sample of the encoded video that shows the lag. I want to see if it plays cleanly on my (fast) system.

[Guest]

I've released the sample client package with source code. It works with the CUVID Server contained in DGAVCDecNV 1.0.5. The package contains documentation for the CUVID Server interface. I would be interested in any ideas for improving the interface.

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

[crypto]

Thanks for making this available. I like the server concept and find it extremely interesting. Wouldn't this also be ideal to recombine the NV and non-NV lines of dgavcindex?

[Inventive Software]

No, because the license models are different.