[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.

Thanks,

Marton


More information about the ffmpeg-devel mailing list