Warum man nicht überall croppen sollte

Zitat von kurt

der Unterschied zwischen Mod8 (72 Zeilen) und Mod16 (80 Zeilen) wäre sicher interessant :ja:

Für den Fall, dass in diesen 8 Zeilen kein Rand ist, kann man das Ergebnis schon etwa aus der Grafik entnehmen.

Für den Fall, dass man schwarzen Rand mitcodiert müsste ich mir noch einen Testcase ausdenken und durchrechnen. Wäre dabei vielleicht auch interessant zu sehen was passiert wenn man zwar bis zum Bildrand croppt, dann aber wieder schwarze Balken hinzufügt. Dann ist die Übereinstimmung in der ersten Zeile von Blöcken nicht so doll, dafür ist das Schwarz aber "schwärzer". Alle weiteren Blöcke sind dann aber wieder deckungsgleich und damit "gut".

Zitat von Selur

Okay, dies trifft dann aber nur auf Mpeg4 ASP zu

Keine Ahnung. Gibt's irgendwelche Codecs, die keine DCT machen?

Zitat

1. die gleichen Quantisierungmatrizen verwendet werden

Nein. Wenn man die gleichen hätte, wäre der Effekt am stärksten, aber auch halbwegs ähnliche Matritzen sorgen schon für eine Ersparnis. Genau das zeigt ja mein Test. Natürlich steht es jedem frei, ähnliche Tests anzustellen, ich würde mich darüber freuen.

Zitat

2. das Material nicht gefiltert wird

Ja, schrieb ich ja. Obwohl auch Undot() den Effekt nur abschwächen und nicht völlig aufheben wird. Das ist erstmal nur eine Vermutung, wenn man's genau wissen will, müsste man's mal durchspielen (wozu mir allerdings gerade der Nerv fehlt ).

Zitat

3. die anfängliche Wahl gut war, soll heißen, was spricht dagegen, dass die ein neuer Block nicht besser sein kann, wenn er aus 4 früheren bestand?

MPEG2 wäre niemals bekannt geworden, wenn es die ungünstige Eigenschaft hätte, nicht öfter gut zu quantisieren als schlecht. Wenn das so wäre, würden MPEG2s vor Artefakten strotzen. Eine gute Auswahl zu treffen ist bei der DCT eigentlich trivial. Nicht-trivial ist es, eine Auswahl zu treffen, die Eigenheiten des Sehapparates bei bewegten Bildern gut ausnutzt.

Zitat

Wirkt sich dies wirklich aus wenn ich ein Decodiertes Bild habe? (Avisynth arbeitet auf Pixeln und kümmert sich dabei herzlich wenig um Markoblockübergänge..)

Da so eine ähnliche Frage schonmal kam, frage ich mal zurück, woher AviSynth denn die Informationen herzaubern soll, die im Originalbild enthalten waren, bei der DCT aber unter den Tisch fielen? Nur weil ein Mensch im decodierten Video keine Blöcke erkennen kann, heißt das noch lange nicht, dass noch alle Informationen da sind. Encodier doch mal mit extrem niedriger Bitrate (Codec egal), dann siehst Du, dass Informationen in den Blöcken unwiederbringlich verlorengehen, selbst wenn man sie mit AviSynth öffnet ;).

Zitat

Sehe ich momentan nicht, so lange ich nur 'ganze' Markoblöcke encode. Soll heißen würde ich z.B. oben und unten bzw. links&rechts jeweils einen halben Makroblock weg schneiden, sehe ich keinen Grund wo das wirkliche Problem liegt.

Puh, ich hab mich ja schon bemüht, das halbwegs zu erklären. Ich mach noch einen "einfachen" Versuch, danach müsste man wirklich tief in DCT einsteigen. In der DCT wird ein Macroblock genommen und eine Liste von Matritzen generiert, deren Überlagerung wieder das Ursprungsbild ergeben. Bis dahin geht bis auf Rundungsfehler keine Information verloren. Diese Matritzen sind nach ihrer Wichtigkeit für die Bildqualität sortiert und die n unwichtigsten werden einfach weggelassen.

Wenn der neue Codec auf denselben Blöcken arbeitet, steht er vor demselben Problem. Er muss bei gegebener Bandbreite die wichtigen Informationen erhalten und die unwichtigen verwerfen. Da der Codec die zuvor verworfenen Informationen gar nicht kennt, findet er ziemlich genau dieselben, die der MPEG2-Codec auch gefunden hat. Wenn der Quantisierer exakt genauso funktionieren würde wie der von MPEG2, würden schon relativ wenige Matritzen den Block perfekt rekonstruieren und er würde nie zusätzliche erzeugen, sondern die Bandbreite für die P- und B-Frame-Prediction verwenden (was sehr wünschenswert ist).

Wenn nun der neue Codec aber 4 Teile von 4 Blöcken komprimieren muss, sieht es anders aus. Die 4 Teile enthalten 4mal nur "wichtige" Informationen, und zwar in jedem Block andere. Der Codec braucht also entweder mehr Platz, um sie alle gut zu repräsentieren, oder aber er muss von dem neuen Block Informationen verwerfen, die ursprünglich da waren. Dasselbe Problem stellt sich bei den 3 benachbarten Blöcken. Grob gesagt kann sich der Codec nicht auf die Auswahl der richtigen Frequenzen eines Blockes beschränken sondern muss aus vier Frequenzmischungen eine neue Auswahl treffen.

Zitat von Selur

MPEG AVC Codec machen etwas ähnliches aber rein im Integerbereich

Das betrifft wahrscheinlich nur die Berechnung der Matritzen. Was rauskommt dürfte sehr ähnlich sein.

Zitat

dann gibt's da ja noch waveletbasierte Codecs

Jo, das ist andere Baustelle :).

Zitat

daran zweifeln, dass die Macroblöcke durchaus nicht immer ideal gewählt sind.

Die sind bestimmt selten ideal gewählt. Aber schon wenn sie besser gewählt sind als blind geraten, gibt's den besagten Effekt.

Zitat

Ich sehe nicht, dass bei einer erneuten Komprimierung DCT wieder genauso läuft wie vorher

Nee, genauso nicht, aber mit einigen Ähnlichkeiten, eben weil die "unwichtigen" Anteile bereits weg sind.

Zitat

sehe ich nicht, warum es hilfreich sein kann, dass die Markoblockgrenzen identisch seien sollen.

Tja, da bin ich dann mit meinen Erklärkünsten auch am Ende. Wenn ich es nochmal erklären sollte, würde ich es wieder genauso machen wie vorher. Vielleicht springt ja wer anders ein oder ein Whitepaper kann helfen.

Zitat

Warum besteht hier nicht die Möglichkeit, dass der Codec andere Matrizen/Koeffizienten wählt weil er mit ihnen die vom ersten Encode verbleibenden Informationen (Orginal-Rundungsdaten) besser erhalten kann, gerade wenn die Makroblockgrenzen nicht identisch?

Es hat ja niemand behauptet, dass das nicht mal passieren kann. Nur ist die Wahrscheinlichkeit, dass man mit weniger Bits/Block auskommt viel größer bei Alignment mit Originalblöcken. Das mag man gut, doof, logisch oder seltsam finden, in der Praxis gibt es diesen Effekt aber, wie man mit simplen Tests z.B. mit JPEG-Bildern leicht überprüfen kann (dazu gibt's sicher einiges im Netz).

Zitat

Ich glaube mein Problem ist, dass ich noch irgendwie nicht daran glaube, dass die 'Daten' benachbarter Makroblöcke so verschieden seien müßen.

Ich hab ehrlich gesagt noch nicht in welche reingeschaut, aber ich würde erwarten, dass sie so gut wie keine Gemeinsamkeit haben. Denn auch wenn der Nachbarblock ähnliche Farben und Formen hat, ist es äußerst unwahrscheinlich, dass dieselben Matritzen herauskommen. Warum, kann die englische Wikipedia oder dieses PDF besser erklären als ich.

Zitat von Selur

Werden denn sicher auch die (fast) gleichen Matrizen verwendet?

Keine Ahnung. Ich betrachte das von der anderen Seite: Die Tatsache, dass die Kompression so viel besser ist auf Mod16 zeigt doch, dass es so ist. Und wie gesagt, sie müssen überhaupt nicht "fast gleich" sein, um einen Vorteil gegenüber "völlig unterschiedlich" zu haben.

Zitat

Sweeeet: Kannste eventuell ein Diagram mit PSNR-Werten ansstelle von SSIM Werten machen?

Wieso? Ich vermute, dass SSIM die Ähnlichkeit zweier Clips wesentlich besser (d.h. näher an der menschlichen Wahrnehmung) misst.

Aber was ich machen kann, ist, die verwendeten AviSynth-Scripts zu posten, dann kann jeder seine eigenen Tests machen.

Zitat

Ps.: Hatten nicht mal syskin&co gemeint ein DCT Domain-Transcoder wie Shrink ihn verwendet wäre für Mpeg2->Mpeg4 unsinnig, da es zu ungenau wäre

Keine Ahnung, bin ja ein Frischling hier. Ich denke aber auch, dass sich die Motion Compensation viel zu sehr unterscheidet. Nur mit Domain-Transcodieren ist es also sicher nicht getan.

Zitat von nexustheoriginal

Vorausgesetzt es wird gefiltert, ist es dann noch von Vorteil die ursprünglichen Makroblockgrenzen beizubehalten?

Das kommt darauf an wie Du filterst. Da alle Filter Information vernichten und keine hinzufügen wird der Effekt schwächer werden. Um wieviel, das müsste man einfach mal testen.

Zitat von nexustheoriginal

Das übliche eben, Rauschentfernung, Schärfen.

Schätze, danach wird der Effekt immer noch deutlich da sein.

Zitat

Dann poste mal dein Skript.

Ok, dazu muss ich ein bissl was schreiben. Insgesamt sind es 3 Dateien:

• globals.avs (muss so heißen) speichert globale Werte, so dass man weniger Fehler machen kann :).
• mkclips.avs erzeugt einen Testclip.
• cmpclips.avs vergleicht einen Testclip mit dem Original.

Den Inhalt von globals.avs musst Du logischerweise anpassen. Hier ein Beispiel:

PluginPath = "C:\Programme\AviSynth\Plugins\"SourcePathname = "D:\Video\"SourceFilename = "Schoene_Autos_Schnelle_Uhren_und_Teure_Frauen.d2v"StartFrame = 1000EndFrame = 1240CropLeft = 32CropWidth = 640CropTop = 80CropHeight = 352

Wichtig ist, dass CropTop und CropHeight so gewählt werden, dass in jedem Clip nur Bild und kein Rand zu sehen ist. In diesem Fall darf also bei 80 kein Rand sein und bei 80 + 352 + 16 auch nicht.

Folgendes Script dient zum Erstellen der Testclips mit VirtualDub. Für alle Clips gilt: Audio ausstellen und Target Size / Bitrate bei XviD (bzw. anderem Codec) einstellen. Die muss für alle Clips gleich bleiben! Clip abspeichern, unter dem Namen Clip_00.avi. Die Datei muss so heißen und im selben Verzeichnis liegen wie die D2V, damit das Vergleichsscript die Datei findet. Dann im Script den Wert Offset um 1 erhöhen, AVS neu laden in VirtualDub (F2), AVI als Clip_01.avi speichern, usw.. Hier das Script mkclips.avs:

# CONFIGOffset = 0Import("globals.avs")#  PLUGINSLoadPlugin(PluginPath + "DGDecode.dll")cl_src = Mpeg2Source(SourcePathname + SourceFilename)cl_src = Trim(cl_src, StartFrame, EndFrame)# Cropping on any pixel boundary only allowed with RGB32cl_src = ConvertToRGB32(cl_src)cl_src = Crop(cl_src, CropLeft, CropTop + Offset, CropWidth, CropHeight)cl_src

Damit werden nun 16 AVIs erzeugt. Um die jeweils mit dem Original zu vergleichen, benutzen wir ein weiteres Script. Auch hier muss nach jedem Durchgang der Wert Offset um 1 erhöht werden. Hier das Script cmpclips.avs:

# CONFIG 
Offset = 0
Import("globals.avs")


#  PLUGINS
LoadPlugin(PluginPath + "DGDecode.dll")
# http://www.avisynth.org/warpenterprises/files/ssim_25_dll_20050817.zip
LoadPlugin(PluginPath + "SSIM.dll")


TestClip = SourcePathname + "Clip_" + String(Offset, "%02.0f") + ".avi"
StatsFile = SourcePathname + "ssim_stats_" + String(Offset, "%02.0f") + ".csv"
AvrgFile = SourcePathname + "ssim_avrg_" + String(Offset, "%02.0f") + ".txt"


#  SOURCE
cl_src = Mpeg2Source(SourcePathname + SourceFilename)
cl_src = ConvertToRGB32(cl_src)
cl_src = Trim(cl_src, StartFrame, EndFrame)
cl_src = Crop(cl_src, CropLeft, CropTop, CropWidth, CropHeight - 16)
cl_src = ConvertToYV12(cl_src)


cl_dst = AviSource(TestClip)
cl_dst = ConvertToRGB32(cl_dst)
cl_dst = Crop(cl_dst, 0, 15 - Offset, CropWidth, CropHeight - 16)
cl_dst = ConvertToYV12(cl_dst)
SSIM(cl_src, cl_dst, StatsFile, AvrgFile)

Hm, ich geb zu, ich hab die Scripte gerade bei der Eingabe verändert, aber es müsste so passen. Im Zweifelsfall beim Vergleichsscript mal StackHorizontal(cl_src, cl_dst) machen, um zu kontrollieren dass die richtigen Clips verglichen werden. Ich hab am Anfang cl_src und cl_dst in Streifen geschnitten und mit StackHorizontal aneinandergeklebt, um zu erkennen, ob ich die Verschiebung richtig hatte.

Nach der Aktion haben wir ein paar ssim-Dateien in dem Verzeichnis. Die ssim_stats_xx.csv sind nur für ganz Neugierige. Uns interessieren nur die ssim_avrg_xx.txt. In ihnen steht der durchschnittliche SSIM-Wert für den jeweiligen Clip. Daraus eine CSV-Datei zum Import in einer Tabellenkalkulation zu machen ist nicht schwer (aber nervig, deshalb hab ich's mit awk automatisiert :D).

Genau das hätte ich auch vermutet :).

So, für alle, die ein wenig basteln wollen, habe ich mal alle relevanten Daten zusammengestellt. Das stats-File enthält die Daten des 1. XviD-Pass' für die entsprechenden Frames. Wer herausfindet, welcher Film das war, vor dem erstarre ich in Ehrfurcht (möglich ist es bestimmt) ;D.

Ich bin ja Frickler und als solcher werde ich mal versuchen, die ganzen Schritte zu automatisieren, damit man nur noch die Queue von VirtualDub anwerfen und ein wenig warten muss. Damit sollte man dann relativ schnell an mehr, und damit aussagekräftigere, Daten kommen können.