[FFmpeg-devel] [PATCH] ffprobe: fix sample aspect ratio output when sample aspect ratio is not set

Stefano Sabatini stefano.sabatini-lala
Mon Apr 19 23:39:33 CEST 2010


On date Friday 2010-04-16 18:40:53 +0200, Robert Kr?ger encoded:
> 
> On 16.04.2010, at 18:16, Michael Niedermayer wrote:
> 
> > On Thu, Apr 15, 2010 at 03:05:30PM +0200, Robert Kr?ger wrote:
> >> 
> >> On 15.04.2010, at 14:02, Michael Niedermayer wrote:
> >> 
> >>> On Thu, Apr 15, 2010 at 01:16:05PM +0200, Robert Kr?ger wrote:
> >>>> 
> >>>> the following patch fixes current behaviour where for example
> >>>> for all ffmpeg-generated mjpeg files sample aspect ratio is
> >>>> output as 0:1 and display aspect ratio is computed accordingly
> >>>> (i.e. wrong).
> >>> 
> >>> undefined and 1:1 are 2 different things
> >>> 
> >> 
> >> What currently happens is that obviously for some files with a
> >> sample aspect ratio of 1:1 the corresponding struct is filled
> >> correctly and for some it seems to be filled with 0:1.
> > 
> > If a field is filled incorrectly a bugreport is needed
> > 
> 
> OK, I'll file one, then you can decide if it's really a bug and
> close it if it's not.
> 
> > 
> >> I looked at the way this is treated in avcodec_string in utils.c
> >> and line 857 suggests that it treats a zero numerator for sample
> >> aspect ratio as 1:1
> > 
> > no it does not
> > 
> 
> You're probably right although I would suspect that there are tons
> of programs out there which parse the output of ffmpeg to determine
> the display size of the video which will have an incorrect result
> here but that's beside the point, I know. What I would like someone
> to decide is how ffprobe should communicate the sample aspect ratio
> (and consequently the display aspect ratio as well) not being
> available (i.e. numerator being zero, at least that criterion is
> used in other places in ffmpeg code)
> 
> 1) output "N/A" for both values
> 2) don't output those key value pairs at all
> 3) output what's in the struct (e.g. 0:1 in my case) for both like it does now
> 
> I think 3 does not make sense and would submit a patch for 1 or 2 if
> someone (Stefano or you?) tells me which.

I have a slight preference for solution 1), and we're already using
"N/A" at least in another case (for PTS == AV_NOPTS_VALUE), so if
there are not other opinions that should be fine.

Regards.
-- 
FFmpeg = Free & Furious Multimedia Plastic Elegant Guru



More information about the ffmpeg-devel mailing list