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

Marton Balint cus at passwd.hu
Sun Apr 29 16:39:07 CEST 2012


On Sun, 29 Apr 2012, Reimar Döffinger wrote:
> On Sun, Apr 29, 2012 at 01:30:02AM +0200, Marton Balint wrote:
>> Guesses the sample aspect ratio of a frame, based on both the stream and the
>> frame aspect ratio.
>>
>> Since the frame aspect ratio is set by the codec but the stream aspect ratio
>> is set by the demuxer, these two may not be equal. This function tries to
>> return the value that you should use if you would like to display the frame.
>>
>> Basic logic is to use the stream aspect ratio if it is set to something sane
>> and not 1:1, otherwise use the frame aspect ratio if it is set. I made some
>> tests with the files on samples.libav.org and this logic performed the best.
>
> It also means it will be impossible for users to fix an incorrect ratio
> encoded in the H.264 headers by just modifying the container value.
> Since the container value is basically always easy to trivial to fix,
> while the stream one is very difficult (with FFmpeg for example the
> only way possible is re-encoding) I am against ever disregarding the
> container value.

I also wanted to give priority to stream aspect ratio first in every case 
because of what you explained. But later I made tests and some files from 
samples.libav.org were misdetected. But mplayer, xbmc, or vlc handled them 
properly. Example:

FILE                                         WIDTH  HEIGHT  STREAM     FRAME
V-codecs/CDVHsample.avi                       1440    1080     1:1       4:3

> In MPlayer I made one special case: when the frame value changes, that
> one is used. Since that most likely means there was an aspect change
> and most containers do not support those.

For the above file the aspect is not changing but mplayer still thinks it 
does for some reason, so it uses the frame aspect ratio.

Anyway, I think it is more important to provide a ways to do this and 
handle it consistently throughout the whole ffmpeg codebase than to stick 
to a particular method. If others agree I will drop the extra smart 1:1 
detection stuff, and just change it to a simple use stream ratio then use 
frame ratio logic.

Regards,
Marton


More information about the ffmpeg-devel mailing list