Vista/VMR9 - Videos kontrastarm [Archiv]

HeldImZelt

2007-02-12, 05:29:12

Test: YUV/RGB Konvertierung
(Luma range test for video YUV/RGB conversions)

Symptome: Schwacher Kontrast, Grauschleier, helles Bild

Testvideos im Anhang

Zu beachten ist nur der untere, rechte Teil des Videos:

http://www.abload.de/img/hinturqo.png

Richtig: 1 Balken
Falsch: 3 (oder kein) Balken

http://www.abload.de/img/vmr9ri2dp5t.png
Bilder sind illustrativ.
Helligkeit am Monitor muss erhöht werden.

Betrifft hauptsächlich VMR9 Renderer unter bestimmten Treiberversionen und Renderpfaden. Overlay ist nicht betroffen. EVR mit gemischten Ergebnissen. Nvidia und Ati gleichermaßen betroffen. Bekannte Workarounds sind softwaremäßige Farbraumkonvertierung (FFDShow RGB32, Deaktivierung aller YUV Ausgabemodi), Shader (16..235->0..255) oder alternative Renderer (Overlay, Haali Renderer,..).

Filelist:
Luma range test - Avisynth source file.avs
Luma range test - MPEG1.m1v
Luma range test - MPEG2.m2v
Luma range test - WMV3.wmv
Luma range test - x264.mp4
Luma range test - x264vfw.avi
Luma range test - XviD.avi

Letzte Änderung:
+ x264vfw (09.07.2010)

san.salvador

2007-02-12, 07:32:03

Media Player Classic schon probiert?

Ich spiel alles mit dem MPC und ffdshow ab und ich hab das von dir genannte Problem nicht.

HeldImZelt

2007-02-12, 17:55:58

Was hast Du denn für eine Karte?
Kannst Du mal einen Screenshot von dem Testvideo machen?
Achte nur darauf dass 'View/Options/Playback/Output/VMR9' aktiviert ist. Welcher Modus genau, ist egal.

jojo4u

2007-02-13, 00:07:15

Das ist by Design. Wenn du nur Video schaust und ne Bildröhre hast, stell die Helligkeit runter.
http://www.avsforum.com/avs-vb/printthread.php?t=523614

Du kannst auch in MPC einen Shader implementieren. Output VMR9 renderless, render Video in 3D und dann unter Play->Shaders->Edit diesen Code (http://forum.doom9.org/showthread.php?p=889952#post889952) einfügen. Funktioniert bei mir prima.

aths

2007-02-13, 00:39:16

Wenn ich mit dem WMP in Vista Videos abspiele, ist der Kontrast zu schwach. Somit ist schwarz zu hell und weiß zu dunkel (Grauschleier). WMP und Zoom Player zeigen beide ein falsches Bild bei VMR9. Sieht für mich nach fehlender Farbraumkonvertierung aus. YUV Videos haben eine Helligkeitsbandbreite von 16 bis 234, während RGB 0 bis 255 hat. Das wird bei Overlay ordnungsgemäß gemacht (konvertiert), bei VMR9 fehlt das scheinbar.

Weiß jemand woran das liegt und wie man das korrigieren kann?Woran es liegt – ja, wie man es korrigiert – nein.

Es liegt daran, dass in den meisten MPEG-Videos (und auch bei anderen Formaten) schwarz nicht als schwarz (Wert 0) kodiert ist, sondern (bei Werten zwischen 0 und 255) meistens so um die 16 oder 18 herum.

Solange eine Ausgabe gewählt wurde, die sich von der Windows-GAMMA-LUT anfassen lässt, kann man mit dem aTuner im Gamma-Panel den Schwarzpunkt ändern, und somit schwarz wieder schwarz machen.

HeldImZelt

2007-02-13, 02:28:37

Ich kann es korrigieren, das ist nicht das Problem (FFDShow, alle YUV Farbräume deaktivieren), dann wird softwaremäßig (standardkonform) korrigiert. Das kann doch aber nicht im Sinne des Erfinders sein, bzw. so auf die Masse losgelassen werden. Das Bild ist.. einfach falsch (CCIR601/TV range).
Der Programmierer vom ZoomPlayer meinte damals es wäre u.U. nur ein Ati Problem, die nVidias liefen unter vmr9 einwandfrei. Mittlerweile ist aber schon einige Zeit vergangen und vmr9 wird langsam Standard. Das kann man im jetzigen Zustand aber unmöglich so stehen lassen.
Der Catalyst 7.1 von XP(!) lief im ZoomPlayer bei mir zum ersten Mal korrekt ohne FFDShow. Ich habe das leider nicht näher analysiert, aber vielleicht tut sich gerade was bei Ati.

Könnt ihr noch einige Screenshots von dem Testvideo mit Angabe der Karte (Ati/Nvidia/XP/Vista) posten? Wäre sehr hilfreich.

aths

2007-02-13, 05:31:19

Nochmal: Es ist üblich, dass Videos so kodiert werden, dass Schwarz als Dunkelgrau gespeichert wird. Das müsste die Abspielsoftware selbst umrechnen. Bei Wiedergabe auf einem TV wird dies vom DVD-Player zum Beispiel nicht gemacht, entsprechend wird die eigentlich mit MPEG mögliche Dynamik nicht ausgenutzt.

Ich weiß nicht, was die aktuellen Software-Player machen. Man könnte den Bereich 16..235 auf 0..255 strecken (was jedoch die Colorbanding-Gefahr erhöht) oder man könnte alles <16 einfach auf 0 abschneiden.

jojo4u

2007-02-13, 12:56:10

Bei Wiedergabe auf einem TV wird dies vom DVD-Player zum Beispiel nicht gemacht, entsprechend wird die eigentlich mit MPEG mögliche Dynamik nicht ausgenutzt.

Wieso sollte man durch Streckung mehr Dynamik rausholen?

aths

2007-02-13, 17:04:30

Wieso sollte man durch Streckung mehr Dynamik rausholen?Weil es sinnvoll sein kann, einen schwarzen statt grauen Weltraum zu haben?

HeldImZelt

2007-02-13, 22:46:53

aths

2007-02-14, 04:05:36

Das wird deshalb so kodiert damit die Spannung der Röhre (TV) nicht übersteuert wird. Dazu findet man Dokumentation im Netz, darauf will ich nicht näher eingehen.

Alle YUV Materialen unterliegen dieser limitierten Luminanzbandbreite. Das Problem ist das bei Overlay ein korrektes Bild erscheint und bei VMR9 nicht (Mißstand).

Das obige Testvideo ist 16...235 yuv kodiert und bei Overlay vollkommen schwarz, so wie es sein soll.

DVD Player brauchen nichts korrigieren, weil auf dem TV '16' absolut schwarz ist (0 Volt) und '235' absolut weiß (max.Volt). Das ist gewollt, bzw. musste so (aus alten Zeiten) übernommen werden.Auf meinen Röhren-TVs ist "schwarz" (ca. „16“) nicht voll schwarz. Wenn ich die Helligkeit so weit herunterregele, dass es voll schwarz ist, laufen die Schatten zu.

Bei den Overlays die ich so kenne, bis auf das einer Test-6800, war „16“ grau. Auf der 6600 GT ebenfalls, obwohl es auf der 6800 schwarz war. Auf meiner 7600 GT ist es auch grau (und es gibt nach wie vor keine Gamma-Korrektur dafür = megapeinlich für NV.)

HeldImZelt

2007-02-15, 03:22:59

Auf meinen Röhren-TVs ist "schwarz" (ca. „16“) nicht voll schwarz.
Der Satz ist unter Berücksichtigung der Problematik unvollständig, da nicht hervorgeht aus welcher Betrachtung dieser Wert ermittelt wurde. Handelt es sich um einen RGB Wert im RGB Farbraum (z.B. Malen in Photoshop im RGB Farbraum auf PC Monitor), ist 16 in der Tat nicht Schwarz und die Aussage richtig. Handelt es sich aber um einen Y=0 Wert (TV Scale, absolut Schwarz), der im RGB Farbraum gemessen wird (z.B. DVD wiedergabe auf PC Monitor), sollte ebenfalls der dunkelste Helligkeitswert des RGB Farbraums (RGB 0,0,0) erscheinen. Wenn dann aber RGB 16,16,16 erscheint, wurden die YUV Helligkeitswerte fälschlicherweise 1:1 übernommen, da der dunkelste Y Wert (technisch) nicht als '0' gespeichert wird, sondern als '16', weil es der Standard so verlangt. Die Ausgabegeräte sind angewiesen den Wert 16 als Schwarz darzustellen (0 Volt). Nebenbei angemerkt sei, dass es auch einen Standard mit voller Y Helligkeitsbandbreite (Luminanz[Y] 0-255) gibt. Jener ist aber nicht für TV Material gedacht und wird auch nicht bei DVDs angewendet.

Schau dir das Testvideo an und stelle die Helligkeit hoch, sodass Du rechts unten die Balken gut erkennen kannst. Siehst Du dort drei Balken, ist das Bild falsch. Hebt sich nur ein Balken ab, ist das Bild richtig.
Zur Illustration habe ich den Effekt hier verstärkt dargestellt:
http://img165.imageshack.us/img165/1415/yuvty7.png

Zur Erklärung zitiere ich die Avisynth Dokumentation zum 'Colorbars' Befehl, womit das Testvideo erstellt wurde.
The lower part of ColorBars is called the pluge. From left to right it consists of: -I, white, +Q, black, -4/0/+4 IRE levels and black. The -4/0/4 IRE levels can be used to set the brightness correctly. The -4 IRE and 0 IRE should have the same brightness, and the +4 IRE should be less[?] bright than -4/0 IRE.

Dass sie bei +4 IRE (http://en.wikipedia.org/wiki/IRE_%28unit%29) 'should be less bright' geschrieben haben, muss ein Druckfehler sein. Richtig sollte es 'should be more bright' heißen. Der Wert ist unter jeder Betrachtung heller als -4 und 0 IRE. Der Wert -4 IRE ist nicht PAL konform und dient bei einem Testbild lediglich zu Kalibrierungszwecken. Das Testvideo ist somit streng genommen auch nicht korrekt, weil -4 IRE den gültigen Helligkeitsbereich des TVs unterschreitet.

Wenn man demnach einen Unterschied zwischen -4 und 0 sehen kann, wurde das Bild nicht ordnungsgemäß in den Zielfarbraum konvertiert, mit Gamma hat das aber nichts zu tun.

jojo4u

2007-02-15, 04:15:41

Das wird deshalb so kodiert damit die Spannung der Röhre (TV) nicht übersteuert wird.

Es gibt wohl auch weitere Gründe:

“Why does data below black even exist? That makes no sense! What can be blacker than black!?”
In video, headroom and footroom is important for a number of reasons. The most basic is that mastering can be less than perfect, so some “fudge-room” has always existed. However, even with ‘perfect’ mastering, data regularly extends outside reference black/reference white. Peak white data allows for highlight details to be maintained, which is common in clouds and other bright objects. BTB data helps prevent image anomalies from hard clipping of the analog waveform at black when converted to analog. BTB can also sometimes become visible as the actual black level on a CRT display floats up and down with image content because black level retention on CRTs is not perfect. The mastering engineer is viewing on a CRT display and actively changing the encoded levels so that they are imaged correctly on the display. This reverse-float compensation in black is allowed with BTB footroom. This reverse float compensation should be the only times data encoded below black is visible in the final image. If you are using a PLUGE pattern with BTB bars to calibrate, you should calibrate so that the BTB data is not visible. BTB data also helps define dithering duty patterns on DLP projectors. Lastly, BTB and peak white data is quite useful for any image processing/scaling etc applied to an image. For all these potential reasons, video engineers advocate preserving full BTB and peak white data whenever possible. Lastly, this data is helpful for any image processing that is applied on an image, such as sharpening, scaling, etc.

Gast

2007-02-15, 12:39:14

So und gibt es eine Moeglichkeit unter ZoomPlayer mit VMR9 den Kontrast irgendwie wiederherzustellen (also so zumachen wie unter OverLay)?

MfG

HeldImZelt

2007-02-15, 15:04:01

Ja, mit FFDShow (http://sourceforge.net/project/showfiles.php?group_id=173941).
Dort deaktiviert man alle YUV Farbräume, damit FFDShow die Daten als RGB ausgibt (Softwarekonvertierung, hoher Rechenaufwand).

http://img179.imageshack.us/img179/9247/ffdshowhg6.png

Als Dauerlösung ist das aber nicht passabel. Man verzichtet quasi auf einen Teil der Hardwarebeschleunigung (GPU) und verlagert es auf die CPU.

Hast Du das Problem denn auch? Wenn ja, welche gfx Karte, welches OS, welchen Treiber hast Du?

Gast

2007-02-15, 17:38:35

Es ist gar keine Lösung für mich - denn ich schaue HDTV Filme und die lassen sich schlecht mit ffdshow darstellen.

Ich habe eine Radeon X1950 Pro, Vista 64-bit, Catalyst 7.1

MfG

Gast

2007-02-15, 18:23:24

Ich brauche ne Lösung für DScaler!

Gast

2007-02-16, 00:03:48

Alle YUV Materialen unterliegen dieser limitierten Luminanzbandbreite. Das Problem ist das bei Overlay ein korrektes Bild erscheint und bei VMR9 nicht (Mißstand)Daher hab ich mich immer gewundert warum beim VLC (Overlay) das Bild immer so schön ist und beim ZoomPlayer (VMR) so grottig. Unterschiedliche Voreinstellungen.

DVD Player brauchen nichts korrigieren, weil auf dem TV '16' absolut schwarz ist (0 Volt) und '235' absolut weiß (max.Volt)So ist es. Auf dem DVD-Player siehst es ebenfalls ok aus.

Das ist gewollt, bzw. musste so (aus alten Zeiten) übernommen werdenSchade daß VMR9 diese Tatsachen nicht brücksichtigt. Wen wundert es aber.

Gast

2007-02-16, 00:06:10

Hast Du das Problem denn auch?Das gilt übrigens auch für XP. Treiberversion ist egal.

Gast

2007-02-16, 00:15:15

So ich habe eine Teil-Lösung gefunden:

-Für HDTV Zeugs: CoreAVC hat ein Kästchen, welches man ankreuzen kann dann wird das wieder verbessert
- Für normales Zeugs (divx usw.): FFDShow

Aber für MPEG-2 hab ich noch keine Lösung gefunden! Der decoder vom ffdshow ist müll (kein gescheites deinterlacing)

aths

2007-02-19, 12:05:21

Der Satz ist unter Berücksichtigung der Problematik unvollständig, da nicht hervorgeht aus welcher Betrachtung dieser Wert ermittelt wurde. Handelt es sich um einen RGB Wert im RGB Farbraum (z.B. Malen in Photoshop im RGB Farbraum auf PC Monitor), ist 16 in der Tat nicht Schwarz und die Aussage richtig. Handelt es sich aber um einen Y=0 Wert (TV Scale, absolut Schwarz), der im RGB Farbraum gemessen wird (z.B. DVD wiedergabe auf PC Monitor), sollte ebenfalls der dunkelste Helligkeitswert des RGB Farbraums (RGB 0,0,0) erscheinen. Wenn dann aber RGB 16,16,16 erscheint, wurden die YUV Helligkeitswerte fälschlicherweise 1:1 übernommen, da der dunkelste Y Wert (technisch) nicht als '0' gespeichert wird, sondern als '16', weil es der Standard so verlangt. Die Ausgabegeräte sind angewiesen den Wert 16 als Schwarz darzustellen (0 Volt). Nebenbei angemerkt sei, dass es auch einen Standard mit voller Y Helligkeitsbandbreite (Luminanz[Y] 0-255) gibt. Jener ist aber nicht für TV Material gedacht und wird auch nicht bei DVDs angewendet.

Schau dir das Testvideo an und stelle die Helligkeit hoch, sodass Du rechts unten die Balken gut erkennen kannst. Siehst Du dort drei Balken, ist das Bild falsch. Hebt sich nur ein Balken ab, ist das Bild richtig.
Zur Illustration habe ich den Effekt hier verstärkt dargestellt:
http://img165.imageshack.us/img165/1415/yuvty7.png

Zur Erklärung zitiere ich die Avisynth Dokumentation zum 'Colorbars' Befehl, womit das Testvideo erstellt wurde.

Dass sie bei +4 IRE (http://en.wikipedia.org/wiki/IRE_%28unit%29) 'should be less bright' geschrieben haben, muss ein Druckfehler sein. Richtig sollte es 'should be more bright' heißen. Der Wert ist unter jeder Betrachtung heller als -4 und 0 IRE. Der Wert -4 IRE ist nicht PAL konform und dient bei einem Testbild lediglich zu Kalibrierungszwecken. Das Testvideo ist somit streng genommen auch nicht korrekt, weil -4 IRE den gültigen Helligkeitsbereich des TVs unterschreitet.

Wenn man demnach einen Unterschied zwischen -4 und 0 sehen kann, wurde das Bild nicht ordnungsgemäß in den Zielfarbraum konvertiert, mit Gamma hat das aber nichts zu tun.Auf TV-Geräten gibts ja (leider) noch immer keine Gamma-Korrektur.

Wenn ich einen Film habe, der anamorph kodiert ist und ich den 4:3-TV im 16:9-Modus laufen lasse, habe ich ja „echt schwarze“ Balken (wo der Kathodenstrahl nicht langläuft) und „kodiert schwarze Balken“ (vor allem bei 2,53:1-Cinemascope-Material.) Regle ich Helligkeit und Kontrast so, dass die mitkodierten schwarzen Balken wirklich schwarz sind, sind im Bild die Schatten viel zu dunkel.

HeldImZelt

2007-02-19, 20:34:45

Das ist bei mir auch so. Das liegt aber individuell am Gerät. Trinitron Röhren haben z.B. ein sehr gutes Schwarz, während der Rest des Bildes noch in Ordnung ist. Man sagt den Schlitzmasken eh eine bessere Brillanz nach.

Gast

2007-02-19, 20:37:06

Alles schwer vom Thema ab.

HeldImZelt

2007-02-19, 21:00:23

Was mir noch aufgefallen ist, dass wmv (in Vista) nicht mit FFDShow funktioniert, vielleicht läuft wmv ja auch schon so mit voller Helligkeitsbandbreite. Keine Ahnung...

Ansonsten sind hier auch noch Leidensgenossen...
http://forum.doom9.org/showthread.php?t=120718

Unterm Strich gibt es aber (bis jetzt) keine Lösung. Peinlich nur, das Vista so ausgeliefert wird. Das müsste mal an die große Glocke gehangen werden.

jojo4u

2007-02-20, 02:26:47

Ok mal ein kurzer Überblick.

Problem tritt auf bei:
- VRM9 renderless & windowed
- VMR7 renderless (&windowed, in some cases)

Meistens sind ATI Karten betroffen, Nvidia ist aber auch mit dabei. Mein Intel GMA 950 unter WinXP ist wohl nicht betroffen.

Überprüfen kann man es indem man diese Datei (http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=30231&d=1171299085) herunterlädt, abspielt und die rechte untere Ecke mit diesem Bild (http://forum.doom9.org/showthread.php?p=954860#post954860) vergleicht.

Problem ist, dass im Videogeschäft der Schwarzwert bei 16 und der Weißwert bei 235 liegt. Das ist so üblich und wird von Fernsehgeräten korrekt dargestellt. PC-Monitore sind allerdings in der Lage Farbwerte, von 0-255 darzustellen. Genauere Besprechung hier (http://www.avsforum.com/avs-vb/printthread.php?t=523614). Die korrekte Umstellung ist normalerweise eine Sache der Grafikkartentreiber.

Lösungen:

Falls der Monitor nur zum Filmschauen benutzt wird: Helligkeit runter
Overlay benutzen - hat mehrere Nachteile (Qualität, Vsync, Screenshots, mehrere Monitore)
VMR7 windows benutzen - bietet keine bikubische Filterung, Vsync und ist u.U. langsamer, *mehr?*
Catalyst 7.1 unter Windows XP verwenden - soll hier gefixt sein
Bei Forceware 90+ gibt es einen Registry-Fix für DVI-Verbindungen (Seite 19 (http://download.nvidia.com/Windows/93.71/93.71_ForceWare_Release_Notes.pdf))
FFDShow Optionen -> output -> allein RG32 anhaken - braucht CPU-Leistung, sehr gute Qualität
FFDShow Optionen -> Avisynth -> ColourYUV(TV->PC) - erfordert installiertes Avisynth, bessere Qualität
FFDShow Optionen -> Levels -> input 16-235 - angeblich schlechte Qualität (8 bit)
Media Player Classic: per Shader (http://forum.doom9.org/showthread.php?p=889952#post889952) korrigieren - Qualität unbekannt

HeldImZelt

2007-02-20, 03:46:27

VMR9 scheint auch nicht mehr das Schlachtschiff von Microsoft zu sein. Ihr neues Spielzeug heißt EVR (Enhanced Video Renderer) (http://forum.doom9.org/showthread.php?t=117475) und soll ein DX10/Vista-only Renderer sein, der wohl auch 16-235 ausspuckt.

Ich meine mich dunkel erinnern zu können, daß der Programmierer vom Zoom Player mir mal gesagt hat, daß MS in der SDK vorgibt den VMR9 Renderer 16-235 zu speisen. Die Softwareseite macht demnach alles richtig. Dagegen ist ja auch nichts einzuwenden. Letztlich ist es die GPU, dessen Power dafür am effizientesten und sinnvollsten eingesetzt werden kann (so ist es ja wahrscheinlich auch bei Overlay). Demnach sollte die Korrekur am Ende des Renderpfades, bzw. in der Hardware (via Grafiktreiber) erledigt werden. Die Chancen, daß in nächster Zeit ein Treiber erscheinen wird, der das Problem lösen wird, stehen somit garnicht mal so schlecht.

Nichtsdestotrotz wäre es schon klasse wenn jemand unter XP bestätigen könnte, daß das Problem nicht mit dem Cat7.1 besteht, bzw. korrigiert wurde. Das wäre dann zum einen der Beweis dafür, daß ich das nicht geträumt habe und das Hoffnung besteht, daß sich das Problem in nächster Zeit durch einen ordentlichen Treiber erledigen wird.

Rumbah

2007-02-20, 18:51:50

Nichtsdestotrotz wäre es schon klasse wenn jemand unter XP bestätigen könnte, daß das Problem nicht mit dem Cat7.1 besteht, bzw. korrigiert wurde.

Das wäre ja echt mal was, wenn die das endlich beheben würden. Ich kann es nicht so richtig glauben, denn das Problem besteht ja nicht erst seit gestern (seit VMR9) und ist auch schon so lange bekannt. Aber die Mehrheit der Nutzer sieht es wahrscheinlich einfach nicht.

Darth Viorel

2007-02-20, 19:21:08

Bei meinem Standard Videoplayer KMPlayer kann man mehrere Sachen machen, um das Problem zu lösen:

-man kann die Ausgabe auf bestimmte Formate beschränken, z.B. RGB32 und YV12
-man kann die über die "Level Controls" die Ausgabe anpassen
-oder man kann extra für vmr9 die RGB32 Ausgabe erzwingen.

Mit dem Player kann man auch den neuen "Enhanced Video Renderer" benutzen, der aber die gleichen Farbverfälschungen aufweist... Dies kann man zwar auch "ausgleichen", aber ich habe keine Verbesserungen mit dem Renderer bemerkt. Die Leistung ist nicht besser und auch beim resizing merke ich keinen Unterschied.

Rumbah

2007-02-21, 13:21:30

So, ich habe gerade den Cat 7.1 installiert und kann sagen, dass laut Testvideo das Problem behoben ist. Ich kann es im VMR9 renderless Modus abspielen und sehen nur einen Balken.

HeldImZelt

2007-02-21, 18:05:15

Das ist doch mal'ne Aussage, darauf habe ich gewartet. Dann sieht die Zukunft ja doch brillant aus... Vielen Dank.

Gast

2007-02-21, 21:03:54

Unterm Strich gibt es aber (bis jetzt) keine Lösung. Peinlich nur, das Vista so ausgeliefert wirdNochmal: VMR zeigt hier unter XP die gleichen Effekte.

HeldImZelt

2007-02-22, 02:44:56

Nochmal: VMR zeigt hier unter XP die gleichen Effekte.
Sicher, daß Du eine Ati Karte mit Catalyst 7.1 hast?
Ich glaube Rumbah schon... da ich es, wie oben erwähnt, auch erlebt habe. Irgendwas muss dran sein.

Ich habe gerade den Cat7.2 in Vista getestet, hat sich nichts geändert.

Vielleicht sollte man mal an den Ati Support schreiben. Oder einen Sack Reis umwerfen. Hat wahrscheinlich die gleichen Auswirkungen...

Edit:
Falls jemand, z.B. aus Geschwindigkeitsgründen oder wegen der nicht funktionierenden WMVs unter Vista (mit RGB32), nicht RGB32, sondern YV12 oder YUY2 nutzen und mit FFDShow/Levels (16,235) korrigieren möchte, sollte dort auch auf 'Full range' stellen, sonst bringt das nichts. Wurde glaube ich noch nicht erwähnt.

http://img512.imageshack.us/img512/5629/levelsht4.png

JaDz

2007-03-25, 12:35:36

Vielleicht irre ich mich ja, aber mit dem ASUS-Treiber 8.351 (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=354973) scheint es bei mir behoben zu sein. Vista 32-Bit

JaDz

2007-03-26, 11:19:08

Vielleicht irre ich mich ja, aber mit dem ASUS-Treiber 8.351 (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=354973) scheint es bei mir behoben zu sein. Vista 32-Bit
Könnte das eventuell jemand bestätigen?;(

HeldImZelt

2007-07-22, 04:23:27

EVR lief eine Zeit lang perfekt, jetzt nicht mehr. Ich habe mit dem Catalyst 7.7 zufällig bemerkt, daß jetzt auch dort der Farbraum nicht mehr korrigiert wird. Somit sind scheinbar alle Renderer (VMR7, VMR9, EVR) in Vista betroffen, abgesehen vom Overlay Mixer. Den kann man aber zwecks Kompatibilitätsmodus wohl kaum als brauchbar in Vista bezeichnen. Daraufhin habe ich erstmal ein Ticket bei Ati gezogen und denen einen halben Roman geschrieben.

In der Zwischenzeit sind aber auch recht brauchbare Workarounds erschienen. So gibt es beispielsweise beim KMPlayer Pixelshader, die den Farbraum in der Hardware umwandeln. So wälzt man die Leistung wenigstens nicht auf die CPU ab, um das Problem zu umgehen. Der MPC müsste das auch können.

In Anbetracht der derzeitigen Situation läuft Vista mit dessen hauseigenen Playern verdammt mies. Die Videoqualität wirft derzeit kein gutes Licht auf das Multimediaschlachtschiff Vista. Ich verstehe nicht warum MS da nicht Druck auf die Grafikkartenhersteller macht. Die Frage, wem man den schwarzen Peter zustecken darf, dürfte doch geklärt sein.

Darth Viorel

2007-07-22, 13:05:07

EVR lief eine Zeit lang perfekt, jetzt nicht mehr. Ich habe mit dem Catalyst 7.7 zufällig bemerkt, daß jetzt auch dort der Farbraum nicht mehr korrigiert wird.

Das ist mir auch aufgefallen. Da ich recht viele Filme am PC schaue, habe ich den 7.7er wieder deinstalliert und den 7.6er draufgemacht. Komischerweise hat das aber nichts gebracht, die Farben wurden trotzdem noch falsch dargestellt...
Ich benutze jetzt einfach den Haali Renderer und kümmere mich nicht weiter um den Treiber. Mit dem hat es bislang immer funktioniert.

Rumbah

2007-07-22, 13:13:42

In den Vista Treibern gibt es seit einiger Zeit eine Option, um das umzustellen. Man darf die Farben nicht auf Office stellen oder so. Mangels Vista kann ich das allerdings nicht nachgucken.

Darth Viorel

2007-07-22, 15:00:01

In den Vista Treibern gibt es seit einiger Zeit eine Option, um das umzustellen. Man darf die Farben nicht auf Office stellen oder so. Mangels Vista kann ich das allerdings nicht nachgucken.

Wenn damit diese Einstellung gemeint sein soll, die bringt bei mir nichts. Wenn ich es auf PC Standard Levels stelle, dann ist das Bild ziemlich kontrastarm, bei den voreingestellten MCE schwarz und weiß Werten stimmen die Farben auch nicht.

Matrix316

2007-07-22, 15:10:45

Vielleicht im CCC beim AVIVO den Gamma Wert runterstellen? Bei mir ist er auf 1,1 gewesen und DVD Videos waren etwas zu hell, vor allem schwarz war grau.

Gast

2007-07-22, 15:32:13

Somit sind scheinbar alle Renderer (VMR7, VMR9, EVR) in Vista betroffen, abgesehen vom Overlay MixerIch erinner' dich nochmal dran, daß das unter XP nicht anders ist. Overlay, sonst nichts :frown:

Rumbah

2007-07-22, 15:38:51

Seit einigen Catalyst Versionen (7.1 oder 7.2) funktioniert unter Windows XP auch die Farbdarstellung mit VMR. Warum das unter Vista immer noch nicht geht, ist mir allerdings ein Rätsel. Naja, bei XP hat es ja auch Jahre gedauert, bis es endlich behoben wurde :) .

JaDz

2007-08-15, 11:21:52

7.8: keine Besserung in Sicht.:(

HeldImZelt

2007-08-15, 19:21:32

Die Vermutung liegt nicht fern, daß das in Vista sogar gewollt ist. Eine DXVA(?) fähige Karte/Software kann mit Pixelshadern den Farbraum in der GPU selbst korrigieren, was weit besser erscheint als über den Treiber (mehr/direkte Kontrolle). Aber warum macht der WMP das dann nicht so? Der läuft von Haus aus mit diesem "Fehler", mit der Ausnahme, daß man dort keine Pixelshader nutzen kann.

In XP gibt es zu viele kleine Karten, als das man es dort zum Standard forcieren könnte, so daß man weiterhin direkt im Treiber korrigiert.

Nur ein Gedanke...