panscan: garbage results with tallscreens (multi monitor)

[ballerburg9005]

When viewing a tallscreen (9:16) video on a widescreen (16:9) monitor, panscan "zooms" into the video at the expense of removing an upper and lower portion of it, thus scaling it over 100% beyond the screen.

But when all aspect ratios are reversed, meaning a widescreen video is watched on a tallscreen monitor, it fails to produce the exact same behavior in a sensible manner.

In any kind of sensible manner, the video would be "zoomed", as described above, only that now the left and right portions are cut off instead of the upper and lower parts in order to fill the vertical (and not horizontal) black voids.

But as it is now, only -panscanrange -1 produces any kind of visible change and that change is as following: the video is magnified (as visible to the eye with correct scaling) but it maintains the exact same height on the screen. Thus the black voids above and below also remain the exact same height, and it is cropped in all directions, which totally defeats the purpose (to cut off black bars inside video left and right and expand the image up and down).

You can easily reproduce and test against this behavior, by simply reducing mplayer window size to 9:16 and trying to fit a widescreenified video to it. One of those videos with blurry bars left and right or 4:3 video put into 16:9, both pretty common and annoying.

I would further argue that "panscanning" by itself is a misconception, associated with such unwanted assumptions and defective behaviors as described.

The all-users all-time desired feature is simply video magnification in relation to window size. E.g. a 200% scaled video would always produce a window that captures 50% of the video with 100% of the window's pixels, as the theoretical image is twice as big, with either vertical or horizontal crop dominating first as the window's aspect ratio misfits the video's.

Quite honestly, this and only this makes perfect sense and it is the elegant solution.

There is no reason, why any panscanning should depend on actual X11 screen size or dimensions, graphics drivers and so forth.

[ballerburg9005]

I was just able to produce the desirable output by simply specifying the window's dimensions manually with -geometry WxH.

However I still want to emphasize that this is only a workaround solution, which corrects for unreasonable assumptions of the program. One which I have spent 2 hours over reading manpages and trying to understand the inner workings of Mplayer.

Mplayer should read and constantly update the correct dimensions from window size, to produce a consistent, intuitive, user-accessible and reliable behavior.

As mentioned before, actual "pan scanning" as a feature ought to be a misconception and cannot work properly or desirably if taken literally. Since pan scanning only denotes the removal of usable parts of the video footage to fit a screen format.

In contrast, what the user needs and expects is merely magnification of the video. This is either, and most widely used so and most importantly so *to remove unusable parts of the video* (black and fuzzy blurry bars inside the video data itself).

Only secondary to that, some people want to actually crop off parts of usable footage, and those people are an extreme minority. No one however wants the video shrunk down because the screen is bloated with unusable footage and the "mplayer zoom feature isn't working for reasons entirely inaccessible to common sense", to put it bluntly.

I am not saying it hasn't worked out mostly or somewhat acceptably all this time for single monitor widescreen and 4:3 setups. I am just saying, if it ought to be right, this is how it is.

[compn]

yeah -panscan was created prior to 2002. I cant even find the commit for it. maybe back in cvs days even.

but this is not a proper bugreport. which video output are you using? did you test all of them? maybe this works in one vo but not the others. i am wondering if it is vo bug or panscan bug...

to answer your question, the panscan is done in the video output for fastest playback. thats why it relies on x11 size. it also works on mac osx and windows in certain video outputs. if you want to panscan in a different way, you should instead use -vf cropdetect and -vf crop...

strangest bug request i've seen in years. a tallscreen monitor! poppycock!

[ballerburg9005]

Thanks for your response!

I am using three 1080p screens on a Nvidia GTX660 with :0.1 and :0.2 being oriented tallscreen left and right respectively to a widescreen on :0.0 via metamodes via nvidia-settings.

The screen is fully accelerated and you can move windows across screens. It is a very common setup.

The panscan behavior is identical on all screens as far as I can tell, whereas either 1920x1080 or the total virtual size of 4080x1920 serves as the fixed aspect ratio that serves to crop the video at all time the same no matter the window size, I can't tell.

Multi-monitor is pretty common nowadays. Especially when people are putting a laptop with tiny 4:3 screens at home into their docking station and then use for example a 4K display (however it is oriented) as second monitor. Then they are like me confronted with misfit screen aspect ratios.

I believe every modern office desk has (at least) two monitors now. Tallscreen has huge advantages when editing documents, viewing PDFs, computer programming, and so forth. If it wasn't for the fact that rotatable monitor stands are just very expensive, and that you can now buy 4K displays and divide them into two or three with windows, I believe tallscreen would be a whole lot more commonly used right along widescreen.

People use their phones mostly in tallscreen format, and also record videos this way. This has lead to the situation, where it is pretty common to encounter videos that are totally misfit to the screen aspect ratio and leave as much as 80% of the screen space blank.

Even worse, some of those videos have been widescreenified again.

When such a video is viewed on a tallscreen, without panscan for magnification, this does leave some staggering 96% of the screen space wasted.

[beastd]

Which MPlayer vo (video output) are you using?

Could you try using vo gl and check if the behavior is different?

[ballerburg9005]

The behavior is exactly the same.

[reimar]

I'm afraid it behaves correctly/the way that you describe with -vo gl for me.
xv, x11, vdpau all seem buggy in various ways however.
Note that normally you should not be able to change the MPlayer video window to a size that does not match the aspect, if you can that means your window manager is not respecting some of the hints.
It seems rather unlikely, but if -vo gl DEFINITELY is affected, that is the most likely explanation I can think if: when PAspect is set your window manager fails to enfore the aspect, but instead reports an incorrect window size to MPlayer.
That would also explain why you need -panscanrange, which I do not need.
To investigate further I'd need to know which Window manager you use.