DE60310368T2

DE60310368T2 - Verfahren zur verhinderung von startkode-emulation und stopfdaten

Info

Publication number: DE60310368T2
Application number: DE60310368T
Authority: DE
Inventors: J. Gary Redmond SULLIVAN; J. Stephen Carnation ESTROP
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-01-22
Filing date: 2003-01-22
Publication date: 2007-03-29
Anticipated expiration: 2023-01-23
Also published as: EP1468566B1; WO2003063500A1; JP2005516496A; ATE352171T1; ATE464748T1; EP1753244A1; DE60311231D1; JP5394528B2; ATE348484T1; US20030146855A1; DE60332175D1; US7505485B2; HK1069700A1; DE60310368D1; JP2009246995A; DE60311231T2; JP4503294B2; ES2341357T3; PT1753244E; JP5175371B2

Description

Technisches Feld
Diese Erfindung betrifft Verfahren für die Verhinderung von Startcode-Emulation und Stopfdaten.
Hintergrund der Erfindung
Digitale Daten werden typisch von einem Typ von Sender zu einem Typ von Empfänger übertragen. Sender umfassen typischerweise einen Codierer, der die Daten für die Übertragung codiert; und Empfänger umfassen typischerweise einen Decodierer, der empfangene Daten decodiert. Es gibt unterschiedliche Typen von digitalen Daten, wie beispielsweise Videodaten, Audiodaten, Audio/Videodaten, Textdaten, von einem Rechner ausführbare Programmdaten, Daten im Archiv, Datenbankinformation, und dergleichen. Wenn digitale Daten übertragen werden, werden sie typischerweise in einem Typ von Kanal übertragen. In gleicher Weise können Rechnerspeicher oder jede Speichervorrichtung oder Speichermedium als Übertragungskanal für solche Zwecke angesehen werden.
Wenn digitale Daten übertragen werden, ist es wichtig, spezifische Punkte innerhalb der Daten im Kanal finden zu können. Dies wird zu verschiedenen Zwecken getan, wie um z. B. Punkte zu lokalisieren, an denen nach Fehlern und Verlusten in der Übertragung der Daten durch den Kanal fortgesetzt werden kann, oder um Punkte zu lokalisieren, an denen das Starten des Decodierungsprozesses an einer anderen Stelle als der Start des gesamten Datenstroms möglich ist, oder um Punkte zu lokalisieren, die das Suchen nach verschiedenen Typen von Daten ermöglichen, welche für unterschiedliche Zwecke benutzt werden. Auf der Decodiererseite müssen Decodierer und andere Komponenten, die digitale Daten verarbeiten, oft den Kontext der Daten kennen, so dass die Daten ordentlich verarbeitet werden können. Das wäre nicht so wichtig, wenn der Start mit dem ersten gesendeten Bit erfolgt und der Decodierer ohne jegliche Fehler laufen könnte. In dieser Situation könnte der Deco dierer einfach die gesendete Information entsprechend dem Wissen verfolgen, was das Format der Daten ist. Leider kommt diese idealistische Situation nicht häufig vor. Fehler und andere Eventualitäten treten auf, die Herausforderungen für diejenigen darstellen, die Systeme zur Übertragung und zum Empfang von digitalen Daten entwerfen und benutzen. In einigen Fällen, zum Beispiel beim Einschalten in einen laufenden Sendungsstrom von Daten, kann der Decodierer nicht am Start der Datenübertragung beginnen. Das Lokalisieren von Punkten durch Datenformatanalyse kann auch eine signifikante Menge an komplexer Verarbeitung in einem Decodierer erfordern.
In vielen Typen von Kanalumgebungen werden solche Themen durch die Bereitstellung von sogenannten Resynchronisierungsmarkierungen in den Daten angegangen. Resynchronisierungsmarkierungen stellen einen Mechanismus bereit, durch den ein System seinen Decodierungsprozess starten oder nach einem Fehler fortsetzen kann. Wenn digitale Daten z.B. als eine Serie von Bits oder Bytes aufgereiht werden, kann das Vorhandensein von Resynchronisierungsmarkierungen im Datenstrom einen Decodierer mit einem Bezugspunkt versorgen, von welchem in dem Falle, dass ein Fehler in der Übertragung auftritt, fortgesetzt werden kann.
Eine Weise der Verwendung von Resynchronisierungsmarkierungen geschieht im Kontext der Startcodes. Ein Startcode ist eine Kette von Bits oder Bytes mit einem spezifischen Wert. Im Allgemeinen tendieren viele Systeme dazu, Bytes (z.B. H.222.0/MPEG-2-Systeme) zu tragen, so dass Startcodes als eine Kette von Bytes mit einzigartigem Wert definiert werden können. Eine Kette von Bytes mit einzigartigem Wert stellt ein Muster bereit, dessen Anwesenheit einen Resynchronisierungspunkt anzeigt. Ein Resynchronisierungspunkt zeigt typischerweise den Start oder die Grenze von irgendeiner unabhängig decodierbaren Datenmenge an. In H.262/MPEG-2-Videodaten können Resynchronisierungspunkte zum Beispiel den Start eines Abschnitts (slice) (d.h. einer unabhängig decodierbaren Bildregion), den Start des Bildes, den Start einer GOP (d.h. "Group of Pictures" (Bildgruppe) oder unabhängig decodierbaren Sequenz von Bildern) oder den Start einer neuen Videosequenz an. Digitale Videoströme können auch sogenannte zusätzliche oder ergänzende Daten beinhalten, denen ein Startcode vorangestellt ist.
Manchmal werden Startcodes nicht nur innerhalb eines Datenstromes, wie beispielsweise eines Videostroms, verwendet, sondern werden auch von der Multiplexstufe eines Systems verwendet. Die Spezifikation des H.222.0/MPEG-2-Systems ist ein Beispiel eines Systems, das Startcodes verwendet und Videodatenströme trägt, die mit Systemstufeninformation und Audioinformation verflochten sind.
Da Startcodes wichtig sein können, insofern sie Resynchronisierungspunkte innerhalb des Datenstroms bereitstellen, ist es eine gute Idee, die Emulation von Startcodes im Datenstrom an Orten zu vermeiden, welche an sich nicht Startcodes darstellen sollen.
Z.B. ist Folgendes zu beachten. Startcodes definieren ein spezifisches Muster von Bits und Bytes, das den Start einer neuen Dateneinheit identifizieren kann. Wenn man zufällige Daten zwischen den Startcodes sendet, dann ist es möglich, dass die zufälligen Daten in sich dasselbe Muster beinhalten, das als Startcode verwendet wird. Z.B. unter der Annahme, dass die Daten, die getragen werden, vollständig zufällig sind, dann ist die Wahrscheinlichkeit der zufälligen Emulation des Startcodes in den an einer bestimmten Bitposition startenden Bits ½^K, wenn ein Startcode K Bits lang ist.
In einigen Fällen kann die Beurteilung gemacht werden, dass dann, wenn die Anzahl der Bits im Startcode groß ist, es recht unwahrscheinlich ist, dass der Startcode zufällig nachgebildet wird. Dies ist der Fall im Hinblick auf einige Audiodatenformate. Diese Formate benutzen typischerweise keine sehr hohe, in Bits pro Sekunde gemessene Bitrate, so dass es nicht zu wahrscheinlich ist, dass der Startcode aus Versehen während irgendeines bestimmten Zeitintervalls nachgebildet wird. Im Hinblick auf Videodaten ist dies im Allgemeinen nicht der Fall, da Video häufig eine viel höhere Bitrate erfordert.
In größeren Videocodierungsstandards in der Vergangenheit (mit vielleicht einer Ausnahme) ist das Videosyntaxformat innerhalb der Datennutzlast so entworfen worden, dass Startcode-Emulation vermieden wird. Das heißt, wenn man weiß, welcher Typ von Datenelementen die Videosyntax ausmachen wird, kann man die Syntax sorgfältig so entwerfen, dass keine zufälligen Startcodes auftreten können. Ein Startcode in traditionellen Videocodierungsstandards beginnt zum Beispiel mit einer langen Kette von 0-Bits, gefolgt von einem 1-Bit. Diese lange Kette kann 23 0-Bits enthalten, gefolgt von einem 1-Bit. Man nehme an, dass die meisten der gesendeten Daten Entrophie-codiert sind unter Verwendung von Codes variabler Länge (häufig informell als Huffman-Codes bezeichnet). Codes mit variabler Länge (variable length codes, VLCs) werden hier beispielsweise als Codes mit variabler Tiefe und Baumstruktur definiert, die verwendet werden, um aus einer Reihe von repräsentierten Symbolen auszuwählen. Eine Technik unter Verwendung von binären Baum-VLCs besteht darin sicherzustellen, dass der Weg im Baum von der Wurzel zu jedem Blatt, das ein gültiges Symbol darstellt, irgendwo eine "1" beinhaltet, und dass die Baumstruktur nicht zu tief ist.
Wenn man daher zum Beispiel weiß, dass jede Codekette mit variabler Länge nicht länger als 10 Bits lang ist und dass jede solche Kette mindestens ein 1-wertigen Bit beinhaltet, dann weiß man, dass unter keinen Umständen eine codierte Datensequenz eines VLCs jemals mehr als 18 aufeinanderfolgende Null-wertige Bits enthalten kann. Das heißt, im schlimmsten Fall würde 1000000000 gefolgt von 0000000001. Wenn man daher die Syntax sorgfältig entwirft und die Position jedes 0-wertigen und jedes 1-wertigen Bits untersucht, um sicherzustellen, wie viele 0s in einer Reihe auftreten, kann man einen Startcode verwenden, der eine längere Kette an 0s enthält, als jemals in der Syntax auftreten kann. Die Syntax kann zum Beispiel so entworfen werden, dass die gültige Syntax niemals 23 Nullen in einer Position enthalten kann, die kein Startcode ist. Daher sollte jedes Auftreten von 23 Nullen ein Startcode sein, und der Decodierer sollte in der Lage sein, Startcodes genau zu entdecken.
Während die oben beschriebene Operation geradlinig erscheint, kann die Operation ein recht schwieriges Unterfangen sein, weil man alle möglichen Daten (auf der Bitebene), die gesendet werden, in jeder möglichen Reihenfolge, in welcher sie gesendet werden, untersuchen muss um sicherzustellen, dass ein Startcode-Muster nicht zufällig gesendet werden kann. Dies ist ein beschwerliches Verfahren des Syntaxentwurfs, das für Fehler anfällig ist.
Dieser Designprozess der Untersuchung der Bit-Ebene beschreibt im Allgemeinen die Art und Weise, in der viele Videocodierungsspezifikationen in der Vergangenheit entworfen worden sind (d.h. H.261, MPEG-1, H.262IMPEG-2, den Großteil von H.263 und MPEG-4). Die eine Ausnahme hierzu ist Annex E der ITU-T-Empfehlung H.263, die eine "arithmetische Codierung" genannte Technik verwendet zur Generierung von komprimierten Bits in einer algorithmischen Weise von einer mathematischen Spezifikation. Hier gibt es einen Extraprozess am Ende des Entrophie-Codierers, der die generierten Bits untersucht und auf der Seite des Codierers ein "Markierungs"-Bit (ein 1-Bit) einfügt, wenn es zu viele 0-Bits in einer Reihe gibt, bevor eine vorbestimmte Anzahl an 0-Bits gefunden wird. Auf der Decodiererseite zählt der Decodierer die Nullen zusammen und wenn er die kritische Anzahl an Nullen findet, weiß er, dass er einen echten Startcode gefunden hat. Wenn der Decodierer eine Null weniger als die kritische Anzahl sieht, weiß er, dass das folgende 1-Bit ein eingefügtes Markierungsbit ist, um Startcode-Emulation zu verhindern, verwirft dieses Bit und nimmt das folgende Bit als die Weiterführung der echten Daten an.
Das Problem mit dieser Lösung ist, dass es den Codierer und den Decodierer die eingehenden Daten auf Bit-Ebene untersuchen und verarbeiten läßt. Die Analyse und Verschiebung der Position der Daten, die verarbeitet werden, um einzelne Bit-Positionen wird schwierig und kann den Decodierer in unerwünschter Weise belasten. Die Verschiebung Bit um Bit ist auch eine Prozessor-intensive Operation.
Dementsprechend ist diese Erfindung aus Überlegungen entstanden, die damit verbunden sind, verbesserte Verfahren und System zur Vermeidung von Startcode-Emulation bereitzustellen.
Zusammenfassung der Erfindung
Verfahren und Systeme werden beschrieben, um Ansätze zur Startcode-Emulationsverhinderung bereitzustellen durch Operationen, die auf einer Ebene mit höherer Körnigkeit als der Bit-Ebene durchgeführt werden. Durch das Operieren auf einer anderen Ebene als der Bit-Ebene kann die Verarbeitungseffizienz verstärkt werden. In Übereinstimmung mit einer oder mehreren Ausführungsformen sucht ein Verfahren zur Verhinderung von Startcode-Emulation nach Datenmustern, die sich auf Datenportionen mit festgelegter Größe größer als einzelne Bits beziehen. Wenn ein bestimmtes Muster gefunden worden ist, werden Daten zur Verhinderung von Startcode-Emulation eingefügt, um Startcode-Emulation zu verhindern. Die eingefügten Daten sind größer als ein einzelnes Bit und umfassen in einigen Ausführungsformen ein Byte. Wenn ein Decodierer Daten decodiert, in welche Daten zur Verhinderung von Startcode-Emulation eingefügt worden ist, kann es einfach legitime Start codes identifizieren und dann die Startcode-Emulationsverhinderungsdaten entfernen, um die Originaldaten bereitzustellen, die übermittelt werden sollten.
Darüber hinaus wird ein Datenstopfverfahren beschrieben, welches ermöglicht, dass Nutzlastdaten zu einer ganzen Anzahl an Byte-Größen aufgerundet zu werden, und dann ermöglicht, dass Fülldaten in einer Weise hinzugefügt zu werden, die durch einen Decodierer einfach zu entdecken sind.
Kurze Beschreibung der Zeichnungen
1 ist ein Flußdiagramm, welches Schritte in einem Verfahren in Übereinstimmung mit einer Ausführungsform beschreibt.
2 ist ein Flußdiagramm, welches Schritte in einem Verfahren in Übereinstimmung mit einer Ausführungsform beschreibt.
3 ist ein Hochniveaudiagramm einer Rechnerumgebung, in Verbindung mit welcher eine oder mehrere Ausführungsformen implementiert werden können.
Ausführliche Beschreibung der bevorzugten Ausführungsform
Überblick
Die unten beschriebenen Verfahren und Systeme sehen Ansätze zur Verhinderung von Startcode-Emulation auf einer Ebene mit höherer Körnigkeit als die Bit-Ebene vor. Durch das Operieren auf einer höheren Ebene als der Bit-Ebene kann die Verarbeitungseffizienz verstärkt werden. Im Kontext dieses Dokuments soll das Operieren auf einer höheren Ebene als der Bit-Ebene sich auf einen Prozess beziehen, der nach Datenmustern sucht, die sich auf Datenportionen von festgelegter Größe größer als einzelne Bits beziehen. Datenportionen von festgelegter Größe können Bytes (d.h. 8 Bits), "Worte" (d.h. 16 Bits), "Doppel- Worte" (32 Bits) und dergleichen umfassen. Daher können die Erfindungstechniken nach Mustern innerhalb und zwischen Bytes, Worten, und dergleichen suchen.
Darüber hinaus wird ein Datenstopfverfahren beschrieben, welches ermöglicht, dass Nutzlastdaten auf eine ganzzahlige Anzahl von Byte-Größen aufgerundet werden, und dann ermöglicht, dass Fülldaten in einer Weise hinzugefügt zu werden, die durch einen Decodierer einfach zu entdecken sind.
Während darüber hinaus die unten angeführten Beispiele im Kontext von Videodaten diskutiert werden, muss anerkannt und verstanden werden, dass die Erfindungstechnik in Verbindung mit jedem Datentyp angewendet werden kann, der typischerweise codiert und decodiert wird und für den die Verhinderung von Startcode-Emulation wünschenswert oder notwendig ist. Beispiele solcher Daten umfassen Audiodaten, Audio/Videodaten und dergleichen.
1 ist ein Flußdiagramm, das Schritte in einem Verfahren in Übereinstimmung mit einer Ausführungsform beschreibt. Das Verfahren kann in jeder passenden Hardware, Software, Firmware oder deren Kombination implementiert werden. In der veranschaulichten und beschriebenen Ausführungsform wird das Verfahren zumindest zum Teil in der Software implementiert. Darüber hinaus wird der Leser bemerken, dass das Verfahren veranschaulicht wird als ein Verfahren mit zwei verschiedenen Zweigen, von denen einer mit "Codierer" und der andere mit "Decodierer" bezeichnet ist. Der "Codierer"-Zweig veranschaulicht Schritte, die durch einen oder in Verbindung mit einem Codierer durchgeführt werden. In ähnlicher Weise veranschaulicht der "Decodierer"-Zweig Schritte, die durch einen oder in Verbindung mit einem "Decodierer" ausgeführt werden.
Schritt 100 erhält oder generiert eine Datenquantität, die für die Übertragung nach einem Startcode bestimmt ist. Die Daten können alle passenden Daten umfassen. Beispiele für Datentypen umfassen ohne Einschränkung Quantitäten von Videodaten, Audiodaten, Audio/Videodaten und dergleichen. Schritt 101 stellt den Daten Startcodes voran. Dieser Schritt fügt effektiv Startcodes zu den Daten hinzu, die in Schritt 100 erhalten oder generiert worden sind. Schritt 102 überprüft oder durchsucht eingehende Daten nach einem oder mehreren Mustern für Datenportionen von festgelegter Größe. In der veranschaulichten und beschriebenen Ausführungsform umfassen die gesuchten Muster mindestens zwei Datenportionen von festgelegter Größe, und jede individuelle Datenportion umfasst mindestens zwei Bits. Schritt 104 bestimmt, ob ein Muster gefunden worden ist. Wenn das Muster nicht gefunden worden ist, zweigt das Verfahren zu Schritt 108 ab, in dem die Daten übertragen werden können.
Wenn andererseits das Muster gefunden wird, fügt Schritt 106 Startcode-Emulationsverhinderungsdaten ein in Bezug auf die Daten, die das Muster enthalten. In der veranschaulichten und beschriebenen Ausführungsform umfassen individuelle Fälle der Startcode-Emulationsverhinderungsdaten mehr als ein Bit. Vorzugsweise umfassen Startcode-Emulationsverhinderungsdaten eine Datenmenge, die in der Anzahl der Bits gleich einer individuellen Datenportion von festgelegter Größe ist. Wo daher eine Datenportion von festgelegter Größe 8 Bits (eine Datenmenge, die als ein Byte bezeichnet wird) beinhaltet, beinhaltet die Startcode-Emulationsverhinderungsdaten 8 Bits. Nachdem die Startcode-Emulationsverhinderungsdaten eingefügt worden sind, überträgt Schritt 108 die Daten. Schritt 110 bestimmt, ob es zusätzliche Daten gibt, die vor dem nächsten Startcode übertragen werden sollen. Wenn es diese Daten gibt, dann kehrt das Verfahren zu Schritt 102 zurück und läuft wie oben beschrieben fort. Wenn es diese Daten nicht gibt, kann das Verfahren an Schritt 111 bestimmen, ob es zusätzliche Daten zu übertragen gibt. Wenn es diese zusätzlichen Daten gibt, zweigt das Verfahren zurück zu Schritt 100. Wenn es diese zusätzlichen Daten nicht gibt, dann kann das Verfahren an Schritt 112 beendet werden.
Daneben wird bemerkt, dass ein Verwendungsbeispiel dieser bestimmten Technologie den Startcode in ein "Startcode-Präfix" und einen "Startcode-Typen"-Suffix einteilt, wobei das Präfix eine einzelne Kette von Werten ist und das Suffix den Datentyp anzeigt, der dem Startcode folgt. Insbesondere ist dies die Struktur von MPEG-2- und H.264/AVC-Startcodes und dies ist die in dem Abschnitt mit dem Titel "Erstes beispielhaftes Verfahren" unten verwendete Struktur. Eine noch allgemeinere Verwendungsform, die die Präfix/Suffix-Struktur als ein spezieller Fall umfaßt, ist die allgemeine Auffassung, ein oder mehrere Startcode-Muster zu haben. Dann können auch ein oder mehrere Emulationsverhinderungsmuster verwendet werden. Solange die verschiedenen Startcode-Muster sich von den verschiedenen Emulationsverhinderungsmuster unterscheiden und alle diese Muster in der Verarbeitung der Nutzlastdaten vermieden werden, wird das Schema dementsprechend funktionie ren. Darüber hinaus ist nicht notwendigerweise anzunehmen, dass die Startcode-Muster alle dieselbe Länge haben. Dies kann in bestimmten Fällen wichtig sein, weil beispielsweise die Verwendung von H.264/AVC interpretiert werden kann als Verwendung von Multilängen-Startcodes.
Auf der Decodiererseite ist Folgendes zu beachten. Sobald die Startcode-Emulationsverhinderungsdaten durch den Codierer eingefügt worden sind, können sie identifiziert und an irgendeinem Punkt für die richtige Interpretation der anderen Daten entfernt oder ignoriert werden. Man beachte auch, dass dann, wenn der Decodierer die übertragenen Daten empfängt, er nach den legitimen Startcodes suchen kann. Sobald er die legitimen Startcodes findet, weiß er, wo die durch einen Startcode definierten Datengrenzen liegen. Nun kann der Decodierer fortfahren, nach den Startcode-Emulationsverhinderungsdaten zu suchen und sie zu entfernen, so dass er die echten Daten weiterverarbeiten kann.
Insbesondere empfängt Schritt 114 übertragene Daten, die von einem Codierer verarbeitet wurden, um die Emulation der Startcodes zu verhindern. Schritt 118 verarbeitet die Daten, um den Startcode zu finden. Sobald der Startcode gefunden und angemessen verarbeitet wurde (z.B. gelesen und verworfen), durchsucht Schritt 120 die Daten, um Startcode-Emulationsverhinderungsdaten zu identifizieren. Sobald die Startcode-Emulationsverhinderungsdaten gefunden sind, entfernt Schritt 122 die Startcode-Emulationsverhinderungsdaten. Sobald die Startcode-Emulationsverhinderungsdaten entfernt worden sind, können die Daten in einer Weise verarbeitet werden, die typisch ist für den Datentyp, der empfangen worden ist. Die Daten können zum Beispiel durch eine Verbrauchervorrichtung verbraucht werden, wie in Schritt 124.
Erstes beispielhaftes Verfahren
Das Verfahren, welches nun beschrieben wird, veranschaulicht nur ein spezifisches Beispiel des in 1 gezeigten und beschriebenen Verfahrens. In dem nun beschriebenen Verfahren wird ein Byte der Emulationsverhinderungsdaten eingefügt, immer wenn eine Kette von N + 1 Bytes der Nutzlastdaten entweder mit dem gesamten Startcode-Präfix übereinstimmt oder wenn er mit den ersten N Bytes des Startcode-Präfix plus dem Wert des Emulationsverhinderungsbytes übereinstimmt. Dieses Verfahren fügt Daten seltener hinzu als das in der Sektion mit dem Titel "Zweites beispielhaftes Verfahren" beschriebene Verfahren, und reduziert daher die Anforderungen an die Übertragungskapazität zum Senden der Nutzlastdaten.
Die MPEG-2-Startcode-Präfixstruktur beginnt an einer auf Bytegrenze ausgerichteter Position und hat 23 0-Bits gefolgt von einem 1-Bit. Dieses Startcode-Präfix wird wie folgt angeführt:
00000000 00000000 00000001
Diese Struktur kann als Muster verallgemeinert werden, das irgendeine Anzahl an Bytes N umfasst, die denselben Wert haben, gefolgt von irgendeinem anderen Byte, das einen unterschiedlichen Wert hat. In MPEG-2 kann man sagen, dass N = 2 und die ersten zwei Bytes 0 sind (unten als "W" bezeichnet), und dass das letzte Byte 1 ist (unten als "X" bezeichnet). Daher hat das Startcode-Präfix das folgende Muster:
WWX
Nach diesen drei Bytes folgt in MPEG-2 ein anderes Byte und identifiziert, welcher Typ von Startcode es ist. Dieses folgende Byte wird als "Y" bezeichnet. Der Startcode besteht dann grundsätzlich aus einem Startcode-Präfix WWX, gefolgt von einem Byte Y, das den Typ des Startcodes identifiziert. Der gesamte MPEG-2-Startcode kann dargestellt werden als:
WWXY
Der Startcode-Präfix (WWX) hat einen festgesetzten Wert, während Y eine Anzahl an verschiedenen Werten hat, die den Typ des Startcodes anzeigen (z.B. Abschnitt, Bild, GOP, Sequenz, System, und dergleichen).
In Entsprechung mit einer Ausführungsform werden die Daten verarbeitet und nach dem Muster WWX gesucht. Wenn das WWX-Muster gefunden wird, werden die Startcode-Emulationsverhinderungsdaten eingefügt, um Startcode-Emulation zu verhindern. Hier umfassen die Startcode-Emulationsverhinderungsdaten ein Byte Z, das einen Wert hat, der sich von den Werten der W- und der X-Bytes unterscheidet. Daher wird angenommen, dass der Codierer Datenbytes untersucht und das Muster WWX bemerkt. Als Reaktion auf das Auffinden dieses Musters in den Daten fügt der Codierer ein Byte mit dem Wert Z ein, um das folgende Muster bereitzustellen:
WWZX
An diesem Punkt hat der Codierer sichergestellt, dass die Nutzlastdaten, die übertragen und vom Decodierer verarbeitet werden sollen, nicht zufällig einen Startcode oder einen Startcode-Präfix nachbilden. Nun ist Folgendes zu beachten. Genau wie die Nutzlastdaten eine Chance haben, einen Startcode-Präfix nachzubilden, indem sie zufällig das WWX-Muster enthalten, haben die Nutzlastdaten auch eine Chance, zufällig Daten nachzubilden, die die Startcode-Emulationsverhinderungsdaten enthalten. Das heißt, die Nutzlastdaten können schon an sich das Muster WWZX enthalten. Wenn dies der Fall ist und der Codierer nichts tun würde, wird der Decodierer bei dem Versuch des Entfernens der Startcode-Emulationsverhinderungsdaten das Z-Byte entfernen, welches in diesem Fall echte Daten sind.
Dementsprechend wird der Codierer in den beschriebenen Ausführungsformen konfiguriert, um nicht nur zu verhindern, dass die Nutzlastdaten Startcodes oder Startcode-Präfixe nachbilden, sondern der Codierer wird konfiguriert, um zu verhindern, dass die Daten Datenmuster nachbilden, die aus der Verwendung von Startcode-Emulationsverhinderungsdaten resultieren. Wenn insbesondere in diesem Beispiel der Codierer das Muster WWZ identifiziert, fügt er ein Byte mit dem Wert Z zwischen dem zweiten W und dem Z ein, um das folgende Muster bereitzustellen (das eingefügte Byte Z ist das erste Z, das unten erscheint):
WWZZ
Nun werden die verarbeiteten Daten aus der Perspektive des Decodierers betrachtet. Wenn der Decodierer irgendein Muster von Bytes sieht, das WWZ gefolgt von entweder einem Z oder einem X enthält, weiß er, dass das erste Z ein Emulationsverhinderungsbyte ist, welches durch den Codierer eingefügt wurde. Dementsprechend kann der Decodierer das erste Z verwerfen. Daher gibt es in diesem Beispiel zwei Situationen, wo ein Emulationsverhinderungsbyte eingefügt werden kann. Die erste Situation besteht, wenn die Daten versehentlich einen Startcode oder einen Startcode-Präfix nachbilden. Die zweite Situation besteht, wenn die Daten versehentlich Daten nachbilden, denen ein Emulationsverhinderungsbyte eingefügt worden ist.
In beiden Fällen kann der Decodierer einfach nach einem angemessenen Muster suchen, das Emulationsverhinderungsbyte verwerfen und die Daten wie gewöhnlich verarbeiten.
Um den oben angeführten Prozess in programmatischerer Weise zu veranschaulichen, ist Folgendes zu beachten. Um auf der Codierer-Seite ein Paket P[] von B Bytes, welches mit einem Startcode-Präfix beginnt, das aus N oder mehr Bytes desselben Wertes W und einem letzten Byte eines anderen Wertes X besteht, gefolgt von einem identifizierenden Startcode-Type-Suffix von einem Byte mit dem Wert Y, betreiben wir den folgenden Pseudo-Code-Prozess, der Emulationsverhinderungsbytes mit dem Wert Z einfügt (wobei W, X, Y und Z voneinander unterschiedliche Werte haben und P[B-1] nicht gleich W ist), wobei die Quantität von zusätzlichen Daten, die zum Füllen des Kanals zu senden sind, durch E spezifiziert wird:
Im obigen Pseudo-Code wird angenommen, dass eine Funktion "send_byte()" die Übertragung einer Einheit von Daten (Prozess 108 in 1) betreibt.
Um das Paket zu empfangen, wird auf der Decodierer-Seite angenommen, dass der Decodierer den bekannten Startcode-Präfix, der aus N oder mehr Bytes desselben Wertes W und einem letzten Byte eines anderen Wertes X besteht, bereits gefunden, gelesen und verworfen hat. Auch wird angenommen, dass der unbekannte Einzelbyte-Startcode-Type-Suffix in einer Variablen Y zu lesen ist und das Paket der Nutzlastdaten in einen Bereich P[] zu lesen ist und die Menge der Nutzdaten zu bestimmen ist und die Quantitätsanzeige in einer Variablen B zu plazieren ist, während das Emulationsverhinderungsbyte mit dem Wert Z entfernt wird (wobei W, X, Y und Z voneinander verschiedene Werte haben und P[B-1] nicht gleich W ist):
Im obigen Pseudo-Code wird angenommen, dass eine Funktion "receive_Byte()" den Empfang einer Dateneinheit betreibt und dass eine Funktion "more_data()" bestimmt, ob es noch weitere Dateneinheiten zu empfangen gibt (diese beiden Funktionen umfassen Prozess 114 in 1).
Das oben beschriebene Verfahren erlaubt eine zufällige Menge an dem Startcode vorausgehenden Stopfen mit W-Wert. Formulierungen, die die Anzahl der W-Wert-Präfixe auf N begrenzen, sind genauso möglich.
Zweites beispielhaftes Verfahren
Das zu beschreibende Verfahren veranschaulicht nur ein weiteres spezifisches Beispiel des in 1 gezeigten und beschriebenen Verfahren. Hier fügt das Verfahren immer dann ein Byte von Emulationsverhinderungsdaten ein, wenn eine Kette von N Bytes von Daten in der Nutzlast mit den ersten N Bytes des Startcode-Präfixes übereinstimmen, unabhängig vom Wert der nachfolgenden Nutzlastdaten. Wenn die Daten das Muster "WW" gefolgt von irgendetwas enthalten, fügt das Verfahren unter der Verwendung der Nomenklatur des obigen Beispiels ein Emulationsverhinderungsbyte ein. Wenn der Codieren das Muster WW identifiziert, fügt er dementsprechend ein Emulationsverhinderungsbyte ein, um das folgende Muster zu erzeugen:
WWZ
Der Unterschied zwischen dem zuerst beschriebenen Verfahren und dem gerade vorgestellten Verfahren besteht darin, dass das erste Verfahren die ersten N + 1 Bytes anschaut, um sicherzustellen, wo ein Emulationsverhinderungsbyte eingefügt werden soll, wogegen das gerade vorgestellte Verfahren die ersten N Bytes anschaut.
Das erste Verfahren reduziert die Quantität der zu übertragenden zusätzlichen Daten, während das gerade vorgestellte Verfahren unter Verwendung einfacherer Regeln operiert. Daher bieten beide Verfahren zusammen eine Wahl zwischen der Reduzierung der übertragenen Datenquantität und der Reduzierung der Regelkomplexität. Mit dem zuerst beschriebenen Verfahren ist die Datenquantität im Vergleich zu der des als zweites beschriebenen Verfahrens reduziert. Mit dem als zweites beschriebenen Verfahren werden einfachere Regeln verwendet.
Um das Obige in einer programmatischeren Weise zu veranschaulichen, beachte man Folgendes. Um ein Paket P[] von B Bytes, das mit einem Startcode-Präfix beginnt, welches aus genau N Bytes desselben Wertes W und einem letzten Byte eines unterschiedlichen Wertes X besteht gefolgt von einem identifizierenden Startcode-Typ-Suffix von 1 Byte mit dem Wert Y, zu verschicken, betreiben wir den folgenden Pseudo-Code-Prozess, der Emu lationsverhinderungsbytes mit dem Wert Z einfügt (wobei W, X, Y und Z voneinander unterschiedliche Werte haben und P[B-1] nicht gleich W ist):
In dem obigen Pseudo-Code wird angenommen, dass eine Funktion "send_byte()" die Übertragung einer Dateneinheit betreibt (Prozess 108 in 1).
Um das Paket zu empfangen, nehme man an, dass der Decodieren auf der Decodieren-Seite das bekannte Startcode-Präfix, welches aus genau N Bytes desselben Wertes W und einem letzten Byte eines unterschiedlichen Wertes X besteht, bereits gefunden, gelesen und verworfen hat, und dass wir das unbekannte Single-Byte-Startcode-Typ-Suffix in einer Variablen Y lesen und das Paket der Nutzlastdaten in einen Bereich P[] lesen und die Menge der Nutzlastdaten bestimmen und die Mengenanzeige in einer Variable B plazieren möchten, während wir Emulationsverhinderungsbytes mit dem Wert Z entfernen (wobei W, X, Y und Z voneinander unterschiedliche Werte haben und P[B-1] nicht gleich W ist):
In dem obigen Pseudo-Code wird angenommen, dass eine Funktion "receive_byte()" den Empfang einer Dateneinheit betreibt, und es wird angenommen, dass eine Funktion "more_data()" bestimmt, ob es noch weitere Dateneinheiten zu empfangen gibt (diese zwei Funktionen umfassen Prozess 114 in 1).
Es wird davon ausgegangen, dass die oben beschriebenen Verfahren die Quantität einer großen Menge an idealen Nutzlastdaten zufälliger Eingabe um einen Faktor von ungefähr 1/256^N für das als zweites beschriebene Verfahren und 1/256^(N+1) für das zuerst beschriebene Verfahren erweitern werden. Diese Mengen sind klein, wenn N groß ist (z.B., 2 oder größer, wenn man bemerkt, dass N = 2 für MPEG-2-Startcodes). Es wird davon ausgegangen, dass der Erweiterungsfaktor für die Nutzlast im schlimmsten Fall 1/N für das als zweites beschriebene Verfahren beträgt und 1/(N + 1) für das zuerst beschriebene Verfahren. Wenn N vergrößert wird, wird der Nutzlasten-Erweiterungsfaktor sowohl in der statistischen Analyse als auch in der Analyse des schlimmsten Falles verkleinert, obwohl die Datenmenge, die von den Startcodes selber verwendet wird, erhöht wird.
Es sollte anerkannt werden, dass der oben beschriebene Emulationsverhinderungsprozess nicht von dem Wissen abhängt, wieviel Daten sich in dem Paket vor dem Start des Versendens befinden. Daher kommt keine signifikante Verzögerung hinzu.
Diese Formulierung des als zweites beschriebenen Verfahrens nimmt an, dass die eingefügten Emulationsverhinderungsbytes einzelne Bytes mit dem Wert Z sind. Es ist stattdessen möglich, jeden Wert oder multiple Werte oder eine oder mehrere Ketten von Werten für die Emulationsverhinderungsdaten zu verwenden, solange das erste Byte der eingefügten Daten nicht gleich W oder X ist, was einen gültigen Startcode nachbilden würde oder als Fortsetzung des Starts des Präfixes erscheinen würde.
Sogar Information kann in diese Emulationsverhinderungsbytes eingebracht werden (so wie z.B. eine GOB-Rahmen-ID-/Bildsequenznummer im H.263-Stil, oder es kann vielleicht nur die MSB auf "1" eingestellt werden und die anderen sieben Bits können dazu verwendet werden, einen ASCII-Buchstaben zu senden).
Wenn berücksichtigt wird, was am Ende des Pakets auf der Decodieren-Seite passiert, kann erkannt werden, dass es einfacher ist, die Operation zu steuern, wenn das letzte Byte der Datenpaketnutzlast nicht W ist. Dies bedeutet, dass das letzte vor einem Startcode gesendete Byte nie ein Emulationsverhinderungsbyte zu sein braucht und dass eine vom Decodieren erkennbare Grenze zwischen dem Ende der Nutzlastdaten und dem Start der Sequenz von Bytes gleich W für den nächsten Startcode lokalisiert werden kann. Wenn dies erzwungen wird, kann ermöglicht werden, jede Menge an W Bytes (z.B. Null-Bytes) nach dem Ende der Nutzlast und vor dem nächsten Startcode einzufüllen, ohne die Übersicht zu verlieren, wo sich das Ende der Nutzlast befindet.
Datenstopfen
Normalerweise brauchen bei Videodaten die Daten, die als Datennutzlast gesendet werden, keine ganzzahlige Anzahl von Bytes sein. Es können z.B. 627 Bits sein, die zwischen zwei Startcodes gesendet werden. Die Systemmultiplexebene kann jedoch in Bytes operieren. Dies ist der Fall bei der MPEG-2-Spezifikation. Andere Gründe, wie zum Beispiel das Ermöglichen der Entdeckung von irgendwelchen durch Übertragungsfehler erzeugten falschen Startcode-Mustern oder das Ermöglichen von einfachen Decodierungsprozessen für die Dateninhalte des Beginns der Nutzlast kann auch den Wunsch nach einem Paket rechtfertigen, welches eine ganzzahlige Anzahl an Dateneinheiten, wie zum Beispiel Bytes, enthält. Daher muss man unter Umständen ein bißchen mehr Daten senden, um die 627 Datenbits zu tragen. Die Frage stellt sich dann, wie man die Daten auffüllt, um eine ganzzahlige Anzahl an Bytes zu bekommen.
Es gibt andere Situationen, wo es nützlich wäre, einfach zusätzliche Fülldaten zu senden. Wenn ein Kanal zum Beispiel eine Kapazität von 1 Megabits hat und die Menge der zu sendenden Nutzlastdaten ist nur 900 Kbits/s, kann es einen Zwang oder Wunsch geben, den Kanal mit Fülldaten aufzufüllen.
In Übereinstimmung mit einer Ausführungsform ermöglicht die Datenstopftechnik das Hinzufügen von zusätzlichen Daten zum Kanal, um im Wesentlichen die Nutzlastdaten aufzufüllen.
2 ist ein Flußdiagramm, das Schritte in einem Datenstopfverfahren in Übereinstimmung mit einer Ausführungsform beschreibt, in welcher angenommen wird, dass die Startcodes mit einer Kette von Bits beginnen, die gleich Null sind. Schritt 200 richtet die Endstelle der Daten ein, die gesendet werden sollen. Schritt 202 fügt ein "1"-Bit nach dem letzten Bit der Nutzlastdaten ein. Schritt 204 bestimmt die Anzahl der zusätzlichen Bits, die notwendig sind, um eine ganzzahlige Anzahl an Bytes zu senden. Schritt 206 fügt die erforderliche Anzahl an "0"-Bits nach dem eingefügten "1"-Bit ein. Schritt 208 fügt jede erwünschte Anzahl an Fülldaten-Bytes ein. Die Fülldaten können aus jedem Datenmuster bestehen, das entworfen wurde, um Verwirrung über die Position der echten Nutzlastdaten und der absichtlichen Startcodes zu vermeiden. Dies wird typischerweise durch Einfügen von Bytes mit dem Wert "0" implementiert.
Als Beispiel ist Folgendes zu beachten. Angenommen, dass 627 Bits gesendet werden sollen. Hier würde Schritt 202 ein "1"-Bit nach dem 627ten Bit einfügen. Schritt 204 würde dann bestimmen, dass vier weitere Bits notwendig sind, um eine ganzzahlige Anzahl an Bytes bereitzustellen – hier 79 Bytes. Dementsprechend würde Schritt 206 vier "0"-Bits oder 0000 nach dem eingefügten "1"-Bit einfügen. Nachdem nun eine ganzzahlige Anzahl an Bytes erzeugt wurde, kann Schritt 208 nun, falls so gewünscht, jede gewünschte Anzahl an Fülldaten-Bytes hinzufügen. In diesem besonderen Beispiel können Bytes mit einem Wert von "0" eingefügt werden. Die Fülldaten können einfach als Fülldaten verwendet werden oder für irgendeinen anderen Zweck, wie zum Beispiel das Beinhalten von Information, die ein Decodierer für irgendeinen Zweck verwenden kann.
Nun wird die Situation am Decodieren betrachtet. Der Decodierer erhält die Stopfdaten und kann am Ende der Daten starten und die Daten rückwärts überprüfen. Alle Bytes, die der Decodierer zu Beginn sieht, werden die 0-Bytes sein, bis er zum Byte mit dem "1"-Bit kommt. Das "1"-Bit nennt dem Decodierer die Position des Endes der Nutzlastdaten oder echten Daten. Sobald der Decodieren das eingefügte "1"-Bit findet, kann er also genau bestimmen, wo die echten Daten enden.
Daher können die oben beschriebene Techniken dazu verwendet werden, die Anzahl an gesendeten Bits "aufzufüllen", so dass die Anzahl der gesendeten Bits eine ganzzahlige Anzahl an Dateneinheiten umfaßt. Darüber hinaus können diese Techniken dazu verwendet werden, Fülldaten zwischen die Startcodes, die den Beginn der Nutzlastdaten anzeigen, zu stopfen.
Beispielhafte Rechenumgebung
3 veranschaulicht ein Beispiel einer passenden Rechenumgebung 300, in welcher das oben beschriebene System und die damit verbundenen Verfahren implementiert werden können.
Es sollte anerkannt werden, dass die Rechenumgebung 300 nur ein Beispiel einer passenden Rechenumgebung ist und nicht irgendwelche Beschränkung des Anwendungsumfangs oder der Funktionalität des oben beschriebenen Codier-/Decodier-Systems bedeuten soll. Noch sollte die Rechenumgebung 300 so interpretiert werden, als gäbe es irgendeine Abhängigkeit oder Notwendigkeit in Verbindung zu irgendeiner Komponente oder einer Kombination von Komponenten, die in der beispielhaften Rechenumgebung 300 veranschaulicht werden.
Die verschiedenen beschriebenen Ausführungsformen können mit vielzähligen anderen Allzweck- oder Sonderzweck-Rechensystem-Umgebungen oder -Konfigurationen betrieben werden. Bespiele von gut bekannten Rechensystemen, -Umgebungen und/oder -Konfigurationen, die für die Verwendung mit dem Medienverarbeitungssystem passend wären, umfassen, sind aber nicht beschränkt auf PCs, Serverrechner, Thin Clients, Thick Clients, tragbare oder Laptop-Vorrichtungen, Multiprozessorsysteme, Mikroprozessor-basierte Systeme, Digitalempfänger, programmierbare Verbraucherelektronik, Network-PCs, Minicomputer, Großrechner, verteilte Rechenumgebungen, die irgendeines der obigen Systeme oder Vorrichtungen umfassen, und dergleichen.
In bestimmten Verwirklichungen können das System und die damit verbundenen Verfahren sehr wohl im allgemeinen Kontext von vom Computer ausführbaren Anweisungen beschrieben werden, so wie beispielsweise Programm-Module, die von einem Computer ausgeführt werden. Im Allgemeinen umfassen Programm-Module Routinen, Programme, Objekte, Komponenten, Datenstrukturen etc., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Ausführungen können auch in verteilten Rechenumgebungen praktiziert werden, wo die Aufgaben von Fernverarbeitungsvorrichtungen durchgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Rechenumgebung können sich Programm-Module in lokalen und Fernrechenspeichermedien befinden, inklusive Speichervorrichtungen. Komponenten des beschriebenen Rechensystems können verwendet werden, um einen Codierer oder einen Decodieren, die wie oben beschrieben funktionieren, zu implementieren.
In Übereinstimmung mit der veranschaulichten beispielhaften Ausführungsform von 3 wird das Rechensystem 300 gezeigt, welches einen oder mehr Prozessoren oder Verarbeitungseinheiten 302, einen Systemspeicher 304 und einen Bus 306 umfaßt, der verschiedene Systemkomponenten, darunter den Systemspeicher 304, mit dem Prozessor 302 koppelt.
Der Bus 306 soll eine oder mehrere von verschiedenen Typen von Busstrukturen darstellen, eingeschlossen einen Speicherbus oder Speichersteuerung, einen dezentralen Bus, einen beschleunigten Graphikanschluß, und einen Prozessor oder lokalen Bus unter Verwendung irgendeiner von einer Bandbreite an Busarchitekturen. Als Beispiel und nicht im Sinne einer Beschränkung umfassen solche Architekturen den Industrie-Standard-Architektur-Bus (Industn Standard Architecture Bus, ISA), den Mikro-Kanal-Architektur-Bus (Micro Channel Architecture Bus, MCA), den Erweiterten ISA-Bus (Enhanced ISA, EISA), den Video-Elektronik-Standard-Vereinigungs-Lokalbus (Video Electronics Standards Association local bus, VESA local bus) und den Dezentralen-Komponenten-Verbindungs-Bus (Peripheral Component Interconnects Bus, PCI), auch als Mezzanine-Bus bekannt.
Der Rechner 300 umfaßt typisch eine Vielzahl an vom Computer lesbaren Medien. Solche Medien können jedes zur Verfügung stehende Medium sein, das lokal oder entfernt für den Rechner 300 zugänglich ist, und umfaßt sowohl flüchtige als auch nicht flüchtige Medien, entfernbare und nicht entfernbare Medien.
In 3 umfaßt der Systemspeicher 304 vom Computer lesbare Medien in Form eines flüchtigen Speichers, wie beispielsweise eines Arbeitsspeichers (random access memon, RAM) 310 und/oder eines nicht flüchtigen Speichers, wie beispielsweise eines Nur-Lese-Speichers (read only memon, ROM) 308. Ein einfaches Eingabe/Ausgabe-System (BIOS) 312, das die grundlegenden Routinen enthält, welche bei der Übertragung von Information zwischen Elementen des Rechners 300 helfen, wie beispielsweise während des Herauffahrens, ist auf dem ROM 308 gespeichert. RAM 310 enthält typischerweise Daten und/oder Programm-Module, die unmittelbar zugänglich sind oder gegenwärtig von der/den Verarbeitungseinheiten 302 betrieben werden.
Der Rechner 300 kann darüber hinaus andere entfernbare/nicht entfernbare, flüchtige/nicht flüchtige Rechnerspeichermedien umfassen. Nur im Sinne eines Beispiels veranschaulicht 3 ein Festplattenlaufwerk 328, von dem gelesen und auf ein nicht entfernbares, nicht flüchtiges magnetisches Medium (nicht gezeigt und typischerweise "Festplatte" genannt) geschrieben werden kann, ein Magnetplattenlaufwerk 330, von dem gelesen und auf eine entfernbare, nicht flüchtige magnetische Platte 332 (z.B. eine "Floppy Disk") geschrieben werden kann, und ein Optoplattenlaufwerk 334, von dem gelesen oder auf eine entfernbare, nicht flüchtige optische Platte 336, wie einen CD-ROM, einen DVD-ROM oder andere optische Medien geschrieben werden kann. Das Festplattenlaufwerk 328, das Magnetplattenlaufwerk 330 und das Optoplattenlaufwerk 334 sind jeweils über eine oder mehrere Schnittstellen 326 mit dem Bus 306 verbunden.
Die Laufwerke und die mit ihnen assoziierten, vom Computer lesbaren Medien sorgen für nicht flüchtige Speicherung von vom Computer lesbare Anweisungen, Datenstrukturen, Programm-Modulen und andere Daten für Rechner 300. Obwohl die hier beschriebene beispielhafte Umgebung eine Festplatte 328, eine entfernbare magnetische Platte 332 und eine entfernbare optische Platte 336 anwendet, sollten die mit dem Stand der Technik vertrauten Personen zu schätzen wissen, dass andere Typen von vom Computer lesbaren Medien, die Daten speichern können, welche für einen Computer zugänglich sind, wie beispielsweise magnetische Kassetten, Flash-Speicherkarten, digitale Videoplatten, Arbeits speicher (RAMs), Nur-Lese-Speicher (ROM) und dergleichen, auch in der beispielhaften Betriebsumgebung verwendet werden können.
Eine Anzahl an Programm-Modulen kann auf der Festplatte 328, der magnetischen Platte 332, der optischen Platte 336, in dem ROM 308 oder in dem RAM 310 gespeichert werden, darunter im Sinne eines Beispiels und nicht im Sinne einer Beschränkung ein oder mehrere Anwendungsprogramme 316 (z.B. Multimedia-Anwendungsprogramm 324), andere Programm-Module 318 und Programmdaten 320. Ein Benutzer kann Befehle und Information in den Rechner 300 über Eingabevorrichtungen wie die Tastatur 338 und die Zeigevorrichtung 340 (wie beispielsweise eine "Maus") eingeben. Andere Eingabevorrichtungen können eine Audio/Video-Eingabe-Vorrichtung 353, ein Mikrofon, einen Joystick, ein Spielbrett, eine Satellitenschüssel, einen Serienanschluß, einen Scanner oder dergleichen (nicht gezeigt) umfassen. Diese und andere Eingabevorrichtungen sind mit der/den Verarbeitungseinheiten 302 über die Eingabe-Schnittstelle/n 342, die mit dem Bus 306 verknüpft ist, verbunden, können aber über andere Schnittstellen- und Bus-Strukturen, wie beispielsweise einen parallelen Anschluß, einen Spielanschluß oder einen universellen Serienbus (USB) verbunden sein.
Ein Monitor 356 oder ein anderer Typ von Anzeigevorrichtung ist auch mit dem Bus 306 über eine Schnittstelle verbunden, wie beispielsweise einen Videoadapter oder eine Video/Graphikkarte 344. Zusätzlich zum Monitor umfassen PCs typischerweise andere dezentrale Ausgabevorrichtungen (nicht gezeigt), so wie beispielsweise Lautsprecher und Drucker, die durch eine dezentrale Ausgabeschnittstelle 346 verbunden sein können.
Der Rechner 300 kann in einer Netzwerkumgebung operieren unter Verwendung logischer Verbindungen mit einem oder mehreren Fernrechnern, so wie beispielsweise ein Fernrechner 350. Der Fernrechner 350 kann viele oder alle der hier beschriebenen Elemente und Merkmale in Verbindung mit dem Rechner umfassen.
Wie in 3 gezeigt ist das Rechensystem 300 in kommunikativer Weise mit den Fernvorrichtungen (z.B. Fernrechner 350) durch ein lokales Netzwerk (local area network, LAN) 351 und ein allgemeines Fernnetz (wide area network, WAN) 352 verknüpft. Solche Netzwerk umgebungen sind Allgemeinplätze in Büros, unternehmensweiten Rechennetzwerken, Intranets und dem Internet.
Wenn der Rechner 300 in einer LAN-Netzwerkumgebung verwendet wird, ist er mit LAN 351 über eine passende Netzwerkschnittstelle oder -adapter 348 verbunden. Wenn der Rechner 300 in einer WAN-Netzwerkumgebung verwendet wird, umfaßt er typisch ein Modem 354 oder andere Mittel zur Einrichtung von Kommunikation über das WAN 352. Das Modem 354, das intern oder extern sein kann, kann mit dem Systembus 306 über die Benutzer-Eingabeschnittstelle 342 oder einen anderen angemessenen Mechanismus verbunden sein.
In einer Netzwerkumgebung können die abgebildeten Programm-Module in Verbindung mit dem PC 300 oder Teilen davon in einer Fernspeichervorrichtung gespeichert sein. Im Sinne eines Beispiels und nicht im Sinne einer Beschränkung veranschaulicht 3 Fernanwendungsprogramme 316, die auf einer Speichervorrichtung des Fernrechners 350 vorliegen. Es ist anzuerkennen, dass die gezeigten und beschriebenen Netzwerkverbindungen Beispiele darstellen und andere Einrichtungen zum Aufbau einer Kommunikationsverbindung zwischen den Rechner verwendet werden können.
Zusammenfassung
Einige der oben beschriebenen Verfahren und Systeme können auf einer anderen Verarbeitungsebene als der Bit-Ebene für Startcode-Emulationsverhinderung sorgen. Dies ist vorteilhaft, weil es die Verarbeitungskomplexitäten vereinfachen kann. Die in diesem Dokument beschriebenen Techniken können in jedem passenden Kontext verwendet werden, z.B. in Verbindung mit Nutzlast, die Inhalt enthält, der durch Codes mit variabler Länge, Huffman-Codes und arithmetische Codierung erzeugt ist. Darüber hinaus sorgen manche Ausführungsformen für ein geradliniges Verfahren zum Datenstopfen, das sicherstellen kann, dass auf Wunsch eine ganzzahlige Anzahl an Bytes gesendet wird, und dass das Versenden von zusätzlichen Fülldaten über die Daten für die Startcodes, Emulationsverhinderungsmuster und grundlegenden Nutzlastdaten hinaus ermöglicht.
Obwohl die Erfindung in einer Sprache beschrieben wurde, die spezifisch für strukturelle Merkmale und/oder methodologische Schritte ist, ist zu verstehen, dass die in den ange fügten Ansprüchen definierte Erfindung nicht notwendigerweise auf die beschriebenen spezifischen Merkmale oder Schritte begrenzt ist. Vielmehr werden die spezifischen Merkmale und Schritte als bevorzugte Formen der Implementierung der beanspruchten Erfindung offengelegt.

Claims

Verfahren in einem Decodierer, das umfasst: Empfangen von Daten (114) in einem Datenstrom, wobei die empfangenen Daten mehrere Start-Codes umfassen; Auffinden wenigstens eines Start-Codes (118) der mehreren Start-Codes in den empfangenen Daten; wobei das Verfahren gekennzeichnet ist durch: Suchen nach einem Muster einer ganzen Zahl von Bytes in den empfangenen Daten, wobei das Muster ein Start-Code-Emulations-Verhinderungsbyte (120) umfasst, das Start-Code-Emulation während des Auffindens des wenigstens einen Start-Codes (118) in den empfangenen Daten verhindert; und wenn das Muster in den empfangenen Daten gefunden ist, Aussondern des Start-Code-Emulations-Verhinderungsbytes (122) des Musters aus den empfangenen Daten.
Verfahren nach Anspruch 1, wobei der Datenstrom Videodaten umfasst.
Verfahren nach Anspruch 1, wobei der Datenstrom Audiodaten umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei das Muster wenigstens drei Bytes umfasst.
Verfahren nach Anspruch 4, wobei die wenigstens drei Bytes umfassen: wenigstens zwei Bytes, die jeweils gleich Null sind; und das Start-Code-Emulations-Verhinderungsbyte (120).
Verfahren nach einem der Ansprüche 1 bis 5, wobei das Start-Code-Emulations-Verhinderungsbyte (120) gleich 0 × 03 ist.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Auffinden des wenigstens einen Start-Codes (118) der mehreren Start-Codes in den empfangenen Daten Auffinden eines Start-Code-Präfixes umfasst.
Verfahren nach Anspruch 7, wobei das Auffinden des Start-Code-Präfixes Suchen nach einer Folge mehrerer aufeinander folgender Nullen in dem Datenstrom umfasst.
Verfahren nach Anspruch 7, wobei das Auffinden des Start-Code-Präfixes Suchen nach einer Folge mehrerer aufeinander folgender Nullen unmittelbar gefolgt von einer 1 in dem Datenstrom umfasst.
Verfahren nach Anspruch 8 oder 9, wobei die Folge mehrerer aufeinander folgender Nullen aus 31 Nullen besteht.
Verfahren in einem Codieren, das umfasst: Codieren eines Datenstroms unter Verwendung von Start-Codes und Start-Code-Emulations-Verhinderungsdaten, wobei das Verfahren gekennzeichnet ist durch: Suchen nach einem ersten Muster einer ganzen Zahl von Bytes (102) in Daten, die codiert werden, wobei das erste Muster wenigstens einen Teil eines Start-Code-Präfixes umfasst; und wenn das erste Muster in den Daten, die codiert werden, gefunden ist (104), Austauschen des ersten Musters gegen ein Austauschmuster in dem codierten Datenstrom, wobei das Austauschmuster Daten in dem ersten Muster zusammen mit einem Emulations-Verhinderungsbyte (106) zum Verhindern von Start-Code-Emulation umfasst, wobei das Austauschmuster eine ganze Zahl von Bytes aufweist.
Verfahren nach Anspruch 11, wobei der codierte Datenstrom Videodaten umfasst.
Verfahren nach Anspruch 11, wobei der codierte Datenstrom Audiodaten umfasst.
Verfahren nach einem der Ansprüche 11 bis 13, wobei das erste Muster wenigstens drei Bytes umfasst.
Verfahren nach Anspruch 14, wobei die wenigstens drei Bytes umfassen: wenigstens zwei Bytes, die jeweils gleich Null sind; und ein Byte, in dem jedes der sechs höchstwertigen Bits des Bytes Null ist.
Verfahren nach einem der Ansprüche 11 bis 15, wobei das Emulations-Verhinderungsbyte (106) gleich 0 × 03 ist.
Verfahren nach einem der Ansprüche 11 bis 16, wobei das erste Muster einen vollständigen Start-Code-Präfix umfasst.
Verfahren nach Anspruch 17, wobei der Start-Code-Präfix aus zwei Bytes besteht, die jeweils 0 × 00 sind und auf die unmittelbar ein Byte folgt, das gleich 0 × 01 ist.
Ein oder mehrere computerlesbare Medien, auf denen durch Computer ausführbare Befehle gespeichert sind, die einen Computer veranlassen, das Verfahren nach einem der Ansprüche 1 bis 18 durchzuführen.