Avidemux Forum

I uninstalled the 2605 version ans installed the new nightly.
Windows, of course, tried to stop me running it,
but I found the "run anyway" button.

The new version did not fix the problem,
but I have found a work around:

Running AviDemux as an Administrator allowed it to set the new default settings.
Subsequent runs of Avidemux were able to pick up the new defaults,
without running as Administrator.

I just have to remember that if I want to change them again in the future, then I will need to run as Administrator for that session.

This is good enough for me. Thank you for your help.

A new cross-compiled official Avidemux nightly has been generated and uploaded. Upon a quick look at the ZIP-packaged variant (didn't try the installer-packaged one), I understand what might have posed a problem: please make sure the Avidemux executable is not named "avidemux_portable.exe" but simply "avidemux.exe" else it will try to save its configuration to install directory rather than to %appdata%. If the install directory is not user-writable, this will fail causing the problem you describe.

Alternatively, make the install directory read-write for your user.

Quote from: RocketJet on July 27, 2026, 12:36:16 AMI have very little experience with Linux,
it is rather beyond me to do a cross-compile.

Which is a pity as e.g. this official nightly lacks NVENC-based video encoders (which is a build environment configuration issue) which would be available in your own, local build.

I do have multiple versions of Avidemux installed,
so I renamed the Avidemux folder in %appdata%.
I also uninstalled all versions of Avidemux,
downloaded the latest current nightly of the ming64 version,
and reinstalled from that, and rebooted.

It did not fix the problem,
but I should now have a clean Avidemux install,
which is good.

TT don't use Mpeg-2 TS files anymore,
though I sometimes use AviDemux to
extract Mpeg-2 from MKV into an Mpeg-2 PS file.
I have not noticed any problems with that.

I have very little experience with Linux,
it is rather beyond me to do a cross-compile.
I can wait for the next nightly windows build, thanks.

I've updated MXE setup scripts and was able to test my own build off the latest git on Windows 11: "Save Current Settings as Default" works for me as it should.

If you have access to a somewhat powerful PC with a current Linux distribution (e.g. Fedora 44) and 10 GiB or more free storage space, I would recommend to cross-compile from source as described here (the description itself has not been updated but should work as-is).

At least the current git master works fine (on Linux, testing on Windows is not possible for me ATM) in this regard. From 2026-04-08 to and including 2026-05-29 is a very unfortunate time range as opening MPEG-TS streams with MPEG-2 video was broken.

If you don't need MPEG-2, it should be more or less fine function-wise. Can it be that you access the same Avidemux profile from different Avidemux versions? As configuration was changed on April 8, returning to an earlier build may be problematic. In doubt, please rename %appdata%\avidemux directory and retry with 260516.

The "Save Current Settings as Default" menu option no longer seems to be honoured for Video settings. In the next session Video resets to Copy, and the Config reverts to default values.

I am running Avidemux 2.8.2 260516_46963d075c1-fflibs 7.0.2  mingw 64bit
under Windows 11 on an Intel PC, with a local account.

I also have an old version that works fine in this regard,
on a Windows 10 AMD PC, with a Microsoft account.
Avidemux 2.8.2 250526_b008a4d098-fflibs 7.0.2-VC++

Quote from: Redcrest82 on July 16, 2026, 08:26:54 AM

Code Select Expand

Assert failed :0 at line 116, file F:
\jenkins\workspace\VS2019_no_import\avidemux_plugins\ADM_demuxers\Mp4\ADM_atom.cpp

Honestly, I would not expect a different outcome with a recent nightly, but still please try nevertheless with the most recent build from the folder with cross-compiled builds. It should dump a more verbose debug message to admlog.txt in %localappdata%\avidemux directory. The file might be slightly corrupted.

If the file still triggers this assert failure (an orderly termination of the application to avoid a condition not handled by the code), please provide the file via Mega, Dropbox, Google Drive (link share that doesn't require a Google account to access the sample) or an equivalent service.

Thank you for the reply eumagga.  That 2.9.0 was a mistake.  It should have been 2.8.2.  My apologies.  I must have been doing it wrong.  I just tried it again using the round Red X button to cut the section in the middle and was able to save the video correctly, without getting the error message.  Thank you for your help. 

Try using a more recent version of Avidemux

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

Hello,

The same file opens properly in other tools.

Error output is:
Assert failed :0 at line 116, file F:
\jenkins\workspace\VS2019_no_import\avidemux_plugins\ADM_demuxers\Mp4\ADM_atom.cpp

Please let me know how I can share the problematic MP4 file.
This post has restrictions in format and size for attachments.

Thanks in advance