H.264 - Dinge, die mir (noch) unklar sind...

Soweit ich mich erinnere, ist erhöhte Blockneigung in dunklen Bereichen ein bekanntes Problem bei MBTrees. Wie man es vermeidet, weiß ich leider nicht.

Bitspyer, bist du sicher, dass du ein aktuelles x264 Build benutzt und dass du keine allzu ungewöhnlichen Settings verwendest? Gegen Klötzchen und Banding in "flachen" Bildbereichen sollte eigentlich die Adaptive Quantisierung (VAQ) gute Dienste leisten! Das einzige "Problem" das mir bezüglich MB-Tree Ratecontrol bekannt ist, sind "Fades" (Ein-/Ausblenden). Aber das sollte dank Weighted P-Frames ebenfalls der Vergangenheit angehören. Ansonsten kann man natürlich den Loop-Filter leicht erhöhen oder zumindest nicht herabsetzen, um Klötzchen weg zu filtern. Ich bevorzuge allerdings -1:-1, weil es einfach mehr "Schärfe" erhält. Auch solltest du mal überprüfen, ob dein Monitor korrekt kalibriert ist. Vllt sind die "Klötzchen" in den dunklen Flächen bei korrekter Kalibrierung gar nicht sichtbar?

Na, was heißt hier "falsch geflaggt" ... es sind tatsächlich die meisten MPEG2-Videos im Interlaced-Modus encodiert worden, auch wenn sie nicht "combed" sind. Das tun die meisten DVD-Studios oder DVB-Sender aber nur zur Sicherheit - damit sie nicht aus Versehen mal Combed-Material progressiv encodieren (das sieht dann übel aus).
__

Ich würde im Allgemeinen schon empfehlen, den Deblocker von MPEG2Source zu verwenden, vor allem wenn man DVB-Material hat. Es ist durchaus denkbar, dass du MPEG2-Blöcke schon im Original hast, und dich jetzt darüber beschwerst, dass dein MPEG4-AVC-Encoder die so originalgetreu wiederherstellt ...

Zitat von LigH

Ich würde im Allgemeinen schon empfehlen, den Deblocker von MPEG2Source zu verwenden, vor allem wenn man DVB-Material hat. Es ist durchaus denkbar, dass du MPEG2-Blöcke schon im Original hast, und dich jetzt darüber beschwerst, dass dein MPEG4-AVC-Encoder die so originalgetreu wiederherstellt ...

Ja, das sollte man in der Tat sehr genau überprüfen. Der H.264 Loop-Filter entfernt ja keine Blöcke, die im Quellmaterial enthalten waren, sondern er unterdrückt nur solche Blöcke, die durch die H.264 Kompression hinzugefügt werden bzw. würden. Außerdem ist CRF=18 schon ziemlich hoch gegriffen. Niedrigere CRF-Werte braucht man eigentlich fast nie für "transparente" Qualität. Würde mich schon sehr wundern, wenn du da noch auffällige Blöcke rein bekommst. Am besten wäre es, wenn du mal einen Schnippsel unbearbeitetes(!) Quellmaterial hochlädst...

Zitat von Bitspyer

Schliesse ich daraus, das ein generelles TDeint() oder Yadif() dann nicht verkehrt ist? Wenn mich bei DGIndex das interlaced Flag anlacht, suche ich mir schnelle Scenen und Bildwechsel und schaue, ob es Kämme gibt. Falls nicht, gehe ich von Progressive aus.

Nein! Wenn das Material nicht "interlaced" ist, dann braucht man es auch nicht durch einen Deinterlacer zu jagen. Damit zerstörst du nur Details ohne einen Gewinn zu haben. Ob man sinnvollerweise einen Deinterlacer einsetzt oder nicht, hängt vom Inhalt ab, nicht davon wie er kodiert wurde! Progressives Material kann man "interlaced" kodieren. Es schadet dem Material nicht, aber es wird dadurch auch nicht plötzlich interlaced! Umgekehrt wäre es fatal wenn man interlaced Video progressive kodieren würde. Deshalb gehen die Studios auf Nummer sicher und kodieren meistens gleich alles interlaced, auch wenn das weniger effizient ist. Um zu entscheiden, ob ein Video interlaced ist oder nicht, helfen nach wie vor nur deine Augen. Auf "Flags" kann man sich nicht verlassen, sie sagen nichts über den Inhalt.

Der "cpu"-Parameter legt nicht fest, wie viel Deblocking verwendet werden soll, sondern worauf und in welche Richtung (siehe DGMPGDec-Dokumentation). Die Stärke hängt von der Quantisierung des Videos ab. Wenn du davon abweichend steuern willst, wie stark entblockt werden soll, könntest du eventuell die Threshold-Parameter ausprobieren.