Replay Mod (Fabric & Forge)

Replay Mod (Fabric & Forge)

1M Downloads

Washed out colors when rendering as a video but accurate when rendering as a PNG sequence

SpacEagle17 opened this issue · 3 comments

commented

After rendering a replaymod recording I have noticed that the colors of the video are washed out and less saturated compared to what you see in-game. Then I tried to render it as a PNG sequence and it was accurate again and exactly like in-game. I have already talked about this issue in the replaymod discord server in a support thread (https://discord.com/channels/708304818829262910/983797559132839977).
I'm using Replay Mod v2.6.5 and the Compatible Sodium 0.4.1 for Minecraft 1.18.2 version.
First the comparison screenshots:
(they are not all at exactly the same frame, but should be close enough, ±5 frames. For better comparison open the images in a new tab)

The PNG sequence image (this will be our reference image)
100

A screenshot of the video with these settings: Mp4 1080p 20Mbps
Resolve_Z9oP6dsX1X

A comparison side by side thanks to Kepler-17c from the replaymod discord (left is the PNG sequence and right the MP4 screenshot)
comparison

Slider: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=786f2a90-e6b0-11ec-b5bb-6595d9b17862
As you can see the video one is much more washed out.

In the thread I linked earlier, we came to the conclusion that it also happens with vanilla so also when shaders are disabled.
Changing the bitrate doesn't affect things either:
We have tried 10Mbps, slider: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=d1e1eb4e-e6b0-11ec-b5bb-6595d9b17862
20Mbps (image from the start)
60Mbps, slider: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=73371956-e6b1-11ec-b5bb-6595d9b17862

Then we tried this command line (calling it "command line 1") bela333 from the replaymod discord gave me:
-y -f rawvideo -pix_fmt bgra -s %WIDTH%x%HEIGHT% -r %FPS% -i - %FILTERS%-an -b:v %BITRATE% -c:v libx264rgb "%FILENAME%"
Slider: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=42a278fc-e6b2-11ec-b5bb-6595d9b17862
After that we also tried another command line (to test if Resolve can load that one, calling it "command line 2") bela333 gave me again:
-y -f rawvideo -pix_fmt bgra -s %WIDTH%x%HEIGHT% -r %FPS% -i - %FILTERS%-an -b:v %BITRATE% -c:v libx264rgb -pix_fmt yuv420p "%FILENAME%"
Slider: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=a1d72e94-e6b2-11ec-b5bb-6595d9b17862

As you can see both command lines 1 and 2 gave the correct result. (As a small notice, both videos generated with command lines 1 and 2 couldn't be imported into Davinci Resolve and only VLC Media Player could play them)
It seems to me like a colorspace conversion issue and color accuracy is rather important for what I use replaymod for.
I hope that this helps

commented

Which ffmpeg version are you using? I can't seem to reproduce this using ffmpeg 5.0.1, neither from the reference image provided, nor directly in the mod:

Left to right: PNG, MP4 Custom preset, command line 1

Tried to reproduce it from the reference image like this:

ffmpeg -i reference.png -f rawvideo -pix_fmt bgra -s 1920x1080 raw
cat raw | ffmpeg -y -f rawvideo -pix_fmt bgra -s 1920x1080 -r 1 -i - -b:v 20M -c:v libx264 -pix_fmt yuv420p output.mp4


Left reference, right output

commented

I was using ffmpeg 5.0.
I got interesting results.
This is my mods folder:
explorer_MrugUDfIai

This is with ffmpeg 5.0:
Replaymod 2.6.6: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=ff789176-0621-11ed-b5bb-6595d9b17862
Replaymod 2.6.4: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=576bc984-0622-11ed-b5bb-6595d9b17862

This is with ffmpeg 5.0.1:
Replaymod 2.6.6: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=24d28468-0622-11ed-b5bb-6595d9b17862
Replaymod 2.6.4: https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=6e0a13c6-0622-11ed-b5bb-6595d9b17862

In all these comparisons you can see that there is in fact a color difference, the curious thing is that in those comparisons the screenshot of mp4 render looks more accurate than what I have seen on my screen. I am pretty confused right now as that is the opposite of what I reported earlier.

This should probably be reported in a separate bug report, but using 2.6.6 and rendering as a png sequence creates corruptes images every 10 frames or so. Here are 2 examples of it:
10
73
This happens in all scenes. No matter what, only with 2.6.6

commented

Hm, not sure what's going on. PNG should be the most accurate since there's no color space conversions or lossy compression, it should be pretty much 1:1 what was displayed on screen. Only potential difference being that PNG can include the alpha channel, but that should be disabled by default since 2.6.4.

This should probably be reported in a separate bug report, but using 2.6.6 and rendering as a png sequence creates corruptes images every 10 frames or so. Here are 2 examples of it:

That's a known long-standing bug, it just got much more likely to happen with the recent improvements to png/openexr export performance. It'll be fixed in 2.6.7: 6e3d30e (if you need a workaround, you can use Stereoscopic rendering and then cut off half of it in your video editor)