Luminanz-Probleme

[Kika]

Hallo,

ich krieg' hier grade die Kriese...

Angeregt durch diverse Diskussionen darüber, wie DV-Codecs den Luma-Level interpretieren, habe ich heute mal überprüft, wie verschiedenen Programme das eigentlich handhaben - und bin aus allen Wolken gefallen!

Ausgangsmaterial waren ein MJPEG-Video (PICVideo) und ein D2V-File.

Im Media-Player sehen z.B. das Original-AVI und eine durch AVISynth gejagte Version (kein Processing) absolut gleich aus - nämlich mit ziemlich hohem Kontrast. Das ändert sich schlagartig, wenn ich das AVISynth-File in VirtualDub oder TMPGEnc öffne - hier ist die AVISynth-Version eindeutig zu dunkel. Das Script wird so angezeigt und encodet, wie es auch der Media Player wiedergibt. Das AVI direkt hingegen so, wie es auch in der VirtualDub-Preview während der Aufnahme zu sehen war. Das bestätigt auch die Histogramm-Funktion von TMPGEnc. Während beim AVI der Luma-Bereich 16-235 angezeigt wird, ist es beim Script die volle Range von 0-255.
Das gleiche passiert, wenn ich ein D2V einmal über AVISynth (MPEG2DEC3) oder direkt in TMPGEnc öffne - wieder ist die AVISynth-Version dunkler.

Ich habe früher immer geglaubt, dass z.B. CCE kräftigere Farben erzeugt, nun, das liegt daran, dass er das genauso macht wie der Media Player - voller Luminanz-Bereich statt des richtigen.

Im Moment stehe ich schockiert auf dem Schlauch, denn das bedeutet nichts anderes, als dass ALLE Videos, die ich mit AVISynth und TMPGEnc encodet habe, eine verkehrte Luma-Range haben, während alle Videos, die ich über VirtualDub und TMPGEnc encodete, so sind, wie sie sein sollten. Die CCE-Videos sind ebenfalls alle verkehrt.
Die diversen Funktionen von AVISynth, wie z.B. der Limiter helfen da auch nichts mehr.
Die Frage, die sich für mich daraus ergibt, ist folgende: Ich kann nicht glauben, dass das IMMER so ist, das müsste doch längst jemandem aufgefallen sein. Vielmehr denke ich darüber nach, ob es an der Kombination der installierten Codecs bzw. Wiedergabe-Filter liegt. Den MSYUY2-Codec habe ich entfernt, damit entweder HuffYUV oder AVISynth das Decodieren von YUY2-Daten übernehmen, das hat aber auch nichts gebracht.

Ideen? Vorschläge? Hab' ich 'n Brett vor'm Kopf?

Gruß,
Kika

[Kika]

Na, dann antworte ich mir mal selbst...

Es war das berühmt berüchtigte Brett vorm Kopf bzw. eine unvollständige deutsche Dokumentation zu AVISynth. Die Lösung nennt sich... tadaa...

ColorYUV(levels="PC->TV")

Damit klappt's dann.

Manchmal wünschte ich, ich wäre nie auf die neueren Versionen umgestiegen...

[Angelika]

[SVCDFan]

[shh]

Ich möchte nur mal auf nen Standardfehler hinweisen. Leider übersieht man das immer wieder bei Farbvergleichen.
Ich hoffe, dir ist das nicht passiert. [zusätzlich]

Wenn man einen Film öffnet, wird für den ersten meistens die DirectDraw Overlay-Ebene benutzt.
Öffnet man nen zweiten (gleiche Quelle), ist fürs decodieren die Overlay-Ebene belegt. Es muss also auf eine neue projeziert werden. Dabei kann's dann sogar dazu kommen, dass der codec zu einer anderen Farbtiefe decodieren muss.
Die Overlay-Ebene hat (je nach Grafikkarte und Einstellung) ganz andere Farben/Kontrast, als "normale" BildEbenen, so dass man zT gewaltige Unterschiede ausmachen kann - trotz gleichem Ausgangsmaterial.
=> Beim Vergleich aufpassen
_________________
shh >>> shh's MPEG-tools

[Kika]

DIE Falle kenn' ich.

Ich hab's so gemacht: Video in TMPGEnc geöffnet, Histogramm anzeigen lassen. TMPGENc beendet.
Neu gestartet, Script geöffnet, Histogramm anzeigen lassen.

usw. usf.

Das ganze je einmal mit und einmal ohne eingeschaltetes Overlay in TMPGEnc, das aber ohnehin keinen Einfluss auf das Histogramm hat.

Das Verhalten ist zu 100% reproduzierbar.
Ohne ColorYUV(levels="PC->TV") habe ich grundsätzlich zu kontrastreiche Videos. Mit dem Befehl im Script ist der Unterschied auch im Media Player sichtbar.
Also scheinen die einzelnen Programme das wirklich unterschiedlich zu interpretieren.
Mich interessiert nun, ob das generell so ist oder ob das in Abhängigkeit der installierten Komponenten geschehen kann.

[kempfand]

Aus dem Doom9 Forum:

[Kika]

Das kannte ich schon. Das Problem ist ja, das es bereits VOR dem Encoden nicht richtig ist.
Na ja, wie auch immer, mit dem Kommando ColorYUV klappt's ja jetzt immer - nur das WARUM ist mir eben nach wie vor nicht klar.
Außerdem ging's ja nicht um DV-Video, sondern MJPEG und D2V.

Nachtrag: BTW: ConvertToRGB24() benötige ich in meinen AVISynth-Skripten nicht, es wird auch bei YUV2-Output alles richtig.

[Kika]

So, jetzt bin ich ein Stück weiter. Einiges davon beruhte auf verschiedenen Darstellungen. shh hatte da einen guten Ansatz, was Overlay betrifft. Ein AVISynth-Skript wird im MediaPlayer ja ohne Overlay ausgegeben, das MJPEG mit und das MPEG ebenfalls mit aber über andere DirectShow-Filter. Jedes Mal ist die Farbdarstellung anders - auch dann, wenn Luminanz- und Chrominanz-Werte in allen drei Videos identisch sind. Für den endgültigen Vergleich habe ich die Einzelbilder mit VirtualDub (MJPEG, AVISynth) und MME (MPEG) extrahiert und in der Bildbearbeitung vergleichen.
Aber die Luminanzlevel sind tatsächlich bei mir grundsätzlich verkehrt, wenn ich AVISynth 2.5x einsetze.

Die Lösungen sehen so aus:

AVISynth direkt zu TMPGEnc
avisource("video1.avi")
assumeTFF()
ColorYUV(levels="PC->TV")

Premiere via PlugInPack und AVISynth
avisource("ppack1")
assumeTFF()
converttoyuy2()

Nur dann hat das resultierende Video die gleichen Farben wie ein direkt mit TMPGEnc encodetes MJPEG-Video und das MJPEG-Video selbst.

ConvertToRGB24() ist bei mir in jedem Fall überflüssig. Was mich aber wundert ist, dass ich beim PlugInPack ohne converttoyuy2() überhaupt kein Bild in TMPGEnc bekomme.

[Tsunami]

[Kika]

So, ich bin erst jetzt wieder dazu gekommen, mich damit zu befassen.

Ich habe das nochmal überprüft und muss bestätigen, was Tsunami sagt. ColorYUV(levels="PC->TV") ist tatsächlich nur eine Krücke. Vielmehr sollte man AVISynth immer explizit angeben, womit es es zu tun hat. Bei neuer Software bedeutet das zwar, das man's erst ausprobieren muss, aber nur so ist man wirklich sicher.
Also man muss herausfinden, ob YUV oder RGB geliefert, welcher Farbraum dabei benutzt wird und ob da die Luminanz-Range nicht eventuell komprimiert oder gestreckt wurde. Letzteres ist übrigens genau der Fall, in dem man ColorYUV(levels="PC->TV") dann auch wirklich benötigt (oder die 'rumgedrehte Variante).

[Kika]

So, hier nochmal was zu diesem Thema.

Ausgangsmaterial waren Captures mit BT-TV-Karte und PicVideo. Subsampling 4:2:2, Aufnahme in YUY2. Diese Kombination liefert die Range von 16-235, der Codec kann wahlweise YUY2 und RGB24 ausgeben. Und hier steckt schon die erste Falle: NUR RGB ist bei TMPGEnc richtig. Lädt man das MJPEG-Video direkt in TMPGEnc ist erstmal alles richtig, denn TMPGEnc fordert RGB24 an. Man muss dann aber bei Setting->Advanced->Quantize Matrix unbedingt Output YUV Data as Basic YCbCr not CCIR601 aktivieren.

Will man den Source durch AVISynth jagen, muss man sehr aufpassen. Schaut Euch mal die folgenden beiden Skripte an:


LoadPlugin("E:\AviSynth2.5\AVS25Plugins\convolution3d.dll")
avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToYUY2(interlaced=true)
separatefields()
Convolution3D (0, 8, 8, 8, 8, 3, 0)
weave()


LoadPlugin("E:\AviSynth2.5\AVS25Plugins\convolution3d.dll")
avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()
separatefields()
Convolution3D (0, 8, 8, 8, 8, 3, 0)
weave()


Beide machen dasselbe, beide liefern YUY2 an TMPGEnc, aber nur das erste liefert die korrekte Range, daran würde auch ein abschließendes ConvertToRGB24() nichts ändern.


Nun könnte man auf die Idee kommen, das YUY2-Skript (das zweite) zu benutzen und TMPGEnc dann CCIR601 ausgeben lassen - eine Variante, die beim Encoden erheblich schneller ist. Aber..., schaut man sich das Histogramm dieser Variante an, sieht man, dass die Farben verfälscht wurden!

In dieser Luminanz-Range-Geschichte stecken also einige üble Fallstricke drin.


Gruß,
Kika

[Kika]

So, bevor ich die AVISynth und Encoder-Gemeinde schockiere, würde ich mal einige andere Leute bitten, das selbst auch noch zu überprüfen:

Die Option "Output YUV data as Basic YCbCr not CCIR601" in TMPGEnc wird in 90% aller Guides FALSCH beschrieben! Siehe auch meinen Disput mit Wilbert im deutschen Doom9.

Hat man ein Video mit korrekter Luma-Range (16-235), dann MUSS man in TMPGEnc diese Option einschalten, genau so, wie Kempfand es zitierte. Die Option "Set equation for ColorSpace = CCIR-601" in den Environmental Settings funktioniert ausschließlich bei DV-Source mit dem Canopus DV-Codec. Für alles andere, also auch MJPEG, HuffYUV usw. muss man in YCbCr encoden - immer vorausgesetzt, die Luma-Range ist von vornherein 16-235.

Zu PicVideo MJPEG im speziellen: Der Codec kann YUY2 und RGB liefern - setzt dabei aber je nach Farbraum die Luma-Range anders um. Öffnet man ein solches Video direkt mit TMPGEnc, wird RGB erzeugt. Und zwar mit der Luma-Range 16-235, also encodet man in YCbCr.
Jagt man es durch AVISynth, hat man zwei Möglichkeiten: Als RGB oder als YUY2. Bei RGB ist alles OK, also wieder YCbCr, bei YUY2 wird die Luma-Range VERSCHOBEN. Encodet in Modus CCIR sieht das auf den ersten Blick zwar korrekt aus (fast wie RGB zu YCbCr), ein Blick ins Histogramm offenbart aber, dass da was nicht stimmt.
Das erklärt auch, warum die beiden AVISynth-Skripte aus dem vorigen Posting unterschiedliche Ergebnisse liefern.
Im Prinzip habe ich das ja schon im vorigen Posting so gesagt, mir war nur nicht klar, dass der Luma-Bereich dabei verschoben wird.

Zurück zu TMPGEnc:
Der CCIR-Modus geht von einer Range von 0-255 aus und komprimiert sie zu 16-235.
Der YCbCr-Modus komprimiert nicht, sondern schneidet Werte < 16 und > 235 einfach ab.
(das ist das genaue Gegenteil dessen, was Wilbert behauptet)

Die Crux ist, dass die meisten wohl glauben, dass diese Option in TMPGEnc dasselbe tut wie die in CCE, was aber verkehrt ist. Bei CCE stellt man damit ein, wie Encodet wird, bei TMPGEnc, wie die Luma-Range generell behandelt wird.
Anders als bei CCE kann man somit in TMPGEnc gar nicht wählen, ob man ein Output-Video mit CCIR oder YCbCr haben will - TMPGEnc erzeugt grundsätzlich Videos nach CCIR (16-235).

Zu PicVideo:
RGB-Ausgabe liefert korrekte Ergebnisse.
YUY2-Ausgabe liefert verschobene Ergebnisse. Statt 0-255 oder 16-235 liefert er sowas ähnliches wie 0-235.

[kempfand]

[mb1]

[Kika]

@mb1

Tja, genau das ist das Problem. Ich schaffe es ums verrecken nicht, wirklich alles und alle unter einen Hut zu bringen.
Wenn einer allein das testet und ausprobiert, gibt das ja keine letztendliche Sicherheit. Das schon deshalb nicht, weil ja zur Decodierung der Bilder selbst jeweils das benutzt wird (der Codec oder Filter), was beim jeweiligen Tester dazu installiert ist.

Deshalb wollte ich versuchen, zunächst mal die Encoder selbst daraufhin zu überprüfen, wie sie den Source überhaupt auslegen.
Klar, bei TMPGEnc könnte ich zumindest bei RGB da schnell ein Erfolgserlebnis haben: Einfach ein entsprechendes Bild direkt als Source laden. Aber wie mache ich das bei anderen Encodern? Und wie erzeuge ich einen YUV-Source, bei dem ich ABSOLUT sicher sein kann, dass er wirklich die vorgegebene Luma-Range hat?
AVISynth traue ich da inzwischen auch nicht mehr soooo sehr über den Weg.

Na ja, schaun wir mal.

Gruß,
Kika

[mb1]

Hier hast du 3 DV-Dateien mit unterschiedlichen Kennungen (1x Sony, 2x Canopus) mit einem Umfang von 0-255. Der Text "Hello World" liegt außerhalb von 16-235.
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."

[kempfand]

Bin gerade am suchen weiterer Info's zum Thema. Bei TMPGEnc - "Output YUV data as Basic YCbCr not CCIR601&q findet man auch jede "Meinung" sowie alle kombinarischen Möglichkeiten dazu

Gruss,
Andreas

[Kika]

Ich weiß, jeder macht und denkt da was anderes. Genau deshalb wollte ich es ja unter einen Hut bringen. Ich dachte ja auch, ich hätte es fast - und was passiert? Der mb1 kommt und bringt mit seinen MPEGs mit 0-255 alles wieder durcheinander...
Na ja, man kann es so erklären: Wenn dem so ist, wie ich es schon schrieb, dann müsste man dazu nur einen Source mit 0-255 laden und auf YCbCr umschalten.
Wie ich schon schrieb: Meiner Meinung nach (und meine bisherigen Tests bestätigen das auch), beschneidet YCbCr nichts und komprimiert auch nichts. Ist diese Option eingeschaltet, wird die Luma-Range so genommen, wie sie im Source ist.

Nun, wie auch immer. Bei den von mir beschriebenen Fällen stimmt das Ergebnis von TMPGEnc immer dann mit dem von CCE überein, wenn ich zum Encoden YCbCr statt CCIR benutze. Laut Beschreibung ist das ja auch richtig so.

[Tsunami]

Hier gibt's mehr Infos zu MJPEG und Luma-Range :
http://forum.doom9.org/showthr....umber=1

Kann jemand bestätigen, das der Sender RTL2 bei einer analogen Übertragung greller rüberkommt als zum Beispiel Sat1?
Bei mir sieht RTL2 jedenfalls sichtbar 'übersteuert' aus.