Support forum for DG Tools

Out of curiosity: Any progress with DGdecNV for HEVC ....

Good timing. I just started playing around with it again today. I'll keep you informed here. The first step is to get the nVidia decode sample working.

Good news. Thanks.

Oy, looks like I need to buy a GTX 950/960 for full HW decode or a 750 for hybrid SW/HW decode. Earlier cards won't work at all.

The best I have right now is a 620 OEM with GF119.

Got my grubby hands on a GTX 950 today.

Newegg delivers faster than Amazon and it was cheaper. Who'd a thunk it? I tried Newegg only because Amazon hosed me on a Roku 3 order. When I clicked Add to Cart, it was showing in stock and shipped by Amazon. But after a week I found myself on a backorder with some 3rd-party supplier (FBA program). That was pointpod, and they responded rudely to my WTH inquiry. Amazon blamed pointpod and pointpod blamed Amazon. I bitched and moaned but they wouldn't just ship me the in-stock goods. They said I had to cancel and re-order, but I had already ordered from in stock, so I told them to shove it. Now I am on boycott of Amazon until there is no alternative for my purchases. None of this nonsense at Newegg.

GTX 950 installed and working as primary alongside a GT 520 on my i7 980X machine running Win 10.

Back to the decode sample. It has to be modified to do HEVC. Theoretically, it should be simple.

It's looking good. I have successfully decoded and displayed a raw 1080p .265 file using the nVidia sample CUVID decode application. The changes to the sample application were indeed easy (one line of code changed and one added). I don't know why nVidia didn't do that.

Now let's see if things work in DGIndexNV...

Another thought I had was that if I build the NV12-to-RGB24 .cu file to PTX (instead of .cubin) then I won't have to compile for each architecture and I'll be able to upgrade CUDA versions without losing any older cards. I'll look further into that as time permits.

Finally, I have revamped the GPU listing code to use the database from https://pci-ids.ucw.cz/. That should allow me to better keep up with new cards. At some point I will slipstream that. It now prints the device ID (e.g., 10DE:1049 for my GT 620 OEM) as well as the GPU core type. The first number of the device ID is the nVidia vendor ID 10DE and the second is the device number for the chipset. You can look it up at the linked site and see that it is a GT 620 OEM. I'll refresh from the site at every slipstream so that we are always up-to-date, or very nearly so.

Would you happen to know what the minimum GPU/driver requirements are for H.265 decoding, if it isn't something that all VP5+ cards are capable of out of the box?

As far as I can determine, you need VP6 for partial acceleration and VP7 for full acceleration. I don't think VP5 can decode HEVC.

I've got the HEVC stream detection code working. Now the hard slog begins...

Major step completed: I am playing raw HEVC video in DGIndexNV. That verifies the CUVID decoding with my video source and NALU parsing. Now I have to do all the ancillary stuff that DGIndex does (timeline navigation, info dialog, indexing, etc.), i.e., the hard part. But theoretically there are no obstacles to completing it now.

admin wrote:If 9600GS works with 2048 then you will be fine with the HEVC version.

EDIT: I was wrong. You need a GTX 750/950/960. 9600GS will need to go to the video card graveyard I
'm afraid.

Too bad, your EDIT.....

It should have gone to the graveyard long ago, actually.

Well, it has served the purpose well, so far ....

admin wrote:As far as I can determine, you need VP6 for partial acceleration and VP7 for full acceleration.

Thank you. Perhaps I will upgrade if nVidia releases some useful cards in the 1000 series.

Timeline navigation for HEVC is complete. Moving on to indexing...

Generation of a rudimentary HEVC index file is complete. It's enough to do correct random access though DGDecodeNV but all the bells and whistles are not there yet (e.g., repeat flag handling, info for debug overlay, etc.) I want to get DGDecodeNV working at least in this mode before going back to add the bells and whistles. Then, too, I need to add support for TS, MKV, and MP4 containers. We also wait for nVidia to support Main10.

The HM reference parser code is ridiculously complex so I rolled my own. Anyway it would have to be heavily modified to work with my per-NALU parsing architecture.

Following is what the index file looks like at this time. The frame count matches MPC-HC so it seems I am detecting new pictures correctly, which is the sine qua non of correct indexing.
__________
DGHEVCIndexFileNV14 DGIndexNV 2050 X64
D:\DGIndexNV\.\x64\Debug\

TearsOfSteelFull12min_720p_24fps_27qp_831kbps_720p_GPSNR_41.65_HM11.hevc 76244512

DEVICE 0
DECODE_MODES 0,0,0
STREAM 0
CLIP 0 0 0 0
RANGE 0 0 76244511 0
AUDIO

VPS 0
SPS 29
PPS 82
IDR 93
0: FRM
1: FRM
2: FRM
3: FRM
4: FRM
5: FRM
6: FRM
7: FRM
8: FRM
9: FRM
10: FRM
11: FRM
12: FRM
13: FRM
14: FRM
15: FRM
16: FRM
17: FRM
18: FRM
19: FRM
20: FRM
21: FRM
22: FRM
23: FRM
24: FRM
25: FRM
26: FRM
27: FRM
28: FRM
29: FRM
30: FRM
31: FRM
32: FRM
33: FRM
34: FRM
35: FRM
36: FRM
37: FRM
38: FRM
39: FRM
40: FRM
41: FRM
42: FRM
43: FRM
44: FRM
45: FRM
46: FRM
47: FRM
VPS 4173
SPS 4202
PPS 4255
IDR 4266
48: FRM
49: FRM
50: FRM
51: FRM
52: FRM
53: FRM
54: FRM
55: FRM
56: FRM
57: FRM
[.....]
VPS 76242178
SPS 76242207
PPS 76242260
IDR 76242271
17568: FRM
17569: FRM
17570: FRM
17571: FRM
17572: FRM
17573: FRM
17574: FRM
17575: FRM
17576: FRM
17577: FRM
17578: FRM
17579: FRM
17580: FRM
17581: FRM
17582: FRM
17583: FRM
17584: FRM
17585: FRM
17586: FRM
17587: FRM
17588: FRM
17589: FRM
17590: FRM
17591: FRM
17592: FRM
17593: FRM
17594: FRM
17595: FRM
17596: FRM
17597: FRM
17598: FRM
17599: FRM
17600: FRM
17601: FRM
17602: FRM
17603: FRM
17604: FRM
17605: FRM
17606: FRM
17607: FRM
17608: FRM
17609: FRM
17610: FRM
17611: FRM
17612: FRM
17613: FRM
17614: FRM
17615: FRM
SIZ 1280 x 720
FPS 25000 / 1000
CODED 17616
ORDER -1

That didn't take long. I'm serving HEVC video through an AVS script using DGDecodeNV with full random access. Random access is really fast on this GTX 950!

Nice progress! It looks like I have to think seriously about replacing my 9600GS.....

Thanks Sharc. You're on to something there. That moldy 9600 won't take you into the coming UHD world. A 950/960 is the way to go right now. At some point horse-drawn carriages must give way to automobiles.

If you want to be on the bleeding edge, regular HW upgrades are essential.

admin wrote:That moldy 9600 won't take you into the coming UHD world.

On the other hand, unless you can upgrade your eyes, you might not get much benefit from entering the UHD world, anyway. As far as I can tell, it's more about selling TVs (since the 3D push didn't work) than actually improving the viewing experience. In any event, I'm hoping nVidia comes out with some better upgrades for the 1000 series, as I didn't find the specs of the 960 to be good enough to warrant replacing my 760, so I'll have to forego HEVC support for the time being. My hardware players don't support UHD or HEVC anyway, so I can't use them as input or output formats. A GTX 960 would be a pretty huge upgrade from a 9600, though. I upgraded from a 6800 to my 760.

Aleron Ives wrote: As far as I can tell, it's more about selling TVs (since the 3D push didn't work) than actually improving the viewing experience.

I totaly agree with you on the commercial part, UHD is more to try to sell new TVs. But, nevertheless, there is a viewing improvement, but it's far away less obvious than going from SD to FHD...

CRA handling is a bit of a challenge, as the decoder discards the preceding RASL pictures, complicating random access. Fortunately, I have a working strategy for it. X265.exe and others use CRAs rather than IDRs (except for the first GOP of the stream).

Anybody ever see BLA pictures? If so, I would appreciate a sample. Thank you.

Everything is working great with CRAs. I ran into an issue with tiles, basically CUVID fails on any stream using tiles*. But as usual nVidia support is outstanding and I am informed that the bug is trivial and will be fixed in an upcoming driver. Still lots of time to get ready for UHD bluray.

BTW, I am also informed that HEVC 10-bit support will be added to CUVID, so we will be ready to rock and roll. It will support dithering down to 8-bit for feeding 8-bit Avisynth, but will also be able to deliver 10-bit to 10-bit processing chains. It's up to DGDecodeNV to decide what to give to the Avisynth host.

Next up, HEVC in MKV support (TS just works and MP4 comes later). Then I will probably release an alpha as we need to discover any other problematic streams. Also, I changed DGIndexNV to support higher zooms, as UHD was pushing the buttons off screen, oy! I have Zoom 1 for full size, Zoom 1/2 for half size, and Zoom 1/4 for, you guessed it, quarter size. I experimented with moving all the navigation stuff to the top of the window below the menu bar, but it looked ugly, so I went with the different zoom factors instead. We should be using UHD monitors with our development PCs, but until that day zooming works fine.

* Introduction of a tile, a new concept, is yet another innovation of H.265/HEVC standard compared to H.264/AVC standard. Tiles divide the frame into a grid of rectangular regions that can be independently decoded/encoded. Tiles opens up new possibilities to increase encoding and decoding efficiency of video data using parallel processing on modern multicore desktop and mobile platforms. [Elecard]

... At first glance, it seems similar to slices in H264 (from the few i've read about slices), but i don't know deeply enough, and i may misunderstand things...