[FFmpeg-devel] [PATCHv3] lavf: add av_guess_frame_sample_aspect_ratio function
cus at passwd.hu
Tue May 8 21:56:06 CEST 2012
On Tue, 8 May 2012, Joakim Plate wrote:
> On Mon, May 7, 2012 at 11:03 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Mon, May 07, 2012 at 08:39:32PM +0200, Joakim Plate wrote:
>>> Just thought i'd chime in here. We (xbmc) ended up using that special
>>> handling of stream aspect being 1:1 and codec aspect not being 1:1 to
>>> solve a few samples we found in the wild. Thing the where mp4's
>>> recorded by some camera if i remember correctly. So i'm sort of in
>>> favor of that solution even if it's ugly.
>> iam in favor of whatever works best and is simple
>> in that sense, does anyone know how common in the wild files are that
>> change the sample aspect ratio midstream but have a valid and not 1:1
>> sample aspect at the format level ?
> Can't really say.
> Here our our ticket and change for this. Seems it was an MKV after allH
> so maybe i should just have asked him to re-mux the file.
> And now that i look at it I notice the commit message is wrong. It's
> the opposite order of what it does (what it does matches what was
> proposed here).
You don't need the 1:1 hack to fix the file in this bug, because here the
stream sample aspect ratio is 4:3 (DAR is 16:9), therefore it got priority
over the codec sample aspect ratio anyway.
So the reason for keeping the 1:1 hack was probably some other file which
is not in the report.
Anyway, I really agree with Reimar here and rather not handle 1:1 aspect
specially. If we do find a device (camera, etc.) which sets these fields
to wrong values, then I think it is better to match for some
identification of the creator device in the file if it is possible and
handle _that_ specially.
More information about the ffmpeg-devel