VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 33
Thread

Threaded View

  1. 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 !
    Quote Quote  
  2. 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?
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  3. 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.
    Last edited by Shishi; 8th Jan 2019 at 13:39.
    Quote Quote  
  4. Originally Posted by Shishi View Post
    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 ........
    Quote Quote  
  5. 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.
    Last edited by Shishi; 10th Jan 2019 at 19:02.
    Quote Quote  
  6. Originally Posted by Shishi View Post
    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
    Last edited by somespirit; 11th Jan 2019 at 07:40.
    Quote Quote  
  7. Originally Posted by somespirit View Post

    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
    Quote Quote  
  8. Originally Posted by somespirit View Post
    Originally Posted by Shishi View Post
    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
    Last edited by Shishi; 11th Jan 2019 at 11:32.
    Quote Quote  
  9. 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
    Code:
    # 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.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  10. 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
    Quote Quote  
  11. 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
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  12. Thank you, you two for this awesome answers. I will try to first convert the 8bits sample source to 10bits using the last method.
    Quote Quote  
  13. 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.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  14. 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.)
    Quote Quote  
  15. 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
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  16. 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.
    Last edited by Shishi; 12th Jan 2019 at 11:24.
    Quote Quote  
  17. 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"
    Quote Quote  
  18. 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
    Quote Quote  
  19. 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]]
    Quote Quote  
  20. 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 ........
    Quote Quote  
  21. Originally Posted by somespirit View Post
    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
    Quote Quote  
  22. 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.
    Quote Quote  
  23. 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 .......)
    Last edited by somespirit; 28th Jan 2019 at 07:17.
    Quote Quote  
  24. Originally Posted by somespirit View Post
    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.
    Quote Quote  
  25. Originally Posted by poisondeathray View Post
    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)
    Last edited by somespirit; 28th Jan 2019 at 13:15.
    Quote Quote  
  26. Originally Posted by somespirit View Post
    Originally Posted by poisondeathray View Post
    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
    Quote Quote  
  27. 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.
    Quote Quote  
  28. 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 .........
    Last edited by somespirit; 28th Jan 2019 at 13:18.
    Quote Quote  
  29. 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
    Last edited by somespirit; 29th Jan 2019 at 11:05.
    Quote Quote  
  30. Originally Posted by somespirit View Post
    every little kid will understand my test, if you cant it is your problem......
    Did you want to ask a kid to clarify it for you? or did you someone to explain it to you more clearly ?



    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
    It does not indicate that . The quantizer scale is different between 8bit and 10bit ( a quantizer of say, 10, does not indicate the same thing between 8bit and 10bit) , and average QP is not a direct measure of "quality" . There is a positive relationship between lower quantizer and quality, but you cannot conclude anything from those numbers alone
    Quote Quote  



Similar Threads