[FFmpeg-devel] [PATCH] metadata conversion API
Mon Mar 2 22:51:00 CET 2009
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
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.
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>
...certainly expect to be able to use their old options in easy way,
preferbly by having exactly the same names as before.
>> 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
> 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:
ffmpeg -i file -qscale 4.0 -bf 2 file.mp2
One would expact to at least recieve an error massage like "options
-qscale, -bf have been ignored". But this would mean to check in every
*enc.c for every option.
> we have
> codec specific options, we have a few in AVCodecContext that work just with
> one or few codecs.
That's not really what I mean by "codec specific" options. What I mean
is that every *enc.c has it own list of options, possibly duplicating
common ones like "b" (=bitrate) and allowing them to freely use their
own terminology that fits best to the specific codec. And the lib*
wrappers could then just copy the options names 1:1 from their libs.
The syntax in ffmpeg could look like this (would afaik also solve the
ffmpeg -ae codec=libmp3lame,V=6.666,vbr,...
ffmpeg -ve codec=libx264,pre=hq,crf=18,weightb,ref=3,...
ffmpeg -ve codec=mpeg4,help
available options of codec "mpeg4":
(also -vd/-ad, -dm/m could make sense...)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 572 bytes
Desc: not available
More information about the ffmpeg-devel