@VMesquita
I just changed the script also into a GOP based version: Code:
#################################################### Full movie got 721 MB (just testing) the GOP method gives me an Q=12 and therefore an average of the ping-pong-outputs which is 36.18 MB! So the total sampler size takes 5% of the whole movie... 36.18*2=72,36*10=723,6MB!!!!!!!!!! Matches almost the full encode, now I've to see if the overflow depends on the "round" AVS comand in the script, maybe "int" would be better ... first I gonna try on a different movie... All testings where made first using 300min, 3000max ... next movie I choose 500min, 5000max |
-------------------------------- nest step ---------------------------------
Another Movie testing ... "The Matrix" Refering Offset ping-pong settings: I did 1-2-3-4 "Pings" and hit the nedded sample filesize, then I performed a "pong" and another one .. average then was right! Ok not that exact cause CCE only allows rounded Q values! And thats what came out finally: 649MB! Which gets in relation almost exact close to the predicted sample! 649+117(Audio)=766MB Well for a prediction which only allows rounded Q Values to me it seems good. Cause that's what was almost predicted Tomorrow testing on other Movies also using Mainconcept and for shure again TmpgEnc |
Quote:
But only when we get very accurate manual predictions with this method. Once it's proven to work reliably (manually), then I'll integrate the method into CQMatic. :D -kwag |
----------------------------------- Next Step ---------------------------------
Encoding using TmpgEnc: Here's the report: http://www.digitalfaq.com/archives/error.gif __________________________________________________ _________________________ Now I did set the variable sa=5 ... (100/10/sa) .... therefore the sample stream will be 2%!!! of the whole video. To see how acurate this method works by using only a 2% moviesample ... therefore less prediction time. I first I calculated the Avrg.Bitrate using Calcumatic and did a 2pass on the sample just to see how much the 5% stream hast to take finally! (But I think you don't need 2pass cause you can obtain this value based on an mathematic formula .. but here I wanted to test again including 2pass at the beginning) Then aproaching needed filesize using "pings" (=offset set to 0) and therefore changing CQs until it matches. Finally I perfome a "pong" (offset in script set to 30 sec!) to be safe! Changing CQs again until the average of "ping" & "pong" ca. matches finally the needed result. ... encoding "full" size (offset set to 0 and deactivating the sampler line in the AVS script). Muxed result matches very well the needed size to fit on one CD-R80. Now testing on 480x576 ...... using diff. max and min Bitrates like 64/2000 ... to be continued |
----------------------------------- Next Step ---------------------------------
Other Movie encoding using my Script above. Encoding again using TmpgEnc: 480x576 mpeg1! 64/2000kbit and 2% Moviesample size! (variable sa=5 ... (100/10/sa) .... =sample stream=2%) Here's the report: __________________________________________________ _________________________ http://www.digitalfaq.com/archives/error.gif __________________________________________________ _________________________ It seems thats the way!! Using The Offset Ping Pong Script icluding the auto generation of a 2% Moviesample works as wonderful as working with an auto generated 5% Moviesample. :) |
Hi incredible,
sorry for getting back so late. You've achieved great results. Have you made a second VBR encoding on your offset prediction :?: I'm doing some tests right know. @Kwag Have you seen my post above on calculating the right size :?: What do you think :?: |
Here are the test results with incredible's script and a sa=5 (2% sample of movie length)
VBR mode VBR sample: 13.174 KB CQ1: 74.3 offset 0 CQ2: 73.1 offset 30 CQ average: 73.7 Full encoding: Wanted VS: 684080 KB Resulted VS: 656206 KB Calculated Sample (Frames of Sample/framerate)/8*(average bitrate) 13559.4 KB sample 13.488 with 74.7 offset 0 13.527 with 74.2 offset 30 CQ average: 74.45 Full encoding: Wanted VS: 684080 KB Resulted VS:680409 KB :i: :wink: |
:D
Now we should test what will serve better: more frames per slice or more slices containing less frames within the 2% :?: I think if we will integrate this pingpong-offset way in CQ matic there should be a window whre the user can determine this ... just in case of for example "YDifferenceToNext()" based avs script routines like MA?! Today I testet it on "Gladiator" @ 480x576 ... 8MBs less than wanted :evil: :D (1-41-1 GOP based Template so GOPlength= 84! as value in the script therefore less slices) Quote:
And thats why its not really needed to do a 2pass before ... as we talked in the chat ... and also VMesquita said ... its a simple math. calculation based upon Mediasize. :) In my workouts above I was just too lazy to calculate (got my brain in already other kvcd-Template optimization projects *g*) so I just did a quick 2pass. |
Quote:
-kwag |
Quote:
http://www.kvcd.net/forum/viewtopic.php?t=4964 -kwag |
Quote:
The 2% "reference"-output as it's based on the sampling routine in my script gives me an output of 2% of the whole amount of frames of the movie and .... the 2pass result will give me a size which would fit the needed final size (in this case 2% of 785) cause its based on avrg.Bitrate calculation. So i.e. I calculate using Calcumatic ... to fit 2%movie on 2%media I need an average of i.e. 700kbit. and thats the point .... the 2% reference encoding is not made using CQ which really would give me on each slice diff. sizes as you mentioned. And thats also what Krassi and I talked about yesterday in the Chat. 2% will be a sliced-amount of minutes which as to fit to a determined size (in this case as it makes the sense: 2% of 785) and thats what 2pass should calculate correct if Tmpegs internal calculation does this correct!?. No matter if the reference-samplestream includes high motion or less moving dark scenes --- the result will base upon average bitrate and thats why it ca. matches. Maybe within the sample encoding the allocation of the bitrates will differ a lot in comparosion to another sliced sample but the output will be ca. the same :arrow: 2pass And as Krassi also said ... to do this calculation the 2pass of tmpgenc is not needed cause it also refers to a formula where the average bitrate is the main component of the calculation to fit the result to the wanted size. And that's also a point ... can we believe tmpgEnc's internal calculation to fit an amount of frames refering to average bitrate to a needed final size? And to be shure Krassi used a mathematical formula. I think IF there would be a size-difference in encoded 2%-reference streams this will not belong to different slice-contents but to tmpgEnc internal 2pass avrg. bitrate calculation. And so I did yesterday again a new test: - No 2pass before done to get the refered reference-size but used Krassis formula also based on an avrg.bitrate value determined using Calcumatic. - Movie "The english Patient", ca.150mins 480x576mpeg1 using a gop length of 84! (1-41-1) to test. Therefore the variable Gop in the script was determinet to 84! but I choosed a GOPlength multiplicator of 1 cause 84 frames each slice are enough. -Again sliced-sampler size calculation set to 2% in the script. - ca. 9 ping-pongs where needed. In this case pong-offset was set to 40 sec! Cause of less slices (larger gop lenght!) where auto-calculated by the script to get still 2% of the movie. - Final encoding and therfore muxed output was a 787 MB! mpeg stream, 795 where wanted. I can't proof that this is really Luck ;-) BUT Im Going to to more encodings to see the average acuracy of this way .... just to be safe. But Kwag .... I think the thread finally NOW does not base only on "2pass or not" , it changed ALSO to verify a "offset ping-pong" calculation method (which by the way is not new) ... so if there still will be a precise calculation needed refering to generate a acuarate first-reference sample ... then this will be another workout. There i agree with you definitely, thats right. I don't say THIS IS the right method to determine the first-reference sample stream! (although my tests do match) BUT even if we got a precise method to determine the right referenze stream size ... we still have to do prediction turns to match the right reference size ... and IMHO this will be done best by using offset-intervalls in CQ matic which is faster than larger samples and even more precise cause the offset-method offers more DIFFERENT scene contents in the slices within the whole prediction. And exactly that's it what I wanted to say in the other thread where you replied. But as I said ... Im not at the end ... Ill do more and more tests and maybe if this will end by seeing that there will be needed a right first reference sample calcu-method we continue by figure that out. Belongig to acurate predictions :arrow: I will not give up ;-) |
First of all I want to thank to Incredible and Krassy for this interesting thread .
I hope it'll give us perfect file size prediction method. @ Incredible I'm trying to follow this thread and to understand how exectly are u predicting file size and I have question (with your permission ) : 1. This method coould be good for predicting sizes for vcd,svcd,xvcd and DVD's too ??? ( as I see it answer should be - YES , or I'm wrong???) 2. are u runung off=0 and off=30 scripts in manual way or u use some prgram code ? 3. Which encoder do u prefer for best results ???(TMPG ,CCE ,MCE???) 4. Did u tryed to compare CCE vs Tmpg for prediction accuracy with your method??? I know that u have made many tests and I'm just currious about results of prediction with diff encoders . To make it more clear , can u make mini HOW-To and put it here ??? It'll be so helpful ( for me for sure ). Results are wery promissing , Keep going !!!! bman |
Hi bman,
thanks for your input 8) We are changing the offset manually, but here's a short how-to: 1) Take incredible's script, make your adaptions (e.g. Resizing Values and sa) 2) Change sa to 5 to reflect a 2% sample of the movie 2a) Change the Variable GOP to the amount of frames within your Goplength you're encoding with .... like 24 in case of standard KVCD 3) Make a 2-pass VBR encoding on that script or calculate it with the following formula: (Frames of Sample/framerate)/8*(average bitrate). Tip: You can see the Frames of the sample when you start an encoding of the sample. You can calculate the average bitrate with CalcuMatic. 4) Try to find a CQ matching this sample size. If found note it and 5) Change the offset value to 30 and redo a prediction until sample size is matiching again 6) Take the average of this value and do a full encode. You only need to comment the sampler line. 7) Post the results 8) CCE gives about the same accuracy, the only problem is that the CQ values aren't precise enough.I'm using TMPGEnc for now. My range is min: 300 to max 5000. So that's targeting for KDVD. EDIT: Edited Mini-Howto with point 2a. Thanks incredible :D |
Quote:
First, I can only give you answers based on my experiences, .... maybe Kwag is right ... maybe I'm right .... maybe another Member will figure out the right way using a total diffenrent method ... we don't know by now. And I hope I use the correct english words so noone will get confused. Quote:
Quote:
Quote:
Mainconcept is even worth when predictionning cause of less amount of possible Q values! Quote:
Quote:
Oh ... I see now Krassi already answered ... AND Bman....... :!: : As Krassi already posted a how to. - Use the GOP refering script! - Use the same logic of offset "pin-pong" as I did in my reports above! You also can figure out the amount of frames of your script generated sample by opening the script in Vdub .... switch to the last frame and see the framecount within the generated sample below in Vdub. It should take about 2% of the whole amount of frames in case of the "unscliced" source if varaible sa=5 (5= 2%, 2=5%, 1=10% sample size to match!) Based on (100/10)/sa = sample size To see if the offset is rigth I inculded subs in the script in case of trying and playing ... just to get a feeling for this! So if you manual predict including subs ... therefore you also have to full-encode including the subs! Later you can perform a manual real-world prediction by deactivating the sub- lines in the avs script. |
Thank's Krassy & Incredible !
I think that now is clear for me what to do so as soon as I'll get home I'll try this new method . One more quastion : How do u now what CQ u should start encoding ( or it do not metter ) and how long it takes to find RIGHT CQ value this way . I assume that as u are running all stuff manually than it should take an about half or 3/4 of hour . Is my assumption right ? If so than it's really precise but not so fast way (yet )! :wink: :cry: Maybe some day whan it'll be implemented in automathic prog than ..... Anyway , great job . I LOVE this site :D :D :D bman |
Quote:
Quote:
So a good start in CQ is 60, but you can guess what you want at start. If it's not a long movie you could start with 70... Quote:
Quote:
|
Quote:
How long it takes? Well if you start using a very near CQ as I did in the reports above ... you'll match it faster ;-) 3/4 of hour??? No! First ... also when using automatic program codes like CQ the prediction time depends on your encoding size, CPU and so on. Try first using an encoding size of 352x288! As default in the script --- this gives you a faster prediction to do your test workout. So in my case and my CPU as I remember every turn took about 1-2 minutes (352x288) and as you see the reports above (wich show the count of turns) you can assume how much it took, including the manual setting of off=x and re-safing the .avs every time... EDIT: And again, meanwhile Krassi found the english words much faster :lol: |
---------------------------------- Next step ------------------------------------
Other successful prediction yesterday evening using this method: "Gladiator" · 480x576 · mpeg1 · 149min · GOP = 84 (1-41-1) · 112kbit Audio muxed mpg. size = 783MB ... 795 wanted (CDr80) |
Quote:
Could you also test with MPEG2? I've found that you can't simply treat MPEG2 the same as MPEG1 and just subtract 25MB for SVCD overhead. |
That will be the next testing ...!
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.