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.

Always you should demonstrate hipotesis with facts. I posted my results:

http://www.digitalfaq.com/archives/error.gif

Could you go ahead and do your owns tests. Also same I asking to Incredible. Please.

Edited: Also I would like to know, what method seems you easier, after your test end.

Hi Luis :),
I see your results look indeed interesting.
But I'm a little confused.
The 1% Ping+Pong gave you a 52.410KB result.
Then the 2% Ping / 2% Pong gave you a 52.045KB result.
I would not start giving a party right now, with these results.
You see, in fact you just sampled only 2% of your movie and it went off by 365KB.
I am still not talking about which will be closest in terms of prediction.
I am only stating that it is a big difference.
You see, if you were encoding the whole movie you would have ended up with a difference of 18.250KB, which is a lot.
As to which will be easier or faster or more clean to use, for me it is obvious I would peek OPPPP.
The only downside is that it will take longer in each prediction fase.
Predicting Ping+Pong+Ping+Pong+Ping+Pong+Ping+Pong takes longer than Ping+Pong+Ping+Ping+Ping+Pong and I'm counting the last Pong that from my point of view is almost useless.
Tonight I'll run 2 predictions and let the movies encoding overnight.
Tomorrow I'll tell you the results.
I'm only doing it with 2 movies due to harddrive-available-space restrictions :roll: ...
Cheers

As I mentioned previously, 52045KB is just the avg, as you point, between ping and pong (it means that I obtained that value after doing ping pong passes, averaging it, so you see the usual ping pong matching perfect). For that it seems that traditional ping pong method is more exact. But suppose the target would be 52400?
In other word, do your prediction searching an exact match of your sample size. If you reach an exact match with 2 methods, it should give you same Q value. In this case, only left as important what method was easier and quicker.
If Q value is different, you need to do a whole encoding of same film with 2 differents Q found.
Then evaluate:
Final difference is significant whatever method used. If yes, you must to select final size closer method as winner.
If not, put in the balance what method is quicker and easier.

Despite 52045 was averaged from results:

Let's take 2602250KB as total video size (52045*50)

(18250/2602250)*100=0.7%

Does it seems to big for you?
What precission did you obtain usually with traditional ping pong prediction (TPPP)?

Edited: I think for precission comparations you must to do traditional ping pong 1% samples, against 2%(1% ping - 1% pong) OPPPP, as if you do use traditional ping pong 2% samples you will sample double with Incredible's method.
There is a posibility (I not tested already) that 2% OPPPP, sampling half than 2% TPPP, be more exact, but I don't think really it could be so.

I would like to add that NO 1% or 2% sampling of a total footage, no matter how good it is, will ever achieve 99.999% target.
It's :arrow: I M P O S S I B L E, unless you sample the complete footage, because you can NEVER tell what the activity of the other 98% is :!: Period.
Anyone who claims that is a joker :!:

-kwag

Sorry, was my fault.
D9 thread title is:

That sounds more realistic!
But still, 99.99% accuracy on sample can be either -10% to +10% (or worse!) off target size on the full encode, specially if only 2% of the footage is sampled.
And that's why I drop prediction phases on CQMatic once I get to +-1% of wanted sample, because I still can't tell what the final size will be, even with 1% accuracy of the sample.
Still, I've found that with the latest algorithm in CQMatic, the worse case scenario is about 5% undersize to 2% oversize, and that's not that bad.

EDIT: Quoting what I just read:
"With the help of Prodater64 I find now a way to predict more exactly ever wanted. Now AutoQ2 matches 99.999% the wanted filesize."

Second post here: http://forum.doom9.org/showthread.php?t=96420

-kwag

Well, regarding the thread title, it must be a typo.
Can I ask him?

Edited:

I didn't test AutoQ2 as I am working on my owns projects.
When I ends it, I'll give a try.
For this, I don't say here that tool is wonderful.
I only talking about about my prediction mod.
AutoQ2 is a proove that it works, at least, matching the target size.

A little bit OT:
You all did feel yourself bad when I talked with Amnon82.
I did feel bad myself, when here, in "my forum", nobody even tested that wath I am talking about, just a "superficial" interest, and disscarted inmediately. Im not claiming you a special interest in all I am saying here (maybe mostly stupid things), but my work related to this site (really a lot of hard work) is for all my friends and partners here, and I would like, some of you just give me a little, little bit of your time and feedback.
As another example, I had to insist hard and very, very much in Calcumatic thread, and I did need @rds help, to reach that somebody hear me about "finding a proportional space". At least, if such tool born any time, I will feel happy knowing that I was first 2 cents contributer.
End OT.

Well I'll run the test to see how close I can get in encoded filesize.
I must warn you guys, even if it was simple luck, I've reached less than 1% undersize several time with HC in (C)Q mode.
BTW, I was thinking.
I'm used to do 1% Ping Pong predictions so 1st I'll predict the OPPPP with 2% and then I'll try to do it with 1% also.
For that I'll change the slicer function in order to allow me the usage of decimal figures.
Like: Just for testing purposes.
Hope Andrej doesn't mind :).
Cheers

First I do see that Amnon did put me OUT of the credits, that was shure!
Ok, its a mod on slicer where parts of predictions are used now in a diff. way but the root is very clear .... but who cares. Its the p**** off shit, that people do use other Ideas, techniques etc. ---- using that 99% core and use it just a different way. The name OPPPPP eben contains that "P" based on whatever Ping or Pong.

I dont understand ..... when the first release of slicer came out .... modding did start. Then one year silence. After one year an update came out .... and then modding started again ;)
Well "that" I dont! see proplematic for shure ;) But its nice to see that deeds do start inspirations (not said ironic)

I DO apreciate cooperations and I DO assist, if I have time and if Im not on other projects. But one thing is shure, these approaches do base on slicer.

Do imagine u use the MA script AS it is, just changing unfilter() and Temporalsoften() to other filter.dlls - and btw putting Karl out of the list. :lol:

These are two cents .... so the modder or developer should know by himself.




One moment Luis .... its a diff. kind of thing if someone doesnt have time in the exact same moment like where you want assistance. So "superficial" interest is NOT given. If there wouldn't be interest, some people like mine wouldnt take time in the job to write explanations understandable down in a thread like above.

The idea on a proportional space was already given at CQ mode a long time before .... Im doing CQ encodes (and Phil also AFAIK) in a way that movies on one DVD do keep the same quality.
BUT! The case of that idea on a 2pass approach DOES base on YOUR cents contribution.

There was NEVER a time in here when someone did start a real new Idea that his name wasnt kept in mind after that. ;) Like Arnet_tenrA.

That man is a real marketing king ;)
Good ! Approaches do get even bigger, but 99.999% of wanted FINAL filesize on CQ ARENT possible like Karl pointed to. The reason is that you dont predict ALL peaks and lows, even when using 20% on every prediction turn. Look at my graphs at the beginning of this thread.
But ... you can get closer and closer.

Its like "unfold fields horizontal" and "fold fields horizontal back".

The I frames will be the same as thats the purpose of the 15th gop length size. If you set "auto I frame insertion" that that will be linear, but if no auto I frame will be inserted, even then it will stand in a same "propoprtional" relation to the full encoding where also the Iframes will be at diff. positions.

And THATs why I never use Auto-I-Frames when doing OPV predictions.

@ Generally

Tomorrow Ill start tests as I was in Job business till tonight.
But the math and the "real" framecount AND contend on BOTH (1%+1% and 2% scripting) for me is clear. If the "real world" behaves different, then it bases on things like Auto-I-Frame.
Shure u dont have to change that much the encoder source but you need to take twice the time for one turn as you did simply (in math thinking) append.
The pong was just an idea to get more samples by almost the same time for predictionning seen in a whole.


But beside all testings and Credit deserving to people which do develop.
My point to that credit thing of avalon is clear! As he NEVER used own Ideas. If slicer wouldnt have been born he would still use these one slice sampler(xxx,yyy) maths. I knew it that this would end up like this
:lol: :lol: :lol: :lol:


PS: As you mentioned the "friendship" in here: WE didnt feel bad, as its not on us what youre doing and what you decide ;).
BUT these where 2 cents for YOU! As WE had clear experiences.
And thats a little part of "friendship".
Solamente evitar qué te vas a caer un tiempo en esta situación con avalon. ?Entiendes? ;)

@Prodater,

How about fixing that Luis :?:
As you have contact with Avalon, and we don't, maybe you can ask him why he removed Incredible from the credits, as it's HIS idea :!:

-kwag

I did try that also, but an error was raised!

Did you read what is the thread name, as I quoted before?
If Amnon82 withdraws your credit line, it is very bad really. I'll talk about that with him.

Edited: I just now PM Amnon82 claiming him that put back Incredible's credits and offered in exchange that withdrown my ones if he think that I don have anyone.
For sure he missinterpreted me and did think that the function is mine. Remember that we, both, don't have english as native language.

LATELY I still do see that the 2pass approach , means the one approch you tried to explain in here isnt the fact of the purpose of that tool there. He is still using CQ mode and a diff. kind of using slicer, based on inspirations of you. He did code, but the ideas do belong to others. --- you see?

And he is still talking of one movie predictions, right? So even that approach is not given keeping same Q on an amount of movies one one target, which was done by using CQ already before.

Now here comes the importand part for you: :arrow: IF its shure that your 1%+1% usage of slicer will give the better results, ... then WHY in the hell did you give it to other coders where you by your own do have enough skills in VB usage for coding that????? You could enhance your own tool without that marketing taste.

YOU got the idea of 1%+1% ... if it will be proofed that it works much better THEN for shure you got the right to be in there .... much more then him! I dont care if being put in the last line, but eliminating is what teases me.

He doesnt misinterprete you at all, he gots that good english knowledge, which was enough to force a 20 page long anti MVCD campaign in here!

You still don't understand me.

1 - OPPPP is not only for 2PassVBR encoding.
2 - With OPPPP he still needs 2 pass, finding 1 sample at given CQ and other at another given CQ. After that he needs only to do maths to obtain final CQ.
3 - With TPPP he needs, at least one ping, one pong, do maths, and another ping, aplly "proportional difference" at this, and do maths again to obtain final CQ
4 - I give him my idea voluntary, he don't forced me in any way.

This is another affair.

1 - First I talked with him about my way prediction method that resulted he changed his code.

2 - After that last program version was released, I asked him if he would like his program had a 2 or 3 movies "proportinal space prediction" or if he could be interested in developpe such prediction tool isolated.
Two ideas did seems him good. He is thinking about now.
It liked also that his program would be only (ATM) with that tool.

I would like to remark here that my idea is to 2 Q samples of 2 movies, with let's say CQ=100, they can be with fixed frames number or with a percentage, as doing maths you always can to know ho many KB needs a fixed frames number.
As in those samples, samplesizes are determined by the bitrate assigned by the CQ encoding, if we do aKB/(aKB+bKB) and bKB/(aKB+bKB) we will obtain a proportion based upon bits repart. If you apply then (but you can apply it at same time, I explain it in this way for better understanding) differents movies times, you will obtain final proportions (FP1 and FP2).
Now you only needs to do:

Final Video Size 1 = Mediasize * FP1
Final Video Size 2 = Mediasize * FP2

With this values and your desired audio rate and overhead, you can obtain
an avgBTR.

Finally with all this, a tool as CQMatic could do its known work, but ALSO wichever xPass encoder could encode the streams with the given avgBTR.

This work can be do perfectly with the Boulder's spreadsheet.
Values obtained permits CQ encodings (CQmatic needs only playing time and avgBTR, all other data is given by TMPGEnc project), or xPassVBR encodings (encoders only needs avgBTR, max and min, and also a "Final Video Size"

I'm working in my own programs.
This do not avoid I can share knowledge. I liked Amnon82 program and I though I could help him. I also wanted interchange ideas about HC Encoder and its CQmaxbitrate issues.
My programs are mostly as control panels to call useful encoding and another frequent tasks softwares, and also adds batch encoding to some encoding softwares. Now also adds prediction for CQ encoding.
His programs are complete frontends where you can set all variables as in the original one. You can see, programs "are like" but not equals.
Finally, if I can help to develope an useful video encoding tool, I will do it, as you can see in Maurus last tool thread, as I worked with Mencoder and lately with HC Encoder and NuEnc.

I was sure someone will tell that. But I hoped he would think a little further. There is not only I frames in a GOP.
Let's talk about P frames : how big is a P frame in a middle of a scene compared to one at a change scene ? What is the proportion of change scene in a 1%+1% compared to 2% ?
Is is the same ? No.
So are the two methods equivalent ? No.

The two methods are equivalent IF no auto-I are introduced AND no P or B frames are used. A not really interresting hypothesis ;)

Verrrrry nice I just typed in here maths and calculations which did take 15 mins - and firefox *bombed* when entering beside kvcd page was open at several other pages on the www :evil:

@ All
The accuratest approch in predictions is if you dont use AutoIframes.
Why?

Cause it gots its sense as slicer and also the sampler() way we know use a chunk length which matches the framecount within a GOP of the final encoding.

Lets say we do allocade a 15th GOP "IPBBPBBPBBPBBPB".

Now every slicelength is set to 15. Based on the used % of the full movie those routines like slicer do take chunks of á 15frames and merge them as ONE bitstream. And as we us a FIXED encoding GOP (non autoIframe) of 15, every I frame will match each chunk at its beginning. So the GopStructures and Lengths will be constant while doing that pass. The I,P,B frames will always be on the same Positions when doing the prediction passes. And as every I,P,B.

Even if I do set to AutoIframe, ... as the content of the slices wont differ when appending a 1%+1% these GOPs also will be constant in their structure


(x) = Slice No.(x)

2%ping = (1)IPBBPBBPBBPBBPB_(2)IPBBPBBPBBPBBPB_(3)IPBBPBBPB BPBBPB_(4)IPBBPBBPBBPBBPB_(5)IPBBPBBPBBPBBPB_(6)IP BBPBBPBBPBBPB_(7)IPBBPBBPBBPBBPB_(8)IPBBPBBPBBPBBP B_(9)IPBBPBBPBBPBBPB_(10)IPBBPBBPBBPBBPB

1%ping = (1)IPBBPBBPBBPBBPB_(3)IPBBPBBPBBPBBPB_(5)IPBBPBBPB BPBBPB_(7)IPBBPBBPBBPBBPB_(9)IPBBPBBPBBPBBPB

1%pong = (2)IPBBPBBPBBPBBPB_(4)IPBBPBBPBBPBBPB_(6)IPBBPBBPB BPBBPB_(8)IPBBPBBPBBPBBPB_(10)IPBBPBBPBBPBBPB

1%ping+1%pong = (1)IPBBPBBPBBPBBPB_(3)IPBBPBBPBBPBBPB_(5)IPBBPBBPB BPBBPB_(7)IPBBPBBPBBPBBPB_(9)IPBBPBBPBBPBBPB_(2)IP BBPBBPBBPBBPB_(4)IPBBPBBPBBPBBPB_(6)IPBBPBBPBBPBBP B_(8)IPBBPBBPBBPBBPB_(10)IPBBPBBPBBPBBPB

means the by appending, the slice alignment has changed but NOT the SlicePixelDataContent (which also is responsable for auto I frames. And even if I would use Auto I frame, THAT slice where in these 15frames of that slice 2 or 3 I frames did result. If appending 1%+1% exactly THAT slice will be shown to the encoder again where again the same 2 or 3 I frames will be allocaded.

See a prediction not in sampling frames, but sampling GOP contents/bits.

Now related to Auto-Gop-Insertion:

If I do encode a whole movie using NO Auto I frames, then I got a continous Gopflow by a content of each GOP of "IPBBPBBPBBPBBPB".

Means in that Movie "I" Frames would cause taking 50% of Bits, "P" Frames 30% and "B" Frames 20% (lets assume these values).

If I also do apply a prediction where I also do use a fixed GOP then also here we do have a relation of 50/30/20 %.

If I do use AutoIframes the proportion of I frames in a range of 15 frames could/will be "out of control" and therefore IF the slicing would touch exactly those scenes where much Schanges do occur, it could happen that the result in kbit of that prediction will be messed up as the relation of added I frames from the prediction to the final full encode could be different! As by this these bitrate peak scenes and their SCs will affect even more the risk of beeing out of target finally.

I made tests on the first version of slicer and already there I did figure out that the possibility to match the final wanted target size is MUCH bigger if AutoIframes are of. Why we are doing predictions? Cause we cant deal with constans in resulted bitcontents and if we now do apply a routine which makes it even more inconstant, then its even harder to predict.

Its not just 1%ping+1%ping as these returned bitstreams are defined by 1%ping+1%pong! Where the pong is exactly in the middle of two pings.
So its the same pixeldatacontent! when comparing to 2%ping ... see my graphs some posts above.

1% ping and 1% pong IS the same as 2% ping.

It doesnt matter "where" the slice including its pixeldata of xKbits does exist in the alignment of slices in the prection stream, then important thing is that it wont differ in its content to the next sliced turn of the same slicing (ping or pong).

Do that on a mpeg2source, open it in Vdub and compare.
The slices are just alignet different, but lentgh of slices is the same and ALSO the pixeldata contents!

Thats the IDEA of slicer that ist NOT needed to predict in 2% passes which need more time, BUT in several 1% passes which just do contain 1 or two pongs for getting a comparison to frames beeing offsetted!

Inc, a P frame can be as big as a I frame at a change scene, and even bigger ! The most scene change you introduce in the middle of a GOP, the more will be the weight of the P frames in the bit consumed.

Now I don't use either of all these methods or any ping pong or pang method, and I don't give a shit about them. Reading carefully your post above and the former one, I think I'd probably badly understood you. Just forget my remark.

OF COURSE !!! I'm saying that since the very begining of CQMatic ! And is is not a matter of bigger possibility or not : any "sliced" prediction method is a nonsense if I frames are introduced automatically at scene changes.

Note: just to tell why I do not use any "p" method. You all know that even with a 100% accurate sampler method, you can't tell nothing about the size of the final encode. So why do you bother to find such a method ? :lol:

Well thats cause I told "assume these values" just for explanation - as also here we do have a non-constant.

Ahhhh :) I knew that you understood it as 1%ping+1%ping which wasnt the case - shure that makes it confusing.

@ Generally

Slicer wasnt build to be acurater at the first sight (as that always does base on the % of the movie you do use for prediction IF no constant CQ output encoding is possible). It was build to take in the same number of prediction turns MORE samples due offsetting which MAKES it acurater AND as predictions are NEVER constant (due the encoders lack of constancy while Q encoding) there will be NEVERNEVERNEVRENVER a prediction method which lets the movie result in 99,99 final wanted targetsize, even if you would use nonsenseful 100% when doing a prediction ... the inconstant CQing will not end up 99,99 bit 99,xx in its accuracy.


Means ...

1%_ping + 1%_pong at CQ 10 = ResultLow
1%_ping + 1%_pong at CQ 90 = ResultHigh

The needed CQ = the average out of ResultLow & ResultHigh and putted afterwards in a rule of three calculation.

The only Problem is ....... :arrow: you do use a math formula wich of course IS CONSTANT ---- but the enemy of that "beeing Constant" is "CQ itself" as its NOT constant. Thats why Karl never did only one Prediction Turn and applied a rule of three.

Such an approach (as I understood) I used to get very close to the near cq WHERE I do begin my real ping-pong-ping-ping-ping-pong prediction.
MEANS: This way is ok to obtain an INITIAL CQ value where the turns do begin but NOT to obtain a final CQ. The "initial" way only makes the prediction taking less time ... but NOT more acurate ;)

But I guess again I didn't understand you in your explanations?

I remember veray good wen we and Karl did approaches on new predictionning thoughts, maybe the first encodings did result verrry acurate and then *boooom* the affection of CQ's nature did its part by beeing non constant and suddelny the big applause changed into silence when a target encoding finally went out of wanted filesize.
So ... IF I would do obtain this evening good results, I would need mooore testsings ... as TIME is the one which does proof things in this case ;)
And on the coming Wednesday Im on holidays at the Lake Garda in Italy.

HC maybe when using these steps gives GIVES good results as it uses an almost constant Q curve in Bitrateviewer which TmpgEnc or CCE dont provide! But that average Q value out of he Q curve will also be never that acurate.
To be most acurate, you would need an encoder using a fixed Quantizer Scale which we know from Libavcodec, but as we do know that the ratecontrol is freaky ... that will also make it not possible doing a rule of three prediction.

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.

So in easy words ....

- Use slicing on i.e. 2 diff. MovieSources of 2% each (no matter what slicing way).

- do encode the first using i.e. CQ 60
- do encode the second using also CQ 60

Do calculate the proportional difference of both outputs.
Lets say the first one needs 20% more of space at the same CQ.

So we do assign out of the final caluclated avg bitrate needed for both for matching the target media 20% more to the first Movie? and in proportional less XX% to the second one. This keeps the "total needed avg bitrate of BOTH" but each gots its bits assignet individually.

Link to that spreadsheet please? I know it has been posted somewhere in here but ... ough

Here is the speadsheet:

http://www.saunalahti.fi/sam08/kbps_eng.xls

http://www.kvcd.net/forum/viewtopic.php?p=117425#117425



Addendum: @Inc: Once I explained Ammon82, that OPPPP is my idea but the function, and the script also (as you corrected my one) are yours, your credits are again in the "about page" of AutoQ2. Also my ones.