ralck said:
Forgive me for being ignorant, but if you are compressing, how is it lossless? You say it's compressed, but all the data is still there?
Yes, all data is still there. Data compression works because data is redundant, so a long string of data can be expressed by a small string of data.
Indeed, we do it in our everyday language. Instead of
American Automobile Association, which is a string of 31 letters (including the blank spaces), we write down
AAA, a string of three letters. As long as we know what that short string stands for, we can recover the original string from it.
Computers work in similar ways. They use two types of compression. One, quite well known in our circles here, is the lossy compression used by JPEG images and MPEG movies or MP3 audio. All of these change the image (or sound) to something that the average person cannot tell apart from the original, which results in fewer actual values, so they can be expressed in less than 8 bits per byte and similar. But by changing the image, it has thrown away some information, so it is lossy.
The other, lossless, works like that AAA example, compressing redundant data into smaller chunks of data that exactly represent the original data, so decompressing the compressed data will give us the exact same data as we had before compression.
One such compression is GZIP, which is a general compression, i.e., compression used for any kind of data. When used on redundant data, it compresses well. When used on random data with no redundancy, it performs poorly and can actually increase the size of the data.
The codec I mentioned takes advantage of the fact that in motion pictures, there is a lot of repetition from one video frame to the other. For example, if you show a person walking, the only thing that changes is that person. But the background stays the same, or mostly the same.
So, if you just subtract the value of each pixel from the corresponding pixel in the previous frame, you'll end up with a lot of small numbers and much repetition, so instead of something like 10, 230, 75, 131, you may end up with 1, 0, 1, 1, assuming that the corresponding values in the last frame were 9, 230, 74, 130. And GZIP does a great job in compressing a series of small numbers. In the above example, you need 8 bits per value for the original set (10, 230, 75, 131), but only two bits per the differences (1, 0, 1, 1), so you only need one fourth of the storage.
It is somewhat more involved than that, but that is the gist of it: Yes, you can compress video (and audio) and then decompress it to the exact original if you are using a good algorithm that takes advantage of the common redundancies in video (and audio) data.