[Ffmpeg-devel] Patch add function to read record time in dv video
Fred Rothganger
rothgang
Mon Sep 5 18:17:43 CEST 2005
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
More information about the ffmpeg-devel
mailing list