[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Tue, Mar 03, 2009 at 02:20:47PM -0800, Baptiste Coudurier wrote:
> On 3/3/2009 2:05 PM, Michael Niedermayer wrote:
> > On Tue, Mar 03, 2009 at 09:35:09PM +0000, Robert Swain wrote:
> >> 2009/3/3 Michael Niedermayer <michaelni at gmx.at>:
> >>> On Mon, Mar 02, 2009 at 06:25:30PM -0800, Baptiste Coudurier wrote:
> >>>> I however volunteer to add key/value as char* options to AVFormatContext
> >>>> and AVCodecContext and use them.
> >>> You said that already but there is no relation between that and such validity
> >>> checks, its not going to solve this problem.
> >> OK, so maybe this is off topic for this thread.
> >>
> >>> Things added to svn have to be justified and their advantages and
> >>> disadavatanges weighted against each other. Also once a technical discussion
> >>> happened its the decission of the maintainer(s). Or in exceptional
> >>> circumstances a vote (or consensus for thouse prefering the terminology)
> >>> overriding the maintainer.
> >>>
> >>> The arguments brought forth so far in favor of it, where that you want to
> >>> export ".mov/width" with a value that could be scaling or croping. And that
> >>> some advanced users may be able to make more sense out of it then we. And
> >>> that you prefer not to export the croping information in the existing
> >>> fields for this puprose.
> >>> And you want to export a field (whichs name you have not revealed yet)
> >>> that only has 2, 4 and 8 as valid values.
> >>> Have i missed some? I remember alot of flaming and trolling and some
> >>> unsuccessfull attempts at provocating me but little actual discussion
> >>> about it.
> >>>
> >>> The arguments against, being a roughly 10x increase in memory consumtion,
> >>> similar or worse increase in cpu consumtion for access and the loss of a
> >>> common set of parameters for codecs. Each could have their own flag to
> >>> enable b frames ...
> >> The CPU loss should be minimal and it's only a set up cost. How many
> >> cycles are really spent on option parsing?
> > 
> > we directly access fields from AVCodecContext currently just try
> > grep avctx libavcodec/*.c | grep -v av_log
> > there are over 5000 matches
> > i do not want to replace 5000 single instruction reads with 5000 function
> > calls doing a search through a table of strings.
> > Especially considering that i dont see what we would gain by this
> 
> I don't see how this relates to using char */char * as options, you can
> set AVCodecContext fields if you want.

thats what we have currently
av_set_string() takes a name & value char * and sets the corresponding field
on AVCodecContext


> 
> Although almost every codec has its own context anyway, point is to
> factorize when it's actually needed and not by principle.

So would you agree that the char * are only allowed to be used for things
that are used by just one muxer/demuxer or encoder/decoder ?


> 
> >> Also, we can still enforce
> >> some sort of option naming consistency.
> > 
> > I cant even enforce some decission about where to store the croping
> > information now. And i am listed as maintainer of mov
> 
> Well you share maintainership, and please stop saying this, it is not
> true, if you want to store croping into something actually used, I
> already said you were free to do so.

then stop phonily offering to store it in some wrong place


> 
> Please don't focus on this "width" thing, this might apply to any
> information people find useful.

so far people have not found anythig else though,
external libs and mov/width being the only.


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/20090304/7cdacba5/attachment.pgp>