[Ffmpeg-devel] Patch add function to read record time in dv video
Mon Sep 5 19:37:50 CEST 2005
Michael Niedermayer wrote:
>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
The design I had in mind is a little more nuanced than the one you
saw. I was just giving a general summary of the idea in order to avoid
being tedious. We can have get_metadata() and set_metadata() functions
respectively in AVInputFormat and AVOutputFormat. The functions can
include a stream index, and perhaps some special indices to indicate
container-wide or other special interpretations of the name.
Now regarding the issue of converting one format to another: It
makes sense to be able to enumerate available metadata items. I view
metadata as having different levels of availability. Some items may be
immediately available in the working state of the format implementation,
while other items may require special action to extract.
>somehow i dont think it will be even remotely that easy, think of
>unicode vs. ascii, timezones and containers not specifiying half of the
The issue here is whether there is a clear interpretation of the
data returned by the function. Are you saying that sometimes the
meaning will be so ambiguous that the format implementation must pass
this ambiguity on to the client program? In such a worst case, we could
return an error code along with the data. In general, we could return a
type indicator. Alternately, the user could pass a code for the
expected type, and if the data doesn't match that type (or can't be
converted), then the function could return the error code.
>yes, everything must be associated with a struct in some way (same for your
>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
I would like you to consider the possibility of computed values or
values retrieved only on demand. This would be more efficient than
filling up structures with stuff that the user program has no interest in.
More information about the ffmpeg-devel