[FFmpeg-devel] [PATCH] metadata conversion API

[Peter Eszlari]

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

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

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

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
presets problem):

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":
    -q <x.x-x.x>
    -bf <x-x>
    [...]

(also -vd/-ad, -dm/m could make sense...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-aq-in-mp2.patch
Type: text/x-patch
Size: 572 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090302/d76af0aa/attachment.bin>