Xvid-Video größer als angegeben... Warum ?

Zitat von namor82

Was meinst du denn mit den limit q4 limit q3/q8 Einstellungen ?
Meinst du die max Quantizer von I,P,B Frames ?

Jup.
1st-pass: zone @ quant=4
2nd-pass: min.Quant=3 / max.Quant=8 (I,P und B)

Zitat

Wie finde ich denn den avg. Quant raus um die Formel "max.Quant = ~1.66*avg.Quant" richtig anzuwenden ?

enc , und damit ein bisschen probieren mit 2% - Snips

Erstmal Vielen Dank an Selur und Didée für die ausführlichen und verständlichen Erklärungen! :daumen:

Das am Schluß muß ich nochmal in Ruhe durchdenken - aber ich glaube die Grundzüge hab ich kapiert

Ein paar Fragen würd ich gerne noch loswerden, auch wenns in diesen Thread grade nicht reinpasst - die Frage ist allerdings, in welchen Thread es sonst passt

1. "q1-Frames sind unverhältnismäßig viel größer als q2-Frames. So im Bereich 50% bis 100% größer" :eek:
Wie das denn? q2 ist doch nur eine zusätzliche Division durch 2 - das heißt ein Bit wird immer 0 gesetzt - das dürfte bei der anschließenden Huffman-Kompression doch nicht so viel ausmachen - *fragendkuck*
Das typische Anfängerszenario traf bei mir übrigens voll zu, als ich mit DS9 anfangen wollte :ja:

2. Thread zu CC: Ja, bitte - den Anfang hätte man ja schon, wenn man die Teile, die hier OT sind, rüberkopiert

3. Wie/Womit machst Du CC? Sorry, wahrscheinlich ne doofe Frage, ist aber ernst gemeint...
...ab der Stelle kann ich nur noch theoretisch folgen - nee, ich brauch keine Screenshots, aber so grob: Meinst Du mit "limit q3/q8" die Limits für I und P-Frames, oder bin ich völlig an der falschen Stelle?
Wie schaffst Du es, daß der 1.Pass mit q4 statt q2 läuft?

Wie geschrieben, ich will gar keinen "Guide" mit Bildles (hab zwar Nix dagegen, ist aber zu viel Arbeit), ein Anstoß reicht hoffentlich.

Danke namor82 - haste schön gemacht, mit dem Pass im darunterliegenden Fenster...

OK, es geht also tatsächlich um "Quantizer Restrictions" - Didée, stellst Du die dann Szene für Szene per Zone ein :eek: ?
Ich wußte auch nicht mehr, daß man die auch im 1.Pass einstellen kann.

An den Overflow-Settings zu drehen macht für mich wenig Sinn, da ich meistens Serien encode, da kommts mir auf ein paar Byte mehr oder weniger pro folge nicht an.

Zu 1)

So funktioniert das aber nicht. Ohne jetzt den ganzen i/DCT-Prozess erklären zu wollen (so sehr sattelfest bin ich da auch nicht) :

Am Ende des DCT-Prozesses werden viele Werte (für die einzelnen "Frequenz-Zellen" der Matrix) genullt, also komplett fallengelassen, wenn ihr Wert klein genug ist ... so 'ne Art Threshold. Und bei q2 rutschen einfach viele Werte unter diesen Threshold und werden weggeworfen, die bei q1 noch "überlebt" hätten.

Vergleiche: Der Größenunterschied q2 / q3 ist sehr viel größer als der von q30 / q31 ...

Zu 3)

>> Wie/Womit machst Du CC

XviD -> 2nd-pass -> more -> Curve Compression

>> Meinst Du mit "limit q3/q8" die Limits für I und P-Frames

jep. XviD -> Advenced -> Quantization -> Min=3 / Max=8

>> Wie schaffst Du es, daß der 1.Pass mit q4 statt q2 läuft?

XviD -> 1st pass -> SimsalabimZoneOptions -> AbrakadabraQuantizer=4

edit: aha, bin wieder mal zu langsam gewesen

Zitat von namor82

Also das habe ich auch nicht verstanden. Was sind denn Q1 und Q2 Frames ? Was machen die und wo stellt man die ein (sorry, verstehe ich echt nicht).

Hier muss man aufpassen mit der Schreibweise!

q2-Frame == "Frame, der mit Quantizer=2 quantisiert wurde"

Q20-Frame =="Frame, der mit Quality=20% quantisiert wurde"

Also: kleines "q" = Quantizer, großes "Q" = Qualität

Zitat von Trekkie2

OK, es geht also tatsächlich um "Quantizer Restrictions" - Didée, stellst Du die dann Szene für Szene per Zone ein ?

Nö, wieso denn? Der Analyse-Pass läuft mit einem einzigen Quantizer durch. Der Encoding-Pass verteilt dann die Quantizer entsprechend FirstPassSize/DestinationSize - Verhältnis, und nimmt zusätzlich aktiv Einfluss entsprechend den CC-Einstellungen: mehr Bits für "kleine" Frames, und weniger für "große" Frames.

Ein einziges Mal hab ich alles manuell gemacht: Für LOTR-Die Gefährten, SharpResized auf 960*528 ("720p anamorph"). Zur der Zeit war XviD-1.0 noch "blutige Alpha", und das 2-pass-Modul hat nur M.u.r.k.s. produziert. Also hab' ich das die ganze SEE kapitelweise kodiert, und dabei die Quantizer-Verteilung für die ca. 190 Minuten komplett von Hand vorgenommen, per Zones.

Hat ein wenig gedauert bis das fertig war ...

(Sieht aber auch heute noch gut aus )

edit: oh, was man auf so'ner Festplatte nicht so alles findet. Angehängte Datei war "mein erster Einblick" in den i/DCT - Kram ...

Zitat von Didée

Ohne jetzt den ganzen i/DCT-Prozess erklären zu wollen (so sehr sattelfest bin ich da auch nicht) :

Das gibts ja auch zum Nachlesen Und da hab ich sogar ne Quelle ;D

Zitat von Didée

Am Ende des DCT-Prozesses werden viele Werte (für die einzelnen "Frequenz-Zellen" der Matrix) genullt, also komplett fallengelassen, wenn ihr Wert klein genug ist ... so 'ne Art Threshold.

OK, dann glaub ich das sofort. Das mit Threshold hat mir gefehlt...

Zitat von Didée

Zu 3)
XviD -> 2nd-pass -> more -> Curve Compression
XviD -> Advenced -> Quantization -> Min=3 / Max=8
XviD -> 1st pass -> SimsalabimZoneOptions -> AbrakadabraQuantizer=4

OK, da merkt man mal wieder, daß ich das nicht hier im Büro probieren kann - werds mir zu Hause mal anschauen - Danke!

[edit:] OK, jetzt hab ich zu langsam getippt
"Der Encoding-Pass verteilt dann die Quantizer entsprechend FirstPassSize/DestinationSize - Verhältnis, und nimmt zusätzlich aktiv Einfluss entsprechend den CC-Einstellungen: mehr Bits für "kleine" Frames, und weniger für "große" Frames."
Das ist der einzige Teil, den ich mir jetzt noch nicht vorstellen kann - werds möglichst bald mal antesten...

.. und ich dachte, dass mit den Overflow Settings hätte ich im Wissenswertes verständlich erläutert,...

Naja, ist alles ne Geschmackssache
Gerade bei dunklen Szenen bevorzuge ich sehr niedrige Quantizer. Ein Grund für Quantizer 1 ist für mich u.a. der, dass dunkle Szenen teilweise nur mit Quantizer 1 ordentlich werden.

Über Curve Compression an sich köntne man durchaus nen eigenen Thread machen, falls Diskussionsbedarf besteht,...

"Quantization -> Min=3 / Max=8"
halte ich persönlich für Unfug :D, aber wie gesagt ist Geschmackssache
(ich encode aber auch meist nur Quellmaterial was mindestens DVD Qualität hat)

Cu Selur

Ps.: Vielleicht auch ganz nett zu lesen: http://www.flaskmpeg.info/board/thread.php?threadid=4526

Zitat von Selur

.. und ich dachte, dass mit den Overflow Settings hätte ich im Wissenswertes verständlich erläutert,...

:redface: Vielleicht muß ich doch nochmal nachlesen...

Zitat von Selur

Über Curve Compression an sich köntne man durchaus nen eigenen Thread machen, falls Diskussionsbedarf besteht,...

Mein Wissen reicht zwar nicht für tiefgreifende Diskussionen, aber als interessierten Leser (und Fragesteller ) könnte ich dienen.

Trekkie2: lies auch mal den Thread im Flaskmpeg.info Forum der hilft eventuell auch was beim Verständnis.

Cu Selur

Danke Selur!
Ja, so langsam wirds...
... jetzt muß ich nur noch erkennen, was das für meine Serien heißt und dann umsetzen...
... aber erst, wenn der Schwindel nachläßt :ani_lol:

Selur, wenn Du - statt diffus herumzuorakeln - klarer herausstellen könntest, *warum* Du das für Unfug hälst, dann könnte ich Dir sagen, warum Dein Dafürhalten Unfug ist

Irgendwo hatten wir das Thema letzthin doch schon mal angeschnitten ... und ich meine gesagt zu haben, dass das Herumgespiele mit der Curve Compression ein *Ansatz* ist, um die Verteilung der Bitrate etwas näher an HVS heranzubringen ... dass das aber keinesfalls ein Ersatz ist für eine Komplexitäts-Analyse, die XviD leider immer noch nicht hat.

Aber was wollte ich eigentlich - ach ja,

Ein Mini-Beispiel:

(Zur Vereinfachung ohne B-Frames, und die Farben bitte einfach mal vergessen)

1st-pass @ quant 4 :

[Blockierte Grafik: http://img223.echo.cx/img223/8670/1stpass5vw.png]

2nd-pass, CC: hi=0, lo=0 :

[Blockierte Grafik: http://img223.echo.cx/img223/1851/2ndpasszero7fh.png]

2nd-pass, CC: hi=40, lo=20 :

[Blockierte Grafik: http://img223.echo.cx/img223/6796/2ndpass40205ks.png]

Die ersten 100 Frames sind "einfach" (dunkel), brauchen also wenig Bitrate. Die zweiten 100 Frames sind komplex (hell, kontrast- u. detailreich, viel Bewegung), brauchen also viel Bitrate. Der 2nd-pass zielt auf einen Durchschnitts-Quantizer von ~ungefähr~ 4.5 (vier Komma fünf) ab.

Ohne Curve Compression: Die Sequenz wird durchgängig mit q4-q5-q4-q5.... kodiert.

Mit Curve Compression: Die einfache Sequenz kriegt fast durchgängig q3, die komplexe fast durchgängig q5.

Ergebnis: die komplexe Szene sieht nicht wirklich schlechter, die einfache (dunkle) aber deutlich besser aus.

Warum ich eine Einschränkung auf Quantizer 3-8 für Unfug halte:
1. weil die meisten Encodes die ich habe durchaus Quantizer 2 benutzen
2. ich wenn ich Custom Matrizen benutze öfters auch mal eine viel weitere Streuung der Quantizer habe

Einen first pass mit einem anderen Quantizer als 2 zu machen macht nur Sinn, wenn man genug Erfahrung hat um zu wissen was etwa der spätere durchschnittliche Quantizer ist => sollte man meiner Ansicht nach nicht generell empfehlen

So wie die Curve Compression früher (pre 1.0) in Xvid war, war sie unverständlich und hat nur selten geholfen. Eine Curve Compression die mir Zonen und einem guten (wie auch immer aussehenden) HVS Model arbeitet wäre natürlich klasse.

"Ergebnis: die komplexe Szene sieht nicht wirklich schlechter, die einfache (dunkle) aber deutlich besser aus."
Das die dunkle Szene einen höheren Quantizer bekommt ist doch verständlich, da die Ratecontrol nach relativ kurzer Zeit wieder aus die durchschnittliche Datenrate kommen muss, das Material aber einfach zu komprimieren ist wird ein niedriger Quantizer verwendet. (<= früher war es auch schonmal so, dass hier trotzdem höhere Quantizer benutzt wurden, was dazu geführt hat, dass dunkle Szenen wirklich grottig aussahen)
Damit die komplexe Szene dann von der Ratecontrol noch akzeptiert wird muss der Quantizer niedriger sein,... (ist auch logisch)

Zu bedenken ist, dass die Ratecontrol auch durch das Profile (Stichwort: VBV) eingeschränkt ist.

=> Damit die Ratecontrol besser arbeiten könnte, müsste sie die Datenrate über einen wesentlich größeren Bereich verteilen dürfen, dies könnte aber Probleme mit etwaigen VBV Einschränkungen geben,...

Cu Selur

Ps.: Sorry, aber irgendwie ist mir nicht so ganz klar, was Du mit dem Beispiel eigentlich wirklich sagen willst,.. wie schon erwähnt überrascht mich die Verteilung der Quantizer nicht im Geringsten,..

@ Selur

Zitat

Warum ich eine Einschränkung auf Quantizer 3-8 für Unfug halte:
1. weil die meisten Encodes die ich habe durchaus Quantizer 2 benutzen

Du hast schon gesehen, dass ich mich hier speziell auf SixOfNine bezogen habe, ja?

q3(6of9) ~ q2(standard) ...

Und mit 6of9 kriegen die ganz kritischen Szenen halt q2 verpasst - ähnlich gut wie q1(standard), aber immer noch billiger.

Oh, und für solche Fälle (schwierige dunkle Szenen) sind natürlich die Standard-Bframe-Settings von 1.50/1.00 nicht gut, gar nicht gut ... ich hab da meistens 1.63/0.00 drinstehen. B=P+1 ist in diesem Bereich viel verträglicher als B=P+2

Zitat

2. ich wenn ich Custom Matrizen benutze öfters auch mal eine viel weitere Streuung der Quantizer habe

Echt? Komisch, kann ich so nicht unbedingt bestätigen ... Wenn Dir die reine Benutzung einer Custom Matrix eine eher große Streuung der Quantizer beschert, dann solltest Du vielleicht Deinen 1st-pass mit einem anderen Quantizer als "2" machen, oder doch noch ein wenig mehr Üben mit dem Overflow Treatment /*duck-und-wegrenn*/

Zitat

So wie die Curve Compression früher (pre 1.0) in Xvid war, war sie unverständlich und hat nur selten geholfen.

Am Grundprinzip hat sich aber, meines (Un)wissens nach, seit DevAPI3 nix Wesentliches geändert. Daran 'rumgefeilt wurde wohl schon, aber im Prinzip ist's noch immer die gleiche Methode. Deswegen wäre mir Foxer's Variante ja auch lieber gewesen ... aber es war wohl keiner mehr da, der den Code noch verstanden hätte ...

Zitat

Das die dunkle Szene einen höheren Quantizer bekommt ist doch verständlich, da die Ratecontrol nach relativ kurzer Zeit wieder aus die durchschnittliche Datenrate kommen muss, das Material aber einfach zu komprimieren ist wird ein niedriger Quantizer verwendet. (<= früher war es auch schonmal so, dass hier trotzdem höhere Quantizer benutzt wurden, was dazu geführt hat, dass dunkle Szenen wirklich grottig aussahen)
Damit die komplexe Szene dann von der Ratecontrol noch akzeptiert wird muss der Quantizer niedriger sein,... (ist auch logisch)

Entschuldigung, aber *das* ist jetzt Unfug. Und, hast Du nicht irgendwie "hoch" und "niedrig" verwechselt ... ?

(Profile und erlaubte Puffer übergehen wir hier mal. Sind für SAPs natürlich wichtig, aber hier geht's ums *Prinzip*, und nicht um Hardware-Einschränkungen.)

Sowas wie "durchschnittliche Datenrate" wird doch von der Ratecontrol bei 2-pass überhaupt nicht angestrebt! Beim Start des 2. Durchganges knobelt XviD erst mal den "theorethischen average Quantizer" aus - für den *ganzen* Clip, über *alle* Frames. Dann wird, im Prinzip, jeder Frame mit dem nächstliegenden ganzzahligen Quantizer kodiert. Dabei treten natürlich Abweichungen auf, wegen dem (offensichtlichen) Unterschied [ganzzahliger Quantizer] <--> [gebrochen rationaler (theoretischer) Quantizer], und wegen dem unvermeidlichen Abschätzungsfehler [Framegröße(Quant-X)] --> [Framegröße(Quant-Y)]. Und diese Abweichungen werden vom Overflow Treatment korrigiert. Dabei ist die Quantizer-Streuung aber nur selten größer als +/- 1 (für P-Frames. Für B-Frames natürlich auch mehr.)
Interne "Sonderregelungen" gibt's nur für *sehr* kleine Frames - sprich: komplett-schwarze Frames, und quasi-Duplikate. Die kriegen, glaub' ich, von Haus aus kleine Quantizer. Aber um diese Frames geht's ja auch gar nicht.

Jedenfalls, *im Durchschnitt* wird versucht, eine konstante Quantisierung mit möglichst geringer Fluktuation der verwendeten Quantizer zu erreichen. Und genau das zeigt doch mein kleines Beispiel: ohne CurveCompression wird alles mit dem Durchschnitts-Quantizer kodiert. Mit Compression wird Datenrate von den Reichen abgezwackt (die können's verschmerzen), und den Armen gegeben (die können's brauchen).

Klartext:

Keine Curve compression:

Dunkel: q4-q5-q4-q5-...
Hell: q4-q5-q4-q5-...

Mit Curve Compression:

Dunkel: q3-q3-q3-q3
Hell: q5-q5-q5-q5

==> Ich versteh' nicht, was man daran nicht verstehen kann ...

Natürlich war das hier ein extremes (und extrem kurzes) Beispiel - der mittlere Quantizer-Bereich (q4) wurde ja gar nicht genutzt. In der Praxis jedoch gibt das, mit Curve Compression, eine schöne Glocken-Kurve über den verwendeten Quantizer-Bereich. Ohne Curve Compression gibt's meistens nur 'ne Bohnenstange, mit kleinen Standfüßchen links und rechts.

Zitat von namor82

Habe das jetzt runtergeladen und mit 2% getestet...
Was soll ich denn das bei 1st pass und 2nd pass für Einstellungen nehmen ?
Vor allem beim Quantizer...
Soll man da "Weight = 1 " nehmen oder festen Quantizer ? Wenn ....

Nein.

Du wills ein Video (nur Video) von 600 MB haben, per 2-pass. Du willst vorher schon wissen, wie groß -in etwa - der durchschnittliche Quantizer sein wird.

Also machst Du mit enc kurze Tests, z.B. 2%, mit festem Quantizer (über zones), und kriegst zum Beispiel solche Abschätzungen von enc:

q2 -> 900 MB
q3 -> 650 MB
q4 -> 550 MB

Dann würde man stark vermuten, dass der avg.Quantizer am Ende knapp über "3" liegen wird.

Zitat

Besides:
Wie kriege ich denn so eine hübsche grafische Darstellung hin wie du z.B. ?

"DivX DRF Analyzer". Dr. Google weiss bescheid

***

Verziehe mich bis morgen in die Internet-freie Zone

"Standard-Bframe-Settings von 1.50/1.00 nicht gut,"
ich hab auch nicht die Standardsettings,..

"Wenn Dir die reine Benutzung einer Custom Matrix eine eher große Streuung der Quantizer beschert,..."
Das hab ich nicht behauptet, sondern Du.
Persönlich sehe ich eine große Streuung auch nicht als etwas negatives an,..
(ich benutz übrigends meist als profile: unrestricted )

"Am Grundprinzip hat sich aber, meines (Un)wissens nach, seit DevAPI3 nix Wesentliches geändert."
Nein, leider nicht, da sich aber einiges am 1st Pass geändert hat,...

"Deswegen wäre mir Foxer's Variante ja auch lieber gewesen ..."
Mir auch.

Zitat

Entschuldigung, aber *das* ist jetzt Unfug. Und, hast Du nicht irgendwie "hoch" und "niedrig" verwechselt ... ?

Yup

hier korregiert:

Zitat

Das die dunkle Szene einen niedrigeren Quantizer bekommt ist doch verständlich, da die Ratecontrol nach relativ kurzer Zeit wieder aus die durchschnittliche Datenrate kommen muss, da das Material aber einfach zu komprimieren ist wird ein niedriger Quantizer verwendet. (<= früher war es auch schonmal so, dass hier trotzdem höhere Quantizer benutzt wurden, was dazu geführt hat, dass dunkle Szenen wirklich grottig aussahen)
Damit die komplexe Szene dann von der Ratecontrol noch akzeptiert wird muss der Quantizer niedriger sein,... (ist auch logisch)

Zitat

Sowas wie "durchschnittliche Datenrate" wird doch von der Ratecontrol bei 2-pass überhaupt nicht angestrebt!

Doch, da die Abschätzung des durchschnittlichen Quantizers direkt mit der Datenrate zusammenhängt und auch die späteren korrekturen orientieren sich an der Datenrate, die die Quantizer haben sollen,...

Zitat

Jedenfalls, *im Durchschnitt* wird versucht, eine konstante Quantisierung mit möglichst geringer Fluktuation der verwendeten Quantizer zu erreichen.

Umpf, der durchschnittliche Quantizer gehört aber zu einer durchschnittlichen Datenrate, die nach einer gewissen Zeit wieder erreicht sein muss.

Warum habe ich eigentlich den Eindruck, dass Du irgendwie denkst ich hätte was gegen Curve Compression ?

Cu Selur

Ps.: denke die Fragen von narmor82 gingen an Dich

Moin,
das Programm DivX DRF Analyzer gibts übrigens hier:
http://www.geocities.com/analyzerdrf/index.html
Das kann ich grade gut brauchen: Ein paar aufgenommene Folgen werden trotz ausreichend Bitrate suboptimal - vielleicht kann ich mir mit dem Programm ein bischen Übersicht verschaffen, was der Codec da tut...

Ansonsten wie immer: Danke für die vielen Erklärungen!

Könnte man diese Diskussion abtrennen und unter einem deskriptiviren Namen, wie z.B. Curve Compression oder was auch immer einstellen? Wäre dann leichter wiederzufinden...

So, dann werf ich mal ein rotes Tuch in die Runde - und entschuldige mich schon vorher, da die Behauptung vermutlich falsch ist, aber irgendwie drängt sich die Frage grade wieder mal auf:
Ist 2-Pass-Encoding dann noch sinnvoll, wenn man Serien encodet und es einem nicht auf die Größe der einzelnen Folgen ankommt, sondern nur auf den Durchschnitt (z.B. etwa 10 Folgen zusammen)?
Ich verwende auch 2-Pass, weil ich dachte, daß der Codec noch mehr Informationen im 1.Pass sammelt und die Qualität dann tatsächlich besser wird. Aber dann könnte man statt dessen doch auch mit konstantem Quantizer (z.B. q3 oder q4) encoden, oder? Das ist doch das, was Codec sowieso versucht aber manchmal halt nicht ganz hinbekommt? Oder sammelt der Codec doch im 1.Pass sinnvolle Informationen? Oder tut er das nur, wenn man CC benutzt?

Zitat

Ist 2-Pass-Encoding dann noch sinnvoll, wenn man Serien encodet und es einem nicht auf die Größe der einzelnen Folgen ankommt, sondern nur auf den Durchschnitt (z.B. etwa 10 Folgen zusammen)?

Ja. Da Du ja wahrscheinlich nicht willst, dass Du bei Folge 6 z.B. schon 90% des Platzes verbraten hast,...

Curve Compression wird immer verwendet, wenn man nicht mit einem konstanten Quantizer encoded. Mit den Einstellungen im Encoder kann man nur Einfluß auf die Compression nehmen, aber eine generelle Curve Compression findet immer statt.

Cu Selur

Zitat von Trekkie2

Ist 2-Pass-Encoding dann noch sinnvoll, wenn man Serien encodet und es einem nicht auf die Größe der einzelnen Folgen ankommt, sondern nur auf den Durchschnitt (z.B. etwa 10 Folgen zusammen)?

Wenn du Serien encodest würde ich dir prinzipiell zu folgendem raten:
Angenommen du verteilst die Staffel z.B. auf 3DVDs, encodest du am besten 7-8 Episoden am Stück.
D.h. du fügst sie mit avisynth zu einem großen video zusammen und stellst eben z.B. im 2nd pass die Größe einer DVD - Audio ein.
So bekommst du über alle Folgen im Schnitt ausgewogenere Qualität, da die einzelnen Folgen zum Teil sehr stark im Platzbedarf schwanken.:)