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üß
