BT.709 for PAL SD

[stubhead]

This is a question regarding color transfer characteristics in encoding to FFV1.

Research for vrecord saw BT709 implemented for all FFV1 capture:

vrecord/vrecord

Lines 881 to 895 in 50e9dba

	# video standard
	"NTSC")
	STANDARD="ntsc"
	DECKLINK_FPS="30000/1001"
	RECORDINGFILTER="setsar=40/27,setdar=4/3"
	MIDDLEOPTIONS+=(-color_primaries smpte170m)
	MIDDLEOPTIONS+=(-color_trc bt709)
	MIDDLEOPTIONS+=(-colorspace smpte170m) ;;
	"PAL")
	STANDARD="pal "
	DECKLINK_FPS="25000/1000"
	RECORDINGFILTER="setsar=16/15,setdar=4/3"
	MIDDLEOPTIONS+=(-color_primaries bt470bg)
	MIDDLEOPTIONS+=(-color_trc bt709)
	MIDDLEOPTIONS+=(-colorspace bt470bg) ;;

, including PAL SD. This seems to show that development is in favor of using the BT.709 profile for color transfer characteristics mapping (ffmpeg “color_trc”) of PAL SD video, instead of the “gamma28” profile (BT.470 B/G), even for SD. Normally I would’ve expected that color transfer would also follow BT.470 for PAL SD.

Dave Rice comments :
"[these comments] came from this section of vrecord which sets color metadata for SD captures in vrecord, conditionally, whether they are NTSC or PAL: https://github.com/amiaopensource/vrecord/blob/main/vrecord#L1873-L1894."

...and further :

"In the QuickTime specs at https://developer.apple.com/documentation/quicktime-file-format/color_parameter_atom, in the transfer index the transfer function value 5 is reserved. But now transfer function = 5 is regarded at bt 470 b/g. Also at the time, we were trying to get vrecord to emulate Final Cut Pro and I believe it used the same transfer function = 1 value which used the same values as bt709."

For encoding from PAL SD, which is the better choice? BT.709 or BT.470 B/G ?

[etienne-ina]

According to ITU-T H.273, if I understand well, all BT.470 systems are marked as "historical" and superseded by BT.601 for SD.
The transfer characteristics of BT.601 are identical to those of BT.709.
BT.470 is different though.
So, for transfer characteristics of SD material, I think either BT.709 (function 1) or smpte170m (function 6, shows up as "BT.601" in MediaInfo), which have the same coordinates, should be used. The only difference will be the way it is tagged.

In FFmpeg, if we want all fields to reflect PAL BT.601, we can use:

-color_primaries bt470bg
-color_trc smpte170m
-colorspace smpte170m

It is functionally the same as the parameters currently implemented in vrecord, but maybe it is semantically more accurate.

[dericed]

Hi @etienne-ina, with those options and using ffmpeg 7.1, the colr atom in a quicktime recording would look like:

Color parameter type=nclc
   Primaries index=2
   Transfer function index=2
   Matrix index=6

Apple's QuickTime documentation calls these:
Primaries index="Primary values are unknown"
Transfer function index="Transfer function is unknown"
Matrix index = "Recommendation ITU-R BT.601-4 and BT.470-4 System B and G, SMPTE 170M-1994, 293M-1996"

Although, that output seems the same as before, so making the proposed change wouldn't change the QuickTime output. @etienne-ina @stubhead (cc @JeromeMartinez), could you clarify which index values in particular you'd propose for the QuickTime colr atom. See https://developer.apple.com/documentation/quicktime-file-format/color_parameter_atom or possibly the ISOBMFF might have this more recently documented.

[etienne-ina]

Well, if those values are unknown by Apple, that's an issue indeed, but only in a QuickTime file, right?
I think stubhead's question referred to the use of FFV1 in a MKV container, although not explicitely mentioned. This is what I was answering to (how to properly tag a MKV/FFV1 file).
For QuickTime, I don't really know.
Should it be the same?

[etienne-ina]

Hi @dericed ,

Thanks to stubhead, we found out that there actually was a bug in ffmpeg v7.1 regarding the color_primaries and color_trc parameters.
See bug tracks https://trac.ffmpeg.org/ticket/11309 and https://trac.ffmpeg.org/ticket/11238
Current workaround is to specify those flags via filters:
-vf setparams=color_primaries=bt470bg:color_trc=smpte170m:colorspace=smpte170m
There it works with 7.1.

[dericed]

Hi @etienne-ina, I had forgotten in this testing that vrecord uses ffmpeg 5.1.4 specifically, via this formula https://github.com/amiaopensource/homebrew-amiaos/blob/master/ffmpegdecklink.rb. So this should be retested in that version. If you have vrecord installed you can access that ffmpeg via /usr/local/opt/ffmpegdecklink/bin/ffmpeg-dl.

[etienne-ina]

I'm not actually using vrecord, but we were trying to align our FFV1 encoding settings to what is proposed by vrecord as a reference tool, hence the question about color parameters.
The inital interrogation was really about how BT.709 found its way into the generation of SD material.