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 :?:

TmpgEnc Plus 2.512.52.161, WinXP.

That should be fine. I'm on XP too, but TMPEG 2.520 ( 2.512 should be ok too )
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...

Not a dumb question at all :!:
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

Exactly :!:

:imstupid:
-kwag

Here they are :roll: :
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.

excuse me.... :wink:

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?

Is your source range cleared :?:
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 :)

Yesterday i had a similar idea:
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

Hold on :!:
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

beta 6 test :

5 tries, then he found a cq of 51,50...
encoded same movie with 57 as cq, filesize (only videostream) was ca. 840mb i think , instead of 685...so the cq could go right!

don´t have the bug with the loop

What TV-System do you have :?: PAL :?:

Grab it: http://www.kvcd.net/cqmatic-1.0b7.exe :!:

-kwag

Testing right now, thx :P
I'm sorry but i'll be offline in ~10 mins. Hopefully another user has the same problem as i have :oops:
My girlfriend has no internet connection at all. Thats the next thing i'll change :D

CQ's: 60, 57.38, 56.07, 55.41 ...

The connection, or your girlfriend 8O :lol:

-kwag

yes i have pal (germany)

well, beta6 gave me a cq of 51,50, whichs seems to be realistic , but manually i got an cq of 54, well must check it...

will test beta7 with shorter movies to get faster results, which i can post :)

with versions 1.0b6 and b7 the CQ increase from
CQ63,10 to CQ63,62 ,just the same final prediction for each.

remeber,i got perfect final size 290mb with CQ63!

:!:

:mnkypile:
I'm glad my girlriend doesn't watch. She would do this: :BangHead:
I just phoned her to get 15 mins....

Hi Jorel,
great results. How many tries does CQMatic need to find final CQ :?:
You post your results sooo fast 8O
Mine takes about 5-10...

Not anymore with BETA 7 ;)

-kwag

running 9th at the moment and still not finished. Maybe because of the short video length.

Yes. What are the CQs being shown :?:

60, 57.38, 56.07, 55.41, 55.08, 54.92, 54.84, 54.80, 54.78, 54.77, 54.66, 54.66....stuck again.

I'm offline now, sorry. See you tomorrow :D

my sample is short and i got the result after
CQMatic search only 3 times for final prediction.

:!:

well as i can see now, beta7 is giving me a LOWER cq then beta6 :?: :?:

beta6 : 51,50
beta7 : 48,18

Your CQ should be no lower than 0.25 difference from previous :!:
So if your last CQ was say 62.50 and your current is 62.74, your final CQ is 62.50
Does that difference match your predicted CQ values. It has to :!:

-kwag

found sth in tmpeg, the aspect ratio was another then in the test with beta6!

testing now with THE EXACT SAME settings like beta6...

perhaps this was the reason why my filesize was always much lower then i expected and wanted?

í´ll do a couple of tests now...

That's weird :!:
It should have stopped after 55.08, 54.92 because Abs( 54.92 - 55.08 ) = 0.16 which is below 0.25 (the trigger point) and encode at 55.08 :roll:
I'm encoding something now to verify this. Unless my Abs (Absolute value) is screwed up :!:

-kwag

my result :

beta6: 51,50
beta7: 51,18

now EXACT same settings, so with another aspect ratio, i got a lower cq (perhaps the reason of my problem with my filesize?)

well, will take this cq now, and encode it as 16:9...