Avidemux-Linux-Nvidia - wie es bei mir funktioniert hat

[tomk]

Die Vorgeschichte:
Vor einigen Jahrzehnten hatte ich ganz gute Unix-/Xenix-Kenntnisse auf den frühen IBM PCs, die aber im Lauf der Zeit durch die Beschäftigung mit DOS und den verschiedenen Windows-Versionen mehr oder weniger verschüttet wurden.
Mittlerweile nervt die "Benutzerfreundlichkeit" von Windows so sehr, dass ich ernsthaft eine komplette Umstellung auf Linux erwäge. Eine der betroffenen Baustellen ist Avidemux, das ich seit langem intensiv nutze. In diesem Zusammenhang Danke an alle Beteiligten für die kontinuierliche Weiterentwicklung!

Hier die Vorgehensweise bis zum Erfolg. Die Grundlagen hierfür waren mehrere gegoogelte, zum Teil veraltete Rezepte (z.B in https://wiki.ubuntuusers.de/Avidemux/) und die eigenen Überlegungen und Erfahrungen während der Versuche.

Hardware (für den Test): Laptop mit Intel i7-7700HQ, 16GB RAM, GTX1060 (Laptop Version), 240GB SSD als Systemlaufwerk
Software: frisch installiertes Linux Mint 20.2 (Uma) Cinnamon Edition mit über die Treiberverwaltung installiertem aktuellen Nvidia-Treiber (beim nächsten Hochfahren erscheint zwar eine Fehlermeldung (fehlende Grafik-Hardwarebeschleunigung), die ich bis jetzt lieber ignoriert habe).

1. Versuch - Verwendung des in www.avidemux.org/nightly/appImage4 bereitgestellten aktuellen AppImages (hier avidemuxUniversal_amd64_210823_130.app)
Ergebnis: Avidemux funktioniert wunderbar, erkennt aber nicht den Grafikprozessor, daher werden keine Codecs angeboten, die die Rechenleistung des Grafikprozessors verwenden.

2. Versuch - Installation von Avidemux über den in Linux integrierten Paketmanager
Ergebnis: nicht erfolgreich (Grund schon wieder vergessen, vermutlich keine Nutzung des Gafikprozessors)

3. Versuch (nach langer Bedenkzeit, ob ich mich so weit hineinsteigern soll) - Avidemux selbst kompilieren
   [alle Eingaben im Terminalfenster, am Anfang im Verzeichnis $HOME]

3.1 eventuell installierte Version von Avidemux deinstallieren
    sudo apt-get purge "avidemux"
   
3.2 falls noch nicht geschehen Git (Versionsverwaltung) installieren   
    sudo apt-get update
    sudo apt-get install git

3.3 Quelltext aus Git herunterladen
    git clone https://github.com/mean00/avidemux2.git
    cd avidemux2  [in diesem Verzeichnis spielt sich ab jetzt alles ab]
    git submodule update --init --recursive
   
3.4 Abhängigkeiten im Quelltext-Ordner avidemux2 installieren
    bash createDebFromSourceUbuntu.bash --deps-only
   
3.5 Installtion von nv-codec-headers
    git clone https://github.com/FFmpeg/nv-codec-headers
    cd nv-codec-headers
    git checkout sdk/8.1
    make
    sudo make install
   
3.6 Kompilieren
    cd .,  [zurück ins Verzeichnis avidemux2]
    bash bootStrap.bash   [falls während der Kompilierung Fragen kommen, immer positiv antworten "J" - die Kompilierung dauerte insgesamt (gefühlte, nicht gestoppte) 10-15min]
   
3.7 Kopie der Skripts für die Ausführung von Avidemux und Avidemux_jobs erstellen
    Start eines Editors [bei mir Geany - musste vorher über die Anwendungsverwaltung installiert werden]
    Einlesen der Datei  run_avidemux_template.sh
    unverändert als (z.B.)  avidemux.sh ins gleiche Verzeichnis avidemux2 speichern
    Einlesen der Datei  run_jobs_avidemux_template.sh
    unverändert als (z.B.)  avidemux_jobs.sh  ins gleiche Verzeichnis avidemux2 speichern
   
3.8 Fertig - Avidemux starten
    im Verzeichnis avidemux2 die Skript-Datei  avidemux.sh  ausführen [Avidemux bietet jetzt die Codecs, die den Grafikprozessor verwenden, an]
    wenn mehrere Jobs für die Warteschlange (Queue) definiert wurden, nach Beenden von Avidemux durch Ausführen des Skripts  avidemux_jobs  die Warteschlange abarbeiten lassen
   
Was noch zu tun wäre (daher ungetestet):
Komfortablerer Start: die beiden Start-Skripte in ein Verzeichnis in $PATH übertragen
Vorgehensweise bei neuen Versionen
Falls sich aus diesem Beitrag ein Thread mit Korrekturen und zusätzlichen/neuen Informationen entwickeln sollte, habe ich jetzt den guten Vorsatz meinen Beitrag entsprechend anzupassen.

Viel Vergnügen (und Erfolg!)  für alle, die dieses Rezept nachkochen wollen...

[eumagga0x2a]

1. Versuch - Verwendung des in www.avidemux.org/nightly/appImage4 bereitgestellten aktuellen AppImages (hier avidemuxUniversal_amd64_210823_130.app)
Ergebnis: Avidemux funktioniert wunderbar, erkennt aber nicht den Grafikprozessor, daher werden keine Codecs angeboten, die die Rechenleistung des Grafikprozessors verwenden.

Dieses appImage ist für wirklich alte Linux-Distributionen bestimmt. Alle aktuellen, die auf der glibc in der Version 2.28 oder neuer aufgebaut sind, sollten zu appImages aus dem Ordner mit dem Zusatz "Buster" greifen, sie haben auch eine bessere Unterstützung für Hardwarebeschleunigung.

git checkout sdk/8.1

Das ist nur dann notwendig, wenn man auf eine alte Version des NVIDIA-Treibers angewiesen ist. Installiert man die aktuelle, sollte man bei git master bleiben.

bash bootStrap.bash  [falls während der Kompilierung Fragen kommen, immer positiv antworten "J"

Die Kompilierung erfordert und erlaubt von diesem Punkt an kein Input vom User mehr (außer Strg+C zum Abbrechen). Entweder sie ist erfolgreich oder eben nicht. Was für Fragen sind denn gekommen?

Mit dem VDPAU-basierten Dekoder auf NVIDIA-Hardware gibt es aktuell ein gravierendes Problem bei H.264 Open-GOP-Streams typisch für ÖR-Sender ausgestrahlt über DVB-S und -C: die ersten auf das Keyframe folgenden Bilder (Keyframe kann, muss aber nicht das erste Keyframe im Video sein) nach dem Starten der Wiedergabe werden nicht vollständig dekodiert.

Das ist zumindest seit vorletzter Treiberversion (470.57.xx) so, aber ein Zusammenhang mit der Treiberversion ist unsicher. Welcher NVIDIA-Treiber wurde beim obigen Rezept verwendet? Wenn ein bedeutend älterer: besteht das Problem auch damit?

[tomk]

1. Versuch - Verwendung des in www.avidemux.org/nightly/appImage4 bereitgestellten aktuellen AppImages (hier avidemuxUniversal_amd64_210823_130.app)
Ergebnis: Avidemux funktioniert wunderbar, erkennt aber nicht den Grafikprozessor, daher werden keine Codecs angeboten, die die Rechenleistung des Grafikprozessors verwenden.

Dieses appImage ist für wirklich alte Linux-Distributionen bestimmt. Alle aktuellen, die auf der glibc in der Version 2.28 oder neuer aufgebaut sind, sollten zu appImages aus dem Ordner mit dem Zusatz "Buster" greifen, sie haben auch eine bessere Unterstützung für Hardwarebeschleunigung.

Werde ich dann ausprobieren, wenn ich das endgültige "Produktionssystem" aufsetze. Heißt "bessere Unterstützung", dass dieses Avidemux-AppImage die Codecs für den Grafikprozessor anbietet?

git checkout sdk/8.1

Das ist nur dann notwendig, wenn man auf eine alte Version des NVIDIA-Treibers angewiesen ist. Installiert man die aktuelle, sollte man bei git master bleiben.

Wie sieht für die aktuelle Treiberversion dann Punkt 3.5 des Rezepts aus?

bash bootStrap.bash  [falls während der Kompilierung Fragen kommen, immer positiv antworten "J"

Die Kompilierung erfordert und erlaubt von diesem Punkt an kein Input vom User mehr (außer Strg+C zum Abbrechen). Entweder sie ist erfolgreich oder eben nicht. Was für Fragen sind denn gekommen?

Mit dem VDPAU-basierten Dekoder auf NVIDIA-Hardware gibt es aktuell ein gravierendes Problem bei H.264 Open-GOP-Streams typisch für ÖR-Sender ausgestrahlt über DVB-S und -C: die ersten auf das Keyframe folgenden Bilder (Keyframe kann, muss aber nicht das erste Keyframe im Video sein) nach dem Starten der Wiedergabe werden nicht vollständig dekodiert.

Das ist zumindest seit vorletzter Treiberversion (470.57.xx) so, aber ein Zusammenhang mit der Treiberversion ist unsicher. Welcher NVIDIA-Treiber wurde beim obigen Rezept verwendet? Wenn ein bedeutend älterer: besteht das Problem auch damit?

Kann gut sein, dass die Fragen irgendwann vor der Kompilierung kamen. Werde bei der nächsten Installation besser aufpassen (und mehr protokollieren).

Das angesprochene Keyframe-Problem ist mir bisher (auch unter Windows) nicht aufgefallen. Werde aufpassen.

Über die Treiberverwaltung wurde übrigens nvidia-driver-470 Ver 470.52.02 ubuntu0.20.041 installiert.

Tschuldigung, kenne mich dem Quoten beim Reply (noch) nicht aus - daher etwas Durcheinander.

[eumagga0x2a]

Das angesprochene Keyframe-Problem ist mir bisher (auch unter Windows) nicht aufgefallen.

Das Problem tritt nur bei VDPAU mit NVIDIA GPU auf. VA-API (libva) mit Intel ist nicht betroffen. Ich kann mir gut vorstellen, dass DXVA2 mit NVIDIA ebenfalls nicht betroffen ist, kann aber nicht selber testen.

Über die Treiberverwaltung wurde übrigens nvidia-driver-470 Ver 470.52.02 ubuntu0.20.041 installiert.

Danke, ich sollte bald unter Debian Buster testen können (418.xx.xx), das wird das Bild ergänzen.

[eumagga0x2a]

Das VDPAU-Problem, das sich durch unvollständig dekodierte Frames äußert, ist leider eine Regression vom Upgrade des internen FFmpeg vom 4.2.4 auf 4.4 und hat mit der Version des Grafiktreibers nichts zu tun.