Re: [SLUG] preserving a full DVD w/ compression

From: Mario Lombardo (mario@alienscience.com)
Date: Tue Sep 04 2007 - 19:23:12 EDT


On 9/4/07, Ian C. Blenke <icblenke@nks.net> wrote:
> 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
>
>
> -----------------------------------------------------------------------

I guess the correct term I should have used is transcoding a DVD. I
don't care for compression since, as you pointed out, MPEG2 is already
compressed. It would be pointless for me to bzip2 an ISO only to
extract what I might want to watch. I can't imagine much gain
(anybody try?), and the decompression time would only annoy me as I
wait.

What I was looking for was transcoding a DVD into a better, another
more-compressed and lossy format, like MPEG4 or H.264 (not sure what
I.264 is). I'm OK sparing the extra CPU cycles for the decoder since,
while watching a movie, I'm not doing anything else. It seems the
menu preservation is something altogether different :(

/mario
-----------------------------------------------------------------------
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:02:32 EDT