Avidemux Forum

Quote from: eumagga0x2a on April 10, 2026, 08:15:31 PMNew build infrastructure is being tested. Definitely some codecs (e.g. FDK_AAC) are still missing, will be present / will be re-added in the future.

Official nightly builds are distributed only via https://avidemux.org/nightly, anything else, especially trying to catch visitors typing in a wrong TLD, is untrusted or fraudulent.

Hello,
New to this forum, but a long-time and loyal Avidemux user.

So it's normal not to find the MP4v2 multiplexer in these test versions?
Thks.

I've changed the default behavior to use the last read directory instead.

No, this is not possible with the current interface, unfortunately. More than that, when opening a file dialog from tinyPy to select a directory, Avidemux doesn't pass the last selected directory to the dialog. This is inconsistent with the behavior of the file dialog to select a file when invoked via scripting, thus most likely a bug.

QFileDialog defaults to the present working directory when an empty QString is passed to the file dialog, this must be the directory where the executable is located on Windows, the directory from where the Avidemux binary is called on Linux.

Whenever I start one of my scripts (tinypy) with an open dialog e.g.:
inputFolder=gui.dirSelect("Select Source Folder")

The seletion box starts with the following folder:
C:\Program Files\Avidemux 2.8 VC++ 64bits

After this I have to select my source.

Is there any possible solution to set an other path for the program/script to start?
In the doumentation of tinypy I couldn't find a solution.

Attached you'll find such a script.

Quote from: Fozzie Bear on April 13, 2026, 03:41:00 PMHave you managed to view the file segment I shared?

Just got the sample, thank you for reminding me. Indeed, timing in the file is a mess, with roughly a half of frames having duration of 1 in 90 kHz units while the remainder is oscillating between approx. 20 ms and approx. 60 ms:

[MP4Header::indexify] Histogram map has 7 elements.
Frame duration 1 count: 10236
Frame duration 1798 count: 3412
Frame duration 1799 count: 3269
Frame duration 1800 count: 3555
Frame duration 3599 count: 142
Frame duration 3600 count: 3269
Frame duration 5400 count: 3412

We should have got just all frame duration being equal 1800, maybe with a few gaps (duration 3600 and 5400).

Apparently, each 5th picture produces by the decoder ends up with presentation timestamp going backward by exactly 1 unit (1/90000 of a second – approx. 11 microseconds), so it gets dropped and the warning about wrong frame order is shown. Accepting the dialog makes the mess complete, need to investigate why this happens.

The best strategy to deal with such files for now is to reject the dialog and to re-encode the video with the "Resample" filter with PAL50 as target fps in the filter chain.

Have you managed to view the file segment I shared?
Thankd

New build infrastructure is being tested. Definitely some codecs (e.g. FDK_AAC) are still missing, will be present / will be re-added in the future.

Official nightly builds are distributed only via https://avidemux.org/nightly, anything else, especially trying to catch visitors typing in a wrong TLD, is untrusted or fraudulent.

Quote from: upwithav1 on April 06, 2026, 07:27:21 PMAnd thanks for the new release @eumagga0x2a.

Just to clarify the misunderstanding: there hasn't been any new release. Mean, the author of Avidemux, has thankfully stepped in to implement the move to the new AppImage format which doesn't need the obsolete libfuse2 to be present on target and to make the build infrastructure a part of the codebase using docker containers. The generated binary is a result of testing the new implementation.

QuoteIs this going to support hardware av1 encoding? Just asking..

No.

Quote from: Mr. Whatshisname on April 04, 2026, 12:05:34 PMWhat do I need to do to add codecs (AV1, AV2, H266) as output options when building Avidemux from source on MacOS?

Regarding AV2, as long as it is not supported in an official libaom (or libavcodec) release – and even codec specs seem to be not fully finalized – there won't be support downstream in Avidemux.

VVC / H.266 encoding support should be feasible via vvenc library, not yet started. Upgrading bundled FFmpeg to 7.1 or later to add VVC decoding support should be the first step.

Quote from: Mr. Whatshisname on April 04, 2026, 12:36:37 PMDa heißen die Keyframes offenbar I-Frames.

Korrekt, die Benutzeroberfläche von Avidemux nennt Keyframes leider I-Frames (und I-Frames, die keine Keyframes sind, werden zu P-Frames degradiert), ohne zwischen IDR- und Nicht-IDR-Keyframes zu unterscheiden.

Quote from: Mr. Whatshisname on April 04, 2026, 12:36:37 PMGrundsätzlich würde ich intuitiv als letztes Frame des zu entfernenden Abschnitts das Frame wählen, daß ein Frame vor dem I-Frame ist, wo das Video weiter gehen soll.

Laut mathematischer Konvention gehört das Ende einer Auswahl nicht zur Auswahl. Ich hatte vor vielen Jahren das Verhalten von Avidemux in diesem Punkt vorübergehend geändert, weil es mir aus Ahnungslosigkeit auch intuitiver bzw. praktischer schien, beim Navigieren gleich das letzte zu entfernende Bild zu sehen, statt das erste zu behaltende. Diese Änderung ist allerdings längst zurückgenommen worden.

Dem ist hinzuzufügen, dass das Löschen von Abschnitten innerhalb von H.264 Streams nur am IDR-Frames (IDR = instantaneous decoder refresh) sauber möglich ist. Da aber IDR in den meisten über DVB-T/C/S gesendeten Streams rar gesät sind ("Open GOP"), wäre der Kopiermodus zum Schneiden von solchen Streams völlig nutzlos. Aus Gründen der Praktikabilität akzeptiert Avidemux, dass Streams streng genommen invalid werden, solange FFmpeg-basierte Player mit den erzeugten Inkonsistenzen halbwegs zurechtkommen (und wenn erwartbar nicht, gibt es die Warnung über den zurückgehenden POC-Zähler).

Im Kopiermodus ist das Ergebnis stets the best effort. Die tatsächliche Struktur des Streams bestimmt, wie nah man an die gewünschten Schnittpunkte kommt. Das ist kein Bug sondern eine fundamentale Einschränkung.