Window size changes when in Movie Mode aren't handled correctly

[berarma]

Tested versions

• Reproducible in: 4.5dev5

System information

Debian GNU/Linux 12.10

Issue description

Running a project in embed mode at a different resolution than defined in the project, produces AVI files with incorrect resolution and aspect ratio.

The problem is that in embed mode, the initialization of MovieWriter sometimes receives the project viewport size, and sometimes the embedded viewport size. But the frames sent have always the embedded viewport size.

There was a similar error, same effect, different cause, that was reported in the forum and #71254.

Edit: The issue doesn't happen only in embed game mode, it can happen at anytime if we're not careful to avoid window size changes. We should probably think of a way to handle window size changes in movie mode, implement a way to prevent them, or warn the user when it happens. If the movie writer isn't prepared to handle resolution changes, it could even make Godot crash. See comments below.

Steps to reproduce

• Open any project.
• Make the viewport size in the Project Settings big enoough so that it has to be scaled down to fit the embedded window.
• Enable Movie Maker mode.
• Run the project.
• Check the resulting video.

This might take several tries because it doesn't always happen. In my case it happens like 4 out of 5 times. It looks like a race condition between the embedded process and the MovieWriter initialization.

Minimal reproduction project (MRP)

Any project. The viewport has to be big enough to not fit the embedded window.

[Fireye04]

Trying to repro on arch/i3; I'm just getting output that mirrors the runtime viewport size and nothing else.

The wording of the issue leaves me a bit confused though, would the preferred output be the dimensions set ahead of time in the "viewport size" settings, or the size of the viewport at runtime?

[berarma]

Thanks for testing.

Trying to repro on arch/i3; I'm just getting output that mirrors the runtime viewport size and nothing else.

I think it depends on code execution timing. I couldn't reproduce it always, but most of the times.

The wording of the issue leaves me a bit confused though, would the preferred output be the dimensions set ahead of time in the "viewport size" settings, or the size of the viewport at runtime?

The viewport size settings. I've edited my post to make it clearer.

[Fireye04]

Awesome; In that case I can successfully report full reproduction on both 4.5dev5 and 4.4.1 (arch/niri now).

In my testing I have observed that the recording will always match the runtime, and never the pre-set "viewport size" settings. If by chance the runtime viewport were to be set to the preset setting, then it will record at that preset setting, however if the window is altered, that change is mirrored in the video's output.

[berarma]

This can result in buffer overflows at least for the OGV writer when the resolution increases. No video encoder supports changing resolutions in the middle of a video, AFAIK. MJPEG and PNG, being only intra-frames, seem to handle it without crashing, others will not.

I can write a workaround for the OGV writer so that it fails when the resolution changes to avoid buffer overflows, but the underlying issue is the changing resolutions.

I'm already working on the workaround. I'll create a PR as soon as possible for review.

[berarma]

I've changed the wording of the issue because I think the root issue is allowing window size changes in movie mode without any warning, and the user or the movie writers have to handle them. Users will probably already know that the window size shouldn't change when in movie mode, but there are some instances where they might not be aware of the change, as it happens in embed game mode.

[Calinou]

We should probably have a movie override for the resizable project setting that defaults to false, so you can't resize a window that is recording a movie by default. This would prevent most resolution changes during recording, which are often accidental.