Feature request: constrain window to video aspect ratio

[willgfx]

It would be nice to be able constrain the window to the video's aspect ratio when manually resizing.

[Rafostar]

I always wanted to have the resize work like that, but it is not easy to achieve in GTK apps. If I am not mistaken other GTK video players don't have that ability either (totem and celluloid).

I would prefer to have the video rendering widget merged into GStreamer first, cause it might require some changes to get working what you ask for. Now that GTK 4.0 is released (and considered stable API), I will work towards having that updated and merged.

[Rafostar]

A user provided a video with this demonstration.

I think that we can do something similar here for this functionality and make it an opt-in in preferences. So when enabled in Clapper prefs, after user finishes dragging the window to such-and-such size (with black borders), Clapper window automatically resizes itself to best possible (nearest) size for played video, reducing its size by borders amount (with fluid animation, like we have for show/hide bottom panel when clicking PiP button).

[frandavid100]

That would be great.

[RedAuburn]

This would be really nice. Firefox's PiP window is able to keep a set aspect ratio, maybe looking at that implementation could help?

[nekohayo]

Besides the whole "preserve aspect ratio while the user is resizing" idea, I think a good first step would be to have clapper auto-size the window to the correct size and aspect ratio when it is launched directly with a video file (i.e. by Nautilus).

If the window is already in the correct aspect ratio, and auto-sized to fit most needs (i.e. look a the video's resolution vs the screen resolution, and try to fill maybe 80% of the screen if the video's resolution isn't too low) from the start, then it would already do most of the job and the user wouldn't even need to resize in most cases.

This could be done independently as a first step, before a (more complicated) solution is found for constraining.

[Rafostar]

The problem with window doing this on its own is that this would break all kinds of tiling compositors. There are also use-cases that user might actually want to have black bars in window (e.g. show OSD on them to not cover subtitles). Having an opt-in in prefs seems tiresome to constantly go there and enable/disable it for current usage.

Taking above into account, I suggest assigning mouse middle click to this. Seems easy and fast to perform, will not break tiling compositors and doesn't require constantly going into prefs to change this config (also avoids one more option to have).

[RedAuburn]

the main usage i would have for this is when the player is in picture-in-picture mode, like the old version used to have. Only constraining aspect ratio when in PiP mode would work well IMO

[Rafostar]

the player is in picture-in-picture mode, like the old version used to have

We do not have a different/dedicated PiP mode in new UI, but it doesn't mean there is no such functionality. All you have to do is right click anywhere on the video and select always on top option from context menu. This avoids us ugly hacks that we had previously and even stopped working after some GNOME shell update.

Basically, what I mean is that we need a single way for this feature to work the same regardless if always on top is selected or not, since mutter handles that and we aren't aware of it's state here.

[Rafostar]

Other problem that we want to avoid, example:

User constrains window size, selects always on top option, puts video in screen corner, then plays few videos in queue with order with aspect ratios: 16:9 -> 4:3 -> 16:9 -> 21:9 -> 16:9.

What happens to the window then? Does it stay intact? Does it grow or shrink when going to different aspect (also consider how these aspect differs - black bars at different side depending on video). Also if it was at some size initially, will it go back to this initial size after all this aspect changes? When video width is longer will it go outside the screen on its own?

For these reasons I suggested manual "resize to best fit" action with a middle button click on video. Cause the benefit of it is that if you lets say play 7 videos with the same aspect and some very short clip at different aspect in between them, then otherwise size would change and it would be hard/impossible to get it back into exact same size and place automatically where it was earlier.

It can be always changed in future when/if someone comes up with better idea, but hey, its much better then nothing, right? 😉

[Rafostar]

Taking above into account, I suggest assigning mouse middle click to this.

Nobody seems to be against, so I went ahead and implemented just that:

out.webm

(note that PC I was recording this sucks - its recording task that causes slowdown/stutter)

[sp1ritCS]

Nobody seems to be against

well, the downside is that it doesn't work without interaction. Maybe the usecase of having a small clapper window as pip in the corner of the screen, while having an application that captures the mouse (mostly video games) might be slightly impaired.

I doubt it's that really relevant tho.

[Rafostar]

well, the downside is that it doesn't work without interaction.

yeah, but there are multiple things that may go haywire if I try to make it force itself to keep aspect ratio while resizing. GTK does not do this for a reason. Also, I am not closing this issue.

The main use-case for this is PiP like "always on top" usage of Clapper window, yes. On the other side, with this you can middle click on a window, put it in a corner and forget its there. Automatic behavior would each time a video with a different aspect is played cause window to change its size and position on its own (we cannot control window position on Wayland) which seems like it would actually need more interactions for the user to keep fixing its position.

Just imagine how annoying it would be when you are just about to click something or reading something, meanwhile video changes causing window size and/or position to change and covers it.