Avidemux Forum

Quote from: WLF on January 31, 2026, 07:32:00 AMIs there any way to prevent Avidemux from converting a 10-bit BT.2020 video to 8-bit when not using Copy mode?

This would require a lot of work to implement this capability, slightly short of a full rewrite of the entire application (meaning also internal libraries, all video filters and many encoder plugins). Very much wanted, sure.

Thank you for re-posting in English, else I would have to use 100% Google Translate (which is awfully lame) replying to your Spanish post.

First of all, please make sure you use the latest available Avidemux 2.8.2 build (for Windows, there is one from May 26 2025). If the issue persists, please provide a sample video (as short as possible) enough to reproduce the problem via Mega, Dropbox or Google Drive (link sharing only, accessible without Google account).

I can imagine that the application you mentioned creates MP4 files with very high timebase denominator which Avidemux tries to approximate with 90 kHz, ultimately leading to this timing error, but better to identify the real reason than to guess.

Quote from: Gloster on January 30, 2026, 10:03:15 PMIch gehe davon aus, das Avidemus eine Dekodierung via ffmpeg ausführt.

Nein, Avidemux benutzt dafür (wenn sich kein Plugin als zuständig meldet) libavcodec über die entsprechenden APIs. ffmpeg benutzt ebenfalls libavcodec zum Dekodieren von Audio und Video. Die libavcodec Library kann ihrerseits auf weitere Libraries zurückgreifen.

Danke, es sieht für mich auf den ersten Blick, als ob

14:12:56-324 [ADM_AudiocodecAC3::run] [a52] Demuxer and decoder disagree about # of channels: 6 vs 2
(die Anzahl von Kanälen springt von 6 auf 2) von Avidemux nicht abgefangen werden kann, weswegen die Bedingung, dass sich die Kanalkonfiguration nicht mitten im Encoding ändert und wir somit unzugeordnete Kanäle bekommen, nicht erfüllt werden kann:

14:12:56-327 [ADM_AudioEncoder::reorderToPlanar] Output channel LFE not mapped!
Wenn ich mich nicht irre, den umgekehrten Fall (also von 2 auf 6 Kanäle) kann Avidemux bei AC3 und dem liba52-Dekoder im Einsatz noch handhaben. Grundsätzlich dürfen sich bei Avidemux Audiotracks nicht zwischendurch ändern. AC3 ist ein Sonderfall, weil der liba52-Dekoder das Feature besitzt, notfalls intern auf Stereo herunterzumischen.

Hello. I bought Cloner Alliance Pro and I'm having a problem when I try to save the edited files. I get this message:

Too Short.
The saved video is incomplete. The error occurred at 00:00:10,216 (0). This may have happened as a result of invalid timestamps in the video.

Error -22 ("Invalid argument")

Is there a solution?

Is there any way to prevent Avidemux from converting a 10-bit BT.2020 video to 8-bit when not using Copy mode? I need to re-encode to fix non-IDR recovery points but even using NVENC HEVC Main10 the output still looks super washed out and I think it's 8-bit. I know this isn't an issue if you use copy mode and then play it with LAV filters, but I would like it to be able to play correctly on other devices like TVs. Using ffmpeg concat to re-encode with libx265 correctly preserves 10-bit but it also drops some frames at cut points while avidemux does not (also avidemux is just so much easier to use).

Ich gehe davon aus, das Avidemus eine Dekodierung via ffmpeg ausführt.
Via Avidemux kann ich eine Dekodierung unterbrechen und fortsetzen.
Ich suche nach dem zugehörigem ffmpeg line command, wenn verfügbar.

Après quelques tentatives supplémentaires aussi infructueuses que les précédentes, j'ai finalement décidé d'essayer la version Flatpak pour aarch64 disponible sur Flathub.

Bon, je ne suis pas trop partisan des solutions de virtualisation d'application et j'ai donc dû commencer par installer flatpak, mais, force est de constater que pour Avidemux ça fonctionne parfaitement sans trop alourdir le système avec les librairies et dépendances redondantes requises.

https://flathub.org/en/apps/org.avidemux.Avidemux

Après quelques tests sur un Raspberry Pi 5 (je n'ai pas essayé sur un RPI4) et donc une architecture arm64 v8 (NEON) avec RaspiOS Desktop (Debian "Trixie" 13.3), il me semble que tout fonctionne parfaitement. J'ai pu :
- trimmer sans réencoder
- transcoder
- transmuxer
- utiliser les filtres

L'affichage est correct, l'audio est nickel, les fichiers produits conformes aux specs demandées.

En terme de performance, là on voit que ça manque d'optimisation évidemment.
- 30/35% de CPU pour lire un FullHD H264
- 35/40% de CPU pour lire un FullHD H265 (malgré le support matériel natif du décodage HEVC par les RPI5)
Pour comparer, la même chose avec VLC, c'est 4% de CPU ! FFplay : 8/10%...
Donc oui c'est bcp de ressources CPU mais le RPI5 encaisse sans broncher et en terme d'expérience utilisateur / confort d'utilisation, il n'y a pas vraiment de différence avec Avidemux sur un gros i7 sous Windows.
Bien entendu, les encodages, eux, font tout monter dans le rouge très vite, surtout le H265, mais le jour où j'ai vraiment beaucoup d'encodage, je passe sous Windows avec un bon GPU et par conséquent je n'utilise sans doute pas Avidemux du tout !

Malgré tout, ça fonctionne plutôt bien, on peut travailler correctement et je pense, comme je le disais précédemment, qu'Avidemux est un outil indispensable pour l'environnement Raspberry Pi pour qui veut pouvoir éditer rapidement une vidéo sans que cela ne requiert de sortir l'artillerie lourde !

Voila, j'espère que ce retour d'expérience sera utile à qq-uns en attendant de voir un jour sortir une version officielle et optimisée pour les processeurs arm64 et le hardware des Raspberry Pi !

Have fun and take care !

Hallo eumagga, bittschön: You cannot view this attachment.

Markus

Bitte das AppImage auf der Kommandozeile (im Terminal) starten, das Problem reproduzieren, Avidemux, falls das Programm hängt, notfalls mit Strg+C im Terminal beenden und die Meldungen im Terminal nah ans Ende in eine Textdatei kopieren und an die Antwort hier anhängen, danke.