freeware x265 encodes with 10-bit color

[akrako1]

Is Handbrake capable of x265 encodes with 10-bit color? Any other freeware solutions available?

I've experimented a bit with Handbrake... found an older version with a 'main10' profile, but that still resulted in 8bit encodes. Is there a way to do this with the current (1.X) version without installing any extra compiled binaries or 'nightly builds'?

Finally found an inexpensive media player with x265/10bit support, this one. From what I've read, 10bit color encoding gives better compression, even with 8bit sources. Figured my personal archival encodes should be x265 with 10bit color going forward... thoughts?

[sophisticles]

This has been talked about before, while there are certain builds of Handbrake that allow for 10 bit and 12 bit x265 encodes, it's absolutely useless:

https://handbrake.fr/news.php

- High bit depth encoding support via external shared libraries (video pipeline is still 8-bit 4:2:0)
- x264 10-bit
- x265 10-bit and 12-bit

From personal testing with 10 bit and 12 bit x265, via Handbrake on Fedora 25, not only does 10 bit encoding via Handbrake not offer any quality improvements but 12 bit actually seems to produce lower quality "fuzzier" looking output.

I recommend Selur's Hybrid if you want to give 10 bit and 12 bit x265 encoding a shot.

[pandy]

ffmpeg support 10 bits for sure (12 bit seem to be also supported).

[akrako1]

Trying some conversiosn with StaxRip, which uses x265.exe. Below is the resulting video MediaInfo. I see a similar 4:2:0 that's mentioned above, for 'ChromaSubsampling'. Does this also indicate an 8-bit video pipeline? How should that appear for true 10-bit?

Video
ID/String : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format_Profile : Main 10@L3.1@Main
CodecID : V_MPEGH/ISO/HEVC
Duration/String : 25 min 47 s
BitRate/String : 551 kb/s
Width/String : 960 pixels
Height/String : 720 pixels
DisplayAspectRatio/String : 4:3
FrameRate_Mode/String : Constant
FrameRate/String : 23.976 (24000/1001) FPS
ColorSpace : YUV
ChromaSubsampling/String : 4:2:0
BitDepth/String : 10 bits
Bits-(Pixel*Frame) : 0.033
StreamSize/String : 102 MiB (46%)
Encoded_Library/String : x265 2.2+2-bbb13fcb4c45:[Windows][MSVC 1910][64 bit] 10bit
Encoded_Library_Settings : cpuid=1105919 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=960x720 / interlace=0 / total-frames=37108 / 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 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / 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 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05
Default/String : Yes
Forced/String : No

Using the following settings in StaxRip: x265 encoder, main10 profile, 10-bit depth.

Should i be using the Main422-10 or Main444-10 profiles instead? What are the *-intra profiles for? Or best to just use 'Unrestricted'?

Thanks!!

[sneaker]

I see a similar 4:2:0 that's mentioned above, for 'ChromaSubsampling'. Does this also indicate an 8-bit video pipeline?

No.

How should that appear for true 10-bit?

"BitDepth/String: 10 bits" is "true" 10 bit bitdepth. Is the complete pipeline 10 bit? Impossible to tell. MediaInfo only shows the encoding mode of the final file.

[_Al_]

Heck, lots of uncertainty now, , so if using 8bit 4:2:0 input and using :

avs4x26x.exe -L x265-64bit-10.exe" --crf 22 --vbv-bufsize 20000  --vbv-maxrate 20000 --output  out_10bit_4_2_0.hevc   input_8bit_4_2_0.avs

Is it correct workflow to get 10 bit 4:2:0 HEVC?
avs4x26x.exe just seems to add frame rates, fps and input color:

--frames 10456 --fps 30000/1001 --input-res 1280x720 --input-csp i420

[leghorn]

Simple x264 Launcher has x265 capabilities. And it has 10-bit and 12-bit options. Possibly mulder could add his two cents on this. I'm not sure whether his application uses 8-bit pipelining or has native 10-/12-bit encoding.

[LigH.de]

"Simple x264 Launcher" expects already prepared AviSynth scripts as source. It will not create a script handling any source media for you. The whole filter pipeline is all your responsibility.

[akrako1]

Has anybody tried Handbrake 1.1? Now that 10-bit (and 12-bit) color is included natively, does anyone know if the full pipeline is 10bit now?

If the pipeline is actually 8-bit, would you still gain in storage efficiency when encoding a 8-bit source to x265 10bit? Or would it need to be 10-bit throughout the pipeline to gain the color encoding efficiency?

[LigH.de]

10 or 12 bit precision for DCT / Integer Transform matrix coefficients in the AVC / HEVC encoded bitstream does not mean the same as 10 bit precision for Y / U / V color components of input video pixels.

[sneaker]

Has anybody tried Handbrake 1.1? Now that 10-bit (and 12-bit) color is included natively, does anyone know if the full pipeline is 10bit now?

It doesn't. AFAIK pipeline is still 8 bit.
https://github.com/HandBrake/HandBrake/issues/1339

If the pipeline is actually 8-bit, would you still gain in storage efficiency when encoding a 8-bit source to x265 10bit?

Yes. But banding might be introduced in the filtering step (e.g. if source is 10 bit).

[akrako1]

is there any difference when encoding an 8-bit color source to 10-bit color based on pipeline?

8-bit source -> 8-bit pipeline -> 10-bit result
vs.
8-bit source -> 10-bit pipeline -> 10-bit result

Since the source is 8-bit, would the true 10-bit pipeline produce better results?

From what I remember, StaxRip uses 10-bit pipeline (someone correct me if I'm wrong), but it's a bit more cumbersome and i prefer Handbrake...

[sneaker]

Since the source is 8-bit, would the true 10-bit pipeline produce better results?

If you only do re-encoding? No.
If you do some filtering (resizing, debanding, ...) the 10 bit pipeline might or might not yield better results. For most of the stuff you can do in HandBrake it doesn't matter much.

[LigH.de]

If you do any filtering after decoding the video, filtering with 10 bit precision may indeed be more precise than filtering with only 8 bit precision.

If you don't, then filling up color components of video decoded with 8 bit precision to 10 bits with 0 bits is not more precise. Like e.g. a floating point number 0.1250 is not more precise than 0.125, it's exactly the same number.

But after all, you may or may not notice the difference. That will depend on the video content and on several more factors.