[Ffmpeg-devel] Patch add function to read record time in dv video

[Michael Niedermayer]

Hi

On Mon, Sep 05, 2005 at 10:17:43AM -0600, Fred Rothganger wrote:
[...]
> >>AVInputFormat {
> >>...
> >>  int (*metadata)(AVFormatContext *, char * name, void * value, int * 
> >>size);
> >>   
> >>
> >
> >what exactly is this supposed to do? and the name of the function is 
> >unaceptable
> > 
> >
>    As an input format processes its file, it will accumulate certain 
> information in its internal state (stored in or connected to 
> AVFormatContext).  The idea of this function is to allow a client 
> program to query the format for such values by name.  The values may 
> simply be fields in some structure, or they may be computed/retrieved on 
> a "lazy" basis only when a query is made.

ok, thanks for explaining
now thats nice but its really not usefull for us on its own, you simple 
miss the goal, just think about how to convert anything to anything
the first thing you need is to be able to enumerate the stored metadata 
tags, ffmpeg cant bruteforce all strings to get the info out ...
the second issue is that the association must be preserevd a "most
recent frame and if not global" rule just isnt usefull the metadata 
can be associated to a stream, or even a specific timespan, think of 
tv with different movies with differnt titles for example, all this 
must be preserved when transcoding


> 
>    Regarding the name, please suggest one.  The one given above is just 
> a placeholder for sake of discussion.

get_metadata() seems to be a obvious choice for your proposed function


> 
> >fine but i hope you are aware that you cannot store arbitrary structs in a 
> >portable way, it would need container and metadata type specific converters
> > 
> >
>    Could you elaborate on this a little?  It sounds like you are 
> concerned about converting data in the container file into a structure 
> to shared with the client program.  Of course we'd have to do this.  
> However, the burden should be light since we will mostly be concerned 
> with simple types like ints, doubles, and null-terminated strings.

somehow i dont think it will be even remotely that easy, think of
unicode vs. ascii, timezones and containers not specifiying half of the
information


[...]
> It sounds like you are considering a more flexible 
> name-value interface, but it also sounds like you expect everything to 
> live in some struct somewhere. 

yes, everything must be associated with a struct in some way (same for your
proposal)
no, it wont necessary be a field in a struct but could be a name+value tag
in a linked list or other data structure

and most important, we need a API for encoding, decoding and (de)muxing one
just for playback is really entirly useless
 
[...]
-- 
Michael