[FFmpeg-devel] ffmpeg -s breaks aspect ration (regression)

[Jean Delvare]

Last time I updated ffmpeg, I hit a problem where option -s breaks the
aspect ratio. I bisected the repository and found that this regression
was introduced by:

commit 7a11c82fb760619d0e17ca234381b50d6c675cc0
Author: Michael Niedermayer <michaelni at gmx.at>
Date:   Mon Jan 31 20:48:35 2011 +0100

    vsrc_buffer: add sample_aspect_ratio fields to arguments.
    
    This fixes aspect handling in ffmpeg.
    
    This is based on a patch by Baptiste.
    
    Signed-off-by: Anton Khirnov <anton at khirnov.net>

My input video looks like:

Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [PAR 64:45 DAR 16:9], 9500 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc

I am passing -s 640x360 to ffmpeg to get square pixels, before the bug
I would get:

Stream #0.0(und): Video: mpeg4, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 640 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc

and the video would look OK. Since the commit above, I get:

Stream #0.0(und): Video: mpeg4, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 743 kb/s, PAR 91:64 DAR 91:36, 25 fps, 25 tbr, 25 tbn, 25 tbc

and the aspect ratio is wrong when video is played with totem or
mplayer (although surprisingly correct with ffplay.) I _can_ fix the
problem by passing an additional -aspect 16:9, but I didn't have to do
that before and it seems wrong that the aspect ratio is not preserved
by default.

Can this bug be fixed, please? I'll be happy to perform any amount of
testing or provide a small sample input file.

As a side note, I would be very grateful if someone could explain to me
how a given video stream can have two different PAR, why anyone would
want to do this, and what a video player is supposed to do in that case
(apparently totem/gstreamer and ffplay do not agree.)

Thanks,
-- 
Jean Delvare