Avidemux Forum

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).

just wanted to say thanks for all the info, just gone from intel mac to a new m6 mac mini running os 27.2, followed the instructions and now have arm version of the software.

I believe the reverse() filter exists in AviSynth.
VirtualDub can open an AviSynth script.

Latest version below:

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

Add Logo (including Partial) is currently available. I don't remember Reverse, but if it was available, it is no longer available.

I'm using Avidemux 2.8—I think it's the latest version, although I haven't found the right section.
My complaint is that, for many years now, numerous filters have disappeared. I'm referring in particular to "reverse" and "add logo" for only a portion of a video, but I think there are many others.
It's time to bring these filters back. Sure, you can do everything with FFmpeg, but a graphical interface is easier than the complicated syntax.

I wanted to add some additional findings to this issue after quite a bit of testing.

I've been able to reproduce the same problem consistently on Debian 13. Pressing the Up Arrow during active video playback causes an odd stutter/jump, and playback doesn't advance properly. Seeking with the Up Arrow while playback is paused works normally.

Here's what I've tested on the same machine with the same video files:

- Official Avidemux 2.8.1 Linux AppImage — works perfectly.
- Official October 9, 2026 nightly AppImage — problem reproduced.
- Custom-compiled newer Avidemux using Qt6 — problem reproduced.
- Custom-compiled newer Avidemux using Qt5 — problem reproduced.
- Independently compiled newer Avidemux build — same problem.
- Newly compiled Avidemux 2.8.1 using the original 2.8.1 release source, Qt5, and FFmpeg 4.4.2 — works perfectly!

The newly compiled 2.8.1 includes some unrelated subtitle-preservation modifications, but the original playback and navigation code was left completely unchanged.

I also tested different video renderers, Dummy audio, and single Up Arrow taps to rule out keyboard auto-repeat. None resolved the problem in the newer builds.

Interestingly, the debug logs from the newer builds sometimes show a forward seek selecting the correct next keyframe, followed by playback resuming at an earlier position.

Based on these results, I strongly suspect a regression somewhere between the original 2.8.1 release and the newer 2.8.2 development code, or a change in one of its underlying dependencies.

I realize that doesn't identify the exact commit responsible, but hopefully it helps narrow down the investigation. At least I now have a working 2.8.1 build that restores the original seeking behavior.

Is there a particular playback/navigation change introduced after 2.8.1 that might explain this?