This is following up on one of the bugs I reported in the BETA version 24.02 thread here. I’ll repeat the report here:
Colors are still altered when using Ut Video in Convert To Edit-friendly. However, the colors are accurate when using Ut Video from the Export preset list. The discrepancies in color can be seen in the linked images below. Original video Ut Video Converted To Edit-friendly
Just to clarify, the video isn’t HDR. When I select the Edit-friendly format in the Convert To menu, I stick to just that option without tweaking anything else in there like sub-clips or color space. The colors look spot-on in the “good” (H.264) and “better” (DNxHR) formats, but it’s the “best” option (Ut Video) where those color discrepancies pop up, as you can see in the links above. And as I also said above, this issue doesn’t occur when I use Ut Video from the Export preset list.
It’s been happening across various files for me, and after Dan said in the thread he didn’t reproduce it, I reckon the best way to tackle this is for me to share the exact file I used for those screenshots so you can dive into what’s causing these color discrepancies in the “best” Convert to Edit-friendly option. You can download the video here.
The sample video does not specify a color space. ffprobe comes back with “unknown”, but we can guess from visual inspection that it should be BT.709. MLT (not FFmpeg) also infers BT.709 because of the Poynton heuristic.
However, the color space of the converted video is BT.601, which explains the color shift. This is somewhat unique to the Ut Video codec. If -colorspace is not specified on the command line, then Ut Video will default to BT.601 regardless of the upstream color space. Yeah, it’s dumb, but it’s what happens. The legacy reason is that for Ut Video, there are different FourCC codes for BT.601 (ULY0) vs. BT.709 (ULH0). Color space in Ut Video is not defined using a regular metadata field like it is for other codecs.
Getting technical, colors shifted on the sample video because the only time -colorspace is added to the ffmpeg command line in the transcoder module is if the “Convert to BT.709” checkbox is checked. Since that checkbox was not checked, there is no -colorspace added to the command line, and therefore Ut Video defaults to BT.601 regardless of the source’s color space.
Relevant code here, with my crummy hot-take suggestion being to have the transcoder module always specify -colorspace, which is hopefully safe since in theory the upstream producer already did the Poynton resolution hack:
It is not really always safe. It would need to use the colorspace from the MLT producer but what about color_primaries? Usually it has been safer to let ffmpeg do what it knows how to do, which is to pass through when it can.
I can certainly appreciate specifying as little as possible. The situation gets even harder with “BT.601” because of the NTSC and PAL variants like bt470bg.
What about a middle ground? If the producer color space is BT.709, then specify -colorspace bt709 on the command line, which at worst is merely redundant. The primaries and transfer function could continue to pass through and be no worse off. This is the minimal configuration to get a Ut Video BT.709 FourCC.
Obvious exception for the Convert to 709 checkbox. It forces its own primaries/trc and can specify them.
EDIT: For even more containment, the color space could be specified only for the Ut Video transcode option (line 260 in transcoder.cpp) and only if the producer is BT.709. It wouldn’t hurt the other codec options, and wouldn’t be any worse than what we have today. Currently, if I understand right, the Convert to Edit-Friendly lossless option is broken for all BT.709 source videos, which is probably the most common use case for the lossless option.
