[FFmpeg-devel] [PATCH] metadata conversion API

[Baptiste Coudurier]

On 3/2/2009 3:32 PM, Michael Niedermayer wrote:
> 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.

I propose to add an array of tag/value pairs as "char*" in
AVCodecContext, then encoder_init can check these values.

char* is definitely more flexible, and permits more advanced treatment.
Furthermore, it can be passed "as is" to libx264.

It's nice to see that you can agree with me when someone else finally
express interest in something I propose.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org