Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Korrektur,

offenbar interagiert etwas zw. DVBV 5.5/5.5.0.1 und LAV 0.65.0.26/35 weil 'Private Bytes' und 'Virtual Size' mit EVR-C@2160p sehr unterschiedlich ausfallen.

 

Damit ist 'Process Explorer' rehabilitiert und dessen Ergebnisse stimmen mit denen aus #852 überein wenn LAV 0.26 in DVBV 5.5 statt 5.5.0.1 läuft.

 

Hier das aktualisierte Bild, ganz rechts unten stehen jetzt die korrekten Werte (<2 GB):

Private Bytes - 1,6 GB

Virtual Size - 1,9 GB

 

post-73651-0-60719900-1438323247_thumb.jpg

 

Irgendwie scheint 5.5.0.1+EVR-C den LAV 0.26 dazu zu verlocken bei 2160p "endlich alles rauszulassen" ;)

Alle anderen Messungen blieben gleich.

Edited by craig_s
Link to comment
  • 2 months later...

Die hohe GPU-Last mit madVR konnten wir (bzw. madshi) jetzt mittels Debug Logging ermitteln. Das Problem war ein leicht verstellter Contrast-Regler im DVBViewer, welcher mit freiem Auge nicht zu erkennen war. Da passieren dann ein paar zusätzliche Shader-Steps in madVR. Jetzt ist die GPU-Last mit madVR auch unter der vom EVR. procamp ist im EVR wohl effizienter weil dafür auch "Fixed Function" Hardware (DXVA) verwendet wird.

Link to comment
Jetzt ist die GPU-Last mit madVR auch unter der vom EVR.

 

..nehme mal an du sprichst von deinem Haswell? Habe grad den meinigen i5-3320 angeworfen, hmm da müssen bei dir aber noch zusätzliche *trade quality..*-options an sein?

Mit madVR-reset per 'restore default settings.bat', dann 'image up' auf DXVA2 komme ich mit 720p->1080 fullscreen auf GPU Load 41% -> EVR nur 23%.

 

Schalte ich 'image up' auf den Standard Lanczos 3 bin ich gleich auf 73%.

EVR CiNstom war bei meinen 360p->1080 Upscaling Tests aber locker bei Lanczos 4 AR Qualität ohne zusätzliche *trade quality..*-options (wovon bei 720p->1080 zwar eh nichts zu sehen ist..).

 

Aber immerhin eine enorme madVR-Abkühlung seit April wo der Renderer auf solch gewöhnlicher Hardware quasi unbenutzbar war.

Link to comment

Folgendes ist zu beachten...

 

Wenn ich vom EVR spreche, meine ich den MS Standard EVR, den ich gerne als Referenz heranziehe. Der hat aber den Nachteil, dass sich das Rendern von OSD über den 2. Input Pin am EVR Filter nachteilig auf die GPU-Last auswirkt, selbst wenn gar kein OSD angezeigt wird. Die EVR Custom OSD Methode ist da in der Tat effizienter, weshalb dieser Renderer momentan wohl das beste Performance/Qualitäts-Verhältnis darstellt.

 

Um gleiche Bedingungen zu schaffen, müssen folgende madVR Einstellungen vorgenommen werden:

- Image Up-/Downscaling: DXVA 2

- Dithering: None

- trust DXVA...: enabled

Außerdem müssen sämtlich ProcAmp Einstellungen (Kontrast, Helligkeit, Sättigung) im DVBViewer auf neutral stehen. madVR macht das momentan über die Shader, wird irgendwann in Zukunft bei aktiver trust-Option aber DXVA dazu verwenden.

 

Ich habe die letzten Tage wieder intensiv mit madshi zusammengearbeitet, um die Performance nochmal zu steigern. Unter Verwendung von DXVA wird so ab der nächsten Version von madVR alles in einem Render-Step absolviert. Damit liegen wir nun knapp über EVR Custom (mit FSE sogar darunter) und deutlich unter Standard EVR. Wir konnten die Last auch im Windowed Fullscreen auf EVR Custom Niveau senken, allerdings nicht ohne Qualitätseinbußen im Chroma Channel.

Link to comment

Danke an CiNcH, der mir beim weiteren optimieren geholfen hat. Hier nun die neuste Build mit vielen weiteren Performance-Optimierungen für niedrige GPU-Last bei Verwendung von DXVA:

 

http://madshi.net/madVR.zip

 

Wäre cool, wenn da der eine oder andere User mal Performance-Vergleiche zu EVR und EVR-Custom machen könnte, am besten mit unterschiedlichen GPUs und OSs. Wobei ich dazu sagen muß, daß ich bei Intel und NVidia mehr optimieren konnte als bei AMD. Empfehlenswerte Settings für niedrigste GPU-Last bei madVR wären:

 

1) Default-Settings, aber mit DXVA2 für "image upscaling" und "image downscaling", und "Bilinear" für "chroma upscaling".

2) Wie 1), aber zusätzlich mit ausgeschaltetem Dithering und angehaktem "trust DXVA [...]".

 

Option 2) entspricht noch eher dem, was EVR(-Custom) macht. Wenn die GPU es schafft, wäre aber 1) auf jeden Fall vorzuziehen.

Link to comment

1080i (no ProcAmp)

madVR 0.89.13 (DXVA scaling, default settings): 30% @ 350MHz, 2.9W

madVR 0.89.13 (DXVA scaling, trust DXVA): 27% @ 350MHz, 2.5W

madVR 0.89.13 (DXVA scaling, trust DXVA, no dithering): 23% @ 350MHz, 1.9W

EVR: 31% @ 350MHz, 2.8W
EVR (Custom): 24% @ 350MHz, 2.2W

720p (no ProcAmp)

madVR 0.89.13 (DXVA scaling, default settings): 25% @ 350MHz, 2.7W

madVR 0.89.13 (DXVA scaling, trust DXVA): 22% @ 350MHz, 2.3W

madVR 0.89.13 (DXVA scaling, trust DXVA, no dithering): 17% @ 350MHz, 1.4W

EVR: 26% @ 350MHz, 2.5W
EVR (Custom): 19% @ 350MHz, 1.7W

 

 

Wir sind hier mit madVR mit Dithering im Bereich vom EVR. Mit „trust DXVA“ kann man die Last noch etwas in Richtung Custom EVR senken. Ohne Dithering ist man dann dank FSE unter der Last vom EVR Custom.

 

Ich gebe hier eigentlich nur 8-Bit Quellmaterial wieder und nutze die komplette DXVA Pipeline ohne jegliches Post-Processing. Wozu sollte Dithering bei 8-Bit Ausgabe gut sein? Mehr als rauschen kommt da doch nicht bei raus!? Dithering dürfte nur dann sinnvoll sein, wenn die Eingabebittiefe größer als die Ausgabebittiefe ist, oder?

 

 

ProcAmp 1080i (Brightness, Saturation, Contrast, Hue leicht verstellt)

 

madVR 0.89.13 (DXVA scaling, trust DXVA, no dithering): 23% @ 350MHz, 1.9W

EVR (Custom): 24% @ 350MHz, 2.2W

 

ProcAmp hat jetzt keinen Einfluss mehr auf die GPU-Last. Das macht Intel wohl locker lässig über „Fixed Function“ Hardware. Sämtliche ProcAmp Slider erledigen ihren Dienst in madVR mit DXVA.

 

 

Absolut super Ergebnis mit der aktuellen Version!

  • Like 1
Link to comment

Danke für den ausführlichen Test! :D

 

Dithering ist ein kompliziertes Thema. Ich versuch's mal zu erklären:

 

99,9% aller Videos sind ja in YCbCr 4:2:0 encodiert. Windows arbeitet aber in RGB. Das heißt, madVR muß Chroma upscalen, dann eventuell noch Deinterlacen und Up/Downscalen und dann auch noch eine Farbumwandlung machen. Vernünftiges Scaling erzeugt mehr als 8bit Daten, Video-Mode-Deinterlacing ebenso. Aber vor allem die Farbumwandling ist wichtig, das ist nämlich eine Floating-Point-Matrix-Multiplikation. Das heißt, nach erfolgter Farbumwandling sind sind die Pixel eigentlich in Floating-Point und nicht mehr in 8bit. Ok, bei RGB 16-235 Ausgabe und schwarz/weiß-Videos ist Dithering dann nicht wirklich wichtig. Aber sobald das Video Farbe kriegt, bekommen die Pixel auch ganz krumme Floating-Point-Werte, und das gibt ohne Dithering u.U. sichtbare Artefakte. Bei Computer-Monitoren ist es sogar ganz extrem: Dort muß nämlich der Luma-Channel von 16-235 auf 0-255 gestretched werden. Ohne Dithering sieht ein Grayscale dann ganz furchtbar aus.

 

Problematisch wird das ganze dadurch, daß die DXVA-Algorithmen teilweise auf 8bit limitiert sind. Bei AMD z.B. muß man NV12 -> NV12 scalen, andernfalls verwendet AMD einen schlechteren Algorithmus. Oder Intel macht grundsätzlich eine 8bit-Farbumwandlung. Immerhin die Farbumwandlung machen AMD und NVidia besser (in höhere Bittiefe). Das heißt praktisch, daß es je nach GPU-Hersteller bei Verwendung der DXVA-Algorithmen auch in 8bit schon Qualitätsprobleme geben kann. Hängt aber wie gesagt vom GPU-Hersteller ab, eventuell auch vom GPU-Modell bzw der Treiber-Version.

 

Ohne "trust DXVA" versucht madVR, die Farbumwandlung wieder rückgängig zu machen und anschließend in hoher Bittiefe "vernünftig" durchzuführen. Wie gut das klappt, hängt allerdings davon ab, wie sehr die DXVA-Algos die Daten vorher schon verstümmelt haben. Bei Intel ist da leider nicht viel zu holen, bei AMD und NVidia schon eher...

 

Gut testen läßt sich das z.B. mit den folgenden 8bit Testpattern:

 

http://madshi.net/madTestPatternSource.zip

 

Versuch z.B. mal "colors.ytp" oder "grayramp.ytp", aufgezoomt auf den ganzen Bildschirm. Dann teste das ganze mal mit EVR-Custom im Vergleich zu madVR *ohne* DXVA. Da sollte es sichtbare Unterschiede geben. madVR ohne DXVA sollte die Testpatterns alle ohne sichtbare Banding-Probleme darstellen, EVR-Custom sollte Banding zeigen. Wäre dann die Frage, wie sich madVR mit DXVA verhält, mit/ohne Dithering und/oder "trust DXVA". Auf meinem PC ist der Ofen aus (in Sachen guter Bildqualität), sobald ich bei einer Intel-GPU DXVA verwende. Da ist Dithering und "trust DXVA" mehr oder weniger egal. Bei AMD sieht das ganz anders aus. Da gibt's auch mit DXVA kaum Banding, solange ich Dithering aktiv lasse. Die besten Ergebnisse bekomme ich aber in jedem Fall ohne DXVA - leider!!

 

(Komischerweise zeigt der DVBViewer mit EVR (ohne Custom) bei den Testpatterns gar kein Bild. Aber EVR-Custom und madVR zeigen ein Bild.)

  • Like 1
Link to comment

1) Default-Settings, aber mit DXVA2 für "image upscaling" und "image downscaling", und "Bilinear" für "chroma upscaling".

 

Wie kehrt man bei MadVR zum Default zurück? Auf der Eigenschaftsseite sehe ich keine Möglichkeit, und was ich früher verstellt habe, weiß ich nicht mehr.

Link to comment

Es gibt dafür eine BAT Datei im madVR Verzeichnis ("restore default settings.bat"). Imaga up/downscaling solltest du auf deinen Systemen auf DXVA2 stellen. Dithering abschalten und "trust DXVA" aktivieren schadet wahrscheinlich auch nicht.

Link to comment

@Griga, wenn ich mich recht erinnere, hast Du 'ne AMD GPU? Bei der ist die Performance mit DXVA2 in madVR leider etwas schlechter als bei Intel/NVidia. Kann sein, daß der EVR-Custom da schneller ist. Dafür ist aber auch die Bildqualität (bei eingeschaltetem Dithering) bei madVR mit AMD besser als bei Intel.

Link to comment

Ausgehend von den Default Settings HD 720p Vollbild:

 

aber mit DXVA2 für "image upscaling" und "image downscaling", und "Bilinear" für "chroma upscaling".

 

Gibt dropped frames. Dithering muss ich auf jeden Fall ausschalten. Dann wird es besser. Keine dropped frames, allerdings nur, wenn ich im LAV Video Decoder DXVA ausschalte (damit er nicht mehr mit MadVR um die GPU konkurriert) und kein OSD einblende.

 

Wunder wirkt jedoch rendering -> trade quality for performance -> trust DXVA color & level conversion. Dann gibt es im Vollbild auch mit DXVA im LAV Video Decoder und OSD keine dropped Frames. Nur noch, wenn ich das Kontextmenü aufrufe.

Link to comment

Tja, mit ausgeschaltetem Ditherung und aktiviertem "trust DXVA" solltest Du dann auch bildqualitätsmäßig ziemlich genau da sein, wo der EVR-Custom liegt. Wahrscheinlich ist dann auch die Performance nicht allzu doll unterschiedlich. Eigentlich schade, bei einer AMD wäre eingeschaltetes Dithering schon hilfreich.

Link to comment

Naja, ATI Radeon HD 4300/4500 Series... wie alt ist die? Ziemlich, glaube ich. Ich bin auch nicht so ein Video-Qualitätsfanatiker, insofern ist mir Dithering herzlich egal. Ich wollte nur feststellen, ob die MadVR-Fortschritte bei der Beanspruchung von Ressourcen hier 720p HD im Vollbild ermöglichen. Das ging zuvor nämlich kaum.

Link to comment

Gut testen läßt sich das z.B. mit den folgenden 8bit Testpattern:

 

http://madshi.net/madTestPatternSource.zip

 

Versuch z.B. mal "colors.ytp" oder "grayramp.ytp", aufgezoomt auf den ganzen Bildschirm. Dann teste das ganze mal mit EVR-Custom im Vergleich zu madVR *ohne* DXVA. Da sollte es sichtbare Unterschiede geben. madVR ohne DXVA sollte die Testpatterns alle ohne sichtbare Banding-Probleme darstellen, EVR-Custom sollte Banding zeigen. Wäre dann die Frage, wie sich madVR mit DXVA verhält, mit/ohne Dithering und/oder "trust DXVA".

 

Stimmt alles (hier auf Nvidia, Intel, AMD) nur nicht mit "colors.ytp" oder "grayramp.ytp". Die beiden zeigen vorbeifliegende Balken, das ist nicht so günstig um dazwischen noch zusätzliches Banding auszumachen.

 

Besser ist das "smallramp.ytp", das ist ein glatter Grauverlauf und die beschriebenen Effekte im oberen Zitat sind alle gut sichtbar.

Dafür braucht man dieses 200-pixel Mini-Testpattern sogar nur weinig aufzuziehen. Außer bei Nvidia, da muß man schon 1080 Fullscreen schalten um sehr schwaches Banding zu sehen.

 

Ich zweifle allerdings an der Aussagekraft dieses Tests bezügl. dem was in realem Video stattfindet, besonders in HD Format.

Die Stelle wo zB. in einem 720p Video o.g. Banding auch nur minimalst nachweisbar ist mußt du mir erst mal zeigen, Nvidia, Intel, AMD egal.. :innocent:

 

 

Bei AMD sieht das ganz anders aus. Da gibt's auch mit DXVA kaum Banding, solange ich Dithering aktiv lasse. Die besten Ergebnisse bekomme ich aber in jedem Fall ohne DXVA - leider!!

 

Auch das kann ich bestätigen, würde sogar sagen "kein Banding".

Ich hatte heute ein ulkiges Date mit meiner "Ati Radeon HD 3850 AGP" mit der ich 2009 auf Intel Pentium 4, 3000 MHz SingleCore die Käsescheibchen erzeugt habe. Ich konnts einfach nicht lassen darauf den neuen madVR zu probieren und er konnte immerhin den "smallramp.ytp" bandingfrei abspielen. Die WinXP Renderer als Konkurrenz - ja und siehe da, der gute alte Overlay Mixer spielte das auch bandingfrei! Da legst di nider :rofl2: "System Standard" Renderer konnte es solo auch!

 

Parallel nebendran ein Rechner mit modernerer Ati, jetzt schon AMD HD 6970.

Damit gabs einen bemerkenswerten Ausfall:

"smallramp.ytp" auch jedes andere .ytp -> sowohl MPC-HC als auch DVBViewer schalten damit trotz EVR-C gewählt auf einen anderen Renderer um (->hier jetzt in Win7!):

nämlich auf "Video Renderer" = "System Standard", Überbleibsel aus XP -> und der spielt "smallramp.ytp" mal wieder - bandingfrei.. :| Bei dir evl. mit AMD auch so?

 

(Komischerweise zeigt der DVBViewer mit EVR (ohne Custom) bei den Testpatterns gar kein Bild. Aber EVR-Custom und madVR zeigen ein Bild.)

die .ytp laufen bei mir auch mit EVR (Enhanced) einwandfrei.

 

 

Auf meinem PC ist der Ofen aus (in Sachen guter Bildqualität), sobald ich bei einer Intel-GPU DXVA verwende. Da ist Dithering und "trust DXVA" mehr oder weniger egal.

 

Weil du so über Intel Banding schimpfst... eventuell hast du einen TV über HDMI dranhängen?

Dann probiere mal einen *echten* 60Hz PC-Moni über DVI an der Intel GPU. Wirkt(e 2012) Wunder, heute auch noch besser. Damals gab es im Treiber sogar noch ein halblebiges Ausgabe-Menü das mit HDMI@TV nie richtig funktionierte. DVI / DisplayPort @PC-Moni lief dagegen problemlos Plug'nPlay "RGB full" plus ein ausgezeichnet funktionierendes Extra-Treiber-Menü fürs DDC Protokoll, all das ist inzwischen scheinbar gestrichen?

 

Soweit erstmal..

Edited by craig_s
Link to comment

 

Ich hatte heute ein ulkiges Date mit meiner "Ati Radeon HD 3850 AGP" mit der ich 2009 auf Intel Pentium 4, 3000 MHz SingleCore die Käsescheibchen erzeugt habe. Ich konnts einfach nicht lassen darauf den neuen madVR zu probieren und er konnte immerhin den "smallramp.ytp" bandingfrei abspielen. Die WinXP Renderer als Konkurrenz - ja und siehe da, der gute alte Overlay Mixer spielte das auch bandingfrei! Da legst di nider :rofl2: "System Standard" Renderer konnte es solo auch!

 

Unter XP macht madVR wohl kein DXVA, da nur DXVA2 (mind. Vista) unterstützt wird. Overlay Mixer unter XP ist auch nichts anderes als eine vollwertige DXVA-Kette (sofern ein geeigneter DXVA-Video-Dekoder zum Einsatz kommt). Dürfte also ähnliche Ergebnisse liefern wie madVR in neueren Betriebssystemen mit DXVA2.

 

 

Weil du so über Intel Banding schimpfst... eventuell hast du einen TV über HDMI dranhängen?

Dann probiere mal einen *echten* 60Hz PC-Moni über DVI an der Intel GPU. Wirkt(e 2012) Wunder, heute auch noch besser.

 

Nach meinem theoretischen Verständnis ist Banding am PC Monitor ein noch größeres Problem, weil 16-235 auf 0-255 gestreckt werden muss!?

Link to comment

Also ich persönlich finde "colors.ytp" und "grayramp.ytp" fast noch besser, um Banding zu erkennen. In Filmen ist es auch so, daß man Banding "in motion" fast besser sieht als in Screenshots. Achte doch bei "colors.ytp" und "grayramp.ytp" mal auf folgendes: Beide sollten beim Abspielen idealerweise keine Bewegung nach links, rechts oder diagonal zeigen. Beide sollten nur Helligkeit oder Farben ändern, gleichmäßig über den ganzen Bildschirm. Sobald Du z.B. bei "grayramp.ytp" eine Bewegung nach links oder rechts wahrnehmen kannst, stimmt etwas nicht. Bitte "colors.ytp" und "grayramp.ytp" nicht pausiert benutzen. Diese beiden sind dafür ausgelegt, bewegt abgespielt zu werden. Du brauchst dann gar nicht nach Banding-Steps zu gucken, sondern einfach nur danach, ob Du eine seitliche oder diagonale Bewegung erkennen kannst.

 

Tja, Du hast natürlich vollkommen Recht damit, daß die Probleme, die wir in diesen Testpatterns vielleicht sehen können, nicht *unbedingt* auch bei normalen Videos für das menschliche Auge sichtbar/störend sind. Das ist ähnlich wie beim Chroma-Upscaling: In manchen Szenen sieht man es, in anderen Szenen eher nicht. Chroma-Upscaling-Unterschiede sieht man z.B. fast nur bei roten Schriften auf schwarzem Hintergrund (oder ähnliches). Banding-Unterschiede kann man manchmal sehen in Szenen, wo man typische Grayscale-ähnliche Verläufe hat, wie sehr neblige Szenen oder so. Auch fade-to-black wirken ohne Dithering manchmal etwas weniger "weich" und flüssig als mit Dithering. Der Unterschied wird natürlich auch wieder größer, je nachdem wie groß der Bildschirm ist (bei mir 2,80m breite Leinwand).

 

Grundsätzlich ist meine Meinung, daß alles was man in einem Testpattern sehen kann (solange das Testpattern nicht völlig film-untypisch ist, wie z.B. abwechselnd schwarze und weiße 1-Pixel-Linien), auch in echten Filmen auftreten *kann*. Wie häufig und wie auffällig, ist eine andere Frage. Aber ich denke, viele klitzekleine Verbesserungen können sich auch zu einem deutlich sichtbaren Unterschied auf-addieren. Von daher versucht madVR, alles "perfekt" zu machen, in der Hoffnung, daß das Endergebnis dann vielleicht doch einen kleinen sichtbaren Qualitätsgewinn zeigt, selbst wenn man keine speziellen madVR-Algos (wie Scaling, Debanding, Sharpening, Smooth Motion usw) aktiviert hat.

 

Hab an meinem Dev-PC per DVI einen Computer-Monitor. Am HTPC einen Projektor über HDMI.

 

Interessant, daß der Overlay-Mixer bzw System-Standard-Renderer kein Banding zeigt!! Bin mir nicht ganz sicher, was der für GPU-APIs der aufruft. Hat der denn identische Schwarz- und Weiß-Werte wie EVR/madVR? Oder kann es vielleicht sein, daß der Overlay-Mixer 16-235 ausgibt anstatt 0-255? Bei 16-235-Ausgabe gibt's von Natur aus deutlich weniger Banding-Probleme als bei 0-255, weil der Luma-Channel nicht gestretcht werden muß.

 

Kannst Du mal die Performance vergleichen zwischen EVR, EVR-Custom und madVR, mit Deiner Hardware? Bei AMD sollte EVR(-Custom) leicht im Vorteil sein, bei NVidia und Intel sollte madVR auf gleichem Niveau liegen, zumindest wenn Du madVR auf DXVA-Up/Downscaling schaltest, Chroma-Upscaling auf Bilinear, Dithering aus, und "trust DXVA" an.

Link to comment

 

Unter XP macht madVR wohl kein DXVA, da nur DXVA2 (mind. Vista) unterstützt wird. Overlay Mixer unter XP ist auch nichts anderes als eine vollwertige DXVA-Kette (sofern ein geeigneter DXVA-Video-Dekoder zum Einsatz kommt). Dürfte also ähnliche Ergebnisse liefern wie madVR in neueren Betriebssystemen mit DXVA2.

 

 

Nach meinem theoretischen Verständnis ist Banding am PC Monitor ein noch größeres Problem, weil 16-235 auf 0-255 gestreckt werden muss!?

 

War nicht unter bestimmten Umständen (ich glaube .NET 3.0 muß installiert sein oder so) auch DXVA2 in WinXP verfügbar?

 

Korrekt: Banding ist bei 0-255-Ausgabe definitiv ein größeres Problem als bei 16-235.

Link to comment

 

War nicht unter bestimmten Umständen (ich glaube .NET 3.0 muß installiert sein oder so) auch DXVA2 in WinXP verfügbar?

 

Nur der EVR, aber ohne Hardwarebeschleunigung, also weder DXVA noch DXVA2 standen da dann zur Verfügung.

Link to comment

Oh, ich hatte in Erinnerung, daß es zwar so gut wie keine DXVA2-Video-Decoder gibt, daß aber DXVA2-Deinterlacing und -Scaling funktionieren würde? Kann mich aber auch irren, ist schon ewig lange her, daß ich XP laufen hatte...

Link to comment

 

daß aber DXVA2-Deinterlacing und -Scaling funktionieren würde?

 

Habe ich ehrlich gesagt nie getestet. Ob die GPU-Treiber das unter XP wirklich unterstützten?

Link to comment
Overlay Mixer unter XP ist auch nichts anderes als eine vollwertige DXVA-Kette (sofern ein geeigneter DXVA-Video-Dekoder zum Einsatz kommt). Dürfte also ähnliche Ergebnisse liefern wie madVR in neueren Betriebssystemen mit DXVA2.

 

Mit dem Unterschied das in modernen DXVA2 Zeiten kein einziger Renderer ausser madVR "grayramp.ytp" bandingfrei kann.

"System Standard" Renderer kann es in MPC-HC und DVBViewer auch in modernen PCs immernoch. Ist ja nur ein rein *wissenschaftl.* Experiment. Zum Weiterkommen.

 

Nach meinem theoretischen Verständnis ist Banding am PC Monitor ein noch größeres Problem, weil 16-235 auf 0-255 gestreckt werden muss!?

 

 

Bei teildefekten Treibern ist es ein Glücksspiel was hinten rauskommt. Intel über HDMI an TV zeigt hier schon auf dem Desktop oder Fotoanzeige Banding. Ausgabemenü gibts keins...

Auf dem PC-Moni ist schonmal der Desktop ohne Banding.

Link to comment

 

"System Standard" Renderer kann es in MPC-HC und DVBViewer auch in modernen PCs immernoch. Ist ja nur ein rein *wissenschaftl.* Experiment. Zum Weiterkommen.

 

System Standard dürfte im Hintergrund auch nur je nach OS einen bekannten Renderer verwenden (Overlay oder VMR bis Windows XP, ab Vista dann EVR?).

Evtl. werden Probleme in neueren Renderern ja durch D3D verursacht?

Link to comment

Banding-Unterschiede kann man manchmal sehen in Szenen, wo man typische Grayscale-ähnliche Verläufe hat, wie sehr neblige Szenen oder so. Auch fade-to-black wirken ohne Dithering manchmal etwas weniger "weich" und flüssig als mit Dithering.

..und sieht dabei meistens nur was die zahlr. broadcasting- oder sonstige Komprimierungen schon lange vorher unauslöschlich verbrochen haben...

 

 

Der Unterschied wird natürlich auch wieder größer, je nachdem wie groß der Bildschirm ist (bei mir 2,80m breite Leinwand)

 

..beeindruckt mich nicht, auf das Verhältnis zum Betrachtungsabstand kommts doch an. Außerdem ist meine Weinland breiter. Mit D-ILA Projektor. :P

 

 

Grundsätzlich ist meine Meinung, daß alles was man in einem Testpattern sehen kann (solange das Testpattern nicht völlig film-untypisch ist, wie z.B. abwechselnd schwarze und weiße 1-Pixel-Linien), auch in echten Filmen auftreten *kann*. Wie häufig und wie auffällig, ist eine andere Frage. Aber ich denke, viele klitzekleine Verbesserungen können sich auch zu einem deutlich sichtbaren Unterschied auf-addieren. Von daher versucht madVR, alles "perfekt" zu machen, in der Hoffnung, daß das Endergebnis dann vielleicht doch einen kleinen sichtbaren Qualitätsgewinn zeigt, selbst wenn man keine speziellen madVR-Algos (wie Scaling, Debanding, Sharpening, Smooth Motion usw) aktiviert hat.

 

Bravo!

Pass halt auf das du dich bei dem ans Unmögliche grenzenden Unternehmen nicht zu sehr verzettelst. "Zuviele Häkchen verderben den Brei", hatten wir ja schon.. ;)

Aus gleicher Erfahrung heraus kann ich heute sagen, immer denkt man der Filz wäre irgendwann irgendwie, sogar bald? leicht zu lösen.

Dann vergehen die Jahre wie im Fluge und alles immernoch mehr oder weniger unverändert...

 

>>abwechselnd schwarze und weiße 1-Pixel-Linien<< funktionieren wunderbar um untersch. Deinterlacing-Algos in DXVA schnell zu bestimmen.

Wenn der viel später dazugekommene madVR andere Wege geht, tja, zu spät.. ;)

 

 

Hab an meinem Dev-PC per DVI einen Computer-Monitor. Am HTPC einen Projektor über HDMI.

 

Projektoren erzeugen Bildtechnisch wieder ein ganz anderes bombastisches Eigenleben.

Wenn ich die dort gefundenen Fehler nah vor einem großen Monitor ansehe sind sie regelmäßig viel deutlicher zu erkennen.

Schwaches Banding über HDMI (schon auf dem Desktop?) bliebe allerdings nach meinen jüngsten Beobachtungen hier dem Projektor vorbehalten.

 

 

Interessant, daß der Overlay-Mixer bzw System-Standard-Renderer kein Banding zeigt!! Bin mir nicht ganz sicher, was der für GPU-APIs der aufruft. Hat der denn identische Schwarz- und Weiß-Werte wie EVR/madVR? Oder kann es vielleicht sein, daß der Overlay-Mixer 16-235 ausgibt anstatt 0-255? Bei 16-235-Ausgabe gibt's von Natur aus deutlich weniger Banding-Probleme als bei 0-255, weil der Luma-Channel nicht gestretcht werden muß.

 

Natürlich kann, wenn man in kurzer Zeit über mehrere Plattformen und Hardwares testet mal ein falscher Schwzarzwert durchrutschen aber einen deutlich schlechten hätte ich mit Sicherheit bemerkt.

Außerdem kann wie gesagt jeder das *Wunder* des System-Standard-Renderer mit "smallramp.ytp" selbst checken, funzt auch auf modernen GPUs. Hier jetzt gerade GTX960 in Win10..

Der AMD HD 6970 Rechner hat sich den System-Standard-Renderer sogar in MPC-HC als auch DVBViewer selbst *geholt* obwohl EVR-C eingestellt war (Win7).

 

 

Kannst Du mal die Performance vergleichen zwischen EVR, EVR-Custom und madVR, mit Deiner Hardware? Bei AMD sollte EVR(-Custom) leicht im Vorteil sein, bei NVidia und Intel sollte madVR auf gleichem Niveau liegen, zumindest wenn Du madVR auf DXVA-Up/Downscaling schaltest, Chroma-Upscaling auf Bilinear, Dithering aus, und "trust DXVA" an.

 

Geduld, das ist viel Arbeit auf die ich grad nicht so scharf bin. Immerhin habe ich bei allen Tests auf den Rechnern den Taskmanager angehabt, CPU war meistens um 2-5-10%. Bei größerformatigem im Pentium 4 gings mit madVR natürlich höher aber das zählt nicht. madVR *fühlte* sich sonst immer "ungewohnt niederverbrauchig" an, "fast so wie die anderen" Renderer. Irgendwann werd ich mal dazu kommen die Performance genauer zu checken.

Edited by craig_s
Link to comment

Ich hab überhaupt nix gegen künstliche Testpattern mit 1-Pixel-schwarz/weiß Linien. Sowas ist durchaus hilfreich, um bestimmte Dinge zu testen. Was ich sagen wollte ist, daß in gefilmtem Content niemals eine 1-Pixel breite schwarze Linie direkt neben einer 1-Pixel breiten weißen Linie sein kann, weil das MTF der Kamera-Optik so eine Auflösung niemals zulassen würde. Selbst in computer-gerendertem Content gibt's sowas eigentlich nicht, weil die auch mit Anti-Aliasing-Filtern arbeiten (bzw höher rendern und dann runterscalen), und da kommt auch niemals am Ende eine 1-Pixel-schwarz-Linie neben einer 1-Pixel-weiß-Linie raus.

 

Heißt praktisch, so ein Testpattern ist für manche Tests gut (z.B. ob Deinterlacing korrekt arbeitet, wie Du schon gesagt hast), aber man sollte sich bewußt sein, daß in echtem Content sowas normalerweise nicht vor kommt. Heißt praktisch, die Qualität eines Scaling-Algorithmus würde ich z.B. nicht mit so einem 1-pixel-weiß/1-pixel-schwarz Testpattern testen, weil Scaling-Algorithmen nicht für sowas optimiert sind. Leider gibt's immer wieder Reviewer, die Scaling-Algorithmen mit solchen Testpatterns quälen und darauf dann basieren wollen, ob der Algo gut ist oder nicht. Auch Frequenz-Bänder/-Bursts werden für solche Tests gerne mißbraucht. Das macht einen Hauch mehr Sinn, aber hat auch nur sehr beschränkte Aussagefähigkeit für die Qualität eines Scaling-Algos.

 

Solange man Testpatterns für den "richtigen" Zweck einsetzt, habe ich überhaupt ganz und gar kein Problem damit, auch film-untypische Testpatterns zu verwenden.

 

Die "zu viele Häckchen" werden irgendwann radikal reduziert werden. Aber ich habe immer gesagt, das passiert für die Version 1.0, und nicht davor. Du mußt mal im doom9-Forum das Rumgeheule hören, wenn ich nur einen Haken irgendwo weg nehme. Da gibt's immer einen User, für den gerade der eine Haken lebensnotwendig war. Aber für Version 1.0 werde ich da ziemlich radikal sein. Kann allerdings sein, daß ich die meisten Haken dann doch noch irgendwo versteckt unter "Nerd-Tweaks" wieder zugänglich mache. Wobei mein Plan eigentlich ist, die meisten Haken intelligent selbst zu setzen, je nach Leistungsfähigkeit der GPU. Aber soweit bin ich noch nicht. Muß erstmal noch einiges an Features einbauen, die noch fehlen. Solange werden tendenziell eher *noch* mehr Haken dazu kommen. <seufz>

Link to comment

"Nerd-Tweaks" ist doch gut.

Das Problem mit den vielen Haken ist auch beim DVBViewer nicht unbekannt. Der DVBViewer hat daher diese Tweaks auch. ;)

 

Die Königslösung ist imho ein Expertenmenü, damit man auf die Tweaks direkt per GUI zugreifen kann.

Wenn nützliche Dinge aufgrund der Bedienbarkeit zurückgebaut werden finde ich das problematisch. Irgendwie sollte man da schon noch dran kommen ...

Ich mecker da beim DVBViewer auch meistens. :D

 

Zum Banding: Finde die Tests mit Testpattern für Dithering wesentlich zielführender wenn man erstmal feststellen will ob ein Processing-Schritt Banding erzeugt.

"Normale" Quellen wie DVB Streams enthalten meist schon selbst jede Menge Banding und das bekommt man mit dithering dann nicht beseitigt (sondern nur mit dem deband Algo).

Link to comment
...die Qualität eines Scaling-Algorithmus würde ich z.B. nicht mit so einem 1-pixel-weiß/1-pixel-schwarz Testpattern testen...

 

2008/9 waren grad alle total irre scharf auf das neue VectorAdaptive (so wie jetzt auf das 10te Bit ;))

Wildeste Spekulationen, keiner hatte es je wirklich gesehen.

 

In diese Situation schlug Käsescheibchen ein wie eine Bombe.. :D Es ging von Anfang an nur um den Nachweis:

-> "ist es auf meiner Hardware vorhanden / machbar?" ja/nein.

Das man VA nur selten im TV sieht war klar - sonst hätten es ja schon vorher viele gesehen. Schräge Linien..

Das Fachzeitungen später daraus irgendwas anderes rauskitzeln hat mich nur am Rande interessiert. Jaa die müssen halt ihre Seiten vollkriegen.. Bin doch selber "Presse" (TV)mann :innocent:

 

 

Du mußt mal im doom9-Forum das Rumgeheule hören, wenn ich nur einen Haken irgendwo weg nehme. Da gibt's immer einen User, für den gerade der eine Haken lebensnotwendig war.

 

..das wollt ich eigentlich noch in einem Nachsatz formulieren - als Mann der Öffentlichkeit entstehen einem Abhängigkeiten die Veränderungen sehr erschweren.

Irgendwo bist du jetzt Politiker/Fernsehmoderator in einem und darfst nicht mehr laut furzen/fluchen sonst keine Wiederwahl, die Einschaltquoten gehen zurück.. :laughing:

 

"Expertenmenü", eine gute Wahl..

Edited by craig_s
Link to comment
Kann allerdings sein, daß ich die meisten Haken dann doch noch irgendwo versteckt unter "Nerd-Tweaks" wieder zugänglich mache.

 

Im DVBViewer-Umfeld habe ich das Problem durch ein Programm namens Tweaker.exe entschärft. Es stellt eine beliebige Menge per INI-Date definierte Tweaks als UI dar (allerdings ohne Hierarchie-Ebenen) und schreibt die Einstellungen wahlweise in eine XML oder INI-Datei.

 

Zwischenablage01.png

 

Das UI ist (optional) zweisprachig, für den DVBViewer deutsch / englisch mit automatischer Erkennung. Vom Standard abweichende Einstellungen werden kursiv dargestellt. Ein Tweak wird z.B. so definiert:

 

[10]

Section=OSD

Ident=UseOSD

Type=Boolean

Default=1

Caption=Enable the OSD

CaptionG=Das OSD aktivieren.

Description=If this options is enabled the OSD can be used.

DescriptionG=Wenn diese Option aktiviert ist, wird das OSD angezeigt.

 

Bei Bedarf könnte ich dir den Delphi-Quellcode zur Verfügung stellen.

Link to comment

Hmmmm... Das klingt durchaus interessant!

 

Etwas problematisch an der Sache ist aber, daß man bei madVR dynamische Profile einrichten kann. Die meisten der Einstellungen (auch die Nerdy-Tweaks) können daher mehrfach vorkommen, halt 1x pro Profil. Das werd ich mit einer Ini-Datei nicht gelöst kriegen. Die Einstellungen müssen schon im Haupt-Einstellungs-Tree bleiben, damit die Zuordnung zu den Profilen paßt. Aber es ist eine gute Idee, da nicht manuell Dialoge für alle Nerdy-Tweaks zu machen, sondern einen generellen Dialog, der dann einfach jeden Tweak je nach Typ anzeigt und editierbar macht. Vielleicht löse ich das dann auch auf ähnliche Weise, mal schauen.

 

Es wird aber eh noch Monate dauern, bis ich soweit bin, daß ich überhaupt anfangen kann, mich mit dem Thema zu beschäftigen.

Link to comment
  • 1 month later...

Hi madshi,

 

ich beschäftige mich gerade etwas mit dem Thema deinterlacing (DXVA vs IVTC in madVR).

 

Der DXVA-Deinterlacer macht imho aus 50i immer 50p und dann muss sich madVR mit 50 frames abmühen, obwohl das für "unechte" interlaced Quellen wie Filme gar nicht nötig wäre.

Ich würde daher erwarten, dass bei aktiviertem Filmmodus in madVR die Zeit fürs Rendering deutlich geringer wird als bei aktiviertem DXVA-Deinterlacer.

 

Soweit zur Theorie, in Test konnte ich das zumindest anhand der OSD Statistik so leider nicht nachvollziehen (s. Bilder im Anhang).

Die hohe GPU-Last wurde im Test durch übertriebenen Einsatz der Schärfe-Filter nach dem upscaling erzeugt, da dies auf beide Methoden gleich wirken sollte.

 

Was auffällig war: beim DXVA-Deinterlacer kam doch zu deutlichen verworfenen frames, mit dem madVR eigenen "Deinterlacer" war davon nichts zu sehen.

Meine Vermutung war daher ein Fehler in der Messung? Zu erwarten wäre eigentlich eine in etwa halbierte Zeit fürs rendering, da madVR das Processing nur auf 25frames anstatt auf 50 frames anwenden muss?

 

Oder stimmt die Theorie so gar nicht? Falls nein: wieso nicht?

 

 

Gruß und frohe Weihnachten. :)

 

 

 

post-39934-0-01916400-1451147880_thumb.png

post-39934-0-98615600-1451147893_thumb.png

Link to comment

Moin,

 

IVTC:

vsync 20ms, frame 40ms

rendering ~ 30ms

render queue: 7-8/8

dropped frames: 0

 

DXVA:

vsync 20ms, frame 20ms

rendering ~ 30ms

render queue: 1-3/8

dropped frames: 2310

 

Sieht doch recht eindeutig aus, oder nicht? Für die Render-Zeiten macht es keinen Unterschied, ob es sich um 25fps oder 5000fps handelt, da es sich ja um Render-Zeiten *pro Frame* handelt, und nicht pro Sekunde oder so. Entscheidend ist, daß die Render-Zeiten unter der "frame"-Zeit liegen. Bei IVTC ist das der Fall (30ms < 40ms), bei DXVA nicht (30ms > 20ms).

 

Wenn es für Dich einfacher verständlich ist, kannst Du natürlich auch die Render-Zeiten auf eine Sekunde Filmlaufzeit hochrechnen. Das wäre dann bei IVTC: 30ms * (1000 / 40ms) = 750ms Renderzeit pro Sekunde Laufzeit. Und bei DXVA: 30ms * (1000 / 20ms) = 1500ms Renderzeit pro Sekunde Laufzeit.

Link to comment

Danke für die Erklärung.

Das war mir so nicht bewusst klingt aber logisch.

Ich dachte die Umrechnung würde madVR "irgendwie" schon machen damit man ohne weiteres rechnen vergleichbare Werte im Bezug auf das laufende Video hat. :)

Edited by nuts
Link to comment
  • 3 weeks later...

Wo wir beim Thema VSync und Frame sind... kann mir jemand erklären warum die Anzeige bei 720p50 Sender so ist?

 

vsync 20ms, frame 40ms

 

Das würde heissen 25 fps???

Link to comment

Würde es, aber die Info wird da von LAV nicht immer korrekt erkannt und dementsprechend falsch an den Renderer übergeben. Wenn du in den DVBViewer Filter Einstellungen die Formaterkennung aktivierst, ist die Info korrekt.

Link to comment

...ist die Info korrekt, wo? im Source Filter oder in MadVR?

 

Mit und ohne Formaterkennung ist die Info im Source Filter korrekt und in MadVR falsch

Edited by blasgl
Link to comment

Mit Formaterkennung gibt schon der DVBSource dem LAV die korrekten Infos und der weiter an madVR.

 

Ohne Formaterkennung muss LAV selbstständig die korrekten Infos ermitteln, was bei 720p50 nicht korrekt funktioniert. Allerdings rendert madVR anhand anderer Infos. Somit ist nur die Anzeige fehlerhaft.

Link to comment

So wie ich das verstanden habe, holt sich MadVR die Infos direkt vom Sourcefilter. Der LAV Video Decoder erkennt auf jeden Fall die korrekten Parameter, sonst könnte er den Kram gar nicht dekodieren (und mit DXVA schon gar nicht). Am LAV Output-Pin erscheinen die Infos für das bereits dekodierte Video. MadVR hat jedoch den den Drang, anzuzeigen, was es ursprünglich war.

Link to comment

Das ganze ist relativ komplex. Es gab mal ein paar Decoder, die falsche FPS-Infos an madVR geliefert hatten. Aus dem Grund hat madVR eine Logik eingebaut, die sich den Video-Bitstream (h264/MPEG2/VC-1) anguckt, und falls die vom Decoder kommenden FPS-Infos genau um den Faktor 2.0 oder 0.5 falsch sind, korrigiert madVR das automatisch. Der entsprechende Code ist aber schon viele Jahre alt und ist möglicherweise heute nicht mehr nötig, keine Ahnung.

 

Grundsätzlich ist es so, daß madVR zuallererst die FPS-Infos aus dem VIDEOINFOHEADER2 zieht. Falls da nix drin steht, hangelt sich madVR durch die Filter-Chain, angefangen mit dem Filter, der am nächsten zu madVR ist (in der Regel der Decoder), und nimmt dann die erste FPS-Info, die es finden kann.

 

Mir ist nicht klar, warum das Problem in diesem bestimmten Fall auftritt. Normalerweise ist LAV recht zuverlässig damit, die korrekte FPS-Info an madVR zu schicken. Es gibt aber auch Video-Streams, in denen diese Info gar nicht im Header drin steht, und dann kann man nur anhand der Frame-Timestamps raten.

 

Läßt sich das Problem auch "offline" mit einer Datei reproduzieren? Oder passiert das nur im Live-TV-Betrieb?

 

P.S: Für das eigentliche Rendern benutzt madVR diese FPS-Info übrigens gar nicht. Es wird allerdings dazu herangezogen, die passende Display-Refresh-Rate einzustellen (falls der optionale Display-Mode-Changer aktiviert ist), und es wird auch herangezogen um zu entscheiden, ob das optionale Smooth Motion FRC aktiviert wird oder nicht.

Edited by madshi
Link to comment

 

Läßt sich das Problem auch "offline" mit einer Datei reproduzieren? Oder passiert das nur im Live-TV-Betrieb?

 

Soweit ich weiß wird bei Dateiwiedergabe die Formaterkennung immer gemacht. Mit der TeVii S660, die ich dir geschickt habe, ist es mit den deutschen öffentlich rechtlichen leicht reproduzierbar (Das Erste HD, ZDF HD,...). Die sind alle 720p50.

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...