16 bit Calculation Precision for X265

Augur89 · 2nd May 2021, 18:07

Can we please get 16 bit precision back in the future releases?
By using 16 bit instead of 8 bit precision, the video bitrate can be reduced significantly → way less filesize for the same quality.

This was removed in 2015 for a reason, i never understood.
If i'm not wrong, main reason for usage of x265 is saving bandwidth (video bitrate) and by removing the 16 bit calculation precision the devs drastically reduced the amount of bandwidth, that can be saved by using x265. Why?

Are the X265 Devs reading this forum or is there a way to get in contact with them?

Thanks in advance

rwill · 2nd May 2021, 18:45

But 16 bit is twice the bandwidth of 8 bit, I don't understand what you want.

PS: Dont feed the troll.

Augur89 · 2nd May 2021, 21:34

with 8 bit calculation precision you need a significantly higher video bitrate to make the compressed video look as proper as with 16 bit calculation precision (which can be seen best in dark scenes with smog or dust in the air).

why was the 16 bit calculation precision removed?
i'm still using the old 2015 version since it was way more efficient and would love to see 16 bit calculation precision reimplemented in the new versions

huhn · 3rd May 2021, 09:40

it's still supported and even updated just compile x265 with HIGH_BIT_DEPTH and follow the rules it "needs" like 64 bit.

FranceBB · 3rd May 2021, 13:10

x265 is NOT x264.
Back in the days, when we used to encode files with x264 we noticed that 10bit files were actually smaller than 8bit ones 'cause the additional precision in vector calculations for motion compensation and other things improved compression.
This is no longer the case with x265, 'cause no matter in which bit depth you're gonna end up with, calculations will always be performed in high bit depth.
In other words, it doesn't matter which bit depth you're targeting, calculations will always be done with the highest possible precision, so if this is what kept you up at night, don't worry, you can have sweet dreams.

rwill · 3rd May 2021, 15:24

Quote:

Originally Posted by FranceBB

For instance, let's suppose you feed x265 with 12bit planar and you wanna go down to 8bit planar.
It doesn't matter if you're going down 8bit, all the calculations will be performed with the highest bit depth and only the final result will be 8bit (dithered down).
In other words, it doesn't matter which bit depth you're targeting, calculations will always be done with the highest possible precision, so if this is what kept you up at night, don't worry, you can have sweet dreams.

That is not correct.

In your example the encoder input would be converted from 12 bit to 8 bit and then processed. Pel buffers will be 8 bit.

HEVC just has higher intermediate precision and does not take the shortcuts H.264 took when doing prediction and transform.

Augur89 · 3rd May 2021, 17:26

well that would be nice, but it's not what my experiences show.
i'm not talking about bit depth. i only talk about calculation precision and i think, the highest possible precision at the current releases is 8 bit (instead of the 16 bit, we had in the 2015er versions)

however i had a lot of videos, that looked way worse with the latest version and the exact same coding options than with the old version (just with 16 bit calculation precision). with other words, i didn't find a encoding setting with the new versions, that did even get close to the results, the older versions provided.

with very short test samples, it's the other way round.
so it just would be nice to get the opportunity to chose back

huhn · 3rd May 2021, 17:34

again you can still compile it with 16bpp. is not gone it's still updated and i have no clue when and how it is compiled by default and it does not really matter to the answer it is still an option.

Augur89 · 3rd May 2021, 17:48

so you think, if i select high bit depth, it will automatically be processed with 16 bit calculation precision?

no matter where i changed between 8 bit depth or 10/12/16, the results always weren't the same like 16 bit calculation precision

→ where / in which software do you select high bit depth, so that it increases calculation precision to 16?

Selur · 3rd May 2021, 17:52

@huhn: can you share a binary that still supports 16bit?
Looking at:
https://bitbucket.org/multicoreware/...CMakeLists.txt
https://bitbucket.org/multicoreware/...ux/multilib.sh
https://bitbucket.org/multicoreware/...4/multilib.bat
none of them seems to support 16bit,...
Documentation (https://x265.readthedocs.io/en/maste...n-output-depth) also does only mention 8/10/12 bit,...

Cu Selur

rwill · 3rd May 2021, 18:16

@Augur89

Do you mean the Range Extensions (RExt ?)

Like RExt__HIGH_BIT_DEPTH_SUPPORT, FULL_NBIT and RExt__HIGH_PRECISION_FORWARD_TRANSFORM ?

huhn · 3rd May 2021, 18:23

i never talked about 16 bit output just 16bpp. it still just 8-12 bit.

from the CMakeList: if(X64)

Quote:

# NOTE: We only officially support high-bit-depth compiles of x265
# on 64bit architectures. Main10 plus large resolution plus slow
# preset plus 32bit address space usually means malloc failure. You
# can disable this if(X64) check if you desparately need a 32bit
# build with 10bit/12bit support, but this violates the "shrink wrap
# license" so to speak. If it breaks you get to keep both halves.
# You will need to disable assembly manually.
option(HIGH_BIT_DEPTH "Store pixel samples as 16bit values (Main10/Main12)" OFF)
endif(X64)

source: https://github.com/videolan/x265/tree/master
clearly not dead: https://github.com/videolan/x265/com...c28884293fdabc

and no i don't have binary and no setup where i could even try to compile one.

this is also now leaving my expertise on the matter.

Augur89 · 3rd May 2021, 18:36

Quote:

Originally Posted by rwill

@Augur89

Do you mean the Range Extensions (RExt ?)

Like RExt__HIGH_BIT_DEPTH_SUPPORT, FULL_NBIT and RExt__HIGH_PRECISION_FORWARD_TRANSFORM ?

no, i'm not talking about bit depth.
i'm talking about calculation precision.

PS: i'm currently rendering two 45 min videos (one time with 8 bit calculation precision and another time with 16 bit calculation) to show you the difference

rwill · 3rd May 2021, 19:09

Quote:

Originally Posted by Augur89

PS: i'm currently rendering two 45 min videos (one time with 8 bit calculation precision and another time with 16 bit calculation) to show you the difference

A 3:32 min video would be enough.

Augur89 · 3rd May 2021, 19:25

Quote:

Originally Posted by rwill

A 3:32 min video would be enough.

no, that would be way too short. for a proper test with 2 pass encoding, you need at least 30-50 min to really see a difference.
if they only tested at 3 min video, i wouldn't wonder, why they skipped 16 bit calculation precision

as i wrote before, at very short samples, 8 bit calculation precision even delivers better results sometimes

huhn · 3rd May 2021, 19:32

not how encoding works either you have a difference between a GOP or you don't have a difference.
16 bpp isn't skipped at all but i guess bug fixes and the fact it can be compiled isn't enough?

Augur89 · 3rd May 2021, 19:43

Quote:

Originally Posted by huhn

not how encoding works either you have a difference between a GOP or you don't have a difference.
16 bpp isn't skipped at all but i guess bug fixes and the fact it can be compiled isn't enough?

1) i just can say, the quality loss speaks for itself. i can't explain to you how exactly calculation precision works as i didn't find an explanation anywhere. i just can tell you, that it makes a big difference for testing if you only render 3 min or the whole movie

2) as long as i can't select 16 bit calculation precision and reach the same quality / filesize, i assume, it's not available.
if you have a current version of x265, that included 16 bit calculation precision, please link it. and please keep in mind, that i am not talking about bit depth and bpp.

huhn · 3rd May 2021, 21:14

it's a compile option not a setting it never was a setting. there where just executables with 8bpp and 16bpp if you use a tool that has this option it is just switching between executables.

if i read this correctly it always used for main10 and main12 by default only main8 is using 8 bit.

benwaggoner · 3rd May 2021, 21:28

Where are you talking about 8-bit precision? In the frequency transform? Internally, all the operations run at >>8-bit precision in the encoder and the decoder. IIRC, 16-bit for Main and 32-bit for Main10 and Main12.

Any encoder actually doing 8-bit iDCT would presumably yield poor output in all kinds of typical usage. You need the internal operations to happen at higher precision than input/output to avoid cumulative rounding errors and spatial/frequency domain bugs.

Maybe MPEG-2 had a mode to do internal 8-bit precision, but even then 10-bit was available even with 8-bit encoding. I'm not sure if that's apples-to-apples for what I'm talking about.

huhn · 3rd May 2021, 22:23

you can clearly compile it with 8 bit internal precision.

in the past these builds are called x265 8 bit 8bpp.

what a time: https://forum.doom9.org/showthread.p...06#post1684406

only 2 ways to fix this "issue":
1. find a comparison between two modern 8bpp and 16bpp x265 builds
2. compile then and do the comparison
3. move on they are not idiots that create x265

the rest is talking around.

2nd May 2021, 18:07	#1 \| Link
Augur89 Registered User Join Date: Apr 2021 Posts: 10	16 bit Calculation Precision for X265 Can we please get 16 bit precision back in the future releases? By using 16 bit instead of 8 bit precision, the video bitrate can be reduced significantly → way less filesize for the same quality. This was removed in 2015 for a reason, i never understood. If i'm not wrong, main reason for usage of x265 is saving bandwidth (video bitrate) and by removing the 16 bit calculation precision the devs drastically reduced the amount of bandwidth, that can be saved by using x265. Why? Are the X265 Devs reading this forum or is there a way to get in contact with them? Thanks in advance Last edited by Augur89; 2nd May 2021 at 21:41.

3rd May 2021, 13:10	#5 \| Link
FranceBB Broadcast Encoder Join Date: Nov 2013 Location: Royal Borough of Kensington & Chelsea, UK Posts: 2,904	x265 is NOT x264. Back in the days, when we used to encode files with x264 we noticed that 10bit files were actually smaller than 8bit ones 'cause the additional precision in vector calculations for motion compensation and other things improved compression. This is no longer the case with x265, 'cause no matter in which bit depth you're gonna end up with, calculations will always be performed in high bit depth. In other words, it doesn't matter which bit depth you're targeting, calculations will always be done with the highest possible precision, so if this is what kept you up at night, don't worry, you can have sweet dreams. __________________ LUT Collection FFAStrans Videotek - AAA - SafeColorLimiter Last edited by FranceBB; 3rd May 2021 at 16:52.

3rd May 2021, 17:52	#10 \| Link
Selur Registered User Join Date: Oct 2001 Location: Germany Posts: 7,277	@huhn: can you share a binary that still supports 16bit? Looking at: https://bitbucket.org/multicoreware/...CMakeLists.txt https://bitbucket.org/multicoreware/...ux/multilib.sh https://bitbucket.org/multicoreware/...4/multilib.bat none of them seems to support 16bit,... Documentation (https://x265.readthedocs.io/en/maste...n-output-depth) also does only mention 8/10/12 bit,... Cu Selur __________________ Hybrid here in the forum, homepage

3rd May 2021, 21:28	#19 \| Link
benwaggoner Moderator Join Date: Jan 2006 Location: Portland, OR Posts: 4,770	Where are you talking about 8-bit precision? In the frequency transform? Internally, all the operations run at >>8-bit precision in the encoder and the decoder. IIRC, 16-bit for Main and 32-bit for Main10 and Main12. Any encoder actually doing 8-bit iDCT would presumably yield poor output in all kinds of typical usage. You need the internal operations to happen at higher precision than input/output to avoid cumulative rounding errors and spatial/frequency domain bugs. Maybe MPEG-2 had a mode to do internal 8-bit precision, but even then 10-bit was available even with 8-bit encoding. I'm not sure if that's apples-to-apples for what I'm talking about. __________________ Ben Waggoner Principal Video Specialist, Amazon Prime Video My Compression Book

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

2nd May 2021, 18:45	#2 \| Link
rwill Registered User Join Date: Dec 2013 Posts: 348	But 16 bit is twice the bandwidth of 8 bit, I don't understand what you want. PS: Dont feed the troll.

2nd May 2021, 21:34	#3 \| Link
Augur89 Registered User Join Date: Apr 2021 Posts: 10	with 8 bit calculation precision you need a significantly higher video bitrate to make the compressed video look as proper as with 16 bit calculation precision (which can be seen best in dark scenes with smog or dust in the air). why was the 16 bit calculation precision removed? i'm still using the old 2015 version since it was way more efficient and would love to see 16 bit calculation precision reimplemented in the new versions

3rd May 2021, 09:40	#4 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,923	it's still supported and even updated just compile x265 with HIGH_BIT_DEPTH and follow the rules it "needs" like 64 bit.

3rd May 2021, 17:26	#7 \| Link
Augur89 Registered User Join Date: Apr 2021 Posts: 10	well that would be nice, but it's not what my experiences show. i'm not talking about bit depth. i only talk about calculation precision and i think, the highest possible precision at the current releases is 8 bit (instead of the 16 bit, we had in the 2015er versions) however i had a lot of videos, that looked way worse with the latest version and the exact same coding options than with the old version (just with 16 bit calculation precision). with other words, i didn't find a encoding setting with the new versions, that did even get close to the results, the older versions provided. with very short test samples, it's the other way round. so it just would be nice to get the opportunity to chose back

3rd May 2021, 17:34	#8 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,923	again you can still compile it with 16bpp. is not gone it's still updated and i have no clue when and how it is compiled by default and it does not really matter to the answer it is still an option.

3rd May 2021, 17:48	#9 \| Link
Augur89 Registered User Join Date: Apr 2021 Posts: 10	so you think, if i select high bit depth, it will automatically be processed with 16 bit calculation precision? no matter where i changed between 8 bit depth or 10/12/16, the results always weren't the same like 16 bit calculation precision → where / in which software do you select high bit depth, so that it increases calculation precision to 16?

3rd May 2021, 18:16	#11 \| Link
rwill Registered User Join Date: Dec 2013 Posts: 348	@Augur89 Do you mean the Range Extensions (RExt ?) Like RExt__HIGH_BIT_DEPTH_SUPPORT, FULL_NBIT and RExt__HIGH_PRECISION_FORWARD_TRANSFORM ?

3rd May 2021, 19:32	#16 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,923	not how encoding works either you have a difference between a GOP or you don't have a difference. 16 bpp isn't skipped at all but i guess bug fixes and the fact it can be compiled isn't enough?

3rd May 2021, 21:14	#18 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,923	it's a compile option not a setting it never was a setting. there where just executables with 8bpp and 16bpp if you use a tool that has this option it is just switching between executables. if i read this correctly it always used for main10 and main12 by default only main8 is using 8 bit.

3rd May 2021, 22:23	#20 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,923	you can clearly compile it with 8 bit internal precision. in the past these builds are called x265 8 bit 8bpp. what a time: https://forum.doom9.org/showthread.p...06#post1684406 only 2 ways to fix this "issue": 1. find a comparison between two modern 8bpp and 16bpp x265 builds 2. compile then and do the comparison 3. move on they are not idiots that create x265 the rest is talking around.