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]

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]

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]

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]

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]

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]

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 8bitsDespite the fact that deblocking is partially broken at bit depths above 8 due to a mistake in the standard?


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]

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]

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.

[Golgot13]

"I mean, no reason aside from the lack of encoder, of decoder, and of hardware supporting it..."


Hello Manao (Salut !)

I 'm not agree there are some product available in High10 (chipset encoder and decoder)
since last announce at NAB2008 from japanese company ;)

I understand some company start integration since last IBC. So we will see nice things at next NAB2009...

[akupenguin]

I *think* that some extra compression could also be gathered from H10P because it allows the use of YCgCo color space.
If that's true, then that improvement is really easy. x264 already supports YCgCo (the option is named --colormatrix, and it doesn't affect anything in the stream other than one header field), all the needs to be implemented is the media player's color conversion functions.

[Manao]

Sorry, I should have said "lack of encoder, decoder or hardware" for the common people. Announced 10 bits encoder/decoder are mostly 5000$+ rack-mount machines, to be used by broadcasters / content providers.

[Golgot13]

Sorry, I should have said "lack of encoder, decoder or hardware" for the common people. Announced 10 bits encoder/decoder are mostly 5000$+ rack-mount machines, to be used by broadcasters / content providers.

No, I talked about chipset so the price is automaticly different ;)
We will see product which use it at NAB2009...

And I know another chipset (available since one year) which can encode in High10
but in SD only (with a firmware update), High Profile (up to 4.2) is available in HD.
This chipset is used on some new HD camcorder :D

[Gabriel_Bouvigne]

If that's true, then that improvement is really easy. x264 already supports YCgCo (the option is named --colormatrix, and it doesn't affect anything in the stream other than one header field), all the needs to be implemented is the media player's color conversion functions.
The only issue is that from what I remember, YCgCo needs 9 bits to handle data coming from 24bits RGB space. (which is why H10P profile is then required)

[akupenguin]

The only issue is that from what I remember, YCgCo needs 9 bits to handle data coming from 24bits RGB space.
That's no different from YCbCr.
Only 1/4 of the possible YCbCr triples lie inside the RGB gamut, so 8bit YCbCr has only about 2^22 valid colors. You need 9bit YCbCr in order to have as many colors as 8bit RGB (though it's still not quite lossless with any simple rounding scheme, due to the rotated coordinate system). But typical videos don't do that, they downsample chroma both in colordepth and in spatial resolution.

YCgCo has exactly the same issue, except that 9bit YCgCo can losslessly store 8bit RGB, because the coordinates are rotated by an amount that makes integer rounding come out right. 8bit RGB -> 8bit YCgCo -> 8bit RGB also has less distortion than 8bit YCbCr, for the same reason.

However, I don't know how YCgCo fares in terms of decorrelation, either objectively (reducing entropy of the chroma planes) or psy (allowing chroma subsampling). After all, if you wanted perfect reconstruction at the cost of worse decorrelation, you could just use G, R-G, B-G, which fits in 8bit (or at least can be reconstructed if you only store the least 8 bits. That does make subpel mc and clipping after quantization tricky, but I'm trying it anyway in my experimental lossless codec).

[Gabriel_Bouvigne]

I overlooked the fact that 9 bits are also needed to represent RBG gamut within the YCbCr space...

About YCgCo, there used to be results on Malvar's homepage at Microsoft (within documents related to the HD Photo format), but it seems that all papers related to YCgCr are now gone from this homepage.

We are then left with "YCoCg-R: A Color Space with RGB Reversibility and Low Dynamic Range" (Google will find it) which only present cumulative comparison against YCgCr.

[benwaggoner]

I overlooked the fact that 9 bits are also needed to represent RBG gamut within the YCbCr space...

About YCgCo, there used to be results on Malvar's homepage at Microsoft (within documents related to the HD Photo format), but it seems that all papers related to YCgCr are now gone from this homepage.

We are then left with "YCoCg-R: A Color Space with RGB Reversibility and Low Dynamic Range" (Google will find it) which only present cumulative comparison against YCgCr.
What was the URL that was at? I'll see if I can find where the documents went.

[Gabriel_Bouvigne]

What was the URL that was at? I'll see if I can find where the documents went.
From memory, they were on Malvar's Ms Research page:
http://research.microsoft.com/en-us/people/malvar

(but YOU might perhaps be able to directly ask him about any YCoCg paper?)