1 - A CQ based proportional .... Not really in topic in this thread, but in Calcumatic one. Anyway, as you seem to be interested by the spreadsheet, I would like your opinion. Finally I think you understood my question.
2 - An approach for getting a CQ based... This is really the topic affair.
3 - something else? Yes, secondary and completely off topic Anmon82 related affairs.

Luis, ....

based on that I understood your aprroch well, that you still insist on doing a 1%ping++1%pong instead of 2%ping results in diff. outputs.

As explained very easy and shown via graphics in here
http://www.kvcd.net/forum/viewtopic....r=asc&start=97

1%_ping + 1%_pong is EXACTLY the same as 2%_ping.

1%ping+1%pong is MERGING, ..... 2%ping is an INTERLEAVE or MULTIPLEX VERSION of 1%ping+1%pong = same bits needed. Its like if you would merge a m2v and an ac3 one behind the other.

Not only in Filesize, also in exactly the same Imagecontent, same Frames, SamePixelvalues. as you do just align slices different, but the contend of that "container" is the same so the weight is the same.



I even wondered as I thought that there at least should be a difference in a few bits, so that above is luck, but shows clearly that these 2% turns do result a very conventional 2% prediction appraoch. where Ping-pong-ping-ping-ping-ping-pong only uses 1% but gots the same amount effective MovieFrames/pixels of that stream in his calculations.

I also do give you an advice FAR away from any personal emotional point of view:
Be careful, as avalon says he would reach 99,999 acuracy. No matter if he means a simple samplestream or a final encoding. THIS IS NOT POSSIBLE FOR SHURE WHEN USING AN ENCODER LIKE CCE BY USING ONLY INTEGER Q VALUE SETTINGS!
Didn't he thought about that?? Shurely not. But he posted a log file in that thread where these integer only changing steps are shown.
http://forum.doom9.org/showpost.php?...59&postcount=2

If any knowledged person on doom9 or from the outside sees that, he can imagin what that kind of "99,9" propaganda is about.
Thats also why not that much testers do assist these testings.

So YOUR approch could be used without thinking and therefor it will be faster treaten "dead" to an out of interest state before something can be proofed on real testings.

my real two cents ... independent from my understandings on YOUR idea.

@Andrej: I don't disscused that:

Would be also 2%pingSize (TPPP) = 1%pingSize (TPPP)+ 1%pongSize (TPPP)?

Being the same, what do you think is quicker and easier matching a desired sample size?

What is the difference to ......
?

Thats what Im doing to explain since the last 2 days ...

1%_ping+1%pong = 2%_ping .... equals to your 2%"OPPPPP"
So thats an "traditional" 2% sampler WITHOUT any advantage of offsetting at at least one turn to AVOID continous 2% sampling but quicker 1% sampling.
Lets keep saying 2% or 1% and ping or pong .... a new word definitioning of TPPPP and OPPPP or whatever makes it even more confusing (to me) if talking about that slicer function.

Using a build of an initial Q by using 1 lowest and 1 max Q or even a rule of three is enough: (if CQ@10 results in xxxxkb, whatt CQ is needed to match wanted kb) ..... using THAT calculated CQ result for starting the ping, pong, ping, ping, (pong). process.

= 1% + 1% (= initial Q) +1% +1%+1%+1% = 6% of total Movietime is needed and if using a safe pong then 7%. ..... but all that incl 2% of movieCONTENT (not time!) predicted! Thats the Idea of slicer.


@ All

Heres a nice Site from FR_AN a member from german Gleitz board....
http://fr-an.de/fragen/v04/index.htm

You can see that even a simple rule of three wont fit, but you can include in that rle of three a little exponential value, so a very near initial CQ would result for beginning an even less truns needed process.

What a nice links you post always Inc.
I would like this one was in english language.

I also did think that the article define. Inclusive I did think that it could be a logaritmic relation tha convert such hiperbolic curve in a straight.
But as im not mathematician...
Anyway in that article don't show any defined equation, but say that CQ is function of avgBTR and vice versa.
Of course, if I could find out such logarithmic equation, we can "transform" a non lineal CQ curve in a lineal one.
In other words, prediction could be a lot more exact than at the moment.

But you see a good Q curve is not one that is flat.
That's only good for prediction .
A good Q curve is one that adapts to the video source in question.
It is reasonable to say that, x-pass is the best method to compress your video.
Take a 2-pass VBR as an example: the encoder creates a database on it's first run.
On the second run it uses such database to know which parts of the movie need more (or less) bitrate.
The encoded output is (should!) perfect size, almost perfect quantization and best quality.
And if you look at the Q curve of an x-pass encode, you'll see that it is FAR from being flat, and I mean far.
Given fact: most encoders that I've tested so far, encode better in x-pass than in (C)Q mode.
Let's just say that if you take tmpgenc as an example you could almost proove me wrong because in terms of quality it can be better than a 2-pass VBR.
But load a sample of a tmpgenc's CQ encode in bitrate viewer: it is very far from being flat, and that's probably why it looks so good.
And that you will only find in tmpgenc, as far as I have seen in other encoders.
Cheers

__________________
Rui

@rds: I agree. That I said is only with prediction purposes, a logarithmic equation show a logarithmic straight. It is to say, " an increase of 1000 in bitrate will increase (or decrease depends if 1 is the better or the worse value) the logarithm of CQ in 1 unit. When you apply the antilogaritm at that unit, you will obtain the CQ value that is not a direct proportional number. When you increase btr from 2000 to 3000, Q will increase (or decrease) from, lets say, 90 to 95, but if you increase btr until 4000, CQ will increase, lets say, until 98 and not until 100 as it was direct proportional. But the logarith was increasing in 1 unit. This permit you, find the desired Q value in an easier way.
I don't know if you can understand it, my english is not so good.

Beside the question IF 2pass is really better on some encoders than OPV...

_____________________________________________

Rules of prediction:

- You cant to a static math formula on non linear Q/CQ working encoders to obtain a final correct CQ, as they act arbitrary

- The less samples you take, the less the prediction will be trustable, as you dont know WHAT happens between the sampled chunks! And no type of prediction will change that, as its a fact based on the source and not on the concept of the prediction utility.

_____________________________________________


Now, how can we optimize a prediction?

As you see most encoders do result in a "Gamma curve" similair graph as you can see on Fr_An's Site, that one cant be used in a simple math we know. BUT we can take that into account when determining an initial CQ Value to start with.
Why?
Because sometimes 70% of the prediction time is used to get almost near to that point where an initial CQ start "would" begin. Ok, some apps do got a field where you can enter the initial CQ of your "assumption", but you can be far off.
So we should put the whole time a prediction needs in another relation, means:
Helping the predicting to be more fast by finding an initial CQ which shortens the amount of steps for finding the optimal CQ significantly.
THAT safed time we could serve to more sampled Source frames, means more % of the movie .... Result: SAME time needed but MORE precise!

So, IF that CQ curve in the graph in the link above is just more or less a constat like a gamma curve behaves, then we could at least use that on a math where we can find a "near" CQ Value to start with.

But how is the math for such a curve? To me it seems like a type of exponential but not x^x bot something like x^(x-y).

I really hate to bring this up so late in the thread, but how is ping-pong prediction any different than regular sample size prediction?

As incredible has pointed out 1%+1% encoding is the same as 2% encoding.

So a 2% ping - 2% pong prediction is exactly the same as a 4% sample without ping-pong.

Why should I use ping-pong?
Instead of just SelectRangeEvery(600,24)

Regards,
Tenra

Yep, I see where you're going .
But those 4% take very long to encode.
A Ping/Pong prediction works like this:
CQ=70, do a Ping of 1% and a Pong of 1%.
Let's assume we are low on target so we need to raise the CQ to match.
CQ=75, do a Ping of 1% ----> too low on target again.
CQ=77, do a Ping of 1% ----> too high on target.
CQ=76, do a Ping of 1% ----> too low on target.
CQ=76.5, do a Ping of 1% ----> too low on target.
CQ=76.7, do a Ping of 1% ----> found a CQ inside a 1% deviation.
CQ=76.7, do a safe Pong of 1% ----> the Pong certifies that it is really inside 1%.
Encode at CQ=76.7.
How do you see if it is higher or lower than wanted by just doing a Ping?
By using the first Ping/Pong that will give you a percentual and proportional difference that should always be the same wether the CQ=1 or CQ=90 or whatever figure.
So from my figures we've done a:
1% Ping
1% Pong
1% Ping
1% Ping
1% Ping
1% Ping
1% Ping
1% Pong
This equals 8% of the movie.
It is my understanding that If you do that with Prodater's method or by your method you'll always do much more than 8%.
Or am I wrong?
Nice seeing you (back) on the forum .
Cheers

__________________
Rui

I totally agree that ping-pong is faster. I like the idea of finding a target size faster.

What is hard for me to grasp is why this is any better in accuracy, as seems to be claimed in previous posts.

To me it looks like in your example you are really only looking at 2% of the total frames, 1% ping and 1% pong. Even though you are looking at the ping frames more than once.

I don't mean to say that I wouldn't use this method, it's fast. I just need more convincing that it has better accuracy.

Regards,
Tenra

You don't need to do that.
Select your 2% target and do 2% pings until you see sample match your target filesize. You dont need any math neither percentual.
I prefer that an not to take a calculator any time a sample is coded.

the 1%ping and 1%pong is to get the relation of 2%, where the further prediction routines just use 1% for approaching the needed samplesize.

At the beginning I continously did ping-pong-ping-pong-ping-pong .... but not needed, ping-pong-ping-ping-ping (if seen logically) a way of LongShort you also did

So more accuracy will be taken out of that we use the safed time to rise the % of the ping & pong samples.

Read again Ruis post, he safes time by only doing further 1% pings!

2% ping and further 1% ping turns are also ok, would be exactly Long-Short Prediction.

Now I get it, Thanks KWAG!!!!

Ha Ha