[MPlayer-users] mencoder/lameopts aq=<value> ?
Haas Wernfried
amnenion at xover.htu.tuwien.ac.at
Thu Jul 11 12:33:02 CEST 2002
as no one else seems to be interested in this for me quite interesting issue
i just did some more research for myself. attention: i am not a programmer, so
don't flame me for anything wrong. you could have done this yourself and
better ;)
what i might have found out:
{"aq", &lame_param_algqual, CONF_TYPE_INT, CONF_RANGE, 0, 9, NULL},
aq is passed to lame_param_algqual which is passed to lame_set_quality in
mencoder. according to lame sources/include/lame.h:
// internal algorithm selection. True quality is determined by the bitrate
// but this variable will effect quality by selecting expensive or cheap
algori\t// quality=0..9. 0=best (very slow). 9=worst.
// recommended: 2 near-best quality, not too slow
// 5 good quality, fast
// 7 ok quality, really fast
int CDECL lame_set_quality(lame_global_flags *, int);
----------------
{"q", &lame_param_quality, CONF_TYPE_INT, CONF_RANGE, 0, 9, NULL},
q is passed to lame_param_quality which ends up with
// VBR quality level. 0=highest 9=lowest
int CDECL lame_set_VBR_q(lame_global_flags *, int);
in lame.h
so aq actually is quality by algorithm (slow/fast) and
q is actually higher/lower vbr bitrate.
please check this for yourself if you think i am wrong and update the docs
regards
wernfried
On Tue, Jul 09, 2002 at 12:49:45PM +0200, Haas Wernfried wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> hello,
> i think i might found out what this value is being used for:
> if you lower the value (aq=0), encoding time rises, with high values (aq=9)
> encoding time decreases. i guess, that this is the switch for the "-q" in
> lame:
> (from lame manpage):
> -q qual
> 0 <= qual <= 9
>
> Bitrate is of course the main influence on quality.
> The higher the bitrate, the higher the quality.
> But for a given bitrate, we have a choice of
> algorithms to determine the best scalefactors and
> huffman encoding (noise shaping).
>
> q=2 is recommended and always enabled when using vbr.
>
> q=value in lame seems to refer to the bitrate in vbr which is -V in lame
>
> a few examples to illustrate this (only audio was encoded in 3-pass style):
> (1)
> cbr:br=128:aq=2
> Pos: 485.3s 12131f (100%) 65fps Trem: 0min 7mb A-V:-0.045 [0:128]
> filesize: 8.2 megs
> ordinary cbr encoding...
>
> (2)
> vbr=2:q=0:aq=2
> Pos: 485.2s 12131f (100%) 31fps Trem: 0min 9mb A-V:-0.016 [0:157]
> 9.9 megs
> vbr with highest quality results in higher bitrate/bigger file...
> time: user 6m4.300s
>
> (3)
> vbr=2:q=9:aq=2
> Pos: 485.2s 12131f (100%) 29fps Trem: 0min 8mb A-V:0.017 [0:136]
> 8.7 megs
> no big surprise, filesize/bitrate are lower now, encoding was a bit faster.
> time: user 5m57.660s
>
> (4)
> vbr=2:q=9:aq=9
> Pos: 485.2s 12131f (100%) 46fps Trem: 0min 8mb A-V:-0.016 [0:137]
> 8.8 megs
> time: user 3m27.720s
> filesize/bitrate are almost the same, but encoding was much faster (and
> the quality should be worse than in (3)
>
>
> if aq(mencoder) is -q (lame) (which i am quite sure) and q(mencoder) is
> -V (lame) the whole thing gets a bit confusing with these different q's,
> maybe it would be wise to name them as in lame. maybe not, as this just
> messes up existing encoding scripts and people wonder, why the q-switch
> does no longe affect bitrate. however i hope you can now take add the
> description for the aq-switch to the manpage.
>
> regards
> wernfried
>
> --
> -> Wernfried Haas - w.haas at xover.mud.at / amnenion at xover.mud.at
> -> Homepage: http://xover.mud.at/~amnenion
> -> Beutelland: http://bl.mud.at
>
> _______________________________________________
> RTFM!!! http://www.MPlayerHQ.hu/DOCS
> Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users
--
-> Wernfried Haas - w.haas at xover.mud.at / amnenion at xover.mud.at
-> Homepage: http://xover.mud.at/~amnenion
-> Beutelland: http://bl.mud.at
More information about the MPlayer-users
mailing list