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

[Robert Swain]

2008/8/1 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Aug 01, 2008 at 09:04:23AM +0100, Robert Swain wrote:
>> 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.
>
> mplayers and i think thus also mencoders command line is also position
> sesitive, just try
> mplayer video1 -vf scale=100:50 video2 -vf scale=50:100

Interesting, I didn't know this. Still, the point is - good documentation! :)

Rob