DE60100204T2

DE60100204T2 - Lokalisierung von MPEG-Flüssen für IP-Netzwerke

Info

Publication number: DE60100204T2
Application number: DE60100204T
Authority: DE
Inventors: John P. New Providence Hearn; Kim N. Watchung Matthews; Christopher C. Westfield Yu
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2000-06-30
Filing date: 2001-01-15
Publication date: 2004-02-05
Anticipated expiration: 2021-01-16
Also published as: EP1175098B1; DE60100204D1; US7200670B1; JP2002084323A; EP1175098A1; CA2345314C; CA2345314A1; AU5411501A; JP3946465B2

Description

Technisches Gebiet
Diese Erfindung betrifft die Technik der Übertragung auf Echtzeit eingeschränkter Informationen über Internetprotokoll-Netze (IP-Netze) und insbesondere die Identifizierung besonderer Ströme auf Echtzeit eingeschränkter Informationen, wie Video, das unter Verwendung der Motion-Pictures-Expert-Group-2-Codierung (MPEG-2-Codierung) codiert wird, so dass diese eine entsprechende Verarbeitung erfahren können.
Allgemeiner Stand der Technik
Ein Problem bei der Technik der Übertragung von Paketen, die auf Echtzeit eingeschränkte Informationen enthalten, über Internetprotokoll-Netze (IP-Netze) ist die Notwendigkeit, jeder Art von Information die richtige Verarbeitung zu bieten. Dazu ist es notwendig, an jedem Punkt, an dem das Paket verarbeitet wird, die Art von Information zu kennen, die in jedem Paket enthalten ist, während es durch das Netz geleitet wird. Insbesondere Video, wie die Verwendung eines durch Motion-Pictures-Expert-Group-2 (MPEG-2) codierten Videos, kann ausgelassenen Paketen nicht Stand halten. Daher ist es bei der Verarbeitung von Strömen von Paketen, die MPEG-2-Video enthalten, notwendig, jeglichen MPEG-2-Videoströmen Priorität gegenüber anderen Strömen zu geben, die weniger empfindlich, oder unempfindlich, gegenüber ausgelassenen Paketen sind.
Techniken nach dem Stand der Technik geben Paketen auf der Basis vordefinierter Kriterien Priorität, ohne tatsächlich, z. B. durch Untersuchen des Inhaltes des Pakets, sicherzustellen, dass die Pakete tatsächlich MPEG-2-Video enthalten. Zum Beispiel kann ein Paketfluss definiert werden und es wird angenommen, dass alle Pakete in diesem Fluss MPEG-2-Pakete sind, und Pakete aus diesem Fluss werden so behandelt, als ob sie MPEG-2-Pakete enthalten, ohne auf ihren tatsächlichen Inhalt Rücksicht zu nehmen. Ein Fluss wird häufig durch Spezifizieren der Quellen- und Ziel-IP-Adressen für den Fluss oder durch Spezifizieren seiner Quellen/Zielanschlussadressen definiert.
Eine andere Technik nach dem Stand der Technik, die verwendet wird, um Paketen Priorität zu verleihen, beruht auf dem sogenannten "type-of-service"-Byte (TOS-Byte), das Teil des IP-Paket-Anfangsblocks ist. Das TOS kann zur Anzeige einer groben Prioritätsverleihung verwendet werden, so dass zum Beispiel angenommen wird, dass ein beliebiges Paket mit entweder einem vordefinierten Wert im TOS-Byte oder einem Wert im TOS-Byte, der zumindest ein vordefinierter Wert ist, MPEG-2-Video enthält, und es wird entsprechend behandelt.
Da diese Techniken nach dem Stand der Technik den Inhalt des Pakets nicht wirklich untersuchen, um sicher zu sein, dass es MPEG-2-Video enthält, ist es möglich, dass Pakete, die kein MPEG-2-Video enthalten, so verarbeitet werden, als enthielten sie MPEG-2-Video. Vorausgesetzt, es ist genügend Bandbreite in dem Verarbeitungssystem vorhanden, ist die Verarbeitung dieser Nicht-MPEG-2-Pakete, das heißt, dieser Schein-MPEG-2-Pakete, als wären sie tatsächlich MPEG-2-Pakete, kein Problem. Angesichts der begrenzten Bandbreite jedoch – und welches System hat keine begrenzte Bandbreite – verbraucht die Verarbeitung dieser Schein-MPEG-2-Pakete als nicht auszulassende, tatsächliche MPEG-2-Pakete unnötig Systembetriebsmittel. Ferner können diese Anordnungen zur Prioritätsverleihung nach dem Stand der Technik von einem skrupellosen Benutzer missbraucht werden, der seinen Fluss, oder sein TOS-Byte, so einstellt, dass die Sendung eines MPEG-2-Videos angezeigt wird, wenn dies in Wirklichkeit nicht der Fall ist.
Zusätzlich erfordert die Einrichtung der Flüsse in einem IP-Netz – die Flüsse sind eine statische Kon figuration, die unveränderliche Anschlüsse spezifiziert – eine Verwaltung und/oder Rekonfiguration immer dann, wenn ein Fluss geändert werden muss, d. h., a) wenn in einer Punkt-zu-Punkt-Verbindung einer der Punkte geändert wird, b) wenn eine neue Verbindung hergestellt wird oder c) dergleichen. Es ist zu beachten, dass jede Schalt- oder Verarbeitungseinheit, durch welche ein MPEG-2-Videostrom fließt, mit der neuen Flussidentifizierungsinformation aktualisiert werden muss, sobald ein Fluss geändert werden muss. Aus der daraus resultierenden heftigen Flussbewegung ergibt sich eine konstante administrative Belastung.
Ein weiteres Problem, das bei Anordnungen nach dem Stand der Technik entsteht, die das TOS-Byte zur Definition eines Flusses verwenden, der MPEG-2-Video enthalten soll, ist die Notwendigkeit für alle Schalt- und Verarbeitungseinheiten, durch welche der Fluss strömt, sich auf einen gemeinsamen TOS-Byte-Wert oder Satz von Werten zu einigen, der auf ein MPEG-2-Video hinweist. Andernfalls könnten einige Schalt- oder Verarbeitungseinheiten die MPEG-2-Pakete nicht richtig handhaben, z. B. auslassen. In der Praxis ist es schwierig, eine solche Übereinstimmung zu erreichen, insbesondere wenn sich der Fluss über mehrere Netze bewegt.
A. PURI, T. Chen: "Multimedia Systems, Standards, and networks" (Kapitel 18) März 2000 (2000-03), MARCEL DEKKER XP002183848 ISBN: 082479303X, lehrt den Versand und die Steuerung von MPEG-4-Inhalt über IP-Netze. Der Inhalt eines Paketstromes wird durch die Verwendung von Anfangsblock-Bits identifiziert.
WO-A-98/18233 lehrt eine Vorrichtung und ein Verfahren zum Ermitteln des Synchronisationsmusters eines paketierten Bitstroms unveränderlicher Länge, z. B. eines MPEG-2-Transportstroms. Dies wird unter Verwendung eines Histogramms erreicht, welches das Auftreten des Synchronisationsmusters zeigt.
Kurzdarstellung der Erfindung
Ein Verfahren und eine Vorrichtung gemäß der Erfindung sind in den unabhängigen Ansprüchen dargelegt.
Wir haben erkannt, dass die Probleme nach dem Stand der Technik gemäß den Prinzipien der Erfindung behoben werden können, indem tatsächlich bestimmt wird, dass ein Paket MPEG-2-Video enthält, anstatt vordefinierte Ströme oder Prioritätsniveaus zu verwenden, von welchen angenommen wird, dass sie eine derartige Information enthalten, wie dies nach dem Stand der Technik erfolgt. Insbesondere werden gemäß einem Aspekt der Erfindung die "Synchronisationsbytes" des MPEG-2-Stroms innerhalb der IP-Paketnutzinformationen gesucht, und wenn ein Muster gefunden wird, das auf die Synchronisationsbytes hinweist, werden die Synchronisationsbytes identifiziert und es wird festgestellt, dass das Paket MPEG-2-Video enthält. Das Synchronisationsbyte wurde im MPEG-2 für die drahtlose Aussendung definiert, so dass ein Fernsehempfänger imstande ist, die MPEG-2-Transportstrompakete zu synchronisieren. Es ist zu beachten, dass das MPEG-2-Video, z. B. die MPEG-2-Transportstrompakete, in Echtzeitprotokoll-Paketen ("real time protocol" – RTP) eingefügt sein kann oder nicht, bevor es in die IP-Pakete eingefügt wird.
Kurze Beschreibung der Zeichnung
In der Zeichnung zeigt:
1 ein Internetprotokoll-Paket (IP-Paket) der allgemeinen Art, für das eine Bestimmung, ob es MPEG-2-Video enthält oder nicht, nur auf der Basis der IP-Datennutzinformationen des Pakets gemäß den Prinzipien der Erfindung durchgeführt wird;
2 eine erweitere Version eines Abschnittes des in 1 dargestellten Pakets; und
3 ein beispielhaftes Verfahren in Form eines Flussdiagramms zur Verarbeitung eines IP-Pakets gemäß den Prinzipien der Erfindung, um zu bestimmen, ob es MPEG-2-Video enthält.
Ausführliche Beschreibung
Im Folgenden werden nur die Prinzipien der Erfindung veranschaulicht. Es versteht sich daher, dass der Fachmann imstande ist, verschiedene Anordnungen zu entwickeln, die, obwohl sie hier nicht ausdrücklich beschrieben oder dargestellt sind, die Prinzipien der Erfindung verkörpern und in deren Wesen und Schutzumfang enthalten sind. Ferner sollen alle hierin genannten Beispiele und hypothetischen Aussagen prinzipiell ausdrücklich pädagogischen Zwecken dienen, um dem Leser die Prinzipien der Erfindung und die Konzepte, die von dem bzw. den Erfindern zur Förderung der Technik beigetragen werden, besser verständlich zu machen, und sind so zu verstehen, dass sie in keiner Weise auf solche spezifisch genannten Beispiele und Hypothesen begrenzt sind. Ferner sollen alle Angaben hierin, die Prinzipien, Aspekte und Ausführungsformen der Erfindung betreffen, wie auch spezifische Beispiele derselben, sowohl deren Konstruktions- als auch Funktionsäquivalente umfassen. Zusätzlich ist beabsichtigt, dass solche Äquivalente sowohl gegenwärtig bekannte Äquivalente als auch in der Zukunft entwickelte Äquivalente umfassen, d. h., beliebige entwickelte Elemente, welche dieselbe Funktion ausführen, unabhängig von der Konstruktion.
Somit ist zum Beispiel für den Fachmann offensichtlich, dass die vorliegenden Blockdiagramme Konzeptansichten einer veranschaulichenden Schaltung darstellen, welche die Prinzipien der Erfindung verkörpert. Ebenso ver steht sich, dass schematische Darstellungen, Flussdiagramme, Zustandsübergangsdiagramme, Pseudocode und dergleichen verschiedene Prozesse darstellen, die im Wesentlichen in einem computerlesbaren Medium dargestellt und somit von einem Computer oder Prozessor ausgeführt werden können, gleich, ob ein solcher Computer oder Prozessor ausdrücklich dargestellt ist oder nicht.
Die Funktionen der verschiedenen Elemente, die in den Figuren dargestellt sind, einschließlich Funktionsblöcken, die als "Prozessoren" gekennzeichnet sind, können durch die Verwendung zweckbestimmter Hardware wie auch Hardware, die zur Ausführung von Software imstande ist, in Verbindung mit geeigneter Software bereitgestellt werden. Wenn die Funktionen von einem Prozessor bereitgestellt werden, können sie von einem einzigen zweckbestimmten Prozessor, von einem einzigen gemeinsam benützten Prozessor oder von mehreren einzelnen Prozessoren, von welchen einige gemeinsam benützt werden, bereitgestellt werden. Ferner sollte die ausdrückliche Verwendung des Begriffs "Prozessor" oder "Steuerung" nicht so ausgelegt werden, dass sie sich explizit auf Hardware bezieht, die in der Lage ist, Software auszuführen, und kann implizit, ohne Einschränkung, Digitalsignalprozessor-Hardware (DSP-Hardware), Nur-Lese-Speicher ("read-only memory" – ROM) zum Speichern der Software, Direktzugriffsspeicher ("random access memory" – RAM) und nichtflüchtige Speicherung umfassen. Er kann auch andere Hardware, herkömmliche und/oder kundenspezifische, enthalten sein. Ebenso sind in den Figuren dargestellte Schalter nur konzeptionell. Ihre Funktion kann durch den Betrieb einer Programmlogik, durch zweckbestimmte Logik, durch die Wechselwirkung von Programmsteuerung und zweckbestimmter Logik oder sogar manuell ausgeführt werden, wobei die besondere Technik von dem Ausführenden gewählt werden kann, wie aus dem Zusammenhang deutlicher hervorgeht.
In den vorliegenden Ansprüchen soll ein beliebiges Element, das als Mittel zur Ausführung einer bestimmten Funktion angegeben ist, jegliche Möglichkeit der Ausführung dieser Funktion beinhalten, einschließlich zum Beispiel a) eine Kombination aus Schaltungselementen, die diese Funktion ausführen, oder b) Software in beliebiger Form, somit einschließlich Firmware, Microcode oder dergleichen, kombiniert mit der richtigen Schaltungsanordnung zur Ausführung dieser Software zur Durchführung der Funktion. Die Erfindung, wie durch diese Ansprüche definiert, beruht auf der Tatsache, dass die Funktionalitäten, die von den verschiedenen genannten Mitteln bereitgestellt werden, wie in den Ansprüchen verlangt wird, kombiniert und zusammengebracht werden. Der Antragsteller betrachtet daher jegliches Mittel, das diese Funktionalitäten bereitstellen kann, als äquivalent zu den hier gezeigten.
Falls nicht ausdrücklich hier angegeben, sind die Zeichnungen nicht maßstabgetreu.
1 zeigt ein Internetprotokoll-Paket (IP-Paket) 101 der allgemeinen Art, für das eine Bestimmung auf der Basis nur der IP-Datennutzinformationen des Pakets gemäß der Prinzipien der Erfindung durchgeführt werden kann, ob es MPEG-2-Video enthält oder nicht. Insbesondere wird gemäß einem Aspekt der Erfindung eine Suche nach den "Synchronisationsbytes" des MPEG-2-Stroms in den IP-Paket-Datennutzinformationen des Pakets 101 durchgeführt. Wenn ein Muster gefunden wird, das auf die Synchronisationsbytes hinweist, wird bestimmt, dass das Paket MPEG-2-Video enthält. Andernfalls wird bestimmt, dass das Paket Informationen enthält, die nicht MPEG-2-Video sind.
Das Paket 101 hat eine Reihe von Anfangsblöcken, die den IP-Datennutzinformationen 111 vorangehen. Insbe sondere enthält das Paket 101 einen IP-Anfangsblock 105, der 20 Bytes lang ist, und einen unzuverlässigen Datagramm-Protokoll/Übertragungssteuerungs-Protokoll-Anfangsblock ("unreliable datagram protocol/transmission control protocol" – UDP/TCP-Anfangsblock) 107, der 8 Bytes lang ist. Es ist zu beachten, dass normalerweise der IP-Anfangsblock 105 und der UDP/TCP-Anfangsblock 107 auf herkömmliche Weise zusammengruppiert sind und als Anfangsblock für das IP-Paket bezeichnet werden. Sie sind der Deutlichkeit halber und nur aus pädagogischen Gründen in 1 unabhängig dargestellt.
Es ist zu beachten, dass das IP-Paket 101, wie dargestellt, ein UDP-Paket ist. Der Grund ist, dass in Bezug auf dieses Schreiben UDP normalerweise für ein Echtzeit-Streaming verwendet wird, da TCP eine Ende-zu-Ende-Verbindung benötigt. Somit wird die Erfindung hier in Bezug auf UDP-Pakete im IP beschrieben. Der Fachmann weiß jedoch sofort, wie die Prinzipien der Erfindung bei TCP-Paketen anzuwenden sind.
Dem UDP/TCP-Anfangsblock 109 folgen IP-Datennutzinformationen 111. Die Anzahl von Bytes, die in den IP-Datennutzinformationen 111 enthalten sind, ist flexibel, von 0 aufwärts, obwohl gewisse Übertragungsanordnungen, wie Ethernet, andere Grenzen setzen könnten. Ein wahlweiser Echtzeitprotokoll-Anfangsblock (RTP-Anfangsblock) 109, falls vorhanden, ist 12 Bytes lang und liegt innerhalb der IP-Datennutzinformationen 111.
2 zeigt eine erweiterte Version von IP-Datennutzinformationen 111, die, da das Paket 101 ein UDP-Paket ist, UDP-Datennutzinformationen sind. 2 zeigt ein Beispiel, in dem UDP-Datennutzinformationen 111 MPEG-2-Video befördern. Wie angeführt, kann der RTP-Anfangsblock 109 dem MPEG-2-Video in den UDP-Datennutzinformationen 111 vorangehen.
In Übereinstimmung mit jeglichen festgesetzten Größeneinschränkungen können die UDP-Datennutzinformationen 111 jede beliebige Anzahl von MPEG-2-Transportstrompaketen 201 befördern. Jedes der MPEG-2-Transportstrompakete 201 ist 188 Bytes lang. Aufgrund der Definition der MPEG-2-Transportschicht ist das erste Byte jedes der MPEG-2-Transportstrompakete 201 immer ein sogenanntes "Synchronisationsbyte" 203, das einen Wert von 0×47 hat.
Gemäß den Prinzipien der Erfindung ist es aufgrund der regelmäßigen Beabstandung des Synchronisationsbytes möglich, die UDP-Datennutzinformationen 111 auf die Gegenwart des erwarteten Musters des MPEG-2-Videos zu durchsuchen, d. h., eines Musters mit einem Synchronisationsbyte als das erste Byte der UDP-Datennutzinformationen 111 – nach einem beliebigen wahlweisen RTP-Anfangsblock – und danach mit einem Synchronisationsbyte an jeder Byteposition in den UDP-Datennutzinformationen 111, die ein Vielfaches von 188 sind. Obwohl das Auffinden eines Synchronisationsbytes als das erste Byte der UDP-Datennutzinformationen 111 nach einem beliebigen wahlweisen RTP-Anfangsblock einen starken Hinweis darauf liefert, dass das IP-Paket MPEG-2-Video enthält, und angenommen wird, dass bei UDP-Datennutzinformationen mit einer Länge von 188, von welchen das erste Byte den Wert eines Synchronisationsbytes hat, das Paket MPEG-2-Video enthält, sollte vorzugsweise jede mögliche Position des Synchronisationsbytes geprüft werden. Der Grund ist, dass das Vertrauensniveau, dass tatsächlich MPEG-2-Video gefunden wurde, deutlich steigt, wenn jede Position tatsächlich einen Synchronisationsbyte-Wert enthält.
Falls die meisten der erwarteten Positionen ein Synchronisationsbyte enthalten, aber eine oder mehrere nicht, liegt es im Ermessen des Ausführenden beim Entwickeln oder Konfigurieren des Systems, ob das Paket als ein Paket mit MPEG-2-Video ausgewiesen wird oder nicht. Wenn zum Beispiel nur eine Position, an welcher ein Synchronisationsbyte zu erwarten wäre, kein Synchronisationsbyte war, und das IP-Paket als einen Übertragungsfehler aufweisend angezeigt wurde, könnte der Ausführende entscheiden, dass das System das Paket weiterhin so behandelt, als enthielte es MPEG-2-Video.
3 zeigt einen beispielhaften Prozess in Form eines Flussdiagramms zur Verarbeitung eines IP-Pakets gemäß den Prinzipien der Erfindung, um festzustellen, ob es MPEG-2-Video enthält. Der Prozess beginnt in Schritt 301, wenn ein IP-Paket empfangen wird. Danach wird in Schritt 303 das Paket so verarbeitet, dass ein Pointer vorhanden ist, der auf die UDP-Datennutzinformationen in dem Paket zeigt, d. h., ein Pointer zur Anzeige innerhalb des Pakets wird inkrementiert, um auf die UDP-Datennutzinformationen zu zeigen. Danach prüft ein bedingter Programmverzweigungspunkt 305, um festzustellen, ob die Länge der UDP-Datennutzinformationen ein Vielfaches von 188 ist. Wenn das Testergebnis in Schritt 305 JA ist, was darauf hinweist, dass kein RTP-Anfangsblock vorhanden ist und dass die Länge der UDP-Datennutzinformationen einem Vielfachen der Länge eines MPEG-2-Transportstrompakets entspricht, fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 307 fort, der prüft, um festzustellen, ob das Byte der UDP-Datennutzinformationen, auf welches der Pointer zeigt, den Wert eines Synchronisationsbytes hat, z. B 0×47.
Wenn das Testergebnis in Schritt 307 JA ist, fährt die Steuerung mit Schritt 309 fort, in dem der Pointer 188 Bytes inkrementiert wird, d. h., die Länge eines MPEG-2-Transportstrompakets. Dies sollte dazu führen, dass der Pointer entweder a) auf den Beginn des nächsten MPEG-2-Transportstrompakets zeigt oder auf das Ende der UDP-Datennutzinformationen, das auch das Ende des Pakets ist, vorausgesetzt die UDP-Datennutzinformationen enthalten tatsächlich MPEG-2-Video, oder b) nur auf ein zufälliges Byte, wenn die UDP-Datennutzinformationen nicht tatsächlich lich MPEG-2-Video enthalten. Danach fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 311 fort, der prüft, um festzustellen, ob das Ende des IP-Pakets erreicht worden ist. Wenn das Testergebnis in Schritt 311 NEIN ist, was darauf hinweist, dass noch zusätzliche Abschnitte der UDP-Datennutzinformationen zu verarbeiten sind, kehrt die Steuerung zu Schritt 307 zurück, um den Rest des Pakets wie zuvor beschrieben zu verarbeiten. Wenn das Testergebnis in Schritt 311 JA ist, fährt die Steuerung mit Schritt 313 fort, und das IP-Paket wird als ein Paket mit MPEG-2-Video gemäß einem Aspekt der Erfindung ausgewiesen. Es kann dann entsprechend weiterverarbeitet werden. Das Verfahren endet in Schritt 315.
Wenn das Testergebnis in Schritt 307 NEIN ist, was darauf hinweist, dass entweder das erste Byte oder ein anderes Byte an einer Position von einem Vielfachen von 188 nicht den Wert eines Synchronisationsbytes hat, fährt die Steuerung mit Schritt 315 fort und der Prozess wird beendet.
Wenn das Testergebnis in Schritt 305 NEIN ist, fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 317 fort, der prüft, um festzustellen, ob die Länge der UDP-Datennutzinformationen gleich einem Vielfachen von 188 plus der Länge des RTP-Anfangsblocks ist. Wenn das Testergebnis in Schritt 317 JA ist, was darauf hinweist, dass die UDP-Datennutzinformationen einen RTP-Anfangsblock und danach MPEG-2-Transportstrompakete enthalten können, fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 319 fort, der prüft, um festzustellen, ob die ersten Bytes der UDP-Datennutzinformationen, deren Länge einem RTP-Anfangsblock entspricht, die Eigenschaften eines RTP-Anfangs- blocks haben, z. B. einen Videoindikator an der Stelle haben, wo das Feld vom Typ der Nutzinformationen erwartet wird. Insbesondere ist das Feld vom Typ der Nutzinformationen 7 Bits, wobei die Definition für MPEG-2-Transportstromdaten 0×21 ist.
Wenn das Testergebnis in Schritt 319 NEIN ist, was darauf hinweist, dass kein RTP-Anfangsblock vorhanden ist oder der Anfangsblock auf kein Video hinweist, fährt die Steuerung mit Schritt 315 fort und der Prozess wird beendet, ohne das IP-Paket als ein Paket mit MPEG-2-Video auszuweisen. Wenn das Testergebnis in Schritt 319 JA ist, was darauf hinweist, dass ein RTP-Anfangsblock für Video gefunden wurde, fährt die Steuerung mit Schritt 321 fort, in dem der Pointer inkrementiert wird, um auf das erste Byte nach dem RTP-Anfangsblock zu zeigen. Die Steuerung fährt dann mit dem bedingten Programmverzweigungspunkt 307 fort und der Prozess wird wie zuvor beschrieben fortgesetzt.
Wenn das Testergebnis in Schritt 317 NEIN ist, was darauf hinweist, dass das IP-Paket keine ganze Anzahl von MPEG-2-Videotransportstrompaketen enthält, fährt die Steuerung mit Schritt 323 fort, in dem eine Zählervariable COUNT, die als Versatz in den UDP-Datennutzinformationen verwendet wird, auf 0 gesetzt wird. Danach prüft der bedingte Programmverzweigungspunkt 325, um festzustellen, ob COUNT gleich der Summe von 188 und der Länge eines RTP-Anfangsblocks ist. Wenn das Testergebnis in Schritt 325 JA ist, was darauf hinweist, dass alle Positionen, die möglicherweise ein Synchronisationsbyte eines ersten MPEG-2-Videotransportstrompakets in den UDP-Datennutzinformationen enthalten, getestet wurden und sich nicht als Synchronisationsbyte erwiesen haben, wird der Prozess in Schritt 315 beendet, d. h., das Paket wird nicht als ein Paket mit MPEG-2-Video ausgewiesen. Wenn das Testergebnis in Schritt 325 NEIN ist, was darauf hinweist, dass nicht alle Positionen, die möglicherweise ein Synchronisationsbyte eines ersten MPEG-2-Videotransportstrompakets in den UDP-Datennutzinformationen enthalten, getestet wurden, fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 327 fort, in dem ein anderer Pointer PACKTPT auf den Wert von COUNT eingestellt wird.
Danach wird in Schritt 329 das Byte in den UDP-Datennutzinformationen, auf das PACKTPT zeigt, geprüft, um festzustellen, ob es den Wert eines Synchronisationsbytes hat. Wenn das Testergebnis in Schritt 329 NEIN ist, was darauf hinweist, dass das Byte, auf das gegenwärtig PACKTPT zeigt, kein Synchronisationsbyte ist, fährt die Steuerung mit Schritt 331 fort, in dem COUNT inkrementiert wird, so dass auf das nächste Byte in den UDP-Datennutzinformationen gezeigt wird. Die Steuerung geht dann zu Schritt 325 zurück und der Prozess wird wie zuvor beschrieben fortgesetzt.
Wenn das Testergebnis in Schritt 329 JA ist, was darauf hinweist, dass das Byte, auf das gegenwärtig PACKTPT zeigt, tatsächlich den Wert eines Synchronisationsbytes hat, fährt die Steuerung mit dem bedingten Programmverzweigungspunkt 333 fort, der prüft, um festzustellen, ob die verbleibende Anzahl von Bytes in dem Paket ab der Stelle, auf die COUNT zeigt, weniger als 188 ist. Wenn das Testergebnis in Schritt 333 JA ist, was darauf hinweist, dass kein ganzes MPEG-2-Videotransportstrompaket in den UDP-Datennutzinformationen enthalten sein kann, fährt die Steuerung mit Schritt 315 fort und der Prozess wird beendet, d. h., das Paket wird nicht als ein Paket mit MPEG-2-Video ausgewiesen. Wenn das Testergebnis in Schritt 333 NEIN ist, was darauf hinweist, dass ein ganzes MPEG-2-Videotransportstrompaket in den UDP-Datennutzinformationen enthalten sein könnte, fährt die Steuerung mit Schritt 335 fort, in dem PACKTPT um 188 inkrementiert wird.
An diesem Punkt, wenn die UDP-Datennutzinformationen tatsächlich MPEG-2-Video enthalten und das Byte, auf das gegenwärtig COUNT zeigt, ein Synchronisationsbyte ist, sollte das Byte, auf das PACKTPT zeigt, auch den Wert eines Synchronisationsbytes haben oder sich an oder hinter dem Ende des Pakets befinden. Zu diesem Zweck prüft der bedingte Programmverzweigungspunkt 337, um festzustellen, ob das Ende des Pakets erreicht oder überschritten wurde. Wenn das Testergebnis in Schritt 337 NEIN ist, was darauf hinweist, dass PACKTPT auf ein Byte in den UDP-Datennutzinformationen zeigt, geht die Steuerung zu Schritt 329 zurück und der Prozess wird wie zuvor beschrieben fortgesetzt. Wenn das Testergebnis in Schritt 337 JA ist, was darauf hinweist, dass PACKTPT auf das Ende oder darüber hinaus zeigt, fährt die Steuerung mit Schritt 313 fort und der Prozess wird wie zuvor beschrieben fortgesetzt.
Es ist zu beachten, dass die vorliegende Besprechung in Bezug auf das IP sich auf die IP-Version 4 bezieht, die im Wesentlichen universell in der Anwendung zum Zeitpunkt der Verfassung dieser Anmeldung ist. Der Fachmann ist sofort imstande, die Prinzipien der Erfindung auf später entwickelte IP-Versionen, wie die vorgeschlagene Version 6, anzuwenden, sollte eine implementiert werden.

Claims

Verfahren zum Verarbeiten eines Internet-Protokoll-Pakets (IP-Pakets) (101, 111), umfassend den Schritt des Feststellens, dass das Paket MPEG-2 Video (MPEG – "motion picture expert group") enthält, als Funktion nur des Inhalts der IP-Datennutzinformationen (111) des IP-Pakets ausschließlich der Informationen in einem beliebigen Echtzeitprotokoll-Anfangsblock ("real time protocol" – RTP), der sich in den IP-Datennutzinformationen befinden kann.
Verfahren nach Anspruch 1, wobei das MPEG-2 Video im Transportstromformat ist.
Verfahren nach Anspruch 1, wobei die IP-Datennutzinformationen mindestens ein RTP-Paket enthalten, welches das MPEG-2 Video enthält.
Verfahren nach Anspruch 1, wobei die IP-Datennutzinformationen unzuverlässige Datagramm-Protokoll-Datennutzinformationen ("unreliable datagram protocol" – UDP) sind.
Verfahren nach Anspruch 1, wobei die IP-Datennutzinformationen Übertragungsteuerungs-Protokoll-Datennutzinformationen ("transmission control protocol" – TCP) sind.
Verfahren nach Anspruch 1, des Weiteren umfassend den Schritt des Verarbeitens des IP-Pakets mit einer Priorität, die Paketen mit Video zugeordnet wird, wenn in dem Feststellungsschritt festgestellt wird, dass das Paket Video enthält.
Verfahren nach Anspruch 1, wobei der Feststellungsschritt des Weiteren die folgenden Schritte umfasst: Bestimmen, ob in den IP-Datennutzinformationen wenigstens ein erwartetes Muster von MPEG-2 Synchronisationsbytes vorhanden ist, das auf das Vorhandensein von MPEG-2 Video hinweist.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Vergleichen eines ersten Bytes der IP-Datennutzinformationen nach einem beliebigen Echtzeitprotokoll-Anfangsblock (RTP-Anfangsblock) mit dem Wert eines MPEG-2 Synchronisationsbytes; und wenn das Ergebnis des Vergleichsschrittes ist, dass das erste Byte der IP-Datennutzinformationen denselben Wert wie ein MPEG-2 Synchronisationsbyte hat, Ausweisen des IP-Pakets als MPEG-2 Paket.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Vergleichen eines ersten Bytes der IP-Datennutzinformationen nach einem beliebigen RTP-Anfangsblock mit dem Wert eines MPEG-2 Synchronisationsbytes; und wenn das Ergebnis des Vergleichsschrittes ist, dass das erste Byte der IP-Datennutzinformationen ein MPEG-2 Synchronisationsbyte ist und die Länge der IP-Datennutzinformationen nach einem beliebigen RTP-Anfangsblock gleich der Länge eines MPEG-2 Transportstrompakets ist, Ausweisen des IP-Pakets als MPEG-2 Paket.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Beenden des Prozesses und Anzeigen, dass das erwartete Muster in dem Paket nicht vorhanden ist, wenn nicht die Länge der IP-Datennutzinformationen oder die Länge der IP-Datennutzinformationen minus der Länge eines RTP-Anfangsblocks ein ganzes Vielfaches der Länge eines MPEG-2 Transportstrompakets ist; Richten eines Pointers auf ein Byte in den IP-Datennutzinformationen, wobei das Byte ein erstes Byte der IP-Datennutzinformationen ist, wenn die Länge der IP-Datennutzinformationen ein ganzes Vielfaches der Länge eines MPEG-2 Transportstrompakets ist und das Byte ein erstes Byte der IP-Datennutzinformationen nach der Länge eines RTP-Anfangsblocks ist, wenn die IP-Datennutzinformationen minus der Länge eines RTP-Anfangsblocks ein ganzes Vielfaches der Länge eines MPEG-2 Transportstrompakets ist; Durchführen eines Vergleichs zwischen dem Byte, auf das der Pointer gerichtet ist, mit dem Wert eines MPEG-2 Synchronisationsbytes und Ausweisen des IP-Pakets als Kandidaten für ein MPEG-2 Paket, wenn das Ergebnis eines jüngsten Vergleichs ist, dass das Byte der IP-Datennutzinformationen, auf das der Pointer gerichtet ist, denselben Wert hat wie ein MPEG-2 Synchronisationsbyte; Einstellen des Pointers, so dass er auf ein Byte in den IP-Datennutzinformationen gerichtet ist, das um die Länge eines MPEG-2 Transportstrompakets zu dem Ende des IP-Pakets versetzt ist; Wiederholen der Durchführungs- und Einstellungsschritte, bis der zuletzt ausgeführte Durchfüh rungsschritt das IP-Paket als Kandidaten für ein MPEG-2 Paket ausweist und das Ende der IP-Datennutzinformationen noch nicht erreicht ist; und Ausweisen des Pakets als MPEG-2 Paket, wenn das Ende der IP-Datennutzinformationen während eines Versuchs, den Einstellungsschritt auszuführen, erreicht wird und der zuletzt ausgeführte Durchführungsschritt das IP-Paket als Kandidaten für ein MPEG-2 Paket ausweist.
Verfahren nach Anspruch 7, wobei das erwartete Muster ein MPEG-2 Synchronisationsbytewert in einem Abstand von 188 Bytepositionen ist.
Verfahren nach Anspruch 7, wobei das erwartete Muster ein MPEG-2 Synchronisationsbytewert in einem Abstand von der Länge eines MPEG-2 Transportstrompakets ist.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Ausweisen des IP-Pakets als MPEG-2 Paket, wenn eine Suche über die Länge eines Echtzeitprotokoll-Anfangsblocks und die Länge eines MPEG-2 Transportstrompakets ein Synchronisationsbyte ergibt, zu dem ein anderes Synchronisationsbyte um die Länge eines MPEG-2 Transportstrompakets versetzt ist.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Ausweisen des IP-Pakets als MPEG-2 Paket, wenn eine Suche über die Länge eines Echtzeitprotokoll-Anfangsblocks und die Länge eines MPEG-2 Transportstrompakets den Wert eines Synchronisationsbytes ergibt, zu dem der Wert eines Synchro nisationsbytes bei jedem ganzen Vielfachen der Länge eines MPEG-2 Transportstrompakets versetzt ist, bis das Ende des IP-Pakets erreicht ist oder überschritten wird.
Verfahren nach Anspruch 7, wobei der Bestimmungsschritt des Weiteren folgenden Schritt umfasst: Ausweisen des IP-Pakets als MPEG-2 Paket, wenn eine Suche über die Länge eines Echtzeitprotokoll-Anfangsblocks und die Länge eines MPEG-2 Transportstrompakets den Wert eines Synchronisationsbytes ergibt, zu dem das Ende des Pakets um die Länge eines MPEG-2 Transportstrompakets versetzt ist.
Verfahren nach Anspruch 7, wobei jedes der Synchronisationsbytes einen Wert von 0×47 hat.
Verfahren nach Anspruch 7, wobei das wenigstens eine erwartete Muster der Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen ist.
Verfahren nach Anspruch 7, wobei das wenigstens eine erwartete Muster der Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen und alle 188 Bytes danach bis zum Ende der IP-Datennutzinformationen ist.
Verfahren nach Anspruch 7, wobei das wenigstens eine erwartete Muster wenigstens einen der Mustersätze enthält, bestehend aus: a) dem Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen nach der Länge eines Echtzeitprotokoll-Anfangsblocks (RTP-Anfangsblocks) (109), wobei die IP-Datennutzinformationen nach der RTP-Anfangsblocklänge eine Länge von 188 Bytes haben, b) dem Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen nach der Länge eines Echtzeitprotokoll-Anfangsblocks (RTP-Anfangsblocks) und alle 188 Bytes danach bis zum Ende der IP-Datennutzinformationen, c) dem Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen und alle 188 Bytes danach bis zum Ende der IP-Datennutzinformationen, d) dem Wert eines MPEG-2 Synchronisationsbytes als das erste Byte der IP-Datennutzinformationen, wobei die IP-Datennutzinformationen eine Länge von 188 Bytes haben.
Vorrichtung, umfassend: Mittel zum Durchsuchen von IP-Datennutzinformationen (111) eines Internet-Protokoll-Pakets (IP-Pakets) (101, 111) ausschließlich eines beliebigen Echtzeitprotokoll-Anfangsblocks (RTP-Anfangsblocks) darin nach einem Muster, das auf Video hinweist; und Mittel zum Anzeigen, dass das IP-Paket Video enthält, wenn das Muster gefunden wird.