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

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