Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix some media attachments being converted with too high framerates #17619

Merged
merged 1 commit into from
Feb 22, 2022

Conversation

ClearlyClaire
Copy link
Contributor

Video files with variable framerates are converted to constant framerate videos and the output framerate picked by ffmpeg is based on the original file's container framerate (which can be different from the average framerate).

This means that an input video with variable framerate with about 30 frames per second on average, but a maximum of 120 fps will be converted to a constant 120 fps file, which won't be processed by other Mastodon servers.

This commit changes it so that input files with VFR and a maximum framerate above the framerate threshold are converted to VFR files with the maximum frame rate enforced.

Video files with variable framerates are converted to constant framerate videos
and the output framerate picked by ffmpeg is based on the original file's
container framerate (which can be different from the average framerate).

This means that an input video with variable framerate with about 30 frames per
second on average, but a maximum of 120 fps will be converted to a constant 120
fps file, which won't be processed by other Mastodon servers.

This commit changes it so that input files with VFR and a maximum framerate
above the framerate threshold are converted to VFR files with the maximum frame
rate enforced.
@ClearlyClaire
Copy link
Contributor Author

ClearlyClaire commented Feb 22, 2022

To be honest, I would advocate changing the flags to switch to variable framerate unconditionally, as I see no reason to stick to CBR with x264 MP4 files… for the record, we have used this flag since 6382ef2, when Mastodon used to encode to WebM. No rationale has been given in that commit, and I wasn't around in the project at that time, so I don't know what was the reason for that choice. I suppose this may have been linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1022762

In the meantime, this PR is conservative in its approach by only changing the options if the file has a max framerate that exceeds the framerate limit, which means it should only change how files that currently cause issues are processed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants