MPV Player als Alternativer Player z.B. in Kodi

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

  • Den Start habe ich (in der Windows Variante) so angepasst:


    Original (in der Funktion autoChange):

    Code
            --waits until some of the required properties have been loaded before running
            msg.verbose('automatically changing refresh')
            mp.add_timeout(0.5, matchVideo)

    Es dauert hier immer 0.5 Sekunden bevor das Script die Auflösung etc liest. Wenn es länger geht, dann funktioniert das Script evtl nicht richtig.


    modifizierte Variante:

    Hier arbeitet das Script so schnell wie möglich, aber gibt nach 5 Sekunden auf, falls es keine Daten finden kann.

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

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

    Das habe ich schon richtig verstanden. Beim Ausschalten geht das nur synchron. Das hast du völlig ríchtig erkannt und beschrieben.


    Mir ging es in dem Beispiel nur ums Einschalten von Ausschalten war nicht die rede.
    Beim Einschalten gibt es das Problem, dass das Script versucht Werte zu lesen, die wegen der Asynchronität (und Performance) evtl noch nicht verfügbar sind. In diesem Fall helfen Timeouts, Sleep etc schon. Der Standardcode löst das aus meiner Sicht nicht besonders gut.

  • Ah sorry. Da hast Du natürlich vollkommen Recht, habe es falsch gelesen! Ja, beim Einschalten nutze ich es auch, da ansonsten die Werte für Resolution und Framerate des abzuspielenden Contents noch nicht gleich zur Verfügung stehen.

  • Wenn ein Wert anfangs noch nicht da ist, kann man sich von MPV auch darüber informieren lassen, wenn er da ist.

    mp.observe_property("xxx", "string", on_xxx)


    Das wird zwar teilweise zuerst mit einem leeren Wert aufgerufen. Wenn man aber auf gültige Werte überprüft, klappt es prima.

    "A computer lets you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila." - Mitch Ratcliffe

  • 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. :)

    entschuldigt, ich bin noch neu, gibt es hier irgendwo einen Thread für Anfängerfragen oder soll ich das hier machen? z.B. verstehe ich den Post von dem User "FoLLgoTT" nicht.

    Ich empfehle dir, erstmal ein paar Wochen quer im Forum zu lesen. Für CIH habe ich z.B. hier etwas geschrieben. Dann sollte das klarer werden. :)

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

    ne da warte ich dann gerne drauf. Das will ich haben ein stand alone Gerät. Und die confit kann ich dann ja noch was abändern ;)


    Besten Dank vorab für deine Mühe.

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

  • 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?

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

    Ich gebe auch immer mit BT.2020 aus und habe das Problem nicht. Kannst du mal deine Konfiguration zeigen?


    Die Daten im OSD sind übrigens die der Quelle.

  • 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 das Du draufschaust.

    Kein Problem. Aber auch damit kann ich das unter Windows nicht nachvollziehen. Ich sitze zwar vor einem BT.709-Monitor, aber sowohl HDR als auch SDR kommen gleichermaßen untersättigt raus, also so, wie man es erwartet (und wie es mit meiner Konfiguration auch ist). Ich habe leider keine Idee.

  • Weißt Du zufällig wie man MPV entlocken kann welcher Farbraum zur Ausgabe aktuell genommen wird?

    Starte mal mit -v, dann kommen mehr Informationen raus. Bei mir steht dann z.B. irgendwo:


    Code
    [vo/gpu/d3d11] Queried output: \\.\DISPLAY1, 3840x2160 @ 8 bits, colorspace: RGB_FULL_G22_NONE_P709 (0)
    [vo/gpu/d3d11] Selected swapchain format R8G8B8A8_UNORM (28), attempting to utilize it.
    [vo/gpu/d3d11] Selected swapchain color space RGB_FULL_G22_NONE_P709 (0), attempting to utilize it.
    [vo/gpu/d3d11] Swapchain capabilities for color space RGB_FULL_G22_NONE_P709 (0): normal: yes, overlay: no
    [vo/gpu/d3d11] Swapchain successfully configured to color space RGB_FULL_G22_NONE_P709 (0)!
  • -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?

  • Hast du immer die 2 gleichen Filme getestet? Ich hatte auch bei MadVR mal eine mkv die hatt es immer zum Absturz gebracht….EINE….alle anderen gingen. Also nicht dass du eventuell immer die gleiche beschädigte/komische Datei. Testest.

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

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!