=> Wissenswertes rund um Xvid <=

Dank an [Blockierte Grafik: http://members.aol.com/jefftube3/images/MRBIG.JPG]

Hallo

Zunächst mal vielen Dank für den Guide, ohne den der Einstieg in XviD wesentlich schwerer gefallen wäre. Und da du ja ein Feedback wünschst, hier meine Gedanken zu XviD im Allgemeinen und zu dem Guide im Besonderen, die mir während der letzten Wochen gekommen sind. Ist was länger geworden.

Matrix: H.263- und MPEG-Matrix
Wie sehen die eigentlich aus. Bei den mitgelieferten Matrizen ist eine Standard-Matrix, die enthält aber andere Werte, wie die, die nach der Installation im Edit-Dialog angezeigt werden. Ist eine von denen die H.263-Matrix? Und die MPEG.txt enthält die Standard-MPEG-Matrix?

Hilfreich wäre es, wenn bei jeder Einstellung gesagt würde, ob sie zwischen 1st- und 2nd-Pass geändert werden darf. (Besser wäre es natürlich, wenn in einer zukünftigen XviD-Version alle Einstellungen, die der 2nd-Pass vom 1st-Pass übernehmen muss, in einen Header der video.pass geschrieben, und im Dialog dann für den 2nd-Pass grau angezeigt würden.) Zur Zeit probiere ich gelegentich rum, ob eine geänderte Einstellung eine andere video.pass Datei liefert oder nicht. Das macht mich nicht immer schlauer. Beispiel: Änderung der Matrix (H.263 auf MPEG), die video.pass-Dateien sind gleich, obwohl es laut XviD-Status eine unterschiedliche Anzahl von P- und B-Frames gibt, das passt nicht zusammen, denn P- und B-Frames werden in der video.pass gespeichert.

Quarter-Pixel:
Aus dem Official DivX-Guide (oder so ähnlich):
"By increasing the accuracy of the motion vectors quarter-pixels also increases the bit spend on predicted frames. The result can actually be detrimental to quality at low bitrates. Although the motion compensation will be more accurate and the picture will appear sharper, fewer free bits will cause the rate control to enforce higher quantizers throughout the video."
Also: Quarter-Pixel benötigt zusätzliche Bits für die feinere Motion-Compensation, die dann für den eigentlichen Codiervorgang fehlen, was zu etwas höheren Quantizern für das gesamte Video führt, das dafür aber etwas schärfer wirkt. Klingt plausibel und sollte eigentlich auch für XviD gelten. Gemessen habe ich bis jetzt nur (in sage und schreibe zwei Versuchen) um 1-2% niedrigere Quantizer ohne Quarter-Pixel.

GMC:
Das klingt ja fast so, als fände eine echte Bewegungsanalyse statt, also zum Beispiel: roter Ferrari überfährt Frau mit rotem Kleid und flüchtet links aus dem Bild. Wenn ich mich recht an das irgendwann mal gelesene und längst wieder vergessene erinnere, werden bei der GMC doch nur die Verschiebungen von 16x16 Pixel großen Makroblöcken untersucht, das heißt, es wird ein möglichst ähnlicher Makroblock gesucht; wie soll das dann mit Drehungen und Verzerrungen funktionieren? Für den Codec ist es doch völlig egal (so habe ich es verstanden), wozu ein Makroblock gehört. Die Szene könnte für den Codec also auch heißen: roter Ferrari überfährt Frau, verwandelt sich dabei in ein rotes Kleid, roter Wollhase materialisiert und hüpft verschreckt links aus dem Bild. Bei DivX war ein Tool, damit konnte man sich die Bewegungsvektoren anschauen, das sah zwar weitestgehend systematisch aus, aber immer wieder sprangen die Vektoren auch kreuz und quer über das Bild, ohne irgendeinen erkennbaren Zusammenhang zum Inhalt des Videos.

B-Frames:
Ich wüsste gerne einmal, warum man für B-Frames "schlechtere" Quantizer wählt wie für die anderen Frames. Wenn ich B-Frames zulasse, besteht doch der größte Teil des Videos daraus, ich muss sie mir doch auch ansehen. Benötigten sie bei gleicher "gefühlter" Qualität keinen so niedrigen Quantizer? Oder kommen die besseren Quantizer der I- und P-Frames, auf die sie sich ja beziehen, ihnen auch zugute? (Beziehen sie sich eigentlich auch auf die P-Frames, oder nur auf die I-Frames? Was sind eigentlich S-Frames? Erscheinen im XviD-Statusfenster, wenn man die Details anzeigen lässt.) Ich verwende im Moment (ich experimentiere noch rum): max cons. BVOPs=30-50, ratio=1.0-1.4, offset=0.0-0.25, sensitivity=50. 75-80% aller Frames sind so B-Frames. Ich versuche eine Einstellung zu finden, bei der für alle Frametypen ähnliche durchschnittliche Quantizer angezeigt werden, ist das sinnvoll? Ich tue mich schwer, einen Unterschied zu den Standardeinstellungen festzustellen- beim Betrachten, der XviD-Status zeigt natürlich was anderes an. Was mich interessiert: Warum sind die Standardeinstellungen empfehlenswert? Weiter hinten outest du dich ja selbst, das du völlig andere Einstellungen verwendest.

Packet-Bitstream:
Wenn ich das deaktiviere, zeigt mir VirtualDubMod beim Öffnen eine Fehlermeldung beim ersten Frame an: "Warning: Nothing to output. BFrame Decoder Lag". Ein Bild vor und wieder zurück und der Fehler ist weg. Ich meine zumindest, es hätte an dieser Einstellung gelegen.

Twopass - 1st-Pass:
Sind die Einstellungen, die du hier erwähnst, die, die zwischen 1st- und 2nd-Pass geändert werden dürfen? Und natürlich die unter 2nd-Pass/more.

I-Frames closer than ... (Frames):
Woraus folgt denn, dass ein Wert von 1 das Feature deaktiviert? Ich verstehe den Tooltip so, dass bei einem Wert von 1 nur unmittelbar aufeinander folgende I-Frames reduziert werden (ausser dem letzten), sobald ein anderer Frame zwischen je zwei I-Frames ist, werden die I-Frames nicht reduziert.

Overflow-Treatment:

Overflow-Control-Strength:
0=let XviD decide. Wieso ist dann aber 5 die Standardeinstellung? Was genau bedeutet 0: Die Bitverteilung erfolgt genau so, wie im 1st-Pass von XviD berechnet, oder erfolgt eine Umverteilung gegenüber dem 1st-Pass nach einer intern in XviD definierten Regel (so verstehe ich die Bedeutung von core im Tooltip, ansonsten würden ja auch die nachfolgenden beiden Einstellunge keinen Sinn machen).

Max Overflow improvement/degradation:
Könnte es sein, das die Erklärungen vertauscht werden müssen? Improvement soll undersized files vorbeugen, Einsparen von Bits bei gut zu komprimiernden Szenen produziert aber zunächst mal undersized files; und umgekehrt bei degradation.

Zones:

Begin with Keyframe:
Auch hilfreich, wenn man z.B. mehrere Folgen einer Serie auf eine CD bringen will: Man stückelt sie mit einem AVISynth-Script aneinander und läßt sie alle in einem Aufwasch von XviD kodieren. Anschließend schneidet man sie mit VirtualDub an den Keyframes wieder auseinander. Auf diese Weise sollte man eine konstante Qualität über alle Folgen bekommen. Ich habe das bei Coupling in den letzten Wochen so gemacht, die Größe der einzelnen Folgen differierte um bis zu 65MB bei ca. 235MB pro Folge im Schnitt.

Das wars dann erst mal

Tschüß

Hilfe... [Blockierte Grafik: http://www.cheesebuerger.de/smilies/verbluefft/50.gif] 
__

Ob es eine H.263-Matrix gibt, hab ich auch schon mal im englischen doom9-Forum gefragt. Antwort dort: Die H.263-Quantisierung funktioniert mit einer anderen Rechenvorschrift, Matrix-Darstellungen sind da so gut wie nicht möglich.

"Global Motion Compensation" untersucht, ob sich der Bildinhalt insgesamt in die gleiche Richtung bewegt (z.B. Kameraschwenk, bei 3-Warppoint-GMC - wie in XviD - auch Zoomen und Verdrehen). Motion-Vektoren für einzelne Objekte berechnen sich dann als Differenz zur Gesamtbewegung des Bildinhaltes.

"I-Frames closer than..": Wie viele Frames sind denn "näher als 1 Frame"? Richtig, 0.

Matrizen:
Wie hast du denn die video.pass-Dateien verglichen?
Die Größe müsste gleich sein, der Inhalt aber nicht.

Packet-Bitstream:
Da die VfW-Schnittstelle (wird auch von VDub benutzt) nicht mit B-frames umgehen kann, muss das anders geregelt werden.
Dazu gibt es zwei Möglichkeiten:
- encoder (Packed-Bitstream)
- decoder
Eine gute Erklärung findest du hier

Danke schon mal für die Antworten.

Manchmal ist wirklich der Wurm drin. Eigentlich wollte ich nur den Tip geben, in dem Guide bei jeder Einstellmöglichkeit anzugeben, ob man sie zwischen den beiden Durchläufen ändern darf oder nicht. Aus dem Aufbau der Konfigurationsdialoge geht das nämlich nicht hervor. Nur um sicher zu gehen (ich könnte ja sonst irgendeinen Müll erzählen) habe ich noch einen Test gemacht. Von Quarter-Pixel wußte ich schon, daß es die video.pass nicht verändert, von der Matrix habe ich eben dies aber stark vermutet. Und was teste ich? Weil Rechenzeit bei Videocodierung ja überhaupt kein Thema ist, noch mal Quarter-Pixel. Zum Glück protokolliere ich meine Fehler auch brav, sonst wüsste ich immer noch nicht, was ich gestern falsch gemacht habe. Selbstverständlich korrigiere ich hiermit auch meine Aussage von gestern, daß mich ein Vergleich der video.pass Dateien (übrigens mit fc am DOS-Prompt) nicht wirklich schlauer macht, das galt nur gestern Nacht. Immerhin zeigt der Vorgang, wie nützlich mein Tip ist, zumindest für mich.

Und den Vorschlag, die im 2nd-Pass besser nicht zu ändernden Einstellungen in einen Header der video.pass zu übernehmen, halte ich nach wie vor für gut. Die Option kann ja abschaltbar sein, die Versionsnummer wird selbstverständlich mit reingeschrieben. Aber wer wartet denn schon zwischen 1st- und 2nd-Pass auf die nächste XviD-Version, die Entwickler vielleicht mal ausgenommen.

GMC:
LigH
Stimmt, ich hatte GMC mit der grundsätzlichen Bewegungsanalyse für den einzelnen Makroblock verwechselt und an Rotation und Verzerrung dieser Blöcke gedacht, nicht an die Bewegung ganzer Blockgruppen (Objekten).

Aber über die Interna des MPEG-Standards weiß ich sowieso nicht viel, außer, daß eine solche Analyse durchgeführt wird.

Selur
Verwechselst du das jetzt gerade auch? Oder meinst du die Gesamtbewegung vieler Makroblöcke?

B-Frames:
Noch mal zur Sicherheit: B-Frames haben trotz eines höheren Quantizers für den Betrachter dieselbe Qualität; das ist bewiesen worden in ausgiebigen Versuchsreihen mit Leuten mit besonders geschultem Blick? Wieso bevorzugst du dann auch die Einstellungen 1.0 für ratio und 0.0 für Offset? Damit haben die Quantizer der B-Frames ja im Prinzip denselben Wert, wie die der angrenzenden P- oder I-Frames. Hast du das Gefühl, das das Video dadurch besser wird? Ich find es schwierig, überhaupt Unterschiede zu erkennen.

Ich versuche mich mal mit meinem bischen MPEG-Wissen anzunähern, vielleicht liege ich ja richtig: Der Encoder versucht festzustellen, ob ein bestimmter Makroblock durch eine Bewegung aus einem Makroblock des oder der Bezugsframes hergeleitet werden kann, von zusätzlichen Einsparmöglichkeiten jetzt mal abgesehen:

Ja -> nur der Bewegungsvektor wird gespeichert, der wird aber nicht quantisiert(?). Die Bildinformation für diesen Makroblock stammt also aus dem Bezugsframe.

Nein -> Der Makroblock wird wie üblich codiert, mit dem Quantizer, der sich aus den Einstellungen für B-Frames ergibt.

(Ich glaube, es gab da noch ein Mittelding, habe ich aber wieder vergessen und lassen wir erst mal weg.)

Beim Betrachten eines B- oder P-Frames sehe ich also Makroblöcke, die mit dem Quantizer für den betrachteten B-Frame quantisiert wurden, und ich sehe Makroblöcke, die mit dem Quantizer für die angrenzenden P- oder I-Frames quantisiert wurden. Ich kann also für B- und P-Frames im Prinzip zwei Durchschnittswerte angeben, einen für die tatsächlich im betreffenden Frame codierten Blöcke (Wert1), und einen für alle Blöcke (Wert2).
Welchen Wert zeigt XviD im Statusfenster an? Ich vermute mal Wert1.
Bei den Standardeinstellungen für B-Frames ist Wert1 immer schlechter als Wert2, in den ja noch die qualitativ besseren Blöcke der angrenzenden Frames eingehen, und da B-Frames ja einen besonders hohen Anteil an Bewegungsvektoren enthalten.
Trifft diese Erklärung zu, dann sind mir auch die Standardeinstellungen von XviD klar: durch die Verwendung eines etwas schlechteren Quantizers für die paar Makroblöcke, die in einem B-Frame noch codiert werden müssen, verbessere ich gleichzeitig die Quantizer für I- und P-Frames, wovon letztendlich auch die B-Frames profitieren. Verändere ich aber die Einstellungen so, daß ich im Statusfenster ähnliche Durchschnittswerte für alle Frametypen habe, versaue ich mir im Prinzip den Schnitt für alle Frames, denn sowohl I- und P-Frames liegen jetzt höher, als auch der sich daraus ergebende tatsächliche Durchschnitt für die B-Frames.

Zeigt aber XviD den Wert2 an, sollte man doch versuchen, für alle Frames ähnliche Werte zu erreichen.

Nachdem ich mir das nun alles so schön zurecht gebastelt habe, dürft ihr jetzt wieder alles kaputtmachen. Ich sehe z.B. gerade, daß ich die Bemerkung über die Differenzdaten in P- und B-Frames völlig übersehen habe; aber wenn ich mich recht entsinne, war das das Mittelding, welches mir oben entfallen war: Makroblöcke, bei denen sowohl ein Bewegungsvektor, zusätzlich aber auch noch diese Differenzdaten gespeichert werden. Wahrscheinlich sind die meisten Makroblöcke von dieser Art. Stürzt jetzt mein Erklärungsgebäude, falls es überhaupt jemals stand, wieder ein, oder steht es nur ein bischen schief?

Was sind PSNR-Werte?

Wurde das mit den S-Frames überhaupt schon mal irgendwo erwähnt? Ich habe danach gesucht (hier im Forum), aber keine Treffer erhalten. Sollte vielleicht in den Guide.

I-Frames Closer Than ... (Frames):
Zugegeben, die Einstellung klingt, als ob meine Frage unsinnig wäre, aber der Tooltip gibt mir Recht: Use this to define how close must keyframes be to be reduced = Wie nahe beieinander müssen Keyframes sein, damit sie reduziert werden. Der von Frame x aus nächste Frame ist x+1.

Beispiele:
Einstellung=1 IIIIIIIIIII die ersten 9 Frames werden reduziert
Einstellung=1 IPIPIPIPIPI kein Frame wird reduziert
Einstellung=2 IPIPIPIPIPI die ersten 5 I-Frames werden reduziert
Einstellung=250 vermutlich alle I-Frames im Video außer dem letzten würden reduziert, klingt komisch, steht für mich aber da.

Das deckt sich im Übrigen auch mit deinem ersten Satz hierzu im Guide: "Hier kann man angeben, wie viele Nicht-I-Frames mindestens zwischen zwei I-Frames stehen müssen, damit das zweite I-Frames nicht weniger Datenrate erhält." Heißt: Stehen weniger Nicht-I-Frames dazwischen, werden die I-Frames außer dem letzten reduziert, bei 1 müssen die I-Frames also unmittelbar aufeinander folgen. Wie sollte ich sonst auch angeben können, das nur unmittelbar aufeinander folgende I-Frames reduziert werden.

Ich vermute, 0 deaktiviert die Einstellung. Wenn die Entwickler sagen, 1 deaktiviert sie, stimmt der Tooltip nicht und der Wert muß irgendwie anders interpretiert werden, oder ich verstehe es einfach nicht.

Overflow-Treatment:
Ich wollte auf den Widerspruch zwischen Tooltip und deiner Erklärung hinweisen:
Wenn die improvment Einstellung undersized-Files (also zu kleinen Dateien) vorbeugen soll, erreiche ich das nicht, indem ich zusätzliche Bits einspare, dann wird sie ja noch kleiner.
Ich gebe zu, die Tooltips sind mir in diesem Punkt am unverständlichsten. Overflow heißt doch, daß mehr Bits verbraucht werden wie geplant? Dann müsste in einem der Tooltips aber die Rede von 'Underflow' und 'waste Bits' sein, um also einem Underflow vorzubeugen, dürfen Bits verschwendet werden.
Ich hatte jetzt zwei Videos, bei denen eine deutlich höhere Datenrate wie eingestellt rauskam (über 3000 statt 2300 kBps); eine Erhöhung des degradation-Wertes auf 7 löste das Problem, also beugt diese Einstellung tatsächlich einem Overflow durch Einsparung von Bits vor..

Ich hoffe diese langen Postings stören niemanden, oder sollte ich das 'Hilfe' oben so interpretieren?

Tschüß

Zitat von 0815-0815

I-Frames Closer Than ... (Frames):
Zugegeben, die Einstellung klingt, als ob meine Frage unsinnig wäre, aber der Tooltip gibt mir Recht: Use this to define how close must keyframes be to be reduced = Wie nahe beieinander müssen Keyframes sein, damit sie reduziert werden. Der von Frame x aus nächste Frame ist x+1.

Beispiele:
Einstellung=1 IIIIIIIIIII die ersten 9 Frames werden reduziert
Einstellung=1 IPIPIPIPIPI kein Frame wird reduziert

Ich dachte da bisher immer:

1: IIIIIIIIIIII
2: IiIiIiIiIiIi
3: IiiIiiIiiIii
4: IiiiIiiiIiii

Sollte ich mich da geirrt haben? Aber finde mal Quellen, die dutzende "consecutive I frames" provozieren; Flimmern, vielleicht.

Zitat

Ich hoffe diese langen Postings stören niemanden

Nö, ich find den Thread richtig interessant. Mein "Durchblick" hat sich wieder etwas erhöht. :seher:

So, ich bin etwas früher wach geworden.

Zu den Features die gewechselt werden dürfen:

Es scheint aber so zu sein, das man auch andere Einstellungen bedenkenlos zwischendurch ändern darf, die nicht deaktiviert werden: z.B. Quarter-Pixels, das habe ich jetzt zwei- dreimal getestet, ändert nicht die video.pass, vermutlich auch Adaptive-Quantization und GMC (nicht getestet); die Matrix-Einstellungen imselben Dialog darf man aber nicht ändern (getestet), vermutlich auch nicht die B-VOP-Einstellungen. Auch bei den Advanced-Options habe ich noh nicht getestet, ob ich die Einstellungen zwischen den Durchläufen ändern darf. Max I.Frame-Interval vermutlich nicht, VHQ-Mode möglicherweise ja, sonst müßte ja der 1st-Pass länger dauern, ich habs aber noch nicht getetest. Das meinte ich damit, daß aus den Dialogen nicht klar wird, welche Einstellungen zwischendurch nicht geändert werden sollten. Aber wie du schon gesagt hast, XviD ist ja nur zum Testen da.

I-Frames Closer Than ... (Frames):

Ich denke endgültige Klärung schafft nur ein Blick in den Quellcode. Ich bezweifle, daß ich das könnte - reingucken schon, aber auch verstehen?

LigH

Die kleinen i's sollen I-Frames mit reduzierter Datenrate sein? Aber wieso sollten in einer Folge von I-Frames dann mittendrin wieder I-Frames mit voller Datenrate codiert werden? Sinnvoll wäre es möglicherweise schon, bei zu vielen, aber wie folgt das aus dem Einstellungsdialog?

Bei DivX hatte ich schon mal viele I-Frames in Folge, komischerweise bei völlig ereignislosen dunklen Szenen, bei XviD bis jetzt noch nicht.

Selur

Ich sagte ja schon, wenn ich den Namen für die Einstellung zugrunde lege - im mathematisch korrekten Sinn, also < nicht gleich <= setze -, habe ich Unrecht. Umgangssprachlich macht man da aber für gewöhnlich keinen Unterschied. Ich denke der Name wurde gewählt, weil man zum einen eine aussagekräftige Bezeichnung mit dem Namen der nachfolgenden Einstellung schaffen konnte, zum anderen aber nicht schreiben wollte "closer than or in the distance of ...", was, wenn ich Recht habe, mathematisch korrekt aber schwerfällig wäre.

Wenn ich den Tooltip zugrunde lege, habe ich Recht. Ich wiederhole noch einmal: "Use this to define how close must keyframes be to be reduced" = Wie nahe beieinander müssen Keyframes sein, damit sie reduziert werden. Zwei benachbarte Frames haben den Abstand 1, nicht 0! Bei der Einstellung 1 wird ein I-Frame also nur reduziert, wenn der unmittelbar folgende Frame auch ein I-Frame ist, weil sich der im Abstand 1 befindet. Bei der Einstellung 2 wird ein I-Frame reduziert, wenn der nächste oder übernächste Frame ein I-Frame ist.
Würde 1 diese Einstellung deaktivieren, könnte ich unmittelbar aufeinander folgende Frames nicht mit reduzierter Datenrate berechnen lassen, aber gerade da macht es am meisten Sinn und vermutlich ist es deshalb auch die Standardeinstellung. Deaktiviert würde die Einstellung automatisch durch den Wert 0, da sich zwei verschiedene Frames nicht im Abstand 0 befinden können, also auch nie eine Reduzierung stattfindet.
Die Entwickler können sich auch nicht jede Einstellung merken, die sie irgenwann mal irgendwo in den Quellcode geschrieben haben, vor allem wenn es eher Kleinkram ist. Ich benutze diese Einstellung ohnehin nicht, die I-Frames liegen bisher alle weit auseinander.

Sollte ich tatsächlich Unrecht haben, führt der Tooltip komplett in die Irre. Oder ich bin nicht mehr der deutschen Sprache fähig; ähem: oder der englischen Sprache? Ein Übersetzungsproblem scheint mir aber nicht vorzuliegen.

B-Frames:

Doch, ich glaube wir sind fast zusammengekommen und die wesentlichen Aussagen, die ich daraus gezogen habe, hast du ja bestätigt. Ich versuche das obige Beispiel noch etwas detaillierter zu formulieren. Ich gestehe, daß ich mir das alles selber erst zwischen diesen Postings so gründlich durch den Kopf gehen lasse. Dabei versuche ich mich an Texte zu erinnern, die ich vor ca. einem halben Jahr darüber gelesen habe, und die ich mir vielleicht noch mal antun sollte. Und so logisch mir das alles erscheint, vielleicht bin ich ja völlig auf dem Holzweg.

Vorab: Es ist doch richtig, das nicht die Frames als ganzes quantisiert werden, sondern nur die einzelnen Makroblöcke, dafür hat man sie ja erfunden. Und das innerhalb eines Frames jeder Makroblock einen anderen Quantizer haben kann. Ich gehe zumindest davon aus.
Außerdem bin ich mir nicht ganz sicher: kann sich ein einzelner Makroblock auf beide Bezugsframes beziehen, also zwei Bewegungsvektoren haben? Ich war der Meinung, daß zwar der B-Frame selbst sich auf zwei Frames bezieht, die einzelnen Makroblöcke sich aber nur aus jeweils einem dieser beiden Frames herleiten lassen. Das ist aber für das Folgende nicht so wichtig.

Nehmen wir an, wir haben einen Nachrichtensprecher vor einem statischen Hintergrund; auch der Sprecher ist statisch, nur der Mund bewegt sich, und die Augen, sonst könnte er nicht vom Teleprompter ablesen. Das Video ist absolut rauschfrei. Wir haben drei Frames: P1 B P2. P1 und P2 sind schon berechnet, mit konstantem Quantizer 2 für alle Makroblöcke. Für B-Frames ergäbe sich ein Quantizer 4.
Der Encoder macht sich jetzt an die Berechnung von B. Dabei stellt er fest, das fast alle Makroblöcke sich durch eine direkte Verschiebung aus Frame P1 herleiten lassen (Verschiebung ist zwar 0, aber das muß ja auch abgespeichert werden). Er könnte auch bei P2 nachgucken, aber wozu, wenn er bei P1 schon Treffer landet. (Möglicherweise trifft diese ideale Annahme in einem realen Video nie ein, es geht mir im Moment nur darum, ein sehr vereinfachtes Modell zu verstehen.) Er speichert für diese Makroblöcke also nur die Bewegungsvektoren ab, da wird nichts quantisiert, die Quantisierung fand ja schon in P1 statt, wo bei der Darstellung diese Makroblöcke hergeholt werden.
Dann kommt er zu den Makroblöcken für Augen und Mund und stellt fest, das Bewegungsvektoren nicht mehr reichen. Meine erste Annahme oben ging davon aus, daß er diese Blöcke komplett neu codiert. Mittlerweile ist mir wieder klar, daß er sich diese Makroblöcke aus Bewegungsvektoren plus Differezinformation zusammenbasteln kann. In beiden Fällen muß dieser Block aber quantisiert werden, der Quantizer ist im Beispiel 4.
So, nun kann XviD den durchschnittlichen Quantizer für diesen Frame berechnen. Am schnellsten geht es, wenn es nur die aktuell im B-Frame quantisierten Makroblöcke berücksichtigt, die summiert es während der Berechnung nur auf und teilt am Ende durch die Anzahl. Das ist der von mir oben genannte Wert1. Oder es berechnet den Durchschnitt über alle Blöcke des Frames, dann müsste es aber für jeden verschobenen Block die Quantizer-Informationen aus den Bezugsframes wieder abrufen. Außerdem müsste es bei Blöcken mit Differenzinformationen irgendeine Gewichtung einführen zwischen den Quantizern der Originalblöcke in den P-Frames, und dem Quantizer für die Differenzinformationen, denn die haben ja beide Einfluss auf die Bildqualität: viel zu kompliziert und langsam. Ich gehe also davon aus, das XviD mir den Wert1 anzeigt.

Nehmen wir an, der Frame hat 100 Makroblöcke (ist nur ein kleiner Nachrichtensprecher), davon 10 für Mund Augen (hat halt einen großen Mund). Wert1 wäre 4 (10 Blöcke mit Quantizer 4 macht einen Schnitt von 4). Der tatsächliche Durchschnitt wäre (ich sehe mal von dem angesprochenen Gewichtungsfaktor ab): (10 Blöcke * Quantizer 4 + 90 Blöcke * Quantizer 2)/100 Blöcke = Quantizer 2.2.
Setze ich jetzt die Einstellungen für B-Frames so das B-Frames mit Quantizer 3 berechnet würden und nehmen wir an, daß dann I- und P-Frames nur noch mit Quantizer 2.5 berechnet werden könnten ergäbe sich:
Für Wert1 =3 (10 Blöcke mit Quantizer 3/10 Blöcke), scheinbar eine Verbesserung, tatsächlich aber: (90 Blöcke * 2.5 + 10 Blöcke * 3)/100 Blöcke = 2.55, also eine Verschlechterung.
Wenn aber der Quantizer für I- und P-Frames nur auf 2.05 steigen sollte, ergäbe sich für den tatsächlichen Wert: (90 * 2.05 + 10*3)/100 = 2.145, also eine wirkliche kleine Verbesserung.

Diese Überlegung bezog sich nur auf einen einzelnen Frame, das XviD-Statusfenster zeigt aber die Ergebnisse über alle Frames an, an der Aussage sollte sich dadurch aber nichts ändern.
Meine Beispieldaten sind natürlich völlig aus der Luft gegriffen. Mich würde interessieren, ob sich die Standardwerte aus dem mathematischen Algorithmus als optimal ergeben, indem man irgendwelche statistischen Angaben über durchschnittliche Videoclips in die Formeln einsetzt, oder ob das Betrachten zahlreicher Videoclips die Grundlage für die Standardeinstellungen war. Ist aber nicht so wichtig.

PSNR:

Ich wußte doch, das mir die Abkürzung SNR bekannt vorkam. Wofür steht noch das P? Findet wirklich so etwas wie ein Entrauschen bei der Codierung statt, als nützlicher Nebeneffekt oder so?

Overflow-Treatment:

Control-Strength war mir klar.

Improvement/Degradation:

Du zitierst genau den Satz, bei dem ich meine Zweifel an der Richtigkeit geäußert habe: "How much of the overflow the codec can eat into during ...". Wenn es das heißt, was ich meine, nämlich das Wegnehmen von Bits, weil schon zu viele verbraucht wurden, dann muß (!) in einer der beiden Einstellungen dies durch eine Formulierung wie "How much of the Underflow the codec can waste ...", also: wie viele Bits zusätzlich verschwendet werden dürfen, weil ohnehin zu wenige verbraucht wurden, ersetzt werden, da beide Einstellungen ja gegensätzliche Wirkung haben sollen.

Bei der improvement-Einstellung steht aber ganz klar, daß es um das Vermeiden von "undersized files" geht, also zu kleinen Dateien, und bei der degradation-Einstellung um das Vermeiden von "oversized-files" geht, also zu großen Dateien. Ich erreiche ersteres nicht, indem ich Bits einspare, und letzteres nicht, indem ich zusätzliche Bits einsetze. Das ist kontraproduktiv. Umgekehrt würde es stimmen. Hier liegt ganz klar ein Widerspruch vor. Ich bin mir ziemlich sicher, das die Erklärungen im Guide vertauscht gehören und der Tooltip, auf den du dich berufst fehlerhaft ist. Sehe wirklich nur ich diesen Widerspruch, habe ich da ein Brett vor dem Kopf?

Tschüß

Zitat von 0815-0815

Der Encoder macht sich jetzt an die Berechnung von B. Dabei stellt er fest, das fast alle Makroblöcke sich durch eine direkte Verschiebung aus Frame P1 herleiten lassen ....Er speichert für diese Makroblöcke also nur die Bewegungsvektoren ab, da wird nichts quantisiert, die Quantisierung fand ja schon in P1 statt, wo bei der Darstellung diese Makroblöcke hergeholt werden.

Hallo,

ist es wirklich so, daß nichts quantisiert wird? Wird nicht eine Differenz zwischen den verschobenen Makroblöcken und dem neu zu encodierenen Quellbild erzeugt, und dieses Differenzbild neu encodiert? Sind verschobener Makroblock und neues Quellbild identisch, ergibt sich zwar leerer Block (da Differenz=0), so daß nach der DCT nur bestens quantisierbare Nullen drin stehen, aber diese werden doch trotzdem neu quantisiert, auch wenn null rauskommt. Und wenn Quantisiert wird, gibt es doch auch einen Quantizer, der sich bei B-Frames durch die gewählten Werte für "Quantizer Ratio" und "Quantizer Offset" beliebig beeinflussen läßt.

Gruß

akapuma

Jau schon passiert.Besser so?