[Libav-user] FLV logic question

[Mark Stevans]

On 6/20/2013 7:31 AM, Hendrik Leppkes wrote:
> On Thu, Jun 20, 2013 at 4:16 PM, Mark Stevans <mark39518 at cesinst.com> wrote:
>> Thanks for the quick reply, Hendrik.  But you say that the data is *already*
>> stored somewhere: I just don't see how that is possible.  When you open a
>> random FLV clip file, the first thing you usually encounter is the Metadata
>> packet.  How can you know what codec is being used, the height/width, etc.
>> without parsing that metadata?  I mean, isn't that why it's put there at the
>> start of the file?
>>
>> Or does FFMPEG rely on elaborate probing methods to deduce that metadata in
>> the case where no header is present, and so, for consistency, it just
>> ignores the header metadata if it *is* present?
>>
>>
>
> Please don't top post on this mailing list.
>
> Regarding your question, the metadata that is being skipped here is
> processed in the block above.
> It is used to set the various properties in the acodec and vcodec
> structures, so there is no need to put it into the generic metadata
> anymore.
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>

No top-posting, got it.  Thanks again for your replies -- it's hard to 
pick up the philosophies just by reading the code.

My only remaining point is that the metadata is not always saved on the 
codec structures or in AVFormatContext.  If, for example, you don't 
trust the metadata (flv->trust_metadata is false), the metadata isn't 
saved for any sort of subsequent "untrusted" processing.

I am not sure if there are any guarantees as to the order in which keys 
appear in header metadata: I would hope that, for example, the audio 
codec ID would appear before the audio sample rate, but if it doesn't, 
it is ignored (as are most others if out-of-order).

Filesize metadata could (obviously) be a valuable check against 
truncated input files, but it's discarded.  The official frame rate is 
also very helpful (though I know it could be estimated from timestamps, 
etc.) -- but it's also thrown away.

Frankly, it just seems like an optimization, where the skipping of the 
storage of those dozen metadata fields saves a few hundred bytes.  IMHO, 
the potential usefulness of that original metadata outweighs the savings....

Mark