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

[Marton Balint]

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.

Regards,
Marton