Maybe theres a hint/solution. When using CQMatic i've let CQMatic open and only loaded the new project file again (with different project settings).
I've closed CQMatic and reopened it again and the bugs disappeared :!: Now it seems that its searching the right CQ value also with CQ=40 at start. I'll keep an eye on this. EDIT: Dump question, but are you initializing values when a new project file is loaded :?: |
Quote:
|
Quote:
OK, this is on my top priority for today. I just wich I could reproduce the behaviour here, but I havent :roll: Anyway, back to the source, and hopefully find something today :!: Quick idea :idea: Try setting your initial CQ to 100. I want to know if the problem is related to starting from a low CQ on the first start on a increasing scale, instead of starting very high on a decreasing scale. This means a LOT for my internal algorithm :!: -kwag |
Hi Kwag,
Starting CQ at 100 brings illegal stream format error. With 90 its working. Well, also with a restart of CQMatic the CQ stucks at 43 when starting with 40, but the error where it is encoding directly after one prediction and taking starting CQ is gone with the restart. Have you read my (edited) post above:?: I'll post the results with CQ=90 later... |
Quote:
That's exactly where the problem must be :) Every test I've done, has been running CQMatic, and then exiting. So I haven't encoded a second movie without exiting CQMatic. So obviously, it's variables with previous values. Verifying this, and then BETA 6 will be posted ;) -kwag |
That would explain why it was directly encoding after one prediction :D
|
Quote:
:imstupid: -kwag |
Quote:
90, 80.12, 75.18, 72.71, 71.47, 70.86, 70.55, 70.39, 70.32, 70.28, 70.26, 70.25, 70.24, 70.24, 70.24 .... Right CQ should be about ~60. |
Quote:
prediction results using CQMatic 1.0b5 with small source. souce 31 minutes,average 1070,wanted size 290mb one project for each new start CQ and the same source! starting with CQ100 :arrow: don't work, "CQ ABOVE watermark" starting with CQ90 :arrow: give final CQ62,96 starting with CQ60 :arrow: give final CQ63,10 starting with CQ50 :arrow: give final CQ63,15 then like J.Lennon in "good morning" from sgt peppers sung: "nothing is change,still the same, i've got nothing to say but it's ok! good morning, good morning SIR! 8) |
CQMatic 1.0 BETA 6 is up :!:
http://www.kvcd.net/cqmatic-1.0b6.exe Fixed: Cleared some variables that were clobbered when running CQMatic more that once, without exiting. Added: Exit condition when last CQ = next CQ ;) Please try it, and report if it does exit now, and doesn't hang in a loop :!: -kwag |
hi guys :)
well, hope you can answer me this question :) cqmatic seems to work properly, tries 4 times to find the right cq, ok... but then, the file size is much too small , and i think of the following : i use pal sources, and then, i encode it as 16:9 ; perhaps the black borders are the thing, why the filesize is getting too small ? anyone had this problem too? |
Quote:
That is, start frame = 0, end frame = -1, and Cut Edit list is cleared :?: -kwag |
yes of coure it is :)
check it every time! |
If BETA 6 still locks in a same CQ value, please let me know immediately, because then the problem is a floating point rounding comparison error, and then I know what to do next ;)
-kwag |
Hi tigger,
Is your source a .d2v or avi (MPEG-4, DivX, etc. ) :?: |
testing it now :)
|
Quote:
We already had the same problem once. The OS is localized with , . ; etc. I've just tested this and found no difference. But maybe there is one. Maybe thats the difference in accruacy we have :?: EDIT: BTW, Beta 6 is quicker finding right CQ... |
Let's see it BETA 6 did fix the error. If not, the problem is clear. The CQ values you see in the log, are actually truncated to 2 precision digits. So you may see a CQ of 62.12, when it's actually 62.1234567 etc. Obviously, I can't compare "Last CQ = Next CQ", because the chances of hitting a 62.1234567 = 62.1234567 are almost endless. And that's the problem with the CQ scaling. It's not linear, and once I get close to the target, CQMatic will start comparing something like 62.12345 and 62.12999 which are different, and never end :!:
So I'm fixing that to take into consideration, if the floating point difference in CQ is < 0.2 (that's just an example), exit with a CQ found flag, and start encoding :) -kwag |
Well, still have the same error. Repeating CQ value is now 54.76 starting from 60.
I think that floating point issue could solve that, thx :D |
Quote:
I'm finding the correct treshold to break out. I'll post BETA 7 (Hopefully the last BETA for this issue :!: ) Keep an eye here, in the next few minutes. -kwag |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.