Tim Jansen's Blog (deutsch) |
2006/01/26
Die UPnP AV Architektur (Teil 2)(Teil 1, Teil 2, Teil 3) Hier ist der zweite Teil meiner Einführung in die UPnP AV Architektur. Nachdem es im ersten Teil um UPnP ging, komme ich nun endlich zu den eigentlichen Funktionen des AV Standards. Ich plane ausserdem noch einen dritten Teil, in dem es um existierende und angekündigte Geräte gehen wird und vor allem darum, wie diese UPnP benutzen. Der UPnP Audio/Video StandardDer UPnP AV Standard dient dazu, dass Geräte über das Netzwerk Medien wie Musik, Videos und Bilder austauschen können. Die Medien können in Echtzeit gestreamt werden, beispielsweise wenn man sich per UPnP einen Film ansieht, der anderswo auf einem Server liegt. Es gibt aber auch die bislang kaum genutzte Möglichkeit, Medien von einem Gerät auf das andere zu kopieren. Beispielsweise könnte eine mit WLAN ausgestattete Kamera automatisch ihre Bilder auf einen Server kopieren, sobald sie im Netzwerk ihres Besitzers ist. Ebenso flexibel ist UPnP bei der Frage, wer von wo aus die Geräte bedient. Sowohl die teilnehmenden Geräte, als auch externe Programme oder Fernbedienungen, können theoretisch zur Steuerung benutzt werden.Aufbau der ArchitekturDas UPnP Modell kennt drei Rollen: das MediaServer Gerät, das MediaRenderer Gerät und den Control Point. Wenn man ein Stück UPnP-fähiger Hard- oder Software hat, dann nimmt diese gewöhnlich ein oder zwei dieser Rollen ein. Hier die Rollenverteilung im Detail:
Transport und FormateDie eigentliche Kommunikation zwischen MediaRenderer und MediaServer wird von UPnP nicht direkt festgelegt. Die UPnP-Spezifikation macht keinerlei Vorgabe darüber, wie die Medien von Server zu Renderer transportiert werden sollen, noch welche (Audio-, Video- etc) Formate zu unterstützen sind.Es ist letztenendes die Aufgabe des Control Points, die unterstützten Formate der beiden Geräte abzugleichen und ein passendes auszuwählen. Und es ist Aufgabe des Besitzers, sich nur solche Geräte anzuschaffen, die miteinander klarkommen, indem sie mindestens ein gemeinsames Format verstehen. Die Spezifikation benutzt in den meisten Beispielen HTTP als Protokoll, und ich habe auch noch von keinem UPnP-Gerät gehört, das mit HTTP nicht zurechtkommt. HTTP ist zwar nicht unbedingt optimal zum Streamen von Medien, aber es ist simpel und funktioniert in den meisten Fällen gut genug. Das zweite in der Spezifikation beschriebene Protokoll ist RTSP. RTSP ist im Gegensatz zu HTTP fürs Streaming konzipiert, ist aber auch deutlich komplizierter und funktioniert im Gegensatz zu HTTP nicht mit jedem File-Format. Da nicht jeder MediaRenderer jedes Format versteht, kann ein MediaServer laut UPnP-Spezifikation auch Medien in Echtzeit in ein anderes, vom MediaRenderer verstandenes Format transkodieren. Das ist vor allem bei Audio-Daten eine relativ einfache Lösung für das Formatchaos, wird bei Videos aber derzeit noch sehr viel Rechenleistung benötigen. Digital Living Network Alliance (DLNA)Die DLNA ist ein weiteres Firmenkonsortium, welches Interoperabilitätsrichtlinien festlegt und Geräte zertifiziert. Die beiden ersten Geräteklassen, für die Richtlinien herausgegeben wurden, sind Digital Media Server und Digital Media Player. Beide basieren auf dem UPnP AV Standard, und geben unter anderem das Minimum der zu unterstütztenden Transportprotokolle und Formate an. So müssen alle DLNA-zertifizierten Geräte LPCM (unkomprimierte) Audiodaten verarbeiten können. Als Mindest-Videoformat ist MPEG2 vorgeschrieben. Mit einem transkodierendem Server sollte man daher jedes mögliche Format in guter Qualität auf einem DLNA-Gerät konsumieren können, jedenfalls wenn es nicht einen Haken gäbe: die meisten Server können derzeit entweder gar nicht transkodieren, oder verstehen nur wenige Formate. Langfristig sind die DLNA Richtlinien aber sicherlich eine gute Idee.zu Teil 3. |