10 bit vs. 8 bit

[gatewaymastering]

Hello,

I am doing blu-ray encoding. Does x264 take advantage of a 10 bit video file and dither it down to 8 bit during encoding or does it truncate?

Thanks

[Sharktooth]

what do you mean with 8 and 10 bit video file?

[Dark Shikari]

Neither, since x264 only takes YV12 input.

[Sagekilla]

He probably means RGB with 8-bits per channel or 10-bits per channel (24 bit, 30 bit). Either way, x264 won't accept it like Dark Shikari said.

[cacepi]

Originally Posted by gatewaymastering

I am doing blu-ray encoding. Does x264 take advantage of a 10 bit video file and dither it down to 8 bit during encoding or does it truncate

Even if x264 supported 10-bit - which it doesn't - you couldn't encode it as Blu-Ray only supports High profile. High profile has no 10-bit support.

You'll need to downsample to 8-bit planar (4:2:0 YUV) before encoding if you want Blu-ray delivery.

[Koorogi]

Originally Posted by cacepi

Even if x264 supported 10-bit - which it doesn't - you couldn't encode it as Blu-Ray only supports High profile. High profile has no 10-bit support.

You'll need to downsample to 8-bit planar (4:2:0 YUV) before encoding if you want Blu-ray delivery.

I think the point of the question was about how x264 reduces it to 8-bits - does it simply truncate the extra bits, or does it do dithering?

Of course, as DS pointed out, it doesn't handle it at all. You'd need to find some other software to do the 10→8 conversion for you.

[scharfis_brain]

x264 doesn't deduce the colourspace.
It simply can't. It only accepts YV12 input, which already has 8 bits per channel and subsampled chroma.

The colourspace reduction has to be done with something else.
Most probably within Directshow or so...

[gatewaymastering]

Sorry about that. I should have explained it better.

So the "ConvertToYV12()" in the avs script would convert a 10bit per channel RGB file by trucating it? So I should dither it to 8bits per channel first?

Thanks

[J_Darnley]

Originally Posted by gatewaymastering

So the "ConvertToYV12()" in the avs script would convert a 10bit per channel RGB file by trucating it?

No, because Avisynth doesn't support 10-bit video. The conversion to 8-bit would be handled by the source filter.

[Golgot13]

@gatewaymastering


I recommand you to use Xscaler (a PeP tool) to convert 10bit to 8bit (there are different dithering filters)

About x264 and 10bit, I understand it will be integrate in futur (with High 10 Profil).

[LoRd_MuldeR]

Originally Posted by Golgot13

About x264 and 10bit, I understand it will be integrate in futur (with High 10 Profil).

Well, the "High 10" (and above) profile of the H.264 standard does support "9 and 10 Bit Sample Depth".

But that doesn't mean that it will be implemented in x264. The same goes for 4:2:2 and 4:4:4 chroma support.

I didn't read any announcements so far...

[Sagekilla]

Yes, it will probably be implemented eventually. But Dark Shikari already pointed out that implementing other color spaces basically requires a huge rewrite. I don't know the specifics internally, but x264 is more or less hard coded for YV12 at the moment.

[benwaggoner]

Originally Posted by Sagekilla

Yes, it will probably be implemented eventually. But Dark Shikari already pointed out that implementing other color spaces basically requires a huge rewrite. I don't know the specifics internally, but x264 is more or less hard coded for YV12 at the moment.

Also, I'm not aware of any place where > YV12 is being used.

I know that Flash supports the 4:2:2 profile in theory, but haven't ever seen an actual file using it. And Flash's rendering pipeline is 8-bit anyway, so there wouldn't really be any point.

Honestly, a well-dithered 8-bit 4:2:0 is pretty darn well at our visual threshold. The nice thing about 10-bit is that you don't need to dither to hide gradients or banding, but a well-dithered 8-bit won't show gradients or banding either.

Bad banding in a final encode is normally in the source as well anyway .

[Sagekilla]

We could use high bit depths in intermediate (Read: processing) stages though. A lot of filtering done in avisynth could stand to benefit from higher bit depths, to prevent banding from popping up. It's pretty easy to mask with appropriate use of Gradfun2db() and AQ in x264, but it could be done more elegantly if we had proper support for high bit depth processing

[Manao]

Honestly, a well-dithered 8-bit 4:2:0 is pretty darn well at our visual threshold. The nice thing about 10-bit is that you don't need to dither to hide gradients or banding, but a well-dithered 8-bit won't show gradients or banding either.

A well dithered 8-bit 4:2:0 is perfectly watchable. However, you can't encode it efficiently without losing the dither (since dither acts like noise with a very small variance). Furthermore, though it isn't intuitive, 10bits AVC is actually more efficient than 8bits, so there are actually no reason not to encode in 10 bits (I mean, no reason aside from the lack of encoder, of decoder, and of hardware supporting it...)

[Dark Shikari]

Originally Posted by Manao

A well dithered 8-bit 4:2:0 is perfectly watchable. However, you can't encode it efficiently without losing the dither (since dither acts like noise with a very small variance). Furthermore, though it isn't intuitive, 10bits AVC is actually more efficient than 8bits

Despite the fact that deblocking is partially broken at bit depths above 8 due to a mistake in the standard?

Originally Posted by JVT-experts

Equations 8-474 to 8-477 derive tc and tc0 from tc0' (which itself is derived from indexA and bS). tc and tc0 are used to clip delta of pixels values, so their inherent scale is the plane bitdepth. tc0' is decorrelated from bitdepth. With a bitdepth of 8, we have :
(1) tc0 = tc0'
(2) tc = tc0 + (condP ? 1 : 0) + (condQ ? 1 : 0) or
(2') tc = tc0 + 1

With a bitdepth of more than 8, we have :
(3) tc0 = tc0' << (bitdepth - 8)
(4) tc = tc0 + (condP ? 1 : 0) + (condQ ? 1 : 0) or
(4') tc = tc0 + 1

I think that, for homogeneity's sake, it should have been :
(3) tc0 = tc0' << (bitdepth - 8)
(4'') tc = tc0 + (((condP ? 1 : 0) + (condQ ? 1 : 0)) << (bitdepth - 8)) or
(4''') tc = tc0 + (1 << (bitdepth - 8))

If we don't do it my way, the behavior of the deblocking is changed when bitdepth increases. Naively, I would say that, given a set of 8bits pixels, if I were to multiply those pixels by 2^N, then to apply the deblocking process as if I had a bitdepth of 8+N bits, and finally to divide the result of the deblocking process by 2^N, I should get the same results (if we ignore rounding errors) as if I were to run the deblocking process in 8bits on the original set of 8bits pixels. Equations 8-474 and 8-475 prevent that from happening, because they aren't homogeneous. And I think that definitely wasn't a wanted feature.

[Manao]

I'm the one who sent that email to jvt-experts, so I know that deblocking doesn't behave exactly in the same way with 8 and 10 bits. But that doesn't amount to saying deblocking is partially broken or that the standard made a mistake. And that doesn't change the fact that a normative 10 bits AVC is more efficiency than a normative 8 bits AVC.

[Dark Shikari]

Originally Posted by Manao

I'm the one who sent that email to jvt-experts, so I know that deblocking doesn't behave exactly in the same way with 8 and 10 bits. But that doesn't amount to saying deblocking is partially broken or that the standard made a mistake. And that doesn't change the fact that a normative 10 bits AVC is more efficiency than a normative 8 bits AVC.

Why is it more efficient despite the hordes of unnecessary LSBs to code?

Or are you saying that because of the extra precision--since the encoder can decide when and when not to code the extra LSBs--it offers more flexibility and thus more compression?

[akupenguin]

Originally Posted by Dark Shikari

Why is it more efficient despite the hordes of unnecessary LSBs to code?

There don't have to be any extra LSBs. If you increase the depth by 2 bits, and increase the QP by 12, you're coding the exact same significant bits as before, just with less intermediate rounding in mc/idct/etc.
If you didn't care about speed you could take this all the way to the asymptote: make a codec in 32bit float.

[Gabriel_Bouvigne]

I *think* that some extra compression could also be gathered from H10P because it allows the use of YCgCo color space.
Rico Malvar seems to think that this is a more efficient color space, and even if all I've seen is only some papers, I would trust him on most things related to the entropy of transforms.