Neues von mb1

[ANDREAS]

Hallo Leute,
habe im Ultimate-Forum einen Link von mb1 gefunden. Sehr interessant.
Original
http://pub6.ezboard.com/fultimatefrm39.showMessageRange?topicID=2342.topic&start=61&stop=66
Direktlink
http://members.tripod.de/mb1svcd/analogtest.htm
http://members.tripod.de/mb1svcd/analogtest2.htm

@mb1
Das wirft natürlich Fragen auf wie die Matrix von Tmpeg jetzt zu verbessern ist. Analog ist schon deshalb wichtig, da es ja doch viele gibt, die Fernsehen über eine billige TV Karte und Antennenkabel aufnehmen und dann umrechnen. Ferner ist dann ein Aufnehmen einer Hi-8 Sequenz über die S-Video Schnittstelle interessant.
Gruß
ANDREAS

[Angelika]

Das ganze entstand aus einer Diskusion hier auf dem Bord
wie sich die Encoder mit analogem Material oder Digitalem
mit FOB verhalten.Also ich würde sagen man lässt mb1 das in Ruhe fertig machen dann wird er uns sicher seine Ergebnisse mitteilen.
Gruss Angelika

[Kika]

Hm, wundert mich eigentlich nicht so sehr, das Ergebnis, wenn man mal ein paar Punkte bedenkt:
1. Die Matrix allein kann einiges bewirken, das stimmt schon. Aber: Wichtig sind auch die Routinen, mit denen die Encoder arbeiten. Das fängt bei der eventuellen Farbraumkonvertierung an und reicht bis hin zur Entscheidung, welche Macroblocks denn nun wirklich gespeichert werden. Und an dieser Stelle spätestens unterscheiden sich die Encoder stark.
So bin ich schon vor einiger Zeit wieder zu den Original-Matrizen von TMPGenc zurückgekehrt. Zwar sind die inzwischen nach ähnlichem Muster verändert, entsprechen aber sonst den Originalen.
Meiner Meinung nach sind die für TMPGenc besser geeignet als die modifizierten CCE-Matrizen.
2. Bei TMPGenc gibt es eine fatale Fehlermöglichkeit: alte Templates! Letztes Wochenende habe ich die gleiche Sequenz bei exakt gleichen Einstellungen einmal mit meinen 12h-Template und einmal mit einem neu zusammen gestellten encodet: Das Ergebnis war verblüffend und äußerte sich in totalen Unterschieden bezüglich verwendete Bitrate und Bildqualität.
Mir ist nicht ganz klar, was diesen Fehler ausgelöst hat, da ich in meiner ersten Panik die alten Templates dummerweise gelöscht habe. Hier, am Bürorechner, habe ich dann mal ein 12a-Template in den 2.0 geladen und mit diesem abgespeichert, was prompt funktionierte.
3. Meines Wissens speichert CCE (der bei mir immer noch nicht gescheit läuft...) die manipulierten Matrizen nicht im Stream mit ab, was zwar auf das Encoden keinen Einfluss hat, wohl aber auf die Wiedergabe. Inwieweit lässt sich das bei einem solchen Test berücksichtigen?

[PCCounselor]

Spannend ist ja die Frage mit welcher Einstellung wurde was gemacht. Um z.B. bei TMPEG die gleiche schoene Farbsaettigung zu bekommen wir bei CCE gibt es ja auch diverse Einstellmoeglichkeiten.
Um fuer alle nachvollziehbare Ergebnisse zu bekommen, waere eine Doku der Grundeinstellungen schon von Interesse.
Gruesse
PCC

[Helmut]

MB1 hat ja die Tests nun laufen u.a. um zu klären wie sich die Matrixen auf das Interlacematerial auswirken. Ausgehend auch von meinen Tests - wo ich ja dann auch Zweifel bekam ob die Andreas - und Angelmatrixen (welche offenbar für das progressive Material und in Bezug auf das Platzoptimieren gut geeignet sind) tatsächlich passen.
Was mich (immer noch) etwas irritiert weil ich eindeutige Ergebnisse nicht rausbekomme. Hängt offenbar sehr vom Film ab. Aber wie genau ?
Das der CCE das "gefälligere" Bild macht .. hatte ich ja auch schon rausgefunden.
Die Frage ist natürlich ob man den TMPG doch noch - sei es durch Matrixen oder Filter - dazu bewegen kann gleich zu ziehen.
Gruß

[ANDREAS]

Grundsätzlich hat mb1 ja recht, wenn er KEINE Filter in irgend einer Art und Weise zur Hilfe nimmt. Denn nur so ist die Encoderqualität richtig zu beurteilen. CCE macht nun mal von Haus aus ein etwas kräftigeres Bild, das steht dann wohl fest.
Stellt sich natürlich die Frage in wieweit Tmpeg beim analogen Material vom Zig-Zag Scan abweicht, wahrscheinlich nicht. Das bedeutet wiederum, man muß für diesen speziellen Fall mit Sicherheit die Matrix vorbereiten.
Weiterhin bestätigt sich die Feststellung, das die Matrix in Tmpeg und CCE unterschiedlich auszuführen sind um auf das gleiche Ergebnis zu kommen. Auch der Unterschied von Analog, DV und DVD Material ist eindeutig.
Gruß
ANDREAS

[mb1]

@Andreas
>Das wirft natürlich Fragen auf wie die Matrix von Tmpeg jetzt zu verbessern ist
Ich werde zuerst mir eine Matrix für den CCE 2.62 versuchen zu erarbeiten; und dann für Tmpeg (aber da bist ja eigentlich du der Spezialist ;))
>Stellt sich natürlich die Frage in wieweit Tmpeg beim analogen Material vom Zig-Zag Scan abweicht, wahrscheinlich nicht. Das bedeutet wiederum, man muß für diesen speziellen Fall mit Sicherheit die Matrix vorbereiten.
Tmpeg wie auch CCE encoden bei interlaced Material korrekt mit der "Alternate Scan"-Methode (der LSX macht das falsch !). Allerdings denke ich, daß das gar nicht so wichtig ist, da diese Methode in damaligen (Sicht-)Tests des Mpeg-Konsortiums zwar minimal bessere Ergebnisse brachte, aber vermutlich nicht generell auf interlaced Material verallgemeinert werden kann.
>Weiterhin bestätigt sich die Feststellung, das die Matrix in Tmpeg und CCE unterschiedlich auszuführen sind um auf das gleiche Ergebnis zu kommen. Auch der Unterschied von Analog, DV und DVD Material ist eindeutig.
Absolut richtig. Eigentlich müsste man für jeden dieser Fälle (und für Tmpeg und CCE getrennt) eine Matrix entwickeln. Ich persönlich möchte aber lieber an einer Matrix arbeiten, die in jedem Fall ein sehr gutes (wenn auch nicht maximales) Ergebnis liefern kann.
Leider habe ich in den nächsten Tagen beruflich bedingt wenig Zeit (gerade soviel, um etwas auf dem laufenden zu bleiben und das ein oder andere Posting zu beantworten, maximal 30-60min tgl.), daher werden die Tests und Ergebnisse noch etwas länger auf sich warten lassen ...

@Kika
>Meines Wissens speichert CCE (der bei mir immer noch nicht gescheit läuft...) die manipulierten Matrizen nicht im Stream mit ab, was zwar auf das Encoden keinen Einfluss hat, wohl aber auf die Wiedergabe. Inwieweit lässt sich das bei einem solchen Test berücksichtigen?
Das gilt nur für den Tsunami-gepatchten CCE 2.50. Der speichert immer die Standard-Matrix im Stream ab (da er ja nicht weiß, daß er gepatcht wurde). Man könnte einen zusätzlichen Patcher machen, der die benutzte Matrix auch in den mpg-Stream schreibt.
Der CCE 2.62 schreibt die benutzten Matrizen auch korrekt in den mpg-Stream mit rein, und zwar intra und non-intra.
Und in meinen Tests habe ich ja nur den CCE 2.62 verwendet.
Tatsache ist allerdings, daß die Streams des gepatchten CCE 2.50 bei der Wiedergabe besser aussehen als die der ungepatchten Version. Ob das nun Glück für den jeweiligen Fall war (wie ixi und Angel dies bezeichnen) vermag ich nicht zu sagen. Entscheidend ist für mich die bessere Ausgabe am TV und die war bei mir in 5 von 5 Versuchen gegeben.

@PCCounselor
Die Einstellungen in Tmpeg entsprechen denen von Helmuts Einstellungsempfehlung für analoges Kameramaterial zu DVD mit Ausnahme von Motion Search auf "High Quality", Closed GOP deselektiert; dann die CG-Matrix des CCE 2.62 (unterscheidet sich von der Tmpegs CG-Matrix) und Soften Block Noise war 2x auf 5.
Auf Wunsch kann ich die ganz exakten Einstellungen ja noch im Test anführen.

Tatsache ist, daß mir derzeit die Testarbeit am meisten Spaß macht. Filme (auch die eigenen DV-Filme) zu bearbeiten interessiert mich momentan absolut gar nicht.
So genug geschrieben (und ab ins Bett )

[mb1]

Habe mir schnell mal die Matrizen in den mpg-Streams angesehen:
Encodet wurde mit folgender Intra Matrix:
-8,16,20,22,24,24,24,24,
16,16,20,22,24,24,24,24,
20,20,22,24,28,28,28,28,
22,22,24,24,28,28,28,28,
24,24,24,24,32,32,32,32,
24,24,24,24,32,32,32,32,
28,28,28,28,32,32,32,32,
28,28,28,28,32,32,32,32,
Der CCE 2.62 und auch Tmpeg 2.00 speichern aber im Stream als Intra Matrix:
-8 16 16 20 16 20 22 20
20 22 24 22 22 22 24 24
24 24 24 24 24 28 24 24
24 28 24 24 24 24 28 28
24 24 28 28 28 28 24 32
28 28 24 28 28 32 32 28
28 28 32 32 32 28 32 32
32 32 32 32 32 32 32 32
Das ist also auch nur annähernd identisch. Mit welcher Matrix wird denn nun encodet ? Mit der von mir eingestellten oder mit der im Stream abgespeicherten. Hält der Encoder sich an die von mir vorgegebenen Einstellungen, müßte es ja später auch Dekodierungs-Fehler geben.
Das muß ich mir mal alles sehr genau zu Gemüte führen !
@Helmut
Ich denke, man kann mit Tmpeg die Einstellungen so treffen, daß die Ausgabe zu der des CCE annähernd identisch ist. Farben und Kontrast sind ja schnell verstärkt und für die Entfernung des Analograuschens muß man halt auch etwas probieren. Problem ist halt, daß man immer erst etwas rumprobieren und testencoden muß. Und das kann dauern (und erfordert natürlich auch eine Menge Wissen).
Grüße
mb1

[Helmut]

Ich denke, man kann mit Tmpeg die Einstellungen so treffen, daß die Ausgabe zu der des CCE annähernd identisch ist .. MB1
Werden wir mal angehen. Grund:
Der TMPG ist ja als (noch) kostenloses Progi der "Standart" für viele User (und vor allem Einsteiger). Insofern lohnt es schon da ne vernünftige optimierte Einstellung für SVDC /DVD und in Abhängigkeit für div. Ausgangsstreams zu finden.
Deine Tests bestätigen im Grunde meine Ergebnisse - wiewohl ich die nicht "wissenschaftlich" oder "empirisch" ermittelt hatte - mehr in Form von "Try and error". Nixdestotroz - bisher führt der CCE.
Gruß

[Kika]

@mb1
> Tatsache ist, daß mir derzeit die Testarbeit am meisten Spaß macht.
Da geht's Dir wie mir. Inzwischen fasziniert mich der Umgang mit diesen Dingen mehr als das Erstellen irgendwelcher Ergebnisse ;)
> Tatsache ist allerdings, daß die Streams des gepatchten CCE 2.50 bei der Wiedergabe besser aussehen als die der ungepatchten Version.
Nun, warum auch nicht? Die Hauptarbeit wird ja beim Encoden erledigt, und dort wirkt ja die Matrix. Bei der IDCT wird dann zwar eventuell mit der falschen Matrix gerechnet, nur, was heißt das denn im Klartext? Es kommen Werte dabei heraus, die nicht denen entsprechen, die laut DCT herauskommen sollen, das bedeutet aber nicht zwangsläufig, dass die Werte auch "falsch" sind.
Aber das müsste mal jemand mit dem entsprechenden mathematischen Wissen nachrechnen/nachprüfen.
Unterschied in benutzter und gespeicherter Matrix:
Hm, an dieser Stelle fehlt mir noch ein wenig Wissen, aber könnte es sein, dass das was mit der Nachquantisierung zu tun hat?
Farbe & Kontrast bei TMPGenc:
Bei den wenigen Malen, bei denen CCE bei mir mal nicht abschmierte, habe ich auch festgestellt, dass der bei Farbe & Kontrast Vorteile hat. Es ist aber kein wirkliches Problem, den TMPGenc so einzustellen, dass identische Ergebnisse entstehen.
Allerdings ist ist bei meinen analogen Aufnahmen wohl so, dass die Ergebnisse ziemlich unterschiedlich sind, je nachdem, welchen Codec ich benutzt habe.
Bei HuffYUV werden die Farben sehr blass, bei PICVideo sind sie kräftiger, vor allem, wenn ich beim Subsampling 1:1:1 und nicht 4:2:2 benutze.
Generell löse ich das Problem aber so, dass ich bei Custom Color Correction zwei Dinge tue (YUV Farbraum):
1. Y-Wert bei Brightness leicht erhöhen
2. Y-Wert bei Contrast stark erhöhen
Wie stark, hängt aber vom Material ab.
Ich habe mir daher angewöhnt, mehrere Testschnipsel zu encoden und auf dem Player zu testen, bevor ich ein größeres Projekt encode.

[ANDREAS]

@mb1
das sind ja sehr kleine Werte die Du hast. Vor allem hast du ja die Matrix in „zwei“ Blöcke aufgeteilt. Einen vorderen und einen hinteren. Ist das zufällig mit try and error oder ganz bestimmt so gewählt ?
Ich würde Kika auch recht geben, das der Unterschied durch die Nachquantisierung kommt. Ich glaube wichtig ist die „richtige“ Abstimmung der Matrix im encoder. Das der dann eventuell zusätzlich noch was anderes macht, soll er doch. Beeinflussen kann ich das doch sowieso nur wenn ich das ganz genau untersuche. Und wenn mein Ergebnis stimmt, was solls.
Logisch währe es wenn die zweite Matrix genommen wird. Das was ich einstelle wird wahrscheinlich nur der „erste Rechenansatz“ sein. Wenn dann ganz genau gerechnet wird kommen diese Korrekturen zum tragen. Darum kann ja u.a. Nachquantisiert werden.
Was mich noch interessieren würde ob Du die „Filter“ unter SOFTEN BLOCK NOISE gesetzt hast. Wenn nicht, pixelt es nicht da die Werte doch recht hoch sind?
Gruß
ANDREAS

[mb1]

@Kika
Ja richtig, da war doch noch was mit der Nachquantisierung. Muß ich mir mal anschauen, wie man sowas berechnen kann. Ich glaube Angel_SVCD hatte da schon Unterlagen mit den Berechnungsformeln.
@Andreas
Das ist einfach die voreingestellte Smooth-CG-Matrix des CCE 2.62 ! Der Non-Intra besteht im übrigen aus lauter 16ern.
Das benutze ich derzeit für "Only-One-CD" und für Analog-Kamera-Material.
Muss mir nur noch die Auswirkungen auf DV-Material und auf DVD-Material anschauen.
Obgleich die Matrix eigentlich für Computergrafiken (CG) gedacht ist, liefert sie in meinen Augen doch gute Ergebnisse.
@Helmut
Ja genau, da hast du recht. Steht aber momentan bei mir etwas hintenan.

[mb1]

@Andreas
Soften Block Noise war 2x auf 5

Übrigens kann man mit bbmpeg beliebige Matrizen in den Mpeg-Header muxen ! Das hatte ich vorher noch nie probiert.

[mb1]

In meinen Analogtest hat sich ein Fehler eingeschlichen.
Und zwar bin ich eigentlich so vorgegangen, daß ich mir anhand des Originals einen interessanten Frame ausgesucht habe.
Dann habe ich die Bildqualität dieses Frames bei den Encodern untersucht. Im ersten Test mit der Hubschrauberlandung ist im Prinzip alles in Ordnung. Alle untersuchten Bilder waren zufällig B-Frames und daher gut vergleichbar.
Der zweite Test macht da leider einen Unterschied (hatte ich wohl Pech ;)). Und zwar ist das Bild nur beim CCE ein B-Frame und bei Tmpeg und dem LSX jeweils ein I-Frame.
Nun war ich ja bisher immer der Meinung, die I-Frames müssten eigentlich die besten sein, da sie am größten sind und die meisten Infos enthalten und sich ja die anderen Frames von dem I-Frame ableiten.
Tatsächlich ist es aber wohl so, daß die B-Frames die besten sind bei Analog-Material (bei DV-Material wie der Achterbahnfahrt sind es die I-Frames).
Jedenfalls schneiden Tmpeg und LSX im zweiten Test nur deswegen so schlecht ab, da es sich um I-Frames gehandelt hat. Die danebenliegenden B-Frames bieten ein besseres Bild. Muß ich also meinen Test nochmal überarbeiten.
Stellt sich mir allerdings die Frage, ob man bei analogem Material vielleicht die GOP so anordnet, daß möglichst viele B-Frames vorhanden sind ?
Wollte das nur schnell anmerken ...

[Kika]

Dazu kann ich eventuell was beitragen.
Ich weiß jetzt nicht, wie CCE das handhabt, aber wenn man dem TMPGenc mal bei der Arbeit zuschaut (Log-File), merkt man sehr schnell, dass er bei stark bewegten Szenen die I-Frames sehr viel stärker komprimiert. Bei interlaced Video ist dieser Effekt noch stärker ausgeprägt. Dadurch sinkt logischerweise die Qualität der I-Frames, während die der B-Frames gleich bleiben kann (nicht muss). Das hält so lange an, bis im auch dafür die Bitrate ausgeht und er gezwungen wird, die stärker quantisierten Intra-Blocks zu benutzen. Dann kommt's zu diesen Unschärfeeffekten wie "lebenden Wänden".

[Helmut]

Reden wir von der gleiche GOP ?
IBBPBBPBBPBBP = bei TMPG 1 / 4 / 2 / 1
Nur um sicher zu gehen - will das auch mal nachvollziehen.
Gruß

[mb1]

GOP in Tmpeg war 1/4/2/1, allerdings nicht "Close all GOPs". Da verändert Tmpeg ja dann die GOP-Struktur (CCE dagegen nicht, kann das sein, oder zeigt er es nur nicht an in den Einstellungen; muss ich mir auch noch ansehen !).
Die genaue GOP-Struktur ist auf der Startseite des Analogtests aufgeführt.
@Kika
>stark bewegten Szenen die I-Frames sehr viel stärker komprimiert
Sind die dann also in der Größe kleiner ? Das ist doch eigentlich kontraproduktiv. Für mehr Bewegung kann er doch bei VBR die Bitrate hochsetzen, also auch (vor allem) die I-Frames größer machen. Wenn er die I-Frames aber kleiner macht, müssten doch zumindest P- und B-Frames größer werden, denn irgendwo muss er die Bitrate ja hin stecken ...

[Helmut]

[/i]... GOP in Tmpeg war 1/4/2/1, allerdings nicht "Close all GOPs". MB1 [/i]
Eben drumm. Hat mich ja gewundert. Das "Close all GOPs" ist aber notwendig für die DVD-Authorisierung. Sollte doch aber auf die Qualität keinen Einfluß nehmen - oder doch ?
Gruß

[Kika]

@mb1
> Sind die dann also in der Größe kleiner ?
Nicht kleiner als andere Frames, das nicht, aber deutlich kleiner als in ruhigen Szenen.
Wie stark sich das auswirkt, ist aber sehr stark vom Q-Wert bei 1pass VBR oder der erlaubten Varianz bei 2pass abhängig.
Wenn ich ihn so einstelle, dass er sowieso ständig in der Nähe des Maximums encodet, dann ist der Effekt natürlich am größten, wähle ich den Q-Wert aber niedrig, dann fällt das kaum auf.
Und ja, er steckt die gewonnene Bitrate in die B- und P-Frames. Wie gesagt, anhand des Log-Files ist das ganz gut zu beobachten.
Die größte Variation in der I-Framegröße hatte ich bei einer Szene, in der zunächst das gleiche stehende Motiv zu sehen war, das dann in einen Schwenk überging. Im ruhigen Teil hatte der I-Frame 72 KB, im Schwenk dann nur noch 43! Alles bei einer 1/5/2/1-GOP.
@Helmut
Nun, bei offenen GOPs hängt TMPGenc ja noch 2 B-Frames mit dran, die ja auch Bitrate benötigen, durchaus möglich, dass das Auswirkungen auf die Qualität hat. Effektiv gesehen ist die GOP ja dadurch größer.
(Edited by Kika at 11. Okt. 2001

[mb1]

@Kika
Das meinte ich, das die I-Frames im Vergleich zu anderen I-Frames schrumpfen.
Das mit der Varianz bei 2pass ist mir eigentlich auch klar. Mich stört nur die generell schlechte Varianz von Tmpeg. Zusätzlich zu den Bitratenbeispielen auf der Analogtestseite hier mal die Bitrate eine Achterbahnfahrt von DV-Material gewandelt:
Bitrate war auch hier: min 2.000 avg 4.000 max. 5000
Jede waagrechte Linie stellt 1.000 kbps dar, wobei die unterste 2.000 kbps und die oberste demnach 6.000 kbps zeigt.
Tmpeg 2.00 macht daraus:

Der CCE 2.62SP macht daraus:

Mir ist klar, daß für eine optimale VBR-Varianz das Maximum nun besser in Richtung 7-8.000 angesiedelt wäre, aber andere Encoder können es ja auch trotzdem.
Tmpeg nutzt das vorgegebene Spektrum einfach nicht aus, während der CCE dies vorbildlich macht.

@Helmut
Gibt es denn kein Authoring-Programm, was fehlende "Closed GOPs" nicht bemängeln würde und die so erstellten DVDs trotzdem einwandfrei auf den meisten Playern laufen ?
Im Handbuch des CCE steht dazu:
"When strong random accessibility for a stream is demanded (an example is when a multi-angle is used for DVD-creation, where frequent channel hopping is executed), set this option, then all GOPs can be set to Closed GOP (individual frames in a GOP do not refer to frames outside the GOP). Since image quality slightly drops, use this function only when absolutely necessary."
Die Qualität verschlechtert sich also vermutlich dadurch, auch wenn das auf die unterschiedliche Qualität der I- und B-Frames als Feststellung an sich ja keine Auswirkungen habe dürfte (und zwar die mangelhafte Qualität der I-Frames).
Ich möchte also im Prinzip jetzt noch XSVCDs (mit 720x576, hoher Bitrate und offenen GOPs) erstellen, deren Stream ich später 1:1 auf DVDs übernehmen kann (lediglich halt umauthoren !).