Avidemux Forum

I think it's very important Avidemux should give a warn when sees an unsupported stream in MKV (like soft subtitles), that will be removed on conversion/copy of audio/video streams.
I'm quite advanced user but converted many video before realizing it removed all of that. Fortunately of some I kept the original, extracted subtitles and re-added, but some I lost the subs.
I Imagine many users fall on this, and it is a subtle dataloss bug/rfe.

Currently 2.8.2 nightly 260516 on Debian 13

Hey! With all the warnings my Mac OS has given me about how my avidemux binary is going to stop running when Apple deprecates x86 support, I figured I better build an ARM native version to head that off. Found and fixed some issues and it now builds.

The current master fails to build natively on Apple Silicon with Homebrew due to two new issues:

Linking:

The SDL3 link sites use the bare library name, and /opt/homebrew/lib  isn't in the default linker search path on Apple Silicon.

ld: library 'SDL3' not found
make[2]: *** [ADM_render_qt/libADM_render6_QT6.dylib] Error 1

Packaging:

fixup_bundle's search dirs hardcode /usr/local/lib, the Intel Homebrew prefix.

CMake Error at BundleUtilities.cmake:725 (message):
  error: otool-classic: can't open file:
  @rpath/QtCore.framework/Versions/A/QtCore (No such file or directory)
Here are the fixes for them

I've submitted both fixes as https://github.com/mean00/avidemux2/pull/555. Until it's merged, you can build today with:

git clone https://github.com/mean00/avidemux2.git
cd avidemux2
git fetch origin pull/555/head:pr555
git checkout pr555
bash bootStrapMacOS_Monterey.arm64.sh

Verified on macOS 26.5 (M-series), Homebrew Qt 6.11.1 / SDL3 3.4.14, CMake 4.4.2: clean bootstrap run through DMG creation and ad-hoc signing, all-arm64 bundle, app launches and a copy/copy cut saves and probes clean. No extra environment variables needed.

Above, I believe I meant to say, "PAR", Pixel Aspect Ratio.

so (something more along the lines of) ...

So lets say Media Info showed ...PAR... to be 1.3 (non-square pixels or whatnot).

Derived from display width, adjust by ...PAR...

Sorry, but I'm not good in this stuff, thats chinese to me, i can work with avidemux but not build my own avidemx
And i have no Linux, or VM, anyway

And in that respect, I was thinking of a setting in Avidemux, something like:

Derived from display width, adjust by DAR

That would go out, see that non-square pixels exist, & do the computation automatically...

Well you can do that, in a round about way - perhaps*.

*Perhaps, depending on Output Format.  Like mp4, mkv, but not flv...


Output Format
Configure -> Force aspect ratio --> Derived from display width


At that point, you need to set the Display Width to a number that "works".

In a recent video, output A/R was coming out wrong, & that had to do with the (oh, I'll probably get the terminology wrong, but...) DAR.
The DAR was weird.  So I took the expected Display Width, then divided that by the DAR (as reported by MediaInfo).

(I think that was the deal.)

So lets say Media Info showed DAR to be 1.3 (non-square pixels or whatnot).
So I took the expected Display Width, say 480, then divided that by 1.3, & used that value, 369, as the Display Width setting in Avidemux.

With that the output file A/R was as wanted (or at least close enough, given rounding).


(Again, I may have terminology wrong, or my numbers could be wrong, but the basic premise did work out.)

An official Qt5 Windows version would be great. Why switch when it brings downgrade in features and also in supported platforms...

If you fancy cross-compiling Avidemux for Windows from the latest git master yourself, the resulting Qt5 build should have the progress indicator on taskbar button again (the relevant definition is now set).

You need Linux (preferably Fedora or latest Debian stable) installed (a VM should suffice) with at least 8 GiB of available memory and 16 GiB free storage for that. The howto is in parts (especially regarding description of applied MXE patches) outdated, but mainly valid.

Hello,
I notice that the Avidemux window is gradually coming to resemble the version from December 12, 2024, which offered better visual comfort.
However, the progress bar (timeline) remains very mediocre, featuring a circle and scale markings that are unpleasant to work with.
Is this a consequence of Qt6, or simply a deliberate design change that—in my opinion—is a complete failure?
Thanks nonetheless to the developers for continuing to improve this very handy tool.

I am not optimistic about a chance to get this implemented as FFmpeg libraries libavcodec and libavutil Avidemux uses to decode HEVC (and most other video codecs) don't pass the distinction keyframe vs IDR to decoded pictures.

The "non-IDR recovery points" warning is just a warning to reflect poor guesswork in libavcodec when dealing with POC discontinuities, i.e. if the target video player is not FFmpeg-based, the chances are high that it will play such streams just fine.

The presence of IDR frames in an open-GOP H.264 or HEVC stream is not guaranteed at all, and even if present, they may be very far apart (minutes or even hours apart).

Calling in the script console

ed = Editor()
for frame in range(0, 1000):
    ed.printFrameInfo(frame)
will dump raw info from the demuxer about the first 1000 (replace 0 and 1000 with different integer values if desired) frames to Avidemux log (admlog.txt in %localappdata%\avidemux on Windows). Search the log for occurences of the "Flags 0110" string that identifies an IDR frame and for "Flags 0010" that identifies merely a keyframe to get an impression of the frequency of IDR frames in the stream.