DGAVCDecNV 1.0.13: GPU decoding on Nvidia

[meatwad]

Yes. I was just about to post that I believe it completes the encode, just the encoder doesn't close. In VirtualDub I can see the completed encode but I have to stop the encoder. If I stop X264 CLI when it hangs I can't view the video. Naturally I can't do any batch encoding running like this.

@Zwitterion: I've been using this one from the CUDA page NVIDIADisplayWinVista(177_84)Int.exe, I believe I tried the regular driver as well since others have said they used it without any issues. I'll try it again before I move the card to another system.

I really appreciate everyone's help with this. Sorry I'm such a pain DG.

Update: I just found that if I seek to the end and then go back it locks up VirtualDub.

[meatwad]

I just tested with 178.13_geforce_winvista_32bit_english_whql.exe installed and I'm still getting the same results.

[meatwad]

I found what was wrong, it doesn't like my avc .ts streams. It will work with other avc sources but not my transport streams (even if they're demuxed). Neuron2, could you please add support for them in a future release? I'll send you all the samples you need.

They're all I really work with. I would forever be in your debt if you could also get it to decode the same type of avc streams in .vdr (video disk recorder) format.

Also, were you able to get the sample to encode with vdub or x264 cli?

[Guest]

Originally Posted by meatwad

Also, were you able to get the sample to encode with vdub or x264 cli?

I am able to duplicate your issue with the file that you provided. So I'll try to fix it today.

EDIT: OK, I know what is happening. When you hit EOF the decode thread is waiting for a signal from the decoder to say that a requested frame is available, but the EOF processing doesn't send that signal to allow the decode thread to terminate. I don't know why it was happening only on these streams, but it's a design issue, so I'll release an update ASAP.

[meatwad]

You are far and above the cut. Thank you so much for addressing the issue. I've included a link to a sample avc .vdr file so you can see the similarities. They are a pain to work with, unlike the mpg version (just rename the files to .mpg and they'll work with most anything). Linux gurus probably eat them for breakfast, but it takes me several steps to get a finished .mkv file. The streams inside the vdr file should be the same make as the transport stream sample.

http://www.zshare.net/download/200884986b8c802a/

If you don't have the time to look at the sample don't worry about it. Just fixing the transport stream issue is more than enough.

Once again, thank you for making such a wonderful product.

[Casimir666]

@neuron2
Marc99 post a message on the mpc-hc thread that puzzle me :
http://forum.doom9.org/showpost.php?...postcount=4468

The weird things is that VSFilter is not supposed to be compatible with DXVA for 2 reasons :
- IMediaSample::GetPointer is not supposed to return buffer (because it's DX Surface)
- Video decoder cannot initiate the DXVA negociation with EVR (because of intermediate filters)

But marc99 screenshot show that mpc detect H264 bitstream mode. Mpc-hc show this only if :
- Someone ask interface IDirectXVideoDecoderService on the EVR
- Someone successfully call IDirectXVideoDecoderService::CreateVideoDecoder


So I have a small question for you : are you using the IDirectXVideoDecoderService interface one way or another in your AVISynth filter (asking to EVR filter or using Media foundation)?

[Guest]

Originally Posted by Casimir666

So I have a small question for you : are you using the IDirectXVideoDecoderService interface one way or another in your AVISynth filter (asking to EVR filter or using Media foundation)?

No. If you follow the Nvidia development dialog at my website, you'll know exactly what I am using.

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

[Casimir666]

Originally Posted by neuron2

No. If you follow the Nvidia development dialog at my website, you'll know exactly what I am using.

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

Ok thank you for you answer, it's a really interesting dialog.

[Guest]

@meatwad

Your issue has made it to the Nvidia development dialog, as it appears to expose a regression in nvcuvid.dll. Scroll to the bottom of the dialog and you'll see the analysis.

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

[meatwad]

I was hoping it was going to be something minor, but I have faith they'll come through. You were right about Nvidia being extremely helpful. It's in their best interest after all as it will help them sell more GPUs (and I'm proof of that).

[Pookie]

@meatwad - sounds like the same problem I was experiencing -

http://forum.doom9.org/showthread.ph...58#post1186758

[Guest]

Oh, I'm glad you reminded me about that. I have meatwad's stream working and just now tested with yours and they're not yet fixed. Investigating...

[Guest]

OK, Pookie, I've figured out the problem with your streams.

The stream is sending a lump of 8 PPSs every so often. When I seek, though, I was just injecting the previous 5 known PPSs, so the decoder was silently discarding the frames with orphaned PPSs, and when I reached the end of the stream, my app thought there were more frames to come but the decoder couldn't provide any more. I have to rethink my heuristics for SPS/PPS injection on a seek. For now I've bumped it to inject the last 15 prior to the seek point. I should be able to think of something a little more intelligent, however, as I do have the stream indexed at that point and know about all the PPSs.

I spent two days being confused because I thought the problem was caused by end of stream handling when all along it was caused by start of stream handling!

Also, Nvidia has delivered a new nvcuvid.dll with better performance and some bug fixes. So I'll make a release tonight with that, the temporary PPS fix, and the fix for meatwad. That should keep us going until I redesign the SPS/PPS heuristics properly.

[Guest]

1. Fixed an uninitialized variable in the CUDA parser creation that could cause random suboptimal decoding performance.

2. Changed handling of NALUs with forbidden_zero_bit set. They are now silently discarded.

3. Fixed a problem that could cause a stream to not be properly flushed on end of stream, which in turn could cause DGAVCDecNV to hang.

4. Fixed D3D device object leak for XP.

5. Improved the heuristic for SPS/PPS injection when seeking. This fixes some other cases of hanging at the end of the stream.

6. Added a safety timeout for end of stream hangs (although I think they are all solved now).

7. Updated the Nvidia Development dialog at my web site.

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

I'm still working on compatibility with managed applications, i.e., the COM server solution.

[Guest]

Originally Posted by meatwad

I've included a link to a sample avc .vdr file so you can see the similarities. They are a pain to work with, unlike the mpg version (just rename the files to .mpg and they'll work with most anything). Linux gurus probably eat them for breakfast, but it takes me several steps to get a finished .mkv file. The streams inside the vdr file should be the same make as the transport stream sample.

Do you have any information on what these VDR streams are inside, i.e., specs? What do you use to demux them?

[meatwad]

I've been using elecard xmuxer. I'll post a link with a sample already demuxed.

[Guest]

I don't need the demuxed sample!

Testing Elecard now, standby...

[Guest]

Hmm, Elecard works, but I can't recognize the file type in my hex editor.

[meatwad]

Unfortunately I don't have a clue either. I've asked in some Linux forums but no one responded. I'd probably just put this on the back burner as you have much bigger fish to fry with all your other projects. Besides, I'm looking forward to your avc cutter and you've already done more than enough for me in the last few days. Thanks again for the fix and I'll test it out later tonight.

[Guest]

Ah, OK, it's PES. I can handle that. I'll put it on the container to-do list with MKV and MP4.