Monochromatic primaries
BT.2020 defines its red, green and blue at single wavelengths: 630 nm, 532 nm and 467 nm. That is what pushes the triangle out to the edge of the visible spectrum, and it is also why no consumer display fully covers it. A good OLED reaches most of DCI-P3, which sits between BT.709 and BT.2020.
The container, not the contents
This is the part that trips people up. Tagging a file BT.2020 does not add colour to it. The gamut is a coordinate system: it says how to interpret the numbers, not what the numbers contain. Footage shot on a camera whose sensor and processing landed inside BT.709 will still be inside BT.709 after retagging, just described in wider coordinates.
What conversion can do is remap the existing colours into the wider space correctly and give the highlights somewhere to go. What it cannot do is invent saturation that was never captured. See what conversion can and cannot do.
In a file
BT.2020 appears in two fields, and they are not the same:
ffprobe -v error -select_streams v:0 \
-show_entries stream=color_primaries,color_space -of default=nw=1 input.mp4
color_primaries=bt2020 is the gamut. color_space=bt2020nc is the non-constant-luminance matrix used to convert between RGB and YCbCr. HDR10 delivery normally carries both.
Questions people ask
Does my monitor cover BT.2020?
Almost certainly not. Its primaries are monochromatic wavelengths at the edge of the visible spectrum, and no consumer display reaches them. A good OLED covers most of DCI-P3, which sits between BT.709 and BT.2020. Every HDR playback chain is gamut-mapping as a result.
Does tagging a file BT.2020 make the colours richer?
No. The gamut is a coordinate system, not content. Footage whose colours fell inside BT.709 stays inside BT.709 after retagging, just described in wider coordinates. Worse, a mislabelled file is interpreted against the wrong primaries and renders incorrectly.