madshi Posted April 4, 2015 Share Posted April 4, 2015 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. Quote Link to comment
nuts Posted April 4, 2015 Share Posted April 4, 2015 (edited) 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 April 4, 2015 by nuts Quote Link to comment
Tüftler Posted April 4, 2015 Share Posted April 4, 2015 Danke euch, jetzt sind mir die Zusammenhänge klarer und im OSD ist das auch nachvollziehbar Quote Link to comment
Griga Posted April 5, 2015 Share Posted April 5, 2015 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. Quote Link to comment
bccrew Posted April 5, 2015 Share Posted April 5, 2015 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! Quote Link to comment
blasgl Posted April 5, 2015 Share Posted April 5, 2015 simple, wait some weeks until it´s released, at least as a public beta Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
CiNcH Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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). Quote Link to comment
CiNcH Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
CiNcH Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 (edited) Bei mir auch und da wir jetzt (intern zumindest ) 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 April 6, 2015 by nuts Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 (edited) 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 April 6, 2015 by madshi Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
hackbart Posted April 6, 2015 Share Posted April 6, 2015 @Madshi: Ich schick dir gleich eine neue Build zu. Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 Danke! 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 Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 Auch interessant. Also selbst ein nicht aktives OSD verbrät soviel GPU Last? Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 Den Default Skin, aber der Skin könnte natürlich auch etwas ausmachen. Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 Zumindest ein Skin der Plugins nutzt (BluFuzz etc.) wird sich anders verhalten, und eine aktive HbbTV-Engine könnte auch was ausmachen Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 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? Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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 Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 Was für'n Problem hast Du denn genau? Ist Deinterlacing laut madVR OSD aktiv? Und das tritt nur bei madVR auf? Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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) Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 Ja, aber was für ein Problem hast Du genau? Explodiert Dein Computer? Oder was anderes? Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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)! Quote Link to comment
madshi Posted April 6, 2015 Share Posted April 6, 2015 Komisch, kann hier mit AMD keine Probleme nachstellen. Vielleicht tritt das nur unter bestimmten Bedingungen oder mit bestimmten Einstellungen auf? Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 Hilft dir das log dabei nicht? Ich kann das auf 2 Rechnern reproduzieren Vollbild Fenstermodus Quote Link to comment
Griga Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 Ich kann das auf 2 Rechnern reproduzierenAlso ich kanns ehrlich gesagt auch nicht reproduzieren. Wie sind deine Settings jetzt genau? Und ... danke Griga. Quote Link to comment
hackbart Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 Hier mal meine Settings: Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 (edited) Deaktiviere mal "disable Auto Source detection" und wähle dafür "if in doubt activate Deinterlacing". Edited April 6, 2015 by nuts Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment
nuts Posted April 6, 2015 Share Posted April 6, 2015 Auch im LAV? Dort könntest du noch die Einstellung "aggressive" beim Deinterlacing versuchen (in madVR wie empfohlen lassen). Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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 Quote Link to comment
azeman Posted April 6, 2015 Share Posted April 6, 2015 (edited) 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 April 6, 2015 by azeman Quote Link to comment
Tüftler Posted April 6, 2015 Share Posted April 6, 2015 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. 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.