Compression Problems?

[gaitej]

Hi,

I am slightly confused - possibly because I don't fully understand the complexities of MPEGs - as to why VDR TVS constantly over-estimates (and consequently over-compresses) files.

For example:

I put two files of similar type into the DVD Creator; the files were 0.35GB combined, the creator estimated the output (everything unchanged) to be 0.65GB and the result was a DVD of 349MB.

I then changed the aspect of one of the files from 16:9 to 4:3 (by using the Save As option) and then re-ran the DVD Creator. Again, the combined input file length was 0.35GB but this time VRD TVS estimated the output to be 1.86GB (recoding was required for 'Force Aspect Change' and 'Output to 9.80Mbps' - from 9.608) and created a DVD of length 0.99GB.

I understand that all files on the DVD must have the same settings - hence the 'Force Aspect Change' - and also that, by creating a border around the 4:3 recording to allow it to become 16:9 without distorting the image would increase the size of the file.

My main queries, however, are:

1. Both files had 9.549Mbps so why was a change required?
2. Why did said change require the first file (the one with 16:9 aspect ratio) to increase by 50% (the other file increased by roughly 400%)?
3. Why does VRD TVS vastly over-estimate the size of the created output?

My main reason for trying the above is that I tried creating a disk of eleven files totally about 4.2GB; the first ten (4.0GB) were accepted without any changes required; the last one, however, seemed to be the proverbial straw and, all of a sudden, the output was reduced to 2.83Mbps (from the original 9.549Mbps on ten files and 15Mbps on the other). Once the recode was completed, the resulting disk was only 4.07GB long and the file that was reduced from 15Mbps to 2.83 became a rather interesting pattern of different colour squares.

Is this a problem under review or is it not a problem but something I am doing wrong? For info, the properties of a typical file is listed below:


File Name: G:\Rugby Edits\World Cup 1999\1999GG Ireland vs Argentina.mpg
File Size: 181463044 ( 0.17 GB )
Program Duration: 00:10:38.17
File Type: PS - MPEG2
Encoding: MPEG 2
Video stream Id: xE0
Encoding Dimensions: 704 x 576
Display Size: 704 x 576
Aspect Ratio: 4/3
Frame Rate: 25.00 FPS
Bit Rate: 9.549 Mbps
VBV_Buffer: 224 KB
Profile: Main/Main
Progressive: Prog or Int
Chroma: 4:2:0
Audio Format: Layer 2
Audio Stream Id: xC0
Audio Bit Rate: 192 Kbps
Audio Sampling Rate: 48000 Hz

[Anole]

Please use the latest version (http://www.videoredo.net/msgBoard/showthread.php?t=5363).
See the release notes for what has been changed recently.

There have been numerous comments on the forum about the problem.
The company has responded with some work arounds.
They have also made a number of changes to the program, working toward a solution.

One clever suggestion, which may or may not work for you, was to author to a Video_TS folder as though you were going to make a double-sided disc.
If the resultant output is small enough to burn on your single-sided media, you are done.

[gaitej]

Anole,

Thanks for the reply. I am currently running the beta 544 build and these are the results I get. Cheers for the suggestion about burning to the 'double sided' disc - will give that a go and I look forward to any further improvements.

[DanR]

1. Both files had 9.549Mbps so why was a change required?
The bit rate from the mpeg header is not used any of the calculations. Its a maximum bit rate not and actual bit rate. VideoReDo reports the actual bit rate after it saves a file.

2. Why did said change require the first file (the one with 16:9 aspect ratio) to increase by 50% (the other file increased by roughly 400%)?The file probably had a low bit rate to start with. When we recoded we tried to recode at a higher bit rate. That would cause the size to increase.


3. Why does VRD TVS vastly over-estimate the size of the created output?
We will need more information to figure that out. What are the durations and sizes of the original source videos? One thing this version does do is add a 285 mb "fudge factor" to the estimate. The reason for the fudge factor is to account for menus and estimation errors as we don't pre-scan the file. It's obvious we need to a better job on estimating. There's no reason to add 200 mb if the original files are only 350 mb to begin with.

[gaitej]

Dan,

Thanks for the reply.

I now understand the workings better and am happy with the answers to 1. & 2.

As to 3. - Why VRD TVS over-estimates the size of the created output - I tried a simpler project with two other files (rather than the eleven in the orginal one which might get too complicated).

The first mpeg file (File 1) was 1.88Gb (1,975,126KB or 2,022,529,024 bytes) long;

The second mpeg file (File 2) was 2.38GB (2,497,324KB or 2,557,278,208 bytes) long.

When adding them to DVD Creator, the combined output without recoding was recorded as 4.86GB but when written to the VIDEO_TS folder, the output were actually 4.55GB (4,779,570KB or 4,893,179,904 bytes)

As the capacity of a DVD is only (in computer terms) 4.49GB (only ever referred to as 4.7GB by manufacturers who use the 1GB=1,000MB=1,000,00KB=1,000,000,000bytes) then VDR TVS was absolutely correct in determining that a project of 4.55GB would be too large for a single-sided DVD.

However, when I recoded the compilation at 2.16Mbps as suggested by DVD Creator, the resultant VIDEO_TS file was only 4.23GB (including menu)

(For information, the actual video bit rates of the two original files were 2.22 and 2.20 respectively.)

I know that 0.26GB isn't a huge amount when dealing with large files but, with smaller files it could be one, if not two, files that would force an unnecessary recode. Petty, maybe, but annoying nevertheless.

Another option open would be to combine all the small files into one (or more) large files separated with chapter marks but, again, this would invoke a long recode and, without the options of Chapter menus, a tedious search through the file to find the one you wanted. (Not such a good idea then!)

My apologies if this sounds a bit petty.

[DanR]

The 0.26GB is rougly equivalent to our "fudge factor" of 285 MB. We discuss it internally and come up with something more accurate.