Mario Lombardo wrote:
>That won't work since I need to lug around discs with me. I just want
>to have files to click on, specifically compressed. It's the 21st
>century. I feel I should be able to do this. No more mucking around
>with toxic DVDs that I'll just throw away someday. More waste really.
>
>
MPEG2 files are already pretty well compressed. You _might_ get a small
compression with bzip2, but it would take forever and you would save
less than 5% of the original filesize (largely the repeating MPEG2
overhead involved in framing).
Compression is all about removing entropy. Entropy is about having
structure and order.
In a big file full of zeros, you can compress that almost entirely. This
file doesn't have much entropy.
In a big file full of nothing but pure random noise, you won't compress
it much if at all. This file has no entropy.
All compression is about minimizing repetition. This requires some
knowledge of the content being compressed. The more specific a
compression algorithm to a specific type of content, the better it will
compress said content, as it will inherently know what things are most
likely to repeat.
There are two kinds of compression. Lossless and lossy.
Lossless is like a ZIP file. It is meant to retain every precious bit in
the origional file). Executables won't run if the bits aren't exactly
the same after decompressing as they were before compressing.
Lossy is like a JPEG file. It is meant to look generally the same (to
the human eye) as the quality of said image is reduced to save space.
This is why you specify a quality between 0% and 100% when compressing a
JPEG file: to tell the compression algorithm how important the details
and quality are to you for storing a given image.
A movie is nothing more than a buch of photographs, taken at some
resolution and framerate.
Raw video files are typically stored as mjpeg (motion jpeg), with some
level of acceptable lossiness. In this format, all of the individual
frames of a movie are stored as individual compressed images. This makes
it fairly painless to "splice" together video snippets and do frame by
frame overlays and tricks on the fly. These files can be VERY large.
Motion video files, like MPEG2 as included on a DVD, have "keyframes"
every N number of frames (that are an entire refresh of the picture).
These keyframes and successive frames are broken down into smaller
squares and "delta" changes between them are recorded to the digital
stream. The idea is that a picture changes very little between
successive frames, and the deltas can minimize the redundant data
between frames.
Newer encodings like MPEG4 break the image down into even smaller
squares, and use even more advanced (also, slower) predictive algorithms
to minimize these repetitions even more.
So, where a MPEG2 file with 480i video for a 2 hour movie might take up
4G of disk space and is playable on any DVD player, a MPEG4 transcoded
version of that same digital movie might take up 1G of disk space but
you will need a fast PC to be able to play it back.
This is even more true when you step into the world of 720p or 1080i
video, where videos may commonly be 20G in size on a blueray or HDDVD
disc. The blueray/hddvd player has enough CPU to play it back largely
due to hardware assistance. While you can transcode such video into
I.264 video formats and save quite a bit of disk space (20G HD file
might get you a 4G I.264 file), you likewise need quite a bit of CPU or
hardware assistance to play back that transcoded file due to the
additional overhead of the algorithms involved.
That being said.. there's nothing wrong with losing quality in the
transcoding, you will generally get a viewable movie as a result, but
quite a bit of detail may be lost in your conversion.
If you think you are going to convert a 480i 4G DVD (MPEG2) to a 480i
740M VCD (MPEG2) without some kind of loss, you're kidding yourself.
The big tradeoff between MPEG2 and MPEG4 is horsepower. You need much
more CPU power to compress video to an MPEG4, as well as more CPU power
to decompress the video on the fly as you play it.
So, given these constraints, you can trade off quality or you can make
things harder to play back, but you always have to trade something off
to save the additional space.
A lossless compression algorithm simply doesn't buy you much.
Hope this helps.
- Ian C. Blenke <ian@blenke.com> http://ian.blenke.com
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:01:38 EDT