Hi kwag!

Are you sure the formula is so accurate? I've encoded a film which is 80 min long with lbr template. The file size is 555MO with cq 90. The predicted filesize is 9,88. If i use your formula i've got a result of 617M0. But if i use this:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .90 ) the result is: 555,75MO!!!

Do you think the factor could be different for each resolution?

ARAGORN

@All,

There is some improvement using High in motion search
This goes back to an old issue about the algo Tmpgenc's using
to detect scene changes between frames at the macro block level it
seemed to work, but at the pixel block level it would ignor this
due to smoothing from TemporalSmoother and now FluxSmooth.
Try encoding without smoothing and see if it improves more
With these short comings and others the Frankencoder project was
born. (Maybe). Tweaking Q-Matrix may not have produced solutions
but defining the problem further could help in seeking answers. The
progress being made is excellent (file prediction, new GOP, 704x480
fitting on 1 CD, etc.) Don't give up now. Maybe Tmpgenc's
developer could shed some light for a solution on this problem

-black prince

@Kwag,

Just finished encoding full movie using 704x480, GOP=1-12-2-1-24,
for 2 CD(800MB ea) with CQ=75 and there are NO!! Gibbs effects.
I threw Blockbuster noise back in with a variance of .3 and Flux.
Tmpgenc's motion search is set to High and I'm using Clip Frame.
Audio is 128kb and thanks to file predictor the video filled the rest of
the CD's. Picture quality is incrediable!!!! Maybe with higher
CQ the encoder has more bitrate to work with Any way, I'm
switching to this resolution at least for 2 CD's.

-black prince

That's exactly the parameters I have been using. I even lowered the "detail"max" to 5 and the variance to .5 and the results are worse. The problem is the movie I tested is 138 minutes. That is a very long movie with a lot of movement. So as it is, the bit rate is already pretty marginal without any filters. When I add blockbuster, that margin is gone because I have to lower CQ value in order to target the same predicted sample, and then things start to look bad. That's why I mentioned that if you have more bits to play with, then you can use Blockbuster to your advantage. If the movie is already too long, any noise filters will just drop your quality below that minimum treshold and the overall picture quality will suffer.

-kwag

Hi kwag!

can you actually compare the Q-Level of different resolutions? because lower quality has a lower Q-Level too, as far as my tests prove...

Is that right?

__________________
j3llyG0053

With the new GOP and formula, remove the factor.
The formula is:

-kwag

Hi kwag
I know that but if i do this the result is not good. There is 62MO of difference between the encoded film and the result with the new formula. I'm using the new gop and Sampler last version. To have the good result I have to multiplying the mpeg file size by .9... Sorry to insist

ARAGORN

Hi ARAGORN,

I'm not sure what's going on there , because I've already made over 4 different CQ encodes with the above formula, and every time I'm hitting < 1% predicted size to final size no matter what resolution I use

-kwag

Kwag,

What are your exacts settings in cq mode: does enable padding is check?
And what about P and B picture spoilage? Are they set to 0 or not?

I don't know if that could make a difference in the accuracy of the prediction ?

Hi all !!!
I'm confused !!!
what is the most updated method or script for file prediction ?!?
Anyone please ?!!!
bman

It shouldn't make any difference what you set your parameters, as long as your settings remain identical after calculating final size with the sample. That means that after you have your final CQ value, just remove the "Sampler()" line from your .avs script and encode your movie. I always check "enable padding". I am currently using picture spoilage of 0 and B spoilage of 20. These are the default values. I noticed that if I change those values, I have to re-calculate CQ, and when I do it's the same result no matter what I set the spoilage. Changing the spoilage values only changes the CQ encoding curve.

-kwag

Hi kwag,

Which template did you use ?
My tests are better with CQ_VBR that CQ

--
apoc

I've tried 352x240, 528x480 and 704x480. All with CQ encoding and KVCDs Q Matrix.

-kwag

apoc,

Strange. I'm testing on some of my Tv Captures and CQ set to 80-85 (704x576) puts 1 Hour Widescreen on one CD at far better quality than CQ_VBR at the same filesize. For me, this is definately the way to go.

Jim

I've just encoded The Game : 2 hours CQ_VBR=8 (KVCDx3) 1 CD
Very nice quality ... My first tests with CQ give me lot of macroblocks.

dunno why

I use KVCDx3 template and I replace CQ_CBR with CQ and change the resolution.

--
apoc

I'm getting very confused now =)

What is the concensus? Is CQ better with high resolution (704x480 and x3) and CQ_VBR with low resolution (352x240/480)?

Should we keep using filters?

Just when I think I've got a handle on the KVCD thing everything changes...

I'm not complaining...just losing track.

Hi m0rdant,

Try your prediction samples with all the filters. Blockbuster, FluxSmooth, etc. Then if you see that the sample's quality is not so good, remove only the blockbuster "noise". Leave FluxSmooth() and LegalClip(). I always use them. So far it seems that CQ is beating the crap out of CQ_VBR

-kwag

I'm using DVD2SVCD for encoding/predicting...

CQ prediction doesn't seem as acurate with DVD2SVCD. I tried the first disk of Lord Of The Rings and got a file that was 200megs too big.

CQ_VBR seems to come in on target or just below though.

What I'm wondering is, if CQ is kicking the crap out of CQ_VBR, how did we get started on CQ_VBR and what has changed to make CQ the better choice again?

We started with CQ and then went to CQ_VBR and the "plus" templates, which were recomended over the originals...and now Blockbuster is no longer in favor (for me it seems to help with getting solid black colors)...but at some point each of these was viewed as way better than the old way.

At any rate, the work is appreciated, even if its overwhelming me a bit at the moment.

Don't use DVD2SVCD for prediction with the new GOP. It just won't work. The algo we've developed is extremely accurate, and it's not the same algo used in DVD2SVCD. We'll have to wait until DVD2SVCD integrates the new method. We didn't have any kind of file prediction way back when we started to do comparison with CQ and CQ_VBR. CQ_VBR seemed to create better quality, maybe with the older versions of TMPEG used at the time. But now that we have tools to measure different encoding techniques by keeping a target size constant between different encoding schemes, we clearly see the difference NO WAY, Blockbuster is the bomb . But I explained this earlier: If you have enough bits available that you can add Blockbuster "noise", go ahead, and you'll have excelent quality. If you don't have spare bits, that is your encoded sample has a very low CQ for your final target size and the quality is good but "borderline", anything you introduce that will lower your final average bit rate will degrade your quality. In this case, don't use blockbuster.

-kwag

Ok, that makes some sense to me =)

I can go back to doing things manually, I just like the ease of DVD2SVCD...support for it here is one of the things that brought me back to using KVCD settings.

The prediction in DVD2SVCD seems to work very well with CQ_VBR and the new gop settings, just not with CQ.

Well, I'll try doing things the old "hands on" way for my next encode.