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.
