[FFmpeg-devel] [PATCHv3] lavf: add av_guess_frame_sample_aspect_ratio function
cus at passwd.hu
Sat May 12 21:06:04 CEST 2012
On Tue, 8 May 2012, Marton Balint wrote:
> On Tue, 8 May 2012, Joakim Plate wrote:
>> On Mon, May 7, 2012 at 11:03 PM, Michael Niedermayer <michaelni at gmx.at>
>>> 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.
Is there anybody who is against the v3 patch for some reason? If no
objections come in a day or two, then Michael, can you apply it?
More information about the ffmpeg-devel