Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Ja, stimmt schon. Ein "Schnellschuss" bringt natürlich auch niemandem was.

Aber wie schon von dir angemerkt. Ungeduld, mit einem kleinen Schuss Langeweile. :rolleyes:

Link to post
  • 2 weeks later...
  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

  • madshi

    283

  • nuts

    184

  • CiNcH

    145

  • craig_s

    143

Top Posters In This Topic

Popular Posts

Bei mir hat der Download geklappt. Vielleicht überhitzt dabei eine Komponente deines Rechners, oder der Stromverbrauch für den Download ist zu hoch.   Sorry, konnte wieder mal nicht anders

Hallo,   derzeit teste ich mit MPlayerHC einen neuen Renderer, das gute Teil nennt sich MadVR, mehr Infos dazu bekommt ihr hier: http://forum.doom9.org/showthread.php?t=146228   Ich bin bisher vo

Sollte man nicht besser diesen thread teilen? Ich wäre für einen inhaltlichen teil und einen für allgemeine meinungsäusserungen. Ich würde wenn überhaupt selbst wahrscheinlich nur im 2.thread schreibe

Posted Images

goldfield

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

Link to post

Im Prinzip entspricht das erste Beispiel im Link deinen Anforderungen.

Es wird eben zusätzlich noch auf die fps (24p, 60p usw.) eingegangen.

Link to post

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?

Link to post
  • 2 weeks later...

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

Link to post

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.

Link to post

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

Link to post

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.

Link to post

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"

Link to post

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.

Link to post

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

Link to post

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 by madshi
Link to post

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 ;)

Link to post

@Griga, und das ist auch mit der v0.87.15 noch so, selbst mit allen "trade quality" Optionen aktiviert (außer der letzten)?

Link to post

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 by nuts
Link to post
@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:

 

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

Link to post

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

Link to post

 

Ja. Die GPU-Last ist zu hoch, und es gibt ständig Dropped Frames:

 

attachicon.gifZwischenablage01.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... :shocked:

Link to post

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
Link to post

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?

Link to post

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.

Link to post

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!

Link to post

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 by nuts
Link to post

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?

Link to post

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?

Link to post

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?

Link to post

Bei bestimmten Einstellungen muss ich einen Wiedergabe Neuaufbau des Graphen machen um verlässliche Messungen zur Last zu bekommen.

Link to post
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.

Link to post

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 by madshi
Link to post

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.

Link to post

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

Link to post

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.

Link to post

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.

  • Like 1
Link to post

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"

Link to post

Join the conversation

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

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