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.


    Moin @DaVu,

    jo, hast recht, das war der Beitrag, der mich auf die Idee gebracht hat, mal in diese Richtung zu denken. Da ich allerdings statt unraid openmediavault verwende, habe ich den Beitrag wohl nicht mehr wiedergefunden. ;)

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

    • alle verfügbaren Tonspuren in lossless Audio (DD, DD True-HD, DTS, DTS-HD MA, DTS-HD HRA)
    • alle verfügbaren Subtitles mit den entsprechenden Flags (bspw. forced)

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

    • Wenn sie auch in irgendeiner Form encoded werden, zeigt mir mein AVR dann trotzdem noch das ursprüngliche Audioformat an oder sehe ich dann überall nur noch "PCM" oder etwas anderes in der Art?
    • Wenn das der Fall ist, bleibt die Frage, ob ich die Tonspuren vom Encoden ausschließen kann?
    Zitat von CvH

    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.


    Hm..., naja, wie gesagt mein Server hat keine wirkliche GPU. Die GPU meines Servers (Aspeed AST2400 BMC) dient lediglich dazu ein Bild anzuzeigen, um das OS lokal per VGA oder remote per IPMI konfigurieren zu können.

    In meiner Workstation ist allerdings eine Nvidia GTX 950 verbaut: https://de.msi.com/Graphics-card/GTX-950-GAMING-2G.html

    Um diese GPU für das Vorhaben nutzen zu können, müsste ich dann entweder jeden Film einzeln auf diese Workstation kopieren, konvertieren und wieder auf den Server schieben oder das direkt über die SMB-Freigabe machen. Der Aufwand die Filme alle einzeln hin und her zu kopieren, ist mir gefühlt zu groß. Das direkte Encoden über die SMB-Freigabe führt wahrscheinlich zu einem extremen Einbruch der Encoding-Performance. Das würde lokal auf der SSD der Workstation wahrscheinlich wesentlich schneller ablaufen. Zwischen Workstation und Server besteht GBit-Ethernet.

    Die GPU von der Workstation in den Server umzubauen oder extra für diese Aufgabe für den Server eine neue Grafikkarte zu kaufen, ist für mich keine Alternative. Bisher habe ich auch keinen Mehrwert darin gesehen, meinem Server eine echte GPU zu verpassen. Das führt meiner Ansicht nach zu unnötig hohem Stromverbrauch.

    Ich denke, ich werde es einfach mal auf meinem Server mit ffmpeg ausprobieren und mal schauen, wie lange meine CPU dafür so braucht, wie ausgelastet die CPU dadurch ist und ob der Server während des Encodens anderweitig noch nutzbar ist. Den schwächsten Server habe ich hier ja auch nicht gerade stehen... ;)

    Ein weiterer Test für den direkten Vergleich wäre das Encoden anhand der GPU meiner Workstation über die SMB-Freigabe.


    Zitat von McStarfighter

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


    Ja, das hatte ich mir auch schon kurz ergoogelt. Allerdings stellte sich mir dann die Frage, was ein Filmkorn sein soll... ;) Habe gerade nochmal danach gegoogelt und folgende Wiki-Erläuterung gefunden: https://de.wikipedia.org/wiki/Korn_(Foto)

    Wenn diese Details, wie @b0mb beschrieben hatte, beim konvertieren flöten gehen, bleibt die Frage, ob das ganze konvertieren bei DVDs (mpeg2) und Blurays (h264) überhaupt sinnvoll ist. Da müsste ich mir tatsächlich erstmal ein paar Testfilme in h265 erstellen, um zu schauen, ob ich einen Unterschied in der Bildqualität erkennen kann. Wie mehrfach erwähnt, ist mir die Qualität auch wichtiger als die Speicherersparnis,

    Offtopic: Kann man 4K-Material eigentlich mittlerweile schon irgendwie rippen, wenn man das richtige Bluraylaufwerk hätte?

    Gruß Hoppel

    frontend: nvidia shield tv 2019 pro | apple tv 4k | sonos arc 5.1.2 | lg oled65c97la
    backend: supermicro x11ssh-ctf | xeon | 64gb ecc | wd red | zfs raid-z2 | dd max s8

    software: debian | proxmox | openmediavault | docker | kodi | emby | tvheadend | fhem | unifi

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

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

    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.

    Zitat von bitspyer

    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.


    Hohe Bitraten sind ok, hauptsache die Qualität stimmt.

    Zitat von DaVu

    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

    Bleiben erhalten, so wie sie sind. Zumindest konnte ich keinen Unterschied feststellen:
    Wir können den Befehl ja mal zerlegen:

    ...

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


    Coole Sache, dann werde ich es demnächst zumindest Mal ausprobieren. Danke für die Erläuterungen zum ffmpeg command. Dann wäre jetzt nach den ganzen Informationen hier für mich noch interessant, wie ich statt der GPU die CPU verwenden kann.

    Zitat von Cherryman

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


    Ich bin gespannt, wie lange mein Server für das Encoden eines mpeg2- bzw. h264-Filmes benötigt.


    Zitat von Django.Durano

    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.


    Je nachdem wie die Ergebnisse ausfallen und wie lange das Encoden per CPU auf meinem Server bzw. per GPU auf meiner Workstation lokal und per smb benötigt, werde ich ggf. wieder Abstand von der ganzen Sache nehmen.

    Mittlerweile habe ich fast 1000 Filme. Die alle zu encoden, würde ja ggf. Ewigkeiten dauern. Mal sehen, testen will ich es auf jeden Fall.

    Vielen Dank für die Tatkräftige Unterstützung und den hervorragenden Austausch. Über diesen Thread wird sicher noch der ein oder andere stoßen, der aufgrund ähnlicher Ideen nicht mehr ruhig schlafen kann. ;)

    Viele Grüße Hoppel

    frontend: nvidia shield tv 2019 pro | apple tv 4k | sonos arc 5.1.2 | lg oled65c97la
    backend: supermicro x11ssh-ctf | xeon | 64gb ecc | wd red | zfs raid-z2 | dd max s8

    software: debian | proxmox | openmediavault | docker | kodi | emby | tvheadend | fhem | unifi

    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.

    Einmal editiert, zuletzt von DaVu (29. September 2017 um 01:02)

    Für mich brauchst du das nicht zurecht schnipseln. Ich werde mir bei Gelegenheit selbst ein Bild davon machen! ;)

    frontend: nvidia shield tv 2019 pro | apple tv 4k | sonos arc 5.1.2 | lg oled65c97la
    backend: supermicro x11ssh-ctf | xeon | 64gb ecc | wd red | zfs raid-z2 | dd max s8

    software: debian | proxmox | openmediavault | docker | kodi | emby | tvheadend | fhem | unifi

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden