[FFmpeg-devel] [PATCH] Metadata

[Michael Niedermayer]

On Sat, Jan 03, 2009 at 03:26:05PM -0800, Baptiste Coudurier wrote:
> Hi Michael,
> 
> Michael Niedermayer wrote:
> > [...]
>  >
> > + * 3. A tag whichs value is translated has the ISO 639 3-letter language code
> > + *    with a '-' between appended. So for example Author-ger=Michael, Author-eng=Mike
> > + *    the original/default language is in the unqualified "Author"
> > + *    A demuxer should set a default if it sets any translated tag.
>  >
> > [...]
>  >
> > +typedef struct {
> > +    char *key;
> > +    char *value;
> > +}AVMetaDataTag;
> 
> Maybe it would be simpler and more extensible to have a "const char 
> **attributes" field where to store language, or anything else related to 
> the AVMetaDataTag entry. This would avoid parsing the '-'.
> 
> What do people think ?

I am against it, let me explain why

First, currently metadata support in svn is "too little" that is nothing
is really supported, no preserving of arbitrary tags, no way for users to
add anything but 5 standard tags ...

Aurels variant, that had a language field and did use a tree based metadata
system allowing metadata about metadata is IMHO "too much" Its not something
anyone should need, nor is it really needed for language & metadata about
metadata, and still it wouldnt be able to handle all metadata about other
metadata like "the email address of the child of the author and producer"

my sugestion of a simple key-value based system
can be stored in any container that supporte key-value string based
metadata, and still can represent language and metadata about other metadata.
Also it can very easily be implemented efficiently, currently all operations
are O(n) thus it would become slow if there are many tags. But if we would
use tree.c/h it would all just be O(log n) and its very easy to use tree.c/h
with it ...

Now if we do add attributes
* The api to search for tags becomes more complex
* It is more difficult to use tree.c/h (it needs like qsort a sanely
  behaving comparission function, which is trivial for char*, less
  so with an additional attriute list, and even a lot less if we want
  to actually search for specific attributes)
* No container i know supports arbitrary attributes, thus muxers would
  either have to convert the attribute list into a string or extract the
  2 or 3 they suport.
* The user interface from the command line would be more complex, or it
  would be maybe just a string but then why not keep the string internally

So i would prefer if we kept a pure key-value list and did not add more
fields.

just my oppinion ...

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- 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-devel/attachments/20090104/f31cb1f4/attachment.pgp>