Optimize

roxylee wrote on 12/12/2008, 6:20 AM
I am transfering one of my VHS tapes to DVD. The VHS is 1 hour and 40 minutes. I transferred it in sony vegas pro, rendered it as MPEG2. When I open the mpg file in DAP 5.0, it says it is at 107% and too large for the single sided DVD I am using. When I choose optimize and "fit to disc", it has no effect and the error message says the project won't fit on one disc.

Is there a setting available to force the project size down to fit on disc? I am expecting some degradation of image by doing so, but the content is not critical to me and that would be acceptable. Also, at 107%, am I assuming correctly that it wouldn't take a lot of compression, as it is only 7% over the limit?

I am in windows XP, 2 GB ram, Athlon dual core, tons of hard drive space available. I've limited experience in both programs, transferring old home projects, usually under an hour a piece, but now I'm tackling some of the larger ones and I'm coming up against settings I haven't used before.

Thanks,
roxylee

Comments

TOG62 wrote on 12/12/2008, 6:34 AM
You need to set the properties of the video to allow recompression. In the Optimise dialogue select the clip, then Video and change Recompress to Yes.

Alternatively, you could just compile as it to disc and use DVD Shrink to reduce the size.

Mike
roxylee wrote on 12/12/2008, 7:01 AM
Thank you. It worked.

Your second suggestion I'm not familiar with. I do not use DVD Shrink. Is there a benefit to that method over the recompress in DAP?
roxylee
TOG62 wrote on 12/12/2008, 8:01 AM
Some say it gives slightly better quality, although I can't really vouch for that. It's usually quicker, though.

Mike
roxylee wrote on 12/12/2008, 8:52 AM
Thanks, I'll give it a try
roxylee
musicvid10 wrote on 12/12/2008, 9:14 AM
Roxy, You may not need to recompress the video at all. DVDA is very conservative in estimating disc space, and it may actually fit.

Open your project, but click "Prepare" instead of "Burn." Ignore the warning messages and prepare to a folder on your hard drive. When you are done, close DVDA, open it again, and "Burn" from the previously prepared folder. It will report a smaller size, hopefully one that will fit on the dvd disc. If you don't have to compress twice, it will save you time and result in better quality.
bStro wrote on 12/12/2008, 10:42 AM
I haven't used DVD Shrink often, but when I have, it was much quicker. So I can only guess it's doing something very different from what DVDA does when it recompresses a video. I think I read a description of what DVD Shrink actually does, but I can't remember what it was. Maybe it analyzes the video and only re-encodes certain parts, whereas DVD Architect re-encodes everything?

Rob
John_Cline wrote on 12/12/2008, 4:48 PM
Roxylee,

MPEG2 filesize is determined exclusively by bitrate. In order to fit a 1 hour 40 minute video on to a single-sided DVD, you would need to encode the video using the two-pass VBR setting in Vegas using 8,000,000 as the MAX value, 5,624,000 as the AVG value and 3,376,000 for the MIN value. This is assuming that you use 192Kbps .AC3 audio encoding. I'm pretty sure you used the default 6,000,000 value in the DVDA template in Vegas and that's why your video is a bit too big. It would be much better from a quality standpoint to have Vegas just encode the video again using the correct values rather than having DVDA "optimize" the disc. DVDA decodes and then re-encodes the video which seriously compromises the image quality.

DVDShrink doesn't do a full decode/encode cycle, The DVD Shrink transcode engine works by requantizing video data. Here is what the author of DVD Shrink had to say about how he's requantizing MPEG2 video to make it smaller:
--------------------------------------------
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.


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.
-------------------------

If your videos are under about 70 minutes, you can just encode using CBR (constant bit rate) at 8,000,000, if they're longer than about 70 minutes, you need to calculate the VBR values. You can use a bitrate calculator to figure out what bitrate you need to use to fit your video on a DVD based on the video's length. I have one hosted on my web site:

http://www.johncline.com/bitcalc110.zip