[MPlayer-dev-eng] [libass] Ignore PlayResX/Y aspect ratio for font aspect ratio.

[Grigori Goronzy]

Nicolas George wrote:
> 
> There are TV shows where "dubious" encodings can be found both in downscaled
> XviD and in unscaled anamorphic x264. There are fan-made subtitles for these
> shows, some are in ASS to avoid subtitles over on-screen texts: they are
> supposed to fit both versions.
>

How do these deal with the VSFilter incompatibilites then? My guess is
the fan-made subtitles never were made for the anamorphic encodings as
"everyone" (> 90%) is using VSFilter that by default always uses the "k
= 1" behavior.

> Any heuristic is bound to sometimes make the wrong guess. We could simply
> take k = 1 as the default, this will be identical to the current behaviour.
> Still, I believe that a smart heuristic is a better choice by default. Those
> who disagree can set the option in ~/.mplayer/config.
>

Sure, I just wanted to point out one case where it can fail.

> 
> 2. The script is overcompensated but the heuristic detects it as anamorphic:
>    2a. The script is overcompensated.
>    2b. It does not use ScaleX to do its overcompensation
>        (either it uses ScaleY or \fsc[xy], or it finds stretched text nice).

Nice.  2b is something I didn't consider, but it's very unusual too.

> 
> And obviously, this is only relevant if the contents is itself anamorphic.
>

I think that's wrong.  It should be relevant if PlayResX/Y ratio differs
from the display aspect ratio. If the script doesn't specify PlayResX/Y
at all or just one component, this can easily happen. That should be the
worst problem, the heuristic doesn't work at all in such cases.

> 
> I am pretty sure I encountered at least once Matroska with embedded ASS that
> looked fine with the old (k = -2) behaviour. This heuristic is not perfect
> either.
>

I don't doubt that; most content is non-anamorphic and in this case the
old behavior is correct as long as no odd PlayResX/Y is specified.

> To gain time, I can submit a patch that adds the option with k = 1 the
> default, and therefore with no visible change from the user's point of view,
> and later submit another patch implementing the best heuristic we could
> devise in the meantime.
> 

Well, that's probably fine for now, but it'd be great if no libass code
will be modified; libass is now developed outside MPlayer (and hopefully
 the standalone library will be supported in MPlayer soon).

Grigori