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

Michael Niedermayer michaelni
Fri Aug 1 11:38:46 CEST 2008

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/20080801/d4146149/attachment.pgp>

More information about the ffmpeg-devel mailing list