X264 /MeGUI - abstruse Datei-Größen der unterschiedlichen Presets

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

  • X264 /MeGUI - abstruse Datei-Größen der unterschiedlichen Presets

    Anzeige
    Hallo!

    Ich bin noch sehr unerfahren im Bereich Gameplay-Videos aufnehmen und encodieren. Momentan versuche ich gerade einen für mich vernünftigen Kompromiss zwischen Dateigröße und Encoding-Dauer zu finden.

    Dazu habe ich ein Video aufgenommen:
    Länge: 3:59 min.
    Codec: LAGS YV12
    Auflösung: 2560x1440
    FPS: 30

    Mit dem SSM habe ich dann folgendes AVS generiert:
    Spoiler anzeigen

    Quellcode

    1. ### SagaraS Scriptmaker - Version 5.6 ###
    2. ### Load plugins and set the global variables ###
    3. LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\resamplehq.dll")
    4. Global breite = 2560
    5. Global hoehe = 1440
    6. Global AR = 1
    7. ### Loading video sources ###
    8. SetMTMode(3)
    9. AVIload("K:\WL2_2015_07_19_03_25_00_960.avi", 0, 0, 0, -0, -0, "Auto", "Auto", 0, 0)
    10. ### Filter processing zone ###
    11. ### Function for video loading routine ###
    12. Function AVIload (String file, int loading, int cl, int co, int cr, int cu, string pixtype, string afps, int fpsn, int fpsd) {
    13. (loading == 1) ? FFIndex(file) : nop()
    14. clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : (pixtype == "Auto") ? AVISource(file, false).KillAudio() : AVISource(file, false, pixel_type=pixtype).KillAudio()
    15. clip1 = clip0.AutoFPS(afps, fpsn, fpsd).Cropping(cl, co, cr, cu)
    16. Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline16") : Clip1.Resize()
    17. }
    18. Function AutoFPS (Clip clip0, string afps, int fpsn, int fpsd) {
    19. rate1 = (afps == "Auto") ? (Round(Float(clip0.framerate * 1000)) / 1000) / 2 : nop()
    20. rate2 = (afps == "Auto") ? Round(clip0.framerate) / 2 : nop()
    21. rate = (afps == "Auto") ? (rate1 == rate2) ? 1 : 1001 : (afps == "Igno.") ? clip0.frameratedenominator : fpsd
    22. ratefaktor = (afps == "Auto") ? (rate == 1001) ? 1000 : 1 : nop()
    23. clip0 = (afps == "Auto") ? (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate) : (afps == "Igno.") ? clip0.AssumeFPS(clip0.frameratenumerator, rate) : clip0.AssumeFPS(fpsn, rate)
    24. Return clip0.ChangeFPS(60, 1)
    25. }
    26. Function Cropping (Clip clip0, int cl, int co, int cr, int cu) {
    27. clip0 = (clip0.IsRGB32() == True) ? clip0.ConvertToRGB24() : clip0
    28. Return (cl != 0 || co != 0 || cr != 0 || cu != 0) ? clip0.Crop(cl, co, cr, cu) : clip0
    29. }
    30. Function Resize (Clip clip1) {
    31. clip1 = (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24(matrix = "Rec709") : clip1.ConvertToRGB24(matrix = "Rec709") : clip1
    32. clip1 = (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.ResampleHQ(breite, ceil(float(Clip1.height * breite) / clip1.width), Kernel = "Spline16", dstcolorspace="RGB24", srcmatrix = "TV.601", dstmatrix = "TV.709", Chroma_Kernel = "Spline16") : Clip1.ResampleHQ(ceil(float(clip1.width * hoehe) / clip1.height), hoehe, Kernel = "Spline16", dstcolorspace="RGB24", srcmatrix = "TV.601", dstmatrix = "TV.709", Chroma_Kernel = "Spline16")) : clip1.ResampleHQ(breite, hoehe, Kernel = "Spline16", dstcolorspace="YV12", srcmatrix = "TV.601", dstmatrix = "TV.709", Chroma_Kernel = "Spline16")
    33. back = (AR == 1) ? (0 == 1) ? ImageReader("", 0, clip1.framecount - 1, clip1.framerate).ChangeFPS(Clip1.frameratenumerator, Clip1.frameratedenominator).ResampleHQ(breite, hoehe, Kernel = "Spline16", dstcolorspace="YV12", srcmatrix = "TV.601", dstmatrix = "TV.709", Chroma_Kernel = "Spline16") : BlankClip(clip1, width = breite, height = hoehe, pixel_type = "YV12").KillAudio() : clip1
    34. Return (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2) : clip1
    35. }​
    Alles anzeigen


    Das Ausgabe-Video hat also 60 FPS. Es handelt es sich um Gameplay von WASTELAND 2, also wohl eher weniger komplexes Bildmaterial (?).

    Das Encodieren unter MeGUI mit CRF 22.0 und den diversen Presets brachte Ergebnisse, die ich absolut nicht nachvollziehen kann. So entspricht zwar die Encoding-Dauer den Erwartungen, nicht aber die Größe der resultierenden Dateien.

    Quellcode

    1. Preset Encoding FPS Dateigröße (MB)
    2. veryfast 46,4 FPS 151 MB
    3. faster 34,0 FPS 183 MB
    4. fast 29,3 FPS 199 MB
    5. medium 22,8 FPS 206 MB
    6. slow 16,4 FPS 196 MB
    7. slower 10,4 FPS 200 MB
    8. veryslow 6,3 FPS 188 MB


    Bei konstanter Qualität sollten doch die aufwändigeren Presets bessere Resultate bei der Kompression produzieren, oder?

    Das Gegenteil ist jedoch der Fall. Das mit Abstand schnellste verwendete Preset erzeugt in diesem Fall auch die mit Abstand kleinste Datei! Das Preset "very fast" spuckt nach 5:10 Minuten eine 151 MB große Datei aus, "very slow" hingegen braucht ca. 7x so lange und erzeugt eine um 25% größere Datei?

    Wie kann das sein?

    Ich habe zur Ansicht mal die mit VERY SLOW and VERY FAST erzeugten Videos hochgeladen. Ich erkenne da auf den ersten Blick keinen Unterschied bei der Qualität, allerdings habe ich zugegebenermaßen auch absolut kein Auge für sowas.
    www6.zippyshare.com/v/rIsfZYF3/file.html
    www6.zippyshare.com/v/uNZd6Xqj/file.html

    Ich würde mich sehr freuen, wenn jemand etwas Licht diese Angelegenheit bringen könnte.
  • Die Presets bestimmen die Einstellung der Kompressionsmechanismen. Dazu gehören:

    - Die Einstellung der GOP (Group of pictures): Interframe Kompression (B-Frames,...) > reduzieren Dateigröße
    - Quantisierung/ Macroblocks: Intraframe Kompression > reduzieren/erhöhen Dateigröße
    - Analysevorgänge (Bewegungsvektoren): unterstützen den Rate Control (also in deinem Fall den CRF) > reduzieren/erhöhen Dateigröße

    Je langsamer das Preset, desto genauer arbeiten alle Mechanismen. Man kann also sagen, dass veryslow die beste Kompression und Qualität bringt und veryfast die schlechteste.

    Während die ersten beiden Mechanismen (hauptsächlich) die Dateigröße reduzieren, sind die Analysevorgänge der Grund, warum die Datei größer wird.

    Der CRF bestimmt bei x264 den Rate Control, also welche Bitrate letztendlich für ein Frame gewählt wird. Dazu gibst du ein groben Wert an wie hier 22.
    Der Encoder guckt sich jetzt die "Wichtigkeit" dieses Frames an und wählt für jeden Frame ein qp-Faktor. Der wird genauso berechnet wie der CRF. Ein wichtigerer Frame erhält dann zum Beispiel qp 19 während ein weniger wichtigerer qp 24 bekommt. Letztendlich hat man aber die Qualität von qp 22, das gibt der CRF an.

    Danach wird für jeden qp Faktor des Bildes eine Bitrate freigegeben. qp 19 kann dabei bei einem komplexerem Bild zum Beispiel 20.000 kbit bekommen, bei einem leichter zu komprimierenden Bild 10.000 kbit.

    Um zu ermitteln welche Bitrate jetzt tatsächlich eingesetzt wird, wird ein Analysevorgang gestartet.

    Wenn du jetzt veryfast gewählt hat, dann hat der Encoder nur eine sehr kurze Zeit um sich den Frame anzuschauen und übersieht dann z.B. komplexere Stellen und trifft eine zu niedrige Bitrate um dem CRF gerecht zu werden.
    Faster erkennt dann z.B. schon mehr Komplexität und gibt mehr Bitrate.
    Fast noch mehr, genauso wie Medium.
    Slow erkennt jetzt beispielsweise keine neue Komplexität, aber setzt dafür mehr B-Frames = Größe sinkt wieder
    ...
    ...

    Ungefähr so kann man sich das vorstellen :D

    Theoretisch hat jetzt veryslow eine schlechtere Qualität, die du mit bloßem Auge auch nicht erkennen kannst, wenn du die Datei einfach so hochlädst :)
    Aber ein zweiter Encoder, wie der von Youtube, erkennt die fehlende Bitrate schon und die Qualität würde schlechter werden.

    Du kannst dich aber ein bisschen an der Gewichtung orientieren:

    Von Veryslow bis Medium werden die Analysevorgänge nicht mehr so schwer beeinflusst.
    Unter Medium würde ich nicht gehen, da ab hier die Analyse stark abgeschwächt werden.
    Über Slow lohnt sich die Encodingzeit für die zusätzlich Kompression nicht mehr.

    Insgesamt hat man mit Medium oder Slow ein gutes Preset :)
    ~ Let's plays, Animes, Cinematics, Zeichnungen ~ :D

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

  • Vielen Dank für die Erklärung.

    Mal schauen, ob ich das richtig verstanden habe:

    - CFR produziert keine konstante Qualität über Presets hinweg
    - Langsamere Presets weisen die Bitrate intelligenter zu, was in einer höheren Bitrate resultieren kann
    - Auch diverse Analysemechanismen können die Dateigröße aufblasen
    - Der Umstand, dass die schnelleren Presets in diesem Fall qualitativ schlechter encodieren, ist eventuell für das bloße Auge nicht sichtbar

    Richtig?

    Das bedeutet aber gleichzeitig, dass die Daumenregel "Langsamere Presets -> kleinere Dateien" eigentlich keine allgemeine Gültigkeit hat, oder? Ich habe auch schon mehrfach gehört/gelesen, dass die Presets angeblich keinen Einfluss auf die Qualität haben, nur Geschwindigkeit und Datei-Größe. Diese Behauptung wäre dann auch falsch, oder?

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

  • Anzeige
    Also ich habe gerade mal nachgesehen... das "very fast" bekommt deutlich weniger Bitrate ab als das "very slow". Das finde ich ebenfalls überraschend, weil ich eigentlich angenommen hatte, dass die schnelleren Presets eher verschwenderisch mit der der Bitrate umgehen, um X Qualität auch ohne aufwändige Analyse zu erreichen. Das war wohl falsch gedacht.

    Very fast: 5200 kbps
    Very slow: 6500 kbps

    Wirklich seltsam, dieses Verhalten.

    Was mich interessieren würde: Wie verhält es sich bei anderem Bildmaterial, also z.B. schnellen 3D-Shootern, und macht es bei der erneuten encodierung durch YouTube einen sichtbaren Unterschied.

    Ich habe mal Very Fast und Very Slow zu YT hochgeladen:
    Very Fast
    youtube.com/watch?v=KJJ5ZhI5JKc
    Very Slow
    youtube.com/watch?v=NGFR3ntL-kU

    Ich sehe da in 1440p immer noch keinen relevanten Unterschied. Ich meine, dass der "very fast" Encode minimal mehr Artefakte um die Schrift herum in der Textbox rechts produziert, aber das kann auch Einbildung sein. Oder vielleicht habe ich auch Tomaten auf den Augen.

    Da stellt sich wirklich die Frage, ob langsamere Presets den höheren Zeitaufwand und die höhere Dateigrößen wert sind - zumindest bei diesem Bildmaterial. Mit der Lupe wird wohl keiner vor'm Monitor sitzen und LPs schauen....

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

  • Die Kiste schrieb:

    Da stellt sich wirklich die Frage, ob langsamere Presets den höheren Zeitaufwand und die höhere Dateigrößeren wert sind - zumindest bei diesem Bildmaterial. Mit der Lupe wird wohl keiner vor'm Monitor sitzen und LPs schauen....

    Meinen Versuchen nach: Nein. Deswegen kodiere ich schon seit längerer Zeit mit dem TMPGEnc-Preset das "Fast" entspricht, habe sehr viel kürzere Kodierungszeit, ein paar wenige MB mehr und absolut keine sichtbare Qualitätsminderung. Und da ist mir auch furzegal, was die Hyperqualitätselite davon hält.
  • Ich enkodiere auch auf fast, brauche dadurch (ohne Aufbauschen) teils weniger Zeit als eine Folge lang ist. Also z.B. war eine Folge 17 Minuten lang und hat zum enkodieren 12,5 Minuten gebraucht. Dabei war die Enddatei ca. 700MB groß bei CRF 23 (Valiant Hearts). Sieht trotzdem super aus. Denke auch,d ass der Otto-Normalverbraucher auf Youtube da keinen Unterschied sieht.

    *tschiep* Fallout 4 / Dragon Age: Inquisition (Hakkons Fänge) *tschiep*
  • Julien schrieb:

    Meinen Versuchen nach: Nein. Deswegen kodiere ich schon seit längerer Zeit mit dem TMPGEnc-Preset das "Fast" entspricht, habe sehr viel kürzere Kodierungszeit, ein paar wenige MB mehr und absolut keine sichtbare Qualitätsminderung. Und da ist mir auch furzegal, was die Hyperqualitätselite davon hält.


    Wobei witziger weise bei mir hier nicht mal das "ein paar wenige MB mehr" zutrifft.

    Ich hab noch ein paar Tage auf meiner TMPGEnc Trial. Könntest Du eventuell Dein Preset irgendwo hochladen? Das wäre wirklich nett, ich würde mir das gerne mal anschauen.
  • Ich schließe mich mal Julien an und bin selber der Meinung, dass sich beim Rendern über jedes Preset reden lässt, solang's nicht Ultra Fast ist. Ich selber würde mich wohl zwischen Slow und Faster aufhalten und wahrscheinlich Fast bevorzugen - da sollte der sichtbare Effekt vernachlässigbar sein und die Einstellungen, die sich auf die Kompressionseffizienz auswirken, sind nicht ganz für'n Arsch.
    Videoempfehlungen:
    ShimmyMC
    NuRap
    ShimmyMC
    Napoleon Bonaparte

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

  • Die Kiste schrieb:

    Ich sehe da in 1440p immer noch keinen relevanten Unterschied. Ich meine, dass der "very fast" Encode minimal mehr Artefakte um die Schrift herum in der Textbox rechts produziert, aber das kann auch Einbildung sein. Oder vielleicht habe ich auch Tomaten auf den Augen.


    Ja ungefähr in der Größenordnung bewegen sich auch die Artefakte.
    Du musst halt wissen, dass CRF 22 + 1440p@60 schon so hohe Qualität bring, dass das hier relativ egal sein wird.
    Aber das Preset musst du halt nach deinen Vorstellungen wählen ;)

    Die Kiste schrieb:

    Da stellt sich wirklich die Frage, ob langsamere Presets den höheren Zeitaufwand und die höhere Dateigrößen wert sind - zumindest bei diesem Bildmaterial. Mit der Lupe wird wohl keiner vor'm Monitor sitzen und LPs schauen....


    Wer weiß :D
    Ne, wie schon gesagt, die wirklichen langsamen Presets sind bei Youtubeaufnahmen eher überflüssig.

    Insgesamt kommt das ja auch auf das Material und deinen gewünschten Zeitaufwand an.

    Mal als Beispiel:
    1. Du hast einen schnellen Shooter mit sehr vielen Szenenwechseln und komplexen Texturen, wie sich bewegendes Gras.
    = viele Mechanismen können hier nicht mehr viel Dateigröße sparen, da z.B. B-Frames nicht hut einsetzbar sind. Ein langsameres Preset wird wohl weder Dateigröße noch Qualität großartig verändern.

    2. Du hat ein sehr ruhiges Spiel mit gleichmäßigen Farben und Texturen. Als extremsten Fall kannst du dir auch ein Anime vorstellen.
    = hier kommen die Mechanismen sehr gut zur Geltung. Viele Bereiche können gut komprimiert werden und es können auch mal ~8 B-Frames hintereinander stehen. Die Dateigröße sinkt bei langsameren Presets.

    Letztendlich musst du dich auch nicht auf Presets konzentrieren (sind ja schließlich nur Vorlagen), sondern kannst auch bei MeGUI gleich die Sachen verändern, die du brauchst/ nicht brauchst.

    Hier siehst du nochmal alle Einstellungen und Presets im Überblick: encodingwissen.de/x264/referenz
    ~ Let's plays, Animes, Cinematics, Zeichnungen ~ :D
  • GrandFiredust schrieb:

    Der CRF bestimmt bei x264 den Rate Control, also welche Bitrate letztendlich für ein Frame gewählt wird.


    Letztendlich bestimmts rein nur die quantizer. Bitraten sind nur ein Resultat der Mathematik. Der Encoder arbeitet selbst bei VBR via Quantisierung. Der sagt dann der Frame kriegt Quantizerfaktor 21 beispielsweise, statt der Frame kriegt jetzt 9340 kbit.
    War dir vllt schon klar, aber ums nochmal zu verdeutlichen :)

    Das schnelle Presets kleinere Dateigrößen haben wurde schon gut erklärt wieso und liegt ja auf der Hand. Es wird weniger nach Details gesucht. CRF arbeitet somit inakkurater und feindetails werden nicht erkannt und bekommen entsprechend stärkere kompression.

    Schnelleres preset als medium empfehl ich nicht. Eher kann man die b-frames auf 0 setzen. Das verdoppelt bereits die encodespeed - und vllt ja sogar mehr als preset fast, wo du noch b-frames nutzt.
    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
  • Naja, eventuelle Details werden spätestens von YouTube kaputtcodiert und wenn man die Unterschiede, wie bei den Beispielen oben, zwischen einen Very Fast und einem Very Slow Encode am Ende mit der Lupe suchen muss, dann isses mir letztendlich auch wayne, wenn das YT-Gesamtergebnis immer noch gut aussieht. Für's private Archivieren von nachbearbeiteten Urlaubsfilmen würde ich eventuell andere Maßstäbe anlegen.

    Wie genau wirken sich denn die bframes beim Encoden aus?

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

  • Eine genaue Erklärung gibt es hier: encodingwissen.de/grundlagen/v…ession/interframe#bframes

    Grundsätzlich jedoch gehören die B-Frames zu der GOP, also für die Frame-übergreifende Kompression.

    Normalerweise hast du ein ganzes Bild, den I-Frame mit allen Informationen.
    Jetzt kommt ein P-Frame, dieser enthält nur noch die Informationen aus dem vorherigen I-Frame die anderes sind.
    Damit lässt sich extrem die Dateigröße einsparen, da theoretisch ein Video nur aus einem I-Frame und Refrenzbilder bestehen kann, solange keine starken Szenenwechsel kommen.

    Der B-Frame funktionier genauso wie der P-Frame, nur dass dieser auch Informationen aus nachfolgenden Bildern ziehen kann.



    Durch B-Frames lässt sich die Dateigröße noch mehr reduzieren.

    Das Problem ist neben der schon erwähnten viel höheren Encodingzeit, dass der Encoder nicht immer B-Frames setzen kann. Bei einem Spiel mit vielen schnellen Szenenwechseln, bringen dir B-Frames nicht viel.
    Bei ruhigeren Spielen mit vielen ähnlichen Bildern jedoch lohnt es sich schon auf B-Frames zu setzen. :)

    De-M-oN schrieb:

    War dir vllt schon klar, aber ums nochmal zu verdeutlichen


    So ungefähr :S
    ~ Let's plays, Animes, Cinematics, Zeichnungen ~ :D