UltraHD BluRay chroma positioning

[sneaker_ger]

I'm currently looking at a white paper for UltraHD BluRay. (http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf)

Chapter 3.6.3 and 3.7.3 are as follows:
For ITU-R BT.709 (colour primaries is set to 1), chroma_sample_loc_type_top_field and
chroma_sample_loc_type_bottom_field shall be set to 0 or 2 if chroma_loc_info_present_flag is set to
1. If chroma_loc_info_present_flag is set to 0, the location of chroma sample is type 0 and
chroma_sample_loc_type_top_field and chroma_sample_loc_type_bottom_field are both inferred to be
equal to 0.

For ITU-R BT.2020 (colour primaries is set to 9), chroma_loc_info_present_flag shall be set to 1 and
chroma_sample_loc_type_top_field and chroma_sample_loc_type_bottom_field shall be set to 2.

chroma_sample_loc_type_top_field and chroma_sample_loc_type_bottom_field shall have the same
value.

Am I understanding this correctly?
A.) the common "MPEG-2" chroma position is not supported for BT.2020?
B.) for BT.709 we have the choice between two different chroma positions?
- common "MPEG-2" (chroma between top and bottom, left side)
- same as for BT.2020 (chroma on same position as top-left luma sample)

[nevcairiel]

This is correct, the standard asks for a slightly different chroma position.

[sneaker_ger]

Thx. So now authoring houses and studios have have yet another thing to screw up.
Does anyone know the reason for this decision?

[benwaggoner]

I don't know where this comes from, but it's also standard practice for HDR-10 encoding. Fortunately with 3840x2160p sources, slight errors are going to be much less visible than at lower resolutions.

[vivan]

AFAIK that's exactly how gpu treats 2 textures with different resolutions. That's one of the reasons why 2/3 of video players on Android have shifted chroma (other 1/3 uses nearest neighbor).
So that makes it easier to render.