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

"ich weiß gerade nicht wo, aber in irgendeinem Beitrag hier im Forum hatte ich kürzlich gelesen, dass es mit ffmpeg auf der Command Line möglich ist, einen Film von h264 zu h265 zu konvertieren."

hier....ich war das

Konvertierungs Programm für Unraid.

Ich mache es genau so und es dauert mit einer NVidia 1050ti ca 15-20 Monuten für einen 2 Stunden Film als BR in h264. Eine DVD in MPEG2 geht noch viel schneller. Wenn mir jemand den "ach so eklatanten" Unterschied zeigen kann, lass ich mich gern umstimmen.

Staxrip ist haltnur für Windows und Handbrake unterstützt unter Linux keine GPU. Weiter nutzt Handbrake im Hintergrund auch einfach nur ffmpeg. Von daher sehe ich es nicht ein für igendwas eine GUI zu verwenden, die dann (in meinem Fall unter Linux) noch nicht mal alles unterstützt.

@hoppel118 wenn du Fragen zu dem Befehl hast, dann nur zu.

Zitat von hoppel118

Mir gehts nicht darum möglichst viel Platz zu sparen. Wenn bspw. aus einem 40GB-File ein 20 bis 30GB-File entsteht, wäre das schon absolut ausreichend. Perfekte Qualität ist für mich weiterhin das wichtigste.

Wenn du eine Nvidia 900/1000 hast dann kannst du getrost den GPU Encoder nehmen, eine FullHD Film passt da bei "gleicher" Qualität in 10-15gb und das encodieren dauert nicht all zu lange.

Würde auch eine 1030 reichen. Um GPU beschleunigung zu nutzen? Kosten nicht viel.

@hoppel118: Grain = Korn, in diesem Fall also das sogenannte Filmkorn!

@linkplayer

Sollte auch ausreichend sein. Hat halt 2GB weniger Speicher (unter anderem).

Wenn es nur ums archivieren geht, dann mittels MakeMKV den Hauptfilm in mkv packen ohen reencode.

Ansonsten kommen die GPU Encoder immer noch nicht an die Qualität der Software-Encoder ran.
Ich persönlich finde, dass der Aufwand für eine h265 Umwandlung sich noch nicht lohnt und h264 durchaus ausreichend ist und der Encoder (x264) sehr gute Ergebnisse erzeugt.

Hybrid läuft auch unter Windows. Persönlich finde ich eines der besten Programme.

Filmkorn kann man zb. sehr gut mit x264 erhalten mit --preset slow und --tune grain

Aber dann gehen natürlich die Bitraten hoch.

Ansonsten: Viel Infos gibt es dazu unter
German Doom9
Encodingwissen

Englisch:

Doom9

Gruss,
Bitspyer

Zitat von hoppel118

Wenn du einen Film mit ffmpeg zu h265 konvertierst, bleiben dann die für mich wichtigen Eigenschaften des Filmes erhalten? Das sind folgende:

Ich machs mal so....für mich sind die gleichen Dinge wichtig und von daher kann ich alles "bejahen" ;). Ton und Untertitel sind so, wie vorher auch

Zitat von hoppel118

Werden beim konvertieren mit ffmpeg die Tonspuren auch in irgendeiner Form angepasst oder bleiben die erhalten wie sie sind?

Bleiben erhalten, so wie sie sind. Zumindest konnte ich keinen Unterschied feststellen:

Wir können den Befehl ja mal zerlegen:

Das ist er komplett:
ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i <inputfile.mkv> -map 0 -c copy -vcodec hevc_nvenc <outputfile.mkv>

Der Bereich bis zum inputfile beschreibt das Decoding:

ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i <inputfile.mkv>

-y bestätigt die kommende Aktion mit "Yes". Ähnlich wie unter Ubuntu sudo apt upgrade && sudo apt upgrade -y. Da kommt dann auch keine Frage mehr

-hwaccel cuvid beschreibt, dass Hardare Beschleunigung verwendet werden soll und welche genommen werden soll. Welche bei dir für den jeweiligen Codec verfügbar ist, musst du checken. Nehmen wir an, du hast ein h264 video, dann machst du das am besten mit: ffmpeg -decoders | grep h264. Da kommt dann sowas bei raus:

Zitat

VFS..D h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
V..... h264_crystalhd CrystalHD H264 decoder (codec h264)
V....D h264_vdpau H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration) (codec h264)
V..... h264_cuvid Nvidia CUVID H264 decoder (codec h264)

Je nach Verfügbarkeit des Decoders und der ffmpeg Version kann die Ausgabe variieren.

-c:v h264_cuvid beschreibt wohl (da bin ich mir unsicher), das er jede Spur, die er findet, mit dem h264_cuvid auslesen soll.

-vsync 0 parameter für VSync

-i inputfile halt die Datei als Input

Dann gehts mit dem Encoden weiter:

-map 0 übernimmt alle Spuren und ...

-c copy kopiert sie und ....

-vcodec hevc_nvenc encoded sie in HEVC mit Hardwarebeschleunigung NVenc (bei NVidia)

<outputfile> selbsterklärend

Was als encoder bei dir verfügbar ist, musst du ggf auch überprüfen: ffmpeg -encoders

So funktioniert das bei mir bestens. Wir haben im Team ein kleines Rennen und versuchen uns gegenseitig mit der Dateigröße zu unterbieten. Es gibt noch eine Menge anderer Optionen, die man setzen kann. Auch mit dem -q-setting. Damit habe ich aber noch nicht gespielt. Bin grundlegend mit dem Ergebnis mehr als zufrieden. Konnte es aber bisher nur auf einem 55" TV testen und kann noch nichts darüber sagen, wie es auf meinem Beamer mit 100" Leinwand aussieht. Das werde ich so schnell auch nicht testen können, da erst der Raum dafür noch gebaut werden muss

Edit:

Anpassungen an den Befehl musst du natürlich je nach verwendetem Video-Codec machen. Eine DVD hat halt mpeg2, da musst du dann den decoder verändern. ffmpeg -decoders | grep mpeg2

Bei VC1 ähnlich....

Nur um es erwähnt zu haben

Vielleicht stimmen meine Erklärungen oben nicht 100%ig. Dann bitte ich um Berichtigung.

So habe mir jetzt mal eine GT 1030 geholt. Eine 1050 will ich mir nicht holen nur um Videos zu decodieren.

Wenn Dir Qualität wirklich wichtig ist, mach es nur mit einem Software-Encoder. Hardware-Encoder auf Grafikkarten-Basis neigen immer noch zur Verblockung...

Beispiel Video (youtube)

Zitat von linkplayer

So habe mir jetzt mal eine GT 1030 geholt. Eine 1050 will ich mir nicht holen nur um Videos zu decodieren.

zum Dekodieren brauchst Du die sowieso nicht... wenn überhaupt zum Enkodieren und da gebe ich meinem Vorredner recht

Zitat von bitspyer

Wenn Dir Qualität wirklich wichtig ist, mach es nur mit einem Software-Encoder.

Richtig, auch wenns (viel) läner dauert. Der Qualitätsunterschied GPU/CPU ist je nach Filmmaterial enorm. Habe lange genug in der Richtung experimentiert (x265 GPU) und bin wieder bei x264 CPU gelandet. x265 per CPU ist selbst bei starken Rechnern eine Tortour

Wenn es mir nicht gefällt kann ich sie ja wieder zurückgeben.

Gesendet von meinem SM-G920F mit Tapatalk

Also ich habe mich auch schon länger mit dem Thema beschäftigt, und einiges gelesen und auch probiert.
Gpu encodieren soll wesentlich schlechter sein als CPU.
Wenn man sich dann benchmarks zum Thema X265 Encoding anschaut ist es doch recht erschreckend, wie langsam die meisten CPU's dabei sind.

Wenn man dann bedenkt wie lange so ein Film dauert umzuwandeln, Stromverbrauch da die CPU /Gpu dabei ziemlich ausgelastet ist lohnt es aktuell einfach kaum.

Gpu encodieren soll wesentlich schlechter sein als CPU.

Vielleicht werde ich ja alt und meine Augen werden schlechter...aber ich sehe bei meiner Umwandlung weder eine Blockbildung, noch sehe ich, dass Details verloren gehen oder irgendwelche anderen Artefakte.

Wer es nicht glaubt....ich stelle sofort ein Teilstück von einer Datei als Download zur Verfügung. Ich mache kein Gehimnis draus.

Ich will ja nicht sagen, dass CPU encoding nicht doch einen Qualitätsgewinn mit sich bringt. Ich würde aber mal sagen, dass GPU encoding bei weitem nicht soooooo schlecht ist, wie es hier gerade dargestellt wird. Und ja...ich habe den A-B Vergleich gemacht. Auch den Original<->Kopie Vergleich habe ich gemacht. 'Eklatante' Unterschiede konnte ich keine sehen.

Wie gesagt...wer es nicht glaubt, dem schnipsel ich ein Stück zurecht und stelle es in meinen Dropbox zum Download bereit.

Zitat von DaVu

Gpu encodieren soll wesentlich schlechter sein als CPU.

Vielleicht werde ich ja alt und meine Augen werden schlechter...aber ich sehe bei meiner Umwandlung weder eine Blockbildung, noch sehe ich, dass Details verloren gehen oder irgendwelche anderen Artefakte.

Wer es nicht glaubt....ich stelle sofort ein Teilstück von einer Datei als Download zur Verfügung. Ich mache kein Gehimnis draus.

Ich will ja nicht sagen, dass CPU encoding nicht doch einen Qualitätsgewinn mit sich bringt. Ich würde aber mal sagen, dass GPU encoding bei weitem nicht soooooo schlecht ist, wie es hier gerade dargestellt wird. Und ja...ich habe den A-B Vergleich gemacht. Auch den Original<->Kopie Vergleich habe ich gemacht. 'Eklatante' Unterschiede konnte ich keine sehen.

Wie gesagt...wer es nicht glaubt, dem schnipsel ich ein Stück zurecht und stelle es in meinen Dropbox zum Download bereit.

hallo

Habe es selber getestet - Bild quali bei GPU encoded war ubelst - aber schnell

Kodieren alles auf aktuell auf h265 (4500kbits vbr - AAC 5.1 (1080p)

Alles gut soweit

System: [fn]Mein KnechtKnecht[/fn]

Zitat von agarnele

Habe es selber getestet - Bild quali bei GPU encoded war ubelst - aber schnell

Kann ich nicht nachvollziehen. Was hast du verwendet?

Wie gesagt, verwende ich ffmpeg unter Linux. Ich habe das mittlerweile für eine komplette Serie (ca. 50 Folgen) und mehrere Filme gemacht. Ich kann eine "übelst schlechte Bildqualität" zu 0% nachvollziehen. Selbst @CvH hat schon Beispiele von mir gesehen (wenn ich mich recht erinnere), wo auch er meinte, dass das mehr oder minder besser als erwartet wäre.

Also unter "übelst" verstehe ich, dass man den Film so einfach nicht schauen kann, inkl. der Bildung von Artefakten/Blockbildung, Banding, etc. etc. etc....Das habe ich hier nicht wenn ich via GPU encodiere. Aber überhaupt gar nicht. Ich sage nicht, dass das Bild besser wird. Ich sage aber, dass es nicht sichtbar schlechter wird.

Ich mache nachher mal einen Screenshot in 1080p von einem original und einem in HEVC gewandeltem Video.

Zitat von agarnele

Bild quali bei GPU encoded war ubelst - aber schnell

Interessehalber: Läuft ein anderer Algorithmus über die Files, wenn man per GPU encodet?

Normalerweise sollten sich die Rechenvorschriften nicht wirklich unterscheiden bei beiden Implementierungen. Der Befehlssatz, ja, da gehe ich mit. Aber das Ergebnis sollte identisch sein.
Also Sprich: Rechnet die CPU 1+1 kommt 2 raus. Macht die GPU das gleiche, sollte ebenfalls 1 + 1 = 2 gelten. Oder hab ich nen Denkfehler?

Sonst wären ja schlimmstenfalls auch die Ergebnisse unterschiedlich, wenn ich mit gleichen Einstellungen auf einer Intel Maschine oder einer AMD Maschine codiere - die haben ja auch teils andere Befehlssätze. Und das kanns ja nicht sein