Unterstützung IINA Projekt

[spittix]

Help needed!
Aktuell stocken die Implementierungen für das HDR Feature im IINA Projekt, weil jemand mit Cocoa Programmierkenntnissen benötigt wird.
Könnt ihr unterstützen bzw. kennt ihr jemand?

Für aktuelle Video-Formate mit HDR gibt's für MacOS nur den Infuse Pro Player (leider nur mit Abo). Der beste freie Player IINA kann bisher ebenso wie VLC keine HDR Wiedergabe. Die reine HDR Wiedergabe ist in einem pull request bereits implementiert. Für eine gute Benutzbarkeit sind ein paar Anpassungen an der Benutzeroberfläche notwendig, hierfür wird Unterstützung benötigt, für Details bitte dem Link folgen.

Es wäre großartig, wenn sich jemand finden würde!

 

[Kaito]

Worum geht es hier wirklich? Dein Post sagt das nicht. Es gibt drei relevante Aspekte:

1. HDR Mapping zu SDR (für non-HDR Displays).
   Das kann mpv bereits. Problem ist, dass man hier praktisch Einstellungen wählen muss, da es keine optimale Einstellungen für alle Videos gibt, die man programmatisch finden kann. Macht es etwas unhandlich, haben aber alle Player gemein.
2. HDR Wiedergabe auf externen Bildschirmen (z.B. HDR TVs): dazu ist ein Durchschleifen der HDR Metadaten zum Display notwendig. Auch das kann mpv bereits, aber nur für Windows. Unter macOS ist das meines Wissens nach noch gar nicht möglich, aber ggf. bin ich hier outdated. Also ich hab da nur kurz reingeschaut, aber zumindest das Weitergeben von DolbyVision Metadaten an ein HDR Display via HDMI unterstützt macOS nicht und da kann dann kein Player was machen. HDR10 geht, aber das ist halt käse. Das gleiche gilt für Dolby Atmos. Die Dolby Webseite sagt hier, dass Atmos nur auf integrierten Lautsprechern von Macs unterstützt wird, aber eine Weitergabe von Atmos via HDMI an einen z.B. AV Receiver nicht von macOS unterstützt wird.
3. HDR Wiedergabe auf internen Displays (also von MBPs etc): das nennt sich dann EDR. Das funktioniert nur auf den integrierten Displays von MB(P/A)s/iMacs und glaub dem XDR und irgendwelchen Eizos. Ich glaube darum geht es, denn entsprechende Verweise findet man im PR und es wird nur auf MBPs getestet. EDR kann mpv selbst aber fast schon, das ist praktisch fertig (hilft jedoch IINA nichts, aber ggf. könnte man das übernehmen).

Persönlich finde ich jedoch, dass 3. am "wertlosesten" ist, auch wenn sich das hart anhört. Ich schaue mir Blockbuster jetzt halt nicht gerade auf einem Laptopdisplay an, selbst auf dem XDR nicht, sondern auf dem wesentlich größeren HDR TV. Und sofern man sich nicht um 2. kümmert ändert sich daran nichts. Was ich viel gerne hätte ist, dass macOS den TV in seinen HDR Modus versetzt und ihm einfach die Dolby Metadaten streamed und ihn machen lässt, wie das unter Windows auch geht. Dann bekomme ich das beste Ergebnis (auf diesem HDR TV).

Edit: um Verwirrung zu vermeiden: mpv ist der Videoplayer um den IINA eine Oberfläche herumbaut. Die "Video-Engine" sozusagen ist mpv.

 

[cyberfeller]

Help needed!
Aktuell stocken die Implementierungen für das HDR Feature im IINA Projekt, weil jemand mit Cocoa Programmierkenntnissen benötigt wird.

Nix für ungut aber das Projekt _ist_ doch eine Mac App. Wenn die jetzt nicht mal mehr _einen_ Entwickler haben...
Die haben 91 "Contributors". Ich bin mir sicher, das Problem liegt woanders

 

[Kaito]

Naja, keine erfahrenen halt. Die Hauptcontributor sind nicht mehr sehr aktiv und um die grafische Oberfläche zu verbessern und zu erweitern muss man sich nicht mit Video auskennen.

Insbesondere das Thema Farben ist aber auch wirklich hochkomplex und ich sehe es als sehr kritisch, wenn da jetzt Amateure (zumindest was Farbmanagement betrifft) versuchen in wenigen Zeilen Code neu zu erfinden, was in mpv (und zugehörigen, der Komplexität wegen sogar ausgelagerten Projekten*) seit Jahren bereits existiert und durch Experten perfektioniert wurde.


*

- Color management and format conversions for a wide variety of HDR or wide gamut color spaces. This includes support for ICC profiles, ITU-R BT.1886 emulation, colorimetrically accurate clipping, custom 1D/3D LUTs, scene-referred OOTFs (such as HLG), constant luminance formats including ICtCp and a variety of film industry formats ranging from XYZ to Sony's S-Log or Panasonic's V-Gamut.
- Dynamic HDR tone mapping, including shaders for real-time peak and scene-change detection, chroma-preserving (luma-only) tone mapping, highlight desaturation, dynamic exposure control and a variety of industry-standard EETFs including BT.2390.

 

[spittix]

Da sind durchaus noch einige Entwickler aktiv. Wie ihr anhand dieses Aufrufes sehen könnt fehlt es allerdings neben partiellem technischen Wissen auch an übergeordneter Steuerung. Die Entwicklungen sind seit ca. 1 Jahr nicht mehr zu einem Release zusammengefahren worden...
Ich finde die App wirklich gelungen und gut integriert, im Gegensatz beispielsweise zu VLC. Sie bietet für alle Mainstream-Formate Unterstützung und lässt sich sehr gut bedienen... Wäre schade, wenn es nun nicht mehr weiter ginge.

 

[oneOeight]

Statt einen neuen Fork zu machen, warum holt der die ganzen Changes nicht aus den anderen Forks und submitted die ins Main Projekt?
Das geht doch mit git.

 

[spittix]

Vermutlich weil er sich das nicht zutraut. Er sucht ja nach Unterstützung um die Merges durchzuführen.

 

[Kaito]

Statt einen neuen Fork zu machen, warum holt der die ganzen Changes nicht aus den anderen Forks und submitted die ins Main Projekt?
Das geht doch mit git.

Der Typ hat einen Fork gemacht weil er keine Lust mehr hatte die Bugs und Fehler seines PRs zu fixen und mit Leuten zu kommunizieren. Der aktuelle Zustand dieses Features ist alles andere als korrekt. Man schaue sich den Code nur an, der hardcoded den Colorspace Es gibt aber leider mehr als nur den einen für HDR. Wenn jemanden korrekte Farben nicht interessieren, dann kann man vor dem Anschauen des Videos auch einfach die Bildschirmhelligkeit hochdrehen, hat dann den gleichen Effekt. Zudem will er keine PRs verwenden. Das zusammen mit "want it to be open and easy to contribute ( not open PR, but join the group and push code directly into the repo )" (Quelle) sollte bei jedem Entwickler sämtliche Alarmglocken klingeln lassen.
Jeder der OSS schon etwas länger kennt weiß, dass dies nie funktioniert, sofern das Originalprojekt nicht zumindest semi-offiziell zu Grabe getragen wird. Alles was der Typ jetzt macht ist die ohnehin dünne Decke an Mitwirkenden nochmals aufzuteilen. Für die Nutzer ist es der schlimmste Zustand, da kein upstreaming passieren soll und damit jeder Nutzer im Hauptprojekt nichts von den Änderungen im Fork bekommt und jeder Nutzer im Fork bekommt nichts neues vom Hauptprojekt.
Total unprofessionell, so was regelt man anders. Wobei ich anstelle der Leute im Hauptprojekt dieser Person auch nichts geben würde, angesichts dessen Gebaren in oben erwähntem PR.

Aber jetzt mal Butter bei die Fische, "unsere" (macOS Nutzer) Probleme liegen im Videobereich gerade ganz wo anders. mpv (und damit über kurz oder lang auch IINA) stellt auf libplacebo um. Es ist zu erwarten, dass neue Entwicklungen bzgl. Videorenderer nur noch dort passieren. VLC soll auch demnächst auf libplacebo umstellen. Problem: das läuft auf macOS nicht, da macOS gefühlt das einzige Betriebssystem auf diesem Planeten ist, welches den offenen Standard Vulkan nicht unterstützt.
Wir stehen also gerade nicht nur was mpv/IINA betrifft, sondern auch was das noch weiter verbreitete VLC betrifft, auf dem Abstellgleis. libplacebo auf dem Mac würde HDR Support direkt sprunghaft verbessern sowie uns an allen Neuerungen teilhaben lassen, die schon heute existieren, aber auf macOS aufgrund fehlendem Vulkan nicht funktionieren. Und das EDR, um das es hier initial ging, gibt es in mpv de facto ohnehin schon fast.
VideoLAN hat initial mal ein Metal-Backend für libplacebo angefragt, aber diese Idee wurde aufgrund des Aufwands verworfen. Eine Alternative ist die Nutzung des Übersetzungslayers MoltenVK, welches Vulkan zu Metal übersetzt. Einst ein kostenpflichtiges Tool hat Khronos es gekauft und stellt es nun frei zur Verfügung. Im Prinzip ist das Wine für Grafik APIs. Die Performance ist nicht gut, aber immerhin funktioniert es. Aktuell hat man als macOS Nutzer auf mpv/IINA/VLC ja ohnehin schon (z.T. deutlich!) weniger Features als die anderen Betriebssysteme, schlicht weil die bisherige Grafik API viel weniger kann als beim Rest. Immerhin das würde behoben werden, es würde Featuregleichheit gelten, auch wenn die anderen Betriebssysteme performanter wären. Es gibt einen PR dazu bei mpv der aber schon länger eingeschlafen ist, zuletzt aufgrund technischer Probleme. Bevor die Frage kommt wieso man das noch nicht viel früher gemacht hat: MoltenVK hat ganz lange nicht genug Vulkan unterstützt, um für libplacebo genutzt werden zu können. Auch heute unterstützt es nicht 100%, aber wohl genug, wenn ich richtig informiert bin.