Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Leider funktioniert die Deinterlacing Umschaltung mit DVBViewer 4.8.1 und MADVR v0.88.21 auch nicht korrekt. Die für mich am besten funktionierende Kombination (auch mit UHD) ist bisher DVBViewer 4.8.1 und MADVR v0.88.16.

Link to comment

Hm ok ich schau mal (dauert leider etwas).

Also 5.5 zusammen mit 0.88.16 geht auch nicht?

Hab leider keine Idee wie madshi das per File nachstellen könnte.

Link to comment

Das Deinterlacing funktioniert mit der Testbuild 0.88.21b jetzt auch mit DVBViewer 5.4.1 korrekt.

 

Bzgl. UHD Crash, ich habe im LAV alles auf DXVA-CB eingestellt. Das funktioniert auch bei HEVC mit meiner GTX 960 einwandfrei. Leider nicht in 5.5.0 mit MADVR.

Link to comment

Echt? Das ist mir gar nicht aufgefallen. :(

 

Also nochmal zum mitschreiben:

HEVC UHD mit 5.5.0 und madVR 0.88.21b => crash

HEVC UHD mit 5.4.1 und madVR 0.88.21b => läuft

HEVC UHD mit 5.5.0 und EVR Custom?

Link to comment

Nee, ich glaube das mit HEVC UHD hat nix mit der madVR-Version zu tun (kann ein Bug in madVR, LAV oder DVBViewer sein, keine Ahnung).

 

Was die 0.88.21b fixt ist das Deinterlacing.

Link to comment

Denke ich auch nicht, aber möchte das nachvollziehen können um das selbst zu testen. ;)

 

So aus dem Kopf heraus fällt mir nämlich gar keine Änderung zwischen 5.4.1 und 5.5.0 ein die in diese Richtung geht.

Kann leider erst am Wochenende "eingreifen".

Edited by nuts
Link to comment

A wild guess: Könnte es vielleicht einfach am Speicherverbrauch liegen? 4K benötigt natürlich mehr RAM als 1080p, und madVR hat ja ne recht ordentlich dimensionierte Decoder-Queue im CPU-RAM liegen. Versuch doch mal, die Größe der CPU-Queue in den madVR-Einstellungen zu verkleinern. Hilft das? (Wobei ich nicht weiß, warum es dann mit einer DVBViewer-Version laufen sollte und mit einer anderen nicht).

Link to comment

 

Ja wieso das mit 5.4.1 läuft und 5.5.0 crasht ist wirklich etwas seltsam.

 

Griga hat die Large Address Awareness deaktiviert, weil der Programmcode teilweise nicht dafür ausgelegt war und üble Bugs zur Folge hatte. Dadurch bekommt der DVBViewer jetzt nur noch 2 GB RAM zugewiesen.

 

Hier noch, was Griga zu den Konsequenzen geschrieben hat:

 

Die Konsequenz kann eigentlich nur lauten: Weg mit dem Flag und mit 2 GB Adressraum begnügen. Normalerweise sollte das dicke reichen. Allerdings: Bilder mit 4k-Auflösung stehen vor der Tür, die unkomprimiert richtig Platz benötigen. Wenn man 4 Byte pro Pixel rechnet, kommt man pro 4k-Bild auf ca 33 MB. Davon passen etwa 64 in den 2 GB-Adressraum. Zwar wird ein Videorenderer normalerweise nicht so viele Frames in der Warteschlange halten, aber trotzdem wird das schon ein bisschen eng...

 

Allerdings würde ich mir auf Grund von Speicherknappheit keinen Crash erwarten!?

Link to comment

Naja, theoretisch, wenn jeder Code alle Allozierungen prüft und im Fehlerfall perfekt reagiert, sollte es keine Crashes geben, das ist richtig. Aber das Problem ist ja, wenn ein Prozeß an sich RAM-Probleme hat, dann kann jedes DLL, jeder Filter in die Situation laufen, daß eine Allozierung fehlschlägt, und da würde ich nicht drauf wetten, daß z.B. alle DirectShow-Filter perfekt sauber programmiert sind. Kann durchaus sein, daß ich auch in madVR da nicht an allen Stellen jede noch so kleine Allozierung prüfe. <schäm> Bin mir auch nicht sicher, wie z.B. die C++ oder Delphi RTL reagiert, wenn da Klassen instanziert werden sollen, aber die Allozierung fehlschlägt. Was passiert dann? Bin nicht sicher. Aber zuerst Mal sollten wir feststellen, ob's wirklich am RAM liegt oder nicht. War ja nur eine wilde Vermutung von mir...

 

Gibt's eigentlich Pläne für eine 64bit DVBViewer-Version? Da gäb's das Problem mit Speicher dann nicht mehr.

Link to comment

Naja Crash hin oder her, wenn 2GB für UHD nicht ausreichen muss zumindest die Large Address Geschichte wieder ins Blickfeld.

 

@satsyl: Welches OS verwendest du? 32/64Bit?

Link to comment

Dafür müsste man den Delphi Code von Delphi 7 auf XE2 bzw. 5 hieven :) Das ist arg aufwändig, zumal strings da widestring sind.

Link to comment

2GB sollten eigentlich schon ausreichen, notfalls muß halt die madVR-Frame-Queue etwas runter geschraubt werden. Da gibt's schlimmeres. Vielleicht kann ich die Frame-Queue auch bei 4K automatisch limitieren, um es für die User einfacher zu machen. Wenn denn der Speicherverbrauch wirklich das Problem ist! Das haben wir ja noch nicht wirklich bestätigt bekommen.

 

@hackbart, ja, ich kenne das Problem sehr gut, hab selbst schon mehrere solche Umstellungen von Delphi 7 -> XE2+ gemacht. Zum einen die WideStrings, zum anderen die ganzen 32bit vs 64bit Typ-Sachen, wie daß ein Pointer plötzlich 64bit lang ist. Wenn man da dann z.B. Informationen in Records speichert, muß man total aufpassen, daß sich die Größe des Records nicht ändert usw. Diese ganzen Umstellungen können schon recht schmerzhaft und zeitaufwendig sein - und auch neue Bugs mit sich bringen... :( Immerhin ist's meiner Erfahrung nach so, daß wenn die Umstellung einmal erledigt ist (inklusive Bugfixing usw), es ab da so gut wie keine extra Arbeit mehr ist, 64bit zu unterstützen.

Link to comment

Ich habe noch ein wenig getestet. Es scheint tatsächlich Ressourcenprobleme zu geben. Ich hatte bisher im LAV die P010 Decodierung aktiv. Der Speicherverbrauch vom DVBViewer ist hier 1,3GB (D3D9 Rendering) bzw. 1,4GB (DX11 Rendering).

--> Crash in 5.5.0

 

Schalte ich die P010 Decodierung inaktiv wird NV12 benutzt und der Speicherverbrauch wird reduziert auf 1GB (D3D9 Rendering) bzw. 1,1GB (DX11 Rendering).

--> kein Crash mehr in der 5.5.0, es funktioniert aber nicht so problemlos wie in der 5.4.1 (z.B. wird beim Wechsel von Fenster in Vollbild von MADVR ein D3D Initialisierungsfehler gemeldet).

Link to comment

Und das alleine hatte noch nicht als "Lösung" gereicht? Zusätzlich mußtest Du auch noch P010 deaktivieren?

 

Ich frage mich, wo da so viel Speicher verbraten wird! Ich meine, ein 4K-Frame mit P010 sollte gut 26MB verbraten. Ist natürlich ordentlich. Aber selbst bei einer Decoder-Queue von 16 Frames wären das "nur" 425MB. Das ist immer noch *weeeeeeeit* weg von 1.3GB. Kannst Du mal ein paar Tests machen, um herauszufinden, wer so viel RAM verbrät? Ist es madVR? Um das herauszubekommen, könntest Du mal testen, wieviel Speicher z.B. beim EVR verbraucht wird? Und dann stell doch mal die Decoder-Queue in madVR so niedrig ein wie es nur geht und miß dann nochmal den Speicherverbrauch. Gibt's dann nen riesigen Unterschied zwischen madVR und EVR? Interessant wäre auch ein Test verschiedener Decoder, und vielleicht auch mal mit einem anderen Media-Player, um zu checken, ob's am Decoder oder am DVBViewer liegt, falls es nicht madVR's Schuld ist.

 

Jedenfalls scheint mir 1.3 bzw 1.4GB doch arg viel zu sein...

Link to comment

Der Speicherverbrauch ist nicht groß unterschiedlich (LAV mit NV12):

 

DVBViewer mit MADVR (D3D9 Rendering, alle Queues auf 8): 1 bis 1,1 GB

 

DVBViewer mit Custom EVR (D3D9 Rendering): 1 bis 1,1 GB

 

MPC-BE mit MADVR (D3D9 Rendering, alle Queues auf 8): 0,9 bis 1 GB

Link to comment

Ok, das ist interessant. 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?

 

Hat jemand ein h264 oder MPEG2 4K Sample zum Testen für satsyl? Dann kann er mal mit einem anderen Decoder und Software-Decoding testen...

 

P.S: Interessant wäre auch der Speicherverbrauchs-Vergleich zu 1) DXVA-Copyback-Decoding mit 1080p-Content und 2) Software-Decoding mit 1080p-Content.

Edited by madshi
Link to comment

Ist das mit DXVA Copyback oder mit Software-Decoding? Gibt's da nen Unterschied zwischen?

 

Das ganz macht aber nicht wirklich so viel Sinn. Die Framerate sollte keinen Unterschied machen. Und ich sehe nicht, warum HEVC mehr Speicher verbraten sollte als h264. Schon gar nicht 400MB mehr. Ich denke, ich werd mal den nevcairiel (LAV Developer) anfragen, ob er da eine Erklärung für hat...

Link to comment

Das sieht für mich jetzt nach dem Umkopiervorgang aus.

Und ob der H.264 Clip jetzt nach dem Decoder eine vergleichbare Größe wie der HEVC Clip hat wissen wir auch nicht.

 

Vielleicht fällt dem nevcairiel ja was ein, aber scheint mir insgesamt zu sehr am Limit die 4K HEVC Geschichte. :(

Edited by nuts
Link to comment

nevcairiel hat gerade geantwortet: Er meint, für 4K wäre ein 64bit MediaPlayer schon eigentlich die passendere Variante, auch weil HEVC Software-Decoding in 64bit viel schneller ist als in 32bit. Aber er will mal gucken, ob er vielleicht noch was optimieren kann in Sachen Speicherverbrauch...

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.

Das Problem ist, dass der Speicher vom NVIDIA treiber belegt wird. Meiner Theorie nach reserviert der Treiber für jedes Video Frame (D3D Surface) einen entsprechenden Buffer im Hauptspeicher, so dass der Treiber dann per DMA das Video Bild rüberkopieren kann, wenn ich ihn danach frage.

Eigentlich ist das ein super feature, weil das Copy-Back schneller macht, aber wenn man es nun eine ganze Menge 4K 10-bit Video Bilder gibt, belegen die schon eine Menge Speicher...

 

Am besten morgen mit dem neuen nightly build einmal testen. Ob die 300mb nun so viel helfen ist schwer zu sagen, aber es gibt zumindest etwas mehr puffer.

 

PS:

DVBViewer crasht schon bei 2GB? Ideallerweise sollten bis 4GB gehen, wenn alle komponenten als "Large Address Aware" geflaggt sind.

Edited by nevcairiel
Link to comment

Hey, super daß Du hier direkt vorbei schaust... :D

 

Das Problem ist wahrscheinlich dadurch ausgelöst worden, daß die neuste DVBViewer-Build gerade das "Large Address Aware"-Flag *gelöscht* hat, weil das an anderer Stelle Probleme gemacht hat. Von daher, wenn die neue LAV-nightly bei gleicher Leistung mal eben so 300MB einspart, ist das schon ein recht großer Fortschritt, gemessen daran, daß wir mit 2GB auskommen müssen.

Link to comment
DVBViewer crasht schon bei 2GB? Ideallerweise sollten bis 4GB gehen, wenn alle komponenten als "Large Address Aware" geflaggt sind.

 

Der DVBViewer war entsprechend geflaggt, aber ich habe das wegen nicht absehbarer Nebenwirkungen im 5.5-Release rausgenommen. Es braucht sich ja nur irgendeine DLL bei der Adress-Arithmetik vorzeichenbehaftet daneben benehmen, und schon knallt es.

 

Falls die Nachteile überwiegen sollten, mache ich es wieder rückgängig, und nach mir die Sintflut :innocent:

Link to comment

Hallo und willkommen nevcairiel. :)

 

Die Large Address Awareness Rücknahme muss vielleicht nochmal überdacht werden?

Ist doch alles zu knapp. 2020 (?) kommt 8k? Dann sind wir völlig am Ende ...

Selbst wenn nix mehr crasht wird das vermutlich nicht flüssig laufen wenn der Arbeitsspeicher nicht ausreicht.

Link to comment

Für 8K brauchst du auf jedenfall 64-bit, eigentlich würde ich das schon für 4K fast als Grund Vorrausetzung sehen. Aber dass die Umstellung nicht immer so einfach ist, ist mir durchaus bewusst. Mein Brötchengeber hat auch nur 32-bit derzeit.... :)

Link to comment

Es braucht sich ja nur irgendeine DLL bei der Adress-Arithmetik vorzeichenbehaftet daneben benehmen, und schon knallt es.

 

P.S. Außerdem sind mir nach Lars' Abschied unvermutet über 1.000.000 nahezu undokumentierte Quellcode-Zeilen (Delphi 7, strikt 32 Bit) zugefallen, die ich bislang nur zum Teil durchschaue, und ich würde nicht meine Hand dafür ins Feuer legen, dass die alle sauber sind. ;) Wer die Nerven und das Können hat, den Kram auf 64 Bit umzustellen, ist herzlich eingeladen. :)

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