HEVC - qcomp

CQP = Constant Quantizer Parameter

Ich glaube, dass du das im Kern richtig verstanden hast. Soweit ich mich erinnere, geht es um die Gewichtung zwischen konstanter Quantisierung und konstanter durchschnittlicher Bitrate (ABR).

Um dir das im Detail zu beantworten, müsste man selber die verschiedenen Rate-Control-Modi von Grund auf verstanden haben ... so weit bin ich noch nicht. Aber ich weiß zumindest, dass qComp nur im Bereich 0.5 - 1.0 gültig ist, und dass hier eine Gewichtung zwischen zwei Berechnungsmethoden stattfindet. Ein qComp-Wert von 60% bedeutet also nicht, dass die Quantisierung um 40% schwanken darf, sondern dass ein fester Quantisierungsfaktor einen Anteil von 60% an der Berechnung hat, und die restlichen 40% Anteil aus einer Komplexitätsschätzung über die Vorausschau in das zukünftige Video (Lookahead) stammen.

Dieser "Faktor für die Komprimierung der Quantisierungskurve" (bei der dieser in einem Exponenten steht, also deren "Biegung" beeinflusst) hat seinerseits auch Auswirkungen auf die Berechnung des Komplexitätsfaktors, des Ratefaktors, sowie auf die Ermittlung eines Offsets in der MBTree-Struktur ... nach meinem Gefühl dürfte er so unter anderem steuern, wie vorausschauend die Quantisierung abhängig vom Bildinhalt angepasst wird. Im Extremfall 1.0 weicht die Quantisierung eben gar nicht vom geplanten durchschnittlichen Quantisierungsfaktor ab, egal was da für Video kommt. Bei der Verwendung der adaptiven Quantisierung mit CUTree wird er auch teilweise ignoriert.

Solche Detailfragen sollte man am besten den Entwicklern selber stellen, vielleicht im doom9-Forum, weil dort sowohl die x265-Entwickler mitlesen und antworten können, als auch andere (GUI-) Entwickler und Qualitätsfanatiker was davon haben.

Ich compiliere doch bloß ab und zu. In der Tiefe verstehen muss ich die Quellen dazu nicht unbedingt...

Ich glaube aber, dass ein höherer Wert nicht unbedingt nützlich für Actionszenen ist, denn wenn da die Komplexität häufig wechselt, ist es doch besser, eher nicht ständig eine konstante Quantisierung zu verwenden. Wo viel Bewegung, aber wenig Schärfe ist, darf die Quantisierung doch gerne etwas gröber werden, oder?

Und ... wenn der Lookahead-Bereich relativ weit ist, ändern sich die Vorhersagen doch eher nicht so stark? Die Änderung der Quantisierung in Anpassung an eine sich plötzlich ändernde Komplexität von evtl. dutzenden Frames im Voraus (20/25/30 bei medium/slow/slower) wird doch wie eine Bugwelle weich vor sich her geschoben?

Zitat

Another common heuristic is known as “quantizer curve compression”, or “qcomp”. qcomp attempts to compensate for the variance in RD curves among frames without the complexity of calculating the actual RD curves. It does this by leveraging the correlation between the inter residual of a frame and its importance for predicting future frames. Typically inter prediction is less useful in sections of video with high inter residual, and thus the value of a higher quality reference frame is lower. As such, qcomp adjusts the quality of frames in inverse proportion to their inter residual. This algorithm was originally invented for use in libavcodec's MPEG video encoder. x264's implementation of qcomp
measures the Sum of Absolute Hadamard-Transformed Differences (SATD) residuals of frames, performs a Gaussian blur over the residuals to limit local variation, then multiplies the quality of all frames by (SATD residual) Combined with heuristics such as constant I-frame and B-frame offsets, qcomp helps approximate the effect of a much slower RD-optimal
ratecontrol algorithm with negligible computational cost.

Quelle: http://www.x264.nl/developers/Dar…ree%20paper.pdf (aus dem Abschnitt: Background)
grob:
- kleiner qcomp Wert -> es wird versucht eine möglichst konstante Datenrate zu erreichen
- großer qcomp Wert -> die Datenratenkurve darf mehr schwanken

konstante Datenrate/Quantizer: beides doof, da die Bits oft entweder zu wenige oder zu viele sind, sinnig ist eine möglichst clevere Verteilung basierend auf dem zu Grunde liegenden Qualitätsmaß (i.d.R. PSNR, SSIM etc.)
Problem daran ist: eine voll Optimierung anhand eines Qualitätsmaßes kostet viel zu viel Zeit. Brute-force würde man einfach einen Stapel von Quantizern für ein Frame ausprobieren und dann den der den besten Wert liefert nehmen. Problem daran ist das ein Quantizer nicht für ein komplettes Bild gewählt wird, was die brute-force Methode wirklich unbrauchbar macht. Ein anderes generelles Manko ist, dass das man weiß, dass das Qualtitätsmaß nicht optimal ist (deshalb kommen dann jede Menge psychovisuelle Verbesserungen&Co) und man vermutlich nicht auf ein Qualitätsmaß, sondern auf einen Sack voll Maße hin optimieren will,...
=> brute-force geht nicht, also müssen Heuristiken her. (Lookahead&Co würde ich erst mal aus solchen Gedankenspielen raus lassen, oder das Ganze wird noch undurchsichtiger. Generell würde ich empfehlen mal nach den Papern von Jason Garrett-Glaser (<- ich weiß er ist jetzt eine sie und heißt anders, aber auf den Papern steh i.d.R. der alte Name) zu suchen, da wird öfters einiges erklärt.

Cu Selur

Ps.: das generelle Handling ist bei den meisten Encodern gleich, sprich die Idee von qcomp funktioniert ist nicht Codec abhängig. (weshalb auch die Idee von x262 so interessant war,..)