Movie Writer Colors differ significantly from Rendered Output

[thygrrr]

Tested versions

Reproducible in 4.3 stable on Windows 11 Pro, with a reasonably recent version of VLC

The color discrepancy exists in VLC Media Player even if all preferences are reset to default.
The color discrepancy is visible in HandBrake preview, but is goine in H.264 output.

System information

Windows 11 - Godot v4.3.stable.mono.official [77dcf97]

Issue description

Recording a movie results in a movie file whose color grading is quite different from the output shown, both while recording or while playing the scene normally.

Steps to reproduce

1. Run the attached Reproduction Project, enabling the movie writer
2. Run it again without recording, and bring the video up in a player on the same screen to compare
3. Observe: Differences in colors and brightness even with a world environment derived from the default (color differences are somewhat subtle, but usually noticeable, you can use an image capture program to compare)

Screenshot with locally sampled color values in image editor and annotated)

Minimal reproduction project (MRP)

Reference Project

movie-color-grading-bug-repro.zip

Reference Project Movie File:

movie.avi.zip

"Repaired" Movie after Re-Encoding to H.264 with HandBrake 1.8.1

Movie-22-repaired.mp4

[thygrrr]

Hardware:

Running in Desktop Colour Accuracy Mode "Accurate" or "Override to Reference Mode" results in the same results. (I usually run in Accurate)

I do have Monitor color profiles installed:
(LG) 38GN950, LG SDQHD, LG ULTRAGEAR (for the three displays, respectively)

The bug occurs on all screens and appears unrelated to color correction in hardware / driver level.

[thygrrr]

Re-Encoding the movie with HandBrake to something "default", like H.264 as written by the preset "Fast 1080p30", will result in a stream that's much closer to the original colors.

(comparing numerically is somewhat moot due to the complete re-encoding and default noisy quality of 22, but it's overall much closer)

[huwpascoe]

It could be that the file needs to be tagged as sRGB or something.

Well these are certainly linked
godotengine/godot-proposals#903

[thygrrr]

It could be that the file needs to be tagged as sRGB or something.

Well these are certainly linked godotengine/godot-proposals#903

I don't think these are directly related, especially not after 4 years. I think that proposal is, at best, valid for Godot 3.

With no color grading enabled (i.e. Linear), a unshaded cube of color #808000FF reproduces exactly as color #808000FF on my display and screen capture. Also side-by-side.

Yet the same captured as video is much darker:

I think this may be a Color Gamut / Full vs. Limited Range scaling issue (due to how the colors actually scale up in bright regions and down in dark regions) in the written video file. Also noteworthy: The video color of the cube is only very subtly different. #808100FF

[thygrrr]

I found this tidbit on my research after trying to take apart the moviewriter:

MJPEG videos are (according to VLC) in Planar 4:2:2 YUV full scale.
Most video is YUV limited scale so a lot of decoders do not expect full range video and AVI has no in-spec way to identify full-range video.

In reality, this is close to how the video is actually seen by VLC:

So it could indeed explain why the video appears dark/exaggerated in AVI format (values from 0..255 may be squished/remapped as if they were expected to be Limited Gamut 12..244 video or something)

(why are we using MJPEG in AVI containers, anyway? judging by the code, that was done because it's somewhat simple to implement, though one might ask why implement a video codec, there's excellent open source projects that do this made by wonderful people who enjoy doing this :) )

[allenwp]

From a quick glance at your original issue description, my first guess would be that VLC is misinterpreting the video to be limited range, when it’s actually encoded as full range. This is honestly an annoying problem that spans all sorts of video encoding/decoding, transport (HDMI, etc), and displays.

It sounds like you have determined what the issue is. Maybe try recording some AVI files with different settings using OBS Studio to see if you can reproduce the same problem. If it’s easy to reproduce the same issue with OBS Studio saving an AVI file, this will be good information in determining if this is really an issue with Godot’s approach or if it’s a widespread issue.

(Personally, I remember having issues with how VLC was treating everything as limited range and stopped using it as my media player many years ago 😅)

[Calinou]

I guess this is one more reason to switch to mpv. 🙂

(why are we using MJPEG in AVI containers, anyway? judging by the code, that was done because it's somewhat simple to implement, though one might ask why implement a video codec, there's excellent open source projects that do this made by wonderful people who enjoy doing this :) )

This was done to avoid linking against FFmpeg, which has licensing quirks (LGPL) and is a huge library compared to a self-made MJPEG implementation. MovieWriter is also compiled in export templates, not just in the editor.

Uncompressed AVI output could be supported, but file sizes are prohibitive when targeting modern resolutions/framerates and QOI makes it less relevant.