Avidemux Forum

For Win7/8/8.1, best I know is you're going to have to stick with avidemux_2.8.2 r241212_win64.exe (or the corresponding  .zip).

https://www.avidemux.org/nightly/win64/

Quote from: eumagga0x2a on July 02, 2025, 11:35:06 AMAll Avidemux builds are inherently portable, i.e. installers are for comfort ... Once extracted, the program directory may be moved e.g. to a flash drive ... "Portable mode" on Windows means that Avidemux stores user profile in the program directory instead of the default location in %appdata%\avidemux, i.e. the program directory must be writable for the user.

To note:

Though if using the .exe installer as 'portable', in order for settings to be stored in the program directory, the avidemux.exe file also needs to be renamed to, avidemux_portable.exe.

Runtimes don't seem to include DX12.
This thread may be relevant, perhaps there are some plugins/extensions that could be removed from the installer to make it work.

https://github.com/GPUOpen-Tools/Compressonator/issues/37

Windows 8.1 doesn't support DX12 so I don't think it can be worked around without providing a custom .dll with the installer to handle this.
Unless VC redistributables would do something...?

Quote from: Cormy1 on July 03, 2025, 11:03:12 PMWould it be sufficient to grab runtime libraries?

If you are able to try and to report back, that would be great. I can test on Windows 11 only.

I receive an error when trying to run "Avidemux_2.8.2 VC++ 64bits 250526.exe" and of course Windows 8.1 does not support DX12... Natively.
Would it be sufficient to grab runtime libraries?

What do the strings mean after QT5 in the builds? They don't seem to be in any kind of order in relation to the build numbers.

avidemux_r241110_win64Qt5_35.zip
avidemux_r241110_win64Qt5_36.zip
avidemux_r241110_win64Qt5_8.zip

Either use an X11 session or lauch Avidemux with -platform xcb Qt command line option (losing hw accel related features). In any case, you are much better off using the latest 2.8.2 code. However, Wayland remains entirely unsupported (the GUI is totally broken in Qt6 on Wayland).

It's too long to post here and says it's spam, but I've pasted it here: https://pastebin.com/fMdrEHuf

Is this a Wayland problem again? I was using X11 before but got switched back to Wayland in the recent KDE Plasma 6.4 upgrade.

Avidemux was phasing out Qt5, transitioning to Qt6 for Windows builds as well. Support libraries, namely ICU (international components for unicode), pulled in by Qt6 are partially responsible for inflated installation size, libaom AV1 decoder and encoder components being a major factor too.

In official cross-compiled, ZIP-compressed builds, files needed for plugin development are not removed. Cross-compiled builds with NSIS installer allow to deselect installation of those header and lib files during installation.

Native Windows builds (MSVC-compiled VC++ builds) use Qt Installer Framework (QtIFW) as installer rather than NSIS, which includes a full static build of Qt, huge in size. Creating a custom build of QtIFW with all unused Qt features disabled could reduce installer size a lot – if the project maintainer find time to perform the extra work necessary. Honestly, I doubt that it is worth the effort, but I'm not the maintainer to decide.

ZIP-packaged cross-compiled builds use a fast but relatively weak ZIP compression, NSIS-packaged ones use a much stronger LZMA algo, resulting in a smaller package size.

All Avidemux builds are inherently portable, i.e. installers are for comfort and in order to match user expectations only. Once extracted, the program directory may be moved e.g. to a flash drive (at a cost of much lower launch speed compared to a fast internal drive, especially a SSD). "Portable mode" on Windows means that Avidemux stores user profile in the program directory instead of the default location in %appdata%\avidemux, i.e. the program directory must be writable for the user.

Regarding output format, I'd recommend to stick with the MP4 muxer.

Regarding video encoder, the choice depends on capabilities of the targeted hardware. A safe option would be to encode to H.264 with x264 ("Mpeg4 AVC (x264)") using default settings with the only exception of a shorter GOP (group of pictures) length for better seek granularity, like the source video that uses GOP length / size (the interval between keyframes) of 75 rather than the default value of 250. Reducing GOP size (on the "Frame" tab of the x264 plugin configuration dialog) comes at a cost of a worse compression, of course.

If your target hardware supports hw accelerated decoding of HEVC, you might want to choose HEVC as codec with x265 as encoder both for better compression rate as well as quality.

Please remember to switch away from "Copy" mode for video in order for video filters to become available.

Keep audio in copy mode.