Dokumentation
Werbung
Java Media Framework API Theoretischer Hintergrund und Anwendungen LVA: Java3D (Seminar) Thema: Java Media Framework API Autor: Daniel Birk Email: [email protected] Java3D (Seminar), Java Media Framework API Inhaltsverzeichnis: 1. Einleitung 2. Java Media Framework (JMF) API 3. High-Level Architektur und Erweiterungen 3.1 High-Level Architektur 3.1.1 Wiedergabe (engl. presentation) zeitbasierter Medien 3.1.2 Bearbeiten (engl. processing) zeitbasierter Medien 3.1.3 Aufnahme (engl. capturing) zeitbasierter Medien 3.2 Erweiterungen 4. Echtzeiterweiterung: JMF Real-Time Transport Protocol (RTP) API 4.1 Streaming-Media 4.2 Real-Time Transport Protocol 4.3 Architektur des JMF RTP API 4.3.1 Senden von Streaming-Media 4.3.2 Empfangen von Streaming-Media 5. Literaturstellen 6. Anhang Seite 2 Java3D (Seminar), Java Media Framework API 1. Einleitung Grundlage dieses Tutorials ist der Java Media Framework (JMF) API Guide v. 2.0 [1]. Zusätzliche Informationen und Hintergrundwissen stammen aus dem Entwicklerbereich der IBM Website [3]. Das Java Media Framework API erweitert die Funktionalität des Java SDK um weitreichende Multimediaeigenschaften. Es enthält Bibliotheken zum Einbinden zeitabhängiger Medien, wie Audio und Video. Das JMF API besteht seit Version 2.0 aus einer Kombination des Vorgängers, nämlich der Java Media Player API 1.0, und einer Echtzeiterweiterung, die früher unter dem Namen RTP Session Manager API verbreitet wurde. Inzwischen wurde die Version 2.1.1.b veröffentlicht. Diese Version bietet neben dem einfachen Abspielen auch das Aufnehmen und Bearbeiten verschiedener Medienformate. Aufgrund eines Lizenzstreits wurde, mit Ausnahme der Windowsplattformen, in der aktuellen Version die MP3-Funktionalität entfernt. Der zweite große Bestandteil des JMF API ist die Echtzeitfunktionalität. Mit ihr lassen sich zeitkritische Anwendungen, wie beispielsweise Audio- oder Videostreaming, in JavaApplikationen und Applets realisieren. 2. Java Media Framework (JMF) API Das JMF API ist eine komfortable Lösung im Umgang mit verschiedensten Mediendaten für die Programmiersprache Java. Dabei werden die Daten zunächst importiert, anschließend verarbeitet und wieder exportiert. Die importierten Daten können aus unterschiedlichen Quellen, wie z.B. Lesen einer Datei oder Empfang aus einem Netzwerk, stammen und werden deshalb allgemein als Input bezeichnet. In der Verarbeitungsphase können die importierten Daten komprimiert, konvertiert oder mit verschiedenen Filtern belegt werden. Der Output der Applikationen und Applets kann je nach Wunsch und Einsatzgebiet vom einfachen Darstellen auf einem Bildschirm bis hin zur Übertragung über ein Netz differieren. Abbildung 1 illustriert noch einmal den eben beschriebenen Verarbeitungsprozess. Seite 3 Java3D (Seminar), Java Media Framework API Abbildung 1 aus [1] Eine erste Unterscheidung ist die nach der dem Initiator. Je nachdem wie die Mediendaten zur Verfügung gestellt werden, unterscheidet man zwischen Push- und PullTransfer. Beim Push-Transfer dient in der Regel ein Server als Initiator, der die Daten sozusagen zum Client schiebt. Das RealTime Transport Protokoll (RTP) beispielsweise ist ein Push-Protokoll, das beim Streaming-Verfahren von Audio und Video eingesetzt wird. Ein weiteres Beispiel für Push-Transfer ist Video-On-Demand (VOD), das mit Hilfe des SGI MediaBase Protokoll realisiert wird. Im Gegensatz dazu ist beim Pull-Transfer in der Regel ein Client der Initiator, der die Mediendaten anfordert und auch kontrolliert. Beispiele hierfür sind das FILE- oder das HTTP-Protokoll. 3. High-Level Architektur und Erweiterungen 3.1 High-Level Architektur Die High-Level Architektur des JMF API bildet Komponenten ab, wie sie auch bei herkömmlichen analogen Verfahren verwendet werden. So speichert beispielsweise eine Videokamera die aufgenommen Daten auf einem Videoband, dass in einem Videorekorder über ein Fernsehgerät wiedergegeben werden kann. Die Videokamera ist in diesem Fall ein Aufnahmegerät (engl. capture device), das Videoband die Datenquelle (engl. data source) und der Videorekorder ist das Abspielgerät (engl. player). Die folgende Abbildung verdeutlicht diesen Sachverhalt. Seite 4 Java3D (Seminar), Java Media Framework API Abbildung 2 aus [1] Das JMF API ist stark an diesem Modell orientiert, so dass sich viele Begriffe in den Klassen- und Interfacebezeichnungen wieder finden. Daneben gibt es ein Zeitmodel, ein Eventmodel, ein Datenmodel und drei sog. Manager. Das Zeitmodel besteht aus einem Time Objekt und einem Clock Interface, dass alle Methoden zur Ermittlung der Zeit und zur Synchronisation definiert. Das Clock Interface bekommt seine Informationen wiederum von einer TimeBase, die meist auf der Systemzeit basiert. Das Eventmodel folgt den Regeln der JavaBeans. Ein Controller hat einen ControllerListener, der an ein Objekt gehängt werden kann. Tritt ein Event an diesem Objekt auf, so kann dies in der Methode ControllerUpdate behandelt werden. Alle Events des JMF API sind Unterklassen von MediaEvent. Das Datenmodell wird durch das DataSource Objekt repräsentiert. Dieses Objekt zeigt einerseits den Speicherort der Datenquelle an und andererseits das Protokoll und die Software, die nötig sind die Quelle abzuspielen. Weiterhin hat jede Datenquelle ein bestimmtes Format. Dadurch werden alle spezifischen Eigenheiten der einzelnen Formate vom JMF API verdeckt und man braucht sich als Entwickler nicht darum zu kümmern. Die drei Managerklassen sind Manager, CaptureDeviceManager und PlugInManager. Der Manager ist für Erstellung der Player, Processor und DataSource bzw. DataSink Objekte verantwortlich. Der CaptureDeviceManager verwaltet die verfügbaren Aufnahmegeräte, während der PlugInManager die installierten und verfügbaren PlugIns verwaltet. Seite 5 Java3D (Seminar), Java Media Framework API Dies sind die Hauptkomponenten der High-Level Architektur die nötig sind, um verschieden Medien zu präsentieren, zu bearbeiten oder aufzunehmen. Diese drei Bereiche werden im Folgenden näher vorgestellt. 3.1.1 Wiedergabe zeitbasierter Medien Das Abspielen zeitbasierter Medien geschieht mit Hilfe des Player Objekts. Der Player wird, wie oben erwähnt vom Manager erzeugt. Dies kann auf unterschiedliche Weise passieren. Zunächst ist wichtig zu verstehen, dass das Player Objekt verschiedene Phasen durchläuft, ehe es bereit ist die Quelle abzuspielen. Folgende Abbildung gibt den zeitlichen Verlauf dieser Phasen wieder. realize unrealized prefetch realizing realized prefetching RCE deallocate Stopped Started prefetched PFCE started SE deallocate, setMediaTime stop Events: RCE: RealizeCompleteEvent PFCE: PrefetchCompleteEvent SE: StopEvent Abbildung 3 aus [2] Zwei dieser Phasen haben besondere Bedeutung. Denn einige Methoden des Players können erst aufgerufen werden, wenn er sich im Zustand realized, andere wenn er sich im Zustand prefetched befindet. Eine komplette Übersicht darüber, wann welche Methoden aufgerufen werden können befindet sich im Anhang. Um nun ein Player Objekt zu erzeugen ruft man die Methode Player player = Manager.createPlayer(Parameter p); Seite 6 Java3D (Seminar), Java Media Framework API auf. Diese Methode stößt die Erzeugung aber lediglich an, überwacht jedoch nicht die einzelnen Phasen. Dafür muss man das ControllerListener Interface implementieren, dass in diesen Phasen die dazu passenden Events auslöst. Der Grund für diese Zerlegung des Erzeugungsprozesses ist, dass dieser von mehreren asynchron arbeitenden Threads übernommen wird, um nicht den Hauptthread für die Dauer der Erzeugung zu blockieren. Genau dies passiert beim Aufruf der Methode Player realizedplayer = Manager.createRealizedPlayer(Parameter p); was zu unerwünschten Ergebnissen führen kann. Dieser Ansatz hat aber den Vorteil, dass sich der Entwickler nicht um die Überwachung der Zustände kümmern muss. Folgende Abbildung zeigt einen Ausschnitt der Events, die ein Player Objekt erzeugt. Abbildung 4 aus [2] Die start() Methode des Players kann z.B. erst aufgerufen werden, wenn das RealizeCompleteEvent erzeugt wurde. Wenn der Datenstrom vor dem Abspielen gepuffert werden soll, wartet man damit bis das PrefetchCompleteEvent ausgelöst wurde. Weiterhin zeigt die Abbildung verschiedene Events, die auch durch den Benutzer erzeugt werden können. Zu nennen sind hierbei das StartEvent oder das StopByRequestEvent, die ausgelöst werden, wenn die Start- bzw. Pausetaste des Players gedrückt werden. Auch die Start- und Pausetasten müssen erst erzeugt werden. Sie gehören zu den Kontrollkomponenten eines Players. Um zu erfahren welche Komponenten ein Player Objekt unterstützt, ruft man die Methode Control[] controls = Player.getControls(); Seite 7 Java3D (Seminar), Java Media Framework API auf und erhält als Rückgabewert ein entsprechendes Array. Folgende Auflistung beschreibt die wichtigsten Komponenten, die die meisten Player unterstützen. Steuerkomponente mit Start- und Pausetaste: Component controlcomponenet = Player.getControlPanelComponent(); Anzeigebereich beim Abspielen von Videos: Component visualcomponent = Player.getVisualComponent(); Lautstärkeregler, bei Implementierung des GainControl Interfaces: Component gaincomponent = Manager.getGainControl().getControlComponent(); Der Rückgabewert ist jeweils eine AWT-Komponente, die man anschließend in einem Applet oder einer Applikation aufnehmen und darstellen kann. Der Parameter p, den die beiden Methoden zur Erzeugung der Player Objekte benötigen, kann entweder ein DataSource, ein MediaLocator oder ein URL Objekt sein, je nach Einsatzgebiet und Format. Letztendlich werden alle drei Objekte jedoch mit einer Pfadangabe erzeugt. 3.1.2 Bearbeiten zeitbasierter Medien Zum Bearbeiten von Mediendaten stellt das JMF API den Processor zur Verfügung. Seine Klasse ist von der Klasse Player abgeleitet, d.h. dass jeder Processor gleichzeitig auch ein Player ist. Genau wie das Player Objekt, durchläuft auch der Processor bei seiner Entstehung verschiedene Phasen. Bevor der Processor in die realizing Phase eintreten kann, muss er im Zustand configured sein. In dieser Phase wird für jede Spur einer Mediadatei ein sog. TrackControl Objekt generiert, mit dem verschiedene Parameter, wie z.B. das Outputformat, eingestellt werden. Ist diese Phase abgeschlossen wird ein ConfiguredCompleteEvent ausgelöst. Alle weiteren Schritte sind analog zum Player Objekt. Eine Abbildung aller Konfigurationsschritte des Processor ist im Anhang zu finden. Seite 8 Java3D (Seminar), Java Media Framework API Die genauen Konfigurationsschritte sind davon abhängig, was man mit dem Processor machen möchte. Nachstehende Auflistung gibt Aufschluss über die verschiedenen Möglichkeiten: a) Erzeugung des Processors mit Hilfe eines ProcessorModels b) Verwendung eines Plug-Ins (Codec und/oder Renderer) c) Ausgabeformat festlegen zu a) Erzeugung des Processors mit Hilfe eines ProcessorModels Bei der Erzeugung mit Hilfe eines ProcessorModels wird die schon von Player bekannte Methode aufgerufen, die einen „fertigen“ Processor erzeugt. Processor p = Manager.createRealizedProcessor(ProcessorModel pm); Um ein ProcessorModel zu erzeugen, braucht man eine Datenquelle, ein Array, das die für diese Quelle verfügbaren Formate enthält und einen ContentDescriptor, der den Typ der Zieldatei beschreibt. zu b) Verwendung eines Plug-Ins Jede Spur des Eingangsdatenstroms kann mit Hilfe eines installierten Plug-Ins entsprechend manipuliert werden. Dafür lässt man sich vom PlugInManager eine Liste aller installierten Plug-Ins generieren und ruft anschließend eine der Methoden setCodecChain(Condec[] c) oder setRenderer(Renderer r) für die jeweilige Spur, bzw. das jeweilige TrackControl Objekt auf. Auf diese Weise lässt sich z.B. das Audiosignal eines Videos separat vom eigentlichen Bildsignal in einem Arbeitsschritt bearbeiten. zu c) Ausgabeformat festlegen Um das Ausgabeformat einer Spur festzulegen ruft man trackcontrol.setFormat(Format f) am gewünschten TrackControl Objekt auf. Die Methode Format[] formats = trackcontrol.getSupportedFormats(); Seite 9 Java3D (Seminar), Java Media Framework API liefert ein Array aller verfügbaren Formate zurück. Außerdem kann man neben dem Format auch den Typ der Datei festlegen. Dies erreicht man mit den Methoden ContentDescriptor[] cd = processor.getSupportedContentDescriptors() und Processor.setContentDescriptor(ContentDescriptor cd), die am Processor Objekt aufgerufen werden. Hierbei muss beachtet werden, dass die Formate der einzelnen Spuren mit dem Typ der Datei, also dem ContentDescriptor kompatibel sind. 3.1.3 Aufnahme zeitbasierter Medien Das JMF API hat neben dem Abspielen und Bearbeiten von Mediendaten auch die Möglichkeit solche Daten von einem analogen Gerät, wie z.B. einem Mikrophon oder einer Videokamera, aufzunehmen. Dazu benötigt man die dritte Managerklasse, den CaptureDeviceManager. Dieser generiert ein CaptureDeviceInfo Objekt von der angegebenen Aufnahmequelle. Wenn der genaue Name der Quelle nicht bekannt ist, kann der CaptureDeviceManager eine Liste aller verfügbaren Quellen erstellen. Dabei muss lediglich das Format angegeben wie der Eingabestrom digitalisiert werden soll. Anschließend erzeugt man mit Hilfe des CaptureDeviceInfo Objektes ein MediaLoacator Objekt und mit diesem ein Player oder Processor Objekt. Folgende Prorammzeilen fassen diese Schritte noch einmal zusammen. CaptureDeviceInfo ci = CaptureDeviceManager.getDevice(„deviceName“); Alternativ: Vector v = CaptureDeviceManager.getDeviceList(new AudioFormat("linear", 44100, 16, 2)); CaptureDeviceInfo ci = (CaptureDeviceInfo)v.elementAt(1); Player/Processor p = Manager.createPlayer/Processor(ci.getLoacator()); Mit dem Player kann man den digitalisierten Eingabestrom natürlich nur wiedergeben. Will man die Daten jedoch weiterverarbeiten, wie z.B. komprimieren oder in eine Datei speichern, benötigt man immer das Processor Objekt. Nachdem der Processor erzeugt wurde lassen sich alle Manipulationen durchführen, die unter 3.1.2 Bearbeiten zeitbasierter Medien, angesprochen wurden. Um eine Datei zu schreiben, generiert der Processor vom Eingabegabestrom eine Datenquelle, die nötig ist, um später eine Seite 10 Java3D (Seminar), Java Media Framework API korrespondierende Datensenke zu erzeugen. Weiterhin muss ein ContentDescriptor gesetzt werden, der das Speicherformat beschreibt. Zum Schluss wird ein MediaLoactor Objekt erzeugt, das den Speicherort und den Dateinamen festlegt. Danach kann mit dem Schreiben kann begonnen werden. Die eben beschriebenen Schritte sind im Folgenden noch einmal, in zeitlich korrekter Abfolge der Anweisungen zusammengefasst. p.setContentDescriptor(FileTypeDescriptor ftd); DataSource source = p.getDataOutput(); MediaLocator dest = new MediaLocator(„protocol://file.ext“); DataSink filewriter = Manager.createDataSink(source, dest); filewriter.open(); Um die Größe der zu schreibenden Datei kontrollieren zu können, implementiert man das StreamWriterControl Interface und überschreibt die Methoden getControlComponent(); setStreamSizeLimit(long bytes); getStreamSize();. 3.2 Erweiterungen Unter Erweiterungen sind hier selbst implementierte Erweiterungen des JMF API gemeint. Hierdurch können eigene Formate und benutzerdefinierte Methoden zu deren Be- und Verarbeitung definiert werden. Dazu implementiert man je Zweck bestimmte Interfaces und überschreibt deren Methoden. Anschließend muss das neu geschriebene Plug-In noch registriert werden, damit es über den PlugInManager erreichbar wird. 4. Echtzeiterweiterung: JMF Real-Time Transport Protocol (RTP) API Die Echtzeiterweiterung des JMF API besteht aus den Packeten javax.media.rtp javax.media.rtp.event und javax.media.rtp.rtcp. Seite 11 Java3D (Seminar), Java Media Framework API Auch die Echtzeitfunktionalität kann durch selbst geschriebene Plug-Ins über den in 3.2 beschriebenen Mechanismus erweitert werden. 4.1 Streaming-Media Die Erweiterung des JMF API bezieht sich auf den Umgang mit Streaming-Media. Damit ist eine Technik gemeint, bei der Mediendaten, wie Audio oder Video, über ein Netzwerk übertragen werden und bei einem Client in Echtzeit wiedergegeben werden. Der Begriff schließt sowohl den Client, bei dem der Datenstrom empfangen und wiedergegeben wird, als auch den Server, der die Daten sendet, mit ein. Zwischen dem Server und den Clients bestehen dabei Ende-zu-Ende-Verbindungen, d.h. es gibt keine tatsächliche oder virtuelle Verbindung auf dem Übertragungsweg. Das besondere an dieser Technik ist, dass eine Datei bereits wiedergegeben werden kann, ohne vollständig übertragen worden zu sein. Außerdem kommt es nicht darauf, die Daten um jeden Preis fehlerfrei zu übertragen, sondern auf die Echtzeitfähigkeit des Systems. Protokolle wie HTTP oder FTP legen im Gegensatz dazu den größten Wert auf eine fehlerfreie Übertragung. Hierfür setzt es auf dem zuverlässigen TCP Protokoll auf. Das von der JMF API verwendete Protokoll ist das Real-Time Transport Protocol (RTP). 4.2 Real-Time Transport Protocol (RTP) Das Real-Time Transport Protocol (RTP) überträgt Daten mit Hilfe von Ende-zu-Ende Verbindungen in Echtzeit. Mit Echtzeit ist gemeint, sicherzustellen, dass ein konstanter Datendurchsatz erreicht wird und dabei bestimmte Zeitgrenzen eingehalten werden. RTP ist von der Architektur des Netzwerks und den eingesetzten Protokollen unabhängig, setzt jedoch meist auf dem „unzuverlässigen“ User Datagram Protocol (UDP) auf. Folgende Abbildung verdeutlicht die Architektur und Einordnung des RTP. Seite 12 Java3D (Seminar), Java Media Framework API Real-Time Media Framework and Applications Real-Time Control Protocol (RTCP) Real-Time Transport Protocol (RTP) Other Network Transport Protocols (TCP, ATM, ST-II, etc) UDP Internet Protocol (IP) Abbildung 5 aus [2] RTP kann für unicast und multicast Anwendungen eingesetzt werden. Beim unicast Verfahren werden einzelne Kopien der Originaldatei an die Teilnehmer versendet und ist daher nur für eine begrenzte Anzahl von Benutzern praktikabel. Im Gegensatz dazu übernimmt bei der multicast Übertragung der oder die Router die Dublizierung der Pakete, sodass eine sehr große Anzahl von Teilnehmern gleichzeitig bedient werden können. Aus der Abbildung wird ebenfalls ersichtlich, dass sich RTP einem zweiten Protokoll bedient, nämlich dem Real-Time Control Protocol (RTCP). Dieses Protokoll bietet dem Entwickler die Möglichkeit die Qualität der Datenströme zu identifizieren und zu überwachen. Dadurch wird eine Quality of Service Funktionalität erreicht. Die Übertragung der Mediendaten geschieht mit Hilfe von Sitzungen. Eine Sitzung ist durch eine Adresse und zwei Portnummer charakterisiert. Dabei wird ein Port für die eigentliche Mediendaten verwendet und ein zweiter für die Übertragung der Kontrollpakete des RTCP. 4.3 Architecktur des JMF RTP API Mit dem JMF RTP API kann die gesamte Funktionalität der JMF API bezogen auf Streaming-Media verwendet werden. So gliedert sich die Echtzeiterweiterung nahtlos in die High-Level Architektur des JMF API ein. Folgende Abbildung verdeutlicht die Einsatzmöglichkeiten des JMF RTP API. Seite 13 Java3D (Seminar), Java Media Framework API File Sender Processor Session Manager Capture Device Empfänger Netzwerk Session Manager DataSource DataSink Player Processor DataSink Abbildung 6 aus [2] Im Grunde sind es die gleichen wie auch beim JMF API mit der Einschränkung, dass die verwendeten Mediendaten mit Hilfe des RTP über ein Netzwerk übertragen werden. Diese Daten können auf Senderseite von einer Datei oder einem Aufnahmengerät kommen. Auf der Seite des Empfängers können die Daten entweder abgespielt oder in einer Datei gespeichert werden. Der unterste Zweig der Abbildung beim Empfänger zeigt einen Anwendungsfall, bei dem die empfangenen Daten zunächst als Input durch einen Processor laufen und anschließend in einer Datei gespeichert werden. Der Processor könnte die eingehenden Daten z.B. wiedergeben oder vor dem Speichern in ein anderes Format überführen. Bei der Übertragung mit Hilfe einer Sitzung, kann pro Sitzung nur ein Stream gesendet und empfangen werden. Deswegen ist ein sog. SessionManager nötig, sobald mehr als nur Stream übertragen werden soll. Der SessionManager des Senders startet für jeden Stream, der übertragen werden soll eine separate Sitzung. Auf Seite des Empfängers generiert der SessionManager für jeden erkannten Eingangsstream einen neuen Player oder Processor. 4.3.1 Übertragen von RTP Streaming-Media Um eine streamingfähige Datei vom Sender zum Empfänger zu übertragen sind eine Datenquelle (DataSource), ein MediaLocator und eine Datensenke (DataSink) notwendig. Der MediaLocator spezifiziert den Empfänger und den Typ der übertragenen Seite 14 Java3D (Seminar), Java Media Framework API Datei. Das Objekt wird mit einer URL erzeugt, die diese Angaben enthält. Sie könnte wie folgt aussehen: MediaLocator medialocator = new MediaLocator(„rtp://192.168.0.1:49150/audio“); Der IP-Adrsse des Empfängers geht dem Protokollname voraus, gefolgt von Portnummer und Medientyp. Die Datenquelle enthält Angaben zur Datei, die übertragenden werden soll. Der Processor wird mit Hilfe eines ProcessorModels, das auch die Datenquelle beinhaltet, erzeugt. Das ProcessorModel legt das Streamingfomat und den ContentDescriptor fest. Streamingformat und ContentDescriptor müssen zur Datenquelle kompatibel sein. Die JMF RTP API bietet eine Reihe vordefinierter Standardformate, die für die geläufigen Medientypen wie Audio und Video ausreichend sind. Die Datensenke wird am Ende vom Manager mit Hilfe des MediaLocators und dem Output des Processors erzeugt. Diese Datensenke ist als Repräsentation des Empfängers zu sehen. Nachdem die Operation DataSink ds = Manager.createDataSink(processoroutput, medialocator); ausgeführt wurde, kann der Processor gestartet, die Datenquelle geöffnet und gestartet und mit der Übertragung begonnen werden. Der eben beschriebene Weg ist nur praktikabel, wenn lediglich ein Stream übertragen werden soll. Eine Mediendatei kann jedoch mehrere Formate und damit mehrere Streams enthalten. So besteht z.B. eine Videodatei neben den Bildinformationen auch meistens aus einer Audiospur. Mit dem oben angesprochen Weg kann immer nur der erste erkannte Stream übertragen werden. Sind dagegen mehrere Streams gleichzeitig zu übertragen, benötigt man den oben angesprochenen SessionManager. Weiterhin bekommt man alle in einer Datei enthaltenen Streams über den Processor mit der Methode TrackControl[] trackControls = Processor.getTrackControls(); Alle in diesem Array enthaltenen TrackControl Objekte können anschließend aktiviert oder deaktiviert, sowie individuelle Einstellungen getroffen werden. Jedes TrackControl Objekt repräsentiert später einen Stream. Folgender Programmausschnitt beschreibt die Erzeugung des SessionManagers und der bzw. des Streams. Seite 15 Java3D (Seminar), Java Media Framework API SessionManager sm = new com.sun.media.rtp.RTPSessionMgr(); sm.createSendStream(processoroutput, 0); sm.initSession(); sm.startSession(); Der SesionManager ist ab diesem Zeitpunkt für die Übertragung verantwortlich. Mit Hilfe des zweiten Parameters der Funktion createSendStream, kann eingestellt werden, welcher Stream bzw. welches TrackControl Objekt übertragen werden soll. Steht dort eine eins, so bedeutet dies, dass der erste aktivierte Stream im Array trackControls übertragen werden soll. Steht, wie in diesem Fall eine null an dieser Stelle, so ist der tatsächlich übertragene Stream eine Mischung aller aktivierten TrackControl Objekte. Die Einzelstreams werden dabei mit Hilfe eines Multiplexers zu einem entsprechend kodierten Signal vereinigt und auf Seite des Empfängers wieder getrennt, sodass tatsächlich nur ein Stream übertragen wird, dieser jedoch aus Einzelstreams oder Spuren zusammengesetzt ist. Auf diese Weise können scheinbar mehrere Streams gleichzeitig übertragen und beim Empfänger synchronisiert abgespielt werden. 4.3.2 Empfangen von RTP Streaming-Media Das Empfangen von RTP Streaming-Media ist noch einfacher als das Senden. Dennoch muss man auch hier unterscheiden, zwischen einem einzigen Stream, der empfangen und wiedergegeben werden soll und mehreren parallelen Streams. Im ersten Fall benötigt man lediglich eine MediaLocator Objekt, das analog zum MediaLocator Objekt des Senders erstellt wird. Danach wird der Player mit Hilfe des Managers und des gerade erzeugten MediaLocators kreiert. Sobald der Player den ersten Stream entdeckt hat, löst er ein RealizeCompleteEvent aus und ist damit bereit die Quelle abzuspielen. Folgende Anweisungen fassen die eben beschriebenen Schritte zusammen: MediaLocator medialoc = new MediaLocator(„rtp://192.168.0.1:49150/audio“); Player player = Manager.createPlayer(medialoc); player.addControllerListener(ControllerListener); player.realize(); Seite 16 Java3D (Seminar), Java Media Framework API Sollen mehrere Streams einer Sitzung empfangen und wiedergegeben werden, braucht man auch hier den SessionManager. Diesem muss ein ReceiveStreamListener engehängt werden, damit neue eingehende Streams erkannt werden können. Jedes Mal, wenn nun ein neuer Stream erkannt wird, löst der Manager ein NewReceiveStreamEvent aus. Anhand des Streams kann ein DataSource Objekt gewonnen werden, dass an die Mananger Methode createPlayer übergeben wird. Auf diese Weise wird jedes Mal ein neuer Player erzeugt, wenn ein neuer Stream erkannt wird. Die folgenden Anweisungen verdeutlichen noch einmal, wie bei einem neu eintreffenden Stream einer Sitzung zu Verfahren ist. ReceiveStream stream = ((NewReceiveStreamEvent)event).getReceiveStream(); DataSource datasource = stream.getDataSource(); Player player = Manager.createPlayer(datasource); Dies waren die Grundlagen, um einen oder mehrere Streams einer Sitzung empfangen und abspielen zu können. Daneben gibt es eine Reihe weiterer Maßnahmen, die einerseits zu statistischen Zwecken gebraucht werden und andererseits die Anwendung robuster machen. So gibt es z.B. die Möglichkeit auf Veränderungen im Format zu reagieren. Dabei wird entweder ein FormatChangeEvent oder ein RemotePayloadChangeEvent ausgelöst. Im ersten Fall, ist zu prüfen, ob ein neuer Player erzeugt wurde. Ist dies der Fall, müssen die Referenzen seiner visuellen und Kontrollkomponenten auf das Player Objekt gesetzt werden. Im Falle der RemotePayloadChangeEvent, muss der alte Player freigegeben, alle Listener entfernt und ein neuer Player mit der gleichen Datenquelle erzeugt werden. 5. Literaturstellen [1]: Java Media Framework API Guide v. 2.0 [2]: vom Autor erstellte Bilder dessen Vorlage aus [1] stammt [3]: https://www6.software.ibm.com/developerworks/education/j-jmf/index.html Seite 17
