Ein Einblick in Miracast

Es handelt sich bei Miracast um die Zertifizierungs-Bezeichnung für Geräte, die die Wi-Fi-Display-Spezifikation der Wi-Fi Alliance erfüllen. In dieser Spezifikation ist definiert, wie Audio- und Videomaterial in HD-Qualität (High-Definition) mit 1080p zwischen einem Source-Gerät (Quelle) und einem Sink-Gerät (Senke) gestreamt werden kann. Die Technik wurde als Wi-Fi-basierter Ersatz für HDMI-Kabel für den Consumer-Markt konzipiert und ermöglicht beispielsweise die reibungslose Übertragung von Video-Inhalten aus einem Smartphone an ein Fernsehgerät. Die Rolle der Miracast-Technik als Ersatz für HDMI-Kabel impliziert die HDCP-Unterstützung (High Definition Content Protection) für eine kontrollierte Verteilung geschützter Inhalte. Die Grundlage hierfür ist die Wi-Fi Peer-to-Peer-Spezifikation, die ein direktes Verbinden zweier Wi-Fi-fähiger Geräte nach dem Peer-to-Peer-Prinzip (P2P) ohne zwischengeschalteten Access Point (AP) gestattet. Der P2P-Modus ersetzt den ursprünglichen Wi-Fi Ad Hoc-Modus, bei dem ein Gerät im Netzwerk zum Group Owner (GO) erklärt wird, um den übrigen Clients im Netzwerk in dieser Rolle prinzipiell die Funktionen eines AP zur Verfügung zu stellen. Ein entscheidendes Merkmal der Wi-Fi-Display-Spezifikation ist die Tatsache, dass kein übergreifendes System für das Erstellen, die Verteilung und die Wiedergabe von Audio- und Videomaterial definiert wird. Stattdessen definiert die Spezifikation lediglich die Funktionsweise der Verbindung zwischen der Source-Softwarekomponente, die den Inhalt sendet, und der als Empfänger fungierenden Sink-Komponente. In der Spezifikation ist festgelegt, wie die beiden Wi-Fi P2P-Geräte die Verbindung aushandeln, wie der Inhalt zu formatieren ist und wie er übertragen wird (Bild 1). Offen bleibt dagegen, um welche Inhalte es sich handelt und wie diese letztendlich genutzt werden. Zusätzlich definiert die Spezifikation einen User Interface Back Channel (UIBC). Dieser ermöglicht es, Maus- oder Touchscreen-Ereignisse vom Senken-Gerät, auf dem der Inhalt wiedergegeben wird, als Steuerbefehle an die Quelle zurück zu übertragen, wodurch sich – über das reine Kopieren des Quell-Bildschirms hinaus – vielfältige weitere Anwendungsmöglichkeiten eröffnen. Bild 1. Grundsätzliche Architektur der Wi-Fi-Display-Spezifikation Als Inhalt kommt deshalb nicht allein der Bildschirm des Smartphones in Frage, sondern es kann sich auch um Inhalte handeln, die im Smartphone gespeichert sind und per Wi-Fi Display gestreamt werden, ohne auf dem Quell-Gerät selbst wiedergegeben zu werden. Ebenso ist es möglich, nur einen Teil des Smartphone-Displays (z. B. eine Karten-Applikation) zu streamen, was ebenfalls viele neue Anwendungsmöglichkeiten jenseits des reinen Duplizierens des Mobiltelefon-Displays erschließt. Liegt der Inhalt nicht als H.264-Video oder in einem der in der Wi-Fi-Display-Spezifikation definierten Audioformate vor, ist vor dem Streamen an die Senke ein Transcoding im Smartphone erforderlich. Der erste Schritt besteht im Einrichten einer P2P-Verbindung zwischen zwei Geräten, wobei das eine Gerät als P2P GO und das andere als Client dient. Ist dies geschehen, kann jedem Gerät eine IP-Adresse zugewiesen werden und es besteht die Möglichkeit zur Nutzung der existierenden TCP- oder UDP-Mechanismen. Wi-Fi Display erschafft keine neuen Protokolle, definiert aber neue Control Messages und nutzt die standardmäßigen RTSP-over-TCP-Methoden zum Austausch dieser Steuerungsnachrichten. Senke und Quelle informieren sich gegenseitig über ihre Fähigkeiten beispielsweise in Sachen Auflösung und Codec-Format sowie darüber, ob die Quelle ein Verschlüsseln des Inhalts mit dem zwischen den Geräten ausgetauschten HDCP-Schlüssel verlangt. Sind diese Verhandlungen erfolgreich abgeschlossen, beginnt die Quelle mit dem Streamen des H.264-Videos und/oder des AAC/LPCM/AC-3-Audiomaterials als MPEG2 TS-Kapselung per RTP over UDP. Die Senke nimmt die UDP-Pakete dann an einem bestimmten Port entgegen, um den Stream zu decodieren und wiederzugeben. Da Wi-Fi Display lediglich beschreibt, wie die Übertragung von Inhalten abzuwickeln ist, während der Aufbau eines kompletten Systems offen bleibt, wird diese Technik üblicherweise in die eigene Applikation eines OEM integriert werden oder Bestandteil einer übergeordneten Applikation sein. Zum Beispiel wird die Mirrorlink™-Lösung des Car Connectivity Consortium die Technik bis Ende 2013 als Option bieten [Brakensiek]. Mirrorlink™ ist ein Standard, der die Verbindung eines Smartphones mit einem In Vehicle Infotainment-System (IVI) definiert. Der ursprüngliche Anwendungsfall aus dem Consumer-Segment, Smartphone-Inhalte per HDMI-Dongle an ein Fernsehgerät weiterzuleiten, kommt dem eigenständigen Wi-Fi-Display-System am nächsten und dürfte meist am besten mit einer ASIC-Lösung implementiert werden. Komplexere Implementierungen, die Wi-Fi Display als zusätzliche Funktion in ein bestehendes System integrieren, erfordern dagegen eine Kombination aus Prozessor und Wi-Fi-Baustein, mit der sich die Wi-Fi-Stacks sowie die Video-Encoder- oder Decoderfunktionen effizient und mit minimalen Rückwirkungen auf die existierenden Funktionen implementieren lassen. Voraussetzung hierfür ist ein Wi-Fi-Baustein, der die Weiterführung der bestehenden Wi-Fi-Station-Funktionalität parallel zum P2P-Modus erlaubt (Concurrent Mode) und durch Auslagern eines Teils der Paketverarbeitung die Interruptbelastung des Prozessors minimiert. Außerdem wird ein Prozessor benötigt, der die nötigen Hardwarebeschleuniger und die erforderliche Speicherbandbreite für die Videoverarbeitung mitbringt. Texas Instruments bietet für die Wi-Fi-Funktion und den Prozessor Systemlösungen an, die diesen Anforderungen gerecht werden. Bei den Produkten der Wilink8-Familie von TI handelt es sich um drahtlose Wireless-Kombibausteine, die Unterstützung für Wi-Fi (802.11n, 2.4GHz und 5GHz), Bluetooth (BT), Bluetooth Low Energy (BLE) und ANT bieten und optional als Automotive-qualifizierte Q100-Versionen lieferbar sind. Sie verfügen über einen internen Koexistenz- und Priorisierungs-Mechanismus, der die konkurrierenden Zugriffe auf die Luftschnittstelle zwischen Wi-Fi und BT koordiniert, um die jeweiligen Durchsätze zu optimieren und die Dienstqualität zu wahren. Wichtig ist dies im Kontext der Audio/Video-Verteilung, wenn Inhalte per Wi-Fi empfangen werden, während das decodierte Audiosignal per BT und A2DP an Kopfhörer oder Lautsprecher gestreamt wird. Ein entscheidendes Feature, das zum geringen Host-Overhead der Wilink8 Wi-Fi-Lösung beiträgt, ist die Verwendung des internen Speichers im Gerät zum Puffern der Datenpakete. Dies nämlich minimiert die Zahl der vom Host empfangenen Interrupts sowie die Folgewirkungen des Wi-Fi-Betriebs auf das existierende System. Illustriert ist dies in Tabelle 1, die zeigt, wie die Pufferung in einem mit 1,5 GHz getakteten OMAP5 zur Minimierung der Interruptbehandlung führt. Die Tests wurden mit iperf durchgeführt, während mpstat zum Messen der Auslastung diente. Darüber hinaus sind die Wilink8-Bausteine in der Lage, den Parallelbetrieb zu unterstützen. Wi-Fi Display kann daher als P2P Group Owner zur bestehenden Wi-Fi-Station-Funktionalität eines Produkts hinzugefügt werden oder als ein P2P-Client die vorhandene AP-Funktionalität ergänzen. Wilink8-Treiber sind für Linux, Android und QNX verfügbar. Es stehen zwei verschiedene Prozessor-Optionen zur Wahl, die auf unterschiedliche Endanwendungen zielen. Zunächst gibt es das Referenzdesign „Remote Media Display“, basierend auf einem DM8134-Prozessor mit Cortex-A8-Core (600 MHz) und einem für 1080p60 geeigneten Videobeschleuniger und WiLink8. Dieses Referenzdesign nutzt die Flexibilität des Prozessors zur Bereitstellung von Lösungen, die nach 1080p60-Video oder der Fähigkeit verlangen, als Senke für mehrere Wi-Fi-Display-Quellen zu fungieren und diese auf dem Bildschirm zusammenzufügen, und die außerdem kurze Latenzzeiten (Glass to Glass) bis 120 ms herab von einer latenzarmen Quelle erfordern. Mit einem Telefon des Typs Google Nexus4 (unter JellyBean 4.2 oder 4.3) kann die Lösung den 720p30-Stream mit 5 MBit/s abwickeln, mit einer 40-prozentigen Auslastung des A8-Cores und einer Glass-to-Glass-Latenz von 350 ms (wovon mehr als 200 ms auf das Konto der Nexus4-Quellimplementierung gehen). Das Referenzdesign nutzt eine optimierte gstreamer-Pipeline zum Minimieren der Latenz beim Decodieren des RTP-Streams. Das Referenzdesign kann von TI Eco-System-Partnern bezogen werden. Für Automotive-Infotainment--Applikationen gibt es darüber hinaus eine Demoversion der Software auf der Basis von GLSDK 6.02 Linux, die auf Prozessoren der Typen OMAP5™ und Jacinto 6 lauffähig ist. Beide Prozessoren basieren auf der gleichen Architektur, mit einem Dual Core Cortex-A15 und 1080p60-Videobeschleunigern. Der Nexus4-Stream wird derzeit mit einer CPU-Auslastung von 7 % (bei 1,5 GHz Taktfrequenz) decodiert, allerdings beträgt die Latenz in dieser Demoversion wegen der Verwendung einer nicht optimierten gstreamer-Pipeline mehr als 900 ms. In Anwendungen dieser Art dient Wi-Fi Display lediglich als Komponenten-Technologie in einem größeren System wie Mirrorlink™, sodass die Integration durch die Anbieter der Mirrorlink™-Applikation erfolgt. Beide genannten Prozessoren bieten in Kombination mit Wilink8-Bausteinen die Flexibilität und den Durchsatz, um entweder als Senke für mehrere Quellen zu fungieren und in dieser Rolle Inhalte von verschiedenen Quellgeräten wiederzugeben, oder um als mehrere Quellen denselben Inhalt an verschiedene Senken-Geräte zu übertragen. Referenzen Brakensiek, J. (n.d.). http://carconnectivity.wordpress.com/2013/04/23/mirrorlink-in-2013-beyond-screen-replication/. TI. (n.d.). Von http://processors.wiki.ti.com/index.php/WL18xx_Overview. Wi-Fi Alliance. (n.d.). Von http://www.wi-fi.org/knowledge-center/published-specifications. ----- Autor: Dr. Iain Hunter, System Applications Engineer Wireless Connectivity Solutions, © Texas Instruments