Avidemux problems after upgrading to Ubuntu Linux 22.10

[plux7887]

After updating my Linux system to Ubuntu 22.10, I recompiled Avidemux from the source code. Since then I've had a strange problem with Avidemux. When I start Avidemux, I can load, cut and save a video as normal. But if I then try to load a video a second time, I just get a gray empty Avidemux window with no video displayed. If I close the Avidemux program and restart it completely, I can load and edit a video exactly once again.

[eumagga0x2a]

Just in case: please make sure you don't try to run Avidemux on Wayland. This is not going to work. Wayland support is very much wanted, but currently not even started.

That said, if you have verified that you run Avidemux in an X session, then please redirect stdout and stderr of avidemux3_qt5 (or avidemux3_qt6 if you build for Qt6) to a file, reproduce the issue and provide that text file.

[plux7887]

the problem exists with all window managers and display servers. The following example files were created in an X session under a Plasma window manager. I just noticed that if I minimize the window and then maximize it again, the video is displayed. Minimizing and maximizing appears to update the display.

[eumagga0x2a]

Thank you, does closing Avidemux window while it is not maximized have any effect on the problem you experience?

Why do you use the unaccelerated "Qt" renderer (indicated by "RGB" label) to display video? You have VDPAU available (albeit the NVIDIA driver is very old – needed by very old hardware?) and also use VDPAU hw decoder – the "Qt" renderer is meant to be used as the last resort when all other options are either unavailable or result in crashes.

Please also try enabling OpenGL, restart Avidemux and test whether using the "OpenGL" / "QtGl" renderer has any effect on the issue.

[plux7887]

I compiled it new with the newest nvidia driver and activated VDPAU and OpenGL. Same Problem. See attachement.

[plux7887]

Building with Qt6 faild. See attachement.

[eumagga0x2a]

Building with Qt6 faild. See attachement.

I've seen this on Debian, please try the following private patch:

Code Select Expand

diff --git a/bootStrap.bash b/bootStrap.bash
index a11dc1e21..e13cea980 100644
--- a/bootStrap.bash
+++ b/bootStrap.bash
@@ -219,7 +219,7 @@ while [ $# != 0 ] ;do
                 qt_ext=Qt4
              ;;
          --enable-qt6)
-                QT_FLAVOR="-DENABLE_QT6=True"
+                QT_FLAVOR="-DENABLE_QT6=True -DQt6_POSITION_INDEPENDENT_CODE=True"
                 export QT_SELECT=6
                 qt_ext=Qt6
              ;;

to enable PIC in parts of the application which are linked against Qt6.

I don't have ATM an idea what is going wrong on Ubuntu. I don't see this problem with Qt5 builds on Debian 11, on Fedora 36 and Fedora 37 (all gnome-shell in an X session).

[eumagga0x2a]

Regarding building for Qt6 at least on Debian, you might need to modify PATH so that Qt6 executables (on Debian, in /usr/lib/qt6/bin) take precedence.

[plux7887]

With the help of the patch I managed to build a QT6 version. Many thanks. The error described above does not exist in the QT6 version. It only exists in the QT5 version on Ubuntu 22.10.
While building, I noticed the following warnings, but they don't seem to have any effect. What does that mean?

Code Select Expand

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_EDIT_COMMAND
    ENABLE_QT6
    Qt6_POSITION_INDEPENDENT_CODE


[eumagga0x2a]

While building, I noticed the following warnings, but they don't seem to have any effect. What does that mean?

Indeed, these warnings are completely harmless. Some of CMake variables set by the Process() function in bootStrap.bash are not evaluated while building some parts of Avidemux.

[betters]

I always leave Avidemux if I want to process another file. You can use a custom file if you have lots of config changes and want the same setup, that is what I do. I am also on Linux 22 and my recently locally built version does not have that problem (version 2.8.2 (230107_8807ce5230c_fflibs4.4.2).

It is always a good idea to start from a clean hymn sheet because you don't know what has been inadvertently not 'cleared up' when you close the input file (what uo experience being and example!).

I do 'sudo sync ; echo 1 > /proc/sys/vm/drop_caches' while logged out of Avidemux. The reason for this is that Linux has the annoying feature of building up everything you read/write in cache until it only has about 200MB left! OK, it then starts flushing stuff/swapping out but anything demanding RAM fast (like a gpu using ram) might well crash and your new run will benefit starting with a clean cache.

There have been many requests to have the kernel stop eating up free memory over the years but nobody ever sees the problem 'because it works'. That philosophy is outdated because most hard disks have lots of cache of their own and ssds are effectively a giant cache. The design is from the days when a read from hard disk was REALLY slow.

So, do what the kernel should have done for it!