Ich bin echt begeistert, dass endlich auch das Hardware-Encoding mittles Intel Quicksync unter Linux funktioniert. ;D
Ich hatte anfangs das Problem, dass unkodiertes DV-Material (576p) funktionierte (>500 fps Encoding-Geschwindigkeit auf meinem Dualcore i3 7300),
aber sobald das Quellvideo kodiert in h264 (720p, 1080p) oder dergleichen vorlag ging es nicht.
Abhilfe:
In den Einstellungen die standardmäßige (?) Aktivierung der Hardware-Beschleunigung "Video mittels LibVA dekodieren (Intel)" muss deaktiviert werden,
gleichzeitig Hardware En- und Dekodieren funktioniert wohl nicht. Ist aber nicht schlimm.
Ich finde in der nächsten Version von Avidemux sollte das automatisch bei QSV deaktiviert werden. Weiter gibt es noch einen Bug, nachdem die Einstellung mit
dem LibVA dekodieren ein- oder ausgeschaltet wird, stürzt Avidemux ab sobald das Video gespeichert bzw. das Rendern gestartet wird. Nach einem Neustart
geht es wieder.
Ich habe die Version 2.7.4 unter Ubuntu 19.10 im Einsatz.
Danke für den Bericht, mit dem aktuellen Avidemux vom Git master und auf meiner Test-Hardware (i3-6100U) klappt das gleichzeitige De- und Encodieren mittels libva einwandfrei, wenn der "Intel AVC HW (VA)" Encoder benutzt wird. Die libavcodec-basierten "Intel H264" und "Intel HEVC" Encoder sind komplett kaputt, da sie für FFmpeg 4.2.2 noch auf die neue API migriert werden müssen.
Avidemux nutzt jetzt die neue avcodec_send_frame / avcodec_receive_packet API (Commits 1, 2 und 3), "Intel H264" und "Intel HEVC" Encoder funktionieren dadurch wieder, auf meiner Hardware auch gleichzeitig zum Dekodieren in Hardware. Bitte Avidemux von git master kompilieren und melden, ob das Problem damit trotzdem besteht. *
Was den Absturz nach dem Deaktivieren der HW-beschleunigten Dekodierung betrifft, muss das Video anschließend zwingend geschlossen und neu geladen werden, da wir den Dekoder nicht on-the-fly austauschen können.
1: [coreVideoEncoderFFmpeg] Switch to the new API (https://github.com/mean00/avidemux2/commit/62bdd8ff2ee4607e6b019ed33ef0174fe1e47050)
2: [videoEncoder/ffVaH264] Use encodeWrapper from the base class (https://github.com/mean00/avidemux2/commit/3d8c55c6b90bfdcd1311069b322a6b07ab3951a1)
3: [videoEncoder/ffVaHEVC] Use encodeWrapper from the base class (https://github.com/mean00/avidemux2/commit/2e18a906b8e670d507f0e1dadece9588bc53357e).
*) Bitte mit dem Kompilieren warten, das erste Commit hat höchstwahrscheinlich einen großen Speicherleck zur Folge. Dies muss ich erst noch korrigieren.
Das Speicherleck ist gefixt (https://github.com/mean00/avidemux2/commit/5843ad3ba8700faae2dace5c3fe345e5c3d3d450), jetzt darf getestet werden.
Hi,
ich habe das gleiche Problem wie @kristatos. Ich habe eine Core i7-6700 CPU, mit der ich gerne HW-Beschleunigung nutzen würde.
Bei mir läuft eine Avidemux Version 2.7.5 vom 15.06.2020 unter Linux Mint 19.3, kompiliert aus dem Master Git, allerdings ohne den nVidia/nVenc betreffenden Teil.
Nutze ich ffmpeg im Terminal, funktioniert die HW-Beschleunigung sowohl beim Decoding wie auch beim Encoding.
Wenn ich in den Einstellungen von Avidemux HW-Beschleunigung via LibVA aktiviere, funktioniert wenn dann nur das Decoding. Das Encoding/Rendern eines Films von z.B. 83 Minuten, dauerte damit noch rund 60 Minuten bzw. evtl. die ein oder andere Minute mehr.
Nachdem ich HW-Beschleunigung via LibVA in den Einstellungen deaktiviert habe, dauerte der Vorgang bei diesem Film nur noch 22-23 Minuten.
Das ließ mich vermuten, dass bei mir das gleiche Problem besteht.
Lösung?
Hylli
Ich kann im Augenblick nicht selber testen. Bitte ein kurzes H.264 Video mit aktivierter Dekodierung durch LibVA mit einem der beiden libavcodec-basierten LibVA-beschleunigten Encoder neu kodieren, Avidemux beenden und admlog.txt aus dem Home-Verzeichnis komprimieren und anhängen.
avidemux3_qt5 > ~/admlog.txt 2>&1
Vielleicht davor noch auf den 2.7.6 Release aktualisieren.
Habe gestern Abend/Nacht noch auf 2.7.6 aktualisiert. Hat sich leider nichts geändert.
Werde heute Abend mal ein kurzes Video entsprechend neu Kodieren und das Log dann anhängen.
Hylli
Ich habe inzwischen selbst getestet und kann den Performance-Einbruch mit VA-API bei gleichzeitiger Nutzung der Hardware-Beschleunigung beim De- und Encodierung bestätigen (das hat nichts mit dem Problem von @kristatos zu tun, aber auch nicht schön).
Wir können noch nicht das Herunterladen des dekodierten Bildes in den Arbeitsspeicher und das erneute Hochladen in den Grafikspeicher vermeiden, mit einhergehender doppelter Konvertierung zwischen NV12 und YV12 Farbräumen. Das erklärt dennoch nicht, warum Software-Dekodierung so einen gewaltigen Vorteil bietet (Intel HEVC mit Software-Dekoder: 168 fps, mit libva: 60 fps, vergleichbar mit x265 mit dem "veryfast" Preset).
Werde das mir demnächst näher ansehen, danke für die Meldung.
Der Vollständigkeit halber das gewünschte Admlog.
Hylli
Danke, ja, dem Log nach komme ich so auf etwa 33 fps für den ADM_ffVAEncH264Encoder. Das ist ausgesprochen wenig. Werde in der nächsten Zeit schauen, was man da machen kann.
Übrigens, beim Neu-Encodieren in echt müsste zwingend ein Deinterlacer (es gibt jetzt einen für VA-API) zwischengeschaltet werden, weil das ursprüngliche Video im Zeilensprungverfahren kodiert ist. Dem x264 Encoder kann man sagen, dass das Video interlaced ist, dem VA-API Encoder Plugin in Avidemux nicht (oder zumindest noch nicht).
Mitt ffmpeg im Terminal, kam ich teilweise auf durchschnittlich 242 fps, wenn ich keine zusätzlichen Filter wie Delogo verwandet habe.
Ich hoffe, dass Du/Ihr den Fehler bzw. das Problem bald beseitigt bekommt.
Freue mich auf jeden Fall schon auf eine neue und dann funktionierende Version von Avidemux.
Hylli
Für die Art von Quellmaterial wie im Log abgebildet (1080i) ist die Neu-Encodierung mit einem der VA-API Encoder ohne Filter irrelevant, weil zwingend ein Deinterlacer her muss.
Der einzige Anwendungsfall, wo vermutlich eine erhebliche Geschwindigkeitssteigerung drin wäre, ist direkte Neu-Encodierung ohne Filter, sonst ist der Umweg über Arbeitsspeicher unvermeidlich.
Was anderes. Im Log ist mir
Quote [collectStats] 15:30:15-779 Stats for 0 tracks out of 2 populated, bytes used: 16777216
in der Zeile 627 aufgefallen, d.h. wir suchen vergeblich nach Zeitstempeln und Offsets für Audiopakete. Wäre es bitte möglich, ein 100 bis max. 200 MiB Stück vom MPEG-TS als Sample via WeTransfer (keine E-Mail-Adresse und keine Registierung vonnöten!), Mega, Dropbox, Google Drive oder einen vergleichbaren Service zu bekommen?
Heutige kurze Aufnahme (ca. 150MB):
https://we.tl/t-ABhUC2u9IJ
Habe ebenfalls nochmals konvertiert und ein Log erzeugt, siehe Anhang!
Hylli
Super, vielen Dank für den Sample. Das mit nicht gefundenen Zeitstempeln und Offsets für Audiopakete war eine Falschmeldung, ohne Auswirkung auf den letztendlich erstellten Index für die .ts Datei, aber nachteilig für die Performance (statt nach ungefähr 222 kiB aufzuhören, las Avidemux die als maximum festgelegten 16 MiB ein).
Der Bug soll durch den Commit [demuxers/MpegTS] Remember how many audio tracks have got their packet stats populated (https://github.com/mean00/avidemux2/commit/8cca121b4c9b1782bfd1052c5a82b09d7fdac76d) behoben worden sein. Leider zu spät für diesen Release, aber so ist es halt mit der Software.
Das Video ist zwar als interlaced encodiert, aber beide Halbbilder entsprechen dem gleichen Zeitpunkt (fake interlaced). In diesem Fall braucht man keinen Deinterlacing-Filter.
Das Log habe ich mir noch nicht angeschaut.
Bislang zeigt alles auf den VA-API beschleunigten Dekoder als die fps-Bremse. Trotz extra Farbraum-Konvertierung im Encoder, erreicht der Encoder mit Leichtigket sehr hohe fps > 250 sofern nur der Software-Dekoder benutzt wird. Der Hardware-Encoder funktioniert gleich gut, egal welcher Dekoder ihn mit dem Bildmaterial versorgt, aber der Hardware-Dekoder hat es irgendwie nicht eilig.
Die Hauptbremse ist die Konvertierung von NV12 zu YV12 (zurück geht es sehr flink). Ich habe Avidemux-eigene Implementierung durch libswscale ersetzt (https://github.com/mean00/avidemux2/commit/2ce12812bbeaba40b94cd81ccdc52a23f90ab6de), was auf meiner Hardware die Geschwindigkeit beim Dekodieren durch VA-API bei 720p H.264 um run 50% steigert. Ein weiter Weg von 250 fps, die der Encoder sonst schafft, aber immerhin eine Verbesserung.
Hi,
Danke schon mal bis hier hin. Habe es gestern mal getestet, und hatte jetzt bei einem Film von 84 Minuten eine Zeit von ca. 50 Minuten zum Rendern.
Bin auf die weitere Entwicklung gespannt.
Hylli
Interessant wäre ein Vergleich zwischen dem 2.7.6 Release (interne NV12-->YV12 Umwandlung) und der jetzigen (Zwischen-) Lösung. Bei mir bringt sie so um die 50% höhere fps.
Für die Praxis, empfehle ich zum Neukodieren den LibVA-Dekoder (nur den Dekoder!) lieber zu deaktivieren, es sei denn man hat es mit einer 4K-Auflösung zu tun. Die Nachteile durch die Umrechnung von NV12 zu YV12 sind leider sehr groß. Grundsätzlich ist es möglich, die Bilddaten von LibVA gleich als YV12 zu bekommen, leder sind damit aber andere, viel schwerwiegendere Probleme verbunden. Ausgang offen.
Die VA-API-basierten Encoder sind vom Dekoder unabhängig.
Wenn nur Copy Mode benutzt wird, bietet LibVA Dekoder + Display sehr große Vorteile, aber sobald man umkodiert, schlägt der Fluch der notwendigen Umwandlung NV12 --> YV12 zu.
Ich habe parallel auch Avidemux aus diesem PPA installiert:
https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/avidemux
Ich gehe mal davon aus, dass dies dem aktuellen 2.7.6 Release entspricht?!?
Habe jetzt mal den gleichen Film (TV-Aufnahme, 1080i, Länge 84 Min. 7 Sek.) mit beiden Versionen gerendert.
Version GIT:
Mit LibVA Decodierung: ca. 50 Min.
Ohne LibVA Decodierung: ca. 20 Minuten
Version PPA
Mit LibVA Decodierung: ca. 70 Min.
Ohne LibVA Decodierung: ca. 20 Minuten
Hylli
Danke, deckt sich ungefähr mit meinen Beobachtungen.
Gleichen Film nun nochmals mit FFMPEG im Terminal gerendert:
Quoteffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device /dev/dri/renderD128 -ss 00:03:23.955 -i "/media/user/OMV-Aufnahmen/Aufnahme.ts" -t 01:24:07.680 -c:v h264_vaapi -crf 18 -c:a copy "/media/user/OMV-Video/Aufnahme_ffmpeg.mkv"
Ergebnis:
14:30 (MM:SS), Speed 5.83x, ca. 146fps
---
Da bin ich allerdings noch weit entfernt von den von Dir mitgeteilten 250fps, die der Encoder sonst schaffen kann/könnte?
Hylli
Über 250 fps waren es mit 720p. Kann gut sein, dass bei 1080i die Geschwindigkeit entsprechend absinkt.
FFmpeg ist mit VA-API manchmal so schnell, weil dort der Dekoder im günstigsten Fall die Hardware-Surfaces mit Bilddaten an den Encoder weiterreichen kann – keine langsamen Kopiervorgänge zwischen der Grafikeinheit und dem Arbeitsspeicher oder gar CPU-intensive Konvertierungen in einen anderen Farbraum.
In Avidemux fehlt soweit für die beiden VA-API Encoder auf der Basis von FFmpeg und für den ebenfalls darauf aufbauenden VA-API Dekoder die Möglichkeit einer gemeinsamen Verwaltung von Hardware-Surfaces. Es sind wie zwei Haushalte in einem Hochhaus auf gleicher Etage, Wand an Wand, aber mit unterschiedlichen Hauseingängen.
OK, bei 720p habe ich immerhin auch 242fps erreicht.
Hylli