Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Die madVR-eigenen OSD-Einblendungen sind im Moment nicht ausschaltbar. Das ist ein weiterer Punkt auf meiner ToDo-Liste. Kann halt nicht alles auf einmal machen...

Link to comment

Joo kein Stress, mich stört es sowieso nicht. :)

Wenn du da mal dran gehst: Ich würde dann auch unterscheiden zwischen automatischen OSD Einblendungen (potentiell störend) und durch den Benutzer gewollte Einblendungen (Strg+j => kann nicht stören, da gewollt).

Link to comment

Ich freue mich sehr, dass sich jetzt eine so fruchtbare Zusammenarbeit ergeben hat und über Euer gemeinsames Weihnachtsgeschenk an uns in Form des madVR im DVBViewer.

 

:original:

 

Herzlichen Dank an alle Devs und Tester die das stemmen :showoff:

 

 

Link to comment

O.k. .. Die Diskussion Bildqualität . AMD vs. Nvidia in jeglicher MadVR config. gibts ja schon lange auf Doom und AVS. . Mein augenblicklicher Stand :

 

(ich sag jetzt mal dazu , dass ich durch eine glückliche Fügung Zugang zu den meisten neuen GPUs habe )

 

 

a. Die neuen Generationen nVidia und AMD unterscheiden sich im Hi- End Bereich in Beziehung PQ i.m.h.o. kaum .

b. Sie unterscheiden sich aber sehr wohl in der Treiber- Softwareentwicklung.

c. Bei beiden Anbietern funktioniert ein Treiber gut , der nächste diametral schlecht.(was MadVr betrifft)

d. UND Das ist DAMIT für das zufriedenstellende Funktionieren von MadVR von essentieller Bedeutung.

 

Beispiel (schon mal angeführt) : zwischen einem ATI Treiber Catalyst 14 xxxx und einem Catalyst Treiber 13.12

klafft ein essentieller Unterschied . (und das entscheidet über Wohl und Wehe) .

 

Und leider so elitär das klingt :

Spass macht diese ganze Geschichte mit einer Nvidia GT 8800 oder ATI 4650 beileibe nicht. Forget it.

Link to comment

Sollte man nicht besser diesen thread teilen? Ich wäre für einen inhaltlichen teil und einen für allgemeine meinungsäusserungen. Ich würde wenn überhaupt selbst wahrscheinlich nur im 2.thread schreiben, denn meine prioritäten liegen auf einer anderen ebene. Zum gucken verwende ich lieber für diesen zweck gebaute fernseher. Da die immer smarter werden, würde ich es bevorzugen, entwicklungsressourcen für UPnP und DLNA freizumachen. Irgendwann in diesem jahr werde ich wahrscheinlich in die 4k-liga aufsteigen. Mein vorhandener i7 könnte den über HDMI doch nicht mit HEVC UHD füttern, egal welcher renderer noch kommt :horror:

  • Like 1
Link to comment

Interessant wäre dann noch der GPU-Power-Vergleich zwischen EVR und madVR im DVBViewer. Denn ich glaube bei AMD wird das Scaling auch per PixelShader gemacht. Wahrscheinlich hat AMD da aber einen deutlichen Power-Vorteil, weil die ja direkt an die Hardware dran kommen, und nicht wie ich Umwege über komplizierte Direct3D-PixelShader machen müssen...

 

Ich habe vor längerem mal einen Renderer-Verbrauchs-Vergleich auf ner Intel iGPU gemacht. Wenn im EVR-CP im MPC-HC "Bikubisch -A1.00" eingestellt war brauchte er etwa gleich viel wie der EVR Custom im DVBV.

"Bikubisch -A1.00" war aber natürlich einiges schärfer.

madVR zog in der Default-Einstellung einiges mehr. Bei den EVR ging im MPC aber auch immer das DXVA-"Lämpchen" an, bei madVR nicht. Ich habe hier auch AMD GPUs die zeigen das gleiche Verhalten.

 

Wäre madVR da schon im DVBV gelaufen hätte der Verbrauch wohl sehr ähnlich ausgesehen wie im MPC-HC. Wenn Christian soweit ist kann man ja nochmal testen.

Link to comment

Das DXVA Lämpchen geht mittlerweile schon an. ;)

Interessant wäre mit Intel GPU: madVR mit DXVA2 Decoder (LAV) und DXVA Scaler vs Standard EVR mit DXVA2 Decoder (LAV)

 

Habe leider nix da zu messen.

Link to comment

... Aber wenn du dir jetzt vorstellst, wie das ganze bei einer Bildbreite von um 3m aussieht, und noch daran denkst, das viele aus der Heimkinofront auch noch hunderte von DVD's in ihrer Sammlung haben, dann verstehst du jetzt unseren Wunsch nach dem MadVR vielleicht etwas besser.

Dazu kommen dann auch noch die schon durchgekauten zusätzlichen Features

Heimkino ist nun mal was für "etwas verrückte".

 

:thumbsup: Ich freu mich auf jeden Fall wie Bolle auf die nächste DVBViewer-Version :thumbsup:

 

..übrigens, hatte ich schon erwähnt das ich seit 2011 ein Homecinema mit JVC D-ILA Projektor habe :P, den gleichen den Gaddafis Sohn in seinem Londoner Appartment hatte, wie ich später bei einem Dreh feststellen durfte.

Mein Eindruck war aber immer das gerade Projektoren ein kräftiges Eigenleben in Sachen Bildverbesserung haben und hatte kaum nen Gedanken an noch mehr Verbesserung.

Ich habe allerdings keine große DVD Sammlung, nur TV-Aufzeichnungen und die fangen fast alle bei 720p an.

 

 

Irgendwann in diesem jahr werde ich wahrscheinlich in die 4k-liga aufsteigen. Mein vorhandener i7 könnte den über HDMI doch nicht mit HEVC UHD füttern, egal welcher renderer noch kommt :horror:

 

Sag das nicht, habe 4K gerade auf ner i5 Ivy-Bridge zum Laufen bekommen. Video unskaliert läuft immerhin flüssig (mit EVR). *hier*

Link to comment

Mein Eindruck war aber immer das gerade Projektoren ein kräftiges Eigenleben in Sachen Bildverbesserung haben und hatte kaum nen Gedanken an noch mehr Verbesserung.

Die JVC Projektoren sind schon nicht so schlecht fürs Videoprocessing, aber mit dem PC als Zuspieler nützt der JVC nicht so viel. Der sollte vom PC mit seiner nativen Auflösung (in RGB) gefüttert werden und somit spielt das Processing im PC wieder eine Rolle. Die Mediaquellen möglichst direkt hinter dem Decoder abzugreifen und dem JVC zu füttern geht mit dem PC einfach nicht.

 

Du kannst ja deine Versuche mal dann am Projektor fortsetzen. Dann sollte man ja was sehen!

Link to comment

...gleich natürlich nur was das Verhältnis Auflösung bzw. Pixelgröße -> zu Betrachtungsabstand angeht. Da sehe ich nah vorm TV/Moni die Fehler meist genauer als im Kino.

Das Kino-Bild ist nach einiger Kalibrierung wiederum so atemberaubend das es mir schwer fällt mich auf Fehler zu konzentrieren. Da will ich nur noch Film gucken. Mit hochauflösendem Quellmaterial.

Edited by craig_s
Link to comment

Irgendwann in diesem jahr werde ich wahrscheinlich in die 4k-liga aufsteigen. Mein vorhandener i7 könnte den über HDMI doch nicht mit HEVC UHD füttern, egal welcher renderer noch kommt :horror:

Sag das nicht, habe 4K gerade auf ner i5 Ivy-Bridge zum Laufen bekommen. Video unskaliert läuft immerhin flüssig (mit EVR). *hier*

..gut den thrad habe ich mal überflogen. Über die dekodierung von HEVC UHD steht dort nichts. Höchstens dass selbst eine aufzeichnung ruckelt. Irgendwann wird man den typ natürlich auch im griff haben, aber bis jetzt gibt es noch kein funktionierendes dxva. Und wenn, ist meine gpu vielleicht nicht ausreichend. Ganz schweigen von HDM ;)

 

Ich wollte damit auch nur sagen, dass ich mir ein gerät kaufen werde, das funktioniert :D

Link to comment

Schuld am Flackern ist bei mir das aktivierte "switch to matching display mode".

Und auch das "enable automatic fullscreen exclusive mode" per default aktiviert ist halte ich für keine gute Idee.

 

Ich habe eine weile Gebrauch um heraus zu finden was beim MadVR das Optionen Fenster auf dem zweiten Monitor unbedienbar macht.

 

Und auch sonst gibt es noch einige meiner Meinung nach ungünstiege Default werte.

 

Daher die Frage gibt es einen weg gezielt einige Einstellungswerte zu auf bestimmt Einstellungswerte zu setzen z.B. per .bat oder .reg Datei?

Also jetzt ohne die ganze Hex Codierte Binärdatei unter HKEY_CURRENT_USER\Software\madshi\madVR\Settings zu ersetzen? Da in der dann ja auch die Systemspezifischen Sachen wie die zum Monitor enthalten sind.

 

Also um was zu haben um einfach auf möglichst unproblematische werte zurück zu kommen.

 

Nachtrag:

OK zumindest über die API scheint das Setzen von einzelnen Werten möglich zu sein

Edited by Tjod
Link to comment

Ich hätte auch mal ein paar Fragen und hoffe, dass madshi sie beantworten kann :) .

 

 

Problem 1:

Bei Umschaltung von 1080i Kanälen auf 720p Kanäle (bei 1080p Ausgabe) wird das 720p Bild unskaliert im oberen linken Bildrand angezeigt. madVR Statistics zeigt dann als "Target Rectangle" die Source-Auflösung 1280x720 anstatt der Ausgabeauflösung 1920x1080 an.

 

Lösung 1: "Schneller Senderwechsel" in den DVBViewer Optionen deaktivieren und so bei jedem Umschaltvorgang einen kompletten Graph-Rebuild erzwingen.

Lösung 2: A/V Formaterkennung für den DVBSource Filter aktivieren. Der Video-Zweig wird dann neu verbunden, wenn sich die Quellauflösung ändert.

 

Beide Lösungansätze verzögern den Umschaltvorgang erheblich. Es geht deutlich schneller, wenn Dekoder und Renderer das selber ermitteln. Die haben auf einem tieferen Niveau die besseren Möglichkeiten als der Source-Filter. Die Quellauflösung wird aber eigentlich ja richtig erkannt...

 

Als Dekoder wird übrigens LAV im DXVA-Modus (Intel) eingesetzt.

 

 

Problem 2:

Je nach Einstellungen hat man mehrere Schwarzblenden pro Umschaltvorgang (was Tjod bereits als Flackern bezeichnet hat). Da wird dann auch das Mini-EPG-OSD jeweils kurz ausgeblendet. Ich konnte diese Schwarzblenden jetzt per Einstellungen auf eine einzige reduzieren (A/V-Formaterkennung im DVBSource Filter, Fullscreen Exclusive ohne Verzögerung bzw. ganz abgeschalten). Ich frage mich allerdings, ob das wirklich nötig ist? Wenn der Graph nicht neu instanziiert wird, bleibt doch auch madVR am Leben. Ich nehme an, dass bei einem Graph Stop auch kein OSD mehr gezeichnet wird? Kann man madVR nicht instanziiert lassen und gewährleisten, dass OSD immer funktioniert?

 

Ich habe mir auch überlegt, ob nicht der DVBViewer das D3D-Device (via IMadVRDirect3D9Manager) zur Verfügung stellen sollte!? Dann könnte der immer OSDs malen. Aber im D3D Fullscreen Exclusive hat man dann wahrscheinlich Probleme, weil es nur eine Swap Chain gibt und madVR seine Video-Frames nicht parallel zum DVBViewer OSD zeichnen kann, oder?

Link to comment

Und auch sonst gibt es noch einige meiner Meinung nach ungünstiege Default werte.

 

Daher die Frage gibt es einen weg gezielt einige Einstellungswerte zu auf bestimmt Einstellungswerte zu setzen z.B. per .bat oder .reg Datei?

Also jetzt ohne die ganze Hex Codierte Binärdatei unter HKEY_CURRENT_USER\Software\madshi\madVR\Settings zu ersetzen? Da in der dann ja auch die Systemspezifischen Sachen wie die zum Monitor enthalten sind.

 

Also um was zu haben um einfach auf möglichst unproblematische werte zurück zu kommen.

 

Nachtrag:

OK zumindest über die API scheint das Setzen von einzelnen Werten möglich zu sein

 

Die Einstellungen lassen sich komplett per API ändern. Leider im Moment nur global für den ganzen PC (was sich also auch auf andere Media-Player auswirken würde). Von daher würde ich im DVBViewer jetzt nicht einfach gnadenlos ohne Rückfrage alle Einstellungen überbügeln. Man könnte eventuell im DVBViewer einen Knopf machen, um auf Wunsch ein paar Einstellungen gezielt zu ändern. Oder ich muß halt (ist eh geplant) in madVR einbauen, daß der DVBViewer Einstellungen auch gezielt nur für die aktuelle Session ändern kann, statt global.

 

Es ist aber auch schwierig, allgemein gültige Einstellungen zu finden, weil sich das je nach GPU, OS und Treiber-Version unterschiedlich verhalten kann. Da müßte man das erstmal richtig recherchieren, welche Einstellungen für den DVBViewer wirklich am meisten Sinn machen, für alle GPUs und OSs usw. Aber das sollte ja möglich sein, da etwas zu finden...

 

 

Problem 1:

Bei Umschaltung von 1080i Kanälen auf 720p Kanäle (bei 1080p Ausgabe) wird das 720p Bild unskaliert im oberen linken Bildrand angezeigt. madVR Statistics zeigt dann als "Target Rectangle" die Source-Auflösung 1280x720 anstatt der Ausgabeauflösung 1920x1080 an.

 

Lösung 1: "Schneller Senderwechsel" in den DVBViewer Optionen deaktivieren und so bei jedem Umschaltvorgang einen kompletten Graph-Rebuild erzwingen.

Lösung 2: A/V Formaterkennung für den DVBSource Filter aktivieren. Der Video-Zweig wird dann neu verbunden, wenn sich die Quellauflösung ändert.

 

Beide Lösungansätze verzögern den Umschaltvorgang erheblich. Es geht deutlich schneller, wenn Dekoder und Renderer das selber ermitteln. Die haben auf einem tieferen Niveau die besseren Möglichkeiten als der Source-Filter. Die Quellauflösung wird aber eigentlich ja richtig erkannt...

 

Als Dekoder wird übrigens LAV im DXVA-Modus (Intel) eingesetzt.

 

Hmmm... Ein Graph-Rebuild sollte eigentlich nicht nötig sein. Soweit ich das aus Deiner Beschreibung erkennen kann, vertragen sich LAV und madVR hier ja auch einwandfrei. Das einzige Problem scheint zu sein, daß das Target-Rect nicht korrekt gesetzt wird, richtig? Für das Target-Rect ist eigentlich der Media-Player zuständig. Wenn sich nur die Video-Größe ändert, sollte der Media-Player eine EC_VIDEO_SIZE_CHANGED Nachricht bekommen und dann das Target-Rect neu setzen. Der Media-Player hat normalerweise das Sagen, wohin und in welcher Größe das Video gerendert werden soll. madVR hält sich dann ganz naiv an die Vorgaben des Media-Players.

 

Allerdings wundert mich etwas, daß vorher ja scheinbar 1080i-Video war, und damit das Target-Rect wahrscheinlich auf 1080p. Wieso ändert sich das Target-Rect dann plötzlich auf 720p? Könnte sein, daß madVR das selbst geändert hat, weil der LAV plötzlich einen Media-Change ausgelöst hat. Das wäre dann vielleicht nicht so ganz im Sinne des Erfinders. In jedem Fall denke ich, daß sich das Problem lösen lassen sollte, wenn der DVBViewer bei EC_VIDEO_SIZE_CHANGED das Target-Rect gezielt neu setzt.

 

 

Problem 2:

Je nach Einstellungen hat man mehrere Schwarzblenden pro Umschaltvorgang (was Tjod bereits als Flackern bezeichnet hat). Da wird dann auch das Mini-EPG-OSD jeweils kurz ausgeblendet. Ich konnte diese Schwarzblenden jetzt per Einstellungen auf eine einzige reduzieren (A/V-Formaterkennung im DVBSource Filter, Fullscreen Exclusive ohne Verzögerung bzw. ganz abgeschalten). Ich frage mich allerdings, ob das wirklich nötig ist? Wenn der Graph nicht neu instanziiert wird, bleibt doch auch madVR am Leben. Ich nehme an, dass bei einem Graph Stop auch kein OSD mehr gezeichnet wird? Kann man madVR nicht instanziiert lassen und gewährleisten, dass OSD immer funktioniert?

 

Ich vermute, daß madVR schon instanziert bleibt. Aber beim Graph-Stop hört madVR im Moment leider auf zu rendern, bzw erzwingt sogar die Anzeige eines schwarzen "Abschluß"-Frames. Das ist natürlich nicht ideal für den DVBViewer. Die Frage wäre da, ob der DVBViewer vielleicht ohne Graph-Stop auskommen kann? In Sachen Media-Player-Programmierung kenne ich mich leider gar nicht aus. Weiß nicht, ob das ohne Schwierigkeiten möglich ist. Es ist auf jeden Fall auf meiner ToDo-Liste, daß ich mit dem Rendern (inkl. OSD usw) optional auch im Stop-Zustand weiter mache. Damit sollte sich das Problem dann hoffentlich vollständig lösen (falls es sich hier lediglich um das Stop handelt und nicht um einen kompletten Graph-Rebuild).

 

 

Ich habe mir auch überlegt, ob nicht der DVBViewer das D3D-Device (via IMadVRDirect3D9Manager) zur Verfügung stellen sollte!? Dann könnte der immer OSDs malen. Aber im D3D Fullscreen Exclusive hat man dann wahrscheinlich Probleme, weil es nur eine Swap Chain gibt und madVR seine Video-Frames nicht parallel zum DVBViewer OSD zeichnen kann, oder?

 

Wenn beide ein D3D-Device benutzen und ohne Rücksicht auf Verluste wild drauf rum malen, gibt's Chaos. madVR muß z.B. während des Renderns oft das RenderTarget ändern, damit nicht direkt in den Backbuffer, sondern stattdessen in eine Zwischentexture gerendert wird. Wenn zu diesem Zeitpunkt dann der DVBViewer gerade sein OSD malen würde, würde es in der Zwischentexture landen und nicht im Backbuffer. Daher ist es auf jeden Fall zumindest nötig, die Malvorgänge gezielt zu synchronisieren. Wenn man aber eh die Malvorgänge synchronisiert, ist es nicht mehr so wichtig, wer denn nun das D3D-Device erzeugt. Theoretisch könnte es auch der DVBViewer machen. Aber dann limitiert sich für madVR halt schon wieder einiges an Möglichkeiten. Z.B. muß ich für den "alten" Fullscreen-Exclusive-Mode ein IDirect3DDevice9 verwenden, für alle anderen Modes aber ein IDirect3DDevice9Ex. Und wenn ich irgendwann demnächst native 10bit-Ausgabe einbauen will, brauche ich wahrscheinlich ein D3D11-Device statt eines D3D9-Devices. Für Frame-Packed-3D-Ausgabe wiederum könnte es eventuell (je nach GPU) auch ein D3D9-Overlay-Device werden. Oder ab Windows 8 wiederum ein D3D11-Device. Weil das alles so kompliziert ist, ist es für den DVBViewer viel einfacher, wenn der einfach sein OSD als Bitmap an madVR sendet, und madVR kümmert sich um den Rest. Da können sich die DVBViewer-Devs dann einiges an Kopfschmerzen sparen. Bzw wenn der DVBViewer immer ein D3D9-Device übergibt, könnte madVR dann keine native 10bit-Ausgabe machen, kein Frame-Packed-3D usw...

Edited by madshi
Link to comment

Das einzige Problem scheint zu sein, daß das Target-Rect nicht korrekt gesetzt wird, richtig? Für das Target-Rect ist eigentlich der Media-Player zuständig.

 

 

Ich kann das von CiNcH gemeldete Problem nicht nachvollziehen. Hier funktioniert der 1080i -> 720p Wechsel auch ohne Graph-Neubau oder Vorab-Formaterkennung. Es fragt sich, welche der gefühlt 1000 Einstellungen dabei mitspielt. Oder vielleicht der Graka-Treiber?

 

Außerdem betrachtet der DVBViewer normalerweise den Video Decoder als zuständig. :) Er sollte rcTarget im VIDEOINFOHEADER2 korrekt setzen. Das tut der LAV Output Pin hier laut GraphStudioNext auch (@Cinch: Wie sieht das bei dir aus?). Falls MadVR sich jedoch direkt an den Sourcefilter wendet, gerät er eventuell an den falschen.

 

Hier eine (gekürzte) Kopie aus einem Meinungsaustausch mit dem LAV-Autor:

 

Im Live-Betrieb findet bei uns seit jeher keine Ermittlung der Auflösung statt bzw. ist optional (Optionen -> DirectX -> DVBViewer Filter -> TV/Radio Vorab-Formaterkennung), und sie steht auch nicht in den Senderdaten.

 

Aktuelle Decoder wie LAV kommen durchweg damit zurecht, wenn die beim Verbinden gemeldete Auflösung nicht stimmt. Der DVBViewer Sourcefilter liefert die korrekte Information via IMediaSample.SetMediaType nach, sobald er sie kennt, wenn sie vom Verbindungsformat abweicht.

 

Wenn der Sourcefilter bei Live-Betrieb die Auflösung ermittelt, und danach der Video Decoder - weil er sich nicht darauf verlässt - noch einmal, zieht sich das hin und überfordert die Geduld der Zapper. Insbesondere bei H.264, wo die Einstiegspunkte nicht gerade dicht gesäht sind.

 

Absurderweise bringt es die moderne Technik mit sich, dass alles wieder länger dauert. Das alte Röhrenradio meines Großvaters brauchte nach dem Einschalten seine Zeit, bis man etwas hörte. Dann kamen Transistorgeräte, und es ging blitzschnell. Analoge Senderumschaltungen sowieso. Mit der Digitalisierung kehrte sich die Tendenz um. Inzwischen muss man wieder richtig warten, bis Geräte nach dem Einschalten betriebsbereit sind oder eine Umschaltung zwischen zwei H.264-Quellen vollzogen ist.

Link to comment

Ja, der Videodecoder ist zuständig dafür, dem Video-Renderer die aktuelle Video-Auflösung zu übermitteln. Und der Video-Renderer meldet das dann an alle interessierten Parteien über die offizielle EC_VIDEO_SIZE_CHANGED Meldung.

 

Bei den meisten anderen Media-Playern gibt es verschiedene Zoom-Einstellungen. Z.B. gibt's dort 100% (also unskaliert), 200%, 50%, "touch window from inside", "touch window from outside" und noch ein paar andere. Damit das ganze funktioniert, muß dann der Media-Player dem Renderer die genau gewünsche Video-Position und -Größe mitteilen. Das geschieht über IBasicVideo::SetDestinationPosition. Damit das richtig klappt, muß das natürlich bei jedem EC_VIDEO_SIZE_CHANGED neu gesetzt werden.

 

Ich weiß, das ganze Konstrukt ist recht kompliziert. Die Kommunikation läuft ja praktisch Decoder -> Renderer -> Media-Player -> Renderer. Aber so ist's halt von Microsoft/DirectShow vorgesehen. Normalerweise hat ja der Renderer kein eigenes GUI. Deshalb sind Sachen wie Zoom-Einstellungen usw halt Aufgabe des Media-Players.

Link to comment

Je nach Einstellungen hat man mehrere Schwarzblenden pro Umschaltvorgang (was Tjod bereits als Flackern bezeichnet hat)

Bei mir war das unabhängig vom Sendewechsel oder OSD aufrufen und auf beiden Monitoren.
Link to comment

So, jetzt kann ich das 1080i > 720p Problem nicht mehr reproduzieren. Ich melde mich, sobald ich es wieder kann ;) .

 

 

LAV Video Decoder hat nie die Auflösung des Ausgabefensters im rcTarget vom VIDEOINFOHEADER2, sondern immer die Quellauflösung. Ich hätte auch nicht gedacht, dass der Video Dekoder etwas vom Ausgabefenster weiß...

Link to comment

Wegen des Zusammenhangs mit der Vorab-Formaterkennung hatte ich vermutet, dass der Decoder zumindest anfänglich (nach dem Verbinden und bevor er die Auflösung selbst erkennt) aufgrund der vom Sourcefilter gelieferten Information ein rcTarget von 1920 x 1080 meldet, aber dann nur 1280 x 720 Frames liefert, was zu gewissen Missverständnissen führen könnte ;)

 

Dass der Video Renderer ohne Vorab-Formaterkennung zunächst die falscher Auflösung und später eine Korrektur erhält, kann man bei Live-Betrieb auch im DebugLog des Custom Renderers sehen. Ob der Video Decoder dabei sogar ein Reconnect veranstaltet, weiß ich nicht.

Link to comment

Ich habe jetzt mal mit den Settings etwas gespielt. Folgendes habe ich eingestellt:

 

- Chroma Upscaling via Bilinearem Texturfilter

- DXVA2 Upscaling (wobei bei meinem Test kein Scaling durchgeführt werden musste, 1080i bei 1080p Ausgabe)

- Smooth Motion off

- Dithering off

- kein "copyback" bei DXVA Dekodierung/Deinterlacing

 

Ich hatte mir erhofft, eine ähnliche GPU-Auslastung wie mit EVR zu erzielen. Davon bin ich jedoch weit entfernt... ca. 20% vs. 50%. Nun ist die Anzeige ja nicht sonderlich aussagekräfitig (wahrscheinlich wurde zusätzlich noch höher getaktet), aber auch der Core i3 wird deutlich wärmer. Die temperaturgesteuerten Lüfter beginnen zu drehen. Was treibt denn die GPU-Last da so in die Höhe? Kann doch nicht alles der RGB-Konvertierung geschuldet sein!?

 

Warum kann das Chroma Upscaling nicht DXVA2 erledigen? Ist hier mit Intel ausgegraut. Ich erinnere mich dumpf, es im endlos langen Doom9-Thread mal gelesen zu haben. Aber finde darin mal etwas...

 

Ein weiteres Problem, das ich habe ist, dass sich der Mauszeiger beim Umschalten immer wieder in den Vordergrund drängt.

Link to comment

So, jetzt kann ich das 1080i > 720p Problem nicht mehr reproduzieren. Ich melde mich, sobald ich es wieder kann ;) .

 

Ich auch nicht. Seltsam. :)

Gestern wars noch reproduzierbar! Wurde in madVR 87.13 diesbezüglich etwas geändert?

Link to comment

..bis die erste DVBV@madVR-Vers. dann videotechnisch testbar ist und Christian sich dran erinnert das er sie mir dann gleich schicken wollte..? ;)

hier ein weiterer Screenshot-test:

 

Kann irgendein EVR auf AMD oder Intel per DXVA den madVR@Lanczos-4 erreichen?

 

Dabei für EVR die Treiber der Graka's minimal getrimmt:

im AMD CatalystControlCenter Mosquito und Kantenverstärkung ausschalten.

-> diese Einstellung ist aber nur für kleinformatiges Video (SD) empfehlenswert, ab 720p nicht mehr, da wirken die Filter vollkommen anders.

 

In der Intel Grafiksteuerung in "Video" die Standardfarbkorrektur auf "Treibereinstellungen" und dort die Helligkeit auf 3,3 weil Intel macht im direkten Vergleich ein bisschen dunkler als AMD

und auch als madVR (wärend der auf Intel (default) läuft).

 

Das Video habe ich ein bisschen verlängert und hier jetzt als ts damit es auch im TSPlayer mit Cinch's EVR läuft.

madVR_640x360-Test.ts

 

 

Im Ordner 7 Bilder, diese als Dia-Show fullscreen 1920x1080 ansehen.

Die Bilder: Vergleich EVR-madVR

 

Die Ripple-Freiheit von NNEDI3 schafft keiner.

Das unbewegte Testvideo im Miniformat 360p kann NNEDI3 auch auf schwachbrüstigeren Plattformen darstellen. Normales SD (576i) ruckelt mit NNEDI3 aber bereits auf der Ivy i5 2,6@3,6 GHz.

 

DVBV EVR Custom bekannt unscharf. Ich würde aber gerne mal einen Blindtest mit euch machen:

Ein 2min-Video mit einem Renderer, dann 1min Pause dann ein anderes 2min video mit einem anderen Renderer usw. und irgendwo DVBV EVR Custom dazwischen.

Ich wette selbst auf nem großen Screen würdet ihr alle durchfallen. :)

 

Zwischen DVBV EVR Enhanced und TSPlayer mit Cinchs EVR Custom kein Unterschied zu sehen. Beachtlich wenn der von Cinch dann alles mit OSD, Untertiteln usw. könnte. Und DXVA.

Eben kurz den Verbrauch gecheckt, mit 1080i ~3W über EVR Enhanced, genau wie der alte EVR Custom. Nennt ihn doch bitte EVR CiNstom oder so damit man im Menü gleich bescheid weiß welcher.

 

Bildet euch selbst ein Urteil über die Bilder. Ich finde madVR@Lanczos-4 wird von allen EVR (außer dem alten DVBV-Custom) locker erreicht.

Mir täte der EVR "CiNstom" im DVBViewer genügen zumal ich kaum noch SD gucke.

 

Anbetrachts der Tatsache das mit 720p und 1080i Video von dem ganzen Spuk nix mehr zu sehen ist, madVR aber mit expotentiell viel mehr Verbrauch schafft als mit SD und so GPU/CPU leicht in die Knie zwingen könnte,

- wäre es da nicht sinnvoll wenn er beim Umschalten auch gleich auf einen "günstigeren" Scaler umschaltet?

 

Edited by craig_s
Download-Links aktualisiert
Link to comment

wäre es da nicht sinnvoll wenn er beim Umschalten auch gleich auf einen "günstigeren" Scaler umschaltet?

Kannst dir doch Profile anlegen und dann schaltet madVR je nach Auflösung auf den gewünschten Scaler.

 

EVR und EVR Custom verwenden beide den DXVA Scaler und auch sonst die gleiche Processing-Pipeline.

Daher ist kein Unterschied das richtige Ergebnis.

Diese Verbesserungen irgendwann einzubauen lohnt sich natürlich auch.

Link to comment

Ich habe jetzt mal mit den Settings etwas gespielt. Folgendes habe ich eingestellt:

 

- Chroma Upscaling via Bilinearem Texturfilter

- DXVA2 Upscaling (wobei bei meinem Test kein Scaling durchgeführt werden musste, 1080i bei 1080p Ausgabe)

- Smooth Motion off

- Dithering off

- kein "copyback" bei DXVA Dekodierung/Deinterlacing

 

Ich hatte mir erhofft, eine ähnliche GPU-Auslastung wie mit EVR zu erzielen. Davon bin ich jedoch weit entfernt... ca. 20% vs. 50%. Nun ist die Anzeige ja nicht sonderlich aussagekräfitig (wahrscheinlich wurde zusätzlich noch höher getaktet), aber auch der Core i3 wird deutlich wärmer. Die temperaturgesteuerten Lüfter beginnen zu drehen. Was treibt denn die GPU-Last da so in die Höhe? Kann doch nicht alles der RGB-Konvertierung geschuldet sein!?

 

Warum kann das Chroma Upscaling nicht DXVA2 erledigen? Ist hier mit Intel ausgegraut. Ich erinnere mich dumpf, es im endlos langen Doom9-Thread mal gelesen zu haben. Aber finde darin mal etwas...

 

Ein weiteres Problem, das ich habe ist, dass sich der Mauszeiger beim Umschalten immer wieder in den Vordergrund drängt.

 

Noch ein komisches Phänomen...

 

Ausgangssituation: 1080i auf 1080p mit Lanczos 4-tap AR Chroma Upsampling (+Deinterlacing)

 

mit "copyback": 70% GPU-Last @ 1250 MHz

mit aktiviertem "don't use copyback": 90% GPU-Last @ 1250 MHz

 

Komisch, dass die GPU-Last mit "copyback" kleiner ist.

Link to comment

Bei aktiviertem "copyback" wird das DXVA-Videoframe von der CPU so konvertiert, daß madVR das per PixelShader weiter bearbeiten kann. Bei "don't use copyback" wird die Konvertierung von der GPU gemacht. Das heißt, bei "copyback" hat die GPU etwas weniger zu tun, dafür müssen aber alle Frames zweimal über den PCI-Express-Bus kopiert werden. Hat alles Vor- und Nachteile...

Link to comment

Könntest du mal Kurz die Kette beschreiben was wie sein muss damit was in MadVR geht und was nicht, etwa so:

-> LAV (DXVA native) -> MadVR -> Bildausgabe

-> LAV (DXVA COPY BACK) -> MadVR mit Postprocessing? / SHADER? -> Bildausgabe

 

Ich bin damit nicht wirklich firm und teste sonst evtl. völlig falsch (AMD Hardware)

Link to comment

..kurz und schmerzlos.. ;):

Mit LAV (DXVA2 native) auf AMD und Intel bleibt es auf allen Renderern icl. madVR am kühlsten, d.h. du kannst in madVR evl. noch was versuchen, zB. die scaler hochzukitzeln.

 

Mit -> LAV (DXVA2 COPY BACK) operiert madVR in reinem "Software-Decoding", d.h. je nach Hardware wird's schön heiss und das Bild fängt viel früher an zu ruckeln.

 

was war da noch... überleg... mit LAV wird Deinterlacing per DXVA erst ab Ati HD5xxx unterstützt wenn ich mich recht entsinne.

Auf der sicheren Seite ist man mit den PDVD Decodern, die sind per DXVA noch sparsamer als LAV.

Edited by craig_s
Link to comment

Im Grunde sollte alles gehen. Aber je nach GPU-Hersteller, GPU-Modell und PCI-Express-Geschwindigkeit wird manchmal eine Lösung besser sein als eine andere. Meine *persönliche* Meinung ist, daß heutige CPUs so schnell sind, daß sie h264-Videos mit links dekodieren können, von daher verwende ich nur Software-Decoding. Aber das ist wie gesagt nur meine persönliche Meinung. DXVA Native ist eine gute Lösung vor allem bei NVidia-GPUs, weil die sehr schnell beim Copyback sind. Bei AMD und Intel würde ich Copyback vs. Native beides ausprobieren und das nehmen, was bei Dir besser läuft.

 

DXVA Native hat im Zusammenspiel mit madVR einen Nachteil: Der "film mode" geht nicht. Das heißt, Du kannst nicht 1080i60 Videos in 24p/Hz ausgeben. Bei DXVA Copyback und bei Software Decoding kannst Du in madVR den "film mode" aktivieren, und dann werden 1080i60-Filme von madVR in perfektes 1080p24 umgewandelt. Das klappt aber nur bei Filmen, die ursprünglich 24p waren und dann beim Broadcast in 1080i60 umgewandelt worden sind (das ist der Fall bei 99% der USA-Movie-Broadcasts, und auch bei vielen USA-DVDs).

 

Alle anderen derzeitigen madVR-Features funktionieren (soweit ich mich erinnere) auch mit DXVA Native.

Link to comment

..fang einfach "unten" an und arbeite dich hoch. Also erstmal PDVD Decoder auf DXVA... oder hast du eine "heutige CPU"? Also Haswell kann es nicht in Software, jedenfalls nicht solo...

Edited by craig_s
Link to comment

Wenn ich den LAV also auf Software stelle sollte ich Deinterlacing dann über MadVR machen oder trotzdem das LAV überlassen?

Deinterlacing dann madVR machen lassen, da sonst kein Hardware Deinterlacer!
Link to comment

Also eigentlich brauchst Du gar nicht viel rumstellen. Default-Einstellungen sowohl bei madVR als auch LAV sollten passen (eventuell Scaling-Algos runterschrauben, falls es ruckelt). Kannst natürlich mit Software vs. DXVA Native vs. DXVA Copyback rumprobieren, welches da am besten für Dich läuft. Deinterlacing in LAV ist eigentlich nur für Sonderzwecke gedacht, nicht für den Normalfall. Normalerweise sollte der Renderer deinterlacen, und das macht er mit den Default-Einstellungen auch.

Link to comment

Möchte das noch etwas ergänzen: Der LAV-Decoder ist ein Decoder und der will mit dem Video-Processing (Dithering, Deinterlacing, Scaling usw.) eigentlich nichts zu tun haben.

Mit der Zeit sind in den LAV-Filter trotzdem einige Dinge eingebaut worden, die das Video-Processing betreffen.

z.B. Deinterlacing (Yadif, GPU Deinterlacing über CUVID und Quicksync), Farbraumkonvertierung oder Dithering

Das sind aber alles Möglichkeiten, die für den normalen "Benutzer" überhaupt keine Rolle spielen!

 

d.h. im LAV Filter einen Hardware Decoder auswählen und für den DVBViewer (LiveTV) den Deinterlacing Mode "aggressive" (ist nur eine "Nachricht" an den Renderer) wählen und sonst alles @default lassen.

Der LAV-Decoder konvertiert nur wenn man ihn zwingt (Software Modus und native "output formats" abgewählt => nicht zu empfehlen!).

Link to comment

 

d.h. im LAV Filter einen Hardware Decoder auswählen und für den DVBViewer (LiveTV) den Deinterlacing Mode "aggressive" (ist nur eine "Nachricht" an den Renderer) wählen und sonst alles @default lassen.

Wenn das so ist warum erhöht sich mit diesem Schalter die GPU-Last?
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...