add --chromaloc 2 to x265 parameters automatically if source is 4.2:0 (Type 2)

[E-t-z]

A bit unsure on this, if it is even required, some sources say it is definitely required if you want to retain HDR, others say it is optional.

Maybe @cdgriffith can comment on this (you wrote terrific article on HDR encoding after all) and if needed, could implement it?

[cdgriffith]

Never heard of that before actually. Know of any example sources that have type 2 chroma? Would need to find out how that is displayed via ffprobe.

If you happen to have one, would appreciate output of:

ffprobe -v quiet -loglevel panic -print_format json -show_format -show_streams <file>

[E-t-z]

Most UHD BR's (if not all) with HDR should have it, but I have some sample clips myself as well.

Type 2 does not have anything chromaloc related present in JSON.

But, when you don't specify it as x265-param and use Defaults, this row appears on HEVC stream.
"chroma_location": "topleft",
Immediately after "color_primaries": "bt2020"

In mediainfo, it shows like this:

Type 2:

Default (Without chromaloc specified):

[E-t-z]

Some documentation https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup19-201910-I!!PDF-E&type=items

To follow BT.2020 specifications, it seems to be, kind of required, if Color Space is YUV (YCbCr) a.k.a TV color. 😄

[E-t-z]

My current assumption is, that it should be always used, when dealing with WCG/HDR content and YUV.

At least all of my 10-bit HDR sample files (except one) have Type 2 specified.
Checked couple of UHD BR's as well, they also have 4:2:0 (Type 2) on all of them.

[cdgriffith]

Thanks for the details!

Luckily it does display in ffprobe: "chroma_location": "left" looks to be 0 and "chroma_location": "topleft" looks to be 2.

And you are correct that it seems a movies encoded with FastFlix without that does switch it from topleft to left. (There seems to be debate if anything actually uses that flag right now, is possibly why no one has yet noticed https://forum.doom9.org/archive/index.php/t-174491.html)

https://x265.readthedocs.io/en/3.1/cli.html says to refer to the HEVC specification to find what the 5 possible options mean, did a quick search through https://www.itu.int/rec/T-REC-H.265-201911-I/en without much luck, would like to get them all defined for future proofing.

[E-t-z]

For me Type 2, does not seem to reflect anything in ffprobe output, at least BR's which I checked have nothing in that output.
That element is simply not present...but they are Detected as 4:2:0 (Type 2).

You are probably right, that nothing uses it at the moment, as my AndroidTV does not seem to care.
Still, it would be nice to follow the standards, in case something does and messes up the colors 😆

I think best way to understand, how it is actually reflected in ffprobe, would be to encode 6 sample files, with chromaloc flag 0...5 and one without that flag and then compare outputs.

[E-t-z]

@cdgriffith BTW all HEVC possible chroma locations are described here:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.265-201612-S!!PDF-E&type=items

On page 384, Figure E.1

TL;DR: They are basically: left, center, top_left, top, bottom_left, bottom

[cdgriffith]

I think best way to understand, how it is actually reflected in ffprobe, would be to encode 6 sample files, with chromaloc flag 0...5 and one without that flag and then compare outputs.

You know, I felt so smart going and brute forcing it just like that, and was coming back to report the results and you already posted the idea 😭

chromaloc	ffmpeg chroma_location
0	left
1	center
2	topleft
3	top
4	bottomleft
5	bottom

[E-t-z]

And now, checkbox would be nice "Preserve Chroma location", checked by default for HDR and inserting chromaloc=X as last element into x265-params 😄

Too bad, I suck on python...maybe I could rewrite it in C# (kidding) 😋

[cdgriffith]

I think it's safe to just always insert it if the incoming source provides a chroma_location.

My only wonder now is if doing the remove_hdr process changes the chroma_location..hmm..

[E-t-z]

That is an interesting question indeed.
But if you look this table (I pasted here previosly) BT.709 has Chroma_location=0 always, when YUV is used.

AFAIK, you cannot remove HDR and keep BT.2020 😉

EDIT: Mkay, you actually (technically) can...wondering, what is the point of having BT.2020 on SDR.

[cdgriffith]

Currently it does take it down to bt709, so hopefully just always setting / leaving it at 0 is proper for that.

Filter used:

zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap={tone_map}:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p"

[E-t-z]

As 0 seems to be default as well, I don't think it would cause an issue.

[cdgriffith]

I hope not, and just did some test encodes with Handbrake to see how they handled it, they seem to ignore it entirely as well (everything comes out 0).

I'm still planning on adding the passthrough, just glad I'm not the only one who missed the memo 😉

[E-t-z]

As I stated at the beginning, I'm quite unsure how much it actually matters in real life, but it seemed to violate the spec,
so I simply started digging.

Even checked couple of encodes (of UHD BR's I own) on torrent sites, to see how famous scene groups handle it.
And they all seemed to preserve "chromaloc" for some reason...and you already know the rest I guess... 😄

AFAIK, Handbrake cannot handle HDR properly, their internal pipeline is 8-bit only, so I would not pick them as reference.

[E-t-z]

Anyway, I think we can close this now.

[cdgriffith]

I just like to keep these open until actually released to keep track of progress, thanks again for all the info!

[cdgriffith]

Fixed in 4.2.0 https://github.com/cdgriffith/FastFlix/releases/tag/4.2.0

[cdgriffith]

When you convert to BT.709 you need to scale planes to different chroma sample location with -vf scale. @ValZapod

I don't fully follow, do you have an example?