Bt601 does not appear in the reference section in the pdf

@dericed Do you mean Rec. 709?

pointing on 1 specific document which provides choices about transformations constants is maybe not the best choice (why BT.601 and not BT.709 or BT.2020?)
Maybe a more generic paper on color spaces?

It seems to me that Rec. 709 fits better the purpose than Rec. 601, but I plenty agree with @JeromeMartinez. I would recommend Charles Poynton (I also use Y′C_BC_R myself).

• Updated from bt601 to bt709.
• Added the same reference to the pdf references section.

Ready for review again.

Refering to bt709 would suggest that no other YCbCr can be stored or that its implied to be bt709 "compatible"

Refering to bt709 would suggest that no other YCbCr can be stored or that its implied to be bt709 "compatible"

None of them, as bt709 is only one of the possibilities for YCbCr.
@dericed, why a specific standard (here, HDTV, excluding SDTV or UHD or...)? From my point of view, it may be misleading, as the bt number is in the Matroska for the moment (we plan to add the bt number later in FFV1 as a metadata)

Since the intro suggests that familiarity with YCbCr is assumed, I wanted to add a reference in case the reader needs that info.

Having a reference is good, but having a specific YCbCr transformation as a reference may make people think that this is the "standard" method for FFV1 (and it is not).
As the constants are not provided by FFV1 (external metadata for the moment), I suggest something more neutral e.g. https://en.wikipedia.org/wiki/YCbCr which says that there are several possibilities (including broadcast vs full range).

I suggested Rec. 709 because in my experience is what people request most those days. The Wikipedia entry is not completely correct, but Charles Poynton’s attemps to improve it failed. I’m OK with it, not less not more.

I suggested Rec. 709 because in my experience is what people request most those days.

Really depends of who you are talking to. In some other domains, this is XYZ (cinema, and they also use lossless video, but ok maybe out of topic it is not YCbCr) or HLG (broadcast, extending YCbCr from BT.2020 used for 4KK, and there are more and more 4K content).
My concern is to not be focused on what we use to have now in our domain of expertise and to try to stay neutral. Yesterday was BT.601, today is BT.709, tomorrow is BT.2020/HLG, the day after tomorrow will be something else. And yourself use other color spaces. Wikipedia entry is just an idea, my concern is to avoid to focus on a particular color space, as it may be misleading as an endorsement of this particular color space in FFV1.

If we stay with a particular BT.xxx, maybe writing that this is only an example and that there is no endorsement of particular YCbCr transfer constants.

And yourself use other color spaces.

Indeed! And I know why… ;-)

The colour space XYZ is the origin which is meant to represent scientifically the view of an average trichromat.

As said, I’m OK with the Wikipedia entry for Y′C_BC_R.

Updated from ITU bt709 to Wikipedia:YCbCr

LGTM