[FFmpeg-devel] [PATCH] metadata conversion API

[Baptiste Coudurier]

On 3/3/2009 12:22 PM, Michael Niedermayer wrote:
> On Mon, Mar 02, 2009 at 06:25:30PM -0800, Baptiste Coudurier wrote:
>> On 3/2/2009 5:36 PM, Michael Niedermayer wrote:
>>> On Mon, Mar 02, 2009 at 03:41:04PM -0800, Baptiste Coudurier wrote:
>>>> On 3/2/2009 3:32 PM, Michael Niedermayer wrote:
>>>>> On Mon, Mar 02, 2009 at 10:51:00PM +0100, Peter Eszlari wrote:
>>> [...]
>>>>>> 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.
>>>>
>>> [...]
>>>
>>> Also we are lacking volunteers to make such lists, are you
>>> volunteering?
>> Sorry, nope, I don't find this solution elegant nor flexible.
>> I need an option which only supports 2, 4 or 8 as param.
> 
> its trivial to add a callback to AVOption to do such specific validity
> checks.
> Besides whats next? Should i add a fast primality check because some
> option might want to allow just prime numbers?
> 
> 
>> I however volunteer to add key/value as char* options to AVFormatContext
>> and AVCodecContext and use them.
> 
> You said that already but there is no relation between that and such validity
> checks, its not going to solve this problem.
> 
> Things added to svn have to be justified and their advantages and
> disadavatanges weighted against each other. Also once a technical discussion
> happened its the decission of the maintainer(s). Or in exceptional
> circumstances a vote (or consensus for thouse prefering the terminology)
> overriding the maintainer.
> 
> The arguments brought forth so far in favor of it, where that you want to
> export ".mov/width" with a value that could be scaling or croping. And that
> some advanced users may be able to make more sense out of it then we.

Well, I want to export ".mov/width" with a value, this value can be used
for whatever the user want.

> And that you prefer not to export the croping information in the existing
> fields for this puprose.

"Feel free to implement this if it works, I'm only proposing to export
"width" so I can automatically crop in ffmpeg.c, not anything else."

I'm perfectly fine with this also, I just don't volunteer to do it.

> And you want to export a field (whichs name you have not revealed yet)
> that only has 2, 4 and 8 as valid values.

Like audio channels for a muxer.

> Have i missed some? I remember alot of flaming and trolling and some
> unsuccessfull attempts at provocating me but little actual discussion
> about it.

Sorry, but it seems to me that everytime you disagree, you call flaming
or trolling, this really doesn't help the discussion.

> The arguments against, being a roughly 10x increase in memory consumtion,
> similar or worse increase in cpu consumtion for access and the loss of a
> common set of parameters for codecs. Each could have their own flag to
> enable b frames ...

The advantage being a lot simpler interface of users, and having the
possibility to declare these options only were are are actually used
(encoders or muxers) and with more appropriate names.

> Independant of this there is the seperate question about passing char*
> to external libs where this is much easier than other ways of interfacing,
> like with libx264. I do not strongly object to this but will not agree
> unless there are at least 2-3 developers who want it.

If we add them for libx264, I don't see why it couldn't used for others.

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