Juhuuuh, Teegedeck ist da! Herzlich willkommen, Du ... Grünschnabel 
Kopernikus - ich hab diesen Thread keineswegs vergessen, aber so ist's dieser Tage. Hier, und auf Doom9 und Videoforumer hab ich wohl noch ein Dutzend anderer Baustellen offen, wo die Leutchen sich wundern, warum man nix hört und nix weitergeht (bleistiftsweise ist das neue Restore24 seit 6 Monaten "praktisch fertig"...) - Kann leider nicht so, wie ich gern wollte, und das geht schon fast das ganze Jahr so. Der Gedanke an Notschlachtung rückt näher ... (Burnout ist echt ScheiBe, wenn man nicht gerade Hannawald heisst.)
Übrigens, ich glaube dass in dem Build mit dem "inversen" Lumimasking etwas mit dem "normalen" Lumimasking nicht stimmt. Wie schon gesagt: Die Vorgabe "wenn avgFrame>60 dann erhöhe Quants für Blöcke mit avgBlock<90 kann nicht richtig sein. Das bedeutet ja, dass auch alle Blöcke stärker quantisiert werden, die mitten im sichtbaren Bereich liegen. Das lag keinesfalls im Sinne des Erfinders, bzw. des Tweakers (Syskin).
Und wenn ich den Output dieses Test-Builds mit einem Standard-Build vergleiche, dann wendet der Testbuild tatsächlich AQ in [zu hellen] Bereichen an, in denen der Standardbuild AQ *nicht* anwendet. Also, unabhängig davon was wo in welchen Sourcen 
drinsteht: der Standard-Build arbeitet *anders*.
Teegedeck: Also, bei mir waren's nur ca 15% mehr. So oder so, der Mehrverbrauch an Bitrate sollte auf 40%~60% des derzeiten Wertes schrumpfen, wenn der Bereich sinnvoller eingegrenzt werden würde, anstatt einfach "alles-was-dunkel-ist" schwächer zu quantisieren.
Trotzdem, Du hast recht: sehr viel Unterschied sieht man z.Zt. nicht. Es ist durchaus einer da, aber ... ein guter Teil der optischen Verbesserung wird durch die B-Frames verschleiert. Die laufen ja mit "normalem" Quantizer weiter (kein AQ für B's), und können nur durch die "bessere" Referenzierung nicht in dem Maße bessere Ergebnisse liefern, wie die P-Frames mehr Bitrate ziehen. Zumal in dunklen Szenen B-Frames typischerweise sehr zahlreich anzutreffen sind ...
An diesem Punkt gebe ich mich, glaube ich, erstmal geschlagen ... und neige mein Haupt gen Prunedtree. Nur über einfaches AQ ist der Wunsch "helfe den Schwachen" wohl nicht zufriedenstellend hinzukriegen. Man müsste tatsächlich in die RDO einsteigen, und ziemlich komplexe Modelle ausarbeiten, damit alle vorhandenen Features sinnvoll zusammenarbeiten.
Bekräftigen möchte ich allerdings mein Veto gegen AQ-für-detailreiche-Blöcke, und auch gegen Texture Masking. Ersteres schon allein vom theoretischen Ansatz her - Detail ist das, was der Codec so verzweifelt zu transportieren versucht. Wollen wir das wirklich stärker quantisieren? Ich nicht. Und wenn man's nur auf extrem hochfrequentes Detail beschränkt (d.h. auf mögliches "Salt-and-Pepper"-Pixelrauschen), dann ... kann man gleich eine Q.matrix verwenden, die die höheren Frequenzen stärker 'rannimmt
Und, Texture Masking: in dem zuvor geposteten Screenshot sieht das ja wunderbar aus: man sieht es nicht. Man sieht es in dem Screenshot nicht. Sobald aber eine Folge von Bildern abläuft, würde man sehr wahrscheinlich ein höchst lästiges Flimmern wahrnehmen, wo eigentlich eine "stabile" Textur sein sollte. Eine Textur mit gleich aussehendem "Schrott" zu ersetzen funktioniert nicht, weil der "Schrott" nicht über die temporale Achse stabil bleibt, sondern zufällig ist.
