Gute Matrix für Trickfilme

[Kika]

> Und jetzt kommt's: Das Ergebnis war 1000 mal schlechter als vorher!

Wenn Du den Thread meinst, von dem ich denke, dass Du ihn meinst, dann wirst Du dort auch lesen, dass sich die Einstellungen je nach Geräten völlig unterscheiden.
Ich selbst benutze ein "Flat-Model", bei dem im Histogramm links und rechts NICHT bis zum Anschlag geregelt wird, eine allgemeingültige Formel dafür gibt's nicht.
Bei meiner Kombination aus Sat-Empfänger und TV-Karte ergibt das eine gute Rauschminimierung, wobei gleichzeitig das Überstrahlen von hellen Flächen vermieden wird. Außerdem verringert es den Kontrast zwischen den Hintergründen und den schwarzen Umrandungslinien der Figuren, was Mosquitos minimiert.

> Aber warum nimmst du so einen krummen min-Wert von 1650?

Das hat sich beim Experimentieren als recht gut erwiesen. 1600 und 1700 würden keinen sichtbaren Unterschied ergeben, also war's ziemlich wurscht, inzwischen gehe ich gelegentlich auch bis 1850 hoch, hängt aber davon ab, wieviel AVG und Max ich brauche.

Übrigens: da ich zurzeit Urlaub hab, konnte ich mir mal eine Spiderman-Episode ansehen. Ist tatsächlich Cel-Animation, wobei einige Szenen mit 3D-Rendering gemixt wurden.

Gruß,
Kika

[Nemo]

Hello again,

ich hab die ganze Zeit meine Einstellungen getestet und war schon kurz davor meine persönliche Perfektion zu finden, da ist mir etwas komisches aufgefallen. Es geht wieder einmal um Spider-Man. Ich hab da eine Szene, bei der sich Macroblocks einschleichen, was mir natürlich gar nicht gefällt. Vor allem sind sie so riesig, dass man sie einfach nicht übersehen kann. Und da mein Ziel eigentlich ein BackUp in mindestens VHS-Quali war, kann ich das nicht akzeptieren. Ich hab also noch mal ein bisschen rumprobiert und herausgefunden, dass es nur an deiner Matrix liegt. Und die Macroblocks treten auch bei schon fast absurden Raten von 9000 kbit/s auf. Mit der TMPEG-CG-Matrix gibt es komischer Weise keine Probleme. Ich weiß, dass du deine Matrix extra optimiert hast und dass sie ja eigentlich besser sein soll als die ganzen CG-Matrizen, also kannst du mir das mal erklären? Oder sind meine Raten einfach zu hoch? (Was ist dann ne gute Matrix für die Raten, da unten?) Ich hab mal zwei Beispiele hochgeladen, du findest sie unter:
http://mitglied.lycos.de/matrizentest/
Die verwendeten Einstellungen: 4-pass-VBR, IQP 5, kein Filter (die Macroblocks treten aber auch mit Filter auf), min 1700, avg 3300, max 4900, Intra DC precision Auto, 12er GOP.
Ach ja, an der Kürze der Sequenz liegt es auch nicht, ich hab nämlich zuvor die ganze Folge encodet und die Macroblocks waren auch da.
So, bin schon gespannt auf eine Antwort

Nemo

[Kika]

Hm, lustiger Effekt. Was Du da hast, ist keine Verblockung, sondern ein echter Bildfehler, und die haben normalerweise nichts mit der Matrix zu tun.
Was Du außerdem noch hast, ist ein Field Swap, scheint an Deiner Capture-Karte zu liegen. Wenn Du das mit dem DVD-Player abspielst, dürfte es grausam aussehen.

[Nemo]

@Kika:

Was meinst du mit Bildfehler? Im Fernsehen ist der Fehler nicht (das stammt aus dem Opening, wird also in jeder Folge wiederholt), auf dem VHS-Tape ist der Fehler nicht, das gecapturete Material hat den Fehler nicht, und wenn ich es mit der CG-Matrix encode, ist der Fehler auch nicht da. Also kann es doch nur an der Matrix liegen. Guck dir doch mal die andere Sequenz an, die ich auch upgeloadet habe und die mit der TMPEG-CG-Matrix encodet ist.

Mit dem Field Swap hast du recht. (Peinlich, peinlich! ) Ich bin da ein bißchen durcheinander gekommen, weil meine TV-Karte das tatsächlich falsch macht, ich also vor oder nach dem Capturen bis jetzt field swap eingesetzt habe. Aber in CCE makier ich kein tff, wie man es ja sinnvollerweise machen sollte, deshalb stimmt die Fieldorder in dem Beispiel nicht. Meine Karte macht es also grade so, wie ich es brauchen kann. Hat das jetzt jemand verstanden? *g* ... Aber das tut nix am Problem, ich hab auch noch mal mit im Endergebnis richtiger Fieldorder encodet und die "Bildfehler" sind immer noch da.

Gruß
Nemo



Zuletzt bearbeitet von Nemo am Juli. 01 2002,21:52

[Kika]

Nun, das ist wirklich ein echter Bildfehler. Mehrere Macroblocks sind regelrecht defekt. Und zwar nur in einem einzigen Field, nirgends sonst.
Ich habe sowas auch noch nie gesehen und keine vernünftige Erklärung dafür, aber an einer Matrix kann das nicht liegen, sowas ist ausgeschlossen.
Wenn beim Quantisieren Mist gebaut wird, dann sieht das anders aus - entweder völlig verwaschen oder total verblockt. Bei Deinem Beispiel fehlen aber einfach nur Daten, einer der Blocks wird sogar invers dargestellt, und sowas passiert nicht beim Quantisieren.

Zum Field Swap: nur zur Vorsicht - das hat nichts mit der Field Order zu tun, das sind zwei paar Schuhe.

Und zur zweiten Sequenz: Dort ist das betreffende Field tatsächlich OK, kein Fehler. Ich habe beide Sequenzen auch Bild für Bild (na ja, einige Bilder, natürlich nicht alle) miteinander verglichen, und bin eigentlich recht zufrieden. Nur diesen Fehler, den kann ich mir nicht erklären.
Inzwischen hab' ich mit meiner Matrix insgesamt 65 Trickfilmfolgen encodet, aber sowas ist noch nie geschehen.

[Nemo]

Hm, na toll! Warum muss so was immer mir passieren? Hab ich zu gute Augen oder was? ;) Ich hab jetzt noch meine Quelle hochgeladen, da kannst du (könnt ihr) mal kräftig testen, woher das kommen könnte. Ich hab so ziemlich alle Einstellungen ausprobiert und der tritt immer nur mit deiner Matrix auf, Kika. Das heißt, er tritt IMMER auf, wenn ich deine Matrix benutze. Keine Ahnung, wie das sein kann, vielleicht ist das wieder so eine tolle CCE-Eigenheit (ich hab übrigens wie immer 2.62 benutzt)! Auf jeden Fall liegt es an der Matrix. Und so lange mir keine sagen kann, woher das kommt oder was man dagegen tun kann, werd ich wohl oder übel ne andere Matrix benutzen müssen. Kann ja schließlich gut sein, dass das kein Einzelfall ist. (Bist du dir sicher, das in deinen 65 Folgen kein einziger solcher Fehler aufgetreten ist?)

Gruß
Nemo

[Kika]

So, Problem gelöst:

Du benutzt noch die alte, unkorrigierte Fassung der Matrix, die in der Non-Intra als ersten Wert die 8 enthält. Dort muss beim CCE eine 16 rein, beim TMPGEnc kann die 8 stehen bleiben.
Das ist eine Eigenheit des CCE.
Hm, ich hatte gehofft, dass inzwischen überall, wo über die Matrix geschrieben wurde, die neuere Fassung drin stände.

Das Problem der falschen Blocks taucht allerdings nicht nur bei meiner ursprünglichen, sondern bei JEDER Matrix auf, die in der Non-Intra als ersten Wert die 8 enthält, und da gibt's einige. Und es passiert immer nur an dieser einen einzigen Stelle, sieht aber unterschiedlich aus. Bei anderen Sequenzen tritt der Fehler nicht auf.

Übrigens: die Testsequenz hat nicht einfach nur einen Field Swap, der ließe sich ja mit Swap Fields in VirtualDub beheben, ist bei Deinem AVI aber nicht der Fall. Ich hoffe, dass ist nicht bei all Deinen Videos so?

[Nemo]

Super, danke! Und wieder was dazu gelernt! Aber die 24 bleibt bei der non Intra, oder?

Die alte Version deiner Matrix hab ich übrigens aus dem neuesten (! ) Tsunami-Patch Release. (Hm, warum wohl ... ;) ) Und grad da braucht man ja die neue Version deiner Matrix, schließlich lädt sich keiner den Patcher runter um dann die Matrizen in TMPEG zu verwenden. Ich hab denen schon bescheid gesagt, kann sein, dass sie noch mal bei dir rückfragen.

Jetzt machst du es aber spannend. Wenn die Testsequenz nicht einfach nur einen Field Swap hat, was ist es dann? Das musst du mir jetzt aber erklären, oder gib mir wenigstens einen Link, wo ich das nachlesen kann. Hab bisher eigentlich gedacht, ich würd da durchblicken ... Ich hab noch mal ungefähr die selbe Sequenz frisch gecapturet und ungefiltert hochgeladen. SO sehen alle meine Videos aus. Ich filtere und resize dann noch (von 480x566, also gecroppt, auf 352x566 und dann auf 576 geletterboxt, kann es daran liegen?).

Gruß
Nemo

[Kika]

@Nemo

Ich habe mal mehrere Tests laufen lassen. Der Effekt trat bislang nur bei Deinen Videos auf. Meine Matrix ist auch bei weitem nicht die einzige, die als ersten Wert der Non-Intra eine 8 benutzt. Die Änderung auf 16 erfolgte aufgrund eine Fehlinformation. Aber egal, der Unterschied zwischem der 8 und der 16 ist beim Ergebnis derart marginal, lohnt nicht, da viel drüber nachzudenken.

Was es nun mit dem falschen Field Swap bei Dir auf sich hat, ist mir ein Rätsel.
Wie genau nimmst Du denn auf? Direkt in 480x566? Das sollte man nicht tun, sondern in 480x576 mit Cropping auf 560. Am besten in RGB24.
Hintergrund ist der, dass man bei interlaced immer gradzahlig croppen muss, wobei eine Hälfte dann durch 2 teilbar sein muss, da sich das Bild/Field sonst um eine Zeile nach unten oder oben verschiebt.

Dazu ein Beispiel:
Bei den 560 coppst Du 16 Zeilen. Die Hälfte davon ist 8, das geteilt durch 2 ist 4, passt also.
Machst Du das aber mit 566, dann croppst Du 10 Zeilen, die Hälfte ist 5, das geteilt durch 2 ist 2,5, und das gibt Probleme.

Nimmt man dann noch in YUV2 (YUY2) auf und hat eine Karte, die dabei einen Field Swap durchführt, ergibt das zusammen mit dem ungeraden Cropping mit ziemlicher Sicherheit das, was Du da auch hast.
Mit AviSynth und sehr viel Aufwand (ist selbst für Profis nicht ganz einfach) könnte man das reparieren, mit VirtualDub nicht.

Also am besten nochmal neu aufnehmen und das Croppen und Resizen im Zweifelsfall für Testsequenzen erstmal sein lassen.

[Nemo]

@Kika:

Der Unterschied ist marginal? Also wenn das noch bei weiteren Blitzlichtern auftritt kann ich das nicht marginal nennen. Außerdem hätt ich diesen Fehler ja dann bei jeder Folge - und jeder andere, der Spider-Man encodet. Aber zum Glück ist das Problem ja jetzt gelöst.

Ich nehm mit 480x576 und YUV2 auf. Dann croppe ich (bisher) auf 480x566 und resize auf 352x566, plus letterboxen komm ich dann auf 352x576. Und damit alles wieder stimmt, werd ich ab sofort nicht 10, sondern 12 Zeilen croppen, denn wenn man 6 halbiert, hat man 3 und das is ne ganze Zahl. Gut so?

Nemo

[Kika]

Das mit dem Marginal bezog sich auf den Unterschied, den man hat, wenn alles glatt geht ;)
Ich habe das heute Abend extra nochmal überprüft, bei richtig aufgenommenen Videos tritt der Effekt definitiv nicht auf, auch dann nicht, wenn noch die 8 in der Matrix steht.

[Der Karl]

>sondern 12 Zeilen croppen, denn wenn man 6 halbiert, hat man 3 und das is ne ganze Zahl. Gut so?...

Kika hat nicht richtig gelesen. Ist schon o.K.
Kein Wunder früh im viertel Eins.

Gruß Karl

[Kika]

@Der Karl

Doch, doch, ich habe das schon richtig gelesen, und mit 12 Zeilen klappt's definitiv nicht.

Warum? Was passiert, wenn man das Bild um eine ungerade Anzahl von Zeilen verschiebt? Genau, die erste Zeile des ersten Fields steht dann an der Position, die die erste Zeile des zweiten Fields haben sollte usw., und das sieht... na ja, ziemlich müllig aus.

Nicht vergessen, wir haben über VirtualDub geredet, nicht über AVISynth. Bei letzterem kann man auch mit den 12 Zeilen arbeiten, wenn man's richtig macht, bei VirtualDub aber nicht.

[Der Karl]

Verstehe ich jetzt wirklich nicht!
12 ist eine gerade Zahl. 12 durch 2 ist 6 ist auch eine gerade Zahl.
Also 6 oben, 6 unten.
Geteilt durch 2 ist 3, also eine _ganze_ Zahl.
Wo ist jetzt das Problem?

Gruß Karl



Zuletzt bearbeitet von Der Karl am Juli. 04 2002,11:13

[Kika]

Au elend, jetzt hab' ich mich in meiner eigenen Anleitung verlaufen...
Die 3 ist natürlich wirklich völlig irrelevant, wichtig ist, dass oben eine gerade Anzahl von Zeilen hinzugefügt werden, wie viele, spielt dann keine Rolle mehr. 0, 2, 4, 6, 8 usw. ist alles richtig, 1, 3, 5, 7 usw. ist falsch.

Das mit der 12 war übernommen aus einem anderen Beispiel. Dort wurde aber wegen der Timing-Probleme der BT-Karten bei VHS mit 574 und nicht 576 aufgenommen, und wenn dann 12 Zeilen gecroppt werden, klappt's natürlich nicht.
(574-12=562, 576-562=14, 14/2=7 und 7 ist nicht gut ;) )

Shit, irgendwann muss ich das Ganze mal in einem einzigen Text unterbringen und nicht in etlichen verschiedenen.

[Nemo]

Jetzt habt ihr mich aber überholt! Also edit:
Dann stimmt's ja doch, dacht schon, ich könnt nicht lesen.
12 : 2 : 2 = 3 = ganze Zahl also geht 12. Und ebenso gehen 4, 8, 16, 20, 24, ... Zeilen.

Nemo



Zuletzt bearbeitet von Nemo am Juli. 04 2002,11:45

[Der Karl]

>(574-12=562, 576-562=14, 14/2=7 und 7 ist nicht gut )

Yepp.
Wer so spät ins Bett geht, ist auch entschuldigt, wenn er morgens um 10 noch nicht ganz wach ist.. ;)

[Tsunami]

@ Nemo :
ich habe versucht die drei files ab inkl. 'matrizentest001.zip' zu entpacken, aber alle entpacker melden mir einen crc-fehler, obwohl ich mehrmals auf verschiedene arten die files heruntergeladen habe.
bitte packe dein avi mal mit winrar (nicht im solid-modus, aber mit recovery-infos), wenn möglich berechne die crc-daten und uppe sie erneut, damit ich mir dieses file mal anschauen kann.
oder mache ich eventuell beim entpacken etwas falsch ?

wieso packst du das avi überhaupt zusammen, die dateigröße hat sich dadurch kaum geändert.

treten die bildfehler auch auf, wenn du das video deinterlaced und progressiv encodest ?

was soll ich am patcher ändern ?
von dem fehlerhaften 8er wert am anfang der non intra matrix habe ich erst _nach_ dem release der patcher-version 0.3.2 erfahren (es wäre übrigens hilfreich, wenn du die version immer mit angeben würdest, anstatt die 'aktuelle' version zu sagen, denn unter 'aktuell' versteht jeder etwas anderes).
soll ich generell alle non intra matrizen mit einer 16 beginnen lassen ?
aber da der 'bug' nur bei inkorrekt digitalisierten avis (falsche filed order ?) auftritt, ist das eigentlich auch nicht generell zu empfehlen.

danke übrigens für diesen interressanten thread, der eine neue eigenart des cce aufgedeckt und wieder ein mosaikstückchen ins puzzle eingefügt hat.

ich suche übrigens immer noch einen hinweis darauf, wann und wieso der cce 2.64 mal anstandslos funktioniert und ein anderes mal bzw. auf einem anderen pc nach einem neustart ddie zusammenarbeit verweigert.

ebenso suche ich infos darüber, wie man die priorität (rechenleistung und speicherkonsum) des cce herabsetzen kann, damit man mehr rechenleistung für andere dinge zur verfügung hat (jetzt will ich aber nichts vom task-manager hören).

Gruß
Tsunami

[Nemo]

@Tsunami:

, ups mein Zip-Programm taugt wirklich nix, ich hab die Dateien auch nicht mehr auf der Platte, ich versuch das Ganze am Wochenende zu rekonstruieren und neu hochzuladen.

Ich hab die Datei(en) gepackt um sie zu splitten, da mir Tripod keine größeren Dateien anzunehmen scheint (oder es liegt an meinem Provider ...)

Das mit dem Matrixändern war wohl ein Schnellschuss, ich hab es nämlich zuerst so verstanden, dass der Bildfehler auftritt, wenn die nonIntra-Matrix mit ner 8 beginnt. Aber der Fehler tritt ja nur auf, wenn die nonIntra-Matrix mit ner 8 beginnt UND man zu blöd ist richtig zu croppen (hm, wer weiß, wieviele das sind ... :0 ;) )

Und bedank dich bei Kika, der war es ja, der die Fehlerquelle herausgefunden hat (für das Fehler liefern bin ich zuständig! )

[Kika]

@Nemo

Hähä, das schwierigste dabei war in der Tat, das Video zu entpacken, sowas hatte ich auch noch nicht.
Leider hab' ich mir nicht gemerkt, mit welchem Entpacker es dann doch ging, ich habe ziemlich viele im System. Könnte PowerArchiver oder Squeeze 3 gewesen sein.

Zu dem Fehler: das war auch für mich recht interessant, denn vorher wusste ich nicht, dass sowas überhaupt auftreten kann. Passiert auch nur beim CCE.

Hast Du das mit dem Aufnehmen und Encoden inzwischen hinbekommen?

@Tsunami