PrismCore

Aether

Die Standard-Wiedergabe-Engine auf iPhone, iPad, Mac, Apple TV und Apple Vision Pro — bei jeder Installation aktiv, nicht hinter einem Schalter.

Aether laden ›

Es ist ein Swift-Package, kein Framework, das du bauen musst. Alles, was heute schon eine URL an AVPlayer gibt, kann es nutzen.

PrismCore soll unsichtbar sein: du öffnest einen Film, und er läuft. Was du dabei bekommst, ist genau das, was ein Player, der sein Bild selbst zeichnet, aufgeben muss.

1. 1

   Die Datei wird gelesen, nicht umgewandelt

   FFmpegs Demuxer öffnet den Container — MKV, MPEG-TS, AVI — und trennt dessen Inhalt in die einzelnen Spuren: Bild, jede Tonsprache, jeden Untertitel. Dabei wird nichts decodiert und nichts konvertiert; die Datei wird nur auseinandergelesen.

2. 2

   Die Spuren werden unverändert neu verpackt

   Dasselbe komprimierte Bild und derselbe Ton wandern in fragmentierte MP4-Stücke, beschrieben von einer Playlist der Art, die AVPlayer nativ öffnet. Es ändert sich die Verpackung, nicht der Inhalt — Bit für Bit dasselbe Video und derselbe Ton wie in der Datei.

3. 3

   Eine lokale Adresse liefert es aus

   Diese Stücke bekommt AVPlayer von 127.0.0.1, der Adresse, die das Gerät nie verlässt, als würde der Film gestreamt. Genau das ist der Trick: Apples Player streamt gern, was er als Datei zu öffnen verweigert.

4. 4

   Den Rest macht Apples Engine

   Hardware-Decoding, Atmos-Passthrough, der Dolby-Vision-Handshake, das Spurmenü, PiP und AirPlay — nichts davon wird neu gebaut, denn aus Sicht von AVPlayer passiert hier nichts Ungewöhnliches.

Zwei Dinge lassen sich nicht umpacken und werden eigens behandelt. Untertitel, die Bilder von Text sind statt Text (die PGS in Blu-ray-Remuxen), liest Visions OCR direkt auf dem Gerät, und sie hängen sich als gewöhnliche Untertitel ein. Und eine Handvoll Codecs, die Apple gar nicht decodiert — VP9, MPEG-2, VC-1 — nimmt einen zweiten Weg, auf dem PrismCore das Bild selbst decodiert und zeichnet; dort fehlt die Oberfläche des Systemplayers, aber der Film läuft.

Auf Apple-Plattformen wählt man sonst zwischen einem Player, der das Gute behält, aber nur Apples Container öffnet, und einem, der alles öffnet, aber eigene Frames rendert und Audio zu PCM decodiert — genau dort sterben Atmos und Dolby Vision. PrismCore ist gar kein Player: es füttert AVPlayer, also gibt es nichts aufzugeben.

VLCKit und libmpv zeichnen in ihre eigene Ebene und geben dir PCM — deshalb scheitern bei ihnen die mittleren Zeilen. Das ist die Folge davon, den Renderpfad zu besitzen, kein Versehen. AVPlayer scheitert an der ersten und letzten Zeile, weil er nur Container annimmt, für die Apple Unterstützung liefert.

Package hinzufügen, dann eine URL übergeben. Ein Einstiegspunkt prüft die Quelle und gibt entweder eine Playlist für AVPlayer oder eine bereits gestartete Software-Pipeline zurück.

.package(url: "https://github.com/Wenzlik/PrismCore.git", from: "1.8.7")

switch try await PrismCoreEngine.open(url: mkvURL) {
case .remux(let session, let playlist):
    player.replaceCurrentItem(with: AVPlayerItem(url: playlist))
    …
    await session.stop()

case .software(let pipeline):
    hostView.layer.addSublayer(pipeline.displayLayer!)
    pipeline.play()
}

Sobald die erste Wiedergabe läuft, lohnen sich zwei Optionen. Gib der Session ein Cache-Verzeichnis, und ein Container ohne eigenen Index sammelt sich beim Abspielen einen — die nächste Wiedergabe sucht dann wie eine indexierte Datei. Dasselbe Verzeichnis trägt die Vorschaubilder für die Suchleiste: eine eigene kleine Pipeline — separater Kontext, Decoding auf der CPU, Cache pro Keyframe — die deshalb nie die Wiedergabe aufhält, zu der sie gehört, welche Engine auch läuft.

let session = try PrismCoreSession(url: mkvURL, keyframeIndexCacheDirectory: caches)

let previews = SeekPreviewService(url: mkvURL, keyframeIndexCacheDirectory: caches)
let frame: CGImage = try await previews.thumbnail(at: 42 * 60)

Mindestversionen sind iOS 16, tvOS 17, macOS 14 und visionOS 1. FFmpeg kommt über MPVKits dynamische xcframeworks, ein Host mit MPVKit fügt also keine neuen Binärabhängigkeiten hinzu. Wenn deine CI die Abhängigkeiten auflöst, pinne eine exakte Version und halte die eingecheckte Package.resolved damit im Gleichschritt — sonst laufen ein Gerätebuild und ein TestFlight-Build still auf verschiedenen Engines.