Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th March 2009, 17:13   #1  |  Link
gatewaymastering
Registered User
 
Join Date: Nov 2008
Location: Portland ME
Posts: 17
10 bit vs. 8 bit

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
gatewaymastering is offline   Reply With Quote
Old 10th March 2009, 17:16   #2  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
what do you mean with 8 and 10 bit video file?
Sharktooth is offline   Reply With Quote
Old 10th March 2009, 17:17   #3  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Neither, since x264 only takes YV12 input.
Dark Shikari is offline   Reply With Quote
Old 10th March 2009, 19:00   #4  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
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.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 11th March 2009, 03:08   #5  |  Link
cacepi
Just as bad up as down.
 
Join Date: Nov 2005
Posts: 166
Quote:
Originally Posted by gatewaymastering View Post
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.
cacepi is offline   Reply With Quote
Old 11th March 2009, 09:05   #6  |  Link
Koorogi
Registered User
 
Koorogi's Avatar
 
Join Date: Feb 2009
Posts: 8
Quote:
Originally Posted by cacepi View Post
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.
Koorogi is offline   Reply With Quote
Old 11th March 2009, 09:34   #7  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,605
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...
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 11th March 2009, 15:35   #8  |  Link
gatewaymastering
Registered User
 
Join Date: Nov 2008
Location: Portland ME
Posts: 17
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
gatewaymastering is offline   Reply With Quote
Old 11th March 2009, 15:38   #9  |  Link
J_Darnley
Registered User
 
J_Darnley's Avatar
 
Join Date: May 2006
Posts: 959
Quote:
Originally Posted by gatewaymastering View Post
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.
__________________
x264 log explained || x264 deblocking how-to
preset -> tune -> user set options -> fast first pass -> profile -> level
Doom10 - Of course it's better, it's one more.
J_Darnley is offline   Reply With Quote
Old 11th March 2009, 15:52   #10  |  Link
Golgot13
Registered User
 
Join Date: Mar 2006
Location: Grand StrateGuerre
Posts: 361
@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).
Golgot13 is offline   Reply With Quote
Old 11th March 2009, 16:50   #11  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,799
Quote:
Originally Posted by Golgot13 View Post
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 11th March 2009 at 16:54.
LoRd_MuldeR is offline   Reply With Quote
Old 11th March 2009, 19:35   #12  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
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.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 12th March 2009, 06:16   #13  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,362
Quote:
Originally Posted by Sagekilla View Post
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 .
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 12th March 2009, 06:36   #14  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
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
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 12th March 2009, 08:19   #15  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Quote:
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...)
__________________
Manao is offline   Reply With Quote
Old 12th March 2009, 08:22   #16  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Manao View Post
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?

Quote:
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.
Dark Shikari is offline   Reply With Quote
Old 12th March 2009, 09:18   #17  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
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.
__________________
Manao is offline   Reply With Quote
Old 12th March 2009, 09:34   #18  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Manao View Post
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?
Dark Shikari is offline   Reply With Quote
Old 12th March 2009, 09:37   #19  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
Quote:
Originally Posted by Dark Shikari View Post
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.
akupenguin is offline   Reply With Quote
Old 12th March 2009, 11:06   #20  |  Link
Gabriel_Bouvigne
L.A.M.E. developer
 
Gabriel_Bouvigne's Avatar
 
Join Date: Dec 2001
Location: Paris - France
Posts: 276
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.
Gabriel_Bouvigne is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:57.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.