VideoHelp Forum

Try DVDFab and copy Ultra HD Blu-rays and DVDs! Or rip iTunes movies and music! Download free trial !
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 35
Thread
  1. This question has been asked, and in theory, answered numerous times, with the topic usually popping up as it related to x264 vs x264 10-bit. The generally accepted answer is that even with an 8-bit source there are benefits to encoding to 10-bit because, the argument goes, of smoother color gradients due to higher precision math. This seems like a reasonably conclusion, and in fact I admit I am guilty of offering this advice in the past.

    However, a recent discussion with a sparing partner on this forum led me to start rethinking this position, especially as i watched him tap dance around the offer he made and I accepted only for him to back out of with silly objections.

    One of the objections revolved around the source I proposed for his test and his claims that since some of the encoders to be tested support 10-bit encoding and some don't, that it would unfairly penalize the 8-bit encoders by using a 422 10-bit source.

    Despite mocking him, I spent some time thinking about this and no matter with way I look at it, I can't escape one very simple reality, it probably doesn't matter whether or not you encode to 8-bit or 10-bit because the final encode will be viewed in nearly all cases on an 8-bit monitor, which means that the 10-bit encoding needs to somehow be mapped to an 8-bit display.

    In order to display a true 10-bit image, you need a video card, drivers and monitor that support true 10-bit output. But most monitors only support 8-bit, some support a pseudo 10-bit output, and as far as I know there are no consumer tv's that currently support 10-bit output.

    Further compounding my skepticism is that some, if not all, non-pro encoding front ends, such as handbrake, despite being able to output a 10-bit or 10/12-bit video (in the case of x265), the internal processing is still done in 420 8-bit.

    So I decided to perform a test, using the source named BMPCC6K_Wedding.mov, from here:

    https://www.blackmagicdesign.com/products/blackmagicpocketcinemacamera/workflow

    The source is ProRes, 1034 Mb/s, 6144x3456, 24fps, 422 and I used the latest build of Handbrake on Manjaro, with all the updates.

    When you load this in Handbrake, it automatically crops it 448 top and bottom to 6144x2560 and I outputted it as 1920x1080 storage resolution, 2592x1080 2.40:1 display resolution.

    I considered outputting it at 6k, but the reality is that most people don't even have a 4k monitor, much less a 6k monitor, at 1080p, it should give us a realistic idea of the benefit to an end user in encoding to bit depths higher than 8-bit.

    As a side note, for $2500, this camera is one hell of a value, 13 stops, capable of recording to RAW or ProRes, full 6k resolution, if I were running a streaming site, with unique content, I would author and stream in 5k as a way of differentiating my site from competitors. Fun fact, there is an "adult" site that sells it's movies at resolutions up to 5k, though I strongly suspect it's 4k that's been upscaled.

    What I did was encode the first one to x264 with CRF 22, then did a 2 pass encode for x264 10-bit and x265 8/10/12-bit. As you will note, in some case the encoder missed the target bit rate slightly.

    Just for fun, I did a few higher quality encodes as well, at 6k, with x264 CRF 16 and i tried to match the bit rate with NVENC HEVC but it fell short of the target bit rate by a bit, I will be uploading those shortly as there seems to be a problem with the forum accepting those uploads at the moment.

    If anyone has access to any commercial encoders, Main Concept, Sony AVC, Apple, Ateme, or a Turing card and wants to join in the fun, feel free to run your own test.
    Image Attached Files
    Quote Quote  
  2. Why would you select a source that needs to be fixed, is cropped, resampled, resolution and chroma and God know what more is done behind scenes, so there is no original available for direct comparison?

    Videos (as posted) 1,4 and 6 need to have cut first frame to be in sync with the rest. (using ffms2 as source plugin)

    nvenc smooths out stuff, h265 keeps more detail (10 and 8 bit), x264 is behind, trying also keep details but cannot keep up like x265 does.
    To not include an original is kind of faux-pas though.
    What is always missing is time it took to encode.
    vapoursynth script:
    Code:
    import vapoursynth as vs
    from vapoursynth import core
    
    input1=r'F:/BMPCC6K_Wedding nvenc hevc.mkv'
    clip1 = core.ffms2.Source(input1)[1:] #first frame cut
    
    input2=r'F:/BMPCC6K_Wedding x265 10-bit.mkv'
    clip2 = core.ffms2.Source(input2)
    
    input3=r'F:/BMPCC6K_Wedding x265 12-bit.mkv'
    clip3 = core.ffms2.Source(input3)
    
    input4=r'F:/BMPCC6K_Wedding x264 10-bit.mkv'
    clip4 = core.ffms2.Source(input4)[1:] #first frame cut
    
    input5=r'F:/BMPCC6K_Wedding x265.mkv'
    clip5 = core.ffms2.Source(input5)
    
    input6=r'F:/BMPCC6K_Wedding x264.mkv'
    clip6 = core.ffms2.Source(input6)[1:] #first frame cut
    
    from vnp15 import Preview
    Preview([clip1,clip2,clip3,clip4,clip5,clip6])
    frames 539 (counting from zero) , brides forehead, png's are in RGB of course cropped: core.std.CropAbs(clip, width=240, height=134, left=502, top=236), then zoomed in the picture using nearest resize, so points get just bigger:
    Image Attached Thumbnails Click image for larger version

Name:	06_x264_clip_06_[240, 134, 502, 236]_frame_0000539.png
Views:	159
Size:	269.3 KB
ID:	50416  

    Click image for larger version

Name:	05_x265_clip_05_[240, 134, 502, 236]_frame_0000539.png
Views:	123
Size:	279.9 KB
ID:	50417  

    Click image for larger version

Name:	04_x264 10-bit_clip_04_[240, 134, 502, 236]_frame_0000539.png
Views:	126
Size:	277.7 KB
ID:	50418  

    Click image for larger version

Name:	03_x265 12-bit_clip_03_[240, 134, 502, 236]_frame_0000539.png
Views:	109
Size:	284.9 KB
ID:	50419  

    Click image for larger version

Name:	02_x265 10-bit_clip_02_[240, 134, 502, 236]_frame_0000539.png
Views:	117
Size:	282.9 KB
ID:	50420  

    Click image for larger version

Name:	01_nvenc hevc_clip_01_[240, 134, 502, 236]_frame_0000539.png
Views:	128
Size:	259.4 KB
ID:	50421  

    Last edited by _Al_; 6th Oct 2019 at 19:52.
    Quote Quote  
  3. Atta boy! I thought you ran away!

    Does handbrake support the full 10bit pipeline yet?

    1) The math is 100% sound for the accuracy component, and you can verify this in real test. You can reproduce accurate 8bit RGB colors with 10bit YUV . But not with 8bit YUV . Just check some color bars . Is color accuracy important ? Or does it "matter" if on the 8bit monitor RGB values are +/- 3 vs. +/- 0 ? Probably not for the typical user. It's probably more important for web designers who embed videos. Things such as logos, trademarks are a bit "off" with 8bit. But the problem is, browser support is for proper 10bit video is currently WIP. It plays, but it's truncated to 8bit right now. If you want , I can upload a demo in this thread or another if you don't want it polluted. You need to use an accurate player like MPCHC or MPV . VLC truncates to 8bit too

    2) For the banding and compression discussion , it's easier to see with gradients . Would you like a demonstation ? Same deal let me know this thread or another? A good clip is the Lighthouse of the Pacific clip, with the blue skies. That's the 8bit 4:2:0 source used to encode the retail BD from. Full permissions from the author for testing. Basically, does 10bit encoding help, even in the 8bit source scenario ?

    3) I'll try to upload some Meridan encodes in another thread over the next few days. Sneaker made a sample for testing in another forum , so no 300GB DL's. He converted to 1920x1080 8bit 4:2:0 but since that's a standardized source, none of those other variables come into play. One issue is that it's a bit atypical since it's "59.94p" , and the motion and shutter blur looks awkward compared to a traditional theatrical production, so it's probably not representative, but it's just another data point for fun . I'll do the legacy encoders AVC first when I have time, since that was requested first in the other thread, and add more gradually. Others can contribute too with others like SVT HEVC/AV1/VP9 , that SIF, NVEnc (hopefully Turing), or I'll try gradually add to them with what I have available
    Quote Quote  
  4. Originally Posted by _Al_ View Post
    Why would you select a source that needs to be fixed, is cropped, resampled, resolution and chroma and God know what more is done behind scenes, so there is no original available for direct comparison?

    To not include an original is kind of faux-pas though.
    I linked to the original, everyone is free to download any and all the ProRes or RAW samples.

    As for the rest, professional video is never used as is straight from the camera, prior to the editing it's color graded, debayered, denoised, sharpened, etc, as pros usually shoot "flat" in order to avoid "baking in" information in the source so as to allow maximum creative flexibility during the producing.

    If you were shooting your own project you most definitely would crop because there are likely to be elements, such as a boom mike, extras, camera men, props, etc that a viewer is not meant to see. This is why I laugh when people complain about UHD blu-rays not being authored from a 4k master, it doesn't matter because even if the whole movie is shot in 4k and mastered in 4k, there always some cropping, reframing, stabilizing, before being resized back up to 4k for the master.

    A good look at what goes on is here:

    https://jonnyelwyn.co.uk/film-and-video-editing/the-making-of-gone-girl/

    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    Quote Quote  
  5. Originally Posted by poisondeathray View Post
    Does handbrake support the full 10bit pipeline yet?
    No and I doubt it ever will. In fact, I strongly suspect that ffmpeg (I know HB is not based on it) does not support a full 10-bit pipeline.

    Unfortunately I switched to using Linux as my primary OS years ago, and the video tools available are not as robust as Windows or OSX.

    I can't seem to find that Lighthouse of the Pacific clip, the clips that are similar to what you describe all require they be purchased.

    Feel free to post any test encode in this thread.
    Quote Quote  
  6. Originally Posted by sophisticles View Post
    Originally Posted by poisondeathray View Post
    Does handbrake support the full 10bit pipeline yet?
    No and I doubt it ever will. In fact, I strongly suspect that ffmpeg (I know HB is not based on it) does not support a full 10-bit pipeline.
    I think HB used to use libav, but some versions switched to ffmpeg ?

    ffmpeg does for sure . 100% certain

    If you insert an 8bit filter somewhere, then it might get truncated .

    Unfortunately I switched to using Linux as my primary OS years ago, and the video tools available are not as robust as Windows or OSX.
    But in some ways better . Linux benchmarks are always faster , sometimes much faster. Not just video; other areas too


    I can't seem to find that Lighthouse of the Pacific clip, the clips that are similar to what you describe all require they be purchased.
    Lighthouses of the Pacific, from Stacey Spears (The same one from "Spears and Munsil" fame ), sneaker uploaded a lossless x264 version here to reduce filesize
    https://mega.co.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw

    Not an "exciting" clip , but lots of blue skies prone to blocky banding, and don't forget to check out the fades - encoders love fades .

    Feel free to start on it if you have time, I'll do some encodes with Apple/MC/Vegas AVC in another thread , and contribute here too if time permits
    Quote Quote  
  7. To illustrate the 10bit vs 8bit YUV color accuracy for 8bit RGB :

    1) Start with known R,G,B values. Test charts are easy because they have big bars of colors you can test. Or offical SMPTE HD bars
    eg. https://www.belle-nuit.com/test-chart

    I converted to YUV444 (Rec709) , because I didn't want the effects of subsampling intefering with results

    I chose VP9 here because both 8bit and 10bit 444 configurations are supported by modern HTML5 browsers natively. There is the aformentioned 10bit truncation to 8bit issue, but development team for Mozilla for sure, and probably Chrome, are working on implementing the correct 10bit YUV => 8bit RGB conversion (albeit slowly). The emphasis for browser code is speed on multiple platforms, not quality. But when it's done you can use these same test videos in the browser to check.

    You need a color picker, many to choose from eg. instant eyedropper is a good one , with a portable version
    http://instant-eyedropper.com/

    I like MPV, and this should be good on linux too. MPCHC also works for Win. Some players emphasize the "speed" over proper 10bit YUV => 8bit RGB conversion, such as VLC , so you 'll get the errors

    If you check the colors, they are off by +/-3 in the 8bit YUV version, but accurate in the 10bit YUV version. e.g. "Green" is 16,180,16 in original RGB, and 10bit YUV when properly converted to 8bit RGB for display ; but something 16,179,14 in 8bit YUV version (or possibly more off in the browser) . All the colors will be off a bit, but hardly noticable to average person, especially from a distance. ie. this is mostly academic for the end user scenario. And "color perception" in humans is much less important anyways than luma .

    But for stages earlier in the pipeline, it's almost "mandatory" for professional work . In general you need 2 more bits to express all the colors, it's important for post production, grading, VFX, greenscreen etc.. . So if delivery is 8bit , you need 10bit . For 10bit UHD BD, HDR streams, Netflix, 12bit intermediates are common

    (FYI, The version I uploaded is modified, with "superbright" Y=255 (or Y-1023 in the 10bit version) and "superdark" patches Y=0 , so you can test for clipping in various workflows, but it's unrelated to this discussion)
    Image Attached Files
    Quote Quote  
  8. Originally Posted by sophisticles View Post

    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    But any encoder already decides which part of each frame should be given priority regardless of psy optimizations

    If you had near unlimited bitrates , no constraints, then you can do what the author wants perfectly. Compression is about compromises


    Psy optimizations are in every high end pro encoder . Ateme was pioneer in this long before x264 . Mainconcept has them too .

    Netflix values psy and perceptual optimizations, they realized this when testing and building their current batch of models for human perception. This is why we have VMAF, and their next development round is geared directly towards improving this

    But whether or not you "like" a particular encoders' implementation of various psy optimization strategies is going to vary from person to person.

    You can do some tests, change some values , etc... rinse, repeat . For example, x264 is weak around shadow areas , flat areas. Prone to banding along gradients. It's original AQ mode 1 implementation shifts bits to those areas from edges. The side effect is lower quality edges around objects, frame edges when AQ is high. AQ can be considered a type of psy opt. Trade offs.

    Some encoders have the same or similar "name" for a particular optimization, but the effect is drastically different. In short, each encoder reacts very differently to the various psy options
    Quote Quote  
  9. "Lighthouse" using GTX 1660 Ti (Turing) HEVC vs x264. 8 bit and 10 bit for each. ~3000 kbps.

    Code:
    nvencc64 -c hevc --vbrhq 0 --vbr-quality 25.5 --max-bitrate 100000 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log lighthouse_turing_hevc_10bit.txt --avhw -i "lighthouse_lossless.mp4" -o lighthouse_turing_hevc_10bit.265
    nvencc64 -c hevc --vbrhq 0 --vbr-quality 26 --max-bitrate 100000 -u quality --output-depth 8 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log lighthouse_turing_hevc_8bit.txt --avhw -i "lighthouse_lossless.mp4" -o lighthouse_turing_hevc_8bit.265
    
    avs2pipemod -y4mp lighthouse.avs | x264.exe - --demuxer y4m --bitrate 3000 --preset veryslow --tune film --output-depth 8/10 -o lighthouse_x264_8/10bit.264 --pass 1/2
    Image Attached Thumbnails Click image for larger version

Name:	330_turing_hevc_8bit_.png
Views:	292
Size:	1.04 MB
ID:	50425  

    Click image for larger version

Name:	330_turing_hevc_10bit_.png
Views:	322
Size:	1.22 MB
ID:	50426  

    Click image for larger version

Name:	330_x264_8bit_.png
Views:	229
Size:	1.11 MB
ID:	50427  

    Click image for larger version

Name:	330_x264_10bit_.png
Views:	253
Size:	1.22 MB
ID:	50428  

    Image Attached Files
    Quote Quote  
  10. @sneaker: How about downloading the 6k source I linked to, and doing an NVENC AVC and HEVC encoding with that Turing of yours, maybe encode some of the other 4k and 6k samples as well.

    Thanks.
    Quote Quote  
  11. Originally Posted by sophisticles View Post
    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    I eagerly await your samples showing how psy decreases the quality compared to --no-psy (x264).
    Quote Quote  
  12. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    [QUOTE=poisondeathray;2562106][QUOTE=sophisticles;2562105]
    Originally Posted by poisondeathray View Post
    Does handbrake support the full 10bit pipeline yet?
    ffmpeg does for sure . 100% certain

    ...it does huh?

    Then....show me a list of ffmpeg parameters that will make ffmpeg properly convert a 10-bit MKV to a 10-bit MP4.

    I have googled for weeks to find a parameter set that will do it. I have tested many experimental parameter sets. All output to 8-bit. I finally found the following:

    -pix_fmt yuv420p10le \
    -c:v libx265 \
    -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:hdr-opt=1:repeat-headers=1:colorprim=bt2020:transfer=smpte-st-2086:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)W P(15635,16450)L(40000000,50)"


    I tested it a few minutes ago. Output to 8-bit. My version of ffmpeg is

    ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
    built with Apple clang version 11.0.3 (clang-1103.0.32.62)
    configuration: --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --enable-libbluray --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --enable-opencl --disable-outdev=xv --enable-audiotoolbox --enable-videotoolbox --enable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/clang --enable-libdav1d --arch=x86_64 --enable-x86asm --enable-libx265 --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
    libavutil 56. 51.100 / 56. 51.100
    libavcodec 58. 91.100 / 58. 91.100
    libavformat 58. 45.100 / 58. 45.100
    libavdevice 58. 10.100 / 58. 10.100
    libavfilter 7. 85.100 / 7. 85.100
    libavresample 4. 0. 0 / 4. 0. 0
    libswscale 5. 7.100 / 5. 7.100
    libswresample 3. 7.100 / 3. 7.100
    libpostproc 55. 7.100 / 55. 7.100

    Thanx in advance.
    Quote Quote  
  13. Originally Posted by GrampaD View Post

    Then....show me a list of ffmpeg parameters that will make ffmpeg properly convert a 10-bit MKV to a 10-bit MP4.
    What kind of 10bit ? 10bit420 ?

    yuv420p10le input will automatically select yuv420p10le output. Works. I just tested it. There is nothing else you need to set

    ffmpeg -i input.mkv -c:v libx265 -crf 18 -an output.mp4

    Maybe your ffmpeg binary does not have 10bit enabled. Check to see supported pixel formats

    ffmpeg -h encoder=libx265
    Quote Quote  
  14. Member
    Join Date
    Mar 2011
    Location
    Nova Scotia, Canada
    Search Comp PM
    I'm absolutely amazed that this debate still goes on. Once you've seen 10 bit color space it's hard to go back to 8 bit. It's so obvious it's ridiculous. Especially noticeable with good anime, if you've never seen a Miyazaki anime in 10 bit you just don;t knopw how good it really is.
    Quote Quote  
  15. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    Originally Posted by Hoser Rob View Post
    I'm absolutely amazed that this debate still goes on. Once you've seen 10 bit color space it's hard to go back to 8 bit. It's so obvious it's ridiculous. Especially noticeable with good anime, if you've never seen a Miyazaki anime in 10 bit you just don;t knopw how good it really is.
    Sigh. Tell me about it Rob. I can hardly wait to see my UHD4K 10-bit movies on my 85" UHD4K10-capable monitor.

    I will test poisondeathray's commands tonight, and report back here. If it still doesn't work, it may be that my version of ffmpeg does not have an up-to-date version of the x265 encoder. That's why I posted my version's details.

    As for Handbrake, I've read that the current versions use the ffmpeg API. Just FYI.

    All my fingers and toes are crossed - we'll see what happens tonight.
    Quote Quote  
  16. Originally Posted by GrampaD View Post
    I will test poisondeathray's commands tonight, and report back here. If it still doesn't work, it may be that my version of ffmpeg does not have an up-to-date version of the x265 encoder. That's why I posted my version's details.
    Check your input file characteristics first

    Then check your ffmpeg build for supported pixel formats

    ffmpeg -h encoder=libx265

    Code:
    Encoder libx265 [libx265 H.265 / HEVC]:
        General capabilities: delay threads 
        Threading capabilities: auto
        Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le gray gray10le
    libx265 AVOptions:
      -crf               <float>      E..V...... set the x265 crf (from -1 to FLT_MAX) (default -1)
      -qp                <int>        E..V...... set the x265 qp (from -1 to INT_MAX) (default -1)
      -forced-idr        <boolean>    E..V...... if forcing keyframes, force them as IDR frames (default false)
      -preset            <string>     E..V...... set the x265 preset
      -tune              <string>     E..V...... set the x265 tune parameter
      -profile           <string>     E..V...... set the x265 profile
      -x265-params       <dictionary> E..V...... set the x265 configuration using a :-separated list of key=value parameters

    As for Handbrake, I've read that the current versions use the ffmpeg API. Just FYI.
    Libav

    And you can demonstrate that the handbrake pipeline is 8bit, even if it can encode 10bit

    https://forum.videohelp.com/threads/397681-Xmedia-recode-true-10bit-encoding-and-hdr#post2590737
    https://forum.videohelp.com/threads/397681-Xmedia-recode-true-10bit-encoding-and-hdr#post2590767
    Quote Quote  
  17. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Originally Posted by GrampaD View Post
    As for Handbrake, I've read that the current versions use the ffmpeg API. Just FYI.

    Libav

    And you can demonstrate that the handbrake pipeline is 8bit, even if it can encode 10bit

    https://forum.videohelp.com/threads/397681-Xmedia-recode-true-10bit-encoding-and-hdr#post2590737
    https://forum.videohelp.com/threads/397681-Xmedia-recode-true-10bit-encoding-and-hdr#post2590767
    ...Yes, alas, I've seen that. That's why I'm trying to do it in ffmpeg directly. Not that I don't know ffmpeg, handbrake is just easier for the old DVD/VHS class movies.

    Anyhow, here are the results:

    ================================================== ===================================

    Command: ffmpeg -h encoder=libx265

    Yield:

    ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
    built with Apple clang version 11.0.3 (clang-1103.0.32.62)
    configuration: --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --enable-libbluray --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --enable-opencl --disable-outdev=xv --enable-audiotoolbox --enable-videotoolbox --enable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/clang --enable-libdav1d --arch=x86_64 --enable-x86asm --enable-libx265 --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
    libavutil 56. 51.100 / 56. 51.100
    libavcodec 58. 91.100 / 58. 91.100
    libavformat 58. 45.100 / 58. 45.100
    libavdevice 58. 10.100 / 58. 10.100
    libavfilter 7. 85.100 / 7. 85.100
    libavresample 4. 0. 0 / 4. 0. 0
    libswscale 5. 7.100 / 5. 7.100
    libswresample 3. 7.100 / 3. 7.100
    libpostproc 55. 7.100 / 55. 7.100

    ================================================== ====================================

    title: Beauty and the Beast [UHD4K10] (2017)
    filename: batb.mkv

    Format: HEVC
    Format/Info: High Efficiency Video Coding
    Format profile: Main 10@L5.1@High
    HDR format: SMPTE ST 2086, HDR10 compatible
    Codec ID: V_MPEGH/ISO/HEVC
    Color space: YUV
    Chroma subsampling: 4:2:0
    Bit depth: 10 bits
    Bits/(Pixel*Frame): 0.078
    Writing library: x265 3.2+7-gb291a1c95+26:[Windows][#Erg`Djh#][@Yuuki] made by @Dongfangbubai

    Encoding settings: rc=crf / crf=18.0000 / qcomp=0.70 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / no-lossless / no-cu-lossless / aq-mode=1 / aq-strength=0.80 / cbqpoffs=-3 / crqpoffs=-3 / ipratio=1.40 / pbratio=1.30 / psy-rd=2.00 / psy-rdoq=3.00 / deblock=-1:-1 / ref=5 / limit-refs=0 / no-limit-modes / bframes=8 / b-adapt=2 / bframe-bias=0 / b-pyramid / b-intra / weightp / weightb / min-keyint=23 / max-keyint=240 / rc-lookahead=60 / gop-lookahead=0 / scenecut=40 / radl=0 / max-cu-size=32 / min-cu-size=8 / me=3 / subme=4 / merange=25 / rdoq-level=2 / rd=4 / rdpenalty=1 / dynamic-rd=0.00 / no-rd-refine / ----- / no-cutree / no-sao / no-rect / no-amp / no-open-gop / wpp / pmode / pme / no-psnr / no-ssim / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-tu-size=32 / tu-inter-depth=2 / tu-intra-depth=2 / limit-tu=0 / qg-size=32 / qpmax=69 / qpmin=0 / ----- / cpuid=1111039 / frame-threads=6 / numa-pools=54,- / log-level=2 / input-csp=1 / input-res=3840x1608 / interlace=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / no-allow-non-conformance / no-repeat-headers / no-aud / hrd / info / hash=0 / no-temporal-layers / lookahead-slices=0 / no-splice / no-intra-refresh / no-ssim-rd / signhide / no-tskip / max-merge=3 / temporal-mvp / no-hme / no-analyze-src-pics / no-sao-non-deblock / selective-sao=0 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-splitrd-skip / zone-count=0 / no-strict-cbr / no-rc-grain / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=0 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP (15635,16450)L(40000000,50) / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00

    Color range: Limited
    Color primaries: BT.2020
    Transfer characteristics: PQ
    Matrix coefficients: BT.2020 non-constant
    Mastering display color primaries: Display P3

    -------------------------------------------------------------

    Command: ffmpeg -i batb.mkv -c:v libx265 -crf 18 -ss: 00:05:00 -t: 00:00:30 -an batb.mp4

    Output:

    ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
    built with Apple clang version 11.0.3 (clang-1103.0.32.62)
    configuration: --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --enable-libbluray --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --enable-opencl --disable-outdev=xv --enable-audiotoolbox --enable-videotoolbox --enable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/clang --enable-libdav1d --arch=x86_64 --enable-x86asm --enable-libx265 --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
    libavutil 56. 51.100 / 56. 51.100
    libavcodec 58. 91.100 / 58. 91.100
    libavformat 58. 45.100 / 58. 45.100
    libavdevice 58. 10.100 / 58. 10.100
    libavfilter 7. 85.100 / 7. 85.100
    libavresample 4. 0. 0 / 4. 0. 0
    libswscale 5. 7.100 / 5. 7.100
    libswresample 3. 7.100 / 3. 7.100
    libpostproc 55. 7.100 / 55. 7.100
    [matroska,webm @ 0x7fe42e80f200] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
    Consider increasing the value for the 'analyzeduration' and 'probesize' options
    [matroska,webm @ 0x7fe42e80f200] Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
    Consider increasing the value for the 'analyzeduration' and 'probesize' options
    Input #0, matroska,webm, from 'batb.mkv':
    Metadata:
    title : Beauty.and.the.Beast.2017
    encoder : libebml v1.3.10 + libmatroska v1.5.2
    creation_time : 2020-06-29T03:09:23.000000Z
    Duration: 02:09:16.80, start: 0.000000, bitrate: 16730 kb/s
    Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1608, SAR 1:1 DAR 160:67, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
    Stream mapping:
    Stream #0:0 -> #0:0 (hevc (native) -> hevc (libx265))
    Press [q] to stop, [?] for help
    x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
    x265 [info]: build info [Mac OS X][clang 11.0.0][64 bit] 8bit
    x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
    x265 [info]: Main profile, Level-5 (Main tier)
    x265 [info]: Thread pool created using 8 threads
    x265 [info]: Slices : 1
    x265 [info]: frame threads / pool features : 3 / wpp(26 rows)
    x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
    x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
    x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
    x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
    x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
    x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
    x265 [info]: References / ref-limit cu / depth : 3 / off / on
    x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
    x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
    x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
    x265 [info]: tools: strong-intra-smoothing lslices=8 deblock sao
    Output #0, mp4, to 'batb.mp4':
    Metadata:
    title : Beauty.and.the.Beast.2017
    encoder : Lavf58.45.100
    Stream #0:0: Video: hevc (libx265) (hev1 / 0x31766568), yuv420p, 3840x1608 [SAR 1:1 DAR 160:67], q=-1--1, 23.98 fps, 24k tbn, 23.98 tbc (default)
    Metadata:
    _STATISTICS_WRITING_APP-eng: mkvmerge v46.0.0 ('No Deeper Escape') 64-bit
    encoder : Lavc58.91.100 libx265

    ------------------------------------------------------------------------------------------

    Resulting color information in output file:

    Container
    Format: MPEG-4
    Format profile: Base Media
    Codec ID: isom (isom/iso2/mp41)
    Writing application: Lavf58.45.100
    Format: HEVC
    Format/Info: High Efficiency Video Coding
    Format profile: Main@L5@Main
    Codec ID: hev1
    Codec ID/Info: High Efficiency Video Coding
    Color space: YUV
    Chroma subsampling: 4:2:0

    Bit depth: 8 bits

    Scan type: Progressive
    Bits/(Pixel*Frame): 0.058
    Writing library: x265 3.2.1+1-b5c86a64bbbe:[Mac OS X][clang 11.0.0][64 bit] 8bit

    Encoding settings: cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1608 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
    Color range: Limited
    Codec configuration box: hvcC

    ================================================== ================================================== ======

    <;(
    Quote Quote  
  18. Your binary does not list supported pixel formats such as in post #16. Possibly it does not support 10bit encoding

    Code:
    x265 [info]: build info [Mac OS X][clang 11.0.0][64 bit] 8bit
    Did you say you already tried -pix_fmt yuv420p10le ?

    Also try -vf format=yuv420p10le

    You're on a mac, try to find ones that support 10bit or you can try hybrid
    https://www.videohelp.com/software/Hybrid
    Quote Quote  
  19. Originally Posted by Hoser Rob View Post
    I'm absolutely amazed that this debate still goes on. Once you've seen 10 bit color space it's hard to go back to 8 bit. It's so obvious it's ridiculous. Especially noticeable with good anime, if you've never seen a Miyazaki anime in 10 bit you just don;t knopw how good it really is.
    Unless you have a true 10-bit source, with a 10-bit monitor and 10-bit cables, then I guarantee you have never seen 10-bit color space, regardless of what you think you have seen.
    Quote Quote  
  20. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Your binary does not list supported pixel formats such as in post #16. Possibly it does not support 10bit encoding

    Code:
    x265 [info]: build info [Mac OS X][clang 11.0.0][64 bit] 8bit
    Did you say you already tried -pix_fmt yuv420p10le ?

    Also try -vf format=yuv420p10le

    You're on a mac, try to find ones that support 10bit or you can try hybrid
    https://www.videohelp.com/software/Hybrid
    ...sigh. I was afraid of that. Damn. I hope somebody on here knows of a URL where I can find a current version of ffmpeg that has the 10-bit x265 CODEC.

    Apparently, the binaries I have - the one in MacPorts or the OSX binary that I found online - do not contain an x265 binary that supports 10-bit.

    Thanx everyone
    Quote Quote  
  21. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    Originally Posted by poisondeathray View Post
    You're on a mac, try to find ones that support 10bit or you can try hybrid
    https://www.videohelp.com/software/Hybrid
    ...Hybrid says: "...Hybrid is intended for advanced users..."

    ...Excellent! I like it already...WAIT!

    "...Hybrid - Mac complete package rev 2018.08.05.1
    (Got no Mac anymore, so no more [new] mac releases...)"

    nooooooo <;(
    Quote Quote  
  22. Originally Posted by Hoser Rob View Post
    I'm absolutely amazed that this debate still goes on. Once you've seen 10 bit color space it's hard to go back to 8 bit. It's so obvious it's ridiculous. Especially noticeable with good anime, if you've never seen a Miyazaki anime in 10 bit you just don;t knopw how good it really is.
    10 bit isn't a color space, it's a bit depth. 8 bit is capable of displaying the same range of colors as 10 bit.

    Generalising....
    8 bit means you can sample something, and give each sample 256 discreet values. For 10 bit, it's 4x that.
    That means, for example, if you take a primary colour such as red, 8 bit can display 256 shades of red, and obviously 10 bit can display 1024 shades, but both can still display almost-black red, and both can display almost-white red. 10 bit can display more shades in between. For 8 bit video, dithering can be used (randomising the sample values) to give it the appearance of 10 bit. Most LCD displays are, or at least used to be, 6 bit with dithering to give the appearance of being 8 bit. Are your video card and/or monitor 10 bit?

    I remember reading somewhere the rec.2020 color space, with it's greater range of colors, needs to be 10 bit in order to perform as well as 8 bit rec.709.
    Last edited by hello_hello; 10th Sep 2020 at 14:26. Reason: Fixed a stupid
    Quote Quote  
  23. Originally Posted by hello_hello View Post
    8 bit means you can sample something, and give each sample 256 discreet values. For 10 bit, it's twice that.

    Yes, bit depth is just the precision, more "shades" of colors. But it's more than twice

    It's 2^10 for 10 bit = 1024 values per channel (0 to 1023 code values) . 8bit is 2^8 = 256 values per channel (0 to 255 code values) . (It's normally reduced than that for limited range video, and YUV)

    In RGB, 8bit values can display ~ 16.7M different colors (256 * 256 * 256) . 10bit can display > 1 Trillion different colors (1024 * 1024 * 1024)
    Quote Quote  
  24. Originally Posted by sophisticles View Post
    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    It's only silly if the result is lower quality at a given bitrate, and you're yet to show an example of that.
    Of all the decisions an encoder has to make, letting it decide how to best distribute the bits within a frame is somehow crossing the line? That seems silly. Why not move the line and make every frame an I-frame? You're okay with the encoder deciding which frames to encode as P or B-frames etc, but don't let it try to more cleverly distribute the bits within each frame for a higher perceived quality.... because the author of the content spent lots of time and money creating the end product, so obviously he wouldn't want that.
    Last edited by hello_hello; 10th Sep 2020 at 14:31.
    Quote Quote  
  25. Originally Posted by poisondeathray View Post
    Originally Posted by hello_hello View Post
    8 bit means you can sample something, and give each sample 256 discreet values. For 10 bit, it's twice that.

    Yes, bit depth is just the precision, more "shades" of colors. But it's more than twice

    It's 2^10 for 10 bit = 1024 values per channel (0 to 1023 code values) . 8bit is 2^8 = 256 values per channel (0 to 255 code values) . (It's normally reduced than that for limited range video, and YUV)

    In RGB, 8bit values can display ~ 16.7M different colors (256 * 256 * 256) . 10bit can display > 1 Trillion different colors (1024 * 1024 * 1024)
    Doh!! I was simplifying by using one sub-pixel color as an example, although I apparently made an idiot of myself in the process by claiming 10 bit can give 512 discrete values to a sample.... because it's obviously wrong and 1024 is the correct answer. I don't know what my brain was doing while I typed that, but it let me down again. I'll correct my previous post.
    Quote Quote  
  26. Video Intermediate GrampaD's Avatar
    Join Date
    Oct 2009
    Location
    United States
    Search Comp PM
    Ssiigghh...

    it really really looks like I'm going to need to bit the bullet, and learn how to build my own version of ffmpeg and the x265 10-bit CODEC from source.

    Heck, I'm an IT Pro, so I SHOULD have the skill to do that. It's just that building from source is a real pain because it never goes right; there's hundreds of errors and thousands of warnings and yada yada that you have to slog through. Fixing all the build errors and warnings will take tons of posts in forums and lots of research to do.

    But hey, once I'm all done, I'll have a build system that can create a static build of the most current version of ffmpeg and the x265 lib for windows, osx, and *nix!
    Quote Quote  
  27. btw. nice statically linked ffmpeg builds for mac are offered by https://evermeet.cx/ffmpeg/ (for years) and "x265 library is a multi-bit version (8-bit, 10-bit, 12-bit)"
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  28. Video Restorer lordsmurf's Avatar
    Join Date
    Jun 2003
    Location
    dFAQ.us/lordsmurf
    Search Comp PM
    So .... the main benefit of 10-bit is to better see forehead pimples?

    RE: post#2 above.
    Quote Quote  
  29. Generally the main benefits for higher calculation precision over 8bit precision are:
    a. potentially higher compression ration (size vs. preserved details) (more noticable in H.264 than H.265)
    b. no artifacts that are caused by rounding -> so no banding due to the compression (assuming reasonable bit rates)

    main downside is higher compression an decompression hardware requirements.
    For H.264 10bit isn't part of the Main profile branch (no Main10) so most (older) hardware will not support it.
    For H.265 10bit is part of the Main profile branch so most of the hardware should support it.

    Cu Selur

    Ps.: for H.265 even Main12 hardware decoding is getting some attention
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  30. Originally Posted by lordsmurf View Post
    So .... the main benefit of 10-bit is to better see forehead pimples?

    RE: post#2 above.
    No, it is a detail how a uniform gradient is handled with a detail in one crop together with hair detail. It is familiar to us and how it suppose to look. We all know exactly what we suppose to see. So we have encoded samples to compare. op did not provided an original. Everyone starts to complain lately about something. It is a trend.
    Quote Quote  



Similar Threads