[FFmpeg-cvslog] r20839 - trunk/libavformat/id3v2.c

[Baptiste Coudurier]

On 12/14/2009 08:32 AM, Michael Niedermayer wrote:
> On Mon, Dec 14, 2009 at 07:03:13PM +0530, Jai Menon wrote:
>> On Mon, Dec 14, 2009 at 12:23:39PM +0100, Michael Niedermayer wrote:
>>> On Mon, Dec 14, 2009 at 07:54:49AM +0100, Reimar D?ffinger wrote:
>>>> On Mon, Dec 14, 2009 at 02:53:48AM +0100, Michael Niedermayer wrote:
>>>>> whats left currently is: (note i manually edited the diff so i cant gurantee
>>>>> that the stat is completely correctly, iam not sure how good diffstat is at
>>>>> manually edited diffs)
>>>>
>>>> Can you just dump that diff somewhere? I think the gxf and s302m stuff is "mine",
>>>> though I expect I might lack samples for them.
>>>
>>> attached, but keep in mind these are my work in progress diffs they are
>>> hand edited with hunks and lines removed that where merged or that i
>>> considered not worth the work merging (too much work / bikeshed / things
>>> appearing incomplete or buggy). Its possible i also removed changes by
>>> mistake from them!
>>
>> [...]
>>
>>> +/**
>>> + * Used attributes: "language", "mime"
>>> + */
>>> +typedef struct {
>>> +    char *key;
>>> +    char *value;
>>> +} AVMetadataAttribute;
>>> +
>>> +typedef struct {
>>> +    unsigned count;
>>> +    AVMetadataAttribute *elems;
>>> +} AVMetadataAttributes;
>>> +
>>> +enum AVMetadataType {
>>> +    METADATA_STRING, ///<  UTF-8
>>> +    METADATA_INT,
>>> +    METADATA_DOUBLE,
>>> +    METADATA_BYTEARRAY,
>>> +};
>>
>> BTW, is there any possibility of the above metadata type being
>> considered? I'm asking this with reference to cover art export.
>
> binary data will be considered once someone explains what the problem with
> CODEC_TYPE_ATTACHMENT is.

IMHO it makes no sense. It is not a stream and not semantically 
considered as such in any format encountered.

I know you would to transcode it if possible, but I'm not sure it would 
be that useful, all containers basically supports the same type of 
coverart.
Also having coverart as metadata will simplify the commandline:
It will be kept when using -map_meta_data.
Otherwise user has to -attachementcodec copy -newattachementtrack ?

> about number vs. string
> the metadata doesnt need to store number/string its just a recipe
> for ending with inconsistant information. If something can be parsed as
> number it is a number if not its not.
> and strings are utf-8/unicode always, if not the demuxer has to do
> whatever convertion is needed
>
> Comments welcome, bikeshed not

No problem.

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