Wie kann ich meine komplette Movie-Sammlung von h264 zu h265 konvertieren?

Zitat von Superbunny79

Code

ffmpeg -y -i *.mkv -c:v libx265 -b:v 2900k -x265-params pass=1 -an -f null /dev/null && ffmpeg -i *.mkv -c:v libx265 -b:v 2900k -x265-params pass=2 -c:a aac -b:a 320k output.mkv

Diese zwei-pass codierung ist eher "old-school". Die wurde AFAIK mal entwickelt, damit man fuer einen vorgegebenen datentraeger wie SVCD/DVD/BD oder eine vorgegebene netzwerkverbindung mit konstanter bitrate die beste Qualitaet draufkriegt. Da kommt am ende aber pro bit des Resultats nicht soviel qualitaet bei run, als wenn Du ein-pass crf encoding machst. Einfach weil da halt gemittelt ueber einen relativ kurzen zeitraum (glaube wenige GOPs, als < 1 sekunde), eine feste bitrate, die du vorgegeben hast rauskommt, und wenn da halt zu diesem zeitpunkt besonders viel bewegung oder schnitte im bild waren, dann siehst halt nicht gut genug aus, und wenn stattdessen nix im bild passiert werden beliebig bits im videostrom verschwendet.

Fuer sowas wie festplattenspeicherung und uebertragung uebrre schnelles netz kriegste halt die beste qualitaet/bit indem du "constant rate factor" 1-pass codierung machst. also parameter -crf beim software codec x265. Je niedriger der Wert, desto besser die Qualitaet. Es gilt dann auch noch, das wenn du eine feste bildschirmgroesse hast, das du dann bei zunehmender aufloesung hoehere CRF werte nehmen kannst um dieselbe visuelle qualitaetzu kriegen. Also z.b. crf 21 bei DVD, crf 22 bei 720p, crf23 bei fullHD und crf24 bei UHD. Oder halt 20...23 fuer noch bessere Qualitaet. Aka: Das CRF macht halt qualitaet pro pixel und beruecksichtigt nicht, das dein Bild bei groesserer aufloesung halt nicht groesser wird.

Das was Lehmden1 fuer die GPU codierung schreibt ist die variante von crf fuer die GPU codierung. Gilt also im Prinzip dasselbe, bloss das es da halt keine echten standards fuer die werte gibt. Die GPU codierer sind da viel inflexibler und erzeugen erfahrungsgemaess fuer gleiche qualitaet vielleicht doppelt so.

grosse dateien wie x265. Aber halt schneller und mit weniger stromverbrauch/minute.

Ansonsten: Selbst wenn Du umcodierst um dann z.b. auf BD-R zu schreiben kannst Du auch problemlos CRF nehmen. das braucht dann beim Abspielen evtl. mal kurzfristig bis zu 4-fache Abspielgeschwindigkeit, aber das koennen ja die BD Laufwerke inzwischen alle. Bei UHD hab ich mir die maximalen kurzfristigen Bitraten von CRF noch nicht so angeschaut. Aber man kann ja immer CRF mit maximaler bitrate kombinieren.

Jo, das artet schnell in einen Studiengang aus.

Das setzt Handbrake wohl intern um, denn auch Handbrake verwendet ja ffmpeg. Handbrake hab ich allerdings schon länger nicht mehr genutzt. Wenn es mal etwas gibt, was ich mit Media-Buddy nicht machen kann, weil man das ganz individuell einstellen muss (z.B. Synchron- oder Seitenverhältnis- Probleme reparieren) nehme ich dann meist XMedia Recode als ffmpeg- GUI...

Schade Das MediaBuddy windows GUI ist. Die fetten CPU sind halt bei mir nur in den Limux-Servern. Windows ist fuer interaktiv HTPC, und da nervts auch mehr, wenn da der Luefter voll aufdreht (soviel schlechter ist ja die 5600APU nicht als meine 5900 im Server). Wie sind die Chancen das sowas unter Wine laeuft und nicht beliebig effizienz kostet ?

AutoIt ist Windows Only. Aber eben auch die einzige Programmiersprache, die ich kann. Wenn du ein wenig AutoIt kannst, lässt sich das vielleicht sogar machen. Der Quellcode ist ja beim Programm immer dabei.

Das Hauptprogramm selbst startet unter Wine. Hab ich schon mal ausprobiert. Aber es werden diverse Zusatzprogramme aus dem Hauptprogramm heraus aufgerufen. Dort müsste man die Aufrufe ggfs. anpassen und auf die jeweiligen Linux Versionen umlenken. Der speziell für Media-Buddy geschriebene Grabber nfo4htpc benötigt Mono zum Arbeiten unter Linux, läuft dann aber. Ffmpeg ist keine ".exe" unter Linux weswegen man den Aufruf dahingehend ändern müsste. genau wie bei MKVToolnix. MPV gibt es auch als Linux Version, genau wie MediaInfo. Hier wäre es sicher auf jeden Fall besser, die nativen Linux Versionen zu nutzen, statt die Windows Versionen, sofern sie überhaupt unter Wine laufen, was ich nicht weiß. Wenn man da jeweils die Aufrufe ändert, um die entsprechenden Linux Versionen aufzurufen, könnte das tatsächlich funktionieren. Das Hauptprogramm ist kein so großer Ressourcenfresser, das die Effizienz eine große Rolle spielt. Gut, RAM wird schon mal gebraucht, besonders wenn man viele Dateien auf einmal verarbeitet. Aber sonst hält sich das in Grenzen.

Allerdings kenne ich mich mit Wine und Linux nicht genug aus, um das selbst umzusetzen.

Hast Du da alle binaries in der distribution integriert oder muessen die separat installiert werden ?

Wuerde mal hoffen das es keine Performance Gruende geben sollte, linux native apps zu installieren und im source code rumzuhacken. wine ist ja kein cpu emulator, da laufen windows binaries native, und bloss die ssytem-calls werden umgeleitet. Betrifft also bloss graphik und disk I/O.

Wahrscheinlich natuerlich einfacher, das mal mit CrossOver auszuprobieren, als mit dem freien wine...

Ach, die CPU wird nicht sehr belastet, wenn man per GPU kodiert. Auf meinem Pentium G6600 (ist mein stärkstes System, reicht mir völlig) liegt die CPU Last beim Arbeiten mit ffmpeg unter 20%, wohingegen die GPU auf 100% konstant läuft. Das treibt bei mir die Lüfter nicht merklich hoch.

5600, damit ist doch der Ryzen 5 5600 gemeint, oder? Einen Core i 5600 gibt es nicht, so weit ich weiß, nur einen Pentium G5600 (der locker ausreichen würde). Hast du schon mal probiert, wie da die Ergebnisse sind, wenn die GPU das Kodieren macht? AMD steht ja in dem Ruf, hier eher Murks abzuliefern. Ich habe selbst allerdings überhaupt keine eigenen Erfahrungen damit, in sofern...

Zitat von te36

Hast Du da alle binaries in der distribution integriert oder muessen die separat installiert werden ?

Sind alle dabei.

Zitat von Lehmden1

Der Nvidia Codec heißt hevc_nvenc, der für AMD eben hevc_amf. Sonst ändert sich nichts an den Parametern. Welchen Codec das Eingangsvideo hat ist egal. Damit wird alles nach HEVC kodiert.

2 Pass kann ich dir nicht helfen, denn das hat mich nie auch nur ansatzweise interessiert. Für mich, meine Ansprüche ist 2 Pass unsinnig. Das musst du dir dann selbst raus suchen. Ich weiß nicht mal, ob das bei Hardware Codecs überhaupt geht. Der große Vorteil der Hardware Codecs ist doch die massiv höhere Geschwindigkeit. Warum sollte man die dann so massiv wieder ausbremsen?

Versuch mal

ffmpeg -y -i *.mkv -c:v hevc_nvenc -q:v 21 -c:a aac -b:a 320k output.mkv

Das sollte eigentlich funktionieren.

Du kannst ja mal in deiner Zeile die libx265 durch hevc_nvenc ersetzen, die -x265-params weglassen und stattdessen -q:v 22 (oder 21, weil NVidia hier nicht so gut wie Intel abliefert, AMD ist noch mal erheblich schlechter weswegen meist Intel GPU dafür eingesetzt werden)

ffmpeg -y -i *.mkv -c:v hevc_nvenc -q:v 21 pass=1 -an -f null /dev/null && ffmpeg -i *.mkv -c:v hevc_nvenc -q:v 21 pass=2 -c:a aac -b:a 320k output.mkv

Ob das so tatsächlich funktioniert, weiß ich aber wirklich nicht. Ist nur geraten.

Alles anzeigen

Moin,

ich habe das mal versucht und bekomme leider ein Fehler.

Unknown encoder 'hevc_nvenc'

Dann ist deine ffmpeg Version entweder zu alt oder ohne den Hardware Codec kompiliert worden.

Welches OS verwendest du eigentlich? Falls es möglich ist, würde ich empfehlen, lieber eine GUI Version wie Handbrake, XMedia Recode oder eben MediaBuddy zu probieren. Handbrake gibt es auch für Linux und Mac, in sofern also möglich, sofern überhaupt eine GUI in Linux installiert wurde und es kein reines Konsolen- OS ist. Damit muss man nicht so wild mit den unzähligen Parametern hantieren. Grade wenn man noch nicht genau weiß, wie das alles funktioniert sind solche Programme extrem hilfreich um unnötigen Frust zu vermeiden.

Bei Handbrake musst du laut PvD "nvenc_h265" als Codec auswählen. Bei Media-Buddy unter "Einstellungen > Video-Einstellungen > bei Video Codec dann "Nvidia Nvenc"... Bei XMedia Recode kann ich es nicht nachsehen, da dort nur die verfügbaren Codecs angeboten werden und ich keine NVidia GPU habe...

Ich nutze auf meinem System Openmediavault was auf Debian basiert.

ffmpeg habe ich per apitude nach installiert.

Ah ok, das erklärt einiges. OMV ist kein "richtiges" Linux, auch wenn es auf Debian basiert. In wie weit ffmpeg da "abgespeckt" ist, kann ich nicht beurteilen, könnte mir aber gut vorstellen, das dem so ist. Wieso hast du eigentlich so eine "fette" Grafikkarte in einem NAS? Damit rechnet keiner bei einem reinen NAS System weswegen vermutlich die ffmpeg Version auch nur rudimentär ist.

Kannst du keinen "richtigen" Rechner fürs kodieren nutzen? Ein einfacher Pentium G (wie bei mir) langt völlig aus und liefert mit QuickSync generell bessere Ergebnisse als NVidia's NVenc oder gar AMD's AMF.

Eine andere Sache könnte auch sein, das die GPU ohne angeschlossenen Monitor nicht vollumfänglich arbeitet. Bei Intel funktioniert QuickSync nur, wenn am HDMI Ausgang des Mainboards ein Monitor angeschlossen ist. Eingeschaltet muss er nicht sein, aber vorhanden. Sonst existiert einfach kein QS, was dann auch zu der Fehlermeldung führen könnte. Ob das bei NVidia genau so wie bei Intel ist, weiß ich aber nicht. Käme auf einen Versuch an.

bzgl. HDMI Ausgang Aktiv - ist beim Intel QS nicht immer so, auch bei den Grafikkarten nicht immer. Gibt welche die mögen das nicht. Beim Windows ist das oft ein Problem, das stimmt. Ist eher ein OS Fehlverhalten. Aber bspw. das OMV kann das mit QS Einwandfrei ohne das ein Bildschirm angeschlossen ist.

Superbunny79 welche OMV Version hast du aktuell installiert und gab es Meldungen bei der Installation von ffmpeg? Das sollte mit OMV schon laufen! Bist bei weitem nicht der einzige der ffmpeg auf OMV nutzt.

btw. Lehmden1 was heißt kein richtiges Linux?

"Richtiges" in "". Es ist natürlich ein Linux, aber eben eines, das für einen speziellen Einsatzzweck konfiguriert wurde. Wenn man will, ist auch Android eigentlich ein Linux. Nur da würde niemand auf die Idee kommen, das als "Linux" zu bezeichnen, nicht mal als "Falsches". Andere Abwandlungen wie z.B. PiHole, Octoprint und solche Sachen sind für mich auch kein "richtiges" Linux obwohl sie wie OMV auch auf Debian basieren. "Richtiges" Linux ist z.B. Ubuntu, Suse,... und natürlich auch Debian selbst.

Generell würde ich nie auf einem Headless Server kodieren. Die Teile baue ich immer so sparsam wie möglich und eine GTX 1060 verbraucht mit 120 Watt laut Specs mehr Strom als alle meine 5 Rechner zusammen an TDP haben. Selbst wenn ich meine Android und Core Elec Kodi Boxen auch noch dazu rechne, reicht das immer noch nicht um auf den Verbrauch einer einzigen GTX 1060 zu kommen. So ein "Monster" in einem NAS? Auf die Idee würde ich im Leben nicht kommen. Mein Desktop System hat eine TDP von 55 Watt (incl IGPU natürlich) und damit mehr als die Hälfte des Verbrauchs aller 5 Kisten. Die anderen 4 liegen alle bei 10 Watt oder weniger... Und das nächste System, das auf was sparsameres umgestellt wird, ist dann der Desktop PC. 55 Watt ist nicht mehr zeitgemäß. Das muss auch mit der Hälfte gehen...

gut, dass die Graka nur dann Strom zieht wenn sie belastet wird und dann auch nur so viel wie sie sich halt nimmt TDP hat nicht viel Aussage über den Strombedarf. Aber hat ja hier nichts weiter mit dem Thema zu tun

Gerade auf nem headless server zu kodieren hat den Vorteil -> Er läuft doch eh, dann macht er es im Hintergrnd und ich hab nicht noch extra nen ganzen PC an nur dafür. Hardware effizienter ausgenutzt. Aber ja, auf einer nvidia GPU täte ich das auch nicht machen. bevorzugt eine Intel CPU mit GPU und QS

ffmpeg -codecs

listet einkompilierte codecs. Die Liste ist lang (bei mir). Ggf noch ein | grep -i hevc anhängen. Oder "nv" statt "hevc" oder "265".

Kodieren mache ich nebenbei, wenn ich sowieso z.B. im Kodinerds Forum unterwegs bin oder programmiere oder 3D konstruiere oder Bilder bearbeite oder, oder, oder. Dank QuickSync dauert das Kodieren ja nicht mehr lange. Ein Film braucht selten mehr als 30-45 Minuten, eine Serien Episode in der Regel so um 15 Minuten. Das geht fast immer nebenher ohne extra Laufzeit. Und da die CPU ja kaum belastet wird, merkt man das im Alltag gar nicht, ob der Rechner grade kodiert oder nicht. Das Einzige, wo ich aufpassen muss, ist wenn ich im Slicer einen 3D Druck vorbereite. Dabei wird auch die GPU verwendet. Meist klappt es trotzdem, aber es ist auch schon mal schief gegangen und ich musste das Slicen wiederholen.

Meine Headless Systeme laufen, bis auf eine Ausnahme (den Celeron N3350 mit seinen 2,8 Watt gemessener Gesamt- Stromaufnahme) nur dann, wenn sie gebraucht werden. Also ist nicht wirklich was mit extra Strom verbrauchen. Theoretisch kann der N3350 auch QuickSync. Ich habe aber noch nie probiert ob und wie schnell das wirklich geht.

Mein Desktop System braucht im Betrieb auch längst keine 55 Watt. Aber die "120 Watt (typisch)" der GTX 1060 war der einzige Wert, den ich online finden konnte. Deswegen habe ich das mit den TDP Werten verglichen, nicht mit den Realen... Etwas, das 120 Watt (wenn auch nur als Maximalwert) verbraucht, kommt mir ganz sicher in keinen PC, nie und nimmer. Diese Zeiten sind aber sowas von vorbei...

Der größte anteil an GPU Leistung wird wohl in DataCenter Servern stecken mit NVidia Einsteckkarten die wahrscheinlich noch nicht mal Videoausgaenge haben. Von daher ist "headless GPU" eher ein Problem in den verkackten Treibern für den Consumerbereich und weniger konzeptionell.

Solange man die GPU dazu bekommt, bei Nichtbenutzung möglichst wenig Strom zu saugen, und dann im Betrieb richtig zu funktionieren ist doch der Einsatz in einem Server prima. Klar, so ein NAS ist eh schwer genug richtig hinzubasteln, wenn man es selbst macht, ich würde da auch niemandem empfehlen, auch noch zu versuchen, da eine GPU sinnvoll einzupflegen, aber so als advanced Bastelprojekt für einen Nerd... warum nicht.

Gibt ja auch diese HDMI Dongles die einen Monitor vortäuschen, damit die verkackten Consumertreiber vernünftig funktionieren. Evtl. sowas mal probieren, wenn da das Problem liegt. Ich hab z.b. ein neues Server MoBo gekauft, diesmal nicht mit IPMI und dadrin eingebauter Graphikkarte, sondern eben nur ein einfacheres system mit Intel CPU die AMT kann - und dort hab ich auch zum ersten Mal so einen Dongle einsetzen müssen, weil da tatsächlich das AMT nicht mehr richtig lief, weil das BIOS die GPU wegen Abwesenheit eines Monitors nicht richtig initialisiert hat.

Denke aber auch, das das eher ein Problem einer kompilierten Version ist, die solche Erweiterungen wie GPU codierer nicht reincompiliert hat. Wer da für solche Spezialkombinationen ein OS haben will sollte da evtl. schon einen mühsamen Weg wie Gentoo gehen - da kann man ja auf Systemebene optionen vie NVidia GPU konfigurieren, und dann compiliert das ganze System alle Anwendungen mit oder ohne so einer Option. Fauli Faulbär würde wohl eher einen einfachen Debian Desktop Container oder VM unter einem NAS laufen lassen. Wobei ich nicht weiss, wie gut das mit GPU passthrough da funktioniert.

Zitat von Lehmden1

Ach, die CPU wird nicht sehr belastet, wenn man per GPU kodiert. Auf meinem Pentium G6600 (ist mein stärkstes System, reicht mir völlig) liegt die CPU Last beim Arbeiten mit ffmpeg unter 20%, wohingegen die GPU auf 100% konstant läuft. Das treibt bei mir die Lüfter nicht merklich hoch.

5600, damit ist doch der Ryzen 5 5600 gemeint, oder? Einen Core i 5600 gibt es nicht, so weit ich weiß, nur einen Pentium G5600 (der locker ausreichen würde). Hast du schon mal probiert, wie da die Ergebnisse sind, wenn die GPU das Kodieren macht? AMD steht ja in dem Ruf, hier eher Murks abzuliefern. Ich habe selbst allerdings überhaupt keine eigenen Erfahrungen damit, in sofern...

Naja, bisher bin ich nicht überzeugt, das ich von x265 software auf GPU codierung umsteigen sollte. Deswegen ja auch Server mit schneller CPU, Ryzen 5900X. Liegt leider als nacktes MoBo mit laufendem neu installierten OS seit Monaten rum, weil ich Ausfälle des Servers derzeit nicht unterkriege *seufz*. Aber Mobo wechseln, und dann hab ich vielleicht doch irgendwelche Software übersehen...

Meine letzten Zahlen von codieren mit GPU waren ja eben ca. Faktor 2 mehr Bitrate für gleiche Qualität gegen x265.

Die GPU codierung auf AMD hab ich noch gar nicht probiert. Die APUs hab ich ja nur in den Windows HTPC drin. Klar, ich sollte da mal MediaBuddy ausprobieren.

Zitat von noob_at_pc

bzgl. HDMI Ausgang Aktiv - ist beim Intel QS nicht immer so, auch bei den Grafikkarten nicht immer. Gibt welche die mögen das nicht. Beim Windows ist das oft ein Problem, das stimmt. Ist eher ein OS Fehlverhalten. Aber bspw. das OMV kann das mit QS Einwandfrei ohne das ein Bildschirm angeschlossen ist.

Superbunny79 welche OMV Version hast du aktuell installiert und gab es Meldungen bei der Installation von ffmpeg? Das sollte mit OMV schon laufen! Bist bei weitem nicht der einzige der ffmpeg auf OMV nutzt.

btw. Lehmden1 was heißt kein richtiges Linux?

Ich nutze OMV 6:

Version
6.9.2-1 (Shaitan)

Prozessor
AMD Ryzen 7 3800X 8-Core Processor

Kernel
Linux 6.1.0-0.deb11.11-amd64

Warum ich so eine mächtige Grafikkarte dadrin habe nun gut die war über und daher ab damit in den Server (Grundsätzlich um gewisse Dinge zu rechnen mal was brüten usw.)

Ausgabe von ffmpeg -codecs |grep -i hvec lieferte folgendes:

Ist nicht mit dabei, bei mir schon:

DEV.L. hevc                 H.265 / HEVC (High Efficiency Video Coding) (decoders: hevc hevc_v4l2m2m hevc_cuvid ) (encoders: libx265 nvenc_hevc hevc_nvenc hevc_v4l2m2m hevc_vaapi )