DGAVCDecNV 1.0.13: GPU decoding on Nvidia

[JungleBoy]

Subject: Variable audio delay in BBC HD TS files (ITV HD TS files are probably the same).

I've taken 4x30 second samples from a 1 hour BBC HD programme and put them through DGAVCIndexNV.
The audio delay value (in the ac3 filename) comes out at -1104ms, -1016ms, -1072ms and -800ms.
If I run the 1 hour TS file through DGAVCIndexNV the audio delay comes out with -1104ms (same as the sample from the start of the programme).
I just wondered if you were aware of this. Maybe DGAVCIndexNV could use the average audio delay.
This might be related to the recent change over of the BBC HD encoders where the audio delay has shot up from about -50/-70ms to around -1000ms. I can send links to the TS samples if you want to check.

[Guest]

When joining such files you may have to fix up the possible audio/video gaps at the junctions between files. You can either demux using DGAVCIndexNV as usual and then fix up the audio stream using my tool Joints, or you can demux the audio using EAC3TO, which will fix up the gaps during demuxing.

But with EAC3TO, you cannot do this with the -demux option; you have to use the track decoding syntax, as explained in the Joints thread.

[nautilus7]

I 've been reading some posts regarding using eac3to, so here (http://en.wikibooks.org/wiki/Eac3to/How_to_Use#Using_complete_disc_structure_as_input)'s the wiki page (it's been a while since i last updated it, but this part is ok).

[st0niMah0ni]

Hello people.

I get a error message for 3 days now, it dosnt matter what i try I can´t encode the last days with NV versions of dgindex.

cuvid picture decode () error

thats what I allways get, and the time when it happens again is allways random.

It would be so nice to fix this.
Maybe you know a solution?

I´m running 1.04 if cuda server

[Guest]

What is your source file? Can you post a link to a sample that causes this problem?

What Nvidia card are you running and with what Nvidia driver version?

[st0niMah0ni]

Hey Neuron, thx for your reply.
It doesnt depend on the file, it happened now with 3 different files,
two of the encodes crashed with this error in the 1.pass, but they ran fine when I startet it again.
The latest one crashed in 2nd pass. And this happened now 4 times.

Nvidia Card 9800 Pro GT

Driver Version : 190.62

Running Windows-7 32-bit OEM.

It was fine for 2 month now. but since a few days I cannot encode anything running cuvidserver.exe

Sometimes it crashes without any message and I just recognize it by watching the cmd window and it just get stuck....

When I look in the Taskmanager after there is no Cuvidserver.exe running anymore...

I think the problem is more on my side but I dont know anything about this error , it could be so much.


P.s. You edited my 1st post with the reason : rule 4

what did I wrong? I didnt say any disrespectfull word?

[laserfan]

It was fine for 2 month now. but since a few days I cannot encode anythingSimple fix: System Restore to before, when it worked.

[Guest]

If it were me, I would remove and reinstall the NVidia drivers.

Also, just play your script with VirtualDub and see if that crashes. The idea is to know if your encoder GUI is doing something funny. Which one are you using BTW?

(Regarding the rule 4 edit, you used superfluous profanity. Followup to PM if you need to discuss it further.)

[st0niMah0ni]

@ laserfan

sorry pal but thats a solution I will not think about or even care about.It was fine until last week,this machine is as it is.
There is no changes in Hardware or Software for monthes.

I am not going to roll back my system


If it were me, I would remove and reinstall the NVidia drivers.

Also, just play your script with VirtualDub and see if that crashes. The idea is to know if your encoder GUI is doing something funny. Which one are you using BTW?

(Regarding the rule 4 edit, you used superfluous profanity. Followup to PM if you need to discuss it further.)


I am using x264 latest build from techouse @ x264.tk
32-bit.

My scripts allways play fine, I use them also in AVSP.

I Will try to get some "old" nvidia drivers and will test it then, but now the encode is running with directshow source, I need to wait about 18 hours.

I will post my reply then. thx for help

[darcmage]

Just got the license today and I've been trying a few things out. I've noticed some strange things that hopefully someone can help me out with.

System:
Q9400
2GB Ram
Nvidia 9800GT (191.03)
Windows 7 x86
Avisynth 2.58
x264.exe r1271
Source: 10min 1920x1080 interlaced clip from Hauppauge HDPVR

AVS Script
LoadPlugin("D:\DGAVCNV\DGDecodeNV.dll")
DGSource("E:\Capture\test1.dga", deinterlace=1, resize_w=1024, resize_h=576)

Batch file
x264.exe --profile high --crf 27.0 --level 4.1 --keyint 300 --min-keyint 30
--ref 2 --direct auto --deblock -1:-1 --subme 5 --trellis 0 --partitions
p8x8,b8x8,i4x4,i8x8 --vbv-bufsize 50000 --vbv-maxrate 50000 --thread-input --output 1.mp4 1.avs


When I first tried out the encode, I was getting nearly 17fps which was much better than the 9fps I was getting with the regular DGAVC. I noticed my CPU usage wasn't as high as it could be so after a search here, I updated to the latest x264 and saw the encoding speed jump to 26fps.

On my next test, the speed dropped back down to 17fps. :confused:

I couldn't reproduce the 26fps until I started messing with EVGA Precision (Rivatuner clone). I activated my gaming preset (650/1625/950) and the fps jumped to 49fps! All other clockspeeds would result in 20fps max.

I decided to try lowering the resolution.

AVC Script
LoadPlugin("D:\DGAVCNV\DGDecodeNV.dll")
DGSource("E:\Capture\test1.dga", deinterlace=1, resize_w=640, resize_h=368)

Batch file
x264.exe --profile high --crf 24.0 --level 3.1 --keyint 300 --min-keyint 30
--direct auto --deblock -1:-1 --subme 6 --partitions
p8x8,b8x8,i4x4,i8x8 --vbv-bufsize 14000 --vbv-maxrate 17500 --thread-input --output 1sd.mp4 1sd.avs

This would result in a maximum encoding speed of 49fps as well. A head-scratcher to me. I don't understand the dramatic drop in speeds with the various GPU clockspeeds and why a lower resolution wouldn't increase the encoding speed. Appreciate any help you guys can provide.
:thanks:

[Guest]

Scratching my head too but I'd be happy with an increase from 9fps to 49fps. :p

[darcmage]

Scratching my head too but I'd be happy with an increase from 9fps to 49fps. :p

Oh I'm definitely not complaining. Just trying to understand what's going on. I'm perfectly willing to accept the situation as is.

[kemuri-_9]

back when i was testing out Donald's NV tools and the CUDA renderer within the CUDA toolkit some many moons ago,
I found that the vp chip has a constant fps rate for all material and for all resolution sizes...

so decoding a 720x480 mpeg2 clip will have the same decoding speed as a 1920x1088 h264 clip does, despite the large differences these would have on a cpu.

i usually saw the render rate just under 50 fps on my VP2 card, so it coincides with your findings of 49 fps being the maximum.

[darcmage]

Thanks for the info. I've started working on the assumption that 49fps is the max and cranking up the quality options until I max the cpu while maintaining an acceptable encoding rate.

I did go through some instability involving various errors previously mentioned in this thread like the decodePicture() error and the cannot create display error when trying to use the dll found at neuron's site. I tried everything I could think of, installing different driver sets and various nvidia tweaking utilities. It wasn't until I copied nvcuvid.dll from the system32 directory to the CUVIDServer and DGAVCIndexNV directory that I've been able to encode without any errors. Hopefully that'll help someone in the future.

[Guest]

It wasn't until I copied nvcuvid.dll from the system32 directory to the CUVIDServer and DGAVCIndexNV directory that I've been able to encode without any errors. That's not necessary. Just leave the Nvidia installed DLL where it is and do not use any DLL from my site.

Hopefully that'll help someone in the future. That also shouldn't be necessary, if they read my clearly written readme file, as you have apparently did not do.

[darcmage]

I should have clarified that part. I was experiencing the cuvid picture decode () mentioned above which would crash the display adapter and lock the clockrates on power saving mode until I restarted. This happened before I knew about nvcuvid and nothing in the readme addresses this.

I came here looking for a solution and found one of your previous posts mentioning using your dll in the dgavcnv directory and that's when I started getting the Failed to create video decoder errors. I thought maybe I should replace the system32 dll with yours but decided to try using the newer system32 dll in the dgavcnv directory instead and have been stable ever since.

[Guest]

I'm saying that if you followed the readme from the beginning, i.e., use the specified version of the Nvidia driver and do not use any special nvcuvid DLL, then you wouldn't have run into any of the problems you created for yourself.

[darcmage]

From the readme:
You must install version 190.62 or later of the Nvidia driver


Nvidia 9800GT (191.03)

Again, the cuvid picture decode () errors started happening before any knowledge of nvcuvid.dll. I didn't have any other version other than the one installed by the driver.

[Guest]

And you say you fixed that how?

Did you have an old version of the nvcuvid.dll in your DGNV directory? That's the only thing that could explain how copying from system32 to there could have changed anything...it overwrote the old one.

So then we ask, why did you have an old one in there?

[darcmage]

And you say you fixed that how?

Did you have an old version of the nvcuvid.dll in your DGNV directory? That's the only thing that could explain how copying from system32 to there could have changed anything...it overwrote the old one.

So then we ask, why did you have an old one in there?

There was no nvcuvid.dll in the DGNV directory until I searched these forums for a solution to the first set of errors which resulted in the second set of errors.

Maybe it has something do with Win7. All I know is copying the nvcuvid.dll from the system32 dir to the DGNV dir seems to help and someone else with similar issues may want to give it a try.

[Guest]

If the DLL was not found you would have got that message and you didn't report that, so you must have been picking up some other copy of the DLL. So since you appear to be getting irritated with my efforts to get to the bottom of it, I will let it go.

[darcmage]

:eek:

I should have clarified that part. I was experiencing the cuvid picture decode () mentioned above which would crash the display adapter and lock the clockrates on power saving mode until I restarted. This happened before I knew about nvcuvid and nothing in the readme addresses this.

I'm saying that if you followed the readme from the beginning, i.e., use the specified version of the Nvidia driver and do not use any special nvcuvid DLL, then you wouldn't have run into any of the problems you created for yourself.

Again, the cuvid picture decode () errors started happening before any knowledge of nvcuvid.dll. I didn't have any other version other than the one installed by the driver.

Did you have an old version of the nvcuvid.dll in your DGNV directory? That's the only thing that could explain how copying from system32 to there could have changed anything...it overwrote the old one.

So then we ask, why did you have an old one in there?

There was no nvcuvid.dll in the DGNV directory until I searched these forums for a solution to the first set of errors which resulted in the second set of errors.

I would be happy to help you get to the bottom of this but you keep insisting on operating under the false premise that there was a conflicting version of the dll present despite my assurances to the contrary. I'm sure of this because I did a windows search for the file after downloading the one from your site which was still zipped. The only result was in the system32 dir.

[Guest]

Well, you don't acknowledge my argument!

If the DLL was not found you would have got a message to that effect. So it was found. If it was the correct one you wouldn't have any errors. Thus, I conclude that you must have been picking up the wrong DLL from somewhere. It may not be the DGNV directory. Search your entire hard drive for it.

[darcmage]

I'm sorry but there's nothing else I can say other than thank you for creating this tool for us.

[Guest]

Don't go away mad!

Try this. Take it out of DGNV and put it back into system32. What happens?

[darcmage]

I'm not mad. A little disappointed in how the conversation has deteriorated but not mad.

I never removed the original dll from the c:\..\system32 dir, just made a copy to the d:\DGNV dir which has so far prevented further cuvid picture decode () errors.

[JungleBoy]

Since the BBC HD changed their encoders over in August the audio is now transmitted either at 192Kbps 2 channel or 384Kbps 6 channel AC3. When demuxing a TS file with 192Kbps 2 channel audio (with either with DGAVCIndex or DGAVCIndexNV) the ac3 filename is created with 384Kbps 6 channel in the name. Media Info says the ac3 file is 192Kbps 2 channel.

I suspect the BBC HD TS stream is always set to 384Kbps 6 channel to prevent switch over problems which may confuse DGAVCIndexNV. When playing the ac3 file using either VLC v1.0.3 or MPC-HC v1.3.1301.0 (with ffdshow 3078) the duration shown is half the actual duration with a bitrate shown of 384Kbps. The audio sounds ok but the timer shown is wrong.

Muxing the ac3 file into the MKV works and no one would be the wizer. Media Info shows the MKV apparently containing 384Kbps 6 channel AC3 audio when it's really 192Kbps 2 channel AC3. Muxing the ac3 into an AVI causes the audio to be played back at double speed.

I've been using the latest version of Audacity (that supports AC3) to create an ac3 file with 192Kbps 2 channel before muxing with the MKV or AVI. A better way it seems is to put the TS file through tsMuxeR GUI to create M2TS. If the M2TS is put through DGAVCIndexNV the ac3 file comes out at 192Kbps 2 channel with the correct filename as well so no fiddling is needed with Audacity.

Another question.
If the TS file contains continuity errors I assume it's better to create M2TS as I understand it contains timing information.
When demuxing the audio from the TS, compressing the 264 and re-muxing the video and audio into MKV or AVI, lip sync errors can often be seen after a continuity error as occurred especially with AVI files.
Will this lip sync error be prevented/reduced if M2TS is fed into DGAVCIndexNV rather than the raw TS file ?

[Guest]

Since the BBC HD changed their encoders over in August the audio is now transmitted either at 192Kbps 2 channel or 384Kbps 6 channel AC3. If you want me to look at this you'll have to provide a transport stream sample that I can use to duplicate the issue.

If the TS file contains continuity errors I assume it's better to create M2TS as I understand it contains timing information. It means there are missing packets in the stream.

Will this lip sync error be prevented/reduced if M2TS is fed into DGAVCIndexNV rather than the raw TS file ? No.

BTW, I recommend upgrading to DGNV tools version 2.0.0b2.

[paulvdb]

I think the cause of JungleBoy's BBC HD audio bitrate problem is probably that he catches a small fragment of 384 kbps audio at the beginning of the programme before it switches to 192 kbps.

[Guest]

Yes, that is probably true. With a sample I could verify it. The issue of changing audio is on my to-do list, BTW.

[JungleBoy]

paulvdb is correct.

I edited the TS to give just the first minute and put this through DGAvcIndexNV - out comes 384Kbps 6 channel.
I then did almost the exact same thing except instead of starting at 0.00 sec I edited out the first 'I' frame (started at 0.76 sec). This time DGAvcIndexNV creates a filename with 192Kbps 2 channel.

So the switch over is occuring sometime during the first 'I' frame. I think I'm starting the cut too early when editing. I usually start the cut during the black bit just before the programme starts. I'll try cutting on the first frame with a picture in future.

I created 12 second versions to keep the file size down.

file1.ts (14.34MB - First 12 seconds)
http://www.mediafire.com/download.php?mny2mvn24jq
Creates audio file "file1 PID 157d 3_2ch 48KHz 384Kbps DELAY -1095ms.ac3"

file2.ts (13.38MB - First 12 seconds but with first 'I' frame removed)
http://www.mediafire.com/download.php?zfz4jedzyiw
Creates audio file "file2 PID 157d 2_0ch 48KHz 192Kbps DELAY -1087ms.ac3"
-----
I just replicated the same problem with another TS file.
This time I cut on the first picture (not the black picture) and created the TS file.
I then created the ac3 using DGAvcIndexNV - it created a filename with 384Kbps 6 channel.
The ac3 filesize was about 80Mbyte for 1 hour - a sure sign that the file is actually 192Kbps.
Media Info confirmed that it was 192Kbps 2 channel.

So I repeated what I did before - create 2 TS files from the start with the second having the first 'I' frame removed.
The first file created 384Kbps in the name - the second (with the first 'I' frame removed) created 192Kbps.

The switch over is definitely within the first 'I' frame period immediately after the first picture frame.
It's probably a bug or a feature of the new BBC HD encoders.

I'll carry on either using the Audacity or cut after the first 'I' frame.

[DonDan]

Don't think I have posted to this thread before, so first: Big thanks for this fine piece of software that finally allowed me to handle interlaced VC-1, or crap as I call them, sources ;)

Of course the fact that you see me posting here might have given it away: I ran into a problem now.

I am encoding a set of episodes from the same series and one episode keeps giving me this error in the same place: "GPU decoder: Failed to create video decoder (100)"
I will 99.99% exclude a corrupt source file (as in data corruption on my harddisc) as I could reproduce the issue on another PC and also had a friend confirm the issue on his own machine.

I have cut the part of the m2ts that is giving the error. It is short enough to be considered a quotation from the original, so sharing the file here should be entirely legal: http://www.mediafire.com/?zjm4jyywmdl

Hope you can a) use my sample and b) diagnose anything else then a blip in production ;)

[Guest]

@DonDan

Well first it's VC1 and you're posting in the AVC thread! Let's overlook that.

There is corruption in the stream that causes the video parser to request the GPU to create a decoder for an insane-sized frame and it errors out. I added a check to reject new sequences unless they have a proper frame size. This allows the clip to continue but you'll have errors. I'll put this in the 2.0.0 beta 4.

May I ask where this stream came from? If it's from a bluray I'm surprised that it is errored. It also has irregular pulldown, which I've never seen on a bluray or with VC1.

[DonDan]

Damn, you are right, I beg you pardon Sir ;)

It is indeed from a Bluray (I could get ahold of the german retail as to my knowledge there is no other release yet).
It must be a mastering issue then, as I reripped it from another disc only to get the exact same issue.

Thanks a bunch for the quick fix!

[crl2007]

I see that now it is only one program, DGDecNV 2.0.0 beta 3. I'm interested in purchasing this, but in megui I've seen that it has spaces for DGAVCIndex(NV), DGVC1Index(NV) and DGMPGIndex(NV). So, if I buy this, how should I proceed ?

[Guest]

MEGUI died when you weren't looking (or let's be charitable and say it is in death throes but recovery is not completely impossible -- I'd love to be wrong about it but where are the positive indications?). You proceed by using other GUIs such as StaxRip that have been updated for recent DGNV support, or you use the CLI interfaces. Lord_MuldeR's simple GUI also works fine with DGNV.

[crl2007]

Thx for your reply. I saw on their development site that some software was updated there on the 25th, this month. There is still hope. Or, at least, I'm still hoping.

[Guest]

OT discussion of DGAVCDec (the non-NV version) was deleted.

This thread is closed as it is superceded by DGNV tools 2.0.0.