# How can 1080p films be so disproportionally lightweight?

I calculated that for a film of 2 hours with 30 fps, over a 1920*1080 (16:9) display with 32 bps (True Colour) had to weight : `2×3600×30×1920×1080×4 Bytes` which is `1,7915904×10¹²` so `1,8 TB`...

Is there something I didn't get right? Or is it that uncompressed, I could not have more than 1 film stored on my computer to watch on my very standard `1920*1200` Display? Are the films that are shot and projected in 1080p really that size?

And my question is : if so how are Blu-Rays compressed into a measly 25-100 GB disk? I thought DVDs and such were lossless encodings and even if not how can we lose 95%+ of the information (100GB/2TB) and be ok watching it?

• Your basic idea is correct but uncompressed 'true color' doesn't require 32 bits per pixel, just 8 bits for each of BGR. Having an alpha or transparency layer doesn't add to the color depth. Still, the point remains that the work done by modern compression algos is impressive. – Jim Mack May 11 '13 at 14:08
• I figured since it's 24 bits already they used 32 bits cause the 4th byte was useful for whatever anyway. At any rate (pun definitely intended), there could be 24 fps and 24 bbp it would not only halve that 1,8TB, but good point nonetheless – sinekonata May 11 '13 at 17:39
• You're right that using 32 bits has advantages for internal purposes. But for compression there's no advantage, and the bit depth remains the same. The other thing to consider is sample depth, which is 4:2:0 (or 4:1:1) in most compression schemes. BGR color is matrixed to YUV, and these are sampled at different rates -- one color sample for each luma sample. Any DCT compression is then applied to this subsampled video. – Jim Mack May 11 '13 at 18:36
• In movies most frames look more or less like the previous frame, and do not have edge sharp contrasts. These two facts are what movie encodings depend on. – Thorbjørn Ravn Andersen Jul 9 '14 at 16:42

DVD and Blu-Ray content makes massive use of lossy encoding.

An easy way to see for yourself is to find a dark scene in a film, and then pause it. If the only issue was a limited number of black levels, you would expect to see a stepped gradient curve from the darkest region to the lightest region. Of course, if true 24-bit color was being used, the "stepping" would be too subtle for your eye to see. But the video isn't even that good! You will most likely see large solid rectangles in the black part of the screen. This is the result of the compression algorithm "guessing" that a square is a good enough approximation, and everything within the square is close enough to the same color to just use one color.

This works well most of the time, but tends to fall apart in films that make extensive use of dramatic dark scenes.

Added from comments: Encoders "cheat" on everything they possibly can. If you can think of something new to "cheat" on that most people won't notice, you can make a lot of money licensing your codec in the video production world.

• Oh so encoding "cheats" even on colours? If so does that mean a normal video player like vlc will normally only use let's say 16 bits or less? – sinekonata May 11 '13 at 6:17
• Encoders "cheat" on everything they possibly can. VLC itself probably uses the full 24 or 32 bit colorspace, but the video being played will most likely only be using a small subset of that space at any given time. – ObscureRobot May 11 '13 at 18:56
• You're talking about banding. This happens because an area of solid color is easier to represent than a gradient, and the encoder thinks that'll be a good way to save bits to better represent details elsewhere. x264's AQ (adaptive quantization) helps with this, but getting x264 to spend more bits on smooth-looking areas instead of spending so many bits making high detail areas look better. It's nothing as simple as a codec reducing color depth. 10-bit h.264 does have fewer banding problems, though, partly because of having more choice of coefficients that will look the same, compress well – Peter Cordes Apr 12 '15 at 2:08

Your guess is correct. That would be fully uncompressed, true to its settings.

You're right, there's only so much data that disks can handle, so there's compression that does need to take place. We can't always notice it. That's why there's different formats (MOV, MP4, WMV). They all have their individual compression types. Compression, really, is just removing data that is deemed "unnecessary" and remove.

To put it in a perspective, here's an example:

You have a bag of air. It has Hydrogen and Oxygen in it. Let's say you want to keep the Oxygen, but get rid of the Hydrogen, because the Hydrogen is extra space (like extra lines in the binary code of files). When you compress it, and take out Hydrogen, you have a smaller bag, but you also still have Oxygen. The more you want that bag to be smaller, the more Oxygen you'll have to take out. Therefore, there will still be Oxygen there, it's just not as good.

• I understand the concept of lossy encoding but to think that 95%+ is lost data is quite amazing to me. Also how about the theatres? Do they use 2TB films or do they also encode the raw film before distribution? – sinekonata May 11 '13 at 6:20
• @sinekonata most video cameras - even the ones used by Hollywood - already record using lossy formats, so outputting to raw video would give no benefit. You can see the standards listed for digital cinema on Wikipedia - tl;dr they use (lossy) Motion JPEG2000 with a maximum bit rate of 250 Mbit/s. – evilsoup May 12 '13 at 9:54
• @sinekonata it is not lost data, it is redundant data. If you have a sorted dictionary in a file - one word pr line - each word usually share one or more of the first letters. For instance "house" and "housing" share "hous", so if "housing" was written as "+4ing" instead you have saved two characters by encoding four characters as two. – Thorbjørn Ravn Andersen Jul 9 '14 at 16:46

For distribution to theaters, typically the files are several hundred gigabytes to a terrabyte per film (depending on the quality level that they choose to distribute). Even for cinema, some compression is generally used though the quality is still higher than bluray. Even if they choose lossless, compression can still probably cut it down by a significant margin in most cases, the file sizes for lossless 24bit HD is still very high though and it gets even worse when moving to 4K.

For distribution on DVD and Bluray, very heavy compression is used. Over-simplified a little, they use a technique that involves storing "keyframes" of the video and then storing information only about what changed from the last key-frame that was seen. Since video, by nature, has a lot of similarities between one frame and the next, this kind of compression scheme works exceptionally well with minimal quality loss despite the massive amounts of raw data being thrown away.

It does have some costs, such as making it harder to work with the file and making it so that generations of loss are a factor for editing, but for average consumer viewing, it is still plenty high quality to be very near the look and feel of the uncompressed original.

• I recenlty discovered that the open source codec FLAC is able to compress lossless files 30% of the original. So knowing that it gets much easier for me to understand how codecs can be so efficient. – sinekonata May 13 '13 at 17:50
• @Sinekonata - yeah, basically the general idea of compression is to look for patterns and store those patterns only once. Anything that regularly has patterns is easy to compress and both video and audio tend to have patterns to them if you describe them the right way. The difference between lossy and lossless is simply how close the pattern has to match. For lossless, the pattern has to match exactly, but for various degrees of lossy, the acceptible closeness of the pattern becomes more and more different. – AJ Henderson May 13 '13 at 18:09
• There are lossless video codecs. On non-grainy sources, lossless x264 can still take advantage of a LOT of the temporal redundancy (between frames), and just plain arithmetic coding. On the output of a slow deinterlace (of DV 4:2:0), I got a factor of almost 6 or so. (2.213 Bits/(Pixel*Frame) for 4:2:0. vs. 12 b/p/f for raw 4:2:0). This is LOSSLESS, i.e. can be decoded to the bit-exact source, checked with md5sum. – Peter Cordes Apr 12 '15 at 2:03
• But of course, as AJ says, lossy video can be visually transparent (you literally can't tell by flipping between them which is the source and which is the encode), while still saving lots more bitrate than that. – Peter Cordes Apr 12 '15 at 2:04