DGDecodeNV.. and 10bit.

[killazys]

Well, I've been reading up on AviSynth and it appears that it operates natively in 8bit. This means that converting from Hi10P to Hi10P involves 10bit --> 8bit --> 10bit, essentially. To avoid this, one would have to use certain import, operating, and export filters.

Does DGDecodeNV support native 10bit input? Will it output from the AviSynth pipeline in 10bit if there is 10bit input, for feeding into x264 10bit?

Also.. what is the resize filter used (GPU Resize)? Would it be better to use ResampleHQ, or the like (I know ResampleHQ supports 32bit linear color)?

Any clarification on this issue would be greatly appreciated :cool:

[golagoda]

Assuming I understand dgdecodenv 100% properly no it doesn't, since the only GPU's that support 10-bit decoding are AMD FirePro GPU's which are professional workstation cards.

[Guest]

DGDecNV currently does not support 10-bit, and cannot do so until it is supported by nVidia's CUVID API.

The resizer is a simple bilinear resize. Do resizing in your script if that does not meet your needs. I find it adequate for downsizing, especially when I want the result in a hurry.

[killazys]

Thanks for the responses: clarified the issue for me :)

I guess the next question is.. then... is there any noticeable quality improvement by using a completely 10bit pipeline? I know in theory this will increase bit accuracy etc etc., but has anyone done any encoding tests?

If not, I'm getting a new rig soon and will probably do testing myself. But it's always easier to look for answers first ;)

[Keiyakusha]

killazys
You need to make sure that you encode final result in 10 bit if you want better efficiency. Whatever it 10 bit or not before you encode it - doesn't makes that much difference since in most cases all extra bits would be fake anyway. So if you doing some debanding at the end - just make it output 10bit, if not - leave it as is.

[golagoda]

Thanks for the responses: clarified the issue for me :)

I guess the next question is.. then... is there any noticeable quality improvement by using a completely 10bit pipeline? I know in theory this will increase bit accuracy etc etc., but has anyone done any encoding tests?

If not, I'm getting a new rig soon and will probably do testing myself. But it's always easier to look for answers first ;)

There are some great PDF's on 10-bit encoding located here that you might want to have a look at

http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

http://x264.nl/x264/10bit_03-422_10_bit_pristine_video_quality.pdf

http://x264.nl/x264/10bit_01-ateme_pierre_larbier_422_10-bit.pdf

I've encoded a few things into 10-bit and at the very least banding is down by a lot, 10-bit encoding isn't some ultra bandwidth-saving quality-improving thing like H.264 was compared to Xvid, but generally you can get the same quality, or better at about 10% less filesize compared to 8-bit encoding with x264

[killazys]

I have read those, yes. There seems to be a conclusion that even if you're compressing 8bit to 10bit, there's going to be quality improvements. I was wondering if they would be better if you could avoid 8bit completely if you happen to have a 10bit source (unlikely to happen in my realm of encoding, but whatever).

Anyway, another question is the 4:2:0 thing that shows up on the OSD in MPC-HC when I'm watching 10bit video... what does the 4:2:0 refer to? Isn't 10bit 4:2:2?

[Keiyakusha]

I have read those, yes. There seems to be a conclusion that even if you're compressing 8bit to 10bit, there's going to be quality improvements.
Yes but many people gets it wrong. Here we should think about 10bit like switch-in-encoder-that-makes-better-compressed-result. It doesn't cares what input you actually have. So you should decide whatever you need 10bit somewhere in the middle of the processing by some other factors. IMO, when dealing with artificial 10bit source - it doesn't matters. By processing even in 16bits we get a lot of precision blablabla by which you hardly can notice any difference except probably in processing speed.
Anyway, another question is the 4:2:0 thing that shows up on the OSD in MPC-HC when I'm watching 10bit video... what does the 4:2:0 refer to? Isn't 10bit 4:2:2?
These are different things. One is chroma subsampling. By the way 4:2:2 is a 16bit, 4:2:0 - 12bit. It refers to chroma size/placement. Another is amount of colors per channel. If you'll think about RGB, your normal 8bit video can be converted to RGB24 with 8bits per channel (or RGb32 with dummy alpha channel), but to convert 10bit video to RGB you'll need something like RGB48 (RGB64 for alpha channel) to hold all values without loosing information (well RGB48 is probably more than enough, it can hold up to 16 bits per component)

[jmac698]

Your questions should be answered here
http://avisynth.org/mediawiki/High_bit-depth_Support_with_Avisynth

Now that I can write plugins, trust me I'll be doing some high bit depth work...

And there are some videos in even 16bit (like Blender movies). Also note that any down-rezzing creates a higher bit depth naturally.