1. Cookies optimieren die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklärst Du dich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen
    Information ausblenden
  2. Willkommen im Forum von DIGITAL FERNSEHEN - dem führenden Portal für digitales Fernsehen, Medien und Entertainment. Wenn du hier neu bist, schau dich ruhig etwas um und melde dich an, um am Forengeschehen teilnehmen zu können.
    Information ausblenden

Codec Wandlung nach Hevc

Dieses Thema im Forum "Computer & Co." wurde erstellt von Quehl, 21. Juli 2019.

Schlagworte:
  1. Quehl

    Quehl Senior Member

    Registriert seit:
    25. Mai 2001
    Beiträge:
    372
    Zustimmungen:
    9
    Punkte für Erfolge:
    28
    Anzeige
    danke.

    ich hatte doch den NCH 7z installiert, weil ich nichts anderes gefunden hatte. Installation von StaxRip habe ich dann ohne Aktualisierung der Systemdateien installiert. Die Bedienung erscheint mir etwas kompliziert. Wenn ich den Intel Hardware decoder - encoder ausgewählt habe und auch die Qualität, dann funktioniert erstmal nichts. Avisynth installiert und wieder nichts. Nächste Datei installiert und weiß nicht, ob ich noch alles installieren muß. Die Timerfunktion wäre ja auch sinnvoll. Das ist in Handbrake alles automatisch drin. Einlesefunktion auf OK geklickt und nächstes Mal waren diese Dateien nicht mehr da. Auch die Qualität ging wieder auf Standard zurück. Das Zielverzeichnis war auch nicht einfach zu wählen. Da sind andere Programme besser. Viele Einstellungen habe ich nicht verstanden.
     
  2. DVB-T2 HD

    DVB-T2 HD Foren-Gott

    Registriert seit:
    7. Mai 2016
    Beiträge:
    10.874
    Zustimmungen:
    4.621
    Punkte für Erfolge:
    213
    Das ist dein grundsätzliches Problem, egal bei welchem Transcoding-Programm. Gute Qualität nach dem Transcodieren bekommt man nur, wenn man den Vorgang versteht und auch etwas Erfahrung hat. Automatisch kann da bei den verschiedensten Ausgangsmaterialien gar nichts ablaufen, wenn ein brauchbares Ergebnis erzielt werden soll. Insbesondere müssen auch die Zielvorstellungen realistisch sein, da es ein verlustbehaftetes Transcodieren ist.
     
  3. simonsagt

    simonsagt Board Ikone

    Registriert seit:
    11. April 2014
    Beiträge:
    3.563
    Zustimmungen:
    1.410
    Punkte für Erfolge:
    163
    Mal sehen. Ist ne Weile her. Daher gönne ich mir den Spaß, damit ich auch wieder weiß, wovon ich rede. :p

    Die .rar von der offiziellen Seite geladen.

    StaxRip gestartet.

    dot net von Microsoft nachinstalliert

    Neustart verflucht. Nicht neu gestaret. Begriffen, dass die Versionsnummern nicht die von Stax sind sondern von .net. Ältere .net von Stax gestartet, weil die installiert ist und ich so nicht neu starten muss.

    Drama um Configdatei, weil ich mehrere Versionen von Stax auf dem Rechner habe. Egal. Gestartet.

    Ne kurze Probeaufnahme gemacht.

    Mit Drag&Drop auf Stax geworfen.

    Festgestellt, dass ich avisynth plus 64 bit brauche ... und das meine installation - einfach entpacken - die pfade zu den tools versaut hat und ich die wohl nachtragen muss. Hmm. Nope. Muss einfach nur die .exe von Staxrip einen Pfad nach oben schieben. Yep, Installer wäre übersichtlicher gewesen.

    Nochmal Probeaufnahme auf Staxrip geworfen, nachdem Stax mir Avisynth nachinstalliert hat.

    Viele neue Knöpfe die ich noch nicht kannte. Hmm. Ahja. x265 voreingestellt. Hmm. Ahja, unter Coder sind die Hardwarecoder für die Prozessoren. Ich hab nen AMD. Mal den x265 AMD auswählen. Die Optionen für x265 sagen mir nichts, da müsste ich einen Guide für lesen. Also lasse ich sie so.

    Fehler im Hardware Video Encoder. Oh. Äh. Ok. Vielleicht doch neu starten und anderes .net nehmen.? Keine Ahnung. Der Hardwareencoder ist jedenfalls kein offizielles Produkt weder von AMD noch von den Leuten die x265 programmier haben.

    Also auf zum Softwareencoder. Oh. Siehe da. Die gewohnten Presets mit der Geschwindigkeit sind wieder da. Die gab es für den HW nicht. Auch der Tune Preset ist da. Wenn das alles fehlt bei dem HW, wer weiß, wie es da um andere Qualitätssachen bestellt ist. Egal, später.

    10 fps in Medium. Naaaja. Ich hab nen Ryzen 7 2700. Nicht unbedingt berauschend. Gut dass das Testfile nur 93MB war. Hmm. Laut Taskmanager nur 30% Rechenleistung obwohl laut logfile für 16 Threads gestartet wurde. Naja. Flaschenhals ist wohl woanders. Die "Hardwarebeschleunigung" die verwendet wird, sind nun MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2. Keine Ahnung, was die AMD-Hardwarebeschleunigung des anderen Encoders benutzen hätte wollen.

    3 Minuten SD .ts von 93MB in 475MB verwandelt. WTF. Mit VLC nochmal Codec im Endprodukt geprüft. Angeblich h265. Hmm. Oooookay, vielleicht doch von 2pass mit Zielbitrate auf 1pass mit crf 20 stellen. :whistle:. Also nochmal.

    Und schon sind es 50 fps bei immer noch nur 30% CPU Last. Der Coder hat sich ja vorher echt angestrengt, um die Bitrate künstlich aufzublähen.

    Aus 93MB sind so nun 34MB geworden. Seh ich nen Unterschied? Keine Ahnung.

    Aber ich hab da noch einen Encoder für meine schwachbrüstige Nvidia gesehen... da könnte ich zwar mehr Einstellungen durchreichen als für den AMD HW, aber der geht bei mir genausowenig. Ist schon älter die Nvidia-Karte. Keine Ahnung.

    Na dann mal zum Vergleich mit x264 rumspielen.

    crf 20 medium. 250 fps bei 70% CPU Last. Ergebnis 37 MB. Seh ich nen Unterscheid? Keine Ahnung. Die crf Werte werden hoffentlich eine ähnliche Bedeutung haben, da x264 und x265 ähnliche Wurzeln haben, also vom technischen her, sollte das Ergebnis optisch ählich sein in der Qualität.

    crf 20 very slow, tune film. 35 fps bei 60% CPU Last. Also mehr Rechenleistung als oben der x265. Ergebnis 38 MB. Aus technischer Sicht müsste die Qualität besser sein als das crf 20 medium, obwohl gleiche Größe. Wieviel da optisch zu sehen ist, keine Ahnung. Und ob es nun besser als das x265 crf 20 medium ist? Noch weniger Ahnung. Aber es ist etwa 10% größer und es wurde mehr Rechenleistung hineingesteckt und h265 soll erst ab FullHD so richtig gut werden und das war SD... also vermutlich wäre es besser.

    Die Standardeinstellung von x265 scheinen 28 crf gewesen zu sein. Mal den noch probieren.

    crf 28 medium, kein tune, x265. 90 fps bei 30% CPU. 16 MB.

    crf 28 medium, kein tune, x264, 330 fps bei 60% CPU. 19 MB

    Seh ich bei crf 28 nen Unterschied? Oh ja. Bei beiden. Welche der schlechtere unter den schlechten ist? Jammern auf niedrigem Niveau. Ist beides erkennbar schlechter als das Original mpeg2.

    --

    Fazits:


    Also die Bedienung von StaxRip, nunja, man muss die Tools unten drunter und was man macht schon etwas verstehen. Ist nur ne GUI. Wenn dir das von Handbrake besser gefällt, nimmt Handbrake. Dass da der gleiche x264 werkelt wie in StaxRip, das weiß ich. Bei den HW, keine Ahung. Bei Staxrip musst du dir Presets für bestimmte Formate machen, also was du haben willst, damit du dann ähnliches wieder so coden kannst. Beispielsweise für eine Serie. Oder bestimmtes Quellmaterial.

    --

    Hardwarecodierung scheint noch nicht so ausgereift zu sein. Bei ner starken Grafikkarte hat man bestimmt Vorteile. Aber "Software" auf Intel vs. "Hardware" auf Intel??? Oder soll da noch bisschen die Grafikeinheit dazu genommen werden oder sowas? Die Coder sind normal schon hochoptimiert für die CPU, mit diesen Befehlssatzerweiterungen, da noch eine sog. Hardwareunterstützung dazu zu nehmen, ich verstehe nicht ganz, wie das funktionieren soll.

    --

    x264 vs x265

    Die Marketing-Mogelpackung besteht darin, x265 für hohe Auflösungen auszuweisen, wo man kleine Artefakte nicht so gut sehen kann und gleichzeitig die Standardeinstellung von 20 auf 28 zu heben. Das alleine macht bereits bei x264 eine grobe Halbierung. Es ist eben gerade nicht so, dass 28 bei x265 genauso aussieht wie 20 bei x264.

    Also nicht falsch verstehen, h265 ist schon "besser", aber das erkauft man auch mit mehr Rechenleistung bei Coden und vor allem beim Decoden. Aber die grob 10% weniger Platz bei dreimal mehr Zeit zum coden sind halt nicht die versprochenen 50% Platzersparnis. Und mit crf 28 sollte man SD nicht anfassen, da braucht man hohe Auflösungen, damit die Stärken von h265 zum Tragen kommen und man Artefakte nicht so sehr sieht (ist das gleiche bei hoher Framerate. Je mehr, desto eher kommt man mit geringer Qualität unbemerkt davon).

    Zumindest bei meiner CPU bringt x264 die Rechenleistung auch auf die Kerne, im Gegensatz zu x265. Fand ich seltsam.

    --

    tl;dr Man sollte wissen was man tut, bevor man seine Originalaufnahmen zerstört um Platz zu sparen. Mit GUIs wie Handbrake oder StaxRip kann man die verschiedenen Coder für den eigenen Bedarf durchprobieren. Coden ist keine analoge Umwandlung von einem Format zum anderen, es kommt auf sehr viele Faktoren an. Einfach blind in hevc umwandeln, weil das beworben wird mit 50% kleiner als avc, wird in die Hose gehen.

    Zu Hardwareencodern kenne ich mich kaum aus, aber was ich so mitbekommen habe, die sind nicht für Qualität gedacht, sondern für Echtzeit, wenn man eine schwache CPU hat. Für die Umwandlung seiner Mediensammlung also denkbar schlecht geeignet.
     
  4. Quehl

    Quehl Senior Member

    Registriert seit:
    25. Mai 2001
    Beiträge:
    372
    Zustimmungen:
    9
    Punkte für Erfolge:
    28
    danke,

    da bin ich wenigstens nicht der Einzige, der mit StaxRip Probleme hat.

    Gut bei StaxRip finde ich, dass die Dateien eines Ordners als Batch transcodiert werden können. Bei Handbrake können zwar alle Dateien eingelesen werden, diese müssen dann aber einzeln in eine Warteschlange übertragen werden. Das ist dann nicht so gut, weil ich für das Übertragen länger brauche.
    Handbrake hat die 10 bit h265 Hardwarecodierung. StaxRip offenbar nicht, habe ich zumindest nicht gesehen.

    Ein größerer Zeitaufwand bei der Decodierung von H.265 sehe ich nicht mehr als Problem. Bei der Hardwaredecodierung funktioniert das einfach. (mit VLC ab Vers. 3.0). Bei meinem alten Netbook ging das nur in Zeitlupe bei Softwaredecodierung. Etwas Probleme werden die alten Fernseher machen, die keinen Hevc Decoder haben, aber einen HDMI Anschluß. Da könnte man die Videos nur mit meinem Notebook abspielen oder mit Receivern. Da wäre H.264 universeller verwendbar.
    Das werde ich noch testen, ob aus dieser Sicht H.265 noch sinnvoll ist.

    Danke an die Erinnerung an den Taskmanager. Das muß ich mir noch ansehen. Die Transcodierung soll ja bei Intel hintereinander erfolgen, d.h. ohne Interaktion der CPU. Daher müßten mögliche Einstellungen vor der Transcodierung erfolgen. Bei StaxRip kann ich nicht erkennen, welche Einstellungen hardwarerelevant sind. Ebenso auch bei Handbreake, da gibt es aber weniger Einstellungen.

    In einem anderen Umwandlungsprogramm gibt es so gut wie keine Einstellungen. Und nur Softwareencodierung. Geschwindigkeit 3-5 Frames/sec. Da macht sich der jetzige Test mit ca. 60-70 Frames/sec. bei bester Qualität ganz gut.
     
  5. simonsagt

    simonsagt Board Ikone

    Registriert seit:
    11. April 2014
    Beiträge:
    3.563
    Zustimmungen:
    1.410
    Punkte für Erfolge:
    163
    Überbewerte das nicht. Tatsächlich würde ich jetzt nicht behaupten, dass es bei mir Probleme gab. Ich hab ein .rar einer Betaversion entpackt. Das kann man nicht mit einem Installer vergleichen. Und als die Pfade stimmten, hatte Stax sogar den Knopf, um Avisynth in der benötiten Version nachzuinstallieren.

    Was du halt mit StaxRip (und auch mit Handbrake) machst, du sammelst dir die Optionen zusammen, die dann zum eigentlichen Programm weiter gereicht werden. Ich glaube Handbrake bindet das als Bibliothek ein und nicht als .exe. Guis sind halt übersichtlicher, als selber auf der Kommandozeile zu hantieren. Aber unten drunter werkeln hauptsächlich die gleichen kostenlosen Tools und gerade mit Avisynth kann man jede Menge Unsinn anstellen.

    Mittlerweile wieß ich auch, warum die Hardwareencoder bei mir nicht funktionieren. Meine CPU hat sowas nicht (nicht dass ich wüsste) und meine Grafikkarte ebenfalls nicht.

    Was auch immer das ist. Musst halt rausfinden, welches Projekt die da eingebunden haben. Der Intelcoder und der Intelcoder in ffmpeg hat diese Option in StaxRip nicht zum Auswählen. x265 kann 8 10 und 12 Bit.

    hevc scheint problematisch in der Lizensierung. Darum auch die schleppende Unterstützung auf Hardware. Die Codierung ist natürlich gewollt, dass die verfügbar ist. Die Decodierungsfähigkeit auf bestimmten Geräten aber muss offenbar gegen Geld erkauft werden.

    Und nachdem ich mich nun endlich eingelesen habe, Ja, seit einigen Jahren packen die da eine Recheneinheit drauf, die nix kann, außer Videobeschleunigung. Die soll vergleichbare Ergebnisse wie das preset superfast bei den x26x Codern bringen. Nur, auf superfast willst du deine Medienbibliothek eventuell nicht codieren.

    Mit superfast bei x265 hab ich bei crf 28 und meinem Testfile von oben 250 fps, statt die 90 bei medium. Und bei crf 20 waren es immerhin 190 fps statt 50. Das File ist sogar kleiner geworden, 26 statt 34MB. Aber für Qualtiät spricht das nicht.

    Will sagen, du musst auch den x265 mit superfast starten, wenn du da mit der Hardwarecodierung vergleichen willst. Auch solltest du prüfen, ob deine Grafikkarte auch ne HW-Beschleunigung hat, und wie die sich da ggf. eingliedert.

    Wie gesagt, du solltest den x265 mit superfast einstellen, wenn du ihn gegen Hardware antreten lässt.

    Das eigentliche Umwandlungsprogramm ist x265, ffmpeg oder der Hardwareencoder. Der Hardwareencoder ist eher eingeschränkt in der Auswahl was man machen kann, da kann ich nciht viel zu sagen. Bei x264/5 nimmst du normalerweise entweder 1 pass mit Qualität nach Wahl, womit man halt leben kann, Größe vs Geschwindigkeit vs Qualitätsverlust (und das musst du immer berücksichtigen: jede Umcodierung kostet Qualität) oder 2 pass mit willkürlicher Zielgröße. Mit 2pass wird das Optimum an variabler Bitrate erreicht. Und dann braucht es noch zwei Presets: einer für das Quellmaterial, da sollte man sich einlesen was wofür ist, es gibt jetzt mehr als früher. Und einer für die Geschwindigkeit, das ist dieses medium oder superfast.

    Bahnhof?

    Dein Hardwarecoder, was auch immer da in Handbrake eingebunden und angesprochen wird, ist ein komplett anderes Programm, als der x265 (und sowohl Stax als auch Handbrake verwenden den für "Software"-Coding ). h265 ist der Standard, welcher auch hevc genannt wird. Das ist nur eine Beschreibung, wie so ein File aussehen kann, wenn es fertig wäre. Oder noch nichtmal das. Es muss ja noch in einen Container wie etwa mkv gepackt werden. Egal. Jedenfalls, die Berechnungen, wie man so ein File erzeugt sind das was der Coder macht. Und das ist kein eindeutiger Vorgang (auch das decoden ist nicht eindeutig). Daher gibt es so gewaltige Unterschiede, was Qualität und Geschwindigkeit angeht. Für Normalsterbliche gibt es dafür diese Presets, damit man sich nicht viel drum kümmern muss. Der wichtigste ist der tune für das Quellmaterial. Für die Hardware relevant ist nur die Compilierung des Coders, damit auch die Befehlssätze der verwendeten CPU angesprochen werden können und man nciht wirklich "Software"-Encodieren muss.

    Du hast eine i5 7200. Keine Ahnung wo da die Flaschenhälse sind und wie die sich gegen ihre eigene Videobeschleunigereinheit schlägt. Für halbwegs faire Verhältnisse musst du aber sehr wahrscheinlich bei x265 auf den preset superfast wechseln. Und du solltest unbedingt ein paar gute Testfiles ausprobieren, wo du auch Artefakte erkennen würdest. Nebel ist immer gut. Schnelle Kopfbewegungen sind mir bei meinem Test aufgefallen. Die sahen bei crf 28 x265 nicht gut aus im Vergleich zum Original. Und dann müsstest du noch rumprobieren, mit welchen Qualitätseinstellungen du leben kannst. Für SD ist die Voreinstellung von crf 28 von x265 jedenfalls zu hoch (hoch ist weniger Qualität). Falls du mit x264 oder x265 codest, solltes du dich auch einlesen, welches tune-preset für was gut ist. Zu wissen was man codet, hilft dem Coder enorm.
     
  6. simonsagt

    simonsagt Board Ikone

    Registriert seit:
    11. April 2014
    Beiträge:
    3.563
    Zustimmungen:
    1.410
    Punkte für Erfolge:
    163
    Und um darauf nochmal zu antworten:

    Ich habe im Zuge dieses Threads gelernt: nope. "Hardware"-Umwandlung ist tendentziell schlechter als die "schlecht"-Einstellung der "Software"-Umwandler. Für x264 superfast und diese Intel-Umwandlung hab ich mir ein YT-Video angekuckt von einem der wohl Livestreams macht. Da waren in der Hardwareumwandlung mehr Schwächen, als in der superfast-Software-Umwandlung. Aber das war x264 und schon paar Jahre her, also vielleicht es ja besser geworden. Allerdings bezweifle ich das, du hast dich ja auch über die Qualität beschwert ;).
     
  7. Quehl

    Quehl Senior Member

    Registriert seit:
    25. Mai 2001
    Beiträge:
    372
    Zustimmungen:
    9
    Punkte für Erfolge:
    28
    Ich hatte anfangs nur 3 Testdateien verwendet, ohne zu wissen, was ich einstellen muß. Ich wußte nicht, dass in der Hardware die verschiedenen Qualitäten vorhanden sind. Insofern sollte mein Anfangsposting nicht so genau interpretiert werden. Ich habe von Handbrake jetzt eine Bedienungsanleitung gefunden, wo doch noch einiges zu erfahren ist.

    Ich habe jetzt weitere Tests gemacht:
    Handbrake, Datei wie vorher, 6 GB
    Einstellungen: super HQ (beste Qualität), x264 versehentlich,
    Ergebnis: 12 Std. Rechenzeit, abgebrochen. hohe CPU Last
    h.264 Hardwarecodierung, 1 Std. Rechenzeit, 4 GB, Qualität ok. Bemerkenswert ist die verringerte Größe, obwohl Ergebnis das Gleiche ist wie die Quelle.
    h.265 Hardwarecodierung, 1 Std. Rechenzeit, 1,8 GB, Qualität ok. Die Einstellungen waren die gleichen wie bei h.264. Qualitätsregler stand auf 18 und habe ich belassen.
    Der unterschied zu meinem vorherigen Test mit 1 GB Ergebnis war, dass dort der Qualitätsregler auf 22 stand, aber Qualität auch ok war.
    Bemerkenswert die gleiche Rechenzeit bei h.264 und h.265.
    Die CPU Last war zwar bei h.265 etwas geringer als bei h.264, aber doch deutlich höher als ich gedacht habe. Der CPU Takt lag deutlich niedriger als der Nenntakt.

    Seltsam fand ich, dass Handbrake von Anfang an irgendwie funktioniert hatte und bei StaxRip mußte ich das gleiche Programm nachinstallieren, obwohl Handbrake früher da war.
     
  8. simonsagt

    simonsagt Board Ikone

    Registriert seit:
    11. April 2014
    Beiträge:
    3.563
    Zustimmungen:
    1.410
    Punkte für Erfolge:
    163
    Avisynth? Das müsste es in bis zu vier oder noch mehr Varianten geben. Andere Versionsnummer und 32/64 Bit. Ist zwar nicht exakt das gleiche, aber das .net von Microsoft gibt es auch in mehreren Varianten, die nebeneinander installiert sein können.

    Das ist so ne Sache, wenn so eine GUI Configoptionen selbst erfindet.

    Auf der einen Seite könnte man dann mehrere verschiedene Coder unten drunter haben und jeweils das selbst Erfundene "Super HQ" auf das abbilden, was der jeweilige Coder tatsächlich kann. Auf der anderen Seite aber, ist das total undurchsichtig, was da tatsäschlich wie abgebildet wird und sich dann nur schwer vergleichen läßt.

    Ein Super HQ bei x264 wäre mir nicht bekannt. Wie will man das dann objektiv mit einem anderne Coder, besonders einem Hardwarecoder, vergleichen? Oder wenn man eine andere Gui verwendet und den gleichen Coder.

    Und bei x264/5 gibt es mehrere Qualitätsregler. Den Quantitizer (qp) und "Quality" (crf - constant rate factor). Was genau verschiebst du mit dem Regler in Handbrake?

    Das letzte mal, als ich Guides dazu gelesen habe, wurde für 1 pass der crf empfohlen. Man sagt meinetwegen 25. Beim Berechnen wird dann ein tatsächlicher Qualitätsmaßstab von 20 bis 30 verwendet und zwar je nachdem, wie komplex der Inhalt gerade ist.

    Dieser Faktor ist der wichtigste Regler zum Einstellen der Zielgröße, wenn du keine fixe Wunschzielgröße hast. Die Standardeinstellun von x265 ist 28 und von x264 ist 20, was ich ja weiter oben bemängelt habe, denn alleine dadurch kommt schon ein riesiger Größenunterschied zustande. Hast ja bei dir auch gesehen mit 18 und 22.

    Und vergiss die Presets nicht. Das ist dann eher, welche Möglichkeiten der Coder wie ausschöpfen soll, damit man da nicht jeden Regler selber anfassen muss. Gewissermaßen, wie schlampig oder genau gerechnet werden soll. Der Hardwarecoder soll ja offenbar eher auf der schlampigen Seite der Skala ansetzen, im Vergleich zur Softwarecodierung. Du könntest dann zwar zum Ausgleich einen höheren Qualitätsfaktor ansetzten, aber wozu? Das Ziel ist doch Größe einsparen bei möglichst wenig Verlust der Qualität. Wenn dir natürlich ein Daumenkino mit Tonspur aussreicht, keine Hemmungen. Setz mal 35 und ultrafast mit x265 an. Meine 95MB schrumpfen da zu 13 zusammen und 10 davon sind die Tonspuren. Mit medium dauert es zwar doppelt so lange und es ist 14,5 MB groß, aber es ist um Welten besser anschaubar. Ist zwar immer noch schlecht, aber viel besser als ultrafast.
     
  9. simonsagt

    simonsagt Board Ikone

    Registriert seit:
    11. April 2014
    Beiträge:
    3.563
    Zustimmungen:
    1.410
    Punkte für Erfolge:
    163
    Vielleicht sollte ich es nochmal deutlich sagen: du willst nicht handbrake oder staxrip benutzen, du willst x265 oder x264 oder ,wie auch immer das ding für deine Recheneinheit auf dem Intel-Chip heißt, benutzen. Mit welcher grafischen Oberfläche du diese Programme ansteuerst, ist Jacke wie Hose. Allerdings ist halt der Komfort oder die Übersichtlichkeit, was du da eigentlich tust, auch wichtig. Was du im Moment am entscheiden bist, ist offenbar, welcher Coder dir taugt und wie du ihn ansteuern musst. Da wäre ich sehr vorsichtig, da diese Optionen nur schwierig von Coder zu Coder übertragbar sind. Was ich halt gelesen hatte, was dieser Intelchip fabriziert, wäre angeblich in etwa mit dem preset superfast bei x264 vergleichbar, was die Qualität betrifft - und je nachdem welche Ansprüche du an deine Mediensammlung stellst, ist das vielleicht nicht, was du haben willst. Laut subjektivem Testvideo war es sogar merkbar schlechter als superfast. Im ungünstigsten Fall müsstest du den crf so hoch drehen bei Hardware um die Qualität zu halten, dass das neue File gar nicht kleiner wird und sich aber trotzdem verschlechtert.
     
  10. Quehl

    Quehl Senior Member

    Registriert seit:
    25. Mai 2001
    Beiträge:
    372
    Zustimmungen:
    9
    Punkte für Erfolge:
    28
    danke,

    ich hab mal das so getestet, wie Du gesagt hast.
    x264 superfast (ist Software encoder).
    Ergebnis: 1 GB, Laufzeit 3/4 Std. Ergebnis ok. CPU alle CPU Threads zu 100% mit 3 Ghz ausgelastet. Bei Hardware encodierung waren es 2 Ghz, aber stärker schwankend als bei Software.

    Wie ich das jetzt beurteile, weiß ich noch nicht. Werde wohl noch mehr testen müssen.