CQMatic 1.4.00 Release Candidate #2
http://www.digitalfaq.com/archives/error.gif
What's new in this version :?: 1) Completely re-written prediction engine. Sampling now depends on movie length, so it's now dynamic. You should be able to throw just about anything at CQMatic, and it will know "how" to encode "whatever" material (PAL/NTSC, etc) :D 2) Prediction is now done in "phases". Then, using a formula and some tricks (don't ask ;) ), it determines the correct target CQ. 3) Prediction is MUCH faster :!: On my Pentium 4 @2.8Ghz, I am averaging a full prediction cycle in about 20 to 25 minutes minutes, on a average movie of 1 hour, 45 minutes (on linear range, CQ=~50 to CQ=~85) Below CQ=~50, you all know it takes longer, and I can't do a thing about it :roll: The first phase, in theory, should be the longest. All subsequent phases uses the previous found CQ, which is closer to final value, instead of starting every phase at CQ=60, as in previous versions. Still, you should count on about 1/5 of your total movie time, for prediction time. Still, it beats the hell out of any multipass encode :mrgreen: 4) Removed "Override CQ" option. It's now done automagically ;) 5) Added progress bar, to give you a visual idea where the process is. Here you have it: http://up1.fastuploads.info/CQMatic-1.4.00-RC-2.exe.zip Please report any problems on this same thread. If everything goes well, and no bugs are found, I will cut the software as 1.4.00 Release :) If there are inconsistencies, then there might be more release candidates before final release. Thanks to everyone, and all who BETA tested :cool: Enjoy :!: -kwag |
Great Tool Karl!
I know you got your hands into many things and this would be just one of many in a long line of requests, but what about taking some of this functionality to predict with NuEnc and it's CQ function. Right now I am doing it manually. It's super simple and easy to determine as it seems mostly linear with Peter Cheat's code modificatins. Right now I am running commandlines via batch files. Greg a.k.a. Racer99 |
Quote:
Quote:
Quote:
-kwag |
RC-3 is up.
http://up1.fastuploads.info/CQMatic-1.4.00-RC-3.exe.zip You might want to give this a try. RC-2 does 5 test phases. RC-3 does 7 phases. I've had extremely good results with RC-2, but on ONE case, I got a file size over the wanted. This was due to the damn CQ (un)linear range in TMPEG, when target is in the range of ~69 to ~70, where just one click of CQ makes a huge diffference in final file size. With two aditional phases, this should zero in more on the final precision for these particular cases. I'm taking a constant prediction time of around 37 minutes with RC-3, for a full movie, which takes me about 2.5 hours to encode. That's about a 25% (worst case) overhead for prediction, which I consider ok, because what I want is final size to be within a calculated target of no more that -2% to +2% As I've said before, if your final CQ will fall in a range of ~50 or less, you can count on a VERY long time to predict due to TMPEG's behaviour, and I can't do a thing about that :roll: -kwag |
YES !
Movie length : 146 min - Target half DVD Wanted Size : 2109062 Encoded Size: 2078620 :!: Note: RC-2 found CQ= 81.50 and hit the target. Beta-4 found CQ=89.5 and was a little over (above 2200000) Beta-2 found CQ=80.6 and was a lot under (19000000) Beta-1 found CQ=79.8 and was a lot under (17800000) |
Quote:
Now predict with RC-3, please :!: It should be very close, on every run. -kwag |
Mi results, with RC3.
Test bed movie: Red Planet. Time 102 minutes, 39 seconds. Previously encoded with a CQ of 65.81 (from older version of CQMatic) , which rendered a file size of 709,325KB. My wanted file size, based on CalcuMatic, is 722,734KB. Test runs :arrow: Code:
CQ found Time to predict (Min:Sec) I assume that If I encode with all of those CQ values, the final target will be well within the +-2%, as in the calculations in CQMatic :) Remember that the maximum deviation of the final target should be no more than 2% below, or 2% above target. It's really a 4% "window", trying to keep the final size within that bracket. Seems CQMatic 1.4.00 (release) will finally hit the road later today ;) I just compiled it, and fixed the progress bar to reflect the new 7 phases, and everything else is identical to RC-3. Just waiting for more feedback, to see if we post it, or if there's a need for a RC-4 (hopefully not :!: ) -kwag |
The link is not working :( .
Are thousands of us trying to download it?. I'll try again in several minutes... if there's no problem with the link :?: |
Quote:
Well, here you have the release ;) http://www.kvcd.net/downloads/CQMatic-1.4.00.exe -kwag |
nice! :wink:
|
Thanks ginoboy ;)
Quote:
I just re-did "Rambo III", with another script, and look: Target is 2 CDs, full screen movie (KVCD) Wanted: 1,520,640KB Encoded: 1,541,067KB For a 1.3433 % accuracy :) -kwag |
@Kwag
It´s very cool, Mr. Karl Wagner! :D More one "goal" for you! I´ll download it and I´ll let it a shot! 8) Keep up on work, mate! :wink: My Best Wishes, |
Thanks danpos :)
Please test it, and let me know if it fails somewhere :!: -kwag |
Another test :!:
Just for the hell of it, I encoded (my daughter's DVD) Harry Potter Prisoner Of Azkaban, at 352x340. The DVD is the full screen version. I just wanted to see how accurate the encode was going to be, because I really don't do any 352x240 encodes anymore :lol: But her TV is 27", so 352x240 look ok, if done properly. Anyway, here are the results: Movie time: 141 minutes, 39 seconds. Target: One CD 8O :lol: Wanted file size: 689,974KB Encoded file size: 672,345KB And I'll say NOT BAD, for a 2 hour, 21 minute Full Screen movie, on one CD :!: I only used this script: Code:
Undot() Little sample here: www.kvcd.net/downloads/hp.Sample.m1v -kwag |
Quote:
|
Quote:
Starting now. -kwag |
BTW what is important is to tell in the stricky post (I guess you updated it with new release) is that new engine works on a random sample and 2 laucnches won't give the same value. So if an encoded is over to far from the target, just restart a CQ guess and the new value will have great chances to be the good one.
|
Quote:
And it's very possible that CQMatic could fail, if it gets in that non linear range of TMPEG, and will produce a file size much more that the 2% wanted :!: But the chances are now much lower than in previous versions. It's really a nightmare to predict in that area :roll: Edit: Sticky updated with note. -kwag |
@Dialhot
Result of encode at CQ=69.54 File size: 714,913KB ;) Which clearly explains that the area of 65.x to 69.x is almost flat :!: Look what hapened on Harry Potter, on two separate runs: CQ = 69.384. File size: 629,105KB CQ = 70.440. File size: 672,345KB The CQ difference is only 1.056, but the file size difference is 43,240KB :!: And that my friends, is what I call a VERY sloppy CQ curve in TMPEG :x The only way I think that I could correct this in CQMatic, is charting a complete CQ curve, in steps of .1, and then depending on the final calculated CQ value, compare the value to the chart, and adjust it so it doesn't overshoot the file size. But the problem is that every version of TMPEG has a different CQ curve, and this would be a nightmare to maintain. So my advice is: If your file size is way off, run CQMatic one more time. Chances are you'll get the correct file size on the second run. -kwag |
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.