Skip to content

Framerate fixes#350

Open
KirbysDarkNebula wants to merge 2 commits into
friction2d:mainfrom
KirbysDarkNebula:framerate-fixes
Open

Framerate fixes#350
KirbysDarkNebula wants to merge 2 commits into
friction2d:mainfrom
KirbysDarkNebula:framerate-fixes

Conversation

@KirbysDarkNebula

Copy link
Copy Markdown

Fixes #322, adds a signal during videobox initialization to adjust video framerate from scene framerate. Gets applied on asset import (drag and drop/ import menu) and on project load so we might want to bump up the project version, since along changing the video framerate to match the scene framerate it also adjusts the video length, which might be a breaking change (then again we were handling it incorrectly before so I don't think it should be allowed if possible, you let me know).

Problems // Limitations

  • Changing scene framerate doesn't change the framerate of the videos immediately, you'd have to reopen the project after saving (reloading the media doesn't fix it).
  • What I think is a bigger issue is the fact that videos only ever adjust to one framerate, that is, you can have multiple scenes in one project, but the videos will only adjust to the scene they're loaded into, which means the issue we had before persists or gets worse when we change to a scene with different framerate.
  • This does not fix the issue for image sequences, but I can look into it.

The first and third problems seem easy enough to fix but the second one is kind of major and might need some general tweaking of the way the editor handles scenes and assets, so I'm not entirely sure how to approach it. Maybe it's not a big enough problem to look into it because we realistically don't know how much people would be working on scenes with different framerates in the same project but I still think it's important.

I'd appreciate any help to get this to a better state... (For some reason I'm unable to debug the project, that's why changes on my end take a while).

Here's some example videos I made (on friction) to better test the framerate changes, they sync on this branch but do not on the original.

30fpsanim.mp4
60fpsanim.mp4
600fpsanim.mp4

@rodlie

rodlie commented Nov 29, 2024

Copy link
Copy Markdown
Member

Thanks for working on this, will take a look at the PR and the limitations/issues tomorrow.

@KirbysDarkNebula

Copy link
Copy Markdown
Author

Hi, it has been almost a year since I worked on this and I was wondering if this was ever looked into. I saw there were a few release candidates through the year and I understand that the focus is elsewhere but I feel like something as "basic" as this should be looked into, because people will import media and expect it to play properly, and lacking this, in my opinion, makes workflows with assets of different origins very difficult. (some media being 30fps, other being 24.99fps, etc.)
I imagine the codebase has possibly changed a bit so if changes were needed I could look into that, and the issues I outlined on my original post persist, but those were intended to be looked into as we moved along with this initial change, so let me know how we should proceed on this, thanks.
(Also, as I as I was looking through my changes I remembered I was working on a feature that I wanted to propose, but seeing as this didn't move forward I never made a PR, so if this can get moving I would be interested in helping and working on that)

@rodlie

rodlie commented Nov 13, 2025

Copy link
Copy Markdown
Member

Yeah, sorry about that.

I never did anything with this PR as there seems to be more issues lurking, and there might be other ways to solve this.

I imagine the codebase has possibly changed a bit

No changes has been made to videobox.


I can try to look into this after RC3 (note that I forget easily, always too much stuff happening).

A list of everything that's broken related to video is needed before anything is done, as things might be connected (usually is).

@rodlie rodlie added this to the 1.0.0 milestone Nov 13, 2025
@rodlie

rodlie commented Apr 9, 2026

Copy link
Copy Markdown
Member

I'm really sorry for the delays (I forget stuff very easily and have a major backlog on emails/notifications). I will look at this issue after work today.

Do we need to do any changes to the sound handler?

@KirbysDarkNebula

Copy link
Copy Markdown
Author

hi, it's been a long while but from what i remember the sound adjusted properly to scene framerate, the problem was only present in videos and image sequences, as outlined in my post

@rodlie

rodlie commented May 1, 2026

Copy link
Copy Markdown
Member

Thanks for the info.

Again sorry for the delays, always something in the way (and I forget). I aim to release soon and this issue is a blocker (I have dedicated Saturday to fix any blocker issues left before release).

@rodlie

rodlie commented Jun 14, 2026

Copy link
Copy Markdown
Member

Sorry again for the delay, I made a new commit based on this PR: 7bb1e7d

  • This fixes scene changes
  • Regarding linked scenes I don't think we are able to fix that easily, at least not for v1.0.x
  • We should of course do this for image sequences

The biggest issue is of course breaking every project file before this. Any video will be wrong, so what to do? should we have a special case where we warn if the project is "old" and includes a video ?

Now users will need to keep an old version of Friction to read old project? or:

Introduce a "backward compatibility" setting that disable VideoBox::setCorrectFps ? or maybe just disable it in the background for any old project? (but that won't work when user hit save, then the project version is new)

Maybe add a new tag in the project format, "legacyVideo"? Any old project or any new project with "legacyVideo" will not run VideoBox::setCorrectFps?

Late night ramlings 😄

@pgilfernandez what do you think ?

@pgilfernandez

pgilfernandez commented Jun 14, 2026

Copy link
Copy Markdown

Umm, I would bet for max compatibility, I love open source because your projects are always safe (most of...). So in this case, couldn't we open the old project with the new Friction, warn that the project will be updated and saving it with a new filename is recommended in order to not loose the old one? That way users could work with the old projects in the "new" format... and what if they want to go back? Maybe that's not necessary as the new Friction versions can run perfectly in the same hardware... that is, they can easily update their Friction version and they are ready to go 😅

@rodlie

rodlie commented Jun 14, 2026

Copy link
Copy Markdown
Member

What I think we do:

  • bump file format to 35 (frameRateFixes)
  • introduce a new bool in VideoBox (legacyFramerate) default is false
  • on read project, if lower than 35 then set legacyFramerate to true, if 35 or newer read legacyFramerate
  • on save project store legacyFramerate state
  • in setCorrectFps we don't to anything if legacyFramerate is true

This way old projects will work (existing VideoBoxes have the "legacy" framerate) and adding new VideoBoxes will have the new framerate, when we save the project both old and new VideoBoxes works as the user expect, should in theory work and be transparent for the user(?)

@pgilfernandez

Copy link
Copy Markdown

Sweet!
And what if the user wants to "convert" and old project to the new system? is it possible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Issue with video speed being affected by scene framerate

3 participants