Aspect ratio changes don't work properly in Mozilla plugin on Linux

When changing the aspect ratio in the Mozilla plugin on Linux, the picture is not placed properly to fit within the plugin window. The picture is instead stretched to the height of the plugin window, with whatever width yields the proper aspect ratio. Since the plugin window stays the same size, only part of the video is visible.

Investigation has revealed that VoutDisplayFitWindow is being called, which asks the vout (xcb/xvideo.c) to resize itself larger than the plugin window. The vout_window (xcb/window.c) does not object, and so the resize succeeds. The vout should reject this request, thus forcing the video to be resized within the current window.

One possible solution to this problem might be to check the size of the window's parent, and refuse to resize larger than the parent. I'm not 100% sure this would work for the application. A simpler solution is for the vout_window to remember if it's embedded (it can know if it was started via Open or EmOpen) and reject resize requests when embedded.

Hi dmenest,

How are you getting on with this bug? I was about to open a new ticket for almost the same problem when I noticed your ticket.

Added attachment:

• 3848.patch

Sorry, I got lazy and never submitted my patch. I just attached it to this bug.

Added attachment:

• 0002-xcb-don-t-claim-Success-for-work-is-really-performed.patch

assigned to @Courmisch

I just sent a patch sightly modified, since I think the problem is more general.

I totally disagree with the second patch. Given X11 asynchronicity, there will be artifacts when resizing no matter what. You simply cannot synchronize the resizal with drawing of the next picture.

Pretending that we failed to resize the video is just worse than doing it later.

changed milestone to %1.1.3

unassigned @Courmisch

Sorry, the provided patch does not apply to master.

If resizing is bound to succeed, it should not matter that much whether we return VLC_SUCCESS or VLC_EGENERIC. I agree artifact will occur either way.

But, if for instance, a Windows Manager decides to limit the resize to fit within the screen boundaries, vlc core will have changed its size parameters three times, instead of two. For xvision, cost is low. for x11, it means rebuilding buffers to fit the new size, which is not so trivial.

added Status::fixed label

closed