[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Fri, Feb 27, 2009 at 04:44:29PM -0800, Baptiste Coudurier wrote:
> On 2/27/2009 4:30 PM, Aurelien Jacobs wrote:
> > Baptiste Coudurier wrote:
> > 
> >> On 2/25/2009 5:13 PM, Aurelien Jacobs wrote:
> >>> Hi,
> >>>
> >>> There is one last and important issue I want to address with the new
> >>> metadata API.
> >>> Old API allowed client apps and muxers to get a few select well known
> >>> tags (title, author...). With the new API, there is no simple way to
> >>> do that, right now. For example, if you demux an ASF file, and want to
> >>> get the name of the album, av_metadata_get(..., "album", ...) won't
> >>> give you any results, because ASF stores this information in a tag
> >>> named "AlbumTitle". There are lots of examples with various demuxers,
> >>> even for simple common tags. This also prevent correct remuxing between
> >>> different containers.
> >> First, thanks for your work Aurel, this is greatly appreciated.
> > 
> > You're welcome :-)
> > 
> >> I have a few ideas:
> >> Would it be possible to also export container information as "metadata" ?
> > 
> > This is definitely possible.
> > 
> >> Like aspect ratio, width, height. This would avoid duplicating fields
> >> from AVCodecContext, and make this information available as a simple way
> >> to user wanting for example to use libavformat to retrieve media
> >> information.
> > 
> > I think it highly depends on the target usage of the various fields you
> > want to export. If those fields are mostly targeted for textual user
> > information, using metadata is probably the way to go. But if the fields
> > are mostly targeted for numerical parameters to the software, then
> > metadata may not be the most practical way go.
> 
> It would be easy atoi/atoll value though.
> I will propose again my solution to have some "type" field where we
> could set "INT", "INT64", "UTF8", "RATIONAL", etc...

what is the difference between a string representing INT and INT64 ?
if atoi() is no problem then it also should be no problem to check if
a string is a number. This has the advantage that it can be muxed
in containers that do not support storing such information.

Or how would you store these types? If they are lost on remuxing or their
types are randomized then they arent particularely usefull IMHO


> 
> I don't think it might be too bloated, and would be really generic and
> useful. We have too many fields in AVCodecContext IMHO.

I dont mind at all if information is exported using some name-value system
but there are some things that are very important
1. it must be simple & clean & small & fast
2. These fields would be the public API and as such would be constraint
   by the same compatibility issues that apply to fields in AVCodecContext
   And it seems to me you do not realize this at all due to your
   example useage, but a demuxer could  under no circumstances export 
   a random "width" "720" that differed in meaning from a "width" value
   of another demuxer.


Thus i belive that in the end this thing is adding alot of shiny layers
that do nothing at all. But feel free to proof me wrong ...

If each demuxer maintainer exports whatever values with whatever names
he feels like then the values would be a nightmare to use for a user
app. not to mention remuxing a "width" "720" video when that wasnt the true
width.

So what would this all really solve?
* Fewer inactive fields, currently large parts of AVCodecContext are unused
  for some codecs though the bigger codecs probably use most.
* No psychological issue with adding field to a large struct, though people
  would have to add them to a equally long documentation that documented the
  exact meaning and format, who is allowed to set (app/lavc/lavf), ...

What does it not solve?
* exporting mov croping rectangle with a API that differs from mpeg1/2
  and h264 croping rectangles.
* allowing demuxer maintainers to export fields with arbirary name and
  value, insted each addition would need to be discussed to find the
  format for the value and the name that is best for most demuxers.
* decrease the memory requirement, string & values malloced take a
  lot more space than a few unused ints. malloc() alone has considerable
  overhead
* more compatibility for apps, apps already can through AVOptions
  set and get by name and enumerate fields.

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20090228/2be4adf9/attachment.pgp>