HEVC 4:4:4 support

[tormento]

I saw that the latest cards support both 4:2:0 and 4:4:4 HEVC codec.

Are DGTools able to deal with that? And, in general, with any video codec shown on nVidia Decoding Chart?

[Rocky]

Not supported but there's no reason it couldn't be supported if NVDec is happy with it. All I need is a sample.

In general right now, we have AVC, HEVC, MPEG2, and VC1 all in 4:2:0.

Maybe we could do full chroma now too.

[tormento]

All I need is a sample.

Try this: https://krakenfiles.com/view/wM4ny3UB7D/file.html

I hope not to have messed up something. First 444 encode for me

[Rocky]

OK, why not? Whee.

[tormento]

OK, why not? Whee.

Some HDR material both in 4:2:0 and 4:4:4:

https://behome.dyndns.info/index.php/s/7BgTfkYSmYrrzsS

[Rocky]

Cool. Thank you.

[Rocky]

Had time to get started on this. I have completed the first baby steps:

* Updated my nVidia driver to the latest. Easy.

* Installed the latest CUDA toolkit and Video SDK. Easy.

* Managed to coerce cmake to create a .sln file for the application 'AppDec'. Not easy.

* Successfully opened the solution and got AppDec to build. Not easy.

* Successfully decoded an HEVC 4:4:4 file. Easy.
(appdec -i hevc444.mkv -outplanar)

* Displayed the stream in VirtualDub2 using RawSourcePlus (YUV444P16). Easy.
rawsourceplus("out.planar", width=3840, height=1600, pixel_type="YUV444P16")

I wondered why it seemed so slow, but then I saw it had written a 10GB raw output file for 291 3840x1600 4:4:4 frames.

Oh darn, I forgot to save my carefully crafted cmake line. Hope I won't need it again.

So nothing is standing in the way and we are good to go! The only question is what cards do we have
to sacrifice to use CUDA 11.7.

@tormento

See? I'm not neglecting you.

BTW, do you have a GPU that supports HEVC 4:4:4?

[Rocky]

Successfully built and ran DGIndexNV with CUDA 11.7.

[Rocky]

Great news, guys! I have everything working in DGIndexNV. Both of tormento's test files decode, play, and index fine. Of course I had to write a new kernel to convert YUV16_444 to RGB24 for display.

Question for y'all. Should I bother supporting 8-bit 4:4:4? It wouldn't be too hard so I figure I may as well do it. But first I want to add it to DGSource() to check the complete flow for tormento's test files.

Technical tip for others trying to do this: The number of decode surfaces is touchy. It failed without any formal error returns for me with 20 surfaces (which is what DGDecNV always used in the past), but works with 16. I also saw advice to use the minimum number reported from the VPS + 4, which would be 12 for the sample files. The sample code uses just the minimum number reported from the VPS (not + 4). Not sure yet what to use. I'll probably just go with 16 as I use a #define right now and it will be a bit tricky to change that. See the heading 'ulNumDecodeSurfaces' here:

https://developer.nvidia.com/blog/optim ... codec-sdk/

That was an intense day today. Feeling good.

[Rocky]

Everything is done for DGIndexNV, including HDR to SDR for 4:4:4 stuff. tormento for the sample.

I won't do 8-bit 4:4:4 unless I get a sample from the wild and not just artificially created.

Turns out I was able to stay with CUDA 6.5 libraries and includes, and just update cuba.lib from CUDA 11.7 and nvcuvid.lib from Video_Codec_SDK_11.1.5, which read their corresponding DLLs from the driver installation. That way we don't lose any legacy card support.

Gonna do DGSource() now and then give y'all a test build.

[Rocky]

Got it working in DGSource() for Avisynth. Just have to do Vapoursynth and then I'll release a test version.

I hope someone cares about this because it was a lot of work!

[Whackbag]

I may have just signed up but know I have used, enjoyed & appreciated your work for quite some time...the effort does not go unnoticed, thank you.

[Rocky]

Thank you Whackbag. It's folks such as you that make it all worthwhile.

[Rocky]

Everything's working for DGDecNV Avisynth and VapourSynth. I want to add 4:4:4 to DGHDRtoSDR though before I give y'all anything. That way you can test both together.

[Rocky]

Here you go guys. HEVC 16-bit 4:4:4 support:

https://rationalqm.us/misc/dgdecnv_245_test.zip
https://rationalqm.us/misc/DGHDRtoSDR_1.16_test.rar

Your testing will be greatly appreciated. You can make a test stream this way:

ffmpeg -f lavfi -i "mandelbrot=s=3840x2160:r=24" -c:v libx265 -pix_fmt yuv444p16 -t 5 mb444.mp4

or for lossless:

ffmpeg -f lavfi -i "mandelbrot=s=3840x2160:r=24" -c:v libx265 -pix_fmt yuv444p16 -t 5 -x265-params lossless=1 mb444.mp4

I may go ahead and do 8-bit support too if there is any demand for it.

[tormento]

Here you go guys. HEVC 16-bit 4:4:4 support

Great, I will test it ASAP. I have just returned from vacation, more tired than before

I may go ahead and do 8-bit support too if there is any demand for it.

My initial idea was to have HEVC 4:4:4 not to encode movies, as there are almost none, but to have HW accelerated HEVC lossless as intermediate files for working with videos. In that prospective, 8 bit can be useful.

[Rocky]

Welcome back, big t. I have an 8-bit sample so I'll go ahead and add support.

[tormento]

Welcome back, big t. I have an 8-bit sample so I'll go ahead and add support.

Tested with the videos I sent you, works great on my 1660 SUPER.

AVSMeter64.exe "HEVC UHD HDR 10-Bit 420.avs"

AVSMeter 3.0.8.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.2 (r3682, 3.7, x86_64) (3.7.2.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:20.020
Frame width: 3840
Frame height: 2160
Framerate: 50.000 (50/1)
Colorspace: YUV420P16

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 66.25 | 113.6 | 108.4
Process memory usage (max): 416 MiB
Thread count: 14
CPU usage (average): 5.7%

Time (elapsed): 00:00:09.230

AVSMeter64.exe "HEVC UHD HDR 10-Bit 444.avs"

AVSMeter 3.0.8.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.2 (r3682, 3.7, x86_64) (3.7.2.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:20.020
Frame width: 3840
Frame height: 2160
Framerate: 50.000 (50/1)
Colorspace: YUV444P16

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 40.25 | 61.73 | 59.07
Process memory usage (max): 473 MiB
Thread count: 14
CPU usage (average): 6.0%

Time (elapsed): 00:00:16.945

[Rocky]

Please re-download to get 8-bit 4:4:4 support:

https://rationalqm.us/misc/dgdecnv_245_test.zip

[Rocky]

Released build 245. Marking this thread resolved.

[tormento]

Would you please add the option to have 420 output (in a graceful way) from the 444?

P.S: As my conversion line is using (again)

z_ConvertFormat(pixel_type="YUV420P10", colorspace_op="709:709:709:limited=>709:709:709:limited", resample_filter_uv="Lanczos")

perhaps, some day, your itchy thought to port AVSResize will happen.

[tormento]

Released build 245. Marking this thread resolved.

Did you read my last message about 4:2:0 conversion?

[Rocky]

Yes, I did. Due to current exigencies I am able to maintain activity on only one major project at a time. Currently that is DGCube stuff. I take note of your request.