madshi Posted February 16, 2016 Share Posted February 16, 2016 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: 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. 1 Quote Link to comment
CiNcH Posted February 17, 2016 Share Posted February 17, 2016 Sag blos, du hast die TeVii in Betrieb genommen ^^ . Quote Link to comment
madshi Posted February 17, 2016 Share Posted February 17, 2016 Installiert ist sie, aber ich hab ja keine SAT-Schüssel. Das ist eine alte Aufnahme -> DVB File Device. Quote Link to comment
nuts Posted February 17, 2016 Share Posted February 17, 2016 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 ). 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. Quote Link to comment
madshi Posted February 17, 2016 Share Posted February 17, 2016 Du kannst IMadVRSettings2::SettingsActivateProfile() aufrufen, um Profile zu aktivieren. Quote Link to comment
nuts Posted February 17, 2016 Share Posted February 17, 2016 Ok danke, dann hab ich schon mal die richtige Stelle für weitere Nachforschungen. Quote Link to comment
craig_s Posted February 23, 2016 Share Posted February 23, 2016 Außerdem im Vergleich der EVR, wobei da die Bildqualität wesentlich von der GPU bzw vom GPU-Treiber abhängt: 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. Quote Link to comment
madshi Posted February 23, 2016 Share Posted February 23, 2016 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? Quote Link to comment
craig_s Posted February 24, 2016 Share Posted February 24, 2016 (edited) 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.. 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 Edited February 24, 2016 by craig_s Quote Link to comment
CiNcH Posted February 24, 2016 Share Posted February 24, 2016 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. Quote Link to comment
madshi Posted February 24, 2016 Share Posted February 24, 2016 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: Quote Link to comment
craig_s Posted February 24, 2016 Share Posted February 24, 2016 (edited) 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 February 24, 2016 by craig_s Quote Link to comment
madshi Posted February 24, 2016 Share Posted February 24, 2016 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. Quote Link to comment
craig_s Posted February 24, 2016 Share Posted February 24, 2016 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.. Quote Link to comment
madshi Posted February 24, 2016 Share Posted February 24, 2016 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... Quote Link to comment
craig_s Posted February 24, 2016 Share Posted February 24, 2016 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 Quote Link to comment
nuts Posted February 24, 2016 Share Posted February 24, 2016 (edited) 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 February 24, 2016 by nuts Quote Link to comment
madshi Posted February 24, 2016 Share Posted February 24, 2016 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... Quote Link to comment
craig_s Posted February 24, 2016 Share Posted February 24, 2016 ..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.. : Quote Link to comment
Griga Posted February 24, 2016 Share Posted February 24, 2016 Hier wird ja echt um jeden Pixel gefeilscht, oder? Quote Link to comment
madshi Posted February 24, 2016 Share Posted February 24, 2016 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. Quote Link to comment
craig_s Posted February 25, 2016 Share Posted February 25, 2016 ..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... 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 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. Quote Link to comment
madshi Posted February 25, 2016 Share Posted February 25, 2016 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 Quote Link to comment
craig_s Posted February 25, 2016 Share Posted February 25, 2016 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+0x7c13lavvideo+0x84b4lavvideo+0x789flavvideo+0x13ca4lavvideo!DllGetClassObject+0x50clavvideo!DllGetClassObject+0x35639kernel32!BaseThreadInitThunk+0x22ntdll!RtlUserThreadStart+0x34 Quote Link to comment
madshi Posted February 25, 2016 Share Posted February 25, 2016 Dem Stack nach wäre der Absturz im LAV Video Decoder. Quote Link to comment
craig_s Posted February 25, 2016 Share Posted February 25, 2016 ..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.. Quote Link to comment
madshi Posted February 25, 2016 Share Posted February 25, 2016 Spricht auch gar nix dagegen. Overlay hat seine Vorteile, wird allerdings nur von NVidia und Intel unterstützt, nicht von AMD. Quote Link to comment
CiNcH Posted February 25, 2016 Share Posted February 25, 2016 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. Quote Link to comment
craig_s Posted February 25, 2016 Share Posted February 25, 2016 (edited) 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 February 25, 2016 by craig_s Quote Link to comment
craig_s Posted February 25, 2016 Share Posted February 25, 2016 p.s.2 oder muß bei "D3D11 windowed (8-bit)" im LAV immer CopyBack an sein? Damit ist das Zittern weg. Quote Link to comment
craig_s Posted February 27, 2016 Share Posted February 27, 2016 (edited) 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 February 27, 2016 by craig_s Quote Link to comment
gwr Posted February 27, 2016 Share Posted February 27, 2016 GPU queue size: 12 Das hatte ich in diesen Zusammenhang mal vorgeschlagen. Was ist bei dir eingestellt? Quote Link to comment
madshi Posted February 27, 2016 Share Posted February 27, 2016 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? Quote Link to comment
craig_s Posted February 28, 2016 Share Posted February 28, 2016 (edited) 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 February 28, 2016 by craig_s Quote Link to comment
madshi Posted February 28, 2016 Share Posted February 28, 2016 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... Quote Link to comment
craig_s Posted February 28, 2016 Share Posted February 28, 2016 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. Quote Link to comment
jasch Posted February 29, 2016 Share Posted February 29, 2016 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 Quote Link to comment
jasch Posted March 1, 2016 Share Posted March 1, 2016 (edited) So ich hab mal nen debug log gemacht. DVBViewer start -> 720p ->1080i -> 2160p ->1080i crash Das logfile ist leider sehr groß habs mal gepackt. Desweiteren ist mir aufgefallen das madvr zwar auf 2160p wswitcht aber im OSD steht scale 2160 -> 1080 ??? Mit MPC-BE steht draw 2160. http://www.xup.in/dl,54726154/madVR_-_log.7z/ Edited March 1, 2016 by jasch Quote Link to comment
jasch Posted March 2, 2016 Share Posted March 2, 2016 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. Quote Link to comment
craig_s Posted March 3, 2016 Share Posted March 3, 2016 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? 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.