Mit dem Framework Pipewire möchten die Entwickler alte wie neue Probleme im Bereich Audio und Video lösen.

Audio und Video gehören heute zu den wichtigen Anwendungsbereichen sowohl beim privaten Desktop-Computing wie im professionellen Bereich. Aktuelle Trends und der wachsende Fokus auf Sicherheit bei Rechnern, Betriebssystemen und Anwendungen stellen das Segment Multimedia aber vor neue Herausforderungen.

Mit Wayland gelingt es standardmäßig nicht mehr, Vorgänge auf dem Bildschirm mit Screen-Rekordern wie Recordmydesktop oder Vokoscreen aufzuzeichnen: Das Anzeigeprotokoll verzichtet aus Gründen der Sicherheit auf Netzwerktransparenz. Auch die Ausgabe von Audio- und Video-Dateien in Containern wie Flatpak [1] erfordert neue Techniken.

Hier kommt Pipewire ins Spiel, ein neues Multimedia-Framework für Linux aus den Labors von Red Hat beziehungsweise dessen Community-Version Fedora – da, wo auch Wayland und Flatpak herkommen. Hauptentwickler von Pipewire ist der bei Red Hat beschäftige Wim Taymans [2], ein Veteran aus der Gstreamer-Entwicklung. Der Name Pipewire bezieht sich auf die Pipelines in Gstreamer, die unterschiedliche Systeme zum Verarbeiten von Medien zu komplexen Ketten verknüpfen (Abbildung 1). Das Framework basiert auf einer neuen API namens Simple Plugin API oder kurz SPA.

Abbildung 1: Der Name Pipewire geht auf die Pipelines zurück, über die Gstreamer Aktionen auf Multimediadaten zu Ketten zusammenfügt. (ScotXW, CCO 1.0, commons.wikimedia.org)

Pipewire erblickte erstmals im September 2017 das Licht der Öffentlichkeit [3], hat seitdem aber eine rasante Entwicklung durchlaufen. Zwar enthält Fedora 27 die Software bereits, doch diese hat noch ein gutes Stück Weg vor sich. Unter Fedora 27 zeigt ein Terminal die installierten Pakete von Pipewire (Abbildung 2). Per pipewire-cli gelangen Sie auf der Kommandozeile in einen Modus, in dem diese direkt Befehle entgegennimmt. Nach Eingabe von help sehen Sie die Optionen, die die Software akzeptiert (Abbildung 3).

Abbildung 2: Die derzeit verfügbaren fünf Pakete zu Pipewire weisen die Anwendung als Media Sharing Server aus.

Abbildung 3: Das Tool pipewire-cli zeigt auf der Kommandozeile mit dem Parameter help die verfügbaren Befehle an.

Hardware teilen

Pipewire verfolgt mehrere Ziele. Primär dient es sich als Framework für Audio und Video an, auch für den professionellen Bereich. Dabei gibt es drei große Herausforderungen im Video-Bereich zu lösen. Die erste davon stellt das Teilen von Geräten dar, das es ermöglicht, dass mehrere Anwendungen die gleiche Video-Hardware gemeinsam nutzen, wie etwa eine Webcam.

Das will Pipewire zweitens auf sichere Art und Weise ermöglichen, um zu verhindern, dass unberechtigte Prozesse die Daten abgreifen. Als drittes Ziel peilt Pipewire den effizienten Austausch von Multimediadaten zwischen Anwendungen an – etwa Fullscreen-Captures von einem Compositor wie der Gnome Shell zu einer Browseranwendung für Videokonferenzen wie Google Hangouts oder Nextcloud Talk.

Da die Sicherheit einer der treibenden Kräfte für den Umstieg vom X-Window-System auf Wayland war, legten die Entwickler viel Wert darauf, die problematischen Stellen nicht im Wayland-Compositor nachzubilden. Beispielsweise erlaubt Pipewire nur dann, dass eine Applikation ein Capture vom Vollbild macht, wenn diese sich mit dem Compositor über ein D-Bus-API oder ein Flatpak-Portal abgestimmt und die Erlaubnis eingeholt hat.

Jack implementiert

Für den Audio-Bereich integrierten die Developer mittlerweile das Jack-Protokoll [4] in Pipewire. Das ermöglicht, entsprechende Anwendungen ohne Jack auszuführen. Später könnte Pipewire dann den jetzigen Standard-Soundserver Pulseaudio ablösen. Schon jetzt dürfen alle Anwendungen Pipewire im Hintergrund einsetzen, die Gstreamer oder Alsa nutzen. Ein Blick auf die schematische Darstellung zeigt, dass das neue Framework als verbindende Schicht zwischen Kernel-Modulen und Anwendungen fungiert (Abbildung 4).

Abbildung 4: Pipewire knüpft Verbindungen zwischen Kernel und Multimedia-Anwendungen. (Quelle: Wim Taymans)

Lediglich solche Anwendungen bleiben derzeit noch außen vor, die auf die Netzwerktransparenz von Pulseaudio angewiesen sind – dabei geht es hauptsächlich um Netzwerk-Streaming. Ein weiterer Anwendungsbereich für den Newcomer im Bereich Multimedia stellt das Verbinden von Geräten via Bluetooth dar, wobei er sich über ein entsprechendes Modul direkt ins BlueZ-Framework [5] unter Linux einklinkt.

Ende Januar hat der Desktop-Manager von Red Hat, Christian Schaller, Wim Taymans auf der DevConf 2018 im tschechischen Brno getroffen und sich über den aktuellen Stand des Projekts informiert [6]. Der Schwerpunkt der Arbeit liegt derzeit auf den Methoden, die das Screen-Sharing und Recording unter Wayland ermöglichen.

Somit hat derzeit Video die Präferenz. Es soll einerseits Anwendungs- und Desktop-Entwicklern eine neue Methode für die Freigabe des Bildschirms bieten und andererseits für Anwendungen innerhalb eines Desktop-Containers wie Flatpak einen sicheren Weg für den Zugriff auf Audio- und Videogeräte ermöglichen. Dabei sorgt D-Bus dafür, dass die Clients sich sicher authentifizieren, während Pipewire transparent Inhalte und Anwendungen innerhalb und außerhalb der Sandbox verbindet.

Neben seinem Vortrag auf der Konferenz [7] gab Taymans Schaller einen praktischen Einblick, was Pipewire im Bereich Video bereits erlaubt. So können schon jetzt zwei Anwendungen gleichzeitig auf die Webcam zugreifen. Beide nutzen dazu das Gstreamer-Framework und haben somit über das Pipewire-Gstreamer-Plugin automatisch die Unterstützung für Pipewire an Bord. Das gilt für alle auf Gstreamer basierenden Anwendungen, ohne dass Anpassungen an der Software notwendig wären (Abbildung 5).

Abbildung 5: Zwei Anwendungen greifen per Pipewire gleichzeitig auf eine Webcam zu. (Bild: Christian F.K. Schaller)

Pipewire und Plasma

Jan Grulich, ein weiterer Mitarbeiter von Red Hat, der hauptsächlich an Qt und KDE arbeitet, griff das neue Framework auf, um in einer Plasma-Wayland-Sitzung das Aufnehmen und Teilen des Desktops zu implementieren [8]. Solche Szenarien lassen sich aus Sicherheitsgründen nicht mit den Bordmitteln von Wayland abwickeln.

Die benötigte API haben die Entwickler kürzlich in XDG-desktop-portal eingefügt. Mithilfe dieser API können Anwendungen nun auf Bildschirminhalte in Wayland-Sitzungen oder einer Sandbox wie Flatpak zugreifen.

Bei Portalen handelt es sich um weit oben angesiedelte Session-Bus-APIs, die einen trennscharfen Zugriff auf Ressourcen für Sandbox-Anwendungen ermöglichen. Die Verantwortung, ob er einer Anfrage aus einem Portal den Zugriff erteilt oder verweigert, liegt dabei immer beim Benutzer. Daher führen die meisten Portal-APIs zu einer Interaktion in Form eines Dialogs, um Berechtigungen temporär oder dauerhaft zu erteilen oder zu verweigern.

Mit verschiedenen Backend-Implementierungen wie XDG-desktop-portal-kde oder XDG-desktop-portal-gtk brauchen die Entwickler nur eine API zu unterstützen, um alle Desktops anzusprechen. Das Screencast-Portal etwa funktioniert so, dass der Client zunächst eine Sitzung mit der Backend-Implementation von XDG-desktop-portal (XDP) erstellt und dann die Freigabe für den Bildschirm über einen Dialog startet (Abbildung 6).

Abbildung 6: Der Anwender wählt künftig in einer Wayland-Sitzung ab KDE Plasma 5.13 über einen Dialog den zu teilenden Bildschirm aus.

Daraufhin erstellt die XDG-Backend-Implementation einen Pipewire-Stream und sendet die Antwort samt Stream-ID an den Client zurück. Der wiederum kann sich mit dieser ID mit dem Stream verbinden und dessen Inhalt abrufen (Abbildung 6).

Plasma und Gnome

Klappt alles wie gedacht, dann bringt bereits das für den 12. Juni zum Release anstehende Plasma 5.13 eine Pipewire-Implementation mit und wertet so die Plasma-Wayland-Sitzung mit Screen-Recording, Screen-Sharing sowie Remote-Zugriff für Anwendungen mit oder ohne Sandbox auf.

Dem gleichen Unterfangen hat sich der Red-Hat-Mitarbeiter Jonas Ådahl für den Gnome-Desktop gewidmet. Hier fehlte ebenfalls ab Fedora 25 mit dem Umstieg auf Wayland die Möglichkeit zum Screencasting und für Sitzungen auf entfernten Rechnern. Für Anwendungen wie VNC oder RDP mussten Anwender über ein Jahr lang eigens eine X11-Session starten.

Ådahl fügte dem Gnome-Fenstermanager und Compositor Mutter die zwei D-Bus-APIs org.gnome.Mutter.RemoteDesktop und org.gnome.Mutter.ScreenCast hinzu. Sie stellen einen Pipewire-Stream bereit, der den Inhalt der Bildschirme des Systems enthält. Die neuen APIs ermöglichen, Vollbild-Streams oder Streams für einzelne Fenster lokal oder remote zu erstellen (Abbildung 7). Bislang ist allerdings nur Ersteres implementiert [9] – die Implementation gilt noch als experimentell.

Abbildung 7: Der Gnome-Fenstermanager Mutter erhält per Pipewire einen Stream für das Teilen des Bildschirms lokal und auf entfernten Geräten. (Quelle: Wim Taymans)

In der derzeit meistgenutzten Version Gnome 3.26 muss man die Pipewire-Unterstützung noch von Hand einkompilieren, im frisch veröffentlichten Gnome 3.28 ist das nicht mehr nötig. Canonical plant Pipewire für Ubuntu 18.10 ein – falls die Distribution im Oktober zu Wayland zurückkehrt. Bei Debian gibt es ebenfalls bereits ein Repository für den Neuzugang.

Fazit

Die vollständige Implementation und Integration von Pipewire ist ein großes Unterfangen, das sicher noch eine Weile braucht. Dann verfügt Linux hoffentlich über ein Multimedia-Framework, das länger Bestand hat als seine Vorgänger und zudem die Funktionen für Audio und Video vereint. Gstreamer erspart den Entwicklern aufgrund des entsprechenden Plugins viel Arbeit; sie müssen entsprechende Anwendungen nicht von Hand anpassen.

Dasselbe plant Wim Taymans für Anwendungen, die auf die Alsa-Userspace-API aufsetzen; den Soundserver Jack hat er bereits implementiert. Bis allerdings Pulseaudio vollständig eingebunden oder ersetzt ist, vergeht sicher noch einige Zeit. Vorerst bleibt es erhalten und gibt seinen Sound über Pipewire aus. Das betrifft aber nur Anwendungen, die nicht über Gstreamer oder Alsa, sondern direkt über Pulseaudio gehen.

Die Lösungen für das sichere Aufzeichnen beziehungsweise Teilen von Bildschirminhalten sowie Remote-Sitzungen kommen möglicherweise gerade zur rechten Zeit. Die von Jan Grulich entwickelte Lösung über Portals für verschiedene Desktops steht in wenigen Monaten – nach dem Release von Fedora 28 und Plasma 5.13 – sowohl für GTK- wie auch Qt-basierte Applikationen bereit.

Das Erreichte darf jedoch nicht darüber hinwegtäuschen, dass die Pipewire-Implementationen derzeit noch viele Fehler enthalten und wichtige Funktionen fürs Erste fehlen. Das Framework braucht also noch Zeit, bevor es als Linux-Standard auftreten darf.