(XviD) Statsreader

[Koepi]

Ahoy,

I needed a little distraction (right word? dunno...), so I coded yet another stats file viewer.
And as I always wanted to go back to the roots again, I built in an amazing feature:

_linear curve compression for external xvid compression mode_!

Just enter your target filesize in MB, hit the "save as" button, give that baby a name and press "ok".
After that, you'll get the stats file for "2nd pass - external" mode in XviD.

Sure, you can use GKnot.

But this is
a) my first trial of doing that and
b) just 11kb big (zipped 8kb). No huge 7MB downloads just for a curve scaler... ;)

I hope you like it and send me plenty bug reports!

(Until now it's not at all tested. maybe it totally messes up. But the curve is nicely scaled at least ;) )

Best regards,
koepi

[neo_sapien]

Cool :)

Will this one increase the efficiency of bit distribution? Give us an even better quality picture? ;)

EDIT~w00t, apparently I'm a senior member now.

[Koepi]

Depending on your preferences this can give you better quality, right.

At least the quality should be more constant...

The nicest thing is, that quantizer ranges still get applied, and low bitrate situations get some compensation, too.... xvid's 2pass stuff rocks :)

I'm doing the marix (again) and let's see, I think it'll improve it.

Regards,
Koepi

P.S.: since it's so small I'll include it into my next binaries - if there will be any...

[iago]

@Koepi

Great news :). Gonna test it right away with Fight Club (as usual ;)).
BTW, are you using default altCC in your Matrix test with the external stats file?

thanks,
iago

[ookzDVD]

@Koepi,

Thank you for the tool,
even _xvid_ is stopped atm, but the tool is still on going. ;)

[iago]

@Koepi

I get this error message in VirtualDub when initializing the second pass, both in fast recompress and full processing mode. (Using avisynth 2.05, btw.)

regards,
iago

[Koepi]

Strange error, dunno where it comes from.

I manually start both passes and didn't check the job control on that...
how are you going to compress the stats file, output it to another filename (!important! XviD doesn't forgive if the first pass and external compressed stats file are identical ;) ) and in the same time start the second pass? ;)

Try entering that manually and start the jobs by hand, see if that helps it please!

And yes, I use all the rest my default settings. I did the credits at constant quant. 8 in the first pass, in the second pass it's not selectable - and that is a good sign :) I still have ~4hrs to wait from now to see the results, but I'm already impatient. I testet it on the first 2000 frames of matrix and those were the best results I got that far....

Thanks for finding the tool useful :)

Best regards,
Koepi

[iago]

@Koepi

That's the exact procedure I follow: I open the first pass stats file in statsreader, enter my desired filesize (634mb in this case), then I hit "save as" and save the file under another file name. Also, the tool doesn't automatically give the .stats extension so I type it as well: eg. "fightclb-ext.stats". (I also get the "scaled down to ...." confirmation.)

Then I go to XviD 2pass-2ndPass Ext. for the second pass and select the scaled file as my stats file, etc. The usual procedure I follow everytime ;).

Anything wrong with that procedure?

thanks,
iago

[Koepi]

uhm. nope, that's absolutely correct :-(

I have no idea where this comes from.
Did you check the file, if it's the same size as the first pass stats file?

But if you do it that way, I don't know why vdub complains about job control. Please delete your *.jobs file in your virtualdub directory and see if this helps!

Regards,
Koepi

EDIT: I just saw that you wrote "..and I choose that file as my stats file" - you have to just _add_ it as the file at the bottom which defaults to "\videogk.stats". The other field still has to contain your "original" first pass stats file!

[iago]

@Koepi,

I don't know how but it's OK now :). I think I messed up something before. Anyway, never mind ;), since it's working with no problem now! I'm looking forward to see the results too :).

best regards,
iago

EDIT: yes you're absolutely right, that's where I went wrong! ;) Stupid me...

[Koepi]

[1096] Quantizer distribution for 2nd pass:
[1096] Q:2:449
[1096] Q:3:76435
[1096] Q:4:96210
[1096] Q:5:12124
[1096] Q:6:949
[1096] Q:7:16
[1096] Q:8:3
[1096] Q:9:1
[1096] Q:10:1

Looks good to me... the "weapons rack" scene looks ok for my taste, but I have to check the whole movie. I'm amazed as there's still some noise of the source to see :)

EDIT: ouch. the credits stuff didn't work out, file is 9 MB oversized.... hrmpf.

Regards,
Koepi

[rui]

Well, after some experiences, i came to the conclusion that koepi's settings and using his new tool for external 2nd pass, gives us lower absolute quantizers. But using milan's simulation mode and choosing alt cc. parameters from there, but still using koepi's external 2ns pass tool, i can achieve higher number of frames with lower quntizers.

I didn't thought that the alt cc parameters still had influence in the encode, but they do.

I will explain:

##### koepi's settings:------------- milan simulation alt cc.
quant2 -- 92 ------------------------- 79
quant3 -- 36 ------------------------- 71
quant4 -- 112 ------------------------ 319
quant5 -- 365 ------------------------ 540
quant6 -- 595 ------------------------ 742
quant7 -- 873 ------------------------ 577
quant8 -- 795 ------------------------ 450
quant9 -- 383 ------------------------ 248
quant10 -- 212 ----------------------- 231
quant11 -- 81 ------------------------ 125
quant12 -- 25 ------------------------ 68
quant13 -- 1 ------------------------- 40
quant14 -- 0 ------------------------- 33
quant15 -- 0 ------------------------- 14
quant16 -- 0 ------------------------- 10
quant17 -- 0 ------------------------- 8
quant18 -- 0 ------------------------- 8
quant19 -- 0 ------------------------- 3
quant20 -- 0 ------------------------- 2

Now, all of you will say that using milan's simulation, i got much higher quantizers. True, but look at the number of 4, 5 and 6 quantizers i got. Using both koepi's 2nd pass external tool and milan simulation, i got much higher values for those quantizers. The quantizers from 13 to 20 are there, but in low numbers. Probably one doesn't notice them.
So, i believe is a personal choice. If you want a safe encode, one that doesn't use high quantizers, then use koepi's settings.
If you want to be brave :D, and take some chances, use koepi's tool with simulation mode to get the alt cc parameters. You probably can get access to much higher numbers of frames using lower quantizers, in spite of having also some frames that will use higher quantizers.

As always, critics are welcome.

[Koepi]

I assure you, the high quantizers will be visible.
I thought so too first, but I came to the conclusion that even on frames with "few" information the high quantization is visible.
This is especially true because that information is used to show the next picture...

But thanks for the test! :)

regards,
Koepi

[rui]

Ok, i have to correct some data that i posted in my earlier post. In the test using koepi's tool and milan simulator, i had enabled i-frame boost. Now i remade the test without i-frame boost, and the results are:

##### koepi's settings:------------- milan simulation alt cc.
quant2 -- 92 ------------------------- 95
quant3 -- 36 ------------------------- 57
quant4 -- 112 ------------------------ 327
quant5 -- 365 ------------------------ 528
quant6 -- 595 ------------------------ 650
quant7 -- 873 ------------------------ 583
quant8 -- 795 ------------------------ 539
quant9 -- 383 ------------------------ 271
quant10 -- 212 ----------------------- 231
quant11 -- 81 ------------------------ 122
quant12 -- 25 ------------------------ 72
quant13 -- 1 ------------------------- 33
quant14 -- 0 ------------------------- 33
quant15 -- 0 ------------------------- 18
quant16 -- 0 ------------------------- 6
quant17 -- 0 ------------------------- 2
quant18 -- 0 ------------------------- 3
quant19 -- 0 ------------------------- 0
quant20 -- 0 ------------------------- 0

It uses a little lower quantizers, but still there are some high quantizers. According to the expert (none other than our Koepi :D), these can mean trouble.

[iago]

Originally posted by Koepi
I'm amazed as there's still some noise of the source to see :) That's really interesting and nice. I hope I see the same noise (rather than blocks :)) in my test encode too...

best wishes,
iago

[Koepi]

Well, blocks are there, too. But I didn't find them annoying.

For example, before the guy at the computer hits the "enter" key (it's not the enter key, it's just any key... that key I'm always searching when asked to press it ;) ) and then the scene switches to the "loading program" where the weapon racks scroll in, his hand is full of blocks, but the keyboard is amazing stable and detailed.

I'm testing with h263 quant type on second pass ATM - and I hope I have some better news in that respect.

I think that on such "critical" movies the modulated quantizer type is a big no-no as every switch of quant type takes up 140bytes which could be better spent on the movie itself ;)

Regards,
Koepi

[rui]

About quantization modes: lately i am only using MPEG, even on dificult movies. I prefer the extra detail, and don't mind the little increase in blocks.
For smooth videos, i would go to divx5 ;)

[iago]

Originally posted by Koepi
ouch. the credits stuff didn't work out, file is 9 MB oversized.... hrmpf. Yes, my test finished with 7 mb oversize too ;), but I'm quite pleased with the quality though I used MPEG/Modulated quantization, which I believe will be even better after taking your advice and not switching between quantization type (MPEG/MPEG as rui does for example :)).

Predictability is indispensable to XviD, XviD is predictability! :) Koepi, please solve that credits issue, mate! Cause your tool really works great in terms of achieving better quality ;).

best regards,
iago

[manono]

Hi-

I also came out a bit oversized (aimed for 1301MB and got 1304MB-nothing important) on a movie with no end credits. But perhaps it's also due to having used Modulated Quant for the 2nd pass. I didn't know about switching Quant type adding size either. Assuming that the Modified Stats File is created as a straight percentage of the frame sizes of the original first pass Stats File, with no Motion or Luma Correction applied (unlike theWEF's DivX 3.11 version), then this is just what I've been waiting for.

Thanks a lot Koepi.

[Koepi]

ALL PEOPLE, FULL STOP _NOW_!

:)

Just talked to foxer again and we came up with some issues. Seems like we're getting closer to our target ;)

Ok, this is what is most important:
DON'T use MV hints.

Second:
DON'T use alt CC. OR set it like this: altCC of mrq100 or str0.


Third:
IF you don't use altCC, SET "old" CC low/high to 0 (!!!)

I prefer "payback proportionally". Set the payback delay to something like 10-12 times your framrate (thus 10-12 seconds payback delay).

I'm redoing the matrix _again_ now with second pass h263 quant.
All my problems with stacked up overflow are gone (shame on you, MV hints! why do you have to produce an error which has to be compensated? ;) ) Well, ok, at least that's the reason for _slightly_ worse quality, the mv hints stuff. This is a known issue, but with our games we play here it becomes severe - the effect isn't that bad when doing just straight-forward encodings.

The scene based keyframe overflow treatment is active anyways, so you get the most linear curve possible this way for now.

Ok, if you're not "stuffed up" already, please change your test settings ;)

Thanks again for all your help,

best regards,
Koepi

EDITED: to reflect that altCC can achieve that, too. the important point is NOT to use MV hints.

[Koepi]

Ah, one addition:

In this scenario there _shouldn't_ be any difference between internal and external compression.

Would be nice if you could check for that, too!

Thanks,
Koepi

[Bulletproof]

Lately I've been finding that the CBR mode in XviD works quite well.

[rui]

Humm.. By using default cc with high/low at 0, with no hme, i got this:

Quant 2 Used : 2 Times, Percentage Used : 0.06%
Quant 4 Used : 36 Times, Percentage Used : 1.01%
Quant 5 Used : 296 Times, Percentage Used : 8.29%
Quant 6 Used : 633 Times, Percentage Used : 17.73%
Quant 7 Used : 976 Times, Percentage Used : 27.34%
Quant 8 Used : 881 Times, Percentage Used : 24.68%
Quant 9 Used : 339 Times, Percentage Used : 9.50%
Quant 10 Used : 221 Times, Percentage Used : 6.19%
Quant 11 Used : 43 Times, Percentage Used : 1.20%
Quant 12 Used : 99 Times, Percentage Used : 2.77%
Quant 13 Used : 6 Times, Percentage Used : 0.17%
Quant 14 Used : 10 Times, Percentage Used : 0.28%
Quant 15 Used : 6 Times, Percentage Used : 0.17%
Quant 16 Used : 9 Times, Percentage Used : 0.25%
Quant 17 Used : 2 Times, Percentage Used : 0.06%
Quant 18 Used : 7 Times, Percentage Used : 0.20%
Quant 19 Used : 2 Times, Percentage Used : 0.06%
Quant 20 Used : 2 Times, Percentage Used : 0.06%

Average Quantizer Used for Movie : 7.540

I think that it's inferior to what i managed to achieve using alt cc and your defaults, that i posted earlier. Am i missing something?

[Koepi]

No, but we're testing, right?

:)

Regards,
Koepi

[rui]

Ok, boss, i will keep on testing and experimenting :), and will keep an eye (rather both:D) to any new developments and advices you can come up with.

[Koepi]

Just an observation I made:
You seem to test with a short sample (few thousand frames), right?

This gives you a slight idea how things work, but for propper curve treatment testing you should use a whole movie - one thing that didn't change compared to the nandub times ;)

Thanks for all your efforts!

Best regards,
Koepi

[Koepi]

Hm.

[900] Quantizer distribution for 2nd pass:
[900] Q:2:1322
[900] Q:3:95437
[900] Q:4:84934
[900] Q:5:3960
[900] Q:6:391
[900] Q:7:37
[900] Q:8:16
[900] Q:9:18
[900] Q:10:59
[900] Q:11:14

I'm getting a little annoyed with the time.
Well, I'll code a more precise "scaler" routine and add support for credits, maybe this helps (credits just as constant quantiser unfortunately).

Regards,
koepi

[iago]

@Koepi

Well, the first point, I've never used Hinted ME so far, so the source of my problems is certainly not due to MVH :).

Second, now I'll take your new advices and start a fresh test encode (with Fight Club again ;)), without using external curve compression, setting mrq to 100 with default altCC parameters (medium/500/90), payback proportionally, using a payback delay and max i-frame interval of 10-12 times my framerate (which I already do in my encodes), quantizers MPEG/MPEG and capped as 2-6/2-16, with no lumi masking at all.

Next, I will compare the results (with screenshots maybe) with a previous encode of the same movie encoded with the old routine (strength 30 with default altCC, lumi in both passes, payback with bias) and with MPEG/Modulated quantizers capped the same as above.

I really wonder how the final encode will be in comparison to the previous one. I'll report back the results then.

best regards,
iago

[Koepi]

I compiled a new version of the stats reader which should be a little more precise in downscaling.
Also, if you used fixed quantizer credits, it can be setup to not scale those.
Find it attached...

[Koepi]

Ok, while I started the first pass for my mpeg/mpeg quant-type test, I'm watching my h263/h263 encoding. It looks better without any doubt due to switched off mv hints (main difference: the backgrounds are more stable).

Ok, off for checking more... :)

The mpeg/mpeg test is a little unfair, becaus ethere it can reach the desired filesize (hopefully) due to unscaled credits ;)

Regards,
Koepi

[iago]

@Koepi

So, with the latest version, I'm modifying my test setup ;). Now it is:

"...a fresh test encode (with Fight Club again ), using external curve compression with the new statsreader, setting mrq to 100 with default altCC parameters (medium/500/90), payback proportionally, using a payback delay and max i-frame interval of 10-12 times my framerate (which I already do in my encodes), quantizers MPEG/MPEG and capped as 2-6/2-16, with no lumi masking at all.

OK? :)

regards,
iago

[Koepi]

Ok! I'm looking forward to the results! :)

Regards,
Koepi

P.S.: I#m still a little unsure if the quality boost i can see here is due to switched off MVHints or due to using fixed quantizer type (instead of modulated...) - or the mix of both. I think I'll leave my hands off both in future :)

[rui]

Originally posted by Koepi
Just an observation I made:
You seem to test with a short sample (few thousand frames), right?
Right. It's my favorite "The Replacements" trailer, the most demanding piece of video i can find.
Originally posted by Koepi
This gives you a slight idea how things work, but for propper curve treatment testing you should use a whole movie - one thing that didn't change compared to the nandub times ;)

Thanks for all your efforts!

Best regards,
Koepi
I am sure you are right, but most of the times i am at work, and here i have a p2-350 to work with. The only way of conducting some tests is using trailers or chapters from movies :(

[Koepi]

Thanks rui :)

That's ok with me, I just wanted to mention that you don't necessarily get "the whole picture" with a trailer. Any tests are welcome, don't misunderstand that! :9

Best regards,
Koepi

[Emp3r0r]

I'm testing with Planet of the Apes and using iago's setup. I prefer to use h.263 with bicubic as it seems to produce a better (less noise) picture than mpeg or modulated. I'll post my results tommarrow.

@koepie: how do you generate the Quantizer distribution for 2nd pass Information

[Koepi]

Foxer added some statistical info to XviD's 2pass code, it spits that info out like all other info, capturable via Debugview.

Regards,
koepi

[rui]

Well, regarding the internal vs external results, i made another small test, using default cc and o% high/low, with payback bias. The results are very diferent from those i got yesterday, using payback proportional:

Internal:

Quant 4 Used : 82 Times, Percentage Used : 2.30%
Quant 5 Used : 390 Times, Percentage Used : 10.92%
Quant 6 Used : 755 Times, Percentage Used : 21.15%
Quant 7 Used : 1065 Times, Percentage Used : 29.83%
Quant 8 Used : 824 Times, Percentage Used : 23.08%
Quant 9 Used : 300 Times, Percentage Used : 8.40%
Quant 10 Used : 115 Times, Percentage Used : 3.22%
Quant 11 Used : 23 Times, Percentage Used : 0.64%
Quant 12 Used : 13 Times, Percentage Used : 0.36%
Quant 13 Used : 3 Times, Percentage Used : 0.08%

Average Quantizer Used for Movie : 7.046

External:

Quant 4 Used : 104 Times, Percentage Used : 2.91%
Quant 5 Used : 480 Times, Percentage Used : 13.45%
Quant 6 Used : 892 Times, Percentage Used : 24.99%
Quant 7 Used : 1068 Times, Percentage Used : 29.92%
Quant 8 Used : 717 Times, Percentage Used : 20.08%
Quant 9 Used : 225 Times, Percentage Used : 6.30%
Quant 10 Used : 52 Times, Percentage Used : 1.46%
Quant 11 Used : 16 Times, Percentage Used : 0.45%
Quant 12 Used : 13 Times, Percentage Used : 0.36%
Quant 13 Used : 3 Times, Percentage Used : 0.08%

Average Quantizer Used for Movie : 6.806

So, there is a small diference between internal and external, using Koepi's latest statsreader. It seems that external is a little bit better. Take these results with a grain of salt, because they were achieved using only a trailer, not a full movie.

[iago]

@Koepi and all,

The results I had with Fight Club with the above mentioned test setup using external curve compression and entering credits range in the "statsreader" as well confused me a bit, especially regarding the credits treatment: although the encode came out exactly the desired filesize (hit the target accurately), that is 634mb/649000kb in this case, 16mb of the precious total file size is spent on credits with such a distribution:

Quantizers Used For Credits :
--------------------------------
Quant 1 Used : 106 Times.
Quant 2 Used : 3803 Times.
Quant 3 Used : 24 Times.
Quant 4 Used : 24 Times.
Quant 5 Used : 231 Times.

Well, the quality is still OK, maybe better than the previous routine encode, but 16mb is too much a waste for credits, most of which can be spent on an even better encode.

the exact debugview analyzer results:

DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 1927 Times, Percentage Used : 0.98%
Quant 3 Used : 94801 Times, Percentage Used : 48.36%
Quant 4 Used : 93031 Times, Percentage Used : 47.46%
Quant 5 Used : 6015 Times, Percentage Used : 3.07%
Quant 6 Used : 241 Times, Percentage Used : 0.12%
Quant 7 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.530

Quantizers Used For Credits :
--------------------------------
Quant 1 Used : 106 Times.
Quant 2 Used : 3803 Times.
Quant 3 Used : 24 Times.
Quant 4 Used : 24 Times.
Quant 5 Used : 231 Times.

MPEG Quantization Type Used 200204 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 14 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 4 Used : 2171 Times, Percentage Used : 91.10%
Quant 5 Used : 33 Times, Percentage Used : 1.38%
Quant 6 Used : 179 Times, Percentage Used : 7.51%

Credits
---------

Number Of Consecutive I-Frames : 151

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 1927 Times, Percentage Used : 1.00%
Quant 3 Used : 94801 Times, Percentage Used : 48.96%
Quant 4 Used : 90860 Times, Percentage Used : 46.92%
Quant 5 Used : 5982 Times, Percentage Used : 3.09%
Quant 6 Used : 62 Times, Percentage Used : 0.03%
Quant 7 Used : 1 Times, Percentage Used : 0.00%

Credits
---------

Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 2383
Number Of Inter-Frames (P-Frames) : 193633
Total Number Of Frames : 196015

1.22% of the Movie is Intra-Frames (Key-Frames)
98.78% of the Movie is Inter-Frames (P-Frames)

Size Analysis
----------------

1-Pass Size : 1525443749 Bytes or 1489691 KBytes
Scaled Size : 665047442 Bytes or 649460 KBytes
Actual Size : 659450253 Bytes or 643994 KBytes

Usefull Statistics
------------------
Compressibility : 43.23%
Relative Quality of XviD avi : 56.66%
Absolute Quality of XviD avi : 95.41%


Any comments?

best regards,
iago

EDIT: BTW, 1stPass/2ndPass ratio given by statsreader was 2.338:1, and that's my avisynth script, in which I apply TemporalSmoother(10) to the credits as well:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
mpeg2source("C:\FIGHT\FIGHT.d2v")
crop(4,60,716,354)
BicubicResize(640,272,0,0.5)
Trim(0,196015)+Trim(196016,0).TemporalSmoother(10)

[Koepi]

@rui:

surprising results. But hu, then the stats reader is useful for something, isn't it? ;)

@iago:

Dunno what to do about the credist, in ~2hours I'm in the credits range here, too (first pass: fixed quant 20), dunno if or how it will work.

Hopefully the visual quality is ok?

Thanks for your testing efforts, both of you! :)

Best regards,
Koepi

[iago]

@Koepi,

I forgot to say that I'd used fixed quantizer 31 for credits in both passes and as I said before I entered the credits range in the statsreader too before saving the external stats file.

Yes, the quality is absolutely OK, and (hopefully :)) will be even better imho when the credits issue is solved and the precious mb's spent for credits will be used in the movie itself ;).

Thanks are for "you" man, for this great tool and for all your valuable efforts :).

best wishes,
iago

[rui]

Originally posted by iago
[BThanks are for "you" man, for this great tool and for all your valuable efforts :).
[/B]

I can only subscrive iago's words.

[Koepi]

Ok, my new matrix encoding is through.

The credits don't get scaled by the codec, it stuck with fixed quant 5 instead of 20, thus oversizing the output file when using special credits treatment by a huge amount(26MB in my case).

I'm taking a small timeout for getting some sleep, after that will hack a small fix into xvid and release a new binary with "improved" 2nd pass external support for fixed quantizers (it'll be a hack like this: if credits are checked [only end-credits though], it'll take the quantizer which is given by the credit-frames).

Sorry for this. Still dunno if the scaling is correct after that as I didn't see the filesize when credits started, but the formulars in statsreader should be correct.

Ok, CU soon, and thanks for your support!

Best regards,
Koepi

[Koepi]

I've a "bonbon" for you:

XviD-28082002-1:
- Activated EPZS(^2) motion estimation algorithm.
- Enabled fixed quantizer mode for external compression/credits
- included statsreader in the package, for easier access.

It's experimental, I don't know yet if it works, it#s just a one-line-hack which tries to force a quantizer there. Please check on that (rui? your trailer should be fast to test ;) ).

Thanks & best regards,
Koepi

[rui]

Well, i made the test, but the credits still are encoded at various quantizers :( despite the fact that i configured them to be encoded at 20 quantizer.
But i used the 1st pass made with the prior build, and used the stats file created by the statsreader that you launched today. The one that comes with this build isn't diferent, is it? Could this afected the test in some way?
I will make a test with 1st and 2nd pass, but it will take some time. (my p2-350 is sweating all over :D)

DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 3 Used : 3 Times, Percentage Used : 0.09%
Quant 4 Used : 177 Times, Percentage Used : 5.12%
Quant 5 Used : 706 Times, Percentage Used : 20.43%
Quant 6 Used : 1095 Times, Percentage Used : 31.69%
Quant 7 Used : 820 Times, Percentage Used : 23.73%
Quant 8 Used : 490 Times, Percentage Used : 14.18%
Quant 9 Used : 140 Times, Percentage Used : 4.05%
Quant 10 Used : 22 Times, Percentage Used : 0.64%
Quant 11 Used : 2 Times, Percentage Used : 0.06%

Average Quantizer Used for Movie : 6.362

Quantizers Used For Credits :
--------------------------------
Quant 2 Used : 1 Times.
Quant 4 Used : 4 Times.
Quant 5 Used : 109 Times.
Quant 20 Used : 1 Times.

[Koepi]

Nope, it's the same build.
Damn, i just tested it too.

It's seriously messed up, I've to dig deeper into it :-(

Thanks for the test!

Expect a new version soon. (version number won't change, but I'll announce it here).

Regards,
Koepi

[rui]

Koepi, i don't think that it's so bad. With the exact same settings, this new build got the average quantizer down from 6,648 to 6,362, and it didn't used higher quantizers (the max was quant11, the same as the older build).

So to me this is an improvement. :)


EDIT: for what is worth, i found out that, when using the external stats file, using default cc with high%/low% at 0 is the exact same that using alt cc with the mrq at 100% level.

[Koepi]

New binary is up.

Didn't check whether it breaks anything else, but i coded "safely" so it shouldn't harm anything else. It finally hits the target size for me (requested to downscale to 8MB, it reported downscaled to 8.29MB - which it hit on the spot :) ).

Remember, it only works for constant quantizer credits.

Best regards,
Koepi

...who needs a pause now.

[Koepi]

Ah, nice rui - that's the way it's supposed to be! Nice you mention that.

Still, I don't understand why internal compression gives different result s as external...

Best regards,
Koepi

[iago]

@Koepi

Great ;). Starting the new test immediately :).

ciao,
iago

[iago]

Hello everybody,

Well, the 1stPass of my test encode with the new 28082002-1 (updated) binary (6.UltraHigh, MPEG, lumi masking, quant31 credits) is about to finish.

I'll do the second pass with external curve compression, 6.UltraHigh, MPEG, lumi masking, mrq 100 with default altCC parameters (medium/500/90), payback proportionally, capping quantizers 2-4/2-8 (don't tell Koepi ;)) or 2-6/2-16, and quant31 credits.

Hopefully, if the credits issue is solved and 2ndPass also comes out with quant31 credits :), I'm expecting a real quality boost in the final encode.

I think it'll take me some time to post the results.

now, just waiting :)
iago