[FFmpeg-devel] [PATCH] AVI metadata retrieval improvements

Don Moir donmoir at comcast.net
Fri Mar 21 18:15:00 CET 2014

----- Original Message ----- 
From: "Thilo Borgmann" <thilo.borgmann at mail.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Friday, March 21, 2014 12:29 PM
Subject: Re: [FFmpeg-devel] [PATCH] AVI metadata retrieval improvements

> Am 21.03.14 15:30, schrieb Michael Niedermayer:
>> On Thu, Mar 20, 2014 at 11:12:27PM +0100, Thilo Borgmann wrote:
>>> Am 04.03.14 17:16, schrieb gregory.wolfe at kodakalaris.com:
>>>> This is the second of two changes I've made as part of our upgrade to
>>>> the latest FFmpeg development branch.
>>>> This patch enhances two aspects of metadata retrieval from AVI files.
>>>> I've attached before/after command line output from ffmpeg for each
>>>> modification.  Test video files that can be used to generate the
>>>> before/after output have been uploaded to the FFmpeg FTP server.
>>>> Patched file:  libavformat/avidec.c
>>>> Description (from commit message):
>>>> Added function avi_extract_stream_metadata().  Some cameras (e.g., Fuji)
>>>> store stream metadata following the "strd" stream data tag.  Currently,
>>>> avi_read_header() calls ff_get_extradata() to read and save this data in
>>>> the codec's "extradata" slot.  This new function extracts metadata from
>>>> "extradata" by first looking for the AVIF tag, then extracting metadata
>>>> from the EXIF tags which follow it.
>>> I've rewritten almost everything to use existing EXIF functions.
>>> Patch attached, but there are 2 issues I need advise for:
>>> a) Current EXIF is in lavc only and relies on lavc/tiff.h and lavc/bytestream,
>>> so these have to be moved (to lavu)?
>> using just a header with macros/inline functions is fine
>> using ff_* functions from other libs is not as ff_ is not exported
>> using avpriv_* functions in lavf from lavc is ok but the ABI/API
>> of such functions is then part of the libavcodec ABI/API, non public
>> but still, so care has to be taken with future changes to these
>> functions so their ABI/API isnt broken
> Ok these are the rules, but what should I do since there are ff_* functions
> used? My guess was to move to libavu because metadata decoding seems to be
> needed by formats and codecs, but I don't know if there is a better solution? Or
> make exif tag decoding a public av_* funtion in lavc?
> About the avpriv_request stuff, I could make it easy and not request samples for
> avi's featuring these two tags, but I think we actually are interested in such
> files. I really wonder that such requests are used nowhere in lavf. So same
> move/solution for these like for the exif metadata stuff that would also pull
> these tiff tags with it?
>>> b) I can't see anything about the endianess in AVI files. How to determine or is
>>> it always little-endian?
>> the avi fileformat itself is always LE, ive no idea though about the
>> content of various chunks, i guess  either
>> autodetect if its trivial or
>> assume its always LE if all files we have are LE
> I will check if there's something in the padding. A usual header is not present. Gregory says at least for these 300 files its 
> alwas le=1.

While your on the topic of EXIF, why do you have decode a jpeg image before you can retreive the EXIF orientation value and maybe 
some other values. Seems to make sense, especially for a single frame image, that it would be available in stream or context 
metadata without first decoding it and then having to get it from the frame metadata. 

More information about the ffmpeg-devel mailing list