Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Hallo Mathias - wird OpenCL bei dir auch in einer Konfiguration mit 2 GPus unterstützt ? (hier 2x AMD 7850)

Edited by vonMengen
Link to comment

Prost Neujahr!

 

Bin jetzt auch gespannt was die Gemeinde findet, vielleicht lern ich's dann endlich?

 

 

Mit Sicherheit .

Edited by vonMengen
Link to comment

..wobei ich dran erinnere das die meisten hier sich für dieses Killer-Feature einen neuen PC zulegen müssen der richtig schnell ist und wärend das Feature läuft so um 80-100 W frisst...

Edited by craig_s
Link to comment

Ach Gott - ich geh ein einziges Mal mit meiner Freundin und Kind gut essen und das ist das dann aber auch - der Stromverbrauch meiner AMD 7850 fürs Jahr.

Vernünftige Audio -TV - und Videowiedergabe nimmt bei manchen Leuten viel Raum ein , und macht Spass , was soll diese 80- 100 W Fuchserei.

Mich interessiert das nicht die Bohne, der Zugewinn an Lebensqualität gleicht das lässig aus.

 

Und mein subjektives Lästigkeitsempfinden bei Deinen Wattfuchsereien überwiegt da deutlich.

 

Keine Sau hindert dich an deinem Stromspar -Rasberry Pi und Chiuweia 24".

 

Nette Grüssse

Armin

Edited by vonMengen
  • Like 1
Link to comment

Hallo Mathias - wird OpenCL bei dir auch in einer Konfiguration mit 2 GPus unterstützt ? (hier 2x AMD 7850)

 

Jein. Laufen sollte es, aber es wird nur eine GPU unterstützt.

 

..wobei ich dran erinnere das die meisten hier sich für dieses Killer-Feature einen neuen PC zulegen müssen der richtig schnell ist und wärend das Feature läuft so um 80-100 W frisst...

 

Nicht wirklich. Smooth Motion FRC ist verhältnismäßig sparsam. Läuft (eventuell mit angepaßter Konfiguration) auch auf einer Intel GPU. Zumindest wenn man die entsprechende "Trade Quality for Performance" Option aktiviert.

 

Was viele Resourcen verbrät ist vor allem NNEDI3-Upscaling. Weiß aber eh nicht, warum Du immer so auf dem Stromverbrauch rumreitest. Die Features in madVR, die so viel Strom verbrauchen, sind ja optionale Features, die auch per Default deaktiviert sind. madVR läßt sich problemlos auch mit niedrigem Stromverbrauch betreiben. Man kann dann halt nicht alle Algorithmen verwenden, aber muß man ja auch nicht. Smooth Motion FRC ist jedenfalls kein großer Stromfresser.

Link to comment
wobei ich dran erinnere das die meisten hier sich für dieses Killer-Feature einen neuen PC zulegen müssen

 

Wer zum Geier spricht denn von müssen ?

Du mußt doch auch nicht dein Leben lang Grillfleisch essen, nur weil deine Mikrowelle eine Grillfunktion hat.

Wer SmoothMotion (oder madVR generell) nicht braucht, nicht nutzen will, oder nicht kann, der lässt es einfach, oder wählt den Custom-EVR.

Der Punkt ist doch der, das jemand der die Funktionen nutzen will, und dessen Hardware es zulässt, in Zukunft auch die Möglichkeit dazu hat.

 

Gegen die Integration von MadVR in DVBViewer habe ich doch nie etwas gehabt

 

Könnte man nach solchen Sprüchen aber meinen.

Nein sag ich euch Leute, im Moment ist MadVR immernoch einfach nur ein Renderer der eure HTPCs in einen Backofen verwandelt und selbst wenn ihr was sehen würdet gäbe es nur ein paar andere Farbnuancen und ein paar rundere Ecken da und dort,

 

 

 

Wenn du selbst dem madVR nichts abgewinnen kannst, weil du eine Explosion der Stromkosten befürchtest, oder Angst hast, wegen der Hitzenentwicklung deinen PC zu rösten, dann mach doch einfach deinen Haken beim Custom-EVR.

Niemand wird dich dafür steinigen.

Aber hör doch bitte auf, hier alles kaputt zu reden, nur weil dir persönlich der geringere Stromverbrauch, eine geringere Hitzeentwicklung, und geringere Ansprüche an die Hardware wichtiger sind.

Edited by goldfield
  • Like 1
Link to comment

Falsche Adresse Leute, ihr köpft gerade den Überbringer der Nachricht, nicht den Verursacher.

Ich hab überhaupt keinen HTPC, noch nie einen gehabt. Hier stehen nur einige Laptops und Desktops rum und manchmal schau ich Filme drauf.

 

Mehr Spass macht mir aber Multimedia aller Art testen und Problemen auf den Grund zu gehen. Was ich gesagt habe mag euch nicht schmecken aber es ist die nackte Wahrheit.

Hab ich weiter nichts dazu zu sagen.

Link to comment

Einigen wir uns darauf, dass es Leute gibt die unbedingt den Mad im DVBViewer sehen wollen, ggf. sogar wegen dem verwendeten Equipment und andere die das nicht brauchen. Im DVBViewer sind mittlerweile so viele Funktionen drin die kaum wer braucht - so dass ein weiterer Renderer zumindest nicht so ins Gewicht fällt. Ich würde sogar davon ausgehen das 90% der Nutzer bis dato höchstens 10% der Funktionen verwenden.

Das Einbinden des Renderers ging dann überraschender weise doch recht schnell, dank der vielen Sonderfälle die wir eh schon abdecken müssen (und die ich eigentlich lieber konsequent entfernen würde) war die Implementierung nicht sonderlich kompliziert. Zäh wird aber sicherlich das interne Geteste, da einige Sonderfälle beachtet werden müssen. So etwas wie Antennenkabel im laufendem Betrieb ziehen, oder umschalten zwischen mehreren Anzeigegeräten (Monitor, Beamer) bzw. was passiert, wenn die UAC gestartet wird, oder sich der Nutzer abmeldet usw.

Oftmals bekommt man Fehler nur heraus indem man eine Tastatur mit einer Katze in eine Box steckt und kräftig schüttelt. Oder in meinem Fall der Tochter oder Frau das Keyboard in die Hand drückt :)

 

Vorhin kam die Frage wie ich die Qualität der Darstellung finde. Wie gesagt ich kann das schwer einschätzen, da ich nur mit 2 Monitoren arbeite und ich auch die dutzenden Einstellungen im Filter noch nicht durchgegangen bin. Das Bild wirkt etwas plastischer und die Kanten sind besser definiert.

Link to comment

Ein frohes neues Jahr euch allen!

Das sind wirklich tolle Neuigkeiten und ich freue mich schon auf die ersten Tests. :)

 

@craig_s: wieso hältst du dich bei dem Thema nicht einfach raus? Ich habe keine Ahnung was du uns sagen willst! Ist madVR deiner Meinung nach komplett unnütz? Oder was meinst du? Das ist schlicht falsch und nebenbei gesagt auch nicht sehr nett gegenüber dem Entwickler.

Du bildest dir oft sehr schnell eine Meinung und suchst dann nach Argumenten, die deine Meinung stützen. So kann man Dingen schlecht auf den Grund gehen und diese Methodik ist wissenschaftlich auch nicht zulässig.

Link to comment

Übrigens ist die Verwendung vom Mad einfacher als anfangs gedacht, ich kann mittlerweile sogar meine Shader benutzen, mit nur ein paar kleinen Handgriffen mehr.

Link to comment

Übrigens ist die Verwendung vom Mad einfacher als anfangs gedacht, ich kann mittlerweile sogar meine Shader benutzen, mit nur ein paar kleinen Handgriffen mehr.

 

:laughing:

Link to comment

Inzwischen habe ich hier eine ATI Radeon HD 4300/4500 im Stall. Kann man damit MadVR verwenden?

 

 

die Radeon 4300/4500 sollte laut Wikipedia Direct3D10.1 unterstützen, sollte also problemlos mit madVR laufen. Die Geschwindigkeit wird wahrscheinlich nicht so dolle sein, aber wenn man madVR auf entsprechend niedrige Scaling-Einstellungen setzt (z.B. Bilinear oder DXVA Scaling), sollte es eigentlich flüssig laufen.

 

Irgendwie habe ich immer noch keine geeignete Hardware. Zwar läuft der MadVR im DVBViewer Pro und stürzt auch nicht ab - Christian scheint das wirklich gut hingekriegt zu haben - aber sobald ich ins Vollbild wechsle, ist die GPU-Last am Anschlag, und das Bild ruckelt fürchterlich. Scaling ist durchweg auf Bilinear eingestellt.

Link to comment

 

Irgendwie habe ich immer noch keine geeignete Hardware. Zwar läuft der MadVR im DVBViewer Pro und stürzt auch nicht ab - Christian scheint das wirklich gut hingekriegt zu haben - aber sobald ich ins Vollbild wechsle, ist die GPU-Last am Anschlag, und das Bild ruckelt fürchterlich. Scaling ist durchweg auf Bilinear eingestellt.

 

Hmmmm... Was für eine Refresh-Rate hast Du? Hast Du Smooth Motion FRC eingeschaltet? Kannst Du mal das Debug-OSD anmachen und folgende Infos prüfen:

 

1) Was sagt die Refresh-Rate?

2) In welchem Modus ist er (Fullscreen Exclusive, Fullscreen Windowed, Windowed, Overlay)?

3) Was für average render times werden angezeigt? Die müssen niedriger sein als das vsync interval.

4) Ich vermute, Deinterlacing ist aktiv?

5) Welche Queue wird zuerst leer (von oben nach unten)? Ist es die Render-Queue?

 

Du könntest in den madVR-Settings unter "trade quality for performance" mal ein paar Haken setzen. Vielleicht hilft das. Oder vielleicht läuft bei Dir aus irgendeinem Grund der Fullscreen Exclusive Mode sehr schlecht. In dem Fall schalte den doch einfach mal ab.

 

Du hast Gaming-Settings im GPU Control Panel wie Anti-Aliasing und Anisotropic Filtering auf "aus" oder "application controlled" gesetzt? Diese Sachen auf "zwingend an" bremsen madVR aus, ohne Qualitätsgewinn. Stören können auch andere Applications, die auf die GPU zugreifen. Z.B. der Browser, wenn er die GPU mit benutzt. Oder auch GPU-Last-Meßprogramme.

 

Ok, das ist jetzt erstmal die ganze Liste an möglichen Gründen für das Ruckeln. Hoffe, ich hab Dich damit jetzt nicht erschlagen... ;-)

Link to comment

@ Griga

 

Die CPU muß aber auch ein gewisses Mindestmaß haben. Welches genau weiß ich leider nicht nur so viel:

ein i7 von 2011, 1,8@2,8 GHz, starkes ruckeln

ein i5 Ivy Bridge, 2,6@3,6 GHz schafft immerhin DXVA. Da probiere ich aber noch. Daher nun nochmal die Frage,

 

 

@ madshi

 

ist es immernoch so das man, um die "scaling algorithms" zu aktivieren, keinen DXVA-Decoder verwenden darf sondern, damit man von Lanczos/Spiline überhaupt was sieht nur ein "Software-Decoder" aktiv sein darf?

 

bzw. im LAV Videodecoder umstellen von DXVA2 (native) auf DXVA (copy-back), ist das die richtige Einstellung? Oder welchen Videodecoder würdest du in welcher Einstellung empfehlen?

 

Der Hintergrund ist der, wenn ich auf der Ivy den Cyberlink oder LAV in DXVA (native) oder "Intel QuickSync" laufen habe kann man die Taps in den algorithms hochjagen und nichts passiert. Mit DXVA (copy-back) ruckelt es bald und der Lüfter rauscht los.

Edited by craig_s
Link to comment

DXVA in allen Varianten sollte von madVR unterstützt werden. Hat aber alles gewisse "Eigenheiten". So ist es z.B. bei "native" so, daß madVR etwas Verrenkungen machen muß, um das in guter Qualität weiterzuverarbeiten. Leider hat Microsoft es unmöglich gemacht, DXVA-Interfaces direkt mit Direct3D-Pixel-Shadern anzusprechen <würg>. Es sollte grundsätzlich aber trotzdem funktionieren. Je nach GPU-Typ und Konfiguration gibt's aber einen minimalen Chroma-Qualitäts-Verlust, oder einen kleinen Performance-Drop.

 

DXVA "Copy-Back" sieht aus Sicht von madVR eigentlich genauso aus wie Software-Decoding. Allerdings muß der DXVA-Decoder dann per Hand die Video-Frames vom GPU-RAM zurück in den CPU-RAM kopieren, und madVR kopiert's dann wieder andersrum. Ist daher eigentlich für die Performance nicht optimal. Hängt aber stark von der GPU ab. Bei NVidia klappt das "Copy-Back" sehr schnell. Bei AMD und Intel ein gutes Stück langsamer. Vor allem AMD-GPU-Generationen 6xxx und älter sind beim Copy-Back sehr langsam. Ab AMD 7xxx ist es deutlich schneller geworden, aber noch nicht so schnell wie NVidia.

 

Lanczos/Spline usw sollten eigentlich "immer" klappen in madVR, mit einer Ausnahme: Das DXVA-Scaling läßt sich nicht kombinieren mit den anderen Scaling-Algorithmen. Also wenn z.B. in den 3 Abteilungen Chroma-Up, Image-Up, Image-Down irgendwo DXVA-Scaling aktiv ist, kann sich das je nach Situation so auswirken, daß dann alles mit DXVA-Scaling gemacht wird.

 

Bei Performance-Problemen im Zusammenhang mit DXVA (egal ob Decoding, Scaling oder Deinterlacing) kann es Sinn machen, in den madVR "trade quality for performance" Optionen die beiden "don't use copyback"-Optionen zu aktivieren, insbesondere bei Intel-GPUs. Das Ergebnis ist dann ein minimaler Qualitätsverlust im Chroma-Channel, aber eine bessere Performance. Da das ganze von diversen Faktoren abhängt, u.a. auch der PCI-Express-Version-/Geschwindigkeit, fällt es mir schwer, da eine gute Default-Einstellung zu finden, die für alle User gleichermaßen ideal ist. Vielleicht muß ich da irgendwann mal einen internen "Benchmark"-Modus in madVR einbauen, der die GPU, PCIe und CPU auf Speed mißt und dann die Einstellungen in madVR entsprechend anpaßt. Hab ich bisher noch keine Zeit für gefunden...

Link to comment

OK danke, werde weiter probieren.

Das dumme ist halt das man auf "normalem" video nicht sehen kann ob und was nun tatsächlich läuft.

Du solltest dringend mal madVR-Special-Testvideos anfertigen wo erst dann, wenn Lanczos 8 oder Spiline 4 usw. laufen eine entsprechende Einblendung oder bestimmte Farbe oder Muster zu sehen ist.

Das würde enorm weiterhelfen.

Edited by craig_s
Link to comment

Hast Du AviSynth installiert? Dann kannst Du mit z.B. folgendes Script in eine "someImage.avs"-Textdatei schreiben und diese avs-Datei dann einfach im DVBViewer abspielen:

 

 

 

ImageSource("someImage.png").ConvertToYV12()

 

So kannst Du jedes Bild als 4:2:0 YCbCr "Video" im DVBViewer anzeigen lassen. Gute Testbilder, um den Unterschied zwischen verschiedenen Scaling-Algorithmen zu sehen, sind z.B. diese:

 

http://madshi.net/small.png

http://madshi.net/castleOrg.png

http://madshi.net/clown.png

Bei z.B. 200% Zoom-Faktor sollte der Unterschied zwischen z.B. Bilinear, DXVA Scaling, Lanczos, NNEDI3 usw sofort sichtbar sein.

 

Vielleicht sollte ich ins Debug-OSD (Ctrl+J) reinschreiben, welcher Scaling-Algorithmus gerade verwendet wird...

Link to comment
Irgendwie habe ich immer noch keine geeignete Hardware. Zwar läuft der MadVR im DVBViewer Pro und stürzt auch nicht ab - Christian scheint das wirklich gut hingekriegt zu haben - aber sobald ich ins Vollbild wechsle, ist die GPU-Last am Anschlag, und das Bild ruckelt fürchterlich. Scaling ist durchweg auf Bilinear eingestellt.

 

Hmmmm... Was für eine Refresh-Rate hast Du? Hast Du Smooth Motion FRC eingeschaltet? Kannst Du mal das Debug-OSD anmachen und folgende Infos prüfen...

 

MadVR trifft bei mir mal wieder auf seine (unteren) Grenzen :) Ich bin allerdings weder geneigt noch habe ich Zeit, daran lange herumzufrickeln, denn ich glaube nicht, dass ich bei meinen Voraussetzungen eine im Vergleich zum Standard EVR / Custom Presenter verbesserte Bildqualität erreichen kann, also was soll's?

 

Außerdem scheint das eine ziemliche Wissenschaft zu sein, und ich bin vermutlich visuell zu unsensibel für solche Features. Ich konnte zum Beispiel noch nie einen signifikanten qualitativen Unterschied zwischen dem DVBViewer Custom Presenter und dem Standard EVR wahrnehmen, obwohl stark vergrößerte Screenshots ihn belegten. Was das Bild bei mir letztlich wirklich drastisch verbessert hat (so dass sogar ich es gemerkt habe...), war ein neuer Monitor etwas gehobener Qualität. Selbst SD sieht mit dem auf Full HD hochskaliert noch gut aus - keine Ahnung, wie der das macht.

 

Insgesamt halte ich MadVR jedoch für eine Bereicherung des DVBViewers. Es wird sicherlich Anwender geben, die mit dem Renderer eine Steigerung der Bildqualität erreichen werden, wobei es letztendlich ziemlich egal ist, ob vermeintlich oder tatsächlich... :innocent:

Link to comment

Also bei mir sorgt MadVR für gelegentliches Flackern auf beiden Monitoren (mehrmals pro Minute). Außerdem regiert der DVBViewer hin und wieder etwas träge.

 

Ich habe das jetzt nur mit den Default Werten im MadVR getestet (das sollten ja Werte sein die auf möglichst jedem System am wenigsten probleme machen, auch wenn das deutlich zulasten der Bildqualität geht).

 

Ich für meinen Teil halte einen weiteren Renderer für nicht nötig. Und überlasse das Testen und finden der Probleme bei der Einbindung in den DVBViewer oder im Renderer gerne anderen :innocent:

 

Soll heißen ich nutze bis auf weiteres den Custom EVR mit dem ich zufrieden bin. Und der hat noch nie Störungen auf den zweiten Monitor verursacht.

Link to comment

Die erste interne Testversion ist verfügbar. :D

Läuft hier gerade mit Intel Ivybridge onboard GPU, DXVA2 (LAV) Decoder und DXVA Scaler und sieht schon sehr vernünftig aus die Implementierung.

 

OSD geht mit und ohne Wiedergabe, Ruckeln tut nix und die Zeit zwischen den Senderwechseln ist auch noch super!

Kann es fast nicht glauben, dass ich hier grad LiveTV im DVBViewer mit OSD und madVR gucke. :shocked::D

 

Zur Bildqualität sag ich mal bewusst nix. :P

Link to comment

So kannst Du jedes Bild als 4:2:0 YCbCr "Video" im DVBViewer anzeigen lassen. Gute Testbilder, um den Unterschied zwischen verschiedenen Scaling-Algorithmen zu sehen, sind z.B. diese:

 

Bei z.B. 200% Zoom-Faktor sollte der Unterschied zwischen z.B. Bilinear, DXVA Scaling, Lanczos, NNEDI3 usw sofort sichtbar sein.

könntest mal die beiden Videos bei dir einwerfen? Habe ich eben mal aus deinen Bildern zusammengestellt. Kann aber nicht sagen ob der Encoder evl. was *dazugedichtet* hat.

Wichtig: siehst du im progressive die Kriterien auf die es dir ankommt?

progressive

interlaced

 

Beim interlaced sind 4 sec 5x aneinandergeheftet. Bei den Sprüngen in denen neu synchronisiert werden muß sehe ich im zentralen Strichbild auf grau immer wie die Mosquito-Artefakte langsam rausgerechnet werden. Ist das bei dir auch so? Auch hier weiß ich momentan noch nicht ob es der Encoder war. Dementsprechend eingestellt habe ich nichts. Jedenfalls nicht bewußt.. ;)

 

Vielleicht sollte ich ins Debug-OSD (Ctrl+J) reinschreiben, welcher Scaling-Algorithmus gerade verwendet wird...

 

wenn die Einblendung dann auch sicher zutreffend stimmt würd ich es auf jeden fall machen!

Link to comment
Also bei mir sorgt MadVR für gelegentliches Flackern auf beiden Monitoren (mehrmals pro Minute)

 

Ich grübel schon die ganze Zeit rum, weil ich vor Jahren mal was ähnliches hatte.

Ich meine aber mich zu erinnern, das das da irgendwie mit ffdShow oder aviSynth zusammen hing.

Vielleicht hat madshi dazu was auf Lager.

 

ich bin vermutlich visuell zu unsensibel für solche Features. Ich konnte zum Beispiel noch nie einen signifikanten qualitativen Unterschied zwischen dem DVBViewer Custom Presenter und dem Standard EVR wahrnehmen, obwohl stark vergrößerte Screenshots ihn belegten

 

Hattest du für den Vergleich einen Shader aktiviert?

Ohne Shader sehe ich den Unterschied schon.

Complex2a oder Lanzos heben das Bild dann wieder in etwa auf den Level vom Standard EVR.

 

Die erste interne Testversion ist verfügbar.

Läuft hier gerade mit Intel Ivybridge onboard GPU, DXVA2 (LAV) Decoder und DXVA Scaler und sieht schon sehr vernünftig aus die Implementierung.

 

Hört sich doch gut an. :thumbsup:

 

Gibt es eine Möglichkeit für mich (oder Bedarf eurerseits), mich da als Testperson mit einzubringen ?

Könnte das hier auf einer AMD der mittleren Leistungsklasse (HD5770) testen.

Edited by goldfield
Link to comment

könntest mal die beiden Videos bei dir einwerfen? Habe ich eben mal aus deinen Bildern zusammengestellt. Kann aber nicht sagen ob der Encoder evl. was *dazugedichtet* hat.

Wichtig: siehst du im progressive die Kriterien auf die es dir ankommt?

progressive

interlaced

 

Beim interlaced sind 4 sec 5x aneinandergeheftet. Bei den Sprüngen in denen neu synchronisiert werden muß sehe ich im zentralen Strichbild auf grau immer wie die Mosquito-Artefakte langsam rausgerechnet werden. Ist das bei dir auch so? Auch hier weiß ich momentan noch nicht ob es der Encoder war. Dementsprechend eingestellt habe ich nichts. Jedenfalls nicht bewußt.. ;)

 

Ist grundsätzlich keine schlechte Idee, die Bilder zusammen in ein Video zu komprimieren. Einen großen Nachteil beim DVBViewer hat das aber: Zumindest mit den Default-Einstellungen zoomt DVBViewer das ganze Bild "nur" auf die Bildschirmgröße. Das heißt, je größer das Original-Bild, desto kleiner der endgültige Scaling-Faktor. Wenn Du die originalen Bilder einzeln hochscalst, ist der endgültige Scaling-Faktor im DVBViewer höher, wodurch auch die Bildqualitätsunterschiede zwischen den einzelnen Scaling-Algorithmen leichter sichtbar werden.

 

Grundsätzlich klappen beiden Videos bei mir, und erfüllen "einigermaßen" ihren Zweck. Allerdings gibt's schon recht heftige Kompressionsartefakte. Beim Interlaced braucht bei mir der Deinterlacer bei jeder der 5x Unter-Sequenzen ein paar Frames um zu erkennen, daß es sich um statische Bilder handelt, ansonsten funktioniert das aber auch. Mag aber von der GPU abhängen. DXVA Deinterlacing funktioniert je nach GPU, eventuell sogar je nach Modell und Treiberversion unterschiedlich. Ich persönlich würd lieber getrennte Videos für Scaling- und für Deinterlacing-Tests machen. Würde auch eher h264 nehmen (z.B. x264), um die Kompressionsartefakte zu minimieren.

Link to comment

Hi madshi,

 

Bin fleißig am testen und gerade hat mir madVR angeboten einen Bugreport an dich zu schicken.

Der Vorgang wurde leider mit einer Fehlermeldung abgebrochen (sinngemäß: Bugreport konnte nicht gesendet oder so ähnlich). Funktioniert die Funktion grundsätzlich oder was mache ich da falsch?

Link to comment

Sollte eigentlich funktionieren, kann aber je nach Firewall usw auch mal schief gehen. Im Notfall einfach nichts machen und die Fehler-Box einfach schließen. Dann sollte auf dem Desktop eine BugReport-Textdatei entstehen. Die dann "per Hand" an mich, z.B. per madVR-Bugtracker oder so.

Link to comment

Hm okay dann fuchtelt wohl eine Firewall dazwischen.

Die BugReport-Textdatei ist jetzt auch nicht zu sehen. Darf eine Anwendung @8.1 noch so ohne weiteres auf den Desktop schreiben?

Aber naja das wird sich noch einspielen. ;)

Link to comment
Am 4.1.2015 um 21:34 schrieb madshi:

Ist grundsätzlich keine schlechte Idee, die Bilder zusammen in ein Video zu komprimieren. Einen großen Nachteil beim DVBViewer hat das aber: Zumindest mit den Default-Einstellungen zoomt DVBViewer das ganze Bild "nur" auf die Bildschirmgröße. Das heißt, je größer das Original-Bild, desto kleiner der endgültige Scaling-Faktor. Wenn Du die originalen Bilder einzeln hochscalst, ist der endgültige Scaling-Faktor im DVBViewer höher, wodurch auch die Bildqualitätsunterschiede zwischen den einzelnen Scaling-Algorithmen leichter sichtbar werden.

 

Grundsätzlich klappen beiden Videos bei mir, und erfüllen "einigermaßen" ihren Zweck. Allerdings gibt's schon recht heftige Kompressionsartefakte. Beim Interlaced braucht bei mir der Deinterlacer bei jeder der 5x Unter-Sequenzen ein paar Frames um zu erkennen, daß es sich um statische Bilder handelt, ansonsten funktioniert das aber auch. Mag aber von der GPU abhängen. DXVA Deinterlacing funktioniert je nach GPU, eventuell sogar je nach Modell und Treiberversion unterschiedlich. Ich persönlich würd lieber getrennte Videos für Scaling- und für Deinterlacing-Tests machen. Würde auch eher h264 nehmen (z.B. x264), um die Kompressionsartefakte zu minimieren.

Interlaced hab ich nur gemacht weil grad alles drauf eingestellt war.. ;) Ohne Bewegung auch ziemlich nutzlos.

Wegen upscaling stand oben was von 200% -> 1080/480 = 2,25fach ist der Zoom des Testvideos auf FullHD.

Ok dann mach ich eins mit 640x360 das wäre dann voller 3-fach Zoom.

 

Alle Bilder gleichzeitig nur wegen Faulheit, schneller Überblick und so.. Die Burg passt dann nur noch teilweise rein.. h264, oha schon lange nicht mehr gemacht.. Die Bitrate wähle ich mal vorsichtshalber zu hoch...

... und fertig, heute einige Tests gemacht. Super dein Tip war richtig h264 ohne Kompressionsartefakte (oder jedenfalls für mich unsichtbar) :)

Das Video: 640x360_p25_h264.mp4

Die rote schrift und Linien sind nur Versuche, falls dir noch was einfällt was ich ein/ausbauen soll..

 

 

Wir müssten jetzt halt was elementares klären - ob wir beide halbwegs das gleiche sehen. Dazu unten 3 Screenshots nur von madVR. Schau den Ordner als 1920x1080 Diashow (Fullscreen). Die Fragen wären:

1) sehen die Screenshots einigermaßen so aus wie das bei dir mit madVR laufende mp4? Oder was ist anders?

Fotografiert unter LAV auf Intel Quicksync. In den mad-Einstellungen hatte ich nichts verstellt außer in Devices den TV gewählt und eben image up und doubling.

 

2) - 01 Lanczos-4 ist scharf, zeigt aber u.a. bei dem Fahrrad-Gestänge noch Rippels. (Spline-4 brachte keine sichtbare änderung).

3) - 01a Jinc-4 ist etwas unschärfer aber die Rippels sind weg.

4) - 01b Lanczos-4 + NNEDI3 double Lu/Cr 32/16 macht die Fahrradstangen wieder scharf und ohne Rippels.

 

Die Bilder: Lan4_Jinc4_NNEDI3-Ordner

Edited by craig_s
Download-Links aktualisiert
Link to comment

Jau, schaut soweit alles gut und "richtig" aus. Noch deutlicher als beim Fahrrad-Gestänge sehe ich den Unterschied z.B. rechts bei den Speichen des Vorderrads oder beim Leuchtturm-Bild an den Dachkanten des mittleren Hauses. Dort kann man teilweise dann auch noch kleine Verbesserungen sehen, wenn man bei NNEDI3 noch die Neuron-Zahl hochstellt. Mehr als 32 Neurons ist dann aber wahrscheinlich auch nicht mehr sinnvoll, weil zu langsam, und weil die Qualitätsgewinn bei steigender Neuron-Zahl auch immer kleiner wird. Ein großer Vorteil von NNEDI3 ist, daß das Ergebnis recht "sauber" ist, also kaum noch Artefakte wie Aliasing oder Ringing hat. Das ist zum einen einfach gut für das Auge, zum anderen ermöglicht das aber auch, nachträglich das ganze Bild noch besser/effektiver nachzuschärfen. Die entsprechenden Schärfungsalgorithmen stehen schon per Custom-Pixel-Shader zur Verfügung (siehe z.B. hier: http://forum.doom9.org/showthread.php?t=171346 ). Die besten Algos werde ich in einer zukünftigen Version auch gleich in madVR mit einbauen, zur einfacheren Verfügbarkeit.

 

Da NNEDI3 aber schon sehr viel GPU-Leistung benötigt (das ist im Moment mit Abstand der "teuerste" Algo in madVR), ist das natürlich nur etwas für Leute, denen die Bildqualität über alles geht. Für "Normaluser" ist NNEDI3 deshalb wahrscheinlich für's erste keine Alternative. Allerdings steigert Intel jedes Jahr die GPU-Leistung um 30-50%. Also in ein paar Jahren werden wahrscheinlich selbst günstige Standard-Intel-CPUs bereits NNEDI3 machen können - zumindest für das Doubling von SD-Videos.

Link to comment

Kurz noch für Leute , die MadVR auf ATI/AMD GPUs testen . Der ideale Grafiktreiber ist der Catalyst 13.12 .

 

Nach meiner Erfahrung haben alle neueren Grafiktreiber z.T. deutlich schlechtere Performance mit MadVR , auch der Omega. Das kann soweit führen , dass NNEDI3 mit 82 % GPU Last auf einer 7850 läuft,

oder mit 59 % . Das heisst dann im Endeffekt - dropped frames oder keine.

Edited by vonMengen
Link to comment

 

 

 

Außerdem scheint das eine ziemliche Wissenschaft zu sein, und ich bin vermutlich visuell zu unsensibel für solche Features. Ich konnte zum Beispiel noch nie einen signifikanten qualitativen Unterschied zwischen dem DVBViewer Custom Presenter und dem Standard EVR wahrnehmen, obwohl stark vergrößerte Screenshots ihn belegten. Was das Bild bei mir letztlich wirklich drastisch verbessert hat (so dass sogar ich es gemerkt habe...), war ein neuer Monitor etwas gehobener Qualität. Selbst SD sieht mit dem auf Full HD hochskaliert noch gut aus - keine Ahnung, wie der das macht.

 

Insgesamt halte ich MadVR jedoch für eine Bereicherung des DVBViewers. Es wird sicherlich Anwender geben, die mit dem Renderer eine Steigerung der Bildqualität erreichen werden, wobei es letztendlich ziemlich egal ist, ob vermeintlich oder tatsächlich... :innocent:

Das ist dasselbe Phänomen , wie bei hochwertiger Audiowiedergabe - Auge und Ohr sensibilisieren sich mit steigender Qualität der Wiedergabekette -

Das subjektive Lästigkeitsempfinden steigt massiv an

 

Custom presenter als Beispiel , ist bei mir eine absolutes Ausschlusskriterium , nicht nur bei SD , sondern auch bei 720 p .

Edited by vonMengen
Link to comment

P.S: Zum Vergleich wäre jetzt natürlich interessant, was die Standard-Renderer im DVBViewer mit diesem h264 Scaling-Test-Video produzieren... :original:

 

Stimmt, den unscharfen DVBV-EVR-Custom zu überflügeln wird nicht schwer sein, langsam verstehe ich die DVBViewlers. Ich hab immer auf EVR ohne Custom getestet, der ist schön knackig. Ich brauchte aber auch nie eine Skin.

Wegen weiter testen bitte noch etwas Geduld, Christian schreibt grad, das brauch noch etwas.

 

Wegen großem Überschwang aller gebe ich zu bedenken:

- kleinformatiges Video (SD) ist enorm am verschwinden aber starkes up-scaling ist nun mal die Stärke von madVR, je stärker um so besser wie man sieht. Bei 720@1080 bleibt nicht viel zu sehen ausser rauchende Colts :P wärend der Verbrauch von madVR dramatisch wächst. Wer mich jetzt wieder anfängt zu hassen :P, nein mir geht es nicht ums Geld. Mir gehts darum - wenn es schon qualmt will ich dafür auch was sehen was es lohnt. Das gebietet mir mein gesunder Menschenverstand.

 

Das nächste wäre dann evl. 720@4K oder 1080@4K. Da bauen die TV-Hersteller aber selbst schon raffinierte Algos ein. Für madshi zu hoffen nicht zu gute, oder er wird eingekauft? Damit rechne ich schon..

Edited by craig_s
Link to comment

Bei mir ist EVR und CustomEVR beides sehr unscharf, sieht fast identisch aus. Der Unterschied zu madVR ist mit Deinem Test-Video wirklich gewaltig. Ist allerdings mit ner AMD 7770. Kann sein, daß der EVR ohne Custom den DXVA-Scaling-Algorithmus benutzt, der ist bei Intel recht gut, bei AMD und NVidia aber nicht so dolle. Hast Du ne Intel-GPU? Das würde vielleicht erklären, warum das bei Dir mit dem EVR ohne Custom schärfer aussieht.

 

Ja, es ist richtig, daß der Scaling-Qualitäts-Vorteil von madVR sehr stark vom Scaling-Faktor abhängt. Je größer der Scaling-Faktor, desto größer der Unterschied. Bei 720p -> 1080p ist der Unterschied wesentlich kleiner als bei SD -> 1080p. Und es stimmt auch, daß viele 4K-Displays halbwegs vernünftige Upscaling-Algos eingebaut haben. Von dem, was diverse User mir erzählt haben, sind die zwar alle nicht so gut wie das was madVR kann, aber wie groß der Unterschied wirklich ist, kann ich selbst nicht beurteilen, weil ich noch kein 4K-Display habe. Und für 1080p -> 4K Upscaling braucht madVR natürlich auch schon ordentlich GPU-Resourcen. Naja, bei Lanczos3 AR hält's sich einigermaßen in Grenzen, aber für alles andere braucht man dann doch schon mindestens ne Mittelklasse-GPU, denke ich mal.

 

Natürlich ist Scaling nicht das einzige Feature, daß madVR für manche User attraktiv machen könnte. Da gibt's ja noch viele andere Features und Algos (und weitere werden in der Zukunft noch dazu kommen), aber das Thema hatten wir ja schon mal...

 

Naja, auf jeden Fall ist es ja positiv für alle, daß der DVBViewer jetzt madVR-Support bekommt. Wer's mag, kann's benutzen. Wer nicht, läßt es einfach sein. Also sollte es doch alle glücklich machen.

Link to comment

Ja der Intel DXVA Scaler ist wirklich ganz gut, aber den gibt's ja derzeit nicht im EVR Custom und den EVR kann man mit OSD leider vergessen.

 

Ich schau grad zum Test etwas LiveTV mit smooth motion @60hz und das kann sich doch sehen lassen.

Ist nicht 100% perfekt (gut zu sehen bei Laufschriften z.B. auf N24) und würde wenn möglich auch weiterhin 50hz empfehlen, aber z.B. für Laptops mit 60hz only ein deutlicher Fortschritt.

Link to comment

Ja, Smooth Motion FRC mit 50fps @ 60Hz ist nicht ganz optimal, vor allem bei Laufschriften. Da gibt's noch Verbesserungspotential. Das hab ich auf meiner (sehr langen) ToDo-Liste. Aber ich denke, es ist immerhin noch besser als ohne Smooth Motion FRC, oder?

Link to comment

Bei mir ist EVR und CustomEVR beides sehr unscharf, sieht fast identisch aus. Der Unterschied zu madVR ist mit Deinem Test-Video wirklich gewaltig. Ist allerdings mit ner AMD 7770. Kann sein, daß der EVR ohne Custom den DXVA-Scaling-Algorithmus benutzt, der ist bei Intel recht gut, bei AMD und NVidia aber nicht so dolle. Hast Du ne Intel-GPU? Das würde vielleicht erklären, warum das bei Dir mit dem EVR ohne Custom schärfer aussieht.

 

Sehr erstaunt - EVR und Custom ist ein sehr grosser Unterschied . Jedenfalls bei mir.

Link to comment
mir geht es nicht ums Geld. Mir gehts darum - wenn es schon qualmt will ich dafür auch was sehen was es lohnt.

 

Da hätte ich dann noch einen Mitsubishi HC6500 und eine 2,60m Leinwand anzubieten. :original:

Sorry, aber die (scherzhaft gemeinte) Stichelei musste einfach raus.

 

Aber das mit den Testbildern/ dem Testvideo, die du da zusammengestellt hast, ist schon klasse.

Ich denke mal, das die meisten da die Unterschiede schon recht gut erkennen dürften.

Ob einem das dann den (finanziellen) Aufwand wert ist, muss jeder selbst entscheiden.

 

Für einen Monitor, oder einen mittleren TV lohnt sich das vielleicht wirklich nicht unbedingt.

Mein zukünftiger Schlafzimmer-PC wird deshalb auch auf Sparflamme laufen.

 

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:

 

 

 

Sehr erstaunt - EVR und Custom ist ein sehr grosser Unterschied . Jedenfalls bei mir.

 

Bei mir (ATI HD5770) ebenso.

Scheint wohl tatsächlich sehr von der verwendeten Graka abhängig zu sein.

Edited by goldfield
Link to comment

Sehr erstaunt - EVR und Custom ist ein sehr grosser Unterschied . Jedenfalls bei mir.

 

Oh, Du hast Recht. Es scheint, als würde das mit dem Umschalten zwischen CustomEVR auf EVR mitten im Video nicht so richtig bei mir klappen. Nach dem DVBViewer-Neustart sieht das ganze wesentlich besser aus. Scheint so, als hätte AMD da ordentlich nachgebessert. Sieht inzwischen ähnlich aus wie bei Intel. Würde sagen, es ist ähnlich wie Lanczos AR. Allerdings ist der AR-Filter bei AMD sehr scharf ausgelegt, was nicht nur Vorteile hat. Ich hab meinen AR-Filter absichtlich etwas abgeschwächt, weil etwas Ringing manchmal eben (überraschenderweise) positiv sein kann. Aber egal, ich würde sagen, EVR auf meiner AMD ist doch grob vergleichbar zu Lanczos AR mit madVR. Mit kleinen Abstrichen (zu starker AR-Filter, nur 8bit), die aber in normalen Videos nicht soooo wichtig sind. 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...

 

Interessieren würde mich jetzt die NVidia-Scaling-Qualität im EVR. Ob NVidia da inzwischen auch nachgebessert hat?

Link to comment

Aber ich denke, es ist immerhin noch besser als ohne Smooth Motion FRC, oder?

Ja auf jeden Fall! Sitze hier ganz entspannt und schau @60hz auf dem großen Schirm.

Ohne Smooth motion werd ich da ganz schnell nervös. ;)

 

P.S. Wer kontrolliert eigentlich die madVR eigenen OSD Einblendungen (z.B. windowed / exclusive)?

Imho sollte man in einer "echten" Mediacenter-Anwendungen damit sparsam umgehen.

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