06-29-2005, 03:08 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
Seems we're talking about lot affairs in here .... so whats now the subject?
- A CQ based proportional sized avrg bitrate 2pass encoding for keeping a "visuable" constant Quality over several movies one ONE Media or targetspace.
- An approach for getting a CQ based encoding (not 2pass) using slicer in an even more acurate way
- somethign else?
Only that I get a bit updated and for avoiding getting total out of control according to explanations etc.
|
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.
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
06-29-2005, 04:27 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
06-29-2005, 04:41 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@Andrej: I don't disscused that:
Quote:
Originally Posted by Prodater64
So that Incredible points means:
2%pingSize = 1%pingSize + 1%pongSize = 2%OPPPPSize
That supports my hipotesis.
You don't need to do any calculation neither obtain differences or proportions. Only looking at filesize in the screen, you will have an idea of how much near of your target are you.
A 2% OPPPP is the same than an 1% usual ping pong, but you don't need to edit your avs, neither launch again your encoder, etc, etc. More, if you want to obtain an exact match or so close as you want, you can't do it straight obtaining only ping pongs (as you always have to average them and do calculations), but with an OPPPP you can reach exact match looking at the screen.
|
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?
|
06-29-2005, 04:50 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
@Andrej: I don't disscused that:
Quote:
Originally Posted by Prodater64
So that Incredible points means:
2%pingSize = 1%pingSize + 1%pongSize = 2%OPPPPSize
|
|
What is the difference to ......
Quote:
Would be also 2%pingSize (TPPP) = 1%pingSize (TPPP)+ 1%pongSize (TPPP)?
|
?
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.
Quote:
Being the same, what do you think is quicker and easier matching a desired sample size?
|
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.
|
06-30-2005, 01:24 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
@ 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.
|
06-30-2005, 01:37 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
06-30-2005, 02:07 PM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
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
|
06-30-2005, 02:51 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@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.
|
06-30-2005, 04:57 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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).
|
07-01-2005, 02:05 PM
|
Free Member
|
|
Join Date: Jan 2003
Location: Illinois, USA
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
Code:
2%ping =
x.....x.....x.....x.....x.....x.....x.....x.....x...
2%pong =
...x.....x.....x.....x.....x.....x.....x.....x.....x
4%sample =
x..x..x..x..x..x..x..x..x..x..x..x..x..x..x..x..x..x
Why should I use ping-pong?
Instead of just SelectRangeEvery(600,24)
Regards,
Tenra
|
07-01-2005, 02:42 PM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
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
|
07-01-2005, 03:01 PM
|
Free Member
|
|
Join Date: Jan 2003
Location: Illinois, USA
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
|
07-01-2005, 04:10 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
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.
|
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.
|
07-01-2005, 04:21 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by ARnet_tenRA
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.
|
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.
Quote:
Select your 2% target and do 2% pings until you see sample match your target filesize. You dont need any math neither percentual.
|
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.
|
07-01-2005, 04:34 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
07-05-2005, 10:06 AM
|
Free Member
|
|
Join Date: Jan 2003
Location: Illinois, USA
Posts: 73
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Now I get it, Thanks KWAG!!!!
Ha Ha
|
07-05-2005, 02:13 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
All times are GMT -5. The time now is 08:00 PM — vBulletin © Jelsoft Enterprises Ltd
|