Warum Android und Kodi/SPMC vielleicht doch keine Zukunft haben.

Wir haben Probleme Entwickler zu finden. Die meisten Leute die Android machen, machen das kommerziell, also die meisten Hersteller tun das. Jeder Hersteller hat ne eigene API, Rockchip, Allwinner ;-), AMLogic – alle wollen eine „Spezialbehandlung“, die Shield ist die erste Box die wirklich per MediaCodec und Audiotrack halbwegs ordentlich funktioniert und auch sonst ne ansprechende Hardware hat. Seit dem Firmware-Update, vor dem ich massiv mit Nvidia und Android devs selbst diskutiert habe, gab es noch „ohrenbetäubende“ Bugs, vielleicht erinnert sich der eine / andere an die Stottergeräusche beim Seek.

Leider stehen auf Android immense architektonische Veränderungen an, weil über Jahre nur „reingepatched, workarounded, etc.“ wurde. Dies hat letztlich, neben ein paar Menschlichkeiten, zum Bruch mit dem letzten Android Maintainer geführt. Dieser macht jetzt mit SPMC auf Basis von v16 weiter. MrMc hat gesehen, dass mit v16 was Video / Audio angeht kein Blumentopf zu gewinnen ist und hat die Audio-Engine / VideoPlayer von Version 17 auf Version 16 zurückportiert (!) 10 tausende Zeilen Code. Man bedenke, das ganz Zerwürfnis kam daher, dass das Audio / Video Team gesagt hat: Ey, Jungs lasst das mit v16 sein, das funktioniert nicht richtig, ihr bekommt drops, es ist ein immenser Hack und hat keine Zukunft (*) – MrMC hat das gleich kapiert – und obwohl er auch nicht mehr offiziell bei kodi dabei ist – die richtigen technischen Schlüsse gezogen.

So sachen wie inputstream / libwidevine kompiliert zu bekommen ist nur die halbe Miete. Den Content den man da bekommt wird mittels DASH zusammengebaut, d.h. je nach Bandbreite kann sekündlich der Stream / sein Größe etc. wechseln. Der „Renderer“ muss sich anpassen und das so, dass kein einziger Frame kaputt geht … Auf Android braucht das Ding alleine 500 ms um seinen Mode wieder korrekt einzustellen (im AML Decoder wird sogar forciert 500 ms geschlafen, um solche Designbugs zu beheben). Kurzum: Es ist viel Arbeit zu tun, Arbeit die man nicht mit „ach wäre doch toll“ weg oder hindiskutieren kann.

Hier wird in Android momentan nichts investiert. Es werden nur features reingepatched, weiter workarounds reingebaut. Welcher freie Mensch hat denn Lust sich in seiner Freizeit mit einer geschlossenen Platform rumzuärgern und für jede Box unterschiedliche Workarounds einzubauen? Ja, genau – keiner – deshalb kümmert sich ja auch niemand um die Androidplatform.

Eine gute Nachricht hab ich vielleicht dennoch. Ich hab mit Android’s Chef-Audio-Entwickler verhandelt (ja kodi hat ein paar Connections). Die nächste Android Version wird – wegen uns – eine IEC Passthrough Variante bekommen. Dann sollten sachen wie EAC3, Atmos, etc. kein so unglaublicher Krampf wie jetzt mehr sein. Zusammen mit unseren Audio-Änderungen in v17 sind dann zum Beispiel „Pause Bursts möglich“, sprich, wenn mal etwas Audio fehlt, kann man pause frames schicken ohne dass es „butz“ macht. All dies ist mit v16 nicht möglich … wenn sich also jemand eine Shield kauft, dann soll er nicht traurig sein, wenn viele Dinge nicht richtig funktionieren.

Für den „otto normalverbraucher“ ohne 4k, ohne Atmos, ist ein RPi3 die weitaus bessere Wahl.

Falls es technische Fragen im Detail gibt, bitte gerne Fragen. Ich wollte den Android Port vor paar Monaten mal übernehmen, hab dies auch für Audio getan und die beschissene Android v23 API implementiert, aber dann wurds mir zu dumm, mit all den „Nervbacken“ die nur nach Features, Features, Features gerufen haben …

Also: Sucht ein paar fähige Entwickler, die FernetMenta, Mapfau (inputstream Miterschaffer) und mir dabei helfen den eingeschlagenen Weg (Entkopplug von Application und Render, korrekte EGL Implementierung) mit zu gehen. Es ist viel Arbeit aber der Aufwand wird sich lohnen. Ich denke, dass das in 6 Monaten zu schaffen ist

* Um das zukunftsfähig zu machen habe ich mit FernetMenta den „nicht IEC pfad“ in die Audio-Engine eingebaut. Wir können jetzt raw passthrough sprechen, ohne die IEC frames im Sink auszupacken … einziger Abnehmer: Android und zum Glück obsolete mit v24 API. Diese Erweiterung war schon fertig, bevor v16 final wurde …

Zum Vergrößern anklicken....

unterstützte Ausgabeauflösung

2160p bis 30fps; 720p und 1080p bis 60 fps

Zum Vergrößern anklicken....