Avysinth showing double width for HEVC 10bits

[Shishi]

Hello !

Nice to see a forum who does not need 5 days to wait. I am reencoding my librairy with last x265 build and ffmpeg (in 10bits depth).

But when i open the output with an AVS script, it gives me a wrong double width (exemple 1472 => 2944), and i can't use compare. Of course, mediainfo and any other players/encoders says the good width.

Is there any way to go through this ?

Thank you !

[Selur]

Not much details on how you are opening your video in Avisynth.

When comparing videos using avisynth both videos need to have:
a. same resolution
b. same bit depth

You did read http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth#Importing_High_Bit-d..._into_AviSynth right?

[Shishi]

Yes i did. In fact, the source is 8bits depth x264 but i reencoded it into a 10bits depth x265 file. The resolution is the same, only avisynth is giving me a wrong doubled width. I actually read a lot of forums about that issue with 10 bits, but i can't figure out how to open the file with correct width. I used LSMASHVideoSource & LWLibavVideoSource to open source in avs script.

[Selur]

Here's an example where I

• load the plugin
• load the original source
• load the reencode
• convert the reencode to 8bit since Avisynth works in 8bit (or stacked mode)
• Stack the videos
• return the merged video

# loading Plugins:
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\flash3kyuu_deband.dll")
# load videos
original = LWLibavVideoSource("F:\TestClips&Co\Test-AC3-5.1.mp4",cache=false,dr=true,format="YUV420P8",repeat=true) # 8bit YUV 420 source
reencode = LWLibavVideoSource("E:\Output\Test-AC3-5.1.mp4",cache=false,dr=true,stacked=true,format="YUV420P16",repeat=true) # 10bit YUV 420 source
# make sure 10bit video is converted to 8bit for preview (one could also use 'dither tools', but I prefer f3kdb
reencode = reencode.f3kdb_dither(stacked=true,input_depth=16)
# stack videos for comparison (alternatively one could interlaced the video)
StackHorizontal(original, reencode)
# return stacked video
return last

Cu Selur

Ps.: Personally I would use Vapoursynth, since it 'feels' more natural to me when handling high bit depth sources.

[poisondeathray]

Like Selur, I prefer vapoursynth too for high bit depth handling

But , avisynth+ can handle it too . FFMS2 will handle it natively instead of the stacked workaround. The updated avspmod can handle conversions internally for display, as can vdub2, media players like mpv

[Selur]

So using Avisynth+ and the newer avspmod one could instead of converting the 10bit reencode to 8bit for preview convert the 8 bit source to 10bit (i.e. using ConvertBits(..)), stack/interleave/.. the two sources and then preview them, nice. ('stacked=true' in the LWLibavVideoSource shouldn't be necessary then either )

Good to know.

Cu Selur

[Shishi]

Thank you, you two for this awesome answers. I will try to first convert the 8bits sample source to 10bits using the last method.

[somespirit]

Yes i did. In fact, the source is 8bits depth x264 but i reencoded it into a 10bits depth x265 file.

8bits (source) to 10bits is useless operation, you will get the same colors, also x265 is only 8-10% better than x264 ........

[Shishi]

Keep this debate outside this topic.

X264 and X265 have nothing to compare as they don't stand for the same goal. X265 is optimized for streaming at low bitrate while x264 is more bitrate demanding but better for small scene details to retain.

The 10bits on x265 has not only to do with color but with compression algorithm, anyway, the debate here is pointless. Do your research, and please feel free to open a thread to debate what you want to.

[somespirit]

The 10bits on x265 has not only to do with color but with compression algorithm, anyway, the debate here is pointless.

8bit x265 has chroma subsampling 4:2:0 while 10bit x265 has 4:2:2, so you will have 2 more bits (10 bits per 1 colour pixel) to compress compared to 8bits and final encode result will be bigger file if you want to save the same quality as 8 bits video.

so operation such 8bits x264 to 10bits x265 is useless better do encode to (same) 8bits x265

[poisondeathray]

8bit x265 has chroma subsampling 4:2:0 while 10bit x265 has 4:2:2, so you will have 2 more bits (10 bits per 1 colour pixel) to compress compared to 8bits and final encode result will be bigger file if you want to save the same quality as 8 bits video.

so operation such 8bits x264 to 10bits x265 is useless better do encode to (same) 8bits x265

x265 supports 4:2:0 in 8bit and 10bit configurations too

[Shishi]

The 10bits on x265 has not only to do with color but with compression algorithm, anyway, the debate here is pointless.

8bit x265 has chroma subsampling 4:2:0 while 10bit x265 has 4:2:2, so you will have 2 more bits (10 bits per 1 colour pixel) to compress compared to 8bits and final encode result will be bigger file if you want to save the same quality as 8 bits video.

so operation such 8bits x264 to 10bits x265 is useless better do encode to (same) 8bits x265

Sorry to say you are wrong. I invite you to test some 10bit encode with small samples. At my eyes, it reduces banding and improve compression in most case. x265 10bit for sure support 4:2:0 chroma. Glad we got this conversation if it can helps you in anyway, now please keep this debate outside from here.

http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

[Selur]

as a side note: x265 8bit vs 10bit compression gain is less than for x264, but the main point for 10bit usually is to avoid banding without having to add grain.

[somespirit]

[QUOTE=Shishi;2539571][QUOTE=somespirit;2539548]

x265 10bit for sure support 4:2:0 chroma.

now i understand that you dont know what means 10 bits encoding:

10 bits encoding means that every 1 colour pixel (in 1 frame of video) is represent by 10 bits and is using chroma subsampling 4:2:2 always ........

chroma subsampling 4:2:2 that is 10 bits per 1 pixel - 10 bits encoding

chroma subsampling 4:2:0 that is 8 bits per 1 pixel - 8 bits encoding

, no matter what encoder you are using x264 or x265

both encodings 8bits and 10bits using 24 bit color depth (or so called 8 bit color depth) but when we using 4:2:2 chroma subsampling (10 bits encoding) we get more accurate color (for 1 pixel) and that is why we have better quality of video with 10 bits

and from here we can see how one type compression is working for all encoders, we have 24 bits for 1 color pixel but in result output file that pixel is represent by 8bits or by 10 bits, that way encoder is saving: 24bits - 8bits (or 10 bits) = 16 bits (14 bits)

[sneaker]

Chroma-subsampling and bitdepth are totally separate. You can have 12 bit 4:2:0 or 8 bit 4:4:4 or any other combination.
For example UltraHD Blu-Ray uses 10 bit 4:2:0 for HDR10 encodings. That's on average 15 bits per pixel, actually (three planes: 10 bit Y (luma) per pixel, 10/4 bit CB, 10/4 bit CR because there are only 2*1 chroma samples per 4 pixels when using 4:2:0 chroma-subsampling.)

[Selur]

now i understand that you dont know what means 10 bits encoding:

Terminology in video and image editing isn't always the same.
I think your are mixing, 'bit size of chroma sampling', 'coding precision' and 'bit size of chroma range'.

'bit size of chroma sampling': the number of bits an uncompressed YUV requires to represent the chroma information (https://en.wikipedia.org/wiki/Chroma_subsampling)
'bit size of chroma range': the number of bits required to represent a chroma value (full (0-255) and limited (16-235) RGB range both require 8bit)
'coding precision': the precision which is used to represent float values inside the video stream.

In video encoding:
Xbit video encoding describes that Xbit coding precision was used. (in case of x265 for example the calculation precision inside the encoder is always 16bit, but the output coding precision can be 8, 10 or 12bit). For x264 (iirc) on the other hand calculation and coding precision is the same.
This is independent from the bits the chroma sampling.

When speaking of 8bit H.265 one normally refers to H.265 which uses a coding precision of 8bit.
H.265 content with a calculation prevision of 10bit and a 4:2:2 chroma sampling, is normally referred as '10bit H.265 4:2:2'.

-> I think you are not using the normal terminology that is used for video encoding.

Cu Selur

[poisondeathray]

To add to what sneaker and selur are explaining

Bits per Channel component (or just Bits per Channel) is "bpc" . This notation is typically used in video description. Separate descriptor from chroma subsampling

Bits per Pixel is "bpp" is typically not used for video description

"10bits" (10bpc) means there are 0 to 1023 = 1024 code values per channel component. 8bits means 0 to 255 = 256 code values per channel . This is what you referred to as "color depth"

[Shishi]

10 bits encoding means that every 1 colour pixel (in 1 frame of video) is represent by 10 bits and is using chroma subsampling 4:2:2 always ........

This is a non sense, you are mixing 2 differents things. Bit color is not related to chroma subsampling.

Bit color refers to the calculation of colors a single pixel can display. See it as the color accuracy.

Chroma subsampling refers to the behavior of a group of 8 pixels (4x2) and how they display color (4:2:0 => 2 square of 4, 4:2:2 => 4 block of 2, 4:4:4 each pixel). It's the color resolution. 4:4:4 need more bitrate than 4:2:0 (exactly like a 4k resolution needs more than FHD (4x pixels))

You can display 12bits color depth on a 4:2:0 format, and you can display 8bits color depth on a 4:4:4 format. A display can support 4:4:4 but only 8bits color depth.

All of this is theory. Now, encoders are working with algorithms, as the pdf i linked to you describe it. The compression algorithm is more efficient at 10bit depth (for a same bitrate, quality is better, there is less need to quantize, there is less error. If the quality is higher for the same bitrate, then the bitrate is lower for the same quality). The downside is compatibility and ressources needed to encode/decode.

[_Al_]

Bitdepth and chroma subsampling can mess up a brain while trying to understand that. The best example is to visualize it.

Imagine videos with resolution 10x10, first video is 10 bit 4:2:0 second 8 bit 4:2:2. If having in some array those would look like this:

8bit 4:2:2 (8bit values from 0 to 255):
Y plane:
[[ 63 104 125 129 106 79 68 105 112 101]
[ 59 70 102 142 127 87 63 74 102 118]
[ 96 74 102 119 94 114 76 71 91 114]
[127 95 99 82 91 91 102 83 81 100]
[110 116 113 77 88 73 103 95 90 91]
[110 120 127 49 61 67 91 108 96 101]
[ 90 130 93 53 48 60 89 110 99 85]
[ 80 117 85 56 56 71 96 122 107 106]
[100 104 98 57 64 88 83 125 118 128]
[119 121 96 66 80 104 72 121 152 173]]
U plane
[[128 122 123 126 123]
[129 124 122 126 123]
[131 129 132 125 124]
[126 131 146 127 126]
[124 127 145 131 126]
[123 126 135 134 126]
[123 129 138 136 130]
[124 129 143 143 136]
[122 130 150 146 138]
[121 130 151 149 135]]
V plane
[[127 132 131 129 129]
[126 132 135 128 129]
[125 129 128 129 128]
[128 131 117 128 127]
[130 137 119 126 126]
[130 134 127 125 127]
[130 132 123 122 125]
[130 134 120 118 121]
[130 131 115 115 120]
[131 129 113 114 121]]


and same video BUT 4:2:0 and 10 bit, values are from 0 to 1024:
Y plane
[[250 415 498 516 424 315 271 419 448 404]
[238 281 406 566 509 349 253 296 408 472]
[383 298 408 477 375 455 304 284 365 455]
[509 382 397 328 365 366 409 331 324 400]
[439 463 453 308 351 292 411 380 361 366]
[439 479 510 195 242 267 362 430 384 403]
[362 519 371 211 191 241 356 438 395 341]
[320 470 341 223 223 283 384 487 426 423]
[400 415 393 227 256 353 332 499 470 512]
[475 484 386 266 319 417 286 485 609 692]]
U plane
[[515 493 492 504 491]
[513 517 553 505 499]
[494 509 562 528 504]
[495 514 562 559 531]
[488 520 602 591 545]]
V plane
[[506 527 530 513 515]
[506 523 492 513 509]
[520 538 490 502 506]
[521 531 486 480 492]
[522 521 455 458 482]]

So in the second example, values are less prone to banding , more integer choices 0-1024, not 0 to 255, but chroma resolution is much less

Those arrays are numpy arrays of real videos, as you can see, integer values are matching

[_Al_]

16bit 4:4:4 video example: three plane Y,U and V, all same resolution, Integer values 0 to 65535
[[16002 26580 31874 33031 27124 20174 17370 26832 28691 25865]
[15208 17958 25995 36254 32569 22338 16165 18933 26106 30212]
[24534 19057 26139 30547 24027 29105 19430 18155 23382 29115]
[32579 24428 25412 21000 23382 23391 26206 21195 20729 25608]
[28088 29639 29001 19721 22472 18706 26326 24315 23102 23412]
[28065 30681 32625 12504 15515 17088 23179 27536 24565 25776]
[23157 33208 23735 13508 12239 15438 22797 28057 25273 21840]
[20491 30055 21797 14266 14283 18139 24579 31187 27269 27069]
[25601 26540 25181 14525 16413 22597 21215 31914 30093 32790]
[30384 30986 24681 17010 20423 26673 18315 31055 38954 44257]]
[[33150 31770 30816 31071 31425 31925 32433 32142 31275 30818]
[33043 32613 32067 30809 31151 32027 32375 32483 31322 30628]
[33819 33061 32860 32881 35321 32181 31765 32385 32003 31012]
[32555 31448 32807 36570 39158 34529 31247 32203 32749 31385]
[32018 30969 31561 35961 37477 37239 32018 32347 32155 32456]
[31613 31244 31870 34039 33528 36530 34321 31608 31934 33324]
[31753 31341 32590 35395 34283 36877 35202 32429 32689 35265]
[32083 31503 32211 36156 35604 38308 37213 34171 34164 36295]
[31154 31870 32365 36245 38678 39829 37794 34283 35666 35516]
[31027 31456 33002 36140 39218 40265 38333 35450 33905 34937]]
[[32171 33535 33895 34082 33729 33042 32655 33190 33134 32585]
[32110 33046 33422 34710 35055 33038 32575 32506 33084 33042]
[31716 32699 33057 33131 32129 33143 33082 32567 32655 33084]
[31956 34686 34578 30683 28750 31562 33660 32843 31920 32744]
[32471 35560 36518 31495 30345 29997 33253 33016 31766 32060]
[32975 34205 35015 32788 33532 30726 31847 33359 32487 31832]
[32813 34598 34366 31623 32286 30156 31203 32658 32138 30727]
[32691 35194 35499 30950 31333 29260 29743 31505 31336 29936]
[32999 33627 34745 30941 29254 28011 29388 31376 30311 30199]
[33319 33960 33534 31105 28512 27297 29213 30742 31409 30540]]


and now a killer, 4:4:4 32bit floating point:
[[0.21235317 0.4010452 0.49546707 0.5161086 0.41073668 0.2867854
0.23676962 0.40554 0.4386915 0.388287 ]
[0.19819644 0.24726236 0.39059868 0.5735873 0.50786173 0.32538342
0.21527691 0.26464078 0.3925736 0.46581787]
[0.3645557 0.26686308 0.39317358 0.47180828 0.3554953 0.4460774
0.27351803 0.25075632 0.34398958 0.44625992]
[0.5080342 0.3626538 0.38019574 0.30151987 0.34398377 0.34417087
0.39437714 0.30497038 0.2966721 0.38370836]
[0.42793396 0.4555993 0.4442323 0.27869466 0.32775614 0.26060343
0.39649826 0.36064446 0.33900744 0.34454525]
[0.4275302 0.4741935 0.5088658 0.14998227 0.20366427 0.23173371
0.34036434 0.41811195 0.3650967 0.38671327]
[0.3399899 0.5192631 0.3502838 0.16788396 0.14522861 0.20230006
0.33357728 0.42740127 0.37773067 0.31649715]
[0.29242757 0.46301907 0.3157128 0.18138622 0.181704 0.25048733
0.36537012 0.4832294 0.4133223 0.40976006]
[0.38358194 0.40031806 0.3760894 0.18601167 0.21970254 0.32999557
0.30535823 0.49618366 0.46371165 0.5118134 ]
[0.46889478 0.47963646 0.3671758 0.23035222 0.29121524 0.4026969
0.25361484 0.48086292 0.621758 0.71632946]]
[[ 0.00665272 -0.0173967 -0.03404726 -0.02959816 -0.02341255 -0.01470044
-0.005834 -0.01091611 -0.02604435 -0.03400423]
[ 0.00480385 -0.00270832 -0.01221984 -0.03415442 -0.02820379 -0.01292369
-0.00685675 -0.00496241 -0.02521988 -0.03731221]
[ 0.01832895 0.00510704 0.00160441 0.00196287 0.04451607 -0.01024256
-0.01748561 -0.00668563 -0.01333471 -0.03061602]
[-0.00372016 -0.02301498 0.00068379 0.06629778 0.11142674 0.03070546
-0.02651834 -0.00985553 -0.00032831 -0.02411095]
[-0.01307419 -0.03137048 -0.02104337 0.05568323 0.08211496 0.07796028
-0.01307984 -0.00734481 -0.01069369 -0.00543471]
[-0.02014837 -0.02657648 -0.0156616 0.02216927 0.01325478 0.06559356
0.027091 -0.02023618 -0.01454819 0.00969708]
[-0.01770791 -0.02488864 -0.00310955 0.04580775 0.02641161 0.07164796
0.04245172 -0.00590625 -0.0013773 0.04355196]
[-0.01194517 -0.02205685 -0.00971348 0.0590842 0.04946498 0.09660266
0.07750829 0.02446801 0.02433973 0.06151292]
[-0.02814757 -0.01565399 -0.00702438 0.06063427 0.1030582 0.12312546
0.08764815 0.02642038 0.05054139 0.04792479]
[-0.03036664 -0.02288169 0.00407309 0.05880797 0.11247557 0.13074106
0.09704594 0.0467656 0.01982775 0.03782815]]
[[-0.01041405 0.01337869 0.01964999 0.02291045 0.01676475 0.00477586
-0.00197053 0.00736388 0.00637962 -0.00318716]
[-0.01147142 0.00484075 0.01140109 0.03387292 0.0398818 0.00470209
-0.00336939 -0.00456874 0.00550431 0.00476915]
[-0.01833718 -0.00121026 0.00503588 0.00633192 -0.01114768 0.00653658
0.00548258 -0.00349703 -0.0019624 0.00550983]
[-0.01415633 0.033454 0.03156574 -0.03636345 -0.0700613 -0.02102666
0.01554847 0.00130552 -0.01478273 -0.00041066]
[-0.00517665 0.0486834 0.06539537 -0.0221926 -0.04225032 -0.04831901
0.00846614 0.00432087 -0.01747351 -0.01234847]
[ 0.00361275 0.02506233 0.03918421 0.00034126 0.01332592 -0.03560889
-0.01606395 0.01030094 -0.00489787 -0.01633028]
[ 0.0007864 0.03191374 0.02787003 -0.01997382 -0.00840169 -0.04555055
-0.02729836 -0.00191015 -0.01098091 -0.03559951]
[-0.00133592 0.04230609 0.04762461 -0.03169624 -0.02502327 -0.0611752
-0.05275191 -0.02202025 -0.02497416 -0.04938621]
[ 0.00403474 0.01497703 0.03447091 -0.03185133 -0.06128407 -0.08295353
-0.05895194 -0.02426705 -0.0428498 -0.04480471]
[ 0.00960931 0.02078531 0.01336674 -0.02900411 -0.07421369 -0.09539901
-0.06200072 -0.03533536 -0.02370013 -0.03885514]]

[somespirit]

lol why we need 10bits encoding and why not,

gpu and monitors can display only 24 bits colors, so we dont need that 30bits colors or so called 10bits encoding

32bits colors is:

“32 bit” also usually means 32 bits total per pixel, and 8 bits per channel (x3 channels), with an additional 8 bit alpha channel that’s used for transparency

24bits + 8bits for transparency , so

so when the encoding is with 10 bits your GPU will convert it to 24 bit colors also monitor can dispay only 24bits colors ..........

that 10bits (30bits colors) is useless ...........

ha ha green astral idiot ........

[poisondeathray]

lol why we need 10bits encoding and why not,

gpu and monitors can display only 24 bits colors, so we dont need that 30bits colors or so called 10bits encoding

32bits colors is:

“32 bit” also usually means 32 bits total per pixel, and 8 bits per channel (x3 channels), with an additional 8 bit alpha channel that’s used for transparency

24bits + 8bits for transparency , so

so when the encoding is with 10 bits your GPU will convert it to 24 bit colors also monitor can dispay only 24bits colors ..........

that 10bits (30bits colors) is useless ...........

ha ha green astral idiot ........

There are 10bit monitors and 10bit capable GPUs . They are becoming more common in consumer space (although some of the cheaper displays are "fake" 10bit 8 bits + FRC) . Now we have cheaper 10bit cameras , UHD BD is 10bit, HDR displays are 10bit ... At one time , only professionals used 10bit .

But from an 8bit source,
1) 10bit lossy encoding can be more efficient compression wise in some circumstances, so you get higher quality at given bitrate .
2) Less banding issues with 10bit
3) More accurate RGB/YUV conversions . If you're starting with a screen cap, maybe a video game, some RGB graphics - Encoding to 8bit YUV you will have +/-3 error in the values with it's displayed back as 8bit RGB without looking that . With 10bit it's possible to be perfect

[Shishi]

Forget it, it's a troll.

We already explained the pro (banding, compression, less error) and the cons (compatibility & ressources). And we only are speaking of 8bit sources.

No need to debate anymore (was still too much). If he can't get why it will benefit 8bit source, why it benefits 8bit display, and why 10bit is becoming common, it's his right to be blind.

[somespirit]

ok, you just made (encode) one video with 10 bit color depth, but you need gpu and monitor that supports this 10 bit depth to watch all 10 bit color right?, for example Nvidia gaming card like RTX 2080 supports 10 bit color (GTX 1080 and bellow series doesnt support 10bit, only 8 bits), then we need 10 bits monitor lol it is a professional monitor which is toooo expensive .....

1) 10bit lossy encoding can be more efficient compression

this is very very stupid statement, we have 30 bits color vs. 24 bits color to compress so 24 bit color will make better compression always ........

and the last thing, if you have 30 bits color camera you will need chroma subsampling 4:4:4 for real representing of the colors otherwise 30 bits color with 4:2:0 it is like 8 bit colors (30 bits color with chroma subsampling 4:2:0 is like astral green idiot again .......)

[poisondeathray]

ok, you just made (encode) one video with 10 bit color depth, but you need gpu and monitor that supports this 10 bit depth to watch all 10 bit color right?, for example Nvidia gaming card like RTX 2080 supports 10 bit color (GTX 1080 and bellow series doesnt support 10bit, only 8 bits), then we need 10 bits monitor lol it is a professional monitor which is toooo expensive .....

For a 10bit source, with true 10bit colors, yes you need a full 10bit chain.

Not as expensive these days, used to be 10x more expensive.

But - even from an 8bit source (like the OP is using in this thread), with an 8bit display, there are compression and accuracy advantages

1) 10bit lossy encoding can be more efficient compression

this is very very stupid statement, we have 30 bits color vs. 24 bits color to compress so 24 bit color will make better compression always ........

For uncompressed, yes. But for lossy compression 10bit often compresses better in many situations and has less banding . Do your research. Read the paper linked above, do some tests. There are many comparisons posted. This is old news and has been proven many times in many tests

But under some low bitrate scenarios, there are times when the compression advantage does not offset the cost of extra bits.

and the last thing, if you have 30 bits color camera you will need chroma subsampling 4:4:4 for real representing of the colors otherwise 30 bits color with 4:2:0 it is like 8 bit colors (30 bits color with chroma subsampling 4:2:0 is like astral green idiot again .......)

Again, bpc is independent of chroma subsampling.

[somespirit]

For uncompressed, yes. But for lossy compression 10bit often compresses better in many situations and has less banding . Do your research. Read the paper linked above, do some tests. There are many comparisons posted. This is old news and has been proven many times in many tests

yes, i did a test, source video 6 min duration (8 bit depth), using 2 pass encoding with bitrate 2160kbps (for both encodings), all other settings are equal except bit depth:

1.first encode 8 bit, output file - 86.9mb and i got this quality of video:
-[Information] [1/28/2019 4:36:44 PM] x264 [info]: profile High, level 4.1, 4:2:0, 8-bit
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame I:123 Avg QP:16.09 size: 35176
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame P:1919 Avg QP:18.08 size: 16022
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame B:6406 Avg QP:19.38 size: 8754

2.second encode 10 bit, output file 87.3mb :
-[Information] [1/28/2019 7:22:49 PM] x264 [info]: profile High 10, level 4.1, 4:2:0, 10-bit
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame I:125 Avg QP:28.18 size: 32473
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame P:1920 Avg QP:29.59 size: 16118
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame B:6403 Avg QP:30.96 size: 8831

so you will decide which encoding have better quality 8 bit or 10 bit , ha ha ha , many tests they have made .............

(so this was the myth of 10 bit better compression or end)

[_Al_]

somespirit,
encoding YUV and previewing it are two different things. You have 8bit YUV limited range converting to 8bit RGB fullrange to view it. That RGB is discarted right away after you see it. RGB has more colors and also some more values available because of full range. So if original is 10bit, converting it to 8bit RGB just looks definitely better, because if you could see those RGB values, they vary more than just from 8bit YUV. You never ever see YUV on screen while viewing it, only RGB representation of it.

[somespirit]

i forgot to say that my source for 2 test encodings is 8 bit depth

useless of 8bit to 10 bit encoding stay on table .........

[poisondeathray]

For uncompressed, yes. But for lossy compression 10bit often compresses better in many situations and has less banding . Do your research. Read the paper linked above, do some tests. There are many comparisons posted. This is old news and has been proven many times in many tests

yes, i did a test, source video 6 min duration (8 bit depth), using 2 pass encoding with bitrate 2160kbps (for both encodings), all other settings are equal except bit depth:

1.first encode 8 bit, output file - 86.9mb and i got this quality of video:
-[Information] [1/28/2019 4:36:44 PM] x264 [info]: profile High, level 4.1, 4:2:0, 8-bit
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame I:123 Avg QP:16.09 size: 35176
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame P:1919 Avg QP:18.08 size: 16022
-[Information] [1/28/2019 4:37:40 PM] x264 [info]: frame B:6406 Avg QP:19.38 size: 8754

2.second encode 10 bit, output file 87.3mb :
-[Information] [1/28/2019 7:22:49 PM] x264 [info]: profile High 10, level 4.1, 4:2:0, 10-bit
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame I:125 Avg QP:28.18 size: 32473
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame P:1920 Avg QP:29.59 size: 16118
-[Information] [1/28/2019 7:24:01 PM] x264 [info]: frame B:6403 Avg QP:30.96 size: 8831

so you will decide which encoding have better quality 8 bit or 10 bit , ha ha ha , many tests they have made .............

(so this was the myth of 10 bit better compression or end)

Do you understand what the numbers mean ?

Are you judging "quality" by average quantizer ?

The quantizer scaling range isn't the same between 8 and 10bit , so they are not directly comparable . Look at the average I,B,P frame sizes

Did you think your one test invalidates the 1000's of others ? You haven't provided any evidence or even a measure of quality

[somespirit]

every little kid will understand my test, if you cant it is your problem......

B frames - Avg QP:19.38 size: 8754 (8bit) compared to Avg QP:30.96 size: 8831 (10bit) means that we have better 8 bit pictute quality for the same size of frame, so 10 bit produce worsе quality for the same bitrate which means that 10 bit have less compression on video