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

[Fred Rothganger]

Michael Niedermayer wrote:

>its simple and solves the problem, doing it correctly is hard and your
>chances of getting a patch accepted in that area are near zero unless
>you understand codecs, containers and ffmpeg well
>  
>
    I have confidence in my programming ability and the ability to 
understand ffmpeg.  However, I have plenty of other software work that 
I'd rather be doing now than to throw patches over the wall and see if 
they stick.  I'm willing to work up a change to ffmpeg as long as we 
have a solid design discussion and agreement ahead of time.


>>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.

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

>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.

>the correct solution is to finish the AVOption code so we can enumerate/
>set/get the fields of a struct, this could then be easily extended to an 
>additional name/value list in the structure
>this way we could access a field by its name independantly of where it is
>actually stored, so we could change a member of the name/value list into
>a normal C struct field without changing the code which accesses it
>
>furthermore we could trivially store various things like a description
>help text, max/min values or a function to check the validity of the value
>
    AVOption looks like a reasonable beginning to a reflection API.  In 
its present form, it is focused on describing the contents of a 
structure.  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.  The idea of a name-value interface is to 
be agnostic about the exact set of values available.  A crude example of 
this (in the still-image domain) is libtiff.  It does not pass a 
structure with the value of every tag at some pre-defined position.  
Instead, it provides a small set of functions for getting/setting 
arbitrary tags.  In fact, the very existence or non-existence of certain 
tags is itself an indicator of the structure of the file (eg: stripped 
vs. tiled).  In contrast with libtiff, using human readable strings 
rather than members of an enum for names avoids rigidity in the set of 
possible values.  The downside is that strings are a little more 
expensive to compare.

-- Fred