DE60207381T2

DE60207381T2 - Verfahren und system zum puffern von stream-daten

Info

Publication number: DE60207381T2
Application number: DE60207381T
Authority: DE
Inventors: Miska Hannuksela; Baris Emre AKSU
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2001-02-08
Filing date: 2002-02-08
Publication date: 2006-08-24
Anticipated expiration: 2022-02-09
Also published as: CN1491381A; US7421508B2; SG148844A1; BRPI0206630B1; KR100629158B1; JP4690280B2; JP2006345582A; CA2435936C; MXPA03007096A; HUP0302621A2; EE200300316A; EP1605347B1; CN100504757C; BR0206630A; EP1605347A1; FI20010239A; EP2159684B1; EP1358542A1; DE60207381D1; RU2302032C2

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen das Streaming von Mediendaten über Netzwerke, die auf Paketen basieren. Insbesondere betrifft die vorliegende Erfindung einen Puffermechanismus zur Verbesserung der Wiedergabe der gestreamten Daten aus einer Paketverzögerungsschwankung, die auf Codierung und Paketierung zurückzuführen ist.
Hintergrund der Erfindung
In herkömmlichen paketvermittelten Multimedia-Systemen, z. B. in IP-basierten Videokonferenzsystemen, werden unterschiedliche Typen von Medien normalerweise in getrennten Paketen übertragen. Ferner werden Pakete typischer Weise auf einem Best-Effort-Netzwerkprotokoll übertragen, das keine konstante Übertragungsverzögerung garantieren kann; vielmehr kann die Verzögerung von Paket zu Paket schwanken. Infolgedessen kann es sein, dass Pakete, welche denselben Präsentations (Wiedergabe)-Zeitstempel aufweisen, nicht zur selben Zeit empfangen werden, und dass das Empfangsintervall von zwei Paketen nicht dasselbe ist wie ihr Präsentationsintervall (in Bezug auf die Zeit). Somit puffert – um die Wiedergabesynchronisation zwischen unterschiedlichen Medientypen und die korrekte Wiedergabegeschwindigkeit aufrechtzuerhalten – ein Multimedia-Endgerät typischer Weise die empfangenen Daten über einen kurzen Zeitraum (z. B. weniger als eine halbe Sekunde), um die Verzögerungsschwankung auszugleichen. Im vorliegenden Dokument wird dieser Typ von Puffer als Verzögerungs-Jitter-Puffer bezeichnet. In herkömmlichen paketvermittelten Multimedia-Systemen kann das Puffern vor und/oder nach dem Decodieren der Mediendaten erfolgen.
Das Verzögerungs-Jitter-Puffern kommt auch bei Streaming-Systemen zur Anwendung. Aufgrund der Tatsache, dass Streaming eine nicht herkömmliche Anwendung ist, kann es sein, dass ein Verzögerungs-Jitter-Puffer erforderlich ist, der wesentlich größer als bei herkömmlichen Anwendungen ist. Wenn ein Streaming-Wiedergabegerät eine Verbindung zu einem Server hergestellt und angefordert hat, dass ein Multimeadia-Stream heruntergeladen wird, beginnt der Server damit, den gewünschten Stream zu übertragen. Das Wiedergabegerät beginnt typischer Weise nicht damit, den Stream sofort wiederzugeben, sondern puffert vielmehr die einlangenden Daten für einen bestimmten Zeitraum, typischer Weise ein paar Sekunden. Im vorliegenden Dokument wird dieser Typ von Puffern als Anfangspuffern bezeichnet. Durch das Anfangspuffern wird die Möglichkeit geschaffen, Übertragungsverzögerungsschwankungen in einer Weise auszugleichen, die jener ähnelt, die durch das Verzögerungs-Jitter-Puffern in herkömmlichen Anwendungen bereitgestellt wird. Darüber hinaus kann es die Verwendung von Link-, Transport- und/oder Anwendungsschicht-Wiederübertragungen von verloren gegangenen Protokolldateneinheiten (PDUs) ermöglichen. Das Puffern erlaubt dem Wiedergabegerät, Daten aus dem Puffer zu decodieren und wiederzugeben, während die Möglichkeit geschaffen wird, verloren gegangene PDUs erneut zu übertragen. Wenn die Pufferzeit ausreichend lang ist, werden die erneut übertragenen PDUs rechtzeitig empfangen, um zum vorgesehenen Zeitpunkt decodiert und wiedergegeben zu werden.
Das Anfangspuffern in Streaming-Clients bietet einen weiteren Vorteil, der bei herkömmlichen Systemen nicht erzielt werden kann: Es ermöglicht ein Schwanken der Datenrate der übertragenen Medien. Mit anderen Worten, Medienpakete können vorübergehend schneller oder langsamer übertragen werden als ihre Wiedergaberate, so lange es beim Empfangspuffer zu keinem Überlauf oder Unterlauf kommt. Die Schwankung bei der Datenrate kann auf zwei Ursachen zurückzuführen sein. Die erste Schwankungsursache geht auf den Umstand zurück, dass die Kompressionseffizienz, die in einigen Medientypen erzielbar ist, wie z. B. einem Video, von den Inhalten der Quellendaten abhängt. Infolgedessen schwankt die Bitrate des resultierenden komprimierten Bit-Streams, wenn eine stabile Qualität gewünscht wird. Typischer Weise ist eine stabile audio-visuelle Qualität subjektiv angenehmer als eine schwankende Qualität. Somit ermöglicht das Anfangspuffern das Erhalten einer angenehmeren audio-visuellen Qualität im Vergleich zu einem System ohne Anfangspuffern, wie einem Video-Konferenzsystem.
Wenn man das Beispiel von Videodaten näher betrachtet, können unterschiedliche Rahmen einer Videosequenz durch unterschiedliche Datenmengen dargestellt werden. Dies ergibt sich aus der Verwendung von prädiktiven Codierungstechniken. Typischer Weise definieren die Videocodierungsstandards mindestens zwei Rahmentypen. Die hauptsächlichen Rahmentypen sind INTRA- oder I-Rahmen und INTER- oder P-Rahmen. Ein INTRA-Rahmen wird auf der Basis von Informationen codiert, die im Bild selbst enthalten sind, während ein P-Rahmen in Bezug auf mindestens einen anderen Rahmen codiert wird, für gewöhnlich einen Rahmen, der in der Videosequenz früher auftritt. Aufgrund der bedeutenden zeitlichen Redundanz zwischen aufeinanderfolgenden Rahmen einer digitalen Videosequenz ist es möglich, einen INTER-Rahmen mit einer bedeutend geringeren Datenmenge zu codieren, als erforderlich ist, um einen INTRA-Rahmen darzustellen. Somit werden INTRA-Rahmen vergleichsweise selten in einer codierten Videosequenz verwendet.
Typischer Weise beginnt eine codierte Sequenz mit einem INTRA-Rahmen (da kein vorhergehender Rahmen zur Verfügung steht, der als Referenz für die Konstruktion eines INTER-Rahmens verwendet werden könnte). INTRA-Rahmen können in die Sequenz periodisch eingefügt werden, z. B. in regelmäßigen Intervallen, um Fehler auszugleichen, die sich ansammeln und durch eine Aufeinanderfolge von vorhergesagten (INTER) Rahmen ausbreiten können. INTRA-Rahmen werden auch häufig bei Szeneschnitten verwendet, wo sich der Bildinhalt von aufeinander folgenden Rahmen so sehr ändert, dass ein prädiktives Codieren keine wirksame Datenreduktion bereitstellt. Somit beginnt ein typischer codierter Videostream im Allgemeinen mit einem INTRA-codierten Rahmen und umfasst eine Sequenz von INTER-Rahmen, die mit gelegentlichen INTRA-Rahmen versetzt sind, wobei die Datenmenge, die erforderlich ist, um einen INTRA-Rahmen darzustellen, um ein Mehrfaches (z. B. 5- bis 10-fach) größer ist als jene, die erforderlich ist, um einen INTER-codierten Rahmen bereitzustellen. Die Datenmenge, die erforderlich ist, um jeden INTER-Rahmen darzustellen schwankt auch gemäß dem Grad der Ähnlichkeit/Unterschiedlichkeit in Bezug auf seinen Referenzrahmen und die Detailmenge in dem Bild.
Dies bedeutet, dass die Informationen, die benötigt werden, um eine prädiktiv codierte Videosequenz zu rekonstruieren, auf die übertragenen Datenpakete nicht gleichmäßig verteilt sind. Mit anderen Worten, eine größere Anzahl an Datenpaketen ist erforderlich, um die Daten in Zusammenhang mit einem INTRA-Rahmen zu transportieren, als dies für das Transportieren der Daten bei einem INTER-Rahmen der Fall ist. Da die Datenmenge, die erforderlich ist, um aufeinander folgende INTER-Rahmen darzustellen, auch vom Bildinhalt abhängt, schwankt auch die Anzahl von Datenpaketen, die erforderlich sind, um die INTER-Rahmendaten zu übertragen.
Eine zweite Schwankungsquelle tritt auf, wenn es zu Paketverlusten in Fest-IP-Netzwerken in Stößen kommt. Um diskontinuierliche Fehler und High-Peak-Bit- und Paket-Raten zu vermeiden, planen entsprechend konstruierte Streaming-Server die Übertragung von Paketen sorgfältig, wobei Pakete unter Umständen nicht genau mit der Rate gesendet werden, mit der sie am empfangenden Ende wiedergegeben werden. Typischer Weise werden Netzwerkserver derart eingesetzt, dass sie versuchen, eine konstante Rate für die Paketübertragung zu erreichen. Ein Server kann auch die Rate der Paketübertragung gemäß vorherrschenden Netzwerkbedingungen einstellen, wobei die Paketübertragungsrate reduziert wird, wenn das Netzwerk verstopft ist, und zum Beispiel erhöht wird, wenn dies die Netzwerkbedingungen erlauben. Dies tritt typischer Weise beim Einstellen des angekündigten Fensters der Empfangsnachricht auf, die im TCP (Übertragungssteuerungsprotokoll) gesendet wird.
In Anbetracht dieser eingebetteten Eigenschaft von Netzwerk-Servern und in Verbindung mit dem zuvor beschriebenen Videocodierungssystem, sind nicht nur die Informationen, die für das Rekonstruieren einer prädiktiv codierten Videosequenz erforderlich sind, ungleichmäßig zwischen den übertragenen Datenpaketen verteilt, sondern die Datenpakete selbst können ebenfalls von dem Server mit einer schwankenden Rate übertragen werden. Das bedeutet, dass ein Decodierer in beispielsweise einem empfangenden Client-Endgerät eine variable Verzögerung beim Empfang der Informationen aufweist, die sie benötigt, um aufeinander folgende Rahmen in einer Videosequenz zu konstruieren, selbst wenn die Übertragungsverzögerung durch das Netzwerk konstant ist. Es sollte angemerkt werden, dass sich der Begriff Client-Endgerät auf ein beliebiges elektronisches Endnutzer-Gerät bezieht, z. B. Handgeräte (PDAs), drahtlose Endgeräte sowie Desktop- und Laptop-Computer und Set-Top-Boxes. Diese Schwankung bei der Verzögerung, die wegen der Codierung, Paketierung und Paketübertragung von einem Server auftritt, kann als „Codierung" oder „serverspezifische" Schwankungsverzögerung bezeichnet werden. Sie ist unabhängig von oder zusätzlich zum Verzögerungs-Jitter, das aufgrund von Schwankungen bei der Übertragungszeit innerhalb des Netzwerks auftaucht.
Somit ermöglicht das Anfangspuffern die Aufnahme von Schwankungen bei der übertragenen Datenrate, die sich aus den zuvor genannten Nachteilen ergeben, d. h. Codierung oder serverspezifische Verzögerungsschwankung und Verzögerungsschwankung in Zusammenhang mit der Netzwerkübertragung. Das Anfangspuffern hilft bei der Bereitstellung einer stabileren audio-visuellen Qualität und bei der Verhinderung von Netzwerk-Verstopfung und Paketverlusten.
Das Anfangspuffern kann auch nach dem Decodieren der empfangenen Mediendaten durchgeführt werden. Das hat den Nachteil, dass die Abmessungen des Puffers relativ groß sein müssen, da das Puffern auf decodierten Daten erfolgt. Die kombinierte Wirkung von Codierung, serverspezifisch und Netzwerkübertragungsverzögerungsschwankungen neigt auch dazu, die Anforderung an das Anfangspufferung zu erhöhen.
Ferner bewirkt das Codieren von Mediendaten und die Art und Weise, in der codierte Daten in Pakete eingekapselt und von einem Server aus übertragen werden, dass ein Decodierer in einem empfangenden Client-Endgerät eine variable Verzögerung beim Empfang der Informationen aufweist, die es benötigt, um die Mediendaten zu rekonstruieren, selbst wenn die Übertragungsverzögerung durch das Netzwerk konstant ist. Somit stellt ein Nach-Decodiererpuffer kein Mittel zur Aufnahme dieser Form von Verzögerungsschwankung vor dem Decodieren bereit.
Dokument US 6175871 B1 offenbart ein System zum Empfangen von Streaming-Medien über ein Netzwerk, das einen Vor-Decodiererpuffer mit einer variablen Puffergröße verwendet, wobei die variable Puffergröße dynamisch gemäß den dynamischen Transporteigenschaften des Netzwerks eingestellt wird.
Kurzdarstellung der Erfindung
Gemäß eines ersten Aspektes der Erfindung wird ein Verfahren zum Streaming von Mediendaten durch Übertragen von mehreren Datenpaketen über ein Netzwerk von einem Quellserver zu einer Client-Vorrichtung bereitgestellt, wobei die Client-Vorrichtung einen Decodierer zum Decodieren codierter Pakete aufweist. Das Verfahren ist dadurch gekennzeichnet, dass die Client-Vorrichtung ferner einen Vor-Decodiererpuffer mit einer variablen Anfangspufferzeit und einer variablen Puffergröße aufweist, die zum Empfang der übertragenen Daten von dem Quellserver vor dem Decodieren in dem Decodierer bereitgestellt werden, und wobei die variable Anfangspufferzeit und variable Puffergröße des Vor-Decodiererpuffers dynamisch für eine verbesserte Leistung der Wiedergabe durch die Client-Vorrichtung angepasst wird.
Gemäß eines zweiten Aspektes der Erfindung wird ein System für das Streaming von Mediendaten durch Übertragen von mehreren Datenpaketen bereitgestellt, wobei das System einen Quellserver aufweist, auf dem sich die Mediendaten befinden, ein Netzwerk, das als Übertragungsmedium für die Datenpakete dient, und eine Client-Vorrichtung, die in der Lage ist, die Mediendaten wiederzugeben, wobei die Client-Vorrichtung einen Vor-Decodiererpuffer aufweist, um die Pakete, die vom Quellserver über das Netzwerk übertragen werden, zu empfangen, wobei der Vor-Decodiererpuffer eine variable Anfangspufferzeit und eine variable Puffergröße, einen Decodierer für das Decodieren der Pakete von dem Vor-Decodiererpuffer und Mittel für das dynamische Anpassen der variablen Anfangspufferzeit und der variablen Puffergröße des Vor-Decodiererpuffers aufweist, um die Leistung der Wiedergabe durch die Client-Vorrichtung zu verbessern.
Gemäß eines dritten Aspektes der Erfindung wird eine Client-Vorrichtung zum Empfangen von mehreren Datenpaketen bereitgestellt, die über ein Netzwerk von einem Quellserver übertragen werden, wobei die Client-Vorrichtung einen Vor-Decodiererpuffer für das Empfangen der übertragenen Datenpakete von dem Quellserver über das Netzwerk aufweist, wobei der Vor-Decodiererpuffer eine variable Anfangspufferzeit und eine variable Puffergröße aufweist, einen Decodier für das Decodieren der Datenpakete von dem Vor-Decodiererpuffer und Mittel für das dynamische Anpassen der variablen Anfangspufferzeit und der variablen Puffergröße des Vor-Decodiererpuffers, um die Leistung der Wiedergabe durch die Client-Vorrichtung zu verbessern.
Kurze Beschreibung der Zeichnungen
Die Erfindung und ihre weiteren Aufgaben und Vorteile können am besten durch Bezugnahme auf die folgende Beschreibung gemeinsam mit den beiliegenden Zeichnungen verstanden werden. Es zeigen:
1 ein vereinfachtes Blockdiagramm eines Vor-Decodiererpufferblocks in der Vorrichtungs-Endgeräte-Architektur gemäß einer Ausführungsform der Erfindung; und
2 ein Beispiel eines Datenflusses in einem typischen Streaming-System, welches die Wirkung des Vor-Decodiererpufferns darstellt.
Detaillierte Beschreibung der Erfindung
Überblick über die Architektur
Gemäß der Erfindung wird ein neuer Pufferblock in der Endgeräte-Architektur bereitgestellt, um das Puffern auf der Empfängerseite zu verbessern. Dieser Pufferblock wird im vorliegenden Dokument als Vor-Decodiererpuffer bezeichnet.
1 zeigt ein vereinfachtes Blockdiagramm eines Vor-Decodiererpufferblocks in der Vorrichtungs-Endgeräte-Architektur gemäß einer Ausführungsform der Erfindung.
Der „Transport-Decodierer" 100 entkapselt den Code-Stream aus den empfangenen Datenpaketen (z. B. RTP-Datenpakete). Der „Quell-Decodierer" 120 decodiert den Code-Stream in ein unkomprimiertes Datenformat, das wiedergegeben werden kann. Der „Vor-Decodiererpuffer" 110 wirkt als vorübergehender Speicher zwischen dem Transport-Decodieren und dem Quell-Decodieren. In dem Fall eines Multimedien-Streams, der mehr als eine Art von Daten umfasst, wird ein gemeinsamer Vor-Decodiererpuffer vorteilhafter Weise zwischen allen Echtzeit-Medientypen geteilt, die übertragen werden. In alternativen Ausführungsformen der Erfindung jedoch wird ein getrennter Vor-Decodiererpuffer für jeden Medientyp bereitgestellt, wobei der Vor-Decodiererpuffer für jeden Medientyp zwischen dem Transport-Decodierer und dem jeweiligen Quell-Decodierer für den betreffenden Medientyp angeordnet ist. Die Decodierungsvorgänge werden vorzugsweise als Software umgesetzt, die in dem Speicher der Client-Vorrichtung gespeichert und von einer MCU (Master Control Unit) und unterer ihrer Kontrolle zum Laufen gebracht wird, welche den Betrieb der Client-Vorrichtung steuert, wovon 1 einen Teil zeigt. Die MCU empfängt Steuersignale von einem Quellserver und steuert die Anpassung der Anfangspufferzeit und der Puffergröße gemäß den empfangenen Signalen vom Quellserver. Die Steuerung der unterschiedlichen Blöcke durch die MCU ist in 1 durch die Steuerpfeile aus der MCU zu jedem Block dargestellt.
In einer bevorzugten Ausführungsform der Erfindung wird der Vor-Decodiererpuffer zusätzlich zu einem Nach-Decodiererpuffer bereitgestellt, der sich nach einem Decodierer in einem Streaming-Client befindet. Vorteilhafter Weise wird der Nach-Decodiererpuffer bereitgestellt, um die Netzwerkübertragungsverzögerungsschwankungen zu absorbieren. Zusätzlich kann der Nach-Decodiererpuffer auch mit dem Decodieren in Zusammenhang stehende Verzögerungsschwankungen absorbieren. Dies ist besonders in dem Fall vorteilhaft, in dem mehr als ein Typ von Mediendaten gleichzeitig gestreamt wird. Die Verwendung eines Nach-Decodiererpuffers in dieser Situation ermöglicht es, dass Decodierungsverzögerungsschwankungen, die durch unterschiedliche Medien-Decodierer eingeführt werden, ausgeglichen werden. In einer alternativen Ausführungsform der Erfindung wird ein getrennter Decodiererpuffer auch im empfangenden Client bereitgestellt. Der Decodiererpuffer ist zwischen dem Decodierer und dem Nach-Decodiererpuffer angeordnet und wird als ein vorübergehender Speicher für die Mediendaten bereitgestellt, während diese decodiert werden. Vorteilhafter Weise wird in einer Situation, in der mehr als ein Typ von Mediendaten gleichzeitig gestreamt werden, ein getrennter Decodiererpuffer für den jeweiligen Quellen-Decodierer für jeden Medientyp bereitgestellt.
Puffer-Algorithmus
Ein Puffer-Algorithmus, der gemäß der Ausführungsform arbeitet, wird bereitgestellt, um empfangene Daten in einem Streaming-Client zu puffern und das Codieren und Bereitstellen von Streams von einem netzwerkbasierten Streaming-Server zu steuern. Der Algorithmus geht davon aus, dass ein Vor-Decodiererpuffer gemäß der Erfindung in dem Streaming-Client bereitgestellt wird.
Es gibt zwei Hauptfaktoren, welche das Verhalten des Pufferalgorithmus beeinflussen, d. h. die Anfangspufferzeit und die minimale Vor- Decodiererpuffergröße. Die Anfangspufferzeit bezieht sich typischer Weise auf die Zeit, die zwischen der Zeit, zu der ein erstes Mediendatenpaket empfangen wird, und der Zeit verstreicht, zu der das erste Medienmuster wiedergegeben wird. Die minimale Vor-Decodiererpuffergröße entspricht typischer Weise der Datenmenge (z. B. der Anzahl von Datenbytes), die der Streaming-Client zusätzlich zu dem Puffern speichern kann, das stattfindet, um die Übertragungsverzögerungsschwankung zu bewältigen. Mit anderen Worten, eine minimale Vor-Decodiererpuffergröße ist für Netzwerke mit Nullverzögerung und verlässlicher Übertragung definiert.
Der Pufferalgorithmus ist ähnlich jenem, der in H.263 Anhang B (Hypothetical Reference Decoder) und MPEG-4 Visual Anhang D (Vido Buffering Verifier) beschrieben wird. Diese Algorithmen definieren das Pufferverhalten für Videocodizes. Es sollte beachtet werden, dass diese Algorithmen nicht verwendet werden können, um die vorgeschlagenen Vor-Decodiererpufferalgorithmen auszutauschen, da sie nur auf Video anwendbar sind. Darüber hinaus unterstützt der H.263 Hypothetical-Reference-Decoder nicht das Anfangspuffern oder Speichern von mehreren (nicht-B) Rahmen in den Puffer. Es sollte beachtet werden, dass der vorgeschlagene Vor-Decodiererpufferalgorithmus vollständig mit den zuvor erwähnten Videopufferalgorithmen verträglich ist. In einer praktischen Umsetzung können der Vor-Decodiererpuffer und der Video-Decodiererpuffer kombiniert werden.
Gemäß der bevorzugten Ausführungsform der Erfindung zwingt der Pufferalgorithmus einen übertragenen Datenpaketstream dazu, mit den Anforderungen des Vor- Decodiererpuffers übereinzustimmen, die wie folgt definiert werden:

1. Der Vor-Decodiererpuffer ist anfangs leer.
2. Jedes empfangene Datenpaket wird zu dem Vor-Decodiererpuffer im Wesentlichen sofort, nachdem es empfangen worden ist, hinzugefügt. Alle Protokollüberschriften auf der Ebene des Übertragungsprotokolls (z. B. RTP-Schicht) oder einer etwaigen niedrigeren Schicht werden entfernt.
3. Daten werden aus dem Vor-Decodiererpuffer nicht während eines Zeitraums entfernt, der als Anfangspufferzeit bezeichnet wird und beginnt, wenn das erste Datenpaket dem Puffer hinzugefügt wird.
4. Wenn die Anfangspufferzeit abgelaufen ist, wird ein Zeitgeber für die Wiedergabe gestartet.
5. Ein Datenblock wird aus dem Vor-Decodiererpuffer im Wesentlichen sofort entfernt, nachdem der Zeitgeber für die Wiedergabe die geplante Wiedergabezeit für den betreffenden Datenblock erreicht hat.
6. Wenn die Daten über ein verlässliches Übertragungsnetzwerk mit Null-Verzögerung übertragen werden, wird dem Belegungsgrad des Vor-Decodiererpuffers nicht erlaubt, über einen bestimmten Wert hinauszugehen, der als die Vor-Decodiererpuffergröße bezeichnet wird. Es sollte beachtet werden, dass die oben angeführten Anforderungen, den Betrieb ohne Zwischenpauseanfragen beschreiben. Jede neue Wiedergabeanfrage (nach einer Pause, zum Beispiel) folgt denselben Anforderungen.

Ferner basieren die oben genannten Anforderungen auf der Annahme, das ein verlässliches Übertragungsnetzwerk mit Null-Verzögerung vorliegt. Somit wird in einer praktischen Anwendung das Client-seitige Vor-Decoderpuffern wahrscheinlich mit einem Netzwerk-Verzögerungs-Jitter-Puffern kombiniert. Infolgedessen ist die tatsächliche Vor-Decodierer-Puffergröße in einem Streaming-Client wahrscheinlich größer als die minimale Vor-Decodierer-Puffergröße, die oben erwähnt wird, und die tatsächliche Anfangspufferzeit ist wahrscheinlich auch länger als die oben genannte Anfangspufferzeit.
Vor-Decodierer-Puffern
2 zeigt ein Beispiel eines Datenflusses in einem typischen Streaming-System, das die Wirkung des Vor-Decodiererpufferns darstellt. Die Balken stellen Medienrahmen oder Pakete dar, zum Beispiel sind die schwarzen Balken Videodatenpakete (z. B. codiert gemäß der ITU-T-Empfehlung H.263), und die hellen Balken sind Audiodatenpakete (z. B. codiert unter Verwendung des Adaptive-Multi-Rate (AMR) Sprachencodex). Die Höhe der Balken stellt die Größe eines Rahmens (oder eines Pakets) in Bytes dar. Der Verarbeitungsfluss läuft von oben nach unten und die Zeit verläuft von links nach rechts.
Nun wird detaillierter auf 2 Bezug genommen, wo zunächst die Eingabedaten codiert werden. Als Ergebnis davon weist der Videostream eine schwankende Rahmenrate und Rahmengröße auf, und der Audiostream weist eine konstante Rahmenrate, aber eine schwankende Rahmengröße auf. Als nächstes werden die komprimierten Medienstreams in Pakete eingekapselt und zum Netzwerk übertragen. Während des Einkapselns teilt der Server große Videorahmen in mehrere Pakete auf und fasst eine Anzahl von kleinen Audiorahmen zu einem Paket zusammen. Der Server überträgt Pakete in regelmäßigen Intervallen. Eine konstante Netzwerkübertragungsverzögerung wird angenommen, ungeachtet der Paketgröße oder etwaiger anderer Faktoren. Somit ist das relative Timing der empfangenen Pakete gleich wie zu dem Zeitpunkt, zu dem sie gesendet wurden. Die empfangenen Pakete werden in einem Vor-Decodiererpuffer gespeichert. Nach einer bestimmten Anfangspufferzeit werden Rahmen aus dem Puffer geholt, wobei die Rahmenentfernungsrate dieselbe ist wie die Rahmenwiedergaberate. Der maximale Pufferbelegungsgrad bestimmt die minimale Vor-Decodiererpuffergröße.
Übermitteln der Vor-Decodiererpuffer-Eigenschaften
Um bestimmte minimale Pufferfähigkeiten in Streaming-Clients zu gewährleisten, werden bestimmte vorgegebene Puffereigenschaften definiert. Wie zuvor beschrieben, können die Puffereigenschaften hauptsächlich durch zwei Faktoren definiert werden, d. h. die Anfangspufferzeit und die minimale Vor-Decodiererpuffergröße. Ein Beispiel für den vorgegebenen Wert für die Anfangspufferzeit liegt bei ungefähr einer Sekunde, während die vorgegebene minimale Vor-Decodiererpuffergröße bei ungefähr 30720 Bytes liegt. Es sollte beachtet werden, dass diese Werte nur beispielhaft sind und dass sie schwanken können, um eine geeignete Leistung für den jeweiligen Typ der Verzögerung zu erreichen, zu der es im Netzwerk zum jeweiligen Zeitpunkt kommt. Die vorgeschlagenen vorgegebenen Werte basieren auf praktischen Experimenten in einer generalisierten Umgebung, die keineswegs spezifisch sind, aber die am häufigsten vorkommenden Paketübertragungsszenarien berücksichtigen. Es sollte auch beachtet werden, dass in einem bestimmten Streaming-System die vorgegebene Vor-Decodieranfangspufferzeit und die vorgegebene Vor-Decoderpuffergröße implizit definiert werden können. Mit anderen Worten, der Quellserver und die Streaming-Clients in dem Netzwerk arbeiten derart, dass bestimmte vorgegebene Vor-Decodierer-Pufferparameter (z. B. Vor-Decodierer-Anfangspufferzeit und/oder Vor-Decodiererpuffergröße) angenommen werden. In alternativen Ausführungsformen wird eine explizite Übermittlung der Vor-Decodierer-Pufferparameter verwendet.
Um einem Streaming-Client zu ermöglichen, seine vorgegebenen Vor-Decodiererpufferfähigkeiten an einen Quellserver zu übermitteln und um ihm zu ermöglichen, Meidienstreams zu empfangen, die anspruchsvollere Pufferfähigkeiten als die vorgegebenen Fähigkeiten erfordern, wird in der Erfindung eine Übermittlung auf der Basis des SET-PARAMETER-Verfahrens des Real Time Streaming Protocol (RTSP) verwendet.
Zum Beispiel kann die Client-Endgerätevorrichtung den Server auffordern, entweder einen oder beide der folgenden Parameter einzustellen:

1. initialBufferingTimeInMSec (Anfangspufferzeit in Millisekunden)
2. preDecoderBufferSizeInBytes (minimale Vor-Decoderpuffergröße in Bytes)

Der Client-Endgeräte-Vorrichtung wird nicht gestattet, Parameterwerte zu übermitteln, die kleiner als die definierten oder implizit im Streamingsystem angenommenen vorgegebenen Werte sind. Ein Server, der eine Anfrage erhält, die einen kleineren Wert anzeigt als einer der vorgegebenen Werte, kann eine „inkorrekte Anfrage" übermitteln. Wenn die übertragenen Werte größer oder gleich den definierten oder implizierten vorgegebenen Werten sind, werden die übermittelten Werte im Wesentlichen unmittelbar nach Empfang der Anfrage in Verwendung genommen und der Quellserver prüft den übertragenen Paketstream unter Verwendung der übermittelten Werte gemäß dem zuvor beschriebenen Pufferalgorithmus. Mit anderen Worten, und so wie unten detaillierter beschrieben, überträgt der Server den Paketstream in solcher Weise, dass er in einer im Wesentlichen korrekten Weise beim empfangenden Client wiedergegeben werden kann. Insbesondere überträgt der Quellserver den Paketstream so, dass sichergestellt wird, dass es zu keinem Überlauf des Vor-Decodiererpuffers im empfangenden Client kommt und dass alle Datenblöcke (z. B. Rahmen) der Mediendaten für eine Wiedergabe in dem empfangenden Client zu ihren geplanten Wiedergabezeiten verfügbar sind.
Gemäß einer vorteilhaften Ausführungsform der Erfindung ist es so, dass – wenn eine Client-Endgeräte-Vorrichtung zuerst eine Verbindung mit einem Netzwerkserver herstellt und damit beginnt, eine Streaming-Sitzung mit dem Server einzurichten, indem bestimmter, zu streamender Medieninhalt angefordert wird – diese Client-Endgeräte-Vorrichtung ihre vorgegebenen Vor-Decodierungs-Pufferparameter zum Server übermittelt. Wie oben erklärt, kann gemäß der Erfindung die Client-Endgeräte-Vorrichtung entweder ihre vorgegebene Vor-Decoder-Pufferzeit oder ihre minimale Vor-Decodier-Puffergröße oder beide der genannten Parameter anzeigen. In einer alternativen Ausführungsform, bei welcher die Client-Endgerätevorrichtung auch mit einem Nach-Decodiererpuffer versehen ist, kann die Nach-Decodiererpuffergröße dem Quellserver angezeigt werden. In Ausführungsformen der Erfindung, in denen die Vor-Decodiererpufferparameter implizit im Streamingsystem definiert werden, ist ein Anfangsübermitteln von Vor-Decodiererpuffer-Parametern durch die Client-Vorrichtung streng vollkommen unnotwendig. Wenn jedoch eine bestimmte Client-Vorrichtung Vor-Decodierer-Pufferfähigkeiten aufweist, die über den impliziert vorgegebenen Werten liegen, die in dem Streamingsystem angenommen werden, kann sie diese dem Server übermitteln. In einer wiederum alternativen Anordnung ruft der Quellserver die Vor-Decodiererpuffer-Parameter für eine bestimmte Client-Vorrichtung von einem Fähigkeitsserver in Verbindung mit dem Streamingsystem ab.
Der Server übermittelt danach der Client-Endgeräte-Vorrichtung die Eigenschaften der Medienstreams, die er bereitstellen kann. Wie Fachleuten hinlänglich bekannt ist, wird ein Streamingserver mit mehreren vorcodierten Medienstreams versehen, welche denselben Medieninhalt darstellen. Jeder der vorcodierten Streams ist mit unterschiedlichen Codierungsparametern codiert. Diese Anordnung ermöglicht es, dass der Medieninhalt zu mehreren, unterschiedlichen Client-Endgeräte-Vorrichtungen, die unterschiedliche Eigenschaften und/oder Fähigkeiten aufweisen und/oder über Netzwerke mit unterschiedlichen Eigenschaften (z. B. maximal verfügbare Übertragungs-Bitrate) gestreamt wird.
Gemäß der vorteilhaften Ausführungsform der Erfindung ist es so, dass – sobald der Server eine Anzeige der vorgegebenen Vor-Decodierer-Anfangspufferzeit des Client-Endgeräts oder seiner minimalen Vor-Decodierer-Puffergröße erhalten hat – der Server das Client-Endgerät mit Hilfe von Übermittlung über das Netzwerk über die unterschiedlichen vorcodierten Medienstreams informiert, die er bereitstellen kann. Wenn der Server zum Beispiel 4 unterschiedlich codierte Medienstreams aufweist, welche sich auf den angeforderten Medieninhalt beziehen, und falls der Client sowohl seine vorgegebene Vor-Decodierer- Anfangspufferzeit und seine vorgegebene Vor-Decodiererpuffergröße angezeigt hat, übermittelt der Server die Vor-Decodierer-Anfangspufferzeit und die Vor-Decodiererpufferzeit, die erforderlich sind, um eine korrekte (z. B. pausenfreie) Wiedergabe der vier unterschiedlichen Medienstreams zu gewährleisten. Das Client-Endgerät wählt dann einen der vier vorcodierten Medienstreams für die Wiedergabe aus und stellt seine Vor-Decodierer-Anfangspufferzeit und Vor-Decodiererpuffergröße gemäß den entsprechenden Anforderungen des gewählten Medienstreams ein. Die Einstellung innerhalb des Client-Endgerätes wird vorzugsweise von der MGU des Client-Endgerätes gesteuert. Wenn der Server nur die erforderliche Vor-Decodierer-Anfangspufferzeit oder die erforderliche Vor-Decodiererpuffergröße anzeigt, die von den verschiedenen codierten Medienstreams benötigt werden, wählt das Client-Endgerät den Medienstream auf dieser Grundlage aus und stellt entweder seine Vor-Decodierer-Anfangspufferzeit oder Vor-Decodiererpuffergröße entsprechend ein. In diesem Fall, wird jenem Parameter, der nicht angezeigt wird, ein vorgegebener Wert zugeordnet.
Das Client-Endgerät übermittelt danach seine Wahl des Medienstreams an den Server, so dass das Runterladen des Medieninhalts beginnen kann. Dieser Schritt informiert auch implizit den Server über die Vor-Decodierer-Anfangspufferzeit und/oder Vor-Decodiererpuffergröße, die nun in dem Client-Endgerät gültig ist, und ermöglicht es dem Server, den übertragenen Medienstream gemäß dem zuvor beschriebenen Pufferalgorithmus korrekt zu prüfen, so dass es zu keinem Überlaufen des Vor-Decodiererpuffers kommt und alle Datenblöcke der Mediendaten für eine Wiedergabe in dem empfangenden Client zu ihren geplanten Wiedergabezeiten verfügbar sind.
Dadurch, dass dem Client-Endgerät ermöglicht wird, seine Vor-Decodierer-Anfangspufferzeit und/oder Vor-Decodiererpuffergröße einzustellen, ermöglicht das Verfahren gemäß der Erfindung dem Endgerät, Medienstreams zu empfangen und korrekt wiederzugeben, welche in solcher Weise codiert sind, dass sie unter Verwendung der vorgegebenen Vor-Decodiererpuffer-Parameter zu keiner korrekten Wiedergabe fähig wären.
Gemäß der bevorzugten Ausführungsform der Erfindung werden die Vor-Decodierer-Anfangspufferzeit und/oder Vor-Decodiererpuffergröße in dem Client gemäß des zuvor beschriebenen Verfahrens angepasst, wann immer ein Streaming eines neuen Medienstreams gestartet wird. Wenn während des Verfahrens bestimmt wird, dass der neue Medienstream beim Client unter Verwendung der zurzeit gültigen Vor-Decodierer-Pufferparameter korrekt wiedergegeben werden kann, sind keine Anpassungen notwendig. Zusätzlich kann der Client seine Vor-Decodierer-Anfangspufferzeit und/oder Vor-Decodiererpuffergröße in einer Situation einstellen, in welcher der Server Änderungen in den erforderlichen Vor-Decodierer-Pufferparamtern während einer bestehenden Streaming-Sitzung übermittelt. Zu einer solchen Situation kann es zum Beispiel kommen, wenn unterschiedliche aufeinander folgende Abschnitte des zu streamenden Medieninhalts unterschiedlich codiert werden, was dazu führt, dass unterschiedliches Vor-Decodierer-Puffern beim Client erforderlich wird, um eine korrekte Wiedergabe des Streams zu gewährleisten.
Zusammenfassend ist zu sagen, dass die vorliegende Erfindung einen Vor-Decodiererpuffer als einen Teil eines Streaming-Client ins Auge fasst. Der Streaming-Client arbeitet unter Befolgung eines Pufferalgorithmus, bei dem ein Streamingserver prüft, ob der übertragene Datenstream mit dem definierten Pufferalgorithmus übereinstimmt. Zusätzlich schlägt die Erfindung Mechanismen für das Definieren und Übermitteln der Pufferfähigkeiten eines Streaming-Client zu einem Streaming-Server vor. Auf diese Weise kann ein Streaming-Server Informationen über die Pufferfähigkeiten eines bestimmten Streaming-Client erhalten und der codierte Daten-/Medienübertragungsrate kann innerhalb der Grenzen des Vor-Decodiererpuffers auf der Empfängerseite erlaubt werden, zu schwanken. Es sollte beachtet werden, dass ein Pufferprüfer in einem Server verwendet werden kann, um sicherzustellen, dass der übertragene Paketstream mit den Empfängerpufferfähigkeiten übereinstimmt. Dies kann zum Beispiel durch Einstellen der Übertragungszeiten von Paketen vom Server geschehen, so dass die Pufferfähigkeiten des Vor-Decodiererpuffers des Client nicht überschritten werden. Alternativ dazu kann der Server die Art einstellen, in welcher die Mediendaten codiert und paketiert werden. In der Praxis kann der Pufferprüfer ein Puffer sein, der innerhalb des Servers nach dem Transportcodierer läuft.
Obwohl die Erfindung in einigen Belangen unter Bezugnahme auf eine spezifizierte Ausführungsform der Erfindung beschrieben wurde, werden Fachleuten Varianten und Modifizierungen davon klar sein. Daher sind die folgenden Ansprüche keine einschränkende Auslegung der Erfindung, sondern sind vielmehr so auszulegen, dass sie auch Varianten und Modifizierungen umfassen, die von dem erfinderischen offenbarten Gegenstand abgeleitet werden.

Claims

Verfahren für das Streaming von Mediendaten durch Übertragen von mehreren Datenpaketen über ein Netzwerk von einem Quellserver zu einer Client-Vorrichtung, wobei die Client-Vorrichtung einen Decodierer zum Decodieren codierter Pakete und einen Vor-Decodiererpuffer mit einer variablen Puffergröße aufweist, wobei der Vor-Decodiererpuffer zum Empfangen der übertragenen Datenpakete von dem Quellserver vor dem Decodieren im Decodierer dient und wobei die variable Puffergröße des Vor-Decodiererpuffers dynamisch angepasst ist, dadurch gekennzeichnet, dass der Vor-Decodiererpuffer eine variable Anfangspufferzeit aufweist und dass die variable Anfangspufferzeit des Vor-Decodiererpuffers dynamisch angepasst ist, um die Leistung der Wiedergabe durch die Client-Vorrichtung zu verbessern.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Client-Vorrichtung eine Anfrage an den Quellserver richtet, um entweder die Anfangspufferzeit oder die Vor-Decodiererpuffergröße oder beides einzustellen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine vorgegebene Anfangspufferzeit und eine vorgegebene Puffergröße für den Vor-Decodiererpuffer definiert sind.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Client-Vorrichtung entweder die vorgegebene Anfangspufferzeit oder die vorgegebene Puffergröße für den Vor-Decodiererpuffer oder beides dem Quellserver übermittelt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die variable Anfangspufferzeit des Vor-Decodiererpuffers durch die Client-Vorrichtung als Reaktion auf eine Anzeige einer erforderlichen Vor-Decodierer-Anfangspufferzeit eingestellt ist, die von dem Quellserver erhalten wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die variable Puffergröße des Vor-Decodiererpuffers durch die Client-Vorrichtung als Reaktion auf eine Anzeige einer erforderlichen Vor-Decodiererpuffergröße eingestellt ist, die von dem Quellserver erhalten wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehrere Kopien der Mediendaten dem Quellserver zur Verfügung stehen, wobei jede der mehreren Kopien der Mediendaten durch mindestens einen Parameter gekennzeichnet ist, der eine erforderliche Eigenschaft des Vor-Decodiererpuffers in der Client-Vorrichtung anzeigt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein Parameter, der eine erforderliche Eigenschaft des Vor-Decodiererpuffers anzeigt, von dem Quellserver zur Client-Vorrichtung übertragen wird.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass mindestens ein Parameter, der eine erforderliche Eigenschaft des Vor-Decodiererpuffers anzeigt, während der Herstellung einer Streaming-Datenverbindung zwischen dem Quellserver und der Client-Vorrichtung für das Herunterladen der Mediendaten in Form von Streaming von dem Quellserver zur Client-Vorrichtung übertragen wird.
Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass mindestens ein Parameter, der eine erforderliche Eigenschaft des Vor-Decodiererpuffers anzeigt, aus einer Gruppe ausgewählt ist, die eine erforderliche Vor-Decodiereranfangspufferzeit, eine erforderliche Vor-Decodiererpuffergröße oder sowohl eine erforderliche Vor-Decodiereranfangspufferzeit und eine erforderliche Vor-Decodiererpuffergröße enthält.
Verfahren nach Anspruch 5 und 6, dadurch gekennzeichnet, dass die dynamische Anpassung eine Anpassung ist, die durch die Client-Vorrichtung als Reaktion auf ein Signal von dem Quellserver erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Pufferalgorithmus in dem Quellserver verwendet wird, um die Übertragung der Datenpakete zu steuern.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Pufferalgorithmus bewirkt, dass der Quellserver die Übertragungszeiten von Datenpaketen von dem Quellserver zur Client-Vorrichtung einstellt.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Pufferalgorithmus überprüft, ob die Übertragung der Datenpakete von der Quelle mit der variablen Anfangspufferzeit und der variablen Puffergröße des Vor-Decodiererpuffers in der Client-Vorrichtung übereinstimmt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Nach-Decodiererpuffer in der Client-Vorrichtung eingesetzt wird, um mit dem Decodieren in Zusammenhang stehende Verzögerungsschwankungen zu reduzieren.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Mediendaten an eine drahtlose Client-Vorrichtung über ein drahtloses Datennetzwerk, wie GPRS (General Packet Radio Service) oder UMTS (Universal Mobile Telecommunications System), übertragen werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Mediendaten an eine drahtlose Client-Vorrichtung übertragen werden, wobei das Netzwerk ein drahtloses Netzwerk aufweist, wobei das drahtlose Netzwerk aus einer Gruppe ausgewählt ist, die ein GPRS (General Packet Radio Service) drahtloses Netzwerk und ein UMTS (Universal Mobile Telecommunications System) umfasst.
Client-Vorrichtung zum Empfangen von mehreren Datenpaketen, die über ein Netzwerk von einem Quellserver übertragen werden, wobei die Client-Vorrichtung Folgendes aufweist: einen Vor-Decodiererpuffer zum Empfangen der übertragenen Datenpakete von dem Quellserver über das Netzwerk, wobei der Vor-Decodiererpuffer eine variable Puffergröße aufweist; einen Decodierer zum Decodieren der Datenpakete von dem Vor-Decodiererpuffer; und Mittel zum dynamischen Anpassen der variablen Puffergröße des Vor-Decodiererpuffers, um die Leistung der Wiedergabe durch die Client-Vorrichtung zu verbessern, dadurch gekennzeichnet, dass der Vor-Decodiererpuffer eine variable Anfangspufferzeit aufweist und dass die Client-Vorrichtung Mittel aufweist, um die variable Anfangspufferzeit des Vor-Decodiererpuffers anzupassen, um die Leistung der Wiedergabe durch die Client-Vorrichtung zu verbessern.
Client-Vorrichtung nach Anspruch 18, dadurch gekennzeichnet, dass sie aus einer Gruppe ausgewählt ist, die ein drahtloses Endgerät, einen Desktop-Computer, einen Laptop-Computer enthält.
System zum Streaming von Mediendaten durch Übertragen von mehreren Datenpaketen, wobei das System Folgendes aufweist: – einen Quellserver, auf dem sich die Mediendaten befinden; – ein Netzwerk, das als Übertragungsmedium für die Datenpakete dient und – eine Client-Vorrichtung nach Anspruch 18.
System nach Anspruch 20, dadurch gekennzeichnet, dass das Netzwerk ein drahtloses Netzwerk aufweist, das aus einer Gruppe ausgewählt ist, die ein GPRS (General Packet Radio Service) drahtloses Netzwerk und ein UMTS (Universal Mobile Telecommunications System) umfasst.
System nach Anspruch 21, dadurch gekennzeichnet, dass die Client-Vorrichtung ein drahtloses Endgerät ist, das für die Datenpaketverwendung durch das drahtlose System geeignet ist.
System nach Anspruch 20 oder 21, dadurch gekennzeichnet, dass ein Pufferalgorithmus in dem Quellserver eingesetzt wird, um sicherzustellen, dass die Datenpakete mit einer Geschwindigkeit übertragen werden, die mit den Pufferfähigkeiten der Client-Vorrichtung verträglich ist.