Hardwarebeschleunigte verlustfreie Aufnahme auf einer 6700 XT mit ffmpeg

Hardwarebeschleunigte verlustfreie Aufnahme auf einer 6700 XT mit ffmpeg

Ich versuche, meinen Bildschirm verlustfrei (oder in nahezu verlustfreier Qualität) mit Hardwarebeschleunigung auf einer 6700 XT mit ffmpeg aufzuzeichnen. Ich verwende Linux Mint mit dem 5.14.14-051414-genericKernel.

Ich habe es versucht:

ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 2560x1440 -i :0 -r 60 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 0 output.mp4

ffmpegsagt, dass es mit 60 fps aufzeichnet, aber die Aufnahme ist abgehackt und leicht verfärbt. Ich gehe davon aus, dass das Farbproblem vom Farbformat nv12 herrührt, aber rgboder es rgb8wird ein Fehler ausgegeben.

Ich habe auch versucht, kmsgrab zu verwenden:

ffmpeg -device /dev/dri/card0 -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi,scale_vaapi=w=2560:h=1440:format=nv12' -c:v h264_vaapi -qp 0 output.mp4

Es tritt jedoch der Fehler auf:

[kmsgrab @ 0x558f001c8d80] Using plane 65 to locate framebuffers.
[kmsgrab @ 0x558f001c8d80] Failed to get framebuffer 127: Invalid argument.
pipe:: Invalid argument

Die Zahl danach Failed to get framebufferist normalerweise 127oder irgendwo zwischen 134bis 136.

Ich habe diese BefehleHier.

Antwort1

Eine wirklich verlustfreie Kodierung ist meiner Meinung nach nur mit Software möglich, aber bei höheren Bitraten sieht es möglicherweise gut genug aus.

Außerdem heißt es im ffmpeg-Wiki, dass VAAPI für AMD-GPUs nur teilweise unterstützt wird.

Ich vermute jedoch, dass Sie derzeit ohnehin die integrierte GPU der CPU verwenden, was zu Leistungsproblemen führen kann:

Wenn Sie über mehrere verwendbare Geräte in derselben Maschine verfügen (beispielsweise eine integrierte Intel-GPU und eine separate AMD-Grafikkarte), können diese gleichzeitig zum Dekodieren verschiedener Streams verwendet werden:

ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device vaapi=amd:/dev/dri/renderD129 -hwaccel vaapi -hwaccel_device intel -i ... -hwaccel vaapi -hwaccel_device amd -i ...

Haben Sie nachgeschaut, ob mehr als ein Hardwaregerät verfügbar ist?

Versuchenls /dev/dri/um zu sehen, welche Geräte verfügbar sind.

Unabhängig davon, ob Sie das richtige Gerät verwendet haben oder nicht,-qp 0Option wird wahrscheinlich nicht wie vorgesehen funktionieren. Versuchen Sie es daher mit den genauen angegebenen Befehlen und prüfen Sie, ob diese zu besseren Ergebnissen führen:

ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 1920x1080 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 24 output.mp4

oder

ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 1920x1080 -i :0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 output.mp4

Ändern Sie einfach die Auflösung und wenn Sie ein anderes Hardwaregerät gefunden haben, können Sie versuchen, dies ebenfalls zu ändern.

Wäre interessant, ob Sie eine gute Qualität mit angemessener Bitrate/Dateigröße erzielen können, also lassen Sie mich bitte wissen, ob es Ihnen gelungen ist.

Übrigens verwendet das Folgende keine Hardwarebeschleunigung, sondern verlustfreie Kodierung, Sie können also auch das hier versuchen:https://trac.ffmpeg.org/wiki/Capture/Desktop#lossless-recording

Um den Kodierungsprozess zu beschleunigen, können Sie verlustfreie Kodierung verwenden und erweiterte Kodierungsoptionen deaktivieren, z. B.:

ffmpeg -video_size 1920x1080 -framerate 30 -f x11grab -i :0.0 -c:v libx264rgb -crf 0 -preset ultrafast -color_range 2 output.mkv

-crf 0 weist x264 an, im verlustfreien Modus zu kodieren; -preset ultrafast empfiehlt, dies schnell zu tun. Beachten Sie die Verwendung von libx264rgb anstelle von libx264; letztere würde eine verlustbehaftete Konvertierung von RGB nach yuv444p durchführen (8 Bit yuv444p reicht nicht aus, um 8 Bit RGB beizubehalten, 10 Bit YCbCr sind erforderlich). ...

Der Encoder sollte auf den meisten modernen Hardwaregeräten schnell genug sein, um ohne Framedrops aufzuzeichnen und sogar noch genügend CPU-Spielraum für andere Anwendungen zu lassen.

Wenn Sie die Aufnahme archivieren möchten oder wegen der Dateigröße besorgt sind, kodieren Sie sie erneut verlustfrei, jedoch mit einer langsameren Voreinstellung. ...

Antwort2

TL,DR: Ich denke, Sie sind hauptsächlich auf Fehler in ffmpeg und/oder anderen Teilen des Stapels gestoßen, die inzwischen behoben zu sein scheinen.

Ihr erster Befehl:

ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 2560x1440 -i :0 -r 60 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 0 output.mp4

Funktioniert bei mir auf Debian Bookworm mit ffmpeg 5.1 (ich habe nur die Größe an meinen Monitor angepasst), ohne Farbprobleme und mit 60 fps, auf derselben GPU (6700 XT). Vielleicht gab es (zu der Zeit) irgendwo in Ihrer Version von ffmpeg oder in den VA-API-Treibern oder so einen Fehler.

Es wird nicht die höchste Qualität verwendet, es -qp 0liegt möglicherweise außerhalb des von diesem Encoder unterstützten Bereichs und wird daher ignoriert. Offenbar wird auf einen Standardwert zurückgegriffen:

No quality level set; using default (20).

Niedrige Werte wie -qp 1scheinen akzeptabel zu sein und bieten möglicherweise für Ihre Anforderungen ausreichende Qualität.


Beachten Sie in Bezug auf kmsgrab, dass für die Verwendung entweder die Ausführung als Root oder die Aktivierung der CAP_SYS_ADMIN-Funktion erforderlich ist. Dies kann durchaus die Ursache für Ihren Fehler sein. Eine Lösung besteht darin, die Funktion in ffmpeg zu aktivieren:

setcap cap_sys_admin=ep /usr/bin/ffmpeg

Dies ist aus Sicherheitsgründen nicht optimal und wird beim Aktualisieren von ffmpeg unterbrochen, aber es funktioniert, und Ihre Befehlszeile läuft bei mir auch einwandfrei.

Beachten Sie auch, dass die Verwendung von kmsgrab während der Audioaufzeichnung bis mindestens ffmpeg 5.1 zu Audio-/Video-Synchronisierungsproblemen führte:

https://trac.ffmpeg.org/ticket/8377

Wenn Sie es verwenden möchten, sollten Sie wahrscheinlich auf ffmpeg 6 aktualisieren, wodurch meiner Erfahrung nach das letzte Problem behoben wurde.

Antwort3

Dies wurde gestern gefragt und die Antwort bleibt dieselbe: HW-Videocodecs unterstützen keine Änderung des Quantisierungsfaktors und crfunterstützen insbesondere keine verlustfreie Kodierung.

Aushttps://trac.ffmpeg.org/wiki/Hardware/VAAPI

Mapping-Optionen von libx264

Derzeit wird kein CRF-ähnlicher Modus unterstützt. Der einzige Modus mit konstanter Qualität ist CQP (Constant Quantisation Parameter), der keine Anpassung an den Szeneninhalt bietet. Er ermöglicht jedoch unterschiedliche Qualitätseinstellungen für unterschiedliche Frame-Typen, um die Komprimierung zu verbessern, indem weniger Bits für nicht referenzierte B-Frames verwendet werden – siehe die Optionen (i|b)_q(factor|offset). Der CQP-Modus kann nicht mit einer maximalen Bitrate oder Puffergröße kombiniert werden.

verwandte Informationen