[MPlayer-dev-eng] [PATCH] Avoid scaling for tiny aspect ratio differences

[Ivan Kalvachev]

On Fri, Mar 28, 2008 at 2:51 PM, Kurt Garloff <kurt at garloff.de> wrote:
> Hi,
>
>  I recoded (Full-)HD material with mencoder into high-Q FMP4 with
>  the native resolution for my LCD screen, which has 1366x768 pixels.
>  (The nice side effect is that this now consumes much less CPU to
>  decode and runs without dropped frames on a not so fast machine.)
>
>  The graphics driver supports 1360x768 only (needs /8 x resolution),
>  so I decided to encode 1360x765. YUV420 requires an even number, so
>  mencode made 1360x766 from it. So far so good.
>
>  Playing it with mplayer, it does however rescale the material to
>  1362x766 (1362 ~ 16/9*766) -- which is absolutely not what I want.
>  No matter how good the scaler, the result will be worse than the
>  format I have encoded with. (The difference shows especially on
>  a digital screen, where you can get really sharp images.)
>
>  In general I think we should avoid scaling if the difference in
>  aspect ratio is tiny.
>
>  Attached patch does this for AVI files.
>
>  I guess this patch could be complemented by a similar patch that avoids
>  other tiny adjustments (e.g. if the video was encoded with 1366x768 and
>  our screen would only display 1360x768, one would rather discard 3
>  columns on left and right than having the sharpness reduced by
>  rescaling). I have not looked into that, though.
>
>  I would rather send this out and see whether people think it's
>  worthwhile ...

So, you  deliberately encode sample with small aspect change and then
you want to bloat mplayer with another useless option to fix what you
have done.
-noaspect would ignore the input file aspect info and assume 1:1
pixels of the decoded material.
Some of the encoders do :autoaspect: calculations, some reqiuare it as
separate option, but there is aways :aspect=1: override available.

Also why did you pick up 766 instead of 768, don't you know all codecs
like multiples of 16 ?