Calculate bitrate for 2 movies on one disc with equal quality?

[Beastie Boy]

I am trying to fit 2 DivX encodes on to one DVD-R. The 2 movies will obviously have different compressibility so it makes sense to allocate more disc space to the one that requires it. My question is how to calculate this.
I'm using Gordian Knot to do a Comp. Check with a target size of 2380MB (approx. half of one DVD) as a guide. As an example, the results from two seperate movies were 63% and 91%. The 63% one should obviously be allocated a higher proportion of the disc space, but how much? Or is there a better way to determine this?

The aim is to try and achieve similar Comp Check percentages which should give similar quality.

Any advice appreciated.

Cheers, Beastie.

Edit: I forgot to mention that these movies are encoded at full frame and so file size is the variable factor and not frame size.

[manono]

Hi-

Raise the file size of one and lower the file size of the other by an equal amount, and keep doing that until the percentages for both are similar. I do it all the time when trying to fit multiple episodes, or multiple short films onto 1 CD with equal quality.

[Beastie Boy]

Thanks manono, I don't know why I didn't think of that. I guess I thought there would be some clever formula that would give me the necessary figures.
Sometimes the easiest solutions are the best :D

Cheers, Beastie.

[manono]

Hi-

You know BB, I bet there is a formula for that; a short and easy equation to solve that'll give you the answer you want. This gets trickier when you want, for example, to fit 4 anime episodes on a CD with equal quality, or 3 Laurel And Hardy shorts on a CD. Maybe some of the geniuses around here can figure it out. :) But until then, jiggling the file sizes until the percentages match up will work.

[b00zed]

This is an extension upon what you suggested, I'd make use of the compressibility values that GKnot gives you.

Say you have three eps, let their compressibilities be a, b and c.

A file with higher bits/(pixel*frame) compressibility value should be allowed a greater file size. I would start by giving each file a size in proportion to its compressibility value. Each file would get CD*x/(a+b+c) worth of space.

Let a = 0.2, b = 0.5 and c = 0.66, and CD = 700MB
file a gets 700*0.2/(0.2+0.5+0.66) = 103MB
file b gets 700*0.5/(0.2+0.5+0.66) = 257MB
file c gets 700*0.66/(0.2+0.5+0.66) = 340MB
103 + 257 + 340 = 700MB

The result of this being that each file gets enough bits to all have the same quality as estimated by GKnot from the compressibility and bitrate at the same resolution and frame rate.

That's where I'd start, using 15% of the file for the compressibility check is a good idea anyway but especially so in this case if you want everything to be equal etc. etc. etc. Factoring audio into this will make it a little more interesting :) (but I suppose you can just knock the audio bitrate + overhead off the file before you encode it...)

[Beastie Boy]

b00zed, your calculation looks like a good theory to distribute the bits. I can't figure out how to use it in practice with the parameters suggested.
The Bits/(pixel*frame) value doesn't indicate compressibility but is simply derived from movie length, frame size and bit-rate. In this case the first two are fixed and we wish to calculate the latter.

As an example, lets suppose that all 3 clips have equal duration. If we do a comp check with a target file size of (700/3)MB, then the bits/(pixel*frame) value will be the same for each, but the clips could have very different compressibility. Hence the percentage figures would vary.

As I've written this, I though of something based on your idea. Let's suppose the results of the 3 comp check gave percentages of
a=69%, b=80%, c=90%.

If we put these figures into your formula it gives us the inverse of what we want, ie, the most compressible clip has the most disc space.

So if we invert the figures to a=100-69=31, b=100-80=20, c=100-90=10 and then use your formula we get;

file a gets 700*31/(31+20+10) = 356MB
file b gets 700*20/(31+20+10) = 230MB
file c gets 700*10/(31+20+10) = 114MB

Total = 700MB.

I've no idea if this works, I shall give it a go when I'm home.
Any thoughts?

Cheers, Beastie.

EDIT: This looks a little suspect as movie 'a' has 3 times as much disc space as movie 'c'. Ah well. :confused:

[manono]

I think you're on the right track, b00zed, but the numbers are off. Just to take the figures for c:

700*0.66(0.2+0.5+0.66)=700*0.66(1.33)=700*.8976=628.32 MB (unless I screwed something up)

And you're right that the audio file size and overhead throws a bit of a monkey wrench into it.

And I agree with Beastie Boy-you need the percentages in there, and not b/pf.

Beastie Boy's closer, but also saw that something's wrong. I'll try and take a crack at it later. Kinda busy now. Maybe you guys will solve it first.

[b00zed]

I made a bit of a mess there, and will correct the original post. I said "CD*x/(a+b+c)" but the individual equations were expressed as "CD*x(a+b+c)," however the calvulated values were based on the correct form of the equation. This equation is the standard way to distribute a certain amount of something based on a bunch of fractions (a, b and c) of the total group (a+b+c), if you let CD = 100 then you'll get the percentage for each fraction:
0.2+0.5+0.66 = 1.36
100*0.2/1.36 = 14.7
100*0.5/1.36 = 36.8
100*0.66/1.36 = 48.5
14.7+36.8+48.5 = 100
ie all this does is indicate what weightings each of the files deserves based upon its compressibility, a higher value deserves more bits since it needs more information.

BB I was talking about the compressibility result that GKnot gives you after a compressibility test, which is also in bits/(pixel*frame). The percentage is based on what fraction the actual value of the output file will be of the compressibility test.

My point was that a movie with a higher value from the compressibility check (higher value = lower compressibility, which clearly leads to confusion) work out how to explain it with respect to the estimated quality but they should all be the same quality if you maintain frame rate and resolution, since each file is getting a size proportional to its compressibility b/(p*f)value.

[Beastie Boy]

B00zed, I see what you mean regarding b/pf. I'm at work at the moment and so cannot test the theory.

Just to confuse things, I've had another thought based on averages.

Take 3 clips and do a comp check at 1/3 of total disc space for each. Average the percentage vaues giving eg. (69+75+90)/3=78.

Now add or subtract a proportion for how much above or below the average each 1 is.

File a:78-69=9. Total disc space =(700/3)+9%=254MB
File b:78-75=3. Total disc space =(700/3)+3%=240MB
File c:78-90=-12. Total disc space =(700/3)-12%=206MB

Total 700MB.

This looks close. :)

Cheers, Beastie.

[b00zed]

I'm going to have a go at comparing the two ideas.

Assume they're all being allowed the same file size, frame count and resolution, thus they should all have the same final b/pf, which for the purposes of working this out is fairly arbitrary; let's give it a value of 1.0b/pf for ease of calculation. The b/pf values would then be:
90% gives 1/0.9 = 1.111b/pf (ie the final 1.0b/pf is 90% of the original 1.111b/pf)
75% gives 1/0.75 = 1.333
69% gives 1/0.69 = 1.449
1.111+1.333+1.449 = 3.894
90%: 700MB*1.111/3.894 = 199.7MB
75%: 700MB*1.333/3.894 = 239.6MB
69%: 700MB*1.449/3.894 = 260.5MB
199.7+239.6+260.5 = 699.8... close enough :D

Very similar results, not likely to be rounding errors either. This is not a formal proof but it at least demonstrates a similarity, now I'm left wondering why there's a subtle difference heh...

Unless someone can come up with something completely different, I'm not willing to suggest that either method is any less valid.

Upon doing a few other calculations... using some large range values
10% or 10b/pf
50% or 2b/pf
90% of 1.11b/pf
% avg = 50%
b/pf total = 13.11b/pf
10% = 1.4*700/3 = 327 or 700*10/13.11 = 533.9
50% = 1.0*700/3 = 233 or 700*2/13.11 = 106.8
90% = 0.6*700/3 = 140 or 700*1.11/13.11 = 59.27

Now 59.27*9 = 533.43, which makes some sense, why give the 10% job only 2.3x as much room as the 90% job when it needs much more? The thing is that 50% is not 1.4*10% (it's 5*10%, and 5*106.8 = 534,) so adding 40% to the value of 700/3 (hence the 1.4*700/3) doesn't increase it enough. Multiplying the 10% value (say it's a 10b/pf requirement and only being given 1b/pf to work with) by 1.4 would result in 1.4b/pf... which is 14%. I don't think that's what you want to do. I only wish I could make this all less confusing :/

[manono]

Hi-

Upon doing a few other calculations... using some large range values
.
.
.
I don't think that's what you want to do.

No, Averaging the percentages doesn't work, and the greater the differences between the compress test percentages, the further off the results will be, as you just proved. I'll give you a real world example from a series I was working on earlier today. I'm putting 3 short films on a CD. I set the file size for each at 233 MB, and here's what I get:1). 88.6% or 0.315 of 0.336
2). 46.9% or 0.334 of 0.711
3). 83.5% or 0.357 of 0.428Averaging the percentages gives me 73%, but my earlier suggested method of adjusting the file sizes until the percentages match up (which I know is correct) gives around 67.5%. In addition, the final results, as given for XviD using DebugView and Moonwalker's XviD Analyzer confirm that.

But this example also demonstrates why using b/pf alone won't work. The first numbers (0.315, 0.334, and 0.357) are the b/pf's of the 3 videos. But those numbers give you no idea of the compressibility of the 3 short films. The second one is very old, very noisy, and very difficult to compress when compared to the other two (they're 2 reeler silent films, each around 20 minutes long, give or take). The number 0.711 proves that, although you can just look at the video to tell. There's just not very much correlation between b/pf and compressibility. No, I'm afraid this may be more difficult than I first thought.

[Beastie Boy]

I think perhaps B00zed may be correct with his first post. The figure that he was using was the last one in your example ie.0.336, 0.711, 0.428, which does give an indication of compressibility. You stated that clip 2 was very noisy and this has a figure much higher than the other two.

What were the final file sizes based on this example. This could tell us whether the method works. Using B00zed's method we get:

1) 699*0.336/(0.336+0.711+0.428)=159.23MB
2) 699*0.711/(0.336+0.711+0.428)=336.94MB
3) 699*0.428/(0.336+0.711+0.428)=202.83MB

Total 699MB

Does this come close to the actual sizes used?

Cheers, Beastie.

[TheWEF]

easy solution:

add both movies in one avs -> encode for one dvd -> split in two.

maybe you should add a single white frame in between to make sure you get keyframes at the splitpoint.

(this is possible because you are using the same framesize for both movies)

wef.

[DDogg]

Howdy brother TWef :)

While frankly out of my area of expertise, I'll hazard a comment here. The only way I ever figured out how to do this easily (relatively) is via percentage sampling using a quantizer based encoding method. It, by its nature, takes in all the elements of length of source, aspect ratio, compressibility, sizing and actually tells you the quality you will achieve before the encode is actually started.

Now I am speaking of mpeg2 and whether there is a corollary in mpeg4, I don't really know. I did a self-learning exercise on this topic in the cce forum (fitting multiple encodes on one disk and achieving the same quality in all - two posts). It is very longwinded, but it might provide some information that might be helpful. Frankly I think it is long past the time the mpeg2 and mpeg4 groups should have done some cross fertilization on ideas and techniques.
http://forum.doom9.org/showthread.php?s=&threadid=59850

Hope nobody minds me sticking my beak in. :)

1> "Final Dstination" --- D2SRoBa_Q32.mpv = 8,196KB, Len -- 133341 frames Time 1:32:41 Target mpv size:-(1043 kbps)
2> "The Usual Sspxts" - D2SRoBa_Q32.mpv = 10,380KB, Len - 148070 frames Time 1:42:55 Target mpv size:-(926 kbps)
3> "The Mtrix" -------- D2SRoBa_Q32.mpv = 8,388KB, Len --- 186356 frames Time 2:09:32 Target mpv size:-(709 kbps)

So in a natural way, Length, Aspect Ratio, and Compression characteristics are all taken into account. Note how #3 compresses to the approximate size of #1 even though it is nearly 40 minutes longer. Here the the encodes of #1 and #3 would be of similar quality even though the bitrate to fill one SVCD on #3 is completely down in the weeds. So bitrate is not the primary judge of quality...Compressibility is, measured in this case by the level of Q that can be "held" within a certain level of bitrate.

[piscator]

I think the solution is easier than you think. You only have to take into account that the compressibility percentage is directly proportional to the estimated video size. You really should take off the sizes estimated for audio, because they still take a huge part of the total file size that cannot be ignored as a marginal error.

Let's start simple.
- You want a total size of 700 MB.
- Your estimated video size is e.g. 560 MB.
- Your comp. percentage is 50%.

What should be your total size for comp. percentage 100%?
1.0/0.50 * 560 + (700-560) = 1260MB
Note that (700-560) indicates the part you want to reserve for audio/subtitles and other files you deem interesting.

What should be your total size for comp. percentage 80%?
0.80/0.50 * 560 + (700-560) = 1036MB

-----------------------------------------------------------------
Now let's expand this knowledge to your case.
1) Determine your maximum (estimated) video size for all the movies you want to put on a single CD/DVD. So subtract all the estimated audio sizes from your total CD/DVD size. Let's call this constant 'maxsize'.
2) Get the compressability percentages and the estimated video sizes from the tests you did. Consider 2 movies. This gets you 4 other constants: v1,c1,v2,c2. (v=video size, c=comp. percentage).

If you want to calculate the maximum video size q1 for movie 1 (100% comp. percentage) you get the following formula (1), and rewriting results in (2)
(1) 1.0/c1 * q1 = v1
(2) q1 = v1/c1

We need the constant in (2) to determine an equal comp. percentage for all the movies (in your case 2 movies). Let's call this new comp. percentage cnew. This leads to formula (3) and rewriting in (4) and (5).

(3) cnew * (v1/c1) + cnew * (v2/c2) = maxsize
(4) cnew * (v1/c1 + v2/c2) = maxsize
(5) cnew = maxsize / (v1/c1 + v2/c2)
Note that maxsize is of course v1+v2.

Now computation of the new video sizes is easy:
new video size1 = cnew * v1/c1 = cnew/c1 * v1
new video size2 = cnew * v2/c2 = cnew/c2 * v2

-----------------------------------------------------------------
Let's practice this in your case. Of course, you have to fill in your own estimated video sizes, since you didn't give them

Assume maxsize = 4000MB (after audio extracted)
c1=0.63 assume v1=2000 (remainder 380MB)
c2=0.91 assume v2=2000 (remainder 380MB)

Now:
cnew = 4000 / (2000/0.63 + 2000/0.91) = 0.7445

Now:
new video size1 = 0.7445/0.63 * 2000 = 2364MB
new video size2 = 0.7445/0.91 * 2000 = 1636MB

And after adding your remainders of 380MB, you get exactly what you want. Unless, of course, I can't count :-)

greetz,
Piscator

[manono]

Hi-

Yeah, rereading his later posts shows he was using the second number. Sorry for doubting you, b00zed.

The figures you came up with by using the second number (I don't know what it's called) are ballpark figures. But as before, audio and overhead aren't figured in. When doing it by adjusting file sizes and percentages, I switched to 701 MB total and came up with:
1). 180 MB
2). 331 MB
3). 190 MB
Those are the final file sizes of the 3 videos.

The problem with using just the second number is that it assumes an equal frame count among the episodes. You can take that into account, and allow for the audio and overhead and it just gets more and more complicated.

While I was writing, TheWEF used Alexander's sword to cut the Gordian Knot again. Using his method, I think, you add together all the audio file sizes and overheads and enter them into the appropriate boxes, and then set the total file size. Then you do something like this (I think-Wilbert or TheWEF, is this right?):

LoadPlugin("C:\Path\To\Mpeg2Dec3.dll")
A=Mpeg2Source("C:\Path\To\movie1.d2v")
B=Mpeg2Source("C:\Path\To\movie2.d2v")
A+B

Or if adding together 2 .avis, as Beastie Boy is:

A=AviSource("C:\Path\To\movie1.avi")
B=AviSource("C:\Path\To\movie2.avi")
A+B

And as he suggested, you might have a problem with a keyframe not being set at the right place at the end of the first movie. But how in the heck do you add one white frame easily? I think if using XviD or DivX 3.11, you can open the stats file after the first pass and add a new keyframe at the right place, but with DivX5.x, I have no idea.

And you can stick your knowledgeable beak in whenever you want, DDogg. :)

Edit Later: Maybe piscator has the answer. I hope so. Looks good piscator.

[TheWEF]

hi guys!

Originally posted by manono
But how in the heck do you add one white frame easily?

K=BlankClip(length=1, width=720, height=576, fps=25, color=$FFFFFF)

A+K+B

gives you a ~4 hour movie, two-pass encoding will guarantee constant quality throughout the movie, later you split it at the white keyframe.

you could also reencode the keyframeinterval that overlaps the splitpoint to get 100% correct duration for the second movie (might be hard to find...), otherwise (if you have to use the white frame as the startframe) you have to set an audio delay of 1/25 sec for the second movie when muxing.

(adust numbers for ntsc)

wef.

[manono]

Thanks, TheWEF-

K=BlankClip(length=1, width=720, height=576, fps=25, color=$FFFFFF)

So you make yourself a 1 frame white .avi at the same resolution (and colorspace-maybe add ConvertToYV12() when making it) to insert between the 2 movies.

[Beastie Boy]

From your final file sizes manano, it looks as though B00zer's method was pretty close.

piscator, excellent post. I think that could be it. I just need to read it a couple of times to get my head around it :D

theWEF, your method is of course foolproof. The problem I have though is that my encodes are straight from DVD with no resizing and just the black bars trimmed. Hence the 2 movies could have (and probably will have) different frame sizes. EDIT: I realise that I may have misled you with my original post. The term 'full frame' was perhaps not a good choice.

Thanks to you all for your input.

Cheers, Beastie.

[b00zed]

I made a small comment about the audio bitrates etc. in there somewhere piscator. After TheWEF's suggestion I'm forced to concede that I overcomplicated things a bit (or a lot...) Letting the codec do the bit distribution for you seems obvious to me now... :)

[piscator]

@b00zed.
Fair enough, you mentioned the audio. But I think there was a bigger problem as well. You really have to compute the 'average' comp. percentage for all the parts before you can compute the target sizes of each part.

If you look at the results beasty boy computed...

1) 699*0.336/(0.336+0.711+0.428)=159.23MB
2) 699*0.711/(0.336+0.711+0.428)=336.94MB
3) 699*0.428/(0.336+0.711+0.428)=202.83MB

...then the comp. percentages for the parts are
1) 159/233 * 0,886 = 60%
2) 337/233 * 0,469 = 67%
3) 203/233 * 0,835 = 72%

Anyway, I used manono's method with juggling sizes in GKnot too. So this discussion made me decide to do it a bit smarter in future. I was too lazy to think about automating it before :)
Using the formula's of yesterday, I made an excel-file which will compute the equal quality results for a multiple of movies.
I put it for download on:
http://home.hetnet.nl/~piscator/EqQualCalc_031001.xls
All you have to do is fill in the green parts:
* Target Size
* And for eacy part: Video Size, Total Size, Compressabilty Percentage.

When I used it on the results manono got:

The figures you came up with by using the second number (I don't know what it's called) are ballpark figures. But as before, audio and overhead aren't figured in. When doing it by adjusting file sizes and percentages, I switched to 701 MB total and came up with:
1). 180 MB
2). 331 MB
3). 190 MB
Those are the final file sizes of the 3 videos.


It calculates
1) 177.5 MB
2) 335.2 MB
3) 188.3 MB
And the average comp. percentage is 67.5%

Of course, it's a bit off because the audio is ignored.

greetz,
Piscator

[manono]

Hi-

Well, I have the audio figures. I followed your written instructions (no Excel on this computer) and got this:

1) 180.12
2) 331.38
3) 189.51

Total=701.01. A perfect calculation. I'm dumbfounded. Excellent work, piscator. Now I have to install Excel, as I put short films and episodes on CDs all the time. Any of you anime encoders out there, sticking 3 or 4 episodes on a CD, should jump on this.

[Beastie Boy]

Excellent work piscator. manano's test confirms your method works. Thanks very much for the spreadsheet.

Cheers, Beastie.

[Joe_Bloggs]

Why not cache your movies on hard disk and pick the movies that best fit the long term storage media of your choice. You don't have to watch the other movies that occupy the disk even though they are just a mouse click away and don't follow a theme or genre of particular interest at the time.
I advise users of compression technology not to skimp on the bitrate as larger screen sizes are becomming cheaper and storage technology such as DVD-+R and Hard disks drop in price.

I stopped using 700Mb disks 2 years ago and switched to 800+ (827Mb)
and have finally switched to DVD+-R with the NEC-1300. It loves EasyCD so if you have got it allready then buy OEM.