Du bist nicht angemeldet.
ffmpeg hat inzwischen zwar OpenCL/Cuda-Support, allerdings liefert das nicht so gute Ergebnisse wie mittels CPU und bietet auch weniger Feature.
Belesen kannst du dich ja mal hier zu dem Thema: https://trac.ffmpeg.org/wiki/HWAccelIntro
Das Video habe direkt von TED-Talks geladen (die bieten ja einen Video-Download an).
Fande Deinen Hinweis auch sehr spannend, da mir dadurch erst der h275_cuvid Codec ins Bewusstsein kam. Allerdings muss ich gestehen, mich erst seit einer Woche mit dem Thema ffmpeg, Codecs etc. zu beschäftigen.
Hintergrund ist, dass ich mit der Bearbeitung von Videos mittels Kdenlive beginnen wollte. Da dachte ich mir eine "richtige" Graka kann nicht schaden, und so habe ich mir eine gebrauchte GeForce GTX 1050 Ti gegönnt. Allerdings - mangels ausreichendem Wissen meinerseits - bringt mir die anscheinend bei Kdenlive nicht so richtig viel.
- Beim direkten Abspielen im Kdenlive Projektmonitor würde es angeblich nur was bringen wenn "OpenGL mit der Movit-Bibliothek" aktiviert ist. Aktivieren kann ich es zwar, aber dann stürzt Kdenlive ab .... Antwort aus dem Kdenlive-Forum: "ist halt noch in der Entwicklung, lass es halt abgeschalten."
- Beim rendern aus Kdenlive in eine separate Datei scheint mir ebenfalls die Graka nicht gut genutzt. Jedenfalls zuckt die GPU-Auslastung keinen Millimeter, während die CPU in Volllast geht. Hier hat mich das Kdenlive-Forum an das Nvidia-GeForce-Forum verwiesen, und von dort wurde ich an das Nivida-Development-Forum weiter verwiesen ... und dort ist der Reply bei 0.
Bei all dem habe ich nun gelernt, dass Kdenlive ffmpeg verwendet, und nun hoffe ich doch noch irgendwie die volle ffmpeg- und Graka Power nutzbar machen zu können.
Bei all dem aber: Arch Linux, Kdenlive, ffmpeg sind alles Programme, die ich kostenlos nutzen kann - wenn ich mal bedenke, was da an Gehirnschmalz und arbeit drin steckt, finde ich es schon irre toll!!!
Ich habe das auch noch mal mit dem RobertWaldinger Video getestet, denke das es von youtube ist. Die Fehlermeldung bekomme ich jetzt nicht.
Wo ich dir recht gebe einen Geschwindigkeitsvorteil gibt es nicht "mehr" ich gucke allerdings nach den Frameraten
mit h264_cuvid fps=1094 ohne fps=1288 ist also langsamer, die CPU Auslastung ist aber runter.
Vor etwa einem Jahr ging das noch nicht, da hatte man nur die halbe Framerate wenn man ohne h264_cuvid Decoder gearbeitet hat.
In Avidemux ist das immer noch so.
Hallo,
so wie Du das machst, hast du nur die halbe hardware Unterstützung. Du must den Eingang auch noch setzen.ffmpeg -c:v h264_cuvid -i in.ts -c:v h264_nvenc -preset slow -b:v 12000k -c:a copy out.mkv
[,,,]
Okay, habe mal folgendes probiert:
$ time ffmpeg -c:v h264_cuvid -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264_nvenc -b:v 1000k test_h264_nvenc_1000kb.mp4
real 0m38,076s
user 0m14,003s
sys 0m16,562s
$ time ffmpeg -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264_nvenc -b:v 1000k test_h264_nvenc_1000kb.mp4
real 0m44,872s
user 1m6,570s
sys 0m2,562s
naja, so richtig viel an Geschwindigkeit hat es jetzt zumindest in diesem Fall nicht gebracht.
Was mir noch auffiel: bei der Variante mit -c:v h264_cuvid kamen noch zusätzlich folgende Meldungen:
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x561309fe0180] stream 0, timescale not set
[AVBSFContext @ 0x56130a088b40] Invalid NAL unit 0, skipping.
Last message repeated 2 times
[h264 @ 0x56130a00e880] Invalid NAL unit 0, skipping.
Last message repeated 2 times
[h264 @ 0x56130a00e880] no frame!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x561309fe0180] decoding for stream 2 failed
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x561309fe0180] Could not find codec parameters for stream 2 (Video: h264, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Hallo,
so wie Du das machst, hast du nur die halbe hardware Unterstützung. Du must den Eingang auch noch setzen.
ffmpeg -c:v h264_cuvid -i in.ts -c:v h264_nvenc -preset slow -b:v 12000k -c:a copy out.mkv
die bitrate kannst du natürlich anpassen wie du möchtest. Hier habe ich schon mal etwas dazu geschrieben.
https://www.linuxmintusers.de/index.php … #msg643217
Mit Avidemux läuft das auch, steht auf Seite 3 und 4
Allerdings musst du dazu Avidemux neu kompilieren. Dazu brauchst das Paket "ffnvcodec-headers"
und du musst diese Zeile in der PKGBUILD unter prepare hinzufügen.
sed -e 's|PATHS /usr/include /usr/include/nvenc /usr/include/x86_64-linux-gnu)|PATHS /usr/include /usr/include/nvenc /usr/include/x86_64-linux-gnu /usr/include/ffnvcodec)|' -i cmake/admCheckNvEnc.cmake
Was möchtest du nachprüfen? Wenn deine Karte die entsprechenden Funktionen nicht unterstützte, würd’s mit einer entsprechenden Fehlermeldung abbrechen. Im Umkehrschluss kann man davon ausgehen, dass die GPU genutzt wird.
Das war mir so nicht klar. Ich dachte halt, der h264_nvenc Codec braucht nicht zwingend eine nvidia Graka, sondern könnte auch genauso gut die Kodierung über die CPU alleine abfrühstücken.
Was CPU-Last angeht: die GPU benötigt gut aufbereitete Daten, um sie parallelisiert verarbeiten zu können. Ebenso müssen die verarbeiteten Daten entgegengenommen und zusammengesetzt werden. Das ist immer noch Job der CPU, die entsprechend nicht gerade rumidelt. Das kann sogar soweit gehen, dass die CPU der Flaschenhals ist, während die GPU weit mehr Daten verwursten könnte. Gut erkennbar bei den Blender-/Cycles-Benchmarks, wenn man die Gesamtergebnisse bei gleicher (leistungsstarker) GPU, aber unterschiedlich potenten CPUs betrachtet.
Top-Erklärung! :-)
Damit verstehe ich wieder ein bisschen besser das ganze Zusammenspiel und ich kann mir nun auch gut all die gemachten Beobachtungen besser erklären [und wenn man etwas versteht, dann muss man auch weniger Fragen ;-) ]!
Danke nochmals!!!
Was möchtest du nachprüfen? Wenn deine Karte die entsprechenden Funktionen nicht unterstützte, würd’s mit einer entsprechenden Fehlermeldung abbrechen. Im Umkehrschluss kann man davon ausgehen, dass die GPU genutzt wird.
Was CPU-Last angeht: die GPU benötigt gut aufbereitete Daten, um sie parallelisiert verarbeiten zu können. Ebenso müssen die verarbeiteten Daten entgegengenommen und zusammengesetzt werden. Das ist immer noch Job der CPU, die entsprechend nicht gerade rumidelt. Das kann sogar soweit gehen, dass die CPU der Flaschenhals ist, während die GPU weit mehr Daten verwursten könnte. Gut erkennbar bei den Blender-/Cycles-Benchmarks, wenn man die Gesamtergebnisse bei gleicher (leistungsstarker) GPU, aber unterschiedlich potenten CPUs betrachtet.
haben die zweit Outputs denn auch die gleiche Bitrate?
Falls nein, könntest du als zusätzlichen Parameter noch -b:v Bitrate angeben.
Die Bitraten sind tatsächlich stark unterschiedlich. In VLC kann man sich die Bitraten beim Abspielen anzeigen lassen.
Hier mal ein Snapshot von beiden Filmen, nach bzw. bei 1min16sec Abspielzeit
Input/Lese Mediengröße Input-Bitrate Größe demuxter Daten Daten-Bitrate
Film kodiert mit h264 4724 KiB 313 kb/s 4141 KiB 548 kb/s
Film kodiert mit h264_nvenc 18394 KiB 2069 kb/s 17946 KiB 2517 kb/s
Ich habe jetzt nochmals beide Konvertierungen erneut durchgeführt, nun aber bei beiden auch eine feste Bitrate von 1000kb/s vorgeben:
$ time ffmpeg -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264_nvenc -b:v 1000k test_h264_nvenc_1000kb.mp4
real 0m29,633s
user 1m6,411s
sys 0m2,256s
Dateigröße / Auflösung / Bildwiederholungsrate: 100M / 854x480 / 24
Größe demuxter Daten: 9384 KiB
$ time ffmpeg -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264 -b:v 1000k test_h264_1000kb.mp4
real 5m20,473s
user 14m36,429s
sys 0m5,726s
Dateigröße / Auflösung / Bildwiederholungsrate: 101M / 854x480 / 24
Größe demuxter Daten: 10043 KiB
Zusammenfassend:
nun, jetzt wo beide Zielvideos auch die selbe Größe/Auflösung/Bitrate haben, zeigt sich, das der h264_nvenc den "normalen" h264 Codec tatsächlich um ein Vielfaches in der Zeit schlägt ... so sollte es ja auch sein :-)
Wäre dennoch schön, irgendwie verläßlich nachprüfen zu können, dass dieser enorme Zeitgewinn tatsächlich daher kommt, dass der h264_nvenc die Power meiner Nvidia Grafikkarte nutzt. Theoretisch könnte es ja immer noch sein, dass auch mit dem h264_nvenc Codec die Transkodierung immer noch über die CPU liefen und "nur" schneller war, da der h264_nvenc einfach besser programmiert ist, Wo oben ja bereits beschrieben, bin ich überrascht, wo stark auch im h264_nvenc Fall, die CPU-Last nach oben springt.
haben die zweit Outputs denn auch die gleiche Bitrate?
Falls nein, könntest du als zusätzlichen Parameter noch -b:v Bitrate angeben.
Bin nicht ganz so tief im Thema drin um über genaue Details zu reden, aber Hardwaredecodierung erzeugt bei gleicher Größe schlechtere Qualität. Könnte also auch damit zusammenhängen.
EDIT: im übrigen sind deine Dateinamen genau falsch rum, nicht dass du die Dateien danach verwechselt hast
upppsss ... die verwechselten Namen habe ich korrigiert (und auch geprüft, ob meine Aussagen noch stimmen - dem so ist).
Naja ... mir stellt sich schon die Frage, lief' die Codierung denn tatsächlich über die Graka? Da bei -vcodec h264_nvenc auch die CPU-Last signifkant hoch ging, dann könnte es doch sein, dass auch hier die Codierung über die CPU lief ... und die Graka nur ein Placebo ist ... vielleich ist einfach nur die Verarbeitung/der Algorithmus zwischen den beiden Codecs anders, was zu den unterschiedlichen Dateigrößen und Geschwindigkeiten führten, aber beides gingen vielleicht über die CPU .... und das Geld für die "hochwertige" Graka hätten man sich dann sparen können.
Bin nicht ganz so tief im Thema drin um über genaue Details zu reden, aber Hardwaredecodierung erzeugt bei gleicher Größe schlechtere Qualität. Könnte also auch damit zusammenhängen.
EDIT: im übrigen sind deine Dateinamen genau falsch rum, nicht dass du die Dateien danach verwechselt hast
Nachtrag: basierend auf den Hinweis von Kabbone unten: ich hatte die Dateinnamen verwechselt :-(. Den ursprünglichen, aber falschen Text habe ich durchgestrichen, und dahinter gleich die Korrekturen gesetzt. Das Ergebnis ist aber immer noch das selbe: die nvenc-Datei ist 4,5x größer als die ohne nvenc.
[...]
Hast du denn mal die Zeiten zwischen CPU decodierung und GPU decodierung gemessen? Das sollte einen relativ großen Unterschied machen
Ich bin mir jetzt unsicher, wie ma es beeinflussen kann, dass einmal die Decodierung über CPU und ein anderes mal über die GPU läuft, Ich vermute mal, indem ich den Parameter -vcodec zwischen h264_nvenc und h264 wechsle. Dies führt auch tatsächlich zu folgendem Ergebnis:
$ time ffmpeg -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264_nvenc test_h264.mp4 test_h264_nvenc.mp4
real 0m31,265s
user 1m7,346s
sys 0m2,637s
$ time ffmpeg -i RobertWaldinger_2015X-480p.mp4 -acodec copy -vcodec h264 test_h264_nvenc.mp4 test_h264.mp4
real 3m48,404s
user 10m21,551s
sys 0m4,626s
ABER: was mich stark verwundert. Ich habe mir die Dateigrößen angesehen. Die mit dem nvenc-Codec ist 4,5x größer! Also ich glaube nicht das hier die Graka für das schnellere Ergebnis sorgte, sondern vielmehr, dass wesentlich schlechter komprimiert wurde. Über VLC habe ich mir noch weitere Daten angesehen:
mit -vcodec h264_nvenc mit -vcodec h264
Dateigröße 191M 42M
Codec ltd. VLC H264 - MPEG-4 AVC (part10) (avc1) <-- dito
Videoauflösung 854x480 <-- dito
Bildwiederholungsrate 24 <-- dito
(... alle weiteren Parameter sind ebenfalls identisch)
ob die Auslastung an sich in der Größenordnung normal ist, kann nicht sagen, aber die Nvidia Karte sollte für Videodecodierung separate Hardwarefeatures (natürlich in begrenzter Menge) besitzen, die mehr oder weniger unabhängig vom normalen Core laufen. Es sollte also der GPU Chip nicht zu 100% ausgelastet werden können.
Hast du denn mal die Zeiten zwischen CPU decodierung und GPU decodierung gemessen? Das sollte einen relativ großen Unterschied machen
Hallo,
als stolzer Besitzer einer neuen, gebrauchten Grafikkarte (GTX 1050 TI), bin ich doch etwas verwundert wie "schwach" Videoprogramme deren Leistungsfähigkeit nutzen (in meinem Fall Kdenlive und Natron).
Deswegen habe ich folgenden Test gemacht: Rechner neu gebootet; GPU-Auslastung mit $ watch nvidia-smi und CPUs mit $ htop überwacht.
Als "Belastungstest" habe ich ein Internetvideo mit ffmpeg in ein anderes Format konvertiert:
$ time ffmpeg -i testfilm.mp4 -acodec copy -vcodec h264_nvenc test.mp4
(hatte mir noch vorher mit $ trizen ffmpeg-full-nvenc die vermeintliche ffmpeg-Unterstützung für die Nvidia-Karte installiert)
Die Auslastung der GPU und CPU sah dann wie folgt aus:
Vor Konvertierungstart Während der Konvertierung
CPU jeder Kern ~2.6% jeder Kernel >86%
GPU 2% 16%
Okay, immerhin scheint die GPU einen Teil der Aufgabe übernommen zu haben. Aber warum bleibt die Hauptlast dennoch bei den CPUs??? Wäre das Ganze nicht schneller, wenn die GPU und nicht die CPU die Arbeit hauptsächlich übernehmen würde???
(Bei der CPU handelt es sich um einen AMD Phenom ii X3)
Installierte nvidia-Pakete:
$ trizen -Ss nvidia | grep Installiert
extra/ffnvcodec-headers 8.2.15.6-1 [Installiert]
extra/libvdpau 1.1.1+3+ga21bf7a-1 [Installiert]
extra/libxnvctrl 415.18-1 [Installiert]
extra/nvidia 415.18-1 [Installiert]
extra/nvidia-lts 1:415.18-1 [Installiert]
extra/nvidia-settings 415.18-1 [Installiert]
extra/nvidia-utils 415.18-1 [Installiert]
extra/opencl-nvidia 415.18-1 [Installiert]
community/cuda 10.0.130-2 [Installiert]