Whats the best way to predict filesize with DivX 5.0 ?

[ViRuZ]

Any tips? Im still using mpeg2avi ...

ViRuZ

[tripnotik]

If I were you, I would use... guess what? A bitrate calculator!!!

I don't see why some people on this board say that we need some new bitrate calculators for DivX 5. I mean, a bitrate is still a bitrate no matter if it's DivX 4 or 5. I just tested on an 8 minute clip of "The Fifth Element" (using b-frames), and it came out with 33.6 MB instead of the 33.4 MB it was supposed to be. So the size predictability is good I think.

[FactorM]

here my example:

i encoded a 101 minute movie with a bitrate of 1770 (suggested by gknot). i should get something about 1300MB (6060s*221kb/s=1307MB).

but the final movie has only about 1050MB, using only b-frames and none of the other mp4-tools.

so how do you explain this? btw there are topic's around this board discussing this problem already.

[MaTTeR]

As been said many times before..the current filesize prediction tools will not work with Divx 5. I think this has been established. Why? There are simply to many variables such as GMC, B Frames, Bi-Directional coding and of course quarter pixel. All of these will effect your final filesize somewhat depending on the source as well.

Sooo...looks like we have to wait for a true calculator which can take all the variables in to account. This isn't going to be an easy task IMO.

[Zarxrax]

I dont see whats so hard that the divx people couldnt make the codec come out to the specified size, even with these new features. I mean, the size prediction would still work the exact same way wouldnt it?

[ViRuZ]

Ah .. my fingers are quicker than my eyes. Sorry I`d have looked first. Well i never liked any of the bitrate calcs for divx4 (imho they all sucked) so i encode twice at least (1pass). First time to see how big the movie gets with 2000 kbit (quantizers and so on nearly untouched) and than adjust the kbit rate according to the file size the encode @ 2000kbit gave..

anyone knows a good standard bitrate for 1 cd rips ?

ViRuZ

PS thanx for your replys

[khp]

@MaTTeR:

There is no way a new calculator will solve anything.

Think about this, how much you gain by the new features, is heavily dependend on the source material, since a calculator has no knowledge of the source material there is no way it can guess the correct setting.

If there is a problem it MUST be addressed by the codec.
But I'am not sure there is a problem, so far we have only heard of some undersized files which may be caused by the video beeing saturated (all frames encoded using quantizer=2).

Please if u get an undersized video try encoded using quality based @100%. This way we can find out if there is a problem.

I have only done one test with 2-pass, which turned out very close to perfect (using GK's calculator).

[MaTTeR]

Originally posted by khp
@MaTTeR:
There is no way a new calculator will solve anything.

Think about this, how much you gain by the new features, is heavily dependend on the source material, since a calculator has no knowledge of the source material there is no way it can guess the correct setting.
Well I thought I pretty much was saying the same thing as you stated;)

[philippas]

Create your avs file with Gnot and select, say 10% comp test, and save the file. Encode it in virtualdub with 1-pass quality based at 100% i.e quant 2-2. Get the file and check its size and multiply it by 10. Now you will have an accurate prediction of the size of the first pass => the compressibility of the movie and what resolution you will have to check.

Anyone remembers the formula that steady first posted for FSE?
I remember it gave very accurate results on how a codec (divx4,div3 then)Scales. It could be very usefull.

[tripnotik]

I don't remember the formula, but you can find the thread there:
http://forum.doom9.org/showthread.php?s=&threadid=5532

[kauffmbe]

Maybe I have just been lucky, but using the Divx 4 calculator settings in Gordian Knot has gotten me file sizes extremely close to pricted (closer actually than I got witn Divx 4.) This has been with three encodes, two 1 disk fairly low bit rates in the 700s and one two disc with a rate of 1450. I used all of the added features and light psychovisual on the first encode, only B-frames and GMC on the two disc encode, and b-frames, GMC, and light psychovisual on the last encode. As I said, maybe I'm just lucky!

Forgot to mention I am encoding by setting up an avisynth script with GKnot and then manually setting up the pases in VDub 1.4.9.

P.S. Psychovisual on light didn't give me the horrible artifacts throughout that some people have experienced, but it did give me a few shit frames.

[kauffmbe]

Update-- luck ran out. Just got a 45 meg short encode on Being John Malkovitch. Oh, well, nothing lasts forever.

Encode properties: 2 pass, B-frames, GMC and light psychovisual on, bitrate on 735k.

[movmasty]

doing 3 passes..........
one at fixed quantizer, say 4,
then input that bitrate,a little more or less,
for the standard 2pass of divx5.

and knowing how it is slow..............

in nandub the 1st pass, divided around 2, gave you some hint on the correct size of the movie, if use 1 or 2 cd,
and you are free to use any bitrate in the 2nd pass

[vcespon]

Well, maybe I got lucky too, but my first movie encoded with Divx 5 (using GMC and b-frames only), ended on 700 Mb. I'm using Xmpeg with full-size frames (no resizing).

The final quality is better than with Divx 4.12, and so far I haven't seen artifacts or shit frames. When played with the Playa 2.0, the post-processing makes the image even better.

[sierrafoxtrot]

@kauffmbe

being john malkovich is extremely compressible, what happened is that you probably maxed out the codec for that particular resolution. try increasing the res, or take phillipas' advice and run a short manual comp check with all the frilly bits enabled, then you get a more accurate picture of what the final filesize @ DRF2 would be, and hence, how compressible ...

[kauffmbe]

You are probably right. A very dark movie with no real high motion areas. Oh, well. It looks good anyway (no shit frames this time with light psychovisual on)

[smokeslikeapoet]

I really don't know what the problem is. I just encoded Jay and Silent Bob Strike Back, 700 MB rip in DivX 4.12, and then again in 5.0. Each came out to exactly 700 MB. Needless to say I was very happy. Needless to say this was probably a fluke, but I'm happy.

[obelix]

I did 2 encodes, 5th Element and Asterix, both aiming at 700 MB. I calculated with GKont and got 696 and 697 MB. That is close enough for me.

[Shayne]

I think when we compare dx5 to nandub we need to compare same file size not same bit rate since i am getting smaller files in divx5 at the same bit rate as divx3

[DJ Bobo]

@ Shayne
It's logical to make comparison at same bitrate, I can't encode a movie several times until it reaches the wanted size, since DivX5 is damn unpredictable :angry:

[Huge]

For me, encoding an old war movie with b-frames made it around 80mb smaller than without which is a huge difference.

[Vinaren]

About the original question, the best way to predict filesize:

Only use 2-pass encoding. This is the number one best way to predict filesize (and get the best encodings). Use a calculator for divx4 to calculate what bitrate you should use. You don't need no special calculator what so ever to calculate divx5 streams.

I've done 6 movies so far in divx5 and only got about 2-4 mb off target from predicted filesize. It's not perfect but good enough.

Second, about the replyes in this thread. Tell what kind of encoding you are using, 1-pass, quality, high bitrate, 2-pass or such otherwise the reply is more or less useless.

/Vinaren

[philippas]

@Vinaren off course we talk about 2-pass encoding.
But the only way to be sure that you will select the appropriate resolution for a given bitRate is to do a compressibility test with quant=2-2 (quality 100% in Divx5).
You can make your own avs file or use GKnot to make it.

The formula that Gnot uses is the following:

Let
a = % of compressibility test
Xo,Yo = small resolution
X1, Y1 = big resolution
k = size of compressibility test
m = new size of first pass

(X0*Y0)/(X1*Y1)*K*100/a = m

So now to give an example: Say you did a 10% compressibility test at a resolution of 640x352 and you reached 200mb.

The size of the first pass will be 200*10=2000mb

Now if you want to choose a smaller resolution say 512x288 you have

a = 10
X1,Y1 = 640,352
X0,Y0 = 512,288
k = 200(as before)

So m = (512*288)/(640*352)*200*100/10 => m = 1309mb

So from 2000mb at 640x352 you end up with a 1309mb at 512x288

Finally if you want to see what’s the quality percentage you divide the size of the 1st pass with the size that you want to fit the movie and multiply the result with 100.

So at 512x288 if you allocate 1309mb for the video you get 100%
for 640x352 you get 100% when you allocate 2000mb for the video.

The formula for the quality is the following:

Let:
p = size allocated for the video
m = size of the first pass at the resolution you chose

quality = (p/m)*100

For the above example m=1309mb and you want to fit in 2cd's and the audio is 200mb so you allocate 1200mb for the video so the quality = (1200/1309)*100 =91.67 %
Now in the above example you have to include also the audio and video interleaving overhead to be precise.


**Gnot assumes that divx4,divx5,divx3.11,Xvid scale linearly which is not the case. So you get a small error in the quality prediction.
But as closer you do the test in the final resolution ,the above method becomes more accurate.
That's why sometimes you have to do a comp test several times**