Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Der EVR ohne Custom ist aber in der Krawatte genauso scharf wie madVR. Sogar etwas schärfer.

Farbverfälschungen, ich sehe nur das die madVR-Farben knackiger sind, man weiß aber nicht wie es im Studio war.

 

In meinen Screenshots war madVR schon ertwas farbiger als DVBV's EVR aber nicht so stark wie bei dir.

Kann man das mit Änderungen im Chroma-Up erreichen? Das war bei mir bis jetzt immer auf default.

 

p.s. die Farbe bzw. Kontrast könnte man für EVR aber auch geringfügig in den Video-einstellungen des Treibers kalibrieren oder anpassen.

Edited by craig_s
Link to comment

..aach jetzt fällts mir ein, du hast bestimmt im CCC auch den "Dynamischen Kontrast" deaktiviert, tja aber der ist ein elementarer Bestandteil des AMD-Treibers. Ohne den wird das Bild total lustlos und flau.

madshi hat viel weiter oben mal gesagt das "madVR sämtliche GPU-Video-Algorithmen umgeht", der merkt also gar nicht ob "Dynamischer Kontrast" on oder off.

 

Damit sieht die Situation so aus:

dem AMD Treiber darf man alle Algos gnadenlos wegnehmen ohne sich nochmal rumzudrehen ist ja sowieso alles scheize, (das Bild ist danach auch richtig mies, Erwartung ist bestätigt, äh..),

und madVR darf fröhlich seine Algos dazumengen denn die sind heilig :innocent: (Bild dann wieder bunt, Erwartung ist bestätigt, alles in Butter)...

 

Sorry Leute aber soo einfach darf man sichs nicht machen!

Edited by craig_s
Link to comment

Nein Dynamischer Kontrast war an aber der steht bei mir auf (16-235). Das kann ich mal mit (0-255) testen.

Chroma Upsampling nutze ich in MadVR bisher nicht.

Ich liefere dann heute abend noch Lancosz 4taps+AR, Spline 4Taps+AR und Jinc 3Taps+AR nach sowie aus dem tsplayer C_EVR,

Die habe ich gestern dann auch noch gemacht. Jinc ist schon gut aber viel zu "teuer" und hat zur Folge dass Bild und Ton nicht mehr Synchron sind, zumindest mit meiner Hardware.

Link to comment

..aach jetzt fällts mir ein, du hast bestimmt im CCC auch den "Dynamischen Kontrast" deaktiviert, tja aber der ist ein elementarer Bestandteil des AMD-Treibers. Ohne den wird das Bild total lustlos und flau.

madshi hat viel weiter oben mal gesagt das "madVR sämtliche GPU-Video-Algorithmen umgeht", der merkt also gar nicht ob "Dynamischer Kontrast" on oder off.

 

Damit sieht die Situation so aus:

dem AMD Treiber darf man alle Algos gnadenlos wegnehmen ohne sich nochmal rumzudrehen ist ja sowieso alles scheize, (das Bild ist danach auch richtig mies, Erwartung ist bestätigt, äh..),

und madVR darf fröhlich seine Algos dazumengen denn die sind heilig :innocent: (Bild dann wieder bunt, Erwartung ist bestätigt, alles in Butter)...

 

Sorry Leute aber soo einfach darf man sichs nicht machen!

 

Du schmeißt da ein paar Dinge zusammen, die man getrennt betrachten muß:

 

Sachen wie Noise Reduction oder Sharpening gehören meiner Meinung nach per Default aus - es sei denn, es ist "bewiesen", daß diese Einstellungen das Bild objektiv immer nur verbessern und praktisch nie verschlechtern. Bei Noise Reduction ist sowas kaum denkbar, Noise Reduction ißt in der Regel immer auch ein paar Details mit weg. Sharpening produziert oft Ringing-Artefakte, und selbst wenn es das nicht tut, verleiht es dem Bild oft einen nachgeschärften etwas künstlichen Look. Deshalb gehören meiner Meinung nach all diese Verschlimmbesserungen per Default aus, zumal die AMD/NVidia/Intel-Algos in der Regel nicht so ausgefeilt sind.

 

Genauso gehören diese Algos auch in madVR per Default aus!!! Keiner verlangt hier eine Sonderbehandlung für madVR.

 

Per Default macht madVR absolut *gar nichts* mit dem Bild, außer es mathematisch so perfekt wie möglich darzustellen. Ein paar Berechnungen lassen sich nicht vermeiden, weil das Bild nunmal in YCbCr 4:2:0 encodiert ist und ein HTPC am besten in der RGB-Ausgabe ist. Also die YCbCr -> RGB Konvertierung muß gemacht werden. Aber da macht madVR nichts wildes, sondern rechnet einfach nur mathematisch korrekt um, in möglichst hoher Bittiefe. Unterschiede in der Bilddarstellung kommen von anderen Scaling-Algos, besserer Bittiefe und abschließendem Dithering bei madVR, was viele andere Renderer so nicht machen.

 

Scaling an sich zählt nicht als Verschlimmbesserung, weil es keinen eindeutig mathematisch korrekten Algo für Scaling gibt. Jeder Scaling-Algo muß halt neue Pixel "erfinden", und die verschiedenen Algos machen das verschieden gut, jeder mit seinen eigenen Vor- und Nachteilen. Wobei es natürlich auch eindeutig "schlechte" Scaler gibt (wie z.B. Nearest Neighbor oder Bilinear).

 

Die Farben bei EVR sind in den oben gelinkten Screenshots wahrscheinlich deshalb blasser, weil da die Ausgabe-Levels (0-255 vs 16-235) wahrscheinlich nicht stimmen. Genauso kann es auch mal bei EVR knackig aussehen und bei madVR blass, wenn halt EVR die richtigen Levels ausgibt und madVR falsch konfiguriert ist.

 

Ich weiß nicht genau, was der "dynamische Kontrast" im AMD-Control-Panel macht. Wenn das einfach die Ausgabe-Levels bei EVR setzt, sollte es entsprechend richtig eingestellt werden. Wenn es aber tatsächlich *dynamisch* den Kontrast ändert, zählt das eindeutig als Verschlimmbesserung und sollte deaktiviert werden. Sowas wie dynamisch den Kontrast ändern macht madVR z.B. gar nicht.

 

Die Deinterlacing-Algos/-Features im AMD-Control-Panel sollten hingegen alle (als einziges) aktiviert werden, inklusive Pulldown-Erkennung usw. Dies sind keine Verschlimmbesserungen, sondern einfach die Aktivierung der verschiedenen Deinterlacing-Features, die mathematisch/wissenschaftlich die besten Ergebnisse bringen.

 

Also Summary: Im AMD-Control-Panel per Default alles aus, außer den Deinterlacing-Einstellungen, die alle an. Natürlich sollten aber die Ausgabe-Levels für EVR korrekt gesetzt werden. Bei schlechten Quellen darf Noise Reduction usw gerne gezielt dazu geschaltet werden. Aber per Default gehört das meiner Meinung nach definitiv aus. Genauso macht das auch madVR.

  • Like 1
Link to comment

Ich meinte den hier in Video, der hat nur einen Haken. Nichts mit 16-235.

 

Und ich meinte:

Erweiterte Videofarbe -> Dynamischer Bereich mit -> Voll (0 -255) oder beschränkt (16-235).

Den stelle ich mal um und teste nochmal

Link to comment

@ madshi

Also erstmal sind mir deine Aussagen viel zu absolut, um so mehr als das sie vom "Algo-Großmeister" persönlich kommen.
Das muß abgeschaltet werden das nicht - und alle rennen blind hinterher, was glaubst du eigentlich wie viele Leute wirklich hinschauen? Die warten doch nur auf Gurus Weisungen, das wird eingestellt und jetzt ist alles richtig. Und ganz schnell fertig, juhuu! Wie kannst du diese Verantwortung nur auf Dauer ertragen? ;)

 

Was dabei rauskommt zeigen Tüftlers Screenshots - graue Maus die madVR zum Leben erweckt.. Da kommt mir grad der Gedanke ob du diese Anweisungen nicht etwa doch so'n gaanz keines bisschen gibst weil dann madVR hinterher immer besser aussieht..? Ausserdem sieht man mal wie nützlich doch Screenshots sind denen du immer so misstraust. Warum..? ;)

Ich weiß nicht genau, was der "dynamische Kontrast" im AMD-Control-Panel macht.

Sag mal auf was arbeitest du eigentlich? Bei Intel vermutest du immer, AMD kennst du nicht, nach Nvidia fragst auch dauernd..?

Wie gesagt "dynamischer Kontrast aus" macht "graue Maus" (reimt sich). Das Bild ist einiges ärmer an Chroma + kontrastärmer als Intel und Nvidia. Im Inteltreiber gab es den Menüpunkt auch mal, den haben sie inzwischen rausgenommen. Er wirkte dort aber nicht ganz so radikal wie bei AMD. Das empfielst du den Leuten obwohl du's noch nichtmal kennst? Sehr verehrte Damen und Herren, liebe HTPC'ler...

Genauso gehören diese Algos auch in madVR per Default aus!!! Keiner verlangt hier eine Sonderbehandlung für madVR.

Ich auch nicht wie du oben lesen konntest. Das madVR alles im Alleingang macht hatte ich schon verstanden.

Viel weiter oben schreibst du das die Leute doch alle auf was anderes achten, jeder was anderes sieht. Wenn du dir das nochmal zu Herzen nimmst solltest du militärische Befehlsausgaben wie oben vermeiden. Zumal es sich um Sachen handelt die du offenbar keines Blickes würdigtest also gar nicht wirklich kennst? Solltest du aber und nicht nur mit den Scheuklappen "kann man vergessen, madVR macht sowieso alles besser".

 

Und mach mal paar Screenshots damit wir verstehen können was du so siehst. Sind alle ganz neugirig drauf!

Edited by craig_s
Link to comment

Und ich meinte:

Erweiterte Videofarbe -> Dynamischer Bereich mit -> Voll (0 -255) oder beschränkt (16-235).

Den stelle ich mal um und teste nochmal

 

..und teste doch auch nochmal den "dynamischen Kontrast" an/aus den ich meine.

 

Und dann mal "Alles auf Default" in der AMD. Da müsste dann ja die Tastatur schmelzen so grauenhaft siehts aus..:)

Edited by craig_s
Link to comment

Wie gesagt "dynamischer Kontrast aus" macht "graue Maus" (reimt sich). Das Bild ist einiges ärmer an Chroma + kontrastärmer als Intel und Nvidia.

Was passiert denn deiner Meinung nach durch diese Einstellung?

 

edit\ Habs mal schnell ausprobiert. Mit 16-235 vs 0-255 hat die Einstellung nichts zu tun.

Also ein reiner "verschlimmbesserer Algo". Kann gefallen oder auch nicht.

Wenn eure Farben ohne diesen Modus nicht passen stimmt etwas anderes nicht.

 

So oder so bringt uns die Diskussion nicht weiter.

Mit craig_s ist das eh sinnlos ... am besten du hälst dich aus dem madVR Thread raus und belehrst uns in einem anderen Thread über die deiner Meinung nach richtigen AMD Einstellungen mit dem EVR.

 

Interesse halber würde mich interessieren: madVR kann die Algo's (Denoise Sharpen, dyn. Kontrast usw.) normal umgehen?

Der dyn. Kontrast ist bei mir auch mit madVR aktiv.

Edited by nuts
Link to comment

@craig_s

 

eigentlich soll doch nur ein neuer Renderer im DVBViewer eingefügt werden nicht mehr und nicht weniger.Weiß nicht warum man unbedingt beweißen will das ausgerechnet dieser Renderer niemanden etwas bringt ausser einem erhöhten Energieverbrauch.

Wenn er dir nicht gefällt warum auch immer benutze den EVR oder Custom und gut ist.

Link to comment

Also erstmal sind mir deine Aussagen viel zu absolut, um so mehr als das sie vom "Algo-Großmeister" persönlich kommen.

Das muß abgeschaltet werden das nicht - und alle rennen blind hinterher, was glaubst du eigentlich wie viele Leute wirklich hinschauen? Die warten doch nur auf Gurus Weisungen, das wird eingestellt und jetzt ist alles richtig. Und ganz schnell fertig, juhuu! Wie kannst du diese Verantwortung nur auf Dauer ertragen? ;)

 

Ich habe wiederholt (mindestens 3x in meinem letzen Post) explizit "meiner Meinung nach" dazu geschrieben. Ich darf doch wohl eine Meinung haben, und die auch äußern, oder etwa nicht??

 

 

Wie gesagt "dynamischer Kontrast aus" macht "graue Maus" (reimt sich). Das Bild ist einiges ärmer an Chroma + kontrastärmer als Intel und Nvidia.

 

Wie schon gesagt, wenn der "dynamische Kontrast" lediglich zum Einstellen der korrekten Output-Levels dient, dann sollte das korrekt gesetzt werden und ist dann keine Verschlimmbesserung. Der Name der Option läßt allerdings vermuten, daß dort der Kontrast der Video-Frames anhand des Histogramms analyisiert und laufend während des Playbacks angepaßt wird. Das fällt dann meiner Meinung nach unter Verschlimmbesserung. Wenn Du dort dann z.B. eine Szene hast (wie z.B. in manchen Silent Hill Szenen, wenn ich mich recht erinnere), wo alles neblig ist mit grau in grau Tönen ohne echte schwarze und weiße Töne, dann würde so ein Algo die Pixelwerte spreizen, um mehr Kontrast zu erzeugen, und würde damit dem eigentlichen Wunsch des Filmemachers (tristes kontrastarmes grau) entgegen arbeiten. So ein Algo ist meiner Meinung nach eine Verschlimmbesserung und sollte ausgeschaltet werden. Es sollte trotzdem irgendwie möglich sein, die Output-Levels korrekt einzustellen, und dann sollte das Bild nicht mehr wie graue Maus aussehen. Wie das bei EVR/AMD geht, weiß ich aber nicht. Irgendwie sollte es aber möglich sein. Bei madVR gibt's dazu die Output-Levels-Option.

 

 

Was dabei rauskommt zeigen Tüftlers Screenshots - graue Maus die madVR zum Leben erweckt.. Da kommt mir grad der Gedanke ob du diese Anweisungen nicht etwa doch so'n gaanz keines bisschen gibst weil dann madVR hinterher immer besser aussieht..? Ausserdem sieht man mal wie nützlich doch Screenshots sind denen du immer so misstraust. Warum..? ;)

 

Ich habe in meinem letzten Post bereits erklärt, daß die EVR-Screenshots deshalb so schlecht aussehen, weil da wahrscheinlich die Ausgabe-Levels falsch konfiguriert sind, und daß das korrigiert werden sollte. Es ist schon bezeichnend, daß Du (wahrscheinlich, soweit ich das verstehe) die Aktivierung eines Verschlimmbesserungs-Algos empfiehlst als Heilmittel für eine falsch konfigurierte Levels-Ausgabe. Da kann man erahnen, wieviel Ahnung Du hast (oder eben nicht)...

 

Außerdem weiß ich nicht, wie Du auf die Idee kommst, ich würde Screenshots mißtrauen. Ich halte Screenshots sogar für sehr aussagekräftig, auch wenn nicht alles in Screenshots sichtbar ist (manche Artefakte, wie z.B. Ruckeln, sieht man nur in Bewegung). Ich verwende Screenshots selbst gerne, z.B. um Unterschiede zwischen verschiedenen Scaling-Algos zu zeigen. Und das habe ich auch in diesem Thread vor einiger Zeit bereits getan! Deine Posts werden irgendwie immer schräger. Voll mit falschen Aussagen (wie daß ich Screenshots mißtrauen würde) und unwahren Unterstellungen (daß ich bewußt Einstellungen empfehle, die madVR im Vergleich besser aussehen lassen).

 

Zu Deiner Info: Ich habe in meinem Development-PC sowohl NVidia, Intel als auch AMD GPUs drin, so daß ich im Zweifelsfall alles testen kann. Deshalb bin ich trotzdem kein Experte darüber, wie EVR funktioniert, weil mich persönlich EVR nicht interessiert. Meine Meinung in Sachen Verschlimmbesserungs-Algos hängt im übrigen nur bedingt von der Qualität der Algos ab. Auch wenn ein Noise-Reduction-Algo allerbeste Qualität hat, würde ich den trotzdem immer per Default ausschalten. Wenn Du den Grund dafür nicht verstehst, dann solltest Du das vielleicht als Hinweis dafür sehen, daß Dir noch ein bißchen Background-Wissen fehlt...

 

So, jetzt hab ich erstmal genug. Gibt's hier im Forum eigentlich eine "Ignore"-Funktion?

Link to comment

Wenn ich "verrückt" oder unkonventionell an alles mögliche drangehe ist das größtenteils Absicht. So bin ich schon bei einigen komplexen Verhältnissen dem Grund näher gekommen als andere die ewig im Trüben fischten.

 

Und das Setup bei Video ist ausserordentlich komplex vom kalibrierten? Monitor übers geschulte? Auge, Hardware, Software, Treiber zu an die 500 Häkchen die ge/entsetzt werden können.

Und keiner kann life sehen was der andere sieht...

Ich finde allein diese Ausgangssituation wahnsinnig. Krasse Fehleinschätzungen sind vorprogrammiert. Auch der "Weiseste" müsste sich täglich selbst von Grund auf hinterfragen.

 

Macht aber kaum einer weil es ganz menschlich ist das man gerade sein eigenes Ding für das richtige hält.

Was bleibt sind Hoffnungen, Vorstellungen, Schwärmereien, Sprache die ein Bild beschreibt...

Da möge man mir verzeihen wenn ich manchmal spontan am "Baum schüttel" und nerve und auf den Putz hau. Ich brauchs einfach etwas konkreter und meistens kommen interessante Sachen zum Vorschein :) oft Sachen die weiterbringen.

 

Was mich persönlich manchmal etwas stört, ist daß die ganze Diskussion um madVR gerne reduziert wird auf die Frage, ob es auf die schnelle in Screenshots oder im Live-Betrieb einen deutlich sichtbaren Bildqualitätsgewinn gibt oder nicht. Es ist ja nicht so, daß Microsoft und die GPU-Hersteller komplett ahnungslos sind. Wenn die ihre Arbeit richtig machen, dann ist es zu erwarten, daß es eben keinen deutlichen Unterschied in der Bildqualität gibt. ...

 

Edited by craig_s
Link to comment

Zum Timing...

 

Queue-Größen von 32/16 scheinen die Situation nicht wirklich zu verbessern. Was ich beobachte ist, dass sich vor allem die Dekoder-Queue ab und zu recht stark entleert. Da die Update-Rate der Statistik natürlich nicht so hoch ist, kann es evtl. sein, dass sich Queues sogar gänzlich entleeren. Ich sehe, dass Drop und Repeat gleichzeit hochzählen. Ich gehe jetzt aber davon aus, dass evtl. auf Grund eines Underruns Bilder erst wiederholt werden (repeated), und dann, wenn wieder neue eingetroffen sind, verworfen (dropped) werden müssen, um zu synchronisieren.

Ab und zu zählt auch der "dropped frames" Zähler doppelt im Gegensatz zum "repeated frames" Zähler (z.B. 2 "dropped frames" und 1 "repeated frames" oder gar 4/2).

 

Nochmal zum Test:

1080i auf 1080p

Windows 7 (DWM)

Intel Core i3-3225 / HD4000 Grafik (aktueller Treiber)

Geänderte Einstellungen: Bicubic 75 Chroma Upsampler (kein AR), kein FSE (mit FSE sieht es aber auch nicht anders aus), 10bit chroma/image

 

Die GPU läuft damit nicht auf Anschlag... 70% @ 1000 MHz

 

Ab und zu zählt auch nur der "presentation glitches" Zähler hoch und Drop/Repeat gar nicht. Keine Ahnung, wann es zu welchem Szenario kommt.

 

 

Weitere Ideen:

 

In meinem Graph gibt es keine Synchronisation zwischen Stream- (basierend auf PCR) und Ausgabegeschwindigkeit (Audio Clock). Ist die Wiedergabe schneller als der Stream, könnte es theoretisch zu Unterläufen kommen. Evtl. würde es helfen, die Latenz vom DVBSource höher zu setzen, was die Timestamps weiter in die Zukunft verschiebt und so die Puffer im Graph voller werden lässt.

 

Evtl. sollte ich auch mal "copyback" deaktivieren. Das entlastet mir zwar die GPU, aber die Kopiererei könnte evtl. auch zu Unterläufen führen.

 

 

Weitere Ideen und Gedanken sind herzlich willkommen...

Link to comment

Also wenn die Decoder-Queue sich stark entleert, ist das sehr wahrscheinlich die Ursache allen Übels. Die große Frage ist, *warum* Deine Decoder-Queue manchmal (fast?) leer wird. Das liegt normalerweise außerhalb der Kontrolle (und somit auch außerhalb der Verantwortung) von madVR. Natürlich kann's aber auch ein Bug in madVR sein, der das irgendwie auslöst. Etwas nachdenklich macht mich, daß Du "nur" einen Frame-Drop/-Repeat hast, und nicht ganz viele. Scheinbar füllt sich die Queue dann doch wieder gerade rechtzeitig? Normalerweise, wenn die Decoder-Queue in Schwierigkeiten kommt, ruckelt es dann für eine Weile.

 

Versuch es doch mal testhalber ohne "copyback" in LAV, oder sogar mit reinem Software-Decoding, und sei es nur als Test. Versuch bitte auch mal die beiden Optionen "don't use copyback" in den madVR "trade quality for performance" Einstellungen. Das könnte auch eine Auswirkung haben.

Link to comment

Ich nutze bereits dxva2n standardmäßig in LAV, d.h. kein "copyback". Was ist nun aber, wenn in madVR don't use "copyback" for DXVA decoding nicht gesetzt ist, da also "copyback" verwendet wird? Der Dekoder macht dann trotzdem kein "copyback", oder? Was bewirkt die Option in madVR?

 

Ich werde weiter testen und deine Anmerkungen natürlich mit einbeziehen.

Link to comment

Die Funktion bewirkt das hier (madVR intern)

Bei aktiviertem "copyback" wird das DXVA-Videoframe von der CPU so konvertiert, daß madVR das per PixelShader weiter bearbeiten kann. Bei "don't use copyback" wird die Konvertierung von der GPU gemacht. Das heißt, bei "copyback" hat die GPU etwas weniger zu tun, dafür müssen aber alle Frames zweimal über den PCI-Express-Bus kopiert werden. Hat alles Vor- und Nachteile...

Aktiviertes dxva "copyback" im (LAV)Decoder ist für madVR wie der Software Decoder.

 

edit\ Hintergrund dürfte hier erklärt sein:

DXVA in allen Varianten sollte von madVR unterstützt werden. Hat aber alles gewisse "Eigenheiten". So ist es z.B. bei "native" so, daß madVR etwas Verrenkungen machen muß, um das in guter Qualität weiterzuverarbeiten. Leider hat Microsoft es unmöglich gemacht, DXVA-Interfaces direkt mit Direct3D-Pixel-Shadern anzusprechen <würg>. Es sollte grundsätzlich aber trotzdem funktionieren. Je nach GPU-Typ und Konfiguration gibt's aber einen minimalen Chroma-Qualitäts-Verlust, oder einen kleinen Performance-Drop.

Ausprobieren könntest du auch mal Quicksync im LAV. Das soll ja sehr schnell sein, auch beim zurückkopieren.

Edited by nuts
Link to comment

Also wenn Du DXVA-Native benutzt, dann sollten die "copyback"-Optionen in madVR keine große Auswirkung auf die Decoder-Queue haben, denke ich mal. Einen Test ist es trotzdem wert. Bliebe nur noch Software-Decoder als Gegentest, um zu checken, ob da die Decoder-Queue auch irgendwann leer wird oder nicht...

Link to comment

Nur erstmal kurz zur Farbsache, die Einstellung 0-255 macht die Farben sauber. Bilder gibt es erst später da der HTPC derzeit mein einzigstes Testgerät und gerade in Benutzung ist.

 

@craig_s

Bitte unterlasse die andauernden Weisheiten-Einwürfe über MadVR und bleibe sachlich.

Für mich ist es wichtig zu Wissen wie der MadVR Renderer eingestellt werden soll um es im DVBViewer-Umfeld zu Testen. Das ich dabei natürlich auch die Fähigkeiten bestmöglich nutzen möchte sollte Klar sein.

Am Ende soll schon möglichst eine Empfehlung für die User stehen und deshalb teste ich auch deine Empfehlungen. Den heiligen Grahl hast aber auch du nicht gefunden denn nur weil Haken per Default aktiv sind macht es nicht immer Sinn es so zu lassen!

Link to comment
die Einstellung 0-255 macht die Farben sauber

 

Und wie sieht es mit der Einstellung in dunklen Szenen aus.

Normalerweise "versumpfen" dann die Detail's

Zumindest war's bei mir immer so.

Link to comment

Naja lasst euch nicht verwirren ...

Wenn möglich lasst ihr diese Einstellung einfach aus.

Ist weder für den EVR noch für madVR nötig, wenn euer Endgerät auf 0-255 einzustellen ist.

Link to comment

Im Anhang neue Screenshots und auch das Video zum selber Testen.

Meine Erkenntnisse/Einstellungen im CCC:

  • PixelFormat = PC Standard-Pixelformat RGB 4:4:4 (volles RGB) -> noch nicht untersucht
  • Farbtiefe = 10bpc -> noch nicht untersucht
  • GPU Aufskalierung aktivieren -> macht keinen Unterschied
  • ITC-Verarbeitung aktivieren ?? -> noch nicht untersucht
  • Erweiterte Videofarbe = Dynamischer Bereich mit -> Voll (0 -255) -> unbedingt aktivieren
  • Pull-Down Erkennung -> noch nicht untersucht
  • Glatte Videowiedergabe erzwingen (ganz böser Schalter bei grenzwertigen GPUs) -> noch nicht untersucht
  • AMD Steady Video -> mach das mal an und schau dir N24 mit Laufschrift an, ein Spaß sag ich dir! -> unbedingt deaktivieren!
  • Dynamischer Kontrast -> meiner Meinung nach deaktivieren, wirkt Global (also auch auf MadVR!)

>Bilder<

 

>Video<

Link to comment
  • Erweiterte Videofarbe = Dynamischer Bereich mit -> Voll (0 -255) -> unbedingt aktivieren
Was dir da "gefällt" sieht mir nach einer starken Übersättigung aus (16-235 vs 0-255 Problem).

Schalte die Option "Dynamischer Bereich" mit madVR mal bei laufender Wiedergabe zu und ab und verwende ein Testbild mit Grautreppe.

Hier gibts was gutes: http://www.avsforum.com/forum/139-display-calibration/948496-avs-hd-709-blu-ray-mp4-calibration.html

 

Wie man sieht gerät madVR durch die Einstellung erstmal aus dem Tritt und fängt sich z.B. durch "Wiedergabe neu aufbauen" oder ein Wechsel zwsichen Fenster und Vollbild Modus wieder.

Edited by nuts
  • Like 1
Link to comment

Es ist auf jeden Fall sinnvoll, die Grundeinstellungen mithilfe von Testvideos vorzunehmen, sowohl bei madVR als auch EVR. Wichtig ist z.B. erstmal, daß bei einem Grayscale-Ramp alle Graustufen von 16-235 sichtbar und unterscheidbar sind, und alle Graustufen von 0-15 und 236-255 nicht sichtbar sind (obwohl, beim WTW-Bereich (236-255) gibt's auch andere Ansichten). Nur so ist sichergestellt, daß das Bild auf der einen Seite schön knackig ist, und auf der anderen Seite keine Details verloren gehen, weder in dunklen noch in hellen Bildbereichen.

Link to comment

Auf jeden Fall.

Dazu könnte kommen, dass man jahrelang "falsch" geguckt und im TV/Monitor mit dem Helligkeitsregler zu kompensieren versucht hat.

 

0-255 Ausgabe einstellen (RGB 4:4: Full), TV/Monitor auf 0-255 Signale einstellen (bei PC-Monitoren unnötig, bei TV fast immer nötig) und Standard-Einstellungen wählen.

Schon damit sieht man mit einem Graustufentestbild (s. Link) deutlich ob ein 16-235 vs 0-255 Problem vorliegt.

Und wenn man das im Griff hat kann man mit dem Helligkeitsregler im TV das Feintuning vornehmen.

 

Erweiterte Videofarbe = Dynamischer Bereich mit -> Voll (0 -255)

Sollte man dann nicht brauchen ...

Edited by nuts
Link to comment

Und dann auch keine Frame Drops/Repeats?

 

Bleibt die Frage, warum bei DXVA die Decoder-Queue manchmal stockt. Hab ich ehrlich gesagt keine Erklärung für, wenn die normalerweise gut funktioniert. Hab jetzt dieses spezielle Problem auch in der letzten Zeit nicht von anderen Usern berichtet bekommen.

Link to comment

Keine Repeat/Drops bis jetzt.

 

Ich bezweifle, dass so viele 1080i durch madVR jagen!? Es macht halt doch einen Unterschied, ob man 1080p24 oder dieselbe Auflösung bei 50Hz mit vorigem Deinterlacing durch jagt...

 

Die Repeat/Drops sind wie gesagt nicht so oft (ca. jede halbe Stunde) und wenn nicht gerade viel Bewegung im Bild ist, bekommt man sie auch nicht mit.

 

Ich werde jedenfalls noch weiter rumspielen und schauen, was evtl. Einfluss darauf hat...

Link to comment

Wäre noch die Frage nach Quicksync.

Nehme an dafür werden bei Intel die gleichen Co-Prozessoren über einen anderen Zugang verwenden.

Vielleicht lässt sich so das Problem etwas näher einkreisen.

 

madVR wird auch wohl zum ersten Mal intensiv mit LiveTV gequält. Da können sich schon mal neue Beobachtungen ergeben. :)

Link to comment

Ja, wobei der Intel-Decoder aber eigentlich recht schnell sein soll. Von daher wundert mich das etwas. Vielleicht gibt's da irgendwo einen Deadlock, entweder irgend im Intel-Treiber oder in madVR, keine Ahnung...

Link to comment

Neue Erkenntnis...

 

Ich habe die Latenz für Material mit H.264 Video im DVBSource jetzt von 300ms auf 600ms gestellt. D.h. die Ausgabe wird weitere 300ms weiter in die Zukunft geschedult. Damit ist die Dekoder-Queue nun konstant voll (ebenfalls 30-32/32). Muss ich jetzt noch in Bezug auf Repeat/Drops überprüfen...

 

Das verlängert natürlich die Kanalumschaltung etwas. Die Frage ist, wieso SW das nicht benötigt und warum EVR mit DXVA2 bei 300ms kein Problem zeigt.

Link to comment

Verstehe auch nicht, wieso das nur in der Kombi madVR+DXVA2 auftritt, und wieso die Latenz da eine Rolle spielt. Was spielt die Latenz da überhaupt für eine Rolle? Warum ist die nicht auf 0ms?

Link to comment

Die Repeat/Drops sind auf jeden Fall nach Erhöhung der DVBSource Latenz erstmal weg.

 

 

Was ich allerdings immer noch beobachte sind "presentation glitches". Worauf basiert diese Anzeige? Der Auswertung der D3D/DWM Present-Stats? Meist inkrementiert dieser Counter um 2 innerhalb weniger Sekunden. Gestern habe ich das ca. alle 10 Minuten mit 1080i im Windowed Fullscreen beobachtet. Könnte das eines der von dir angesprochenen DWM-Probleme sein? Ich werde heute mal FSE probieren.

Der "presentation glitches" Zähler inkrementiert auch gerne, wenn ich künstlich die Systemlast anhebe. Drops oder Repeats werden jedoch keine registriert.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...