Generelles zu QuickTime Broadcater:
Mit QuickTime Broadcaster können QuickTime kompatible Audio- und Videomaterialien einschließlich MPEG-4 Streams für das Live-Streaming im Internet aufzeichnen und codieren.
Das Programm wurde für das Betriebsystem Mac OX entwickelt und ist in englischer, deutscher und französischer Sprache erhältlich.
Apple QuickTime Broadcaster kann von verschiedenen Servern kostenlos in der Version 1.0.1 herunter geladen werden.

Ähnlich der DaViCo Software ist es auch bei Quicktime Broadcaster Ziel der Software
Live-Übertragungen im Internet zu realisieren.
Dafür werden eine Mac OS X kompatible DV-Quelle, die Quicktime Broadcater Software, die QuickTime Player Software und einen Macintosh auf dem Mac OS X Server oder Mac OS X läuft benötigt.



Die beiden Übertragungsverfahren von QT Broadcaster:

Der QT Brodcaster kann seine Sendungen über Multi- oder Unicastnetzwerktransporte
übertragen, wobei die Wahl des Übertragungsverfahrens von der Art des Netzes abhängt.

Unicast wird in der Regel bei einer allgemeinen Übertragung im Internet gewählt.
Bei Unicast initiiert jeder Client seinen eignen Stream zum Server, wodurch viele 1 zu 1 Verbindungen zwischen den einzelnen Client zum Server entstehen können. Die Verbindung zum Server kann dabei, bei entsprechend vielen Clients, überbelastest werden. Apple empfiehlt diese Methode jedoch trotzdem als die Sicherte, um mit Quicktime Braodcast zu arbeiten.



Bei Multicast sendet der Server ähnlich wie bei einem Radiosender den Stream, bei dem sich die Clients „zuschalten“ können. Der Vorteil ist, dass die Verbindung zum Server bei vielen Clients nicht wie bei Unicast überlastet wird. Der Nachteil beim Multicast ist, dass diese Methode nur bei zwei Arte von Netzen funktioniert. Eines dieser Netze hat Zugang zum Mbone (Multicast Backbone), für Inhalte, die im Allgemeinen über das Internet verbreitet werden. Das Zweite Netz ist ein multicast fähiges Netzwerk, für Inhalte, die im Allgemeinen im Intranet verbreitet werden.



Die Übertragungsmodelle des QT Broadcasters:

Ein Sender und ein Empfänger
Die Übertragung findet in diesem Fall nur an einem einzigen Quicktime Player statt. Der QT Bradcaster kann in diesem Fall das Aufgenommene live an den QT Player senden, ohne zusätzliche Serversoftware zum Mac OS X zu haben.
Bei diesem Model sendet der QT Broadcaster einen direkten Stream an den QT Player (Client).



Ein Sender an eine begrenzte Empfängergruppe:
Dieses Modell wird von Apple für den Zweck des Fernunterrichts empfohlen.
Unter der Vorraussetzung, dass die Anzahl der Clients beschränkt ist, können QT Broadcaster und der QuickTime Streaming Server (QTSS) auf einem Computer laufen. Der QT Broadcaster sendet einen Stream an den QTSS, der dann die Übertragung an die Clientgruppe sendet. Die Anzahl der Clients die auf dem Server zugreifen können hängt von der Bandbreite der Internetanbindung und der Prozessorleistung des Servers ab.
Ein G4 Prozessor lässt bis zu 200 DSL – Verbindungen zu.



Ein Sender an eine große Empfangsgruppe (mit unbekannter Client Zahl):
Sollten sehr viele Clients mit unbekannter Anzahl die Sendung empfangen, sollten der QT Broadcaster auf einen Rechner alleine laufen und den Stream an einen Server senden auf dem der QuickTime Streaming Server läuft. Bei Bedarf können dadurch noch zusätzlich Server zugeschaltet werden.



Zur Alternative kann der QT Broadcast Server seinen Stream an ein Content- Delivery- Netzwerk senden, das mit dem QuickTime Streaming Server (QTSS) oder dem Darwin Streaming Server zusammenarbeitet.



Bewertung auf Basis verschiedener Erfahrungsberichte aus dem Internet:
Es gibt verschieden Erfahrungsberichte im Internet zu QuickTime Broadcast. Den Berichten ist zu entnehmen das bei der Wahl der Codec’s für eine gute Qualität dies auf Kosten der Bildgröße geschieht. In der Regel wurden eine Auflösung von 240x180 gewählt und dabei eine durchschnittliche Framerate von 7,6 Frames bei einer 56K Modem Verbindung, ca 15 Frames bei einer ISDN basierten Verbindung sowie eine durchschnittliche Framerate von 30 fps (NTSC) bzw 25 fps bei (PAL) wurde bei Breitbandinternetanbindungen erzielt.
Die hier ermittelten Werte aus der Internetrecherche sind zugegebener maßen nicht wirklich repräsentativ, sie zeigen jedoch, dass genauso wie bei der DaViCo Software die Grundlage für ein Funktionieren der Software eine stabile Breitbandinternetanbindungen ist.
Die durchschnittlich 30 fps (NTSC) bzw. 25 fps (PAL) bei Breitbandverbindungen lassen vermuten, dass die Codecs für Audio und Video in höchster Qualität für diese jeweiligen Obergrenzen sorgen. Die subjektive Bewertung der Qualität von Quicktime Braodcaster war jedoch bis auf wenige Ausnahmen sehr gut.

Quellen: Dieser Beitrag basiert im Wesendlichen auf der Apple Produktbeschreibung unter:
http://www.bense.net/downloads/apple_prod/quicktime_broadcaster.pdf

Die bei den Videokonferenzen zwischen Berlin-Linz bzw. Berlin-Salzburg-Linz immer wieder auftretenden Probleme haben eine erneute Testkonferenz notwendig gemacht.

Teilnehmer dieser Konferenz waren
- der Linzer Tutor
- kuzzeitig Herr Mittendorfer
- Herr Palkow(DaviKo) - vom Büro der Firma
- FHTW Videokonferenzteam

Vorwegnehmen möchten wir an dieser Stelle, dass das Testszenario nicht den vorherigen Gegebenheiten entsprach, jedoch neue Erkenntnisse und gute Ergebnisse gewonnen werden konnten.

Auf der Seite der FHTW fand die Konferenz nicht in den Räumen statt, die normalerweise für die Konferenz verwendet werden. Weiterhin ist das Notebook, welches bisher in den Konferenzen eingesetzt wurde defekt, weshalb ein neues System zum Einsatz kam. Dieses zeigte jedoch verschiedenen Auffälligkeiten die nur zum Teil behoben werden konnten. Obwohl es sich um 2,4 GHz System handelt und nur die Videokonferenzsoftware gestartet war lag die CPU Auslastung fast durchgehend bei 100%, was die Bedienung des Systems zum Teil erschwerte.

Wir werden versuchen die Ursache hiefür zu lokalisieren und zu beheben, so dass unser System am Montag wieder voll einsatzfähig ist.

Während des Testzeitraums (11:00 - 14:30) traten zwischenzeitlich wieder die bereits bekannten Probleme des abgehackt wahrzunehmenden Tons und der sporadisch auftretenden Verschlechterung des Videosignals auf.

Dank der Unterstützung durch Herrn Palkow (Firma DaviKo) konnten jedoch Wege gefunden werden diese zu beheben. Im Ergebnis konnten gute Resultate erzielt werden.

Wie bei früheren Tests war die Verbindung Berlin nach Linz besser als die von Linz nach Berlin. Die Ursache ist bisher nicht geklärt.

Dank der Unterstützung durch Herrn Palkow konnte neue Erkenntnisse im Umgang mit DaviKo gewonnen werden. Dies bezieht sich zum einen auf die Konfiguration der Software und zum anderen auf die Interpretation der Anzeigen.

Die im Fenster sichtbaren Übertragungsraten drücken die Bandbreite aus mit der unser System Audio bzw. Videodaten vom anderen Kommunikationspartner erhält. Um festzustellen wie groß die gesendete Datenmenge ist muss der Info Button gedrückt werden, durch den sich ein neues Fenster öffnet. Die im System einzustellende Bitrate limitiert den von unserem System maximal gesendeten Datenstrom. Die insgesamt verbrauchte Bandbreite ergibt sich aus der Summe der Komponenten:
1. Audiodaten
2. Videodaten
3. Steuerdaten


Im Testbetrieb hat sich gezeigt, dass die Kommunikation mit angehaktem „Send via TCP“ besser funktioniert.
Die aus unserer Sicht wesentlichen Erkenntnisse sind folgende:

1. Es ist von Bedeutung welcher Konferenzteilnehmer wen anruft, da sich hierdurch entscheiden kann, ob ein Datenstrom gegebenenfalls einmal oder mehrmals übertragen wird. Sollte es zu einer 3er Konferenz kommen (Linz, Salzburg, Berlin), so sollte Salzburg Linz anwählen und danach die Verbindung Berlin - Linz aufgebaut werden.
2. Konferenzsysteme wie Netmeeting und iChatAV erlauben laut Aussage von Herrn Palkow nur 2er Konferenzen.
3. DaviKo lässt sich über Registry Einträge sehr spezifisch konfigurieren. Zur Beseitigung der während unserer Konferenzen auftretenden akustischen Probleme, wie der abgehackten Übertragung des Audiosignals lässt sich in der Registry unter HKEY_CURRENT_USER\Software\daViKo GmbH\daViKo 2 das DWORD
„Audio Jitter Buffer“ anpassen. Der Wert ist standardmäßig auf 2 gesetzt und bezeichnet die Größe des verwendeten Audiopuffers. Ein Wert von 1 entspricht einem Puffer von 10 ms. Für unseren Test wurde der Wert auf 12 angehoben. Hierbei ist zu beachten, das es mit zunehmender Erhöhung dieses Wertes zu einer steigenden zeitversetzten Kommunikation kommt, die sich dann störend auswirkt. Wichtig ist das die Werte binär und nicht hexadezimal gesetzt werden. Im gleichen Pfad existiert weiterhin das DWORD „Audio Latency“. Die Erhöhung dieses Wertes beseitigte das während der Kommunikation gelegentlich auftretende Knacken.
4. DaviKo liefert sehr gute Audio und Bildqualitäten bei höher bandbreitigen Verbindungen( ist auf diesen Bereich spezialisiert).


Aus unserer Sicht sollten wir am Montag noch einen Versuch mit der DaviKo Software machen. Die neu gewonnenen Erkenntnisse bieten hier neues Potential. Der Verbindungsaufbau sollte jedoch mindestens 30 Minuten vor Vorlesungsbeginn (also 9:15) erfolgen, um die Systeme anzupassen und im Notfall auf Netmeeting zu wechseln. DaviKo bietet mit seinem Produkt Leistungen an, die die anderen Systeme derzeit nicht bieten, ist jedoch auf höhere Bandbreiten angewiesen. Sollte es uns am Monatg nicht möglich sein die Konferenz ordentlich mit der DaviKo Software durchzuführen sollten wir für den weiteren Einsatz Netmeeting favorisieren, deren Möglichkeiten zwar begrenzt sind, das jedoch auf geringere Bandbreiten spezialisiert ist und dadurch Schwankungen der zur Verfügung stehenden Bandbreite wahrscheinlich besser kompensieren kann.

FHTW-Videokonferenzteam

Im ersten Teil des Tests wurde eine Verbindung per Netmeeting mit den Linzer Kollegen aufgebaut.
Die Qualität des Videostreams nach Linz war gut, nicht aber nach Berlin. Audioqualität war insgesamt OK, auch Application-Sharing funktionierte einwandfrei. Um die Datenübertragung zu testen haben wir eine 10 Mb große Datei hin und hergeschickt und dabei mit einer Stopuhr Zeit gemessen. Unsere Messungen ergaben dann folgendes:

Berlin->Linz : ~200 KB/Sek
Linz->Berlin : ~100 KB/Sek

Somit lag die schlechte Übertragung des Videostroms nach Berlin NICHT an der Bandbreite. Womöglich wird die Übetragung an bestimmten Ports künstlich beschränkt, was eben zu einer nicht optimalen oder gar schlechten Qualität führt.

Im zweiten Teil des Tests war Herr Mittendorfer zu uns zugeschaltet. Die Qualität der Verbindung war etwas besser,aber nicht entscheidend.

stefan wacker
edduard datel
kenji kitamura
kirill lepski