Avidemux Forum

Hello,

I'd like to suggest a new visual feature for Avidemux that could greatly enhance the editing experience, especially for users working with long videos or visual material that requires intuitive segment removal.

Proposal: A "LiveView" Mode

The idea is to add an optional LiveView (or Storyboard) mode (popup or not) that shows a grid or strip of I-frame thumbnails extracted from the video. Similar visually to lightbox in davinci resolve. The user could:

- Visually browse through the keyframes (I-frames) as miniatures.
- Select one or more segments between I-frames by clicking or dragging.
- Delete those segments visually, with the software performing the equivalent of Ctrl+X internally (without re-encoding).
- Return to the classic timeline view, where the cuts are already applied.

Technical feasibility

This could build on top of:
- The current GOP/keyframe analysis already used by Avidemux.
- The cut logic that handles markA, markB, and cut().
- Thumbnails either generated live (ffmpeg) or cached per session.

Why it matters

This feature would make Avidemux much more user-friendly for non-technical users, and extremely efficient for workflows where previewing and removing scenes quickly is critical — without losing the core principle of lossless editing.

Thanks for considering this suggestion, and for the great work you've done on Avidemux over the years!

Kind regards, 
Kikeb

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.