DE69619221T2 - Verfahren und Vorrichtung zur Austausch von Stopfbits mit Zusatzdaten in einem MPEG-Videodatenstrom - Google Patents

Description

GEBIET DER ERFINDUNG
• Die vorliegende Erfindung bezieht sich im Allgemeinen auf die Daten-Speicherung und Übertragung unter Verwendung von MPEG Standards und insbesondere bezieht sich die vorliegende Erfindung auf die festgelegten Standards des Übertragens von "privaten Daten" und "Füll-Bytes" in' einem Transport-Daten-Strom, welcher mit den MPEG Standards übereinstimmt:
HINTERGRUND DER ERFINDUNG
• Hochauflösendes Fernsehen (HDTV) schreitet fort in den Bestrebungen herkömmliches Fernsehen zu ersetzen. Der Wegbereiter für diesen Fortschritt sind verschiedene Firmen und Verbände, welche an den Standards arbeiten, um einen globalen Markt für HDTV zur Verfügung zu stellen.
• Eine solche Gruppe von Firmen ist bekannt als die "Digital HDTV Grand Alliance" und umfasst Mitglieder wie zum Beispiel AT&T, David Sarnoff Research Center, Massachusetts Institute of Technology und andere. Eine umfassende Übersicht der Schritte, welche von diesen Gruppen durchgeführt wurden, wird dargestellt in einem Artikel von Robert Hopkins mit dem Titel "Digital Terrestrial HDTV for North America: The Grand Alliance HDTV System" veröffentlicht in den IEEE Transactions on Consumer Electronics (Sommer 1994). Dieser Artikel lehrt den Hintergrund und Grundlagen von HDTV Systemen einschließlich der Verwendung von Programm- und Transport-Paket-Strömen.
• Zusätzlich zu der Grand Alliance wurden viele Anstrengungen aufgewandt von der Moving Picture Expert Group (MPEG), einem Komitee innerhalb der International Standards Organization (ISO), in den Versuchen verschiedene Standards für die Speicherung und Übertragung von HDTV Daten (zum Beispiel MPEG-2 Standard-Formate für Transport-Paket-Ströme) festzulegen. Akzeptierte Standards werden periodisch veröffentlicht, wie zum Beispiel der Video Section of Information Technology - Generic Coding of Movirig Pictures and Associated Audio ISO/IEC 13818-2 (November 1994) (hiernach "Video-Abschnitt") und der Systems Section of Information Technology - Generic Coding of Moving Pictures and Associated Audio ISO/IEC 13818-1 (November 1994) (hiernach "System-Abschnitt"), wobei beide davon etablierte Standards und Formate einschließlich "Füll"-Techniken lehren.
• Die Syntax für den MPEG-2 Standard definiert mehrere Schichten von Daten- Aufzeichnungen, welche verwendet werden um beides zu transportieren; Audio- und Video- Daten. Aus Gründen der Vereinfachung wird die Dekodierung der Audio-Daten hierin nicht beschrieben. Kodierte Daten, welche eine bestimmte Videosequenz beschreiben, werden dargestellt in verschiedenen verschachtelten Schichten, die Sequenz-Schicht, die Gruppe-von- Bildern-Schicht, die Bilder-Schicht, die Teilstück(slice)-Schicht und die Makroblock-Schicht. Um bei der Übertragung dieser Information zu helfen, wird ein digitaler Datenstrom, welcher mehrere Videosequenzen darstellt, unterteilt in mehrere kleinere Einheiten und jede dieser Einheiten ist eingebettet bzw. eingekapselt in ein jeweiliges paketiertes bzw. in Paketform gebrachtes Elementar-Strom (PES)-Paket. Zur Übertragung wird jedes PES-Paket unterteilt, eines nach dem anderen, aus einer Mehrzahl von Transport-Paketen mit fester Länge. Jedes Transport-Paket enthält Daten, welche sich auf nur ein PES-Paket beziehen. Das Transport- Paket enthält auch einen Kopf bzw. Header, welcher eine Steuer-Information enthält; und manchmal ein Anpassungs-Feld enthält, welches beim Dekodieren des Transport-Paketes verwendet werden kann.
• Wenn ein MPEG-2 kodiertes Bild empfangen wird, dekodiert ein Transport-Dekoder die Transport-Pakete, um die PES-Pakete wieder zusammenzusetzen. Die PES-Pakete werden wiederum dekodiert, um den MPEG-2 Bit-Strom wieder zusammenzusetzen, welcher das Bild in den geschichteten Aufzeichnungen darstellt, wie oben beschrieben. Ein gegebener Transport-Daten-Strom kann gleichzeitig mehrere Bildsequenzen transportieren, zum Beispiel als verschachtelte Transport-Pakete. Diese Flexibilität ermöglicht es auch dem Sender zwischen Formaten zu schalten, welche Material zur Verfügung stellen, in einem 4 mal 3 Bildseiten- Verhältnis (aspect ratio) gemäß einem Standard und einem Breitschirm (16 mal 9) Material gemäß einem anderen Standard.
• Bei einer System-Implementation zum Liefern von HDTV unter Verwendung von MPEG-2 Standards für den Konsumenten werden im Allgemeinen, wie veranschaulicht in dem Block- Diagramm auf hoher Ebene von Fig. 1, auf der Sende-Seite, Video- und Audiosignale den jeweiligen Kodierern 110 und 112 eingegeben, in den Puffern 114 und 116 gepuffert, zu dem System-Kodierer/Multiplexer 118 geliefert, und in der Speicher-Einheit 120 gespeichert oder übertragen durch die Sende-Einheit 120. Auf der Empfangs-Seite werden die Signale empfangen von einem System-Dekoder/Demultiplexer 122, wieder gepuffert in den Puffern 124 und 126, dann dekodiert von den Dekodern 128 und 130 und ausgegeben als die ursprünglichen Video- und Audiosignale.
• Ein wichtiger Aspekt der Veranschaulichung von Fig. 1 liegt darin, dass obwohl die Zwischen-Stufen-Pufferung der Signale eine variable Verzögerung enthält, die Gesamt- Verzögerung von dem Eingang zu dem Ausgang der Signale im Wesentlichen konstant sein muss. Dies wird erreicht durch eine überwachte Ablauf-Steuerung und Puffer.
• Wie in Fig. 1 gezeigt, ist in diesem Modell die Verzögerung von der Eingabe zu dem Kodierer zu der Ausgabe oder Darstellung von dem Dekoder konstant, während die Verzögerung durch jeden der Kodier- und Dekoder-Puffer variabel ist. Nicht nur die Verzögerung durch jeden dieser Puffer ist variabel innerhalb des Weges von einem Elementar-Strom, sondern auch die einzelnen Puffer-Verzögerungen in den Video- und Audiowegen unterscheiden sich. Deshalb gibt die relative Stelle der kodierten Bits, welche Audio oder Video darstellen in dem kombinierten Strom, keine Synchronisations-Information an. Die relative Stelle des kodierten Audio und Video ist nur beschränkt durch ein System-Ziel-Dekoder (STD)-Modell, so dass die Dekoder-Puffer sich geeignet verhalten müssen; deshalb können kodierte Audio- und Videodaten, welche Ton und Bilder darstellen, welche gleichzeitig dargestellt werden sollen, zeitlich innerhalb des kodierten Bit-Systems um soviel wie eine Sekunde getrennt sein, was die maximale Dekoder-Puffer-Verzögerung ist, welche in dem STD-Modell erlaubt ist. Ähnlich wie das STD-Modell ist ein Video-Puffer-Prüfer (VBV), welcher wie in dem Video- Abschnitt festgelegt:
• Mit konstanter Rate kodierte Video-Bit-Ströme sollen die Bedingungen erfüllen, welche auferlegt werden durch einen Video-Puffer-Prüfer (VBV), wie in diesem Abschnitt definiert....
• Der VBV ist ein hypothetischer Dekoder, welcher konzeptionell mit der Ausgabe eines Kodierers verbunden ist.... Kodierte Daten werden entnommen aus dem Puffer wie unten definiert. Es ist erforderlich, dass ein Bit-Strom, welcher mit dieser Spezifikation übereinstimmt, nicht bewirken soll, dass der VBV überläuft. Wenn low_delay gleich 0, soll der Bit-Strom nicht bewirken, dass der VBV unterläuft...
• Eine Veranschaulichung eines beispielhaften STD-Modells auf oberer Ebene, welches arbeitet in Verbindung mit einem Kodierer, ist in Fig. 2 gezeigt:
• Das Erfordernis, dass der VBV-Puffer oder die STD-Modell Dekoder nicht unterlaufen, ist sehr wichtig, weil die Produktqualität auf dem Spiel steht. Um ein Video mit konstanter Bit- Rate aufrechtzuerhalten, wird ein "Füllen" (Stuffing) implementiert innerhalb verschiedener Aspekte des Systems: Das "Füllen" ist der Vorgang des Auffüllens eines Daten-Stromes mit "nicht beachten" (don't care) Information, einfach um die benötigte Bit-Rate zu halten.
• Für Transport-Strom-Pakete, welche PES-Pakete transportieren, wird das Auffüllen verwendet, wenn es nicht ausreichend PES-Paket-Daten gibt, um die Transport-Strom Paket- Nutzinformation-Bytes bis zu einem Pegel zu füllen, welcher die übertragene Daten-Rate unterstützen würde.
• Das Füllen kann zum Beispiel durchgeführt durch Definieren eines Anpassungs-Feldes, welches länger ist als die Summe der Längen der Daten-Elemente in diesem, so dass die Nutzinformation-Bytes überbleiben nachdem das Anpassungs-Feld exakt die verfügbaren PES- Paket-Daten aufnimmt. Der übriggebliebene bzw. Extra-Raum in dem Anpassungs-Feld und/oder Nutzinformation kann mit Füll-Bytes gefüllt werden:
• Fig. 3 zeigt das Format und die Feld-Stellen für einen Transport-Paket-Strom, bei welchem jedes Transport-Paket einen Kopf bzw. Header und eine Nutzinformation (payload) enthält.
• Der Header eines Transport-Pakets enthält Felder zum Anzeigen der Existenz und zum Steuern der Länge und des Inhalts eines Anpassungs-Feldes. Innerhalb dieses Anpassungs-Feldes ist ein anderes Feld bezeichnet als "Füll-Bytes". Füll-Bytes werden ähnlich verwendet in der Nutzinformation der Transport-Pakete.
• Wie oben erwähnt ist jedoch die Verwendung von Füll-Bytes, welche gewöhnlich alle logische 1-Werte aufweisen (d. h. "11111111 ") in dem Transport-Header und älle logische 0- Werte (d. h. "00000000") in der Transport-Nutzinformation aufweisen, eine Verschwendung von System-Resourcen (zum Beispiel Übertragungs-Bandbreite). Entsprechend wäre es wünschenswert effizienteren Gebrauch von den System-Resourcen zu machen, welche bis jetzt auf "Auffüllen" beschränkt waren.
ZUSAMMENFASSUNG DER ERFINDUNG
• Die vorliegende Erfindung richtet sich in einem System umfassend Video-Daten mit variablen Bit-Raten in der Form von Daten-Paketen, welches Füll-Bytes verwendet, um einen Daten-Strom zu füllen, auf ein Verfahren, wie in Anspruch 7 definiert und ein System, wie in Anspruch 1 definiert, zum Entfernen der Füll-Bytes und zum Verwenden der zusätzlichen Bandbreite, um private Daten (hiernach "Privat-Füll-Daten" bzw. "privatestuff data") zu übertragen. Die Erfindung umfasst eine Untersuchungs-Vorrichtung zum Untersuchen eines Daten-Pakets, welches eine Angabe enthält, ob Füll-Bytes verwendet werden in dem Daten- Paket und zum Bestimmen, ob das Daten-Paket auswählbar ist, gemäß einem vorgegebenen Kriterium; um die Füll-Bytes zu entfernen; und eine Re- bzw. Wieder-Multiplex-Vorrichtung, in Reaktion auf die Untersuchungs-Vorrichtung, zum Entfernender Füll-Bytes aus dem Daten-Paket und zum Hinzufügen von vorgegebenen Privat-Füll-Daten zu dem Daten-Paket.
• Gemäß einem Aspekt der Erfindung werden die Füll-Bytes von einem Header-Teil des Daten- Pakets entfernt, um eine zusätzliche Übertragungs-Bandbreite zu erzielen:
• Gemäß einem anderen Aspekt der vorliegenden Erfindung werden die Füll-Bytes entfernt aus einem Nutzinformation-Teil des Daten-Pakets, um eine zusätzliche Übertragungs-Bandbreite zu erhalten: Bei beiden Aspekten werden jedoch die Privat-Füll(privatestuff)-Daten in den Header-Teil des Daten-Pakets eingefügt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
• Die Erfindung wird am besten verstanden aus der folgenden ausführlichen Beschreibung, wenn diese in Verbindung mit den beiliegenden Zeichnungen gelesen wird, wobei:
• Fig. 1 (Stand der Technik) ein Block-Diagramm auf oberer Ebene eines beispielhaften digitalen Mehrprogramm Übertragungs- und Empfangssystems zeigt.
• Fig. 2 (Stand der Technik) ein Block-Diagramm einer beispielhaften Implementation eines STD-Modells mit Teilen des in Fig. 1 gezeigten System auf oberer Ebene zeigt.
• Fig. 3 (Stand der Technik) ein beispielhaftes Format zeigt, einschließlich Feld- Bezeichnungen, für einen Transport-Paket-Strom, welcher verwendet wird in Verbindung mit dem in den Fig. 1 und 2 gezeigten System.
• Fig. 4A zeigt ein Ablauf-Diagramm auf oberer Ebene und veranschaulicht die beispielhaften Schritte, welche ausgeführt werden von der vorliegenden Erfindung, um allgemein Füll-Bytes durch Privat-Füll-Daten zu ersetzen.
• Fig. 4B zeigt ein Ablauf-Diagramm auf oberer Ebene und veranschaulicht die beispielhaften Schritte, welche ausgeführt werden durch die vorliegende. Erfindung, um Füll-Bytes in dem Anpassungs-Feld durch Privat-Füll-Daten zu ersetzen.
• Fig. 5 zeigt ein Ablauf-Diagramm und veranschaulicht die beispielhaften Schritte, welche ausgeführt werden durch die vorliegende Erfindung, um Füll-Bytes in der Paket- Nutzinformation durch Privat-Füll-Daten zu ersetzen.
• Fig. 6 zeigt ein Ablauf-Diagramm und veranschaulicht eine beispielhafte Start-Kode- Verarbeitungs-Technik, welche zur Verwendung mit der in Fig. 5 gezeigten Ausführungsform geeignet ist.
• Fig. 7 zeigt ein Ablauf-Diagramm und veranschaulicht eine beispielhafte Füll-Bytes-Such- Technik, welche zur Verwendung mit der in Fig. 5 gezeigten Ausführungsform geeignet ist.
• Fig. 8A bis 8C veranschaulichen drei Beispiele der Füll-Byte-Ersetzungen, wie von den in den Fig. 5 bis 7 veranschaulichten Techniken ausgeführt.
• Fig. 9 zeigt ein funktionales Block-Diagramm einer oberer Ebene einer beispielhaften Ausführungsform eines Kodierers, welcher zur Verwendung mit der vorliegenden Erfindung geeignet ist.
AUSFÜHRLICHE BESCHREIBUNG
• Wie in dem Abschnitt "Hintergrund der Erfindung" erwähnt, wird für Transport-Strom- Pakete, welche PES-Pakete transportieren, Auffüllen verwendet, wenn es nicht ausreichend PES-Paket-Daten gibt, um die Transport-Strom-Paket Nutzinformation-Bytes aufzufüllen, um die festgelegte Daten-Rate zu unterstützen. Eine Art, in der das Auffüllen bewirkt werden kann, ist das Definieren eines Anpassungs-Feldes, welches länger ist als die Summe der Längen der Daten-Elemente in diesem, so dass die Nutzinformation-Bytes übrig bleiben nachdem das Anpassungs-Feld exakt die verfügbaren PES-Paket-Daten aufnimmt. Der zusätzliche Raum in dem Anpassungs-Feld wird mit den Füll-Bytes gefüllt. Eine andere Art, mit welcher das Auffüllen bewirkt werden kann, ist durch das Auffüllen von nicht verwendeten Teilen der Transport-Nutzinformation durch Nullen.
• Die vorliegende Erfindung, welche allgemein anwendbar ist bei Video mit variabler Bit-Rate, nutzt vorteilhaft die sonst verschwendeten Resourcen, welche für das "Füllen" reserviert sind, um private Daten einzufügen. In der beispielhaften Ausführungsform der vorliegenden Erfindung werden nützliche private Daten in den Transport-Strom eingefügt, anstelle der Füll-Bits, um diese sonst verschwendeten Resourcen vorteilhaft zu nutzen. Das heißt effektiv ein Wieder-Multiplex-Vorgang tritt auf, wo basierend auf dem Vorliegen von bestimmten vorgegebenen Bedingungen in den Feldern des Transport-Stromes (zum Beispiel liegen Füll-Bytes vor) die Information, welche erforderlich ist, um Füll-Bytes zu ersetzen durch private Daten, mit dem Standard übereinstimmend, erzeugt wird und geeignet eingefügt wird.
• Es sollte festgehalten werden, dass obwohl die vorliegende Erfindung so beschrieben wird, dass sie allgemein anwendbar ist bei einem Video mit variabler Bit-Rate, diese im Wesentlichen auch anwendbar ist bei Video mit konstanter Bit-Rate. Das heißt, dass obwohl in der vorliegenden Erfindung das modifizierte Video immer ein Video mit variabler Bit-Rate sein wird, das ursprüngliche Video, welches bearbeitet und übertragen werden soll, entweder ein Video mit konstanter oder variabler Bit-Rate ist.
• Die Daten, welche verwendet werden, um die Füll-Bytes zu ersetzen, werden im Allgemeinen bezeichnet als "Privat-Füll"(privatestuff)-Daten, um diese von gewöhnlichen privaten Daten zu unterscheiden, welche sonst kodiert sein können in einem Transport-Strom.
• Wenn Privat-Füll-Daten eingefügt werden in den Transport-Strom, wenn erforderlich, können diese gesendet werden mit einem individuellen Programm-Identifikations(PID)-Kode, welcher anzeigt, dass das vorliegende Transport-Paket Privat-Füll-Daten enthält. Wie in dem System-Abschnitt beschrieben, ist eine PID ein 13-Bit Feld in einem Transport-Strom- Header, welches die Art der Daten angibt, welche in der Paket-Nutzinformation gespeichert sind. Einige PID-Werte sind zugeordnet und einige sind reserviert. In der beispielhaften Ausführungsform der vorliegenden Erfindung können neu zugeordnete PID-Werte bezeichnet werden, um anzugeben, dass die privaten Daten, welche enthalten sind in dem bestimmten Transport-Paket, tatsächliche Privat-Füll-Daten sind, und nicht normale private Daten. Wenn eine neu zugeordnete PID verwendet wird, kann das Dekodieren der Privat-Füll-Daten leichter bei dem Empfangs-Ende sein:
• Es sollte auch angemerkt werden, dass zusätzlich zu den Füll-Bytes einige Transport-Pakete ausgewiesene NULL-Pakete sind unter Verwendung einer speziellen NULL PID. Unter Verwendung der hierin beschriebenen Technik könnte die vorliegende Erfindung auch vorteilhaft die verschwendeten Resourcen eines NULL-Paketes nutzen durch das Wieder-Multiplexen des Pakets, um Privat-Füll-Daten und alle anderen geeigneten Felder (zum Beispiel Anpassungs- und Privat-Daten-Felder) zu enthalten.
• Zusätzlich werden die Privat-Füll-Daten nur auf einer "bursty" Basis gesendet, d. h. nur wenn der Video-Kanal Füll-Bytes zu senden "wünscht", weil die Füll-Bytes nur, auf der Basis "wenn benötig" verwendet werden. Beispiele einer Information, welche gesendet werden kann als Privat-Füll-Daten, umfassen Programm-Übersichten, Programm-Inhaltsangaben, etc. für Programme, welche zu einem späteren Zeitpunkt übertragen werden sollen.
• Als zusätzlicher Hintergrund ist in dem System-Abschnitt eine Syntax-Darstellung vorgesehen zum Kodieren/Dekodieren des Anpassungs-Feldes eines Transport-Headers. Diese Syntax ist wieder dargestellt nachfolgend in Tabelle I. Tabelle I - Transport-Strom-Anpassungs-Feld Tabelle I (Fortsetzung)
• Wie in Tabelle I gezeigt, werden Füll-Bytes in dem Transport-Header in dem Anpassungs- Feld angeordnet, wenn benötigt.
• Bezugnehmend auf die Syntax ist die Anpassungs_Feld_Länge (Adaptation Field Length), aufgelistet in Tabelle I und veranschaulicht in Fig. 3, ein 8 Bit Feld, welches die Anzahl der Bytes in dem Adaptation_Field spezifiert unmittelbar folgend auf die Adaptation_Field_Length. Zum Beispiel wird in der beispielhaften Ausführungsform der Wert 0 verwendet zum Einfügen eines einzelnen Füll-Bytes in ein Transport-Strom-Paket.
• Des Weiteren sollte der Wert der Adaptation_Field_Length in dem Bereich von 0 bis 182 sein, wenn der Anpassungs_Feld_Steuerung(Adaptation_Field_Control) Wert gleich "11" ist. Wenn der Adaptation_Field_Control Wert gleich "10" ist, sollte der Wert der Adaptation_Field_Length gleich 183 sein.
• Ein Stuffing_Byte, für das Anpassungs(adaptation)-Feld, ist ein festgelegter 8 Bit Wert, gewöhnlich gleich "1111 1111", welcher durch den Kodierer eingefügt werden kann. Sobald als Füll-Bits identifiziert, wird diese "nicht beachten" (don't care) Information verworfen bei dem Empfangs-Ende von dem Dekoder.
• Fortfahrend mit Tabelle I sind zusätzlich zu den Füll-Bytes in der Syntax des Standards für das Anpassungs-Feld private Daten vorgesehen. Zum Beispiel, wie in Fig. 3 gezeigt, werden die zwei Felder unmittelbar vor dem Füll-Byte-Feld bezeichnet mit "5 flags" und "optionale Felder". Das "5 flags" Feld bezeichnet, ob die optionalen Felder vorliegen und; wenn dies so ist, bezeichnen die optionalen Felder die Existenz und Länge von "Transport-Privat-Daten". Das gleiche Verhältnis der Felder ist auch dargestellt im syntaktischen Format von Tabelle I.
• Zusätzlich zu den Füll-Bytes, verwendet in dem Anpassungs-Feld des Transport-Header, wie erwähnt, können Füll-Bytes auch in der Transport-Nutzinformation verwendet werden. In der vorliegenden Erfindung können Füll-Bytes von entweder dem Anpassungs-Feld oder der Transport-Nutzinformation entfernt werden, um eine zusätzliche Bandbreite für Privat-Füll- Daten zur Verfügung zu stellen. Es sollte jedoch angemerkt werden, dass die Privat-Füll- Daten, welche zu dem Paket hinzugefügt werden, in der beispielhaften Ausführungsform der vorliegenden Erfindung nur zu einem Anpassungs-Feld in dem Transport-Header hinzugefügt werden, ob Füll-Bytes entfernt werden von entweder dem Anpassungs-Feld, oder der Transport-Nutzinformation oder beiden.
• Fig. 4A zeigt ein Ablauf-Diagramm einer oberen Ebene und veranschaulicht beispielhafte Schritte, welche ausgeführt werden für das allgemeine Durchführen bzw. Abschließen der Entfernung eines Füll-Bytes und einen Ersetzungs-Vorgang, auch bekannt als ein Re- bzw. Wieder-Multiplex-Vorgang. Dieses Ablauf-Diagramm soll allgemein das Ersetzen eines Füll- Bytes in entweder dem Anpassungs-Feld oder der Transport-Nutzinformation veranschaulichen.
• Wie in Fig. 4A gezeigt, wird zuerst, bei Schritt 402 ein Transport-Paket aus dem Transport- Strom erfasst und dann, bei Schritt 404, wird das Paket untersucht. Die Untersuchung enthält das Bestimmen, ob Füll-Bytes vorliegen, Schritt 405, und wenn dem so ist, wo und wieviele Schritt 407. Dann tritt unter Verwendung der Information, welche erhalten wurde während der Untersuchung, bei Schritt 408, ein Re- bzw. Wieder-Multiplex-Vorgang auf. Das heißt die Füll-Bytes werden ersetzt durch Privat-Füll-Daten. Zusätzliche Details für die obigen Schritte werden nachfolgend vorgesehen unter Bezugnahme auf die Fig. 4B, 5 bis 7 und 8A bis 8C.
• Fig. 4B zeigt ein Ablauf-Diagramm einer oberen Ebene und veranschaulicht die beispielhaften Schritte, ausgeführt durch die vorliegende Erfindung, um Füll-Bytes in dem Anpassungs-Feld durch Privat-Füll-Daten zu ersetzen. Wie in Fig. 4B gezeigt, wird zuerst, bei Schritt 410, ein Transport-Paket aus dem Transport-Strom erfasst und dann, bei Schritt 412, wird das Paket untersucht. Die Untersuchung enthält anfangs die Bestimmung, ob ein Anpasungs-Feld vorliegt, Schritt 414. Dies kann durch die Untersuchung von verschiedenen Feldern durchgeführt werden. Als nächstes, wenn es ein Anpassungs-Feld gibt, dann wird bestimmt; ob private Daten indem Anpassungs-Feld vorliegen, Schritt 416. In der beispielhaften Ausführungsform kann dies durchgeführt werden durch die Untersuchung des "5 flags" Feldes und des "transport private data length" Feldes. Wenn private Daten vorliegen, endet das Verfahren, weil dieses Anpassungs-Feld, in der beispielhaften Ausführungsform der vorliegenden Erfindung, nicht für private Füll-Daten verwendet wird. Es sollte jedoch angemerkt, werden, dass obwohl es möglich ist Privat-Füll-Daten einzufügen, wenn schon private Daten vorliegen, die vorliegende Erfindung absichtlich wählt nicht ein Anpassungs-Feld zu unterbrechen bzw. zu stören, welches schon private Daten enthält.
• Fortfahrend mit dem Ablauf-Diagramm von Fig. 4B wird die Stelle und Anzahl der Füll- Bytes bestimmt, wenn private Daten nicht vorliegen, bei Schritt 418, unter Verwendung der Information von den verschiedenen Feldern, und bei Schritt 420 tritt ein Wieder-Multiplex- Vorgang auf.
• Jetzt, fortschreitend zu dem Wieder-Multiplex-Vorgang, ist es wichtig sich zu erinnern, dass jede Modifikation des Anpassungs-Feldes etablierte Standards einhalten sollte (d. h. die Formate, welche in Fig. 3 gezeigt sind und die Syntax, welche in Tabelle I aufgelistet ist). Deshalb, wenn Füll-Bytes in einem Anpassungs-Feld ersetzt werden sollen durch Priva -Füll- Daten, werden nicht nur die Privat-Füll-Daten gemultiplext in den Daten-Strom, sondern alle geeigneten Bits in den geeigneten Feldern werden entsprechend gesetzt. Zum Beispiel wenn in einem bestimmten Anpassungs-Feld keine optionalen Felder vorlagen bei der anfänglichen Untersuchung, wird das "5 flags" Feld modifiziert, um wiederzuspiegeln, dass nach dem Wieder-Multiplex-Vorgang die optionalen Felder existieren. Des Weiteren wird die Anzahl der Privat-Füll-Bytes hinzugefügt zu dem "transport private data length" Feld, um die Modifikation des Anpassungs-Feldes geeignet anzuzeigen.
• Bei Kenntnis der etablierten Standards, wie zum Beispiel denjenigen, welche hierin durch in Bezugnahme aufgenommen wurden, wird ein Fachmann die verschiedenen Kombinationen der Felder erkennen, welche vorliegen können, wenn versucht wird, die Füll-Bytes durch Privat-Füll-Daten zu ersetzen, wobei er versteht, dass alle erforderlichen Felder modifiziert werden müssten, während des Wieder-Multiplex-Vorganges, um den aktualisierten Inhalt des Anpassungs-Feldes wiederzuspiegeln.
• Ungeachtet der Fähigkeiten eines Fachmanns zeigen beispielhaft die Fig. 5 bis 7 und 8A bis 8C Ablauf-Diagramme und Feld-Ersetzungs-Diagramme, welche detailliert die Schritte zeigen,welche erforderlich sind, um Füll-Bytes zu erkennen und zu entfernen aus einer einzelnen Transport-Nutzinformation und die folgende Extra-Bandbreite zu nutzen, um die Privat-Füll-Daten in einem Anpassungs-Feld bei der Transport-Schicht zu übertragen. Es sollte angemerkt werden, dass das Verfahren, wie in den Fig. 5 bis 7 und 8A bis 8C veranschaulicht,
• 1) die minimal benötigte Anzahl von Video-Füll-Bytes innerhalb eines Transport-Pakets findet, basierend auf der Struktur des Anpassungs-Feldes (oben beschrieben),
• 2) die Positionen von Video-Füll-Bytes innerhalb einer Transport-Nutzinformation lokalisiert und diese Bytes aus der Nutzinformation entfernt,
• 3) private Daten bei dem Anpassungs-Feld einfügt, und
• 4) eine Bild-Header-Struktur lokalisiert und seinen VBV_DELAY Wert durch 0xFFFF ersetzt.
• Es sollte weiter festgehalten werden, dass das in den Fig. 5 bis 7 und 8A bis 8C veranschaulichte Verfahren annimmt, dass
• 1) die Programm-Zuordnungs-Tabelle (PAT) und die Programm-Abbildungs-Tabelle (PMT) verarbeitet wurden und die PID für den als Ziel gesetzten Video-Elementar- Strom erkannt wurde und
• 2) die Syntax-Analyse (Parsing) der Nutzinformation der Transport-Nutzinformation, welche den Video-Elementar-Strom enthält, bei oder vor dem allerersten Video- Sequenz-Header beginnt und bei dem Sequenz-End-Kode endet.
• Bezugnehmend auf die Fig. 5 bis 7 untersuchen die veranschaulichten Verfahren viele Felder innerhalb des Transports-Header und der Nutzinformation, sowie das Verfolgen bzw. Nachführen von einigen Feld-Größen. Für diesen Zweck werden Variablen durch das Verfahren hindurch verwendet. Insbesondere zeigen die Variabel-Legenden, welche unterhalb für jede der Fig. 5, 6 und 7 vorgesehen sind, die bestimmten Variablen, welche für dieses Ablauf-Diagramm verwendet werden und ihre entsprechenden Definitionen:
In Fig. 5 verwendete Variablen
• Cnt_V_ZB = Zähler von Video-Null-Bytes
• StrtCd_Fnd = Flag, um das Auffinden eines Start-Kodes anzuzeigen
• PictStrtCd_Fnd = Flag, um das Auffinden eines Bild-Start-Kodes anzuzeigen
• MIN_V_SB = minimale Anzahl der Video-Füll-Bytes, welche indem TP Paket vorliegen müssen
• Cnt_V_SB = Zähler der Video-Füll-Bytes
• Cnt_Pyld_B = Zähler der TP Nutzinformation-Bytes
In Fig. 6 verwendete Variablen
• PictStrtCd_Fnd = Flag, um ein Auffinden eines Bild-Start-Kodes anzuzeigen
• StrtCd_Fnd = Flag, um ein Auffinden eines Start-Kodes anzuzeigen
• Cnt_Pict_Hdr = Zähler von Bytes in einer Bild-Header-Struktur
In Fig. 7 verwendete Variablen
• Cnt_Pyld_B = Zähler der TP Nutzinformation-Bytes
• Cnt_V_SB = Zähler der Video-Füll-Bytes
• Cnt_V_ZB = Zähler der Video-Null-Bytes
• Cnt_Cur_SB = Zähler der aktuellen Video-Füll-Bytes
• StrtCd_Fnd = Flag, um ein Auffinden eines Start-Kodes anzuzeigen
• Bezugnehmend auf Fig. 5 werden bei den Schritten 510 bis 514 die Variablen "Cnt_V_ZB", "StrtCd_Fnd" und "PctStrtCd_Fnd", welche während der Verarbeitung verwendet werden, initialisiert. Bei den Schritten 516 und 518 wird eine Vor-Verarbeitung durchgeführt, um das nächste Synchronisations(sync)-Byte zu erkennen und zu verifizieren; dass die PID für ein elementares Video-Programm ist.
• Bei den Schritten 520, 522 und 524 untersucht das Verfahren die Anpassungs-Feld-Steuerung und Länge-Felder und, in Abhängigkeit von den Ergebnissen der Untersuchung, legt eine Variable fest, welche die minimale Anzahl der Füll-Bytes bezeichnet, welche in dem Transport- Paket vorliegen müssen, Schritte 526 und 528.
• Als nächstes wird bei Schritt 530 bestimmt, ob es irgendwelche privaten Daten in diesem Anpassungs-Feld gibt. Und wiederum, basierend auf dieser Bestimmung legt das Verfahren eine Variable fest, welche die minimale Anzahl der Füll-Bytes angibt, welche in dem TP Paket vorliegen müssen, Schritt 532. Hier, wie erwähnt, wenn bestimmt wird, dass private Daten schon in dem Anpassungs-Feld vorliegen, dann endet das Verfahren und beginnt ein neues.
• Das Verfahren von Fig. 5, bei Schritt 536, springt dann zu dem ersten Byte der Nutzinformation, während bei Schritt 538 die Variablen "Cnt_V_SB" und "Cnt_Pyld_B" initialisiert werden.
• Jetzt entspricht Schritt 540 einschließlich seiner Verweise (links) auf die Ablauf-Diagramme von Fig. 6 und 7 im Wesentlichen Schritt 404 in Fig. 4A. Es ist hier, dass die Anzahl und Stelle der Füll-Bytes bestimmt wird. Das Ablauf-Diagramm von Fig. 6 erkennt und verfolgt Start-Kodes in der Nutzinformation, während das Ablauf-Diagramm von Fig. 7 Füll-Bytes erkennt und zählt. Das Verfolgen bzw. Nachfolgen (tracking) wo und wieviele Bytes von jedem vorliegen, ermöglicht es dem Verfahren, die Füll-Bytes zu entfernen (wodurch eine zusätzliche Bandbreite für Privat-Füll-Daten zur Verfügung gestellt wird) und bewahrt die Bild- Daten. Bei Schritt 541 wird Cnt_V_SB überprüft, um sicherzustellen, dass sie größer ist als MIN_V_SB. Der Zweck von Schritt 541 liegt darin sicherzustellen, dass die Anzahl der gefundenen Füll-Bytes in diesem Transport-Paket größer ist als die minimale Anzahl der Füll- Bytes, welche vorliegen müssen, um mit dem Wieder-Multiplexen zu folgen.
• Abschließend werden bei den Schritten 542 und 544 (welche im Allgemeinen dem Schritt 408 von Fig. 4A entsprechen) die Füll-Bytes entfernt und das Wieder-Multiplexen der Privat- Füll-Daten, zusammen mit geeigneten Steuer-Feld-Modifikationen, tritt jeweils auf. Dieser Wieder-Multiplex-Vorgang wird weiter veranschaulicht wie bei Schritt 544 gezeigt, anhand eines Beispiels in den Fig. 8A, 8B und 8C.
• Bezugnehmend auf Fig. 6 zählt das Verfahren, welches das Format der Start-Kodes kennt, verwendet von den aussagefähigen Daten (zum Beispiel Bild-Daten) in der Nutzinformation eines Transport-Pakets, die Füll-Bits in der Paket-Nutzinformation bis auf einen Start-Kode getroffen wird. Eine Syntax für die verschiedenen Start-Kodes wird dargestellt in dem Video- Abschnitt. Diese Verarbeitung stellt sicher, dass keine aussagekräftigen bzw. bedeutsamen Bild-Daten, welche von der Transport-Paket-Nutzinformation transportiert werden, gestört, werden.
• Wie in den Schritten 610 und 612 gesehen, fährt das Verfahren in Fig. 6 fort, die Transport- Nutzinformation mit einem Byte zu einem Zeitpunkt zu erkennen und zu verarbeiten, solange entweder das PictStrtCd_Fnd oder das StrtCd_Fnd gleich "1" ist, bis die Bedingung vorliegt, wo beide, das PictStrtCd_Fnd und das StrtCd_Fnd gleich "0" sind. Wenn diese Bedingung erkannt wird, geht das Verfahren zu den Schritten über, welche in Fig. 7 veranschaulicht sind, welches versucht die Füll-Bytes zu verfolgen (track) und zu identifizieren.
• Bis dann, wenn PictStrtCd_Fnd gleich "1" ist, dann werden die nachfolgenden Bild-Header- Bytes verfolgt (tracked) und verarbeitet, Schritte 614, 616, 618, 620, 622, 624, 626 und 628, bis PictStrtCd_Fnd endgültig zurückgesetzt ist bei Schritt 630. Und wenn PictStrtCd_Fnd gleich "0" ist, aber StrtCd_Fnd gleich "1" ist, dann wird das aktuelle Byte der Daten verarbeitet, Schritte 632, 634, 636 und 638, so dass entweder das PictStrtCd_Fnd gesetzt ist bzw. wird, Schritt 634, oder das StrtCd_Fnd zurückgesetzt ist, Schritt 638.
• Es sollte angemerkt werden, dass die Zustände der Variablen PictStrtCd_Fnd und StrtCd_Fnd eine Bedingung wiederspiegeln können, welche verarbeitet und bestimmt wurde in einer vorherigen Transport-Nutzinformation. Das heißt, dass Bild-Daten oder Füll-Bytes mehr als eine Transport-Nutzinformation überlappen können, deshalb, wenn die vorherige Transport- Nutzinformation mit einem Start-Kode endete, sollte die Verarbeitung für die vorliegende Transport-Nutzinformation dieses berücksichtigen, weil Transport-Pakete einfach Teile eines größeren PES-Paketes sind. Zum Beispiel kann, wenn drei aufeinander folgende Transport- Pakete betrachtet werden, das Füllen beginnen in der Mitte durch die Nutzinformation des ersten Paketes, fortfahren für die gesamte Nutzinformation des zweiten Paketes und in der Mitte des dritten Paketes enden. Diese Art einer Bedingung soll berücksichtigt werden während des Erkennens und Entfernens des Füll-Bytes.
• Bezugnehmend auf Fig. 7 sucht das Verfahren nach Füll-Bytes, überprüft sorgfältig den Wert von allen Bytes und verfolgt die Stelle von verschiedenen Punkten, welche verwendet werden, um die Füll-Bytes zu identifizieren und nachfolgend zu entfernen. Kurz zusammengefasst verarbeiten und zählen die Schritte 710 und 712 die Null-Bytes, welche aufeinander treffen. Eventuell wird das zu verarbeitende Byte nicht "0x00" sein; entsprechend dem NEIN- Ausgangs-Weg von Schritt 710, und wird wahrscheinlich "0x01" sein, was angibt, dass ein Start-Kode gefunden wurde, entsprechend dem JA-Ausgangs-Weg von Schritt 716. Bei diesem Punkt wird die StrtCd_Fnd Variable, welche in Fig. 6 verwendet wird, gesetzt, Schritt 718, und die Füll-Byte-Zählung stoppt. Die tatsächliche Anzahl der Füll-Bytes wird bestimmt durch Subtrahieren von 2 von der Cnt_V_ZB, Schritt 720, weil der Start-Kode 23 logische Nullen und eine logische Eins enthält. Jedoch überprüft Schritt 716 nur bezüglich sieben logischen Nullen und einer logischen Eins, deshalb werden 16 weitere logische Nullen (oder zwei Bytes mit "0x0000") nicht als Füll-Bytes angesehen.
• Folglich, wenn die Anzahl der Füll-Bytes, Cnt_Cur_SB kleiner ist als die Nutzinformation- Byte-Zählung, Schritt 722 und nicht gleich Null ist, Schritt 724, wird die Stelle und Menge der Füll-Bytes berechnet und aufgezeichnet unter Verwendung der Variablen, wie zum Beispiel Cnt_Pyld_B und Cnt_V_ZB, welche verwendet wurden, um wichtige Punkte in der Nutzinformations-Verarbeitung zu zählen und zu markieren. Es sollte auch angemerkt werden, dass die Anzahl der Füll-Bytes, welche berechnet wurde unter Verwendung dieser Verarbeitung, dann hinzugefügt wird, bei Schritt 728, zu der Anzahl der Füll-Bytes, welche vorher aufgezeichnet wurden.
• Eine zusätzliche Diskussion der Fig. 6 und 7 ist nicht gerechtfertigt, weil ein Fachmann mit der Beschreibung hierin einschließlich der Fig. 5 bis 7 und 8A bis 8C, sowie dem Wissen von etablierten Standards vor ihm einschließlich derjenigen, welche hierin aufgenommen sind, die in den Fig. 6 bis 7 veranschaulichten Prozesse verstehen kann.
• Die Fig. 8A bis 8C zeigen Beispiele von Transport-Paketen vor und nachdem sie verarbeitet wurden durch die vorliegende Erfindung, beschrieben in den Fig. 5 bis 7. Insbesondere zeigt Fig. 8A Feld-Ersetzungs-Diagramme (d. h. original und verarbeitet) für ein Transport-Paket, welches im Original bzw. ursprünglich kein Anpassungs-Feld hatte. Dies entspricht dem JA-Weg, welcher von Schritt 520 in Fig. 5 ausgeht. Wie in Fig. 8A gezeigt werden die Füll-Bytes der Transport-Paket-Nutzinformation entfernt, ein Anpassungs-Feld, mit den geeigneten Feldern, was erforderlich, um einen Transport-Header anzuzeigen, welcher private Daten trägt, wird erzeugt und das Paket wird so rekonstruiert, dass die Nutzinformation nicht länger Füll-Bytes enthält. Wie in der Legende unterhalb der Darstellung des verarbeiteten Transport-Paketes gezeigt, werden viele der Werte, welche angeordnet werden in den neu ausgebildeten Feldern (zum Beispiel Anpassungs-Feld-Länge) erhalten von dem Zustand der Variablen, welche verwendet werden während der Verarbeitung in den Fig. 5 bis 7 (zum Beispiel Cnt_V_SB).
• Fig. 8B veranschaulicht den Fall wenn das Transport-Paket ein Anpassungs-Feld enthält, aber die Länge des Anpassungs-Feldes 0 Bytes betrug. Dies entspricht dem JA-Weg, welcher von den Schritten 522 und 524 von Fig. 5 ausgeht. Wiederum werden die Füll-Bytes von der Transport-Nutzinformation entfernt und die geeigneten Anpassungs-Felder werden erzeugt und/oder modifiziert in Abhängigkeit von dem Wert einer Variable.
• Fig. 8C veranschaulicht jetzt ein anderes Beispiel, bei welchem ein Anpassungs-Feld vorlag und die Anpassungs-Feld-Länge nicht gleich Null ist und es keine privaten Daten gibt. Dies entspricht dem NEIN-Weg, welcher von Schritt 530 von Fig. 5 ausgeht. Wiederum tritt ein ähnliches Entfernen von Füll-Bytes und eine Modifikation des Anpassungs-Feldes auf.
• Fig. 9 zeigt ein Block-Diagramm einer beispielhaften Ausführungsform eines Prozessors für private Füll-Daten, geeignet zur Verwendung mit der vorliegenden Erfindung. In Fig. 9 wird der Transport-Strom in dem Puffer 910 gehalten, sowie von einem Analysator 912 überwacht. Der Analysator 912 führt viel der Verarbeitung entsprechend den Schritten 402 bis 404 von Fig. 4A und den Schritten 410 bis 418 von Fig. 4B durch, einschließlich der Schritte in den Fig. 5 bis 7 außer Schritt 544 für die Nutzinformations-Verarbeitung. Als nächstes weist der Analysator 912 den Re-Multiplexer 914 an, ob ein Re-Multiplexing-Vorgang durchgeführt werden soll oder nicht und mit welcher Information. Der Re-Multiplexer 914 führt die Verarbeitung entsprechend den Schritten 408, 420 und 544 durch. Wiederum wird der Transport-Strom, zur Verfügung gestellt von dem Puffer 910, temporär von dem Puffer 916 verzögert. Die Puffer 910 und 916 werden im Allgemeinen verwendet, um die Verarbeitungs- Verzögerungen des Analysators 912 bzw. des Re-Multiplexers 914 zu kompensieren. Die Steuerung 918 führt einen gemischten Steuer-Vorgang durch, einschließlich der Steuerung des Daten-Flusses durch die Puffer und dem letztendlichen Entscheiden ob das Transport- Paket durch den Multiplexer 920 geführt wird, oder ob die verarbeitete Ausgabe des Re- Multiplexers 916 hindurchgeführt wird.
• Es sollte angemerkt werden, dass obwohl nur das allgemeine Ablauf-Diagramm zur Verarbeitung der Füll-Bytes in einem Anpassungs-Feld zur Verfügung gestellt ist (Fig. 4B), kann ein Fachmann unter Verwendung der Information, welche zur Verfügung gestellt wird und bekannt ist, leicht die Füll-Bytes von dem Anpassungs-Feld erkennen und entfernen und Felder in dem Anpassungs-Feld erzeugen oder modifizieren. Zum Beispiel würde ein Feld- Ersetzungs-Diagramm für diesen Fall sehr ähnlich wie Fig. 8C erscheinen, außer dass das ursprüngliche bzw. original Transport-Paket Füll-Bytes enthalten würde vor der TP Nutzinformation und das verarbeitete Transport-Paket würde neue private Daten enthalten (zum Beispiel private Füll-Daten in der geeigneten Stelle für private Daten) und keine Füll-Bytes in dem Anpassungs-Feld. Des Weiteren stellen die Feld-Stellen, welche in Tabelle I beschrieben wurden und veranschaulicht sind in Fig. 3, die Details zur Verfügung, welche erforderlich sind, um die Füll-Bytes zu erkennen und zu entfernen von dem Anpassungs-Feld.
• Obwohl die Erfindung hierin veranschaulicht und beschrieben wurde als Ausführungsform bei einem Verfahren und einer Vorrichtung zum Ersetzen von Füll-Bytes durch private Füll- Daten in einem MPEG kodierten Daten-Strom, ist es nicht beabsichtigt, dass die Erfindung auf die gezeigten Details beschränkt wird.

Claims (12)

1. Vorrichtung zum Ersetzen von Füll(stuffing)-Bytes durch privat- bzw. benutzerdefinierte (privatestuff) Daten zur Verwendung in einem System, welches Videodaten mit einer konstanten Bit-Rate und Videodaten mit einer variablen Bit-Rate in der Gestalt von Daten-Paketen umfasst, welche Füll-Bytes verwendet, um einen Datenstrom aufzufüllen, wobei die Vorrichtung aufweist:

eine Vorrichtung zum Analysieren (912) eines Daten-Pakets, um zu bestimmen, ob Füll-Bytes in dem Daten-Paket verwendet werden; und

eine Re-Multiplex-Vorrichtung (914), welche auf das Bestimmungsergebnis der Analysier-Vorrichtung (912) anspricht, zum Entfernen der Füll-Bytes von dem Daten-Paket und zum Hinzufügen von vorgegebenen Privat-Daten zu dem Daten-Paket.

2. Vorrichtung nach Anspruch 1, wobei die Analysier-Vorrichtung (912) gemäß einem vorgegebenen Kriterium, bestimmt, ob das Daten-Paket wählbar bzw. geeignet ist, um die Füll-Bytes entfernen zu können.

3. Vorrichtung nach einem der Ansprüche 1 oder 2, wobei das Daten-Paket einen Header- Teil und einen Nutz(payload)-Teil umfasst und Füll-Bytes in dem Header-Teil angeordnet sind.

4. Vorrichtung nach einem der Ansprüche 1 oder 2, wobei das Daten-Paket einen Header- Teil und einen Nutz-Teil umfasst und Füll-Bytes in dem Nutz-Teil angeordnet sind.

5. Vorrichtung nach Anspruch 2, wobei das Daten-Paket einen Header-Teil und einen Nutz-Teil aufweist, wobei das Daten-Paket weiter eine Anzeige umfasst ob Privat- Daten von dem Header-Teil des Daten-Pakets befördert bzw. getragen werden, wobei das Vorgegebene Kriterium ist, dass keine Privaten-Daten von dem Header-Teil des Daten-Pakets getragen bzw. befördert werden.

6. Vorrichtung nach einem der Ansprüche 1, 2 und 5, wobei das Daten-Paket einen Header-Teil und einen Nutz-Teil umfasst und die Privat-Daten werden in ein Adaptierungs- bzw. Anpassungs-Feld in dem Header-Teil eingefügt.

7. Verfahren zum Entfernen von Füll-Bytes aus einem Daten-Paket, um eine zusätzliche Bandbreite zu erzeugen und um die zusätzliche Bandbreite zu verwenden, um Privat- Daten zu übertragen zur Verwendung in einem System umfassend Videodaten mit einer konstanten Bit-Rate und Videodaten mit einer variablen Bit-Rate in der Form von Daten-Paketen, welche Füll-Bytes verwendet, um einen Datenstrom zu füllen, wobei das Verfahren aufweist:

Analysieren eines Daten-Pakets um zu bestimmen ob Füll-Bytes in dem Daten-Paket verwendet werden;

in Abhängigkeit von dem Bestimmungsergebnis des Analysierungs-Schrittes, Entfernen der Füll-Bytes von dem Daten-Paket, um eine zusätzliche Übertragungs-Bandbreite zu erzeugen; und

Hinzufügen von vorgegebenen Privat-Daten zudem Daten-Paket, wodurch die zusätzliche Übertragungs-Bandbreite verwendet wird.

8. Verfahren nach Anspruch 7 umfassend die Bestimmung ob das Daten-Paket geeignet bzw. auswählbar ist, in Abhängigkeit von einem vorgegebenen Kriterium, um die Füll- Bytes zu entfernen.

9. Verfahren nach einem der Ansprüche 7 und 8, wobei das Daten-Paket einen Header- Teil und einen Nutz-Teil umfasst, und die Füll-Bytes werden von dem Header-Teil entfernt.

10. Verfahren nach einem der Ansprüche 7 und 8, wobei das Daten-Paket einen Header- Teil und einen Nutz-Teil umfasst, und die Füll-Bytes werden von dem Nutz-Teil entfernt.

11. Verfahren nach Anspruch 8, wobei das Daten-Paket einen Header-Teil und einen Nutz- Teil umfasst, wobei da Daten-Paket weiter eine Anzeige aufweist, ob Privat-Daten von dem Header-Teil des Daten-Pakets getragen bzw. befördert werden, wobei das vorgegebene Kriterium ist, dass keine Privat-Daten von dem Header-Teil des Daten-Pakets getragen bzw. befördert werden.

12. Verfahren nach einem der Ansprüche 7 oder 8 und 11, wobei das Daten-Paket einen Header-Teil umfassend ein Adaptierungs- bzw. Anpassungs-Feld und einen Nutz-Teil aufweist, wobei die Privat-Daten durch Einfügen in das Adaptierungs-Feld hinzugefügt werden.