PDA

View Full Version : compressibility thresholds in autogk


sapient
9th February 2005, 03:42
Is there a way to tweak the compressibility thresholds used by autoGK?

len0x
9th February 2005, 14:52
No, but why do you need that?

sapient
9th February 2005, 19:35
I think autogk tends to use higher compression ratios than I would like.
For example getting a compressibility test result of around 110%, it drops both b-frames and uses the mpeg matrix, resulting in a new compressibility ratio of around 75%. That's too low for me, and without good reason. It could have only used the sharper matrix, resulting in an almost perfect encode, which I would greatly prefer.
Since everybody might not feel the same way, a way to chose one's own thresholds for enabling or disabling various features and resizing would give the program some more flexibility.
I like autogk because it can start encoding in just a couple of minutes compared to the half hour it takes to tweak gk for example, but it's too inflexible. I don't think anyone would mind a longer first time setup, especially if there were some good default values, in exchange for greater flexibility.

len0x
9th February 2005, 22:06
Originally posted by sapient
a way to chose one's own thresholds for enabling or disabling various features and resizing would give the program some more flexibility.

Yes and uneccessary complexity. How would one know what to choose there? We'll be back to GK times when you have to read stuff like "choose this BPP value prior compressibility test and then aim at another value afterwards". Right now AutoGK (well mostly me) decides what's good for the user - if user knows what's good for him and can't accept what AutoGK produces now then he should spend some time manually in GK and do it. I will not sacrifice the idea of "Auto"GK to make users of regular GK happy and never was going to.

sapient
10th February 2005, 02:58
Having some more hidden options that the regular user whould not even see would not compromise the idea of autogk, I think.
The advantage of autoGK over GK for someone who knows how to use both is time spent for every encode. In autoGK you would tweak some options one time only and be able to start encoding every other time a lot faster than using GK.

In short, I 'd like it if all or most of autoGK's settings were stored in an *.ini file or something, so that anyone who wanted could change them, but where someone who didn't want to deal with them could ignore them. That would keep everyone happy.

Thanks for paying attention, anyway...

sapient

fewtch
10th February 2005, 03:28
Originally posted by len0x
Yes and uneccessary complexity. How would one know what to choose there? We'll be back to GK times when you have to read stuff like "choose this BPP value prior compressibility test and then aim at another value afterwards".
Not necessarily; wouldn't that be up to you, and how well you hide complex operations in simple sliders, radio buttons, etc?

Just IMHO: AutoGK could keep all the same defaults, expose more functionality, yet do it in a way that seems simple even to a beginner (provided you were thinking like a beginner would when you write the interface to it ;)). (Or like Sapient says, keep all in an .ini file).
Originally posted by len0x
I will not sacrifice the idea of "Auto"GK to make users of regular GK happy and never was going to.
You wouldn't need to; keep it all on hidden screens. If you like, don't even document it -- just tell us here what key to press to bring up the options...

It's your program, of course. Here you are though, getting feedback from actual users of your program, not just people who you think might be using it. I never once even tried Gordian Knot, but am interested in continuing to use AutoGK (and think more functionality exposed would be nice).

len0x
10th February 2005, 12:07
At some point there will be a config file with some options exposed (which ones to be determined later), but atm I have huge todo list already.

P.S. Current hidden options are absolutely necessary to process special type of source that AutoGK wouldn't be able to handle properly otherwise. I intend to keep it that way for the time being.

jggimi
10th February 2005, 13:13
Moved to development.

hAzEr
13th February 2005, 08:35
Kind time of day. Excuse for English language... I am solidary with sapient and I use AutoGK from for absence of a free time - have put films on compression and have left for work. I do not have not enough functionality. I compress DivX 5.21 Pro and AutoGk Encode Performance establishes in Standart and I would like Slowest. Dear developer I understand your position and I appreciate your work. I want only to ask you to pay attention on увеличивающися a stream of requests that that to change.