View Full Version : DGAVCDecNV 1.0.13: GPU decoding on Nvidia
Guest
9th December 2008, 23:44
Source sample needed?
Yes, please. I need to be able to duplicate your issue.
HymnToLife
10th December 2008, 00:28
Hmm, big thread is big, what is the correct method to cut a sample from the TS?
Guest
10th December 2008, 00:39
You can split it into pieces using DGSplit, for example.
HymnToLife
10th December 2008, 01:48
Is setting start and end points in DGAVCIndexNV and then choosing "Save and demux video" a good way to get a stream sample? (the problem is reproductible with a stream obtained that way.)
Guest
10th December 2008, 05:34
Certainly, that is fine if it allows me to duplicate your issue. Please provide a link to the stream and the script and instructions for duplicating the issue. I'm very keen to address issues with random access, as it is the raison d'etre of the DG tools. Thank you for your willingness to help with debugging.
HymnToLife
10th December 2008, 06:44
http://itsuki.fkraiem.org/stuff/tokikake_cut.avs.demuxed.264
Create DGA file normally, then make an AVS script like this:
DGAVCDecodeNV_AVCSource("blah.dga")
Trim(90, 0)
and open in VDub.
(EDIT: Note the key point is accessing at frame 90, the problem does not happen with e.g. Trim(89, 0).)
Guest
10th December 2008, 15:12
Thank you.
The encoding is very unusual and I'm not yet sure it is fully legal. Where did this stream come from?
HymnToLife
10th December 2008, 23:11
Thank you.
The encoding is very unusual and I'm not yet sure it is fully legal. Where did this stream come from?
Original Japanese Blu-ray.
Guest
11th December 2008, 01:01
Interesting. The POCs are goofy in the stream (i.e., wrong) and I'm tempted to simply say that the stream is wrong. But there is a way to fix it. Instead of looking at the POCs of the first two pictures of the GOP to decide if it is open, I can look at the picture types. I've tried it and it fixes the problem so I'll probably go with that. I'm porting the AV sync fixes and I'll include this with the next release if it doesn't break anything else.
HymnToLife
11th December 2008, 02:24
Other small question: is it safe to work on a DGAVCDec (non-NV) script in VDub while there is a DGAVCDecNV script encoding?
Guest
11th December 2008, 04:07
Is it safe to work on a DGAVCDec (non-NV) script in VDub while there is a DGAVCDecNV script encoding? As long as you are working on different files. You wouldn't want to rewrite the DGA file while the decoder is using it. :)
Guest
12th December 2008, 21:19
I have noticed a discrepancy in the description of the detected audio streams from the audio demux and the audio section of the information panel. I have fixed this problem. The fix will be in the next release
BTW, is it possible to give these appropriate names, i.e. DTS Master Audio, TrueHD? If someone can tell me how to detect those audio types, I can probably do it.
madshi
12th December 2008, 23:42
If someone can tell me how to detect those audio types, I can probably do it.
This is with m2ts container, right? If so, you can use the stream type:
0x03: MP2 (MPEG-1 Audio Layer II)
0x04: MP2 (MPEG-2 Audio Layer II)
0x0f: AAC (MPEG-2 Part 7 Audio)
0x11: AAC (MPEG-4 Part 3 Audio)
0x80: LPCM (only if format id descriptor is 'HDMV')
0x81: AC3
0x82: DTS
0x83: TrueHD+AC3
0x84: E-AC3
0x85: DTS-HD High Resolution
0x86: DTS-HD Master Audio
0x87: E-AC3
0xA1: E-AC3 (secondary audio)
0xA2: DTS Express (secondary audio)
Guest
13th December 2008, 00:04
Thank you, rack04 and madshi.
Guest
13th December 2008, 00:13
Also, would you gents happen to have M2TS samples with these new audio types?
nautilus7
13th December 2008, 00:45
0x83: TrueHD+AC3 http://www.sendspace.com/file/miye0c
0x86: DTS-HD Master Audio http://www.sendspace.com/file/eoboij
0x84: E-AC3 or 0x87: E-AC3 http://www.sendspace.com/file/08wkhg
I will upload samples with the ids below tomorrow.
0xA1: E-AC3 (secondary audio)
0xA2: DTS Express (secondary audio)
Guest
13th December 2008, 01:09
Thank you!
rica
13th December 2008, 02:03
DTS-HD-HR into m2ts container:
http://www.mediafire.com/?sharekey=610f03b89c15442e91b20cc0d07ba4d26a1f79f1876d365a
You will find the modified pcm by Pcm2Tsmu and raw pcm under the same folder. (audio.pcm is raw and audiopcm_out.m2ts is modified by Pcm2Tsmu)
Guest
13th December 2008, 02:06
Thank you!
moviefan
13th December 2008, 19:11
Just for curiousity, neuron2, have you planned creating a GPU based decoder for H264 and VC1 for ATI cards, using ATI's stream API? I would be very interested in that and I assume a lot others who own ATI graphics cards.
Sulik
13th December 2008, 20:00
@moviefan: I don't think ATI's Stream API provides any video-decode-related functionality.
CruNcher
13th December 2008, 20:39
i wouldn't say so though if UVD will be accessible we gonna see December 16, but it would be bad in public if it wouldn't as Nvidia provides it for Windows same as for Linux :)
Though sure Ati could decide only Licensed 3rd Party ISVs but why should they makes no sense except if they cant provide a secure way to the UVD part without interfering with Blu-Ray security :)
Guest
14th December 2008, 02:39
DTS-HD-HR into m2ts container:
http://www.mediafire.com/?sharekey=610f03b89c15442e91b20cc0d07ba4d26a1f79f1876d365a Are you sure? Looks like DTS HD Master Audio to me.
rica
14th December 2008, 03:53
Are you sure? Looks like DTS HD Master Audio to me.
No, i'm not sure.
Looks like MA:
http://bluray.highdefdigest.com/1416/27dresses.html
But eac3to gives this information:
[C:\>eac3to\eac3to E: 1)
M2TS, 1 video track, 5 audio tracks, 19 subtitle tracks, 1:50:49
1: Chapters, 25 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Hi-Res, English, 5.1 channels, 24 bits, 3018kbps, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
4: DTS, Italian, 5.1 channels, 24 bits, 768kbps, 48khz
5: DTS, Spanish, 5.1 channels, 24 bits, 768kbps, 48khz
(Btw PowerDVD gives the same info...)
While it gives this info for Close Encounters BD:
C:\>eac3to\eac3to E: 1)
M2TS, 1 video track, 2 audio tracks, 20 subtitle tracks, 2:17:13
1: Chapters, 20 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 448kbps, 48khz)
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
Guest
14th December 2008, 05:12
Hmm, strange. Maybe you should ask madshi about it.
nautilus7
14th December 2008, 13:59
I really think eac3to gives the correct format. It's very precise.
EDIT: rica, what is this sample (audio.dtshd.m2ts)? Is this a remux? Using tsmuxer perhaps? Maybe that buggy program uses wrong id for the audio track. Send a sample from the original file. If you are willing to help, please send original samples.
(neuron2, the samples i promised will be up soon. Do you want them to have VC-1 video only? You will add these changes to your other apps as well, correct?)
Guest
14th December 2008, 14:51
(neuron2, the samples i promised will be up soon. Do you want them to have VC-1 video only? You will add these changes to your other apps as well, correct?) I'm working on DGAVCDec(NV) right now, so I prefer AVC at this point. But I'll happily accept samples with VC-1 too. Yes, I will update the other apps next. I was hoping to release something today, so it would be helpful if you could upload your samples ASAP. Thank you.
rica
14th December 2008, 15:07
I really think eac3to gives the correct format. It's very precise.
EDIT: rica, what is this sample (audio.dtshd.m2ts)? Is this a remux? Using tsmuxer perhaps? Maybe that buggy program uses wrong id for the audio track. Send a sample from the original file. If you are willing to help, please send original samples.
The sample cut by eac3to first, recut/remuxed to m2ts by TSMuxer. But it is not the source of the issue.
Here is a direct cut from the original by clip.exe (27_cut.m2ts):
http://www.mediafire.com/?sharekey=610f03b89c15442e91b20cc0d07ba4d2585f4ee94eb39148
I'm uploading a direct cut by eac3to into the same folder as well. (27_cut.dtshd raw audio)
Edit: Uploaded...
madshi
14th December 2008, 15:37
Hmm, strange. Maybe you should ask madshi about it.
I've found that some streams do not strictly follow the specs. E.g. sometimes there's an E-AC3 track with a stream_type for AC3 or vice versa. The same might be true with DTS-HD High Resolution vs. DTS-HD Master Audio.
eac3to only does rough stream_type checks. E.g. all AC3 and E-AC3 stream_type streams are running through the same general parser which supports both AC3 and E-AC3. And all DTS related stream_type streams are running through one and the same DTS parser which supports all types of DTS streams. The exact stream parameters are then determined by parsing the audio bitstream. This way eac3to cannot be confused by incorrect stream_type values.
nautilus7
14th December 2008, 15:43
I'm working on DGAVCDec(NV) right now, so I prefer AVC at this point. But I'll happily accept samples with VC-1 too. Yes, I will update the other apps next. I was hoping to release something today, so it would be helpful if you could upload your samples ASAP. Thank you.
I mixed the threads that's why i mentioned vc-1. I meant h.264.
Anyway, give me 1 hour (top) because i have to change hdds to find the proper samples.
nautilus7
14th December 2008, 16:39
National Treasure 2 sample (http://www.sendspace.com/file/kh0ktd)
track list
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: TrueHD/AC3, 5.1 channels, 48khz
(embedded: AC3, 5.1 channels, 640kbps, 48khz)
4: AC3 Surround, 2.0 channels, 192kbps, 48khz
5: AC3, 5.1 channels, 640kbps, 48khz
6: AC3, 5.1 channels, 640kbps, 48khz
7: AC3, 5.1 channels, 640kbps, 48khz
8: AC3, 5.1 channels, 640kbps, 48khz
9: AC3 Surround, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB
10: DTS Express, 2.0 channels, 24 bits, 192kbps, 48khz
Jumper sample (http://www.sendspace.com/file/gpudia)
track list
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: DTS Master Audio, 5.1 channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
4: DTS, 5.1 channels, 24 bits, 768kbps, 48khz
5: DTS, 5.1 channels, 24 bits, 768kbps, 48khz
6: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
7: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
8: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
9: AC3, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB
10: DTS Express, 2.0 channels, 16 bits, 192kbps, 48khz
Transformers sample (http://www.sendspace.com/file/fpxtiz)
track list
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: TrueHD/AC3, 5.1 channels, 48khz, dialnorm: -27dB
(embedded: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB)
4: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
5: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
6: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
7: AC3, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
8: AC3 Surround, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB
9: E-AC3, 2.0 channels, 192kbps, 48khz, dialnorm: -27dB
rica
14th December 2008, 17:06
nautilus7,
DTS-HD HR is still missing since we are not sure yet whether my cut is HR or MA.
Edit: Ok, i've found one. Gonna upload soon.
Last Edit: Here it is:
Hitman:
http://www.mediafire.com/?sharekey=610f03b89c15442e91b20cc0d07ba4d25eaa14c0f07f9723
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS, 5.1 channels, 24 bits, 768kbps, 48khz, -769ms
3: DTS Hi-Res, 5.1 channels, 24 bits, 3018kbps, 48khz (core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz), -1003ms
4: DTS, 5.1 channels, 24 bits, 768kbps, 48khz, -769ms
5: DTS, 5.1 channels, 24 bits, 768kbps, 48khz, -769ms
6: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB, -865ms
7: AC3, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB, -865ms
8: AC3 Surround, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB, -545ms
9: Subtitle (PGS)
rica
14th December 2008, 23:08
I checked again; latest versions of both TMT and PDVD give the same info: (TMT 2.1.6.126, PDVD 8.0.2217a.00)
27 is DTS-HD HR; eac3to/madshi is right.
moviefan
16th December 2008, 15:28
A general question: I've experimented with encoding speeds and wonder, if it makes a huge difference when the GPU decodes the video stream. I created a blank clip with AviSynth at 1920x1080 and encoded that with x264. I got something around 15 fps or so, which should be close to a GPU decoding (in terms of CPU usage when decoding because there are no details - completely black picture), right? So am I right saying if the CPU isn't REALLY fast, x264 is the bottleneck anyway and decoding only a couple of frames per second isn't too much of an effort for a C2D CPU. So since x264 cannot encode so fast due to the CPU, it only requires some few frames per second which takes only little CPU usage (for the decoding). The impact of a GPU decoded video stream increases, when the CPU is able to encode at let's say real time or something like that, when this amount of frame decoding would take a lot CPU usage. Is this theory correct?
Comatose
16th December 2008, 15:43
The idea is that x264 will use 100% of your CPU. A decoder can eat some of the available CPU, and even if it's very little (because of the general slowness), some of us do veeeeeeeeery long encodes so even 1% CPU has a big impact in the long run.
rack04
16th December 2008, 15:49
On some machines there may be a small performance improvement, but the main purpose of using CUDA is to get correct decoding for the streams that are not handled by libavcodec, and to access some of the post-processing capabilities of CUDA. Also, to add support for VC-1 in the future.
This may be appropriate here.
Renzz
25th December 2008, 12:42
Had my first ever crash of CUVID server while trying to encode. Windows Event log shows:
Faulting application CUVIDServer.exe, version 0.0.0.0, time stamp 0x49328ce7, faulting module nvcuvid.dll, version 0.0.0.0, time stamp 0x4937286b, exception code 0xc0000005, fault offset 0x00039399, process id 0x1624, application start time 0x01c9667ee9e9ae00.
On examination of the source TS, there is a broadcast glitch at the point that I get the crash. DGAVCIndex doesn't complain and creates the DGA file ok - it's just the Server that doesn't like it.
I've cut the relevant portion out here (60MB):
http://www.mediafire.com/?sharekey=014635695f2c1f3bd2db6fb9a8902bda
The glitch is about 75% of the way through.
Should the code handle glitches like this, or is a crash likely if you have glitches in the original stream?
Thanks, and Happy Christmas!
chr2000
25th December 2008, 12:47
a question, why set Disable Display, the CPU ulity is about 10% in my computer, which is compared with 40% CPU ulity when Enable Display.
why I/O will consum so much cpu resource? isn't the display card push the YUV file to monitor directly?
if the process of coverting yuv to RGB consumed much cpu resource? then is there any display card support YUV input directly?
ultratoto14
2nd January 2009, 19:31
Hi neuron2, I recorded a stream from DVB-T in france.
Frame Size 1440x1080
SAR 4:3
Display Size 1920x1080
When i load the dga via DGAVCDecodeNV the resulting frame is 1440x1080. Is it the normal behavior ?
Happy new year.
Guest
2nd January 2009, 20:22
Yes. You need to resize anamorphic video in your Avisynth script.
ultratoto14
2nd January 2009, 21:16
Ok thanks
crypto
3rd January 2009, 13:23
Yes. You need to resize anamorphic video in your Avisynth script.
Or, from the quality aspect, it would be better to keep it this way and flag the recode as anamorphic.
jonathonsunshine
4th January 2009, 11:38
the following were my results from encoding a 1080p avc stream croppped at resized to 1280x528 (via avisynth). I did it the three different ways that I know, of dgAVCdec , dgAVCdecNV and finally, wrapping the stream in the matroska container and loading it with directshowsource
The stream was 20 seconds and had an average bitrate of 30 and a max of 41
I am encoding with 2gb ddr2 ram, 1066mhz, a Intel CPU, Q6600 / GeForce 8800GS 384mb DDR3 ram.
1st pass 2nd pass
dgAVCdec 100a26
14.61 fps 7.55 fps
dgAVCdecNV 108
23.76 fps 8.11 fps
ffdshow-libav
19.73 fps 7.65 fps
to be quite frank, I was really expecting a bit more...
So um... I'm not a programmer but are there any plans for down the line, having the GPU handle cropping and resizing as well ?
I took the encoded 1280x528 steam, indexed and encoded it the three different ways without any resizing and got the following results.
1st pass 2nd pass
dgAVCdec 100a26
26.52 fps 9.98 fps
dgAVCdecNV 108
30.19 fps 10.14 fps
ffdshow-libav
26.96 fps 10.00 fps
So it would appear to me that offsetting the decoding of the stream itself bears very little benefit but if it could be used also to handle resizing of the image, then that would result in a 30% speed increase.
On another note, (and I did 1st do a search of the thread for "saver" and didn't find anything but i'm sure this has point has been raised before), I have had to disable the screensaver.
Selur
4th January 2009, 13:25
@jonathonsunshine: "to be quite frank, I was really expecting a bit more..." Why? Decoding normally is not the major work that needs to be done during reencoding to h264. If you use high speed settings with (--me hex, --subme 1,..) speed difference might be higher, since decoding speed will become a greater factor. ;)
Audionut
4th January 2009, 14:16
If you use high speed settings with (--me hex, --subme 1,..) speed difference might be higher, since decoding speed will become a greater factor. ;)
As can be seen from the first pass encoding times. Much greater difference.
yesgrey
4th January 2009, 14:24
I've noticed two small errors in DGAVCIndex (and NV) User Manuals, in the DGV Format section:
1-"DGAVCIndexProjectFile" should be "DGAVCIndexFile" or "DGAVCIndexFileNV"
2-"AUD 80,c0" should be "AUDIO 80,c0"
yesgrey
4th January 2009, 14:46
The d2v files included the colorimetry info. Is this information also included in the dga files? It's shown in the info dialog during the project creation, but I cannot find it in the dga file...
rack04
4th January 2009, 15:07
dgAVCdec 100a26
Why are you using such and old version?
http://neuron2.net/dgavcdec/dgavcdec108.zip
to be quite frank, I was really expecting a bit more...
Well Frank, it might serve you well to read this.
On some machines there may be a small performance improvement, but the main purpose of using CUDA is to get correct decoding for the streams that are not handled by libavcodec, and to access some of the post-processing capabilities of CUDA.
Guest
4th January 2009, 16:02
And to get a VC-1 source filter that supports random access. :)
Guest
4th January 2009, 16:09
I'm not a programmer but are there any plans for down the line, having the GPU handle cropping and resizing as well? Thanks for your test results and the information about screensavers. I will ask Nvidia about your question above.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.