Avidemux Forum

First, thanks to the developer of this app, I think it's the best MKV editor on the planet!

To download the files, head to my Proton Drive: https://drive.proton.me/urls/JNHHJPAG2M#f7ZP0FwujNB8

The file names are fairly self-explanatory as to what they are. If you have any questions or problems, let me know. The Linux builds are self-contained AppImage files and the Windows ZIP is a portable version of Avidemux.

Once you're done editing your media file and save it.... you can leave Avidemux open or close it but shortly after saving your file, in that same folder, you'll eventually see a file named '.subs'. That will be the FINISHED file with your edits AND time synced and retained subtitles!

Example, say you're editing a file named 1.mkv. Make your changes and hit save and it will default to naming it 1_edit.mkv. A few seconds later (depending on the speed of your disk sub-system) this modified version of Avidemux will produce 1_edit.subs.mkv.

While it's creating the .subs file, it's normal to see a weirdly named mkv file for a short time. This is just a temp file so don't panic.

I hope you all find this modified version of Avidemux as useful as I do.

Thank you for the (incomplete) log. Regarding libva, the lines

libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1
look for me like a very old libva version from Avidemux appImage build environment conflicts with a less outdated driver version on your system.

Quote from: JanMeki on November 06, 2026, 10:14:33 AMDo I need to install a lot of stuff to do that?

There is a script "createDebFromSourceUbuntu.bash" which automates (should automate) installation of dependencies, see README ("Debian / Ubuntu and variants"). Or do you mean that you are storage constrained, with little free space on the root filesystem?

Quote from: alexstorm on October 28, 2026, 08:39:49 PMI would be interested in seeing the steps you use to get AI making subs.
...snip...

I asked ChatGPT to type up everything my brother and I did and here you go (wall of text warning)

How I Added Automatic Subtitle Preservation to Avidemux Using Claude Code and Codex

I thought I'd explain how this project evolved, because it wasn't simply a case of giving Codex a single prompt and having it create everything from scratch.

The original subtitle-repair utility was developed using **Claude Code**. Later, I used **ChatGPT to help formulate the instructions for Codex**, which integrated the existing utilities into Avidemux and eventually compiled working Linux and Windows versions.

1. The original Claude Code project — avisubfix

The original problem was that Avidemux discards embedded subtitle tracks when saving an edited MKV.

I wanted to be able to remove unwanted scenes from a movie or TV episode, save it using Video Copy and Audio Copy, and retain the original subtitles with their timing corrected automatically.

Claude Code initially developed a standalone Python utility called `avisubfix.py`.

It was designed to:

- Read an Avidemux project file (`.py`) to determine exactly which sections of the original video were retained.
- Interpret Avidemux's `loadVideo`, `appendVideo`, `addSegment`, and marker information.
- Extract subtitle tracks from the original MKV using MKVToolNix.
- Remove subtitle events belonging to deleted portions of the video.
- Adjust subtitle timestamps to match the new, shorter timeline.
- Trim subtitle events that overlap cut boundaries.
- Preserve subtitle track languages, names, ASS styling, and supported font attachments.
- Handle SRT, ASS/SSA, WebVTT, and PGS subtitles, with some VobSub support.
- Preserve and adjust chapter information.
- Remux the corrected subtitles together with Avidemux's edited video/audio using MKVToolNix, without re-encoding the video or audio.

The standalone utility could be run manually after saving a project and edited MKV.

For example:

`python avisubfix.py --project cut.py --edited cut.mkv`

This created a separate corrected MKV containing the edited video, audio, and restored subtitle tracks.

The subtitle-repair logic itself was independent of Avidemux's GUI.

2. Turning the standalone tool into an automatic Avidemux feature

The next goal was to eliminate the need to save an Avidemux project and manually run a Python command after every edit.

Using Codex, we developed an integration that connected the existing subtitle-repair engine to Avidemux's native save process.

The resulting helper system consists of three principal Python files:

**`avisubfix.py`**

The original subtitle-processing engine. It contains the logic for interpreting video cuts, extracting subtitles, correcting timing, and rebuilding the MKV.

**`avisubfix_integration.py`**

Handles the automatic post-save workflow. Instead of requiring a separately saved Avidemux project, it uses a manifest generated by the modified Avidemux save code. This manifest identifies the original source files, retained segments, source timestamps, and output timeline positions.

It also handles timing details such as source timestamp offsets and B-frame timing, which are important for accurate synchronization.

**`avisubfix_autorun.py`**

Supervises the background subtitle job. It launches the processing engine, handles the required external utilities, and allows subtitle processing to continue independently of the Avidemux GUI.

Codex also modified Avidemux's C++ save path so that, after the edited MKV has been successfully saved and closed, Avidemux can generate the required information and launch the subtitle helper automatically.

The workflow is now:

1. Open an MKV in Avidemux.
2. Make the desired cuts.
3. Select Video Copy, Audio Copy, and MKV output.
4. Save the edited file normally.
5. Avidemux launches the subtitle-restoration process in the background.
6. The helper creates a second file named `filename.subs.mkv` containing the edited video/audio and corrected subtitles.

The original edited file remains untouched. The second MKV is the subtitle-restored version.

There is no need to manually save a project, run Python, or open another program. The background worker can also finish after Avidemux has been closed.

3. First successful Avidemux integration — 2.8.1 Qt5

We initially had problems with newer Avidemux builds stuttering when pressing Up Arrow to seek between keyframes during active playback.

The older Avidemux 2.8.1 Qt5 release worked correctly.

Codex therefore integrated our subtitle tools into Avidemux 2.8.1 Qt5 and produced:

- A Linux AppImage.
- A Windows x64 portable version.

Both were successfully tested, including subtitle synchronization and automatic background processing.

That established a working reference implementation.

4. Moving to Avidemux 2.8.2 and Qt6

After the developer posted a fix for the playback seeking regression, I decided to try compiling everything again using the newer Avidemux 2.8.2 development source and Qt6.

The upstream seeking fix was:

https://github.com/mean00/avidemux2/commit/e054b7985521f78fd44d2ca932af6f0cc01fa2dc

I asked ChatGPT to prepare a detailed Codex prompt using our existing working subtitle project as the starting point.

Here is the opening of the actual prompt:

> I want you to build a new experimental version of Avidemux using the latest available Avidemux 2.8.2 development source, Qt6, the recently released upstream playback stuttering fix, and our previously completed custom subtitle-preservation modifications.
>
> Important: Skip ALL testing. Your job is to integrate, compile, and package the software only.

The rest of the prompt instructed Codex to:

- Reuse the existing working subtitle implementation rather than rewrite it.
- Use the Avidemux 2.8.2 development source.
- Verify that upstream commit `e054b798` was included.
- Use Qt6 exclusively, with no fallback to Qt5.
- Preserve the complete SRT, ASS, PGS, chapter, and background-processing functionality.
- Adapt the integration to any changes in the 2.8.2 source.
- Compile a Debian 13 Linux AppImage.
- Compile a Windows x64 portable version.
- Bundle the necessary helper utilities and runtime dependencies.
- Keep the existing working 2.8.1 builds untouched.
- Skip automated and manual runtime testing, since I would test the final builds myself.

The exact Avidemux source revision Codex selected was:

`c7e6576d605de685fae0b126204e4258aa92026d`

That revision already incorporated the upstream seeking fix.

5. Linux Qt6 build

Codex successfully compiled and packaged Avidemux 2.8.2 using Qt 6.8.2 on Debian 13.

It included our C++ subtitle-save modifications and Python helper utilities.

I personally tested the finished AppImage.

Both major requirements worked:

- Up Arrow seeking during active playback no longer stuttered.
- Saving an edited MKV automatically produced a correctly synchronized `.subs.mkv` file.

6. Windows Qt6 build

The Windows build required additional work because our earlier cross-compilation environment used GCC 5.5 and Qt5.

Codex established a newer native Windows build environment using:

- MSYS2 UCRT64
- GCC 16.2.0
- MinGW-w64 14.0.0
- Qt 6.12.0

It compiled Avidemux and packaged the portable Windows application with the subtitle utilities, Python, MKVToolNix, and the necessary runtime libraries.

The first Windows Qt6 build successfully saved edited videos but failed to generate the `.subs.mkv` file.

Rather than blindly modifying the code, I instructed Codex to compare the working Windows 2.8.1 implementation, working Linux 2.8.2 implementation, and failing Windows 2.8.2 implementation.

Codex identified a specific problem:

The Windows launcher supplied a `--mkvtoolnix-dir` argument, but the bundled `avisubfix_autorun.py` supervisor did not recognize it. Python's argument parser exited before subtitle processing began.

Codex restored the missing argument handling and rebuilt the Windows package.

The corrected **Windows Fix1 build now works properly**, including automatic subtitle restoration.

7. Final results

As of November 6, 2026, I have personally confirmed that both versions work:

**Linux:** Avidemux 2.8.2 development + Qt 6.8.2 + upstream seeking fix + custom subtitle preservation.

**Windows:** Avidemux 2.8.2 development + Qt 6.12.0 + upstream seeking fix + custom subtitle preservation.

Both support smooth keyframe navigation during playback and automatic generation of subtitle-restored MKV files.

The original 2.8.1 Qt5 builds have been retained as backups.

Final thoughts

I want to emphasize that this isn't an official Avidemux feature or a simple Python script dropped into an unmodified Avidemux installation.

The solution combines modifications to Avidemux's C++ save process, a Python subtitle-processing engine, a background supervisor, and external MKVToolNix utilities.

Claude Code provided the initial standalone subtitle-repair solution. Codex was used to integrate the utilities, adapt the C++ code, port the implementation between Avidemux versions, and compile/package the custom builds. ChatGPT helped formulate the detailed implementation and troubleshooting prompts.

The important part was having an existing working implementation for Codex to reuse, rather than asking it to invent the entire solution in one pass.

For my MKV editing workflow, the result has been exactly what I wanted: I can cut video in Avidemux without re-encoding, and the subtitle-preservation process runs automatically afterward.

eumagga who moderates here generally recommends We Transfer, Dropbox, Mega or Google Drive. I'm assuming Proton Drive is a similar alternative and accessable to all, if so, I cannot see a reason not to use it if that is your prefered choice.

Quote from: eumagga0x2a on October 27, 2026, 10:28:45 PMProbably due to mismatch between the build and the host environment or due to another reason – please redirect stdout and stderr of appImage to a file and attach it to your reply here or post it on some pastebin equivalent as far as that service doesn't require login.

Code Select Expand

Code Select Expand

./relative/path/to/appImage 2>&1 | tee path/to/admlog.txt
Please replace paths containing personally identifiable information in a consistent way with placeholders prior to uploading the log.

Here it is LOG

Quote from: eumagga0x2a on October 27, 2026, 10:28:45 PMCould you please eventually do build Avidemux locally to have a clear picture of what works and what doesn't?

I need to look into that when I have more time. Do I need to install a lot of stuff to do that? I use the app image because it's easy.

Quote from: sark on October 30, 2026, 10:58:49 AM

Quote from: roadhazard on October 28, 2026, 01:11:00 AMI don't know if I'm allowed to post it here but if I can, I'll gladly share it with the world. To me, this makes Avidemux 1000x better.

If you're not posting links to alternatives to Avidemux (bad form), and there are no potential licensing issues with anything you post, it really should not be an issue.

Where would I post it? Can I add a link to my Proton drive on here?

There is an unofficial Apple Silicon ARM binary build at https://github.com/jw-tecuri/avidemux2/releases

Should be fixed now, primarily by this patch, please try a future nightly build.

Thank you for your report.

Some filters were dropped long before I started contributing to Avidemux during transition from frame-based Avidemux 2.5 to time-based Avidemux 2.6+ era as they were incompatible with the new software design.

For reversing a selection of a video in Avidemux, save it as PNG (to be lossless) or JPG (for smaller size) images to an empty directory, then check the checkbox "Load sequentially named pictures in reverse order" in the Import tab of Avidemux Preferences, then load the first one of the exported pictures.

Thank you for being persistent. Yes, it looks horrible, especially on macOS, I missed the issue because I generally got used to hitting the space button (i.e. stopping playback) before seek and because Qt on my Linux machine is so much faster, making the problem harder to notice when testing. Anyway, the bug is understood, a fix will follow soon (hopefully).