Quote:
-kwag |
@ Kwag..
As for my earlier issue w/ sampler.dll/sampler-2.5.dll, I changed back to * sampler.dll ..and right after, my system went by-by.. When I got it back up and running, restarted ToK, all worked !! I think I know what hapened.., my .d2v source was a small test file I was using in my tests. I think it was like a 3 minutes in total. So, that may have ben the "division by zero" error. I used my favorite movie, "Dogma" @ 128 minutes for my very first test. But ToK gave me these results below, and I'm a little confused, but I did notice that the quality in TMPG's window was not so good w/ those low CQ values. I used the defaults for my first try w/ ToK.. I'm sure I'll get it right, But, for now, I'm just curious.., did I do it correctly, after viewing below ?? Code:
Resolution (fps):720x480 (23.976 fps) @ Kwag.. Oh, about how many more minutes to go for that test of yours ?? Thanks for the help. -vhelp |
Ha Ha that is good to know, it was easier using the calculator anyway
Thax dude. :) |
Hi vhelp,
You're trying to fit 567,396,720 bytes of video at 720x480 on one CD :!: I think that's the problem right there 8) Edit: I mean, you're trying to crunch down your video to that size. Your audio is WAY too big :!: Time left on my encode: 2 hours, 7 minutes. :twisted: -kwag |
Quote:
Hey Vhelp you doing audio at about 192 kbps that audio size is toooo big 8O |
I get that decreasing curve error on one of my DVDs too. Every time it happens and I've tried 5 times. The movie is 120 minutes and I tried 112, 128, 160, and 192 all on 2 CDs and everytime I get the decreasing curve error. I don't know what that means, but for some reason ToK barfs on these Vobs.
And my CQ is in the 70s so I don't know why it does that. |
Ok guys, here are the results :!:
Remember this was an encode with a new shorter GOP (which should generate more accurate prediction results) Wanted final file size: 718,644KB Actual encoded file size: 764,711 8O Now, hold on before you scream :lol: I didn't use any "factor" at all. Just the plain formula, to see the result on the final file size. The difference is basically 6% larger on final file size, compared to the wanted. Now I must do one more test, but with another movie. I now that if I correct the CQ on this one by lowering the wanted CQ to target my sampler file size 6% lower, the result wil be exact. So now I need to encode some other movie, an action movie, but apply the same formula and take into consideration the new 6% introduced with the GOP change. That's the only way we're going to know if we have a constant prediction So now I'm going to encode "Boondock Saints" to see what the final size will be, but with the 6% factor. It the target is on the nose, then we know we're accurate again. K-Pax is a very low action movie, and "Boondock Saints" has a lot of action. So they are movies on extremes. We'll see what happens. If anyone wants to try this, the current formula is this: Predicted MPEG size = ( ((Total frames/MovieTimeInMinutes) / 24 ) * MPEG sample file size ) * 0.94 Which is the same as taking the value that MovieStacker suggests for video stream, divide it by 60, and subtract 6% ( or multiply by 0.94 ) In my K-Pax movie, the final video size required is 718,644KB. So that divided by 60 is 11,977.4KB and then applying the 6% would be 11258.756 and that's the sampler size we need to find CQ for. I'll keep you posted, probably tomorrow when the encode is done. -kwag |
@ Kwag..
Right now, I'm having my own version of :) FUN :) I'm reading KVCD Predictor (by sansGrip 11.18.02) to better understand "predictions" and calculations and whatnots. Its hard reading for me at this hour, and I'm currently at page 7 now. Here's the FUN part. I'm building a predicter app as I go. This way, I am sure to learn it all. Well, it may turn out to be a nothing app, or not. That will be up to me, and how much I can take. I should've done this a long time ago.. oh well.., live and learn. But, this brings back some old memories of LONG nights of programming, and two pots of COFFEE. Part of this app is derived from rendalunit's C++ code on page 4. So, it could be off. It's a start. Hehe.. the funny thing was, in thinking up a name.. vpreck hehe.. but, I stuck to predict.1 instead. Mind you, this is all manual. But, if I have to scratch this app.. so bit it. Heck, maybe I'll spark others to play too. http://www.digitalfaq.com/archives/error.gif But, before i continue, should I be reading this thread, or another one ?? So far, I seem to be reading about CQ_VBR, but not CQ. So, I'm a little worried that I've read the wrong thread all-to-gether 8O I hope not. Please tell I'm not hehe.. Currently, I'm at page 7 and counting. But, I'm taking it REAL slowoww. I wanna make sure I understand this "prediction" stuff, but I must admit, I'm sort of confused on a few points.. * scale factor - where am I getting this from ?? * target MPEG file size - 6MB is my target ? where exactly derived from ?? * Sample size ie, * Well, the list goes on, but I'm learning as I go. -vhelp |
If you're on the CQ vs CQ_VBR thread, you're on the right track :mrgreen:
|
@ Kwag..
Ok, I'm not quite there, but being that I'm almost finished w/ KVCD Predictor (by sansGrip 11.18.02), I'll finish it up and move on to that thread you mentioned.. CQ vs CQ_VBR :wink: Would this thread happen to be this LONG 41 pager: * CQ vs. CQ_VBR ... VERY INTERESTING... [ Goto page: 1 ... 39, 40, 41 ] ...you bast..xx'rd you. hehe.. Ok.., give me a little time, and I'll be ready ta read. What's the countdown for your latest encoding test ?? -vhelp |
Quote:
I could connect to my PC via VNC client, but I rather not touch the machine that is doing the encode, which is about 100 feet from where I am in another room. -kwag |
Current prediction algorithm: Q for Kwag
Hi Kwag,
I don't know, guys, seems that everytime I have a thought and come to this forum with a new idea, some of you are already working on it or have discarded the idea alltogether after serious work. :) However, this time I am sort of confused, and I still would like to help. Would you please post the algorithm currently used in ToK to do the prediction? I don't want to look stupid by coming up with some logical supposedly new idea just to confirm you already gave it 75 posts. You know, it is better to remain silent and look stupid than to speak up and definitely clear the doubt :) Regards, |
Re: Current prediction algorithm: Q for Kwag
Quote:
These are the lines ToK uses at the end of a script to predict: Code:
AssumeFPS(23.976) -kwag |
Well, I need a vacation, because prediction is now a total disaster :!: :x
Finished "The Boondock Saints" with these results: Wanted file size: 722,779.89KB Real encoded final file size: :arrow: 645,083KB So as you can see, prediction is sucking wind :evil: :!: Back to the drawing board :cry: :cry: :cry: :cry: :cry: Note: Anyone interested in accurate prediction, move back to AviSynth 2.08 and the current 2.0x script. For the time being, I consider prediction with the MA script with AviSynth 2.52 marked as "BROKEN" until we can come back to +-2% accuracy and consistent results :!: -kwag |
@ Kwag..
Well, after an hour 1/2, I finally "captured" all those pages for later DETAILED reading (though I skimmed through some that took loke to D/L 'imgaes") But, I think most of the "predictor" formulas started around: * KVCD Predictor (by sansGrip 11.18.02) And, then: * CQ vs. CQ_VBR ... VERY INTERESTING... [ Goto page: 1 ... 39, 40, 41 ] ..took off further from there, w/ Matrix/GOP tuning, and so on and so forth. I'll print out all, later. -vhelp |
@ Kwag..
I feel for ya. Anyways.. Now, don't get mad at me.. Colm down.. and hear me out :) Here's a brilliant idea... :idea: If you can contact Hedix and ask him if revise ToK to make a copy of the .M1V and .M2V files, you can run a quick test to see if they are the same (size/quality etc) . . ..If you run the: ------------------------------------- FIG. A -- -- -- * AVIsynth v2.08 script w/ ToK and same script and filters, same movie * AVIsynth v2.52 script w/ ToK and same script and filters, same movie Note, they should be the same "size and quality" (according to you) Forget about color space and whatnots. Just use the EXACT same Filters that you used in v2.08 scripts w/ the same YUY2 only (I'm assuming that at the time, YUY2 was all you was using then) and make sure you DON'T use YV12 filters for v2.52's script filters (unless you used one in a given predict, back in v2.08 predicitons) <-- follow ? ------------------------------------- FIG. A -- -- -- That'll help you narrow down what's exactly causing the faul-ups. These two files (above) have to be different !! Otherwise, if they are the same, your predicts should be the same. I have the sneaky suspician that these two files will not match, even when useing the same Scripts and their respects Filters :!: Also, I noticed you used MPEG2dec3.dll in your tests. Wasn't there some changes made to it ?? And, are you SURE you are using the exact same script, same Filters, same everything ?? However, if you still are insistant, that I'm in error (as I am at times) you can do the following then. Assuming that it's not the color space or YUY2 vs. YV12, then perform the same senario as above (Fig A) BUT, this time, take out the MA script functions, and only use the script filters in v2.08 and see what you get in those two file sizes (.m2v / .m1v) Again, assuming your're correct, you should two files that are: * same size * same quality * or, same whatever But, first we need to keep the file (or files) that ToK creates during the predict process. I think that all he (or you) have to do is revise the .tpr file to no delete the .m1v or .m2v files it creates. I know it's only ONE file that it creats, but if it could STOP deleting them, and in stead, use index numbers for each file, that'll help us w/ our (your) analisis/comparison of v2.08's based predicts vs. v2.52's !! What do you think. And, remember, be nice.. I'm ONLY trying to help !! -vhelp |
@ Kwag..
Ok, wait a minute.. maybe I need to re-read your post(s) At first, I thought you were not getting the same results based on the same movie you ran ToK (prediction) on in a preivous AVIsynth v2.08 and that your final numbers were way off, but that you felt v2.52 should have matched v2.08 - - Am I understanding you now ?? Now, I'm thinking that you went past that stage, and am not now at the stage where you are not getting an "accurate" predict, using the latest AVIsynth v2.52 version (IOW, you're not comparying AVIsynth v2.08 against v2.52, but rather, you are comparing the "predictability" rate or accuracy when using w/ v2.52 vs. v2.08 <-- follow me ?? I think I now follow you. If that is what you are saying, then I appoligize for my insistive behavior, and rambling on. But, I still feel the above posts hold truth in another perfective :) So, based on my newly found realization, have you done other tests like: * again, take out the MA script functions, and just run the test that way and see how close you get. As, Joz or ovs64 said, it may be the MA script functions that needs to be fine-tuned. I don't know.. I'm just trying to help narrow down the causes. -vhelp |
8O
and i am :Drunk: reading this all..cross-eyed and :oops: too cos i'm lost. i see the last changes in the script,was removed: conditionalfilter( last, asharp(-1,0), last, "nf", ">", "scd_trigger" ) and scd_trigger=30 this will change the velocity and the final prediction too. then someone would help me to use the prediction or is better wait a little more for your results to put my feet in the earth? i'm out of space. :lol: |
@ Kwag..
I just had a thought (made sense to me) w/ ToK's output. When I cancelled the first pass, and wait a little for it to finish, I stopped TMPG. Next, I examined the .m1v file (which by the way seems to be a bug in ToK) I selected SVCD, but it's 8O still 8O making MPEG-1 samples 8O 8O 8O Anyways.. And I examined the .m1v (which was suppose to be MPEG-2) and I observed how it scene-changed through those Samples. I noticed that there were far too many abruptness when TMPG encoded those scene changes w/ the MA script's MA functions. There were soo many bad encoding around these, and as far as I can tell, that leaves to increased filesize. Ok, so given the above, I think that the MA functions have to really looked at. W/ respect to above, I've done a few of my own encoding w/ MA script and I can say, that I STILL find it is not encoding these scene-changes smoothely. If we setup some sort of analigy tool like this, caues I don't know any other way to demonstrate that you would understand: * Bf,Df,Af represents the SCENE Changing.. beforeFrame/duringFRAME/afterFrame An example: When doing "Deuce Bigalow", during a low motion scene change: * Bf would blur, then * Df would be clear (normal) * Af would be blur again -- -- -- (Fig A) -- -- -- . .....OR, . * Bf would blur, then * Df would blur, then * Af would be blur again -- -- -- (Fig B) -- -- -- Note, that Bf,Df,Af would alternate in these anamilies in various order. Now, since this caught my eye, I decided to follow the test encode I did w/ MA script. I found Fig A and Fig B through my test clips, and that the effect (dramatic or not) would depend on the scenes low motion or hi motion would refect the MA's function's effectiveness, hence Fig A, and Fig B. Some how, this has to be fine-tuned some more, because there is obvious issues w/ the scene detection algorithm, which is probably what's causing the predict to be thrown off I'll play around w/ this some more. That's my theory so far. Unless you can come up w/ a better one. -vhelp |
Finding a way around the sheer "unpredictibility" of scene changes, movie to movie, that are
"super compressed " with the "Adaptive" script, is both our blessing and curse. This "unpredictibility" also only increases (theoreticly) as a movie`s timeline gets longer to boot. What we aren`t sampling is what`s skewing the math, I believe. Someone correct me if I`m wrong here. Kwag once joked to me "what we need is a scene change counter"....more truth than jest. To bad we can`t use some kinda` "transcode" technology with it... :lol: ******************************* The Devil`s always.....in the Details! |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.