tuning x265 syntax for UHD /rec2020,HDR10/high quality

[TEB]

hi! Im working on encoding some clips i have in pro-res format to HEVC for HDR10 testing.

Source: Prores 4:2:2 10bit UHD - Nature scene 10000frames

Syntax:

Pass 1:

ffmpeg -i "output2.mov" -strict -1 -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -an -r 25 -f yuv4mpegpipe - | "x265.exe" --y4m - --output-depth 10 --input-res 3840x2160 --fps 25 --preset veryslow --b-adapt 2 --ref 4 --open-gop --keyint 48 --profile main10 --level-idc 5.1 --no-high-tier --sar 1:1 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --b-pyramid --bframes 4 --hrd --vbv-bufsize 35000 --bitrate 35000 --vbv-maxrate 40000 --slow-firstpass --pass 1 --stats "test_HDR10.stats" --aud --chromaloc 2 --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --output nul



Pass 2:


ffmpeg -i "output2.mov" -strict -1 -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -an -r 25 -f yuv4mpegpipe - | "x265.exe" --y4m - --output-depth 10 --input-res 3840x2160 --fps 25 --preset slow --b-adapt 2 --ref 4 --open-gop --keyint 48 --profile main10 --level-idc 5.1 --no-high-tier --sar 1:1 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --b-pyramid --bframes 4 --hrd --vbv-bufsize 35000 --bitrate 35000 --vbv-maxrate 40000 --slow-firstpass --pass 2 --stats "test_HDR10.stats" --aud --chromaloc 2 --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --output "test_HDR10.hevc"

Ive selected slow on the 2nd pass since it takes like 3 days to encode on my Haswell if not..
In the recent 2.3 release of x265, there are some new features for HDR.. Not sure how to incorporate the hdr features..

any comments are welcomed ;)

TEB

[Sagittaire]

seem good for HDR profil.

Anyway you use something like "UHD BD" profil (HDR, VBV, GOP, profil ...). If you want make that, use --uhd-bd command line.

[benwaggoner]

How about --hdr-opt?

And --b-pyramid is always on by default. are you looking for the x265 equivalent to --b-pyramid strict? Because there isn't one.

I don't know if that's a requirement for UHD BD or not. Which IIRC had something to do why UHD-BD encoding required closed GOP or something.

[albt]

I use madvr to watch HDR videos, the problem is that in encodes I do I get red or blue colors or boxes in video, tried so many encoding settings, spent days, but no good solution so far, tried slower settings, with grain, film (suggest in forum), than many settings tested from me, different rdoq level, different aq mode, deblock, sao/no-sao etc..

[benwaggoner]

I use madvr to watch HDR videos, the problem is that in encodes I do I get red or blue colors or boxes in video, tried so many encoding settings, spent days, but no good solution so far, tried slower settings, with grain, film (suggest in forum), than many settings tested from me, different rdoq level, different aq mode, deblock, sao/no-sao etc..
Do you have known-good reference content to test in MadVR? The HDR functionality is pretty new and requires it know a lot about your display setup as well.

You might try --cbqpoffs -3 --crqpoffs -3 to see if lowering QP for chroma improves things. And definitely --hdr-opt.

But what you describe could be a MadVR playback issue that isn't related to encoding.

[albt]

Do you have known-good reference content to test in MadVR? The HDR functionality is pretty new and requires it know a lot about your display setup as well.

You might try --cbqpoffs -3 --crqpoffs -3 to see if lowering QP for chroma improves things. And definitely --hdr-opt.

But what you describe could be a MadVR playback issue that isn't related to encoding.

now i'm using slower profile with grain tune, but with some changes, so i did disable rdoq-level & psy-rdoq as it gives me bad results, i set the level to 0 like it is in medium & fast profiles, also set qcomp 0.8, aq-mode 3, opt-cu-delta-qp, no-fast-tskip. another way is to set deblock to -1 or lower, but the first method is working a bit better for me. even if not what i want, i also don't know if i'm using right settings, i'm a noob in x265 encoding...

[benwaggoner]

now i'm using slower profile with grain tune, but with some changes, so i did disable rdoq-level & psy-rdoq as it gives me bad results, i set the level to 0 like it is in medium & fast profiles, also set qcomp 0.8, aq-mode 3, opt-cu-delta-qp, no-fast-tskip. another way is to set deblock to -1 or lower, but the first method is working a bit better for me. even if not what i want, i also don't know if i'm using right settings, i'm a noob in x265 encoding...
I think you should get your hands on some known-good HDR content (I think there have been download links) and make sure your MadVR setup works with that. Your HDR encoding might be fine, and the issue you're getting is in playback.

[albt]

I think you should get your hands on some known-good HDR content (I think there have been download links) and make sure your MadVR setup works with that. Your HDR encoding might be fine, and the issue you're getting is in playback.

After all, maybe it's a normal thing in HDR, or it's a problem of Madvr, but it's different from the source video.

I'm encoding with low bitrate and maybe this is a reason too, I did set the HDR settings right, based in mediainfo, so primaries, matrix, characteristics, matrix, light level, chroma, master display are all right.

I used so many encoding settings used, from slow/slower/veryslow, grain, no tune or the film tune recommended in this forum. Here I explain what I tried:

deblock 0, -1, -2 (less = more details)
rdoq 0, 1, 4, 5, 8, 10 (not big difference)
psy-rd 0.3, 1.5, 1.8, 2 (mostly 2 for less blur)
qcomp 0.6, 0.7, 0.8 (0.8 worked better)
cutree on/off (off worked better)
opt-cu-delta-qp on/off (prefered on)
rskip on/off (only reducing speed for nothing)
aq-mode 1, 2, 3 (2 always fully disabled the hdr -the x265 staff should fix it, 3 worked ok)
ipratio bpratio 1.1-1.0, 1.4-1.3 mostly but also others. (less for more details)
rect, no-amp (amp = no difference, sometimes it also crashed the encoding process)
b-frames 4-6
no-fast-tskip
sao or no-sao
rd-penalty 0, 1, 2 (1 and 2 increased the details of video but changed the lights)

the rest settings were general preset settings.


I did made around 50 test encodes, it was a 500 frame video so I had no problem to spend 10 minutes to encode, but it didn't fix the problem on how I wanted, during the tests I saw from the worst blured encodes to almost no details lost but my problem are the colors. It is a Madvr problem or HDR is just complex? In every encode something changed, even the smallers options changed something. There are red or blue colors appearing likes boxes, pixels etc. Sometimes more, sometimes less, in every encode is different, sometimes there is more red, and it's not in the same part of the frame, it can happen in different. I have an i7 and the source plays well, while the encode has those problems. Don't know if it is a normal thing.


Screens:

1. Colors more white.
http://screenshotcomparison.com/comparison/205881

2. Red things (the second pic is source), this doesn't show everything, as it's not that the red appears only in complex parts like this.
http://screenshotcomparison.com/comparison/205882

3. Blue:
http://screenshotcomparison.com/comparison/205883

[benwaggoner]

For a simple baseline, try trimming the x265.exe part to:

x265.exe" --y4m - --preset slower --hdr-opt --keyint 48 --profile main10 --level-idc 5.0 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --hrd --vbv-bufsize 25000 --bitrate 25000 --vbv-maxrate 25000 --slow-firstpass --pass 2 --stats "test_HDR10.stats" --aud --chromaloc 2 --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --output "test_HDR10.hevc

I took out the stuff inherited from y4m and the preset. I bumped it up to slower, which is where most of the HEVC features kick in, and added --hdr-opt, which fixes the sort of chroma issues it seems you're getting.

Although I'm surprised that you'd be getting any issues like that at 35 Mbps!

The whole --chromaloc 2 thing is a little suspect for me in general. It's required by UHD-BD, but I don't know that sources are ever converted to that, nor if decoders/displays correct for that in their YUV-RGB conversion. So you might removing ut_h_chr_pos etcetera from ffmpeg and remove chromaloc 2 from x265.

[albt]

For a simple baseline, try trimming the x265.exe part to:

x265.exe" --y4m - --preset slower --hdr-opt --keyint 48 --profile main10 --level-idc 5.0 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --hrd --vbv-bufsize 25000 --bitrate 25000 --vbv-maxrate 25000 --slow-firstpass --pass 2 --stats "test_HDR10.stats" --aud --chromaloc 2 --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --output "test_HDR10.hevc

I took out the stuff inherited from y4m and the preset. I bumped it up to slower, which is where most of the HEVC features kick in, and added --hdr-opt, which fixes the sort of chroma issues it seems you're getting.

Although I'm surprised that you'd be getting any issues like that at 35 Mbps!

The whole --chromaloc 2 thing is a little suspect for me in general. It's required by UHD-BD, but I don't know that sources are ever converted to that, nor if decoders/displays correct for that in their YUV-RGB conversion. So you might removing ut_h_chr_pos etcetera from ffmpeg and remove chromaloc 2 from x265.

my hdr settings were:

--chromaloc 2 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

i'll test your suggestions.

[benwaggoner]

my hdr settings were:

--chromaloc 2 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

i'll test your suggestions.
--hdr-opt is your friend. It should always be on for HDR encodes.

[jd17]

--hdr-opt is your friend. It should always be on for HDR encodes.

Could you explain what --hdr-opt actually does?
The docs say this:
Add luma and chroma offsets for HDR/WCG content. Input video should be 10 bit 4:2:0. Applicable for HDR content. Default disabled. Experimental Feature
But what does that entail?
What luma and chroma offsets?
Will the result be visually inferior?

I encoded the "Samsung HDR Wonderland" demo, once with --hdr-opt and once without.

Source MediaInfo:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 45.7 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.230
Stream size : 878 MiB (100%)
Writing library : ATEME Titan File 3.7.3 (4.7.3.1002)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

My encode (HandBrake 1.0.7, x265 2.4):
CRF17, medium, no tune
CL custom: --no-sao --uhd-bd --hdr-opt --hrd --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)"
(I would normally add --max-cll too, but the source does not include that information...)

MediaInfo:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 22.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.112
Stream size : 427 MiB (98%)
Writing library : x265 2.4+13-26963e98fa64:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 /
input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd /
info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 /
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 /
dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 /
no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=9 / transfer=16 / colormatrix=9 / chromaloc=1 /
chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / refine-level=5 / no-limit-sao
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

The encode without --hdr-opt essentially just resulted in a higher bitrate, everything else is identical:

Bit rate : 25.7 Mb/s


Also, would you be so kind as to "sanity check" those parameters?
Would you change anything for UHD HDR encoding? Is anything essential missing?

I think you also suggested before:
--chromaloc 2
--keyint 48
?

I try to read up on the parameters as much as I can, but everything UHD HDR is not really well documented... So I welcome any help and explanations! :)

[jd17]

I just tried to play the encoded files with my TV's internal media player - unfortunately it won't play them.
Kodi plays them fine (S905X LibreELEC, build with enabled 10bit, HDR10 and BT.2020 passtrough).

The TV's internal player has no issues playing the source file.

Does anyone know the reason?

I thought --chromaloc 1 might be the reason so I tried the same encode with --chromaloc 2, but the result is still --chromaloc 1.
I tried the same withought --uhd-bd, but it still comes out --chromaloc 1...

The only difference between source and encode in the main stats I see is...
Chroma subsampling : 4:2:0 (Type 2)
...but other demo videos are "Type 2" as well and the TV's media player accepts those.

[sneaker_ger]

Could be different muxing or different audio. Don't shorten MediaInfo logs to just the video track's section. If you demux a working file and mux it in the same way you muxed your not working encode does it play or not?

[jd17]

I remuxed the original downloaded demo with MKVToolNix 13.0 to just video.
There is no audio or subtitle.

I played this remuxed video with the TV's internal player, it plays fine.

I don't know why it says 98% for stream size on the encodes...
I used HandBrake 1.0.7 for encoding.

Only the encodes won't play....
Do the parameters look ok to you?

[sneaker_ger]

Are you still using HandBrake? Try to demux and mux using MKVToolNix as well. (If only track has 98% size then MediaInfo estimates mkv container overhead to be the remaining 2%.)

Basically, just keep turning knobs until you have something that works. Try x265cli instead of HandBrake. Try lower level, lower resolution. Try without HDR and UHD-BD options etc.

[jd17]

Try lower level, lower resolution.

Source and encode level + resolution are the same...
I am aiming for a transparent encode, lowering the resolution would not really be productive...

Try without HDR and UHD-BD options etc.

I had the encode without --hdr-opt already, that did not play either.
I will try and see if removing --uhd-bd changes things.


The whole reason for the --uhd-bd command is to ensure compatibility, isn't it? That confuses me...

[sneaker_ger]

Source and encode level + resolution are the same...
Yes, the flags. But (vbv) bitrates might be different.

Just test. Once you've found the culprit you can go back and reactivate settings one by one.

I had the encode without --hdr-opt already, that did not play either.
From what I understand --hdr-opt is what I would call a "pure encoder-side feature" (like cutree/mbtree) and shouldn't require/change player compatibility.

The whole reason for the --uhd-bd command is to ensure compatibility, isn't it? That confuses me...
Compliance with UltraHD Blu-ray (and probably not even that). Since you aren't authoring a Blu-ray that doesn't ensure compatibility with your player. (And then there's still muxing as a factor.)

[jd17]

OK, I will keep trying. :)
Thanks for your help!

[jd17]

Weirdly, the only change that was accepted by the TV's media player was removing the --master-display string (I did however add --hdr instead).

Out of interest, will the encode in that case still use the same master display specs, but just not "announce" them in the container?
I see no obvious difference in color, contrast, peak brightness etc...

[sneaker_ger]

And that was using HandBrake or also using x265cli + mkvmerge? Please test brand new x265 release.

[jd17]

Still HandBrake, I am not experienced in x265 CLI. :o
I used x265 2.4+100 (stable) in the last trials.

I did do a remux with MKVToolNix of a few of the HandBrake muxes (which changed the 98% to 100%), but the TV still did not like those files, however the working encode without --master-display came right out of HandBrake btw.

Should those MKVToolNix remuxes not rule out any potential muxing-related issues?

Apart from that - I never had any issues with any of my HandBrake encodes, all 1080p x265 10bit encodes also play fine with the TV's player, I checked to make sure, because I normally just use Kodi...

[sneaker_ger]

Should those MKVToolNix remuxes not rule out any potential muxing-related issues?
No. It's a bit complicated with were the SEIs will (not) end up. I can create some test samples later if you haven't figured it out by then.

[jd17]

I can create some test samples later if you haven't figured it out by then.

That is very kind of you to offer, thank you so much! :)

I wanted to try as much as I can before I let you do that, so I created an encode with Hybrid.

Unfortunately, the MediaInfo of that encode is extremely stripped:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 14.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Bits/(Pixel*Frame) : 0.071
Stream size : 273 MiB (100%)
Default : Yes
Forced : Yes

I don't know what I'm doing wrong, Hybrid shows the following CL instructions:

x265 --input - --output-depth 10 --y4m --profile main10 --high-tier --level-idc 5.1 --crf 17.00 --qpfile GENERATED_QP_FILE --vbv-maxrate 160000 --vbv-bufsize 160000 --hrd --no-sao --range limited --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" --max-cll "0,0" --hdr --hdr-opt --output "samsung hybrid test1.265"


Anyhow, if you want to give it a shot - here is the source video:
https://openload.co/f/Zfi6a9o4VV4/Samsung_HDR_Wonderland_2160p_hevc_10bit_23.976hz_bt.2020_hdr10.mkv


My encoding setting are simple:
x265 10bit
Preset: medium
Tune: none
CRF 17

Non-standard CL options:
--no-sao --level-idc 5.1 --hrd --hdr-opt --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" --max-cll "0,0"

[sneaker_ger]

Is Hybrid still using mkvmerge 11.0.0? (Again: don't shorten MediaInfo logs) It has a bug that corrupts the HEVC headers. Then MediaInfo will not detect the x265 settings. Use latest mkvmerge.

[jd17]

You were right!

Not only was mkvmerge 11 the root cause for the stripped MediaInfo, the encode created in Hybrid plays fine on the TV's internal player, although the parameters are essentially identical to the HandBrake encode (which still does not play)...

Hybrid:

General
Unique ID : 217123577944451960012513319253810230841 (0xA3587AE3DF94D25EBDAC9A25576A3639)
Complete name : C:\_encode\hybrid test2.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 273 MiB
Duration : 2 min 41 s
Overall bit rate : 14.2 Mb/s
Encoded date : UTC 2017-07-15 22:09:29
Writing application : mkvmerge v13.0.0 ('The Juggler') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Encoding Gui : Hybrid 2017.05.06.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 14.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.071
Stream size : 273 MiB (100%)
Writing library : x265 2.5+1-adbcc90bdef3:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / no-aud / 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=8 / 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 / dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=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(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : Yes
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

HandBrake:

General
Unique ID : 25137540607718895181579008795944933011 (0x12E950709F1185F551E5AF25F533D693)
Complete name : C:\_encode\handbrake-test1-2.5.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 282 MiB
Duration : 2 min 41 s
Overall bit rate : 14.7 Mb/s
Encoded date : UTC 2017-07-15T22:20:48Z
Writing application : HandBrake 20170711194400-1de8f69-master 2017071201
Writing library : Lavf57.7.2

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 14.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.072
Stream size : 277 MiB (98%)
Writing library : x265 2.5+1-adbcc90bdef3:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / no-aud / hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / 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 / dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=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(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

The only difference is Keyint:
24 / 240 in HandBrake
23 / 250 in Hybrid


I will try to report this bug in the Handbrake forum.
Hopefully they can fix it...

I still prefer HandBrake... Apart from the GUI, Hybrid always needs double the free disk space for the encodes.

[jd17]

Now that this issue is sorted out (vielen Dank @sneaker_ger!), I would be grateful for some advise regarding --uhd-bd. :)

I created one encode without --uhd-bd and one with.

--uhd-bd means a significant bitrate increase and I would like to know if it's worth it.

No --uhd-bd:

General
Unique ID : 217123577944451960012513319253810230841 (0xA3587AE3DF94D25EBDAC9A25576A3639)
Complete name : C:\_encode\hybrid test2.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 273 MiB
Duration : 2 min 41 s
Overall bit rate : 14.2 Mb/s
Encoded date : UTC 2017-07-15 22:09:29
Writing application : mkvmerge v13.0.0 ('The Juggler') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Encoding Gui : Hybrid 2017.05.06.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 14.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.071
Stream size : 273 MiB (100%)
Writing library : x265 2.5+1-adbcc90bdef3:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / no-aud / 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=8 / 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 / dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=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(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : Yes
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

With --uhd-bd:

General
Unique ID : 214017709364404599423607843951800577469 (0xA1024FBF149C0B33B859A6193C8D6DBD)
Complete name : C:\_encode\hybrid test7 uhd-bd.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 410 MiB
Duration : 2 min 41 s
Overall bit rate : 21.4 Mb/s
Encoded date : UTC 2017-07-16 19:31:32
Writing application : mkvmerge v13.0.0 ('The Juggler') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Encoding Gui : Hybrid 2017.05.06.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 21.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.107
Stream size : 410 MiB (100%)
Writing library : x265 2.5+1-adbcc90bdef3:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / 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 / dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : Yes
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

The differences triggered by --uhd-bd are:

--aud
--no-open-gop
--min-keyint 1 (instead of 23)
--keyint 24 (instead of 250)
--chromaloc 1 (+ chromaloc-top=2 and chromaloc-bottom=2)

So, I made another encode using all those --uhd-bd parameters except the changed keyint values:

General
Unique ID : 240264526869195679385027338102789456693 (0xB4C143C28958A89E99150C3CF45D4335)
Complete name : C:\_encode\hybrid test6 uhd-parameters except keyint chromaloc 2 proper.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 273 MiB
Duration : 2 min 41 s
Overall bit rate : 14.2 Mb/s
Encoded date : UTC 2017-07-16 20:14:49
Writing application : mkvmerge v13.0.0 ('The Juggler') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Encoding Gui : Hybrid 2017.05.06.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 14.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.071
Stream size : 273 MiB (100%)
Writing library : x265 2.5+1-adbcc90bdef3:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / 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 / dynamic-rd=0.00 / no-ssim-rd / 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 / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / 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 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / 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=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500) / 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 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : Yes
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

This encode confirms that the difference in bitrate comes from the keyint changes only.

As far as I understood --keyint, limiting it to 24 means severely restricting x265 in it's capability, right?

Hybrid says this:
Since the max intra distance used directly translates to more buffer requirement during playback and less accurate seeking most stand alone players got some restrictions regarding the max distance.

So, is it mainly limited to be hardware-compatible?

[sneaker_ger]

To be compliant with Blu-ray specs. Since you aren't creating a Blu-ray I wouldn't worry about it too much. In generel, higher --keyint results in increased seeking times because if you seek to a random position you have to decode all frames starting from the last keyframe. With 24 fps and --keyint 24 there's one keyframe every second. With --keyint 240 only every 10 seconds. So when seeking you will have to wait on average 10 times longer (if we simplify a bit to make seek time only decoding time). --keyint 24 increases the need for bitrate because redundancies between frames can only survive 1 second because in a typical movie we don't have a new scene every second. That wastes lots of bits. When we increase keyint the need for bitrate decreases but the savings diminish at some point. I think at about 4 seconds (at 24 fps roughly --keyint 96) you will have a sweet spot with a good compromise between seeking times and compression. Just do a few tests if you are interested or do a forum search. It was discussed in the past.

[jd17]

Since you aren't creating a Blu-ray I wouldn't worry about it too much.

Well, the intention of this whole exercise is to find good settings in the hope that one day I'll be able to encode an actual UHD Blu-ray - and be prepared for it...
I'm not planning to watch HDR demo videos all day. :)

In generel, higher --keyint results in increased seeking times because if you seek to a random position you have to decode all frames starting from the last keyframe. With 24 fps and --keyint 24 there's one keyframe every second. With --keyint 240 only every 10 seconds. So when seeking you will have to wait on average 10 times longer (if we simplify a bit to make seek time only decoding time). --keyint 24 increases the need for bitrate because redundancies between frames can only survive 1 second because in a typical movie we don't have a new scene every second. That wastes lots of bits. When we increase keyint the need for bitrate decreases but the savings diminish at some point. I think at about 4 seconds (at 24 fps roughly --keyint 96) you will have a sweet spot with a good compromise between seeking times and compression. Just do a few tests if you are interested or do a forum search. It was discussed in the past.

Thank you so much, that's very good advice!
I will do some testing.
However, I think I'll have to find another demo for that because the Samsung HDR Wonderland has very long scenes - not representative of an actual movie.

What about --min-keyint? Should I set that to 1 or leave at 0 (which is usually 23)?

One more thing, is there any downside in using the remaining --uhd-bd parameters?
--aud
--no-open-gop
--chromaloc 2

[sneaker_ger]

What about --min-keyint? Should I set that to 1 or leave at 0 (which is usually 23)?
Leave it at default (i.e. don't explicitly set it).

One more thing, is there any downside in using the remaining --uhd-bd parameters?
--aud
--no-open-gop
--chromaloc 2
--chromaloc signals the chroma position of your source. So it should be set the way the source is. On UltraHD Blu-ray chromaloc 2 is required for BT.2020, for BT.709 it can be 2 or 0. So Blu-ray requires certain source characteristics. x265 will not convert for you, only set the flags.

--no-open-gop is not required for Blu-ray. Both are allowed. OpenGOP improves compression a bit. Can be problematic with some players e.g. in mp4 and makes editing more difficult.

--aud is for compatibility. You shouldn't need to set it. If you don't encode for Blu-ray it is not required. If you encode for Blu-ray it will already be activated by --uhd-bd anyways (same with --min-keyint 1).

[jd17]

I am asking because even for a UHD Blu-ray encode I would not use --uhd-bd (because of what you told me about --keyint).
Instead I would manually only set the essential parameters that don't increase the bitrate unnecessarily.
This is what I meant to say before...

I am creating encodes with different --keyint values now to see where the sweetspot might be...

[sneaker_ger]

I am asking because even for a UHD Blu-ray encode I would not use --uhd-bd (because of what you told me about --keyint).
Instead I would manually only set the essential parameters that don't increase the bitrate unnecessarily.
This is what I meant to say before...
Well, it is a bit unusual but looking at the code it seems possible. (For x264 this is not possible because not all Blu-ray options are exposed to the user but it seems to be ok for x265.)

What I also found is --uhd-bd indeed disables OpenGOP. I didn't know that and I don't know why it does that. OpenGOP is allowed on Blu-ray. So either it is an error or x265's OpenGOP implementation isn't compatible with Blu-ray. So maybe it is better to turn off OpenGOP for Blu-ray after all (i.e. set --no-open-gop).

[jd17]

OK, here it goes. :)

Encode test results with various --keyint values.
I still used the "Samsung HDR Wonderland" demo as kind of a "worst case" scenario, because it has very long, almost static scenes.

--min-keyint / --keyint
Bitrate

1 / 24 (--uhd-bd):
21.4 mbit/s

1 / 48:
17.6 mbit/s

1 / 72:
16.6 mbit/s

1 / 96:
15.9 mbit/s

1 / 120:
15.0 mbit/s

12 / 120 (0 / 120):
15.0 mbit/s

1 / 144:
15.1 mbit/s

1 / 168:
15.0 mbit/s

1 / 192:
15.1 mbit/s

23 / 250 (default):
14.2 mbit/s

It looks to me like the obvious sweetspot is at 1 / 120 (5 seconds) for this demo.


I will later try to see if the "sweetspot" shifts when I use the "Exodus UHD HDR" demo, that is more action-packed, or rather action-y at all. :D

[jd17]

I created a few Exodus encodes as well last night, the difference is much subtler, as expected.
1 / 96 and 1 / 120 are quite similar, 96 only gets a minor bitrate bump. Even 1 / 24 is not too far off due to the very short scenes.

However, I think I will stick with 1 / 120 to not waste bitrate on "slow" movies.
Seeking / skipping should be OK.

So, thanks to your help I think I found quite good settings to use on UltraHD Blu-rays - assuming and hoping it will be possible to encode those at some point... :)

Basic syntax:

--profile main10 --high-tier --level-idc 5.1 --no-open-gop --hdr --hrd --aud --chromaloc 2 --range limited --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(*,*)" --max-cll "*,*"

Custom for me:

--preset medium --crf 17.00 --no-sao --min-keyint 1 --keyint 120 --hdr-opt

[lauguru]

hello

How would you write the tweak for x265 of this encode?thanks



Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : 36
Duration : 2 h 1 min
Bit rate : 50.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.254
Stream size : 42.8 GiB (80%)
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primar : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 10000 cd/m2
Maximum Frame-Average Light Le : 3647 cd/m2[/PHP]




TWEAK_X265=--output-depth 10 --profile main10 --tune grain --level-idc 5.1 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --uhd-bd --hdr-opt


Mastering display color primar : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 10000 cd/m2
Maximum Frame-Average Light Le : 3647 cd/m2[/PHP]

[supergimp]

I hope no one minds a lurker jumping in and asking a question on this topic.

I have a ProRes 4444 UHD HDR (NCLC=9,16,9) source file and am creating a set of HD/UHD files to be packaged for DASH distribution. The source is smpte2084 mastering display P3 at 4000 nits (G(0.265, 0.690),B(0.150, 0.060),R(0.680, 0.320),WP(0.3127, 0.3290),L(4000, 0.0005)). Typical stuff.

Encoding with the following (HD example given, UHD versions don't scale) I'm getting a slight pink shift I'm told by the client (I don't have the ability to view the source with proper EOTF).

ffmpeg -i INPUTFILE.mov -filter_complex '[0:v]scale=1920:-1:flags=+bicublin:sws_dither=ed[v]' -map '[v]' -c:v libx265 -pix_fmt yuv420p10le -preset slow -x265-params level-idc=5.0:high-tier=1:aud=1:sar=1:no-open-gop=1:scenecut=0:ref=4:me=3:merange=57:keyint=48:min-keyint=48:rc-lookahead=96:sao=1:cbqpoffs=6:crqpoffs=6:hrd=1:bitrate=5000:vbv-maxrate=5000:vbv-bufsize=7500:videoformat=5:range=limited:colorprim=9:transfer=16:colormatrix=9:hdr-opt=1:master-display='G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,5)':max-cll='2226,899' -an -dn -sn -y OUTPUTFILE.hevc

Reading here about caveats regarding scale, color_matrix, etc I've tried removing those to no avail. I'm curious if anyone can see any glaring issues that I am overlooking (after messing with this for a week now).

Thanks for any ideas.

[kolak]

Your source is YUV, so encoded h265 should be exactly the same. Rest is how TV processes your metadata.

[quabit]

Try making the chroma qp offsets both -6

Lower is higher bits

Sent from my SAMSUNG-SM-G920A using Tapatalk

[benwaggoner]

Your source is YUV, so encoded h265 should be exactly the same. Rest is how TV processes your metadata.
Yeah, some devices just skew pink/red. It's really common in initial tone mapping implementations. I'm not sure the reason. One theory is that panels all have a native gamma input (even though the actual pixels aren't gamma), so there is a PQ->gamma->panel space conversion for extra unneeded rounding errors.

You simply can't tune HDR encoding without an HDR reference display, or diagnose problems on the customer end without seeing their display. And you can't assume a customer display is accurate. Particularly if the display is in some sort of default Vivid mode, or hasn't been calibrated, or simply doesn't have a good tone mapper. There are a number of devices on the market that demonstrate a red shift in what should be gray-white. And the exact same file will look perfect on a calibrated reference display (I use the Sony Z9D).

[DenisRodman]

Tell me which command disables the Encoding settings?

In MediaInfo it is necessary that this information is not displayed.
Encoding settings : cpuid=1173503 / frame-threads=2 ...
Only information about the encoder.
Writing library : x265 2.4+13-26963e98fa64:[Windows][MSVC 1910][64 bit] 10bit

And one more question, can I add user information about the encoder?

for example
Writing library : Here is my info about the encoder

[SeeMoreDigital]

hello

How would you write the tweak for x265 of this encode?thanks


Chroma subsampling : 4:2:0 (Type 2)


Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

[microchip8]

Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

same as yuv420p10.

[nevcairiel]

Out of interest... What is 4.2.0 'type 2' all about? I've noticed it cropping up in a few of my sample files...

Its the value of chroma_sample_loc_type_top_field/bottom_field. Basically the location of the subsampled chroma sample. When you reduce 4 samples to just one, you need to remember which location you sampled at.

Type 0 is the "normal" type for 4:2:0 which we've been using for years, also known as the MPEG2-type (MPEG1 was different) - for every 4 Luma samples, the Chroma sample sits in between the two Luma samples on the left

Like this, Luma being X, Chroma o

X X
o
X X


Type 2 is the "new" standard userd in certain UHD specifications, where the Chroma sample sits right on top of the top left Luma sample, ie:
(Chroma location in red)

X X
X X


This distinction is important when upscaling Chroma, because doing it wrong can introduce a slight shift in the chroma.

[SeeMoreDigital]

same as yuv420p10.Thanks.

Does 'type 2' offer any benefit over regular 4.2.0?

[microchip8]

Thanks.

Does 'type 2' offer any benefit over regular 4.2.0?

I'm not sure but nev explained it above much better than my extremely short post. What i meant as yuv420p10 is that you'll only come it across on 10 bits files. I've never seen a Type 2 on 8 bits ones, like never

[nevcairiel]

I don't know why they decided to change it. Maybe because its simpler? But basically, unless you are downsampling your own chroma, you just have to use the value that matches your content.

[sneaker_ger]

Some specs may even require it. E.g. UltraHD Blu-Ray demands type 2 for all BT.2020 content.

[SeeMoreDigital]

Sorry Nev, I missed your post in between posting my reply to froggy.

There's a guy over on the AVforum who's having a problem playing certain "Nvidia Encoded HEVC files" on his LG Oled B6. I asked him to upload a MediaInfo file report and the only odd thing I could see was the 'type 2' tag.

I looked through my HEVC samples and found a few a 'type 2' tag files that play fine on my humble LG 65UH770V.

Anyway, I've asked him to provide some samples.


Many thanks for the replies everyone :)

[Asmodian]

I don't know why they decided to change it. Maybe because its simpler? But basically, unless you are downsampling your own chroma, you just have to use the value that matches your content.

I think it must be this. Scaling for all planes can be done relative to 0,0 at the top left.

:thanks:

Edit: Would 50% downscaling be faster and better quality? After all we already have all the exact chroma samples we need without any shifts or interpolation. This would be pretty common, displaying UHD on FHD displays.

[SeeMoreDigital]

...There's a guy over on the AVforum who's having a problem playing certain "Nvidia Encoded HEVC files" on his LG Oled B6. I asked him to upload a MediaInfo file report and the only odd thing I could see was the 'type 2' tag.

Anyway, I've asked him to provide some samples.
Update time... After receiving three samples and running them through eac3to v3.34, it reported the following: -

MKV, 1 video track, 1 audio track, 0:00:29, 48i /1.001
1: h265/HEVC, 3840x2176 48i /1.001 (30:17), 10 bits
2: AC3, 5.1 channels, 640kbps, 48kHz
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[v01] This doesn't seem to be a valid h265/HEVC stream (3). <ERROR>
Aborted at file position 44040192. <ERROR>

As you guys can see, not only has the HEVC video stream been encoded with 2176 (instead of 2160) pixels, it's reported as being 48i... Crazy!

And just to make matters even stranger... When I re-muxed his samples into the .m2ts container using TSmuxer GUI v2.6.12, they actually played on my LG 65UH770V :eek:

[gonca]

Update time... After receiving three samples and running them through eac3to v3.34, it reported the following: -

MKV, 1 video track, 1 audio track, 0:00:29, 48i /1.001
1: h265/HEVC, 3840x2176 48i /1.001 (30:17), 10 bits
2: AC3, 5.1 channels, 640kbps, 48kHz
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[v01] This doesn't seem to be a valid h265/HEVC stream (3). <ERROR>
Aborted at file position 44040192. <ERROR>

As you guys can see, not only has the HEVC video stream been encoded with 2176 (instead of 2160) pixels, it's reported as being 48i... Crazy!

And just to make matters even stranger... When I re-muxed his samples into the .m2ts container using TSmuxer GUI v2.6.12, they actually played on my LG 65UH770V :eek:

I encode a lot of 4k with NVEnc and I never got those weird results
Could be cmd line or source filter issue

[Qarmaa]

Can someone explain why --uhd-bd option is forcing --no-open-gop option? The problem is Scenarist UHD can't mux seamless connected clips with closed-gop encoded streams. Sure I can turn off --uhd-bd option and manually set parameters that makes compliant UHD BD stream, but with open GOP. That way Scenarist can mux seamless, I'm just aware of compatibility with hardware players.

[Qarmaa]

In addition to previous post. I'm getting following error when trying to mux stream encoded with --uhd-bd (closed GOP):

Error : [MUX] Can not write MUX file(s) : Could not create MUX XML File(Video data in TS2 does not start with a closed GOP.[PlayList: PlayList#1, PlayItem : Clip#2, Clip: Clip#2])

[FranceBB]

@Qarmaa... I think it's to increase compatibility with some players that might have difficulties with a GOP that is too long. In broadcast, a closed GOP is required, not sure about UHD BDs.

[Qarmaa]

Problem solved using last build (not stable). Now video encoded with --uhd-bd mux in seamless correctly.

[TEB]

@Qarmaa... I think it's to increase compatibility with some players that might have difficulties with a GOP that is too long. In broadcast, a closed GOP is required, not sure about UHD BDs.

Where did u read that in broadcast Closed Gop is required? Ive been working with broadcast for 16 years and ive never closed a gop (besides in ABR stacks)

[excellentswordfight]

Where did u read that in broadcast Closed Gop is required? Ive been working with broadcast for 16 years and ive never closed a gop (besides in ABR stacks)
Ye, we use opened GOP on our HEVC-UHD hw-encoder as well. Fixed GOP though.

[FranceBB]

@TEB and @excellentswordfight... I guess our playout playback ports are just particularly picky and demand it, then. For instance, the oldish ones we used for XDCAM50 1080i and the very old ones we used for DV25 576i required closed GOP. They were actually able to play open GOP files, but it wasn't recommended by specs and they said that it should have been avoided, in fact we tried with open GOP files and they took like a lot to seek, they were almost unseekable and this created issues coming back from a commercial break to resume playback at a specific timecode. They are probably one of the cheapest, yet crappiest playout ports. I wouldn't be surprised if other ports used by other companies (like yours) were able to play Open GOP files flawlessly.

[excellentswordfight]

@TEB and @excellentswordfight... I guess our playout playback ports are just particularly picky and demand it, then. For instance, the oldish ones we used for XDCAM50 1080i and the very old ones we used for DV25 576i required closed GOP. They were actually able to play open GOP files, but it wasn't recommended by specs and they said that it should have been avoided, in fact we tried with open GOP files and they took like a lot to seek, they were almost unseekable and this created issues coming back from a commercial break to resume playback at a specific timecode. They are probably one of the cheapest, yet crappiest playout ports. I wouldn't be surprised if other ports used by other companies (like yours) were able to play Open GOP files flawlessly.
We have videoservers for XDCAM as well that needs closed GOP, I was talking about contribution encoders.

[user1085]

I see that Google has an official documentation page for VP9 HDR encoding with ffmpeg

https://developers.google.com/media/vp9/hdr-encoding/

I took most of the settings from here and changed libvpx-vp9 to libx265 and my Vizio TV detects and plays HDR10 (shows HDR10 info).

ffmpeg -i strobe_scientist_18Mbps.webm -b:v 18000000 -pass 1 \
-pix_fmt yuv420p10le \
-color_primaries 9 -color_trc 16 -colorspace 9 -color_range 1 \
-maxrate 26800000 -minrate 8040000 -profile:v 2 -vcodec libvpx-vp9 /dev/null && \
ffmpeg -i strobe_scientist_18Mbps.webm -b:v 18000000 -pass 2 \
-pix_fmt yuv420p10le \
-color_primaries 9 -color_trc 16 -colorspace 9 -color_range 1 \
-maxrate 26800000 -minrate 8040000 -profile:v 2 -vcodec libvpx-vp9 \
strobe_scientist_18Mbps.webm

Few follow up questions on this

Are the settings above completely different from what's being discussed in this thread? I didn't see discussion around -color_primaries, -color_trc, -colorspace, -color_range
Is there anything I can add to above command line to improve the encodes?
The page mentions "HDR requires 2-pass encoding". Is that just for VP9 or is that true for x265 as well?because I'd like to use CRF if possible

[benwaggoner]

Some specs may even require it. E.g. UltraHD Blu-Ray demands type 2 for all BT.2020 content.
The scary thing is, I don't know that either encoders or playback are actually doing the proper RGB <-> 4:2:0 w/ chromaloc 2 correct placement.


It may be that all the UHD HDR stuff actually is using the chromaloc 0 positioning, which works because both encoders and decoders ignore it.


Any error at 2160p isn't likely to be visible; worse case it would be 25% the impact CUE was at 1080p.

But I get nervous about what might happen if some encoders and/or players do it correctly and some don't, for content at lower resolutions. And no one seems to have a good test pattern for this.

[no-one]

Problem solved using last build (not stable). Now video encoded with --uhd-bd mux in seamless correctly.

I found this error too. can you tell me how to fix this?

Thank you.

[redbtn]

The whole --chromaloc 2 thing is a little suspect for me in general. It's required by UHD-BD, but I don't know that sources are ever converted to that, nor if decoders/displays correct for that in their YUV-RGB conversion. So you might removing ut_h_chr_pos etcetera from ffmpeg and remove chromaloc 2 from x265.

I read this topic and another one (https://forum.doom9.org/showthread.php?p=1766641#post1766641) and dont understand do i need --chromaloc 2 or --chromaloc 0 for encode 4k HDR or 4k->1080p HDR.
VapourSynth ClipInfo() show Chroma Location: Left

VapourSynth Docs:
Possible chroma locations (ITU-T H.265 Figure E.1): left, center, top_left, top, bottom_left, bottom

So Left mean 0 i think.

I'm confused. What the right way?
PS: Im encode through vspipe.exe --y4m video.vpy -

[sneaker_ger]

--chromaloc is only a flag. You need to set it so fits your content. If your source is chromaloc 2 input and you want chromaloc 0 output you need to filter the content inside VapourSynth accordingly.

[redbtn]

--chromaloc is only a flag. You need to set it so fits your content. If your source is chromaloc 2 input and you want chromaloc 0 output you need to filter the content inside VapourSynth accordingly.

Thank you! But I do not understand unfortunately what chromaloc in my source. text.ClipInfo() show Unknown if i just open source via LWLibavSource, if i resize 2160p to 1080p, then Left. How to correctly determine chromaloc?

My VS script

clip = core.lsmas.LWLibavSource(source="source.mkv", format="YUV420P10")
clip = core.std.AssumeFPS(clip, fpsnum=24000, fpsden=1001)
clip = core.std.CropRel(clip=clip, left=0, right=0, top=264, bottom=264)
clip = core.fmtc.resample(clip=clip, kernel="spline64", w=1920, h=816, interlaced=False, interlacedd=False)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10).text.ClipInfo()
clip.set_output()


Source Mediainfo

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 58 min
Bit rate : 51.9 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.261
Stream size : 42.9 GiB (100%)
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 73 cd/m2

[blublub]

Hi

Do I need special switches for HDR besides the ones I already use?

I currently use:
--profile main10
--output-depth 10
--colorprim bt2020

My encoded movies work as HDR on my TV look realy good.

So my primary question is do I need "--hdr-opt" as it is often referred to in this forum but mostly on older threads.

[Blue_MiSfit]

You should use this, yes. It applies offsets to chroma QPs to improve quality for HDR encoding.

You should really signal --transfer smpte2084 (to signal the PQ curve) and --colormatrix bt2020nc. You should also signal HDR10 static metadata e.g. --master-display and --max-cll if available. This will give your display as much info as possible to present the best possible HDR image.

https://x265.readthedocs.io/en/default/cli.html

[blublub]

You should use this, yes. It applies offsets to chroma QPs to improve quality for HDR encoding.

You should really signal --transfer smpte2084 (to signal the PQ curve) and --colormatrix bt2020nc. You should also signal HDR10 static metadata e.g. --master-display and --max-cll if available. This will give your display as much info as possible to present the best possible HDR image.

https://x265.readthedocs.io/en/default/cli.html

uuuuh ok :thanks:

I can easily set:
--transfer smpte2084
--colormatrix bt2020nc
--hdr-opt

But how do I set " --master-display" and "--max-cll" that looks really complicated.

[sneaker_ger]

Most people look up the source parameters using MediaInfo and then use those values. For master-display these have to be re-calculated but most sources seem to use the very same parameters for the color coordinates anyway where MediaInfo will say "Mastering display color primaries : Display P3" and it's the exact values you find as an example in the x265 docs.
https://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display

Also if MediaInfo says "Chroma subsampling : 4:2:0 (Type 2)" set --chromaloc 2.

[blublub]

Most people look up the source parameters using MediaInfo and then use those values. For master-display these have to be re-calculated but most sources seem to use the very same parameters for the color coordinates anyway where MediaInfo will say "Mastering display color primaries : Display P3" and it's the exact values you find as an example in the x265 docs.
https://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display

Also if MediaInfo says "Chroma subsampling : 4:2:0 (Type 2)" set --chromaloc 2.

OK, thx.

I checked some encoded HDR files and the max-cll values are set correctly. Also the master-display information is included but I can't see those values in the ripped original files with media info - kinda strange.

[THU22]

What does --max-cll and --master-display actually do?

I am trying to get into HDR encoding, but it seems a bit complicated.

Basically this is my command line for SDR videos: --crf 18.0 --fps 24000/1001
This gives me actual perfect quality with 12-bit x265 (dark scenes and fades are perfect too). I do not see the point of using additional settings, I do not care about optimizing the bitrate, it is very low anyway.
I play videos on my PC (MPC-HC + madVR), so I do not care about compatibility either.

This is what I currently have for HDR: --crf 18.0 --fps 24000/1001 --hdr10 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
HDR playback works and looks ok (LG OLED C8), but you cannot compare the HDR source and encode like you can with SDR. Can I be missing something by not using max-cll and master-display? What if I use them, but set them wrong?

[benwaggoner]

What does --max-cll and --master-display actually do?
--maxcll It specifies the nit value of the brightest single pixel (MaxCLL - Max Content Light Level), and the nit average nit value of the brightest single frame (MaxFall, or Max Frame Average Light Level).

Master Display encodes the color volume that the display used in mastering was. The idea is that pixels with values outside of what the mastering display could be clipped because the colorist couldn't have seen those differences. Higher end consumer TVs can deliver a lot more brightness than typical grading monitors.

This is what I currently have for HDR: --crf 18.0 --fps 24000/1001 --hdr10 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
HDR playback works and looks ok (LG OLED C8), but you cannot compare the HDR source and encode like you can with SDR. Can I be missing something by not using max-cll and master-display? What if I use them, but set them wrong?
Definitely add --hdr10 and --hdr10-opt.

That'll put in null values for the SEI metadata, which tells the TV that the values are undefined, which TVs know what to do with. It is much better to use null values than specify incorrect ones!

[Blue_MiSfit]

From what we've seen, the max-cll and master-display params end up doing little to nothing most of the time :)

You never know what future behavior will be, so I agree with the recommendation to make them exact or null.

[THU22]

Thanks for the info.

And can I use the 12-bit x265 encoder with a 10-bit source?

With SDR content, 12-bit encoding provides significantly better results (dark scenes and fades), but I wonder if it can somehow break the accuracy with HDR. 10-bit encoding definitely creates slight artifacts at low and medium bitrates during dark scenes and fades, 12-bit would probably eliminate that, just like with SDR content.

[benwaggoner]

From what we've seen, the max-cll and master-display params end up doing little to nothing most of the time :)

You never know what future behavior will be, so I agree with the recommendation to make them exact or null.
For displays with a peak brightness lower than the MaxCLL, they can adjust the rolloff at the top of brightness based on it some. So, the lower the MaxCLL, the brighter the average frame can be due to less need for headroom.

I'm not familiar with MaxFALL being used much; could be used for average power level adjustments.

Dynamic metadata is much, much, much more useful!

[Blue_MiSfit]

Thanks for the info.

And can I use the 12-bit x265 encoder with a 10-bit source?

With SDR content, 12-bit encoding provides significantly better results (dark scenes and fades), but I wonder if it can somehow break the accuracy with HDR. 10-bit encoding definitely creates slight artifacts at low and medium bitrates during dark scenes and fades, 12-bit would probably eliminate that, just like with SDR content.

You could... but nothing useful would be able to decode it :)

[THU22]

As I said, I only encode videos for personal use and I play them on PC, so compatibility is of no concern. I only care whether it provides accurate results (as it does with SDR content).

On a side note, are hardware decoders not able to decode 12-bit video? It does not seem to require any more power (GPU or CPU) when played on PC.

[Blue_MiSfit]

Not generally as far as I'm aware, no.

[microchip8]

As I said, I only encode videos for personal use and I play them on PC, so compatibility is of no concern. I only care whether it provides accurate results (as it does with SDR content).

On a side note, are hardware decoders not able to decode 12-bit video? It does not seem to require any more power (GPU or CPU) when played on PC.

I have an NV Shield TV (2019 model) and it can decode 12 bit

[THU22]

Shield uses an NVIDIA GPU, so it is like a PC basically. You can use hardware acceleration on PC with 12-bit video.

But I find it weird if other devices cannot do it.

[benwaggoner]

Shield uses an NVIDIA GPU, so it is like a PC basically. You can use hardware acceleration on PC with 12-bit video.
The shield uses a Tegra ARM SoC, not an actual GPU. So the capacities don't have a 1:1 mapping. Both the 2017 and 2019 are based on the Maxwell microarchitecture. Which has pretty powerful media processing, but equivalent to the 9xx series PC GPUs which were the first capable of HDR output.