Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Chroma upscaling muß gemacht werden, sonst kann man das Video gar nicht nach RGB umwandeln. Von daher kann ich Chroma upscaling nicht einfach ausschalten. Ich könnte es höchstens in "Nearest Neighbor" machen, aber auch das fällt theoretisch unter "Upscaling", wenn auch in der übelsten Qualität. Jedenfalls hab ich keine Möglichkeit, bei DXVA Chroma Upscaling von der YCbCr -> RGB Umwandlung zu trennen.

Link to comment

Chroma > DXVA bedeutet, dass ein Chroma Upscaling über DXVA stattfindet.

Das ist so:

 

Wird Luma Scaling (Bildgrösse) benötigt, wird bei aktivierten DXVA Scaler auch immer das Chroma Scaling darüber gemacht.

Imho ist das auch sinnvoll!

Ohne Luma Scaling (Quelle=Ziel) kannst du das DXVA Chroma Scaling über die "Trade" Optionen abschalten. Dann wird die unter Chroma Upscaling hinterlegte Methode verwendet.

 

 

P.S. OSD desktivieren hilft nicht.

Edited by nuts
Link to comment

Da scheint jemand ein "TTranspPanel" zu malen, und zwar über das madVR-Rendering-Window.

 

 

TTransPanel enthält das OSD. Das Panel muss immer sichtbar werden, wenn kein OSD über den Video Renderer ausgegeben werden kann, also wenn kein Video läuft oder sich der Graph im Stop- oder Pause-Zustand befindet (Ausnahme: Custom EVR - hier ist kein instantiierter / laufender Video Renderer erforderlich, da der DVBViewer das OSD direkt via D3D ausgibt).

 

Der Code ist extrem verzweigt (und stammt nicht von mir). Ob es sich hier um ein vermeidbares "OSDPanel.Visible := true" handelt oder nicht, könnte ich nur mit ausgedehnten Recherchen ermitteln, für die mir die Zeit fehlt.

 

(Edit: Komisch, das "[ code ]" scheint hier im Forum nicht ordentlich zu klappen.)

 

Geht hier nicht. Markiere einfach den betreffenden Abschnitt und setze den Font auf Courier New. Einrückungen bleiben erhalten.

Link to comment

I'm sorry but my german is not that great. I have been trying to read from page 15-25 to find how I can activate the useage of madvr in DVBViewer but I cant seem to find how..

 

Can someone please elaborate? tnx!

Link to comment

Hab mal ein bißchen in Sachen Performance recherchiert. Bei mir mit der Intel HD4000 sieht es im Fullscreen bei einem 25p SD Testfile (bei "trust DXVA" und ausgeschaltetem Dithering) so aus, daß der EVR 10% GPU-Leistung braucht und madVR 24%. Jetzt läuft mein Display aber auf 60Hz. Bei "present several frames in advance" heißt das, daß madVR für jeden VSync ein Bild präsentieren muß, damit die ganze Logik funktioniert. Das bedeutet eine Menge an extra Frame-Kopien, die madVR machen muß. Wenn ich das "present several frames in advance" abschalte, reduziert sich der GPU-Verbrauch von 24% auf 16%.

 

Dann hab ich herausgefunden, daß das DVBViewer OSD knapp 2% GPU-Performance kostet, selbst wenn gar kein OSD sichtbar ist. Vielleicht ließe sich das fixen? Außerdem scheint jedes StretchRect (jede Frame-Kopie) etwa 2% Performance zu kosten. Ich vermute, daß der EVR direkt auf den Backbuffer malt. madVR hat aber eine getrennte Frame-Queue. Das heißt, madVR muß pro Frame mindestens ein StretchRect extra machen. Im Moment sind's sogar zwei. Wenn ich das OSD in madVR gewaltsam abschalte und ein StretchRect deaktiviere, komme ich auf ca. 12% GPU. Die extra 2%, die madVR dann noch mehr verbraucht, kommen halt dadurch zustande, daß madVR die Frames erstmal in die interne Frame-Queue kopiert und erst später in die Backbuffer. Der Mehrverbrauch an GPU-Leistung in madVR läßt sich insgesamt also halbwegs sinnig erklären.

 

Wenn das Display eine höhere Framerate hat als das Video, dann läßt sich GPU-Leistung sparen, indem man die "present several frames in advance" Option abschaltet. Empfehlen würde ich das nicht unbedingt. Viel besser wäre es, das Display auf eine Refreshrate zu setzen, die dem Videofile entspricht (also z.B. 23.976Hz bei Blu-Ray Wiedergabe). Wenn das Display das nicht kann, dann würde ich Smooth Motion FRC empfehlen, und dann geht natürlich der GPU-Verbrauch entsprechend rauf. Wer Smooth Motion FRC nicht mag, und trotzdem eine höhere RefreshRate hat als das Videofile, kann natürlich mal versuchen, "present several frames in advance" abzuschalten - aber das ist eigentlich die schlechtere Variante, weil es dann recht schnell mal kleine Ruckler geben kann, wenn der PC gerade arg beschäftigt ist.

 

Langfristig wird madVR einen D3D11-Ausgabe-Modus bekommen, bei dem das "present several frames in advance"-Feature auch funktionieren wird, ohne daß so viele extra Frame-Kopien gemacht werden müssen.

Link to comment

Hast du den GPU-Takt auch berücksichtigt? 30% bei 650 MHz ist was anderes wie 30% bei 900 MHz. Ich schau mir für Vergleiche gerne die Leistungsaufnahme (mit GPU-Z) an.

 

Ich schau mir nochmal "present several frames in advance" an. Bei mir hatte das keinen Einfluss.

Link to comment

Dass erklärt bei mir warum das Abschalten von "present several frames in advance" GPU-Leistung spart. Die Broadwell Intel läuft im Lappi und das Display kann nur 60Hz.

Zum Gegentest könnte ich über HDMI mal an den großen TFT gehen.

Zumindest hat ein Test auf AMD gezeigt dass es dort keine GPU-Leistung spart (läuft bei 50Hz am TFT).

 

Zu den "Leistungen bei unterschiedlicher Taktfrequenz" habe ich das Energieprofil bei Messungen generell auf maximale Performance gestellt (900Mhz).

Link to comment

Nochmal getestet...

 

1080i bei 1080p im Windowed Vollbild.

 

present several frames in advance: an (Default 8 Backbuffer)

74% @ 750MHz (7.4W)

 

present several frames in advance: aus (Default 3 Backbuffer)

74% @ 750MHz (7.4W)

 

Ich kann da nicht den geringsten Unterschied erkennen. Backbuffer Count von 3 habe ich über das Debug OSD verifiziert. Die Option wurde also übernommen.

Link to comment

Bei meinen Tests passt Quelle immer zu Ausgabefrequenz.

Einen großen Effekt durch "present several Frames in advanced" an/aus konnte ich auch nicht feststellen, was zur Erklärung passt.

Link to comment

 

Bei meinen Tests passt Quelle immer zu Ausgabefrequenz.

Einen großen Effekt durch "present several Frames in advanced" an/aus konnte ich auch nicht feststellen, was zur Erklärung passt.

 

Stimmt. Das ist bei mir auch immer der Fall. Da habe ich zu ungenau gelesen. Sorry.

 

Bei mir verbrät madVR mehr als doppelt so viel Leistung wie EVR. Das spiegelt sich auch in der GPU Taktung, Last und Temperatur wieder.

Link to comment

Bei mir auch und da wir jetzt (intern zumindest :P) ja auch einen eigene sparsame und brauchbare DXVA Kette im DVBViewer haben, habe ich auch auf die Renderer Umschaltung gedrängt (die funktioniert jetzt auch einwandfrei per Video A/B ;) )

Damit kann man dann entspannt die Nachrichten mit DXVA gucken und für den Filmabend auf madVR switchen und alle Möglichkeiten nutzen. ;)

 

Ich hab noch ein anderes Thema:

Und zwar wird gerade ein Delay im Zusammenhang mit dem OSD @doom9 diskutiert.

Ich meine das im DVBViewer auch schon gesehen zu haben.

Muss aber noch analysieren wie sich das mit unterschiedlichen Puffergrössen verhält.

Wie ist das bei euch?

Ist eher minimal bei mir und fällt vorallem bei der Bedienung über die Fernbedienung auf, da die Steuerung wohl etwas anfälliger für solche Delays ist.

 

 

@madshi: Welche Testversion des DVBViewer hast du eigentlich?

Edited by nuts
Link to comment

Mein Eindruck ist, daß die GPU-Frequenz nicht viel zu sagen hat. Die GPU-Prozentzahl ist sehr regelmäßig/zuverlässig, auch die Watt-Zahl, aber die Frequenz springt oft mal zwischen 350MHz und 1150MHz hin und her, ohne daß sich dabei die GPU-Prozentzahl und die Wattzahl ändert (was nicht so viel Sinn macht). Beispiel aus dem GPU-Z Log bei mir vom EVR:

 

Date , GPU Core Clock [MHz] , GPU Memory Clock [MHz] , GPU Power [W] , GPU Load [%]
2015-04-06 12:44:35 , 350.0 , 666.7 , 1.2 , 15
2015-04-06 12:44:36 , 1150.0 , 666.7 , 1.1 , 15
Bei 350MHz und 15% sind es 1.2W. Und bei 1150MHz und 15% sind es 1.1W? Ich denke, da kann man gut sehen, daß man die GPU Core Clock komplett ignorieren kann. Brauchbare Vergleichszahlen sollten aber GPU Load und GPU Power sein. Wobei wahrscheinlich eine von beiden reicht, weil die scheinbar mehr oder weniger linear miteinander verknüpft sind.
Ok, hab mal einen Vergleichstest mit einem 720p50 Video gemacht, auf meinem 60Hz Display, mit deaktiviertem "present several frames in advance":
EVR: 23%, 2.2W
madVR: 36%, 3.4W
madVR mit zwangsweise deaktiviertem DVBViewer-OSD: 30%, 2.9W
madVR mit zwangsweise deaktiviertem DVBViewer-OSD und einem StretchRect pro Frame weniger: 25.5%, 2.55W
Edit: Meine DVBViewer-Testversion ist schon etwas älter, aber das sollte ja eigentlich keinen großen Unterschied machen?
Edited by madshi
Link to comment

GPU Power ist sicher ein errechneter Wert.

Der stimmt bestimmt nicht ...

 

P.S. Ich frag mal ob du nicht einen aktuelle kriegen kannst ... es hat sich noch soviel geändert in den letzten Versionen.

Link to comment

Danke! :original:

 

Ergebnisse mit der neuen Build sind mehr oder weniger identisch:

 

EVR: 23%, 2.4W
madVR: 37%, 3.5W
madVR mit zwangsweise deaktiviertem DVBViewer-OSD: 31%, 3.0W
madVR mit zwangsweise deaktiviertem DVBViewer-OSD und einem StretchRect pro Frame weniger: 27%, 2.6W
Link to comment

Ich hab noch ein anderes Thema:

Und zwar wird gerade ein Delay im Zusammenhang mit dem OSD @doom9 diskutiert.

Ich meine das im DVBViewer auch schon gesehen zu haben.

Muss aber noch analysieren wie sich das mit unterschiedlichen Puffergrössen verhält.

Wie ist das bei euch?

Ist eher minimal bei mir und fällt vorallem bei der Bedienung über die Fernbedienung auf, da die Steuerung wohl etwas anfälliger für solche Delays ist.

Welchen Skin nutzt du denn? Ein Vergleich bringt nur was wenn wir den Gleichen nutzen.

Link to comment

Zumindest ein Skin der Plugins nutzt (BluFuzz etc.) wird sich anders verhalten, und eine aktive HbbTV-Engine könnte auch was ausmachen

Link to comment

Die äußeren Einflüsse sollte man besser erstmal eliminieren.

 

@doom9 geht es um den Potplayer und Kodi mit DSPlayer.

Soweit ich die Diskussion dort verstanden habe, funktioniert das OSD im DVBViewer mit madVR aber ähnlich.

Link to comment

Ok, hab eine Möglichkeit gefunden, bei "trust DXVA" und deaktiviertem Dithering noch ein StretchRect einzusparen. Ergebnisse mit der neusten DVBViewer-Build auf meinem PC:

 

Intel HD4000

1680x1050 60Hz

720p50 Content

spezielle madVR-Einstellungen (kein "present in advance", kein dithering, mit "trust DXVA")

 

madVR im Fenster: 15%

madVR Fullscreen: 28%

EVR im Fenster: 16%

EVR Fullscreen: 22%

EVR-Custom im Fenster: 14%

EVR-Custom Fullscreen: 18%

madVR mit zwangsweise deaktiviertem OSD im Fenster: 13%

madVR mit zwangsweise deaktiviertem OSD Fullscreen: 22%

 

Wäre noch die Frage, ob der DVBViewer nicht das OSD-Rendering überspringen könnte, wenn das OSD eh "leer" ist? Würde zumindest bei madVR helfen. Vielleicht beim EVR auch?

Link to comment

Ich hab hier nochmals ein Problem mit fehlerhaftem Deinterlacing, allerdings nur mit AMD und Nvidia (nicht Intel!)

Diesmal habe ich darauf geachtet das alles über DXVA läuft.

Quelle: Slicies.ts 1080i 25fps -> auf Ziel: 1080p 50fps, Decoder LAV dxva2n, ob exclusive oder windowed Mode ist egal

Im Anhang mal ein logfile

 

Link to comment

Genauso ist es. Mit EVR oder Custom EVR gibt es keine Probleme und laut OSD ist Deinterlacing auch aktiv.

-> Hier findest du die Testdatei/en (MPEG2 PAL 1080i)

Link to comment

Das Deinterlacing findet nicht statt. Oben habe ich einen Link zum File gepostet.

Es spielt dabei keine Rolle ob es sich um MPEG oder H264 handelt!

 

Edit: Hab ich noch vergessen zu erwähnen, wenn die Zielauflösung der Anzeige unter der der Quellauflösung liegt klappt das Deinterlacing (bspw. im Fenstermodus statt Vollbild)!

Link to comment

Komisch, kann hier mit AMD keine Probleme nachstellen. Vielleicht tritt das nur unter bestimmten Bedingungen oder mit bestimmten Einstellungen auf?

Link to comment

Wäre noch die Frage, ob der DVBViewer nicht das OSD-Rendering überspringen könnte, wenn das OSD eh "leer" ist? Würde zumindest bei madVR helfen. Vielleicht beim EVR auch?

 

Eine berechtigte Frage :)

 

Ich habe mir den betreffenden Code mal angeschaut. MadVR wird tatsächlich via IMadVROsdService.OsdSetBitmap bei unsichtbarem OSD eine "leere" Bitmap zugeschoben, also keine NULL HBITMAP. Vielleicht hat Christian diese Möglichkeit übersehen. Bei den anderen OSD-Schienen wird dagegen eine leere Bitmap speziell behandelt, also z.B. die dazugehörige Texture deaktiviert (Custom EVR).

 

Ich habe das jetzt geändert und kann nun tatsächlich mit meiner altersschwachen Graka und MadVR .17 ein exklusives 720p-Vollbild ohne dropped frames betrachten (solange ich kein OSD einblende). Ohne obige Maßnahme klappt das nicht bzw. nur, wenn ich per Tweak das OSD generell deaktiviere.

Link to comment

Ich kann das auf 2 Rechnern reproduzieren

Also ich kanns ehrlich gesagt auch nicht reproduzieren. :(

Wie sind deine Settings jetzt genau?

 

Und ... danke Griga. ;)

Link to comment

Ich habe mir den betreffenden Code mal angeschaut. MadVR wird tatsächlich via IMadVROsdService.OsdSetBitmap bei unsichtbarem OSD eine "leere" Bitmap zugeschoben, also keine NULL HBITMAP. Vielleicht hat Christian diese Möglichkeit übersehen. Bei den anderen OSD-Schienen wird dagegen eine leere Bitmap speziell behandelt, also z.B. die dazugehörige Texture deaktiviert (Custom EVR).

 

Ja, ich kann mich auch nicht mehr erinnern, warum ausgerechnet eine leere Bitmap geschickt wird. Ich glaube ich habe den Code von unserem OSD Filter adaptiert und die Variante schlichtweg übersehen.

Link to comment

Deaktiviere mal "disable Auto Source detection" und wähle dafür "if in doubt activate Deinterlacing".

Edited by nuts
Link to comment

Danke bringt aber nix. Ich habe eigentlich schon mit allen erdenklichen Optionen rumgespielt, hilft nur nicht.

Ich schau mir das zum Vergleich jetzt mal mit dem MPC an.

Link to comment

Nö, geht auch nicht.

Wenn ich jetzt noch irgendwie der Nvidia Karte beibringen könnte bevorzugt mit dem MPC zu werkeln statt der Intel GPU dann könnte ich das testen :mad:

Link to comment

Das Deinterlacing findet nicht statt. Oben habe ich einen Link zum File gepostet.

Es spielt dabei keine Rolle ob es sich um MPEG oder H264 handelt!

 

Edit: Hab ich noch vergessen zu erwähnen, wenn die Zielauflösung der Anzeige unter der der Quellauflösung liegt klappt das Deinterlacing (bspw. im Fenstermodus statt Vollbild)!

 

 

Komisch, kann hier mit AMD keine Probleme nachstellen. Vielleicht tritt das nur unter bestimmten Bedingungen oder mit bestimmten Einstellungen auf?

 

Hallo madshi, du erwähntest ein paar Posts weiter vorne dass du mit folgender Auflösung ausgibst: 1680x1050 60Hz

Damit bist du doch unter der 1080i Auflösung und kannst die Deinterlacing Probleme nicht haben wie Tüftler erwähnte.

Nur für Euch also Info damit es nicht unter geht.

Edited by azeman
Link to comment

Guter Hinweis von @azeman.

Hab das mit dem MPC-HC jetzt hinbekommen und habe dort das gleiche Verhalten mit madVR, EVR ist dagegen sauber.

Ich bin jetzt mal bis zur Version 08711 zurückgegangen aber es gibt keinerlei Änderung im Verhalten.

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