MPV Player als Alternativer Player z.B. in Kodi

  • Wenn ich es richtig verstanden habe, dann bleibt die Matrix beim Erstellen eines synthetischen Profils auf Basis eines nicht synthetischen Profils erhalten, korrekt?

    Genau. Im Grunde reichen die Koordinaten des Zielgamuts. Man könnte also auch mit CalMAN oder HCFR die Koordinaten messen und in den Synthetic Profile Creator eintragen. MPV wird die Farben dann korrekt konvertieren. Nur Gamma eben nicht.


    Vermutlich sitzt das Problem vor dem Bildschirm, aber ich komm nicht drauf.

    Ich habe mal ((( atom ))) gefragt, wie er das macht. Ich melde mich, wenn ich eine Antwort habe. Zu Linux kann ich da nicht weiter helfen, unter Windows klappt das mit dem DisplayCal Loader sehr gut.

  • FoLLgoTT

    Danke für die Info und Deine Unterstützung. Du meinst vermutlich Profile Info von Displaycal, oder? Ja, damit hatte ich (zumindest bezüglich der selbst erstellten Profile) schon geschaut.
    Ich werde mir das Ganze am Wochenende nochmal in Ruhe anschauen, wenn ich etwas mehr Zeit habe. Es kann eigentlich nur ein Anwenderproblem sein, da die Tools dispwin und xcalib die Verarbeitung der jeweiligen Profile korrekt bestätigen und ich bei dem bluish-Profil ja auch die Blauverschiebung sofort deutlich sehen konnte.

  • So, inzwischen habe ich mal gpu-next zum Laufen bekommen. Es muss (unter Windows) zwingend gpu-api=vulkan gesetzt sein, sonst startet MPV nicht.


    Mit gpu-next unterstützt MPV 3D-LUTs im cube-Format. Das funktioniert auch, soweit ich das auf die Schnelle beurteilen kann. DisplayCAL kann die direkt erzeugen. Ich muss die sicherheitshalber aber noch mal nachmessen.


    Beispiel:

    Code
    vo=gpu-next
    gpu-api=vulkan
    target-lut="madVR 2021-12-21 09-07 2.2 F-S XYZLUT+MTX.Rec709.bb1.0,2.2Gawn65.cube"


    Es gibt verschiedene Stellen in der Verarbeitung, an denen eine 3D-LUT angewendet werden kann.

    1. Dekodierung (image-lut=)
    2. Farbkonvertierung (lut=)
    3. Nach Farbkonvertierung (target-lut=)


    Bei 3. ist das Bild dann bereits auf das Zielgamma konvertiert, wenn die LUT angewendet wird. Man könnte also target-prim auf "BT.2020" setzen und dann eine 3D-LUT von BT.2020 auf den Zielfarbraum erzeugen. Das sollte dann immer stimmen. Das Problem ist, dass target-lut in Profilen derzeit nicht funktioniert, sonst könnte man BT.709 auch ohne Umweg über BT.2020 ausgeben und eine zweite 3D-LUT dafür erzeugen. Das ist genauer und so mache ich das auch derzeit.


    Ich habe für das Profilproblem ein Issue angelegt.

  • Ich teste nebenbei mal das neue Tone Mapping von gpu-next. BT.2446a ist kontrastloser und mit gamut-mapping-mode=auto auch noch dunkler. Dafür macht aber BT.2390 einiges besser als mit gpu. Die schwierigen Stellen mit illegalen Werten zeigen keine Fehlfarben mehr und die Highlights werden besser restauriert, brennen also weniger stark aus.


    Man achte auf die Wolken.


    gpu + bt.2390:


    gpu-next + bt.2390:



    Das sieht recht vielversprechend aus. Ich muss es allerdings noch längere Zeit in Bewegung testen.

    Code
    vo=gpu-next
    gpu-api=vulkan
    tone-mapping=bt.2390
    gamut-mapping-mode=clip
    tone-mapping-param=2.0

    Ach ja, Hardwaredekodierung funktioniert nur im copy-Modus.

  • tone-mapping-param=2.0


    Das war auch bei mir einer der Punkt der wirklich zu einer Verbesserung geführt hat. Wie die offizielle (ITU) Implementation 0.5 vorsehen kann ist mir ein Rätsel, das kann doch nur scheiße aussehen wenn es schon mit dem 1.0 Standard so ausbrennt in den Highlights...


    Hier ist es übrigens dokumentiert, in der offiziellen Anleitung fehlt, dass tone-mapping-param auch bei bt.2390 einen Einfluss hat.

    https://code.videolan.org/vide…acebo/tone_mapping.h#L119

Jetzt mitmachen!

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