I didn't notice too much of a difference between 20fps and 24fps. Like Lex said, 20fps seems to blink faster, which made the blinking of the purple stars/galaxies in the background of the terminal cutscene more regular. I also found the faster blinking at the end more annoying, though.
Btw, this is pretty much what I referred to when talking about flicker-optimized AviSynth script, but as I haven't tried it yet I don't know how it would look as a result (I think it might produce a slight interlacing artifact that way due to non-uniform sprite brightness), but it would retain better fluidity than both 20 and 24 fps, and a clear reference to proper flickering as well by alternating between 33% and 66% sprite opacity during such segments (as opposed to 50% the entire flicker time).
I'd love to see this. If anyone can code an AviSynth function that does that, it would be appreciated. I'd like to try, but I don't even know how to loop through groups of 2 or 4 frames in a clip. If someone can explain me this, I would make the function.
What I can say is that 30 fps is the same as 60 fps (as expected).
24 fps and 20 fps both looks terrible to me, motion-wise. Thus, I'm looking forward some advanced frame-blending techniques!
Just out of curiosity: Could you make a 30 FPS version where each frame is a blend (ie. average) of the two frames of the original 60 FPS footage? How would that look like?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
That was described by moozooh in a previous post in this thread. It is possible, but it seems like nobody here has the expertise or time to write such a script.
Actually, a simplier version has been used for some time where the exact average of the two frames was used. It lead to all flickering or frame-alternating motion turning the sprite in question into a blurred or translucent (due to the average between 100% and 0% opacity being 50%) form, depending on the nature of the motion. It's arguably better than 30/60 fps's complete vanishment/solidity, but still far from perfect.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
That, and it looks absolutely awful with moving backgrounds. That's part of the reason I can't make many hybrid blending/decimate encodes. If the game has most of the flicker being in areas with moving backgrounds, it'll just look like a blurred mess (and make it quite obvious when it is blurred and when it isn't).
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
If someone is going to test averaged frames (not me, because I'm confident it won't be better) you should also include a part of, say, Sonic and Knuckles 3. Something with a LOT of motion and more complicated backgrounds.
Mister Epic:
Afaik Youtube simply drops frames until the framerate is <= 30, so your 30 and 60 uploads should be the same.
Warp wrote:
It would still be nice to see how the Super Metroid clip would look like with averaged frames.
Like this. Personally I don't think the blurring is worse than having non-smooth motion or no effect at all.
Btw. don't use interlacing and weaving for this, it can lead to "line jumping" in some cases.
As for a function that "stretches" frames over time, that's what ConvertFPS does, and I think it creates clips where moving objects alternate between blurry and sharp, like bad frameblended 24 fps -> 30 fps video conversions.
Optimally, you'd just average the sprite layer and it'd be the emulator providing that functionality. Arm pumping would still look stupid though. Hm, if there was an option to blend frames x and x+1 with 66%/33%, then frames x+2 and x+3 with 33%/66%, etc, and only on the sprite layer, maybe that would produce some nice results... Maybe not.
Btw, I've found 24fps to be the worst by far. It just looks very irritating to me for some reason.
Edit: Hm, with 33/66, 66/33, 33/66, 66/33 the focus would be on frames 2 and 3, then 6 and 7 etc though, so maybe that'd look a bit wobbly.
Maybe 33/66, 50/50, 66/33, 50/50 would look better (I'm trying to think of something that'd still make pumping look like the arm is actually moving, not just doubled).
Or something like 60/40 of frames 1&2, then 10/40/50 of frames 2,3&4 and repeat?
Pretty difficult to imagine what any of this would look like.
@Flygon: How would it be impossible if you let a modified version of the emulator (or maybe LUA) do it?
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
I, myself, would very gladly just blend the sprite layer and that's it. But the problem is is that it's nigh impossible to do when you consider that sprites go behind and on top of the background layer/s at the same time. Even in NES games.
Edit:
Kuwaga wrote:
@Flygon: How would it be impossible if you let a modified version of the emulator do it?
Well, the issue is finding emulator authors that'd be willing to do it to my specifications. That, and I'm still having difficulty doing green-screen effects in AviSynth.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
creaothceann wrote:
Kuwaga wrote:
@Flygon: How would it be impossible if you let a modified version of the emulator (or maybe LUA) do it?
You're assuming that hardware sprites are used only for moving objects and hardware BGs for static backgrounds.
Yeah, that's the other problem. It really buggers up some games, such as Sonic 3 and Knuckles. Or Super Mario Bros. games that used sprites as hidden blocks.
So yeah. I've encoded the same Super Metroid clip I've used for my other tests, using both frame blending techniques mentionned.
33% + 66%, 66% + 33%33% + 66%, 50% + 50%, 66% + 33%, 50% + 50%
If one of them is going to be adopted in the official encoding rules, I'll take creaothceann's function, and make an AviSynth function called "TASBlend", requiring only a clip, so we can use it as easily as clip.TASBlend().
EDIT: I personally like the first frame blending method. What do you think?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Mister Epic wrote:
So yeah. I've encoded the same Super Metroid clip I've used for my other tests, using both frame blending techniques mentionned.
33% + 66%, 66% + 33%33% + 66%, 50% + 50%, 66% + 33%, 50% + 50%
If one of them is going to be adopted in the official encoding rules, I'll take creaothceann's function, and make an AviSynth function called "TASBlend", requiring only a clip, so we can use it as easily as clip.TASBlend().
EDIT: I personally like the first frame blending method. What do you think?
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Mister Epic wrote:
So yeah. I've encoded the same Super Metroid clip I've used for my other tests, using both frame blending techniques mentionned.
33% + 66%, 66% + 33%33% + 66%, 50% + 50%, 66% + 33%, 50% + 50%
If one of them is going to be adopted in the official encoding rules, I'll take creaothceann's function, and make an AviSynth function called "TASBlend", requiring only a clip, so we can use it as easily as clip.TASBlend().
The first of those looks reasonably smooth. The second ... doesn't.
