Ping-pong prediction vs Long-short prediction
Hi,
Here I would like to present the results from some testing in file size prediction. Some details: For ping-pong was used gl=2 and sa=5. Offset was the value which the "subtitle" script posted by incredible gave me. For long-short prediction was used SelectRangeEvery(480,24) for 5% and SelectRangeEvery(2400,24) for 1% of the movie. This is the routine which is implemented in ToK, but different sample length. Quote:
Quote:
Quote:
|
Hi Abond,
nice to hear some one else is testing! :) Well ... I never had that big differences between wanted and final outputsize! And never that oversized 8O Whats the formula you use to calculate the reference size to match? Yesterday I feeded the ping pong way with American Beauty, where in case of this movie I everytime had problems, no matter what prediction appl. used. The American beauty stream runs via avisynth and got Kwags new MA Routine!! ... and final output was very very close. about 8 MBs less gl set to 2 and sa also set to 5 which I everytime use. Well when analyzing your encoding sizes I can see that at these movie examples the difference between the Ping and the pong output isn't that high! Which means that the offset turn didn't show big differences in scenes which wheren't inspected by the ping turn. Because not every movie got such irritating differences between "conventional" sliced szenes. But in my test I got 2-3 Movies where the Difference at 2% Movie-Sample-size was about 0,5-1,5MB! And thats where you see the advantage in doing this. Borax's CQ Tester also uses Offsets but calculates the reference in a different way and other diff. things.. Here you can see how the Offset-way within my routine works: http://www.digitalfaq.com/archives/error.gif And to be safe to hit the middle of the ping slicing I tried to add the "offset recommendation". I hope its calculated well. Yesterday I wrote the AVS Routine as a function, so you can safe it as .avsi and put it in your AVS Plugins Folder. Just add below your script the following syntax Slicer (clip c, int "percent", int "gop", int "off", int "gl", int "subs") Explanation: percent= percentage of the whole movie wich will be used prediction (default=2 this means NOW logically 2%!!!) gop= The length of you GOP you'll use to encode, so DVD(PAL) is 15 KVCD is 24, this has also to be understand as Samplelength! (default=15 so set es default to std. PAL) off= The offset where the sampling begins which is needed for Ping/pong prediction! (default=00 so the sampling begins at Frame 0!) gl= GOPlength multiplicator, this means by how much u want to enlarge the Samplelength which has to be GOP based! subs= Gives you a Subtitle where you can find the recommendation for Offset settings! Use this the first time you just preview your script to see the recommended settings refering to "off"! (default= 0 this means off, 1 = subtitel/recommendation active) And here's the function which you can safe for example as "Slicer.avsi" and put in the Avisynth Plugins Folder so the Syntax as shown above will work: Code:
############################################################### How to do a prediction using this Command: 1. Encode your audio to mp2 and watch in the windowsexplorer how much Kbyte it takes 2. Add the Slicer() at the end of your existing script and configure it refering to your final encode I suggest 2% of total movie which has to be used for prediction, enter the lenght of your used GOP and set the GOP multiplikator to 2 (this means 2times GOPlenght as Samplerlength). The Offset has to be set to 0. 3. Preview your .avs and note the second offset value recommendation! 4. Now calculate: Whole muxed size minus Muxing overhead in Kbyte, substract also the audiosize in Kbyte as you can see it in the WindowsExplorer. So we finally want to have a 795MB muxed moviestream to burn on CDr80. In this case: 795-10=785 .... 785x1024= 803840 Kbyte ..... 803840 Kbyte - 119808 Kbyte (assuming for audio) = 684032 Kbyte!!! Now the next calculation depends on what percentage you have set for prediction, we assume (and I reccomend) 2%, therefore 684032Kbyte / 100 *2 = 13.681 Kbyte !! That is the Reference Size we have to match cause its 2% of the Final Streamsize. 5. Configure your Encoder to CQ (or Q) (GOP settings set to the exact Gop Length as set in the Slicer()!!!) and import your .avs including the Slicer(). 6. Assume a CQ to set in the encoding setting to start with. 7. RUN! 8. You see that the Sampler will be encoded, after encoding you have to watch the encoded size and compare it to the reference size.... already close?? Well if not just rise or lower the CQ value in the encoder and do a new encoding as much times as its needed to get very close to the reference size. If you are almost close (like 10% to the reference size) you do a "Pong". This means that this kind of Prediction uses a Ping-Pong Method and therefore an Offet of 0 is a Ping and a Offset set to the recommended value you noted when previewing you avs.. is a Pong! So if you are close like 10% to the nedded size perform a pong by just setting the int "off" in the Slicer() to the recommended value. Safe your .avs again and run TmpgEnc again (no source reloading needed! and leave the CQ as used as in the last turn!!!!). You will see that the Prediction now uses different Scenes than when performing the Ping Sampling! And thats also why we will get very accurate cause by performing an offset there will be more different scenes encoded.. and therefore we obtain a better average of scenes which will be calculated to the whole prediction. 9. Now ... do you see a difference between the last outputted size and this one? Regulary yes! So you can see how both predictions behave. 10. Now continue performing Pongs by rising/lowering the CQ and keep in mind the difference to the ping! Now when you are very close to the needed size and the ping size keeped in mind, you perform a last "safe"-Ping (offset=0) ... and if the average of Ping and pong outputs matches the reference size ... go into your avs script an deactivate the Slicer() line re-safe it and do your full encode!! Here is a sample report where you can see how to approach to the needed CQ (I everytime mention the CQs and Offsets in my filenames so I will have a good overview): http://www.digitalfaq.com/archives/error.gif The first time it will a bit complicated or it will take some time, but you will very soon get a "feeling" for this and so you will be faster the next time ;-) If you want you can add a safety margin to your calculation of the refered size above ... Well Im happy without but every user got different experiences so in your cases add or substract a factor to your reference size to match the needed final sizes . |
The formula:
( Wanted video size/framecount)*frames in sample = refrence sample size Slicer - very nice! New stuff to play with! BTW after short examination of the ping-pongs I and the sizes they produce it seems that the difference between them for the same CQ is almost constant! 13996-12815=1181 and 13467-12291=1176 but this are KB, maybe in bytes they will match! In my case (movie 3) I have 14328-14163=165 and 14165-13999=166 The other two are different though. Just a thought. Currently I am testing long-short adjusting the reference with ping-pong for 1% sample. The reference file size increase. I think I just found a cure for permanently undersized files using long-short in the range 10-25 MB. Well, will see after almost 4 hours. |
Hi Abond ,
Quote:
I discussed this with Krassi too. So theoretically you only would have to do one "pong" to see how the "other" slices do behave.... BUT! If Ping or Pong ... both are encodings don using CQ and we know that CQ is not linear ... so it could happen that if you figure out at a very beginning of the prediction turns, a difference of about 1024 Kbyte results .... at the end of your prediction there could result a difference of 512 Kbyte! So be safe and do a final "to be safe"-Pong at the end ... as I think you did. I everytime do it like this: I do a Ping and a Pong on a assumed CQ (fist turn)... ok. this gives me a ca. behaviour of bboth samples (ping & Pong). Now I contiunue predicting using only pings ... until I get very very close to the Reference size BUT also the difference of the pong still in mind! Finally I do the safe-pong and see if the average matches the reference. After this ... deleting the Slicer() in my Source Script - resaving the source.avs and let TmpgEnc do the whole Job. I hope you did understand that you dont need at every turn to reload the source .avs in Tmpg! Just change the values of offset in the sclicer() in your source, resafe and hint again "start" in TmpgEnc ... you will see if he got the offset change! Quote:
1024Kbyte Difference at 2% = would be a 50MBs failure on a final encoding ... and thats why the offset makes sense. Maybe we all will figure out how much safety margin is needed or so on which has to be implementated in this manual way but I think the offset/movie-percentual/GOP - Based Prediction "could" give nice results on difficult to predict movies. But as Kwag said .... you will never be away of this tricky non-linear CQ .. until this will be fixed in TmpgEnc. ;-) |
Quote:
Quote:
|
@incredible (or anyone else who can help ;) )
I added the line: "Slicer(clip c, int "percent", int "gop", int "off", int "gl", int "subs")" last in my script, but I get an error in Mediaplayer. It says "Expected a, or )". What does this mean? Could you please explain once again how to use this slicing routine? |
This is my script:
Quote:
Quote:
What am I doing wrong? I'm really interested in trying this prediction method! :wink: Desperate for help... :banghead: |
Audioslave,
Zaks in the german forum got exactly the same error and it was solved when he reinstalled AVS 2.53! Another Point: Don't use just Slicer() You should set it to the needed parameters here an example as folowwed: Slicer(2,24,00,2,1) This means (2% of whole movie will be sliced, 24 (KVCD) frames in a GOP are used when encoding, offset is set to 00, one slice (GOP) will be multiplicated 2 times, and 1 stands for that subtitle for offset determination is on) BTW the size of the subs are opimated for a view within a 480 x XXX size, so if you want to see the subs in a 352 x XXX you have to decrease the fontsize in the avsi doc. Code:
c=Subs >= 1 ? Subtitle(c, text_color=$999999 ,size=16,\ Cheers Inc. |
Thank you, Incredible. I installed AviSynth 2.5.3 and changed the Slicer parameters, and what do you know - it works! :D Thanks!
|
@incredible,
when i use 'slicer(2,15,00,2,1)' at the end of my script, i get the error- message 'Sampler: output frame count must be < input frame count'... mmh, any ideas??? - tnx in advance regards, ***mfb*** |
@mfb
install avisynth 2.53! gruß zaks |
Quote:
i installed avisynth 2.53 and it worked fine. my first try with ping-pong prediction gave me quite accurate results :D (~ 10 MB less than wanted filesize for the muxed videostream predicted for a CDR-100 media) regards, ***mfb*** |
Hell yeah! 8) :D
Just finished encoding Terminator 3 - 800,99 MB muxed! Amazing. This is how I calculated: Quote:
Thank you Incredible! This "Slicer Routine" is great! Keep up the good work. :wink: |
Close but no cigar
Incredible,
What am I missing here? Here's my main AVS Script Quote:
Quote:
"There is no function named Sampler" D:\Ripped\freq.avs line 25 D:\Ripped\Slicer.avs line 54 Any Ideas? :? :?: |
missing sampler.dll for avisynth 2.52 /2.53
regards zaks |
Be shure you installed avisynth 2.53 and downloaded and installed the sampler version 2.5
www.incredible.de.tf/Downloads/Sampler-2.5.rar BTW Vortech ... You should delete the MergeLuma(blur(0.1)) in your MA Script as the new MA routine now unfilters (blurs) linear without threshold settings, in combination with this MergeLuma(blur(0.1)) your image will end up to blurry even on almost no motion scenes! |
Anybody can translate to Spanish this method ? :( It will be a great help for spanish Kdvders
Thanks in advance :P |
Si te esperas, este fin de semana voy a escribir una explicación en español (bueno con mis pequeñas palabras en español que hasta ahora no me han perdido :) )
|
Quote:
|
:D :D :D :D :D :D :D
YESSSSSSS PLEASEEEEE!!!!!!! Hablas muy bien el español = You speak very well spanish :D I will wait for it impatiently!!!!!! THX very much |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.