Farbunterschiede nach dem Rendern

:welcome:

Mir fallen dazu ein paar mögliche Ursachen ein:

- Coring: Weil der Fernsehbildschirm (im Vergleich zum PC-Monitor) die Helligkeit und Farbigkeit eher verstärkt wiedergibt, wird sie gleich von vorn herein eher vermindert gespeichert. Nicht jeder Player zeigt das dann auch korrigiert am PC-Monitor.

- Overlay: Die schnellste Art, Video auszugeben, ist das Hardware-Overlay (ein Speicherbereich der Grafikkarte, in den der PC nur hineinschreiben darf, und nur der Videosignalerzeuger lesen kann). Dieses Signal hat seine eigene Steuerung der Helligkeit, Farbigkeit und Sättigung. Das Overlay wird jedoch auch nur bei der Wiedergabe bestimmter Videoformate verwendet. Andere Videoformate verwenden kein Overlay, und werden statt dessen von der Desktop-Farbsteuerung beeinflusst.

- Chroma Subsampling: Weil die Helligkeit viel detaillierter wahrgenommen wird als die Farbigkeit, werden Informationen über Farbton und Sättigung in stark komprimierenden Formaten mit geringerer Auflösung gespeichert (YUV Chroma Subsampling 4:2:0 = nur je eine Farbigkeit für 2x2 Pixel im Quadrat) als im Original (RGB 4:4:4 = jedes einzelne Pixel mit eigenen Werten). Ein-Pixel-dünne Linien sind also im Allgemeinen eine ganz schlechte Idee.

So subtil wie der Unterschied ist, weil v.a. die 1-px-Linien betroffen sind und die Art wie diese Linien einfach »matter« werden, deutet imo extrem stark auf den Farbraum hin.

Das lässt sich auch nicht vermeiden, weil alle modernen Codecs praktisch ausschließlich mit YV12 (d.h. 4:2:0-Subsampling) arbeiten. Du kannst höchstens das Quellbild so gestalten, dass die geringere Farbauflösung möglichst wenig auffällt. Das ist imo schon der Fall. Ohne die beiden Bilder in verschiedenen Tabs zu öffnen und schnell hin und her zu schalten, ist der Unterschied nicht zu erkennen.

Besonders stark fällt es bei rot und blau auf; grün ist nicht so extrem betroffen, aber keine Ausnahme - jeder Wechsel von Farbton oder Sättigung am Rand von überwiegend satten Farben wird stärker davon beeinflusst als nur Helligkeitsänderungen bei eher gleichbleibender Farbigkeit (was so ja auch in der Natur häufiger passiert).

Fragmente? ... Artefakte, wohl?

Professionell werden Flash-Seiten wohl eher so aufgebaut, dass Farbverläufe zum Teil mathematisch oder per Alphamaske generiert, Texte als Kurven bzw. Vektor-Objekte eingefügt und Linien gezeichnet werden. Ohne Video. Mit geskripteten Animationen und sensitiven Bereichen, die ihre Aktivierungseffekte in Echtzeit anwenden.

Gerade sanfte Farbverläufe sind eine Sache, bei der MPEG-verwandte Videocodecs so ihre Schwächen zeigen.

Noch mal, wie schon ^ oben von Brother John korrigiert:

Riesengroße Bilder bitte nur als URL einfügen, nicht als Inline-Bild.
__

Wie schon gesagt, ist "Flash" im Grunde ein Vektor-Animations-System.

"Flash Video" hat damit nicht viel zu tun.

Vektor-Animationen, die mit Flash und Action Script programmiert werden, brauchen häufig nur wenige hundert KB (meist wegen eingebundener Grafiken, alles andere sind Zeichenbefehle und Effekte).

Flash-Video in den Dimensionen, die du hier vorbereitest, müssten mit VP6 oder MPEG4-AVC komprimiert werden, und würden trotzdem mehrere ('zig) Megabytes groß werden, obwohl die Qualität schlecht wird. Wer, der kein DSL hat, würde sich diese Seite freiwillig anschauen wollen? (Und davon gibt es auf dem Lande noch jede Menge, und wir haben schon fast 2010.)

MotionSearch&Co haben mit der Farbdarstellung nichts zu tun.

Nun ja - man kann für 0,5% kleinere Dateien 50% mehr Rechenzeit investieren.

Muss man aber nicht. Wir wollen doch der Umwelt zuliebe Energie sparen...

Und vor allem sollte man bedenken, dass die mit größtem Aufwand komprimierten AVC-Videos leider auch mit größerem Aufwand abgespielt werden müssen. Und manchmal ist der Aufwand größer, als es z.B. ein Blu-ray- oder sonstiger AVC-Player unterstützt.

Es ist schon etwas länger her, und ich schätze mal, es wurde noch nicht auf den neuesten Stand aktualisiert ... aber "Wissenswertes rund um x264" (Download im FlaskMPEG-Forum) ist immer noch eine nützliche Übersicht über die Optionen und ihre Auswirkungen als Gewinn und Kosten.

Meine Empfehlung: Nimm einen sinnvollen Kompromiss zwischen Aufwand und Nutzen. Wesentlich besser als z.B. DivX 5/6 ist x264 allemal. Und alle Rechenkerne zu 100% auslasten ist technisch ohnehin fast unmöglich.

Zitat

Und vor allem sollte man bedenken, dass die mit größtem Aufwand komprimierten AVC-Videos leider auch mit größerem Aufwand abgespielt werden müssen

Was aber gerade bei MotionEstimation&Co nicht der Fall ist.;)

Da mir nicht so ganz klar ist was Du durchlesen willst würde ich spontan empfehlen:
1. den Standard und generelle Leküre (z.B. bei: http://neuron2.net/library/avc/)
2. Erläuterungen zu Tools und direkt zum Encoder: MeGui Wiki, MeGui Essentials, Brother Johns Encodingwissen, Avidemux Anleitung, man x264,....
3. einfach mal hier und im englischen Doom9 die Suche bemühen.

Bei H.264 ist es so das die meiste Performance beim Decodieren für CABAC (je mehr je höher die Datenrate ist) gewichtete B-Frames und das Deblocking drauf gehen, da man auf diese aber nicht verzichten sollte, da sie für einen Großteil der Effizienz von H.264 verantwortlich sind würde ich empfehlen von ihnen die Finger zu lassen. (Ansonsten kann man sie mit '--tune fastdecode' auch deaktivieren.)

Wichtig ist vor allem, worum es LigH vermutlich eher ging zu wissen welches Profile&Level vom Wiedergabegerät unterstützt wird. Profile&Level bestimmen welche Features, Datenrate usw. zulässig sind, etwas pauschalisiert kann man sagen, dass je höher Profile&Level sind desto mehr CPU Power wird man brauchen beim Decodieren.

Heutzutage macht es meiner Ansicht nach aber nur noch Sinn auch Decoding Performance zu optimieren, wenn man für eine bestimmte Hardware encoded, welche nur Material dekodieren kann was bestimmte Vorraussetzungen erwartet,.. siehe z.B. hier und den dazugehörigen thread im englischen Forum.

Generell würde ich im Umgang mit x264 die oben genannten Quellen mal zu überfliegen um ein generelles Grundverständnis zu haben was die einzelnen Optionen machen und dann erst mal auf die presets&tune Einstellungen von x264 betrachten, überlegen warum dort was eingestellt wird und anschließend den Aufruf nach eigenen wünschen anpassen.

Cu Selur

Ps.:

Zitat

-Farbspektrum auf 0-255 gestellt
-FFDSHOW forciert nur in 32Bit auszugeben

vielleicht ganz interessant: http://forum.doom9.org/showthread.php?t=143598

@ Selur:

Was er durchlesen will? -- "Wissenswertes rund um x264"!

Und ja ... eine aufwändigere Suche nach Bewegungen ist kein Problem für die Decoder (außer wenn die Profile@Level Beschränkungen in der maximalen Entfernung setzen). Da die meisten Bewegungen horizontal stattfinden, ist eine hexagonale Suche vorzuziehen, "umh" sollte aber meist als Strategie mit sinnvoll hohem Aufwand genügen ("esa" wäre für die meisten Fälle schon Zeitverschwendung).

Auch bei der SubME gibt es heute eine Reihe von Möglichkeiten (aktuell 0-10), wie aufwändig die Bestimmung stattfinden soll. Hier gibt es aber auch Abhängigkeiten zu anderen Optionen, die ihrerseits ebenfalls die Rechenzeit beeinflussen (z.B. Trellis-Quantisierungssuche, Adaptive Quantisierung). So kann sich durchaus ein erheblicher zusätzlicher Rechenaufwand aufsummieren, der letztlich nur geringe Vorteile gegenüber einer zwei Stufen niedrigeren Einstellung bietet - je nach Optionen-Menge im Vergleich...

@ Pete-:

:google: bringt den Beitrag mit dem Anhang zum Download als ersten Treffer.

Siehe auch Forenregel 2.1.