I've noticed that some youtube videos appear not to do well with flicker effects. For instance, the flicker when being hit in Super Metroid. I assume this is because youtube videos are encoded at 30fps, and if the blinking alternates on and off every frame, then the effect will either appear to be always on, or always off. You can see Samus completely disappears on the elevators, when she should be flickering.
SDA has sovled this problem by encoding the low quality versions of videos at 20fps, so as to maintain the flicker effect. Perhaps something similar should be done here since youtube does not take 60fps video.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Why not use ~34 fps oslt? YouTube seems to run higher than 30 fps for the 50 fps video(s) I've uploaded.
Edit: This has been found to be false. It's just flash player being crazy.
But I hate encoding in 24 fps. It makes the video play like **** even without being uploaded to any streaming site, and I find it hard to see because of this.
I guess I'll try encoding at the game's native FPS, and them shove it into YouTube, just to see. I'll also try SDA's idea of 20 fps.
EDIT: It's not my computer. It can play 60 fps HD videos without any problem.
If the game runs at 60 fps and the video is encoded at eg. 24 fps (which is not divisible by 60), does that mean that frames are being simply dropped at irregular intervals? Doesn't this cause jittering motion?
If the game runs at 60 fps and the video is encoded at eg. 24 fps (which is not divisible by 60), does that mean that frames are being simply dropped at irregular intervals? Doesn't this cause jittering motion?
That's exactly my problem with 24 fps.
I'll be encoding the same part of a TAS at 20, 24, 30 and 60 fps, for comparison. I'll probably make a new thread about this.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
The jitter of 24fps also sets me off a bit too, but I think the tradeoff for having the flicker work 'properly' is very much well worth it. And most people don't notice the jitter at all.
If the game runs at 60 fps and the video is encoded at eg. 24 fps (which is not divisible by 60), does that mean that frames are being simply dropped at irregular intervals? Doesn't this cause jittering motion?
That's exactly my problem with 24 fps.
I'll be encoding the same part of a TAS at 20, 24, 30 and 60 fps, for comparison. I'll probably make a new thread about this.
I'm looking forward to this. I also agree that 24 fps looks bad on YouTube. There must be a better framerate.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
To prevent further time-wasting like Flygon went through,
#tasvideos on Freenode wrote:
09:32:54 <LexSfX> Flygon: weird. the one i said ran at 34 fps (a number i got from fraps' overlay before) reports only 30 fps in its video info[ (right-click the video on YouTube -> Show Video Info)], debunking my claim completely
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
As far as I can see, 24fps is the best compromise for these videos. That causes flickering every 6 frames (e.g. AAAAAABBBBBB). Go lower than 24fps and the motion becomes too choppy. Higher than that, and the flickering becomes too slow.
Youtube does not seem to support a higher FPS value than 30 or 31 in some cases (apparently when you put a 60fps movie on Youtube, it becomes 31fps, but I haven't tested that).
24 fps is a bad solution. 20 fps is a better one, a flicker-optimized AviSynth frame blending script (that weaves the adjacent frames together with alternating opacity), while not existing yet, is an even better one.
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
moozooh wrote:
24 fps is a bad solution. 20 fps is a better one, a flicker-optimized AviSynth frame blending script (that weaves the adjacent frames together with alternating opacity), while not existing yet, is an even better one.
I've actually made videos that have blended sections and 30fps sections in others, but this is incredibly movie dependent. It also has the unusual issue on that if I only wanted to blend a boss fight but not other areas of the game (that has flicker and moving backgrounds, since blending moving backgrounds makes it much more obvious there is a blend rather than a static boss fight background), I'd have to convert the non-blended segments to 24fps (unless they have no flicker) then upscale to 30fps, which introduces even more strobing artifacts.
If you ask me, the best solution is to dump the sprites and backgrounds separately, assuming the emulators can be modified to do so according to my required specifications (specifically, I'd need the hidden parts of the sprites to remain hidden in the sprite only dump... something that can't be so easily done with just turning off the background layer).
I'm willing to explain to the curious what I mean in depth, if they want.
PAL videos are so much easier to encode, I swear.
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).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Yes, that's a great idea, moozooh. I consider that the optimal workaround for YouTube's failure to provide 60fps video, especially with the opacity fluctuation. Can you produce a sample script?
Joined: 4/17/2010
Posts: 11473
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Surely 60, 30 & 20 suck.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
20 seems to blink faster, but the frame rate seems too low otherwise. Without an advanced method as presented by moozooh, 24 seems like a happy medium for games with 30Hz-blinking graphics. Thanks for the demo, Mister Epic.
Joined: 4/17/2010
Posts: 11473
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
20 doesn't blink faster, it just leaves more frames with sprite than without. It would look opposite if the sprite starts disappearing another frame.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I would rate those as 20 > 24 > 30 = 60. The difference in overall fluidity between 20 and 24 is, as I expected, absolutely insignificant, while frame-alternating motion (particularly arm pumping) looks more defined on 20 fps because the amount of frames showing the sprite is equal to the amount of frames without it. Screen-shaking effects look ugly on both.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
