Teil 2: Anwendungsbeispiele einer flexiblen Middleware für Infotainment-Systeme
Die Multimedia-Engine: Teil 2
Fortsetzung des Artikels von Teil 1
Literatur und Links:
[1] Bischoff, J.; Cochlovius, E.; Tien, M.:Flexible Software-Architekturen für Embedded Multimediasysteme. Elektronik automotiveJuni 2002, S. 63ff.
[2] www.microsoft.com/mind/0596/movie/movie.asp
[3] www.smsc-ais.com/AIS/content/view/623/498
Jobangebote+ passend zum Thema
verwandte Artikel:
Die Multimedia Engine
Elektroniktrends im Fahrzeug
Neue Möglichkeiten in der Telematik
Audio-Genuss auf vier Rädern
 | Dr. Elmar Cochlovius erhielt seine Ausbildung an der TU Braunschweig und in den USA. Bei Bosch hat er an der Systemmodellierung und Entwicklung von Autoradios und Navigationssystemen gearbeitet. Seit 1999 ist er bei Harman/ Becker. Als Director Multimedia Architectures verantwortet er die Definition und Entwicklung von Multimedia- Architekturen und deren Integration in die Infotainmentsysteme von Harman/Becker. ecochlovius@harmanbecker.com |
 | Shrikant Acharya ist Präsident und CTO von Margi Systems, einer Firma von Harman International Industries. Er verantwortet die Entwicklung von Software-Bibliotheken und Decoder-Stacks für Multimedia-Applikationen. Shrikant Acharya arbeitet mit an zukünftigen System-Lösungen für Harman/Becker-Produkte und evaluiert dafür benötigte Schlüssel-Komponenten. |
Die vorgestellte Multimedia-Engine hat sich in mehreren Kundenprojekten bewährt, teilweise bereits in der Serienproduktion. Im Vergleich zu der monolithischen Architektur traditioneller Lösungen sind dabei folgende Vorteile der MME sichtbar geworden:
- Flexible Filtergraph-Architektur: Hierdurch ist es möglich, unterschiedliche Benutzerszenarien mit einem einheitlichen und durchgängigen Paradigma abzubilden.
- Hardware-Transparenz: Durch Kombination der Filtergraphen mit der Multimedia-IPCKommunikationsschnittstelle ist die Einbindung externer Decoder-Bausteine deutlich vereinfacht und aufgrund der geringen CPU-Belastung in vielen Fällen überhaupt erst sinnvoll.
- Datenbank für Metadaten: Die Einbindung einer SQL-Datenbank als zentralen Speicher für alle Arten von Metadaten erlaubt neue Bedienkonzepte wie Geräte-Transparenz und erleichtert die Trennung von Media-Datenverarbeitung und Media-Management.
- Connectivity und Medien-Protokolle: Das modulare Treiberkonzept mit dedizierten Modulen zur Synchronisation der Medien-Träger mit der Datenbank ermöglicht die Einbindung neuer Konsumelektronik-Geräte, Schnittstellen und Protokolle, ohne die Gesamt-Architektur zu beeinträchtigen.
Während die vorgestellten Szenarien sich zunächst auf ein Einzelplatzsystem konzentriert haben, lässt sich die Architektur der MME auch sehr vorteilhaft auf ein Mehrplatzsystem, etwa mit einem integrierten Rear-Seat-Entertainment (RSE) anwenden.
Wie in Bild 9 dargestellt, basiert das System auf einer zentralen Headunit (HU) und einem über einen Bus mit hoher Übertragungsrate (z.B. MOST) angebundenen RSE-System. Da die MME unter dem Betriebssystem QNX läuft, stehen auch Q-Net, beziehungsweise „Q-Net over MOST“ als Netzwerk-Abstraktion zur Verfügung. Damit lassen sich weitere Bedienoberflächen, Decoder und Medienquellen an die MME und die Medien-Datenbank anbinden, die aber – aus Applikationssicht transparent – auf einem anderen Netzwerkknoten ausgeführt werden. Zentrales Media-Management und verteilte Media-Datenverarbeitung erlauben die Implementierung folgender Paradigmen:
Der in Bild 5 dargestellte Filtergraph implementiert die Funktionen eines CPUbasierten Audio-Players. Der Zugriff auf die Medien erfolgt durch den Media-Reader-Filter. Mit Hilfe der bereitgestellten Dateisysteme und Zugriffsprotokolle wie ATAPI werden die Daten in einen Read- Ahead-Buffer eingelesen. Falls aufgrund vorheriger Synchronisationsvorgänge noch nicht bekannt, wird das vorliegende Format analysiert und ein geeigneter Decoder-Filter ausgewählt. Zur Verfügung stehen neben unkomprimierten PCM-Audio üblicherweise die Formate MP3, WMA und AAC. Sie decodieren den Audio-Strom in ein PCM-Signal, welches in darauffolgenden Filtern nachbearbeitet werden kann. Beispiele hierfür sind Equalizer-Einstellung und -Anzeige. Der Media-Writer-Filter gibt das aufbereitete PCM-Signal schließlich an die Audio-Senke aus.
In Bild 6 ist als erste Verfeinerung die CPU-basierte Encodierung bei gleichzeitiger Audio-Wiedergabe dargestellt. Entsprechend dem Szenario besteht der Filtergraph aus zwei parallelen Ästen, welche von einem gemeinsamen Media-Reader-Filter ausgehen. Der Media-Reader liefert einen einzigen PCM-Audio-Strom, ausgehend von einer Audio-CD. Dieser Audio-Strom wird im WMA-Encoder-Filter encodiert und über einen Media-Writer-Filter auf der Festplatte gespeichert. Die gleichen PCM-Daten werden über den Equalizer und einen weiteren Media-Writer an die Audio-Senke ausgegeben.
Die Limitierung dieses Szenarios ist offensichtlich: Benutzer-Aktionen wie schneller Vorlauf oder Titelsprung sind hier nicht möglich, da sie den PCM-Audio-Strom und damit auch die Encodierung unterbrechen würden. Der Grund dafür ist der gemeinsam genutzte Media-Reader-Filter, der genau einen Audio-Strom vom CD-Laufwerk lesen kann. Ein zweiter, davon unabhängiger Audio-Strom scheitert an der Lesekopf-Trägheit aktuell verfügbarer automotive-tauglicher Laufwerke. Dieser Nachteil wird mit dem in Bild 7 dargestellten Filtergraph des Rip-and-Play-Szenarios überwunden. Die deutlich höhere Geschwindigkeit von Festplatten erlaubt den Einsatz eines zweiten, unabhängigen Media-Reader-Filters, welcher auf die bereits encodierten Daten der Festplatte zugreift und sie in einem zweiten Filtergraphen, einem WMA-Decoder-Filter, zur Verfügung stellt. Die Audio-Wiedergabe erfolgt hier also nicht vom Original-Medium wie in Bild 6. Da das CD-Laufwerk durchaus mit dreibis achtfacher Geschwindigkeit lesen kann, ist schon nach kurzer Vorlaufzeit genügend Material auf der Festplatte vorhanden, um auch Trick-Play- Kommandos ausführen zu können.
Bei schnellen CD-Laufwerken wird hier aber eine weitere Limitierung sichtbar. Der CPU-basierte Encoder benötigt erhebliche CPU-Leistung, die linear mit der Bandbreite des Audio-Stroms, beginnend bei etwa 50 MIPS, ansteigt. Um die Vorteile des Rip-and-Play-Szenarios voll nutzen zu können, ohne dabei andere Applikationen zu beeinträchtigen, ist eine Entlastung der CPU durch einen externen DSP notwendig.
Das Szenario für das DSP-basierte Rip-and-Play ist in Bild 8 dargestellt. Der Unterschied zu Bild 7 besteht in der Verlagerung rechenintensiver Filterfunktionen in den DSP. Der Multispeed-WMA-Encoder wird mit Hilfe des DSP-Link-Filters über die Multimedia-IPC in den DSP ausgelagert. Über den Downlink werden PCM-Daten in den DSP gesandt, während die encodierten Daten über den Uplink zurück in die CPU geladen werden. Der Wiedergabe-Zweig des Filtergraphen nutzt die DSPBeschleunigung auch für den Decoder, der mit einem DSP-Writer-Filter angebunden wird. Dieser hat nur einen Downlink-Kanal, da der decodierte PCM-Strom direkt vom DSP über einen eigenen Media-Writer-Filter an die Audio-Senke ausgegeben wird.
Die Partitionierung mit der höchsten Flexibilität, auch bei Einsatz einer kostengünstigen CPU, ist in Bild 4 dargestellt. Sie ist gekennzeichnet durch einen separaten DSP für die Decodierung aller DVD-Formate einschließlich der benötigten Audio-Formate. Alle weiteren Audio-Funktionen einschließlich der Encodierung sind einem zweiten DSP zugeordnet.
Beide DSPs sind über die MM-IPC an die CPU angebunden. Aufgrund der hardware-spezifischen Anpassung der MM-IPC lassen sich PCI-basierte DSPs direkt anbinden (DSP1) oder über einen dedizierten Bus, der durch ein FPGA geführt wird (DSP2). Die Skalierbarkeit dieser Lösung wird daran deutlich, dass durch Entfallen von DSP1 ein Low-End-Infotainment-System ohne DVD-Funktion entsteht, ohne dass die verbleibenden Multimedia-Funktionen verändert werden.
- Die Multimedia-Engine: Teil 2
- Literatur und Links:
