[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Mon, Mar 02, 2009 at 10:51:00PM +0100, Peter Eszlari wrote:
> 2009/3/1 Michael Niedermayer <michaelni at gmx.at>:
> > you are confused we are not talking about codec specific options
> 
> You kinda do. But of course you are free do ignore me if the following
> gets too off-topic... :)
> 
> > or if it would lead
> > to chaos because its all too easy to add the same value to 2 demuxers but
> > under different names
> > that is chaos like
> > ffmpeg -i file -aq 5 out.mp3
> > Unknown option aq, use -audioquality
> >
> > ffmpeg -i file -audioquality 2 out.flac
> > Unknown option audioquality use -aq <1-5>
> 
> If an option is unkown, obviously ffmpeg wouldn't be able suggest an
> alternative...

well its unkown for the specific codec but i agree the error message
would be more cryptic in reality, that just strengthens the point that such
things have to be dealt with carefully ...


> 
> This mixing could be prevented with a naming convention like
> "-lame_q", "-flac_q"... but this looks ugly imo. On the other side, if
> an option like "-aq" can have different ranges depending on the codec
> this imo just leads to confusion too.

exactly, thats why we specifiy quality clearly to have to be between
1 and FF_LAMBDA_MAX
i dont think actual code follows this rules though but the API requires
it, guess that qualifies as bug ...


> 
> Users coming from...
> 
> lame -V <9.999-0.0>
> oggenc -q <-1.0-10.0>
> speexenc --quality <0.0-10.0>
> faac -q <10-500>
> twolame -v <-50-50>
> mppenc --quality <0.00-10.00>
> flac -<0-8>
> 
> ...certainly expect to be able to use their old options in easy way,
> preferbly by having exactly the same names as before.

thats hard ...
but we surely could have a "ffmpeg normalized quality" and a codec specific
one with different parameter names ...
its all patch welcome ...


> 
> >> Not only does the user not know about it, ffmpeg/lavc too doesn't know about it.
> >> If I do the following:
> >>
> >> $ ffmpeg -i file.avi -aq 50 file.mp2
> >>
> >> The option "-aq" gets silently ignored, while one would expect an
> >> error massege like "option -aq not supported by ffmp2".
> >
> > yes yes, using name-value pairs is a "heal all ill"
> > suddenly the problem of not having a list of supported options per codec
> > (something due to lack of interrest, manpower & patch) will disapear
> > we will just querry the magic_crystalbal() fuction and will then know
> > which options the codec supports and what the supported parameter ranges
> > are.
> > iam eagerly awaiting that patch ...
> 
> Of course manpower is a different matter...suppose we had this list
> with all options&ranges, how would we actually proceed? Checking them
> one by one like it is done atm (see attached patch for -aq/mp2 case)?
> This seems not practical, especially if we want to prevent the user
> from doing really stupid things like:

The way to go (if we had the volunteers for it ...) would be to at the
simplest level add an array of const char* name, float max, float min
to AVCodec
that can then include what options and what ranges each codec supports
its easy to check then if everything is within range and if any other
option has been changed from its default (there are also other ways
then checking against the default from AVOptions to detect changed stuff.


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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20090303/0a7863e5/attachment.pgp>