Qt5: the content of a maximized window "unmaximises" on video start

[eumagga0x2a]

When a video is loaded or an already loaded video is played in avidemux3_qt5, the Avidemux window gets usually resized to fit the width (but unfortunately not the full height, which might be a separate bug) of the video. If the Avidemux window was maximized prior to that, the window as such stays often maximized, leaving dead "ghost" controls behind while the content including the menus, the actual controls, the video surface etc. shrinks as it sees fit. The results look very weird (please see the attached screenshot).

rpm -q avidemux3-qt5
avidemux3-qt5-2.6.12-1.r160723_e9287b0f902.bootstrap.x86_64

Fedora 24

STR:
1. Maximise the Avidemux window
2. Load a video
3. Play this video

Actual results:
After Step 3, sometimes already after Step 2 the content of the Avidemux window "unmaximises" without letting the window manager know.

Expected results:
No changes of the position of menus and controls, the window and its content remains maximized.

Reproducible:
Sometimes (almost always on my system).

I had to reduce colors and remove transparency from the screenshot to fit into the very low size limit for attachments. I can't attach a screenshot of the gnome-shell overview which shows that the window really stays maximized.

[Jan Gruuthuse]

Do you have other options in Avidemux Menu -> Edit-> Preferences?
[Display] If you have an option available try this one/one of these if more:
- X11
- Xvideo (best)
- Vdpau (best)
- OpenGL (best)
- LIBVA (best)

[HW Accel]
select matching hardware for Display

This should improve display performance

[CPU]
only select options if your CPU has that option

[Threading]
Multi Threading
(*) Custom only select true Core(s) don't select HT.

4 core intel with HT (counts as 8 cpu) only use 4

Heat management:
---------------------
Make sure air ducts and inside computer cooling fans, including cpu & GPU fan are dust free.
If computer still runs hot, and you can put on stone floor, do so, this will additional help cooling down your computer.
Otherwise use table fan to circulate fresh air around your computer.

[eumagga0x2a]

Thanks, I should have mentioned that this issue occures with all usable video display drivers (no X11, no LIBVA). In case VDPAU ist selected as video output driver, it doesn't matter for the reproducibility of the bug whether video decoding in hardware via VDPAU is enabled. Multi-threading affects only lavc-encoding (and probably decoding as well?) and enabling or disabling it has no effect on this bug.

My PC has an older AMD dual-core CPU, thus no HT. The air circulation is excellent and the temperatures low 

Even if it makes sense to investigate the influence of a different window manager (running another desktop than gnome-shell), Avidemux will have to run under gnome-shell at the end.

[Jan Gruuthuse]

VDPAU: NVIDIA card? With the related software? And its driver?
see: avidemux 2.6.12 Compiling Avidemux on Ubuntu 16.04.1 LTS
1st post regarding nvenc
2nd post regarding Library Info, probably you need to translate ubuntu to fedora

[eumagga0x2a]

Yes, NVIDIA (GK106) with the binary driver from the 361.xx branch. nvenc is of no use for playback, I don't have it on my system.

Compiling Avidemux is really not an issue. The application has been packaged for Fedora and it is more than easy to install all build dependencies on Fedora very similar how you do it on Debian-derived distributions:

Code Select Expand

# dnf builddep avidemux

It works just with the spec file too:

Code Select Expand

# dnf builddep /path/to/avidemux.spec

Then install git and devel packages for Qt5, that is all.

I hope, Mean will be able to reproduce the issue and will find time to look into it.

[Jan Gruuthuse]

I never seen this behavior before, for now. Is this only happening with certain FLV videos?

Depending on what you did load: flv video and the used inside codecs: mainly video.
Avidemux is not showing correct info with loaded video?
Check with loading h264 encoded mkv(or mp4, ts). If VDPAU is installed correctly this should show Left hand of GUI below Video Decoder VDPAU vdpau

some interesting reading: http://rpmfusion.org/Howto/nVidia

When loading video (1080i or 4k) use numeric keyboard 3 or 4 with loaded video (zoom out).

screenshot:
- loaded 1080i video with zoom 4
- avidemux in vdpau mode

[Jan Gruuthuse]

The fifth generation PureVideo HD
-------------------------------------------
The fifth generation of PureVideo HD, introduced with the GeForce GT 520 (Fermi (microarchitecture)) and also included in the Nvidia GeForce 600/700 (Kepler (microarchitecture)) series GPUs has significantly improved performance when decoding H.264.[11] It is also capable of decoding 2160p 4K Ultra-High Definition (UHD) resolution videos at 3840 Ãâ€" 2160 pixels (doubling the 1080p Full High Definition standard in both the vertical and horizontal dimensions) and, depending on the driver and the used codec, higher resolutions of up to 4032 Ãâ€" 4080 pixels.

The fifth generation PureVideo HD is sometimes called "PureVideo HD 5" or "VP5", although this is not an official Nvidia designation. This generation of PureVideo HD corresponds to Nvidia Feature Set D (or "VDPAU Feature Set D").    

Nvidia VDPAU Feature Set D:
-------------------------------------
    Supports complete acceleration for MPEG-1, MPEG-2, MPEG-4 Part 2 (a.k.a. MPEG-4 ASP), VC-1/WMV9 and H.264.
    Global motion compensation and Data Partitioning are not supported for MPEG-4 Part 2.
    support for decoding H.264 with a resolution of up to 4032 Ãâ€" 4080 and MPEG-1/MPEG-2 with a resolution of up to 4032 Ãâ€" 4048 pixels.

source: wikipedia Nvidia PureVideo

[eumagga0x2a]

Thank you for keeping this topic afloat 

I never seen this behavior before, for now.

Does it mean you can't reproduce the bug following the STR? 

Is this only happening with certain FLV videos?

No, this depends neither on the type or size of the video nor on codecs. I've just tested under Xfce with nouveau instead of gnome-shell with the binary NVIDIA driver and could reliably (actually always) reproduce the bug there, thus ruling out gnome-shell and the NVIDIA binary driver as a possible cause.

The Qt4 build from the 2.6.12 release doesn't show this behavior, but a Qt5 one from the git trunk does.

some interesting reading: http://rpmfusion.org/Howto/nVidia

Thank you, I don't use NVIDIA packages provided by rpmfusion.org as their homegrown solution for compiling NVIDIA kernel modules locally as a systemd service (akmod-nvidia) has proven to be unreliable. The page do has a point here and there, though.

[Jan Gruuthuse]

Does it mean you can't reproduce the bug following the STR? 

Yes, I could reproduce, my opinion QT5 and  "Paint event: QWidget::paintEngine: Should no longer be called"
I never run avidemux at full desktop, (4k display). This is a 1080i video at 1:1, to much desktop wasted,  and it is known the player has it quirks and should not be used as such.

see full size screendump: https://www.dropbox.com/s/dm5zplgdq7plenx/16041QT54k.png?dl=0

[ajschult]

GUIPlayback::initialize calls
admPreview::setMainDimension calls
renderDisplayResize calls
MUI_updateDrawWindowSize

And I think qt declines to make the window larger than a certain size.

One possibility would be to not update the window size for this case (when called from GUIPlayback::initialize), but renderDisplayResize doesn't know it is being called from GUIPlayback::initialize.
Another possibility would be for MUI_updateDrawWindowSize to do nothing if it's asked to decrease the size of the window -- it would act more like ensure-the-window-is-big-enough

[Jan Gruuthuse]

That would explain what is going on. Thanks for your input and commits.

[ajschult]

Actually, UI_updateDrawWindowSize (called by MUI_updateDrawWindowSize) does some avidemux resizing and then triggers the qt update.  So, whatever logic is implemented would need to go in UI_updateDrawWindowSize.

Also, the Qt docs for QWidget::adjustSize says:

For windows, the screen size is also taken into account. If the sizeHint() is less than (200, 100) and the size policy is expanding, the window will be at least (200, 100). The maximum size of a window is 2/3 of the screen's width and height.

http://doc.qt.io/qt-5/qwidget.html#adjustSize

[eumagga0x2a]

Thank you very much on my part too. I try my very best to follow.

Everything IMVHO:

First of all, I would prefer Avidemux not to resize its window at all and leave it completely to the window manager and user. The loaded video should be zoomed smoothly to fit into the window (fixed zoom levels do should resize the window if not maximized to fit the video display). Anyway, Avidemux should never ever resize its window ââ,¬â€œ sorry, I meant window content ââ,¬â€œ on playback start, this should happen (if it should happen at all) only on video load.

Is there a way to query if the window is maximized? http://doc.qt.io/qt-5/qwidget.html#maximized-prop doesn't sound very encouraging (GTK allows that: https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-is-maximized)... If there is a way, Avidemux should find out this first and not touch window size (again, window content, sorry) at all then.

Actually, UI_updateDrawWindowSize (called by MUI_updateDrawWindowSize) does some avidemux resizing and then triggers the qt update.  So, whatever logic is implemented would need to go in UI_updateDrawWindowSize.

Also, the Qt docs for QWidget::adjustSize says:

For windows, the screen size is also taken into account. If the sizeHint() is less than (200, 100) and the size policy is expanding, the window will be at least (200, 100). The maximum size of a window is 2/3 of the screen's width and height.

http://doc.qt.io/qt-5/qwidget.html#adjustSize

This is probably the cause for a general issue with the height of the Avidemux window now. The height of the window is always too small when a HD video (1280x720) is loaded on a FullHD display actually big enough to accomodate the Avidemux window with the video display entirely visible.

[mean]

It is the adjustSize() that does not work as expected
I have a crappy workaround nearby, i'll commit it tonight

[eumagga0x2a]

Thank you, I thought you meant https://github.com/mean00/avidemux2/commit/855d28fd58cf2c85a640404ff8f33dc90b794f45, but it doesn't fix any of the resizing issues.