Support forum for DG Tools

I've got full depth delivery for DGDecodeNV working. It will be like this:

DGSource("file.dgi",fulldepth=true)
ConvertBits(8) # for testing

I return CS_YUV420P16 frames to Avisynth+. Unused bits are zeroed. I still have to revise the pulldown code for full depth and then I will make a slipstream. It's working with CUDA 6.5 libraries and locally modified headers, so I did not have to drop support for any older cards to get this going.

At some point I also have to add full depth support to the other included DG filters.

I also added output of the number of CUDA cores to the GPU Info dialog, and fixed D3D operation on Windows 10.

I forgot to mention: HEVC 10- and 12-bit 4:2:0 will be supported. CUVID does not support high-bit-depth AVC.

Thanks for this, i think it will be a great step.

My questions are just to understand how it will work.
- What will the fulldepth default value will be ?
- In case of 10-12 bits, the ouput will be 16 bits if i understand properly. Is there a possibility to know what was the original "true" bit depth ? (Was my 16bits video a 10 or a 12 bits indeed) ?

Edit :
I've noticed in the avs+ header that there is also CS_YUV420P10 or CS_YUV420P12 avaibles. Is it too much complex to output the exact color format ? I'm sure that some people would like to stay with the exact original bit depth and not expand it if possible.
If i said that, it's because (it's the case for nnedi3 for exemple) filters have different paths code according bit depth, and most of the time, the higher it is, the "less" optimised it is, and the slower it is. So, it would be... (don't know the correct english word) "too bad"/"a waiste" to have 12bits bits depths, when 10 would have been enough. I said 12, because the first thing you can do is reduce 16 to 12 without any worries, because you know it will not be higher.

Good morning, jp, I hope your weekend is off to a stellar start.

Great points and questions. I hope this clarifies things.

1. fulldepth default is false. When fulldepth=true and the encoded video is HEVC 10-bit or 12-bit, then DGSource() delivers 16-bit data to Avisynth with the unused lower bits zeroed. The reported pixel format is CS_YUV420P16. If either of the two conditions are not met, then DGSource() delivers 8-bit YV12 or I420 data, as determined by the i420 parameter. When fulldepth=false and the video is HEVC 10-bit or 12-bit, then CUVID dithers down to 8-bit for delivery.

2. Two ways to get the bitness: 1) DGIndexNV info dialog profile field, 2) DGI file DEPTH line.

3. CUVID delivers full 16 bits only, and I don't care to add code for all the conversions when you can simply use ConvertBits(), which also allows extra options, such as choice of dithering method, etc. Here is an example:

DGSource("file.dgi",fulldepth=true) # delivers 16 bits
ConvertBits(12) # discards 4 lower bits

pinterf can implement these conversions way better than me.

I'm about to check it all in and slipstream, so if you have any further suggestions, now is the time.

admin wrote: 3. CUVID delivers full 16 bits only, and I don't care to add code for all the conversions when you can simply use ConvertBits(), which also allows extra options, such as choice of dithering method, etc.
...
pinterf can implement these conversions way better than me.

Great point also indeed...
Thanks for the informations, no suggestions for now, and thanks for your work.

Unfortunately WE start could have been a little better... But it will finaly be good for now.

... A more generic question comes to mind...
HEVC, 10bits, 4k... may lead to a bad word... HDR !!!!
I don't know if you've followed things, but proper HDR conversion seems ... difficult.
Is there by any chance anything in CUDA that can handle properly HDR (and it's metadata) stream to offer proper decoding of it ?
I ask because it seems "logical" that a device which purpose go in the direction if UHD/4k, that HDR may be also in the features.

Thanks, jp! Of course you are absolutely right.

jpsdr wrote: Unfortunately WE start could have been a little better... But it will finaly be good for now.

Sorry about your weekend. There's still time for brilliance. Never despair; it's always onward and upward. All experiences provide important information.

If some HDR metadata from the stream is missing, please describe what's needed and please give a link to the specification to allow the data to be extracted, or passed to Avisynth. I haven't been following other video sites closely. I understand that there are still competing metadata schemes. I am not aware of any relevant metadata offered by CUVID, but I could be mistaken, or maybe it can be derived from other information. Perhaps this is more of a renderer issue. If you could help us with "proper decoding" you'd be the bee's knees, the cat's meow, the guardian of all that is right and good, a towering icon in the pantheon of video gods.

Thanks, jp, that's great.

Don't know if this helps but here is a link
https://developer.nvidia.com/displaying ... -and-bolts

Thanks, gonca, reading now...

That looks great. Thanks. Still looks like a renderer issue but keeping an open mind here.

Unfortunately i know almost nothing about HDR, except it seems to be some kind of nightmare.
I never said anything was missing. It's just that it seems that to convert properly HDR, you need metadata that seems to be only on the h265 stream, and these informations can't be transmitted to avisynth. Or if they can, it could only be via some trick, like using the alpha channel of YUV for exemple...
So,if "proper" HDR decode can be done, it's only while you're still within the processing of the h265 stream. Also, it's more guess than anything.

I'll research the matter and do whatever is needed to support HDR processing workflows. Thanks for bringing the matter to my attention, jp.

The HEVC spec includes a mastering display colour volume SEI message, which signals HDR metadata. I can expose its contents in the index file.

I had a screw-up in the uploaded 2053 slipstream 102, so I have removed it. Corrected version coming shortly.

All fixed in slipstream 103.

U da man!!!

Nice for the metadata things.
I've posted [elsewhere], to try so see if someone has an idea how to go to a second step here

Thanks.

Ok, done.
I'll try to test your new version on the HDR file provided in the first post of the link, out of curiosity, to see what result it produces.

Thanks, jp. That stream does have mastering info. It exposes a bug in my extraction, which I will correct right now.

Hmm, that file is not decoding properly while all my other 10-bit files work fine. Investigating...

Ouch, it appears to be a CUVID problem, as it shows the same errors in the nVidia sample decoder. I will inform nVidia.

What is the provenance of this file? It's title shows 2160p but the coded height is only 1612, with no black bars, so it can't be real ripped UHDBD content.

UHD hasn't been "cracked" by any of the known software
I believe there are two files out there that claim to be UHD rips
The first one might be, I believe it was mentioned somewhere, a resize of HD to UHD.
The second was still an unknown means, possibly thru a capture card or HDCP stripper.
I realize I used the expression "I believe" a few times but this issue is a bit of an enigma wrapped in a mystery

Hacksaw Ridge was derived from 3.4K source, rendered from a 2K DI, and up-converted to 4K. With the limited exposure to Ultra HD either sourced from 2K or 4K Digital Intermediates we are left to judge based upon what we have seen thus far.

from this site
http://ultrahd.highdefdigest.com/42357/ ... luray.html

The Hacksaw Ridge sample was re-encoded with x265 (possibly from some kind of capture, or even just a cheap upsampling) and the encoding parameters are included in an SEI. So I will try to see which if any of these parameters may be giving problems for CUVID.

Anybody see anything problematic here? Other than uhd-bd=0?

x265 (build 103) - 2.2+2-998d4520d1cf:[Windows][GCC 6.2.0][64 bit] 10bit - H.265/HEVC codec - Copyright 2013-2016 (c) Multicoreware Inc - http://x265.org - options: cpuid=1173503 frame-threads=5 numa-pools=16 wpp no-pmode no-pme no-psnr no-ssim log-level=2 bitdepth=10 input-csp=1 fps=23976/1000 input-res=3840x1612 interlace=0 total-frames=0 level-idc=0 high-tier=1 uhd-bd=0 ref=1 no-allow-non-conformance repeat-headers annexb aud hrd info hash=0 no-temporal-layers open-gop min-keyint=23 keyint=250 bframes=3 b-adapt=2 b-pyramid bframe-bias=0 rc-lookahead=40 lookahead-slices=0 scenecut=40 no-intra-refresh ctu=32 min-cu-size=8 no-rect no-amp max-tu-size=32 tu-inter-depth=1 tu-intra-depth=1 limit-tu=0 rdoq-level=2 signhide no-tskip nr-intra=0 nr-inter=0 no-constrained-intra strong-intra-smoothing max-merge=2 limit-refs=0 no-limit-modes me=2 subme=7 merange=57 temporal-mvp weightp weightb no-analyze-src-pics no-deblock no-sao no-sao-non-deblock rd=6 no-early-skip no-rskip fast-intra no-tskip-fast no-cu-lossless no-b-intra rdpenalty=0 psy-rd=4.00 psy-rdoq=8.00 no-rd-refine analysis-mode=0 no-lossless cbqpoffs=0 crqpoffs=0 rc=crf crf=21.5 qcomp=0.80 qpstep=1 stats-write=0 stats-read=0 vbv-maxrate=100000 vbv-bufsize=100000 vbv-init=0.9 crf-max=0.0 crf-min=0.0 ipratio=1.10 pbratio=1.00 aq-mode=3 aq-strength=1.00 no-cutree zone-count=0 no-strict-cbr qg-size=32 no-rc-grain qpmax=51 qpmin=0 sar=0 overscan=0 videoformat=5 range=0 colorprim=9 transfer=16 colormatrix=9 chromaloc=1 chromaloc-top=2 chromaloc-bottom=2 display-window=0 master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0) max-cll=1000,321 min-luma=0 max-luma=1023 log2-max-poc-lsb=8 vui-timing-info vui-hrd-info slices=1 opt-qp-pps opt-ref-list-length-pps no-multi-pass-opt-rps scenecut-bias=0.05

I just had a look at a sample of the Smurfs "rip" linked at reddit. The poster says it's a one-minute sample of the original M2TS but the file is an MKV. It crashes at the end in all players (bad upload/download?). The portion that plays correctly in all players also plays fine in DGDecNV. There are no encoding parameters or other identifiable strings in the elementary stream. The dimensions are correct and the black bars are present. The bitrate seems appropriately high. It has appropriate audio. It contains the mastering SEI. It was muxed by mkvmerge on May 3, 2017.