The problem is not the frame rate conversion per se, but rather the type of conversion that is going on here.
I'm pretty sure you're using blending, which means that the input is indexed and then Avisynth tries to "blend" together frames, namely the frame immediately after the current frame and the one immediately before and "overlaps" them to reduce the framerate. Of course, Avisynth is telling you "hey, I can't do that, mate, 'cause there aren't enough frames, I would have to do the blending of the blending, so overlap more than two frames".
Blending (overlapping) more than two frames leads to a pretty bad frame rate conversion as it's going to produce something that looks like a ghosting artifact sort of speak.
If you use a custom Avisynth Script, you can see what I mean by doing:
Code: Select all
m_clip=ConvertFPS(m_clip, 200).ConvertFPS(134).ConvertFPS(90).ConvertFPS(60).ConvertFPS(50)
return m_clip
The output is gonna be awful.
On the other hand, "ChangeFPS" will just drop frames to 50p so that the encoder can then detect 50p and divide in fields to get a 25i:
which is the same as just setting the GUI without flagging the "blend" option, however... we have a problem here.
What ChangeFPS() does is just to either duplicate or drop frames, so in this case it seems ok to say "ok, we have lots of frames, we can drop some to get to 50p without any issues, right?"
WRONG!
If they really were 300fps, sure, but that's not the case here, 'cause our source is VFR!
VFR, Variable Frame Rate, means that the phone captured a certain amount of FPS depending on the motion of the scene, so there can be as many as 300fps but there could also be as little as 24fps in some scenes (no, mediainfo can't be trusted for max/min VFR info).
So... what happens is that Avisynth can only handle CFR, therefore indexers like ffms2 find the AVERAGE framerate and index it as such with the relative fpsnum and fpsden to create a constant frame rate A/V stream.
The problem with this is that the scenes in which there are less FPS than the average are gonna be duplicated and the scenes in which there are more FPS than the average, those are gonna be dropped.
In other words, we have a stuttering mess and if we add ChangeFPS() we might end up taking the dups and discarding the good frames or vice versa, it's totally random and out of luck, which can't be the case.
Since extracting the VFR stats and finding a way to feed Avisynth with the stats and work with them is complicated and gets even worse if you're trying to do this automatically, the thing to do here is using TDecimate and force our way out with the desired framerate.
Code: Select all
m_clip=TDecimate(m_clip, mode=2, rate=50)
return m_clip
What TDecimate is gonna do is find all the input frames, divide each one of them in blocks and macroblocks, assign a number to each one of them and then compare each frame with the next one and with the next one etc. Then, it will drop those with the lowest value, so with the lowest motion, which means that it's hopefully gonna drop the dups and, when there are no dups, it's going to drop those with less motion, to make the overall experience smooth.
Side note: please note that TDecimate is part of the TIVTC package and if you don't have Avisynth installed, you'll need to manually load it after downloading it, like:
Code: Select all
LoadPlugin("C:\example\TIVTC.dll")
and then use the command I wrote.
I hope it helps.
Cheers,
Frank
