The state of h264 10-bit playback?

[shae]

What PC graphics hardware currently supports 10-bit h264 playback?

What are good/bad decoders for software decoding?

Are there hybrid software decoders that do some of the work on the hardware?

[nevcairiel]

There are no hardware decoders for 10-bit H264.

[shae]

Why is that?

Are there any 10-bit shader-enabled decoders, or decoders that do some of the decoding stages in software and the rest in fixed-function decoding hardware?

[nevcairiel]

No, only pure software decoders can do 10-bit.

The reason is quite simple. There is basically zero commercial content in 10-bit, and thus hardware manufacturers have zero interest in it.

[shae]

Why no shader/hybrid decoders, just not enough interest from open-source developers due to not enough content or not enough reason to use 10-bit?

[Mangix]

a decoder implemented in OpenCL or CUDA would probably not be faster.

[Procrastinating]

Plus, any mid-range CPU can effortlessly decode 10bit in software anyway.

Yes, 10bit encodes reduce banding artefacts. But there is only so much die space you can provide to hardware decoding, and so few people encode to 10bit that it's basically a chicken and the egg problem.

[shae]

Mangix, why wouldn't it be faster?

Regarding the popularity of 10-bit, if what I understand is correct: that 10-bit looks better in some scenarios, and also compresses slightly better, then it's a win-win. I don't understand why it isn't added as a baseline feature in some next iteration of video delivery/format standards.

[sneaker_ger]

It is. For H.265/HEVC 10-bit hardware decoders already exist today.

[Asmodian]

Mangix, why wouldn't it be faster?

Regarding the popularity of 10-bit, if what I understand is correct: that 10-bit looks better in some scenarios, and also compresses slightly better, then it's a win-win. I don't understand why it isn't added as a baseline feature in some next iteration of video delivery/format standards.

Why would it be faster? ;)

It wouldn't be faster because the CPU decoder is already so good and using the GPU as a CPU, instead of the hardware decoder 8-bit uses, is hard to write in the first place and hard to optimize well.

[huhn]

Mangix, why wouldn't it be faster?

Regarding the popularity of 10-bit, if what I understand is correct: that 10-bit looks better in some scenarios, and also compresses slightly better, then it's a win-win. I don't understand why it isn't added as a baseline feature in some next iteration of video delivery/format standards.

he already said it because no one cares.

maybe UHD BD gets it.

there is a free openCL h265 decoder. it mostly still uses the CPU. and the next versions of ffmpeg will beat it without the GPU.

the problem is these are openCL decoder not like DXVA FIXED FUNCTION ASIC decoder. these decoder would be really fast.

[shae]

If it can be made faster with GPU code, I assume it's because of more parallelism and maybe more bandwidth. But I have no idea where the bottlenecks are.

[Mangix]

Mangix, why wouldn't it be faster?

Specifically, code on the GPU wouldn't really provide a meaningful speedup. GPUs excel with massively-parallel workloads whereas decoding(decompression in disguise) is highly serial.

[kieranrk]

There are no hardware decoders for 10-bit H264.

hardware decoders that OP can afford.

[cyberbeing]

hardware decoders that OP can afford.
Did Sony ever end up deploying 4k 10bit x264 streaming via eyeIO?

[G_M_C]

Last time i tried was when AMD released their driver where you can select the output bitdepth. It worked, i could set 10-bit out and force 10-bit in, en via MPC-HT -> EVR CP, force 10-bit in and out, the ctrl-j screen said my system was indeed inputting and outputting 10-bit (X10R10G10B10 or something like that).

But the CTRL-J screen also said that MPC-HT's videomixer was only working in 8 bit (X8R8G8B8 or something of a sort). So there was no benefit using 10-bit in MPC-HT. If they could make it so that the mixer can also work in 10-bit, we could get a fully 10-bit in-to-out chain, but this way is doesn't work.

It could be that MPC-BE has a better mixer, i dont know. If so, let me know i will try the test again.

[huhn]

windows can't do 10 bit with aero so this only works with d3d fullscreen.

and this worked be for they add this option in the CCC.
8 bit sources encoded in 10 bit has a huge effect on quality even if displayed on 8 bit screens.

the number of 10 bit displays is still very low anyway.

I mean I can send 12 bit to my TV and it is still 8 bit.

[G_M_C]

windows can't do 10 bit with aero so this only works with d3d fullscreen.

and this worked be for they add this option in the CCC.
8 bit sources encoded in 10 bit has a huge effect on quality even if displayed on 8 bit screens.

the number of 10 bit displays is still very low anyway.

I mean I can send 12 bit to my TV and it is still 8 bit.

I know, my plasma even doesnt accept 4:4:4 RGB. But aside from the fact that there are almost no displays that show 10 bit, even if there were plenty of those, it wouldnt work cause of the mixer working in 8 bit.

[JanWillem32]

G_M_C, that "10-bit input" option is totally fake. Wat is does is re-ordering the mixer preferred input formats for accepting media types, and it does so in the pretty much worst possible way. This option should absolutely never have been implemented. The EVR and VMR mixers allow input of all basic "RGB"-ish types anyway, as long as the device at least supports them (and even then, both the VMR and EVR have some color conversion methods available to them).
(These types are: R8G8B8, A8R8G8B8, X8R8G8B8, X1R5G5B5, A1R5G5B5, A4R4G4B4, R3G3B2, A8R3G3B2, X4R4G4B4, A2B10G10R10, A8B8G8R8, X8B8G8R8, A2R10G10B10, A16B16G16R16, A8P8, P8, R8G8_B8G8, G8R8_G8B8, A16B16G16R16F, A32B32G32R32F, A2B10G10R10_XR_BIAS and maybe the proprietary or signed integer formats as well.)
The display output type is something entirely different. It's the type set for the display back and front buffers. These can be 8-, 10-, 12- or 14-bit per color channel on modern output ports such as DP, HDMI, some types of (DL-)DVI, SDI types and even some analog connections (the DAC on even many older video cards already featured more than 8 bits of precision). For some very odd reason the Windows desktop (Aero in particular) isn't made to render to more than 8-bit back buffers, so it's usually in D3D or OpenGL exclusive mode that these features can be used (if supported by both the video card and the display, of course).

10- or 16-bit Y'CbCr types usually returned by consumer-grade video sources from the decoder are different. They are usually 4:2:0 or 4:2:2 chroma down-sampled and require a different layout in memory than the simpler "RGB"-ish types. These layouts are generally not supported by any video cards in existence. The video card manufacturers didn't implement such functionality in hardware, nor by emulation in their drivers. That is why the EVR and VMR can't mix the 10- or 16-bit Y'CbCr types (at this moment). A color converter is needed at the moment to convert 10- or 16-bit Y'CbCr types to 8-bit types that are supported by the drivers for the EVR and VMR mixers.
The support for even 8-bit Y'CbCr types is generally poor by the way. The supported formats are NV12, UYVY, YUY2, and in some cases YV12 and AYUV.
Implementations of custom mixers (such as in the Haali video renderer and madVR) can re-order 10- or 16-bit Y'CbCr textures in memory a bit (on the CPU side of things) to fully support mixing of 10- or 16-bit Y'CbCr types without needing much in terms of support of the video adapters.

huhn, there are plenty of display systems (mostly panels and some projection forms) that have better than 8-bit quantization per channel in the high-end consumer and professional market. I believe it were the SGI workstations that came first with 10-bit display color in 1994 (in terms of display, as editing in higher color bit depths was already common before that). Many professional formats even demand minimum precision in processing and display to be over 8-bit quantization per pixel. DCI used in cinemas requires 14-bit processing, 16-bit color conversion, and 12-bit R'G'B' native display (with some additional demands to meet the quality target for display calibration) as a minimum requirement for licensing, for example.

[vivan]

A color converter is needed at the moment to convert 10- or 16-bit Y'CbCr types to 8-bit types that are supported by the drivers for the EVR and VMR mixers.But what about >8 bit RGB?
It will be possible to avoid precision loss if decoder would output high bit depth RGB, right? I guess LAV's RGB48 is not supported (no R16G16B16 in the list), but it could be fixed by adding 0 alpha.

[G_M_C]

Thx for the extensive explanation Jan Willem (toppie dank je !). But all-in-all is sorta comes down to the same doesnt it?

Even with custom mixers, and the abillity to process and work with 10-bit (or higher) inputformats we cant output more than 8 bit. For ex. madVr dithers down to 8 bit and outputs rgb32. That means there is still no fully in-to-out 10-bit (or higher) software solution, or is there?

[huhn]

Thx for the extensive explanation Jan Willem (toppie dank je !). But all-in-all is sorta comes down to the same doesnt it?

Even with custom mixers, and the abillity to process and work with 10-bit (or higher) inputformats we cant output more than 8 bit. For ex. madVr dithers down to 8 bit and outputs rgb32. That means there is still no fully in-to-out 10-bit (or higher) software solution, or is there?

I guess there are professional renderers.
but there is a chance madVR gets true 10 bit output.
but there are a lot of more important things I guess like real 3d support.

[JanWillem32]

vivan, the R'G'B' types I named earlier are all accepted. However, if you are limited to DirectShow you can only use 10-bit R'G'B' (MEDIASUBTYPE_A2R10G10B10 or MEDIASUBTYPE_A2B10G10R10) or less. MediaFoundation types are less restrictive. (The full D3D9 texture format repetoire is supported.) I can't re-program how the EVR and VMR mixers work internally, and as RGB48 is a custom type, it isn't supported.
Passing an R'G'B' type for a video encoded in Y'Cb'Cr is a bad choice by the way. Even the VMR and EVR mixers can do a better quality job than a Y'CbCr-to-saturated 8- or 10-bit R'G'B' conversion. Doing such a conversion before the mixer forces deinterlacing, chroma up-sampling and range conversion to in the color convertor. These are all filtering tasks that should be done in a renderer. The range conversion is the worst offender in that, as it makes the output saturated. That means that from the limited range Y'CbCr only the internal [{16, 16, 16}, {235, 240, 240}] interval is preserved. The so-called BTB (below 16) and WTW (above 235 or 240) is lost in such a conversion. Any reasonable video mixer does preserve these during rendering (if in quality mode) for if the video source contains data in the WTW and BTB.

G_M_C, the 10-bit output mode works fine on multiple PCs I tested (analog, DP and HDMI are all confirmed). Professional-grade solutions that can display 12-bit or more exist for multiple decades already.
Note that the processing format and the format output to display should generally be different. Mixing and rendering in debug mode are perfectly fine if you simply set it to the standard single-precision mode (channels in 32-bit float storage and calculation mode) for testing stuff. (Only for reduced memory pressure and the performance increase along with that, it is worth it to decrease the data storage precision to the 16-bit integer mode with plenty of foot- and headroom reserved. The calculation precision should not be compromised. Lower quality than that will only generate artifacts, but is still somewhat valid when using low-performance or old hardware.) The demands for quantization in the rendering stages are somewhat greater than those for the display panel/projection device. (They don't handle the same color spaces, formats and such.)

[G_M_C]

[...]

G_M_C, the 10-bit output mode works fine on multiple PCs I tested (analog, DP and HDMI are all confirmed). Professional-grade solutions that can display 12-bit or more exist for multiple decades already.
Note that the processing format and the format output to display should generally be different. Mixing and rendering in debug mode are perfectly fine if you simply set it to the standard single-precision mode (channels in 32-bit float storage and calculation mode) for testing stuff. (Only for reduced memory pressure and the performance increase along with that, it is worth it to decrease the data storage precision to the 16-bit integer mode with plenty of foot- and headroom reserved. The calculation precision should not be compromised. Lower quality than that will only generate artifacts, but is still somewhat valid when using low-performance or old hardware.) The demands for quantization in the rendering stages are somewhat greater than those for the display panel/projection device. (They don't handle the same color spaces, formats and such.)

What software did you use JW ? Can you give me a overview/list, so i can try and see for myself?