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

[Fred Rothganger]

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

    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.

-- Fred