Linux Intel Quicksync QSV

[kristatos]

Ich bin echt begeistert, dass endlich auch das Hardware-Encoding mittles Intel Quicksync unter Linux funktioniert.

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.

[eumagga0x2a]

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.

[eumagga0x2a]

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
2: [videoEncoder/ffVaH264] Use encodeWrapper from the base class
3: [videoEncoder/ffVaHEVC] Use encodeWrapper from the base class.

*) Bitte mit dem Kompilieren warten, das erste Commit hat höchstwahrscheinlich einen großen Speicherleck zur Folge. Dies muss ich erst noch korrigieren.

[eumagga0x2a]

Das Speicherleck ist gefixt, jetzt darf getestet werden.

[hylli]

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

[eumagga0x2a]

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.

Code Select Expand

avidemux3_qt5 > ~/admlog.txt 2>&1

Vielleicht davor noch auf den 2.7.6 Release aktualisieren.

[hylli]

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

[eumagga0x2a]

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.

[hylli]

Der Vollständigkeit halber das gewünschte Admlog.

Hylli

[eumagga0x2a]

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).

[hylli]

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

[eumagga0x2a]

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

Code Select Expand

[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?

[hylli]

Heutige kurze Aufnahme (ca. 150MB):
https://we.tl/t-ABhUC2u9IJ

Habe ebenfalls nochmals konvertiert und ein Log erzeugt, siehe Anhang!

Hylli

[eumagga0x2a]

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 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.

[eumagga0x2a]

Die Hauptbremse ist die Konvertierung von NV12 zu YV12 (zurück geht es sehr flink). Ich habe Avidemux-eigene Implementierung durch libswscale ersetzt, 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.