[Render-Test] Sony AVC vs. Handbrake vs. MeGUI

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • [Render-Test] Sony AVC vs. Handbrake vs. MeGUI

    Anzeige
    Ich habe das Problem, dass Maestrocools Methode des Renderns bei mir nichts zu bringen scheint.
    Das heißt: Meine Dateien werden immernoch so groß wie bei dem Sony AVC von Sony Vegas, den ich davor benutzt habe.

    Also habe ich mich mal hingesetzt und die beiden Rendermethoden auf Renderzeiten und Größen geprüft.
    Hier mein Ergebnis:
    Render Test:

    Spiel: Counter-Strike: Source
    Länge der Aufnahme: 14:07Min
    Auflösung: 1280x720p@25fps
    Anmerkung: Es hat etwas gelagt, da ich die Einstellungen von Css nicht an die Aufnahme angepasst habe

    Fraps:
    Dateigröße: (3x3.95GB+2,86GB)

    Sony AVC:
    Renderzeit: 49:42 Min
    Größe: 821 MB
    Anmerkung: ca. 1 min des Videos ist Blackscreen (DANKE VEGAS). Also muss man noch ein paar MB draufrechnen.

    Handbrake:

    Rendern in Vegas
    Renderzeit: 22:03 Min (hier war die Anzeige etwas verbugt, denn Vegas hat mir gesagt, dass es etwa 40 Min dauern würde). Daher könnte es sein, dass mit der Datei etwas nicht stimmt.
    Größe: 8,69GB
    Anmerkung: Entweder habe ich vergessen einen anderen Titel einzugeben, oder Vegas hat meinen Titel nicht übernommen.

    Schrumpfen in Handbrake:
    Zeit: ca. 17 Min
    Größe: 904 MB
    Anmerkung: Das ist das erste Programm, das ich sehe, das meine CPU zu 100% ausnutzt, daher: Überhitzungsgefahr.

    Kopfdatenkompressionsausschaltung in Mkvmerge GUI
    Zeit: 30 sek (kam mir kürzer vor)
    Größe: 903MB


    Und hier sind nochmal zwei Bilder der jeweiligen Ergebnisse: (ich hoffe die Bilder sind nicht zu groß)
    Handbrake-Methode: click
    Sony AVC: click

    Den einzigen Unterschied, den ich erkennen kann ist, dass die Handbrake-Variante heller ist.


    Fazit:
    Bei insgesamt etwas kürzerer Renderzeit, aber dafür sehr viel Programmgewechsle, spuckt die Handbrake-Methode etwa gleichgroße und gleichqualitative Videos aus wie der Sony AVC, bei dem man sich aber entspannt zurücklehnen kann und nichts unter dem Rendern machen muss.
    Bei beiden Methoden ist mir jedoch die Dateigröße etwas zu groß, denn ich habe von anderen für gleich lange und qualitative Videos Werte im Bereich von 200-400MB gehört.
    Wenn ich also keine Verbesserung für die Handbrake-Variante finde, werde ich wahrscheinlich bei dem Sony AVC bleiben, da ich da auf Start drücken und dann etwas anderes tun kann, und nicht alle 20 Min das Programm wechseln muss.

    Aufgenommen wird mit Fraps@Full-size, lock 25fps, kein rbg
    Gerendert wird mit Sony vegas Movie Studio HD Platinum
    Mein Prozessor, ist ein Intel Core2 Quad CPU Q8200 @2,33GHz

    Wer Rechtschreib/Grammatikfehler findet darf sie behalten

    mfg Nightysin

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Nightysin ()

  • RE: [Render-Test] Sony AVC vs. x264vfw+Handbrake+mkvmerge GUI

    Nightysin schrieb:

    Den einzigen Unterschied, den ich erkennen kann ist, dass die Handbrake-Variante heller ist.


    Das hab ich auchschon bemerkt, aber das kleine Detail wird mich bestimmt nicht dazu bringen, mir den Stress mit Handbrake anzutun.
    D.H:
    -Beim Rendern auf x264vfw nicht zu wissen, wann er fertig ist, weil die Anzeige verbugt ist
    -Bein encodieren mit Handbrake Angst zu haben, dass mein PC überhitzt.
    -Immer vor dem Pc sitzen zu müssen, da ich alle Paar Minuten das Programm wechseln muss.

    mfg Nightysin

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Nightysin ()

  • Ein Vorteil den du vergessen hast (ausser das das Handbrakevideo nicht zu dunkel ist, weil bei Sony standardmäßig der falsche Helligkeitsmodus drin ist)
    Du kannst doch den CRF ändern, damit die Dateien noch kleiner werden, bis 25 geht alles, du musst nur ausprobieren wie weit du gehen kannst, bzw wie weit es für dich in Ordnung ist, diesen CRF merkst du dir und stellst du bei jedem Video genauso ein.
    wenn du den für dich passenden CRF Wert erst einmal gefunden hast, brauchst du ihn nie wieder zu ändern, denn der CRF sorgt dafür, das jedes Video absolut die gleiche Qualität hat.
    Der Sony AVC dagegen arbeitet mit einer Festen Bitrate, das heißt wenn es bei Minecraft gut aussieht, dann kann es trotzdem in Crysis schlecht und verpixelt aussehen, das kann bei Handbrakes CRF nicht passieren !

    wenn dir die Überhitzungsgefahr und das Handling nicht gefällt, dann benutze Sonys AVC, ich habe kein Problem damit
    Was mich aber Freut, das du doch einen (oder anderen) Unterschied, beim Ergebnis der Videodateien, und Renderzeiten, gefunden hast.

    Es gibt hier Leute, die sich sogar noch mehr Arbeit aufhalsen und mit MeGui Rendern, nur damit die Zuschauer auch beste Qualität bekommen, also was bist du für einer ?
    Qualität und kleine Dateiund mehr Arbeit (x264) ? oder
    weniger Qualität und viel kleinere Datei und mehr Arbeit (x264) ? oder
    wenig Arbeit und weniger Qualität und dafür größere Datei aber keine Überhitzungsgefahr (Sony AVC) ?
    deine Entscheidung

    Nightysin schrieb:

    -Beim Rendern auf x264vfw nicht zu wissen, wann er fertig ist, weil die Anzeige verbugt ist (die Anzeige ist nicht verbuggt, sie ist dynamisch und passt sich dem Videomaterial an)
    -Bein encodieren mit Handbrake Angst zu haben, dass mein PC überhitzt. (dafür kann doch Handbrake nichts, wenn dein PC bzw dein Prozessor keinen ausreichenden CPU-Kühler bekommen hat, dafür ist eher der Hersteller des PCs verantwortlich)
    -Immer vor dem Pc sitzen zu müssen, da ich alle Paar Minuten das Programm wechseln muss. (WTF du musst doch auch vor dem PC sitzen um Aufzunehmen, und du musst nicht am PC sitzen bleiben, denn die Programme brauchen in der Regel immer ähnlich viel Zeit)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von maestrocool ()

  • Anzeige
    Soooo meine Freunde ich habe mich nun auchnoch hingesetzt, um das ganze nochmal mit MeGUI zu testen.
    Mein Ergebnis
    MeGUI:

    Rendern in Vegas:
    Renderzeit: 17:35 Min
    Größe: 18,6 GB

    Encodieren in MeGUI:
    Renderzeit: Video: ca. 20:30, Audio: zu schnell zum messen ^^
    Größe: Video: 922 MB, Audio: 45,2MB
    Anmerkung: schonwieder eine CPU – H*re. Überhitzungsgefahr!

    Muxen in MkvmergeGUI:
    Renderzeit: 35sek
    Größe: 967MB


    natürlich darf auch ein screen zu MeGUI nicht fehlen: click
    Ich finde hier gibt es Unterschiede zu den anderen, wobei MeGUI deutlich schärfer ist.

    Und jetzt nochmal ein Alles umfassendes Fazit:

    Sony AVC:
    Renderzeit: 49:42 Min
    Größe: 821MB
    Arbeitsschritte: 1
    Qualität: gut, aber zu dunkel

    Handbrake:
    Renderzeit: 39:33 Min
    Größe: 903MB
    Arbeitsschritte: 3
    Qualität: gut

    MeGUI
    Renderzeit: 38:40 Min
    Größe: 967MB
    Arbeitschritte: 4
    Qualität: sehr gut

    sooo nachdem jetzt das erledigt ist kann ich auf die Antworten eingehen.

    maestrocool schrieb:

    -Beim Rendern auf x264vfw nicht zu wissen, wann er fertig ist, weil die Anzeige verbugt ist (die Anzeige ist nicht verbuggt, sie ist dynamisch und passt sich dem Videomaterial an)
    -Bein encodieren mit Handbrake Angst zu haben, dass mein PC überhitzt. (dafür kann doch Handbrake nichts, wenn dein PC bzw dein Prozessor keinen ausreichenden CPU-Kühler bekommen hat, dafür ist eher der Hersteller des PCs verantwortlich)
    -Immer vor dem Pc sitzen zu müssen, da ich alle Paar Minuten das Programm wechseln muss. (WTF du musst doch auch vor dem PC sitzen um Aufzunehmen, und du musst nicht am PC sitzen bleiben, denn die Programme brauchen in der Regel immer ähnlich viel Zeit)


    -Die Anzeige war verbugt, denn sie ist ganz normal von 1-50% gelaufen und als sie bei 50% war ist sie auf 100% gesprungen und war plötzlich fertig in der Hälfte der errechneten Zeit.
    -Ich weiß, dass mein Pc an der überhitzung schuld ist, aber genauso ist auch handbrake schuld, denn mit einem anderen Programm wäre das nicht der Fall gewesen.
    -Naja bei Sony AVC habe ich insgesamt 50 Min Zeit in denen ich was essen, lesen oder sonst was kann, und bei Handbrake ist die größte pause nur 22 Min. Lang, das aber auch nicht sicher, denn die Anzeige ist verbugt und deshalb weiß ich nicht wann ich wieder am Pc sein müsste

    -Und das mit dem höheren CRF werde ich wahrscheinlich auch nochmal ausprobieren.

    Wer Rechtschreibfehler findet darf sie behalten.

    mfg Nightysin

    P.S.: ich schreibe heut verdammt viel für 2 posts

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Nightysin ()

  • Wieso sollte ich mir einen 300€ Prozessor kaufen oder einen 1000€ Prozessor und ihn dann nicht voll auslasten dürfen ?
    Ich habe doch extra so viel Geld hin gelegt damit der Prozessor auch so stark ist, wenn ich etwas schwächeres haben wollte, dann hätte ich auch einen günstigeren und schwächeren Prozessor gekauft
    Also verrate mir dann doch mal, wieso hast du deinen Computer gekauft, mit diesem Prozessor ?
    und wenn schon der Prozessorkühler zu schwach ist, warum ersetzt du ihn nicht mit einem besseren ? der ihn auch richtig kühlen kann.
    Sonst ist der Prozessor nur weggeworfenes Geld, wenn du ihn nicht voll Nutzen kannst, da hättest du auch einen Billigeren kaufen können, oder?
    Ist mir nur so durch den Kopf gegangen, vielleicht hast du ja Antworten darauf, ich für meinen Teil habe sie (meine CPU kann volles Rohr laufen, keine Überhitzungsgefahr, im Gegenteil ich hab sogar auf 3,8 GHz übertaktet)
  • maestrocool schrieb:


    Also verrate mir dann doch mal, wieso hast du deinen Computer gekauft, mit diesem Prozessor ?
    und wenn schon der Prozessorkühler zu schwach ist, warum ersetzt du ihn nicht mit einem besseren ? der ihn auch richtig kühlen kann.
    Sonst ist der Prozessor nur weggeworfenes Geld, wenn du ihn nicht voll Nutzen kannst, da hättest du auch einen Billigeren kaufen können, oder?


    der PC den Ich zurzeit benutzte ist eine etwas ältere kiste (ca. 3 Jahre) und ein Aldi PC, den ich gekauft habe als ich noch nicht so viel am pc gemacht habe, und nichts von Hardware usw. verstanden habe (meistens Konsole gespielt). Und ja du darfst darüber lachen, ich tu es auch öfters. Aber dafür dass er ein 3Jahre alter Aldi PC (mit 4-5 Jahre alter Hardware) ist läuft er doch noch recht zufriedenstellend. Der Grund warum ich keinen neuen Prozessorkühler habe ist der, dass ich bis jetzt keinen brauchte. Mein Pc ist nie großartig erhitzt.
  • Gut, wenn er 3 Jahre alt ist, dann hat er sich sicher schon mit sehr viel Staub zugesetzt (das passiert bei den meisten PCs)
    dann sollte ihn eine Staubbefreiung gut tun, also mit einem Pinsel, die Lüfter und den Kühler säubern, dann überhitzt er nicht mehr so leicht, zumindest kann er dann wieder besser Kühlen
    Das sollte man sowieso mindestens 1mal im Jahr machen, aber die meisten Leute vergessen das oder wissen gar nicht das man den PC auch mal Reinigen/Staub befreien muss
  • Also dem x264 Encoder als Nachteil vorzuwerfen, das er die CPU zu 100% ausnutzt ist schon echt arg daneben^^

    2. Handbrake als auch MeGUI verwenden den exakt gleichen Encoder x264.

    Differenzen sind verschiedene Einstellungen beim x264 Encoder, evtl Avisynth, und die x264 Version als solches.

    -Die Anzeige war verbugt, denn sie ist ganz normal von 1-50% gelaufen und als sie bei 50% war ist sie auf 100% gesprungen und war plötzlich fertig in der Hälfte der errechneten Zeit.


    Das passiert wenn du ohne Interleave speicherst. Dann ist Video am Anfang und Audio am Ende. Das ist kein Bug, sondern normal, da Audio nunmal erheblich schneller encodiert als der Videoteil.
    Vorteil: Ein weiteres Programm - z.B. MeGUI kann so den Ton viel schneller encodieren, wenn der Ton an einem Stück vorliegt. Statt 3 - 4x realtime speed, macht MeGUI so 30 - 40x realtime speed.
    Nachteil: Für non-interleave muss die Platte natürlich beim Abspielen ständig hin und herspringen - Dies ist aber kein wirklicher Nachteil, da wir das verlustfreie Material ja eh nicht als Enddatei behalten wollen.

    Helligkeit: Hängt vom verwendetem Farbraum ab den der Encoder verwendet. Und YUV Material darf nicht auf RGB 0 - 255 erzwungen werden beim Abspielen. Denn dann wirds zu hell und die Farben zu blass abgespielt, da YUV nur 16-235 abdeckt und nicht den vollen Bereich.


    Du kannst eine x264 Encodierung im Übrigen mit nur einem Arbeitsschritt machen.

    TMPGEnc 5 ist ein sehr sehr gutes Videoprogramm (es hat wie vegas und co sehr gute Timeline etc) und ist meiner Meinung nach besser als Vegas, Premiere etc. Ich finde das Programm echt super. Außerdem nicht diese ganzen komischen Bugs, die diese arschteuren Programme teils haben. Der schwarzes Bild Bug ist ja gar bei der Pro Version von Vegas, was dann doch etwas arm ist.
    Naja und TMPGEnc 5 würde dir nebenencodierungen etc sparen, da er x264 drin hat.
    Wenn du keine Timeline benötigst, sondern nur zusammenfügen willst (wobei schneiden und Übergangseffekte gehen dort auch) kannste den Normal Modus nehmen. Da öffnest einfach deine Fraps dateien, hast sie in der Liste drin und encodierst sie nach x264. Fertig.

    Vorteil an MeGUI ist halt das MeGUI immer uptodate ist dank autoupdater, was Tools und Encoder anbelangt. Man muss hier also nicht immer erst auf eine komplett neue Programmversion warten, sondern es wird direkt geupdatet.
    Vorteil an TMPGEnc 5 ist aber klar die sehr gute Bedienung und eben die gute Videobearbeitung.

    Encodieren tut letztendlich x264 und nicht das Programm. Ergo sollte klar sein, das x264 egal ob Handbrake oder MeGUI oder TMPGEnc 5 die CPU zu 100% ausreizt.

    Und das ist kein Nachteil, sondern legt nur wieder, wie effizient der Encoder ist.
    Und Sony AVC kann natürlich Zeit gewinnen, wenn er deutlich weniger komplexe Berechnung macht, als x264 es tut.

    Da muss man schon so fair sein und genauer ins Detail gucken, ob x264 nun wirklich langsamer ist, oder er nicht doch einfach deswegen evtl langsamer ist, weil er schlichtweg den komplizierteren Job macht. ;)
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von De-M-oN ()

  • De-M-oN schrieb:


    Da muss man schon so fair sein und genauer ins Detail gucken, ob x264 nun wirklich langsamer ist, oder er nicht doch einfach deswegen evtl langsamer ist, weil er schlichtweg den komplizierteren Job macht. ;)


    Ich hab nie behauptet, dass x264 langsamer als sony avc ist.

    Nightysin schrieb:



    Sony AVC:
    Renderzeit: 49:42 Min
    Größe: 821MB
    Arbeitsschritte: 1
    Qualität: gut, aber zu dunkel

    Handbrake:
    Renderzeit: 39:33 Min
    Größe: 903MB
    Arbeitsschritte: 3
    Qualität: gut

    MeGUI
    Renderzeit: 38:40 Min
    Größe: 967MB
    Arbeitschritte: 4
    Qualität: sehr gut


    Nein im Gegenteil. Ich habe sogar geschrieben,dass beide x264 Methoden schneller sind als die Sony AVC Methode.
    Und die Einzelnen schritte, bei denen x264 wirklich angewandt wird kosten bei diesen Methoden sogar nur 40% der Zeit von Sony AVC

    mfg Nightysin

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Nightysin ()

  • Also erstmal überhitzt deine CPU nicht gleich, nur weil sie 100% ausgenutzt wird, sie ist doch dazu da um zu ackern. Solange sie gut gekühlt ist, alles kein Problem, CPUs haben eh ne lange Lebensdauer.

    Dann zu diesem ganzen Encodierungs-Wettbewerb: Ich sehe ein, dass x264 eindeutig bessere Qualität liefert, aber: Ich habe ihn sowohl mit Handbrake, als auch MeGUI getestet, habe mich an die Tutorials gehalten, habe Einstellungen richtig angepasst etc.
    Das Endergebnis war, dass die Dateien größer waren, obwohl ich mir kleinere Dateien erhofft hatte.

    Was mich jetzt aber auch neugierig macht ist TMPGEnc 5. Werd ich mich mal informieren :3
  • Dann nimm einen größeren CRF Wert.

    Wie oft muss man das denn noch schreiben?^^
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
  • Ja dann ist deine Kühlung absolut abgrundtief schlecht.

    Dein System wird dann wahrscheinlich auch nicht Prime95 stabil sein.

    Eine CPU muss auch unter Volllast arbeiten können, wenn nicht ist es ein Fakt das die Kühlleistung schlichtweg unzureichend ist.

    Selbst ein Boxed Kühler schafft eine ausreichende Kühlung. Das ist nunmal die Aufgabe eines CPU Kühlers.

    Also irgendwas stimmt einfach mit deiner Kühlung nicht.

    PS: Hardware hält auch wesentlich länger, wenn sie kühler läuft.
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
  • Meine Freunde ich habe die Erleuchtung gesehen.
    Ich habe nämlich eine Session meines Projektes Torchlight gemacht und mir gedacht "Renderste den Kack mal mit Handbrake, mal schauen was passiert".

    Und das ist passiert:

    Bei der Hälfte der Renderzeit von Sony AVC habe ich ein Video rausbekommen, dass jetzt ca 200MB statt 900MB groß ist *yay*
    Anscheinend hängt es sehr von Bildmaterial ab, wie sehr Handbrake komprimiert.
    Bei Css hatte ich 900MB/900MB, und bei Torchlight 200MB/900MB (beide in 720p@25fps)

    Fun Fact am Rande: Torchlight in 720p mit Handbrake ist ca. genauso groß wie Super Mario 64 in 480p mit Handbrake WTF?

    mfg Nightysin

    Edit: alle beispiele wurden in Handbrake mit CRF 20 encodiert

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Nightysin ()

  • CRF 20 ist im Prinzip unnötig! Probiere es mit 21 wenn du richtig Qualitätsgeil bist, sonst eher mit 22-24. Spart nochmal einige MB.
    Torchlight müsste weniger komplex sein als Super Mario, weil sich nur der Hintergrund immer leicht ändert und nie so abrupt wie in richtigen 3D-Spielen.
    Mein funfact am Rande: 10 Minuten Doom (Ein Spiel von 1993!) haben etwas über 300 MB nach Handbrake in 720p. Es kommt immer auf Geschwindigkeit und Komplexität des Ausgangsmaterials an. Würde ich die unkomprimierte Ausgangsdatei durchlaufen lassen, hätte ich vermutlich nur etwa 250MB pro 10 min.
    CobraVerde. Spieleklassiker und untergegangene Juwelen schamlos beworben.
    Der beste Post des Forums!
    Empfehlungen: Outcast
    Thief Gold

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von CobraVerde ()

  • Nightysin schrieb:

    Anscheinend hängt es sehr von Bildmaterial ab, wie sehr Handbrake komprimiert.


    Och komm bitte, das hab ich doch schon so oft erklärt ;(

    Hier nochmal:

    Constant Rate Factor (CRF) Encodiermodus bedeutet:

    Man stellt einen Faktor ein und jedes Video wird an jeder Stelle, an jedem Frame und jeder Auflösung etc die exakt gleiche Bildqualität aufweisen. Und CRF nimmt sich nur exakt so viel Bitrate, wie für den gewählten Qualitätsfaktor pro Frame notwendig ist. ---> Das hat 2 Vorteile:

    -> Kein Bauchgefühlgerate mehr mit Bitrate.
    -> Man weiß das die Videos immer exakt gleich aussehen, egal wie komplex sie sind. (Einheitliche exakt identische Videoqualität)

    Die weiteren x264 Einstellungen beeinflussen bei CRF dann eben nur noch Encodierzeit vs Dateigröße.


    Außerdem CRF 20 ist bereits ein extrem guter Faktor. Klar das die Dateien wachsen. ;)
    Aber CRF 20 ist auch edles Bildmaterial dann. Aber für Leute mit schwachem Internet nicht das Optimale, vor allem wenns Videomaterial komplexer wird.

    CRF 21 ist auch noch excellent und reduziert die Dateigröße bereits deutlich. CRF 22 und 23 sehen auch noch recht ansehlich aus. Kompromiss finden, was dir am ehesten zusagt in Bezug Qualität und Dateigröße.

    Fun Fact am Rande: Torchlight in 720p mit Handbrake ist ca. genauso groß wie Super Mario 64 in 480p mit Handbrake WTF?


    Vllt sollten die Leute endlich mal die Spielgrafik von Videoqualität trennen :P

    Das leidige Thema :D

    Doom 2 wird bei mir auch 50% größer als Doom 3.

    Warum? Weil Doom 2 viel heller ist und manche Texturen Feindetail aufweisen. Während bei Doom 3 viel Dunkelheit herrscht, die Texturen glatter sind, weil viel Innenraum und kein Außenterrain (Kieselsteintexturen etc) oder sonstiges.
    Auch ein C&C Alarmstufe Rot 1 Panzer oder Soldat ist = Feindetail. Er ist klein und Verfälschungen durch Kompression würde man direkt bemerken mit dem Auge. Also muss x264 das hier natürlich berücksichtigen um dem Qualitätsfaktor treu zu bleiben.
    Und natürlich ist ganz klar der Faktor : Bildwechsel. Schnelle Bildwechsel? Langsame Bildwechsel? Wie stark verändern sich die Frameinhalte wie schnell? Viele ähnlich aussehende Frames können natürlich besser genutzt werden für Kompression (kann man auf diese referenzieren), sind es aber grundlegend komplett anders aussehende Frames, wirds natürlich schwieriger.
    Besonders schwierig zu komprimieren ist solch Feindetail wie bei modernen Spielen und dann Terrain (Wald mit Wiese, Kieselsteinen, Baumblätter etc, wo man womöglich noch perfekt hindurchgucken kann bei heutiger Grafik. Das alles erschwert die Kompression.
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
  • De-M-oN schrieb:

    Nightysin schrieb:

    Anscheinend hängt es sehr von Bildmaterial ab, wie sehr Handbrake komprimiert.


    Och komm bitte, das hab ich doch schon so oft erklärt ;(

    Hier nochmal:

    Constant Rate Factor (CRF) Encodiermodus bedeutet:

    Man stellt einen Faktor ein und jedes Video wird an jeder Stelle, an jedem Frame und jeder Auflösung etc die exakt gleiche Bildqualität aufweisen. Und CRF nimmt sich nur exakt so viel Bitrate, wie für den gewählten Qualitätsfaktor pro Frame notwendig ist. ---> Das hat 2 Vorteile:

    -> Kein Bauchgefühlgerate mehr mit Bitrate.
    -> Man weiß das die Videos immer exakt gleich aussehen, egal wie komplex sie sind. (Einheitliche exakt identische Videoqualität)

    Die weiteren x264 Einstellungen beeinflussen bei CRF dann eben nur noch Encodierzeit vs Dateigröße.


    Außerdem CRF 20 ist bereits ein extrem guter Faktor. Klar das die Dateien wachsen. ;)
    Aber CRF 20 ist auch edles Bildmaterial dann. Aber für Leute mit schwachem Internet nicht das Optimale, vor allem wenns Videomaterial komplexer wird.

    CRF 21 ist auch noch excellent und reduziert die Dateigröße bereits deutlich. CRF 22 und 23 sehen auch noch recht ansehlich aus. Kompromiss finden, was dir am ehesten zusagt in Bezug Qualität und Dateigröße.


    WTF was hat der von dir zitierte Auszug aus meinem Post mit dem Crf zu tun?
    Ich hab damit nur sagen wollen, dass Torchlight mit den selben Einstellungen wie CSS gerendert auf sehr viel weniger Dateigröße kommt.
    Daher hängt es sehr vom Ausgangsmaterial ab, wie stark der Encoder komprimieren kann.

    De-M-oN schrieb:

    Fun Fact am Rande: Torchlight in 720p mit Handbrake ist ca. genauso groß wie Super Mario 64 in 480p mit Handbrake WTF?

    Vllt sollten die Leute endlich mal die Spielgrafik von Videoqualität trennen


    lol das war eher auf die 480p bezogen. Denn mit Sony AVC hatte ich bei SM64 nur eine 20MB größere Datei als mit Handbrake und bei Torchlight 700MB
    -----> Es hängt vom Bildmaterial ab, wie stark komprimiert wird

    mfg Nightysin

    Edit: Ich will nicht immer in BB-code schreiben. Wieso haben wir denn keine Editor mehr? <-------FAIL: ich hatte scripts deaktiviert *facepalm*

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Nightysin ()

  • Nightysin schrieb:

    Daher hängt es sehr vom Ausgangsmaterial ab, wie stark der Encoder komprimieren kann.

    Ja eben!

    Ich verstehe nicht, wieso du erst jetzt das verstehst? Genau das ist doch der springende Punkt von CRF und hab ich doch mit genau diesem Auszug auch so oft erklärt.
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von De-M-oN ()