[FFmpeg-devel] [PATCH] metadata conversion API
Michael Niedermayer
michaelni
Sat Feb 28 14:57:46 CET 2009
On Fri, Feb 27, 2009 at 06:15:16PM -0800, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > 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.
>
> The advantage is a direct mapping atoi/atoll.
i do not understand what you mean
> If the muxer wants to take
> the risk to store INT64 into INT it will check the value.
elaborate please, what you say makes no sense at all to me
a muxer always needs to check the value it parses of a unknown
string, some metadata might be marked as INT but really wont be nummeric
at all
and what you suggest sounds like
if(type==INT64){
x= atol(str)
if(x<INT_MIN || x>INT_MAX)
...
}else{
x= atio(str)
}
while no matter if there are seperate types or not the muxer has to do
x= strtoll(str, tail)
if(tail==str || tail!= str+strlen(str) || x<MIN || x>MAX)
...
atol/atoi should not be used, even the libc docs say this
"The `atoi' function is also considered obsolete; use `strtol'
instead."
>
> > 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.
>
> "width" in .mov is "width" in .mov, not "width" in .mkv.
yes but it should be called ".mov/width" and not "width"
the reason is as i alraedy said because of the mess you create when
remuxing this.
>
> Well I think 100% mapping between containers is _impossible_, and
> therefore I don't see a need to find a common denominator.
Sounds like the common argument of:
"a solution working in 100% of the cases is impossible so i will choose
one that works in 0% instead of one that works in 99%."
I mean what you just said is prety much you dont want the user to be able
to use libavformat without having specific code for each demuxer.
and again i like to repeat, that i dont mind you exporting the width
from mov but you CANNOT export this in a field that is ambigously named,
that is ".mov/width" is fine "width" is not
>
> I don't see the need to "restrict" a metadata to a meaning.
> Someone who knows even more the format can retrieve this value if he
> wishes and do whatever he wants with it.
only if you export the whole set of parameters, do you plan to do this?
there are parametrs allowing a full afine or linear transformation of
the image IIRC. just knowing the final width is not enough to the
user application author who knows mov better then the mov demuxer
maintainer as you seem to suggest ...
> I certainly don't understand 100% of .mp4/.mov, I don't see why user
> should be restricted by my ignorance, while I can export everything in
> "udta" assuming the formating is standardized.
The problem is you dont export the information a user would need you
just suggested to export the final width in a misnamed metadata tag
>
> User can retrieve "width" in .mov if he wants, a simple check on input
> format is enough.
but why? if you export it as ".mov/width" the check wont be needed ...
>
> Yes, this would be part of public api, I don't see this a problem.
>
> > 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 ...
>
> Many people wants to use FFmpeg to display information about a file,
> including metadata. This is IMHO a good and simple way to achieve it
AVOptions allows full enumeration of all fields with names so no new
possibilities are opened by making AVCodecContext.* switch to this
name/value system
[...]
> > 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.
>
> It can solve this issue, if user wants to honor it, user can because he
> has access to it. Granted he knows what the value means, but again our
> ignorance should not prevent him from acheiving his goal.
see above, you first have to export the whole transformation matrix, the
width/height is not enogugh to differentiate scale from crop no matter how
smart the user is. Also a user knowing mov internals so well is likely
going to write his own demuxer.
>
> > * 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.
>
> I don't agree with this, see above. "width" in .mov != "width" in .mkv,
> IMHO that's an utopy to try to make everything fitting in the same shape.
than do NOT use the name "width" if it is as you say not "width"
[...]
>
> > * more compatibility for apps, apps already can through AVOptions
> > set and get by name and enumerate fields.
>
> AVOptions uses OPT_<type> isn't it ? Why don't you want to apply this to
> AVMetadata ?
i explained it already above:
> > [...] 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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/0fd61367/attachment.pgp>
More information about the ffmpeg-devel
mailing list