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

[Michael Niedermayer]

On Mon, Dec 14, 2009 at 11:12:44AM -0800, Baptiste Coudurier wrote:
> 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 ?

hmm
as metadata it leads to lots of special cases, as it cant just be printed
like the strings. Also if i have a bmp file of coverart i want to add to a
file doing this with coverart as metadata is not so easy.
I wont object to coverart in metadata if the people really want it that way,
but i feel it is not a pretty way to handle it. What i will insist on though
is that if coverart ends in metadata that the following use cases are
implemented
1. It must be possible to extract coverart into jpeg files
2. It must be possible to import coverart from jpeg files
   (ideally with resizing when needed)
3. coverart is copied from source to destination by default
4. ffplay must be able to display the coverart.
5. clean code, no hacks
Optional but nice to have: coverart per chapter and all of the above with it

[..]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20091216/a6108795/attachment-0001.pgp>