[FFmpeg-devel] [PATCHv3] lavf: add av_guess_frame_sample_aspect_ratio function

Marton Balint cus at passwd.hu
Mon May 14 21:29:07 CEST 2012

On Sat, 12 May 2012, Michael Niedermayer wrote:
> On Sat, May 12, 2012 at 09:06:04PM +0200, Marton Balint wrote:
>> 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> 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.
>>>> https://github.com/xbmc/xbmc/commit/f08c8f01d1014a7f161d40a7cc8ede0680f9fe77
>>>> http://trac.xbmc.org/ticket/12187
>>>> 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?
> sure just send me a reminder in a day or 2 otherwise i will forget

No further comments received, please apply the v3 patch.



More information about the ffmpeg-devel mailing list