I there any benefit to encoding to 10-bits?

[sophisticles]

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.

[_Al_]

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:

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:

[poisondeathray]

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

[sophisticles]

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.

[sophisticles]

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.

[poisondeathray]

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

[poisondeathray]

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)

[poisondeathray]

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

[sneaker]

"Lighthouse" using GTX 1660 Ti (Turing) HEVC vs x264. 8 bit and 10 bit for each. ~3000 kbps.

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

[sophisticles]

@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.

[hello_hello]

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).

[GrampaD]

[QUOTE=poisondeathray;2562106][QUOTE=sophisticles;2562105]

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.

[poisondeathray]

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

[Hoser Rob]

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.

[GrampaD]

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.

[poisondeathray]

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

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

[GrampaD]

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

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

<;(

[poisondeathray]

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

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

[sophisticles]

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.

[GrampaD]

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

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

[GrampaD]

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 <;(

[hello_hello]

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.

[poisondeathray]

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)

[hello_hello]

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.

[hello_hello]

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.

[GrampaD]

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!

[Selur]

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)"

[lordsmurf]

So .... the main benefit of 10-bit is to better see forehead pimples?

RE: post#2 above.

[Selur]

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

[_Al_]

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.