Single Pass will be back in GK 0.29, but question is

[len0x]

Which mode of sigle pass would be more usefull: quality based or bitrate based?

I personally think quality based is the way to go, just wanted to check if everybody agrees...

[Balm]

IMHO quality based is more usefull.

Cu Balm

[len0x]

Is it still usefull to have credits encoded separately for 1 pass encoding, I wonder?

[manono]

Quality based, definitely.

And being able to still encode end credits at a higher quant would also be useful.

[idanm19]

I think also that quality based 1 pass would be the best..

i also think it will be usefull to encode credits seperately also for 1 pass encoding, if you choose high quality for the movie, you would still want to save some space by encoding the credits at low quality...

p.s. if I want constant quality, more then one pass would make any sense ?

[Balm]

i also think it will be usefull to encode credits seperately also for 1 pass encoding, if you choose high quality for the movie, you would still want to save some space by encoding the credits at low quality... That is also my opinion. :)

Cu Balm

[cyberyeye]

Please don't forgot XviD user...

1 pass - quantizer

sometimes this encoding mode could be veeeery useful "when the size is not a matter" lol

[len0x]

Originally posted by cyberyeye
Please don't forgot XviD user...
1 pass - quantizer


well, you either have 1 pass quant or 1 pass quality based. you can't have both :) But opinions on which mode is more useful are welcome.

[DaveEL]

1-pass quality based can be used as one pass quant if you set the quality level correctly so if you can only support one quality based is the way to go.

DaveEL

[len0x]

Originally posted by DaveEL
1-pass quality based can be used as one pass quant if you set the quality level correctly so if you can only support one quality based is the way to go.


that's what I thought...

[jkwarras]

1 pass Quality based IS the way :) I always do that trying to reach a certain size to fit in 1 CD with XviD. I have to do the maths manually (running a comp test avs and then multiply, blabla as that was discussed over here sometimes ago: http://forum.doom9.org/showthread.php?s=&threadid=44414). I hope my dreams are comming true but i have to be sure: are you talking about using 1 pass Quality based in Gknot and still achieve a desired filesize, and all this automated and calculated by the application?:eek:

[len0x]

Originally posted by jkwarras
I hope my dreams are comming true but i have to be sure: are you talking about using 1 pass Quality based in Gknot and still achieve a desired filesize, and all this automated and calculated by the application?:eek:

Actually, no. What you're asking is to determine the quantizer (or quality) at which the desired size is archieved, right? This only possible if:

1) Comptest is made.
2) It is accurate.

First, comp test is never run automatically in current GK. Second, difference of comptest results to actual compressability can be easily upto 5%, so this makes 35Mb per 1 CD! Are you willing to accept this kind of oversize or undersise ?

P.S. But idea is nice... :)

[jkwarras]

Originally posted by len0x
difference of comptest results to actual compressability can be easily upto 5%, so this makes 35Mb per 1 CD! Are you willing to accept this kind of oversize or undersise ?

If oversized can always recompress credits or reompress audio, but i admit this is unacceptable for an automated application like Gknot that target an specific filesize.

[P.S. But idea is nice... :) [/B]

I know, that was all about: a dream :D

So in clear: there's no a way to determine quite accurately a final size for a 1 pass quality (or quantizer) based, without running a 100% first pass? In the best scenarios a +-5% error prediction. And b-frames increase even more the % of error in prediction.

I thought someone from the gknot development team did discoverd the magic "formula" ;) (do we said that in english?)

[len0x]

Originally posted by jkwarras
So in clear: there's no a way to determine quite accurately a final size for a 1 pass quality (or quantizer) based, without running a 100% first pass? In the best scenarios a +-5% error prediction. And b-frames increase even more the % of error in prediction.


Well, if you increase comptest size to 10% or more, then you'll get error rate +-2%, which is still 14Mb. You can do an experiment by yourself - do a comp test with 10% and then calculater quantizer like this:

average_quant = 200/comp_test_percentage (in full %)

and do single pass encoding with it manually and check out the size afterwards...

[jonny]

To find the quantizer/quality to hit a target size, a possible method could be this:

- Run the size prediction at quant=2
- Use the above formula to calculate the new quant (for hitting the target size) and run a new size prediction encode
- At this point, running a series of size prediction encodes to find what is the quant/quality value nearest to hit the target size (using something like the Newton method for the search)
(an easyer method could be a simple binary search, starting to quality=50%, but the above method will surely require less encodes)

In mpeg2 something like this already exists, seems quite interesting to me!

I've started writing an app to automate this, but atm i've stopped since i'm working on other stuffs too (when i try to do too many things at the same time the result is doing nothing ^^), so if you are interested in doing something like this and/or need more info...

PS: some problems exists, for example in XviD the quality can be only an integer value (this limits the search a lot)

bye
jonny

[jkwarras]

Originally posted by len0x
You can do an experiment by yourself - do a comp test with 10% and then calculater quantizer like this:

average_quant = 200/comp_test_percentage (in full %)

and do single pass encoding with it manually and check out the size afterwards...

I will, thanks :)

[len0x]

Originally posted by jonny
- At this point, running a series of size prediction encodes to find what is the quant/quality value nearest to hit the target size (using something like the Newton method for the search)
(an easyer method could be a simple binary search, starting to quality=50%, but the above method will surely require less encodes)


I'm not sure I get it - your series of prediction encodes cannot be 100% accurate anyway, which makes no sense to run more than one comp test... Or I'm missing something ?

[Latexxx]

Kvcd.net has a pretty good filesize prediction program for tmpgenc/mpeg-1/2( http://kvcd.net/forum/viewforum.php?f=64 ). Maybe you should contact their admin Kwag. It might be possible to tweak those methods for mpeg-4.

[jonny]

The problem is that this formula:

average_quant = 200 / comp_test_percentage

Introduce a second level of error, to give you an idea:

http://jonny.leffe.dnsalias.com/doom9/test.gif
(some old tests with DivX, red, green, blue, black are different clips and comptest is calculated with 100% of the clip)

So, while can be used as raw approximation to find the ave_quant, could lead in a bigger final error when used to hit a target size (i'm not able to give you numbers here, but probably looking the graph will give you an idea)

[len0x]

Originally posted by jonny
The problem is that this formula:
average_quant = 200 / comp_test_percentage
Introduce a second level of error, to give you an idea:


true, but I think since you can't get correct prediction anyway - it's a bit pointless to do the search. It's like: there is no difference between 710Mb file and 720Mb file if you want to fit it on 700Mb CD, right ? :)

[jonny]

I know the error i can obtain with a size prediction, i dunno what is the error with the above formula (so i can't tell if the difference will be 10MB or 100MB in a real case).
Perhaps you could implement a simple method using the formula and wait the users post results/experiences :)

[jkwarras]

Originally posted by jonny
Perhaps you could implement a simple method using the formula and wait the users post results/experiences :)

Good idea. A think a lot of people around here (like me :)) will test a "beta" test version with such a feature: 1 pass quality based to achieve a certain size. I know nothing about programming but maybe if we could send to developpers a file created by gknot with:

- Encoding settings (video codec (bframes, vhq, psy, blabla), audio settings)

- Desired size and achieved size: Difference (error prediction)

Maybe this will help to create a database (statistic) from differents codecs and settings and lenght of movie (for my experience the error prediction changes a lot between differents movie lenght). I think this way maybe the final error could be reduced.

I don't even know if this is possible, and if it's useful at all. Only an idea. But i think what jonny said is a good idea :)

PS: excuse my english is too early this morning :(