DVD Shrink compression method question

[SCDVD]

I saw a posting a couple of years ago that described the method that DVD Shrink uses to reduce the video size but I can't seem to find it. Can someone describe the process that Shrink uses? I know it isn't a normal re encoding process but I'm curious what Shrink does.

[Soopafresh]

Are you thinking of "compressed domain transcoding" found in apps like Rejig ?

Requantiser ?

[fritzi93]

From a Doom9 thread on transcoding:



Post by dvdshrink June 17, 2004

...To put the problem in perspective, I will describe the DVD Shrink compression algorithm (this turned out to be a very long explanation, my apologies to those already familiar with MPEG video).

Requantizing

The DVD Shrink transcode engine works by requantizing video data.

There are two kinds of data in an MPEG video stream:
1. Motion vectors
2. Pixel "residual" data (in the form of DCT coefficients)

Each decoded picture is formed by combining parts of previous decoded pictures (using the motion vectors) with new pixel information (residual data).

The basic idea is, that since each decoded picture is very similar to the previous, it can be fairly accurately described using pixels from the previously decoded picture, offset by some motion vectors to compensate for camera movement, or movement of objects in the scene.

The purpose of residual data is then to compensate for any errors in this process, since you are unlikely to get an exact match for the new picture using only the previous picture + motion vectors.

DVD Shrink achieves compression by removing some of the residual data. This process is called requantization. Selected DCT coefficients are scaled down (thus reducing the number of bits required to store them) and a corresponding scale value for these coefficients (quantizer scale) is scaled up. The result is a less accurate description of the same residual data, which takes up less space. Note motion vectors are left unmodified by this process.

With the exception of CCE encoder based applications (which do a full re-encode of the video and recompute all motion vectors), all DVD compression softwares are using this same requantizion algorithm. The difference between alternative software is, how they choose which residual data to requantize, and how they handle the subsequent errors or artifacts which occur in the video as a result of this process.

If you requantize all the residual data (DVD Shrink at maximum compression) then the resulting video will look bad - it will contain noticable artifacts. If you have some compression % to play with (e.g. maximum compression is not required), then the compression software has a choice of which residual data to process. This choice can heavily influence quality. The goal is to select the residual data to compress which minimizes the resulting errors or artifacts.

Picture Types

When choosing residual data, it is important to consider that there are three types of picture in an MPEG stream. They are called I, P and B-pictures. A typical DVD video contains pictures in the following sequence:

I-B-B-P-B-B-P-B-B-P-B-B-P-B-B-I-B-B-P-B-B.... and so on.

I pictures
These contain residual data only. There are no motion vectors, so they do not depend on (or "reference") any previously decoded pictures. Essentially, they are like standalone JPEG images. They occur at a rate of 1 in every 15 pictures (also they occur at the point of a scene change).

P pictures
These contain both motion vectors and residual data. The motion vectors always reference the previously decoded I or P picture. This is important, because it means that any error resulting from compression of the previous I or P picture will also be visible in this picture, and furthermore, if an additional error is introduced by compression of this picture, then the error will accumulate and artifacts will become more noticable. Note the accumulated error will also be visible in the next picture which references this picture, so things can get out of hand rather quickly. P-pictures occur 1 in every 3 pictures.

B pictures
Like P pictures, these also contain both motion vectors and residual data. The motion vectors always reference the last two decoded I or P pictures (data from two pictures is averaged). The important characteristic of b-pictures is, no picture will ever reference this b-picture (only I or P pictures are referenced), which means that any error introduced by compression of this picture will just be a one-off occurrence, visible in this picture, but not accumulated or carried forward into any other. Note also that B-pictures form the vast majority, occuring 2 in every 3 pictures.

If you are still following this, then you'll probably have figured out that when choosing residual data to compress, it makes sense to first select the data in b-pictures. This is because (a) they form the bulk of all pictures, and (b) any artifacts introduced by this compression will not be visible in any other picture.

This is what DVD Shrink does. If the resulting video size after compressing all b-pictures is still too large, then it will try to distribute the remaining compression over the remaining I and P pictures, and this is when artifacts start to become really noticable, because errors introduced into I and P pictures will be visible and compounded in all following pictures (until the next I-picture). Note that at low compression ratios, DVD Shrink will never need to touch I and P pictures. The exact % compression where this becomes necessary depends largely on the DVD, or more accurately, on the video encoder software used to encode it.

Problems with this approach

The first problem is that by applying maximum compression to b-pictures, although the resulting errors are not accumulated in any other picture, they are still heavily present in the b-picture itself. The resulting stream is:

I picture (original)
B picture (visible artifacts)
B picture (visible artifacts)
P picture (original)
B picture (visible artifacts)
etc...

The second problem is as mentioned before, when it becomes necessary to compress I and P pictures, errors are then accumulated from one picture to the next:

I picture (visible artifacts)
B picture (visible artifacts x2)
B picture (visible artifacts x2)
P picture (visible artifacts x2)
B picture (visible artifacts x3)
etc...

The problem is lessened somewhat because errors tend to be random in nature, so positive and negative pixel errors often cancel each other out when accumulated: however this is not always the case, and depends very much on the scene.



Full Thread here:

http://forum.doom9.org/showthread.php?&threadid=63587

[tinker]

Fritzi93, thank you for the web site. I was looking for this one for a long time. Seen that before, but lost it and could not find it after.

[fritzi93]

You know, follow the argument to its remorseless conclusion, and perhaps it's possible in some few instances where transcoding may be better than re-encoding. Not just visually indistinguishable, but objectively better.

Stipulate the obvious: MPEG2 is lossy, any re-encode degrades quality.

Say you have a DVD that has very little motion (a drama, say), adequate bitrate, and the compression required is only a percentage point or so. Low motion means less motion vector data needed, excess pixel (residual) data, and lots of B-frames. Would a transcode with DVDShrink (which is biased towards B-frames, mind you), actually be better than a re-encode in that case? I suspect it *might*.

[SCDVD]

You know, follow the argument to its remorseless conclusion, and perhaps it's possible in some few instances where transcoding may be better than re-encoding. Not just visually indistinguishable, but objectively better.

Stipulate the obvious: MPEG2 is lossy, any re-encode degrades quality.

Say you have a DVD that has very little motion (a drama, say), adequate bitrate, and the compression required is only a percentage point or so. Low motion means less motion vector data needed, excess pixel (residual) data, and lots of B-frames. Would a transcode with DVDShrink (which is biased towards B-frames, mind you), actually be better than a re-encode in that case? I suspect it *might*.

My experience is that this is true as long as the MPEG isn't compressed too much. If the degree of compression only removes redundant pixels in B Frames the quality loss is virtually undetectable. If the degree of compression goes beyond the redundant B Frame pixels, video quality obviously is impacted. There aren't any hard and fast numbers for this. It depends on the specific video. The more motion it contains for example, the fewer the redundant B Frame pixels. It isn't just subject motion in the video; camera motion can be an even bigger contribution to motion vectors. For example a tripod shot of a "talking head" has low motion vectors but a hand held shot of the same talking head will have more motion vectors caused by the unsteady camera movement.