Beiträge von Mule

    Hab mal ein paar Passagen kopiert, vielleicht hilft dir das bei deinem Problem?:

    • "If you're not sure, but want hardware decoding always enabled by default, put hwdec=auto-safe into your mpv.conf, and acknowledge that this use case is not "really" supported and may cause problems."
    • "Use the Ctrl+h shortcut to toggle hardware decoding at runtime. It toggles this option between auto and no.
      Always enabling HW decoding by putting it into the config file is discouraged. If you use the Ubuntu package, delete /etc/mpv/mpv.conf, as the package tries to enable HW decoding by default by setting hwdec=vaapi (which is less than ideal, and may even cause sub-optimal wrappers to be used). Or at least change it to hwdec=auto-safe."
    • "If you only want to enable hardware decoding at runtime, don't set the parameter, or put hwdec=no into your mpv.conf (relevant on distros which force-enable it by default, such as on Ubuntu). Use the Ctrl+h default binding to enable it at runtime."
    • "Most non-copy methods only work with the OpenGL GPU backend. Currently, only the vaapi, nvdec and cuda methods work with Vulkan."

    Danke für die Hinweise. Das Thema SW-/HW-Decoding bezieht sich ja darauf, wie die Dekodierung des Content-Materials erfolgt. Das von mir geschilderte Problem liegt ja rein im Bereich des Outputs. Aber dennoch werde ich auch mit diesen Einstellungen nochmals testen.

    FoLLgoTT : Ja, da dies aus dem Log hervorgeht und weil die Änderungen anderer Parameter (bspw. für das OSD oder auch Target-Peak) auch entsprechende Auswirkungen zeigen.
    Du nutzt doch auch Linux, oder? Hast Du denn mal in der Config den HDMI-Level verändert und hat dies die gewohnten Auswirkungen im Bild gezeigt? Welches OS und welche Grafikkarte nutzt Du?

    Getestet habe ich mit mehreren Dateien. Die werden ja auch abgespielt, aber die Parameter (zumindest Videolevel und Farbraum, mehr habe ich nicht getestet), die den Output betreffen, werden einfach ignoriert.

    Mir ist es nur aufgefallen, das etwas nicht stimmt, weil SDR-Material übersättigt war. Dann habe ich die Parameter verändert und gemerkt, dass sich überhaupt nichts verändert. Leider geben die MPV-Logs wie gesagt auch nichts her.

    Ich wüsste auch nicht, was ich noch testen soll, wenn ich Server, als auch Desktopversion verschiedener Linuxderivate mit unterschiedlichen Nvidia-Grafikkarten und TV und Beamer bereits immer mit dem identischen Ergebnis getestet habe.

    -v hat mir leider unter Linux auch keine Erkenntnis gebracht und ehrlich gesagt verzweifele ich gerade.

    Ich habe nun mit Ubuntu und auch Debian getestet und auch den jeweiligen Desktopversionen. Also nackte Installtion des OS, dann Nvidia-Grafiktreiber, MPV aus dem jeweiligen Standardrepository und ohne irgendwelche LUA-Scripte unter MPV. Sonst nichts, also alles Default. Es ist vollkommen egal, welchen Ziel-PrimaryFarbraum oder auch Ziel HDMI-Level (Full oder Limited) ich unter MPV konfiguriere: Es gibt keinerlei Auswirkungen auf das Bild und in den MPV-Logs taucht auch keine Angabe dazu auf, dass er irgendetwas umschaltet oder entsprechend konfiguriert. In den Logs stehen ausschließlich die Daten zum wiedergegebenen Content. Getestet habe


    ich habe mittlerweile mit zwei Nvidia-Grafikkarten GTX1080 (direkt per HDMI) und T600 (per DP-HDMI Adapter) und sowohl an meinem Sony-Beamer (VW760) als auch einem Samsung-LCD-TV getestet und immer mit identischem Ergebnis.


    Ehrlich gesagt fehlt mir mittlerweile die Fantasie, was ich noch machen kann und woran es liegen könnte, dass die Bildeinstellungen mindestens des Farbraums und des RGB-Levels komplett von MPV oder was auch immer ignoriert werden. Und da sehe ich auch ein großes Defizit bei MPV derzeit: Während MadVR auch die Videoausgabeparameter anzeigt, schweigt das OSD des MPV hier komplett und man tappt im Dunkeln und leider steht zudem im Log auch nichts.

    Hat mal jemand der Linux-Anwender überprüft, ob das Umschalten des Farbraums und des RGB-Levels per MPV wirklich funktioniert?

    Dass das Laserdimming erst bei relativ hellen Szenen die volle Lichtleistung aufruft, finde ich grundsätzlich erstmal keinen Nachteil. Deshalb habe ich es auch nicht unter den Negativpunkten aufgeführt.

    Das darf aber gerne jeder für sich selbst anders bewerten.

    Das Laserdimming soll den Kontrast und Schwarzwert verbessern. Es macht daher überhaupt keinen Sinn auch bei höheren ADL-Werten einzugreifen, da es dann kontraproduktiv ist. Welchen Vorteil siehst Du denn bei dieser JVC-Vorgehensweise, wenn Du meinst, dass dies ein subjektiver Aspekt sei.

    Danke das Du draufschaust. Anbei die Config. Eigentlich simpel und größtenteils noch von Atom übernommen, da ich mich bisher auf die eigentliche HTPC-Installation unter Ubuntu konzentriert habe.
    Ansonsten hatte ich es ja richtig interpretiert, dass das OSD nur die Infos der Quelle anzeigt.


    Ich habe ansonsten auch noch ein Problem die Grafikausgabe auf Full zu setzen. Weder schaffe ich es manuell per XRANDR (hier funktioniert es wohl nur mit Intel- oder AMD-Karten), noch schafft es MPV umzuschalten. Hast Du da noch eine Idee?


    Danke für den Test, auch wenn ich mich des Eindrucks nicht erwehren kann, dass kritische Punkte schreibtechnisch "besänftigt" wurden.

    Man nehme bspw. den Satz "Da mir der Schwarzwert der Projektor dunkel genug ist, schalte ich das Laserlichtdimming aus, um Spitzlichter in dunkler Umgebung mit Maximalhelligkeit erleben zu können." der ja letztendlich auf das für Insider bekannte Problem abzielt, dass das Laserdimming (derzeit?) nicht nur bei dunklen, sondern eben auch bei hellen Szenen Szenen. Weshalb kann man das generelle Manko des derzeit implementierten Laserdimmings nicht direkt beim Namen nennen und muss es so formulieren, dass unbedarfte Leser das eigentliche Problem gar nicht erfassen können? Zumal dieses Manko dann auch gar nicht in der Positiv-/Negativliste auftaucht?

    Mal eine Frage an die MPV-Config-Experten:
    Ich habe nur ein spezielles Profil für HDR angelegt, aber keines für SDR. Der Target-Prim ist grundsätzlich (also keine Unterscheidung zwischen SDR- und HDR-Material) mit BT.2020 angegeben.
    Bei HDR sieht das auch alles gut aus, aber bei SDR scheint er dennoch nach BT.709 zu mappen, denn die Farben sind generell übersättigt und auch im Info-Screen zeigt er BT.709 an (wobei ich mir nicht sicher bin, ob dies nicht nur die Angabe zum Content selbst ist).
    Leider gibt es auch im Log von MPV keine Angaben aus der man mehr Infos zum Ausgabe-Farbraum entnehmen kann).


    Habe ich gerade ein Brett vor dem Kopf?

    Ich bin auch über das Beenden von aufgerufenen Prozessen im End-Event gestolpert. Mit os.execute() passiert das nicht. Eine andere Alternative ist, den Parameter playback_only=false bei

    mp.command_native_async() setzen. Dann der Prozess nicht mit in den Abgrund gerissen. :)

    Falls Du mich bzw. meinen "Fall" damit meinst, habe ich mich wohl misverständlich ausgedrückt: Der LUA-Script-Prozess mit dem XRANDR-Teil wird sauber bis zum Ende abgearbeitet. Das Problem ist, dass der Prozess für das MPV-Player-Window parallel ebenfalls weiter abgearbeitet wird und es so vorkommen kann, dass das Player-Window geschlossen und damit das Kodi-Window wieder in den Vordergrund rückt, bevor der XRANDR-Prozess aus dem LUA-Script-Prozess abgeschlossen ist. Damit hat dann Kodi ein Problem. In den Abgrund wird zumindest in meinem Fall nichts gerissen. Es werden halt nur unterschiedliche Prozesse parallel ohne Synchronisation untereinander abgearbeitet, die aufgrund eines uralten Kodi-Problems zwingend in einer bestimmten Reihenfolge laufen müssen.

    Mdann: Timeouts, Sleeps etc. helfen nicht. wenn der Shutdown-Event getriggert wurde, läuft der eigentliche MPV-Player-Prozess parallel weiter und schließt das MPV-Player-Window und somit kommt Kodi in den Vordergrund. Da kann man in der getriggerten LUA-Funktion machen was man will.


    Ich bin auf die asynchrone Verarbeitung erst drauf gekommen, weil ich auch mit Timeouts, Sleeps etc. getestet hatte und das MPV-Window sich vollkommen unabhängig, ob ich da mit 30Sekunden oder was auch immer versucht habe etwas im Script zu verzögern, sich dennoch immer sofort nach dem Shutdown-Event geschlossen hat.


    Dann habe ich mir die Doku zu MPV genauer durchgelesen und dann war es klar, das aufgrund der asynchronen Verarbeitung auch keine Verzögerung hilft. Der MPV-Player und die getriggerte LUA-Funktion laufen halt komplett parallel und unabhängig voneinander. Synchron eben nur mit Hooks. Dann wartet MPV bis die LUA-Funktion abgearbeitet ist und macht erst dann weiter.

    Für alle technisch Interessierten bzw. damit andere nicht auch darauf hereinfallen (so wie ich und auch der ursprüngliche Author des mpv-plugin-xrandr-Scripts zum automatischen Umschalten der Framerate)


    Ich hatte ja das Problem, dass Kodi nach einem Resolutionswitch innerhalb eines LUA-Scriptes unter mpv nicht immer zuverlässig wieder zurück auf die gewünchte Standard-Auflösung nach Beendigung von mpv zurückschaltete, obwohl die eigentliche Screen-Resolution korrekt umgeschaltet hatte.
    Das Problem ist recht simpel (wenn man erst einmal drauf gekommen ist):

    Funktionen in LUA-Scripten unter mpv, welche auf Event- bzw. Property-Basis getriggert werden, werden grundsätzlich asynchron zu mpv ausgeführt. Triggert man nun auf den Event "Shutdown" von mpv und schaltet in der entsprechenden LUA-Script-Funktion per XRANDR die Auflösung um, dann kann es aufgrund der asynchronen Verarbeitung des LUA-Scripts zu folgender unerwünschten Reihenfolge kommen, die dann das Problem mit Kodi auslöst:
    1.) MPV triggert LUA-Scriptfunktion auf Basis des Shutdown-Events an
    2.) Das MPV-Player-Window wird geschlossen
    3.) Damit rückt das Kodi-Window wieder in den Vordergrund
    4.) Das durch den Shutdown-Event angetriggerte Umschalten der Resolution wird es jetzt durchgeführt bzw. abgeschlossen

    5.) Der MPV-Prozess wird vollständig beendet


    Aufgrund dessen, dass das Kodi-Window vor dem XRANDR-Befehl wieder in den Vordergrund rückt und erst dann die Resolutionänderung erfolgt, bekommt Kodi diese Resolutionänderung nicht korrekt mit und skaliert nun die GUI auf eine fehlerhafte Resolution.

    Lösung: Statt eines Funktionstriggers auf Event/Property-Basis einen Hook auf Basis von "on_after_end_file" verwenden, da Hooks synchron in MPV eingebettet sind. So ist sichergestellt, das die Resolutionänderung erfolgt bevor das MPV-Player-Window geschlossen und das Kodi-Window wieder in den Vordergrund rückt.

    Das Problem, dass MPV manchmal den Fokus nach einem Resolution/Framerate-Switch verlor begründet sich ebenfalls in der asynchronen LUA-Verarbeitung bei entsprechend getriggerten Funktionen. Problem beim Start von MPW ist hierbei aber leider, dass es keinen passenden Hook gibt, der zu einem Zeitpunkt greift zu dem MPV bereits die Angaben zu Auflösung und Framerate aus dem abzuspielenden Content-File bereitstellen kann.

    Das Resolution-/Framerate-Switching funktioniert nun mit den entsprechenden Workarounds. Aber elegant ist es nicht und ich überlege daher eher die Logik in einen MPV-Wrapper zu packen, denn das LUA-Scripting unter MPV ist derzeit hierfür nicht wirklich geeignet.

    @welechr: Ich nutze Ubuntu. Die Beschreibung wird sicherlich noch die ein oder andere Woche brauchen, da es mir nicht nur um mpv, sondern um einen HTPC mit Kodi und MPV geht, den man dann per IR bedienen kann. Das Ganze soll sich eher wie ein Standalone-Player als ein PC anfühlen.
    Ich bin im Moment auch noch am überlegen, ob ich nicht noch ein Install-Script schreibe bei dem der User gleich die ein oder andere Config-Frage gestellt bekommt und somit selbst möglichst wenig in irgendwelchen Configs manuell Änderungen vornehmen muss. Mal schauen was mir einfällt.

    Ich würde daher raten, dass Du daher ruhig schon jetzt mit mpv loslegst, denn welche mpv-Config für Deine Umgebung benötigst, kannst nur Du selbst ermitteln. Da kann Dir auch meine Install-Guide wenig helfen.

    Das wäre ja noch unlogischer.
    Aber gehen wir einmal davon aus, es gibt diesen zusätzlichen Lüfter/Kühlbedarf: Bisher konnte man sich darauf verlassen, dass man die gewünschte Maximallautstärke alleine durch die Helligkeitseinstellung einstellt. Wenn nun aber noch diverse weitere Faktoren die Maximallautstärke beeinflussen, dann empfinde ich das als mindestens "unschön".

    Die Aussage hatte ich auch gelesen, aber mir erschließt sich (zumindest teilweise) der logische Zusammenhang überhaupt nicht.
    Weshalb sollte ein zusätzlicher Lüfter anspringen, wenn man das Objekt einstellt? Da kommen doch nur die Stellmotoren in der Mechanik der Optik zum Tragen und dies auch nur für den kurzen Zeitraum des Einstellvorgangs. Weshalb sollte dadurch ein dauerhafter zusätzlicher Kühlbedarf entstehen?
    Aus diesem Grund traue ich dieser Aussage/Beobachtung insgesamt nicht wirklich über den Weg.

    Chl das Mount habe ich laut Anleitung unter Linux gemacht aber die Filme werden einfach nicht abgespielt.


    In Kodi werden die Filme alle angezeigt. Aber sobald ich einen Film auswähle dann kommt nur noch die „Wiedergabe mit enter stoppen“. Aber der Film läuft nicht.


    Wenn ich mit den dateimanager einen Film aus öfter dem NAS auswähle und mit mpv starte passiert nix.

    Du brauchst ein kleines Helperscript bevor MPV durch Kodi gestartet, welches den von Kodi an MPV gelieferten "Pfad" ("smb://...") auf den von Dir angelegten Mount-Point "umbiegt":

    Dazu eine Datei /usr/bin/mpv-start mit folgendem Inhalt anlegen (hierbei : <server>, <freigabename> und <mountpoint> entsprechend Deiner Config ersetzen) und in der Playercorefactory.xml von Kodi den folgenden Eintrag vornehmen: <filename>/usr/bin/mpv-starter</filename>.


    Code
    #SMB-Protokollpfad zu Mountpfad umwandeln
    source=$1
    replace1="smb://<server>/<freigabename>"
    replace2="/mnt/<mountpoint>"
    result="${source/$replace1/$replace2}"
    /usr/bin/mpv "$result"

    Anschließend noch die benötigten Ausführungsrechte für die Datei vergeben:

    Code
    sudo chmod 755 /usr/bin/mpv-start

    Das Ganze wird auch Bestandteil meiner noch folgenden Installionsbeschreibung (auch für nfs). Wird aber noch etwas dauern, da ich vom Splashscreen bis zum Abspielen per MPV alles sauber integrieren möchte und es immer mal wieder Kleinigkeiten gibt, die nerven und zeitaufwendig sind, bis sie so funktionieren, wie ich es gerne hätte.

    Bei Haus des Geldes waren die Orginalteile 1&2 genial. Danach hat man aufgrund des Erfolges versucht die selbe Story bei Netflix nochmals neu zu verpacken und an allen Stellen einen drauf zu packen und damit hat man es, für mich zumindest, übertrieben und es wurde teils absurd. Daher ja, eine geniale Serie, aber bitte keine weiteren Teile/Staffeln mehr, die nur aufgrund des Erfolges auf Krampf produziert werden.