[FFmpeg-devel] [RFC/PATCH] New metadata conversion API

[Baptiste Coudurier]

Hey guys,

On 10/9/10 1:46 PM, Michael Niedermayer wrote:
> On Sat, Oct 09, 2010 at 09:31:05PM +0200, Anton Khirnov wrote:
>> Before this thread falls into oblivion again, could I please hear
>> everybody's opinion on how should we fix metadata conversion? (that's
>> mainly Michael, Aurelien and Baptiste; of course anybody else is welcome
>> to comment as well)
>>
>> So far the proposals are:
>> 1) Modify the conversion API to fix its problems. This involves adding
>> an AVMetadataConv field to AVMetadata to track current format, changing
>> the conversion function to work on a single AVMetadata instead of the
>> whole AVFormatContext (there's at least one bug in ffmpeg.c related to
>> this) and also adding callbacks to conversion tables, since we have to
>> do advanced stuff like splitting/merging tags during the conversion
>> step.
>> This is what my first patchset in this thread does.
> 
> If we didnt need the callbacks this would look nice but the callbacks IMHO
> make it really messy and defeat the whole idea of having the convertion
> vissible. As you again have black box callbacks
> 
> 
>>
>> 2) Remove the public conversion API completely. Only generic metadata
>> format will be exported by demuxers/expected by muxers. This is
>> somewhat simpler than 1), since advanced conversion can be done directly
>> in (de)muxers. However the users can't access metadata in the native
>> format.
>> This is what my second patchset in this thread does.
>>
>> 2a) Same as 2), but export both metadata sets.
>> 2b) Same as 2), but add an AVOption to choose native format.
>>
>> 3) ????
>>
>> I am in favor of 2), since IMO accessing native format isn't ever really
>> needed. We can later switch to 2b if users start complaining.
> 
> Iam also in favor of 2)
> also if baptiste thinks the AVMetadataConv tables are usefull we can still
> export them for example in AVMetadata but they would not be correct
> for splited/merged/convertet fields
> That is the tables would just be "interresting information" that wouldnt be
> needed or used during normal operation
> 

Well I liked being able to retrieve native tags, but if you guys prefer
only exporting
native, I won't oppose :)
If it is simpler from an user perspective, it should be best.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org