HandBrake

I was told the framerate conversion algorithm is very basic so i suggest a better one that doesn't cause stuttering when changing a lower framerate to a higher one (Such as 23.976 to 25)

What algorithm would you suggest? "A better one" isn't very specific.

Oh, and to quote others, "Patches Welcome".

Why do you want to change frame rate anyway?

Most modern players and TV's will handle this for you.

Woodstock wrote:What algorithm would you suggest? "A better one" isn't very specific.

Oh, and to quote others, "Patches Welcome".

Oh im sorry, i thought this was a suggestion forum. I didn't realise i had to satisfy you too!!!

Not a case of satisfying any particular person.

However, asking for "something better" without suggesting something that is better is exceedingly vague. Some of the things that would be "better" are not available under the source licensing being used for Handbrake.

If you know of something better, suggest it. If you don't, do a bit of research to see if there is something, and suggest it.

In this case, however, it would have to be something very smart, because you're asking it to chose one frame out of 24 to insert to make 25 frames in a second, all while not affecting the smoothness of motion. To truly be smooth, you would have to take those almost-but-not-quite 24 frames, and use them to construct 25 NEW frames, averaging the motion of objects across them.

some interesting looking ones that I found:
http://www.ee.cityu.edu.hk/~lmpo/public ... VT_4SS.pdf

http://www.snellgroup.com/documents/whi ... _Paper.pdf
http://www.snellgroup.com/documents/eng ... motion.pdf

https://www.google.de/search?q=frame+ra ... +algorithm

someone would need to ask the author(s) though if he's allowed to write a code based on this algorithm and publish it as open-source

Djfe wrote:someone would need to ask the author(s) though if he's allowed to write a code based on this algorithm and publish it as open-source

We could as a courtesy, but unless it's patended I don't think we need to.

Anyway, I have no personal interest in adding such a feature, sorry.

We will accept (good) patches though.

Frame rate conversion, other than by drop/dupe (which Handbrake already supports), involves very complex resampling algorithms.
A good one is Twixtor. Depending on your editor, it starts at $300+.for the plugin.

To be honest, the usual method for 23.976 -> 25 fps conversions is to overcrank it - assuming you apply pitch correction the only side effect is reducing the running time of the title by ~4%. This is common practice for PAL DVD releases.

Completely true.
90%+ of PAL movie releases are done this way.
Often the audio is just resampled without any pitch correction.

Yup. You're only looking at a semitone difference so most people won't notice it unless they do a side by side comparison.

I grew up in an era when vinyl recordings were sped up a semitone to mask wow and flutter. Really hard to learn songs on piano in seven sharps (C#).

TedJ wrote:To be honest, the usual method for 23.976 -> 25 fps conversions is to overcrank it - assuming you apply pitch correction the only side effect is reducing the running time of the title by ~4%. This is common practice for PAL DVD releases.

It's not just common, it's universal. There is no other way (except for some anime).

Also, pitch correction has the potential to decrease sound quality in negative ways. Usually, the sound is just stretched, leaving it almost a semitone higher. This is no more noticeable to audiences than the 4% faster pacing.

Given that we in PAL-land don't need 3:2 pulldown and we got a better colour system and frame resolution, I can live with the 4% speedup for 24p movie content. Blu-ray is making that moot nowadays anyway.