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

  • Hi.

    Du kannst im Schnitt ca 40-60% Platz einsparen, wenn du von h264 auf h265 umkodierst. Ich habe aus meinen vorher ca 75 TByte Medien etwa 35 TB gemacht, dadurch. Ich hab das Ganze also schon hinter mir.

    Im Gegensatz zu meinem Vorredner halte ich die Mär von dem ach so viel besseren Encoden per Software eben genau für das, eine Mär. Ich habe das lange und intensiv ausgetestet. Auf einem "normalen" 4k HDR TV (für mich das relevante Ausgabe- Medum) sieht man keinerlei Vorteile von Software zu QuickSync kodierten h265 Videos, gar keine. Und die Dateigröße ist auch ähnlich. Einzig, wenn man die extrem lahme 2- Pass Kodierung macht, gibt es da minimale Unterschiede. Dazu muss man aber schon ganz genau hinschauen. Und besser wird ein Video durch das Umkodieren sowieso nie. Wenn man keine sichtbaren Verluste gegenüber dem h264 Ausgangsvideo sieht, kann und muss man zufrieden sein. Mehr geht sowieso nicht. Und das kann man mit Quick Sync immer erreichen.

    Dafür dauert das Umkodieren einer 45 Minuten dauernden Serien Episode mit QS auf meinem System keine 15 Minuten. per Software 1-Pass 4-5 Stunden, bei 2- Pass sind es locker auch 6 oder 8 Stunden oder mehr. Wie gesagt, auf meinem, nicht grade schnellen System (Pentium G6600, 32 GB Ram).

    Anders sieht es aus, wenn man AMD Hardware Decoding versucht. Das fällt im Vergleich zu Intel doch deutlich sichtbar ab. NVidia liegt irgendwo dazwischen, aber kommt ebenfalls längst nicht an Intel heran. Hier ist der Platzhirsch ganz eindeutig Intel.

    Ich verwende seit vielen Jahren mein eigenes Programm Media-Buddy zum Umkodieren. Die verwendete Engine ist FFMpeg, wie bei den meisten derartigen Programmen (Handbrake und Co.). Aber Media-Buddy ist sehr einfach, unkompliziert und vor allem super komfortabel bei Batch- Verarbeitung. Es erledigt nämlich nicht nur das ggfs. notwendige Umkodieren, sondern kann gleich auch noch überflüssige Ton- und Untertitel- Spuren entfernen, was durchaus eine Menge Platz sparen kann. Wenn man mag (ich mag sogar sehr) kann man den Ton auch gleich normalisieren, also in der Lautstärke angleichen. Die teilweise drastischen Lautstärke- Unterschiede der einzelnen Videos werden somit ausgeglichen. Es ist wirklich herrlich, wenn alle Videos die gleiche Lautstärke beim Abspielen haben, unbezahlbar, finde ich.

    Daneben bevorzuge ich auch eine Dynamik- Kompression. Das alles kann man, muss man aber nicht machen. Ich mag es jedenfalls nicht, wenn ich einen Film so laut anschauen muss, das die Fensterscheiben bei Explosionen zerbersten und das ganze Haus wackelt, man Dialoge aber nicht mehr verstehen kann, weil sie so extrem leise sind. Sowas mag im Kino funktionieren, aber nicht zu Hause, und schon gar nicht in einer Mietwohnung.

    Das Media-Buddy dabei auch gleich noch .nfo Dateien erzeugt, die Videos passend umbenennt und mit Fanart versieht, also quasi die Arbeit von tmm und ähnlichen Programmen mit erledigt, sei nur am Rande erwähnt. Auch das kann man, muss man aber nicht mit machen lassen.

    All das geht mit einem einzigen Mausklick, für dutzende, ja hunderte Videos auf einmal. Bei Stückzahlen jenseits der 1000 Videos wird es allerdings eng, denn die komplette Liste muss im RAM gehalten werden. Man sollte es möglichst bei 200-300 Dateien auf einmal belassen. Das ist dann noch problemlos händelbar und der Rechner hat damit sowieso eine Weile zu tun.

    Wenn du einen halbwegs aktuellen (er muss halt QS für h265 unterstützen, was die älteren Exemplare noch nicht konnten) Intel Prozessor hast oder beschaffen kannst, verwende auf jeden Fall Quick Sync. Das spart unzählige Stunden an Zeit und somit auch Unmengen an Geld, weil der PC eben viel weniger lange schuften muss und somit auch viel weniger Strom verbraucht...

    -------------------------------------
    Danke fürs lesen, Claus

  • Nein es ist kein Märchen. Du kannst mit QS visuell genauso gute Ergebnisse erzielen wie mit x265, aber bei weitem nicht so effizient was den Speicherplatz angeht.

    Habe es oft genug ausprobiert weil ich inzwischen jede neue Serienfolge die bei mir auf den Server geht mit Handbrake und x265 automatisiert encode. Ich habe knapp drei Monate QS dafür verwendet bis ich gemerkt habe wie ineffizient das ist.

    Aber ja es ist um einiges schneller, vor allem bei einer riesigen Sammlung.

  • Bei gleicher Qualitätseinstellung und gleichem Encoder sind die Resultate optisch gesehen auch gleich, egal ob Soft- oder Hardwareencoding. Die Dateigröße des Ergebnisses macht den Unterschied. Softwareencoding erzeugt die "kleinsten" Dateien, Intel QSV ist ca. doppelt so groß und NVEnc legt nochmals eine Schippe drauf (ca 3x des Software-Encodings). Dafür ist NVEnc auch am schnellsten, bei GraKas aus dem High-End Bereich sogar superschnell. Zu AMD kann ich nichts sagen, da ich kein AMD habe.

    Von der Dateigröße her ist H.264 etwa doppelt so groß wie H.265, egal ob Software oder Hardware. Jetzt kann man natürlich verschiedene Kombis ausprobieren und wird dann zu dem Ergebnis kommen, das ein per Software encodetes H.264 in etwa genauso groß wie ein per QSV encodetes H.265 ist, ein per NVEnc encodetes H.265 sogar etwas größer. In jedem Fall bringt jedoch ein re-encodieren eines BD-Rips ca. 50%-70% Platzersparnis, wer also noch "unkomprimierte" BD-Rips rumliegen hat, für den lohnt dann auch ein erneutes Encodieren. Das gilt auch für TV-Aufnahmen der ÖR, die i.d.R. recht groß ausfallen. Sofern verfügbar, ist da aber der Download aus den Mediatheken die bessere Wahl, das spart am meisten Zeit ;) .

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960

    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

  • Sofern verfügbar, ist da aber der Download aus den Mediatheken die bessere Wahl, das spart am meisten Zeit

    Das mache ich immer, aber kodiere sie trotzdem nach h265 um, denn die Downloads aus den ÖR- Mediatheken sind in h264... Grade heute erst noch die "aktuelle" Otto Show geladen und umgewandelt. Das Kodieren hat etwa eine halbe Stunde gedauert, es ist aber auch eine 90 Minuten Sendung. Aus 2,7 Gbyte der herunter geladenen mp4 Datei ist eine 1,3 GByte mkv in h265 geworden. Und das, wo sich so alte Sachen (ist eine Sendung von 1979 in entsprechend mieser Qualität) auf Grund der vielen Störungen im Bild meist nur schlecht komprimieren lassen. Bei so einem Zeitdokument stört mich das aber nicht wirklich...

    Per SAT kommen die Sendungen obendrein nur in 720p, als Download aus der Mediathek sind es (fast) immer 1080p.

    -------------------------------------
    Danke fürs lesen, Claus

  • Hallo zusammen,

    Aktuell liegen Remuxes der BDs auf dem NAS mit bestem Deutsch + English Audio und entsprechende Untertitel, die ich mit Hilfe von QSV in 1080p h265 encoden wollen würde - sollte einiges an Platzersparnis nach sich ziehen und meine Speichersorgen weit in die Zukunft verschieben.

    Problem vor dem ich stehe: Es gibt so viele Einstellmöglichkeiten bei ffmpeg, dass ich gar nicht weiß wo ich anfangen soll.
    Welchen Befehl nutzt ihr denn, um eure BD zu encoden?

    Das groesste Problem wird sein, das Du dich fuer irgendwelche Codierungsparameter entscheiden musst, und da gibt es halt keine allgemeingueltigen Empfehlungen. rf21 mit x265 koennte ziemlich nah drankommen, allerdings gibts ja auch alte Filme, die rauschen, da will man noch den

    rauschparameter setzen. Und die sind dann leichtviel groesser dadurch. Ausser halt, man mag gematschte Konvertierungen. Und wenn Du TV Material hast stellt sich noch die Frage nach deinterlacing. Alte Tatorte z.b. Meistens kriegt man die gut deinterlaced fron dder Mediathek. Ausser einiges an WDR Material, wo die komplett versagen.

    Ich wuerde die HW-encoder prinzipiell nicht nehmen fuer langfristige Archivierung, weil die halt deutlich weniger Gehirnschmal ueber die Jahre bekommen haben. Und wenn dann z.b. die Filme erst mal alle auf 7GByte komprimiert wurden und Du dann wieder Platzprobleme hast... Mehrere Komprimierungen nacheinander sind auch nicht toll.

    Aber klar, SW encoder kostet richtig Strom bei grossem Archiv. Empfehle also erst mal Solaranlage. Auf jeden Fall ist das meine Ausrede das ich mein Archiv noch nicht umcodiert habe.

  • Diese Zahl sieht man hier öfters mal genannt

    Du kannst im Schnitt ca 40-60% Platz einsparen, wenn du von h264 auf h265 umkodierst.

    Ich hatte das schon hin und wieder hier im Forum kommentiert. Insbesondere da der von mir früher genannte Link zum wissenschaftlichen Artikel nicht mehr funktioniert, hier nochmal eine Wiederholung ...

    Die 40%-60% Platzersparnis sind sicherlich möglich, aber kaum ohne sichtbaren Qualitätsverlust. Zum ersten sollte es klar sein, dass Umcodieren mit normalen Methoden die Qualität maximal beibehalten kann, normalerweise aber immer etwas Qualitätsverlust zur Folge hat. Selbst wenn man nicht umkodiert, sondern unkodiertes Roh-Material einmal mit h264 und einmal mit h265 kodiert und gleiche Qualität erreichen will, wird man laut wissenschaftlichen Untersuchungen https://iphome.hhi.de/wiegand/assets…Performance.pdf typischerweise 35% an Speicher sparen können, nicht die oft Marketing-typisch genannten 50%. Beim Umkodieren kann die Ersparnis nur geringer ausfallen.

    Ich habe auch selbst experimentiert (mit ffmpeg). Bin davon abgekommen, das realisieren zu wollen. Es gibt alle möglichen Fallen. Parameter die mal gut funktionieren, zeigen mal komische Effekte. Passt man nicht sehr genau auf inkl. Prüfung, geht leicht Mal eine Tonspur (sagen wir Original-Sprache) flöten, etc. Bei unter 15 € pro TB HDD Kosten zur Zeit (gerne verdoppeln wegen Backups) ist das für mich nicht mehr der Mühe wert.

    Was ich in der Tat tue, ich nehme Filme (meist vorher aus Fernsehen aufgenommen) erneut auf über DVB-T2. Da hat man dann h265 gleich inkl. Den Fernsehanstalten kann man schon zutrauen, das richtig zu machen. Tlws. sollen die früher in 720p50 ausgestrahlten Filme nun auch tatsächlich direkt aus 1080p50 Material kodiert werden (und nicht nur hochgerechnet). https://de.wikipedia.org/wiki/DVB-T2_HD…_in_Deutschland "Stand 2022 werden im Ersten und den Dritten viele Sendungen ohne eine Hochskalierung von nativen 1080p50 HD-Quellen gesendet, beim ZDF beschränkt man sich dabei noch hauptsächlich auf eigene fiktionale Programme und wenige Studioproduktionen, lizenzierte fiktionale Programme werden beim ZDF nach wie vor nur hochskaliert."

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

  • Das groesste Problem IMHO ist, das es keine gute automatisierte Berechnung der Qualitaet eine umcodierung gibt. PSNR kann man vergessen, weil da halt perzeptuelle Faktoren nicht einfliessen. Aka: man kann leicht sehen wie bei h265 der PSNR niedriger ist als bei h264, aber das Bild trotzdem gleich oder besser aussieht.

    Und die "richtige" codierungsparameter aussuchen ist halt bei x265 so viel schwieriger, als zumindestens frueher bei h264. Traditional konnte man bei h264 block artefakte sehen, wenn man zuwenig qualitaet gegeben hat. Aber das ist schon lange durch Matschigkeit ersetzt. Und bewerten, welches Encoding weniger matschig ist ist unglaublich schwierig.

    Und bei erwaehntem hochskalieren gibt man ja wirklich viel plattenplatz fuer mehr matschigkeit aus. Die man ebensogut mit einem guten Abspieler erreichen koennte. Und dabei bits spart. Aber ist halt schwierig festzustellen, ob hichskaliert ist. Und wieder runterskalieren ist dann natuerlich schwierig.

  • Hi.

    Zum ersten sollte es klar sein, dass Umcodieren mit normalen Methoden die Qualität maximal beibehalten kann, normalerweise aber immer etwas Qualitätsverlust zur Folge hat

    Ja, das ist absolut klar. Besser wird nichts durch umwandeln. Bleibt nur die Frage, ob man die Unterschiede aber überhaupt sehen, bzw. in wie weit die eigene Hardware damit besser oder schlechter umgehen kann. Meine Android Boxen auf AML Basis haben z.B. viel weniger Probleme mit h265 Material als mit h264 Material. Deswegen bringt mir das Umkodieren tatsächlich eher einen Qualitätsvorteil als einen Nachteil. Das ist sicher rein Gerätespezifisch, aber nichtsdestotrotz ergibt das für mich unter dem Strich ein eher besseres Bild bei signifikant weniger Platzverbrauch. Viel krasser ist es bei "alten" Codecs wie Mpeg2 oder DivX. Das schafft die Hardware praktisch gar nicht mehr, weil diese Sachen nicht in der GPU Hardware unterstützt werden und die ARM CPU doch meist etwas arg schwach dafür sind. DivX/XVid kann ich eigentlich gar nicht anschauen, weil es so erbärmlich stottert. Besonders dann, wenn die Videos eigentlich nicht gar so gruselig sind. Theoretisch kann DivX ja sogar BluRay, aber meine Hardware kann kein DivX...

    Passt man nicht sehr genau auf inkl. Prüfung, geht leicht Mal eine Tonspur (sagen wir Original-Sprache) flöten, etc.

    Was aber auch grade erwünscht sein kann. Ich schaue keine Filme/Serien in Originalsprache mit Untertiteln, wenn es eine deutsche Tonspur gibt. Zum "Aufpassen" habe ich mein Programm, das übersieht dabei nichts. Tatsächlich kann man es so konfigurieren, das genau die gewünschten Spuren erhalten bleiben. Man kann z.b. Deutsch und Englisch behalten, aber Hebräisch und Swahili entfernen lassen. Ich schmeiße grundsätzlich alles bis auf eine deutsche Tonspur sowie alle Untertitel bis auf die Forced in Deutsch raus. Das Andere brauche und will ich nicht behalten.

    laut wissenschaftlichen Untersuchungen https://iphome.hhi.de/wiegand/assets…Performance.pdf typischerweise 35% an Speicher sparen können

    Das ist sicherlich hoch wissenschaftlich, aber eben nur graue Theorie. Ich habe aus ursprünglich mal gut 60 TByte an h264 Video Material eben gut 30 TByte an h265 Material gemacht, ohne das ich bei mir einen Unterschied sehen kann. Das ist eine Tatsache, keine Theorie. Wissenschaft ist so lange richtig, bis sie von der Realität widerlegt wird. Wie viel genau jetzt durch das reine Umkodieren eingespart wurde und wie viel durch das Entfernen von für mich völlig überflüssigen Ton- und Untertitel Spuren, habe ich dabei nicht gemessen, denn es ist mir völlig Wurscht. Für mich zählt nur das Ergebnis, und das sind eben genau die etwa 50%... Ich habe dabei Videos gehabt, die durch das Umkodieren nach h265 um 70-80% geschrumpft sind, andere hingegen gar nicht. Aber selbst die habe ich in h265 gelassen, weil eben meine Hardware mit h265 besser umgehen kann...

    Bei unter 15 € pro TB HDD Kosten zur Zeit

    Sind bei 30 TByte auch immerhin 500€ - 1000€. Für mich ist das (zu) viel Geld, vor allem für etwas, das ich sowieso nicht sehen kann. Außerdem muss man dabei ja die mögliche Anzahl an HDD im Server berücksichtigen, was in aller Regel bedeutet, man muss die meisten, um nicht zu sagen alle HDD gegen deutlich größere tauschen. Macht die Sache auch nicht günstiger...

    -------------------------------------
    Danke fürs lesen, Claus

  • Hier nur mal meine 2 Cent dazu.

    Ich habe das auch mal ne Weile lang verfolgt und habe über meine GraKa mit FFMPEG und NVENC via Kommandozeile meine h264 Videos zu h265 gewandelt.

    Mal mit gutem mal mit schlechtem Erfolg. Ein Beispiel wo ich es mir z. B. geschenkt habe war beim "Hobbit". Das Banding war grausam. Da habe ich dann lieber den Film so wie er war genommen und den Speicherplatz gern belegt.

    Ich mache es daher immer so, dass ich erstmal nur nen Schnippsel wandele und mir das Ergebnis anschaue. Wenn es mehr als 3 Versuche benötigt um was "ordentliches" zu bekommen, lasse ich es mittlerweile.

  • Habe damit auch ein wenig gespielt.

    Hab es mit DVDFab gemacht.

    Lohnt sich tatsächlich nur wenn man als Vorlage ein Remux nimmt.

    Bitrate auf 6500,2Pass Encoding.

    So schrumpft der Film auf ca die Hälfte bis 2/3 bei gleicher Qualität.

    Gab aber selten Fälle wo ich es einfach gelassen habe.

    Da ich sehr sehr selten mal was auf Englisch gucke lohnte es sich einfach alle unnötigen Ton Spuren zu entfernen.

    Da kommt es auf die Masse an.

    Plex Server@64TB + Kodi ( Homatics Box R 4K Plus @ CoreElec )

  • Hi.

    Ich hatte vorhin eine kleine Lücke, in der es sich nicht gelohnt hat, etwas "richtiges" anzufangen. Daraufhin habe ich mir die Jellyfish Testvideos noch mal alle angesehen. Auf meiner S905x4 Box mit CoreElec/Kodi 20.2 kann ich über GBit Lan die h265 Videos bis 300 MBit Bitrate (in 10 Bit Farbtiefe und 4K Auflösung) ansehen, ohne das die Wiedergabe ruckelt. Nur bei der aller größten Datei mit 400 MBit gibt es vereinzelte Ruckler. Bei h264 reicht es nur bis 80 Mbit bei 8 Bit Farbtiefe, bevor es anfängt zu ruckeln. H264 ist fast um den Faktor 4 anspruchsvoller auf meiner Hardware. Wenn man dann noch berücksichtigt, das h265 besser komprimiert als h264, also mehr Informationen pro MBit enthält, sind die Unterschiede eigentlich noch krasser als die puren Zahlen es erscheinen lassen. Es ist Fakt, das h265 zumindest auf der von mir verwendeten Hardware (die aber allgemein recht gängig ist) besser läuft.

    Diese AMLogic SoC sind sehr verbreitet für Kodi Maschinen. Andere ARM Systeme (RasPi und Co) sind auch nicht wesentlich leistungsfähiger. Auf meinem Intel Pentium Gold System macht hingegen auch das größte h264 Test- Video (250 MBit) keine Probleme.

    Im Alltag wird das allerdings keine so große Rolle spielen, weil schon 250 MBit weit jenseits von gut und böse sind, von 400 MBit ganz zu schweigen. 4K BluRay haben weit weniger Bitrate (deutlich unter 100 MBit). Videos mit so hohen Bitraten machen auf normaler Hardware, wie man sie im allgemeinen zu Hause stehen hat, überhaupt keinen Sinn und sind einfach nur eine große Platz- und Ressourcen- Verschwendung. Auf jeden Fall laufen h265 Videos auf Hardware, die h265 unterstützt, besser als h264 Videos, auch wenn h264 ebenfalls von der Hardware unterstützt wird. Hat man schwächere Systeme wird der Vorteil von h265 noch mal größer. Als ich mich entschieden habe, alles nach h265 zu kodieren, hatte ich eine S905x2 Box. Die fing schon eher an, bei h264 zu stottern. Bei "alten" Codecs wie etwa Mpeg2 oder DivX, die von neuerer Hardware nicht mehr unterstützt werden, bricht die Widergabe schon bei normalem HD ein. Die muss man auf jeden Fall umkodieren, keine Frage.

    -------------------------------------
    Danke fürs lesen, Claus

  • Hi,

    ich nutze ebenfalls zum umkodieren auf meinem Server ffmpeg, leider bin ich dan ent so firm drin.... aber wie bewege ich meine GPU auf meinem Server zum umkodieren mittels ffmpeg.

    Das ist mein Parameter:

    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
  • Wenn du libx265 als Codec verwendest, hast du nie GPU Kodierung. Libx265 ist nun mal der Software Codec. Um die GPU zu verwenden muss dann "hevc_qsv" für Intel QuickSync (oder entsprechend die Passenden für NVida bzw AMD) als Codec ausgewählt werden. -x265-params kann man dabei nicht verwenden. Das würde zu einer Fehlermeldung führen. Das ist nur für x265 verwendbar. Bei QSV setze ich stattdessen die Qualität mit -q:v 22 (man kann auch kleinere oder größere Werte für die Qualität auswählen. Kleinerer Wert heißt größere Datei und eventuell bessere Qualität. größere Zahl heißt kleinere Datei und eventuell schlechtere Qualität. Erlaubt sind Werte zwischen 1 und 51. Sinnvoll sind diese Extreme aber nicht. Je nach eigenen Ansprüchen kann man im Bereich von ca 18 bis 26 testen. Drüber oder drunter wird es sehr schnell viel zu groß oder viel zu schlecht...

    Hier mal eine Befehlszeile aus meinem letzten Media-Buddy Logfile, so wie Media-Buddy dann nach meinen Einstellungen ffmpeg verwendet:

    Code
    ffmpeg -y -i "D:\Media-Buddy_Arbeit\Eingang\Serien\SOKO Potsdam\S06E02 - Brieselanger Licht.mp4" -scodec copy -map 0:0 -c:v hevc_qsv -q:v 22 -map 0:1 -c:a aac -ar 48000 -af dynaudnorm=p=0.95:f=500:m=10:s=15:g=11:r=0.95:b=false -c:s copy -max_muxing_queue_size 10000 "D:\Media-Buddy_Arbeit\Ausgang\Serien\SOKO Potsdam\S06E02 - Brieselanger Licht.mkv"

    Dabei wird der Ton gleich normalisiert (auf 0,95) und mit einer mittleren Dynamik- Kompression versehen. Wenn man das nicht will, muss man den Ton meist gar nicht umwandeln und könnte ihn per -c:a copy einfach kopieren statt mit -c;a aac neu zu kodieren.

    Untertitel werden per -c:s copy unverändert belassen, aber nicht per -map:... gemappt, weil in dem Video aus der ZDF Mediathek keine Untertitel vorhanden sind und ich deswegen auch keine Untertitel Spuren ausmappen kann. In aller Regel fliegen Untertitel bei mir nämlich komplett raus, sofern es keine "Forced" auf Deutsch sind. Die und nur die würden dann auch per -map:... übernommen werden. Bei manchen Untertiteln gibt es beim Kopieren Probleme, die man durch das -max_muxing_queue_size 10000 verhindern kann. Oft ist das nicht nötig, aber ich habe noch nichts Nachteiliges an dem Parameter entdecken können. Die "-map x:x" Parameter müssen nicht sein, wenn man immer alle Spuren behalten will. Will ich aber nicht, weswegen Media-Buddy hier per -map... die Spuren auswählt, die ich behalten will.

    Die "" um die Dateinamen sind nur dann nicht zwingend notwendig, wenn der Pfad keine Leerstellen enthält. Das kann man aber bei einer automatisierten Verarbeitung nicht verhindern, also besser mit ""...

    Es ist allerdings "nur" eine 1-Pass Kodierung. Der maximal höhere Aufwand für das minimal bessere Ergebnis, das dabei herum kommt, ist definitiv nichts für mich.

    -------------------------------------
    Danke fürs lesen, Claus

  • 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.

    -------------------------------------
    Danke fürs lesen, Claus

  • Der Encoder für H.265 und nVidia GPU sollte der nvenc_h265 sein. Du musst also libx265 gegen nvenc_h265 austauschen. Allerdings würde ich mit der Bitrate nach oben gehen, die 2900k bei nvenc werden da wohl nicht reichen. Die Hardwareencoder brauchen i.d.R. mehr Bitrate, schätzungsweise das Doppelte als bei Softwareencodierung.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960

    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

  • Ok, dann unterscheiden sich wohl ffmpeg und handbrake in der Benennung. Bei Handbrake ist es nvenc_h265.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960

    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

Jetzt mitmachen!

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