Braucht man die colormatrix.dll?

Soweit ich in dem Beitrag in englischen Forum gelesen habe, wäre der Vorteil dieser DLL vor allem, dass ihre Arbeitsweise auf dem Wissen basiert, warum es zu diesen Unterschieden kommt; sie setzt also an der Ursache an, nicht nur an ihrer Wirkung. Jedoch muss man dann wohl auch klar eingrenzen, unter welchen Voraussetzungen es zu dem angesprochenen Effekt kommt.

Es gibt definitiv einen erheblichen Unterschied, welche Art von Interpretation und Verarbeitung der abgespeicherten Daten im MPEG-Video sinnvoller ist, abhängig vom jeweiligen Zweck: Ob man sich das Ergebnis auf einem Fernsehbildschirm anschauen will, oder auf einem PC-Monitor, oder ob man die Daten weiterverarbeiten möchte.

Speziell die Frage der Weiterverarbeitung hat einer unserer erfahrersten Mitglieder mal ganz genau untersucht (wer war das gleich - Kika wahrscheinlich), wie man De- und Encoder bei einer Umkonvertierung von MPEG2 nach MPEG2 einstellen sollte: Decodieren nach PC- oder TV-Scale, Encodieren von TV- oder PC-Scale? Seine Ergebnisse kenne ich leider nicht mehr - aber ich weiß, dass es mal einen recht ausführlichen Beitrag darüber gab (wer findet den wieder?).

Natürlich läßt sich dieses Ergebnis auch wiederum nicht komplett auf die Encodierung mit DivX oder XviD übertragen. Insbesondere dann nicht, wenn noch nicht klar ist, womit dieses Material dann wiederum abgespielt wird (TV-Out oder PC-Monitor - Röhre oder TFT, mit Wiedergabe-Filter-Korrekturen oder ohne ...). Aber ich halte es für ziemlich sicher, dass das Material auf DVDs optimiert ist für die Wiedergabe auf einem Fernseher, und Fernsehbildschirme haben keine lineare Helligkeitsdarstellung - wer wissen will warum, der müsste sich mit den Details der Fernsehsignale beschäftigen, vor allem ihren Spannungswertebereichen.

"- Haben DVD2AVI/DGIndex wirklich einen Bug, oder verhalten sie sich lediglich anders (vielleicht sogar richtiger) als mpeg2-Decoder von Playern? Siehe auch hier.
- Ich habe von der colormatrix in Verbindung mit DVD's gelesen. Betrifft das auch andere mpeg2-Quellen, z.B. DVB?
- Was meint Ihr?"

Also ich habe mir das mal angeschaut und laut Readme taugt das eher für DIVX und XVID. Hier der entsprechende Hinweis:

Limitations
* requires progressive video

Daher ist das in meinen Augen für MPEG2 nur bedingt zu gebrauchen, zumindest was DVB angeht.

Was die Farbdarstellung angeht komme ich mit TV Scale gut klar. Wenn ich den Procoder verwende muss aber noch der Befehl "ColorYUV(levels="PC->TV")" ins Script rein bzw. der entsprechende interne Filter des Procoder aktiviert werden, da der Procoder ansonsten das Bild verfälscht und zu dunkel darstellt. Kann man sehr schnell feststellen indem man Quelle und Ergebnis miteinander vergleicht.

Was hat DivX/XviD mit Progressiv zu tun?

Weil bei DivX/XVID interlaced nicht richtig klappt und man daher eh zum deinterlacen gezwungen ist. Es spielt keine Rolle, weil man so oder so immer progressive Videos hat, die man bearbeitet. Man deinterlaced also nicht extra um colormatrix.dll verwenden zu können.

Interlaced MPEG2 zu deinterlacen macht aber wenig Sinn. Zumindest bei den meisten DVB Streams ist das Teil daher nicht zu gebrauchen. DVDs sind allerdings häufig auch Progressiv. Da macht es vielleicht Sinn.

XviD 1.1 interlaced klappt nicht richtig? - Das wäre fast einen eigenen Beitrag wert, das mal in Ruhe auszudiskutieren...

Mag sein, da mich XVID/DIVX nicht sonderlich interessiert, bin ich diesbezüglich nicht auf dem neuesten Stand.

Interlaced Encoding ist schon lange bei XVID möglich, nicht erst seit der aktuellen Version. Bei mir hats in vielen Tests wunderbar funktioniert.
Lediglich manche DVDplayer mit Xvid/mpeg4 Unterstützung haben Probleme mit der interlaced wiedergabe.

Zitat

Ich hab mal nach der colormatrix.dll gesucht, aber nicht viel gefunden, siehe aber hier.

Meine Fragen:
- Haben DVD2AVI/DGIndex wirklich einen Bug, oder verhalten sie sich lediglich anders (vielleicht sogar richtiger) als mpeg2-Decoder von Playern? Siehe auch hier.

Es ist nicht ein bug. Es gibt mehrfache weisen, eine YUV->RGB umwandlung zu tun. Die weise fur eine mpeg2 stream ist gespeichert (stored) in der header. Wenn du die mpeg2 in dvd2avi importiert ist die info verloren gegangen.

Zitat

- Ich habe von der colormatrix in Verbindung mit DVD's gelesen. Betrifft das auch andere mpeg2-Quellen, z.B. DVB?

Um dieser zu kontrolieren (konnte vom dvb stream abhangen, keine ahnung ...) sollen sie die stream in gspot offnen um die gebrauchte koeffizienten zu lesen.

Zitat

Naja, DVB-Dateien sollten als Transportstream an sich keinen Header haben.

Ich dachte das mpeg2 streams (auch mpeg2 in ts) immer ein header hatte.

Zitat

Das wäre aber nicht so toll. Wenn die Art und Weise, wie die YUV->RGB Umwandlung stattfinden müßte, von Headerinformationen abhängt, und wenn diese nach dem Import in dvd2avi verloren gehen, dann kann die colormatrix.dll ja auch auch keine ideale Lösung sein. Wenn nämlich dvd2avi zufällig genau so decodiert, wie es lt.

dvd2avi decodiert nicht. Aber du bist richtig, wenn das mpeg2 stream bt.601 coefficients brauchte, und er encodiert das zu XviD/DivX, sollte ihr keine colormatrix gebrauchen.

Selbstverständlich brauchen auch MPEG-Video-Dateien das, was bei anderen Formaten als "ein Header" am Anfang der Datei zu finden wäre: Informationen über Bildfläche und Bildwiederholrate. Genau so hat auch ein MPEG-Datenstrom entsprechende Blöcke, in denen solche Informationen gespeichert werden. Bei einem Transport-Stream, der an jedem GOP einen Wiedergabestart erlauben soll, müssen solche Blöcke sogar wesentlich häufiger verwendet werden, als bei statischen Dateien, die einen definierten Anfang haben, zu dem man auch mal zurückspringen kann ("zurückspringen" geht ja bei Streams nicht).

4 Byte Header, 184 Byte Payload pro Paket. Im Header werden recht viele Parameter abgearbeitet, z.B. auch das Scrambling...