[MPlayer-dev-eng] [RFC] aspect scaling, panscan etc. in windowed mode

[Reimar Döffinger]

On 13 Sep 2012, at 20:45, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le septidi 27 fructidor, an CCXX, Reimar Döffinger a écrit :
>> this is a long-standing issue and I'd like to resolve it, but I am unsure
>> what is most user-friendly.
>> Currently, when MPlayer plays in windowed mode, we rely only on the
>> windowing system to keep the aspect, i.e. we do not add borders.
>> As a side-effect, panscan and also zooming (with negative panscanrange
>> values) does not work either.
>> In addition, some window managers do not support forcing a fixed aspect.
>> For most vos, it is trivial to switch this behaviour, just by changing the
>> aspect_scaling function in libvo/video_out.h
>> So the option I have been thinking of is changing this condition to vo_fs
>> || vo_keepaspect
>> This would then enable adding borders/panscan in windowed mode as long as
>> the -nokeep-aspect isn't used.
>> So far I think that should not cause issues for anyone.
>> However, that still would leave no way to configure it to allow scaling
>> the window any way you want _and_ adding borders as necessary.
>> I'm not particularly keen on adding yet another command-line option
>> either.
>> Any suggestions? Any opinions on what would be a good way to do handle
>> this whole aspect handling in windowed mode?
> 
> I must say, I never understood the reason for the different treatment
> between full screen and windowed. Why not apply the letterbox or pan-scan
> logic in all cases: in full screen to our full-screen window, in windowed
> mode in the window itself. If the WM obeys to the hints, the bars are empty.

The reason is simple: that the letterbox/panscan code produces anything even remotely sensible in window mode is a relatively recent development.
And one that involved a lot of preparatory work, like making sure all vos actually provide the current window size in a somewhat consistent form.
And when all was done I didn't really feel like changing behaviour when I couldn't decide what is better.

> It makes impossible the current -nokeepaspect behaviour (there will be bars
> instead of stretching), but it could be made possible again by ensuring that
> -noaspect is not actually a synonym of "-sar 1".

Hm, that might be an option. However, if -noaspect no longer means -sar 1, I think we then lack a way to specify -sar 1, so that doesn't look so much like an improvement to me.