Avidemux Forum

Quote from: Fozzie Bear on Today at 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.

Hello and thank you @MeanAdmin

This does work and didn't crash even the first time.

I can't see av1 (libaom) which was there on avidemuxLinux_GLIBC_2.36_amd64_250530_0709.app
and any of the hardware (h) modes which I can't remember if they were there before.

x264 seem to be much faster now but could be just my idea.

Does that one work for you : https://avidemux.org/nightly/appImage_oldSystems/

Warning : It will crash the firsttime, just restart it
Warning2: it does not support wayland, only X11

Also...what is this site. It states it is not affiliated to avidemux.org, but I discovered the mingw nightlies from links here, and as they are in an official depository, it seems to give them some credibility?

Like guru, I would be interested to know what differs between these and the last Windows nightly.

... are there any functional difference to former nightlies?