[FFmpeg-devel] [PATCH] libmp3lame: set noise shaping & psycho acoustic algorithms quality

[Michael Niedermayer]

On Thu, Jul 31, 2008 at 07:56:29PM +0200, Nicolas George wrote:
> Le quartidi 14 thermidor, an CCXVI, Michael Niedermayer a ?crit?:
> > i agree with robert that profile is not the correct choice and that 
> > compression_level would be an option.
> 
> All right: here is a new version of the patch using compression_level. The
> first one had tabs anyway, sorry.
> 
> > if you want an error message for unsupported options, it should be very
> > trivial to do once you have a list of supported options for each codec.
> > And before you have such a list no system will be able to tell you that
> > the option has no effect.
> > 
> > To clarify how the actual code could work:
> > Each AVCodec exports the list of options that do have some effect.
> > ffmpeg checks that list before setting an option and prints a warning if
> > its not on the list ...
> 
> That would do the work to warn about useless options, although I fear that
> the list would not always be in sync with what the codecs do.
> 
> But that does not address the other problem: each time someone adds support
> for a small option like this, he has to either find an existing option with
> a name that vaguely resembles what he is doing, or to add a global option
> that will clutter the global namespace.

you are moving 10min of your time to 10min * 100000users thats not reasonable.
When each codec uses a totally different option name, its the users problem
to find out which to use, otherwise he obviously knows it already.


> 
> In this particular case, "compression_level" is far from perfect, is it? And
> "profile" was no more perfect.

profile was wrong, like samperate would have been wrong.
just pick up any spec (H.264 being freely available) and read about what
profile means in it. It just has nothing to do with the used encoding
details.


> But I think people would have not been happy
> either if I had proposed to add a brand new option, "algorithmic_complexity"
> or something, that would be used only in libmp3lame.c.

no, and if we have had per codec options i simiarly would have complained
about -lame algorithmic_complexity=5
so what are you trying to say?


> 
> And there is another problem: the allowed range for an options is not always
> the same, depending on the codec.
> 
> The way to go may be not just a list of supported options, but an actual
> per-codec set of AVOption structures. Unfortunately, I have no time to dig
> into that at the moment.
> 
> (By the way, did you notice your PGP key has expired?)

yes, half a year ago and i updated the expiraton date back then.

and patch ok

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080731/4d8e5fe1/attachment.pgp>