# Video encoding: How much does the video file size increase with fps?

Given that the next blockbusters of e.g. Peter Jackson (The Hobbit) and James Cameron (Avatar 2) are going to be shot with a frame rate of 48 fps (or even more) - i.e. more than the usual 24 fps - I was wondering: How much does the file size of the encoded video increase with the fps?

With increasing fps the frame to frame difference becomes smaller and smaller. So I suppose that the file size grows less than linear. Is this true? Is there a rule of thumb? Or does anyone have example file sizes of the same video encoded in 24, 48, 60, and 96 fps (with a modern video codec)?

(Side question: How much does the video file size increase with image sizes beyond Full HD - e.g. from Full HD to 4k?)

• Quick answer to your side question: Directly proportional to number of pixels of a single image. So, if you are going from 1920x1080 to double that, both width and height, then you are quadrupling the bit rate. The main question is much more complex :)
– Bora
May 14, 2011 at 19:45
• File-size will only be affected by the actual frames (container overhead not withstanding), not the frame rate. You could have 24 physical frames per second encoded into the video, but have it report as and/or play at 48fps (the player drops every other frame), while conversely, you could have 48 frames per second play at 24 (the player plays each one for twice as long). The 48@24 will have a larger size than the 24@48 because it has more frames actually encoded into it. May 11, 2013 at 18:47

## 4 Answers

The ONLY thing that impacts filesize is bitrate. You can do 1fps or 120fps, and if your bitrate is 1000Mbs, the filesize will be exactly the same. By definition, the bitrate defines the filesize. Feel free to test -- take a video and output it in 10 different dimensions and 10 different fps, and you're going to end up with identical (or negligible difference) filesizes.

This is a simplification, however, if you want to discuss filesize versus quality, then it's a whole different discussion.

• This is a very good point. So for the sake of the discussion can we assume constant quality (not constant bitrate) for all versions? May 14, 2011 at 22:14

I will try the theoretic approach. I would love to see some real-world examples that would prove or disprove my theory. Good question! If you have any comments or find some flaws, feel free to comment.

For any current encoder (let's take MPEG-4/AVC/h.264 as an example) frame rate does not matter as much as you think. Let's just assume there is no rate control and every picture is encoded with the same base QP (quantization parameter).

You are right with the following: The motion difference (as defined in ITU-R P.910, good read) between two frames of an 48 fps video will be lower than for the same video in 24 fps. This is due to the fact that the frames won't differ as much from each other. Note that the whole temporal motion doesn't increase. In the end, an object moves from point A to B, so its motion vector will be the same length no matter how many frames per second.

As the encoder looks for the difference between two (or more) frames and only encodes the residual values, that means it will have to code less residual per picture. In average, this will be half of the residual. So you're right with that. (We must not forget that only half of the residual does not mean half of the data needed to store it. It depends on the algorithmic coding implemented.)

Then again, you have twice as many pictures per second, which means that – in average – the encoded information doubles again.

To summarize, nothing much changes on that side. The encoder will do its best job to encode all the motion in the video, which in sum is the same (just in smaller steps, if you know what I mean). The only overhead we have to add is the overhead from small residuals that can't be arithmetically coded in an efficient way.

The above only applies to B- or P-pictures, which depend on others. However, we have to insert an intra-coded picture every once in a while which isn't dependent on any other picture. If this rate of intra-coded pictures doesn't increase, we could assume a linear growth in file size, maybe a bit more.

However if you decrease the distance of intra-coded pictures in order to compensate for possible packet-loss or bitstream errors, you will carry more overhead and therefore the increase is more than linear, not much, but probably noticeable.

This really depends on the type of encoding. If you capture the video in RAW format, then yes: more images require more storage in a linear fashion.

If you encode the captured images directly into some compressed format, then it all depends on how that codec works.

In regard to file sizes, that is determined by `bitrate × duration`. So the frame rate is not directly involved. To achieve the same quality like that of the same video encoded at a lower frame rate, you probably will have to raise the bitrate somewhat though. By how much - again - depends on the codec you're using.

Also asked myself this question today. On my phone and camera, 60fps videos are almost exactly twice the size of 30fps videos, probably because they don't have too much processing power to spare on smart compression and simply double their framerate to remain on the safe side.

Offline compression can yield better results though. For examples, you can look at YouTube's 60fps videos and specifically the sizes of the actual video files behind different quality settings. A tool like `youtube-dl` allows you to do that. Here's the output from the tool with a random 60fps Youtube video:

``````C:\>youtube-dl -F https://www.youtube.com/watch?v=H53QmxZ-rOs
[youtube] H53QmxZ-rOs: Downloading webpage
[youtube] H53QmxZ-rOs: Downloading video info webpage
[info] Available formats for H53QmxZ-rOs:
format code  extension  resolution note
249          webm       audio only tiny   62k , opus @ 50k (48000Hz), 3.23MiB
250          webm       audio only tiny   82k , opus @ 70k (48000Hz), 4.41MiB
140          m4a        audio only tiny  130k , m4a_dash container, mp4a.40.2@128k (44100Hz), 8.18MiB
251          webm       audio only tiny  158k , opus @160k (48000Hz), 8.41MiB
278          webm       256x144    144p   97k , webm container, vp9, 30fps, video only, 5.11MiB
160          mp4        256x144    144p  113k , avc1.4d400c, 30fps, video only, 3.69MiB
242          webm       426x240    240p  228k , vp9, 30fps, video only, 8.69MiB
133          mp4        426x240    240p  281k , avc1.4d4015, 30fps, video only, 7.95MiB
243          webm       640x360    360p  509k , vp9, 30fps, video only, 15.81MiB
134          mp4        640x360    360p  582k , avc1.4d401e, 30fps, video only, 14.79MiB
244          webm       854x480    480p  771k , vp9, 30fps, video only, 26.80MiB
135          mp4        854x480    480p  992k , avc1.4d401f, 30fps, video only, 20.65MiB
247          webm       1280x720   720p 1555k , vp9, 30fps, video only, 52.89MiB
302          webm       1280x720   720p60 2853k , vp9, 60fps, video only, 79.52MiB
248          webm       1920x1080  1080p 2944k , vp9, 30fps, video only, 94.03MiB
298          mp4        1280x720   720p60 3094k , avc1.4d4020, 60fps, video only, 38.61MiB
303          webm       1920x1080  1080p60 4898k , vp9, 60fps, video only, 142.73MiB
136          mp4        1280x720   720p 4910k , avc1.4d401f, 30fps, video only, 62.89MiB
299          mp4        1920x1080  1080p60 5785k , avc1.64002a, 60fps, video only, 123.69MiB
137          mp4        1920x1080  1080p 6930k , avc1.640028, 30fps, video only, 111.05MiB
43           webm       640x360    360p , vp8.0, vorbis@128k, 43.91MiB
18           mp4        640x360    360p  501k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 31.66MiB
22           mp4        1280x720   720p 1125k , avc1.64001F, mp4a.40.2@192k (44100Hz) (best)
``````

For this video, when compressed with av1, the 60fps FHD video is only 10% larger compared to the 30fps FHD video. But when compressed with vp9, the file size difference is a whopping 60%!

So I guess you can expect 60fps videos sometimes to be up to twice as large, but there are ways to make it have about the same file size with double the framerate, which is pretty neat!