new tool PerfectXviD helps to get best setting for alt-curve

[TheUnforgiven]

i am trying the stat file thing now..

@LigH
the solution for ur problem is in ur mail now.

[TheUnforgiven]

ver 0.5 changes:
-now process the stats file no need for the debug log file.
-instant results (lightning speed)
-calculates bits/(pixel*frame) of the first pass.

get it from here:
http://www.everwicked.com/forums/showthread.php?s=&postid=8333#post8333

[LigH]

Oh wow - just that you created a working version for my DebugView format, I don't need it anymore :D - But reading stats files is obviously better, as you discovered for yourself. I think I'm just about to understand your tool, and I wouldn't be surprised if that technology will become included in any upcoming all-in-one tools or even XviD codec versions (when the Sigma War is over one day)!

[rui]

Great work!

I think that one way of helping xvid is continuing with our efforts to help to develop ways of making even greater encodings with it.

[milan]

I've implemented idea from PerfectXviD into ffvfw and there is graph instead of list of numbers.
When I did this I tried to do something better: complete second pass simulation. It is very fast, because no compression is done and ffvfw just guesses second pass frame sizes based on first pass quantizer and frame size and requested second pass quantizer. This method is not very exact, so simulation results aren't exact too, but I think they can be helpful.
If you want to try this, you can download preliminary ffvfw binary from http://cutka.szm.sk/ffvfw/ and be sure you read the warnings about this alpha version.

[rui]

Well, i have been thinking (don’t worry, i didn’t saw any smoke coming out...:D) about the alt cc. parameters.

In the high parameter it says distance from the average frame size where the minimum relative quality will be applied
In the low parameter it says distance from the average frame size where the maximum relative quality will be applied

This are the parameters that i want to get, after configuring the alt cc. That is, after the 2nd pass encode, i want my avi to be created following the parameter i indicated the codec to steal bits (that’s the high setting-indicates the distance that the codec is allowed to go to get bits from those big frames, that’s why it’s called distance from the average where minimum relative quality will be applied), and the parameter that i indicated to the codec to atribute bits to small frames (that’s my low setting-indicates the distance that i want the codec to atribute bits to the small frames, so is the distance to the average where max quality will be applied).

BUT, i’m not sure if this line of thought is correct. If not, all this post is going to the trash can ;)

So, after analisyng the report that PerfectXvid 0,5 gave me:
PerfectXviD ver 0.5 by TheUnforgiven
unforgiven@soon.com

Total frames = 3570
eff. bits/(pixel*frame)= 0,797
3440 Delta-frame and 130 Key-frame

Key frames are excluded from the following stats :

Average frame size = 17.478 byte
Max frame size is +270% over the average = 64698 byte
Min frame size is -99% under the average = 101 byte

+275%
[ 2 frame 0,06%
+250%
[ 2 frame 0,06%
+225%
[ 14 frame 0,41%
+200%
[ 24 frame 0,70%
+175%
[ 53 frame 1,54%
+150%
[ 45 frame 1,31%
+125%
[ 59 frame 1,72%
+100%
[ 172 frame 5,00%
+75%
[ 140 frame 4,07%
+50%
[ 307 frame 8,92%
+25%
[ 559 frame 16,25%
--- Average frame size --- { 29 frame 0,84%
[ 898 frame 26,10%
-25%
[ 718 frame 20,87%
-50%
[ 209 frame 6,08%
-75%
[ 209 frame 6,08%
-100%

This are the results that i currently have in my source, not the ones that i want in my final avi. That’s why i will configure the alt cc, so i can change this, so the bitrate is distributed more accurately. Give bits where they are needed and take them from where it has loads of it.
One can see that the max frame size above average is 270% bigger, and the minimum frame size below average is around 99%.
If my previous interpretation mentioned in the begining of the post is correct, then i will config high at 270%, and low at somewhere near 90%-100%.
That’s were there are more doubts: the configuring of the low parameter.

As always all critics anybody has will be very welcome. I'm not sure if what i wrote is the truth. That's why we are all here, right? ;)

[gldblade]

>then i will config high at 270%, and low at somewhere near 90%-100%.

I think you've gotten it backwards. I think high should be 100 and low should be 270.

High pass sets a minimum frame size and low pass sets a maximum frame size. Following that and what you said here:

Max frame size is +270% over the average = 64698 byte
Min frame size is -99% under the average = 101 byte

Low pass is 270, high pass is 100.

[rui]

Well, i will try your settings and see what happens.

But i just tried Milan's new ffvfw, and the simulation mode works very well, at least for the small tests i have been doing. Only it has to be done outside of Vdub, or it will crash Vdub. But after experimenting with it, i take note of the values and then open Vdub and config the alt cc for 2nd pass.
In my The Replacements trailer test, it almost hit in it's predicted quantizers in respect to what i got in the end. :)

This could revolutionize the alt cc. choices!

EDIT: Hum.. My final average quantizer in one test was 7,2, but the simulation predited to be 7,95. A bit off, but nevertheless this new simulation mode is very promissing.

[iago]

@gldblade

Originally posted by gldblade

I think you've gotten it backwards. I think high should be 100 and low should be 270.
High pass sets a minimum frame size and low pass sets a maximum frame size. Following that and what you said here: Low pass is 270, high pass is 100. Actually I doubt that your interpretation reflects the situation here, and imho "you" have gotten it backwards. High/low values do not represent the min/max framesizes, but the distances (%) from average framesize where min/max relative quality will be applied as rui quoted. Maybe you've confused it with nandub high-pass/low-pass settings ;).

With the above report file results, I'd set the values as rui does: high:270/low:100

regards,
iago

[OUTPinged_]

@rui

Average frame size = 17.478 byte
Max frame size is +270% over the average = 64698 byte
Min frame size is -99% under the average = 101 byte



Try 125/50 for distances for that encode. Look if quantizers will be distroed better in that case.

[Koepi]

I still think high 500 / low 90 will give you a far more linear scaling experience - together with automatic min qual and strength at ~30 ;)

*hide*

Ah, and I think iago is right, don't mix up high/low distance with high- / low- pass like in nandub, it could give very strange results :)

Best regards,
Koepi

[iago]

To everybody,

I realized that the post I'd sent as reply to rui's interpretation of the high/low distance parameters was just mistaken, so it went to trash! ;) Those who have read it can forget it right away! ;)

best regards,
iago

[gldblade]

Oops. :p

Well, I guess it's a good thing I haven't tried this tool yet, otherwise I would have wasted quite a bit of time.

[milan]

Thank you for testing.

Originally posted by rui
Only it has to be done outside of Vdub, or it will crash Vdub.

It's fixed now.

[OUTPinged_]

glblade, there isn't anything wrong with tool.

it just gives you a framesize sheet.

"good settings" part is in planning stage :-)

[FiW]

:D
http://ukbdelo.ru/admin/altcc.gif

[gldblade]

glblade, there isn't anything wrong with tool.
it just gives you a framesize sheet.
"good settings" part is in planning stage

Well, I didn't say there was anything wrong with the tool. I meant I would have wasted time encoding with the wrong settings.

*EDIT*

Ah, I understand that graph now.

Yes, people, I'm stupid. :) I'll just quickly go back to obscurity now...

[rui]

IMHO the "tool" is great.
In my tests, the predicted quantizer distribution curve almost matches the final quantizer distribution curve, in spite that the average quantizer isn't exactly the same (in almost all cases i get a lower than expect average quantizer).
It allows one to experiment diferent settings and see the results almost instantly.

[TheUnforgiven]

@milan
great job
i sent u a PM, check plz

[rui]

Milan, I tried to experiment using your libavcodec, but always in the 2nd pass it crashes Vdub.
The only settings I changed were the quantization to MPEG, but it crashes also in H.263. All the rest was at default. It crashes both using b-frames and not using them.
But, like I said, only in the 2nd pass. If I try to encode using both quantizer and quality modes it works ok, even using b-frames.
I have WinXP Pro, AMD XP 1600+ OC to 1900+ (the problem isn’t from here), VIA KT133A chipset, Nvidia4 4200 Ti, all with the latest official drivers.
Decoding the resulting avi using your ffdshow seems fine.

Sorry to TheUnforgiven because this isn't related with his thread :o

[milan]

Second pass was broken. It should be fixed now, but it seems another problem is there... I will try to fix it today. Sorry, I think I should test it more before releasing it.

[crOOk]

I'd really like an option to cut off the credits. You could also add support for the debugview file format again. Thanx

[TheUnforgiven]

@crOOk
i'll do the credits soon. but y do u need the debugview format again? it is much slower.

[Didée]

Another suggestion, of which I think it could be quite useful:

A counter of how often the quants switched from 3 to 4 and from 4 to 3.

Koepi made a post lately, in which he mentioned that every switch from h.263 to mpeg quantizers - and vice versa - costs 140 byte extra!
(Man! I wasn´t aware of this - was it ever mentioned before?)

So, if we knew from 1st pass how often such switching happens, we would have some hint if, for the actual encoding, modulated quants are worth it, or if it would do more harm then good.

I´m no coder, so I can´t estimate how complicated (or easy) this calculation would be.
But the more info one can get, the better ...

[crOOk]

@TheUnforgiven
Because you could cut off the credits in the log file with a text editor.

[TheUnforgiven]

@crOOk
i'll do the credits when i come back from a short trip (2 days).
the older version is still available u can use it temporarly.
@didee
any thing with quantizers requires 2nd pass simulation. ask milan for that cuz he's doing that from inside the codec (using the codec stuff).

[TheUnforgiven]

-just adds the possiblity to ignore the last x frames (credits).
get it here:
http://www.everwicked.com/forums/showthread.php?s=&postid=8495#post8495

[Shayne]

My understanding of alt curve was to rob from the rich to give to the poor. Take bits from high bit rate sence and give them to the low so that a more even quality is obtained.

Therefore to look at Purrfect xvid and assign high distance at a value above any frames makes little sense to me (please correct me if i am wrong since i am a little confused about the whole alt curve). Should you not at least set 10 percent of the frames to distribute to the low (some percentage anyway). If no frames can distribute down whats the curve compression really doing?

For me Koepi's defaults are fine and previous testing of alt curve indicates minnor quality improvements are possible at the pain of alot of testing and interupts in encoding.

PS this does have promise plz put a big <---- at the locations of low and high that should be used.

[neo_born]

Would someone like to explain how to use this tool and what to do with the info that it gives me ....step by step would be nice...though am not a total dunce!:D Did I mention ..pleeeeeeeease?

[Koepi]

neo_born,

save us the time and _READ_ through this thread.

You seem to have the attitude that education is for losers - but you're mistaken, I won't tolerate this lazyness as long as you request much work from us (to answer that "request" of yours would take up at least several minutes).

READ the threads you're posting in. _The whole_ thread.

Koepi