Support forum for DG Tools

And maybe if you use VirtualDubFilterMod, it may even work properly without the need of ConvertBits(8).

Thanks, I didn't know about VirtualDubFilterMod. I'll give it a try.

The DOOM9 thread about it is this one : https://forum.doom9.org/showthread.php?t=172021

Euh.... I don't understand why the url is not displayed properly in the post, it's correct when i edit...

It seems that ??? concatened transform in ???

The thread is VirtualDub deep color modification

It triggered my banned words list. Sorry about that, it is what it is.

I did try VirtualDubFilterMod and it said I needed a VFW codec for fourcc P016. I sent Anton a PM on sourceforge asking about it. Obviously I cannot control what fourcc Avisynth+ delivers. Hopefully he'll respond with some useful information.

OK, Anton needs to accept P010, P012, and P016 as synonyms for his supported fourccs. Or we need a way to force Avisynth+ to use his. Worst case we can fork VDFM but hopefully Anton will fix it up for us.

Great news, guys. Anton replied and sent me a test build. It works great with the Avisynth script returning P016. He will release it after some testing.

Now the question is what fourccs does x265.exe expect to see and which one is being passed by Vapoursynth? It's clear that DGDecodeNV itself is just fine.

I can confirm your statement now. Using latest DGDecNV, HDR-10 source and Avisynth+ (came with Staxrip), the encoding just have started using 16 bit input and 10-bit output. Encoding speed is 35-40% faster than the software decoding was without my GPU's support.

So, if someone would like to use DGDecNV with Avisynth+, it will definitely work. Additionally, no ConvertBits(x) is required at the end of the script, because x265 can handle 16-bit input correctly.

Great to hear, mparade. Thanks for the update.

So all remaining issues are only with Vapoursynth? Or have you got that working as well?

Unfortunately, the standpoint of the author of Vapoursynth , that I know, is as follows:
"I already support all the avs+ formats. This is something else. I also have no intention of paying (I mean compulsory donation hahahahaha) to debug this. Or buying an nvidia graphics card for that matter.

Let the butthurt commence!"

I think it means it is very far from him to debug Vapoursynth.

If you can reproduce it with a different source filter or even blankclip() with appropriate parameters maybe he would look at it, since DG stuff would be out of the picture.

BTW, I have always given free licenses to developers (and even to people who have difficulties to donate). I even have a few unused nVidia cards that I would be happy to donate.

Anyway, I see you have things going fine with Avisynth+, so that makes me happy.

I have completed my first HDR encode using DGDecNV, but unfortunately I saw some artifacts during decoding the output:
http://www.mammutmail.com/hu/download/b ... 54b6fea0dd
I don't know yet if it is only a decoding problem now or if it is involved in the encode itself already due to some "problem" with decoding the original HDR content through DGDecNV.

It seems these artifacts are encoded into the output (the source material can be decoded without them).

Those are strange artifacts.

Open your script for the source video directly in VirtualDubFilterMod and move to a place a little ahead of where the artifact occurs. Then play from there. Does the artifact show up? If so, it may be a CUVID issue, and you can please cut a sample around it for me.

The artifacts are the same in VdubFilterMod. I had to use ConvertBits(8) because otherwise the program displayed some error message.
But without ConvertBits(x) the results will be the same surely, because my 10bit encodes (16bit input, 10bit output in x265) has the same artifacts:

http://www.mammutmail.com/hu/download/c ... 3e06a78a02

This is not the source stream. I need to see the original, not your re-encode.

Please find as an attachement the original.

http://s1.toldacuccot.hu/letoltes?sid=7 ... ginal1.zip

Thank you. Downloading...

It's a known CUVID/NVDec bug. I reported it at least 3 months ago. I will rattle nVidia's cage again. We are at their mercy.

Thank you. Until then, I freeze my HDR/4K re-encoding projects.
Is the bug only with high-bit-depth HEVC streams, or with HEVC streams generally?

I believe it is 10-bit only.

In one of your post, there is this video : Philips_Ultra-HD_Beach_Life_supershop-demo-3
Is it possible to have a link where i can download this ? I would like to test/check on my system that everything works fine, and i don't have h265 HDR 10 (or 12) bits video.

http://demo-uhd3d.com/fiche.php?cat=uhd&id=135
Is this the one?

Sorry guys, I am away for a few days. I'll catch up when I return.

Admin are you back ?
I'm not able to download the file from gonca link. Is there any link i can download from the file you're using ?

Odd, the link works fine for me