[FFmpeg-devel] [PATCH] new generic metadata API

[Michael Niedermayer]

On Sun, Nov 02, 2008 at 01:08:52AM +0100, Michael Niedermayer wrote:
> On Mon, Oct 20, 2008 at 11:22:43PM +0200, Aurelien Jacobs wrote:
> > On Mon, 13 Oct 2008 19:27:29 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > On Mon, Sep 29, 2008 at 12:46:54AM +0200, Aurelien Jacobs wrote:
> > > > On Sun, 28 Sep 2008 00:27:40 +0200
> > > > Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > 
> > > > > 
> > > > > On Sat, Sep 27, 2008 at 04:03:53PM +0200, Aurelien Jacobs wrote:
> > > > > > On Tue, 23 Sep 2008 15:21:43 +0200
> > > > > > Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > > [...]
> > > > > 
> > > > > > > [note, also see the nut-devel ML for some related change suggestion i just
> > > > > > >  posted]
> > > > > > 
> > > > > > Seen it.
> > > > > > I've added generic flattening and un-flattening support, following your
> > > > > > proposed nut scheme. The exact formatting could be changed latter if
> > > > > > a different scheme is accepted.
> > > > > 
> > > > > What does it do with 2
> > > > > Author tags? does it convert to Author / Author2?
> > > > 
> > > > Yes.
> > > > 
> > > 
> > > > > Similarly, does it remove the '2' postfix when unflattening?
> > > > 
> > > > No. I'm not sure if it's a good idea to remove it...
> > > 
> > > mkv->nut-mkv should generally end up with equivalent metadata, similarly
> > > nut->mkv->nut should too.
> > > Also what the user of libavcodec sees from both should be roughly the same.
> > 
> > That was exactly what I thought about when I deceided it wasn't a
> > good idea.
> > What if original mkv file literally contains:
> >   AUTHOR=Mr. X
> >   AUHTOR2=Mr. Y
> > I think the mkv spec don't forbid this (anyway, other containers could
> > allow it). So now, mkv->nut->mkv shouldn't remove the '2' to end up
> > with equivalent metadata. This would be even more important if someone
> > deceides to store tags such as:
> >   ID3V1=yes
> >   ID3V2=no
> > or any other names which have a trailing number with an actual meaning.
> > 
> > So removing the '2' could destruct some really useful information
> > in some situations, while keeping it shouldn't have any bad effect,
> > except looking a little worse sometimes.
> 
> The 2 systems are supposed to be bijective. If one cant represent something
> then we already have a problem IMHO
> This is slightly related to escaping.
[...]
> ill review the patc later (just wanted to send these out today ...)

Looking at the patch, i cant help but feel that its significantly more
complex than needed and at the same time is not really more flexible
than a simpler implementation.

The naive implementation would be a simple flat key-value list
as next step key could be split in name,country,language by syntax
of a char[] or a struct.
and name could be "the authors email address" using one syntax or another
so far the tree system inspired by matroska would be equivalent
But if one considers metadata like the authors email its not that far fetched
to consider "the child of author3 and author8" at which point trees break
down. Now this isnt particularely usefull metadata but neither is most of
the tree based stuff AFAIK.

So i think we should before any further review of this discuss how far we
really want to support some of the obscure things above, and if we do then
how.

Also the question of convertion has not been considered much, convertion
could be simply left to a future patch. There could be a documented common
format to/from which de/muxers convert or there could be a seperate
converter.

And last the patch must be split, a 100+k patch is really too big

updating ffmpeg/ffplay/ffserver/demuxers/muxers can all be split off
from the core

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- 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/20081109/842d8631/attachment.pgp>