goldfield Posted February 28, 2015 Share Posted February 28, 2015 Ja, stimmt schon. Ein "Schnellschuss" bringt natürlich auch niemandem was. Aber wie schon von dir angemerkt. Ungeduld, mit einem kleinen Schuss Langeweile. Quote Link to comment
goldfield Posted March 13, 2015 Share Posted March 13, 2015 Mal ne Frage zur Erstellung von Profilen im madVR. Ich hab jetzt Image doubling/32neur., und für das weitere image upscaling Lancos3+AR eingestellt. Wie müsste jetzt das Script aussehen, damit alles ab einer horizontalen Auflösung von einschließlich 1280 Pixeln nur noch per Lancos3+AR hochscaliert wird, ohne vorheriges image doubling ? Ist hier evt. schon das passende dabei? http://www.madvr.com/articles/how-to-configure-profile-rules-in-madvr Ich kann leider weder Englisch, noch hab ich auch nur ansatzweise Ahnung von Scripten. Gruß: goldfield Quote Link to comment
nuts Posted March 13, 2015 Share Posted March 13, 2015 Im Prinzip entspricht das erste Beispiel im Link deinen Anforderungen. Es wird eben zusätzlich noch auf die fps (24p, 60p usw.) eingegangen. Quote Link to comment
DeanK Posted March 15, 2015 Share Posted March 15, 2015 Trying to follow this thread as best as I can using google translate, but I could not find information about what DVBViewer version to download to try MadVR support. Is this version available for download in the members section? Quote Link to comment
Tjod Posted March 15, 2015 Share Posted March 15, 2015 You can't get the version. You have to wait for the next version of the DVBViewer Pro. Quote Link to comment
nuts Posted March 23, 2015 Share Posted March 23, 2015 Hi madshi, Hat sich daraus eigentlich etwas ergeben? Hmmmm... Stimmt, zumindest sieht da irgendwas komisch aus: Wenn ich pausiere, kommt kurz ein altes Frame, dann erscheint direkt danach das aktuelle Frame mit nem Pause-Symbol drüber, allerdings auch nicht im korrekten AR! Wenn ich die Wiedergabe dann wieder starte, sieht aber alles ok ..... Naja, könnte aber mit dem OSD zusammen hängen, .... Zumindest ist das etwas, das ich mir angucken kann. Mal schauen, ob es meine Schuld ist... Quote Link to comment
CiNcH Posted March 24, 2015 Share Posted March 24, 2015 Wenn ich es richtig verstanden habe, ist das Problem hier das Standbild-Frame, das der DVBViewer an den Standard-Renderern vorbei im Pause-Zustand anzeigt. Quote Link to comment
madshi Posted March 30, 2015 Share Posted March 30, 2015 Jau, so ist das. Hab gerade eine neue Release veröffentlicht: http://madshi.net/madVR.zip (v0.87.15) Könnte für einige der Power-Optimierungs-Fans hier im Thread vielleicht interessant sein. Hab das ganze DXVA-Handling etwas überarbeitet. Es gibt ein paar neue "trade quality for performance" Optionen, die per Default aktiviert sind. Mit diesen Einstellungen sollte madVR jetzt bei Verwendung von DXVA Decoding/Deinterlacing/Scaling etwas schneller geworden sein. Außerdem sollte nun die Scaling-Qualität auch bei AMD gefixt sein. Ich gehe davon aus, daß CiNcH's EVR-Custom immer noch spürbar schneller sein sollte, weil madVR ja immer noch ein paar Sachen extra macht (wie Dithering usw). Aber die Unterschied sollte etwas kleiner geworden sein... Quote Link to comment
nuts Posted March 30, 2015 Share Posted March 30, 2015 Danke für die neue Version. Das Update kommt auch zur richtigen Zeit! Muss noch richtig vergleichen, aber von der Statistik her scheint das schon einen gewissen Performance Boost zu bringen. Quote Link to comment
nuts Posted March 30, 2015 Share Posted March 30, 2015 Zum besseren Verständnis, mit diesen Optionen wird kein copyback nach dem DXVA Decoder mehr durchgeführt oder? * new trade option "use DXVA chroma upscaling when doing native DXVA decoding"* new trade option "use DXVA chroma upscaling when doing DXVA deinterlacing" Quote Link to comment
madshi Posted March 30, 2015 Share Posted March 30, 2015 madVR macht jetzt überhaupt kein Copyback mehr. LAV Video Decoder kann das besser. Also wer Copyback haben will, am besten LAV auf DXVA Copyback einstellen und fertig. Die neuen trade Optionen entscheiden nur, wer chroma upscaling macht: DXVA/GPU oder madVR per PixelShader. Quote Link to comment
nuts Posted March 30, 2015 Share Posted March 30, 2015 Ich habe mir die DXVA Kette mal angesehen. Quelle: 1080i50 HDTV (Live) GPU: Intel HD4000 (neuster Treiber) Decoder: LAV DXVA native EVR Custom (nach cinchs Vorlage mit DXVA Scaler): Fenster=> 16-17% GPU Last @350mhz (lt. GPU-Z) Vollbild => 28-29% GPU Last @350mhz MadVR (Deband aus, DXVA Up- und Downscaler, ordered dithering, FSE aus, und die zwei oben genannten Optionen aktiviert): Fenster=> 28-29% GPU Last @350mhz Vollbild=> 73-74% GPU Last @800mhz D.h. der Unterschied wird vor allem im Vollbildmodus größer. Welcher Schritt braucht im Vollbildmodus die Rechenpower? Ich dachte das meiste Processing findet vor dem Scaling statt? Beim testen ist mir auch aufgefallen, dass der Deband-Filter im Vollbildmodus auch deutlich mehr Shader Power benötigt. Wird der auch nach den Resize angewendet? Kann ein Deband-Filter nicht auch vor dem Resize eingesetzt werden (Option? ) P.S. Mir geht es nicht ums Stromzählen, sondern darum die Zusammenhänge zu verstehen. Quote Link to comment
madshi Posted March 30, 2015 Share Posted March 30, 2015 (edited) Debanding findet normalerweise vor dem Scaling statt. Ausnahme ist bei DXVA-Scaling, weil DXVA-Scaling nur mit NV12-Quellen funktioniert, und damit wiederum funktioniert Debanding nicht. Im Vollbild gibt's natürlich mehr zu tun, weil der Scaling-Faktor größer ist, und auch alles weitere Processing dann in der größeren Auflösung gemacht werden muß. Wie ist denn das Device-Setup bei Dir eingerichtet? Auf "disable calibration controls" oder "this display is already calibrated"? Und wie sieht's aus mit der "lose BTB and WTW" Option? Aktiviert oder deaktiviert? Was passiert, wenn Du testhalber mal alle "trade quality" Optionen aktivierst, außer der letzten? Der EVR-Custom deinterlact auch nach 50p, nicht nach 25p, korrekt? Interessant wäre dann auch nochmal der Vergleich zur v0.87.14. Edited March 30, 2015 by madshi Quote Link to comment
Griga Posted March 30, 2015 Share Posted March 30, 2015 Bei mir ist es auch so, dass MadVR vor allem im Full HD-Vollbild meine Graka (ATI Radeon 4300/4500) überfordert. Im Fenster kein Problem, aber alles oberhalb von 576i ruckelt unschön im Vollbild. Die "trade quality for performance settings" ändern daran nichts. Mit CiNcH's Variante des Custom EVR - insbesondere mit DXVA Scaling - läuft das Vollbild in jedem Fall angenehm flüssig. Allerdings ist meine Hardware nicht gerade als Referenz geeignet Quote Link to comment
madshi Posted March 30, 2015 Share Posted March 30, 2015 @Griga, und das ist auch mit der v0.87.15 noch so, selbst mit allen "trade quality" Optionen aktiviert (außer der letzten)? Quote Link to comment
nuts Posted March 30, 2015 Share Posted March 30, 2015 (edited) Mit allen Trade Quality Optionen geht es runter auf 63-64% GPU Last im Vollbild @650mhz. Schaltet man das dithering noch ganz aus geht es noch runter bis 60% @650mhz, aber das ist dann nicht eher nicht mehr zu empfehlen. Bei mir ist für die Tests "disable calibration" aktiviert, da andere Settings auch Rechentakte kostet können. Das mit dem Deband Filter macht dann natürlich auch Sinn. Hat eben alles Vor- und Nachteile mit der DXVA Kette. Vergleich zur 87.14 mach ich dann morgen. P.S. Auch beim EVR Custom gibt der Deinterlacer 50p aus. Darauf habe ich extra geachtet. Edited March 30, 2015 by nuts Quote Link to comment
Griga Posted March 30, 2015 Share Posted March 30, 2015 @Griga, und das ist auch mit der v0.87.15 noch so, selbst mit allen "trade quality" Optionen aktiviert (außer der letzten)? Ja. Die GPU-Last ist zu hoch, und es gibt ständig Dropped Frames: Im Fenstermodus sinkt die GPU-Last auf ca. 40%, und damit läuft es rund. Der Custom EVR á la CiNcH begnügt sich im Vollbild mit 55%, und der Standard EVR sogar mit 45%. Quote Link to comment
CiNcH Posted March 31, 2015 Share Posted March 31, 2015 Ich habe nur mal einen kurzen Blick darauf geworfen. Bei mir ist die GPU-Last auch immer noch deutlich höher als mit EVR, auch mit ausgeschaltetem Dithering. Ein detaillierter Vergleich folgt noch, sobald ich etwas Zeit dafür finde. Wie ich schon bei 720p Material auf 1080p Ausgabe mit den vorigen Versionen festgestellt habe (da werden ja auch Chroma und Luma über DXVA skaliert), habe ich mit der neuen DXVA-Pipeline generell sehr viel mehr "presentation glitches" im Windowed Modus (alle paar Sekunden so 2-3). Mit dem alten madVR hatte ich die bei 1080i auf 1080p kaum. Da wird dann ja nichts über DXVA skaliert, bzw. nur Chroma über die Shader (dafür aber DXVA Deinterlacing)... Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Ja. Die GPU-Last ist zu hoch, und es gibt ständig Dropped Frames: Zwischenablage01.png Im Fenstermodus sinkt die GPU-Last auf ca. 40%, und damit läuft es rund. Der Custom EVR á la CiNcH begnügt sich im Vollbild mit 55%, und der Standard EVR sogar mit 45%. Ach man, Du liegst mit 21ms Rendering-Times nur ganz knapp über dem, was wir bei 720p50 brauchen würden (< 20ms). Etwas komisch ist, daß der Splitter/Decoder bei Dir 25p meldet. Aber das sollte eigentlich keine großen Auswirkungen haben. Du verwendest scheinbar noch den "alten" Windowed-Mode. Kannst Du mal versuchen, in den madVR-Einstellungen bei "rendering -> windowed mode settings" den Haken bei "present several frames in advance" reinzusetzen? Das ist eigentlich der Default-Zustand. Wird aber wahrscheinlich auch nichts helfen. Helfen könnte höchstens der Fullscreen-Exclusive-Mode, aber da läuft es auch nicht flüssig? Ich habe nur mal einen kurzen Blick darauf geworfen. Bei mir ist die GPU-Last auch immer noch deutlich höher als mit EVR, auch mit ausgeschaltetem Dithering. Ein detaillierter Vergleich folgt noch, sobald ich etwas Zeit dafür finde. Wie ich schon bei 720p Material auf 1080p Ausgabe mit den vorigen Versionen festgestellt habe (da werden ja auch Chroma und Luma über DXVA skaliert), habe ich mit der neuen DXVA-Pipeline generell sehr viel mehr "presentation glitches" im Windowed Modus (alle paar Sekunden so 2-3). Mit dem alten madVR hatte ich die bei 1080i auf 1080p kaum. Da wird dann ja nichts über DXVA skaliert, bzw. nur Chroma über die Shader (dafür aber DXVA Deinterlacing)... Das ist natürlich nicht so schön. Sind die Glitches auch visuell sichtbar? Und im FSE-Mode sind die wieder weg, richtig? Generell macht madVR im Moment noch 2 Sachen extra, die Custom-EVR (wahrscheinlich) nicht macht: 1) Das DXVA-Color-Decoding (YCbCr -> RGB) wird rückgängig gemacht und dann entsprechend den madVR-Einstellungen neu durchgeführt. Grund hierfür ist, daß die GPUs nicht immer zuverlässig die richtige Decoding-Matrix wählen (BT.709 vs. BT.601 vs. PAL, demnächst vielleicht noch BT.2020). Außerdem nimmt DXVA gerne mal undefiniert Video- oder PC-Levels, je nach OS, GPU und Treiber-Version. Das macht madVR alles rückgängig, damit auch die Levels wieder stimmen usw. Aber das kostet natürlich Rendering-Zeit, das ganze ist praktisch ein extra Rendering-Pass (unter v0.87.14 noch *zwei* extra Rendering-Passes). Ich *könnte* diesen Rendering-Pass per "trade quality"-Option deaktivierbar machen. Würde das Sinn machen? Die Option würde dann heißen "use DXVA YCbCr -> RGB color version" oder so... 2) Im letzten Schritt wird noch endgültige DXVA-Ausgabe-Ergebnis auf das gewünschte Ausgabe-Rechteck umgemappt, Subtitles drauf gemalt und Dithering gemacht. Das ist auch wieder ein extra Rendering-Pass. Ich könnte eventuell, falls Dithering ausgeschaltet ist, und keine Subtitles gemalt werden müssen, diesen Rendering-Pass komplett weglassen, und DXVA direkt in eine 8bit-Texture rendern lassen. Eigentlich sind beides Aktionen, die nicht sonderlich rechnerisch aufwendig sind. Aber es sind halt trotzdem 2 extra Rendering-Passes, und scheinbar ist das für alte/langsame GPUs immer noch genug Arbeit, um sie bei 50fps in Schwierigkeiten zu bringen... Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 Hier mal Vergleichswerte mit EVR, C_EVR und madVR von mir (Intel HD5500/Broadwell), gemessen mit GPU-Z auf FullHD Display und LAV 0.64.0.33-git EVR: Mpeg2 576i -> 21% GPU bei DXVA-Native und 22% GPU bei Intel QuickSync Memory Dedicated -> 30MB bei DXVA-Native und 20MB bei Intel QuickSync Memory Dynamic -> 176MB bei DXVA-Native und 185MB bei Intel QuickSync H264 1080i -> 26% GPU bei DXVA-Native und 30% GPU bei Intel QuickSync Memory Dedicated -> 64MB bei DXVA-Native und 64MB bei Intel QuickSync Memory Dynamic -> 223MB bei DXVA-Native und 221MB bei Intel QuickSync C_EVR mit DXVA Scaling: Mpeg2 576i -> 18% GPU bei DXVA-Native und 20% GPU bei Intel QuickSync Memory Dedicated -> 30MB bei DXVA-Native und 27MB bei Intel QuickSync Memory Dynamic -> 168MB bei DXVA-Native und 177MB bei Intel QuickSync H264 1080i -> 16% GPU bei DXVA-Native und 23% GPU bei Intel QuickSync Memory Dedicated -> 64MB bei DXVA-Native und 64MB bei Intel QuickSync Memory Dynamic -> 208MB bei DXVA-Native und 212MB bei Intel QuickSync madVR mit unten genannten Einstellungen: Mpeg2 576i -> 30% GPU bei DXVA-Native und 31% GPU bei Intel QuickSync Memory Dedicated -> 46MB bei DXVA-Native und 29MB bei Intel QuickSync Memory Dynamic -> 184MB bei DXVA-Native und 182MB bei Intel QuickSync H264 1080i -> 33% GPU bei DXVA-Native und 30% GPU bei Intel QuickSync Memory Dedicated -> 64MB bei DXVA-Native und 64MB bei Intel QuickSync Memory Dynamic -> 246MB bei DXVA-Native und 231MB bei Intel QuickSync Einstellungen in madVR für geringste GPU-Last: Chroma upscaling = Nearest Neighbor image up-/downscaling = DXVA2 CPU & GPU queue size = 4 windowed mode settings = kein Haken bei "present several frames in advance" und 1 bei "backbuffers" smooth motion = off dithering = none trade quality for performance, Haken bei: use DXVA chroma upscaling when doing native DXVA decoding lose BTB and WTW if it improves performance don't analyze gradient angles for debanding use 10bit image buffer instead of 16bit Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Danke, das ist interessant! Kannst Du vielleicht noch Werte für madVR v0.87.14 dazu fügen? Nur um mal zu sehen, inwieweit v0.87.15 überhaupt einen Fortschritt darstellt? Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 windowed mode settings = kein Haken bei "present several frames in advance" und 1 bei "backbuffers"Hm auf meinem AMD System ist das eher kontraproduktiv (im Vergleich zu Haken bei "present several frames in advance" gesetzt mit 8 frames "in advance"). Zumindest was die Renderer Statistik angeht, GPU Last ist quasi unverändert. Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 Ja aber erst viel später. Habe oben noch den angezeigten Speicherverbrauch zugefügt. Wenn ich dann die Werte mit der 14er habe poste ich die sicher eher als Vergleichstabelle, sonst wird das zu unübersichtlich. Auf AMD habe ich noch nicht getestet und gerade für die Lastmessungen habe ich keine Statistik anzeigen lassen! Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 (edited) Also ich hab auch was interessantes. Die Einstellung GPU Queue hat bei mir massiv Einfluss auf die Statistik "deinterlace & scale". D.h. je größer die Queue je länger dauert deinterlace & scale? Ist das bei euch auch so? Edited March 31, 2015 by nuts Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Komisch, sollte so eigentlich nicht sein. Das kann eventuell aber auch ein Fehler in der Messung sein. Oder spiegelt sich das in der GPU-Last wieder? Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Schwierig zu sagen, da mein AMD Arbeitslaptop leider keine vernünftige Werte für die GPU-Last anzeigt. Der hat eine AMD APU und eine extra AMD GPU (so ein hybrid Dings ). Damit ist es mit madVR eh etwas schwierig, da nur die onboard GPU verwendet wird? Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Hybrid-Dings sind immer schwer zu durchschauen... Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 Manchmal hilft ein Gegentest mit dem Afterburner, natürlich nicht bei der Statistik. Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Bin in der Mittagspause mal schnell zum HTPC (gerade Intel HD4000) gehuscht. Auch hier kann ich die Unterschiede in der Statistik deutlich sehen. Die GPU Last erhöht sich durch vergößern der GPU-Queue jedoch nur geringfügig. Spricht etwas für einen Fehler in der Messung? Quote Link to comment
Tüftler Posted March 31, 2015 Share Posted March 31, 2015 Bei bestimmten Einstellungen muss ich einen Wiedergabe Neuaufbau des Graphen machen um verlässliche Messungen zur Last zu bekommen. Quote Link to comment
Griga Posted March 31, 2015 Share Posted March 31, 2015 Du verwendest scheinbar noch den "alten" Windowed-Mode. Kannst Du mal versuchen, in den madVR-Einstellungen bei "rendering -> windowed mode settings" den Haken bei "present several frames in advance" reinzusetzen? Das ist eigentlich der Default-Zustand. Der Haken war und ist gesetzt. Helfen könnte höchstens der Fullscreen-Exclusive-Mode, aber da läuft es auch nicht flüssig? Etwas besser vielleicht, aber nicht wirklich glatt. Wenn ich vom Vollbild in den Fenstermodus zurückkehre, ist der DVBViewer nicht mehr ansprechbar und muss mit dem Taskmanager beendet werden. Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 (edited) Ja, manche Änderungen werden erst von der nächsten madVR-"Instanz" berücksichtigt. Geht nicht anders. Wird bald eine v0.87.16 geben, mit ein paar weiteren DXVA-Performance-Improvements. Edit: @Griga, komisch, Dein OSD sagt, der "neue" Windowed Mode ist nicht aktiv. Wird wahrscheinlich einen guten Grund haben, weiß aber gerade auch nicht welchen... Edited March 31, 2015 by madshi Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Naja wenn du schon grad da bist ... Kann man das Debug OSD per API an- und ausschalten? Falls nein: könnte man das nachrüsten? Hintergrund: Es gibt im (internen) DVBViewer eine neue Action-ID um das Debug-OSD von cinchs EVR Custom aufzurufen und ich fänd es sinnvoll diese Funktion auf das Debug OSD von madVR zu erweitern. Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Uhm, ist im Moment nicht per API möglich, kann ich aber einbauen. Quote Link to comment
nuts Posted March 31, 2015 Share Posted March 31, 2015 Gut zu wissen. Ich fänds sinnvoll. Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Ist schon in meinen Quellen drin. Wird in der nächsten Build gehen über "IMadVRSettings.SettingsSetBoolean("DebugOsd", true/false)". Hab's allerdings "blind" eingebaut, weil ich gerade nichts zum Testen zur Hand hatte... Quote Link to comment
Griga Posted March 31, 2015 Share Posted March 31, 2015 So richtig? function TRenderer.ToggleMadVROSD: HRESULT;const IID_IMadVRSettings: TGUID = '{6F8A566C-4E19-439E-8F07-20E46ED06DEE}';var MadVRSettings: IMadVRSettings; CurrentState: BOOL;begin result := E_FAIL; if assigned(FVideoRenderer) then begin result := FVideoRenderer.QueryInterface(IID_IMadVRSettings, MadVRSettings); if SUCCEEDED(result) then if MadVRSettings.SettingsGetBoolean('DebugOsd',CurrentState) then MadVRSettings.SettingsSetBoolean('DebugOsd',not CurrentState); end;end; Ich finde in mvrInterfaces.pas keine Angabe dazu, was der BOOL-Rückgabewert der Getter/Setter bedeutet. Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Jau, sieht gut aus so. Der Rückgabewert heißt einfach, ob's geklappt hat oder nicht. Wenn der Wert nicht gefunden wurde, oder wenn der geschriebene Wert nicht zulässig ist, wird "FALSE" zurück gegeben. Bei Booleans gibt's eigentlich keine ungültigen Werte. Von daher heißt Rückgabewert "FALSE" normalerweise "Wert nicht gefunden". v0.87.15 sollte für "DebugOsd" FALSE zurückgeben, mit der heute noch kommenden v0.87.16 dann hoffentlich TRUE. 1 Quote Link to comment
madshi Posted March 31, 2015 Share Posted March 31, 2015 Ok, neue Build released: http://madshi.net/madVR.zip (v0.87.16) Diese Build sollte nochmal etwas schneller geworden sein in Sachen DXVA-Behandlung (bei gleichen Optionen). Zusätzlich habe ich eine weitere "trade quality for performance" Option eingebaut mit dem Namen: "trust DXVA color & levels conversion". Ich empfehle, diese Option *nicht* zu verwenden. Aber sie bringt halt auch wieder etwas extra Performance - vor allem wenn man zusätzlich noch Dithering deaktiviert. Wenn man das alles macht, sollte v0.87.16 jetzt von der Performance her recht nahe an den EVR-Custom heranrücken. Mag das jemand mal testen? Also für Turbo-Performance: - Mit Default-Einstellungen starten - DXVA Scaling aktivieren für "image upscaling" und "image downscaling" - trade quality "trust DXVA color & levels conversion" Option aktivieren - Dithering ausschalten Ein sinniger Kompromiß zwischen Bildqualität und Performance sollte dieser sein: - Mit Default-Einstellungen starten - DXVA Scaling aktivieren für "image upscaling" und "image downscaling" Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.