38

Note bene: I realize this is an immensely complicated question with about a million levels of nuance that I'm trying to reduce to a single number...

I'm about to undertake a large video encoding project using H.264 encoding. We are trying to create multiple bitrate profiles in order to accommodate streaming across internet connections, processors, devices, etc.

Generally speaking, what kind of compression ratio should I be expecting to see (while staying within a reasonable level of quality)?

For example, a 640x360 (16:9) pixel video file @ 24 frames per second and 16-bit color should yield an uncompressed file that is approximately 33 MB/s.

I've been told that, for that file, 500 Kbits/second (or 62 KB/s) is not an unreasonable video bitrate. That seems insane - more than 530:1 compression? That's 99.8% compression. Is my math wrong?

I'm just looking for a rough outer guide for quality, like "more than 500x compression is crazy" or "less than 400x is a waste of bandwidth". I've looked everywhere, and nothing gives me any kind of expected compression...

Nuby
  • 2,378
  • 2
  • 21
  • 26
  • 4
    The upside of asking an obscure question? The tumbleweed badge. Awesome... – Nuby Feb 24 '11 at 03:02
  • 2
    I hope my answer is worthy enough to justify denying you the Tumbleweed badge ;) – Stu Thompson Mar 07 '11 at 13:20
  • 1
    »a 640x360 (16:9) pixel video file @ 24 frames per second and 16-bit color should yield an uncompressed file that is approximately 33 MB/s« - Just wondering how this is calculated … If I go 640 * 360 * 2 bytes (16 bit color) * 24, then it's 11059200, so 11 MB, not 33 MB. But then I don't really know whether that calculation is correct … chances are it isn't because I don't know much about video and so am likely to be missing something … just what? Asking because it would make the H.264 compression rate a bit less astonishing (but still great, of course). – Lumi Jan 06 '13 at 21:55
  • You're comparing two different things: A 48bit/px(16x3colors) stream and a YUV 420 8bit stream. H.264 (mostly) compress and decode 8bit YUV420. The H.264 encoder may pull down RGB444/YUV444 pixel into YUV420 before doing compression. You made people confused about how to calculate the RAW stream bitrate and compression ratio. The chosen answer is only suitable for your case practically. I hope you can remove the question. – Wilson Luniz Aug 08 '16 at 15:20

5 Answers5

72

In a quite interesting document called H.264 Primer, a simple formula is given as an hint to compute the `ideal' output file bitrate, based on the video's characteristics:

[image width] x [image height] x [framerate] x [motion rank] x 0.07 = [desired bitrate]

where the image width and height is expressed in pixels, and the motion rank is an integer between 1 and 4, 1 being low motion, 2 being medium motion, and 4 being high motion (motion being the amount of image data that is changing between frames, see the linked document for more information).

So for instance, if we take a 1280x720 video at 24 FPS, with medium motion (movie with slow camera movements, not many scene changes...), the expected ideal bitrate would be:

1280 x 720 x 24 x 2 x 0.07 = 3,096,576 bps => approximatively 3000 kbps

This is purely a hint, and in my opinion, the only way to accurately find the ideal bitrate is trial by error :)

SirDarius
  • 41,440
  • 8
  • 86
  • 100
  • 1
    Yes, but still. Awesome. If it gives a non-ridiculous starting point within a factor of 10 (times or divided) I'm doing so much better than before! Thanks. – david van brink Apr 03 '15 at 22:30
  • 2
    The key to this answer is the `0.07` in the equation. I created a calculator for this independently of this answer, and the constant my calculator came up with based on averaging a whole bunch of different calculators is `0.074`. This is your compression ratio. `1/0.07 ~= 1/0.074 ~= 13.5x - 14x compression`. (For MPEG-4, this constant is `0.114, or 8.77x compression`) – dberm22 May 13 '15 at 18:31
  • 1
    But what about the number of bits in a pixel? Let's say I have 3840x2160 YUV frames at 30 fps, where each pixel takes 12 bits. That's 3840*2160*12*30 = 3 billion bits / second almost. Using this formula I get 3840*2160*30*1.5(motion parameter)*0.07 = 26 million bits / s. That's a ration of 115:1. Isn't this unrealistic? – nirvanaswap Jun 13 '16 at 17:48
  • @nirvanaswap at 1.5 motion, I believe it's not unrealistic. It is still kind of a slow motion factor, and H.264 is extremely efficient in these scenarios. It can really depend, but if we are in the 2.5 / 3 range, a 50:1 ratio wouldn't be suprising.. – SirDarius Jun 14 '16 at 13:57
  • The link is broken – austinmarton Jan 26 '18 at 03:22
  • @austinmarton Just tried to fix it, but the page at Adobe links to a broken PDF link. Gonna try to find it on webarchive. – SirDarius Jan 26 '18 at 12:21
  • @SirDarius I ended up finding it eventually by searching for the pdf. Thanks for the answer! This was the closest I could find to an estimate of H264 frame size. I see you've added a view only link now but here's another copy in case anyone wants to download https://austinmarton.files.wordpress.com/2018/01/h264_primer.pdf – austinmarton Jan 28 '18 at 20:15
25

It will vary dramatically depending on the content of the source videos. I'll get to that in a bit.

640x360 is not that large. 512kbps is very reasonable and arguably standard. Maybe 768kbps if you are really interested in quality.

How is this possible? A simplified answer: There are a couple of techniques and facts about video compression that make this possible:

  1. Not every video frame data structure in an common H.264 (or other CODECs for that matter) is a full image. Instead there are two types which are colloquially referred to as
    1. Key Frames: a full rendering of the entire video image
    2. Intra-frames: a description of changes to the previous frame. These frames generally make up the vast majority (80%-99%) of frames in a video.
  2. H.264 is "lossy", as are many other CODECs. They do not reproduce a pixel-by-pixel, frame-by-frame exact duplicate of the original source video. Example: Lossy blocks: If all but one pixel in an area is the same color, the CODEC 'loses' the one pixel. So, instead of having to store information about every single pixel in a frame, the CODEC just says "x1, y1 to x2, y2 are all color x". Very efficient.

It is all wildly more complex than that, with zillions of different approaches, techniques and algorithms within specific CODECs and between CODECs to make this happen.

So, back to the "It will vary dramatically depending on the content of the source videos" comment: The compression ratio you'll see, and the resulting quality, will depend significantly upon:

  • the contents of the video
  • your tolerance for artifacts (blocks, loss of color, loss of definition)
  • the CODEC parameters you set, and how you set them

Example: A video of a door in a room (like a security camera) with one key frame every ten minutes is going to have an amazingly high compression ratio. My back-of-the-napkin calculations put that scenario at 15,000:1 compression.

Since you are starting on a large video encoding project, I would recommend a couple of things to determine what your compression ratio is going to be:

  • take a sample of the source videos you are going to encode. 100 or more being statistically relevant.
  • encode them at various bit rates, with various parameters, to determine what resulting characteristics meets your needs

Changing the parameters of the encoder to make the videos smaller can have other impacts too:

  • higher play back CPU requirements
  • player CODEC expectations. Not all H.264 encoded videos can be played back by all players
  • longer encoding times
  • various degrading of quality

It's a big complicated subject. Good luck. My experienced "thumb-to-the-wind" test says you'll be more than happy with 512-768kbps for your project.

SO_fix_the_vote_sorting_bug
  • 412
  • 1
  • 5
  • 14
Stu Thompson
  • 38,370
  • 19
  • 110
  • 156
  • Stu, thanks for the detailed response. I've been waiting for a while for some answers to this question. Really helpful to get a concise guide to what I should be researching further. It's amazing how efficient H.264 seems to be... – Nuby Mar 07 '11 at 14:39
10
Compression Ratio Rules of Thumb
Compression ratios to maintain excellent quality:
– 10:1 for general images using JPEG
– 30:1 for general video using H.263 and MPEG-2
– 50:1 for general video using H.264 / MPEG-4 AVC

from http://www.kanecomputing.co.uk/pdfs/compression_ratio_rules_of_thumb.pdf

Costa
  • 461
  • 7
  • 13
1

Don't forget normal playback MPEG will only use YUV 4:2:0. In 8-bit color depth each pixel only worth 16-bit(or 64bit each 4 pixels). Please, only RAW file from camera will use 16-bit depth, and it must worth millions USD!!Medium high Film DVR only can provide 12-14bit!!And nobody will use H.264 to store RAW. H.264 is deigned for end product.

In 640x360/24p YUV4:2:0 the bitrate will worth:

  640x360x24x(8+4+4)/8 = 10.5MB/s

For 500Kbps the compression will be only 172:1. It's normal

For expatiation of YUV4:2:0, read:
http://en.wikipedia.org/wiki/Chroma_subsampling

Wilson Luniz
  • 459
  • 2
  • 7
  • 18
0

Just sharing my knowledge over encoding with H264 environment

As for the ratio 450-512 kbits/second is best if you use H264 with High 5.0 or High 7.0. Well i can suggest you that to get a good ratio in balance with the best quality , the key that really matters to it is to play with the Resolution size. Result of Video Resoltion = 3/4 * Native's / Raw Video's Resolution

H264 tends to loose details more if you don't compress the frame into a little bit of smaller resolution.

laruffii
  • 440
  • 1
  • 4
  • 11