madVR Renderer in DVBViewer nutzen

[goldfield]

Nochmal zu den deutlich unterschiedlichen Graka-Auslastungen bei Verwendung der Option "Scalierung bei hohem DPI-Wert deaktivieren".

 

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

 

Wenn ich für den DVBViewer bei "Scalierung bei hohem DPI-Wert deaktivieren" keinen Haken setze, bleibt selbst bei Verwendung von "image doubling" (32 neurons), und weiterem image upscaling mit Jinc-3, die Belastung der Graka bei 28%.

Da kann ich mir beim besten Willen nicht vorstellen, das MadVR da wirklich mit den Einstellungen, und in vollem Umfang aktiv ist.

Im MPC-HC liegt die Belastung bei dem gleichen Video, und mit identischen Einstellungen bei 86%.

 

Sobal ich bei "Scalierung bei hohem DPI-Wert deaktivieren" den haken setze, steigt die Belastung auf 61% an, und es kommt dann auch (wie zu erwarten) zu droppet frames.

Das sieht mir schon eher glaubwürdig aus, obwohl immer noch deutlich unter der Belastung mit MPC-HC.

 

 

 

 

 

 

[nuts]

Hier kommen mehrere Umstände zusammen.

Durch die DPI Einstellungen stimmt das target rect (Zielaufösung) nicht mehr. Dieses Problem ist im DVBViewer zu suchen, soweit ich Griga da richtig verstanden habe.

Das allein spart schonmal relativ viel ein, da jede Berechnung nach dem Scaling auf wesentlich weniger Pixel angewendet werden muss.

 

In dem speziellen Fall führt es außerdem noch dazu, dass der teure Nnedi Algo nicht für X und Y verwendet wird.

Edited April 28, 2015 by nuts

[blasgl]

Wenn man die bestmögliche Bildqualität erzielen will sollte man also die DPI-Skalierung ausschalten, entweder Systemweit, oder Anwendungspezifisch. Und das nicht nur beim MadVR. Oder sehe ich das falsch?

[goldfield]

Durch die DPI Einstellungen stimmt das target rect (Zielaufösung) nicht mehr. Dieses Problem ist im DVBViewer zu suchen, soweit ich Griga da richtig verstanden habe.

Das allein spart schonmal relativ viel ein, da jede Berechnung nach dem Scaling auf wesentlich weniger Pixel angewendet werden muss

 

Das würde die unterschiedliche Auslastung der Graka ohne "Scalierung bei hohem DPI-Wert deaktivieren" (28%%),

und mit "Scalierung bei hohem DPI-Wert deaktivieren" (32%) erklären.

Mit "Scalierung bei hohem DPI-Wert deaktivieren" liegt die target rect ja bei den korrekten 1920, 1080.

 

Der Grund, warum die Auslastung mit dem MPC-HC bei mir dann nochmal deutlich höher liegt, ist übrigens der Einsatz des "shapen complex_2" Shader's.

Im MPC-HC setze ich den nach dem resize ein, was im Sinne der Qualität ja auch Sinn macht..

Beim DVBViewer scheint der Shader ungünstiger Weise vor dem resize zum Einsatz zu kommen.

Edited April 28, 2015 by goldfield

[madshi]

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

 

Haha!

 

Ok, ab der nächsten madVR-Build kannst Du "SettingsSetBoolean('FinalizeOnWMClose', false)" aufrufen, um dieses Verhalten abzuschalten. Also der gleiche Weg, auf dem der DVBViewer schon das madVR-OSD ein/ausschaltet ("SettingsSetBoolean('DebugOSD', true/false)"). Kannst Du jetzt schon in den DVBViewer einbauen, am besten irgendwo nach der Erzeugen der madVR-Instanz aufrufen, also nach dem Graph-Build oder so.

 

Ich gebe Dir grundsätzlich eigentlich Recht, daß der Renderer sich eigentlich nicht in Belange des MediaPlayers einmischen sollte. Ist halt nur so, daß es je nach Situation ein Weilchen dauern kann, bis madVR sich ordentlich beenden kann. Wenn ich z.B. im Fullscreen Exclusive Mode bei 24Hz 10 Frames an D3D9 zum präsentieren gebe, dann braucht D3D9 beim Freigeben fast ne halbe Sekunde, weil die 10 Frames erst noch abgezeigt werden. So lange bleibt madVR dann beim Beenden hängen. Um dieses Problem etwas abzufedern, hab ich halt versucht, die madVR-Finalisierung schon so früh wie möglich zu starten, damit der User nicht so lange auf das Beenden des MediaPlayers warten muß. Deshalb der "vorauseilende Gehorsam".

 

 

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

 

Hmmmm... Theoretisch ist es so, daß madVR alles schön sauber objektorientiert macht, gerade damit es keine Probleme mit mehreren Instanzen gibt. Allerdings war das nicht immer so, weshalb die meisten MediaPlayer, die madVR unterstützen, ganz besonders darauf aufpassen, daß es immer nur eine madVR-Instanz gibt. Mit anderen Worten: Ich hab keine echte Möglichkeit, mehrere madVR-Instanzen gleichzeitig zu testen. Es kann sein, daß es da noch ein paar Bugs in madVR gibt.

 

Kann der DVBViewer auch PIP machen bei reiner Video-Wiedergabe, ohne DVB? Wenn ja, vielleicht kannst Du mir mal so eine Testbuild schicken, bei der madVR dann crasht, wegen zweier gleichzeitiger Instanzen? Dann kann ich mal gucken, ob ich das Problem gelöst kriege.

 

Gibt's sonst noch irgendwas (nicht zu aufwendiges), was ich für die nächste madVR-Build einbauen könnte, um die DVBViewer-Integration zu verbessern?

 

 

Wenn man die bestmögliche Bildqualität erzielen will sollte man also die DPI-Skalierung ausschalten, entweder Systemweit, oder Anwendungspezifisch. Und das nicht nur beim MadVR. Oder sehe ich das falsch?

 

Ehrlich gesagt, keine Ahnung. Mich verwirrt etwas, daß Du scheinbar im DVBViewer bei gleichem DPI-Wert ein anderes TargetRect bekommst als im MPC-HC? Das ist komisch. Ist das Video trotzdem bei beiden genau gleich groß gezoomt?? Du kriegst definitiv nur dann die ideale Bildqualität, wenn das TargetRect im Fullscreen auch wirklich der Bildschirmauflösung entspricht.

[blasgl]

Du kriegst definitiv nur dann die ideale Bildqualität, wenn das TargetRect im Fullscreen auch wirklich der Bildschirmauflösung entspricht.

 

Genau das war mein Punkt. Also doch besser die Standard DPI-Werte benutzen.

 

Ehrlich gesagt, keine Ahnung. Mich verwirrt etwas, daß Du scheinbar im DVBViewer bei gleichem DPI-Wert ein anderes TargetRect bekommst als im MPC-HC? Das ist komisch. Ist das Video trotzdem bei beiden genau gleich groß gezoomt??

 

Ich habe es nicht getestet, es war "goldfield". Aber ich sehe im DVBViewer, je nach DPI-Wert, eine sehr unterschiedliche GPU-Auslastung. Beim kleinerem DPI-Wert geht der Intel NUC mit HD4400 auf 50% GPU. Bei grosseren Werten so um die 15% GPU

Edited April 29, 2015 by blasgl

[madshi]

Wichtig ist das "target rectangle" im madVR-OSD (Ctrl+J). Wenn Du den DVBViewer auf Fullscreen schaltest, sollte das "target rectangle" praktisch der Display-Auflösung entsprechen. Scheinbar ist das bei veränderten DPI-Werten nicht der Fall? Je kleiner das targetRect ist, desto weniger Arbeit muß madVR tun. In dem Fall muß aber irgendwer anders (Windows oder der GPU-Treiber) den Rest der Zoom-Arbeit erledigen - und macht das höchstwahrscheinlich in schlechterer Qualität.

[nuts]

Für die Qualität ist das sicher nicht gut, da dann eine doppelte Skalierung stattfindet oder das Bild gar nicht auf 1080p ausgegeben wird.

Beides schlecht.

 

Das targetRect muss schon stimmen! Das wird im DVBViewer gefixt werden müssen.

Edited April 29, 2015 by nuts

[Tjod]

Das targetRect muss schon stimmen! Das wird im DVBViewer gefixt werden müssen.

Das wird aber nicht so schnell gehen. Dazu muss der DVBViewer Pro (so wie der DVBViewer GE) in allen Dialogen DPI Aware werden. Und dafür hat Griga ja schon den zeitlichen rahmen gesetzt:

So im Laufe der nächsten Jahre...

Das heißt Nutzer die unter Windows die schriftgröße ändern müssen das über die Kompatibilitäts- Einstellungen lösen und damit leben das einige Dialoge eventuell nicht bedienbar sind.

[Tjod]

Kann der DVBViewer auch PIP machen bei reiner Video-Wiedergabe, ohne DVB? Wenn ja, vielleicht kannst Du mir mal so eine Testbuild schicken, bei der madVR dann crasht, wegen zweier gleichzeitiger Instanzen? Dann kann ich mal gucken, ob ich das Problem gelöst kriege.

Du kannst das mit der DVBViewer Pro Beta 5.4.0 machen. Dafür brauchst du nur eine .ts Aufnahmen.

 

Dann unter Optionen Hardware > Hinzufügen > File Device

dann den Status auf Normal setzen.

 

Einstellungen >> Hinzufügen > Datei > .ts Aufnahme auswählen

und 10744 Frequenzen auswählen.

 

TV/Radio > Sendersuchlauf > Empfangstype Satellit und als Transponderliste Astra 19,2

Und dann Bereich scann und du solltest einen Sender in der Senderliste haben.

 

Dann MadVR für TV und BiB einstellen.

 

In der Senderliste den Sender auswählen und einen rechts klick darauf machen und BiB wählen.

 

Und schon hast du den Absturz.

[goldfield]

Aber ich sehe im DVBViewer, je nach DPI-Wert, eine sehr unterschiedliche GPU-Auslastung. Beim kleinerem DPI-Wert geht der Intel NUC mit HD4400 auf 50% GPU. Bei grosseren Werten so um die 15% GPU

 

Das hatte ich ja auch schon berichtet.

Evt. ist das auch der Grund, weshalb die Auslastung bei Cinch und bei nuts (einige Posts vorher) so deutlich voneinander abweichen.

[nuts]

Also ich kann das von meiner Seite eigentlich ausschließen, da ich an den DPI Einstellungen noch nie etwas geänderte habe und targetRect, FPS und solche Dinge immer beachte bei meinen Tests.

[Griga]

Wenn man 150 dpi einstellt (große Schrift), skaliert Windows den DVBViewer Pro als ganzes hoch, weil er sich nicht durch ein entsprechendes Manifest als DPI-bewusst ausweist. Damit wird dann auch die Schrift vergrößert.

 

Das gilt auch für das Vollbild. D.h. der DVBViewer erfährt gar nicht die wirkliche Bildschirmgröße. Ihm wird eine kleinere vorgekaukelt. Und dann wird das zu kleine Vollbild von Windows auf die wirkliche Bildschirmgröße gestreckt, damit dabei die Schrift größer wird. Dass es im Vollbild keine Schrift gibt, weiß Windows ja nicht. Also absolut suboptimal

[awehring]

Ein kleiner Hinweis, der erstaunlich wenig bekannt ist:

 

Man kann in Windows die Schriftgrösse unabhängig von der DPI-Skalierung einstellen - an einem gut versteckten Ort:

 

Windows 7:

Systemsteuerung -> Darstellung und Anpassung -> Anpassung -> Fensterfarbe und -Darstellung -> Erweiterte Darstellungseinstellungen

 

Dort kann man für einzelne Windows-Elemente Schriftgrösse, Farbe, Rahmenbreite, etc. einstellen. Ich benutze das, um den Touchscreen an meinem HTPC fingerfreundlich zu machen.

 

Das löst euer Problem zwar (bestenfalls) indirekt, indem man die DPI auf 100% stellt und nur die Schrift etc. vergrössert, aber vielleicht ist es trotzdem hilfreich für euch.

 

[blasgl]

Das die DPI-Problematik suboptimal gelöst ist, scheint unbestritten zu sein. Da es keine Lösung in absebahrer ZeitIch geben wird, würde mir von den Entwickler bzw. den Experten in der Community einen gut sichtbaren Hinweis in der Doku. Oder viel besser noch: eine ausgesprochene Empfehlung, wie alles einzurichten ist.

 

Nicht das einige mit dem MadVR und teure Grakas den letzten 0,1% Bildqualität holen wollen, und all die Mühe durch eine ungünstige DPI-Einstellung wieder in die Tonne gekloppt wird.

Edited April 29, 2015 by blasgl

[Tjod]

Es steht jedem Frei derartige Empfehlung im Wiki zu verfassen, die Entwickler haben sicher schon mehr als genug zu tun.
http://de.DVBViewer.tv/wiki/MadVR
http://en.DVBViewer.tv/wiki/MadVR
(gerne auch in einem Extra Artikel)

Aber erwartet von mir keinerlei Artikel zur Bildoptimierung.

Ich werde höchsten Warnhinweise einbauen wie das "Skalieren bei hohen DPI-Werten deaktivieren" zu Problemen mit einigen Dialogfenstern führen kann.

Aber wenn keiner der Optimierungs-Fanatiker Lust hat einen Artikel zu schreiben. Gibt es ja immer noch die Lösung dass alle die sich dafür interessieren einfach alle Topics zu dem Thema aufmerksam von Anfang bis Ende durchlesen dann wissen die auch alle über jede Möglichkeit und jedes Problem bescheid.

[madshi]

Du kannst das mit der DVBViewer Pro Beta 5.4.0 machen. Dafür brauchst du nur eine .ts Aufnahmen.

 

Dann unter Optionen Hardware > Hinzufügen > File Device

dann den Status auf Normal setzen.

 

Einstellungen >> Hinzufügen > Datei > .ts Aufnahme auswählen

und 10744 Frequenzen auswählen.

 

TV/Radio > Sendersuchlauf > Empfangstype Satellit und als Transponderliste Astra 19,2

Und dann Bereich scann und du solltest einen Sender in der Senderliste haben.

 

Dann MadVR für TV und BiB einstellen.

 

In der Senderliste den Sender auswählen und einen rechts klick darauf machen und BiB wählen.

 

Und schon hast du den Absturz.

 

Thanks! Hab den Absturz so reproduzieren können - und das Problem wird in der nächsten madVR-Version behoben sein.

[rmo]

Kann jemand die Deinterlacing-Optionen im madVR erläutern und das Zusammenspiel mit den Deinterlacing-Einstellungen im Decoder? Man könnte ja meinen, dass ich das Deinterlacing im Decoder ausschalten kann, wenn ich das Deinterlacing im madVR einschalte, das ist aber offenbar nicht so.

Also, was macht der Decoder beim Deinterlacing und was macht der Renderer?

[Griga]

 

Ok, ab der nächsten madVR-Build kannst Du "SettingsSetBoolean('FinalizeOnWMClose', false)" aufrufen, um dieses Verhalten abzuschalten.

 

Ok, danke, ich werde es einbauen. Allerdings habe ich inzwischen selbst ein Mittel gefunden, mit dem sich der DVBViewer die volle Kontrolle zurückholt. Vielleicht ganz gut, etwas gegen übereifrige Komponenten an Bord zu haben

 

Zumindest im DVBViewer ist nicht sichtbar, was das "beschleunigte Beenden" bringen soll. Wenn ich an den Anfang von OnCloseQuery ein Sleep(5000) setzte, läuft Video noch 5 Sekunden weiter. Erst nach dem Eintritt in die modale Message Loop eines Dialogs reißt MadVR die Bude ein. Das heißt, im Normalfall, wenn der DVBViewer tatsächlich beendet wird, hat er den Filtergraphen schon längt abgebaut, bevor MadVR dazu kommt, irgendwas zu beschleunigen.

 

Der Versuch ist im DVBViewer-Kontext ebenso wirkungslos wie fatal: Nicht nur, dass der Anwender die OSD-Nachfrage nicht sieht (aus seiner Sicht hängt die Anwendung), der Filtergraph wird auch teil-stillgelegt, im DVBViewer Sourcefilter gibt es Pufferüberläufe, da der Renderer nichts mehr annimmt (Push Mode!), die Anwendung versucht mehrfach, den Fehler durch ein Stop -> Run -> Reset des Graphen zu beheben, der Audiozweig läuft weiter...

 

Aus meiner Sicht ein riskantes Manöver, das MadVR da durchzieht. Ich würde FinalizeOnWMClose standardmäßig auf false setzen, und eventuell eine entsprechende Checkbox in den MadVR-Einstellung ergänzen, falls das wirklich irgendwo was bringen sollte...

[alfonxs]

Ich hätte da mal gerne 3 Fragen zur Verwendung von MadVR:

 

1. Meine schwachbrüstige Intel HD Grafik kommt im Grunde gut mit MadVR zurecht, natürlich alles auf niedrigen Einstellungen (nur Dithering ist an und Trust DXVA... aus). Dateien lassen sich ohne Probleme abspielen, allerdings gibt es bei Live TV ein wenig Schluckauf (Format egal, betrifft 576i25 genauso wie 720p50 und 1080i25): Nach dem Umschalten (bzw. grundsätzlich bei neuem Bildaufbau) dauert es 1-2 Sekunden bis das Bild läuft (ist wohl normal, Initialisierung). Nach ca. 10 Sekunden bleibt das Bild aber wieder stehen, laut MadVR Debug lehren sich alle Queues auf 0, und im DVB Source erscheint "Graph too late". Mit EVR passiert das nicht. Nach ca. 1-2 Sekunden füllen sich die Queues wieder voll auf und es läuft wieder für ein paar Sekunden. Dann steht das Bild wieder und es passiert das gleiche. Das wiederholt sich dann ca. 5-10 mal, aber anschl. gibt es keine Hänger mehr, Queues bleiben voll, keine Fehler mehr im DVB Source. Woran kann dieser initiale "hickup" liegen?

 

2. Manchmal läuft ein Video oder TV völlig problemlos, obwohl die Summe der Renderstats deutlich größer ist als der vsync (z.B. >30ms, aber vsync 20ms). Ich habe allerdings keine dropped frames und auch kein Auseinanderlaufen von Audio und Video. Können die Stats dann überhaupt richtig sein?

 

3. Wenn ich nicht genug CPU/GPU Power für z.B. 50 oder 60 Hz habe, kann ich dann das Display auf 25 bzw. 30Hz schalten ohne Qualitätsverlust? Dann würde ich ja nur die halbe Rechenpower benötigen (da doppelter vsync) und das frame doubling 25 fps -> 50 fps ändert ja nichts an der Bildqualität, oder?

 

System: Intel Pentium G2120 mit HD Grafik (6 Shader), Win 10 aktuelle Preview, Ausgabe über Full HD Beamer

 

Danke an die Devs und Tester, habe auch schon lange auf MadVR gewartet!

 

P.S. Gibt es beim EVR von CiNCH auch ein Debug OSD?

Edited May 1, 2015 by alfonxs

[nuts]

Zu 1) Du könntest mal die Video Voraberkennung aktivieren

 

Zu 2) Nehme an das ist dann ein Fehler in der Anzeige.

 

Zu 3) Kommt auf die Quelle an.

Das Display würde ich nicht umschalten, aber mit dem Deinterlacing lässt sich ein ähnlicher Effekt erzielen.

Mit deaktiviertem Deinterlacing werden aus 50 Halbbilder 25 Vollbilder und madVR muss nur die Häfte bearbeiten.

Das funktioniert bei ursprünglich progressiven Video (Filme in 24p oder 25p) verlustfrei, aber bei ursprünglich interlaced Quellen (z.B. Sport in i50) gibt es die unschönen Kamm-Artefakte.

Bei LiveTV ist das eben bunt gemischt, was eine eindeutige Empfehlung schwierig macht.

Vielleicht hat madshi mal Lust, Zeit und gute Idee wie man dafür eine Automatik in madVR einbauen kann, ich weiß aber von den externen Videoprozessoren, dass eine Automatik nicht gerade trivial ist. Auch die Lumagen oder DVDO Geräte haben damit Probleme und bieten daher zusätzlich feste Modi für das Deinterlacing.

 

P.S. Ja der EVR Custom hat auch ein Debug OSD, lässt sich z.B. Über eine Aktion ID aktivieren.

[madshi]

 

Zumindest im DVBViewer ist nicht sichtbar, was das "beschleunigte Beenden" bringen soll. Wenn ich an den Anfang von OnCloseQuery ein Sleep(5000) setzte, läuft Video noch 5 Sekunden weiter. Erst nach dem Eintritt in die modale Message Loop eines Dialogs reißt MadVR die Bude ein. Das heißt, im Normalfall, wenn der DVBViewer tatsächlich beendet wird, hat er den Filtergraphen schon längt abgebaut, bevor MadVR dazu kommt, irgendwas zu beschleunigen.

 

Hört sich sehr komisch an, das scheint irgendwas schief zu laufen. Könntest Du mir eventuell mal so eine Build mit einem Sleep(5000) zur Verfügung stellen? Würde gerne mal gucken, was denn da los ist.

 

 

1. Meine schwachbrüstige Intel HD Grafik kommt im Grunde gut mit MadVR zurecht, natürlich alles auf niedrigen Einstellungen (nur Dithering ist an und Trust DXVA... aus). Dateien lassen sich ohne Probleme abspielen, allerdings gibt es bei Live TV ein wenig Schluckauf (Format egal, betrifft 576i25 genauso wie 720p50 und 1080i25): Nach dem Umschalten (bzw. grundsätzlich bei neuem Bildaufbau) dauert es 1-2 Sekunden bis das Bild läuft (ist wohl normal, Initialisierung). Nach ca. 10 Sekunden bleibt das Bild aber wieder stehen, laut MadVR Debug lehren sich alle Queues auf 0, und im DVB Source erscheint "Graph too late". Mit EVR passiert das nicht. Nach ca. 1-2 Sekunden füllen sich die Queues wieder voll auf und es läuft wieder für ein paar Sekunden. Dann steht das Bild wieder und es passiert das gleiche. Das wiederholt sich dann ca. 5-10 mal, aber anschl. gibt es keine Hänger mehr, Queues bleiben voll, keine Fehler mehr im DVB Source. Woran kann dieser initiale "hickup" liegen?

 

2. Manchmal läuft ein Video oder TV völlig problemlos, obwohl die Summe der Renderstats deutlich größer ist als der vsync (z.B. >30ms, aber vsync 20ms). Ich habe allerdings keine dropped frames und auch kein Auseinanderlaufen von Audio und Video. Können die Stats dann überhaupt richtig sein?

 

3. Wenn ich nicht genug CPU/GPU Power für z.B. 50 oder 60 Hz habe, kann ich dann das Display auf 25 bzw. 30Hz schalten ohne Qualitätsverlust? Dann würde ich ja nur die halbe Rechenpower benötigen (da doppelter vsync) und das frame doubling 25 fps -> 50 fps ändert ja nichts an der Bildqualität, oder?

 

1. Welche Queues im madVR-Debug-OSD (Ctrl+J) sind denn leer, wenn das passiert?

 

2. Guck mal im Debug-OSD, ob Deinterlacing in der Situation an ist. Wenn nicht, muß madVR nur ein Frame für jeden zweiten VSync berechnen.

 

3. Wenn Du nicht genug GPU für 50Hz Live-TV hast, kannst Du in den madVR "Trade quality for performance"-Einstellungen "use half framerate for DXVA deinterlacing" aktivieren. Dann wird Video-Content nur mit 25fps gerendert statt mit 50fps. Wirklich gut ist das natürlich nicht. Wenn es sich um Filme handelt, würde ich stattdessen empfehlen, das Deinterlacing komplett auszuschalten (klappt meist gut für PAL-Filme) oder den madVR "forced film mode" zu aktivieren.

Edited May 2, 2015 by madshi

[alfonxs]

Danke für eure Antworten, madshi und nuts.

 

1. Queues fallen alle auf 0 in diesem Fall. Video Voraberkennung hat gefühlt etwas geholfen, ich habe das Problem dann nicht mehr 5-10 mal sondern nur noch 2-5 mal.

 

2. Tritt sowohl bei aktivem Deinterlacing (z.b. 1080i) als auch bei deakt. Deinterlacing auf (z.B. 720p). Wenn Deinterlacing aus ist, muss die Summe der Stats also nicht kleiner als der vsync sein?

 

3. Da ich bei 1080i meist Sport schaue, kann ich deinterlacing nicht ausschalten. Ich teste mal die Optionen.

[madshi]

Wenn die Decoder-Queue auch auf 0 geht, dann liefert der Decoder einfach nicht genug Frames an madVR. Das ist mit 99,9% Wahrscheinlichkeit nicht madVR's Schuld. Könnte am Decoder liegen (vielleicht ist Deine CPU zu langsam) oder am Splitter/Source-Filter, keine Ahnung...

[alfonxs]

Das wäre auch meine Vermutung, nur habe ich das Problem erstens nicht mit EVR und zweitens hat sich das nach 1-2 Minuten erledigt und dann läuft es auch mit MadVR sauber weiter....

[Griga]

 

Hört sich sehr komisch an, das scheint irgendwas schief zu laufen. Könntest Du mir eventuell mal so eine Build mit einem Sleep(5000) zur Verfügung stellen? Würde gerne mal gucken, was denn da los ist.

 

Ein Sleep(5000) allein würde nichts bringen. MadVR sieht die relevanten Messages im DVBViewer überhaupt nicht mehr.

 

Tatsache ist jedenfalls, dass das Abräumen der Ressourcen zuvor erst begann, wenn weitere Messages verarbeitet werden konnten. Womöglich verlässt du dich darauf, dass COM-Methodenaufrufe sofort etwas bewirken. Das ist aber nicht unbedingt der Fall. Bei COINIT_APARTMENTTHREADED wird fleißig serialisiert, soweit ich weiß:

 

In addition, calls can arrive only at message-queue boundaries.

[madshi]

Also eigentlich bekommt madVR die WM_CLOSE Message bevor der MediaPlayer die bekommt, und ich setze sofort intern einen Marker, daß die Finalization eingeleitet werden sollte. Der RenderThread sollte das dann eigentlich selbständig machen. Da ist eigentlich nichts mit COM dazwischen. Von daher wundert mich das ganze ziemlich. Naja, ist wahrscheinlich auch nicht so wichtig...

[Griga]

Der RenderThread sollte das dann eigentlich selbständig machen.

 

Aber der verwendet COM, oder? Sicher, dass alle beteiligten Threads in einem Multithreaded Apartment laufen? Da verliert man leicht den Überblick. Obwohl ich schon einiges dazu gelesen habe, bin ich mir immer noch nicht sicher, dass der DVBViewer in der Hinsicht optimal organisiert ist.

 

Der UI Thread muss jedenfalls mit COINIT_APARTMENTTHREADED laufen, sonst funktionieren die Öffnen/Speichern-Dialoge von Windows nicht richtig.

[madshi]

Also das ganze COM-Thema ist schon recht kompliziert. Aber im habe das Direct3D-Zeugs extra mit dem Multi-Thread-Flag erzeugt, damit ich das auch von mehreren Threads aus aufrufen kann - und das klappt normalerweise auch recht gut. Mein RenderThread hat mit COM nicht viel am Hut, außer daß halt Direct3D-Interfaces angesprochen werden. Von daher ist mir nicht klar, warum das mit dem WM_CLOSE nicht so funktioniert wie geplant. COM spielt da auf meiner Seite kaum rein (außer Direct3D, wie gesagt). Aber ich denke, wir sollten das einfach ignorieren, für den DVBViewer ist es ja jetzt eh egal...

[Griga]

P.S. Du müsstest das auch selbst mit dem DVBViewer testen können, indem du den Finalisierungsmarker setzt und dann ein Sleep(5000) folgen lässt.

 

Übrigens nützt es nichts, MadVR WM_CLOSE vorzuenthalten. Schon WM_SYSCOMMAND mit SC_CLOSE darf da nicht durchlaufen.

 

Aber ich denke, wir sollten das einfach ignorieren, für den DVBViewer ist es ja jetzt eh egal...

 

Von mir aus. Aber für deinen Renderer ist es vielleicht nicht egal. Ich hätte jetzt Zweifel, ob der Mechanismus überhaupt wie vorgesehen funktioniert. Oder ob er das in allen Fällen tut.

[madshi]

Also ich würd's schon gern untersuchen. Will da aber jetzt Deine Zeit nicht verbraten, für etwas, das Dir nicht hilft. Aber das mit dem Sleep(5000) kann ich ja mal ausprobieren, gute Idee.

[nuts]

Ich habe mal mit den schnellen DXVA Settings ein Test mit meiner HD7750 gemacht und erhalte damit in etwa eine vergleichbare GPU Last wie beim EVR Custom mit DXVA.

Werde das morgen nochmal genauer angucken, aber sieht gut aus bei mir (Win8 64Bit).

 

Jinc3 + AR für Luma geht für 50p Quellen mit der Karte übrigens auch.

Mit einer Karte in dieser Leistungsklasse kann also schon recht viel anfangen, wobei man jetzt natürlich etwas neueres kaufen könnte.

[madshi]

Ja, im Moment scheint's so zu sein, daß unter Windows 8 die GPU Last vergleichbar zum EVR (Custom) ist. Unter Windows 7 scheint es ein Lotteriespiel zu sein: Bei manchen Leuten vergleichbar, bei anderen schneidet EVR (Custom) deutlich besser ab. Weiß immer noch nicht, woran das liegt...

[madshi]

Ok, neuste Version ist nun raus, mit nativem 10bit-Output und vielen neuen Scaling-Optionen, Schärfe-Algos usw:

 

http://madshi.net/madVR.zip (v0.88.0)

 

Im Moment ist das mit den zahllosen neuen Optionen ziemlich Overkill. Das werde ich in den nächsten Tagen und Wochen anhand des User-Feedbacks deutlich ausdünnen.

[nuts]

Danke für die neue Version.

 

Wie ist das jetzt eigentlich mit dem dithering und dem 10bit Output.

madVR arbeitet intern mit 16bit außer man aktiviert die 10bit trade Optionen?

Dann entfällt das dithering bei 10bit Ausgabe, weil bei 10bit zu 10bit nix passieren muss? So ganz sind mir die Zusammenhänge noch nicht klar.

Edited May 9, 2015 by nuts

[madshi]

madVR rechnet mit 32bit und speichert Zwischenergebnisse in 16bit (außer man aktiviert die entsprechenden "trade quality for performance" Optionen, dann werden Zwischenergebnisse in 10bit gespeichert). Dithering ist eigentlich immer zu empfehlen, es sei denn, native 10bit Ausgabe wird vom Display gut unterstützt und die GPU ist sehr leistungsschwach. Dann mag man vielleicht auf Dithering verzichten können. Aber ich würd's eigentlich immer anlassen...

 

Die meisten heutigen Displays sind eh intern nur 8bit, von daher ist die native 10bit-Ausgabe jetzt auch nicht so wichtig im Moment. Wird mit den meisten Display eh keinen Qualitätsgewinn bringen (sieht vielleicht sogar schlechter aus). Allerdings soll sich das bald ändern. Die neuen Samsung SUHDTV Geräte sollen z.B. echte native 10bit Panels haben, in Vorbereitung auf die kommende UHD-Blu-Ray.

[nuts]

Das Debug-OSD hat sich verändert ab 0.88.0 bzw. 0.88.1.

 

Und zwar wird bei Quelle=target rect trotzdem ein luma-scaler angezeigt (s. Bild).

Bei 0.87.21 wurde in diesen Fällen nur ein chroma-scaler angezeigt.

 

Ist das so richtig? Falls ja: Welchen HIntergrund hat die Änderung?

[madshi]

Nein, ist ein Bug, den ich in meinem Quellen schon behoben hab.

[nuts]

Ok hab noch was: Die neuen Funktionen fehlen bei den Profile (s. Bild - gilt auch für processing).

Edited May 10, 2015 by nuts

[madshi]

Oh ja, werd ich gleich mal ändern...