Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Mit der .18 hat sich performancemäßig was getan. Bei mir gibt es jetzt im nicht-exklusiven 720p-Vollbild drastisch weniger dropped frames. Zeitweise nur alle paar Sekunden eins, zeitweise etwas mehr. Die GPU-Last ist im Vergleich zu vorherigen Versionen um mehr als 10% gesunken, liegt aber immer noch deutlich über der von Standard und Custom EVR.

 

Die GPU-Last sinkt noch ein paar weitere Prozent, wenn ich im LAV Decoder DXVA (für H.264-Dekodierung) abschalte. Dafür muss die CPU schuften: An die 50% mit einem älteren Dual Core. Erstaunlicherweise lässt MadVR dann wieder deutlich mehr Frames aus :blink: Bei nur noch 70% GPU-Last hatte ich erwartet, dass es keine mehr sind. Die CPU-Last spielt offenbar auch eine Rolle.

 

Die Trust DXVA... Einstellung (ein) erhöht die dropped frames ebenfalls wieder.

Link to comment
Bei nur noch 70% GPU-Last hatte ich erwartet, dass es keine mehr sind. Die CPU-Last spielt offenbar auch eine Rolle.

 

 

Die "dropped frames" müssen nicht unbedingt nur mit der GPU-Last zusammenhängen.

Ich hatte damals im MPC trotz mäßiger GPU-Last trotzdem noch Probleme mit "dropped frames",

was sich zuerst niemand erklären konnte.

Madshi kam dann irgendwann auf die Idee, das im Audiozweig evt. zu viel Jitter entsteht,

und mir den testweisen Einsatz von Reclock empfohlen.

Damit waren die "dropped frames" dann tatsächlich erledigt.

Vielleicht wäre das ja mal einen Test wert. Sei es nur, um das ggf. als Grund auszuschließen.

Edited by goldfield
Link to comment

Denk bei Griga sind das dann eher CPU Peaks? Bei 50% und DualCore ist immer schon ein bisschen verdächtig (je nach Anzeige und Software ist das schon zu viel für Echtzeit Zeugs).

Könnte man mal mit dem Software Decoder und dem EVR Custom gegenchecken.

Link to comment
Die "dropped frames" müssen nicht unbedingt nur mit der GPU-Last zusammenhängen.

 

Wenn es eine last-unabhängige Ursache gäbe, hätte ich die dropped frames auch im Fenstermodus bzw. bei kleinerem Bild.

 

Denk bei Griga sind das dann eher CPU Peaks? Bei 50% und DualCore ist immer schon ein bisschen verdächtig. Könnte man mal mit dem Software Decoder und dem EVR Custom gegenchecken.

 

Der Witz ist, dass es Fälle gibt, in denen es sich mit dem Custom EVR genau andersherum verhält.

 

Das berüchtigte Chile-Sample (Full HD 30 fps, aus denen LAV 60 fps macht) bewirkt, dass sich der LAV Decoder und der Renderer um GPU-Leistung balgen. LAV kann sich nicht durchsetzen, gerät mit der Dekodierung in Verzug -> dropped frames, oder, falls der Renderer verspätete Frames nicht fallen lässt, werden Video und Audio asynchron (Video hinkt hinterher).

 

Wenn ich jedoch DXVA im LAV Decoder abschalte - also quasi Load Balancing zwischen GPU und CPU betreibe - läuft die Sache rund! Deshalb hatte ich erwartet, dass dies bei MadVR auch wirkt. Da geht der Schuss jedoch nach hinten los ;)

Link to comment

So, habe hier jetzt alles getestet nur das debug.log will nicht, da kommt madVR.ax nicht gefunden (habe die madVR v0.87.17c und ich denke da fehlt die passende debug.ax?)

madVR Vollbild

attachicon.gifmadVR.jpg

madVR Fenstermodus

attachicon.gifmadVR_window.jpg

EVR Vollbild

attachicon.gifEVR.jpg

Custom EVR Vollbild

attachicon.gifC_EVR.jpg

 

Sehr merkwürdig. Da hab ich im Moment keine Erklärung für. Auf meiner NVidia kann ich das Problem nicht reproduzieren. Hmmmm... Ist in Deinem madVR-Ordner eine "settings.bin"-Datei (nur falls madVR Schreibzugriff drauf hat)? Wenn ja, kannst Du mir die mal hochladen? Falls nein, kannst Du mir mal "HKCU\Software\madshi\madVR\Settings" exportieren? Vielleicht krieg ich das Problem ja mit Deinen madVR-Einstellungen reproduziert?

 

Welches OS benutzt Du nochmal?

 

 

Mit der .18 hat sich performancemäßig was getan. Bei mir gibt es jetzt im nicht-exklusiven 720p-Vollbild drastisch weniger dropped frames. Zeitweise nur alle paar Sekunden eins, zeitweise etwas mehr. Die GPU-Last ist im Vergleich zu vorherigen Versionen um mehr als 10% gesunken, liegt aber immer noch deutlich über der von Standard und Custom EVR.

 

Die GPU-Last sinkt noch ein paar weitere Prozent, wenn ich im LAV Decoder DXVA (für H.264-Dekodierung) abschalte. Dafür muss die CPU schuften: An die 50% mit einem älteren Dual Core. Erstaunlicherweise lässt MadVR dann wieder deutlich mehr Frames aus :blink: Bei nur noch 70% GPU-Last hatte ich erwartet, dass es keine mehr sind. Die CPU-Last spielt offenbar auch eine Rolle.

 

Die Trust DXVA... Einstellung (ein) erhöht die dropped frames ebenfalls wieder.

 

Aber Du hattest doch mit einer älteren Build schon berichtet, daß es jetzt flüssig laufen würde? War das ein anderes Video? Oder war das im Fullscreen-Exclusive-Mode? Immerhin ist es schön, daß Du eine gesunkene GPU-Last vermelden kannst, da haben meine Optimierungen ja zumindest ein bißchen was gebracht. Hatte aber doch gehofft, daß es jetzt nahe am EVR wäre. Hast Du Dithering ausgeschaltet und "trust DXVA" aktiviert? (Empfehle ich beides nicht, macht aber Sinn für einen fairen Vergleich zu EVR, das meines Wissens auch kein Dithering macht usw).

 

Hast Du Aero/DWM aktiv oder deaktiv? Hilft es vielleicht im nicht-exclusiven Modus, wenn Du das aktivierst?

 

-------

 

@CiNcH, hab noch zwei Ideen gehabt, woran es vielleicht liegen könnte. Bei mir machen beide Sachen keinen Unterschied (auf keinem der beiden PCs), aber vielleicht bei Dir? Hier sind mal drei Test-Builds welches die beiden Änderungen jeweils einzeln und in Kombination beinhalten:

 

http://madshi.net/madVR8719noThread.zip

http://madshi.net/madVR8719noThreadSurface.zip

http://madshi.net/madVR8719surface.zip

 

Tut sich da irgendwas?

 

-------

 

madVR v0.87.19:

 

http://madshi.net/madVR.zip

 

Aber nur 2 Bugs gefixt, keine Performance-Änderung zu v0.87.18.

Link to comment

 

Sehr merkwürdig. Da hab ich im Moment keine Erklärung für. Auf meiner NVidia kann ich das Problem nicht reproduzieren. Hmmmm... Ist in Deinem madVR-Ordner eine "settings.bin"-Datei (nur falls madVR Schreibzugriff drauf hat)? Wenn ja, kannst Du mir die mal hochladen? Falls nein, kannst Du mir mal "HKCU\Software\madshi\madVR\Settings" exportieren? Vielleicht krieg ich das Problem ja mit Deinen madVR-Einstellungen reproduziert?

 

Welches OS benutzt Du nochmal?

Win7 SP1, den Rest kann ich erst später liefern.

 

Achtung nochmals, der Fehler ist auf Win8.1 nicht vorhanden!

Link to comment

Ok, also nur Windows 7 und nur mit NVidia/AMD? Hmmmm... Das könnte für mich schwierig zu reproduzieren werden. Mein Windows 7 Laptop hat nur Intel. Mein Dev-PC hat Windows 8.1. Ok, muß ich vielleicht mal auf meinem HTPC probieren, aber der hat eine *Uralt*-NVidia.

Link to comment
Aber Du hattest doch mit einer älteren Build schon berichtet, daß es jetzt flüssig laufen würde? War das ein anderes Video? Oder war das im Fullscreen-Exclusive-Mode?

 

War exklusiv. Nix Video, Live TV.

 

Hast Du Aero/DWM aktiv oder deaktiv?

 

Der Firlefanz ist inaktiv. Mit Aero werden die dropped frames wieder mehr.

 

Hast Du Dithering ausgeschaltet und "trust DXVA" aktiviert?

 

Dithering ist aus und mit Trust DXVA lässt MadVR wieder mehr weg. Hatte ich bereits geschrieben.

Link to comment

Ich hab mal ein kleines Video hochgeladen was den Wechsel zwischen Mad und unserem EVR Allocator/Presenter zeigt. Aussagekräftig ist das Video leider nicht, da UHD+Fraps+Youtube MP4 Kompression nicht wirklich ein schönes Bilderlebnis liefern. Man sieht nur kurz den Astra SES Kanal, einen Wechsel auf MDR HD und das Umschalten zwischen EVR und MadVR. Am Ende hab ich noch einen Testshader aktiviert und das war es auch schon.

 

https://www.youtube.com/watch?v=6ABR4SLgIPw

Link to comment

Ich überlege das Topic hier mit dem Veröffentlichen der Beta zu schließen.

 

Das Topic ist schon sehr lang, das heißt keiner liest das ganz durch. Das heißt wenn dann mehrere den DVBViewer mit MadVR nutzen wäre wahrscheinlich ein neues Topic besser damit relevanten Informationen nicht so leicht untergehen. Und Area HTPC ist wahrscheinlich auch nicht der optimale Bereich damit das Nutzer finden.

 

Oder spricht irgendwas dagegen?

Link to comment

Sind noch ein paar Sachen offen hier im Thread. Wollte noch das Problem von Tüftler untersuchen. Und ich hoffe, daß CiNcH irgendwann noch meine 3 Testbuilds probiert... :original:

Link to comment

Außerdem wurden hier schon sehr viele Dinge diskutiert auf die man später ggf. nochmal zurückkommen kann.

Dazu sollte der Thread unbedingt offen bleiben.

 

Ich habe meinen Text für madVR Einstellungen und relevante Informationen fast fertig und werde den in den nächsten Tagen veröffentlichen. Welcher Bereich wäre dafür passend? Area HTPC finde ich eigentlich zutreffend?

Edited by nuts
Link to comment

Zu MadVR wird es mit Sicherheit einiges an Fragen geben.

Aber vermutlich auch zu dem neuen EVR von Cinch.

Vielleicht wäre ja für die Zukunft ein eigener Unterbereich für "Renderer (und Decoder)" eine Überlegung wert ?

 

Ich überlege das Topic hier mit dem Veröffentlichen der Beta zu schließen.

 

Gibt's denn schon eine grobe Schätzung, ab wann dann hier geschlossen werden soll ? :original:

Edited by goldfield
Link to comment

In einem Topic mit knapp 700 Beiträgen geht das meiste unter aber ich las das offen (nur um Missverständnissen vorzubeugen ich wollte das nicht löschen).

Für Dokumentation bietet sich das Wiki deutlich mehr an als irgend ein Topic.
http://de.DVBViewer.tv/wiki/MadVR

Du kannst das aber auch gerne direkt hier machen. Aber ich werde das dann nicht verlinken. Das dürfen dann andere machen oder jeder Nutzer sucht es halt selber. Am besten das Topic hier einfach vom Anfang bis zum ende durchlesen. :D Steht sicher viel wertvolles drin und ist die Zeit sicher für jeden wert der MadVR mal kurz ausprobieren möchte.

Link to comment

 

Und ich hoffe, daß CiNcH irgendwann noch meine 3 Testbuilds probiert...

 

Werde ich noch machen (heute oder morgen). Bin gerade zeitlich etwas eingeschränkt...

Link to comment

Dieses Thema hat sich zu einem intensivem "Arbeitsthema" entwickelt, in dem auch für den DVBViewer wichtige technische Sachverhalte kommnuniziert und geklärt werden.

 

Ich bitte deshalb dringend darum, dass allgemeine (befürwortende oder ablehnende) Meinungen zu MadVR, die nicht der Klärung technischer Sachverhalte dienen und deshalb hier als störend empfunden werden, ab jetzt in diesem Thema gepostet werden, um zukünftige Interessenkollisionen zu vermeiden. Wer sich dabei auf einen bestimmten Post in diesem Thread beziehen will, kann das per Link machen.

 

Ich behalte mir vor, unpassende Beiträge in diesem Thema in den o.a. Thread zu verschieben oder (bei Hartnäckigkeit) zu löschen. Und danke schon mal für das Verständnis, das solche Maßnahmen hoffentlich unötig machen wird :)

Link to comment

Parameter:

- FSE @ 1080p50

- trust DXVA

- Dithering: None

- 10bit chroma/image

 

Quelle:

Pro7 FUN HD (1080i)

 

 

madVR 0.87.18

 

60% @ 350/650 MHz (5.4W)

 

 

madVR 0.87.19 a.k.a. "No Thread"

 

60% @ 350/650 MHz (5.4W)

 

 

madVR 0.87.19 a.k.a. "No Thread Surface"

 

60% @ 350/650 MHz (5.4W)

 

 

madVR 0.87.19 a.k.a. "Surface"

 

60% @ 350/650 MHz (5.4W)

 

 

Alles ziemlich gleich...

Link to comment

Ich hab auch mal eine Frage zum dithering.

madVR verwendet intern 16 oder 10 Bit und die Daten werden bis madVR die Kontrolle darüber verliert in 8bit gewandelt?

Mit oder ohne dithering. Je nach Einstellung in madVR eben.

 

Wird vor der GPU Ausgabe (nach madVR) nicht eh immer eine Art dithering verwendet? Ansonsten müsste es doch übles banding geben?

Dieses dithering wird bei EVR/EVR Custom verwendet, jedoch nicht bei madVR da dieser sich immer um die Reduzierung auf 8bit kümmert?

Könnte man das nicht ändern indem madVR 16/10 Bit bis zum letzten Schritt beibehält?

Edited by nuts
Link to comment

EVR selbst macht eigentlich gar nichts. EVR läßt den GPU-Treiber die ganze Arbeit machen. Das heißt, man kann hier nicht davon sprechen, was EVR macht. Sondern davon, was der GPU-Treiber macht. Und das kann sich offensichtlich je nach GPU-Hersteller und Treiber-Version unterscheiden. Meines Wissens dithern die GPUs normalerweise gar nicht. Wobei das möglicherweise bei AMD bei neueren Treibern anders ist, bin mir aber nicht ganz sicher, hab mir das noch nicht genau angeguckt. Ist mir ja eigentlich auch egal, weil ich das ganze ja eh selbst mache.

 

Die GPU-Ausgabe ist normalerweise "lossless". Das heißt, jeder 8bit RGB Pixel, der von Windows gerendert wird, wird auch 100% genauso ausgegeben (es sei denn, daß man im GPU-Control komische Sachen eingestellt hat). Das trifft auf Video-Wiedergabe genauso zu wie auf den Desktop und Spiele. Deshalb macht ja madVR alles selbst und gibt dann "perfekt" geditherte 8bit RGB Bilder an Direct3D, in der Hoffnung, daß es wirklich lossless zum Display geschickt wird. Das ist aber nur der Fall, falls die GPU auf PC-Level-Ausgabe (0-255) eingestellt ist. Andernfalls wandelt die GPU jeden Windows-Pixel um.

 

Natürlich behält madVR 16bit bis zum letzten Schritt bei, ist doch ganz klar. Gedithered wird erst ganz zum Schluß - aber von madVR, nicht vom GPU-Treiber oder von Direct3D, die machen das normalerweise nicht selbst.

Link to comment

Genau das meine ich.

Wenn madVR nicht von 16bit auf 8bit wandeln würde, würde je nach GPU vielleicht eine schnelle und hochwertige (im Vergleich zum runden bei madVR dithering "none") Varinate verwendet?

Wäre natürlich nur als optionales Feature zu sehen.

 

Ich glaube AMD macht schon eine Art dithering.

Edited by nuts
Link to comment

..wenn ich MadVR wähle - nichts weiter mit den instellungen gefummelt und alles mit LAV (ohne dxva) - zerbröselt der text, wenn ich im fenstermode den DVBViewer über den firefox schiebe. Mit dem custom renderer passiert das nicht.

Snap441.png

Link to comment

Wenn madVR nicht von 16bit auf 8bit wandeln würde, würde je nach GPU vielleicht eine schnelle und hochwertige (im Vergleich zum runden bei madVR dithering "none") Varinate verwendet?

 

Nein, definitiv nicht. Wenn AMD dithered, dann nur bei DXVA Scaling oder DXVA Farbkonvertierung. Aber nicht bei einem simplen Pixel-Shader-Pass mit 8bit Zieltexture.

 

Warum vertraust Du nicht einfach, daß ich schon weiß was ich tue? ;)

 

 

..wenn ich MadVR wähle - nichts weiter mit den instellungen gefummelt und alles mit LAV (ohne dxva) - zerbröselt der text, wenn ich im fenstermode den DVBViewer über den firefox schiebe. Mit dem custom renderer passiert das nicht.

 

Komisch. Kann sein, daß der Firefox auch die GPU benutzt und deshalb irgendwie in Schwierigkeiten kommt? Oder vielleicht hat's auch eine andere Ursache. Keine Ahnung. Da ist aber nicht viel, was ich da machen kann. In Windows ist es ja eigentlich so, daß sich jeder Prozeß nur um sich selbst kümmern soll/kann. Was außerhalb des Media-Player-Prozesses passiert, darauf habe ich eigentlich Null Einfluß. Ich vermute aber, daß es bei aktiviertem Aero keine Probleme gäbe. Vielleicht wäre das eine "Lösung"? Oder bist Du noch auf Windows XP/2003? Du könntest auch mal testweise versuchen, in den Firefox-Optionen unter "Advanced" die Hardware-Acceleration abzuschalten. Aber wie gesagt, mehr als diese Vorschläge kann ich leider nicht anbieten. Es gibt (meines Wissens) nichts, was ich in madVR ändern könnte, um Darstellungsprobleme in Firefox zu fixen...

Link to comment

Hehe es ist mehr ein Verständnis- und kein Vertrauensproblem. ;)

 

Wenn man den DXVA Scaler verwendet kommen schon geditherte (oder halt nicht je nach GPU/Treiber) 8bit raus?

Edited by nuts
Link to comment

Wenn man den DXVA Scaler verwendet kommen schon geditherte (oder halt nicht je nach GPU/Treiber) 8bit raus?

 

Keine Ahnung. Bei Intel glaube ich nicht. Vielleicht bei AMD. Bringt aber eh nix, weil madVR ja nach dem DXVA Scaling oft noch weitere Processing-Schritte machen muß. Selbst wenn DXVA da dithered, ist das für madVR zu früh. Das ist jetzt erstmal mein letzter Kommentar zu diesem Thema.

Link to comment

Ja ok eigentlich ist das auch nicht der Punkt.

Ich dachte nur madVR könnte auch direkt 10/16 Bit an D3D übergeben und dem GPU Treiber den Rest überlassen.

So wie es der EVR auch macht?

Wenn das nicht geht oder keinen Sinn macht ist das auch ok ...

Link to comment

@madshi:

 

Es hat sich ein unangenehmes Problem mit MadVR herausgestellt (überprüft mit 0.87.21). Wenn man den DVBViewer über das Systemmenü (also auch das Kreuz oben rechts) schließt, schaltet der Renderer ab -> schwarzes Bild. Normalerweise macht das nichts, weil der DVBViewer ohnehin geschlossen wird, aber wenn er in OnCloseQuery einen modalen Dialog anzeigt - z.B. um nachzufragen, ob eine laufende Aufnahme wirklich abgebrochen werden soll - und das auch noch im OSD, gibt es ein Unglück. MadVR hat dann nämlich keine Neigung mehr, das OSD anzuzeigen ;) Und wenn der Anwender sich entscheidet, den DVBViewer doch nicht zu schließen, hat er kein Video mehr. Erst nach einem Neubau des Graphen geht es weiter.

 

Es sieht so aus, als würde MadVR in vorauseilendem Gehorsam den Laden dicht machen. Ich habe bislang keine Möglichkeit gefunden, drumherum zu arbeiten - wenn ich im Hauptfenster WM_CLOSE oder gar WM_SYSCOMMAND -> SC_CLOSE abfange und ins Leere laufen lasse (so dass sich der DVBViewer auf diesem Weg nicht mehr schließen lässt), wird es trotzdem dunkel, sobald MadVR Gelegenheit erhält, Messages zu verarbeiten. Bei einem Schließen mit TForm.Close (also z.B. via TV/Radio -> Schließen) funktioniert dagegen alles bestens.

 

Was machen wir da?

Link to comment

Oooops. Tja, diesen vorauseilenden Gehorsam hab ich tatsächlich absichtlich eingebaut, um das Beenden des MediaPlayers zu beschleunigen. Außer dem DVBViewer hat sonst kein MediaPlayer, den ich kenne, eine OnCloseQuery-Behandlung. Also da gibt's jetzt drei Möglichkeiten:

 

1) Entweder ich baue dieses Feature komplett aus. Das wäre nicht so schön für die anderen MediaPlayer.

2) Oder ich gucke nach dem Exe-Namen und baue für alle Exes, in denen "DVBViewer" vorkommt, eine Sonderbehandlung ein.

3) Oder ich füge ein Interface dazu, mit dem man das Feature gezielt ausschalten kann.

 

Mir wäre 2) oder 3) lieber. Was wäre Dir lieber? Im Fall 2) gibt's vielleicht noch eine bessere Möglichkeit, wie ich den DVBViewer von madVR aus eindeutig erkennen kann?

Link to comment

Generell halte ich nichts davon, wenn sich DirectShow Filter in Belange einmischen, die die Anwendung regeln sollte. Solche Kompetenz-Überschneidungen sind fast immer problemschwanger. Aber du wirst deine Gründe für die Maßnahme haben...

 

Wenn also unvermeidlich, wäre eigentlich 3) angebracht, denn es könnte auch andere Programme geben, die MadVR verwenden wollen und aus irgendeinem Grund beim Schließen nachfragen ("Wollen Sie wirklich wirklich...?"). Bei Programmen, die Aufnahmen durchführen, ist das absolut üblich. Aber für eine exklusive MadVR-Unterstützung im DVBViewer, die kein anderes TV-Programm bietet, wäre natürlich 2) besser o:)

 

Ich könnte es auch im DVBViewer regeln, indem ich ihn noch vorauseilender die Wiedergabe mit MadVR abschalten lasse, bevor eine Nachfrage in OnCloseQuery stattfindet - Aufnahmen berührt das nicht, da sie unabhängig von der Wiedergabe laufen. Nur müsste dann ein Anwender, der sich doch anders entscheidet, die Wiedergabe neu starten. Und eine eventuelle Timeshift-Datei für zeitversetzte Wiedergabe wäre weg. Ziemlich unschön ;)

 

gibt's vielleicht noch eine bessere Möglichkeit, wie ich den DVBViewer von madVR aus eindeutig erkennen kann?

 

Ich denke mal drüber nach. Vielleicht senden wir MadVR eine geheime Botschaft :)

Link to comment

Ich hab da auch noch eine interessante Beobachtung gemacht.

 

Wenn ich den DVBViewer mit MadVR 0.87.21 laufen lasse, zeigt mir das MadVR-OSD keine Zielauflösung auf 1920. 1080 an, sondern auf 0, 0, 1098. 618.

Laut diesem Post hier http://www.DVBViewer.tv/forum/topic/56402-DVBViewer-pro-beta-540/#entry427103 dürfte der Grund dafür sein,

das ich in der Windows-7 Systemsteuerung die Größe der Anzeige manuell angepasst habe.

 

Wenn ich nun in dieser Konfiguration eine Videodatei mit dem DVBViewer im Vollbild abspiele,

liegt die Auslastung der Graka (AMD HD7880) bei sagenhaften 16%.

post-39779-0-14422400-1430159830_thumb.png

Und das trotz aktiviertem smooth-motion, artefakt removal, Error-Diffusion-2 mit use colored noise und change dither for every frame, und auch noch mit einem image upscaling per Jinc-3 .

(Bei der Wiedergabe der gleichen Vidodatei mit dem MPC-Classic hat meine Graka bei gleichen Einstellungen im MadVR schon eine Auslastung von 55%)

 

1.- Kann es evt sein, das im DVBViewer in dieser Konfiguration zwar das OSD vom MadVR angezeigt wird,

aber dieser garnicht wirklich (oder zumindest nicht in vollem Umfang) aktiv ist ?

(16% mit den Einstellungen im MadVR kommen mir selbst bei einer HD7880 doch äußerst verdächtig vor.)

 

2.- Könnte das evt. auch der Grund für die stark abweichende Graka-Auslastung bei Cinch und nuts sein ?

Edited by goldfield
Link to comment

Welcher Renderer Verwendet wird kannst du während der wiedergebe unter Einstellungen > Filter sehen.

 

Und das Statistik OSD Kommt direkt vom Renderer kann also nicht ohne den zusehen sein.

 

Aber bei der Auslastung musst du immer auch die Auflösung des Eingangsmaterials und die Ausgabe Auflösung mit berücksichtigen. Je nach Einstellungen kann das einen deutlichen unterschied machen wenn die Ausgabeauflösung geringer ist.

Link to comment

Welcher Renderer Verwendet wird kannst du während der wiedergebe unter Einstellungen > Filter sehen.

Und das Statistik OSD Kommt direkt vom Renderer kann also nicht ohne den zusehen sein.

 

Das ist mir bekannt, und scheint mir auch Logisch.

Aber bei den MadVR-Einstellungen ist mir eine Graka-Auslastung von 16% doch mehr als verdächtig.

Zumal der MPC-HC bei der gleichen Videodatei und den identischen Einstellungen im MadVR dann schon eine Auslastung von 55% verursacht.

 

Aber bei der Auslastung musst du immer auch die Auflösung des Eingangsmaterials und die Ausgabe Auflösung mit berücksichtigen

 

Die Eingangsauflösung (720, 576) ist aus dem angehängten Bild ersichtlich, weshalb ich das nicht mehr zusätzlich erwähnt hatte.

Die Ausgangsauflösung liegt (bedingt durch die manuell angepasste Anzeigegröße in der Windows-Systemsteuerung) bei den schon erwähnten 0, 0, 1098. 618.

 

Wenn ich (wie in meinem Link beschrieben) in den Eigenschaften der Verknüpfung, unter dem Reiter "Kompatiblität" die "Scalierung bei hohem DPI-Wert" deaktiviere, wird die Ausgangsauflösung auch korrekt auf 1920, 1080 gesetzt,

und die Auslastung der Graka steigt auf 31%.

Edited by goldfield
Link to comment
Die Ausgangsauflösung liegt (bedingt durch die manuell angepasste Anzeigegröße in der Windows-Systemsteuerung) bei den schon erwähnten 0, 0, 1098. 618.

 

die manuell angepasste Anzeigegröße in der Windows-Systemsteuerung aus deinem Link verändert doch nur die Schriftgröße und manchmal Fenster. Fullscreen ist dann immernoch 1920*1080. Die tatsächliche Bildsch.Auflösung wird im Grafiktreiber verstellt. Oder in "Bildschirmauflösung" (nicht verwechseln).

In deinem Screenshot steht außerdem 'smooth-motion off '.

Edited by craig_s
Link to comment

Aber wie kommt dann die unterschiedliche Graka-Auslastung von 16% oder 31% zustande

(je nachdem ob "Scalierung bei hohem DPI-Wert deaktivieren" angehakt ist, oder nicht) ?

Link to comment

@madshi:

 

Ist eigentlich vorgesehen, dass MadVR in zwei Instanzen innerhalb eines Prozesses laufen kann?

 

Im DVBViewer stürzt der Renderer heftigst ab, wenn man ihn sowohl für die Hauptwiedergabe als auch für Bild in Bild verwendet. Windows fühlt sich dann bemüßigt, die Anwendung abzuräumen. Eine Debugger-Session ergab, dass die zweite Instanz nach Start der Wiedergabe genau in dem Moment abschmiert, wenn PictureInPicturePanel.Visible := true ausgeführt wird:

 

---------------------------
Benachrichtigung über Debugger-Problem
---------------------------
In Projekt C:\Program Files (x86)\DVBViewer Pro\DVBViewer.exe trat ein Problem mit folgender Meldung auf: 'application-defined exception (code 0xc000041d) at 0x73344f5d'. Prozess angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK
---------------------------

 

Die CPU-View zeigt, dass es in der User32.dll am Anfang von SetWindowPos passiert (Der Balken steht auf add esp,$04). Wenn MadVR nur in einer Instanz läuft, also nur für die Hauptwiedergabe oder nur für Bild in Bild verwendet wird, gibt es das Problem nicht.

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