Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Wen es interessiert: Die neuste madVR-Build hat nun einen neuen Downscaling-Algorithmus mit dem Namen "SSIM", der sich besonders gut für z.B. das PiP eignet (oder zum Downscaling von 4K-Content auf 1080p Displays). Hier ein Vergleich zum Catmull-Rom-Algo, der vorher der "empfohlene" Downscaling-Algo in madVR war. Außerdem im Vergleich der EVR, wobei da die Bildqualität wesentlich von der GPU bzw vom GPU-Treiber abhängt:

 

 

DVBViewerBib2.png

 

 

Die neuste madVR-Build kann nun übrigens auch 3D-Blu-Rays in 3D abspielen. Voraussetzung: Ein 3D-Display, eine halbwegs aktuelle GPU, Windows 8.1 oder Windows 10, und die neuste LAV Nightly Build. Das Abspielen von HDR-Videos wird mittlerweise auch unterstützt, inklusive aufwendigem Tone- und Gamut-Mapping. Sollte (theoretisch, hab's nicht getestet) alles auch einwandfrei im DVBViewer klappen.

  • Like 1
Link to comment

Hm der Bildvergleich beim PiP Fenster ist gar nicht so einfach, da es so klein ist (SSIM profitiert von einem größeren scaling Faktor?).

Habe bei der Gelegenheit aber nochmal PiP mit 2 madVR Instanzen ausprobiert und das funtkioniert mit 0.90.10 ziemlich gut (Sinn und Zweck sicher diskussionsfähig :D ).

 

Mir ist dabei aufgefallen, dass nur die zweite Instanz Tastatur-Befehle annimmt (z.B. strg+j für das OSD oder hinterlegte Hotkeys für Profile).

Nehme mal an das muss so sein?

 

Gibt es eigentlich eine andere Möglichkeit um Profile zu aktivieren außer den definierten Hotkeys, sodass man z.B. ein Eventghost Plugin schreiben könnte?

Tue mich etwas schwer mit dem Lesen der delphi und c header. :(

Link to comment

Außerdem im Vergleich der EVR, wobei da die Bildqualität wesentlich von der GPU bzw vom GPU-Treiber abhängt:

 

 

DVBViewerBib2.png

 

 

Habe gerade über eine Stunde probiert mit EVR auf Intel und Nvidia mit versch. Auflösungen und Decodern ein auch nur annähernd so miserables PIP-Bild zu bekommen - vergeblich.

Manchmal schaltet DVBViewer den Renderer bei PIP nicht oder nicht gleich um dann kann er zB. beim Start auf VMR7 stehenbleiben.

 

Oder es taucht nur bei dieser "eine alte Aufnahme" und Auflösung auf und sonst nie?

Mache doch bitte mal ein paar mehr Tests damit das aussagekräftiger wird.

Link to comment

Ich hab mir natürlich einen Frame rausgesucht, bei dem man die Unterschiede recht gut sehen kann (ist ja klar). Hier ist der Original-Frame als PNG:

 

http://madshi.net/soccerOrg.png

 

Zieh den mal in den DVBViewer und verkleinere dann den DVBViewer auf PiP-Größe, dann müßtest Du das Problem eigentlich reproduzieren können. FWIW, das Bild aus dem Screenshot-Vergleich kommt von meiner AMD-GPU, die ich als "Haupt-GPU" in meinem Dev-PC verwende. Hier nochmal Screenshots vom DVBViewer mit diesem "soccerOrg.png"-Frame von meinem Dev-PC (Windows 8.1 x64), bei Verwendung von AMD- und Intel-GPUs:

 

http://madshi.net/dvbViewerAMD.png

http://madshi.net/dvbViewerIntel.png

Wie Du siehst, habe ich nicht "gemogelt". Intel sieht etwas besser aus als AMD, aber immer noch (meiner Meinung nach) grottenschlecht. Vielleicht kannst Du einen Screenshot in der gleichen Größe von diesem Frame mit einer NVidia-GPU machen? Vielleicht ist NVidia ja besser beim Downscaling?
Link to comment
Zieh den mal in den DVBViewer und verkleinere dann den DVBViewer auf PiP-Größe, dann müßtest Du das Problem eigentlich reproduzieren können..

 

..also die Quali des Graphs (und damit auch von Renderern) mit Standbildern (des laufenden Videos) zu vergleichen ist ja schon nicht ganz unkritisch.

Leider zeigt selbst der Screenshot eines laufenden Videos zwangsläufig je nach Quelle ein leicht-stärker verfälschtes Stand-Bild so als hätte man pausiert.

-> nur bei der genauen Beobachtung des laufenden Videos sieht man die momentane Realität!

 

Aber die Quali des Graphs zu vergleichen indem man Screenshot.png's in die Player einspeist ist nun wirklich Blödsinn.

Hier ein einfaches Beispiel, ein Video (interlaced, also die härtere Variante)

https://dc2.safesync.com/FdSVjnr/offen/various/Fu%C3%9Fball%20kurz.ts?a=I_L8NEqykkg

 

und ein PNG

https://dc2.safesync.com/FdSVjnr/offen/various/fu%C3%9Fball.png?a=e1T7tQF1DbE

 

1) Dann lässte das Video im DVBV-winz-Fenster laufen, und schaltest gelegentlich die renderer um, welche Unterschiede siehst du?

2) Dann schiebste das png in den DVBViewer (wärend EVR-C an ist, für madVR musste ich es erst in ein jpg wandeln sonst schwarz) - was siest du?

Ich sah genau das aus deinen Screenshots oben.

 

Hier was ich bei 1) (Intel i7-4600 Haswell) sah:

wennihrschonüber40seidsetzteuchnebrilleauf-klick..

 

mini-Fussball.png

 

 

p.s.

In der Tat präsentiert sich MPC-HC etwas anders - wenn man da das "Fußball kurz.ts" mit dessen EVR-C ganz winzig macht sieht man wieder die punktigen Linien. Aber was hat der herrliche EVR-CiNstom mit den EVR-C vom MPC zu tun? Garnix! Übrigens Überraschung - MPC's EVR-Enhanced kann es wieder ohne Punkte :P

Edited by craig_s
Link to comment

Oh Mist, ich hab gerade festgestellt, daß der DVBViewer beim Anzeigen von PNGs scheinbar nicht den normal eingestellten VideoRenderer verwendet, sondern das Scaling irgendwie selbst durchführt? Jedenfalls wird madVR bei mir nicht verwendet, selbst wenn es aktiviert ist. Beim MPC-HC läuft das Anzeigen von PNG/JPG Bildern ganz normal über den VideoRenderer, von daher war das mit dem PNG meine erste Idee, wie Du das am einfachsten reproduzieren kannst, ohne daß ich da was vom TS hochladen muß.

 

Grundsätzlich ist die Vorgehensweise, mit einem Screenshot eines Videos zu testen, überhaupt keine schlechte Idee. Natürlich vorausgesetzt, das ganze durchläuft die üblichen Code-Wege, was jetzt hier nicht der Fall war (mein Fehler). Also müßte man dann wahrscheinlich ein AviSynth-Script bauen, um das PNG einzulesen und in 4:2:0 umzuwandeln. FWIW, mein Video war 720p und es gab keine großen Unterschiede zwischen Nachbar-Frames.

 

Anyway, Deine Downscaling-Bilder vom EVR sind dem madVR-Screenshot überraschend ähnlich. Außerdem sieht das madVR-Bild gar nicht nach SSIM aus. Mein SSIM Screenshot (s.u.) hat einen völlig anderen Look als Deiner!? Hast Du vielleicht SSIM1D25 genommen? Default-Einstellung (und empfohlene Einstellung) ist SSIM1D100. Außerdem ist es merkwürdig, daß der Zoom-/Crop-Faktor *genau* identisch ist bei Deinen Screenshots. Bei mir gibt es dort spürbare Unterschiede zwischen madVR, Intel-DXVA und AMD-DXVA. Schau mal hier:

 

http://madshi.net/dvbViewerIntelHD4000.png

http://madshi.net/dvbViewerAMD7770.png

http://madshi.net/dvbViewerSSIM1D.png

 

Mach die drei Bilder mal in unterschiedlichen Browser-Tabs auf und springe dann hin und her. Du wirst sehen, daß das Bild etwas "hin und her springt", obwohl es glaube ich der gleiche Frame ist. Da gibt's minimale Unterschiede im Zoom-Faktor und Aspect-Ratio. Bei Dir sind alle Bilder genau identisch, außer daß das madVR-Bild etwas farbintensiver ist und einen Frame weiter ist. Bist Du sicher, daß Du da nichts durcheinander geschmissen hast?

 

Hier nochmal die 3 nebeneinander:

 

dvbViewerSoccer.png

Link to comment

EVR Custom in MPC-HC verwendet bilinear, wenn ich mich nicht irre. Für den EVR Custom im DVBViewer sollte man in den Optionen DXVA Scaling aktivieren.

 

EVR Custom in MPC-HC hat 5 versch. Einstellungen wählbar. Ich verwende normalerweise Bikubisch A 1.00. Kostet am meisten "Strom" und ist gleichscharf wie EVR Enhanced (der nur ganz wenig Strom kostet). Das von der Laufzeit eines Laptops im Akkubetrieb her betrachtet.

 

 

Bist Du sicher, daß Du da nichts durcheinander geschmissen hast?

Hier nochmal die 3 nebeneinander:

 

Gerade nochmal auf 3 versch PCs probiert.

Intel 4600 Hasw. HD Win10

Intel 4000 Ivy HD Win7

Nvidia GTX960 4k Win10

 

überall das gleiche. Bist Du sicher, daß Du da nichts durcheinander geschmissen hast?

Schau dir mal deinen letzten "Hier nochmal die 3 nebeneinander:" genau an - aahh, plötzlich hat EVR-C auf Intel keine gepunktete Linien mehr sondern sieht ganz so aus wie auf meinem Screenshot - na also, geht doch :)

 

Um solche Punkte auf Intel hinzubekommen muß ich im DVBViewer schon auf VMR7 umschalten (probier das mal, womöglich hat sich DVBV im System Renderer festgebissen und könnte durch die Umstellungen gelockert werden).

MPC-HC's EVR-C kann punkte wie gesagt auch mit Intel (im gegensatz zu MPC-HC's EVR enhanced).

Was AMD macht ist mir egal, AMD ist eh out.. ;)

 

p.s.

SSIM ist auf 100, nix geändert.

Eben nochmal ctrl-J gedrückt, OSD kommt, madVR ist also aktiv.

Edited by craig_s
Link to comment

Ich hab ja schon in meinem ersten Post zum Thema klar geschrieben, daß die Scaling-Qualität "wesentlich" (orginale Wortwahl) von der GPU und dem Treiber abhängt. Sollte keine Überraschung sein, daß sich dies nun tatsächlich so bewahrheitet. Offensichtlich schlägt sich Intel da besser als AMD.

 

Du hast meine noch Frage nicht beantwortet, mit welcher SSIM-Einstellung Du den madVR-Screenshot gemacht hast? Der ist nämlich viel unschärfer als das was ich hier mit der SSIM-Default-Einstellung bekomme.

Link to comment

SSIM ist auf 100, nix geändert.

Hatte ich oben etwas später rein-p.s.'t

 

Aber über den 4k rechner der ja bei *DVBV-winzig* vom OSD einiges mehr anzeigt als bei HD-aufl. bin ich der Frage auf die Schliche gekommen warum madVR *genauso* aussieht wie EVR.

Da steht bei "image" immer < DXVA, ganz egal was in madVR's scaling-Settings eingestellt ist (auch mit per .bat alles auf default)!

 

Den Gegenbeweis gemacht, v0.90.12 weg und zu v0.89.5 zurück, nun steht bei "image" brav was man eingestellt hat.

Bei "chroma" allerdings immernoch > DXVA, egal auf was Chroma steht.

Müsste mal korrigiert werden?

 

Ja und mit image-down bicubic ist dann der *DVBV-winzig* a bisserl schärfer.. :)

Link to comment

Ooooohh, das erklärt natürlich alles!!!!!!!! :)

 

Das hört sich sehr stark nach einem Bug in madVR an. Aber ich krieg das bei mir gerade nicht reproduziert. Könntest Du bitte erstmal Deine "madVR\settings.bin" sichern (falls dort eine ist, ansonsten "HKCU\Software\madshi\madVR\Settings")? Könnte sein, daß Deine spezielle Einstellungs-Kombination dazu nötig ist, den Fehler zu reproduzieren. Könntest Du danach bitte madVR auf die Standard-Einstellungen zurücksetzen, und gucken, ob es dann funktioniert? Sonst eventuell mal alle Trade-Quality-Optionen weghaken? Bin mir nicht sicher, woran das liegt, daß bei Dir für Downscaling immer DXVA verwendet wird. Könntest Du Deine settings.bin für mich hochladen? Vielleicht krieg ich das hier dann auch reproduziert...

Link to comment

Huch, in den Trade-Quality-Optionen sind doch die beiden "use DXVA..." per Default angehakt - wenn ich die weghake schaltet das OSD sofort auf die eingestellten Werte.

Bei installiertem LAV auf default wird somit madVR auf DXVA stehend ausgeliefert?

 

Hätte nicht gedacht das du dich mal soooweit sinken (runterhandeln) lassen würdest.. ;)

 

..mit SSIM100 großbild (etwas kleiner als 1080) ist dann gleich mal der Haswell in die Knie gegangen (MPC-HC)!

Beim *DVBV-winzig* hat i-down bicubic100 viel weniger Treppchen als SSIM100?

settings.zip

Link to comment

Huch, in den Trade-Quality-Optionen sind doch die beiden "use DXVA..." per Default angehakt - wenn ich die weghake schaltet das OSD sofort auf die eingestellten Werte.

Bei installiertem LAV auf default wird somit madVR auf DXVA stehend ausgeliefert?

Die Optionen beziehen sich nur auf das chroma scaling.

Bei mir (AMD GPU s. madshi im nächsten Post) wird der ausgewählte luma (up und down) scaler mit der neusten Version auch verwendet, trotz der beiden Haken bei den Trade-Quality-Optionen.

Edited by nuts
Link to comment

Oh, der Bug passiert bei mir mit der Intel-GPU, aber *nicht* mit der AMD (welche meine "Haupt"-GPU ist). Deshalb hab ich den Fehler bisher nicht bemerkt. Thanks, werde ich in der nächsten Build beheben.

 

Diese Trade-Quality-Optionen sollen sich eigentlich nur auf die Chroma-Channel auswirken, welche nicht sooo wichtig sind, und diese Optionen haben nur eine Auswirkung, wenn natives DXVA-Decoding verwendet wird, oder DXVA-Deinterlacing. Bei allem was mit DXVA zu tun hat (außer wenn "Copyback" benutzt wird), leidet der Chroma-Channel eh etwas. Deshalb hab ich diese Optionen eingebaut, da es einen hohen Performancevorteil bei nur geringem Qualitätsverlust bringt. Aber letztendlich sind dies ja auch nur "Default"-Einstellungen, die dafür optimiert sind, daß der User möglichst auch auf langsamen GPUs erstmal ein flüssiges Bild bekommt. Aufdrehen kann man ja immer...

 

Die Treppchen sind bei Bicubic auch vorhanden, fallen nur nicht so auf, weil der Kontrast viel niedriger ist. Wenn Du das Bicubic-Bild gezielt nachschärfen würdest, wären die Treppchen wahrscheinlich genauso stark zu sehen. SSIM 2D ist da einen Hauch besser, aber verbrät dramatisch mehr Performance. SSIM 1D macht intern erstmal ein Bicubic-Downscale, geht nur nach dem Downscaling nochmal hin und überarbeitet das Bild, um den lokalen Kontrast auf das gleiche Niveau zu bringen wie im ursprünglichen (großen) Bild. Von daher sollte sich das mit den Treppenstufen eigentlich nicht groß unterscheiden.

 

Mich nerven diese Treppenstufen grundsätzlich aber auch. Hab schon verschiedene Dinge probiert, um die loszuwerden, aber das ist schwieriger als man meinen sollte. Ich muß den Downscaling-Algo sehr stark verwaschen machen, damit die Treppenstufen verschwinden, was ein sehr unscharfes Bild ergibt, und das ist ja genau was wir *nicht* wollen. Vielleicht finde ich da irgendwann eine Lösung für, im Moment geht's erstmal nicht anders. Wobei Fußball mit den scharfen schrägen Linien natürlich schon ein recht "gemeiner" Test ist. Aber deshalb hab ich das ja auch genommen, weil man da solche Probleme gut sehen kann...

Link to comment

..Idealist ohne Schmerzgrenze? :)

Eben weil so ein Sportfeld mit genau dieser Ausleuchtung, Winkel und Bewegung seeeltenst übern screen flimmert selbst wenn man immer nur Sport guckt.

Bei halberwegs *normalem* Bildmaterial fällt das alles überhaupt nicht auf !

 

Ich würde SSIM 100 etwas zu schärfend finden wenn es mich interessieren würde.. ;) :

 

post-73651-0-19671800-1456343623_thumb.jpg

Link to comment

Also die generelle Bildschärfe (oder Mangel an Bildschärfe) fällt bei PiP schon deutlich auf, finde ich, bei eigentlich jedem Material. Und bei AMD-DXVA sieht's ganz gruselig aus. Bei Intel (und scheinbar auch NVidia) ist's zumindest erträglich, aber tendenziell schon relativ soft. Ich finde, da ist SSIM schon ein deutlich sichtbarer Fortschritt. Ist natürlich nur meine persönliche Meinung.

Link to comment

..genau, das ist Geschmackssache.

Und wenn du sagst "Bei Intel (und scheinbar auch NVidia) ist's zumindest erträglich" ist das nichts als dein Geschmack der warscheinlich noch vom Eifer des Entwicklers beeinflusst wird, was ja verständlich ist... :innocent: Hier dagegen sieht es so aus das auf Intel und Nvidia der Unterschied den Aufwand nicht lohnt zumal PIP bei mir recht selten zum Einsatz kommt, was interessiert mich da wie dieses kleine Bildchen aussieht?

 

Gerne würde ich immer mal einen deiner Algos auf dem *normalgroßen* Bildschirm auch dauerhaft probieren. Das scheitert aber regelmäßig daran das ich fast nur auf Laptops unterwegs bin. Deren Grafiklösungen (meist Intel iGPU) geraten sofort an ihre Grenzen wenn man in madVR DXVA verlässt. Macht auch kein Spass wenn das große Rauschen anfängt.

 

Und dann die Fehleranfälligkeit. Wenn ich manchmal madVR "vergesse" und anlasse passiert regelmäßig bei irgendeiner Funktion oder Auflösung innerhalb von ein paar Stunden irgend ein Fehler und ich kratz mich am Kopf - ah madVR ist an. Einen aufwändigen Bugreport zu schreiben ist mir dann zu mühsam...

 

 

So, in der Hoffnung das das nicht gleich gelöscht / verschoben wird, weil hier nur noch "madshi & friends" soviel Meinungen äußern dürfen wie sie wollen :innocent: doch noch eine Art Bugreport:

Intel 4600 Hasw. HD Win10 <---hier passiert es

Intel 4000 Ivy HD Win7 <-hier nicht

Nvidia GTX960 4k Win10 <-hier nicht

 

DVBViewer und MPC-HC

madVR v0.90.12 und v0.89.5 (mehr nicht probiert. Settings: mit .bat alles auf Default)

 

Sobald ich bei einem laufenden Video oder Live-TV den unteren Fensterrand des Players "in die Hand nehme (Maus)" und den hochschiebe oder runterziehe frieren gleichzeitig die Größenänderung und das Video ein. Dann muß man sich etwas gedulden bis das Programm wieder reagiert. Wenn ich dann in DVBViewer auf stop drücke erscheint meistens auf dem schwarzen Frame:

 

madVR reports:
- resetting Direct3D device failed (8007000e)
- creating Direct3D device failed (8007000e)

 

manchmal geht auch noch ein kleines "Bug-report" -Fenster auf.

 

Manchmal kann man die Player reaktivieren indem man ein neues Video reinzieht oder den Sender wechselt.

Ist mir lästig aufgefallen als ich die Player bei den Tests oben dauernd auf "Briefmarkengröße" bringen mußte. Das ging nur reibungslos wenn madVR gerade nicht lief.

Link to comment

8007000e bedeutet "out of memory/system resources". Weiß nicht, warum das bei Intel 4600 auftritt und nicht bei Intel 4000. Könnte ein Bug in madVR sein, oder ein GPU-Treiber-Problem, oder vielleicht gibt's irgendwo eine BIOS- oder GPU-Einstellung, wieviel RAM Grafikspeicher die Intel GPU kriegt? Aber warum passiert das dann nur beim Ändern der Fenster-Größe per Drag&Drop? Wenn's wirklich einfach zu wenig RAM ist, könnte man es vielleicht durch verkleinern der GPU-Queue lösen.

 

Natürlich ist vieles irgendwo Geschmackssache. Aber die meisten User bevorzugen meiner Erfahrung nach ein schärferes Bild. Der eigentliche Logikansatz bei SSIM-Downscaling ist, daß es versucht, das kleine Bild so aufzubereiten, daß es für das menschliche Auge wie eine naturgetreue Verkleinerung des originalen Bildes aussieht. Die ursprüngliche Idee kommt von hier:

 

https://graphics.ethz.ch/~cengizo/Files/Sig15PerceptualDownscaling.pdf

Link to comment

Beide Intel haben 8GB Ram / gleiche Bios-Settings wo man in Dell Laptops nicht einstellen kann wieviel RAM Grafikspeicher die Intel GPU kriegt.

GPU-Treiber-Problem, na ja, sonst ja keine Probleme, nur madVR.

 

GPU-Queue ändern brachte nichts, aber weiter oben das: Haken vor "Enable windowed overlay".

Damit ändert sich ja die Bildgröße nicht mehr on-the-fly sondern folgt im Abstand von ca. 1sec. Auch schien mir stürzten die player bevorzugt in dem Moment ab wo die org-resolution durchschritten wurde und madVR von up- auf down-scaling (und umgekehrt) umschaltet. Mit "Enable windowed overlay" gehts jedenfalls nun ohne einfrieren.

 

MPC-HC schickte bei einem der Abstürze mit doctor dump das nach hause:

Stack:
lavvideo+0x7c13
lavvideo+0x84b4
lavvideo+0x789f
lavvideo+0x13ca4
lavvideo!DllGetClassObject+0x50c
lavvideo!DllGetClassObject+0x35639
kernel32!BaseThreadInitThunk+0x22
ntdll!RtlUserThreadStart+0x34

Link to comment

..auf PDVD Generic Video Decoder umgestellt,

- in LAV Video Decoder alle mögl. Hardw.Accelerations durchprobiert / aus - brachte alles keine Besserung.

 

"Enable windowed overlay" Wundermittel, wird vorläufig beibehalten, bis zum nächsten Screenshot..

Link to comment

Overlay hat immer noch die kleine Present-Queue, die bei mir früher gerne mal leer gelesen wurde. Mit aktuellen DXVA Optimierungen habe ich das jedoch nicht mehr getestet.

Link to comment

Ich vermute mal madshi hat seinen develop-PC noch nicht umgestellt was ich verstehe.

Aber Win10 + Intel iGPU läuft wie gesagt videotechnisch schon sehr stabil und da müsste madVR dann halt mal angepasst werden.

 

Gerade probiert - auch "D3D11 windowed (8-bit)" geht in Win10 + Haswell gar nicht - wilde Zitterorgie... NV12, 8-bit, 4:2:0 (DXVA2)

Auch "exclusive" (fullscreen) noch Zuckungen.

 

Win10 + GTX960 dagegen kein Problem.

 

p.s.

DVBViewer, MPC-HC, bei beiden.

Edited by craig_s
Link to comment

Nein, mit CopyBack ist das Zittern nicht weg sonden nur wenn "image up/down" entweder inaktiv ist oder auf DXVA steht.

 

Ich habe das Zittern inzwischen auf allen 3 Intels nachstellen können, sogar im Win7 Laptop. Sollte also auch in Win8 erscheinen?

Evl. verschwindet es ja wenn der "use DXVA..." Bug behoben wird?

 

Intel 4600 Hasw. HD Win10 <- zittert windowed und exclusive

Intel 4000 Ivy HD Win10 <- zittert windowed und exclusive

Intel 4000 Ivy HD Win7 <- zittert nur exclusive (HD fullscreen) -> also bei 1080-Moni - SD oder 720p video spielen

 

Voraussetzung:

DVBViewer oder MPC-HC

wenn MPC-HC auf 100% öffnet muß man ein bisschen am Fenster ziehen damit image up/down aktiviert wird.

 

madVR v0.90.12 - v0.90.0 - v0.89.5 (mehr nicht probiert)

in den Trade-Quality-Optionen die beiden "use DXVA..." ohne Haken

 

image down: catmull oder bicubic (mehr nicht probiert)

image up: lanczos 3 (mehr nicht probiert)

 

in "general settings" nur das angehakt:

- enable automatic fullscreen...

- use Direct3D 11 ...

- present a frame...

 

alles andere auf default.

Edited by craig_s
Link to comment

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

 

Könntest Du mal prüfen, ob die neue Einstellung "use alternative glitch handling mode" besser funktioniert? Diese Option hat zur Folge, daß die D3D11-Präsentations-Logik so geändert wird, daß sie relativ ähnlich wie die D3D9-Logik ist. Ich hab festgestellt, daß das für 3D-Playback besser funktioniert. Vielleicht hilft es auch beim "Zittern" mit der Intel-GPU?

Link to comment

Wow @gwr, das ist der Volltreffer!

Mit den queue sizes hatte ich ja nur bei dem "Absturz bei Größenänderung des Fensters" -Bug rumgetestet (Tip madshi), bei dem "Direct3D 11 Zappel-Bug" dann leider nicht mehr.

Was ich bei GPU queue size eingestellt habe -> immer default (8) solange ich nix anderes dazusage. Wenn ich eine neue Reihe (zB. andere madVR Version) anfange schalte ich immer als erstes mittels madVR's "restore default settings.bat" auf default um irgendwie ne Linie reinzubringen.

 

Mit den Causalitäten zeichnet sich nach viel Testerei eine rel. klare Reihenfolge ab, alles hängt offenbar zusammen:

1) "Absturz bei Größenänderung des Fensters" passiert nur in Win10 + Intel, in madVR alles auf default.

 

2) den "Direct3D 11 Zappel-Bug" leitete ein Fehler in madVR ein, der bei Intel "image up/down" permanent auf DXVA stellt wenn in den Trade-Quality-Optionen die beiden "use DXVA..." (per Default) angehakt sind (unabhängig davon was in madVR's scaling-Settings eingestellt ist).

 

Ob v0.90.13 das schon repariert hat weiß ich nicht - immerhin zeigte das OSD zwar eben die "image up/down" richtig an aber um den "Direct3D 11 Zappel-Bug" schnell zu provozieren muß ich die beiden "use DXVA..." immernoch ausschalten. Aber (noch komplizierter) den "Direct3D 11 Zappel-Bug" kann ich auch mit eingeschalteten "use DXVA..." locker provozieren, ich muß nur etwas länger nach einer Fenstergröße suchen wo es zappelt.

 

3) die neue Einstellung "use alternative glitch handling mode" - habe hin- und hergeschaltet bewirkt nichts oder nichts Bemerkbares.

 

4) der "Absturz bei Größenänderung des Fensters" -Bug ist auch weg sobald in Win10 + Intel -> Direct3D 11 eingeschaltet ist, egal ob es zappelt oder nicht!

-> oder "Enable windowed overlay" wie genannt.

 

5) gwr, finally :) --> GPU queue size: 12

Damit ist der "Direct3D 11 Zappel-Bug" in Win10 + Intel vorbei, nichts zappelt mehr, sollte man sich merken, vielen Dank!

In Win7 noch nicht probiert, mir gerade zu mühsam, bin aber guter Hoffnung..

 

Wünsche meinerseits geholfen zu haben :)

Edited by craig_s
Link to comment

Oh, das ist ja komisch! Ist mir nicht klar, warum die GPU queue size da einen Unterschied macht!!! Ich würde die ja per Default höher setzen, aber manche User würden vielleicht dann in GPU-RAM-Probleme kommen...

Link to comment

Mit 4) etwas zu früh gefreut, hatte gegen Ende nur noch mit MPC-HC getestet.

 

Bei DVBViewer siehts anders aus, da muß für die wirksame Bekämpfung des "Absturz bei Größenänderung des Fensters" -Bug

- Direct3D11 aus und

- "Enable windowed overlay" an sein, wie gehabt.

Link to comment

Hi, ich bin gerade mit dem Res. switcher am rumtesten(hatte bisher das Plugin von snoopy benutzt) .

Funktioniert soweit einwandfrei ausser beim zurückschalten von 2160p23 auf 1080pxx, da stürzt der Viewer reproduzierbar ab.

1080p50 auf 1080p23 geht hin und zurück einwandfrei.1080p50 / 23 auf 2160p23 geht auch wunderbar.

 

DVBViewer 5.2.2,madvr 90.13,lavfilter 67-136.(AMD A10-7800 mit Cat 16.2)

Ich schau mal ob ich nen log zusammenbekomme.

 

Mfg Alex

Link to comment

Nachtrag 3D funktioniert auch im DVBViewer alleder macher er da machmal sidebyside und erst nach nem wiedergabe neu aufbauen framepacking.

Im MPC-BE geht das problemlos.

Das Problem mit 4k im DVBViewer besteht aber, unten in viewer wird richtig erkant(38..x2160) er swticht auch auf die richtige Auflösung aber er bleibt bei scale 2160->1080,

Im MPC-BE gibt er richtig dra 2160p wieder allerdings funz das auto. switching im Be garnicht.

Link to comment

MPC-BE geht mit 4K spezial- Wege die evl. gerade bei Sonderfunktionen problematisch sein können, siehe ua. hier*.

 

Die Developers könnten daher versucht sein mit MPC-BE nicht viel zu testen.. Daher probiers nochmal mit MPC-HC für mehr Wiederhall?

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