Konfiguration HTPC ?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Nuts schrieb:

      Auch der MPC Audiorenderer ist auch WASAPI fähig, d.h. der Umweg über Reclock kann entfallen.


      Ja, aber der funktioniert nicht stabil. Ich bekomme teilweise Aussetzer und kaputten Ton. Es wird sogar von MPC-HC selbst abgeraten, den zu benutzen. MPC-BE hat einen stabilen WASAPI-Renderer implementiert. Dafür keine LAV-Decoder.

      Im Bitstream Modus ist WASAPI nach meinem Verständnis auch nicht nötig? Das ist "bitperfect" oder es fehlen eben Pakete (alte Reclock, bitstream, powerstrip Problematik oder sonstige grundlegende Problem bei der Wiedergabe).


      Ich musste sowohl "Accept Bitstreaming" als auch WASAPI unter PCM aktivieren, damit Mehrkanal-PCM funktioniert. Bei den anderen Tonformaten kann man natürlich auch Waveout benutzen. Das ist egal. :)
      Ein weiterer Vorteil von ReClock ist der sehr genaue Mastertakt. Damit sinkt die Clock Deviation in madVR drastisch. Wenn man Smooth Motion aktiviert hat, wird damit auch Video-Jitter reduziert, da Smooth Motion auf dem Timestamp basiert.


      Ach ja, die AMD R7 250X ist mit folgenden Optionen bei HD zu 48% ausgelastet:

      - Chroma Upsampling: Lanczos 8 + Anti Ringing
      - Debanding
      - Dithering: Error Diffusion Option 1
      - OpenCL deaktiviert (die Auslastung steigt, wenn ich es aktiviere)

      Jinc kann man vergessen, das ruckelt. Genausowenig schafft die Karte NNEDI3. Dafür müssen also andere Kaliber her.

      Übrigens würde ich das Deinterlacing in madVR deaktivieren (wenn nicht benötigt), da das viel Rechenleistung frisst. :)
    • Hm okay das es zwischen MPC-HC und MPC-BE Unterschiede zwischen den Audiorenderern gibt war mir nicht bewusst (verwende MPC-BE, natürlich mit LAV Decodern).

      Ich muss daheim nochmal mein Setup checken, aber ein "genauen Reclock Mastertakt" dürfte mit deiner Hardware (AMD Karte, HDMI Ton) eigentlich gar nicht nötig sein.
      Was sollte Reclock (ohne Sync, bitstream) hier anders/besser machen als sagen wir mal der Default Audiorenderer (Default Directsound Device)?
    • Hi,

      Kleiner Tipp....

      Ich benutze jetzt schon seit fast einem Jahr den jriver Mediaplayer (jriver.com/).

      Den gibt es für Windows und Macs.
      Linux ist in Arbeit.

      Ich hatte ihn mir damals besorgt, weil ich beim MPC-HC die Medien Verwaltung vermisst habe und XBMC keine gute Bildqualität (Banding z.B. dadurch, das kein Dithering gemacht wird) hat und auch kein 7.1 bei DTS-MA kann.

      Der jriver ist mind. genauso konfigurierbar / programmierbar wie xbmc, hat aber im Red October HQ Mode den MadVR.

      Zum restlichen splitten / decodieren werden die LAV DS Filter benutzt.

      Um 7.1 DTS MA zu kriegen, braucht man allerdings noch die Arcsoft DTS Lib, die man an einen bestimmten Ort hin kopieren muss.

      Ferner hat er Videoclock, was Reclock in etwa entspricht, , so das Ruckeln absolut kein Problem ist (außer ev. beim Start eines Films am Anfang in den ersten paar Sekunden, wenn sich noch nicht alles 100% synchronisiert hat, danach 100% ruckelfrei, auch keine Microruckler.), sofern man den PC DTS/Dobly Digital decodieren lässt.

      Ich lasse das ganze auch noch hochsamplen auf 96khz/24bit, weil ich danach noch ein paar zusätzliche DA/AD Konvertierungen habe durch Receiver und Smyth und die Verluste minimieren will in meiner Audiowiedergabekette (Ob das Hochkonvertieren wirklich nötig ist, habe ich nicht getestet, aber psychologisch tut es gut ;) ).

      Auch noch von Vorteil ist, das der jriver stetig weiter entwickelt wird.
      Pro Woche gibt es mindestens ein Update/Bugfixes.

      Und so Spielereien, wie Fernbedienung per App / Remote Wiedergabe auf Smartphones und Tablets hat er auch.

      Also ich bin mit dem jriver sehr zufrieden und er ist für mich die Spitze der Mediacenter.

      Erst danach kommt XBMC und danach lange nichts mehr.

      Wenn jetzt irgendwann LAV/MadVR 3D BluRays decodieren und im frame packed Format anzeigen könnten, wäre ich im 7. Himmel.
      Dann könnte man endlich den Cyberlink PowerDVD komplett deinstallieren, deren einzige Existenzberechtigung die Bluray 3D Wiedergabe ist und alle Medien über jriver laufen lassen.

      Ach ja... TV Karten gehen damit auch.

      cya
    • FoLLgoTT schrieb:

      Ein Vergleich der Bildqualität zwischen der Windows- und Linux-Version wäre mal interessant. Ich könnte mir durchaus vorstellen, dass es da Abweichungen geben könnte...


      Hast du Lust das mal in Angriff zu nehmen? Ich würde mich bereit erklären mit meinem HTPC bei dir vorbei zu kommen. 1. Würde ich gern mal deine Basswand bewundern :freu: und somit könnten wir 2. gleich einen richtigen A/B Vergleich machen. Ein kühles :bier: könnte man auch gleich zu sich nehmen ;)
    • By the way.....

      XBMC decoding:

      When software decoding of a Full HD 1080p high-definition video is performed by the system CPU, a dual-core 2 GHz or better CPU is required in order to allow for perfectly smooth playback without dropping frames or giving playback a jerky appearance. XBMC can however offload most of the video decoding process onto GPU graphics hardware controller that supports one of the following types of hardware-accelerated video decoding: Intel's VAAPI, Nvidia's VDPAU, AMD's XvBA, Microsoft's DXVA, Apple's VDADecoder/VideoToolBox, OpenMAX, and Broadcom Crystal HD Enhanced Media Accelerator. By taking advantage of such hardware-accelerated video decoding, XBMC can run well on most inexpensive, low-power systems which contain a modern GPU.


      (Quelle:XBMC Wiki Hardware requirements)

      In meinem Fall wäre es dann VAAPI. Somit wird es definitiv Unterschiede geben

      Grüße
    • So, ich habe den ersten Test hin mir...
      Getestet habe ich auf einem Intel Core i7 mit einer GeForce GT530.

      Die Einstellungen habe ich dem Link entnommen und einiges probiert.

      Verglichen habe ich mit der aktuellen Version von XBMC auf einem FullHD Philips Monitor.

      Worauf muss ich achten? Ich sehr wirklich keine Unterschiede, oder kann die Graka einfach nicht genug? Ich teste zu Hause mal.. Da habe ich nee sehr schnelle GTX.

      Gruß
      Nilsens
    • amigenius schrieb:

      Um 7.1 DTS MA zu kriegen, braucht man allerdings noch die Arcsoft DTS Lib, die man an einen bestimmten Ort hin kopieren muss.


      Das gilt aber nicht für Bitstreaming, oder?
      Ich weiß, dann ist der VideoClock nicht aktiv, aber wenn der Taktgeber auf den AMD-Karten sowieso für Bild und Ton identisch ist, braucht man den ja gar nicht.

      Ansonsten finde ich an jRiver sher interessant, dass man zwischen einer praktischen Windows-Oberfläche und einer schönen Heimkinooberfläche wählen kann. :)

      David1977 schrieb:

      Hast du Lust das mal in Angriff zu nehmen? Ich würde mich bereit erklären mit meinem HTPC bei dir vorbei zu kommen. 1. Würde ich gern mal deine Basswand bewundern und somit könnten wir 2. gleich einen richtigen A/B Vergleich machen. Ein kühles könnte man auch gleich zu sich nehmen


      Hmm, Bier bin ich ja nie abgeneigt... :D

      Momentan wird das aber leider nichts. Das kann ihc meiner Frau noch nicht zumuten. Die Kleine schreit dafür zu viel. ;)
      Ich denke, ich werde sowieso mal einladen, wenn das Heimkino im besuchsreifen Zustand ist.

      Nilsens schrieb:

      Worauf muss ich achten?


      Auf das Banding. Das sieht so aus:

      EDIT: <Screenshot des Urlaubsfilms entfernt>

      Bewegt ist das noch viel stärker sichtbar als im Standbild. :puke:

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von FoLLgoTT ()

    • @FoLLgoTT:
      Danke für deine Hinweise und Erklärungen, hab mich heute deswegen mal näher damit beschäftigt und auch den Vergleich gemacht. Der Unterschied fällt bei mir zwar nicht so extrem aus wie in deinem Bild (XBMC sieht bei mir besser aus), aber wenn das Logo aufblendet kann man doch leichte Linien erkennen, die von unten nach oben über das Logo laufen, die mit aktiviertem Debanding auf high in MadVR nicht mehr sichtbar sind.
      Ich werde mich auf jeden Fall weiter damit beschäftigen und schauen wie ich das in XBMC und Yatse als Remote ordentlich zum Laufen bekomme.
    • FoLLgoTT schrieb:

      deathbringer schrieb:

      Der Unterschied fällt bei mir zwar nicht so extrem aus wie in deinem Bild (XBMC sieht bei mir besser aus), ...


      War das die Linux-Version?


      Nein, auf meinem Windows 7 Notebook mit GeForce GT 230M und der XBMC 13.0. Hab mal ebenfalls ein Vergleichsbild erstellt, das Banding ist unbewegt aber so gut wie gar nicht zu erkennen.
    • deathbringer schrieb:

      Nein, auf meinem Windows 7 Notebook mit GeForce GT 230M und der XBMC 13.0. Hab mal ebenfalls ein Vergleichsbild erstellt, das Banding ist unbewegt aber so gut wie gar nicht zu erkennen.


      Danke für den Screenshot. War das mit DXVA oder ohne? Kannst du das noch mal vergleichen? Wie war der Renderer einsgestellt?
      Ich habe die Vermutung, dass die GeForces etwas anders machen als die Radeons.
    • FoLLgoTT schrieb:

      deathbringer schrieb:

      Nein, auf meinem Windows 7 Notebook mit GeForce GT 230M und der XBMC 13.0. Hab mal ebenfalls ein Vergleichsbild erstellt, das Banding ist unbewegt aber so gut wie gar nicht zu erkennen.
      Danke für den Screenshot. War das mit DXVA oder ohne? Kannst du das noch mal vergleichen? Wie war der Renderer einsgestellt?
      Ich habe die Vermutung, dass die GeForces etwas anders machen als die Radeons.
      Ich meine, dass generell die ATIs nicht so dolle für XBMC sind... HD Sound geht / ging auch nur 100% mit GeForce oder Intel HDxxxx.

      @Follgott: Es soll übrigens kein Problem sein, MPC als Player unter XBMC zu nehmen so wir hier gezeigt:
      youtube.com/watch?v=S33UYas6wCE


      Gruß
      Nilsens
    • Nilsens schrieb:

      Ich meine, dass generell die ATIs nicht so dolle für XBMC sind...


      Das sieht aber auch mit EVR/Sync Renderer unter MPC-HC so aus. Es scheint also eher ein Problem von AMD zu sein. Aber dafür müsste man die Karten mal direkt vergleichen. Ich habe leider keine GeForce hier.

      @Follgott: Es soll übrigens kein Problem sein, MPC als Player unter XBMC zu nehmen so wir hier gezeigt:


      Das ist doch gut.
    • @FoLLgoTT:
      Ja, DXVA2 war da aktiviert. Habs gerade auch mal deaktiviert, ändert sich aber nicht wirklich was am Ergebnis.

      Ich werd es mir heute Abend mal auf meinem HTPC (ebenfalls Win7 mit XBMC 13.0) in XBMC ansehen, wie es da aussieht, dort ist nur eine AMD APU drin ohne dedizierte Grafikkarte.
    • So, ich habe eben mal schnell OpenElec auf einem USB-Stick installiert. Es ist so, wie ich es vermutet hatte: das Banding ist mit der Linux-Version geringer, zumindest auf einer AMD-Karte. Unter Windows scheint die AMD-Implementierung, die der EVR benutzt, nicht unbedingt auf höchste Qualität getrimmt zu sein. In dem Punkt waren die früher besser als NVIDIA. Naja...
      Leider konnte ich OpenElec nur ohne Hardwarebeschleunigung testen, da XBMC mit immer abgestürzt ist.

      Trotzdem ist das Banding mit madVR natürlich weiterhin am geringsten, das ist keine Frage. Und für die Bildqualität ist es dann auch egal, welche Graifkkarte man einsetzt, da der Treiber praktisch nichts mehr dazu beiträgt. :)
    • Also bei mir kann ich keinen Unterschied zwischen der AMD APU und der GeForce GT230M erkennen, hab extra auch nochmals das Notebook per HDMI an den TV angeschlossen um auf dem selben Display zu vergleichen.
      Was mir jetzt jedoch aufgefallen ist, daß durch das Debanding vom madVR der Farbverlauf beim Aufblenden des Logos einen gelblicheren Einschlag hat als ohne. Und: der von MPC-HC erstellte Screenshot ist dunkler als die tatsächliche Anzeige, hab beides direkt nebeneinander gestellt. Im Screenshot kommt der gelbliche Einschlag nicht so stark durch wie in der Anzeige in MPC-HC.
    • FoLLgoTT schrieb:

      Leider konnte ich OpenElec nur ohne Hardwarebeschleunigung testen, da XBMC mit immer abgestürzt ist.


      Ahh....schade. Mit wäre das Ergebnis ja noch zuverlässiger gewesen und vielleicht auch besser oder schlechter ;). Ich bin auch der Meinung das XVBA nicht mehr weiter unterstützt wird. Früher musste man sogar aufpassen, welche XBMCbuntu Version man genommen hat. Da gab es eine für AMD/ATI und eine Version für Intel/NVidia. Das war auch mal bei OpenElec so. Wundert mich aber, dass es bei dir nicht mit der Beschleunigung lief. Magst du mir mal ein Crashlog zukommen lassen?

      Am besten hier pasten und mir dann den Link zukommen lassen.

      pastebin.com/

      Auch wenn dich vielleicht OE nicht wirklich interessiert, ist es doch ein Fall, der den Entwicklern helfen könnte einen Fehler zu finden. Von daher ist jedes Crashlog willkommen. Ich würde das dann an die entsprechende Person weiterleiten.

      Mittlerweile sollte es egal sein, welche Hardware man hat. Man nimmt das "generic"-Build und alles weitere sollte "normalerweise" out-of-the-box laufen. Es sei denn, du hast eines der "Fusion"-Builds genommen. Diese sind veraltet und es wird auch auf der Homepage darauf hingewiesen, die "generic"-Builds zu nehmen.

      Grüße
    • Hallo Beisammen

      Dieser Thread macht richtig Spass und weckt bei mir Interesse wieder einen "richtigen" HTPC zu haben :thumbs:

      Seit ich vor über 10 Jahren von meinem Röhrenprojektor auf einen Digitalen gewechselt bin, war das Thema HTPC (für mich) nicht mehr so zwingend nötig, wie mit dem CRT.
      Wenn ich diesen Thread aber lese, kriege ich Lust wieder einen zu verwenden.

      Nachdem ich das Programm JRiver ohnehin im Wohnzimmer als Digitale Musikquelle verwende, könnte ich das natürlich auch im Heimkino in Betrieb nehmen.
      Wenn ich den Thread richtig verstanden habe, geht es hauptsächlich darum, dass man das Plug-in/Tool madVR verwendet und dieses is anscheinend Bestandteil in JRiver.

      Bei mir ist die Situation aber insofern unglücklich, als dass ich Bild (HDMI) und Ton (SPdif) getrennt fahren muss, weil meine Vorstufe keine HDMI Schnittstelle hat.
      Ich denke, dass dieser Umstand die Unterdrückung der Ruckelei schwieriger macht, als wenn Bild und Ton über diesselbe Schnittstelle transportiert werden.

      Wenn sich Bluray und meine TV-Karte (cynergy HD dvb-C) ebenfalls in JRiver integrieren liessen, wäre das ein Traum :jump:
      Gruss Christoph
    • christoph schrieb:


      Nachdem ich das Programm JRiver ohnehin im Wohnzimmer als Digitale Musikquelle verwende, könnte ich das natürlich auch im Heimkino in Betrieb nehmen.
      Wenn ich den Thread richtig verstanden habe, geht es hauptsächlich darum, dass man das Plug-in/Tool madVR verwendet und dieses is anscheinend Bestandteil in JRiver.

      Bei mir ist die Situation aber insofern unglücklich, als dass ich Bild (HDMI) und Ton (SPdif) getrennt fahren muss, weil meine Vorstufe keine HDMI Schnittstelle hat.
      Ich denke, dass dieser Umstand die Unterdrückung der Ruckelei schwieriger macht, als wenn Bild und Ton über diesselbe Schnittstelle transportiert werden.

      Genau.
      madVR läuft einwandfrei im JRiver Mediacenter zusammen mit den LAV Filtern.

      Die Ruckelproblematik könnte durch Smooth-Motion auch entschärft werden.
      Zumindest wenn die Audio-Clock minimal schneller läuft.
      Ausprobiert habe ich das aber noch nicht. Mit HDMI Ton läuft es wie schon erwähnt super (auch ohne Smooth-Motion).
    • FoLLgoTT schrieb:

      Noch ein Tipp: ganz wenige Filme haben Mehrkanal-PCM mit 24 Bit. Das können AMD-Grafikkarten anscheinend nicht ausgeben (zumindest der Treiber nicht). Wenn man im Audio Dekoder von MPC-HC alle Formate bis auf 16 Bit deaktiviert und Dithering aktiviert, klappt auch das.

      Reclock2.png


      Ich glaube es ist nicht nötig die Soundausgabe bei der AMD so zu kastrieren. Wenn du Reclock benutzt kannst du dort einfach "24bit int padded to32" aktivieren und zumindest bei mir funktionieren alle Tonformate mit WASAPI Exklusiv wunderbar über HDMI. Dann hat man auch wieder die "vollen" 24 bit, für all die, die glauben das zu hören.
    • Videodrome schrieb:

      Ich glaube es ist nicht nötig die Soundausgabe bei der AMD so zu kastrieren. Wenn du Reclock benutzt kannst du dort einfach "24bit int padded to32" aktivieren und zumindest bei mir funktionieren alle Tonformate mit WASAPI Exklusiv wunderbar über HDMI. Dann hat man auch wieder die "vollen" 24 bit, für all die, die glauben das zu hören.


      Du hast Recht, das funktioniert! Danke für den Tipp! :thumbs:

      Die Option hatte ich ganz übersehen.
    • Mir ist letztens noch was aufgefallen....

      Ich betreibe meinen Desktop Rechner auch mit Linux. Darin verbaut ist eine NVidia Karte. Wenn ich mir die Einstellungen dieser Karte anschaue finde ich folgendes (siehe Screenshot):

      Bildschirmfoto4.png

      Dort finde ich den Punkt "Dithering". Das ist doch das, was MadVR (unter anderem) auch macht, oder? Auf jeden Fall ist das mit NVidia auch unter Linux möglich. Ich werde demnächst darauf mal ein aktuelles XBMC installieren und mal schauen, wie es sich dort mit dem Banding verhält.

      Wollte nur mal darauf hinweisen ;)

      Grüße
    • David1977 schrieb:

      Dort finde ich den Punkt "Dithering". Das ist doch das, was MadVR (unter anderem) auch macht, oder?


      Nicht ganz. Soweit ich weiß, wenden die Grafikkarten Dithering an, wenn das Farbmanagement aktiv ist. Also wenn eine Farbprofil eingestellt ist, dass die Gammakurve verändert. Die Grafikkarten haben eine 10-Bit-LUT dafür eingebaut. Da sie aber nur mit 8 Bit ausgeben, muss Dithering angewendet werden, damit es kein Banding gibt. Mit meinem VideoEqualizer konnte ich das immer gut nachvollziehen. Trotz massiver Änderungen war kein Banding sichtbar.

      MadVR wendet das Dithering aber an anderer Stelle an, nämlich bei der Konvertierung von YCbCr nach RGB. Das kann der LAV-Decoder übrigens auch, so dass er mit RGB32-Ausgabe mit einem normalen Renderer (z.B. EVR) auch gut aussieht.


      Neben schlechtem Banding, Chroma Upsampling und Skalierung gibt es noch ein paar Andere Probleme, die bei DirectShow auftreten können. Die sind zwar nicht mehr so aktuell, aber waren früher häufig ein Thema. Und auch heute, sollte man sie immer im Auge behalten. :)

      Falsche Koeffizienten bei der Farbraumtransformation
      SD (BT.601) und HD (BT.709) sind mit unterschiedlichen Koeffzienten für die YCbCr->RGB-Transformation kodiert. Heutzutage wird meist angenommen, dass alle Video mit einer vertikalen Auflösung >576 (oder ab 720) BT.709 sind. Das war früher nicht immer so, so dass die Farben mit bestimmten Renderern bei HD falsch waren.

      Inverser Chroma Upsampling Error
      Der CUE ist ja den alten Hasen noch bekannt. Hier wurde das Interlaced-Verfahren für progressive Videos angewendet. Auf dem PC ist es teilweise andersrum. Das Overlay von ATI hat z.B. immer das progressive Verfahren benutzt, auch wenn Interlaced-Material dargestellt wurde. Ich weiß nicht, ob das jetzt noch ein Thema ist. Interlaced verschwindet ja zum Glück auch zunehmend und hat kaum noch Bedeutung.

      Falsche Wertebereiche
      Einige Renderer haben die Wertebereiche 16-235 und 0-255 durcheinandergebracht. Das sieht man zum Glück sofort an dem zu hohen Schwarzwert. Das dürfte inzwischen auch kein Thema mehr sein.

      Banding vom Dekoder
      Bevor die LIBAV und LAV überall eingesetzt wurden, haben einige Dekoder bei MPEG2 schon Banding produziert. PowerDVD war z.B. so ein Kandidat. Es dürften sich wohl die meisten noch an die Klotür-Szene in "Monster AG" erinnern. ;)
      Das ist zwar heute eigentlich kein Thema mehr, ich würde aber vorsichtshalber diesen Test immer noch mal durchführen. Man weiß ja nie...

      Audio-Dekodierung
      Beim Ton gab es genausoviele Probleme. Ob die inzwischen alle behoben sind, weiß ich nicht. Z.B. stimmten von diversen AC3/DTS-Dekodern die Pegel der Kanäle nicht. Bei manchen war der LFE zu leise, andere wiederum haben Clipping produziert und wieder andere haben immer mit Dynamikkompression ausgegeben (siehe hier). Ich vertraue daher auch heute keiner Software-Dekodierung und setze nur Bitstreaming ein. Das mag paranoid klingen, aber ohne einen umfrangreichen Test aller (!) heutigen Tonformate, bleibt immer ein Restzweifel.


      Man sieht also, beim PC (bei Standalone-Geräten prinzipiell auch) kann so viel schiefgehen, dass sich ein tiefergehendes Beschäftigen auf qualitativer Ebene auf jeden Fall lohnt. Ich habe manchmal das Gefühl, dass das seit HD ein bisschen verlorengegangen ist. Ist ja auch verständlich, denn viele Fehler sind durch die hohe Auflösung nicht mehr so leicht zu erkennen. :)
    • Bartman schrieb:

      Meine 5870 gibt 10 Bit RGB per HDMI aus. Was da auf welcher Ebene passiert habe ich aber nie rausfinden können.


      Laut diesem Paper müssen das die Programme explizit unterstützen. Über Direct3D soll es wohl auch gehen. MadVR kann auf jeden Fall 10 Bit entgegenehmen. Ausgeben funktioniert wohl noch nicht, da D3D 11 benötigt wird und madVR D3D 9 benutzt...

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von FoLLgoTT ()

    • FoLLgoTT schrieb:

      Laut diesem Paper müssen das die Programme explizit unterstützen. Über Direct3D soll es wohl auch gehen. MadVR kann auf jeden Fall 10 Bit entgegenehmen. Ich muss zu hause mal schauen, ob er das auch irgendwie ausgeben kann...
      Also raus kommt immer 10 Bit.
      Rendertargets mit mehr als 8 bit sind ja nichts ungewöhnliches bzw teilweise sogar nötig.
      Evtl wird es aber auch nur für Farbkorrektur genutzt oder einfach ein paar Bits angehängt.

      Ich habe auch nur die Info vom Projektor, aber bei anderen Quellen steht da dann auch mal 8 Bit. Ebenso wenn ich das Flag aus dem EDID nehme.

      Eine Checkbox wie in deinem PDF habe ich bei mir nicht und Farbmanagement habe ich auch nirgends aktiviert.
    • DLPLCD schrieb:

      Macht ein HTPC mit aktueller Hardware und madVR ein besseres Bild als ein z.B.Oppo 103 oder muß man madVR usw. haben um ein gleichwertiges Bild zu bekommen ?


      Ich habe es seit den späten DVD-Zeiten nicht mehr aktiv verglichen, da ein Standalone-Gerät für mich nie in Frage kam. Es würde mich aber auf jeden Fall interessieren.

      Grundsätzlich sind Standalone-Geräte in einigen Dingen im Vorteil, solange sie YCbCr 4:2:0 ausgeben. Bisher ist allerdings nur 4:2:2 möglich, also muss der Player den Chromakanal auf jeden Fall vertikal skalieren. Die Farbraumtransformation und die damit verbundenen Rundungsfehler werden aber dem Zielgerät überlassen. Das heißt, die Bildqualität hängt zum Großen Teil am Projektor und dessen Implementierung. Da ändert auch eine 10-Bit-Ausgabe nichts dran. Die ist bei YCbCr sogar relativ sinnlos, da die Werte (bis auf das Chroma-Upsampling) 1:1 rausgegeben werden und somit 8 Bit pro Komponente ausreichen (Deep Color ist also erst bei RGB-Ausgabe oder bei höherbittigem Quellmaterial interessant). Das heißt aber auch, dass der Standalone-Player kein Dithering durchführen muss. Ich könnte mir vorstellen, dass man ohne das Debanding von madVR keinen großen Unterschied sehen wird. Mit wird madVR sicherlich besser abschneiden. Und was die Skalierung von SD-Material angeht, wahrscheinlich auch.

      MPEG2 müsste man noch mal gesondert untersuchen, da hier der Dekoder noch seinen Teil zur Bildqualität beiträgt.
    Abonnement verwalten