Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Nur aus Interesse: Gab's denn tatsächliche Fälle, wo das Large Address Aware Probleme gemacht hat? Oder war das eher eine Vorsichtsmaßnahme, das Flag zu entfernen?

 

Meine Gedanken dazu: MPC-HC hat das Flag gesetzt, und es scheint keine Probleme zu machen. Das heißt, daß die üblichen externen DirectShow-Filter keine Probleme mit dem Flag zu haben scheinen. Probleme wären also hauptsächlich zu erwarten bei DVBViewer-eigenem Code. Sehe ich das richtig? Undokumentierte Delphi-Quellcode-Zeilen sind natürlich häßlich. Als ich meine Delphi-Quellen 64bit-fähig gemacht habe, war ein Schritt, im Quellcode nach "integer" zu suchen und alle Stellen, wo das verwendet wird (entweder direkt, oder über integer-Variablen), auf Pointer-Arithmetik zu untersuchen. Ist eine Menge Arbeit, aber wenn man da gleich das "integer" umwandelt in z.B. "NativeUInt" (das ist der von XE2+ verwendete Datentyp für ein cardinal in der Bittiefe des EXEs, den müßte man dann in Delphi 7 manuell definieren), dann ist der entsprechend geänderte Code nicht nur "Large-Address-Aware", sondern auch gleich 64bit-tauglich.

 

Ein anderer "Trick" wäre, die Allozierungs-Methoden/Funktionen im DVBViewer so zu manipulieren, daß sie immer im Bereich < 2GB allozieren. In Delphi gibt's da ja z.B. das "SetMemoryManager", mit dem man für alle Delphi-Allozierungen einen eigenen Speicher-Manager definieren kann. Der DVBViewer-Code müßte dann "nur" noch nach win32 APIs wie LocalAlloc/GlobalAlloc/VirtualAlloc untersucht werden. Das müßte eigentlich gleich den kompletten DVBViewer-Code Large-Address-Kompatibel machen. Der DVBViewer-Code selbst würde dann zwar nur die unteren 2GB verwenden, aber die externen Filter könnten dann halt 4GB verwenden, das wäre ja "gut genug".

Link to comment

Ich habe eine Änderung eingecheckt, was bei mir den Speicherbedarf bei 4K 10-bit HEVC um ~300mb oder so senkt, aber viel mehr ist nicht drin.

 

Hab noch eine kleinigkeit gefunden, was allerdings clip-abhängig ist. Mein Astra UHD clip verbraucht nochmal 100mb weniger, aber das muss nicht für alle gleich sein.

Link to comment

 

Hab noch eine kleinigkeit gefunden, was allerdings clip-abhängig ist. Mein Astra UHD clip verbraucht nochmal 100mb weniger, aber das muss nicht für alle gleich sein.

 

Super - danke - und weiter so! Morgen früh sind wir bei 1GB Ersparnis... :D Just kidding, of course...

Link to comment
Nur aus Interesse: Gab's denn tatsächliche Fälle, wo das Large Address Aware Probleme gemacht hat? Oder war das eher eine Vorsichtsmaßnahme, das Flag zu entfernen?

 

Vorsichtsmaßnahme. Ich konnte ja nicht wissen, wie massiv ihr Speicher vergeudet :) Allerdings gibt es genug Problemberichte im Forum mit ungeklärter Ursache.

 

Dass das Flag gesetzt wird, habe ich erst vor kurzem entdeckt. Da stand irgendwo gut versteckt zwischen anderen Compiler-Direktiven ein unschuldiges (und natürlich undokumentiertes) {$SetPEFlags $20}. Das habe ich dann aus Neugier recherchiert. Vorher wusste ich gar nicht, dass es sowas überhaupt gibt.

 

Ich würde sagen, 90% meiner Beschäftigung mit DVBViewer Pro / Recording Service Code besteht aus Suchen. Entweder im Code selbst oder im Internet.

Link to comment

Würde sagen das Flag muss wieder rein, da 64Bit kurzfristig nicht machbar. :P

 

Wenn der LAV auf Benutzer Wunsch 4k UHD in RGB ausgeben muss steigt der Speicherbedarf auch nochmal? Wären sicher noch andere Umstände denkbar mit ähnlichem Effekt.

Und ob man von der copyback Geschichte bei 10bit Quellen wegkommt ist doch auch fraglich?

Edited by nuts
Link to comment

Wenn der LAV auf Benutzer Wunsch 4k UHD in RGB ausgeben muss steigt der Speicherbedarf auch nochmal? Wären sicher noch andere Umstände denkbar mit ähnlichem Effekt.

 

Das sollte man nicht tun. Speicher wird nicht sonderlich stark ansteigen, aber die Performance von dieser Option wäre grauenhaft schlecht... :)

 

DXVA2-Native für P010 wäre mit madVR wohl theoretisch möglich, leider scheint es nicht so, als ob EVR das jemals ordentlich unterstützen wird - nicht in DirectShow.

Edited by nevcairiel
Link to comment

..kann ich bei mir bestätigen, DVBViewer 5.5.0 stürzt sofort ab wenn man bei aktivem madVR auf Astra UHD schaltet. 5.4.1 Beta lief dagegen super sauber.

 

-> gratulation an alle beteiligten - madVR ist seit einigen Versionen (alle Settings auf default) genauso "sparsam" wie EVR-Custom geworden! Die DVBViewer-"Kur" hat madVR offenbar gutgetan! ;)

Da ich keine Shader oder sonstige Extras im DVBViewer (und madVR) benutze sind mir keine Vor/Nachteile zw. madVR und EVR mehr aufgefallen. Auch nicht mit Scaling @ 2160p, bravo, damit kann man jetzt arbeiten.

 

Nun hat das 5.5.0-Update Schaden angerichtet, einige 4k-HEVC LAV-CB Tests,

 

es betrifft bei mir nicht nur madVR sondern auch mit EVR-Custom läufts nicht mehr flüssig (4k HEVC 10bit-Live-TV, -Mediawiedergabe gleichermaßen):

windowed - deutliches ruckeln

fullscreen - DVBViewer "verschwindet" dauerhaft. Die Balkenleiste kommt hoch wenn man mit der Maus den unteren Bildsch.Rand berührt. Beenden mit Taskmanager.

- im LAV P010 abhaken ändert daran nichts

 

 

Ein 4k HEVC 8bit Sample läuft hier dagegen mit madVR und EVR völlig problemlos!

 

Soweit erstmal.

Von welchem (zugewiesenem) RAM redet ihr hier eigentlich, GPU Memory?

Edited by craig_s
Link to comment

DXVA2-Native für P010 wäre mit madVR wohl theoretisch möglich, leider scheint es nicht so, als ob EVR das jemals ordentlich unterstützen wird - nicht in DirectShow.

Ja und das bedeutet auch, dass im Hauptspeicher mit decodierten Datenmengen hantiert werden muss.

Bei der internen 64Bit Diskussion kam etwas die Hoffnung auf irgendwann macht das die kleinste GPU von selbst wie bei H.264, aber ganz so einfach wird es wohl nicht werden.

 

@craig_s: Es geht um den Hauptspeicher (Arbeitsspeicher für CPU Aktivitäten).

Edited by nuts
Link to comment
@craig_s: Es geht um den Hauptspeicher (Arbeitsspeicher für CPU Aktivitäten).

 

und wo ablesen wieviel RAM gerade DVBViewer davon abzweigt?

Link to comment

Ich nutze für so was den Process Explorer wenn du da die einen einen doppelklick auf die DVBViewer.exe macht kannst du auch die Veränderung beobachten.

 

2015-07-28_230100.png

(DVB-T2 HEVC 720p 3,3 MBit/s zuerst Custom EVR dann wechsel auf madVR 88.17 und alles mit LAV 0.65.0.26)

Link to comment

 

Vorsichtsmaßnahme. Ich konnte ja nicht wissen, wie massiv ihr Speicher vergeudet :)

 

Haha! Glücklicherweise kann ich da jegliche Schuld von mir weisen, da laut Testergebnissen (siehe weiter oben im Thread) EVR ähnlich viel Speicher verbrät wie madVR... :innocent:

 

 

 

DXVA2-Native für P010 wäre mit madVR wohl theoretisch möglich

 

Kann durchaus irgendwann kommen. Muß mir nur erstmal Hardware besorgen, mit der ich das auch testen kann...

 

 

-> gratulation an alle beteiligten - madVR ist seit einigen Versionen (alle Settings auf default) genauso "sparsam" wie EVR-Custom geworden! Die DVBViewer-"Kur" hat madVR offenbar gutgetan! ;)

Da ich keine Shader oder sonstige Extras im DVBViewer (und madVR) benutze sind mir keine Vor/Nachteile zw. madVR und EVR mehr aufgefallen. Auch nicht mit Scaling @ 2160p, bravo, damit kann man jetzt arbeiten.

 

Oh, danke - das freut mich zu hören! :D

Link to comment

Danke Tjod, hier mein Ergebnis mit Intel Core i7-4790K - GTX 960

 

DVBViewer 5.5.0 --- LAV (CopyBack) 0.65.0.26

 

EVR-Custom (madVR 88.21)

 

SD - 241 (258) MB - Eurosport
720p - 325 (354) MB - ARD HD
1080i - 532 (490) MB - ServusTV HD
4k 8bit - 1,4 (1,4) GB - Media-Wiedergabe
4k 10bit - 1,6 GB (Absturz) - Astra UHD

Alles Live-TV außer 4k 8bit.

post-73651-0-93491400-1438124464_thumb.jpg

Edited by craig_s
Link to comment

Also ist madVR nicht Schuld am großen Speicherverbrauch, und der DVBViewer auch nicht. Die große Frage ist jetzt: Verbrät LAV so viel Speicher? Oder ist es vielleicht D3D?

 

Es ist schon LAV aber die Sache ist vielschichtig,

obwohl SD/HD jetzt nicht der *Feind* ist hier erst ein Vergleich - 'LAV CopyBack' braucht viel RAM gegenüber 'LAV native' (oder anderen DXVA Decodern):

 

LAV CB - (LAV native):

 

SD - 241 - (163) MB

720p - 325 - (209) MB

1080i - 532 - (262) MB

 

Bei 4k 10bit braucht PDVD Generic zwar wenig RAM...

4k 10bit - 1,6 GB - LAV CB (32bit)

4k 10bit - 913 MB - PDVD Generic (32bit)

 

...aber dafür steigt mit PDVD die CPU Usage von 7% auf >50% (Core i7-4790K), dh. eine etwas schwächere CPU als die eines Gaming PC dürfte damit derzeit schnell aus dem Tritt kommen.

 

Oder anders ausgedrückt, die sensationellen ~4-7% CPU mit denen LAV CB eine flüssige 10bit Wiedergabe auch auf schwächeren (GTX960)-PCs und in 32bit ermöglicht wird halt durch größeren Speicherhunger erkauft.

Aber viel Speicher haben ja heute alle ... und DVBViewer sollte langsam schon mal die 64bit ins Auge fassen, erst dann wird's richtig wirtschaftlich mit 4k, und schnell.. ;)

Edited by craig_s
Link to comment

Mit LAV 0.65.0.35 (von hier) nochmal probieren, speicher bedarf sollte jetzt hoffentlich ein gutes stück runter sein. :)

 

Edit:

Build ist jetzt auch up, gab wohl eine kleine netzwerk unterbrechnung letzte nacht.

Edited by nevcairiel
Link to comment

DVBViewer 5.5.0 - LAV (CopyBack) 0.65.0.35

EVR-Custom - madVR 88.21

SD 207 - 222 MB
720p 319 - 336 MB
1080i 489 - 433 MB
4k 8bit 1,1 - 1,2 GB
4k 10bit 1,4 GB - Absturz

4k 8bit - Verbesserung von 1,4 auf 1,1 GB

 

4k 10bit - Verbesserung von 1,6 auf 1,4 GB (EVR-C). Damit läuft's mit DVBV 5.5 schon mal ruckelfrei, sehr gut!

Die 1,4 GB die Process Explorer anzeigt müssen ja nicht genau stimmen (die Verhältnismessung schon) aber man kann 1,4-1,6 GB als 'obere Grenze' ohne "Large Address Aware"-Flag nehmen.

 

4k 10bit mit madVR (alles auf default) leider immernoch Absturz.

Ich habe dann in madVR alles Scaling auf DXVA umgestellt und die Decoder-Queue von 16 auf 8 reduziert.

Damit zeigt Process Explorer nun 1,3 GB an und auch madVR läuft windowed flüssig ohne Absturz!

 

Fullscreen stürzt zwar nicht ab zeigt aber Standbild (Fullscreen mit EVR-C einwandfrei).

Mit zugeschaltetem 'Fullscreen Exclusive Mode' kommt nach der Umschaltung erst Standbild, dann flackerts ausgiebig (Rechnerei), dann läuft Fullscreen aber ruckelt stark.

 

Ich würde sagen das "Large Address Aware"-Flag wieder reinmachen oder besser umschaltbar. Mit meinen wenigen 'Grundbedürfnissen' die ich an DVBViewer habe war 5.4.1 schon optimal.. ;)

Edited by craig_s
Link to comment

Also immernoch sehr knapp ohne das Large address flag.

Ohne wird es bei 4k schwierig werden.

Es wird auch noch Systeme geben, die durch Plugins usw. noch ein paar MB mehr Speicher benötigen als die schlanke Konfiguration (geh ich jetzt mal von aus) von craig_s.

 

Selbst wenn man den Crash noch irgendwie verhindert bekommt wird das trotzdem niemals flüssig laufen wenn der Arbeitaspeicher zuende ist.

Link to comment

..mega-schlanke DVBV Konfiguration, genau. Kein RecService, keine Shader, Plugins, extra Skins, PIP ...

 

Daher umschaltbar für Leute die mit "Large Address Aware"-Flag Probleme haben und nicht dauernd 4k testen müssen.. ;)

 

 

Dass das Flag gesetzt wird, habe ich erst vor kurzem entdeckt. Da stand irgendwo gut versteckt zwischen anderen Compiler-Direktiven ein unschuldiges (und natürlich undokumentiertes) {$SetPEFlags $20}. Das habe ich dann aus Neugier recherchiert. Vorher wusste ich gar nicht, dass es sowas überhaupt gibt.

 

Ich würde sagen, 90% meiner Beschäftigung mit DVBViewer Pro / Recording Service Code besteht aus Suchen. Entweder im Code selbst oder im Internet.

 

Hmm - wenn Griga das Flag grade erst "entdeckt" hat, es also die ganze Zeit gesetzt war, sollten die Probs damit eigentlich auch noch nicht entdeckt sein... :D

Edited by craig_s
Link to comment

Hier mein Testergebnis mit DVBViewer 5.5.0, MadVR und LAV (CopyBack) 0.65.0.35:

 

- mit NV12 Decoding funktionierts jetzt einwandfrei auf Astra UHD. Der Speicherverbrauch ist jetzt nur noch 710 MB.

- mit P010 Decoding wieder Absturz auf Astra UHD.

Link to comment

Test Update: Beim Umschalten zwischen 2 UHD Sendern (Astra UHD und Hotbird UHD) crasht 5.5.0 auch mit LAV NV12 Decoding noch. Scheint wohl nicht nur ein Speicherproblem zu sein.

Link to comment

- mit P010 Decoding wieder Absturz auf Astra UHD.

 

Probier mal in madVR 'image downscaling' und -upscaling auf DXVA, und Decoder-Queue auf 8 (alles andere default)

- damit läuft Astra UHD bei mir in einem ca. 1920x1080 Fenster im 4K-Screen einwandfrei auch mit umschalten (innerhalb Astra, habe nur Astra).

Also auch 'Astra UHD Demo' nach 'SES UHD Demo' stabil.

Edited by craig_s
Link to comment

Ich verwende Win 8.1 64 bit. Ein positives Ergebnis haben wir ja schon: Mit dem aktuellen LAV ist der Speicherverbrauch bei HEVC 4k Prozessierung um 400 MB verringert. Ich habe alle Settings in MadVR und LAV wieder auf meine Normalwerte gesetzt und werde erstmal weiterhin die 5.4.1 nutzen.

Link to comment

Um Klarheit über die Auswirkungen der Large Address Awareness zu erhalten, werde ich gleich für einen begrenzten Zeitraum eine Large_Address_Awareness_Test.zip mit einer DVBViewer.exe in den Mitgliederbereich, Beta-Sektion hochladen, in der das Flag wieder gesetzt ist - also wohlgemerkt kein Release, sondern nur für Testzwecke!

 

P.S. Ist oben.

Edited by Griga
Link to comment

Ok, danke für das Feedback. Richtig zusammenreimen kann ich es mir allerdings nicht, denn der Speicherverbrauch lag doch zuletzt sehr deutlich unter 2 GB, oder? Mal sehen, zu welchem Ergebnis craig_s kommt.

 

Der Kompromiss wird wahrscheinlich so aussehen, dass der DVBViewer zukünftig mit Large Address Awareness ausgeliefert wird, und der Recording Service, bei dem das Flag auch gesetzt war, ohne. Der braucht ja mangels Wiedergabe nicht so viel Speicher. Höchstens mal ein paar MB für einen großzügigen Streaming-Puffer.

 

Wenn ich daran denke, dass ich 2002, als ich den DVBViewer 1.9 bei Christian gekauft habe, einen PC mit Windows XP und 256 MB RAM hatte... und das reichte dicke. Irgendwie ist die IT maßlos. :wacko:

Link to comment

Wenn ich daran denke, dass ich 2002, als ich den DVBViewer 1.9 bei Christian gekauft habe, einen PC mit Windows XP und 256 MB RAM hatte... und das reichte dicke. Irgendwie ist die IT maßlos. :wacko:

 

P.S. Und bevor jetzt jemand erwidert, damals hätte es ja noch nicht mal HDTV gegeben: Natürlich gab es HDTV. Euro1080 über Astra in MPEG2. Das lief auf dem besagten PC mit dem DVBViewer bestens, weil die NVidia Graka (ebenfalls Baujahr 2002) schon DXVA konnte. Und weil es Decoder gab, die das nutzten. Für Historiker:

 

http://www.DVBViewer.tv/forum/topic/2869-DVBViewer-te-euro1080-bild-haengt-tonaussetzer/

Link to comment

Hehe cool der Thread.

Da wollte uns der damalige User (?) Griga doch ernsthaft erzählen HDTV wäre nix für die PC Gucker? :D

 

Mit DXVA copyback und 256mb RAM wäre das aber auch problematisch geworden?

Edited by nuts
Link to comment

Ich habe die RS beiträge mal ausgelagert da die nicht mal im entfernten was mit dem madVR Renderer zu tun haben.

 

http://www.DVBViewer.tv/forum/topic/56825-large-address-awareness/#entry431698

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

Ok, danke für das Feedback. Richtig zusammenreimen kann ich es mir allerdings nicht, denn der Speicherverbrauch lag doch zuletzt sehr deutlich unter 2 GB, oder?

 

Evtl. ist der speicher etwas fragmentiert, wenn etwas größere Speicher-Blöcke alloziert werden müssen (zB ein 4k 10-bit P010 Buffer), und kein zusammenhängender Speicher frei ist, dann crasht es auch unter 2GB.

Link to comment

Ok, bei mir ist mit 5.5.0.1 Large_Address_Awareness_Test auch madVR wieder voll integriert!

 

Wenn ich mir die Werte so ansehe misst @satsyl offenbar mit was anderem als ich (und Tjod). Nun ja, ich habe in meinem Leben schon viiiel gemessen und dabei gelernt - 'wer misst misst Mist' :)

Ich glaube auch 'Process Explorer' nicht wirklich und nehme mal an das wenn der 1,6 GB anzeigt sind die 2 GB erreicht und DVBViewer braucht noch irgendwo/irgendwie RAM wovon Process Explorer gar nichts bemerkt. Und/oder die 2GB sind nur graue Theorie d.h. Probs können schon einiges vor Erreichen des Wertes auftauchen, so in der Art..

 

madVR auf 'image downscaling' DXVA, und Decoder-Queue auf 8 (alles andere default) braucht windowed 1,4 GB, beim Schalten auf Fullscreen hab ich kurz gestaunt - 1,8 GB!

Zum Vergleich - bei EVR-C (1,4 GB) passiert beim auf Fullscreen schalten nichts.

 

Als nächstes in madVR wieder alles auf default (= 'image down' Catmull-Rom und Decoder-Queue auf 16) - 1,9 GB. Jetzt ändert sich beim Schalten auf Fullscreen nichts mehr.

Da ich wie oben beschr. festgestellt habe das bei (Process Explorer's) 1,6 GB ohne Large_Address_Awareness "Schluss" ist wundert mich nun gar nichts mehr ;)

Edited by craig_s
Link to comment

madVR auf 'image downscaling' DXVA, und Decoder-Queue auf 8 (alles andere default) braucht windowed 1,4 GB, beim Schalten auf Fullscreen hab ich kurz gestaunt - 1,8 GB!

Zum Vergleich - bei EVR-C (1,4 GB) passiert beim auf Fullscreen schalten nichts.

 

Als nächstes in madVR wieder alles auf default (= 'image down' Catmull-Rom und Decoder-Queue auf 16) - 1,9 GB. Jetzt ändert sich beim Schalten auf Fullscreen nichts mehr.

Da ich wie oben beschr. festgestellt habe das bei (Process Explorer's) 1,6 GB ohne Large_Address_Awareness "Schluss" ist wundert mich nun gar nichts mehr ;)

 

Interessant. Da ist mir ehrlich gesagt nicht klar, warum der Speicherverbrauch im Fullscreen-Modus so steigt. Rendering und Presentation findet ja auf der GPU statt, das sollte sich also eigentlich nicht auf das CPU-RAM auswirken. Ist aber auch schwierig zu durchschauen, weil's ja unendlich viele verschiedene Modi gibt (alter windowed mode, neuer windowed mode, Overlay, alter fullscreen windowed mode, neuer fullscreen windowed mode, alter FSE mode, neuer FSE mode, und dann das ganze nochmal mit D3D11 statt D3D9). Ich vermute, daß das Direct3D auch irgendwo die Finger mit im Spiel hat. Aber warum dann nicht bei EVR-Custom? Tja, weiß ich im Moment auch nicht. Aber bei 1,8GB bzw 1,9GB ist's natürlich klar, daß es dann mit 2GB Probleme gibt.

 

Aus technischer Sicht zeigen meines Wissens die üblichen Programme wie ProcessExplorer usw nur den tatsächlich *allozierten* Speicherverbrauch an. Man kann aber Speicher auch *reservieren*, ohne ihn zu allozieren. Das verbraucht dann zwar keinen Platz auf dem DDR3-Speicherchip. Aber reservieren verbrät vollen Platz im Adressbereich. Theoretisch könnte man einen Prozeß zum Absturz kriegen, indem man nahe an 2GB RAM reserviert, ohne irgendwas zu allozieren. Dann würde der ProcessExplorer anzeigen, daß kaum was alloziert ist, und trotzdem würde der Prozeß keinen weiteren Speicher mehr allozieren können, genauso als wäre der reservierte Platz auch alloziert. <seufz> Das war jetzt wahrscheinlich arg technisch? Kurz gefaßt: Nicht alles was wichtig ist wird von den üblichen Programmen auch angezeigt. Manches ist versteckt...

Edited by madshi
Link to comment

Unter Performance schlüsselt der ProcessExplorer dass noch deutlich weiter auf.

Wahrscheinlich ist Virtual Size die Größe die für die 2 GB grenze relevant ist.

cevr.png2015-07-30_005416.png

Da habe ich schon mit Custom EVR 522 MB und bei madVR 1,6 GB (HEVC 720p)

In der anderen Grafik wird der Wert von Privat Byts angezeigt, der ja deutlich niedriger ist.

Link to comment

Das war jetzt wahrscheinlich arg technisch?

 

Nein, das war ganz einfach zu verstehen :P

..und bestätigt meine weniger technischen Vermutungen oben.

 

Gerade kurzen Test gemacht, wenn ein AstraUHD Sample in MPC-HC 64bit läuft - verhält es sich genauso wie im DVBViewer, also:

madVR auf 'image downscaling' DXVA, und Decoder-Queue auf 8 (alles andere default) braucht windowed 1,3-1,4 GB, beim Schalten auf Fullscreen - 1,8 GB

Dann 'image down' Catmull-Rom und Decoder-Queue auf 16) - 1,9 GB, beim Schalten auf Fullscreen - keine Änderung

 

Erstaunt mich, hatte ich doch gehofft MPC und noch 64bit machen was anders..

 

"Quälversuche" mit 'image down' Lanczos/Spline 4 AR - kein Einfluß auf's RAM

Nächster "Quälversuch" - 'chroma upscaling' - nur NNEDI3 erhöhte von 1,9 auf 2,1 GB (+ Ruckeln). Dürfte eigentlich nicht sein da 4k windowed in einem 4k Screen immer downscaling ist, öm...

Womit man noch Process Explorer's 'Private Bytes' hochtreiben kann ist mit aufziehen/verkleinern des MPC-Fensters wärend das Video läuft, da gehts nochmal 100-200 MB hoch.

 

Bei einem kleinen Quälversuch ('image down' ändern wärend Astra UHD (Live-TV) lief) den ich aus versehen mit DVBViewer gemacht habe ist madVR sofort abgestürzt und schrieb mir einen "madVR - crash report.txt" aufs Desktop.

Auf Wunsch PM ich dir den.

 

Soweit erstmal, hoffe geholfen zu haben :)

Edited by craig_s
Link to comment
Wahrscheinlich ist Virtual Size die Größe die für die 2 GB grenze relevant ist.

 

Mit Sicherheit. Die Large Address Awareness bezieht sich auf den virtuellen Adressraum, den Windows einer Anwendung zugesteht. Das sind immer 2 oder 4 GB (je nach Flag), auch wenn man nur 1 GB RAM im PC hat. Was über das physikalische RAM hinaus belegt wird, landet für die Anwendung transparent in der Auslagerungsdatei.

 

Ich denke, damit ist die Sache geklärt. Ich räume die Testversion aus dem Mitgliederbereich wieder ab. Eventuell gibt es irgendwann in nächster Zeit ein Bugfix-Release, wenn wir genug Bugs zusammen haben :)

Link to comment

Unter Performance schlüsselt der ProcessExplorer dass noch deutlich weiter auf.

Wahrscheinlich ist Virtual Size die Größe die für die 2 GB grenze relevant ist.

attachicon.gifcevr.pngattachicon.gif2015-07-30_005416.png

Da habe ich schon mit Custom EVR 522 MB und bei madVR 1,6 GB (HEVC 720p)

In der anderen Grafik wird der Wert von Privat Byts angezeigt, der ja deutlich niedriger ist.

 

Waas? EVR 522MB und madVR 1,6GB?? Das hört sich nicht gut an. Hast Du eine besonders große CPU-/Decoder-Queue?

 

 

 

Nein, das war ganz einfach zu verstehen :P

..und bestätigt meine weniger technischen Vermutungen oben.

 

Gerade kurzen Test gemacht, wenn ein AstraUHD Sample in MPC-HC 64bit läuft - verhält es sich genauso wie im DVBViewer, also:

madVR auf 'image downscaling' DXVA, und Decoder-Queue auf 8 (alles andere default) braucht windowed 1,3-1,4 GB, beim Schalten auf Fullscreen - 1,8 GB

Dann 'image down' Catmull-Rom und Decoder-Queue auf 16) - 1,9 GB, beim Schalten auf Fullscreen - keine Änderung

 

Erstaunt mich, hatte ich doch gehofft MPC und noch 64bit machen was anders..

 

"Quälversuche" mit 'image down' Lanczos/Spline 4 AR - kein Einfluß auf's RAM

Nächster "Quälversuch" - 'chroma upscaling' - nur NNEDI3 erhöhte von 1,9 auf 2,1 GB (+ Ruckeln). Dürfte eigentlich nicht sein da 4k windowed in einem 4k Screen immer downscaling ist, öm...

Womit man noch Process Explorer's 'Private Bytes' hochtreiben kann ist mit aufziehen/verkleinern des MPC-Fensters wärend das Video läuft, da gehts nochmal 100-200 MB hoch.

 

Bei einem kleinen Quälversuch ('image down' ändern wärend Astra UHD (Live-TV) lief) den ich aus versehen mit DVBViewer gemacht habe ist madVR sofort abgestürzt und schrieb mir einen "madVR - crash report.txt" aufs Desktop.

Auf Wunsch PM ich dir den.

 

Soweit erstmal, hoffe geholfen zu haben :)

 

Wenn das Video downgescaled wird, gibt's für Chroma drei Varianten:

 

1) Wenn das Video nur weniger als 50% downgescaled wird, heißt das für Chroma, daß es ja immer noch upgescaled werden muß. Beispiel: Luma hat bei 4K die Auflösung 3840x2160. Chroma hat dann die Auflösung 1920x1080. Wenn nun das Video im Windowed Mode auf z.B. 2500x1600 runtergescaled wird, heißt das zwar, daß Luma runter-gescaled werden muß, aber Chroma halt immer noch rauf. Deshalb kann es auch im Windowed-Betrieb bei 4K noch sein, daß z.B. NNEDI3 für Chroma-Upscaling verwendet wird.

 

2) Wenn das Video auf 50% oder weniger downgescaled wird, wird Chroma (erst seit ein paar Wochen!) nicht mehr auf die originale Luma-Auflösung hochgerechnet, sondern stattdessen direkt auf die Zielauflösung. Wenn also 4K auf 1080p runtergescaled wird, muß bei Chroma gar nicht mehr gescaled werden. madVR muß in der Situation allerdings noch den Chroma-Channel um 0.5 Pixel verschieben, weil sonst die Position nicht stimmt.

 

3) Im Fall 2), wenn für "image downscaling" die Option "scale in linear light" aktiviert ist, dann *muß* madVR leider erst Chroma upscalen, obwohl es sinnlos scheint. Der Grund dafür ist, daß die Umwandlung in "linear light" nur in RGB möglich ist, und die Umwandlung nach RGB klappt nur, wenn Chroma die gleiche Auflösung wie Luma hat.

 

Den "madVR crash report.txt" hätte ich gerne. Manchmal hilft er nicht, manchmal hilft er. Kann nicht schaden, mal reinzugucken...

Link to comment

Danke für die allgemeinverständlichen Ausführungen! PM ist raus.

 

Interessant. Da ist mir ehrlich gesagt nicht klar, warum der Speicherverbrauch im Fullscreen-Modus so steigt. Rendering und Presentation findet ja auf der GPU statt, das sollte sich also eigentlich nicht auf das CPU-RAM auswirken. Ist aber auch schwierig zu durchschauen, weil's ja unendlich viele verschiedene Modi gibt (alter windowed mode, neuer windowed mode, Overlay, alter fullscreen windowed mode, neuer fullscreen windowed mode, alter FSE mode, neuer FSE mode, und dann das ganze nochmal mit D3D11 statt D3D9). Ich vermute, daß das Direct3D auch irgendwo die Finger mit im Spiel hat. Aber warum dann nicht bei EVR-Custom? Tja, weiß ich im Moment auch nicht. Aber bei 1,8GB bzw 1,9GB ist's natürlich klar, daß es dann mit 2GB Probleme gibt.

 

Nun ja, jedenfalls in madVR ist bei mir wirklich ALLES bis auf das jeweils Beschriebene auf default mittels "restore default settings.bat". Da müsstest du doch schon genau wissen was gerade läuft bzw. was default bei madVR so an Settings setzt. Evl. hilft noch ein Screenshot (da steht zB. D3D9):

-> DVBViewer 5.5.0.1 - Astra UHD windowed - in madVR gerade ALLES auf default ausser 'Fullscreen Exclusive Mode',

den schalte ich gerne aus weil Pause und Flackern beim Umschalten etwas nervt. Außerdem ist DWM (Win7-Aero) an.

 

Nicht irritieren lassen, es läuft mein neues 'Special-Aero-Night Theme' das ich mir gerade zum schonmal "Üben für Win10 ohne Classic Themes" gebaut habe, daher ist alles schön dunkel.

@ Griga: Screenshot unskaliert bei Win7 auf 100% ebenfalls unskaliert.

 

post-73651-0-99896400-1438260750_thumb.jpg

Edited by craig_s
Link to comment

Waas? EVR 522MB und madVR 1,6GB?? Das hört sich nicht gut an. Hast Du eine besonders große CPU-/Decoder-Queue?

Bewusst habe ich die nie geändert, die stand auf 16.

Ich habe das jetzt mal auf 8 gesenkt. Damit geht das dann auf 1,2 GB runter.

 

Nachtrag: Das ganze war immer im Volbildmodus 2560x1440

 

Wenn ich das Statistik OSD eingeblendet habe gibt es nach einem Sender wechseln mach mal kurz die Meldung "creating dxav processing surface failed" oder "dxav processing failed" aber das gibt sich nach 1-2 Sekunden wieder. Keine Ahnung ob das was zu bedeuten hat.

Edited by Tjod
Link to comment
Wahrscheinlich ist Virtual Size die Größe die für die 2 GB grenze relevant ist.

 

Jedenfalls kommt Virtual Size schon nahe dran,

bei diesem Test: LAV wieder zurück auf v. 0.65.0.26 womit ja AstraUHD@EVR-C in DVBV 5.5 windowed zwar leicht ruckelte aber lief, da geht Virtual Size deutlich über 2 GB - auch mit der Fenstergröße die ich damals offen hatte. EDIT: siehe Korrektur unten

 

'Virtual Size' reagiert nämlich im Gegensatz zu 'Private Bytes' intensiv auf Größenänderung des Fensters.

 

Also nochmal alles mit 'Virtual Size':

Eigentlich hätte ich ja gerne Fullscreen gemessen aber mit nur 1 Bildschirm war das mit Process Explorer nicht möglich.

Um möglichst nahe an Fullscreen ranzukommem habe ich das DVBViewer Fenster so weit aufgezogen wie möglich - 3506*1972.

 

Wenn ich dann auf Fullscreen 3840*2160 geschaltet habe und wieder auf 3506*1972 zurück konnte ich im Process Explorer gerade noch sehen dass die 'Virtual Size' Differenz nur ca. 100MB betrug, also nicht viel. Diese Übung aber für jede Testkombi zu machen war mir zu stressig. :wacko:

 

Also:

DVBViewer Pro 5.5.0.1 - LAV (CopyBack) 0.65.0.35 (.26 wo es dabeisteht) - madVR 88.21 (alles auf default)

 

Window: 3506*1972

 

576i - Eurosport

720p - ARD HD

1080i - ServusTV HD

2160p - Astra UHD

 

Wie man sieht kann madVR mit 2,8 GB ganz schön zulangen, mit LAV .26 gings sogar bis 3,3 GB.

Aber ich seh das gelassen - mit der kommenden 4k-Computergeneration werden, auch bei Laptops, schon wieder viel mehr RAM eingebaut..?

 

post-73651-0-42613800-1438284966_thumb.jpg

Edited by craig_s
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...