Beiträge von B_Racer

Hast Recht, jetzt erinnere ich mich wieder dran. OK, meinen Kommentar zur Matrix ziehe ich zurück. Ich hatte nur hinten auf die 48er Werte geschaut, nicht auf den Rest.

Zitat

Die Matrizen"<< falls sich kein Schreibfehler eingeschlichen hat, ist das die "Original mb1-Matrix"

Hm, deshalb muss ich sie ja trotzdem nicht mögen, oder?
Ist lange her, ich bin mir jetzt nicht mehr ganz sicher, ob die überhaupt für TMPGEnc optimiert war. Falls ja..., OK, auch ich weiß nicht alles und bin auch nicht immer einer Meinung mit mb1 (nein, wir prügeln uns trotzdem nicht).

Nochmal zum Padding: Diese Option dient dazu, Bitratenunterschreitungen auf zu füllen. Das macht bei VCD/SVCD durchaus Sinn, dann hier ja Block- und Sektorgrenzen zu beachten sind. Bei DVD ist es aber nutzlos. Höchstens, wenn man so grob geschätzt unter 1300 kbps kommt, dann wird's wieder sinnvoll. Aber Hand aufs Herz: Wer macht das schon bei den eigenen Videoschätzen?

Aber ich denke mal, das ist hier in diesem Thread etwas Off-Topic, da es mit den Feinheiten eines einzelnen Encoders zu tun hat. Kann aber gerne wo anders fortgeführt werden.

Zu den Parametern ein paar Anmerkungen:

"No motion search...." <- Das bedeutet, auf die Half-Pel-Genauigkeit zu verzichten. Gerade aber im Highest Modus ist die aber lebenswichtig.

"Padding aktivieren" <- das ist nun wirklich überflüssig und pumpt nur das Video völlig unnütz auf.

"Die Matrizen" <- Die sind weit jenseits von gut und böse. Mit High Quality-Encoding haben die absolut nichts zu tun. Wo stammen die denn her? KVCD? MVCD?

"2pass VBR" <- Das ist nur sinnvoll, wenn man eine exakte Größenvorgabe hat und funktioniert auch nur bei längeren Clips. So, wie hier eingestellt und bei der geringen Clip-Länge muss das ja logischerweise schlechter werden als die CBR-Variante.

"15ner GOP" <- Ich selbst bevorzuge einer 12er, wenn ausschließlich die QUalität und nicht der Bitratenbedarf eine Rolle spielen soll. Ist aber Geschmacksache.

Generell: Der Modus Highest benötigt absolut rauschfreies oder doch zumindest sehr rauscharmes Material, sonst kann es zu Motion Search Errors kommen, die den Bitratenbedarf in die Höhe treiben.

Man kann leicht und schnell testen, welcher Modus (High oder Highest) bei einem bestimmten Video besser ist:
Im CQ-Modus bei ca. 65 - 70% ca. 2 Minuten des Videos je einmal mit High und einmal mit Highest encoden. Sich dabei die resultierende Bitrate merken (aus dem LOG). Die Version, die den geringeren Bedarf hat, ist die bessere. Also den entsprechenden Modus setzen. Simpel, aber ziemlich hilfreich.

Na und ich brauche nichts zu beweisen. Ich habe auf Fehlerquellen aufmerksam gemacht. Wie Ihr die Infos nutzt, ist absolut Euer Problem.
Ich kann Euch nur die Tür zeigen, durchgehen müsst Ihr selber.

Ich finde es nur hochgradig interessant, dass darauf nicht eingegangen wird. Und wie gesagt, der Encoder-Test interessiert mich doch überhaupt nicht.

Den würde ich z.B. auch nicht nur an einem Video durchführen, sondern auch an geometrischen Figuren, am besten auch gleich noch an Grundfarben-Clips. Da sieht man direkt - sogar mit bloßem Auge - was passiert. Natürlich würde das nicht genügen, richtige Videos gehören zum Test auch dazu.

Zitat

und wir erwarten immer noch einen praktischen Beweis Deiner theoretischen Fahrkünste..

Ist Dein Forum, dann mach' auch den Anfang.
Außerdem siehe oben, meine Aussagen bezüglich der Luma-Range kann jeder ganz leicht selbst überprüfen. Und zwar speziell für sein eigenes System.

@Ikarus
Wieso bitteschön spielt AVISynth für Dich keine Rolle? Einige haben hier ganz klar gesagt, dass sie es benutzen! Dazu muss man sich nur mal diverse Postings richtig durchlesen - das mal nur als kleine Retourkutsche zu Deinem verbalen Angriff auf Tsunami. Aber weiter im Text: Für Dich ist also eine mögliche Fehlerquelle völlig unwichtig? Und generell zu dem, was ich schrieb: AVISynth war doch nur ein einziges Beispiel, andere hatte ich in beiden Postings genannt. Ich dachte, Ihr beschäftigt Euch hier ernsthaft mit dem Thema Video. Scheint nicht so zu sein.

Peter
Na, das war ja ein tolles Posting... Und so schön am Kernthema vorbei. Ich habe auf mögliche Fehlerquellen beim Encoden hingewiesen und auch aufgezeigt, wie man sie umgehen kann. Wenn das unwichtig ist... Aber um mal Deine eigenen Analogien zu benutzen: Ohne Berücksichtigung solcher Dinge kommst Du erst gar nicht vernünftig auf die Straße. Macht dann keinen Sinn, darüber zu sinnieren, wie man wieder drauf kommt, nachdem man runter geflogen ist. Dazu muss man nämlich erstmal überhaupt fahren können.

Außerdem: Wieso redet Ihr beide ständig über den Encoder-"Test" - das ist doch 'nen ganz anderer Thread!?

Peter

Bei einer Verschiebung oder Komprimierung der Luma-Range ändern sich in erster Linie die Bildhelligkeit und der Kontrast. Die Farben bleiben weitestgehend gleich, verschieben sich also nicht. Da aber die Umrechnung der YUV-Farben zu RGB-Farben unter Verwendung von Y, Cb und Cr erfolgt, also auch den eventuellen falschen Luma-Bereich mit einschließt, werden dann auch die Farben kräftiger bzw. schwächer.

Wie schon ausgeführt, hängt es oft davon ab, über welchen Weg ein Video denn nun exakt in den Encoder kommt.

Nimmt man z.B. Premiere über den Freeware-Frameserver PlugInPack sowie AVISynth, dann erfolgen unter Umständen gleich mehrere Farbraumwandlungen. Ein Beispiel:

DV-Video, YV12, Luma-Range (im Folgenden LR genannt) 16-235 (so sollte es sein).
PlugInPack macht RGB32 draus, LR wird expandiert auf 0-255.
AVIsynth... Ohne gesonderten Parameter wird versucht, YV12 anzufordern. Da das mit PlugInPack nicht geht, wird der Systemcodec zur Wandlung benutzt, nämlich MSYUV, der definitiv fehlerhaft ist.
Nehmen wir an, alles ist richtig gelaufen, dann haben wir ein RGB32-Video mit LR 0-255.
Soll jetzt wegen irgendwelcher Filter zu YUY2 oder YV12 gewandelt werden, ist es elementar wichtig, den interlaced=true Parameter zu benutzen, da sonst ein fehlerhaftes Chroma-Upsampling entsteht. Wie auch immer, LR ist nach einer solchen Wandlung 16-235.
Will man jetzt ein YUY2-Video in CCE laden, ist alles OK, da der YUY2 und RGB24 lesen kann und die LR für ihn nur bei RGB24 eine Rolle spielt. Anders beim TMPGEnc, der erwartet immer RGB24. Liefert AVISynth ihm das nicht, wird wieder per System-Codec gewandelt, der leichte Fehler erzeugt (Lumashift -2). Daher ans Ende des Scriptes ein ConvertToRGB24(interlaced=true).
LR ist nun wieder 0-255, MPEG benötigt aber 16-235. Also muss man TMPGEnc in den CCIR-Modus bringen (Standardeinstellung), der die Kompression des LR selbstständig vornimmt. Dann stimmt alles.
Kommen wir jetzt zu Codecs, die RGB24 liefern können, dabei aber die Luma-Range NICHT anpassen. Dann würde 16-235 geliefert und im CCIR-Modus von TMPGEnc das auf 32-219 komprimiert werden. Für diesen Zweck hat TMPGEnc den YCbCr-Modus, der die Luma-Range nicht ändert aber voraussetzt, dass ihm alles korrekt geliefert wird.

Man sieht schon daran, dass die Encoder zwar fast alle die Möglichkeit haben, eine Luma-Range anzugeben, diese Funktion aber jeweils völlig unterschiedlich arbeitet.

Insgesamt gibt es also zwei mögliche Fehlerquellen, und es liegt nich an uns, den Anwendern, die zu beseitigen, sondern bei den Herstellern, die sich anscheinen einen Dreck drum scheren, was ihre Programme so tun. Wir können höchstens solche Macken in Erfahrung bringen und nach Möglichkeiten suchen, sie zu umgehen, um die bestmögliche Qualität zu erhalten.

Sorry Leute, aber DIESE Art der Beschäftigung mit der Materie erscheint mir sehr viel sinnvoller als irgendwelche Encoder-Tests.

Also, wenn ich in diesem Thread Stagements lese wie "CCE ist etwas farbschwach", drängt sich mir sofort der Verdacht auf, dass hier durch gewissen Kombinationen aus Codec/Encoder/Encoder-Einstellungen und eventuell noch einem Frameserver wie AVISynth oder gar eines Teils wie PlugInPack für Premiere die Luma-Range zu stark komprimiert wurde.
Das ist schnell passiert und führt zu Videos, die flaue Farben haben. Ein Differenzbild würde dann zu eher lustigen Ergebnissen führen.

Zu den DV-Codecs: Da ist es exakt so wie beim MPEG-Encodern, der grundsätzliche Weg ist vorgeschrieben, ja, aber die Qualität unterscheidet sich zum Teil eklatant. Dazu kommt noch das, was Tsunami hier schon sagte: Je nach dem, was angefordert wird (YUY2, RGB24, YV12), kann die Lumarange den Bereich von 0-255 oder von 16-235 haben.
Die MPEG-Encoder können das nicht erkennen, und kompensiert man das nicht selbst, dann... Entweder wird's zu hell oder zu dunkel.
Je nach Kombination von Codec, Encoder und Einstellungen hat man eine 3:1-Chance, es richtig zu machen (3x falsch, nur 1x richtig).