[FFmpeg-devel] ffmpeg -s breaks aspect ration (regression)
khali at linux-fr.org
Wed Jul 20 16:44:56 CEST 2011
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:
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
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.)
More information about the ffmpeg-devel