Avidemux Not Responding or Crashing? Fixes That Work

When Avidemux hangs (“not responding”), crashes on save, or shows a black preview, the cause is usually one of three things: the app is still indexing a large file, hardware decoding is misbehaving, or the video codec you picked does not match the output container. Below you will find the fixes organized by symptom — find your symptom, follow the steps, and skip the rest.

1. Avidemux hangs (“not responding”) when opening a large file

What you see

You open a big video (long screen recording, phone footage, VOB from a DVD rip), the window greys out, and Windows/macOS says the app is “not responding”.

What is happening

Avidemux is almost certainly indexing the file — scanning it to build a seek index. On large files this takes real time, and during indexing the UI does not repaint, which makes the OS report “not responding”. In most cases it is working, not crashed.

Steps

  1. Wait for the progress dialog. Avidemux usually shows an “Indexing” progress window. If it is there and moving, just wait — indexing a multi-GB file can take several minutes.
  2. Move the file to a local SSD. Indexing reads the whole file; a network drive, external USB 2.0 disk or SD card multiplies the wait. Copy the file to your internal drive first.
  3. Try disabling hardware decoding. Go to Preferences → HW Accel (hardware acceleration) and set it to None / disabled, then restart Avidemux and reopen the file. A broken GPU decoder path is a classic hang trigger.
  4. Rule out a nightly bug: if you are on a 2.8.2 nightly build, repeat the test with the stable v2.8.1. If 2.8.1 opens the file fine, you have hit a nightly regression — report it or stay on stable.

Tip: For phone (HEVC/VFR) footage, the first open is always the slowest. If you will edit the same project repeatedly, saving the project file (.py) after the first successful index saves you the wait next time.

2. “MUXER Cannot open” when saving

What you see

You hit Save, and Avidemux pops up an error along the lines of “MUXER: Cannot open” — nothing is written.

What is happening

Your video output codec does not match the output container. The classic case: leaving Video Output on Copy (copy the original stream untouched) while the container you are saving to cannot hold that stream type. Avidemux’s muxer then has nowhere legal to put the data and refuses to open.

Steps

  1. Use a known-good pairing. The two safest combinations are:
    • H.264 video + MP4 container (maximum compatibility), or
    • Copy mode + MKV container (lossless remux, MKV accepts almost anything).
  2. In Copy mode, check the source stream: e.g. copying an HEVC stream into an MP4 usually works, but copying MPEG-2 into an MP4 can fail — switch to MKV in that case.
  3. If you changed the encoder, make sure the output format selector (left panel) actually matches the file extension you typed in the save dialog.
Video Output Container Result
H.264 (x264) MP4 Muxer ✓ Safe default
Copy MKV Muxer ✓ Safe for remuxing
Copy (MPEG-2 source) MP4 Muxer ✗ Often fails — use MKV
HEVC (x265) MP4 Muxer ✓ Works, if your player supports HEVC in MP4

3. Black preview window (video plays “blind”)

What you see

Audio plays, the timeline moves, but the preview area stays black.

What is happening

The video display backend Avidemux picked does not cooperate with your GPU/driver combination.

Steps

  1. Open Preferences → Display (video output).
  2. Try a different backend: if it is on OpenGL, switch to Qt (or DXVA on Windows / VDPAU on Linux) and restart.
  3. Test with a plain H.264 MP4 to confirm the preview works before returning to your original file — this separates a display problem from a decode problem.
  4. As a sanity check, update your GPU drivers; stale OpenGL drivers are the most common cause of the OpenGL backend failing.

4. Display problems on Linux (Wayland)

What you see

On a Wayland session (Fedora, Ubuntu 22.04+ default, Arch with GNOME/KDE Wayland), Avidemux may show a blank window, fail to render menus, or crash on start — while it works fine under X11/Xorg.

What is happening

Avidemux’s Qt interface can hit Qt-on-Wayland rendering issues. The reliable workaround is forcing Qt to run through XWayland.

Steps

  1. Close Avidemux.
  2. Launch it with the platform override: 
    QT_QPA_PLATFORM=xcb avidemux3_qt5

    (or avidemux3_qt6 / the AppImage name, depending on your install)

  3. If that fixes it, make it permanent by adding env QT_QPA_PLATFORM=xcb to your desktop launcher, or export the variable in your shell profile.

Also worth knowing: the Flatpak and AppImage builds bundle their own Qt and tend to behave better on Wayland than distro-packaged builds. If the override does not help, try a different package format before assuming a deeper bug.

5. General fixes when nothing above fits

  1. Test with the stable release. If you are running a 2.8.2 nightly, download the stable v2.8.1 from the download page and see whether the problem reproduces. Nightlies are development snapshots — crashing is literally part of their job description.
  2. Reset the configuration. A corrupted config can cause crashes that survive reinstalls. Delete (or rename) the config folder and let Avidemux recreate it:
    • Windows: %APPDATA%\avidemux
    • macOS: ~/Library/Application Support/avidemux
    • Linux: ~/.avidemux6
  3. Reinstall cleanly. Uninstall, delete the config folder above, then install fresh from a known-good source.

Need the installer first? Grab the latest stable build on our Avidemux download page.

Frequently asked questions

Q: How long should I wait for Avidemux to finish indexing?

A: It depends on file size and disk speed. A few-GB file on an SSD usually indexes in seconds to a couple of minutes; the same file on a slow USB stick or network share can take much longer. If the progress dialog is advancing, let it finish — it is working, not frozen. Copying the file to a local SSD before opening is the single biggest speedup.

Q: What does “MUXER Cannot open” mean?

A: It means the video codec you selected cannot be written into the container you chose (for example, Copy mode with an incompatible source stream going into an MP4). Switch to a compatible pairing — H.264 + MP4 or Copy + MKV — and the error goes away.

Q: Will switching versions fix my crash?

A: Often, yes. If you are on a 2.8.2 nightly build, dropping back to the stable v2.8.1 resolves a surprising number of crashes, because nightlies are untested development snapshots. Always use stable v2.8.1 as your baseline when troubleshooting.