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

Robert Swain robert.swain
Fri Aug 1 10:04:23 CEST 2008


2008/7/31 Michael Niedermayer <michaelni at gmx.at>:
> On Thu, Jul 31, 2008 at 07:56:29PM +0200, Nicolas George wrote:
>> Le quartidi 14 thermidor, an CCXVI, Michael Niedermayer a ?crit :
>> > 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.

Once the initial work is done, as long as patches to add new options
are not allowed into svn unless they also add them to the lists for
codecs that use them this should be fine. However, I'd hope there
could be a more elegant solution, maybe that could also be used to
probe for available options for a codec which would be useful for the
CLI or for self-maintaining GUIs but this could be done with Michael's
option list proposal.

>> 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.

This doesn't seem to be a problem for users as long as the options are
well-documented. mencoder is very easy to use as the options for each
codec are well-documented. And I maintain that mencoder's CLI is
easier to use than FFmpeg's, at least in my opinion.

The context sensitivity of some options on the FFmpeg command line,
while being a cool idea, is unusual and initially confusing.

I think above anything else, regardless of how our command line works,
documentation of all the options is paramount to usability. If it's
documented well, people will figure it out.

Regards,
Rob



More information about the ffmpeg-devel mailing list