Encoding the whole movie
 

Simple question???

I don’t care about the time it takes (the computer is running when I’m asleep),
But I want to make sure that the movie will come out 795 mb.
Is there a way to determine the exact cq by encoding the whole movie (twice) instead of using samples?

No.

YOu can use 2-pass VBR or encode the whole movie more than 2 times (the same number of time you would have encode a sample in fact).

@Dialhot, how about using ToK ?

Can't we tell ToK to do a full encode at a certain CQ, and then small samples starting at the same CQ, I think it's called "Faster Prediction".
If we set ToK to do length of sample = 75, and 20 samples per minute (for GOP of 25, PAL movie), and after that use "Faster Prediction" with "Speed Up" = 10% or perhaps 20%...

Wouldn't that make a full encode, and then compare the size of the full encode with a lot of small samples? ( I know this would take a lot of time, but if it is done over night, then it wouldn't matter )

Maybe I'm wrong, I haven't tried it myself. :lol:

What do you think, is it possible?

Anerboda

For sure it's possible but whatever you do, when using samples you don't compute the real CQ but an estimated one. So the CQ you will find at the end of the "fast prediction" pass won't be the absolutly exact one (it will be closer than with the standrd tok prediction, but not THE one).

:arrow: At the end you can have a file that is still a few MB other the target.
(in a certain part of the curve, the file size move very quicly even for a very small variation of CQ).

@ Anerboda

Well in case of TOK this wont give you a 99% chance to hit the 796 MB muxing Target.

Because the first log pass gives a value, so: long=(resulted MB * (calculation of long slices ))@ CQ 65 for example (stream minus audio).
Now the same CQ will be used on a small sample ... which gives small= (resulted MB * (calculation of small slice sizes)). So TOK calculates that "long" should be in relation to "small" at same cq and so with this "long" in mind he starts approching the nearest CQ using therefore the resulting new "small"s but you still use this "unlinear" CQ behaviour on just all the same sliced "small" samples on every turn. And thats why you'll never get even that 99% acuracy seen as an average on all your predictions done on all your movies ;-) If CQ would be linear we just could perform the mathematical "rule of three" but ... it won't work as we know. So in my opinion an almost 100% acurate prediction will depend on future code-updates of TmpgEnc belonging to its CQ mode.

EDIT: (DialHot just replied also .. he typed it more brought to the point)

@Dialhot
@Incredible

Thanks for your observations and explanations, this will save me from a lot of testing... :D

So this will still be trial and error, I guess... :lol:

But I allready started a few encodes out of this theory, so I'll get back to you...

Anerboda

I know, and a lot of times I have found that around a CQ of 79 to 81 there are very big differences in filesize, even with a little increase/decrease in CQ...
...and it seems to be in these incidents, that it's very difficult to predict the right CQ...
...so if we raised or lowered the min. bitrate we would get out of this area, where CQ is difficult to predict..?

If somehow we could find a min bitrate that would leave us in an area where the CQ is more linear, it would be easier to predict...?

Just wondering... It's late here in Denmark, and I'm probably not thinking straight anymore today...I'll go to bed now, have to get up at 5:00... :evil:

Anerboda

Once a time Kwag told me that using "B spoilage" in tmpgenc setting bows the CQ curve. Perhaps it's possible to make it a little less difficult to predict.

That was the idea of CQMAtic (using 0.57*AVG as min and 2000 as max). But Kwag finally realize that it wasn't enought.