-
Die
vorliegende Erfindung betrifft das Übermitteln einer Gruppe von
Datenpaketen und im Besonderen das Anwenden eines Vorwärtsfehlerkorrektorcodes,
indem eine Gruppe von Paritätspaketen
die Gruppe von Datenpaketen ergänzt.
-
STAND DER
TECHNIK
-
Zur
Verteilung und zum Speichern von Multimediadaten werden die Multimediadaten über einen Kommunikationskanal übertragen.
Multimediadaten betreffen primär
Audio- und visuelle Daten, wobei sie aber auch andersartige Daten
aufweisen können. Der
Kanal ist häufig
Rauschen bzw. Störungen
und Interferenzen ausgesetzt, wie dies im Fall eines kabellosen
bzw. Funkkanals der Fall ist, sowie hohem Datenaufkommen bzw. Staus,
wie dies bei verkabeltem Internet der Fall ist, wobei beide Situationen
zu Datenverlusten während
der Übermittlung
führen.
-
Zwei
Verfahren können
zur Bekämpfung
des Datenverlustes während
der Übermittlung
eingesetzt werden. Die Vorwärtsfehlerkorrektur
(FEC als englische Abkürzung
von Forward Error Correction) ist ein Verfahren zur Umwandlung der
durch eine Folge von Zeichen bzw. Symbolen aus einem endlichen Alphabet
dargestellten Datennachricht durch Ergänzung um Paritätsdaten,
eine andere Folge von Symbolen bzw. Zeichen, um für den Fall,
dass Komponenten eines Codewortes verändert werden, und zwar unter einem
bezeichneten Schwellenwert, sicherzustellen, dass die ursprünglichen
Daten für
gewöhnlich
unversehrt bzw. intakt extrahiert werden können. FEC stellt somit ein
Fehlerausgleichsverhalten bereit, indem die zu übermittelnde Datenmenge erhöht wird.
FEC erfordert keinen Rückkanal
und ist für
gewöhnlich nicht
an den aktuellen Zustand des Kanals anpassbar. FEC garantiert jedoch
nicht, dass die Daten den Empfänger
fehlerfrei erreichen. Ein Protokoll auf höherer Ebene, das eine bestimmte
Form der Wiederholungsanforderung für Daten implementiert, das
geringe Fehler toleriert, ist für
diese Adressierung erforderlich. Bei Multimedia-Kommunikationen dominieren alternativ
die Verzögerungsanforderungen
häufig die
Anforderungen für
die fehlerfreie Übermittlung, was
der fehlerfreien Übermittlung
eine niedrigere Priorität
beimisst.
-
Die
grundlegende automatische Wiederholungsanforderung (ARQ als englische
Abkürzung
von Automatic Repeat Request) ist ein alternativer Ansatz zur Unterstützung von
soliden Datenübertragungen.
Bei ARQ werden die Daten in Pakete aufgeteilt, und wobei eine spezielle
Fehlerprüfsequenz
für den Zweck
der Fehlererkennung an jedes Paket angehängt wird. Die Datenpakete und
Fehlerprüfungen werden über einen
Kanal übertragen,
und der Empfänger
entscheidet, ob ein Übertragungsfehler
aufgetreten ist, indem die Prüfsequenz
berechnet und die berechnete Prüfsequenz
mit der angehängten
Fehlerprüfsequenz
verglichen wird. Wenn eine Diskrepanz festgestellt wird, wird der
Fehler angegeben, und der Empfänger
fordert an, dass der Sender den Rückkanal verwendet, um das Paket
erneut zu senden, indem an negatives Bestätigungs- bzw. Quittungssignal
gesendet wird.
-
Wenn
keine Diskrepanz festgestellt wird, sendet der Empfänger ein
positives Bestätigungssignal
an den Sender. Um den Sender auf den Fehler hinzuweisen, erfordert
ARQ das Vorhandensein eines Zweiwege-Kommunikationskanals. Häufig verwendet
der Rückkanal
das gleiche physikalische Medium wie der Vorwärts- bzw. Hauptkanal, wobei
die Datengröße effektiv
erweitert wird, und zwar aufgrund der erneuten Übermittlungen und der Übertragung
von Steuerinformationen. Der Unterschied zwischen FEC und ARQ liegt
darin, dass ARQ inhärent eine
Anpassung an den Kanal aufweist, da nur verloren gegangene Pakete
erneut übermittelt
werden, während
FEC für
gewöhnlich
allen Paketen Overhead hinzufügt.
ARQ kann jedoch signifikante Verzögerungen einfügen, und
zwar aufgrund der Umlauf-Ausbreitungszeit
und der Verarbeitungszeit. Der letztgenannte Zustand beschränkt die
Anwendung von ARQ in Bezug auf Multimediaübertragungen erheblich.
-
Das
U.S. Patent US-A-5.983.382 offenbart Techniken zur Bereitstellung
automatischer Wiederholungsanforderungsfunktionen (ARQ) in einem Kommunikationssystem.
Wenn eine Prüfung
eines zyklischer Redundanzcodes (CRCD) einer ersten provisorischen
Decodierung erfolgreich verläuft,
sendet der Empfänger
ein ACK-Signal (Bestätigungssignal)
an den Sender, und es ist keine neuerliche Übermittlung bzw. Übertragung
erforderlich. Wenn die Prüfung
nicht erfolgreich verläuft,
sendet der Sender ein oder mehrere zusätzliche Sendepakete, die auf ähnliche
Weise wie das erste Übermittlungs-
bzw. Sendepaket verarbeitet werden, um eine oder mehrere zusätzliche
provisorische Decodierungen des Eingangsdatenpakets zu erzeugen.
Wenn eine CRC-Prüfung
einer bestimmten dieser zusätzlichen provisorischen
Decodierungen erfolgreich verläuft, nimmt
der Empfänger
dies als Eingangspaket an und sendet ein ACK-Signal an den Sender.
-
WO
00/21236A offenbar Hybrid-ARQ-Techniken für die Fehlerbehandlung. Eine
Höhe der
Redundanz, die als Reaktion auf eine erste NACK-Nachricht übermittelt
wird, die einem ersten Versuch zum Decodieren eines Datenblocks
zugeordnet ist, ist variabel. Die Anzahl der übermittelten (und/oder angeforderten)
Redundanzeinheiten kann auf der Basis verschiedener Kriterien ausgewählt werden,
zu denen zum Beispiel die folgenden zählen: die geschätzte Kanalgüte, die
geschätzte
Blockqualität,
die Speichernutzung oder eine Reihe von ausstehenden Blöcken.
-
EP-A-0924890
offenbart ein Verfahren zur maximalen Datenübertragung über einen Datenübermittlungsabschnitt,
erreicht durch das dynamische Anpassen einer Codierungsrate und
im Besonderen einen Fehlerkorrektur-Codierrer, als eine Funktion
eines gemessenen Rückkanal-Signalparameters.
Ein Empfänger
mischt das Signal-Rausch-Verhältnis bzw.
den Störabstand
des übermittelten
Signals und bestimmt eine entsprechend geeignete Codierungsrate
und Codierungstechnik als eine Funktion des gemessenen Störabstands
und übermittelt
einen Codierungsbezeichner des bestimmten Codierers zu dem Sender.
-
„Accessing
multiple mirror sites in parallel: using Tornado codes to speed
up downloads", JW Byers
et al., INFOCOM '99,
EIGHTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS
SOCIETIES, PROCEEDINGS, IEEE NEW YORK, NY, USA, 21-25 MÄRZ 1999,
PISCATAWAY, NJ, USA, IEEE, US, 21. März 1999, Seiten 275-283, XP010323769,
ISBN: 0-7803-5417-6, offenbart ein rückkopplungsfreies Protokoll
auf der Basis von Löschcodes,
das einem Client den Zugriff auf eine Datei über mehrere Spiegel-Sites parallel
ermöglicht,
um den Download-Vorgang zu beschleunigen. Ein Protokoll unter Verwendung
von schnellen Tornado-Codes kann erhebliche Beschleunigungen zu
Lasten der Übertragung
einer moderaten Anzahl zusätzlicher
Pakete in dem Netz bzw. in dem Netzwerk realisieren.
-
Benötigt wird
eine Möglichkeit,
um die beiden Fehlerbehebungsverfahren FEC und ARQ zu kombinieren,
um deren Leistungsfähigkeit
in Bezug auf Multimedia-Datenübertragungen
zu verbessern und um Multimedia-Streaming-Dienste und das Wiedergabeerlebnis
für Anwender
zu optimieren.
-
Vorgesehen
ist gemäß einem
ersten Aspekt der vorliegenden Erfindung ein Verfahren zur Übermittlung
von Datenpaketen gemäß dem gegenständlichen
Anspruch 1.
-
Vorgesehen
ist gemäß einem
zweiten Aspekt der vorliegenden Erfindung ein Übermittlungssystem gemäß dem gegenständlichen
Anspruch 6.
-
Weitere
Ausführungsbeispiele
der Erfindung werden in den Unteransprüchen offenbart.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Es
zeigen:
-
1 ein
Blockdiagramm der Übermittlung von
Datenpaketen gemäß einem
Ausführungsbeispiel;
-
2 ein
Blockdiagramm eines Ausführungsbeispiels
für eine
Gruppe von Paketen; und
-
3 ein
Blockdiagramm eines Systems zur Übermittlung
von Datenpaketen gemäß einem
Ausführungsbeispiel.
-
GENAUE BESCHREIBUNG
-
Das
hierin beschriebene Verfahren und die hierin beschriebene Vorrichtung
können
eine verbesserte Kanalbandbreitennutzung für Multimedia-Kommunikationen
bereitstellen. Gemäß einem
Ausführungsbeispiel
weisen das hierin beschriebene Verfahren sowie die hierin beschriebene
Vorrichtung eine FEC- und eine ARQ-Komponente auf (die als eine
hybride automatische Wiederholungsanforderung (HARQ als englische
Abkürzung
von Hybrid Automatic Repeat Request) bezeichnet werden kann). Die
FEC-Komponente wird eingesetzt, um die über das User Datagram Protocol
(UDP) transportierten Multimediadaten vor Kanalverlusten und -fehlern
zu schützen,
und die ARQ-Komponente wird eingesetzt, um eine effiziente Kanalnutzung
und Sicherheit in Bezug auf Fehler in dem Rückkanal sicherzustellen. Folglich
kann eine verbesserte Qualität
bzw. Güte
der Multirnediaanwendung unter Verwendung des HARQ-Verfahrens im
Vergleich zu herkömmlichen Verfahren
unter Einschränkungen
einer begrenzten Kanalbandbreite erreicht werden.
-
Das
hierin beschriebene Verfahren sowie die hierin beschriebene Vorrichtung
können
für solide bzw.
sichere Multimedia-Kommunikationen über Netzwerke bzw. Netze eingesetzt
werden, zu denen verkabelte bzw. kabelgebundene (IP) Netzwerke, Mobilfunk-Paketdatennetzwerke,
kabellose LANs, Strom- und Telefonleitungsnetzwerke sowie zahlreiche
proprietäre,
nicht genormte Netzwerke auf Paketbasis zählen. Die Integration einer
Software- und Hardware-Unterstützung
für das
solide bzw. sichere Kommunikationsverfahren sowie die entsprechende Vorrichtung
erleichtern Multimedia-Kommunikationsanwendungen,
einschließlich
Multimedia-Streaming, Fernlehrgänge
und mobile Videoübertragungen.
-
In
einem Ausführungsbeispiel
wird das HARQ-Systemdesign an einem Paketlöschkanal eingesetzt, im Besonderen
einem Kanal, der die Positionen von Paketen bereitstellt, die während der Übermittlung
Fehler aufgewiesen haben. Ein Paketlöschkanal wird häufig auf
der physikalischen Schicht unter Verwendung einer zyklischen Redundanzprüfung (CRC)
eingesetzt.
-
Die
Abbildung aus 1 zeigt ein exemplarisches Diagramm
für die
Paketübermittlung
gemäß einem
Ausführungsbeispiel.
Die Mediendaten 110 werden in einer Gruppe von Paketen
(GOP als englische Abkürzung
von Group of Packets) 120 in Paketen zusammengefasst. In
einem Ausführungsbeispiel werden
die Größe der GOP
und die Paketgröße durch
das eingesetzte Kommunikationsnetzwerk und durch die Anforderungen
der Anwendung bestimmt. Zum Beispiel kann eine größere Paketgröße den auf die
Header der Transportprotokolle zurückzuführenden Overhead reduzieren.
Andererseits kann die größere Paketgröße auch
zu größeren Verzögerungen und
Ineffizienz in Umgebungen mit hoher Fehlerrate führen. Der entsprechende FEC-Code
wird auf die GOP angewandt, um die gewünschte Anzahl von Paritätspaketen
je GOP 130 zu erzeugen. Die GOP-Pakete bilden gemeinsam
mit den Paritätspaketen
die codierte GOP (CGOP). In einem Ausführungsbeispiel wird die Anzahl
der Paritätspakete
abhängig von
der tolerierbaren Verzögerung,
der verfügbaren Bandbreite
und/oder Kanalstatistiken ausgewählt. Zusätzliche
Faktoren können
ebenfalls berücksichtigt werden.
Die Paritätspakete
werden so erzeugt, dass sie die verloren gegangenen Datenpakete
mit geringem oder ohne Overhead ersetzen können. In einem Ausführungsbeispiel
können
die Redundanzpakete die ursprünglichen
Daten enthalten. Die Daten- und Redundanzpakete können alle
zusätzlichen
Informationen enthalten, möglichst
in Form von Headern, die für
die Systemsteuerung insgesamt und den Betrieb erforderlich sind.
In einem Ausführungsbeispiel
kann das Paket eine GOP-Anzahl, eine Paketanzahl, FEC-Parameter und/oder
die Paketgrößen enthalten.
-
In
einem Ausführungsbeispiel
werden die Paritätspakete
unter Verwendung der systematischen Reed-Solomon-Codes (RS-Codes)
erzeugt, während
die Anzahl der Paritätspakete
die gleiche Anzahl (etwaiger) der Datenpakete ersetzt, so dass die
Daten unversehrt decodiert werden können. Jeder andere geeignete
FEC-Kanalcode kann eingesetzt werden, um die Paritätspakete
zu erzeugen, wie etwa Tornado-Codes.
-
Die
Daten werden zu Paketen zusammengefasst, FEC codiert und von dem
Sender 140 zu dem Empfänger 150 übermittelt.
Der Empfänger
bestimmt, ob die übermittelten
Daten decodiert werden können.
Wenn die Daten decodiert werden können, sendet der Empfänger eine
Bestätigung
an den Sender, der die Übermittlung
jeder weiteren Redundanz für
die aktuelle CGOP 170 beendet. Die Übermittlung bzw. Übertragung
wird danach decodiert 180 und zu dem Benutzer bzw. Anwender 190 übertragen.
-
Die
Abbildung aus 2 veranschaulicht die Reihenfolge
der Übermittlung
der Daten- und Paritätspakete
gemäß einem
Ausführungsbeispiel.
Zuerst werden die Datenpakete der aktuellen CGOP zu dem Empfänger 210 übertragen.
Die Datenpakete können
mit den Daten-, Paritätspaketen
oder beiden von anderen CGOPs 220 verschachtelt werden.
Die der aktuellen CGOP entsprechenden Paritätspakete werden danach gesendet 230,
bis die Bestätigung von
dem Empfänger
ankommt 240 oder bis die maximale vorbestimmte Anzahl von
Paritätspaketen
erreicht oder überschritten
worden ist 250. In einem Ausführungsbeispiel werden die Datenpakete
der aktuellen CGOP vor den Paritätspaketen
der gleichen CGOP gesendet. Folglich kann der Overhead der Datenübertragung
und der Verarbeitung reduziert werden, wenn keine Pakete aus der
aktuellen CGOP verloren gegangen sind. In einem Ausführungsbeispiel
können
die Pakete von unterschiedlichen CGOPs verschachtelt werden, um
dem Empfänger
ausreichend Zeit für
die Verarbeitung und zum Senden der Bestätigung an den Sender zu geben.
-
In
einem Ausführungsbeispiel
implementiert der Empfänger
das GOP-Bestätigungsprotokoll,
das eine Bestätigung
an den Sender sendet, wenn der Empfänger die GOP-Daten decodieren
kann. Der Empfänger
fordert implizit mehr Reinheit, indem keine Bestätigung an den Empfänger gesendet
wird. Der Empfänger
kann mehrere Bestätigungen
für die gleiche
GOP senden. Mehrere Bestätigungen
können
eingesetzt werden, wenn der Empfänger
davon ausgeht, dass die erste Bestätigung in dem Rückkanal
verloren gegangen ist (oder verloren gegangen sein könnte).
-
In
einem Ausführungsbeispiel
unter Verwendung von RS-Codierung kann die Bestätigung gesendet werden, wenn
die Anzahl der korrekt empfangenen Pakete genau der Anzahl der ursprünglichen Datenpakete
entspricht. Die Bestätigung
kann gesendet werden, bevor die tatsächliche Decodierung erfolgt,
um die Latenz insgesamt zu reduzieren. Wenn alle Datenpakete ohne
Fehler ihr Ziel erreichen, ist keine Decodierung erforderlich, und
die Daten können
direkt zu der Benutzeranwendung übertragen
werden.
-
In
einem Ausführungsbeispiel
unter Verwendung der Tornado-Codierung kann die Bestätigung gesendet
werden, wenn die Anzahl der korrekt empfangenen Pakete der Anzahl
der ursprünglichen
Datenpakete multipliziert mit einer bestimmten vorbestimmten Konstante
entspricht, die größer ist
als eins. Die letztgenannte Konstante wird bestimmt, um eine bestimmte
gewünschte
Wahrscheinlichkeit der richtigen Decodierung bereitzustellen, und
sie wird für
jeden Tornado-Code mittels einer Computersimulation bestimmt. Wenn
alle Datenpakete ihr Ziel ohne Fehler bzw. fehlerfrei erreichen,
ist keine Decodierung erforderlich, und die Daten können direkt
zu der Benutzeranwendung weitergeleitet werden.
-
Verschiedene
andere Bestätigungsmechanismen
sind mit diesem System kompatibel. Bestätigungspakete enthalten die
CGOP-Anzahl, können aber
auch zusätzliche
Informationen aufweisen. Die zusätzlichen
Informationen können
in Form von Steuernachrichten an den Server, Kanalstatistiken und/oder
anderen Informationen gegeben sein. Bei Fehlern in dem Rückkanal,
wie etwa gelöschten
Paketen, sendet der Sender einfach die maximale Anzahl der gemäß dem Algorithmus
zulässigen
Pakete und fährt
mit der nächsten
GOP fort. Wenn die Daten nach dem Senden der vollständigen Paritätsdaten immer
noch nicht decodierbar sind, fährt
der Sender mit der nächsten
GOP fort. In einem Ausführungsbeispiel
unter Verwendung von verzögerungsempfindlichen
Multimediadaten ist die Zustellzeit nach oben begrenzt, so dass
die vorgeschlagene Lösung
im Ist-Zustand eingesetzt werden kann, ohne dass ein zusätzlicher
Fehlerauflösungsmechanismus
hinzugefügt
wird. Ein Ausführungsbeispiel
kann ein Fehlerauflösungsprotokoll
auf höherer
Ebene definieren. Es kann auch zulässig sein, dass die Anwendung
die nicht lösbaren
Kanalfehlersituationen behandelt.
-
In
einem Ausführungsbeispiel
sind das hierin beschriebene und vorgeschlagene Verfahren und die Vorrichtung
anwendbar für
das Video-Streaming über IEEE
802.11 Wireless-LAN. Auf der UDP-Ebene fungiert das IEEE 802.11
Netzwerk als ein Paketlöschkanal,
wenn die Bestätigungen
auf der physikalischen Ebene auch bei unterdrücktem UDP-Verkehr gesendet
werden. In einem Ausführungsbeispiel
werden erneute Übermittlungen
und Bestätigungen
auf der physikalischen Schicht durch den mobilen Empfänger durch
eine Multicasting-IP-Adresse in der Video-Streaming-Anwendung unterdrückt. UDP-Verbindungen
werden von dem Sender zu dem Empfänger für Datenverkehr und von dem
Empfänger
zu dem Sender für
Bestätigungen
aufrechterhalten.
-
In
einem Ausführungsbeispiel
wird das Profil des Kommunikationskanals in Bezug auf die FEC-Parameter
(die Anzahl der Datenpakete und der Paritätspakete in einer CGOP) und
anderer Eigenschaften des hierin beschriebenen Verfahrens sowie der
entsprechenden Vorrichtung berücksichtigt.
In einem Ausführungsbeispiel
können
eine CGOP-Größe und die
Anzahl der Paritätspakete
so ausgewählt werden,
dass das Integral der Paketlöschungen über die
Länge der
CGOP mit hoher Wahrscheinlichkeit kleiner ist als die Anzahl der
Paritätspakete
(für die RS-Codierung)
oder kleiner als die Anzahl der Paritätspakete multipliziert mit
einer bestimmten vorbestimmten Konstante, die größer ist als eins (für die Tornado-Codierung).
-
In
einem Ausführungsbeispiel
können
das hierin beschriebene Verfahren und die hierin beschriebene Vorrichtung
für das
Streaming von Multimediadaten über
ein kabelloses IP-Netzwerk
von einem Streaming-Server zu einer empfangenden Vorrichtung eingesetzt
werden. Zum Beispiel kann ein Ausführungsbeispiel das IP-Netzwerk
mit einem Fehlerausgleichsverhalten bereitstellen, während die temporale
Latenz reduziert wird, um die ordnungsgemäße Datenwiedergabe in dem Streaming-Setup
zu verbessern.
-
Ein
Ausführungsbeispiel
kann auch für
einen Schnittstellenbetrieb mit Medienwiedergabemechanismen verwendet
werden. Zum Beispiel kann ein Ausführungsbeispiel den Intel® Media
Processing Library Rahmen verwenden, so dass das robuste bzw. solide
Streaming und die Wiedergabemechanismen nahtlos integriert werden.
-
Die
Abbildung aus 3 zeigt ein Blockdiagramm für ein Ausführungsbeispiel
für das
Streaming von Multimediadaten über
ein IP-Netzwerk mit UDP-Transportprotokoll. Die Multimediadaten 310 setzen
sich aus Audio- und/oder Videodaten zusammen und werden in komprimierter
oder nicht komprimierter Form in einem Server 320 gespeichert.
Die Programmierschnittstelle (API als englische Abkürzung von
Application Program Interface) 321 wird zum Codieren oder
Codeumsetzen der Mediendaten und deren Speicherung in dem internen
Codiererpuffer 322 verwendet. In einem Ausführungsbeispiel kann
der Codierer mit einem MPEG-Standard (Moving Picture Experts Group)
oder einem anderen Video- und Audio-Codierungsstandard kompatibel sein.
In einem Ausführungsbeispiel
stellt die API den Block der Bildung der Pakete und der FEC-Codierung 323 mit
der Position der komprimierten Stream-Header bereit. In einem Ausführungsbeispiel erzeugen
das Paketbildungselement und die FEC Datenpakete und Paritätspakete.
Die Multimediadaten können
in einer nicht sequentiellen Reihenfolge zu Paketen zusammengefasst
werden. Alternativ können
verschiedene FECs für
unterschiedliche Multimediadaten-Segmente eingesetzt werden. Im
anderen Fall können
bestimmte Daten auch nicht in Datenpakete aufgenommen werden. Die
zu Paketen zusammengefassten Daten und die Paritätsdaten werden in dem internen
Paketpuffer 324 gespeichert. Die API stellt eine Verwaltungsfunktion
bereit, die dem Codiererpuffer ähnlich
ist. Im Besonderen kann der Ein-Ausgabe-Block (E/A-Block) 325 wahlfrei
auf die Daten in dem Paketpuffer auf Paketbasis zugreifen. Die API
stellt ferner zusätzliche
Informationen über den
Inhalt der Pakete bereit, welche die E/A erfordert. Die Funktion
des E/A-Blocks ist es, die Paketzustellung über das IP-Netzwerk auszuführen und
die Steuerverbindung zwischen dem Server und dem Client für die ACK-Übermittlung
bereitzustellen. Der E/A-Block kann Pakete mehrmals senden, Pakete aus
dem Übertragungspuffer
fallen lassen oder die Paketübermittlung
zu der Socket-API planen, welche das IP-Netzwerk 330 repräsentiert.
Alle drei Hauptblöcke,
die den Server darstellen, werden durch einen zentralen Prozess 326 auf
höherer
Ebene gesteuert, der die variablen Parameter dieser drei Komponenten
unter Verwendung ihrer APIs festlegt und zudem den Datenfluss zwischen
den Blöcken
und den Datenpuffern verwaltet.
-
Auf
der Client-Seite 340 werden die Daten von dem IP-Netzwerk
durch den E/A-Block 341 empfangen und in dem Paketpuffer 342 platziert.
Der E/A-Block ist auch zuständig
für das Senden
der ACKs zurück
zu der Server-Seite in Richtung des Client-Steuerprozesses 343.
Der E/A-Block kann auch eingesetzt werden, um weitere Steuerinformationen zu
der Server-Seite
zu senden. Der Paketauflösungs-
und FEC-Decodierungs-Block 344 verarbeitet die Daten aus
dem Paketpuffer 342. Der Paketauflösungs- und FEC-Decodierungs-Block
ist für
die Korrektur von Datenpaketlöschungen
zuständig
und die Darstellung der codierten Multimediadaten in einer Form,
die von dem folgenden Decodierungsblock verarbeitet werden kann.
Die komprimierten Multimediadaten werden zu der API 345 für den Decodierungsprozess
durch den Decodierungspuffer 346 geleitet. Die API dekomprimiert
die Multimediadaten und gibt diese an die Anzeige 350 aus.
Die Client-Steuerung 343 verwaltet den Datenfluss zwischen
den drei beschriebenen Blöcken,
steuert ACKs und andere Kommunikationen zu dem Empfänger.
-
Die
vorstehend beschriebenen Verfahren können in dem Speicher eines
Computersystems (z.B. einer Set-Top-Box, Videorekordern, etc.) als eine
Reihe von auszuführenden
Befehlen gespeichert werden. Darüber
hinaus können
die Befehle zur Ausführung
des vorstehend beschriebenen Verfahrens alternativ auf anderen Formen
von maschinenlesbaren Medien gespeichert werden, darunter magnetische
oder optische Plattenspeicher. Zum Beispiel kann das Verfahren gemäß der vorliegenden
Erfindung auf maschinenlesbaren Medien, wie zum Beispiel magnetischen
Plattenspeichern oder optischen Plattenspeichern, gespeichert werden,
auf welche über
ein Plattenspeicherlaufwerk (oder ein Laufwerk für ein computerlesbares Medium)
zugegriffen werden kann. Ferner können die Befehle über ein
Datennetzwerk in einer Form kompilierter und verknüpfter Versionen
in eine Computervorrichtung heruntergeladen werden.
-
Alternativ
kann die Logik für
die Ausführung der
vorstehend im Text beschriebenen Verfahren in zusätzlichen
computer- und/oder maschinenlesbaren Medien implementiert werden,
wie etwa in diskreten bzw. einzelnen Hardwarekomponenten wie großintegrierten
Schaltkreisen (LSIs), anwendungsspezifischen Schaltkreisen (ASICs),
Firmware, wie etwa einem elektrisch löschbaren, programmierbaren Nur-Lesespeicher
(EEPROMs) und in elektrischen, optischen, akustischen und anderen
Formen von ausgebreiteten Signalen (z.B. Trägerwellen, Infrarotsignalen,
digitalen Signalen, etc.).
-
Die
vorliegende Erfindung wurde vorstehend zwar in Bezug auf bestimmte
Ausführungsbeispiele beschrieben,
wobei es jedoch offensichtlich ist, dass verschiedene Modifikationen
und Abänderungen
dieser Ausführungsbeispiele
möglich
sind, ohne dabei vom Umfang der Erfindung abzuweichen. Folglich dienen
die Beschreibung und die Zeichnungen Zwecken der Veranschaulichung
und haben keine einschränkende
Wirkung.