DE202007019459U1

DE202007019459U1 - Vorrichtung zum Decodieren/Codieren eines Videosignals

Info

Publication number: DE202007019459U1
Application number: DE202007019459U
Authority: DE
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2006-03-30
Filing date: 2007-03-30
Publication date: 2012-09-13
Anticipated expiration: 2017-03-31
Also published as: EP2025170A1; US20100080293A1; KR20090099090A; KR100943911B1; KR20090099585A; EP2008460A1; US20100111169A1; US20100027659A1; US20100027682A1; KR20090006095A; US7782946B2; US20100260265A1; EP2005753B1; US20100091843A1; US8565303B2; KR100949976B1; KR100949983B1; US8411744B2; WO2007114608A1; KR20090006093A

Abstract

Vorrichtung zum Decodieren von Multi-View-Videodaten in einem Multi-View-Videostrom, wobei die Vorrichtung aufweist: eine Parser-Einheit (100), die aus dem Multi-View-Videostrom eine Inter-View-Bildgruppen-Identifizierungsinformation erhält, wobei die Inter-View-Bildgruppen-Identifizierungsinformation angibt, ob ein Typ eines Bildes eine Inter-View-Bildgruppe ist, wobei die Inter-View-Bildgruppe eces referenzieren, die zu einer gleichen Zeit und zu einem anderen View der Inter-View-Bildgruppe gehören, wobei die Parser-Einheit aus dem Multi-View-Videostrom eine Inter-View-Referenzinformation erhält, die View-Beziehungen zwischen mehreren Views repräsentiert, wobei die Inter-View-Referenzinformation eine Viewnummer-Information und eine View-Identifizierungsinformation umfasst; eine Pufferspeichereinheit (600) für decodierte Bilder, die basierend auf der Inter-View-Bildgruppen-Identifizierungsinformation, der Viewnummer-Information und der View-Identifizierungsinformation eine Inter-View-Referenzbildliste für die Inter-View-Bildgruppe erzeugt; und eine Inter-Vorhersageeinheit (700), die basierend auf der erzeugten Inter-View-Referenzbildliste einen Vorhersagewert eines Makroblocks in der Inter-View-Bildgruppe bestimmt, wobei die Inter-Vorhersageeinheit den Makroblock unter Verwendung des Vorhersagewerts decodiert.

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf eine Vorrichtung zum Decodieren/Codieren eines Videosignals.
Stand der Technik
Kompressionscodierung bezeichnet eine Reihe von Signalverarbeitungstechniken zum Übertragen digitalisierter Informationen über eine Kommunikationsleitung oder zum Speichern digitalisierter Information in einer für ein Speichermedium geeigneten Form. Gegenstand einer Kompressionscodierung sind Audio, Video, Text, und dergleichen mehr. Insbesondere wird ein Verfahren für das Ausführen einer Kompressionscodierung an einer Bildsequenz als Videosequenzkompression bezeichnet. Die Videosequenz ist üblicherweise durch eine räumliche und zeitliche Redundanz gekennzeichnet.
Offenbarung der Erfindung
Technische Aufgabe
Die Aufgabe der vorliegenden Erfindung besteht in der Verbesserung der Codiereffizienz eines Videosignals.
Technische Lösung
Ein Gegenstand der vorliegenden Erfindung besteht im effizienten Codieren eines Videosignals durch Definieren einer Viewinformation (Ansichtsinformation) für das Identifizieren eines View (Blickwinkels) eines Bildes.
Ein weiterer Gegenstand der vorliegenden Erfindung besteht in der Verbesserung der Codiereffizienz durch Codieren eines Videosignals auf Basis einer Inter-View-Referenzinformation.
Ein weiterer Gegenstand der vorliegenden Erfindung besteht in der Angabe einer View-Skalierbarkeit eines Videosignals durch die Definieren einer View-Ebeneninformation.
Eine weiterer Gegenstand der vorliegenden Erfindung besteht im effizienten Codieren eines Videosignals durch Definieren eines Inter-View-Synthesevorhersage-Identifikators, der angibt, ob ein Bild eines virtuellen Views bezogen werden soll.
Vorteilhafte Wirkungen
Beim Codieren eines Videosignals ermöglicht die vorliegende Erfindung eine effizientere Ausführung durch Anwenden einer Inter-View-Vorhersage unter Verwendung von View-Information zum Identifizieren eines View eines Bildes. Ferner kann die vorliegende Erfindung durch eine neue Definition einer Ebeneninformation, die eine Information für eine hierarchische Struktur anzeigt, um eine View-Skalierbarkeit zur Verfügung zu stellen, eine für einen Benutzer passende Bildsequenz zur Verfügung stellen. Darüber hinaus ermöglicht die vorliegende Erfindung durch Definieren eines zu einem View einer niedrigsten Ebene gehörenden Referenzviews, eine Kompatibilität mit einem herkömmlichen Decoder. Überdies verbessert die vorliegende Erfindung die Effizienz einer Codierung durch Entscheiden darüber, ob beim Durchführen einer Inter-View-Vorhersage ein Bild eines virtuellen Views vorhergesagt werden soll. Im Falle eines Vorhersagens eines Bildes eines virtuellen Views, ermöglicht die vorliegende Erfindung eine präzisere Vorhersage, wodurch die Anzahl der zu übertragenden Bits reduziert wird.
Beschreibungen der Zeichnungen
1 stellt ein schematisches Blockschema einer Vorrichtung zum Decodieren eines Videosignals gemäß der vorliegenden Erfindung dar.
2 stellt eine graphische Darstellung der Konfigurationsinformation für ein Multi-View-Video gemäß einer Ausführungsform der vorliegenden Erfindung dar, die einem Multi-View-Video-codierten Bitstrom hinzugefügt werden kann.
3 stellt ein internes Blockschema einer Einheit 620 zur Konstruktion einer Referenzbildliste gemäß einer Ausführungsform der vorliegenden Erfindung dar.
4 stellt eine graphische Darstellung einer hierarchischen Struktur einer Ebeneninformation zum Ermöglichen einer View-Skalierbarkeit eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung dar.
5 stellt eine graphische Darstellung einer Konfiguration einer NAL-Einheit, die innerhalb eines Erweiterungsbereiches eines NAL-Header eine Ebeneninformation enthält, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
6 stellt eine graphische Darstellung einer übergreifenden Vcrhersagestruktur eines Multi-View-Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung für die Erläuterung eines Konzepts einer Inter-View-Bildgruppe dar.
7 stellt eine graphische Darstellung einer Vorhersage-Struktur gemäß einer Ausführungsform der vorliegenden Erfindung für die Erläuterung eines Konzepts einer neu definierten Inter-View-Bildgruppe dar.
8 stellt ein schematisches Blockschema einer Vorrichtung zum Decodieren eines Multi-View-Videos unter Verwendung einer Inter-View-Bildgruppen-Identifizierungsinformation gemäß einer Ausführungsform der vorliegenden Erfindung dar.
9 stellt ein Flussdiagramm eines Ablaufs zur Konstruktion einer Referenzbildliste gemäß einer Ausführungsform der vorliegenden Erfindung dar.
10 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens zur Initialisierung einer Referenzbildliste, bei der ein P-Slice einen aktuellen Slice (Teilstück eines Bildes) bildet, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
11 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens zur Initialisierung einer Referenzbildliste, bei der ein B-Slice einen aktuellen Slice bildet, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
12 stellt ein internes Blockschema einer Einheit 630 zum Umordnen einer Referenzbildliste gemäß einer Ausführungsform der vorliegenden Erfindung dar.
13 stellt ein internes Blockschema einer Einheit 643B oder 645B zum Ändern einer Referenzindexzuordnung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
14 stellt eine graphische Darstellung zur Erläuterung eines Ablaufs zum Umordnen einer Referenzbildliste unter Verwendung einer View-Information gemäß einer Ausführungsform der vorliegenden Erfindung dar.
15 stellt ein internes Blockschema einer Einheit 630 zum Umordnen einer Referenzbildliste gemäß einer weiteren Ausführungsform der vorliegenden Erfindung dar.
16 stellt ein internes Blockschema einer Einheit 970 zum Umordnen einer Referenzbildliste für eine Inter-View-Vorhersage gemäß einer Ausführungsform der vorliegenden Erfindung dar.
17 und 18 stellen graphische Darstellungen einer Syntax zum Umordnen einer Referenzbildliste gemäß einer Ausführungsform der vorliegenden Erfindung dar.
19 stellt eine graphische Darstellung einer Syntax zum Umordnen einer Referenzbildliste gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
20 stellt eine graphische Darstellung eines Vorgangs zum Erhalt eines Beleuchtungsdifferenzwerts eines aktuellen Blocks gemäß einer Ausführungsform der vorliegenden Erfindung dar.
21 stellt ein Flussdiagramm eines Ablaufs zur Durchführung einer Beleuchtungskompensation eines aktuellen Blocks gemäß einer Ausführungsform der vorliegenden Erfindung dar.
22 stellt eine graphische Darstellung eines Vorgangs zum Erhalt eines Vorhersagewerts für die Beleuchtungsdifferenz eines aktuellen Blocks unter Verwendung von Informationen für einen benachbarten Block gemäß einer Ausführungsform der vorliegenden Erfindung dar.
23 stellt ein Flussdiagramm eines Vorgangs zur Durchführung einer Beleuchtungskompensation unter Verwendung von Informationen für einen benachbarten Block gemäß einer Ausführungsform der vorliegenden Erfindung dar.
24 stellt ein Flussdiagramm eines Vorgangs zur Durchführung einer Beleuchtungskompensation unter Verwendung von Informationen für einen benachbarten Block gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
25 stellt eine graphische Darstellung eines Vorgangs zum Vorhersagen eines aktuellen Bildes unter Verwendung eines Bildes in einem virtuellen View gemäß einer Ausführungsform der vorliegenden Erfindung dar.
26 stellt ein Flussdiagramm eines Vorgangs zur Synthetisierung eines Bildes in einem virtuellen View beim Durchführen einer Inter-View-Vorhersage bei einer MVC gemäß einer Ausführungsform der vorliegenden Erfindung dar.
27 stellt ein Flussdiagramm eines Verfahrens zur Durchführung einer einem Slicetyp entsprechend gewichteten Vorhersage in einer Videosignalcodierung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
28 stellt eine graphische Darstellung von Makroblock-Typen, die in einem Slicetyp bei einer Videosignalcodierung zulässig sind, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
29 und 30 stellen graphische Darstellungen einer Syntax zur Durchführung einer einem neu definierten Slicetyp entsprechend gewichteten Vorhersage gemäß einer Ausführungsform der vorliegenden Erfindung dar.
31 stellt ein Flussdiagramm eines Verfahrens zur Durchführung einer gewichteten Vorhersage unter Verwendung einer Flag-Information, die anzeigt, ob eine gewichtete Inter-View-Vorhersage bei einer Videosignalcodierung angewandt werden soll, gemäß der vorliegenden Erfindung dar.
32 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens zur gewichteten Vorhersage in Übereinstimmung mit einer Flag-Information, die angibt, ob eine gewichtete Vorhersage unter Verwendung von Informationen eines Bildes aus einem von dem des aktuellen Bildes verschiedenen View durchgeführt werden sollte, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
33 stellt eine graphische Darstellung einer Syntax zur Durchführung einer gewichteten Vorhersage in Übereinstimmung mit einer neu definierten Flag-Information gemäß einer Ausführungsform der vorliegenden Erfindung dar.
34 stellt ein Flussdiagramm eines Verfahrens zur Durchführung einer gewichteten Vorhersage gemäß eines NAL-Einheitstyps (NAL: Netzwerk-Abstraktionsschicht) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
35 und 36 stellen eine graphische Darstellung einer Syntax zur Durchführung einer gewichteten Vorhersage im Falle eines für eine Multi-View-Videocodierung vorgesehenen NAL-Einheitstyps gemäß einer Ausführungsform der vorliegenden Erfindung dar.
37 stellt einen Teil eines Blockschemas einer Vorrichtung zum Decodieren eines Videosignals in Übereinstimmung mit einem neu definierten Slicetyp gemäß einer Ausführungsform der vorliegenden Erfindung dar.
38 stellt ein Flussdiagramm zur Erläuterung eines Verfahrens zum Decodieren eines Videosignals in einer wie in 37 gezeigten Vorrichtung gemäß der vorliegenden Erfindung dar.
39 stellt eine graphische Darstellung eines Modus zur Makroblockvorhersage gemäß einer Ausführungsform der vorliegenden Erfindung dar.
40 und 41 stellen graphische Darstellungen einer Syntax mit darauf angewandtem Slicetyp und Makroblockmodus gemäß einer Ausführungsform der vorliegenden Erfindung dar.
42 stellt eine graphische Darstellung von Ausführungsformen, auf die die Slicetypen in 41 angewandt werden, gemäß der vorliegenden Erfindung dar.
43 stellt eine graphische Darstellung von verschiedenen Ausführungsformen des Slicetyps dar, der zu den in 41 gezeigten Slicetypen gehört.
44 stellt eine graphische Darstellung eines bei einem gemischten Slicetyp zulässigen Makroblocks bei einer Vorhersage von zwei gemischten Vorhersagen gemäß einer Ausführungsform der vorliegenden Erfindung dar.
45 bis 47 stellen graphische Darstellungen eines Makroblocktyps eines in einem gemischtem Slice durch Vorhersage von zwei gemischten Vorhersagen existierenden Makroblocks gemäß einer Ausführungsform der vorliegenden Erfindung dar.
48 stellt einen Teil eines Blockschemas einer Vorrichtung zum Codieren eines Videosignals in Übereinstimmung mit einem neu definierten Slicetyp gemäß einer Ausführungsform der vorliegenden Erfindung dar.
49 stellt ein Flussdiagramm eines Verfahrens zum Codieren eines Videosignals in einer wie in 48 gezeigten Vorrichtung gemäß der vorliegenden Erfindung dar.
Beste Ausführungsform der Erfindung
Um diese und andere Vorteile zu erreichen, und in Übereinstimmung mit dem Zweck der dargestellten und ausführlich beschriebenen vorliegenden Erfindung umfasst ein Verfahren zum Decodieren eines Videosignals Schritte zum Prüfen eines Codierschemas des Videosignals, zum Erhalten von dem Codierschema entsprechender Konfigurationsinformation für das Videosignal, zum Erfassen einer Gesamtzahl von Views unter Verwendung der Konfigurationsinformation, zum Erfassen von auf der Gesamtzahl der Views basierenden Inter-View-Referenzinformation und zum Decodieren des Videosignals auf Basis der Inter-View-Referenzinformation, wobei die Konfigurationsinformation zumindest eine Viewinformation zum Identifizieren eines Views des Videosignals umfasst.
Um zusätzlich diese und andere Vorteile zu erreichen und in Übereinstimmung mit dem Zweck der vorliegenden Erfindung umfasst ein Verfahren zum Decodieren eines Videosignals Schritte zum Prüfen eines Codierschemas des Videosignals, zum Erhalten von dem Codierschema entsprechender Konfigurationsinformation für das Videosignal, zum Prüfen einer Ebene für die View-Skalierbarkeit des Videosignals aus der Konfigurationsinformation heraus, zum Erfassen einer Inter-View-Referenzinformation unter Verwendung der Konfigurationsinformation und zum Decodieren des Videosignals auf Basis der Ebene und der Inter-View-Referenzinformation, wobei die Konfigurationsinformation eine Viewinformation zum Identifizieren eines Views eines Bildes umfasst.
Ausführungsform der Erfindung
Es wird nun im Einzelnen auf die bevorzugten Ausführungsformen der vorliegenden Erfindung eingegangen, wobei Beispiele dieser in den beiliegenden Zeichnungen veranschaulicht sind.
Die Vorrichtung zum Komprimieren und Codieren von Videosignaldaten berücksichtigt eine räumliche Redundanz, zeitliche Redundanz, skalierbare Redundanz und Inter-View-Redundanz. Und sie ist bei dem Kompressionscodiervorgang auch zur Durchführung einer Kompressionscodierung unter Berücksichtigung einer wechselseitigen Redundanz zwischen den Views in der Lage. Das die Inter-View-Redundanz berücksichtigende Verfahren zur Kompressionscodierung ist nur ein Ausführungsbeispiel der vorliegenden Erfindung. Die technische Idee der vorliegenden Erfindung kann auch auf die zeitliche Redundanz, die skalierbare Redundanz, etc. angewandt werden.
Betrachtet man eine Konfiguration eines Bitstroms in H.264/AVC, so existiert dort zwischen einer VCL (Videocodierschicht, Video Coding Layer), die mit einem Bewegtbild-Codiervorgang selbst befasst ist, und einem niedrigeren System, das codierte Information transportiert und speichert, eine separate Ebenenstruktur namens NAL (Network Abstraktion Layer, Netzwerk-Abstraktionsschicht). Ein Ausgabeergebnis eines Codiervorgangs sind VCL-Daten und wird durch eine NAL-Einheit vor einem Transport oder einer Speicherung gemappt. Jede NAL-Einheit umfasst komprimierte Videodaten oder RBSP (Raw Byte Sequence Payload, Rohbytesequenz-Nutzlast: Ergebnisdaten einer Bewegtbildcompression), das heißt die der Headerinformation entsprechenden Daten.
Die NAL-Einheit beinhaltet im Wesentlichen einen NAL-Header und ein RBSP. Der NAL-Header umfasst eine Flag-Information (nal_ref_idc), die zeigt, ob ein Slice als Referenzbild der NAL-Einheit enthalten ist, und einen Identifikator (nal_unit_type), der den Typ der NAL-Einheit anzeigt. In der RBSP werden komprimierte Originaldaten gespeichert und dem letzten Abschnitt des RBSP wird ein Abschlussbit (RBSP_trailing_bit) hinzugefügt, um eine Länge des RBSP als Vielfaches von 8 Bit darzustellen. Als Typen von NAL-Einheiten gibt es IDR-Bild (Instantaneous Decoding Refresh, momentane Decodierungsaktualisierung), SPS (Sequence Parameter Set, Sequenzparametersatz), PPS (Picture Parameter Set), SEI (Supplemental Enhancement Information, ergänzende Zusatzinformation), oder dergleichen.
Bei der Standardisierung werden Einschränkungen für verschiedene Profile und Ebenen festgesetzt, um ein Implementieren eines Zielprodukts mit angemessenem Aufwand zu ermöglichen. Unter diesen Umständen soll ein Decoder die entsprechend dem Profil und der Ebene beschlossene Einschränkung erfüllen. Es sind somit zwei Begriffe, 'Profil' und 'Ebene', definiert, um eine Funktion oder einen Parameter anzugeben, die darstellen sollen, inwieweit der Decoder einen Bereich einer komprimierten Sequenz bewältigen kann. Ferner kann ein Profilidentifikator (profile_idc) kennzeichnen, dass ein Bitstrom auf einem vorgeschriebenen Profil basiert. Der Profilidentifikator ist ein Flag, das ein Profil angibt, auf dem ein Bitstrom basiert. Wenn ein Identifikator bei H.264/AVC z. B. 66 ist, bedeutet dies, dass ein Bitstrom auf einem Basisprofil beruht. Wenn ein Profilindikator 77 ist, bedeutet dies, dass ein Bitstrom auf einem Hauptprofil beruht. Wenn ein Profilindikator 88 ist, bedeutet dies, dass ein Bitstrom auf einem erweiterten Profil beruht. Ferner kann der Profilidentifikator in einem Sequenzparametersatz enthalten sein.
Um ein Multi-View-Video zu verarbeiten, muss daher ermittelt werden, ob es sich bei einem eingelesenen Bitstrom um ein Multi-View-Profil handelt. Falls es sich bei dem eingelesenen Bitstrom um ein Multi-View-Profil handelt, muss eine Syntax hinzugefügt werden, um wenigstens eine zusätzliche Information für den Multi-View übertragen zu können. In diesem Fall gibt das Multi-View-Profil einen Profilmodus zum Bearbeiten eines Multi-View-Videos nach einer Ergänzungstechnik des H.264/AVC an. Bei MVC kann ein Hinzufügen von Syntax als Zusatzinformation für einen MVC-Modus effektiver sein als eine unbedingte Syntax. Beispielsweise kann, wenn ein AVC Profil-Identifikator ein Multi-View-Profil anzeigt, die Codiereffizienz durch Hinzufügen einer Information für ein Multi-View-Bild erhöht werden.
Ein Sequenzparametersatz gibt eine Header-Information an, die eine, sich durch eine Codierung einer übergreifenden Sequenz, wie etwa ein Profil, eine Ebene und dergleichen durchziehende Information umfasst. Ein vollständig komprimiertes Video, d. h. eine Sequenz, sollte an einem Sequenz-Header beginnen. Daher sollte ein, einer Header-Information entsprechender Sequenzparametersatz an einem Decoder eintreffen, bevor sich auf den Parametersatz beziehende Daten eintreffen. Und zwar spielt der Sequenzparametersatz RBSP eine Rolle als Header-Information für die Ergebnisdaten der Videokomprimierung. Sobald ein Bitstrom eingelesen ist, ermittelt ein Profil-Indikator vorzugsweise auf welchem der mehreren Profile der eingelesene Bitstrom basiert. Somit wird durch Hinzufügen eines Stücks zur Syntax für die Entscheidung, ob sich ein eingelesener Bitstrom auf ein Multi-View-Profil bezieht (z. B. 'If(profile idc==MULTI_VIEW_PROFILE)'), entschieden, ob sich der eingegebene Bitstrom auf ein Multi-View-Profil bezieht. Diverse Arten von Konfigurationsinformation können nur dann hinzugefügt werden, wenn der eingegebene Bitstrom als sich auf das Multi-View-Profil beziehend erkannt ist. Beispielsweise kann eine Gesamtzahl der Views, im Falle einer Inter-View-Bildgruppe eine Anzahl von Inter-View-Referenzbildern (List0/1), im Falle einer Nicht-Inter-View-Bildgruppe (non-interview picture group) eine Anzahl von Inter-View-Referenzbildern (List0/1) und dergleichen hinzugefügt werden. Außerdem können diverse View-Informationen zum Erzeugen und Verwalten einer Referenzbildliste in einem Pufferspeicher für decodierte Bilder verwendet werden.
1 stellt ein schematisches Blockschema einer Vorrichtung zum Decodieren eines Multi-View-Videosignals gemäß der vorliegenden Erfindung dar.
Eine wie in 1 gezeigte Vorrichtung zum Decodieren eines Multi-View-Videosignals gemäß der vorliegenden Erfindung umfasst einen NAL-Parser 100, eine Entropie-Decodiereinheit 200, eine Einheit 300 zur inversen Quantisierung/inversen Transformation (inverse quantization/inverse transform unit), eine Intra-Vorhersage-Einheit (intra-prediction unit) 400, eine Entblockungs-Filtereinheit (deblocking filter unit) 500, eine Pufferspeichereinheit 600 für decodierte Bilder (decoded picture buffer unit), eine Inter-Vorhersageeinheit (inter-prediction unit) 700 und dergleichen.
Die Pufferspeichereinheit 600 für decodierte Bilder umfasst eine Referenzbild-Speichereinheit 610, eine Referenzbildlistenkonstruktionseinheit 620, eine Referenzbildverwaltungseinheit 650 und dergleichen. Außerdem umfasst die Referenzbildlistenkonstruktionseinheit 620 eine Variablenableitungseinheit 625, eine Referenzbildlisteninitialisierungseinheit 630 und eine Referenzbildlistenumordnungseinheit 640.
Ferner umfasst die Inter-Vorhersageeinheit 700 eine Bewegungskompensationseinheit 710, eine Beleuchtungskompensationseinheit 720, eine Beleuchtungsdifferenzvorhersageeinheit 730, eine View-Synthesevorhersageeinheit 740 und dergleichen.
Der NAL-Parser 100 parst zum Decodieren einer empfangenen Videosequenz pro NAL-Einheit. Im Allgemeinen werden vor einem Decodieren eines Sliceheaders oder von Slicedaten zumindest ein Sequenzparametersatz und zumindest ein Bildparametersatz an einen Decoder übertragen. In diesem Fall können verschiedene Konfigurationsinformationsarten in einem Bereich eines NAL-Headers oder einem Erweiterungsbereich eines NAL-Headers enthalten sein. Da MVC eine Zusatztechnik zur konventionellen AVC-Technik darstellt, kann es im Falle eines MVC-Bitstroms effizienter sein, nur Konfigurationsinformation hinzuzufügen als einen unbedingten Zusatz. Z. B. kann eine Flag-Information hinzugefügt werden, die im Bereich des NAL-Headers oder im Erweiterungsbereich des NAL-Headers ein Vorhandensein oder Nichtvorhandensein eines MVC-Bitstroms erkennen lässt. Konfigurationsinformationen für Multi-View-Video können nur dann hinzugefügt werden, wenn ein eingelesener Bitstrom entsprechend der Flag-Information ein Multi-View-Video-codierter Bitstrom ist. Die Konfigurationsinformationen können beispielsweise eine Zeitebeneninformation (temporal level information), eine View-Ebeneninformation, eine Inter-View-Bildgruppenidentifizierungsinformation, eine View-Identifizierungsinformation und dergleichen sein. Dies wird nachfolgend im Einzelnen unter Bezugnahme auf 2 beschrieben.
2 stellt eine graphische Darstellung von Multi-View-Video-Konfigurationsinformationen, die einem Multi-View-Video-codierten Bitstrom hinzugefügt werden können, gemäß einer Ausführungsform der vorliegenden Erfindung dar. Einzelheiten bezüglich der Multi-View-Video-Konfigurationsinformationen werden in der nachfolgenden Beschreibung erläutert.
Als Erstes gibt die Zeitebeneninformation (temporal_level) eine Information für eine hierarchische Struktur zum Ermöglichen einer zeitlichen Skalierbarkeit aus einem Videosignal an (➀). Durch diese Zeitebeneninformation kann ein Benutzer mit Sequenzen diverser Zeitzonen versorgt werden.
View-Ebeneninformation (view level) kennzeichnet eine Information für eine hierarchische Struktur zum Ermöglichen einer View-Skalierbarkeit aus einem Videosignal (➁). In einem Multi-View-Video muss eine Ebene für eine Zeit und eine Ebene für einen View definiert werden, um einen Benutzer mit diversen Zeit- und Viewsequenzen zu versorgen. Im Falle einer Definition der oben angegebenen Ebeneninformation können Zeitskalierbarkeit und View-Skalierbarkeit verwendet werden. Dadurch kann der Benutzer eine Sequenz bei einer bestimmten Zeit und einem bestimmten View auswählen, oder eine ausgewählte Sequenz kann durch eine Bedingung beschränkt sein.
Die Ebeneninformationen können auf verschiedene Weise entsprechend einer bestimmten Bedingung gesetzt werden. Z. B. kann die Ebeneninformation entsprechend einer Kameraposition oder einer Kameraausrichtung unterschiedlich gesetzt werden. Weiterhin kann die Ebeneninformation unter Berücksichtigung einer Viewabhängigkeit bestimmt werden. Beispielsweise wird eine Ebene für einen View mit einem I-Bild in einer Inter-View-Bildgruppe auf 0 gesetzt, eine Ebene für einen View mit einem P-Bild in einer Inter-View-Bildgruppe auf 1 gesetzt, eine Ebene für einen View mit einem B-Bild in der Inter-View-Bildgruppe auf 2 gesetzt. Darüber hinaus können die Ebeneninformationen beliebig, ohne an eine bestimmte Bedingung angelehnt zu sein, gesetzt werden. Die View-Ebeneninformation wird unter Bezugnahme auf 4 und 5 detailliert erläutert.
Eine Inter-View-Bildgruppenidentifizierungsinformation gibt eine Information an, um zu identifizieren, ob ein codiertes Bild einer aktuellen NAL-Einheit eine Inter-View-Bildgruppe ist (➂). In diesem Fall ist unter einer Inter-View-Bildgruppe ein codiertes Bild zu verstehen, bei dem alle Slices ausschließlich Slices mit dem selben Bildfolgenzähler (picture order count) referenzieren. Beispielsweise ist unter einer Inter-View-Bildgruppe ein codiertes Bild zu verstehen, das sich nur auf Slices eines anderen Views bezieht, ohne sich auf Slices in einem aktuellen View zu beziehen. Bei einem Multi-View-Video-Decodiervorgang kann ein Inter-View-Direktzugriff (Random Access) erforderlich sein. Die Inter-View-Bildgruppenidentifizierungsinformation kann zur Verwirklichung eines effizienten Direktzugriffs erforderlich sein. Ferner kann eine Inter-View-Referenzinformation zur Inter-View-Vorhersage erforderlich sein. Eine Inter-View-Bildgruppenidentifizierungsinformation kann daher verwendet werden, um die Inter-View-Referenzinformation zu erhalten. Außerdem kann die Inter-View-Bildgruppenidentifizierungsinformation zum Hinzufügen von Referenzbildern für eine Inter-View-Vorhersage beim Aufbau einer Referenzbildliste verwendet werden. Ferner kann die Inter-View-Bildgruppenidentifizierungsinformation zur Verwaltung der hinzugefügten Referenzbilder bei der Inter-View-Vorhersage verwendet werden. Beispielsweise können die Referenzbilder in Inter-View-Bildgruppen und Nicht-Inter-View-Bildgruppen einstuft werden und die eingestuften Referenzbilder können dann dahingehend gekennzeichnet werden, dass die nicht zur Inter-View-Vorhersage verwendbaren Referenzbilder nicht verwendet werden sollen. Daneben ist die Inter-View-Bildgruppenidentifizierungsinformation bei einem hypothetischen Referenzdecoder (hypothetical reference decoder) anwendbar. Näheres zur Inter-View-Bildgruppenidentifizierungsinformation wird später unter Bezugnahme auf die 6 erläutert.
Unter einer View-Identifizierungsinformation ist eine Information zur Unterscheidung eines Bildes in einem aktuellen View von einem Bild in einem anderen View zu verstehen (➃). Beim Codieren eines Videosignals kann zum Identifizieren eines jeden Bildes POC (picture order count; Bildfolgenzahler) oder 'frame_num' verwendet werden. Im Falle einer Multi-View-Videosequenz kann eine Inter-View-Vorhersage durchführt werden. Daher ist eine Identifizierungsinformation zum Unterscheiden eines Bildes in einem aktuellen View von einem Bild in einem anderen View erforderlich. Deshalb muss eine View-Identifizierungsinformation zur Identifizierung eines Views eines Bildes definiert werden. Die View-Identifizierungsinformation kann von einem Headerbereich eines Videosignals erhalten werden. Beispielsweise kann der Headerbereich ein NAL-Headerbereich oder ein Erweiterungsbereich eines NAL-Headers oder ein Slice-Headerbereich sein. Unter Verwendung der View-Identifizierungsinformation wird eine Information für ein Bild in einem von dem des aktuellen Bildes unterschiedlichen View erhalten und das Videosignal kann unter Verwendung der Information für das Bild in dem anderen View decodiert werden. Die View-Identifizierungsinformation kann auf einen übergreifenden Codier/Decodiervorgang des Videosignals angewandt werden. Außerdem kann die View-Identifizierungsinformation auf eine Multi-View-Videocodierung unter Verwendung von 'frame_num' angewandt werden, das anstatt eines bestimmten View-Identifikators einen View berücksichtigt.
Indes führt die Entropie-Decodiereinheit 200 an einem geparsten Bitstrom eine Entropiedecodierung aus und von jedem Makroblock werden dann ein Koeffizient, ein Bewegungsvektor und dergleichen extrahiert. Die Einheit 300 zur inversen Quantisierung/inversen Transformation erhält einen transformierten Koeffizientenwert durch Multiplizieren eines quantisierten Werts mit einer Konstante und anschließendem inversen Transformieren des Koeffizientenwerts zur Rekonstruktion eines Bildpunktwertes. Unter Verwendung des rekonstruierten Bildpunktwerts führt die Intra-Vorhersageeinheit 400 eine Intra-Vorhersage der decodierten Auswahl innerhalb eines aktuellen Bildes durch. Unterdessen wird die Entblockungsfiltereinheit 500 zur Verringerung der Blockverzerrung auf jeden der codierten Makroblöcke angewandt. Ein Filter glättet einen Blockrand zur Verbesserung einer Bildqualität eines decodierten Einzelbildes. Eine Auswahl eines Filterungsvorgangs hängt von Randstärke und Gradient einer Bildauswahl am Rand ab. Nach der Filterung werden die Bilder ausgegeben, oder zur Verwendung als Referenzbilder in der Pufferspeichereinheit 600 für decodierte Bilder gespeichert.
Die Pufferspeichereinheit 600 spielt eine Rolle beim Speichern und Öffnen von zuvor codierten Bildern zur Durchführung einer Inter-Vorhersage. In diesem Fall werden 'frame_num' und POC (Bildfolgenzähler) eines jeden Bildes verwendet, um die Bilder in der Pufferspeichereinheit 600 zu speichern oder um die Bilder zu öffnen. Da unter den zuvor codierten Bildern in einem von dem eines aktuellen Bildes verschiedenen View Bilder existieren, kann eine View-Information zum Identifizieren eines Views eines Bildes zusammen mit der 'frame_num' und dem POC verwendbar sein. Die Pufferspeichereinheit 600 für decodierte Bilder umfasst die Referenzbildspeichereinheit 610, die Referenzbildlistenkonstruktionseinheit 620 und die Referenzbildverwaltungseinheit 650. Die Referenzbildspeichereinheit 610 speichert Bilder, auf die zum Codieren des aktuellen Bildes Bezug genommen wird. Die Referenzbildlistenkonstruktionseinheit 620 erstellt eine Liste von Referenzbildern zur Inter-Bild-Vorhersage. Bei der Multi-View-Videocodierung kann eine Inter-View-Vorhersage erforderlich sein. Daher kann, wenn sich ein aktuelles Bild auf ein Bild eines anderen View bezieht, die Notwendigkeit zum Erstellen einer Referenzbildliste zur Inter-View-Vorhersage bestehen. In diesem Fall kann die Referenzbildlistenkonstruktionseinheit 620 die View-Information zum Erzeugen der Referenzbildliste für eine Inter-View-Vorhersage verwenden. Einzelheiten der Referenzbildlistenkonstruktionseinheit 620 werden später unter Bezugnahme auf 3 erläutert.
3 stellt ein internes Blockschema einer Referenzbildlistenkonstruktionseinheit 620 gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Die Referenzbildlistenkonstruktionseinheit 620 umfasst die Variablenableitungseinheit 625, die Referenzbildlisteninitialisierungseinheit 630 und die Referenzlistenumordnungseinheit 640.
Die Variablenableitungseinheit 625 leitet Variablen ab, die zur Initialisierung der Referenzbildliste verwendet werden. Z. B. kann die Variable unter Verwendung von 'frame_num', das eine Bildidentifizierungsnummer angibt, abgeleitet werden. Insbesondere können die Variablen FrameNum und FramNumWrap bei jedem Kurzzeitreferenzbild verwendbar sein. Als Erstes ist die Variable FrameNum gleich einem Wert eines Syntax-Elements frame_num. Die Variable FrameNumWrap kann für die Pufferspeichereinheit 600 für decodierte Bilder dazu verwendet werden, jedem Referenzbild eine kleine Zahl zuzuordnen. Ferner kann die Variable FrameNumWrap von der Variable FrameNum abgeleitet werden. Daher kann unter Verwendung der abgeleiteten Variablen FrameNumWrap die Variable PicNum abgeleitet werden. In diesem Fall kann die Variable PicNum eine Identifizierungsnummer eines von der Pufferspeichereinheit 600 für decodierte Bilder verwendeten Bildes bedeuten. Im Falle eines Langzeitreferenzbildes kann eine Variable LongTermPicNum verwendbar sein.
Zum Erstellen einer Referenzbildliste für eine Inter-View-Vorhersage kann eine erste Variable (z. B. ViewNum) zum Erstellen einer Referenzbildliste für eine Inter-View-Vorhersage abgeleitet werden. Beispielsweise kann eine zweite Variable (z. B. ViewId) abgeleitet werden, die 'view_id' zum Identifizieren eines Views eines Bildes verwendet. Als Erstes kann die zweite Variable gleich einem Wert des Syntaxelements 'view_id' sein. Ferner kann eine dritte Variable (z. B. ViewIDWrap) für die Pufferspeichereinheit 600 für decodierte Bilder verwendet werden, um jedem Referenzbild eine kleine View-Identifikationszahl zuzuordnen, und sie kann von der zweiten Variablen abgeleitet werden. In diesem Fall kann die erste Variable ViewNum eine View-Identifizierungsnummer eines von der Pufferspeichereinheit 600 für decodierte Bilder verwendeten Bildes bedeuten. Da die Anzahl von Referenzbildern, die bei der Inter-View-Vorhersage einer Multi-View-Videocodierung verwendet werden, relativ kleiner sein kann als die zur zeitlichen Vorhersage verwendete, kann gegebenenfalls sogar keine separate Variable definiert sein, um eine View-Identifizierungszahl eines Langzeitreferenzbildes anzugeben.
Die Referenzbildlisteninitialisierungseinheit 630 initialisiert eine Referenzbildliste unter Verwendung der oben angegebenen Variablen. In diesem Falle kann ein Initialisierungsvorgang für eine Referenzbildliste je nach dem Slicetyp unterschiedlich ausfallen. Beispielsweise ist es im Falle eines Decodierens eines P-Slices möglich, einen Referenzindex auf Basis einer Decodierreihenfolge zuzuordnen. Im Falle eines Decodierens eines B-Slices kann ein Referenzindex auf Basis einer Bildausgabereihenfolge zugeordnet werden. Im Falle einer Initialisierung einer Referenzbildliste für eine Inter-View-Vorhersage kann einem Referenzbild auf Basis der ersten Variablen, d. h. der von der View-Information abgeleiteten Variablen, ein Index zugeordnet werden.
Die Referenzbildlistenumordnungseinheit 640 spielt eine Rolle bei der Verbesserung einer Komprimierungseffizienz durch Zuordnen eines kleineren Index zu einem Bild, auf das in der initialisierten Referenzbildliste häufig Bezug genommen wird. Das liegt daran, dass ein kleines Bit zugeordnet wird, wenn ein Referenzindex zum Codieren kleiner wird.
Ferner umfasst die Referenzbildlistenumordnungseinheit 640 eine Einheit 642 zur Prüfung eines Slicetyps, eine Einheit 643 zum Umordnen einer Referenzbildliste-0 und eine Einheit 645 zum Umordnen einer Referenzbildliste-1. Beim Einlesen einer initialisierten Referenzbildliste prüft die Slicetypprüfeinheit 642 den Typ eines zu decodierenden Slices und entscheidet, ob eine Referenzbildliste-0 oder eine Referenzbildliste-1 umgeordnet werden soll. Daher vollzieht die Umordnungseinheit 643, 645 für die Refertenzbildlisten-0/1 ein Umordnen der Referenzbildliste 0, wenn es sich bei dem Slicetyp nicht um ein I-Slice handelt, und vollzieht zudem auch ein Umordnen der Referenzbildliste 1, wenn es sich bei dem Slicetyp um ein B-Slice handelt. Nach einem Abschluss des Umordnungsvorgangs ist eine Referenzbildliste erstellt.
Die Umordnungseinheit 643, 645 für die Referenzbildlisten 0/1 umfasst jeweils eine Einheit 643A, 645A zum Erhalt von Identifizierungsinformation und eine Einheit 643B, 645B zum Ändern einer Referenzindexzuordnung. Die Einheit 643A, 645A zum Erhalt von Identifizierungsinformation erhält eine Identifizierungsinformation (reordering_of_pic_nums_idc), die ein Zuordnungsverfahren eines Referenzindex angibt, wenn ein Umordnen einer Referenzbildliste entsprechend einer Flag-Information durchgeführt wird, die angibt, ob das Umordnen der Referenzbildliste durchgeführt werden soll. Ferner ordnet die Einheit 643B, 645B zur Änderung einer Referenzindexzuordnung die Referenzbildliste durch Ändern einer Zuordnung eines Referenzindex entsprechend der Identifizierungsinformationen um.
Die Einheit 640 zum Umordnen der Referenzbildliste kann auch ein anderes Verfahren durchführen. Beispielsweise kann ein Umordnen so durchgeführt werden, dass der Typ einer NAL-Einheit vor dem Durchlaufen der Slicetypeinheit 642 geprüft und daraufhin eine Einstufung des Typs der NAL-Einheit als MVC-NAL-Fall oder Nicht-MVC-NAL-Fall vorgenommen wird.
Die Referenzbildverwaltungseinheit 650 verwaltet Referenzbilder zur flexibleren Durchführung einer Inter-Vorhersage. Beispielsweise können ein Speichermanagement-Steuerungsverfahren und ein Gleitfensterverfahren verwendet werden, um einen Referenzbildspeicher und einen Nicht-Referenzbildspeicher durch Zusammenführen der Speicher in einen Speicher zu verwalten und ein effizienteres Speichermanagement mit kleinerem Speicher zu realisieren. Bei einer Multi-View-Videocodierung kann, da Bilder innerhalb einer View-Richtung denselben Bildfolgenzähler aufweisen, eine Information zum Identifizieren eines Views bei jedem der Bilder zur Kennzeichnung der Bilder innerhalb einer View-Richtung verwendbar sein. Ferner können die in der oben angegebenen Weise verwalteten Referenzbilder von der Inter-Vorhersage-Einheit 700 verwendet werden.
Die Inter-Vorhersageeinheit 700 führt die Inter-Vorhersage unter Verwendung der in der Pufferspeichereinheit 600 für decodierte Bilder gespeicherten Referenzbilder durch. Ein inter-codierter Makroblock kann in Makroblock-Partitionen aufgeteilt und jede der Makroblock-Partitionen kann aus einem oder zwei Referenzbildern vorhergesagt werden. Die Inter-Vorhersageeinheit 700 umfasst die Bewegungskompensationseinheit 710, die Beleuchtungskompensationseinheit 720, die Beleuchtungsdifferenz-Vorhersageeinheit 730, die Viewsynthese-Vorhersageeinheit 740, die Einheit 750 zur gewichteten Vorhersage und dergleichen.
Die Bewegungskompensationseinheit 710 kompensiert eine Bewegung eines aktuellen Blocks unter Verwendung von Informationen, die von der Entropie-Decodiereinheit 200 übertragen wurden. Aus einem Videosignal werden die Bewegungsvektoren von zum aktuellen Block benachbarten Blöcken extrahiert und anschließend wird eine Bewegungsvektorvorhersage des aktuellen Blocks aus den Bewegungsvektoren der Nachbarblöcke hergeleitet. Ferner wird die Bewegung des aktuellen Blocks unter Verwendung der hergeleiteten Bewegungsvektorvorhersage und einem aus dem Videosignal extrahierten differentiellen Bewegungsvektor kompensiert. Ferner kann die Bewegungskompensation unter Verwendung eines Referenzbildes oder mehrerer Referenzbilder durchgeführt werden. Falls sich ein aktuelles Bild auf Bilder in anderen Views bezieht, kann bei der Multi-View-Videocodierung eine Bewegungskompensation unter Verwendung einer in der Pufferspeichereinheit 600 für decodierte Bilder gespeicherten Referenzbildlisteninformation für die Inter-View-Vorhersage durchgeführt werden. Ferner kann eine Bewegungskompensation auch unter Verwendung einer View-Information zum Identifizieren eines Views des Referenzbildes durchgeführt werden. Unter einem Direktmodus ist ein Codiermodus zum Vorhersagen einer Bewegungsinformation eines aktuellen Blocks aus einer Bewegungsinformation für einen codierten Block zu verstehen. Da dieses Verfahren eine Einsparung der zum Codieren der Bewegungsinformation erforderlichen Bitzahl ermöglicht, wird eine Verbesserung der Kompressionseffizienz erreicht. Beispielsweise sagt ein Zeitrichtungsmodus eine Bewegungsinformation für einen aktuellen Block unter Verwendung einer Korrelation der zeitlichen Bewegungsinformation in einer Zeitrichtung vorher. Bei Verwendung eines zu diesem Verfahren ähnlichen Verfahrens kann die vorliegende Erfindung eine Bewegungsinformation für einen aktuellen Block unter Verwendung einer Korrelation einer Bewegungsinformation in einer Viewrichtung vorhersagen.
Falls ein eingelesener Bitstrom einem Multi-View-Video entspricht, wird, da die jeweiligen Viewsequenzen von verschiedenen Kameras stammen, durch interne und externe Faktoren der Kameras eine Beleuchtungsdifferenz erzeugt. Um dies zu vermeiden, kompensiert die Beleuchtungskompensationseinheit 720 die Beleuchtungsdifferenz. Bei der Durchführung der Beleuchtungskompensation kann eine Flag-Information verwendet werden, die angibt, ob eine Beleuchtungskompensation auf eine bestimmte Ebene eines Videosignals angewandt werden soll. Beispielsweise kann eine Beleuchtungskompensation unter Verwendung einer Flag-Information durchgeführt werden, die angibt, ob die Beleuchtungskompensation an einem entsprechenden Slice oder Makroblock durchzuführen ist. Eine unter Verwendung einer Flag-Information durchzuführende Beleuchtungskompensation kann auf diverse Makroblocktypen (z. B. Inter-16 × 16-Modus oder B-Überspring-Modus oder Direktmodus etc.) angewandt werden.
Bei der Durchführung einer Beleuchtungskompensation kann zur Rekonstruktion des aktuellen Block Information für einen benachbarten Block oder Information für einen Block eines Views, der von dem eines aktuellen Blocks verschiedenen ist, verwendet werden. Ferner kann auch ein Beleuchtungsdifferenzwert des aktuellen Blocks verwendet werden. In diesem Falle kann eine Beleuchtungskompensation, falls sich der aktuelle Block auf Blöcke in einem anderen View bezieht, unter Verwendung der in der Pufferspeichereinheit 600 für decodierte Bilder gespeicherten Referenzbildlisteninformation für die Inter-View-Vorhersage durchgeführt werden. In diesem Fall gibt der Beleuchtungsdifferenzwert des aktuellen Blocks einen Unterschied zwischen einem durchschnittlichen Bildpunktwert des aktuellen Blocks und einem durchschnittlichen Bildpunktwert eines dem aktuellen Block entsprechenden Referenzblocks an. Der Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks wird, um ein Beispiel für eine Verwendung des Beleuchtungsdifferenzwerts anzugeben, unter Verwendung der zum aktuellen Block benachbarten Blöcke und eines Differenzwerts (Beleuchtungsdifferenzresiduum) zwischen dem Beleuchtungsdifferenzwert und dem Beleuchtungsdifferenzvorhersagewert erhalten. Daher kann die Decodiereinheit den Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung des Beleuchtungsdifferenzresiduums und des Beleuchtungsdifferenzvorhersagewerts rekonstruieren. Zum Erhalt eines Beleuchtungsdifferenzvorhersagewerts eines aktuellen Blocks kann Information für einen benachbarten Block verwendet werden. Beispielsweise kann ein Beleuchtungsdifferenzwert eines aktuellen Blocks unter Verwendung eines Beleuchtungsdifferenzwerts eines Nachbarblocks vorhergesagt werden. Vor einer Vorhersage wird geprüft, ob ein Referenzindex des aktuellen Blocks gleich dem des benachbarten Blocks ist. Entsprechend dem Prüfergebnis wird dann entschieden, welche Art eines benachbarten Blocks oder Werts verwendet werden soll.
Die Viewsynthesevorhersageeinheit 740 wird zum Synthetisieren von Bildern in einem virtuellen View unter Verwendung von Bildern in einem zu einem View des aktuellen Bildes benachbarten View und zum Vorhersagen des aktuellen Bildes unter Verwendung der synthetisierten Bilder in dem virtuellen View verwendet. Die Decodiereinheit ist in der Lage, zu entscheiden, ob ein Bild in einem virtuellen View entsprechend einem von einer Codiereinheit übertragenen Inter-View-Synthese-Vorhersageidentifikator synthetisiert werden soll. Beispielsweise wird ein Slice oder ein Makroblock in einem virtuellen View synthetisiert, wenn view_synthesize_pred_flag = 1 oder view_syn_pred_flag = 1 ist. In diesem Fall, wenn der Inter-View-Synthesevorhersageidentifikator eine Information enthält, dass ein virtueller View erzeugt wird, kann in dem virtuellen View ein Bild unter Verwendung einer View-Information zum Identifizieren eines Views eines Bildes erzeugt werden. Ferner kann bei einem Vorhersagen eines aktuellen Bildes aus den synthetisierten Bildern in dem virtuellen View die View-Information verwendet werden, um das Bild in dem virtuellen View als Referenzbild zu verwenden.
Die Einheit 750 zur gewichteten Vorhersage wird zur Kompensation eines Phänomens verwendet, bei dem sich die Bildqualität einer Sequenz merkbar verschlechtert, wenn sich die Helligkeit bei einer zu codierenden Sequenz zeitlich ändert. Bei MVC kann die gewichtete Vorhersage sowohl zum Kompensieren des Helligkeitsunterschieds einer Sequenz in einem anderen View als auch bei einer Sequenz durchgeführt werden, deren Helligkeit sich zeitlich ändert. Beispielsweise kann die gewichtete Vorhersage in ein explizit gewichtetes Vorhersageverfahren und ein implizit gewichtetes Vorhersageverfahren eingeteilt werden.
Die explizit gewichtete Vorhersage kann insbesondere ein Referenzbild oder zwei Referenzbilder verwenden. Bei Verwendung eines Referenzbildes wird ein Vorhersagesignal durch Multiplikation eines einer Bewegungskompensation entsprechenden Vorhersagesignals mit einem Gewichtungskoeffizienten erzeugt. Bei Verwendung von zwei Referenzbildern wird ein Vorhersagesignal durch Addieren eines Offsetwertes zu einem Wert erzeugt, der sich durch Multiplizieren eines einer Bewegungskompensation entsprechenden Vorhersagesignals mit einem Gewichtungskoeffizienten ergibt.
Die implizit gewichtete Vorhersage führt eine gewichtete Vorhersage unter Verwendung einer Entfernung von einem Referenzbild durch. Als Verfahren zum Erhalt der Entfernung zum Referenzbild kann POC (Bildfolgenzähler) verwendet werden, der z. B. eine Ausgabereihenfolge der Bilder angibt. In diesem Fall kann POC durch Berücksichtigung einer Identifizierung eines Views bei jedem der Bilder erhalten werden. Durch Erhalt eines Gewichtungskoeffizienten für ein Bild in einem anderen View kann eine View-Information zum Identifizieren eines Views eines Bildes verwendet werden, um eine Entfernung zwischen den Views der jeweiligen Bilder zu erhalten.
Bei der Videosignal-Codierung kann eine Tiefeninformation für eine spezifische Anwendung oder für einen anderen Zweck verwendet werden. In diesem Fall kann unter einer Tiefeninformation eine Information verstanden werden, die einen Inter-View-Disparitätsunterschied angibt. Beispielsweise kann mittels Inter-View-Vorhersage ein Disparitätsvektor erhalten werden. Ferner sollte der erhaltene Disparitätsvektor zur Disparitätskompensation eines aktuellen Blocks an eine Decodiervorrichtung übertragen werden. Falls jedoch eine Tiefenkarte erhalten und dann zur Decodiervorrichtung übertragen wird, kann der Disparitätsvektor aus der Tiefenkarte (oder Disparitätskarte) heraus ohne Übertragen des Disparitätsvektors zur Decodiervorrichtung erschlossen werden. In diesem Fall besteht der Vorteil darin, dass die Anzahl der an die Decodiervorrichtung zu übertragenden Tiefeninformationsbits verringert werden kann. Somit kann durch ein Ableiten des Disparitätsvektors aus der Tiefenkarte ein neues Disparitätskompensationsverfahren bereitgestellt werden. Daher kann im Falle der Verwendung eines Bildes in einem anderen View während eines Ableitens des Disparitätsvektors aus der Tiefenkarte eine View-Information zum Identifizieren eines Views eines Bildes verwendet werden.
Die durch den oben erläuterten Vorgang inter-vorhergesagten Bilder oder intra-vorhergesagten Bilder werden zum Rekonstruieren eines aktuellen Bildes einem Vorhersagemodus entsprechend rekonstruiert. In der folgenden Beschreibung werden diverse Ausführungsformen erläutert, die ein effizientes Decodierverfahren für ein Videosignal zur Verfügung stellen.
4 stellt eine graphische Darstellung einer hierarchischen Struktur von Ebeneninformation zum Bereitstellen einer View-Skalierbarkeit eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie in 4 gezeigt, kann die Ebeneninformation für jeden View unter Berücksichtigung einer Inter-View-Referenzinformation bestimmt werden. Beispielsweise kann, da ein Decodieren eines P-Bildes und eines B-Bildes ohne ein I-Bild nicht möglich ist, einem Basisview, bei dem das I-Bild die Inter-View-Bildgruppe bildet, 'level=0', einem Basisview, bei dem die Inter-View-Bildgruppe von dem P-Bild gebildet wird, 'level=1' und einem Basisview, bei dem die Inter-View-Bildgruppe von dem B-Bild gebildet ist, 'level=2' zugeordnet werden. Die Ebeneninformation kann aber auch einem bestimmten Standard entsprechend beliebig bestimmt werden.
Die Ebeneninformation kann einem bestimmten Standard entsprechend oder ohne Standard beliebig bestimmt werden. Beispielsweise kann für den Fall, dass die Ebeneninformation auf Basis eines Views bestimmt wird, ein View V0 als Basisview für die Viewebene 0 gesetzt werden, ein View von Bildern, die unter Verwendung von Bildern in einem View vorhergesagt werden, als Viewebene 1 und ein View von Bildern, die unter Verwendung von Bildern in mehreren Views vorhergesagt werden, als Viewebene 2. In diesem Fall kann zumindest eine Viewsequenz erforderlich sein, um eine Kompatibilität mit einem herkömmlichen Decoder (z. B., H.264/AVC, MPEG-2, MPEG-4, etc.) zu erhalten. Dieser Basisview wird zu einer Basis der Multi-View-Codierung, die einem Referenzview zur Vorhersage eines anderen Views entsprechen kann. Eine einem Basisview der MVC (Multi-View-Video-Codierung) entsprechende Sequenz kann durch ein herkömmliches Sequenzcodierschema (MPEG-2, MPEG-4, H.263, H.264, etc.) in einen unabhängigen Bitstrom umgebildet werden. Eine einem Basisview entsprechende Sequenz kann mit H.264/AVC kompatibel sein, muss es aber nicht. Eine Sequenz in einem mit H.264/AVC kompatiblen View entspricht jedoch einem Basisview.
Wie aus 4 ersichtlich können ein View V2 von Bildern, die unter Verwendung von Bildern in View V0 vorhergesagt werden, ein View V4 von Bildern, die unter Verwendung von Bildern in View V2 vorhergesagt werden, ein View V6 von Bildern, die unter Verwendung von Bildern in View V4 vorhergesagt werden, und ein View V7 von Bildern, die unter Verwendung von Bildern in View V6 vorhergesagt werden, als Viewebene 1 gesetzt werden. Ferner können ein View V1 von Bildern, die unter Verwendung von Bildern in den Views V0 und V2 vorhergesagt werden, sowie ein in der gleichen Weise vorhergesagter View V3 und ein in der selben Weise vorhergesagter View V5 als Viewebene 2 gesetzt werden. Damit decodiert ein zum Decodieren einer Multi-View-Videosequenz nicht geeigneter Decoder eines Benutzers lediglich Sequenzen in dem der Viewebene 0 entsprechenden View. Falls der Decoder eines Benutzers durch eine Profilinformation eingeschränkt wird, kann dieser lediglich die Information einer eingeschränkten Viewebene decodieren. Unter einem Profil ist hierbei zu verstehen, dass technische Elemente eines Algorithmus bei der Verarbeitung von Videocodierung/-decodierung standardisiert sind. Das Profil besteht insbesondere aus einem Satz technischer Elemente, die zum Decodieren einer Bitsequenz einer komprimierten Sequenz erforderlich sind, und kann eine Art von Teilstandard darstellen.
Gemäß einer anderen Ausführungsform der vorliegenden Erfindung kann eine Ebeneninformation sich entsprechend einer Kameraposition ändern. Beispielsweise können unter der Annahme, dass die Views V0 und V1 Sequenzen von vorne platzierten Kameras darstellen, dass Views V2 und V3 rückseitige Sequenzen, dass Views V4 und V5 linksseitige Sequenzen und dass Views V6 und V7 rechtsseitige Sequenzen darstellen, die Views V0 und V1 als Viewebene 0, die Views V2 und V3 als Viewebene 1, die Views V4 und V5 als Viewebene 2 und die Views V6 und V7 als Viewebene 3 gesetzt werden. Alternativ kann eine Ebeneninformation entsprechend einer Kameraausrichtung variieren. Alternativ kann eine Ebeneninformation, ohne auf einem bestimmten Standard zu beruhen, beliebig bestimmt werden.
5 stellt eine graphische Darstellung eines Aufbaus einer NAL-Einheit gemäß einer Ausführungsform der vorliegenden Erfindung dar, die eine Ebeneninformation innerhalb eines Erweiterungsbereichs eines NAL-Headers enthält.
Wie in 5 erkennbar ist, umfasst eine NAL-Einheit im Wesentlichen einen NAL-Header und eine RBSP. Der NAL-Header enthält eine Flag-Information (nal_ref_idc), die angibt, ob ein Slice, das ein Referenzbild der NAL-Einheit wird, mit einbegriffen ist, und einen Identifikator (nal_unit_type), der einen Typ der NAL-Einheit angibt. Ferner kann der NAL-Header auch eine Ebeneninformation (view_level) umfassen, die eine Information für eine hierarchische Struktur zum Zurverfügungstellen einer View-Skalierbarkeit angibt.
Komprimierte Originaldaten werden in der RBSP gespeichert und an einen letzten Teil der RBSP wird, um eine Länge der RBSP als Vielfaches von 8 Bit darzustellen, ein RBSP-Abschlussbit angefügt. Als NAL-Einheitstypen sind IDR (Instantaneous Decoding Refresh, momentane Decodierungsaktualiserung), SPS (sequence parameter set, Sequenzparametersatz), PPS (picture parameter set, Bildparametersatz), SEI (supplemental enhancement information, ergänzende Zusatzinformation), und so weiter zu nennen.
Der NAL-Header enthält Information für einen View-Identifikator. Ferner wird eine Videosequenz einer zugehörigen Viewebene während des Durchführens einer auf eine Viewebene bezogenen Decodierung unter Bezugnahme auf den View-Identifikator decodiert.
Die NAL-Einheit umfasst einen NAL-Header 51 und eine Sliceschicht 53. Der NAL-Header 51 umfasst eine NAL-Header-Erweiterung 52. Ferner umfasst die Sliceschicht 53 einen Sliceheader 54 und Slicedaten 55.
Der NAL-Header 51 enthält einen Identifikator (nal_unit_type), der einen Typ der NAL-Einheit angibt. Beispielsweise kann der den Typ der NAL-Einheit angebende Identifikator sowohl einen Identifikator für eine skalierbare Codierung als auch für eine Multi-View-Videocodierung darstellen. In diesem Falle kann die NAL-Header-Erweiterung 52 eine Flag-Information für die Unterscheidung umfassen, ob eine aktuelle NAL eine NAL zur skalierbaren Videocodierung oder eine NAL zur Multi-View-Videocodierung ist. Ferner kann die NAL-Headererweiterung 52 Ergänzungsinformation für die aktuelle NAL entsprechend der Flag-Information umfassen. Beispielsweise kann der NAL-Header im Falle, dass die aktuelle NAL gemäß der Flag-Information die NAL zur Multi-View-Videocodierung bildet, eine Ebeneninformation (view_level) enthalten, die eine Information für eine hierarchische Struktur zum Verfügung stellen einer View-Skalierbarkeit angibt.
6 stellt eine graphische Darstellung einer übergreifenden Vorhersagestruktur eines Multi-View-Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung zur Erläuterung eines Konzepts einer Inter-View-Bildgruppe dar.
Wie der 6 zu entnehmen ist, bezeichnen T0 bis T100 an einer horizontalen Achse die zeitliche Zuordnung von Einzelbildern und S0 bis S7 an einer vertikalen Achse die Zuordnung von Einzelbildern zu Views. Beispielsweise sind Bilder bei T0 als Einzelbilder aufzufassen, die jeweils mit verschiedenen Kameras aber zur selben Zeit T0 aufgenommen wurden, während Bilder bei S0 als Sequenzen zu verstehen sind, die alle mit einer Kamera aber jeweils zu unterschiedlicher Zeit aufgenommen wurden. Die Pfeile in der Zeichnung geben Vorhersagerichtungen und Vorhersagereihenfolgen der jeweiligen Bilder an. Beispielsweise stellt ein in dem View S2 und der Zeitzone T0 befindliches Bild P0 ein Bild dar, das aus I0 vorhergesagt wird, und das zu einem Referenzbild für ein im View S4 und der Zeitzone T0 gelegenes Bild P0 wird. Ferner wird es zu einem Referenzbild für die jeweils in den Zeitzonen T4 und T2 und im View S2 gelegenen Bilder B1 und B2.
Bei einem Multi-View-Videodecodiervorgang kann ein Inter-View-Direktzugriff erforderlich sein. Deshalb sollte ein Zugriff auf einen beliebigen View durch Minimieren des Decodieraufwands möglich sein. In diesem Falle kann zum Erzielen eines effektiven Zugriffs ein Konzept einer Inter-View-Bildgruppe erforderlich sein. Unter einer Inter-View-Bildgruppe ist ein codiertes Bild zu verstehen, bei dem alle Slices ausschließlich Slices mit dem selben Bildfolgezähler referenzieren. Unter einer Inter-View-Bildgruppe ist beispielsweise ein codiertes Bild zu verstehen, dass sich ohne Bezug auf Slices in einem aktuellen View ausschließlich auf Slices in einem anderen View bezieht. In der 6 werden, wenn ein Bild I0 in einem View S0 und in einer Zeitzone T0 eine Inter-View-Bildgruppe darstellt, alle in anderen Views, aber derselben Zeitzone, d. h. der Zeitzone T0, gelegenen Bilder zu Inter-View-Bildgruppen. Um ein weiteres Beispiel anzugeben, wenn ein in einem View SO und einer Zeitzone T8 gelegenes Bild I0 eine Inter-View-Bildgruppe darstellt, dann stellen alle in anderen Views aber derselben Zeitzone, d. h. der Zeitzone T8, gelegenen Bilder Inter-View-Bildgruppen dar. In gleicher Weise werden auch alle Bilder in T16, ..., T96 und T100 Inter-View-Bildgruppen.
7 stellt eine graphische Darstellung einer Vorhersagestruktur gemäß einer Ausführungsform der vorliegenden Erfindung zur Erläuterung eines Konzepts einer neu definierten Inter-View-Bildgruppe dar.
In einer übergreifenden MVC-Vorhersagestruktur kann GOP mit einen I-Bild beginnen. Ferner ist das I-Bild mit H.264/AVC kompatibel. Daher können alle mit H.264/AVC kompatiblen Inter-View-Bildgruppen zum I-Bild werden. In dem Fall, dass die I-Bilder durch ein P-Bild ersetzt werden, ist sogar eine noch effektivere Codierung möglich. Eine effizientere Codierung ist insbesondere bei Verwendung der Vorhersagestruktur möglich, bei der ein GOP mit dem zu H.264/AVC kompatiblen P-Bild beginnen kann.
In diesem Fall werden, wenn die Inter-View-Bildgruppe neu bestimmt wird, alle Slices zu codierten Bildern, die nicht nur ein Slice in einem in derselben Zeitzone gelegenen Einzelbild referenzieren, sondern auch ein Slice, das in demselben View aber in einer anderen Zeitzone gelegen ist. Im Falle einer Referenzierung eines in einer anderen Zeitzone aber im selben View gelegenen Slices kann es sogar noch ausschließlich auf die mit H.264/AVC kompatible Inter-View-Bildgruppe beschränkt sein. Beispielsweise kann ein in 6 am Zeitpunkt T8 und in View S0 gelegenes P-Bild zu einer neu definierten Inter-View-Bildgruppe werden. In gleicher Weise kann ein am Zeitpunkt T96 und in einem View S0 gelegenes P-Bild oder ein am Zeitpunkt T100 und in einem View S0 gelegenes P-Bild zu einer neu definierten Inter-View-Bildgruppe werden. Ferner kann die Inter-View-Bildgruppe nur dann definiert werden, wenn sie einen Basisview darstellt.
Nach dem Decodieren der Inter-View-Bildgruppe werden alle der Reihe nach codierten Bilder aus Bildern decodiert, die vor der Inter-View-Bildgruppe in der Ausgabereihenfolge ohne Inter-Vorhersage decodiert wurden.
Unter Berücksichtigung der in 6 und 7 dargestellten übergreifenden Multi-View-Videocodierstruktur ist es erforderlich, da sich die Inter-View-Referenzinformation einer Inter-View-Bildgruppe von der einer Nicht-Inter-View-Bildgruppe unterscheidet, die Inter-View-Bildgruppe von der Nicht-Inter-View-Bildgruppe entsprechend der Inter-View-Bildgruppenidentifizierungsinformation zu unterscheiden.
Unter Inter-View-Referenz-Information ist die Information zu verstehen, die zum Identifizieren einer Vorhersagestruktur zwischen Inter-View-Bildern in der Lage ist. Diese kann von einem Datenbereich eines Videosignals bezogen werden. Beispielsweise kann diese von einem Sequenzparametersatzbereich bezogen werden. Ferner kann die Inter-View-Referenzinformation unter Verwendung der Anzahl der Referenzbilder und View-Information für die Referenzbilder identifiziert werden. Beispielsweise wird die Gesamtzahl der Views bezogen und die View-Information zum Identifizieren eines jeden Views kann dann auf Basis der Gesamtzahl der Views erhalten werden. Ferner kann bei jedem View die Anzahl der Referenzbilder für eine Referenzrichtung erhalten werden. Die View-Information für jedes der Referenzbilder kann entsprechend der Anzahl der Referenzbilder erhalten werden. Auf diese Weise kann die Inter-View-Referenzinformation erhalten werden. Ferner kann die Inter-View-Referenzinformation durch Unterscheiden einer Inter-View-Bildgruppe von einer Nicht-Inter-View-Bildgruppe identifiziert werden. Die Identifizierung kann durch Verwenden einer Inter-View-Bildgruppenidentifizierungsinformation erfolgen, die angibt, ob ein codiertes Slice in einem aktuellen NAL eine Inter-View-Bildgruppe darstellt. Einzelheiten zur Inter-View-Bildgruppenidentifizierungsinformation werden nachfolgend unter Bezugnahme auf 8 erläutert.
8 stellt ein schematisches Blockschema einer Vorrichtung zum Decodieren eines Multi-View-Videos unter Verwendung einer Inter-View-Bildgruppenidentifizierungsinformation entsprechend einer Ausführungsform der vorliegenden Erfindung dar.
Wie 8 zu entnehmen ist, umfasst eine Decodiervorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung eine Bitstromentscheidungseinheit 81, eine Inter-View-Bildgruppenidentifizierungsinformation-Erfassungseinheit 82 und eine Multi-View-Videodecodiereinheit 83.
Beim Einlesen eines Bitstroms entscheidet die Bitstromentscheidungseinheit 81, ob es sich bei dem eingelesenen Bitstrom um einen für eine skalierbare Videocodierung codierten Bitstrom handelt oder um einen für Multi-View-Videocodierung codierten Bitstrom. Dies kann mithilfe der im Bitstrom enthaltenen Flag-Information entschieden werden.
Die Inter-View-Bildgruppenidentifizierungsinformation-Erfassungseinheit 82 kann die Inter-View-Bildgruppenidentifizierungsinformation erhalten, wenn es sich gemäß dem Ergebnis der Entscheidung bei dem eingelesenen Bitstrom um den Multi-View-Video-codierten Bitstrom handelt. Wenn die erhaltene Inter-View-Bildgruppenidentifizierungsinformation 'wahr' ist, so bedeutet dies, dass ein codiertes Slice eines aktuellen NAL eine Inter-View-Bildgruppe darstellt. Wenn die erhaltene Inter-View-Bildgruppenidentifizierungsinformation 'falsch' ist, so bedeutet dies, dass ein codiertes Slice eines aktuellen NAL eine Nicht-Inter-View-Bildgruppe darstellt. Die Inter-View-Bildgruppenidentifizierungsinformation kann aus dem Erweiterungsbereich eines NAL-Headers oder einem Sliceschichtbereich erhalten werden.
Die Multi-View-Video-Decodiereinheit 83 decodiert ein Multi-View-Video entsprechend der Inter-View-Bildgruppenidentifizierungsinformation. Einer übergreifenden Codierstruktur einer Multi-View-Videosequenz zufolge unterscheidet sich eine Inter-View-Referenzinformation einer Inter-View-Bildgruppe von der einer Nicht-Inter-View-Bildgruppe. Daher kann die Inter-View-Bildgruppenidentifizierungsinformation zum Beispiel beim Hinzufügen von Referenzbildern bei der Inter-View-Vorhersage zum Erzeugen einer Referenzbildliste verwendet werden. Ferner kann die Inter-View-Bildgruppenidentifizierungsinformation auch zum Verwalten der Referenzbilder für die Inter-View-Vorhersage verwendet werden. Darüberhinaus ist die Inter-View-Bildgruppenidentifizierungsinformation auch bei einem Hypothetische-Referenz-Decoder anwendbar.
Um ein weiteres Beispiel einer Verwendung der Inter-View-Bildgruppenidentifizierungsinformation anzugeben, im Falle, dass für jeden Decodiervorgang in einem anderen View befindliche Information verwendet wird, ist die in einem Sequenzparametersatz enthaltene Inter-View-Referenzinformation verwendbar. In diesem Fall kann eine Information zur Unterscheidung, ob ein aktuelles Bild eine Inter-View-Bildgruppe oder eine Nicht-Inter-View-Bildgruppe darstellt, d. h. eine Inter-View-Bildgruppenidentifizierungsinformation erforderlich sein. Daher können für jeden Decodiervorgang unterschiedliche Inter-View-Referenzinformationen verwendet werden.
9 stellt ein Flussdiagramm eines Ablaufs zum Erzeugen einer Referenzbildliste gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie der 9 zu entnehmen ist, spielt die Pufferspeichereinheit 600 für decodierte Bilder bei der Durchführung einer Inter-View-Vorhersage eine Rolle beim Speichern oder Öffnen von zuvor codierten Bildern.
Zuerst werden Bilder, die vor einem aktuellen Bild codiert wurden, in der Referenzbildspeichereinheit 610 zur Verwendung als Referenzbilder gespeichert (S91).
Bei der Multi-View-Videocodierung kann, da einige der zuvor codierten Bilder sich in einem von dem des aktuellen Bildes verschiedenen View befinden, eine View-Information zum Identifizieren eines Views eines Bildes zur Nutzung dieser Bilder als Referenzbilder verwendet werden. Daher sollte der Decoder View-Information zum Identifizieren eines Views eines Bildes erhalten (S92). Beispielsweise kann die View-Information 'view_id' zum Identifizieren eines Views eines Bildes aufweisen.
Die Pufferspeichereinheit 600 für decodierte Bilder muss eine darin verwendete Variable zum Erzeugen einer Referenzbildliste ableiten. Da zur Multi-View-Videocodierung eine Inter-View-Vorhersage erforderlich sein kann, kann, wenn sich ein aktuelles Bild auf ein Bild in einem anderen View bezieht, ein Erzeugen einer Referenzbildliste zur Inter-View-Vorhersage erforderlich sein. In diesem Fall muss die Pufferspeichereinheit 600 für decodierte Bilder unter Verwendung der erhaltenen View-Information eine Variable ableiten, die zum Erzeugen der Referenzbildliste für die Inter-View-Vorhersage verwendet wird (S93).
Eine Referenzbildliste zur zeitlichen Vorhersage oder eine Referenzbildliste zur Inter-View-Vorhersage können entsprechend einem Slicetyp eines aktuellen Slice mit einem unterschiedlichen Verfahren erzeugt werden (S94). Beispielsweise wird eine Referenzbildliste 0 erzeugt, wenn es sich bei einem Slicetyp um ein P/SP-Slice handelt (S95). Im Falle, dass es sich bei einem Slicetyp um ein B-Slice handelt, werden eine Referenzbildliste 0 und eine Referenzbildliste 1 erzeugt (S96). In diesem Falle können die Referenzbildlisten 0 oder 1 entweder nur die Referenzbildlisten für die zeitliche Vorhersage oder sowohl die Referenzbildlisten für die zeitliche Vorhersage als auch die Referenzbildlisten für die Inter-View-Vorhersage enthalten. Dies wird später ausführlich unter Bezugnahme auf 8 und 9 beschrieben.
Die initialisierte Referenzbildliste wird zur weiteren Verbesserung einer Komprimierungsrate einem Ablauf unterzogen, bei dem einem Bild, auf das häufig Bezug genommen wird, eine kleinere Zahl zugewiesen wird (S97). Dies kann als Umordnungsvorgang für eine Referenzbildliste bezeichnet werden, der später unter Bezugnahme auf die 12 bis 19 ausführlich beschrieben wird. Das aktuelle Bild wird unter Verwendung der umgeordneten Referenzbildliste decodiert und die Pufferspeichereinheit 600 für decodierte Bilder muss die decodierten Referenzbilder zum effizienteren Betrieb eines Pufferspeichers verwalten (S98). Die nach dem oben beschriebenen Ablauf verwalteten Referenzbilder werden von der Inter-Vorhersageeinheit 700 gelesen, um für die Inter-Vorhersage verwendet zu werden. Bei der Multi-View-Videocodierung kann die Inter-Vorhersage eine Inter-View-Vorhersage umfassen. In diesem Fall kann die Referenzbildliste zur Inter-View-Vorhersage verwendet werden.
Ausführliche Beispiele eines Verfahrens zum Erzeugen einer einem Slicetyp entsprechenden Referenzbildliste werden nachfolgend unter Bezugnahme auf die 10 und 11 erläutert.
10 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens nach einer Ausführungsform der vorliegenden Erfindung zur Initialisierung einer Referenzbildliste für den Fall dar, dass ein aktuelles Slice von einem P-Slice gebildet ist.
Wie 10 entnommen werden kann, sind Zeiten mit T0, T1, ..., TN bezeichnet, während Views mit V0, V1, ..., V4 bezeichnet sind. Beispielsweise ist ein aktuelles Bild als Bild zur Zeit T3 in einem View V4 kenntlich gemacht. Ferner stellt der Slicetyp des aktuellen Bildes ein P-Slice dar. 'PN' ist eine Abkürzung einer Variablen PicNum, 'LPN' ist eine Abkürzung einer Variablen LongTermPicNum und 'VN' ist eine Abkürzung der Variablen ViewNum. Ein an einen Endbereich einer jeden der Variablen angefügtes Zahlensymbol bezeichnet einen Index, der (bei PN oder LPN) eine Zeit eines jeden Bildes oder (bei VN) einen View eines jeden Bildes angibt. Dies betrifft in gleicher Weise 11.
Eine Referenzbildliste zur zeitlichen Vorhersage oder eine Referenzbildliste zur Inter-View-Vorhersage können abhängig vom Slicetyp eines aktuellen Slice auf unterschiedliche Weise erzeugt werden. In 12 stellt ein Slicetyp beispielsweise ein P/SP-Slice dar. In diesem Fall wird eine Referenzbildliste 0 erzeugt. Die Referenzbildliste 0 kann insbesondere eine Referenzbildliste zur zeitlichen Vorhersage und/oder eine Referenzbildliste zur Inter-View-Vorhersage umfassen. Bei der vorliegenden Ausführungsform wird angenommen, dass eine Referenzbildliste sowohl eine Referenzbildliste zur zeitlichen Vorhersage als auch eine Referenzbildliste zur Inter-View-Vorhersage umfasst.
Zum Umordnen von Referenzbildern gibt es diverse Verfahren. Beispielsweise können Referenzbilder entsprechend einer Decodier- oder Bildausgabereihenfolge in Einklang gebracht werden. Als Alternative können Referenzbilder auf Basis einer unter Verwendung von View-Information abgeleiteten Variablen sortiert werden. Als Alternative können Referenzbilder entsprechend einer Inter-View-Referenzinformation sortiert werden, die eine Inter-View-Vorhersagestruktur bezeichnet.
Im Falle einer Referenzbildliste zur zeitlichen Vorhersage können Kurzzeit-Referenzbilder und Langzeit-Referenzbilder auf einer Decodierreihenfolge basierend sortiert werden. Beispielsweise können diese einem Wert einer Variablen PicNum oder LongTermPicNum entsprechend sortiert werden, der von einem Wert abgeleitet ist, der eine Bildidentifikationsnummer (z. B. frame_num oder Longtermframeidx) bezeichnet. Vorab sei bemerkt, dass Kurzzeit-Referenzbilder vor Langzeit-Referenzbildern initialisiert werden können. Eine Sortierreihenfolge der Kurzzeit-Referenzbilder kann so festgelegt werden, dass sie von einem Referenzbild mit dem höchsten Wert der Variablen PicNum zu einem Referenzbild mit dem niedrigsten Variablenwert verläuft. Beispielsweise können die Kurzzeit-Referenzbilder entsprechend der Reihenfolge von PN1 mit einer höchsten Variablen, PN2 mit einer mittleren Variablen und PNO mit der unter PN0 bis PN2 niedrigsten Variablen sortiert werden. Eine Sortierreihenfolge der Langzeit-Referenzbilder kann von einem Referenzbild mit einem niedrigsten Wert für die Variable LongTermPicNum zu einem Referenzbild mit einem höchsten Variablenwert verlaufen. Beispielsweise können die Langzeit-Referenzbilder in einer Reihenfolge von LPN0 mit einer größten Variablen zu LPN1 mit einer kleinsten Variablen sortiert werden.
Bei einer Referenzbildliste zur Inter-View-Vorhersage können die Referenzbilder basierend auf einer ersten Variablen ViewNum, die unter Verwendung von View-Information abgeleitet wird, sortiert werden. Referenzbilder können insbesondere in einer von einem Referenzbild mit einem höchsten ersten Variablenwert (ViewNum) zu einem Referenzbild mit einem niedrigsten ersten Variablenwert (ViewNum) führenden Reihenfolge sortiert werden. Beispielsweise können Referenzbilder in einer Reihenfolge sortiert werden, die von VN3 mit einer höchsten Variablen über VN2 und VN1 zu VN0, das unter VN0, VN1, VN2 und VN3 die niedrigste Variable aufweist, führt.
Somit können die Referenzbildliste zur zeitlichen Vorhersage und die Referenzbildliste zur Inter-View-Vorhersage zusammen als eine Referenzbildliste verwaltet werden. Als Alternative können sowohl die Referenzbildliste zur zeitlichen Vorhersage als auch die Referenzbildliste zur Inter-View-Vorhersage jeweils als separate Referenzbildlisten verwaltet werden. In dem Fall, in dem die Referenzbildliste für die zeitliche Vorhersage und die Referenzbildliste für die Inter-View-Vorhersage beide zusammen als eine Referenzbildliste verwaltet werden, können diese einer Reihenfolge entsprechend oder gleichzeitig initialisiert werden. Beispielsweise wird im Falle eines in einer Reihenfolge vorgenommenen Initialisierens der Referenzbildliste zur zeitlichen Vorhersage und der Referenzbildliste zur Inter-View-Vorhersage vorzugsweise die Referenzbildliste zur zeitlichen Vorhersage initialisiert und die Referenzbildliste zur Inter-View-Vorhersage dann zusätzlich initialisiert. Dieses Konzept ist auch auf die 11 anwendbar.
Ein Fall, bei dem ein Slicetyp eines aktuellen Bildes ein B-Slice darstellt, wird nachfolgend unter Bezugnahme auf 11 erläutert.
11 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens nach einer Ausführungsform der vorliegenden Erfindung zum Initialisieren einer Referenzbildliste für den Fall dar, dass ein B-Slice ein aktuelles Slice bildet.
Wie 9 entnommen werden kann, werden in dem Fall, dass ein Slicetyp ein B-Slice darstellt, eine Referenzbildliste 0 und eine Referenzbildliste 1 erzeugt. In diesem Falle können die Referenzbildliste 0 oder die Referenzbildliste 1 lediglich eine Referenzbildliste zur zeitlichen Vorhersage oder aber sowohl eine Referenzbildliste zur zeitlichen Vorhersage als auch eine Referenzbildliste zur Inter-View-Vorhersage umfassen.
Im Falle der Referenzbildliste zur zeitlichen Vorhersage kann sich ein Kurzzeit-Referenzbild-Sortierverfahren von einem Langzeit-Referenzbild-Sortierverfahren unterscheiden. Beispielsweise können die Referenzbilder im Falle von Kurzzeit-Referenzbildern entsprechend einem Bildfolgezähler (nachfolgend als POC (picture order count) abgekürzt) sortiert werden. Im Falle von Langzeit-Referenzbildern können die Referenzbilder entsprechend einem Variablenwert (LongtermPicNum) sortiert werden. Ferner können die Kurzzeit-Referenzbilder vor den Langzeit-Referenzbildern initialisiert werden.
Um Kurzzeit-Referenzbilder der Referenzbildliste 0 zu sortieren, werden die Referenzbilder vorzugsweise von einem Referenzbild mit einem höchsten POC-Wert zu einem Referenzbild mit einem, unter den Referenzbildern, die niedrigere POC-Werte als ein aktuelles Bild aufweisen, niedrigsten POC-Wert sortiert und dann von einem Referenzbild mit einem niedrigsten POC-Wert zu einem Referenzbild mit einem, unter den Referenzbildern, die höhere POC-Werte als ein aktuelles Bild aufweisen, höchsten POC-Wert sortiert. Beispielsweise können Referenzbilder vorzugsweise von PN1, das von den Referenzbildern PN0 und PN1, die kleinere POC-Werte als ein aktuelles Bild aufweisen, den höchsten POC-Wert aufweist, zu PN0 sortiert und dann von PN3, das von den Referenzbildern PN3 und PN4, die einen kleineren POC-Wert als ein aktuelles Bild aufweisen, einen niedrigsten POC-Wert aufweist, zu PN4 sortiert werden.
Zum Sortieren von Langzeit-Referenzbildern der Referenzbildliste 0 werden Referenzbilder von einem Referenzbild mit einer niedrigsten Variablen LongtermPicNum zu einem Referenzbild mit einer höchsten Variablen sortiert. Referenzbilder werden beispielsweise von LPN0, das von LPN0 und LPN1 den niedrigsten Wert aufweist, zu LPN1 sortiert, das eine zweitniedrigste Variable aufweist.
Im Falle der Referenzbildliste für die Inter-View-Vorhersage können Referenzbilder auf Basis einer ersten unter Verwendung einer View-Information abgeleiteten Variablen ViewNum sortiert werden. Beispielsweise können im Falle der Referenzbildliste 0 für die Inter-View-Vorhersage Referenzbilder von einem Referenzbild mit einem höchsten ersten Variablenwert unter den Referenzbildern, die geringere erste Variablenwerte als ein aktuelles Bild aufweisen, zu einem Referenzbild mit einem niedrigsten ersten Variablenwert sortiert werden. Die Referenzbilder werden dann von einem Referenzbild mit einem niedrigsten ersten Variablenwert unter den Referenzbildern, die größere erste Variablenwerte aufweisen als das aktuelle Bild, zu einem Referenzbild mit einem höchsten ersten Variablenwert sortiert. Beispielsweise werden Referenzbilder vorzugsweise von VN1, das von VN0 und VN1, die kleinere erste Variablenwerte als ein aktuelles Bild aufweisen, einen höchsten ersten Variablenwert aufweist, zu VN0 sortiert, das einen niedrigsten ersten Variablenwert aufweist, und dann von VN3, das von VN3 und VN4, die größere erste Variablenwerte aufweisen als das aktuelle Bild, einen niedrigsten ersten Variablenwert aufweist, zu VN4 sortiert, das einen höchsten ersten Variablenwert aufweist.
Im Falle der Referenzbildliste 1, ist das oben erläuterte Sortierverfahren für die Referenzbildliste 0 in ähnlicher Weise anwendbar.
Im Falle der Referenzbildliste für die zeitliche Vorhersage werden zum Sortieren der Kurzzeit-Referenzbilder der Referenzbildliste 1 zunächst vorzugsweise die Referenzbilder bei den Referenzbildern, die größere POC-Werte aufweisen als ein aktuelles Bild, von einem Referenzbild mit einem niedrigsten POC-Wert zu einem Referenzbild mit einem höchsten POC-Wert sortiert, und dann bei den Referenzbildern, die kleinere POC-Werte aufweisen als das aktuelle Bild, von einem Referenzbild mit einem höchsten POC-Wert zu einem Referenzbild mit einem niedrigsten POC-Wert sortiert. Beispielsweise können Referenzbilder vorzugsweise von PN3, das von PN3 und PN4, die größere POC-Werte aufweisen als ein aktuelles Bild, einen niedrigsten POC-Wert aufweist, zu PN4 sortiert werden, und dann von PN1, das von PN0 und PN1, die größere POC-Werte aufweisen als das aktuelle Bild, einen höchsten POC-Wert aufweist, zu PN0 sortiert werden.
Zum Sortieren von Langzeit-Referenzbildern der Referenzbildliste 1 werden die Referenzbilder von einem Referenzbild mit einer niedrigsten Variablen LongtermPicNum zu einem Referenzbild sortiert, das eine höchste Variable aufweist. Beispielsweise werden die Referenzbilder von LPN0, das von LPN0 und LPN1 einen niedrigsten Wert aufweist, zu LPN1 sortiert, das eine niedrigste Variable aufweist.
Im Falle der Referenzbildliste für die Inter-View-Vorhersage können die Referenzbilder auf Basis einer unter Verwendung einer View-Information abgeleiteten ersten Variablen ViewNum sortiert werden. Beispielsweise können im Falle der Referenzbildliste 1 zur Inter-View-Vorhersage die Referenzbilder von einem Referenzbild mit einem niedrigsten ersten Variablenwert unter den Referenzbildern, die größere erste Variablenwerte aufweisen als ein aktuelles Bild, zu einem Referenzbild mit einem höchsten ersten Variablenwert sortiert werden. Anschließend werden die Referenzbilder dann von einem Referenzbild mit einem höchsten ersten Variablenwert unter den Referenzbildern, die kleinere erste Variablenwerte als das aktuelle Bild aufweisen, zu einem Referenzbild mit einem niedrigsten ersten Variablenwert sortiert.
Beispielsweise werden Referenzbilder vorzugsweise von VN3, das von VN3 und VN4, die größere erste Variablenwerte als ein aktuelles Bild aufweisen, einen niedrigsten ersten Variablenwert aufweist, zu VN4 sortiert, das einen höchsten ersten Variablenwert aufweist, und dann von VN1, das von VN0 und VN1, die kleinere erste Variablenwerte aufweisen als das aktuelle Bild, einen höchsten ersten Variablenwert aufweist, zu VN0 sortiert, das einen niedrigsten ersten Variablenwert aufweist.
Die durch den oben beschriebenen Ablauf initialisierte Referenzbildliste wird an die Referenzbildlistenumordnungseinheit 640 übertragen. Die initialisierte Referenzbildliste wird dann zum effizienteren Codieren umgeordnet. Der Umordnungsvorgang soll eine Bitrate reduzieren, indem einem Referenzbild, das die höchste Wahrscheinlichkeit aufweist, beim Betreiben eines Speichers für decodierte Bilder als Referenzbild ausgewählt zu werden, eine kleine Zahl zugewiesen wird. Nachfolgend werden unter Bezugnahme auf die 12 bis 19 diverse Verfahren zum Umordnen einer Referenzbildliste erläutert.
12 stellt ein internes Blockschema der Referenzbildlistenumordnungseinheit 640 gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie der 12 zu entnehmen ist, umfasst die Referenzbildlistenumordnungseinheit 640 grundsätzlich eine Slicetyp-Prüfeinheit 642, eine Umordnungseinheit 643 für die Referenzbildliste 0, und eine Umordnungseinheit 645 für die Referenzbildliste 1.
Die Umordnungseinheit 643 für die Referenzbildliste 0 umfasst insbesondere eine erste Identifizierungsinformationsbezugseinheit 643A und eine erste Referenzindexzuordnungs-Änderungseinheit 643B. Ferner umfasst die Umordnungseinheit 645 für die Referenzbildliste 1 eine zweite Identifizierungsinformationsbezugseinheit 645A und eine zweite Referenzindexzuordnungs-Änderungseinheit 645B.
Die Slicetyp-Prüfeinheit 642 prüft einen Slicetyp eines aktuellen Slice. Anschließend wird entschieden, ob eine dem Slicetyp entsprechende Umordnung einer Referenzbildliste 0 und/oder einer Referenzbildliste 1 vorgenommen wird. Beispielsweise werden sowohl die Referenzbildliste 0 als auch die Referenzbildliste 1 nicht umgeordnet, wenn ein I-Slice einen Slicetyp eines aktuellen Slice bildet. Wenn ein P-Slice einen Slicetyp eines aktuellen Slice bildet, wird nur die Referenzbildliste 0 umgeordnet. Wenn ein B-Slice einen Slicetyp eines aktuellen Slice bildet, werden sowohl die Referenzbildliste 0 als auch die Referenzbildliste 1 umgeordnet.
Die Umordnungseinheit 643 für die Referenzbildliste 0 wird aktiviert, wenn eine Flag-Information zum Durchführen eines Umordnens der Referenzbildliste 0 'wahr' ist, und wenn es sich bei dem Slicetyp des aktuellen Slice nicht um das I-Slice handelt. Die erste Identifizierungsinformationsbezugseinheit 643A bezieht eine Identifizierungsinformation, die ein Referenzindexzuordnungsverfahren angibt. Die erste Referenzindexzuordnungs-Änderungseinheit 643B ändert den jedem Referenzbild der Referenzbildliste 0 zugeordneten Referenzindex entsprechend der Identifizierungsinformation.
Die Umordnungseinheit 645 für die Referenzbildliste 1 wird gleichermaßen aktiviert, wenn die Flag-Information zum Durchführen eines Umordnens der Referenzbildliste 1 'wahr' ist, und wenn es sich bei dem Slicetyp des aktuellen Slice um das B-Slice handelt. Die zweite Identifizierungsinformationsbezugseinheit 645A bezieht eine Identifizierungsinformation, die ein Referenzindexzuordnungsverfahren angibt. Die zweite Referenzindexzuordnungs-Änderungseinheit 645B ändert den jedem Referenzbild der Referenzbildliste 1 zugeordneten Referenzindex entsprechend der Identifizierungsinformation.
Dadurch wird durch die Umordnungseinheit 643 für die Referenzbildliste 0 und die Umordnungseinheit 645 für die Referenzbildliste 1 eine bei der tatsächlichen Inter-Vorhersage verwendete Referenzbildlisteninformation erzeugt.
Nachfolgend wird unter Bezugnahme auf die 13 ein Verfahren zum Ändern eines einem jeden Referenzbild zugeordneten Referenzindex durch die erste und zweite Referenzindexzuordnungs-Änderungseinheit 643B oder 645B erläutert.
13 stellt ein internes Blockschema einer Referenzindexzuordnungs-Änderungseinheit 643B oder 645B gemäß einer Ausführungsform der vorliegenden Erfindung dar. In der nachfolgenden Beschreibung werden die in 12 gezeigte Umordnungseinheit 643 für die Referenzbildliste 0 und Umordnungseinheit 645 für die Referenzbildliste 1 zusammen erläutert.
Wie der 13 zu entnehmen umfassen sowohl die erste wie die zweite Referenzindexzuordnungs-Änderungseinheit 643B und 645B eine Referenzindexzuordnungs-Änderungseinheit 644A für die zeitliche Vorhersage, eine Referenzindexzuordnungs-Änderungseinheit 644B für Langzeit-Referenzbilder, eine Referenzindexzuordnungs-Änderungseinheit 644C zur Inter-View-Vorhersage und eine Referenzindexzuordnungsänderungs-Beendigungseinheit 644D. Teile innerhalb der ersten und zweiten Referenzindexzuordnungs-Änderungseinheiten 643B und 645B werden jeweils entsprechend der von den ersten und zweiten Identifizierungsinformationsbezugseinheiten 643A und 645A bezogenen Identifizierungsinformation aktiviert. Ferner wird der Umordnungsvorgang solange ausgeführt, bis eine Identifizierungsinformation zum Beenden der Referenzindexzuordnungsänderung eingelesen wird.
Beispielsweise wird die Referenzindexzuordnungs-Änderungseinheit 644A für die zeitliche Vorhersage aktiviert, wenn von der ersten oder zweiten Identifizierungsinformationsbezugseinheit 643A oder 645A eine Identifizierungsinformation zum Ändern der Zuordnung eines Referenzindex für die zeitliche Vorhersage erhalten wird. Die Referenzindexzuordnungs-Änderungseinheit 644A für die zeitliche Vorhersage erhält eine der Identifizierungsinformation entsprechende Bildnummerndifferenz. In diesem Fall ist unter einer Bildnummerndifferenz eine Differenz zwischen einer Bildnummer eines aktuellen Bildes und einer Nummer eines vorhergesagten Bildes zu verstehen. Ferner kann die Nummer des vorhergesagten Bildes eine Nummer eines unmittelbar zuvor zugeordneten Referenzbildes bezeichnen. Somit kann die Zuordnung des Referenzindex unter Verwendung der erhaltenen Bildnummerndifferenz geändert werden. In diesem Fall kann die Bildnummerndifferenz zu/von der Nummer des vorhergesagten Bildes entsprechend der Identifizierungsinformation addiert/subtrahiert werden.
Um ein weiteres Beispiel anzugeben, wird, wenn eine Identifizierungsinformation zum Ändern einer Zuordnung eines Referenzindex zu einem designierten Langzeit-Referenzbild empfangen wird, die Referenzindexzuordnungs-Änderungseinheit 644B für ein Langzeit-Referenzbild aktiviert. Die Referenzindexzuordnungs-Änderungseinheit 644B für ein Langzeit-Referenzbild erhält eine der Identifizierungsnummer entsprechende Langzeit-Referenzbildnummer eines designierten Bildes.
Um ein weiteres Beispiel anzugeben, wird, wenn eine Identifizierungsinformation zum Ändern einer Zuordnung eines Referenzindex zur Inter-View-Vorhersage empfangen wird, die Referenzindexzuordnungs-Änderungseinheit 644C zur Inter-View-Vorhersage aktiviert. Die Referenzindexzuordnungs-Änderungseinheit 644C zur Inter-View-Vorhersage erhält eine der Identifizierungsinformation entsprechende View-Information-Differenz. In diesem Fall ist unter der View-Information-Differenz eine Differenz zwischen einer Viewnummer eines aktuellen Bildes und einer vorhergesagten Viewnummer zu verstehen. Ferner kann die vorhergesagte Viewnummer eine Viewnummer eines unmittelbar zuvor zugeordneten Referenzbildes bezeichnen. Somit kann die Zuordnung eines Referenzindex unter Verwendung der erhaltenen View-Information-Differenz geändert werden. In diesem Fall kann die View-Information-Differenz zu/von der vorhergesagten Viewnummer entsprechend der Identifizierungsinformation addiert/subtrahiert werden.
Um ein weiteres Beispiel anzugeben, wird, wenn eine Identifizierungsinformation zum Beenden einer Änderung einer Referenzindexzuordnung empfangen wird, die Referenzindexzuordnungsänderungs-Beendigungseinheit 644D aktiviert. Die Referenzindexzuordnungsänderungs-Beendigungseinheit 644D beendet eine Zuordnungsänderung eines Referenzindex entsprechend der empfangenen Identifizierungsinformation. Somit erzeugt die Referenzbildlistenumordnungseinheit 640 Referenzbildlisteninformation.
Die für die Inter-View-Vorhersage verwendeten Referenzbilder können daher zusammen mit den für die zeitliche Vorhersage verwendeten Referenzbildern verwaltet werden. Als Alternative können die für die Inter-View-Vorhersage verwendeten Referenzbilder getrennt von den für die zeitliche Vorhersage verwendeten Referenzbildern verwaltet werden. Hierzu können neue Informationen zum Verwalten der für die Inter-View-Vorhersage verwendeten Referenzbilder erforderlich sein. Dies wird später unter Bezugnahme auf die 15 bis 19 erläutert.
Einzelheiten der Referenzindexzuordnungs-Änderungseinheit 644C zur Inter-View-Vorhersage werden nachfolgend unter Bezugnahme auf 14 erläutert.
14 stellt eine graphische Darstellung zur Erläuterung eines Vorgangs gemäß einer Ausführungsform der vorliegenden Erfindung für eine Umordnung einer Referenzbildliste unter Verwendung von View-Information dar.
Im Folgenden wird unter Bezugnahme auf die 14 ein Umordnungsvorgang für eine Referenzbildliste 0 für den Fall erläutert, dass eine Viewnummer VN eines aktuellen Bildes 3 ist, eine Größe DPBsize eines Pufferspeichers für decodierte Bilder 4 ist und ein P-Slice einen Slicetyp eines aktuellen Slice bildet.
Zunächst bildet die ursprünglich als '3' vorhergesagte Viewnummer die Viewnummer des aktuellen Bildes. Ferner ist eine ursprüngliche Sortierung der Referenzbildliste 0 für die Inter-View-Vorhersage '4, 5, 6, 2' (➀). In diesem Fall wird, wenn die Identifizierungsinformation zum Ändern einer Zuordnung eines Referenzindex für eine Inter-View-Vorhersage durch Subtrahieren einer View-Information-Differenz empfangen wird, eine '1' als der empfangenen Identifizierungsinformation entsprechende View-Information-Differenz erhalten. Eine neu vorhergesagte Viewnummer (= 2) wird durch Subtrahieren der View-Information-Differenz (= 1) von der vorhergesagten Viewnummer (= 3) berechnet. Insbesondere wird einem Referenzbild mit der Viewnummer 2 ein erster Index der Referenzbildliste 0 zur Inter-View-Vorhersage zugeordnet. Ferner kann ein zuvor dem ersten Index zugeordnetes Bild zum hintersten Teil der Referenzbildliste 0 verschoben werden. Die umgeordnete Referenzbildliste 0 ist somit '2, 5, 6, 4' (➁). Im Anschluss daran wird, wenn eine Identifizierungsinformation zum Ändern einer Zuordnung eines Referenzindex für die Inter-View-Vorhersage durch Subtrahieren der View-Information-Differenz empfangen wird, '–2' als der Identifizierungsinformation entsprechende View-Information-Differenz erhalten. Eine neu vorhergesagte Viewnummer (= 4) wird dann durch Subtrahieren der View-Information-Differenz (= –2) von der vorhergesagten Viewnummer (= 2) berechnet. Insbesondere wird einem Referenzbild mit der Viewnummer 4 ein zweiter Index der Referenzbildliste 0 zur Inter-View-Vorhersage zugeordnet. Daher ist die umgeordnete Referenzbildliste 0 somit '2, 4, 6, 5' (➂). Im Anschluss daran wird, wenn eine Identifizierungsinformation zum Beenden der Referenzindexzuordnungsänderung empfangen wird, die Referenzbildliste 0, die am Ende die umgeordnete Referenzbildliste 0 aufweist, entsprechend der empfangenen Identifizierungsinformation erzeugt (➃). Infolgedessen ist die Reihenfolge der schließlich erzeugten Referenzbildliste 0 für die Inter-View-Vorhersage '2, 4, 6, 5'.
Als weiteres Beispiel zum Umordnen des Restes der Bilder nach einer Zuordnung des ersten Index der Referenzbildliste 0 für die Inter-View-Vorhersage kann ein jedem Index zugeordnetes Bild zu einer Stelle unmittelbar hinter der des entsprechenden Bildes verschoben werden. Insbesondere wird einem Bild mit der Viewnummer 4 ein zweiter Index zugeordnet, einem Bild (Viewnummer 5), dem der zweite Index zugeordnet war, wird ein dritter Index zugeordnet und einem Bild (Viewnummer 6), dem der dritte Index zugeordnet war, wird der vierte Index zugeordnet. Daher wird die umgeordnete Referenzbildliste zu '2, 4, 5, 6'. Ferner kann ein nachfolgender Umordnungsvorgang in der gleichen Weise durchgeführt werden.
Die durch den oben beschriebenen Vorgang erzeugte Referenzbildliste wird zur Inter-Vorhersage verwendet. Die Referenzbildliste für die Inter-View-Vorhersage und die Referenzbildliste für die zeitliche Vorhersage können zusammen als eine Referenzbildliste verwaltet werden. Als Alternative können die Referenzbildliste für die Inter-View-Vorhersage und die Referenzbildliste für die zeitliche Vorhersage jeweils als separate Referenzbildlisten verwaltet werden. Dies wird im Folgenden mit Bezug auf die 15 bis 19 erläutert.
15 stellt ein internes Blockschema einer Referenzbildlistenumordnungseinheit 640 gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
Wie der 15 entnommen werden kann, kann zum Verwalten einer Referenzbildliste für die Inter-View-Vorhersage als separate Referenzbildliste neue Information erforderlich sein. Beispielsweise wird eine Referenzbildliste für die zeitliche Vorhersage umgeordnet und in manchen Fällen wird dann eine Referenzbildliste für die Inter-View-Vorhersage umgeordnet.
Die Referenzbildlistenumordnungseinheit 640 umfasst hauptsächlich eine Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage, eine NAL-Typ-Prüfeinheit 960 und eine Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage.
Die Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage umfasst eine Slicetyp-Prüfeinheit 642, eine dritte Identifizierungsinformationsbezugseinheit 920, eine dritte Referenzindexzuordnungs-Änderungseinheit 930, eine vierte Identifizierungsinformationsbezugseinheit 940 und eine vierte Referenzindexzuordnungs-Änderungseinheit 950. Die dritte Referenzindexzuordnungs-Änderungseinheit 930 umfasst eine Referenzindexzuordnungs-Änderungseinheit 930A für die zeitliche Vorhersage, eine Referenzindexzuordnungs-Änderungseinheit 930B für Langzeit-Referenzbilder und eine Referenzindexzuordnungsänderungs-Beendigungseinheit 930C. Desgleichen umfasst die vierte Referenzindexzuordnungs-Änderungseinheit 950 eine Referenzindexzuordnungs-Änderungseinheit 950A für die zeitliche Vorhersage, eine Referenzindexzuordnungs-Änderungseinheit 950B für Langzeit-Referenzbilder und eine Referenzindexzuordnungsänderungs-Beendigungseinheit 950C.
Die Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage ordnet Referenzbilder um, die bei der zeitlichen Vorhersage verwendet werden. Die Betriebsabläufe der Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage sind mit denen der obengenannten und in 10 gezeigten Referenzbildlistenumordnungseinheit 640 unter Ausnahme der Informationen für die Referenzbilder zur Inter-View-Vorhersage identisch. Einzelheiten der Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage werden daher in der nachfolgenden Beschreibung nicht behandelt.
Die NAL-Typ-Prüfeinheit 960 prüft einen NAL-Typ eines empfangenen Bitstroms. Falls es sich bei dem NAL-Typ um eine NAL für die Multi-View-Videocodierung handelt, werden zur Inter-View-Vorhersage verwendete Referenzbilder durch die Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage umgeordnet. Die für die Inter-View-Vorhersage erzeugte Referenzbildliste wird zusammen mit der von der Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage erzeugten Referenzbildliste zur Inter-Vorhersage verwendet. Die Referenzbildliste für die Inter-View-Vorhersage wird jedoch nicht umgeordnet, wenn der NAL-Typ nicht dem NAL für die Multi-View-Video-Codierung entspricht. In diesem Fall wird lediglich eine Referenzbildliste zur zeitlichen Vorhersage erzeugt. Ferner ordnet die Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage Referenzbilder um, die für die Inter-View-Vorhersage verwendet werden. Die wird nachfolgend im Einzelnen unter Bezugnahme auf die 16 erläutert.
16 stellt ein internes Blockschema der Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie der 16 zu entnehmen ist, umfasst die Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage eine Slicetyp-Prüfeinheit 642, eine fünfte Identifizierungsinformationsbezugseinheit 971, eine fünfte Referenzindexzuordnungs-Änderungseinheit 972, eine sechste Identifizierungsinformationsbezugseinheit 973 und eine sechste Referenzindexzuordnungs-Änderungseinheit 974.
Die Slicetyp-Prüfeinheit 642 prüft einen Slicetyp eines aktuellen Slice. Daraufhin wird entschieden, ob ein Umordnen der Referenzbildliste 0 und/oder der Referenzbildliste 1 entsprechend dem Slicetyp durchgeführt wird. Einzelheiten über die Slicetyp-Prüfeinheit 642 können aus 10 abgeleitet werden und werden in der nachfolgenden Beschreibung nicht behandelt.
Sowohl die fünfte wie auch die sechste Identifizierungsinformationsbezugseinheit 971 und 973 erhält eine Identifizierungsinformation, die ein Referenzindexzuordnungsverfahren angibt. Und sowohl die fünfte als auch die sechste Referenzindexzuordnungs-Änderungseinheit 972 und 974 ändern einen, einem jeden Referenzbild der Referenzbildliste 0 und/oder 1 zugeordneten Referenzindex. In diesem Fall kann unter einem Referenzindex einzig eine Viewnummer eines Referenzbildes verstanden werden. Ferner kann die Identifizierungsinformation zur Bezeichnung des Referenzindexzuordnungsverfahrens von einer Flag-Information gebildet sein. Beispielsweise wird, wenn die Flag-Information wahr ist, eine Zuordnung der Viewnummer geändert. Wenn die Flag-Information falsch ist, kann ein Umordnungsvorgang einer Viewnummer beendet werden. Wenn die Flag-Information wahr ist, kann sowohl die fünfte wie die sechste Referenzindexzuordnungs-Änderungseinheit 972 und 974 eine der Flag-Information entsprechende Viewnummerndifferenz erhalten. Die Viewnummerndifferenz ist in diesem Fall als eine Differenz zwischen einer Viewnummer eines aktuellen Bildes und einer Viewnummer eines vorhergesagten Bildes zu verstehen. Ferner kann die Viewnummer des vorhergesagten Bildes als Viewnummer eines unmittelbar zuvor zugeordneten Referenzbildes zu verstehen sein. Es ist dann möglich, die Viewnummernzuordnung unter Verwendung der Viewnummerndifferenz zu ändern. In diesem Fall kann die Viewnummerndifferenz zu/von der Viewnummer des vorhergesagten Bildes entsprechend der Identifizierungsinformation addiert/subtrahiert werden.
Somit muss die Syntaxstruktur neu definiert werden, um die Referenzbildliste für die Inter-View-Vorhersage als getrennte Referenzbildliste zu verwalten. Die Syntax wird nachfolgend als eine Ausführungsform des in 15 und 16 erläuterten Inhalts unter Bezugnahme auf die 17, 18 und 19 erklärt.
17 und 18 stellen graphische Darstellungen einer Syntax zum Umordnen von Referenzbildlisten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie 17 entnommen werden kann, wird ein Betriebsvorgang der in 15 gezeigten Referenzbildlistenumordnungseinheit 910 für die zeitliche Vorhersage durch eine Syntax repräsentiert. Verglichen mit den in 15 gezeigten Blöcken entspricht die Slicetyp-Prüfeinheit 642 S1 und S6 und die vierte Identifizierungsinformationsbezugseinheit 940 entspricht S7. Die internen Blöcke der dritten Referenzindexzuordnungs-Änderungseinheit 930 entsprechen jeweils S3, S4 und S5. Ferner entsprechen die internen Blöcke der vierten Referenzindexzuordnungs-Änderungseinheit 950 S8, S9 und S10.
Wie 18 entnommen werden kann, werden die Betriebsvorgänge der NAL-Typ-Prüfeinheit 960 und der Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage durch eine Syntax repräsentiert. Verglichen mit den jeweiligen in 15 und 16 gezeigten Blöcken entspricht die NAL-Typ-Prüfeinheit 960 S11, die Slicetyp-Prüfeinheit 642 S13 und S16, die fünfte Identifizierungsinformationsbezugseinheit 971 S14 und die sechste Identifizierungsinformationsbezugseinheit 973 S17. Die fünfte Referenzindexzuordnungs-Änderungseinheit 972 entspricht S15 und die sechste Referenzindexzuordnungs-Änderungseinheit 974 entspricht S18.
19 stellt eine graphische Darstellung einer Syntax zum Umordnen von Referenzbildlisten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
Wie 19 entnommen werden kann, werden Betriebsvorgänge der NAL-Typ-Prüfeinheit 960 und der Referenzbildlistenumordnungseinheit 970 für die Inter-View-Vorhersage durch eine Syntax repräsentiert. Verglichen mit den jeweiligen in 15 und 16 gezeigten Blöcken entspricht die NAL-Typ-Prüfeinheit 960 S21, die Slicetyp-Prüfeinheit 642 S22 und S25, die fünfte Identifizierungsinformationsbezugseinheit 971 S23 und die sechste Identifizierungsinformationsbezugseinheit 973 S26. Die fünfte Referenzindexzuordnungs-Änderungseinheit 972 entspricht S24 und die sechste Referenzindexzuordnungs-Änderungseinheit 974 entspricht S27.
Wie in der vorhergehenden Beschreibung erwähnt kann die Referenzbildliste für die Inter-View-Vorhersage von der Inter-Vorhersageeinheit 700 verwendet werden und ist auch bei Durchführung einer Beleuchtungskompensation einsetzbar. Die Beleuchtungskompensation ist im Rahmen einer Durchführung einer Bewegungsabschätzung/Bewegungskompensation anwendbar. Falls ein aktuelles Bild ein Referenzbild in einem anderen View verwendet, kann die Beleuchtungskompensation unter Verwendung der Referenzbildliste für die Inter-View-Vorhersage effizienter durchgeführt werden. Die Ausführungsformen der vorliegenden Erfindung gemäßen Beleuchtungskompensationen werden nachfolgend erläutert.
20 stellt ein Diagramm für einen Vorgang gemäß einer Ausführungsform der vorliegenden Erfindung zum Erhalt eines Beleuchtungsdifferenzwertes eines aktuellen Blocks dar.
Unter Beleuchtungskompensation ist ein Vorgang zum Decodieren eines anpassungsfähig bewegungskompensierten Videosignals entsprechend einer Beleuchtungsänderung zu verstehen. Ferner ist diese auf eine Vorhersagestruktur eines Videosignals, wie zum Beispiel Inter-View-Vorhersage, Intra-View-Vorhersage und dergleichen anwendbar.
Unter Beleuchtungskompensation ist ein Vorgang zum Decodieren eines Videosignals unter Verwendung eines Beleuchtungsdifferenzresiduums und eines Beleuchtungsdifferenzvorhersagewerts zu verstehen, die einem zu decodierenden Block entsprechen. In diesem Fall kann der Beleuchtungsdifferenzvorhersagewert von einem zum aktuellen Block benachbarten Block erhalten werden. Über einen Vorgang zum Erhalt eines Beleuchtungsdifferenzvorhersagewerts von einem benachbarten Block kann unter Verwendung einer Referenzinformation für den Nachbarblock entschieden werden, wobei beim Durchsuchen von Nachbarblöcken eine Sequenz und Richtung in Betracht gezogen werden können. Unter einem benachbarten Block sind ein bereits decodierter Block und auch ein Block, der unter Berücksichtigung einer view- oder zeitbezogenen Redundanz innerhalb desselben Bildes decodiert wurde, oder eine Sequenz zu verstehen, die unter Berücksichtigung einer Redundanz innerhalb verschiedener Bilder decodiert wurde.
Beim Vergleichen von Ähnlichkeiten zwischen einem aktuellen Block und einem Referenzblockkandidaten sollte eine Beleuchtungsdifferenz zwischen den beiden Blöcken berücksichtigt werden. Um die Beleuchtungsdifferenz zu kompensieren, wird eine neue Bewegungsabschätzung/-kompensation durchgeführt. Das neue SAD kann mittels Gleichung 1 ermittelt werden. [Gleichung 1]
[Gleichung 2]
Hierbei bezeichnet 'Mcur' einen durchschnittlichen Bildpunktwert eines aktuellen Blocks und 'Mref' bezeichnet einen durchschnittlichen Bildpunktwert eines Referenzblocks. 'f(i, j)' bezeichnet einen Bildpunktwert eines aktuellen Blocks und 'r(i + x, j + y)' bezeichnet einen Bildpunktwert eines Referenzblocks. Durch Ausführen einer Bewegungskompensation auf Grundlage des neuen SAD nach Gleichung 2 kann ein zwischen dem des aktuellen Blocks und dem des Referenzblocks gelegener durchschnittlicher Bildpunktdifferenzwert erhalten werden. Ferner kann der erhaltene durchschnittliche Bildpunktdifferenzwert als Beleuchtungsdifferenzwert (IC_offset) bezeichnet werden.
Beim Durchführen einer Bewegungsabschätzung mit darauf angewandter Beleuchtungskompensation werden ein Beleuchtungsdifferenzwert und ein Bewegungsvektor erzeugt. Ferner wird die Beleuchtungskompensation gemäß Gleichung 3 unter Verwendung des Beleuchtungsdifferenzwertes und des Bewegungsvektors durchgeführt.
[Gleichung 3]

NewR(i, j) = {f(i, j) – M_cur} – {r(i + x', j + y') – M_ref(m + x', n + y')} = {f(i, j) – r(i + x', j + y')} – {M_cur – M_ref(m + x', n + y')} = {f(i, j) – r(i + x', j + y')} – IC_offset

Hierin bezeichnen NewR(i, j) einen beleuchtungskompensierten Fehlerwert (Residuum) und (x', y') einen Bewegungsvektor.
Ein Beleuchtungsdifferenzwert (Mcur-Mref) sollte an die Decodiereinheit übertragen werden. Die Decodiereinheit führt die Beleuchtungskompensation in der folgenden Weise aus.
[Gleichung 4]

f'(i, j) = {NewR''(x', y', i, j) + r(i + x', j + y')} + {M_cur – M_ref(m + x', n + y')} = {NewR'' (x', y', i, j) + r(i + x', j + y')} + IC_offset

In Gleichung 4 bezeichnen NewR''(i, j) einen rekonstruierten beleuchtungskompensierten Fehlerwert (Residuum) und f'(i, j) einen Bildpunktwert eines rekonstruierten aktuellen Blocks.
Zum Rekonstruieren eines aktuellen Blocks sollte ein Beleuchtungsdifferenzwert an die Decodiereinheit übertragen werden. Ferner kann der Beleuchtungsdifferenzwert aus Informationen von benachbarten Blöcken vorhergesagt werden. Um die Bitzahl zum Codieren des Beleuchtungsdifferenzwertes weiter zu reduzieren, kann auch nur ein Differenzwert (RIC_offset) zwischen dem Beleuchtungsdifferenzwert des aktuellen Blocks (IC_offset) und dem Beleuchtungsdifferenzwert des benachbarten Blocks (predIC_offset) gesandt werden. Dies wird durch Gleichung 5 repräsentiert.
[Gleichung 5]

RIC_offset = IC_offset – predIC_offset

21 stellt ein Flussdiagramm eines Vorgangs zur Durchführung einer Beleuchtungskompensation eines aktuellen Blocks gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie 21 zu entnehmen wird zunächst ein Beleuchtungsdifferenzwert eines benachbarten Blocks, der einen durchschnittlichen Bildpunktdifferenzwert zwischen dem zu einem aktuellen Block benachbarten Block und einem von dem benachbarten Block in Bezug genommenen Block angibt, aus einem Videosignal extrahiert (S2110).
Anschließend wird ein Beleuchtungsdifferenzvorhersagewert für eine Beleuchtungskompensation des aktuellen Blocks unter Verwendung des Beleuchtungsdifferenzwerts erhalten (S2120). Somit ist es möglich, einen Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung des erhaltenen Beleuchtungsdifferenzvorhersagewerts zu rekonstruieren.
Zum Erhalt des Beleuchtungsdifferenzvorhersagewerts können diverse Verfahren verwendet werden. Beispielsweise wird vor einem Vorhersagen des Beleuchtungsdifferenzwerts des aktuellen Blocks aus dem Beleuchtungsdifferenzwert des benachbarten Blocks geprüft, ob ein Referenzindex des aktuellen Blocks gleich dem des Nachbarblocks ist. Danach kann entschieden werden, welche Art von Nachbarblock oder Wert entsprechend einem Prüfergebnis verwendet wird. Als weiteres Beispiel kann beim Erhalt des Beleuchtungsdifferenzvorhersagewerts eine Flag-Information (IC_Flag) verwendet werden, die angibt, ob eine Beleuchtungskompensation des aktuellen Blocks durchgeführt wird. Ferner kann eine Flag-Information für den aktuellen Block auch unter Verwendung der Information des benachbarten Blocks vorhergesagt werden. Als weiteres Beispiel kann der Beleuchtungsdifferenzvorhersagewert unter Verwendung von beiden, dem Referenzindexprüfverfahren und dem Flag-Informationsvorhersageverfahren, erhalten werden. Diese werden im Einzelnen nachfolgend unter Bezugnahme auf die 22 bis 24 erläutert.
22 stellt ein Blockschema eines Vorgangs gemäß einer Ausführungsform der vorliegenden Erfindung zum Erhalt eines Beleuchtungsdifferenzvorhersagewerts eines aktuellen Blocks unter Verwendung von Information für einen Nachbarblock dar.
Wie der 22 zu entnehmen kann eine Information für einen benachbarten Block beim Erhalt eines Beleuchtungsdifferenzvorhersagewerts eines aktuellen Blocks verwendet werden. Bei der vorliegenden Offenbarung kann ein Block einen Makroblock oder einen Sub-Makroblock umfassen. Beispielsweise kann ein Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung eines Beleuchtungsdifferenzwerts des benachbarten Blocks vorhergesagt werden. Zuvor wird jedoch geprüft, ob ein Referenzindex des aktuellen Blocks gleich dem eines benachbarten Blocks ist. Entsprechend dem Ergebnis der Prüfung ist dann eine Entscheidung darüber möglich, welche Art eines benachbarten Blocks oder Werts verwendet wird. In 22 bezeichnet 'refIdxLX' einen Referenzindex eines aktuellen Blocks und 'refIdxLXN' einen Referenzindex eines N-Blocks. Hierbei ist 'N' eine Kennzeichnung eines zu dem aktuellen Block benachbarten Blocks und gibt A, B oder C an. Ferner bezeichnet 'PredIC_offsetN' einen Beleuchtungsdifferenzwert für die Beleuchtungskompensation eines benachbarten N-Blocks. Falls die Verwendung eines an einem oberen rechten Ende des aktuellen Blocks gelegenen C-Blocks nicht möglich ist, kann anstatt des C-Blocks ein D-Block verwendet werden. Vornehmlich kann die Information für den D-Block als Information für den C-Block verwendet werden. Wenn weder der B-Block noch der C-Block verwendet werden können, dann kann stattdessen der A-Block verwendet werden. Die Information für den A-Block kann damit ausdrücklich als Information für den B-Block und den C-Block verwendet werden.
Als weiteres Beispiel kann zum Erhalt des Beleuchtungsdifferenzvorhersagewerts eine Flag-Information (IC_flag) verwendet werden, die angibt, ob eine Beleuchtungskompensation des aktuellen Blocks ausgeführt werden soll. Als Alternative können zum Erhalt des Beleuchtungsdifferenzvorhersagewerts sowohl das Referenzindexprüfverfahren als auch das Flag-Informations-Vorhersageverfahren verwendet werden. Hierbei wird der Beleuchtungsdifferenzwert 'PredIC_offsetN' des Nachbarblocks auf 0 gesetzt, wenn die Flag-Information für den Nachbarblock angibt, dass die Beleuchtungskompensation nicht durchgeführt wird, d. h. wenn IC_flag==0.
23 stellt ein Flussdiagramm eines Vorgangs gemäß einer Ausführungsform der vorliegenden Erfindung zur Durchführung einer Beleuchtungskompensation unter Verwendung von Information für einen Nachbarblock dar.
Wie der 23 zu entnehmen extrahiert die Decodiereinheit einen durchschnittlichen Bildpunktwert eines Referenzblocks, einen Referenzindex eines aktuellen Blocks, einen Referenzindex des Referenzblocks und dergleichen aus einem Videosignal und ist dann in der Lage, einen Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks unter Verwendung der extrahierten Information zu erhalten. Die Decodiereinheit erhält einen Differenzwert (Beleuchtungsdifferenzresiduum) zwischen einem Beleuchtungsdifferenzwert des aktuellen Blocks und dem Beleuchtungsdifferenzvorhersagewert und ist dann in der Lage, einen Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung des Beleuchtungsdifferenzresiduums und des Beleuchtungsdifferenzvorhersagewerts zu rekonstruieren. Hierbei kann zum Erhalt des Beleuchtungsdifferenzvorhersagewerts des aktuellen Blocks Information für einen Nachbarblock verwendet werden. Beispielsweise ist es möglich, einen Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung des Beleuchtungsdifferenzwerts des Nachbarblocks vorherzusagen. Zuvor wird jedoch geprüft, ob ein Referenzindex des aktuellen Blocks gleich dem des Nachbarblocks ist. Entsprechend einem Ergebnis der Prüfung kann dann darüber entschieden werden, welche Art eines benachbarten Blocks oder Werts verwendet wird.
Vornehmlich wird aus einem Videosignal ein Beleuchtungsdifferenzwert eines Nachbarblocks extrahiert, der einen durchschnittlichen Bildpunktdifferenzwert zwischen dem Nachbarblock eines aktuellen Blocks und einem Block, auf den von dem Nachbarblock Bezug genommen wird, angibt (S2310).
Anschließend wird geprüft, ob ein Referenzindex des aktuellen Blocks gleich einem Referenzindex von einem von mehreren Nachbarblöcken ist (S2320).
Als Ergebnis des Prüfschrittes S2320 wird, wenn zumindest ein Nachbarblock mit dem selben Referenzindex wie dem des aktuellen Blocks existiert, geprüft, ob ein entsprechender Nachbarblock existiert oder nicht (S2325).
Als Ergebnis des Prüfschrittes S2325 wird, wenn lediglich ein Nachbarblock mit dem selben Referenzindex wie dem des aktuellen Blocks existiert, ein Beleuchtungsdifferenzwert des Nachbarblocks, der den selben Referenzindex wie der aktuelle Block aufweist, einem Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks zugeordnet (S2330). Insbesondere ist 'PredIC_offset = PredIC_offsetN'.
Wenn der Prüfschritt S2330 ergibt, dass kein Nachbarblock existiert, der den selben Referenzindex wie der aktuelle Block aufweist, oder wenn der Prüfschritt S2325 ergibt, dass zumindest zwei Nachbarblöcke den selben Referenzindex wie der aktuelle Block aufweisen, wird einem Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks ein mittlerer Beleuchtungsdifferenzwert (PredIC_offsetN, N = A, B oder C) der Nachbarblöcke zugeordnet (S650). Insbesondere gilt:
'PredIC_offset = Median(PredIC_offsetA, PredIC_offsetB, PredIC_offsetC)'.
24 stellt ein Flussdiagramm eines Vorgangs gemäß einer anderen Ausführungsform der vorliegenden Erfindung zur Beleuchtungskompensation unter Verwendung von Information für einen Nachbarblock dar.
Wie der 24 entnommen werden kann, muss eine Decodiereinheit zum Ausführen einer Beleuchtungskompensation einen Beleuchtungsdifferenzwert eines aktuellen Blocks rekonstruieren. Hierdurch kann Information für einen Nachbarblock zum Erhalt eines Beleuchtungsdifferenzvorhersagewerts des aktuellen Blocks verwendet werden. Beispielsweise kann ein Beleuchtungsdifferenzwert des aktuellen Blocks unter Verwendung des Beleuchtungsdifferenzwerts des Nachbarblocks vorhergesagt werden. Zuvor wird jedoch geprüft, ob ein Referenzindex des aktuellen Blocks gleich dem des Nachbarblocks ist. Entsprechend dem Ergebnis der Prüfung kann dann darüber entschieden werden, welche Art eines Nachbarblocks oder Werts verwendet wird.
Insbesondere wird aus dem Videosignal ein Beleuchtungsdifferenzwert eines Nachbarblocks, der einen durchschnittlichen Bildpunktdifferenzwert zwischen dem Nachbarblock eines aktuellen Blocks und einem Block, auf den der Nachbarblock Bezug nimmt, angibt, extrahiert (S2410).
Anschließend wird geprüft, ob ein Referenzindex des aktuellen Blocks gleich einem Referenzindex von einem oder von mehreren Nachbarblöcken ist (S2420).
Als Ergebnis des Prüfschritts S2420 wird, wenn zumindest ein Nachbarblock existiert, der den selben Referenzindex aufweist wie der aktuelle Block, geprüft, ob ein entsprechender Nachbarblock existiert oder nicht (S2430).
Als Ergebnis des Prüfschritts S2430 wird, wenn nur ein Nachbarblock existiert, der den selben Referenzindex wie der aktuelle Block aufweist, einem Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks ein Beleuchtungsdifferenzwert des Nachbarblocks, der den selben Referenzindex aufweist wie der aktuelle Block, zugewiesen (2440). Insbesondere gilt: 'PredIC_offset = PredIC_offsetN'.
Falls der Prüfschritt S2420 ergibt, dass kein Nachbarblock mit dem selben Referenzindex wie dem des aktuellen Blocks existiert, wird der Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks auf 0 gesetzt (S2460). Insbesondere gilt: 'PreIC_Offset = 0'.
Wenn der Prüfschritt S2430 ergibt, dass zumindest zwei Nachbarblöcke existieren, die den selben Referenzindex wie der aktuelle Block aufweisen, wird der Nachbarblock mit einem zu dem des aktuellen Blocks verschiedenen Referenzindex auf 0 gesetzt und dem Beleuchtungsdifferenzvorhersagewert des aktuellen Blocks wird ein Mittelwert der Beleuchtungsdifferenzwerte der Nachbarblöcke einschließlich des auf 0 gesetzten Werts zugeordnet (S2450). Insbesondere gilt:
'PredIC_offset = Median(PredIC_offsetA, PredIC_offsetB, PredIC_offsetC)'. Falls jedoch der Nachbarblock existiert, der den von dem des aktuellen Blocks verschiedenen Referenzindex aufweist, kann der Wert '0' in PredIC_offsetA, PredIC_offsetB, oder PredIC_offsetC enthalten sein.
Indessen kann eine View-Information zum Identifizieren eines Views eines Bildes und eine Referenzbildliste für die Inter-View-Vorhersage auf das Synthetisieren eines Bildes in einem virtuellen View angewandt werden. Bei einem Vorgang zum Synthetisieren eines Bildes in einem virtuellen View kann auf ein Bild in einem anderen View Bezug genommen werden. Somit kann ein Bild in einem virtuellen View, wenn die View-Information und die Referenzbildliste für die Inter-View-Vorhersage verwendet werden, effizienter synthetisiert werden. In der nachfolgenden Beschreibung werden Ausführungsformen der vorliegenden Erfindung gemäße Verfahren zum Synthetisieren eines Bildes in einem virtuellen View erläutert.
25 stellt ein Blockschema eines Vorgangs gemäß einer Ausführungsform der vorliegenden Erfindung zum Vorhersagen eines aktuellen Bildes unter Verwendung eines Bildes in einem virtuellen View dar.
Wie 25 entnommen werden kann, kann ein aktuelles Bild bei einem Durchführen einer Inter-View-Vorhersage bei der Multi-View-Videocodierung unter Verwendung eines Bildes als Referenzbild vorhergesagt werden, das sich in einem zum aktuellen View verschiedenen View befindet. Ein Bild in einem virtuellen View wird unter Verwendung von Bildern in einem zu dem des aktuellen Bildes benachbarten View erhalten, und das aktuelle Bild wird dann unter Verwendung des erhaltenen Bildes in dem virtuellen View vorhergesagt. In diesem Falle kann die Vorhersage präziser durchgeführt werden. In diesem Falle kann zur Nutzbarmachung von Bildern in Nachbarviews oder von Bildern in einem bestimmten View ein View-Identifikator verwendet werden, der einen View eines Bildes angibt. Falls ein virtueller View erzeugt wird, muss eine spezielle Syntax existieren, um anzugeben, ob der virtuelle View erzeugt werden soll. Wenn die Syntax anzeigt, dass der virtuelle View erzeugt werden soll, kann der virtuelle View unter Verwendung des View-Identifikators erzeugt werden. Die durch die Viewsynthesevorhersageeinheit 740 in dem virtuellen View erhaltenen Bilder können als Referenzbilder verwendet werden. In diesem Fall kann der View-Identifikator den Bildern in dem virtuellen View zugeordnet werden. Bei einem Vorgang zur Durchführung einer Bewegungsvektorvorhersage für das Übertragen eines Bewegungsvektors, können sich Nachbarblöcke eines aktuellen Blocks auf Bilder beziehen, die durch die Viewsynthesevorhersageeinheit 740 erhalten wurden. In diesem Falle kann ein View-Identifikator, der einen View eines Bildes anzeigt, genutzt werden, um ein Bild in dem virtuellen View als Referenzbild zu verwenden.
26 stellt ein Flussdiagramm eines einer Ausführungsform der vorliegenden Erfindung gemäßen Vorgangs zum Synthetisieren eines Bildes eines virtuellen Views bei der Durchführung einer Inter-View-Vorhersage in einer MVC dar.
Wie 26 zu entnehmen wird ein Bild in einem virtuellen View unter Verwendung von Bildern in einem zu dem eines aktuellen Bildes benachbarten View synthetisiert. Das aktuelle Bild wird dann unter Verwendung des synthetisierten Bildes in dem virtuellen View vorhergesagt. In diesem Falle kann eine präzisere Vorhersage erreicht werden. Falls ein Bild in einem virtuellen View synthetisiert wird, existiert eine spezielle Syntax, die anzeigt, ob eine Vorhersage eines aktuellen Bildes durch Synthetisieren des Bildes in dem virtuellen View durchgeführt werden soll. Bei einer Entscheidung darüber, ob die Vorhersage des aktuellen Bildes durchgeführt wird, wird eine effizientere Codierung ermöglicht. Die spezielle Syntax ist als ein Inter-View-Synthesevorhersageidentifikator definiert, der nachfolgend erläutert wird. Beispielsweise wird ein Bild in einem virtuellen View durch eine Sliceebene synthetisiert, um 'view_synthesize_pred_flag' zu definieren, das anzeigt, ob eine Vorhersage eines aktuellen Bildes durchgeführt werden soll. Ferner wird ein Bild in einem virtuellen View durch eine Makroblockebene synthetisiert, um 'view_syn_pred_flag' zu definieren, das anzeigt, ob eine Vorhersage eines aktuellen Bildes durchgeführt werden soll. Ist 'view synthesize pred flag = 1', so synthetisiert ein aktuelles Slice ein Slice in einem virtuellen View unter Verwendung eines Slice in einem zu dem des aktuellen Slice benachbarten View. Eine Vorhersage des aktuellen Slice unter Verwendung des synthetisierten Slice ist dann möglich. Bei 'view_synthesize_pred_flag = 0' wird kein Slice in einem virtuellen View synthetisiert. In ähnlicher Weise synthetisiert ein aktueller Makroblock bei 'view_syn_pred_flag = 1' einen Makroblock in einem virtuellen View unter Verwendung eines Makroblocks in einem zu dem des aktuellen Makroblocks benachbarten View. Der aktuelle Makroblock kann dann unter Verwendung des synthetisierten Makroblocks vorhergesagt werden. Bei 'view_syn_pred_flag = 0' wird kein Makroblock in einem virtuellen View synthetisiert. Mithin wird bei der vorliegenden Erfindung der Inter-View-Synthesevorhersageidentifikator, der angibt, ob ein Bild in einem virtuellen View erhalten werden soll, aus einem Videosignal extrahiert. Das Bild in dem virtuellen View kann dann unter Verwendung des Inter-View-Synthesevorhersageidentifikators erhalten werden.
Wie in der vorhergehenden Beschreibung erwähnt können von der Inter-Vorhersageeinheit 700 eine View-Information zum Identifizieren eines Views eines Bildes und eine Referenzbildliste für die Inter-View-Vorhersage verwendet werden. Ferner können diese auch bei der Durchführung einer gewichteten Vorhersage verwendet werden. Die gewichtete Vorhersage kann auf einen Vorgang zur Durchführung einer Bewegungskompensation angewandt werden. Wird dies gemacht, dann kann die gewichtete Vorhersage, wenn ein aktuelles Bild ein Referenzbild in einem anderen View verwendet, unter Verwendung der View-Information und der Referenzbildliste für die Inter-View-Vorhersage effizienter durchgeführt werden. Gewichtete Vorhersageverfahren gemäß Ausführungsformen der vorliegenden Erfindung werden nachfolgend erläutert.
27 stellt ein Flussdiagramm eines der vorliegenden Erfindung gemäßen Verfahrens zur Durchführung einer gewichteten Vorhersage entsprechend einem Slicetyp in einer Videosignalcodierung dar.
Wie der 27 entnommen werden kann, stellt die gewichtete Vorhersage ein Verfahren zum Skalieren einer Auswahl von bewegungskompensierten Vorhersagedaten innerhalb eines P-Slice-B-Slice-Makroblocks dar. Ein gewichtetes Vorhersageverfahren umfasst einen Explizitmodus zur Durchführung einer gewichteten Vorhersage für ein aktuelles Bild unter Verwendung einer gewichteten Koeffizienteninformation, die von einer Information für Referenzbilder erhalten wird, und einen Implizitmodus zur Durchführung einer gewichteten Vorhersage für ein aktuelles Bild unter Verwendung einer gewichteten Koeffizienteninformation, die von einer Information für eine Entfernung zwischen dem aktuellen Bild und einem der Referenzbilder erhalten wird. Das gewichtete Vorhersageverfahren kann entsprechend einem Slicetyp eines Makroblocks unterschiedlich angewandt werden. Beispielsweise kann die gewichtete Koeffizienteninformation im Explizitmodus abhängig davon variiert werden, ob ein aktueller Makroblock, an dem eine gewichtete Vorhersage durchgeführt wird, ein Makroblock eines P-Slices oder ein Makroblock eines B-Slices ist. Ferner kann über den gewichteten Koeffizienten des Explizitmodus durch einen Codierer entschieden werden, und er kann durch Aufnahme in einen Slice-Header übertragen werden. Andererseits kann ein gewichteter Koeffizient im Implizitmodus auf Basis einer relativen zeitlichen Position von Liste 0 und Liste 1 erhalten werden. Beispielsweise kann, wenn sich ein Referenzbild in zeitlicher Nähe zu einem aktuellen Bild befindet, ein großer gewichteter Koeffizient angewandt werden. Falls sich ein Referenzbild in zeitlicher Ferne zu einem aktuellen Bild befindet, kann ein kleiner gewichteter Koeffizient angewandt werden.
Als Erstes wird aus einem Videosignal ein Slicetyp eines Makroblocks extrahiert, auf den eine gewichtete Vorhersage anzuwenden ist (S2710).
Anschließend kann an einem Makroblock entsprechend dem extrahierten Slicetyp eine gewichtete Vorhersage durchgeführt werden (S2720).
Hierbei kann der Slicetyp einen Makroblock umfassen, auf den eine Inter-View-Vorhersage angewandt wird. Unter Inter-View-Vorhersage ist zu verstehen, dass ein aktuelles Bild unter Verwendung von Information für ein Bild in einem von dem des aktuellen Bildes verschiedenen View vorhergesagt wird. Beispielsweise kann der Slicetyp einen Makroblock, auf den eine zeitliche Vorhersage zur Durchführung einer Vorhersage unter Verwendung von Information für ein Bild in dem selben View wie dem eines aktuellen Bildes angewandt wird, einen Makroblock, auf den die Inter-View-Vorhersage angewandt wird, und einen Makroblock, auf den sowohl die zeitliche Vorhersage als auch die Inter-View-Vorhersage angewandt werden, umfassen. Ferner kann der Slicetyp einen Makroblock, auf den lediglich eine zeitliche Vorhersage angewandt wird, einen Makroblock, auf den lediglich eine Inter-View-Vorhersage angewandt wird, oder einen Makroblock, auf den sowohl die zeitliche Vorhersage als auch die Inter-View-Vorhersage angewandt werden, umfassen. Außerdem kann der Slicetyp zwei dieser Makroblocktypen oder alle drei Makroblocktypen umfassen. Dies wird später im Einzelnen unter Bezugnahme auf die 28 erläutert. Daher wird in dem Fall, dass aus dem Videosignal ein Slicetyp extrahiert wird, der einen Makroblock mit darauf angewandter Inter-View-Vorhersage enthält, eine gewichtete Vorhersage unter Verwendung von Information für ein Bild in einem View, der sich von dem eines aktuellen Bildes unterscheidet, durchgeführt. Auf diese Art kann ein View-Identifikator zum Identifizieren eines Views eines Bildes genutzt werden, um Informationen für ein Bild in einem anderen View zu verwenden.
28 stellt eine graphische Darstellung von Makroblocktypen dar, die in einem Slicetyp einer Videosignalcodierung gemäß einer Ausführungsform der vorliegenden Erfindung zulässig sind.
Wie der 28 entnommen werden kann, sind, wenn ein P-Slicetyp bei einer Inter-View-Vorhersage als VP (View_P) definiert ist, ein Intra-Makroblock I, ein aus einem Bild in einem aktuellen View vorhergesagter Makroblock P, oder ein aus einem Bild in einem anderen View vorhergesagter Makroblock VP für den P-Slicetyp bei der Inter-View-Vorhersage zulässig (2810).
Falls ein B-Slicetyp bei einer Inter-View-Vorhersage als VB (View_B) definiert ist, sind ein aus zumindest einem Bild in einem aktuellen View vorhergesagter Makroblock P oder B, oder ein aus zumindest einem Bild in einem anderen View vorhergesagter Makroblock VP oder VB zulässig (2820).
Falls ein Slicetyp, an dem eine Vorhersage unter Verwendung einer zeitlichen Vorhersage, einer Inter-View-Vorhersage, oder sowohl einer zeitlichen Vorhersage als auch einer Inter-View-Vorhersage durchgeführt wird, als 'Mixed' definiert ist, sind für den gemischten Slicetyp ein Intra-Makroblock I, ein aus zumindest einem Bild in einem aktuellen View vorhergesagter Makroblock P oder B, ein aus zumindest einem Bild in einem anderen View vorhergesagter Makroblock VP oder VB, oder ein unter Verwendung von sowohl dem Bild in dem aktuellen View als auch dem Bild in dem anderen View hervorgesagter Makroblock 'Mixed' zulässig (2830). Hierbei kann zur Verwendung des Bildes in dem anderen View ein View-Identifikator zum Identifizieren eines Views eines Bildes verwendet werden.
29 und 30 stellen graphische Darstellungen einer Syntax zur Durchführung einer gewichteten Vorhersage entsprechend einem neu definierten Slicetyp gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie in der vorhergehenden Beschreibung der 28 erwähnt wurde, kann, wenn der Slicetyp als VP, VB oder Mixed bestimmt ist, die Syntax zur Durchführung der herkömmlichen gewichteten Vorhersage (z. B. H.264) in die der 29 bzw. 30 abgeändert werden.
Beispielsweise wird, wenn es sich bei einem Slicetyp um ein P-Slice bei der zeitlichen Vorhersage handelt, ein Teil 'if(slice_type!=VP||slice_type!=VB)' hinzugefügt (2910).
Wenn es sich bei einem Slicetyp um ein B-Slice bei der zeitlichen Vorhersage handelt, kann die if-Anweisung in 'if(slice_type==B||slice_type==Mixed)' abgeändert werden (2920).
Durch die Neudefinition eines VP-Slicetyps und eines VB-Slicetyps kann ein der 29 ähnliches Format neu hinzugefügt werden (2930, 2940). Hierbei umfassen die Syntaxelemente jeweils 'View'-Teile, da Information für einen View hinzugefügt wird. Als Beispiel können 'luma_log2_view_weight_denom, chroma_log2_view_denom' angeführt werden.
31 stellt ein Flussdiagramm eines Verfahrens zur gewichteten Vorhersage unter Verwendung einer Flag-Information dar, die angibt, ob eine gewichtete Inter-View-Vorhersage bei einer Videosignalcodierung gemäß der vorliegenden Erfindung durchzuführen ist.
Wie der 31 entnommen werden kann, wird bei einer Videosignalcodierung, auf die die vorliegende Erfindung angewandt wird, im Falle einer Verwendung einer Flag-Information, die angibt, ob eine gewichtete Vorhersage ausgeführt wird, eine effizientere Codierung ermöglicht.
Die Flag-Information kann auf Basis eines Slicetyps definiert sein. Beispielweise kann eine Flag-Information vorhanden sein, die angibt, ob eine gewichtete Vorhersage auf ein P-Slice oder ein SP-Slice angewandt wird, oder Flag-Information, die angibt, ob eine gewichtete Vorhersage auf ein B-Slice angewandt wird.
Die Flag-Information kann insbesondere als 'weighted_pred_flag' oder 'weighted_bipred_idc' definiert sein. Bei 'weighted_pred_flag=0' wird angezeigt, dass auf das P-Slice und das SP-Slice keine gewichtete Vorhersage angewandt wird. Bei 'weighted_pred_flag=1' wird angezeigt, dass auf den P-Slice und den SP-Slice eine gewichtete Vorhersage angewandt wird. Bei 'weighted_bipred_idc=0' wird angezeigt, dass auf das B-Slice eine standardmäßige gewichtete Vorhersage angewandt wird. Bei 'weighted_bipred_idc=1' wird angezeigt, dass auf das B-Slice eine explizite gewichtete Vorhersage angewandt wird. Bei 'weighted_bipred_idc=2' wird angezeigt, dass auf das B-Slice eine implizite gewichtete Vorhersage angewandt wird
Bei der Multi-View-Videocodierung kann eine Flag-Information, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Inter-View-Bild durchzuführen ist, auf Basis eines Slicetyps definiert sein.
Zunächst werden aus einem Videosignal ein Slicetyp und eine Flag-Information, die angibt, ob eine Inter-View gewichtete Vorhersage auszuführen ist, extrahiert (S3110, S3120). In diesem Falle kann der Slicetyp einen Makroblock, auf den eine zeitliche Vorhersage zur Durchführung einer Vorhersage unter Verwendung einer Information für ein Bild in dem selben View wie dem eines aktuellen Bildes angewandt wird, und einen Makroblock umfassen, auf den eine Inter-View-Vorhersage zur Durchführung einer Vorhersage unter Verwendung einer Information für ein Bild in einem anderen View als dem eines aktuellen Bildes angewandt wird.
Danach kann auf Basis des extrahierten Slicetyps und der extrahierten Flag-Information über einen gewichteten Vorhersagemodus entschieden werden (S3130).
Anschließend kann die gewichtete Vorhersage entsprechend dem aus der Entscheidung hervorgegangenen gewichteten Vorhersagemodus durchgeführt werden (S3140). Die Flag-Information kann hierbei eine Flag-Information umfassen, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Bild in einem zu dem des aktuellen Bildes unterschiedlichen View durchgeführt wird, als auch die vorgenannten 'weighted_pred_flag' und 'weighted_bipred_flag'. Dies wird im Einzelnen später unter Bezugnahme auf 32 erläutert.
Im dem Fall, dass es sich bei einem Slicetyp eines aktuellen Blocks um einen Slicetyp handelt, der einen Makroblock umfasst, auf den eine Inter-View-Vorhersage angewandt wird, wird daher eine effizientere Codierung ermöglicht als in einem Fall, bei dem eine Flag-Information verwendet wird, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Bild in einem anderen View durchgeführt wird.
32 stellt eine graphische Darstellung zur Erläuterung eines Verfahrens nach einer Ausführungsform der vorliegenden Erfindung zur gewichteten Vorhersage entsprechend einer Flag-Information dar, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Bild in einem von dem des aktuellen Bildes verschiedenen View durchzuführen ist.
Wie der 32 zum Beispiel entnommen werden kann, kann eine Flag-Information, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Bild in einem zu dem des aktuellen Bildes verschiedenen View durchgeführt werden wird, als 'view_weighted_predflag' oder 'view_weighted_bipred_flag' definiert werden.
Bei 'view_weighted_pred_flag'=0' wird angezeigt, dass die gewichtete Vorhersage nicht auf ein VP-Slice angewandt wird. Bei 'view_weighted_pred_flag=1' wird auf ein VP-Slice eine explizite gewichtete Vorhersage angewandt. Bei 'view_weighted_bipred_flag=0' wird angezeigt, dass die standardmäßige gewichtete Vorhersage auf ein VB-Slice angewandt wird. Bei 'view_weighted_bipred_flag=1' wird angezeigt, dass eine explizite gewichtete Vorhersage auf ein VB-Slice angewandt wird. Bei 'view_weighted_bipred_flag=2' wird angezeigt, dass eine implizite standardmäßige gewichtete Vorhersage auf ein VB-Slice angewandt wird.
Wenn auf ein VB-Slice eine implizite gewichtete Vorhersage angewandt wird, kann aus der relativen Entfernung zwischen einem aktuellen View und einem anderen View ein Gewichtungskoeffizient erhalten werden. Wird eine implizite gewichtete Vorhersage auf ein VB-Slice angewandt, dann kann die gewichtete Vorhersage unter Verwendung eines View-Identifikators durchgeführt werden, der einen View eines Bildes oder einen sich aus der Berücksichtigung einer Differenzierung eines jeden View ergebenden Bildfolgezähler (POC) identifiziert.
Die oben angegebene Flag-Information kann in einem Bildparametersatz (PPS, von picture parameter set) enthalten sein. Unter einem Bildparametersatz (PPS) ist hierbei eine Headerinformation zu verstehen, die einen Codiermodus (z. B. Entropiecodiermodus, Quantisierungsparameteranfangswert pro Bildeinheit (quantization parameter initial value by picture unit) usw.) für alle Bilder angibt. Der Bildparametersatz ist jedoch nicht an alle Bilder angefügt. Falls kein Bildparametersatz vorhanden ist, wird ein unmittelbar zuvor existenter Bildparametersatz als Headerinformation verwendet.
33 stellt ein Diagramm einer Syntax zur Durchführung einer gewichteten Vorhersage gemäß der neu definierten Flag-Information nach einer Ausführungsform der vorliegenden Erfindung dar.
Wie der 33 zu entnehmen ist, muss bei einer Multi-Videocodierung, auf die die vorliegende Erfindung angewandt wird, in dem Fall, dass ein Slicetyp definiert ist, der einen auf die Inter-View-Vorhersage angewandten Makroblock und eine Flag-Information aufweist, die angibt, ob eine gewichtete Vorhersage unter Verwendung einer Information für ein Bild in einem zu dem eines aktuellen Bildes verschiedenen View auszuführen ist, darüber entschieden werden, welche Art von gewichteter Vorhersage entsprechend einem Slicetyp ausgeführt wird.
Wenn es sich beispielsweise bei einem aus einem Videosignal extrahierten Slicetyp wie in 33 gezeigt um ein P-Slice oder ein SP-Slice handelt, dann kann eine gewichtete Vorhersage durchgeführt werden, wenn 'weighted_pred_flag=1'. Wenn es sich bei dem Slicetyp um ein B-Slice handelt, kann eine gewichtete Vorhersage durchgeführt werden, wenn 'weighted_bipred_flag=1'. Wenn es sich bei einem Slicetyp um ein VP-Slice handelt, kann eine gewichtete Vorhersage durchgeführt werden, wenn 'view_weighted_pred_flag=1'. Wenn es sich bei einem Slicetyp um ein VB-Slice handelt, kann eine gewichtete Vorhersage durchgeführt werden, wenn 'view_weighted_bipred_flag=1'.
34 stellt ein Flussdiagramm eines Verfahrens zur Durchführung einer gewichteten Vorhersage gemäß einer NAL-Einheit (Netzwerk-Abstraktionsschicht-Einheit) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie 34 zu entnehmen ist, wird aus dem Videosignal zunächst ein NAL-Einheitstyp (nal_unit_type) extrahiert (S3410). Unter NAL-Einheitstyp ist hierbei ein Identifikator zu verstehen, der einen Typ einer NAL-Einheit angibt. Beispielsweise ist eine NAL-Einheit bei 'nal_unit_type = 5' ein Slice in einem IDR-Bild, wobei unter IDR(instantaneous decoding refresh, momentane Decodierungsaktualisierung)-Bild ein einer Videosequenz voranstehendes Bild zu verstehen ist.
Anschließend wird geprüft, ob der extrahierte NAL-Einheitstyp ein NAL-Einheitstyp für die Multi-View-Videocodierung ist (S3420).
Wenn es sich bei dem NAL-Einheitstyp um einen NAL-Einheitstyp für eine Multi-View-Videocodierung handelt, wird eine gewichtete Vorhersage unter Verwendung von Information für ein Bild in einem von dem des aktuellen Bildes verschiedenen View ausgeführt (S3430). Der NAL-Einheitstyp kann ein NAL-Einheitstyp sein, der sowohl auf skalierbare Videocodierung als auch auf Multi-View-Videocodierung anwendbar ist, oder ein NAL-Einheitstyp ausschließlich für die Multi-View-Videocodierung. Bei einem NAL-Einheitstyp für die Multi-View-Videocodierung sollte die gewichtete Vorhersage daher unter Verwendung von Information für das Bild in dem von dem des aktuellen Bildes verschiedenen View durchgeführt werden. Daher muss eine neue Syntax definiert werden. Dies wird nachfolgend im Einzelnen unter Bezugnahme auf. 35 und 36 erläutert.
35 und 36 stellen graphische Darstellungen einer Syntax zur Durchführung einer gewichteten Vorhersage für den Fall eines zur Multi-View-Videocodierung vorgesehenen NAL-Einheitstyps gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wenn es sich bei einem NAL-Einheitstyp um einen NAL-Einheitstyp für die Multi-View-Videocodierung handelt, kann eine Syntax zur Durchführung einer herkömmlichen gewichteten Vorhersage (z. B. H.264) zunächst in eine in 35 bzw. 36 gezeigte Syntax abgeändert werden. Beispielsweise bezeichnet das Bezugszeichen 3510 einen Syntaxabschnitt zur Durchführung einer herkömmlichen gewichteten Vorhersage und das Bezugszeichen 3520 einen Syntaxabschnitt zur Durchführung einer gewichteten Vorhersage für die Multi-View-Videocodierung. Die gewichtete Vorhersage wird daher nur dann mittels des Syntaxabschnitts 3520 durchgeführt, wenn es sich bei dem NAL-Einheitstyp um den NAL-Einheitstyp für die Multi-View-Videocodierung handelt. Da in diesem Fall eine Information für einen View hinzugefügt wird, enthält jedes Syntaxelement einen 'view'-Abschnitt. Beispielsweise gibt es ein 'luma_view_log2_weight_denom, ein chroma_view_log2_weight_denom' oder dergleichen. Ferner gibt das Bezugszeichen 3530 in 36 einen Syntaxabschnitt zur Durchführung einer herkömmlichen gewichteten Vorhersage an und das Bezugszeichen 3540 in 36 gibt einen Syntaxabschnitt zur Durchführung einer gewichteten Vorhersage für die Multi-View-Videocodierung an. Somit wird die gewichtete Vorhersage beim Syntaxabschnitt 3540 nur dann durchgeführt, wenn es sich bei dem NAL-Einheitstyp um den NAL-Einheitstyp für die Multi-View-Videocodierung handelt. Desgleichen enthält jedes Syntaxelement, da Information für einen View hinzugefügt wird, einen 'view'-Abschnitt. Beispielsweise gibt es 'luma_view_weight_11_flag, chroma_view_weight_11_flag' oder dergleichen. Eine Definition eines NAL-Einheitstyps für die Multi-View-Videocodierung ermöglicht daher eine effizientere Codierung und eine Art zur Durchführung einer gewichteten Vorhersage unter Verwendung von Information für ein Bild in einem von dem des aktuellen Bildes verschiedenen View.
37 stellt ein Blockschema einer Vorrichtung zum Decodieren eines Videosignals nach einer Ausführungsform der vorliegenden Erfindung dar.
Wie 37 zu entnehmen umfasst eine Vorrichtung zum Decodieren eines Videosignals gemäß der vorliegenden Erfindung eine Slicetypextraktionseinheit 3710, eine Vorhersagemodusextraktionseinheit 3720 und eine Decodiereinheit 3730.
38 stellt ein Flussdiagramm eines Verfahrens zum Decodieren eines Videosignals in der in 37 gezeigten Decodiervorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie 38 zu entnehmen umfasst ein Verfahren zum Decodieren eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung einen Schritt S3810 zum Extrahieren eines Slicetyps und eines Makroblock-Vorhersagemodus, sowie einen Schritt S3820 zum Decodieren eines aktuellen Makroblocks gemäß dem Slicetyp und/oder Makroblock-Vorhersagemodus.
Zunächst wird zum besseren Verständnis der vorliegenden Erfindung ein von einer Ausführungsform der vorliegenden Erfindung verwendetes Vorhersageschema erläutert. Das Vorhersageschema kann in eine Intra-View-Vorhersage (z. B. Vorhersage zwischen Bildern innerhalb des selben Views) und eine Inter-View-Vorhersage (z. B. Vorhersage zwischen Bildern in verschiedenen Views) eingeteilt werden. Ferner kann die Intra-View-Vorhersage das selbe Vorhersageschema wie eine übliche zeitliche Vorhersage aufweisen.
Gemäß der vorliegenden Erfindung extrahiert die Slicetypextraktionseinheit 3710 einen Slicetyp eines Slice, der einen aktuellen Makroblock enthält (S3810).
Hierbei können ein Slicetypfeld (slice_type), das einen Slicetyp für die Intra-View-Vorhersage angibt, und/oder ein Slicetypfeld (view_slice_type), das einen Slicetyp für die Inter-View-Vorhersage angibt, als Teil der Videosignalsyntax zum Zurverfügungstellen des Slicetyps vorgesehen sein. Dies wird unten unter Bezugnahme auf die 6(a) und 6(b) genauer beschrieben. Ferner können sowohl der Slicetyp (slice_type) zur Intra-View-Vorhersage als auch der Slicetyp (view_slice_type) zur Inter-View-Vorhersage zum Beispiel einen I-Slicetyp (I_SLICE), einen P-Slicetyp (P_SLICE) oder einen B-Slicetyp (B_SLICE) angeben.
Wenn es sich zum Beispiel bei 'slice_type' eines bestimmten Slices um ein B-Slice handelt und bei 'view_slice_type' um ein P-Slice, dann wird ein Makroblock in dem bestimmten Slice nach einem B-Slice-Codierschema (B_SLICE) in einer Intra-View-Richtung decodiert (d. h. in einer Zeitrichtung) und/oder nach einem P-Slicecodierschema (P_Slice) in einer Viewrichtung.
Indes kann der Slicetyp einen P-Slicetyp (VP) zur Inter-View-Vorhersage, einen B-Slicetyp (VB) zur Inter-View-Vorhersage und einen gemischten Slicetyp (Mixed) für eine aus dem Mischen beider Vorhersagetypen resultierende Vorhersage umfassen. Genauer gesagt ermöglicht der gemischte Slicetyp eine Vorhersage durch Verwenden einer Kombination aus Intra-View- und Inter-View-Vorhersage.
Hierbei ist unter einem P-Slicetyp zur Inter-View-Vorhersage ein Fall zu verstehen, bei dem jeder in einem Slice enthaltene Makroblock oder Makroblockteil aus einem Bild in einem aktuellen View oder einem Bild in einem anderen View vorhergesagt wird. Unter einem B-Slicetyp zur Inter-View-Vorhersage ist ein Fall zu verstehen, bei dem jeder in einem Slice enthaltene Makroblock oder Makroblockteil aus 'einem oder zwei Bildern in einem aktuellen View' oder 'einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views' vorhergesagt wird. Ferner ist unter einem gemischten Slicetyp für eine aus einem Mischen beider Vorhersagemöglichkeiten resultierende Vorhersage ein Fall zu verstehen, bei dem jeder in einem Slice enthaltene Makroblock oder Makroblockteil aus 'einem oder zwei Bildern in einem aktuellen View', 'einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views', oder 'einem oder zwei Bildern in einem aktuellen View und einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views' vorhergesagt wird.
Mit anderen Worten unterscheiden sich, wie später im Einzelnen unter Bezugnahme auf 43 und 44 erläutert werden wird, ein in Bezug genommenes Bild und ein zulässiger Makroblocktyp in jedem Slicetyp.
Ferner wird die Syntax unter den zuvor angegebenen Ausführungsformen des Slicetyps später im Einzelnen unter Bezugnahme auf 40 und 41 erläutert.
Die Vorhersagemodusextraktionseinheit 3720 kann einen Makroblock-Vorhersagemodusindikator extrahieren, der angibt, ob es sich bei dem aktuellen Makroblock um einen Makroblock zur Intra-View-Vorhersage handelt, einen Makroblock zur Inter-View-Vorhersage oder einen Makroblock für eine aus einem Mischen beider Vorhersagetypen resultierenden Vorhersage (S3820). Hierfür definiert die vorliegende Erfindung einen Makroblock-Vorhersagemodus (mb_pred_mode). Eine Ausführungsform des Makroblock-Vorhersagemodus wird später im Einzelnen unter Bezugnahme auf die 39, 40 und die 41 erläutert.
Die Decodiereinheit 3730 decodiert den aktuellen Makroblock entsprechend dem Slicetyp und/oder dem Makroblock-Vorhersagemodus, um den aktuellen Makroblock zu empfangen/erzeugen (S3820). In diesem Fall kann der aktuelle Makroblock entsprechend dem aus der Makroblocktypinformation bestimmten Makroblocktyp des aktuellen Makroblocks decodiert werden. Ferner kann der Makroblocktyp gemäß dem Makroblock-Vorhersagemodus und dem Slicetyp bestimmt werden.
Falls es sich bei dem Makroblock-Vorhersagemodus um einen Modus zur Intra-View-Vorhersage handelt, wird der Makroblocktyp entsprechend einem Slicetyp zur Intra-View-Vorhersage bestimmt, woraufhin der aktuelle Makroblock mittels Intra-View-Vorhersage entsprechend dem bestimmten Makroblocktyp decodiert wird.
Falls es sich bei dem Makroblock-Vorhersagemodus um einen Modus zur Inter-View-Vorhersage handelt, wird der Makroblocktyp entsprechend einem Slicetyp zur Inter-View-Vorhersage bestimmt, woraufhin der aktuelle Makroblock mittels Inter-View-Vorhersage entsprechend dem bestimmten Makroblocktyp decodiert wird.
Falls es sich bei dem Makroblock-Vorhersagemodus um einen Modus für eine aus einem Mischen beider Vorhersagetypen resultierenden Vorhersage handelt, wird der Makroblocktyp entsprechend einem Slicetyp zur Intra-View-Vorhersage und einem Slicetyp zur Inter-View-Vorhersage bestimmt, woraufhin der aktuelle Makroblock mittels der aus einem Mischen beider Vorhersagetypen resultierenden Vorhersage entsprechend einem jeden der bestimmten Makroblocktypen decodiert wird.
In diesem Fall hängt der Makroblocktyp von einem Makroblock-Vorhersagemodus und einem Slicetyp ab. Insbesondere kann ein für einen Makroblocktyp zu verwendendes Vorhersageschema aus einem Makroblock-Vorhersagemodus bestimmt werden, woraufhin dann ein Makroblocktyp aus einer Makroblocktypinformation durch einen Slicetyp entsprechend dem Vorhersageschema bestimmt wird. Und zwar werden einer oder beide der extrahierten slice_type und view_slice_type auf Basis des Makroblock-Vorhersagemodus ausgewählt.
Beispielsweise kann ein Makroblocktyp, wenn es sich bei einem Makroblock-Vorhersagemodus um einen Modus zur Inter-View-Vorhersage handelt, aus einer Makroblocktabelle von Slicetypen (I, P, B) bestimmt werden, die einem Slicetyp (view_slice_type) zur Inter-View-Vorhersage entsprechen. Die Beziehung zwischen einem Makroblock-Vorhersagemodus und einem Makroblocktyp wird später im Einzelnen unter Bezugnahme auf die 39, 40 und 41 erläutert.
39 stellt eine graphische Darstellung eines Makroblock-Vorhersagemodus gemäß einer Ausführungsform der vorliegenden Erfindung dar.
39(a) zeigt eine Tabelle gemäß einer Ausführungsform eines Makroblock-Vorhersagemodus (mb_pred_mode) gemäß der vorliegenden Erfindung.
Im Falle einer Intra-View-Vorhersage, d. h. für den Makroblock wird ausschließlich eine zeitliche Vorhersage verwendet, wird einem Wert von 'mb_pred_mode' '0' zugeordnet. Im Falle einer ausschließlichen Verwendung einer Inter-View-Vorhersage für den Makroblock, wird einem Wert von 'mb_pred_mode' '1' zugeordnet. Im Falle, dass sowohl zeitliche als auch Inter-View-Vorhersage für den Makroblock verwendet werden, wird einem Wert von 'mb_pred_mode' '2' zugeordnet.
Wenn ein Wert von 'mb_pred_mode' in diesem Fall '1' ist, d. h., wenn der 'mb_pred_mode' die Inter-View-Vorhersage anzeigt, werden Viewrichtungsliste 0 (ViewList0) oder Viewrichtungsliste 1 (ViewList1) als Referenzbildliste für die Inter-View-Vorhersage definiert.
39(b) zeigt die Beziehung zwischen einem Makroblock-Vorhersagemodus und einem Makroblocktyp gemäß einer anderen Ausführungsform.
Wenn der Wert von 'mb_pred_mode' '0' ist, wird ausschließlich zeitliche Vorhersage verwendet. Ferner wird ein Makroblocktyp entsprechend einem Slicetyp (slice_type) zur Intra-View-Vorhersage bestimmt.
Wenn ein Wert von 'mb_pred_mode' '1' ist, wird ausschließlich eine Inter-View-Vorhersage verwendet. Ferner wird ein Makroblocktyp entsprechend einem Slicetyp (view_slice_type) zur Inter-View-Vorhersage bestimmt.
Wenn ein Wert von 'mb_pred_mode' '2' ist, wird eine aus sowohl zeitlicher wie Intra-View-Vorhersage gemischte Vorhersage verwendet. Ferner werden zwei Makroblocktypen entsprechend einem Slicetyp (slice_type) zur Intra-View-Vorhersage und einem Slicetyp (view_slice_type) zur Inter-View-Vorhersage bestimmt.
Basierend auf dem Makroblock-Vorhersagemodus wird der Makroblocktyp auf Basis des wie in den untenstehenden Tabellen 1-3 gezeigten Slicetyps angegeben. [Hier bitte die Tabellen 7-12. 7-14 in N6540 als Tabellen 1-3 einfügen]
Mit anderen Worten wird in dieser Ausführungsform ein Vorhersageschema, das für einen Makroblock verwendet wird, und ein in Bezug genommener Slicetyp durch einen Makroblock-Vorhersagemodus bestimmt. Ferner wird ein Makroblocktyp dem Slicetyp entsprechend bestimmt.
40 und 41 stellen Diagramme von Ausführungsbeispielen der Syntax von einem Teil des von der Vorrichtung zum Decodieren des Videosignals empfangenen Videosignals dar. Wie gezeigt weist die Syntax eine Slicetyp- und Makroblock-Vorhersagemodusinformation gemäß einer Ausführungsform der vorliegenden Erfindung auf.
In 40 ist ein Syntaxbeispiel gezeigt. In der Syntax stellen das Feld 'slice_typ' und das Feld 'view_slice_typ' Slicetypen zur Verfügung und das Feld 'mb_pred_mode' stellt einen Makroblock-Vorhersagemodus zur Verfügung.
Gemäß der vorliegenden Erfindung stellt das 'slice_type'-Feld einen Slicetyp zur Intra-View-Vorhersage zur Verfügung und das 'view_slice_type'-Feld stellt einen Slicetyp zur Inter-View-Vorhersage zur Verfügung. Jeder der Slicetypen kann zu einem I-Slicetyp, P-Slicetyp oder B-Slicetyp werden. Falls 'mb_pred_mode' einen Wert von '0' oder '1' aufweist, ist ein Makroblocktyp bestimmt. Falls der Wert vom 'mb_pred_mode' jedoch '2' ist, lässt sich erkennen, dass noch ein Makroblocktyp (oder zwei Typen) bestimmt werden muss. Mit anderen Worten zeigt die in (a) von 40 gezeigte Syntax an, dass 'view_slice_type' hinzugefügt wurde, damit die herkömmlichen Slicetypen (I, P, B) weiterhin auch auf die Multi-View-Videocodierung angewandt werden können.
41 zeigt ein anderes Syntaxbeispiel. In der Syntax wird ein 'slice_type'-Feld verwendet, um einen Slicetyp zur Verfügung zu stellen, und ein 'mb_pred_mode'-Feld, um einen Makroblock-Vorhersagemodus zur Verfügung zu stellen.
Gemäß der vorliegenden Erfindung kann das 'slice_type'-Feld unter anderem einen Slicetyp (VP) zur Inter-View-Vorhersage, einen Slicetyp (VB) zur Inter-View-Vorhersage und einen gemischetn Slicetyp (Mixed) für eine aus einem Mischen beider, der Intra-View- und der Inter-View-Vorhersage, resultierenden Vorhersage aufweisen.
Wenn der Wert im 'mb_pred_mode'-Feld '0' oder '1' ist, wird ein Macroblocktyp bestimmt. Falls der Wert im 'mb_pred_mode'-Feld jedoch '2' ist, lässt sich erkennen, dass noch ein zusätzlicher (d. h. insgesamt zwei) Makroblocktyp bestimmt werden muss. Bei dieser Ausführungsform liegt die Slicetypinformation in einem Sliceheader vor, der im Einzelnen unter Bezugnahme auf 42 erläutert wird. Mit anderen Worten zeigt die in 41 gezeigte Syntax an, dass die Slicetypen VP, VB und Mixed den herkömmlichen Slicetypen (sice_type) hinzugefügt werden.
42 stellt eine graphische Darstellung von Beispielen zum Anwenden der in 41 gezeigten Slicetypen dar.
Die graphische Darstellung von 42(a) zeigt, dass in einem Sliceheader zusätzlich zu anderen Slicetypen ein P-Slicetyp (VP) für die Inter-View-Vorhersage, ein B-Slicetyp (VB) für die Inter-View-Vorhersage und ein gemischter Slicetyp (Mixed) für eine aus einem Mischen beider Vorhersagen resultierende Vorhersage als Slicetyp vorhanden sein können. Insbesondere werden gemäß einem Ausführungsbeispiel die Slicetypen VP, VB und Mixed zu den eventuell in einem üblichen Sliceheader vorhandenen Slicetypen hinzugefügt.
Die graphische Darstellung von 42(b) zeigt, dass in einem Sliceheader für die Multi-View-Videocodierung (MVC) ein P-Slicetyp (VP) für die Inter-View-Vorhersage, ein B-Slicetyp (VB) für die Inter-View-Vorhersage und ein gemischter Slicetyp (Mixed) für eine aus einem Mischen beider Vorhersagen resultierende Vorhersage als Slicetyp vorhanden sein können. Die einem Ausführungsbeispiel entsprechenden Slicetypen sind insbesondere in einem Sliceheader für die Multi-View-Videocodierung definiert.
Die graphische Darstellumg von 42(c) zeigt, dass in einem Sliceheader für die skalierbare Videocodierung (SVC) ein P-Slicetyp (VP) für die Inter-View-Vorhersage, ein B-Slicetyp (VB) für die Inter-View-Vorhersage und ein gemischter Slicetyp (Mixed) für eine aus einem Mischen beider Vorhersagen resultierende Vorhersage als Slicetyp zusätzlich zu den für die skalierbare Videocodierung existenten Slicetypen vorhanden sein können. Insbesondere werden die Slicetypen VP, VB und Mixed gemäß einem Ausführungsbeispiel den Slicetypen hinzugefügt, die in einem Sliceheader nach dem Standard für skalierbare Videocodierung (SVC) vorhanden sein können.
Die 43 stellt eine graphische Darstellung diverser Beispiele für Slicetypen dar, die von dem in 41 gezeigten Slicetyp umfasst sind.
In 43(a) ist der Fall dargestellt, bei dem ein Slicetyp aus einem Bild in einem anderen View vorhergesagt wird. Ein Slicetyp wird hierdurch zu einem Slicetyp (VP) für die Inter-View-Vorhersage.
In 43(c) ist der Fall dargestellt, bei dem ein Slicetyp aus zwei Bildern in jeweils unterschiedlichen Views vorhergesagt wird. Ein Slicetyp wird hierdurch zu einem B-Slicetyp (VB) für die Inter-View-Vorhersage.
In den 43(c) und 43(f) ist der Fall dargestellt, bei dem ein Slicetyp aus einem oder zwei Bildern in einem aktuellen View und einem Bild in einem anderen View vorhergesagt wird. Ein Slicetyp wird hierdurch zu einem gemischten Slicetyp (Mixed) für eine aus einem Mischen beider Vorhersagen resultierende Vorhersage. Ferner ist in den 43(d) und 43(e) der Fall dargestellt, bei dem ein Slicetyp aus einem oder zwei Bildern in einem aktuellen View und zwei Bildern in anderen Views vorhergesagt wird. Hierdurch wird ein Slicetyp ebenfalls zu einem gemischten Slicetyp (Mixed).
44 stellt eine graphische Darstellung eines für die in 41 gezeigten Slicetypen zulässigen Makroblocks dar.
Wie 44 zu entnehmen ist, sind für einen P-Slicetyp (VP) bei einer Inter-View-Vorhersage ein Intra-Makroblock (I), ein aus einem Bild in einem aktuellen View vorhergesagter Makroblock (P) oder ein aus einem Bild in einem anderen View vorhergesagter Makroblock (VP) zulässig.
Für einen B-Slicetyp (VB) sind bei einer Inter-View-Vorhersage ein Intra-Makroblock (I), ein aus einem oder zwei Bildern in einem aktuellen View vorhergesagter Makroblock (P oder B) oder ein aus einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views vorhergesagter Makroblock VP oder VB zulässig.
Schließlich sind für einen gemischten Slicetyp (Mixed) ein Intra-Makroblock (I), ein aus einem oder zwei Bildern in einem aktuellen View vorhergesagter Makroblock (P oder B), ein aus einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views vorhergesagter Makroblock (VP oder VB) oder ein aus einem oder zwei Bildern in einem aktuellen View, einem Bild in einem anderen View oder zwei Bildern in jeweils verschiedenen Views vorhergesagter Makroblock (Mixed) zulässig.
Die 45–47 stellen graphische Darstellungen eines Makroblocktyps eines Makroblocks dar, der in einem gemischten Slicetyp (Mixed) entsprechend Ausführungsformen der vorliegenden Erfindung vorliegt.
In den 45(a) und 45(b) sind jeweils Konfigurationsschemata für einen Makroblocktyp (mb_type) und Submakroblocktyp (sub_mb_type) eines in einem gemischten Slice vorhandenen Makroblocks gezeigt.
In den 46 und 47 sind Binärdarstellungen von Vorhersagerichtung(en) eines in einem gemischten Slice vorhandenen Makroblocks und tatsächliche Vorhersagerichtung(en) des gemischten Slice dargestellt.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird ein Makroblocktyp (mb_type) unter Berücksichtigung von sowohl einer Größe (Partition_Size) einer Makroblockpartition als auch einer Vorhersagerichtung (Direction) einer Makroblockpartition erstellt.
Ferner wird ein Submakroblocktyp (sub_mb_type) unter Berücksichtigung von sowohl einer Größe (Sub_Partition_Size) einer Makroblockpartition als auch einer Vorhersagerichtung (Sub_Direction) einer jeden Submakroblockpartition erstellt.
Wie der 45(a) entnommen werden kann, geben 'Direction0' und 'Direction1' jeweils eine Vorhersagerichtung einer ersten Makroblockpartition und eine Vorhersagerichtung einer zweiten Makroblockpartition an. Insbesondere im Fall eines 8 × 16-Makroblocks gibt 'Direction0' eine Vorhersagerichtung für eine linke 8 × 16-Makroblockpartition und 'Direction1' eine Vorhersagerichtung für eine rechte 8 × 16-Makroblockpartition an. Ein Konfigurationsprinzip eines Makroblocktyps (mb_type) wird nachfolgend im Einzelnen erläutert. Zunächst geben die ersten beiden Bits eine Partitionsgröße (Partition_Size) eines zugehörigen Makroblocks an, wobei ein Wert von 0~3 für die ersten beiden Bits verfügbar ist. Ferner geben die vier auf die ersten zwei Bit folgenden Bit eine Vorhersagerichtung (Direction) für den Fall an, dass ein Makroblock in Partitionen unterteilt ist.
Bei einem 16 × 16-Makroblock werden an das hintere Ende der ersten zwei Bit beispielsweise vier Bit angehängt, die eine Vorhersagerichtung des Makroblocks angeben. Im Falle eines 16 × 8-Makroblocks geben den ersten zwei Bit folgende vier Bit eine Vorhersagerichtung (Direction0) einer ersten Partition an, wobei an die vorigen vier Bit weitere vier Bit angefügt werden, um eine Vorhersagerichtung (Direction1) einer zweiten Partition anzugeben. Auf ähnliche Weise werden im Falle eines 8 × 16-Makroblocks acht Bit an das hintere Ende der ersten zwei Bit angefügt. Hierbei geben die ersten vier Bit der an die ersten zwei Bit angefügten acht Bit eine Vorhersagerichtung einer ersten Partition an, und die nächsten vier Bit geben eine Vorhersagerichtung einer zweiten Partition an.
Wie der 45(b) entnommen werden kann, wird eine Vorhersagerichtung (Sub_Direction) eines Submakroblocks in der selben Weise verwendet wie eine Vorhersagerichtung (Direction) der in 45(a) gezeigten Makroblockpartition. Ein Konfigurationsprinzip eines Submakroblocktyps (sub_mb_type) wird nachfolgend im Einzelnen erläutert.
Zuerst geben die ersten zwei Bit eine Partitionsgröße (Partition_Size) eines zugehörigen Makroblocks an und die zu den ersten zwei Bit benachbarten zweiten beiden Bit geben eine Partitionsgröße (Sub_Partition_Size) eines Submakroblocks des zugehörigen Makroblocks an. Für die ersten wie die zweiten zwei Bit sind jeweils Werte von 0~3 verfügbar. Daran anschließend geben vier neben den zweiten beiden Bit angebrachte Bit eine Vorhersagerichtung (Sub_Direction) für den Fall an, dass ein Makroblock in Submakroblockpartitionen unterteilt ist. Wenn beispielsweise eine Größe (Partition_Size) einer Partition eines Makroblocks 8 × 8 und eine Größe (Sub_Partition_Size) einer Partition eines Submakroblocks 4 × 8 ist, dann weisen die ersten zwei Bit den Wert 3 auf, die zweiten zwei Bit weisen den Wert 2 auf, die neben den zweiten zwei Bit angeordneten ersten vier Bit geben eine Vorhersagerichtung für einen linken 4 × 8-Block der beiden 4 × 8-Blöcke und die neben den ersten vier Bit angeordneten zweiten vier Bit geben eine Vorhersagerichtung für einen rechten 4 × 8-Block an.
Wie 46 entnommen werden kann, ist eine Vorhersagerichtung eines Makroblocks aus vier Bit aufgebaut. Ferner ist ersichtlich, dass jede Binärdarstellung in Fällen einer Bezugnahme auf ein Bild zur Linken (L), oberhalb (T), zur Rechten (R) oder unterhalb (B) eines aktuellen Bildes entsprechend '1' wird.
Wie aus 47 ersichtlich wird sich, wenn eine Vorhersagerichtung zum Beispiel oben (T) ist, auf ein in einer Viewrichtung oberhalb eines aktuellen Bildes angeordnetes Bild bezogen. Man kann erkennen, dass, falls eine Vorhersagerichtung allen Richtungen (LTRB) entspricht, auf Bilder in allen Richtungen (LTRB) eines aktuellen Bildes Bezug genommen wird.
48 stellt ein Blockschema einer Vorrichtung zum Codieren eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Aus 48 wird eine Vorrichtung zum Codieren eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung ersichtlich. Die Vorrichtung umfasst eine Makroblocktypbestimmungseinheit 4810, eine Makroblockerzeugungseinheit 4820 und eine Codiereinheit 4830.
49 stellt ein Flussdiagramm eines Verfahrens zum Codieren eines Videosignals in einer wie in 48 gezeigten Vorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
Wie aus 49 erkennbar umfasst ein Verfahren zum Codieren eines Videosignals gemäß einer Ausführungsform der vorliegenden Erfindung einen Schritt S4910 zum Bestimmen eines ersten Makroblocktyps für die Intra-View-Vorhersage und eines zweiten Makroblocktyps für die Inter-View-Vorhersage, einen Schritt S4920 zum Erzeugen eines ersten Makroblocks, der den ersten Makroblocktyp aufweist, und eines zweiten Makroblocks, der den zweiten Makroblocktyp aufweist, einen Schritt S4930 zum Erzeugen eines dritten Makroblocks unter Verwendung des ersten und des zweiten Makroblocks, und einen Schritt S4940 zum Codieren eines Makroblocktyps eines aktuellen Makroblocks und eines Makroblockvorhersagemodus.
Gemäß der vorliegenden Erfindung bestimmt die Makroblockbestimmungseinheit 4810 einen ersten Makroblocktyp für die Intra-View-Vorhersage und einen zweiten Makroblocktyp für die Inter-View-Vorhersage (S4910), wie im Einzelnen oben beschrieben wurde.
Anschließend erzeugt die Makroblockerzeugungseinheit 4820 unter Verwendung wohlbekannter Vorhersagetechniken einen ersten Makroblock, der den ersten Makroblocktyp aufweist, und einen zweiten Makroblock, der den zweiten Makroblocktyp aufweist, (S4920) und erzeugt dann einen dritten Makroblock unter Verwendung des ersten und des zweiten Makroblocks (S4930). In diesem Fall wird der dritte Makroblock einem Durchschnittswert zwischen dem ersten und dem zweiten Makroblock entsprechend erzeugt.
Schließlich codiert die Codiereinheit 4830 einen Makroblocktyp (mb_type) eines aktuellen Makroblocks und einen Makroblock-Vorhersagemodus (mb_pred_mode) des aktuellen Makroblocks durch Vergleichen der Codiereffizienzen des ersten bis dritten Makroblocks (S4940).
Hierbei gibt es diverse Verfahren zum Messen der Codiereffizienzen. Insbesondere wird bei dieser Ausführungsform der vorliegenden Erfindung ein Verfahren verwendet, das RD-Kosten (RD: rate distortion, Geschwindigkeitsverzerrung) verwendet. Wie allgemein bekannt werden beim RD-Kosten-Verfahren entsprechende Kosten mit zwei Komponenten berechnet: einer Codierbitnummer, die beim Codieren eines zugehörigen Blocks erzeugt wird, und einem Verzerrungswert, der eine Abweichung von einer tatsächlichen Sequenz angibt.
Der erste und der zweite Makroblocktyp können in einer Weise bestimmt werden, bei der ein Makroblocktyp mit einem Minimalwert der oben ausgeführten RD-Kosten ausgewählt wird. Beispielsweise wird ein Makroblocktyp, der unter den Makroblocktypen bei der Intra-View-Vorhersage einen minimalen Wert der RD-Kosten aufweist, als erster Makroblocktyp bestimmt. Und der Makroblocktyp, der unter den Makroblocktypen bei der Inter-View-Vorhersage einen minimalen Wert der RD-Kosten aufweist, wird als zweiter Makroblocktyp bestimmt.
Bei dem Schritt zum Codieren des Makroblocktyps und Makroblock-Vorhersagemodus kann ein Makroblocktyp eines Vorhersagemodus gewählt erden, der mit dem Makroblock verknüpft ist, der von dem ersten oder zweiten Makroblock die geringeren RD-Kosten aufweist. Anschließend werden die RD-Kosten des dritten Makroblocks bestimmt. Schließlich werden der Makroblocktyp und Makroblock-Vorhersagemodus des aktuellen Makroblocks durch Vergleichen der RD-Kosten des ausgewählten ersten oder zweiten Makroblocks und der RD-Kosten des dritten Makroblocks gegeneinander codiert.
Wenn die RD-Kosten des ausgewählten ersten oder zweiten Makroblocks gleich oder größer als die RD-Kosten des dritten Makroblocks sind, wird der Makroblock zu einem dem ausgewählten ersten oder zweiten Makroblock entsprechenden Makroblocktyp.
Wenn beispielsweise die RD-Kosten des ersten Makroblocks kleiner als die des zweiten und dritten Makroblocks sind, dann wird der aktuelle Makroblock als erster Makroblocktyp gesetzt. Ferner wird der Makroblock-Vorhersagemodus (d. h. Intra-View) ein Vorhersageschema eines Makroblocks entsprechend den RD-Kosten.
Wenn die RD-Kosten des zweiten Makroblocks beispielsweise kleiner als die des ersten und dritten Makroblocks sind, wird ein Inter-View-Vorhersageschema als Vorhersageschema des zweiten Makroblocks der Makroblock-Vorhersagemodus des aktuellen Makroblocks.
Wenn indessen die RD-Kosten des dritten Makroblocks kleiner als die RD-Kosten des ersten und zweiten Makroblocks sind, dann entspricht der Makroblocktyp sowohl dem ersten wie dem zweiten Makroblocktyp. Insbesondere werden Intra-View-Vorhersage- und Inter-View-Vorhersage-Makroblocktypen Makroblocktypen des aktuellen Makroblocks. Ferner wird der Makroblock-Vorhersagemodus ein gemischtes Vorhersageschema, das aus einem Mischen von Intra-View- und Inter-View-Vorhersage resultiert.
Entsprechend ermöglicht die vorliegende Erfindung zumindest die folgenden Wirkungen und Vorteile.
Aufgrund der diversen Vorhersageschemata zwischen Views und solchen Informationen wie Slicetypen, Makroblocktypen und Makroblock-Vorhersagemoden kann die vorliegende Erfindung redundante Information zwischen Views entfernen und hierdurch die Leistungsfähigkeit der Codier-/Decodiereffizienz verbessern.
Industrielle Anwendbarkeit
Auch wenn die vorliegende Erfindung hierin unter Bezugnahme auf deren bevorzugte Ausführungsformen beschrieben und veranschaulicht wurde, ist es für einen Fachmann offensichtlich, dass diverse Abänderungen und Abwandlungen hiervon vorgenommen werden können, ohne Geist und Umfang der Erfindung zu verlassen. Es ist daher beabsichtigt, dass die vorliegende Erfindung die Abänderungen und Abwandlungen dieser Erfindung erfasst, die vom Umfang der beigefügten Ansprüche und deren Äquivalenten umfasst sind.

Claims

Vorrichtung zum Decodieren von Multi-View-Videodaten in einem Multi-View-Videostrom, wobei die Vorrichtung aufweist: eine Parser-Einheit (100), die aus dem Multi-View-Videostrom eine Inter-View-Bildgruppen-Identifizierungsinformation erhält, wobei die Inter-View-Bildgruppen-Identifizierungsinformation angibt, ob ein Typ eines Bildes eine Inter-View-Bildgruppe ist, wobei die Inter-View-Bildgruppe ein codiertes Bild ist, bei dem alle Slices nur Slices referenzieren, die zu einer gleichen Zeit und zu einem anderen View der Inter-View-Bildgruppe gehören, wobei die Parser-Einheit aus dem Multi-View-Videostrom eine Inter-View-Referenzinformation erhält, die View-Beziehungen zwischen mehreren Views repräsentiert, wobei die Inter-View-Referenzinformation eine Viewnummer-Information und eine View-Identifizierungsinformation umfasst; eine Pufferspeichereinheit (600) für decodierte Bilder, die basierend auf der Inter-View-Bildgruppen-Identifizierungsinformation, der Viewnummer-Information und der View-Identifizierungsinformation eine Inter-View-Referenzbildliste für die Inter-View-Bildgruppe erzeugt; und eine Inter-Vorhersageeinheit (700), die basierend auf der erzeugten Inter-View-Referenzbildliste einen Vorhersagewert eines Makroblocks in der Inter-View-Bildgruppe bestimmt, wobei die Inter-Vorhersageeinheit den Makroblock unter Verwendung des Vorhersagewerts decodiert.
Vorrichtung nach Anspruch 1, worin die Viewnummer-Information eine Anzahl von Referenzviews der Inter-View-Bildgruppe angibt und die View-Identifizierungsinformation einen View-Identifikator eines jeden Referenzviews für die Inter-View-Bildgruppe angibt.
Vorrichtung nach Anspruch 1, worin die Multi-View-Videodaten Videodaten eines von anderen Views unabhängigen Basisviews umfassen, wobei der Basisview ein ohne Verwendung einer Inter-View-Vorhersage decodierter View ist.
Vorrichtung nach Anspruch 1, worin die Inter-View-Referenzinformation aus einem Erweiterungsbereich eines Sequenzparametersatzes erhalten wird.