DE60008016T2

DE60008016T2 - Mpeg-4 videospezifisches kontrollpaket zur lieferung von personalisierten kodierungswerkzeugen

Info

Publication number: DE60008016T2
Application number: DE60008016T
Authority: DE
Inventors: Xuemin Chen; Ajay Luthra
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 1999-11-12
Filing date: 2000-10-31
Publication date: 2004-09-16
Anticipated expiration: 2020-11-01
Also published as: CN1409929A; KR20020064899A; CA2391196A1; TW513892B; EP1230802B1; AU1247701A; DE60008016D1; WO2001037573A1; EP1230802A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein Steuerpaketformat für eine Streaming-Videocodierung, wie beispielsweise die MPEG-4 Video-Codierung. Die Erfindung ist besonders nützlich für die Entwicklung von Streaming-Videoprodukten zum Einzelsenden von Video über Internetprotokoll(IP)-Netze, wie beispielsweise das Internet.
MPEG-4 Visual, durch die Moving Picture Experts Group in ISO/IEC 14496-2, Information technology, Generic coding of audio-visual objects, Part 2: Visual, October, 1998 näher beschrieben, ist ein Multimediastandard, der Codierung von sowohl natürlichen als auch synthetischen Audio- und Video-Objekten, eine multiplexierte Darstellung vieler derartiger simultaner Objekte sowie die Beschreibung und Dynamik einer Szene, die diese Objekte enthält, näher beschreibt. MPEG-4 ist für die Bitraten, die von 10 Kbit/s bis 10 Mbit/s reichen, effektiv. Die durch die International Telecommunications Union (ITU-T) ausgeführte Arbeit für den Standard, der als H.263+ bezeichnet wird, ist für MPEG-4 relevant, da H.263+ eine Erweiterung von H.263 ist, und H.263 war auch einer der Anfangspunkte für MPEG-4. MPEG-4 ist jedoch ein vollständigerer Standard, da er einen sehr breiten Bereich und Art von Anwendungen, umfangreiche Systemunterstützung und Werkzeuge für die Codierung und Integration von natürlichen und sythetischen Objekten addressieren kann. MPEG-4 fügte zahlreiche Codierwerkzeuge hinzu, um mehr Funktionalität bereitzustellen und um die Codierer-/Decodiererleistung (Codec-Leistung) gegenüben H.263 zu verbessern. Die Vollständigkeit des MPEG-4 Videos macht es jedoch auch schwierig, einen "vollständigen" Decodierer zu konstruieren, da es kostenaufwendig und kompliziert sein würde, einen Decodierer zu konstruieren, der alle möglichen Codierwerkzeuge bewältigen könnte.
Zudem wird erwartet, dass ein breiter Bereich von Anwendungen um MPEG-4 entwickelt werden wird. Diese Anwendungen werden verschiedene Untergruppen der in MPEG-4 vorhandenen Codierwerkzeuge verwenden. Die Beschreibung der Internationalen Normenorganisation ISO/SC29/WG-11 addressiert dieses Problem, indem Profile erstellt werden, wie es für MPEG-2 gemacht wurde. In MPEG-4 ist der erwartete Bereich von Anwendungen jedoch bedeutend breiter als der für MPEG-2. Dieses erzwingt die Erstellung einer großen Anzahl von Profilen. Um die Anzahl von Profilen zu reduzieren, werden die Erfordernisse der potentiell überlappenden Anwendungen zusammen gemischt, um sie in einer kleineren Anzahl von Profilen zu verbinden. Dies erstellt jedoch Profile, die für eine große Anzahl von Anwendungen nicht effektiv sind. Zudem wird sich, trotz des vorher erwähnten Versuchs, der Druck einer zunehmenden Anzahl von Anwendungen fortsetzen, um die Anzahl der erforderlichen Profile zu erhöhen.
Zusätzlich kann MPEG-4 Video auf eine breite Vielfalt von Diensten über das Internet, einschließlich Echtzeit-Video-Streaming, Videoabruf, Sammelsenden, Einzelsenden und dergleichen angewendet werden. Die in MPEG-4 Video grob festgelegten Profile können jedoch die Anforderungen dieser Anwendungen nicht erfüllen, z. B. auf Grund der großen Anzahl möglicher Arten von Netzen. Das heißt, dass für eine spezielle Netzanwendung festgelegte Codierwerkzeuge nicht unbedingt für andere Anwendungen geeignet sind.
EP-A-0 762 777 offenbart eine Bild produzierende Vorrichtung, die codierte Bilddaten und einen Algorithmus zum Wiedergeben (Decodieren) der codierten Bilddaten sendet und einen Decodierprozessor entsprechend des empfangenen Algorithmus neu konfiguriert.
EP-A-0 917 369 offenbare einen Sender zum Senden von verschlüsselten Videodaten und Audiodaten, der auch ein Decodierverfahren, das durch Erzeugungsmittel des Decodierverfahrens erzeugt wird, sendet.
EP-A-0 577 377 offenbart ein Bildverarbeitungsverfahren, das einen Eingabeschritt zum Eingeben einer Bildinformation, einen Bestimmungsschritt zum Bestimmen einer Eigenschaft der Bildinformation, einen Auswahlschritt zum Auswählen eines Kompressionsvorgangs, der für die Eigenschaft der durch den Bestimmungsschritt bestimmten Information geeignet ist, einen Kompressionsschritt zum Komprimieren der Bildinformation durch die Kompressionsvorgänge, die durch den Auswahlschritt ausgewählt wird, und einen Ausgabeschritt zum Ausgeben der Bildinformation, die durch den Kompressionsschritt komprimiert wird, beinhaltet.
Demgemäß würde es wünschenswert sein, ein System bereitzustellen, um Codierwerkzeuge für die nicht durch ein spezifisches Profil abgedeckten Anwendungen festzulegen.
Das System sollte festlegen, welche Codierwerkzeuge für eine bestimmte Echtzeit-Video-Streaminganwendung über ein spezielles Netz verwendet werden. Die Technik sollte Decodierer, die die Videodaten (z. B. an einem Personal-Computer, einer Fernseh-Set-Top-Box, einem Kabelmodem oder dergleichen) empfangen, darüber informieren, welche Codierwerkzeuge verwendet wurden.
Die Codierwerkzeuge sollten für einen nicht profilierten Bitstrom (wenn kein konventionelles Profil verwendet wird) festgelegt sein. Zum Beispiel können einige nicht profilierte Bitströme für einige Netzanwendungen bessere Leistung hinsichtlich der Codierleistung gegenüber der Codec(Codierer/Decodierer)-Komplexität bereitstellen.
Das System sollte die Verwendung eines kundenspezifischen Codierwerkzeugsatzes ermöglichen, das keinem vorbestimmten Codierprofil entspricht.
Das System sollte ein Steuerpaket, das schon ausgebaut ist, nutzen, und vermeiden, eine Erfordernis einer zusätzlichen Verbindung herzustellen.
Das System sollte mit einem Transportprotokoll für Echtzeitanwendungen, wie beispielsweise dem Echtzeit-Transportprotokoll (RTP), das in "RTP: A transport protocol for real-time applications," RFC 1889, Januar 1996, definiert ist, kompatibel sein.
Das Echtzeit-Transportprotokoll (RTP) wurde als ein flexibles Protokoll entwickelt, das Echtzeitdaten über Sammelsenden oder Einzelsenden transportieren kann. Dieses Protokoll wurde weitläufig eingesetzt und weitreichend zum Senden von Echtzeit-(oder fast Echtzeit-) Multimediaströmen verwendet. RTP addressiert keine Reservierung von Betriebsmitteln und garantiert nicht die Qualität des Dienstes für den Echtzeit-Dienst. Der Datentransport wird durch ein Steuerprotokoll (RTCP) vergrößert, um das Überwachen der Datenlieferung auf eine Weise zu ermöglichen, die für große Netze für Sammelsendungen skalierbar ist, und um minimale Steuerung und Kennungsfunktionalität bereitzustellen.
RTP ist ein Internetstandard-Trackprotokoll, das Ende-zu-Ende-Lieferungsdienste für Daten mit Echtzeiteigenschaften, wie beispielsweise interaktives Audio und Video, bereitstellt. Diese Dienste umfassen Kennung des Nutzlasttyps, Sequenznummerierung, das Zuschreiben von Daten und Uhrzeit (Time Stamping) und die Lieferungsüberwachung.
RTP ist hauptsächlich entwickelt, um die Anforderungen von Multimediakonferenzen mit mehreren Teilnehmern zu erfüllen und kann auch für die Speicherung der kontinuierlichen Daten, interaktiv verteilte Simulation, den elektronischen Ausweis (Logo) und Steuer- und Messanwendungen nützlich sein.
Das RTP-Steuerprotokoll (RTCP) wird verwendet, um die Qualität des Dinstes zu überwachen und Informationen über die Teilnehmer in einer laufenden Sitzung zu übermitteln.
Das RTP wurde jedoch vorher nicht verwendet, um einen Mechanismus zum Ermitteln von Codierwerkzeugen für Streaming-Videoanwendungen bereitzustellen.
Die vorliegende Erfindung stellt ein System mit den obigen und weiteren Vorteilen bereit.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein Steuerpaketformat für Streaming-Videocodierung.
Gemäß Anspruch 1 ist ein Verfahren, um mindestens einem Decodierer zu signalisieren, Codierwerkzeuge, die zum Verschlüsseln eines Videostroms verwendet werden, zu erkennen, bereitgestellt.
Gemäß dem unabhängigen Anspruch 12, ist ein Decodierverfahren zum Erkennen von Codierwerkzeugen, die zum Verschlüsseln eines Videostroms verwendet werden, bereitgestellt.
Gemäß Anspruch 23 ist eine Vorrichtung, um einem Decodierer zu signalisieren, Codierwerkzeuge, die zum Verschlüsseln eines Videostroms verwendet werden, zu erkennen, bereitgestellt.
Gemäß Anspruch 24, ist eine Decodiervorrichtung zum Erkennen von Codierwerkzeugen, die zum Verschlüsseln eines Videostroms verwendet werden, bereitgestellt.
Die vorliegende Erfindung sieht über die MPEG-2-Betrachtungsweise hinaus und geht auf das Originalempfinden und Betrachtungsweise der Flexibilität bei MPEG-4 zurück. Es wird erwartet, dass, wenn sie entwickelt sind, MPEG-4 Decodierer (und entsprechende Codierer) flexibel und daher von unterschiedlicher Leistung sein werden. Das Konzept der graduellen Verschlechterung des digitalen Signals und die Tatsache, dass das Modell aller Empfänger nicht das gleiche ist, wird annehmbar sein und wird die veraltete Bedeutung der Interoperabilität verändern.
Deshalb schlägt die vorliegende Erfindung die Erstellung eines Mechanismus vor, um eine Signalübertragung oder einen Quittungsaustausch zwischen dem Sender und den Empfängern zu ermöglichen, so dass ein Sender die Empfänger darüber informieren kann, welche Werkzeuge er in MPEG-4 verwendet, um ein gegebenes Videosignal zu verschlüsseln. Um die Flexibilität des MPEG-4 Videos für verschiedene Anwendungen sicherzustellen, schlägt die Erfindung ein MPEG-4 Video spezifisches Steuerpaket für die Konfiguration der MPEG-4 Videocodierwerkzeuge vor. Dieses Paket kann zusammen mit dem Videostrom gesendet werden. Als Beispiel wird die Aufmerksamkeit auf ein Echtzeit-Protokoll (RTP) gelenkt. Ein ähnliches Ziel kann für verschiedene Systemschichten, z. B. ein MPEG-2-System über Deskriptoren, erreicht werden.
Insbesondere kann ein Codierwerkzeugpaket einen Codierstatus eines Videostroms in Bezug auf eins oder mehr des Folgenden ermitteln: ob Skalierbarkeit verwendet wird, und, wenn ja, welche Art; ob 8-Bit-Codierung verwendet wird; ob Alpha-Plane-Codierung verwendet wird, und, wenn ja, welche Art; ob fehlerstabile Codierwerkzeuge verwendet werden und, wenn ja, welche Art; ob verschachteltes Codieren verwendet wird; ob Sprite-Codierung verwendet wird und, wenn ja, welche Art; ob B-VOP-Codierung verwendet wird und, wenn ja, ob Direktmdus-Codierung verwendet wird; ob interne Gleichstrom- und/oder Wechselstrom-Prädiktion verwendet wird und, wenn ja, welche Art; ob erweiterte Prädiktion verwendet wird und, wenn ja, welche Art; ob Viertelpixel-Codierung verwendet wird; ob globale Bewegungskompensation verwendet wird; und ob formadaptives DCT verwendet wird.
Die Erfindung ermöglicht deshalb die Verwendung eines kundenspezifischen Codierwerkzeugsatzes, der keinem vorbestimmten, starren Codierprofil entspricht.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein Codierwerkzeug-Configuration-Map(CTCM)-Paket dar, das die erforderlichen Werkzeuge zum Decodieren eines Video-Bitstroms gemäß der Erfindung anzeigt.
2 stellt ein MPEG-4 Video-CTCM-Nutzlastformat gemäß der Erfindung dar.
3 stellt das Übertragen von Videopaketen und CTCM-Paketen von einem Codierer an einen Decodierer gemäß der Erfindung dar.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein Steuerpaketformat für Streaming-Videocodierung.
I. Optionale MPEG-4 videospezifische Steuerpakete
Obwohl MPEG-4 Video auf eine breite Vielfalt von Diensten über das Internet, einschließlich Echtzeit-Video-Streaming, Videoabruf, Sammelsenden, Einzelsenden und dergleichen angewendet werden kann, können die in MPEG-4 Video grob beschriebenen Profile die Anforderungen dieser Anwendungen, z. B. auf Grund der großen Anzahl möglicher Arten von Netzen, nicht erfüllen.
Die Erfindung behandelt dieses Problem, indem ein Codierwerkzeug-Configuration-Map zusammen mit den codierten Videopaketen an die Benutzer gesendet wird, um einen kundenspezifischen Codierwerkzeugsatz, der keinem vorbestimmten Profil entsprechen muss, bereitzustellen. Eine Art, dies zu erreichen, ist das Senden eines derartigen Configuration-Maps als ein MPEG-4 videospezifisches RTCP-Steuerpaket. RTCP ist eine sinnvolle Stelle, an der ein derartiges Steuerpaket verwendet werden kann, da es schon ausgebaut ist und keine zusätzliche Verbindung hergestellt werden muss. Die Konfiguration wird auch immer am Anfang der Übertragung oder auf eine weniger häufige Art und Weise ausgebaut und daher ist das RTCP-Intervall (z. B. wie durch RFC 1889 oben genauer festgelegt) sehr gut für dieses MPEG-4 videospezifische RTCP-Steuerpaket geeignet. Das RTCP-Intervall ist die Zeit zwischen der Übertragung der Komponenten-RTCP-Pakete. Typischerweise werden mehrere RTCP-Pakete zusammen als ein Komponenten-RTCP-Paket in einem Einzelpaket des zu Grunde liegenden Protokolls gesendet; dies wird durch das Längenfeld in dem festgelegten Anfangsblock jedes RTCP-Pakets ermöglicht.
Der folgende Abschnitt beschreibt ein MPEG-4 videospezifisches RTCP-Steuerpaket, das das "Codierwerkzeug-Configuration-Map"(CTCM)-Paket genannt wird. Der Zweck des CTCM-Pakets ist es, den MPEG-4 Video-Decodierer darüber zu informieren, welche Codierwerkzeuge die Pakete eines Video-Objekt-Schicht(VOL)-Bitstroms umfassen. Die Unterstützung dieses MPEG-4 videospezifischen Steuerpakets durch den MPEG-4 Sender ist optional. Insbesondere sollte dieses Paket nicht für die profilierten MPEG-4 VOL-Bitströme verwendet werden. In einem derartigen Fall muss der Video-Decodierer der durch den MPEG-4 Visual bereitgestellten Profil-Definition entsprechen. Diese Konfigurationsdaten könnten auch in anderen ähnlichen Protokollen wie beispielsweise in einem Session Description Protocol (SDP), einem Session Announcement Protocol (SAP) oder einem Echtzeit-Streaming-Protokoll (RTSP) etc. gesendet werden.
II. Codierwerkzeug-Configuration-Map(CTCM)-Paket
1 stellt ein Codierwerkzeug-Configuration-Map(CTCM)-Paket dar, das auf die erforderlichen Werkzeuge zum Decodieren eines Video-Bitstroms gemäß der Erfindung hinweist.
Wie in der Legende 105 erklärt, umfasst das CTCM-Paket 100 ein RTP-Versionsfeld 110, ein Füllfeld 120, ein Profilindikatorfeld 130, ein Nutzlasttypfeld 140, ein Längenfeld 150, ein SSRC-Feld 160 und ein Nutzlastfeld 170.
Eine Skala, die die Anzahl Bits für jedes Feld anzeigt, ist in 102 gezeigt. Die Bitzuweisung für jedes Feld ist lediglich als ein Beispiel gezeigt, da verschiedene Zuweisungen verwendet werden können.
Dieses Paket 100 zeigt die erforderlichen Werkzeuge zum Decodieren des Video-Bitstroms für einen nicht profilierten Bitstrom (PI=0) an.
Die Felder V, P, Länge und SSRC sind in der RTP-Beschreibung, RFC 1889 definiert.
Insbesondere gilt:
(1) Version (V): 2 Bits. Dieses Feld erkennt die Version des RTP.
(2) Auffüllung (P): 1 Bit. Wenn das Füllbit gesetzt ist, enthält das Paket eine oder mehrere zusätzliche Fülloktetts an dem Ende, das nicht Teil der Nutzlast ist.
(3) Der Profil-Indikator (PI) ist als 5 Bits in der Länge dargestellt, obwohl andere Implementierungen möglich sind. Ein Profil ist ein Satz Werkzeuge, die für eine spezifische Anwendung spezifiziert sind. Der PI erkennt das Profil eines MPEG-4 Video-Bitstroms wie folgt:

0: Nicht profilierter Strom
1: Kurzer Anfangsblock-Strom
2: Einfaches Profil
3: Kernprofil
4: Hauptprofil
5: Erweitertes einfaches Echtzeitprofil
6: Erweitertes effektives Codier-Profil
7–63: reserviert

Nur vorhandene Profile werden den oben definierten PI-Feldern zugeordnet. Es versteht sich jedoch, dass andere Entwicklungsprofile zukünftig zugeordnet werden können.
Obwohl das Feld "PI" das Profil anzeigt, ist zu beachten, dass es verschiedene Ebenen des gleichen Profils geben kann. Zum Beispiel gibt es für das einfache Profil (PI=2) Ebene 1, 2 und 3 (siehe MPEG-4 Beschreibung). Die Ebene ist in den Video-Objekt-Köpfen beschrieben.
Zudem sind die CTCM-Daten für einen nicht profilierten Bitstrom (PI=0) gemäß der Erfindung bereitgestellt, um anzuzeigen, welche Codierwerkzeuge verwendet werden. Für einen profilierten Bitstrom beschreibt das Profil die Codierwerkzeuge. PI=1 ist das Grundprofil H. 263 (im MPEG-4 der kurze Anfangsblock genannt). PI=5 und 6 werden in der MPEG-4 Beschreibung, Version 2, beschrieben.
(4) Nutzlasttyp (PT): 8 Bits. Dieses Feld erkennt das Format der RTP-Nutzlast und bestimmt seine Interpretation durch die Anwendung. "RTCP_CTCM" ermittelt eine CTCM-Nutzlast gemäß der Erfindung.
Der Nutzlast-/Pakettyp (PT) ist als ein 8-Bit-Bezeichner definiert, dessen Wert eine Konstante für den MPEG-4 Codierwerkzeug-Configuration-Map ist. Wie in 1 angezeigt, wird ein RTCP-Nutzlasttyp für dieses neue Paketformat zugeordnet werden.
(5) Eine Einzelerweiterung kann optional an den RTP-Daten(Nutzlast)-Anfangsblock angehängt werden. Die Anfangsblockerweiterung enthält ein 16-Bit-"Längen"-Feld, das die Anzahl der 32-Bit-Wörter in der Erweiterung zählt (z. B. weist die Nutzlast 170 zwei Wörter in diesem Beispiel auf).
(6) Synchronisationsquelle (SSRC) ist die Quelle eines Stroms von RTP-Paketen, die durch einen numerisehen 32-Bit SSRC-Bezeichner, der im RTP-Anfangsblock getragen wird, erkannt wird, um nicht von der Netzadresse abhängig zu sein. Alle Pakete von einer Synchronisationsquelle bilden einen Teil des gleichen Zeitablauf- und Sequenznummerraums, deshalb gruppiert ein Empfänger Pakete durch die Synchronisationsquelle für die Wiedergabe. Beispiele für die Synchronisationsquellen umfassen den Sender eines Stroms von Paketen, der von einer Signalquelle wie beispielsweise einem Mikrophon oder einer Kamera oder einem RTP-Mischer abstammt.
Das Nutzlastfeld 170 wird ferner in Verbindung mit 2 erläutert.
2 stellt ein MPEG-4 Video-CTCM-Nutzlastformat gemäß der Erfindung dar.
Wie in der Legende 200 beschrieben ist, umfasst das Nutzlastfeld 170 ein Skalierbarkeit-Kennungsbitfeld 205, ein nicht 8-Bit Codierungsflag 210, ein Alpha-Plane-Codierungsfeld 215, ein fehlerstabiles Codierwerkzeugfeld 220, ein verschachteltes Codierungsflag 225, ein Sprite-Codierungsflag 230, ein B-VOP (bi-direktionales prädiktiertes Video-Objektplane)-Codierungsflag 235, ein internes Gleichstrom-/Wechselstrom-Prädiktionsflag 240, ein erweitertes Prädiktionsflag 245, ein Viertel-Pixel-Codierungsflag 250, ein globales Bewegungskompensationsflag 255, ein formadaptives DCT (Discrete Cosine Transform = diskrete Cosinus-Transformation)-Flag 260 und ein reserviertes Bitfeld 265.
Dieses Format ist lediglich als ein Beispiel gezeigt, da verschiedene dem Fachmann auf dem Gebiet offensichtliche Modifikationen vorgenommen werden können.
Die MPEG-4 Video-CTCM-Nutzlast ist in der dargestellten Ausführungsform 32 Bits in der Länge. Die Syntax und Semantik der MPEG-4 Video-CTCM-Nutzlast sind wie folgt definiert. Die entsprechenden MPEG-4 Begriffe sind angezeigt. SIB, QPCF, GMCF und SADCTF sind in dem MPEG-4 Codierer beschrieben oder konfiguriert.
Skalierbarkeit-Kennungsbits (SIB) (3 Bits):

000: keine Skalierbarkeit
001: zeitliche Skalierbarkeit
010: räumliche Skalierbarkeit
011: feine Granularitäts-Skalierbarkeit
100: reserviert
101: reserviert
110: reserviert
111: reserviert

Nicht 8-Bit-Codierungsflag (N8) (1 Bit):

0: ohne 8-Bit-Codierung (not_8_bit=1)
1: mit 8-Bit-Codierung (not_8_bit=0)

Alpha-Plane-Codierung (APC) (2 Bits):

00: keine Alpha-Plane-Codierung (video_object_layer_shape="00")
01: binäre Alpha-Plane-Codierung (video_object_layer_shape="01 ")
10: Grau-Stufen-Alpha-Plane-Codierung (video_object_layer_shape="10")
11: verboten

Fehlerstabile Codierwerkzeuge (ERCT) (3 Bits):

000: keine RVLC, keine Datenpartition, kein Videopaket (reversible_vlc=0, data_partitioned=0, resync_marker_disable=0)
001: keine RVLC, keine Datenpartition, mit Videopaket (reversible_vlc=0, data_partitioned=0, resync_marker_disable=l)
010: keine RVLC, mit Datenpartition, kein Videopaket (reversible_vlc=0, data_partitioned=1, resync_marker_disable=0)
011: keine RVLC, mit Datenpartition, mit Videopaket (reversible_vlc=0, data_partitioned=1, resync_marker_disable=l)
100: mit RVLC, mit Datenpartition, kein Videopaket (reversible_vlc=1, data_partitioned=1, resync_marker_disable=0)
101: mit RVLC, mit Datenpartition und Videopaket (reversible_vlc=1, data_partitioned=1, resync_marker_disable=1)
110: verboten
111: verboten

Verschachteltes Codierungsflag (ICF) (1 Bit):

0: ohne verschachtelte Codierwerkzeuge (interlaced=0)
1: mit verschachtelten Codierwerkzeugen (interlaced=1)

Sprite-Codierungsflag (SCF) (2 Bits):

00: ohne Sprite-Codierung (sprite_enable=0)
01: mit statischer Sprite-Codierung (sprite_enable=1 und low_latency_sprite_enable=0)
10: mit On-line-Sprite-Codierung (sprite_enable=l und low_latency_sprite_enable=1)
11: reserviert

B-VOP-Codierungsflag (BVCF) (2 Bits):

00: B-VOP mit Direktmodus-Codierung
01: B-VOP ohne Direktmodus-Codierung
10: kein B-VOP (VOP_coding_type! = "B")
11: verboten.

Internes Gleichstrom-/Wechselstrom-Prädiktionsflag (IDAPF) (2 Bits

00: mit sowohl Gleichstrom- als auch Wechselstrom-Prädiktion (ac_pred_flag=1)
01: mit Gleichstrom-Prädiktion, ohne Wechselstrom-Prädiktion (ac_pred_flag=0)
10: Gleichstrom-Prädiktion mit dc_scaler=8, keine Wechselstrom-Prädiktion (ac_pred_flag=0)
11: ohne Gleichstrom-/Wechselstrom-Prädiktion und dc_scaler=8.

Erweitertes Prädiktions-Flag (APF) (2 Bits):

00: ohne erweiterte Prädiktion
01: erweiterte Prädiktion ohne OBMC (obmc_disable=1)
10: erweiterte Prädiktion mit OBMC (obmc_disable=0)
11: reserviert

Viertelpixel-Codierungsflag (QPCF) (1 Bit):

0: ohne Viertelpixel-Codierung
1: mit Viertelpixel-Codierung

Globales Bewegungskompensationsflag (GMCF) (1 Bit):

0: ohne GMC
1: mit GMC

Formadaptives DCT-Flag (SADCTF) (1 Bit):

0: ohne formadaptives DCT
1: mit formadaptivem DCT

Reservierte Bits (RB): (11 Bits)
Dies ist ein reserviertes Feld für mögliche zukünftige Erweiterung und Anwendungen.
Der vorgeschlagene Codierwerkzeug-Configuration-Map (CTCM) kann zum Beispiel in Streaming-Video-Anwendungen verwendet werden. Streaming-Video ist der herkömmlich verwendete Begriff für einseitige, auf Paketen basierende Übertragung von komprimierten Video-Bitströmen über Netze, besonders das Internet.
Das Internet ist ein Gemeinschafts-Datagrammnetz. Die im Internet gesendeten Pakete unterliegen oft unvorhergesehener Verzögerung und Jitter. Streaming-Video-Anwendungen erfordern jedoch einen genauen Zeitablauf für die Übertragung und Wiedergabe. Echtzeit-Transportprotokolle (z. B. RTP) stellen das Zuschreiben von Datum und Uhrzeit, sequentielle Nummerierung und andere Mechanismen zum Behandeln der Zeitprobleme bereit. Diese Protokolle stellen auch eine Unterstützung für Paket-Verlustermittlung, Sicherheit und Inhaltskennung der Ende-zu-Ende-Übertragung für Daten über Datagrammnetze (z. B. UDP-Protokoll/IP) bereit. In der Praxis ist ein Echtzeit-Transportprotokoll normalerweise innerhalb der Anwendung implementiert. Viele Probleme, wie beispielsweise Paketwiederherstellung und -Überlastabwehr müssen auf der Anwendungsebene implementiert werden.
In Streaming-Videoanwendungen werden komprimierte Videobitströme als die Nutzlast der Übertragungspakete getragen. Im Allgemeinen folgt in jedem Transportpaket auf den Transportanfangsblock ein CODEC (z. B. H. 261, N. 263 und MPEG-4)-Nutzlastanfangsblock, dem dann eine Anzahl von Bytes eines CODEC komprimierten Bitstroms folgt. Wie oben angeführt kann der CTCM als ein MPEG-4 videospezifisches RTCP-Steuerpaket getragen werden.
Demgemäß erweitert die vorliegende Erfindung ein Echtzeit-Transportprotokoll, um die Codierwerkzeuge zum Codieren eines Videobitstroms zu ermitteln.
Zu beachten ist, dass die Steuerdaten/-felder des CTCM-Pakets entweder durch ein spezifisches RTP-Paket oder ein RTCP-Paket getragen werden können. Ein derartiges Paket sollte wiederholt gesendet werden, um die neuen Kunden (z. B. Benutzer/Terminals) zu synchronisieren. Die MPEG-4 Videodaten werden als die RTP-Datenpakete (mit einem MPEG-4 Videotyp) gesendet.
Die CTCM-Daten können als Nutzlast in entweder einem RTCP- oder spezifischen RTP-Paket getragen werden.
3 stellt das Übertragen von Videopaketen und CTCM-Paketen von einem Codierer an einen Decodierer gemäß der Erfindung dar.
Eine Verschlüsselungsseite 300 umfasst einen Videocodierer 305 zum Empfangen und Codieren eines Eingabevideosignals unter Verwendung eines oder mehrerer vorhandener Codierwerkzeuge. Ein Codierwerkzeug-Bezeichner/-Codierer 310 steht mit dem Videocodierer 305 in Verbindung, um das CTCM-Paket 100 aus 1 bereitzustellen. Insbesondere wird die relevante Codierwerkzeugsyntax geprüft, um zu bestimmen, welche Codierwerkzeuge verwendet werden. Eine Verweistabelle oder dergleichen an der Funktion 310 kann für diesen Zweck verwendet werden.
Zum Beispiel kann eine Verweistabelle mit der MPEG-4 Syntax "interlaced=0" zum CTCM-Paketfeldwert "ICF=0" korrelieren.
Zudem ist es für die verwendeten Codierwerkzeuge möglich, sich mit der Zeit für eine Videosequenz zu verändern. Demgemäß kann das CTCM-Paket zu bestimmten Zeiten auf der Grundlage einer Benutzereinstellung, z. B. nach jedem 15. Feld, aktualisiert werden.
Das CTCM-Paket oder die CTCM-Pakete werden an einem Multiplexer 315 mit den codierten Videopaketen (z. B. Videobitstrom), der sich als ein Beispiel an den MPEG-4 Standard anpasst, multiplexiert und über ein Netz 350 zu einer Decodierseite 360 übertragen.
Das Netz 350 kann im Wesentlichen jede Art von Kommunikationsnetz, einschließlich eines Computernetzes, wie beispielsweise das Internet und/oder eines Breitbandkommunikationsnetzes, wie beispielsweise ein Satelliten- oder Kabelfernsehen-Netz, eine Telefonverbindung und so weiter beinhalten.
Die Decodierseite 360 umfasst einen Benutzer-/Teilnehmerterminal 370 mit einem Demultiplexer 375, der die vom Netz 350 empfangenen Videopakete und CTCM-Pakete demultiplexiert. Die Videopakete werden einem Videodecodierer 385 bereitgestellt, während die CTCM-Pakete einem CTCM-Decodierer 380, der die relevanten Felder decodiert, um zu bestimmen, welche Codierwerkzeuge durch den Videocodierer 305 verwendet wurden, bereitgestellt werden, um die Videopakete zu verschlüsseln. Insbesondere kann eine Verweistabelle an der Funktion 380 verwendet werden, um die Felder in dem CTCM-Paket mit der relevanten Codierwerkzeugsyntax zu korrelieren.
Zum Beispiel kann eine Verweistabelle CTCM-Paketfeldwert "ICF=0" zur MPEG-4 Syntax "interlaced=0" korrelieren.
Die Codierwerkzeuginformationen werden als CTCM-Daten dem Videodecodierer 385 zur Verwendung bei der Decodierung der Videopakete vom Demultiplexer 375 unter Verwendung der ermittelten Codierwerkzeuge bereitgestellt. Schließlich decodiert der Videodecodierer 385 die Videopakete, um einem Ausgabegerät 390, wie beispielsweise einem Fernseher oder einem Videokontrollschirm, ein Signal bereitzustellen.
Das Terminal 370 kann ein Beispielbenutzerterminal in einer Terminalgesamtheit, das die Videopakete und die CTCM-Pakete empfängt und/oder auf das Netz 350 zugreift, darstellen.
Das Benutzerterminal 370 kann einen Personal-Computer, eine Fernseh-Set-Top-Box, ein Kabelmodem, ein drahtloses Telefon, einen tragbaren "Personal Digital Assistant" oder einen anderen Apparat, der auf das Netz 350 zugreifen kann, umfassen.
Als Alternative können CTCM-Pakete über einen separaten Kommunikationskanal als die codierten Videopakete bereitgestellt werden, wobei das Multiplexieren der Videopakete und der CTCM-Pakete vermieden wird.
Es versteht sich nun, dass die vorliegende Erfindung einen neuen Codierwerzeug-Configuration-Map (CTCM) bereitstellt. Unter Verwendung des CTCM als ein MPEG-4 videospezifisches Steuerpaket gemäß der Erfindung, kann ein Videodecodierer in der geeigneten Anwendungsebene konfiguriert werden, so dass Videocodierwerkzeuge am besten verwendet werden können. Die Erfindung ermöglicht die Verwendung eines kundenspezifischen Codierwerkzeugsatzes, der keinem vorbestimmten Profil entsprechen muss. Die Werkzeuge, die für eine bestimmte Anwendung am günstigsten sind, können daher ausgewählt werden, ohne dass sie die Verwendung aller Codierwerkzeuge in einem Profil erfordern, was nicht effektiv und unnötig sein kann.
Zum Beispiel ist es in einer Streaming-Videoanwendung wünschenswert, B-VOPs zu haben, um die Codiereffektivität zu verbessern. Die vorbestimmte Profildefinition (Kernprofil, PI=3), die B-VOPs zulässt, erfordert jedoch auch die Verwendung von binärer Formcodierung. Zur Zeit gibt es jedoch keine Nachfrage nach binärer Formcodierung für die Streaming-Videoanwendung. Zudem sind Schaltkreise für binäre Formcodierung in der Herstellung sehr teuer. Die Erfindung ermöglicht daher die Erstellung eines kundenspezifischen Codierwerkzeugsets, das B-VOPs, aber keine binäre Formcodierung umfasst.
Unter den anderen Anwendungen ist das CTCM-Konzept bei der Erleichterung der Implementierung des Streaming-Videos, z. B. Sammelsenden von Video über IP-Netze, besonders nützlich.

Claims

Ein Verfahren, um mindestens einem Decodierer zu signalisieren, Codierwerkzeuge, die zum Verschlüsseln eines Videostroms verwendet werden, zu erkennen, das folgende Schritte beinhaltet: Assemblieren von mindestens einem Codierwerkzeugsteuerpaket (170), das ermittelt, welche Codierwerkzeuge beim Codieren des Videostroms verwendet werden; und Versorgen eines Empfängers mit mindestens einem Codierwerkzeugsteuerpaket gemäß dem Echtzeit-Transportprotokoll; wobei ein Decodierer an dem Empfänger angepasst ist, um das mindestens eine diesem bereitgestellte Codierwerkzeugsteuerpaket zu verarbeiten, um zu bestimmen, welche Codierwerkzeuge zum Codieren des Videostroms verwendet wurden, und um den Videostrom unter Verwendung von entsprechenden im Empfänger vorhandenen Decodierwerkzeugen zu decodieren.
Verfahren gemäß Anspruch 1, wobei: das mindestens eine Codierwerkzeugsteuerpaket und der Videostrom über ein herkömmliches Netz von einem Codierer dem Empfänger bereitgestellt werden.
Verfahren gemäß Anspruch 1 oder 2, wobei: das mindestens eine Codierwerkzeugsteuerpaket zum Übertragen an den Empfänger über ein Netz mit dem Videostrom multiplexiert wird.
Verfahren gemäß einem der Ansprüche 1 bis 3, wobei: der Videostrom dem Empfänger über ein Netz als Streaming-Video bereitgestellt wird.
Verfahren gemäß Anspruch 4, wobei: das Netz ein Gemeinschafts-Datagrammnetz beinhaltet.
Verfahren gemäß einem der Ansprüche 1 bis 5, wobei: der Videostrom über ein Netz an den Empfänger sammelgesendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 6, wobei: die Codierwerkzeuge, die beim Codieren des Videostroms verwendet werden, einen MPEG-4 Videostandard erfüllen.
Verfahren gemäß einem der Ansprüche 1 bis 7, wobei das mindestens eine Codierwerkzeugsteuerpaket einen Codierstatus des Videostroms, in Bezug auf mindestens eines von Folgendem, ermittelt: ob Skalierbarkeit verwendet wird und, wenn ja, welche Art; ob 8-Bit-Codierung verwendet wird; ob Alpha-Plane-Codierung verwendet wird, und, wenn ja, welche Art; ob fehlerstabile Codierwerkzeuge verwendet werden, und, wenn ja, welche Art; ob verschachteltes Codieren verwendet wird; ob Sprite-Codierung verwendet wird und, wenn ja, welche Art; ob B-VOP-Codierung verwendet wird und, wenn ja, ob Direktmodus-Codierung verwendet wird; ob interne Gleichstrom- und/oder Wechselstrom-Prädiktion verwendet wird und, wenn ja, welche Art; ob erweiterte Prädiktion verwendet wird und, wenn ja, welche Art; ob Viertelpixel-Codierung verwendet wird; ob globale Bewegungskompensation verwendet wird; und ob formadaptives DCT verwendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 8, wobei: das mindestens eine Codierwerkzeugsteuerpaket assembliert wird, indem darin Felder, die auf entsprechenden Syntaxelementen der zum Codieren des Videostroms verwendeten Codierwerkzeuge basieren, bereitgestellt werden.
Verfahren gemäß Anspruch 9, wobei: eine Verweistabelle zum Bereitstellen der Felder als eine Funktion des entsprechenden Syntaxelements verwendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 10, wobei: der Videostrom nicht profiliert ist; und das mindestens eine Codierwerkzeugsteuerpaket einen kundenspezifischen Codierwerkzeugsatz ermittelt.
Ein Decodierverfahren zum Erkennen von Codierwerkzeugen, die zum Verschlüsseln eines Videostroms verwendet werden, das folgende Schritte beinhaltet: Empfangen des Videostroms an einem Empfänger; Wiederherstellen an einem Decodierer an dem Empfänger von mindestens einem Codierwerkzeugsteuerpaket (170), das ermittelt, welche Codierwerkzeuge zum Codieren des Videostroms verwendet werden; und Verarbeiten des mindestens einen wiederhergestellten Codierwerkzeugsteuerpakets, um zu bestimmen, welche Codierwerkzeuge beim Codieren des Videostroms verwendet wurden, und Decodieren des Videostroms unter Verwendung entsprechender, im Empfänger vorhandener Decodierwerkzeuge; wobei dem Empfänger das mindestens eine Codierwerkzeugsteuerpaket gemäß dem Echtzeit- Transportprotokoll bereitgestellt wird.
Verfahren gemäß Anspruch 12, wobei: das mindestens eine Codierwerkzeugsteuerpaket und der Videostrom über ein herkömmliches Netz von einem Codierer dem Empfänger bereitgestellt werden.
Verfahren gemäß Anspruch 12 oder 13, wobei: das mindestens eine Codierwerkzeugsteuerpaket zum Übertragen an den Empfänger über ein Netz mit dem Videostrom multiplexiert wird.
Verfahren gemäß Anspruch 13, wobei: der Videostrom dem Empfänger über ein Netz als Streaming-Video bereitgestellt wird.
Verfahren gemäß Anspruch 15, wobei: das Netz ein Gemeinschafts-Datagrammnetz beinhaltet.
Verfahren gemäß einem der Ansprüche 12 bis 16, wobei: der Videostrom über ein Netz an den Empfänger sammelgesendet wird.
Verfahren gemäß einem der Ansprüche 12 bis 17, wobei: die Codierwerkzeuge, die beim Codieren des Videostroms verwendet werden, einen MPEG-4 Videostandard erfüllen.
Verfahren gemäß einem der Ansprüche 12 bis 18, wobei das mindestens eine Codierwerkzeugsteuerpaket einen Codierstatus des Videostroms, in Bezug auf mindestens eines von Folgendem, ermittelt: ob Skalierbarkeit verwendet wird und, wenn ja, welche Art; ob 8-Bit-Codierung verwendet wird; ob Alpha-Plane-Codierung verwendet wird und, wenn ja, welche Art; ob fehlerstabile Codierwerkzeuge verwendet werden und, wenn ja, welche Art; ob verschachteltes Codieren verwendet wird; ob Sprite-Codierung verwendet wird und, wenn ja, welche Art; ob B-VOP-Codierung verwendet wird und, wenn ja, ob Direktmodus-Codierung verwendet wird; ob interne Gleichstrom- und/oder Wechselstrom-Prädiktion verwendet wird und, wenn ja, welche Art; ob erweiterte Prädiktion verwendet wird und, wenn ja, welche Art; ob Viertelpixel-Codierung verwendet wird; ob globale Bewegungskompensation verwendet wird; und ob formadaptives DCT verwendet wird.
Verfahren gemäß einem der Ansprüche 12 bis 19, wobei: das mindestens eine Codierwerkzeugsteuerpaket darin Felder, die auf entsprechenden Syntaxelementen der beim Codieren des Videostroms verwendeten Codierwerkzeuge basieren, assembliert werden, beinhaltet.
Verfahren gemäß Anspruch 20, wobei: eine Verweistabelle verwendet wird, um zu bestimmen, welche Codierwerkzeuge beim Codieren des auf dem entsprechenden Syntaxelement basierenden Videostroms verwendet werden.
Verfahren gemäß einem der Ansprüche 12 bis 21, wobei: der Videostrom nicht profiliert ist; und das mindestens eine Codierwerkzeugsteuerpaket einen kundenspezifischen Codierwerkzeugsatz ermittelt.
Eine Vorrichtung, um einem Decodierer zu signalisieren, Codierwerkzeuge, die zum Verschlüsseln eines Videostroms verwendet werden, zu erkennen, die Folgendes beinhaltet: ein Mittel (300) zum Assemblieren von mindestens einem Codierwerkzeugsteuerpaket (170), das ermittelt, welche Codierwerkzeuge beim Codieren des Videostroms verwendet werden; und ein Mittel (350) zum Versorgen eines Empfängers (370) mit mindestens einem Codierwerkzeugsteuerpaket gemäß dem Echtzeit-Transportprotokoll; wobei ein Decodierer (380) an dem Empfänger (370) angepasst ist, um das mindestens eine diesem bereitgestellte Codierwerkzeugsteuerpaket zu verarbeiten, um zu bestimmen, welche Codierwerkzeuge zum Codieren des Videostroms verwendet wurden, und um den Videostrom unter Verwendung von entsprechenden im Empfänger vorhandenen Decodierwerkzeugen zu decodieren.
Eine Decodiervorrichtung zum Erkennen von Codierwerkzeugen, die zum Verschlüsseln eines Videostroms verwendet werden, die Folgendes beinhaltet: ein Mittel (370) zum Empfangen des Videostroms am Decodierer (360); ein Mittel (375) zum Wiederherstellen am Decodierer von mindestens einem Codierwerkzeugsteuerpaket (170), das ermittelt, welche Codierwerkzeuge zum Codieren des Videostroms verwendet werden; und Mittel (380, 385) zum Verarbeiten des mindestens einen wiederhergestellten Codierwerkzeugsteuerpakets, um zu bestimmen, welche Codierwerkzeuge zum Codieren des Videostroms verwendet wurden, und zum Decodieren des Videostroms unter Verwendung entsprechender im Empfänger vorhandener Decodierwerkzeuge (370); wobei dem Empfangsmittel (370) das mindestens eine Codierwerkzeugsteuerpaket gemäß dem Echtzeit-Transportprotokoll bereitgestellt wird.