In simple words, is it true that an average size of an encoded video frame would be FrameSize = BitRate/FrameRate? Because BitRate shows how much data we are transferring per time unit, and FrameRate shows how many frames does this time unit contain.

3 Answers 3


Generally speaking, I suppose technically you're correct if you're looking for a general average. But I think we'd really have to hear the use case that you're looking for, as I can't imagine the resulting value being useful for very much at all (in fact, I mostly agree with John's answer). Each frame's size is going to vary wildly; random example. The 20th frame of a person looking at the camera is going to take up about 12 KB, whereas the jump-cut to a helicopter shot of Hong Kong's skyline is going to take up 700 KB.

Just a general tip for this site; often, giving more details about the exact problem you're trying to solve (ie, "My videos are streaming very slowly, and so I'm trying to....") may get you more helpful results than a very direct question.

  • There is no actually certain problem. I was thinking about encoded video transmission over the network and trying to understand/derive the average number of bytes coming through the channel per time unit and whether it is possible to give an estimate of that in terms of average frames size if one could be defined...
    – peetonn
    Jul 23, 2013 at 23:20


That method will generally yield very erroneous (low) results.

Video codecs generally do a LOT of compression on the video stream, as part of encoding the video. The bit rate is of the bits AFTER encoding.

  • so how the average frame size can be calculated? why we can't use bitrate if it shows the bits after encoding - what we want actually...
    – peetonn
    Jul 22, 2013 at 18:53
  • It's calculated in the same way any other average is calculated. You do equally spaced measurements over time, and then average them together. Jul 22, 2013 at 19:09
  • This is going to vary wildly in real content, depending on where the key frames are and what the content is like.
    – user53141
    Jul 22, 2013 at 19:22
  • 1
    No, a video codec does not always guarantee constant framerates or bitrates for video. H.264, for instance, will prioritize between the two by adjusting the keyframe interval as well as the update interval. it will not exceed a certain bitrate nor a certain framerate, but a specification for one can limit the other, while generous limits on both with a video feed that doesn't change much can result in fewer frames and bits than the spec allows.
    – KeithS
    Jul 22, 2013 at 23:23
  • 2
    I watched "Mission Impossible 2" in a good digital theater. The action scenes near the end were GORGEOUSLY choreographed. Not long after that, I saw it, on DVD, with a good projector and a cheap DVD player. The action scenes were BUTCHERED, because the slow codecs SIMPLY COULD NOT KEEP UP with the highly-dynamic source video. For some applications, there is no substitute for bandwidth. Jul 23, 2013 at 2:30

Kind of? But bitrate may vary drastically between frames, so it is usually not meaningful to talk about size for individual frames.

The vast majority of video compression codecs depend on the content. The general process is

  1. Transform - Convert the data to a form that is more amiable for compression
  2. Quantization - Throw away data in some intelligent way.
  3. Compression - remove redundancies in the data.

For video this is typically done in blocks of multiple frames. Some (key) frames are independently encoded, so will be fairly large, while the vast majority will encode differences between the previous and/or next frame, so will be much smaller.

If you need to hit a specific size you can redo the quantization and compression steps with different parameters until you reached your size target. Or you can do a pre-processing pass to estimate the entropy, and use this information to select appropriate parameters for each step, and hope the result is not to far from expectations.

You can usually configure the encoder in different modes depending on your needs:

  1. Target a specific image quality and let the size vary with content?
  2. Target a total file size? - Useful if the movie needs to fit onto a disk.
  3. Target an average bitrate per block or time unit? Useful if the decoding device has limitations you need to fit within.

When latency is important, say for video conferencing, then the ability to use large blocks is severely reduced, and many simpler system just compress each frame individually.

For online video it is common to encode each block in multiple quality levels, and switch between them depending on the current network conditions.

Some applications, like textures for video games, need fast random access, so typically encodes a block of say 16x16 pixels to a fixed size. This is great for a random access perspective, but absolutely terrible in a quality/size perspective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.