Quantizer im 1st neuerdings kleiner als im 2nd pass

  • Moin. Eine kleine Frage:
    Was könnte die Ursache dafür sein, daß bei x264 neuerdings die Quantizer bei 2pass mit aktivierter Turbo Option im ersten Durchlauf niedriger sind als im zweiten?

    Aufgefallen ist mir dies, seit ich auf die neuen Versionen mit --mbtree gewechselt habe. Hat dies etwas damit zu tun?

    Danke schonmal.

    Einmal editiert, zuletzt von LigH (31. August 2009 um 14:40)

  • Was stört Dich daran?
    Der 1st pass wird i.d.R. nicht exact die gleiche Datenrate haben wie der 2nd pass, d.h. also:
    1. ist die Datenrate die im 1st pass erreicht wurden wäre höher so wird er meist im Durchschnitt niedrigere Quantizer verwenden als der folgende 2nd Pass
    2. ist die Datenrate die im 1st pass erreicht wurden wäre niedriger so wird er meist im Durchschnitt höhere Quantizer verwenden als der folgende 2nd pass
    was auch sinnig und die Aufgabe der Ratecontrol ist.

    Selbst wenn der 1st pass und der 2nd pass exakt die gleiche Datenrate erzeugen würden wäre es durchaus verständlich, dass die durchschnittlichen Quantizer abweichen können, da im 2nd Pass die Quantizerverteilung i.d.R. anders ist als im 1st pass. (wenn sie im 1st pass schon ideal ist brauchen wir keinen 2nd pass ;))

    Cu Selur

    Ps.: Kleine Anmerkung am Rande wenn Du 2pass und mbtree verwendest ist es bei meinen Tests soweit besser gewesen qcomp auf 0.5 (anstatt 0.6) zu setzen um die Zieldatenrate exakter zu treffen.

  • Nein, mich stört nichts daran. Es ist eben nur anders, seit ich auf die neue Version umgestellt habe, und dafür gibt es einen Grund, dachte ich. Solange am Ende alles stimmt, ist es okay.

    Ich habe z.B. bislang häufiger nach dem 1st pass nochmal die Einstellungen geändert (Auflösung, Filter, etc.) und von vorne gestartet, wenn die Quantizer im 1st pass über einem bestimmten Wert lagen.

    Jetzt muß ich umdisponieren, weil sie im 2nd eher steigen denn sinken.

  • Zitat

    wenn die Quantizer im 1st pass über einem bestimmten Wert lagen.


    Beileid, dann sind die Änderungen der letzten Monate ja der reine Horror für Dich, da sich durch sie die Skalierung der Quantizer bzgl. der resultierenden Größe verschoben hat. ;)

    Cu Selur

  • D.h. weder psn, ssim noch der subjektive eindruck korrelieren noch mit den Quantizern, die ich als Erfahrungswerte im Kopf habe? - Also auf, neue Erfahrungswerte sammeln. ;)
    Es war halt praktisch, daß ich nach dem vergleichsweise schnellen ersten Durchlauf schon in etwa wußte, ob es sich lhnt, einen 2. Durchlauf ohne Änderung anzufangen.

    Daß die Quantizer bislang im 2. Durchlauf niedriger ausfielen, kam mir logisch vor, da im ersten Durchlauf einige Funktionen abgeschaltet waren bzw. mit schlechteren Einstellungen liefen. Und möchte man mit schlechteren Einstellungen auf die gleiche Dateigröße kommen, muß gröber quantisiert werden.

    Aber wie ich jetzt merke, war diese Erklärung wohl ein wenig naiv. :(

  • Zitat

    D.h. weder psn, ssim noch der subjektive eindruck korrelieren noch mit den Quantizern, die ich als Erfahrungswerte im Kopf habe? - Also auf, neue Erfahrungswerte sammeln


    Jein, grob sind die Werte natürlich immer noch aussagekräftig, aber dadurch, dass x264 immer mehr in die 'psychovisuelle Ecke' ecke geht sind sie immer weniger aussagekräftig und vor allem nicht mehr mit vorher zu vergleichen. ;)

    Zitat

    Aber wie ich jetzt merke, war diese Erklärung wohl ein wenig naiv


    Gerade funktionen wie adaptive Quantizer kann mit dem durchschnittlichen Quantizern natürlich einiges ändern. ;)

  • Mit dem MBTree-Verfahren lohnt sich ein zweiter Durchlauf nun umso mehr, weil damit nicht nur Quantisierungsfaktoren für gesamte Frames dem Bedarf angepasst werden, sondern eventuell auch verschiedene Bildausschnitte unterschiedlich. Also noch bedarfsgerechter.

  • Danke für die Erläuterungen soweit.
    Bezüglich mbtree hätte ich da noch eine kleine Frage. Die Funktion beißt sich ja bekanntlich mit --b-pyramid, weswegen letzteres ja auch ausgeschaltet wird, sofern mbtree anwendung findet. Gibt es Quellmaterial, welches so stark von --b-pyramid profitiert, daß es einen Verzicht auf mbtree sinnvoll erscheinen läßt?

Jetzt mitmachen!

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