Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Nemo 

Anmeldungsdatum: 20.01.2002 Beiträge: 63
|
Beitrag 40 - Verfasst am: Fr Jul 05, 2002 18:44 Titel: |
 |
|
@Kika
ne, hab noch keine Zeit gehabt, denk aber, dass ich das jetzt hinbekommen werde. Das mit dem Croppen ist mir jetzt klar und das mit der falschen Field Order war ja eh nur ein Versehen.
Um wieder zum eigentlichen Thread zurückzukehren: Sag mal, ließe sich deine Matrix nicht noch verbessern? Schließlich kann eine Matrix nicht gleich gut für interlace und progressiv sein, schon wegen der Scan Order. (Oder hab ich da mal wieder was nicht richtig kapiert? )
Nemo |
|
 |
mb1 
Anmeldungsdatum: 06.06.2001 Beiträge: 3708 Wohnort: München
|
Beitrag 41 - Verfasst am: Fr Jul 05, 2002 18:55 Titel: |
 |
|
Im Doom9-Forum steht ein Perl-Skript mit dem man Matrizen ohne aufwändige Handarbeit zwischen zig zag und alternate scan umarrangiert.
Da die Werte aber nicht einfach hin- und herkonvertierbar sind (kann sich halt ohne zu testen auf die Qualität auswirken), ist normalerweise doch etwas Nachbesserung angesagt.
Bei Interesse poste ich es mal bzw. setze einen Link auf den entsprechenden Thread.
NACHTRAG: Hier ist der Direktlink zum Thread
http://forum.doom9.org/showthr....+matrix _________________ Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 42 - Verfasst am: Fr Jul 05, 2002 23:29 Titel: |
 |
|
Zitat: | Schließlich kann eine Matrix nicht gleich gut für interlace und progressiv sein, schon wegen der Scan Order. |
Das ist ein heikles Thema, das sehr stark in die Interna von MPEG hinein geht.
Ich weiß ja jetzt nicht, ob Du meinen DCT-Artikel in EDV-TIPP.DE gelesen hast, aber zumindest dessen Verständnis ist notwendig, um das überhaupt verstehen zu können.
Die direkte Antwort auf Deine Frage ist nicht so leicht. Grundsätzlich KANN eine Matrix mit Interlaced genauso gut funktionieren wie mit Progressive. Hier geht es ja zunächst um die Quantisierung. Der zweite Schritt ist, vereinfacht gesagt, die anschließenden RLE-Codierung.
Hier kann man tricksen, indem man die Elemente der Matrix so anordnet, dass der Scan dann besser funktioniert. Aber, und das ist das Problem dabei: man beinflusst dann auch die Quantisierung selbst, was genau genommen nicht Sinn der Sache ist.
Ob, und wenn ja, wie stark sich das auswirkt, ist vom jeweiligen Bildmaterial abhängig und davon, was man eigentlich erreichen will.
Der Witz der Trick-HQ-Matrix besteht ja darin, nur sehr schwach zu quantisieren und TROTZDEM hoch zu komprimieren. Das funktioniert in diesem Fall (Trickfilm) ausschlielich über die Bildstruktur. Die Matrix erzeugt ein ziemlich homogenes Muster, was bei ZigZag- UND Alternate-Scan gut via RLE zu komprimieren ist.
Trotzdem kann man die noch weiter optimieren, was aber viel Arbeit ist. Ich halte es so:
Ist es ein gezeichneter Trickfilm, verwende ich meine Matrix.
Ist es einer, der mit starker Computerunterstützung entstanden ist, nehme ich meistens die CG-Matrix des CCE.
Gruß,
Kika |
|
 |
Nemo 

Anmeldungsdatum: 20.01.2002 Beiträge: 63
|
Beitrag 43 - Verfasst am: Mi Jul 31, 2002 17:21 Titel: |
 |
|
Hallo,
hab mich lange nicht mehr gemeldet. Die Matrix-Optimierung lass ich mal lieber, wenn man da noch nachkorrigieren muss und ist mir das zu viel Aufwand und ich bin wohl auch nicht kompetent genug dafür ... ;)
Ich mach meine XSVCD jetzt mit min 1800, avg 3400, max 5000 und half-D1. Allerdings hab ich selbst mit diesen Einstellungen noch reichlich Macroblocks, zwar mehr kleinere aber sie stören (mich). Frage: Gibt es eine Matrix die geeigneter ist für so hohe Datenraten, als deine "Kika TF High"? Es kann doch nicht sein, dass da immer noch soviele Macroblocks drin rumschwirren! Schließlich bewegen sich die Raten im halbierten DVD-Raten-Bereich und es ist half-D1 (wenn auch interlaced).
Nemo |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 44 - Verfasst am: Mo Aug 05, 2002 10:44 Titel: |
 |
|
Also, bei diesen Bitraten DÜRFEN keine sichtbaren Blocks mehr vorhanden sein.
Bei meinen eigenen, interlaced encodeten Trickfilmen nehme ich ja nicht mal so hohe Bitraten, und es klappt trotzdem, obwohl es Aufnahmen mit der TV-Karte sind. Irgendwo ist da bei Dir noch der Wurm drin.
Zitat: | noch reichlich Macroblocks, zwar mehr kleinere aber sie stören |
Das klingt weniger nach Blockbildung als vielmehr nach Mosquitonoise, und das lässt auf einen hohen Rauschanteil im Bild schließen.
Ist dem so, dann hilft filtern. Wobei man aber beachten muss, dass zu viel filtern ebenfalls zu solchen Effekten führen kann, da die Objektkanten verwischt werden. |
|
 |
Nemo 

Anmeldungsdatum: 20.01.2002 Beiträge: 63
|
Beitrag 45 - Verfasst am: Mi Aug 07, 2002 14:23 Titel: |
 |
|
Stimmt, hast recht, jetzt wo du das sagst, das scheint wirklich Mosquitonoise zu sein. Hätt ich auch selbst drauf kommen können!
Ich poste jetzt mal meine Einstellungen, damit man besser konkrete Verbesserungsvorschläge machen kann:
Quelle: gutes VHS-Band, eine Woche alt.
Capture: VD_sync, HuffYUV mit CCE-Patch, 352x568 (8 Zeilen unten gecroppt), Capture-Noise-Filter auf 9 (damit ist jeder sichtbare Noise weg, nur in sehr dunklen Szenen sieht man ihn noch ein wenig. Soll ich da wirklich noch höher gehen?); dann mit VD-resize-Filter geletterboxt auf 352x576 und wieder mit HuffYUV+CCE-Patch gespeichert. (Kann man das nicht auch gleich beim Capturen machen, das kostet mich noch mal ne geschlagene Stunde! )
CCE 2.62: "Kika TF High"-Matrix, Quality-Regler auf 20, kein Filter; min 1800, avg 3400, max 5000; DC 9, sonst kein Haken; 12er GOP
Hier noch ne Ergänzung: Das fertige Video hatte auf dem Fernseher ein Field Swap! Kann das auch die Ursache für den Mosquitonoise sein?
Aufgezeichnet habe ich mit verkehrter Field Order, so wie es meine TV-Karte ausgibt, was ja auch sinnvoll ist, wenn man in CCE tff nicht markiert. Dann stimmt's ja normalerweise wieder. Trotzdem stimmt's eben nicht! Kann das an der HuffYUV-Version mit dem CCE-Patch liegen? *verwirrtbin!* |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 46 - Verfasst am: Do Aug 08, 2002 10:14 Titel: |
 |
|
Zitat: | (damit ist jeder sichtbare Noise weg, nur in sehr dunklen Szenen sieht man ihn noch ein wenig. Soll ich da wirklich noch höher gehen?); |
Nein, damit würdest Du dann eher das Gegenteil erreichen.
Zitat: | (Kann man das nicht auch gleich beim Capturen machen, das kostet mich noch mal ne geschlagene Stunde! )
|
Kann man schon, wenn der Prozessor schnell genug ist. Mein P4 1.9 schafft das mit Links. Einfach mal testen, Versuch macht kluch...
Zitat: | Aufgezeichnet habe ich mit verkehrter Field Order, so wie es meine TV-Karte ausgibt, was ja auch sinnvoll ist, wenn man in CCE tff nicht markiert. Dann stimmt's ja normalerweise wieder. Trotzdem stimmt's eben nicht! |
NEIN!!!!
Wenn Dein PC schnell genug ist, dann RGB und nicht YUV benutzen, dann ist die Field Order richtig.
Bei CCE Upper Field First undbedingt AUSSCHALTEN, NUR DANN wird es richtig!
Der Fehler wird häufig gemacht, da viele einen Field Swap mit einer falschen Field Order gleichsetzen, dabei sind das zwei grundverschiedene Dinge!
Und wenn Du zwar mit richtiger Field Order (eigentlich sollte man sich imho darauf einigen, von Field Dominanz zu reden, wäre viel klarer) aber mit falscher Field-Anordnung (Field Swap) encodest, dann sind die Fields anschließend zwar zeitlich in der richtigen Reihenfolge, aber nicht räumlich. Was erstens bescheiden aussieht und zweitens dazu führt, dass weder die Motion Estimation/Prediction noch die Motion Compensation richtig funktionieren. Und dann gibt's eben Mosquitos ohne Ende. |
|
 |
Nemo 

Anmeldungsdatum: 20.01.2002 Beiträge: 63
|
Beitrag 47 - Verfasst am: Do Aug 08, 2002 10:40 Titel: |
 |
|
Zitat: | Kann man schon, wenn der Prozessor schnell genug ist. Mein P4 1.9 schafft das mit Links. Einfach mal testen, Versuch macht kluch...
| Ja! Mit "können" war aber schon das WIE impliziert. ;) Also wie kann man das? Ich hab zwar die Croppfunktion im Capture-Modus gefunden aber noch nix wo man letterboxen kann.
HILFE!!! Wann kapier ich das endlich? Also: Ich benutze HuffYUV mit CCE-Patch und ich zeichne mit YUY2 auf bzw stell das in HuffYUV so ein. Woher weißt du das? Also ohne geht's nicht, sonst macht mein System schlapp. Aber bisher hat das immer so geklappt. Meine TV-Karte gibt das Material so aus, dass da typische Interlaced-Streifen zu sehen sind. Und ich CCE hüte ich mich tff zu markieren. Also was muss ich jetzt zwischen drin machen, damit's am Ende stimmt?
Erklär am besten mal wie man zeitliche Richtigkeit und wie man räumliche erreicht! Bitte, bitte, bitte ...
*seufz* Nemo
Zuletzt bearbeitet von Nemo am Aug. 08 2002,10:43 |
|
 |
Kika  Moderator
Anmeldungsdatum: 11.06.2001 Beiträge: 3397 Wohnort: Nahe München
|
Beitrag 48 - Verfasst am: Do Aug 08, 2002 11:27 Titel: |
 |
|
Zitat: | Ich hab zwar die Croppfunktion im Capture-Modus gefunden aber noch nix wo man letterboxen kann.
|
Geht ganz normal über die Filter, zusätzlich im Capture-Menü Enable RGB-Filtering aktivieren. Dann werden die Filter, die angeben sind, direkt bei der Aufnahme verwendet. Aber wie gesagt, der PC muss dazu schnell sein, und wenn Deiner schon bei RGB-Capturing schlapp macht, wird's kaum klappen.
Wenn Du nicht anders als mit YUV2 (YUY2) aufnehmen kannst, dann in VirtualDub unter Capture Swap Fields aktivieren. Das ist alles. Ansonsten so vorgehen, wie Du's selbst geschrieben hast.
Räumliche und zeitlöiche Zuordnung von Fields: Das ist eigentlich Karls Fachgebiet.
Aber mal soviel: bei der Aufnahme werden beide Fields zu einem Frame zusammengesetzt. Bei der Aufnahme in YUV machen es aber etliche Treiber so, dass sie zwar die beiden richtigen Frames dazu benutzen, intern aber deren Reihenfolge vertauschen. Daher ist ihre zeitliche Zuordnung richtig, nur eben nicht die Position, an der sie angezeigt werden, eben das, was man einen Field Swap nennt.
Bei einer falschen Field Order ist aber zwar die räumliche Zuordnung richtig, nicht aber die zeitliche.
Was heißt, dass zwar das Top Field auch oben angezeigt wird, aber leider zu einem Zeitpunkt, an dem eigentlich das Bottom Field kommen sollte (ich weiß, dass das verwirrend ist... ich sage nur: Aspirin! ;) ).
Also:
Field Swap: Die Field Order ist richtig, die Fields werden zum richtigen Zeitpunkt aber an der falschen (vertauschten) Position gezeigt. Auf dem Fernseher an den versetzten Zeilen zu erkennen, Deinterlacen führt zu extremer Unschärfe.
Field Order (falsche): Die Positionen der Fields stimmen, sie werden aber zum falschen Zeitpunkt (vertauschte zeitliche Reihenfolge) angezeigt. Auf dem Fernseher als Zittern bei Bewegung zu sehen, Deinterlacen führt zu einem scheinbar normalen Bild aber mit extremen Bewegungsunschärfen.
Phase Shift: Irgendwo ging bei der Übertragung eines eigentlich progressiven Bildes eines der beiden Fields verloren. Von diesem Zeitpunkt an wird daraus dann ein ÜPseudo-Interlaced Bild, da ein Field von Bild 1, das zweite Field aber von Bild 2 stammt. Auf dem Fernseher nicht zu sehen, Deinterlacen führt zu Geister- und Doppelbildern.
Overkill ist dann die Kombination aus mehreren dieser Fehler, wie es bei dem Demovideo von Dir der Fall war (Field Swap + Phase Shift). |
|
 |
|