JP2014522187A - ビデオコーディングにおける様々な次元に対するコーディングパラメータセット - Google Patents

ビデオコーディングにおける様々な次元に対するコーディングパラメータセット Download PDF

Info

Publication number
JP2014522187A
JP2014522187A JP2014524033A JP2014524033A JP2014522187A JP 2014522187 A JP2014522187 A JP 2014522187A JP 2014524033 A JP2014524033 A JP 2014524033A JP 2014524033 A JP2014524033 A JP 2014524033A JP 2014522187 A JP2014522187 A JP 2014522187A
Authority
JP
Japan
Prior art keywords
video
dimension
value
coding
enabled
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014524033A
Other languages
English (en)
Other versions
JP5869126B2 (ja
Inventor
チェン、イン
カークゼウィックズ、マルタ
ワン、イェ―クイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2014522187A publication Critical patent/JP2014522187A/ja
Application granted granted Critical
Publication of JP5869126B2 publication Critical patent/JP5869126B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/37—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability with arrangements for assigning different transmission priorities to video input data or to video coded data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/39—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability involving multiple description coding [MDC], i.e. with separate layers being structured as independently decodable descriptions of input picture data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234309—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234354—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering signal-to-noise ratio parameters, e.g. requantization
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions

Abstract

一例では、ビデオデータをコーディングするためのデバイスは、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされているかを表す情報をコーディングし、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていないビデオコーディング次元の値をコーディングすることなく、イネーブルされたビデオコーディング次元の各々の値をコーディングするように構成される、ビデオコーダを含む。このようにして、ＮＡＬユニットヘッダは可変の長さを有し得るが、それでも、ＮＡＬユニットが対応するスケーラブルな次元の情報を提供する。

Description

優先権の主張
本出願は、その各々の全体が参照により本明細書に組み込まれる、２０１１年８月１日に出願された米国仮出願第６１／５１３，９９６号、２０１１年９月２７日に出願された米国仮出願第６１／５３９，９２５号、２０１１年１１月８日に出願された米国仮出願第６１／５５７，３００号、および２０１１年１１月２３日に出願された米国仮出願第６１／５６３，３５９号の利益を主張する。
本開示は、ビデオコーディングに関する。
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法のような、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコーディングされた（Ｉ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコーディングされた（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
[0005]空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コーディングされたブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコーディングされたブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されてよく、次いで量子化され得る残差変換係数が得られる。最初は２次元アレイで構成される、量子化された変換係数は、変換係数の１次元ベクトルを生成するために走査されてよく、なお一層の圧縮を達成するためにエントロピーコーディングが適用されてよい。
[0006]全般に、本開示は、ビデオデータの様々なスケーラブルな次元の特性をシグナリングするための技法を説明する。ビデオデータは、空間分解能、フレームレート（時間的な）、ビュー（たとえば、３次元（３Ｄ）ビデオ再生をサポートするための）、カラービット深度、クロマサンプリングフォーマット、品質、または他のそのような次元のような、様々な異なる次元においてスケーリングされ得る。一般に、ビデオデータのスケーラブルな次元は、１つまたは複数の要素を含み得る。たとえば、ビュー次元は、２次元ビデオに対しては単一のビュー、立体ビデオに対しては２つのビュー、またはマルチビューに対してはＮ個のビュー（Ｎは２よりも大きな整数）を含み得る。別の例として、時間次元は、基本フレームレート（たとえば、毎秒１５フレーム（１５ｆｐｓ））をサポートするためのピクチャの第１のレイヤと、より高いフレームレート（たとえば、３０ｆｐｓ、６０ｆｐｓ、および１２０ｆｐｓ）をサポートするための１つまたは複数のより高次のレイヤとを含み得る。本開示の技法は全般に、ビットストリーム、またはそのサブビットストリームが、特定の次元のための複数のレイヤを含むかどうかということと、含む場合は、その次元のための特性の値を、たとえばネットワーク抽象化レイヤ（ＮＡＬ）ユニットヘッダにおいてシグナリングすることに関し、このことは、様々な次元の値の各々のためのビットの数をコーディングすることを含み得る。このようにして、本開示の技法は、ＮＡＬユニットヘッダ中の１つのスケーラブルな次元に関連する各シンタックス要素に対して常に固定長の値を使用する代わりに、ビットストリームの異なるコーディングされたビデオシーケンスに対して変化し得る情報と、ビットストリームのコーディングされたビデオシーケンス内で変化しない情報とに基づいて、各シンタックス要素の長さを割り当てることを可能にし得る。
[0007]一例では、ビデオデータをコーディングする方法は、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされるかを表す情報をコーディングすることと、イネーブルされるビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされるビデオコーディング次元を表すシンタックス要素の値をコーディングすることと、を含む。
[0008]別の例では、ビデオデータをコーディングするためのデバイスは、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされるかを表す情報をコーディングし、イネーブルされるビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされるビデオコーディング次元を表すシンタックス要素の値をコーディングするように構成される、ビデオコーダを含む。
[0009]別の例では、ビデオデータをコーディングするためのデバイスは、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされるかを表す情報をコーディングする手段と、有効なビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされるビデオコーディング次元を表すシンタックス要素の値をコーディングする手段と、を含む。
[0010]別の例では、コンピュータ可読記憶媒体は命令によって符号化され、その命令は実行されると、プロセッサに、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされるかを表す情報をコーディングさせ、イネーブルされるビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされるビデオコーディング次元を表すシンタックス要素の値をコーディングさせる。
[0011]１つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。
ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。 ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を実施し得るビデオエンコーダの例を示すブロック図。 ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を実施し得るビデオデコーダの例を示すブロック図。 ビデオデータのスケーラブルな次元の特性をシグナリングするための本開示の技法を実行し得るデバイスの別のセットを含むシステムを示すブロック図。 本開示の技法の様々な例による、ＮＡＬユニットヘッダの例を示す概念図。 本開示の技法の様々な例による、ＮＡＬユニットヘッダの例を示す概念図。 ビデオデータのスケーラブルな次元の特性をシグナリングするための例示的な方法を示すフローチャート。 ビデオデータのスケーラブルな次元のシグナリングされた特性を使用するための例示的な方法を示すフローチャート。 ビデオデータのスケーラブルな次元の特性をシグナリングし、シグナリングされた特性を使用するための、別の例示的な方法を示すフローチャート。
[0020]全般に、本開示は、ビデオデータの様々な次元の特性をシグナリングするための技法を説明する。次元は、ビデオコーディング次元、または簡潔にするために単に「次元」と本明細書では呼ばれ得る。ビデオデータは、空間分解能、フレームレート（時間的な）、ビュー（たとえば、３次元（３Ｄ）ビデオ再生をサポートするための）、カラービット深度、クロマサンプリングフォーマット、または他のそのような次元のような、様々な異なる次元でスケーリングされ得る。したがって、ビデオコーディング次元は、「スケーラブルなビデオコーディング次元」または単に「スケーラブルな次元」とも呼ばれ得る。
[0021]ビデオデータのスケーラブルな次元は、１つまたは複数の要素を含み得る。たとえば、ビュー次元は、２次元ビデオに対しては単一のビュー、立体ビデオに対しては２つのビュー、またはマルチビューに対してはＮ個のビュー（Ｎは２よりも大きな整数）を含み得る。別の例として、時間次元は、基本フレームレート（たとえば、毎秒１５フレーム（１５ｆｐｓ））をサポートするためのピクチャの第１のレイヤと、より高いフレームレート（たとえば、３０ｆｐｓ、６０ｆｐｓ、および１２０ｆｐｓ）をサポートするための１つまたは複数のより高次のレイヤとを含み得る。本開示の技法は全般に、ビットストリーム、またはそのサブビットストリームが、特定の次元のための複数の要素（たとえば、複数の層）を含むかどうかということと、含む場合、その次元の特性の値を、たとえば、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットヘッダにおいてシグナリングすることに関する。
[0022]本開示の技法は、様々なオーディオ、ビデオ、または他のメディアコーディング規格に関して実施され得る。例として、本開示の技法は、来たるＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格の技法に関して論じられる。しかしながら、これらの技法は、他のコーディング規格に対しても実施され得ることを理解されたい。ＨＥＶＣ Ｗｏｒｋｉｎｇ Ｄｒａｆｔ ７またはＷＤ７と呼ばれる来たるＨＥＶＣ規格の最近の草案は、文書ＨＣＴＶＣ−Ｉ１００３、Ｂｒｏｓｓ他、「Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ） Ｔｅｘｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｄｒａｆｔ ７」、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３とＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１のＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ （ＪＣＴ−ＶＣ）、第９回会合：ジュネーブ、スイス、２０１２年４月２７日〜２０１２年５月７日に記載されおり、この文書は、２０１２年７月３０日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／９＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｉ１００３−ｖ９．ｚｉｐからダウンロード可能である。ビデオコーディング規格の他の例は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびＩＴＵ−Ｔ Ｈ．２６４（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られている）を含む。ビデオコーディング規格はまた、様々な拡張を使用して拡張され得る。たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣは、スケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む。
[0023]上で述べられたように、本開示の技法は、様々なスケーラブルな次元の特性をＮＡＬユニットヘッダにおいてシグナリングするために使用され得る。ＮＡＬユニットは一般に、ビデオコーディングレイヤ（ＶＣＬ）データまたは非ＶＣＬデータのような、より下位のレイヤのデータをカプセル化する。ＶＣＬデータは一般に、ビデオエンコーダによって符号化されビデオデコーダによって復号される、コーディングされたビデオデータを含む。非ＶＣＬデータは、復号に必要ではないシグナリングを含み得るが、宛先デバイスに対しては有用であり得る。たとえば、非ＶＣＬデータは、ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ（ＳＥＩ）メッセージを含み得る。
[0024]比較のために、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣ（本明細書では「Ｈ．２６４／ＡＶＣ」とも呼ばれる）のＭＶＣ拡張におけるＮＡＬユニットヘッダは、ＮＡＬユニットタイプとｎａｌ＿ｒｅｆ＿ｉｄｃシンタックス要素とを含む、１バイトのＮＡＬユニットヘッダを含む。加えて、ＭＶＣ ＮＡＬユニットヘッダは、ＮＡＬユニットタイプがプレフィックスＮＡＬユニットまたはノーマルＭＶＣ ＮＡＬユニットである場合、ＭＶＣ ＮＡＬユニットヘッダ拡張を含み得る。ＭＶＣのＮＡＬユニットヘッダ拡張は、ＮＡＬユニットがｃｌｏｓｅｄ−ＧＯＰランダムアクセスポイントのために使用され得るＩＤＲ／Ｖ−ＩＤＲピクチャに属するかどうかを示すためのｎｏｒ＿ｉｄｒ＿ｆｌａｇと、単一パスへの適合のために使用され得るｐｒｉｏｒｉｔｙ＿ｉｄと、現在属しているビューのビュー識別子を示すためのｖｉｅｗ＿ｉｄと、現在のＮＡＬユニットの時間的なレベルを示すためのｔｅｍｐｏｒａｌ＿ｉｄと、ＮＡＬユニットがｏｐｅｎ−ＧＯＰランダムアクセスポイントのために使用され得るアンカーピクチャに属するかどうかを示すためのａｎｃｈｏｒ＿ｐｉｃ＿ｆｌａｇと、他のビュー中のＮＡＬユニットのためにビュー間予測が使用されるかどうかを示すためのｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇとを含む。ＭＶＣにおけるプレフィックスＮＡＬユニットは、ＮＡＬユニットヘッダと、そのＭＶＣ ＮＡＬユニットヘッダ拡張とを含む。
[0025]やはり比較のために、Ｈ．２６４／ＡＶＣのＳＶＣ拡張におけるＮＡＬユニットヘッダは、ＮＡＬユニットヘッダ拡張に追加されるシンタックス要素を含んでよく、これはＨ．２６４／ＡＶＣの従来の１バイトのＮＡＬユニットヘッダを４バイトへと拡張し、ｐｒｉｏｒｉｔｙ＿ｉｄと、ｔｅｍｐｏｒａｌ＿ｉｄと、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄと、ｑｕａｌｉｔｙ＿ｉｄとを含む、複数の次元においてＶＣＬ ＮＡＬユニットの特性を表す。Ｈ．２６４／ＡＶＣのＳＶＣ拡張では、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄは、空間スケーラビリティ、またはＣｏａｒｓｅ Ｇｒａｉｎ Ｓｃａｌａｂｌｅ（ＣＧＳ）に関連し、ｑｕａｌｉｔｙ＿ｉｄは、信号対雑音比（ＳＮＲ）／品質のスケーラビリティを示す。Ｐｒｉｏｒｉｔｙ＿ｉｄは、対応するＮＡＬユニットの優先度識別子に関連し、ｔｅｍｐｏｒａｌ＿ｉｄは、対応するＮＡＬユニットの時間識別子を規定する（これは、時間スケーラビリティ、たとえば変化するフレームレートをサポートするために使用され得る）。
[0026]またやはり比較のために、ＨＥＶＣにおけるＶＣＬ ＮＡＬユニットは、Ｈ．２６４／ＡＶＣにおけるＮＡＬユニットヘッダよりも長いＮＡＬユニットヘッダを含むが、ＨＥＶＣ ＷＤ７ ＮＡＬユニットヘッダの最初のバイトは現在、Ｈ．２６４／ＡＶＣのＮＡＬユニットヘッダと同じである。ＨＥＶＣ ＷＤ７ ＮＡＬユニットヘッダはまた、ｔｅｍｐｏｒａｌ＿ｉｄとｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素とを含む。
[0027]上で示されるように、Ｈ．２６４／ＡＶＣ、ＳＶＣ、ＭＶＣ、およびＨＥＶＣの様々なＮＡＬユニットヘッダは、様々なスケーラブルな次元をサポートするための、シンタックス要素の様々なセットを含む。ＨＥＶＣは最終的に、Ｈ．２６４／ＡＶＣのＳＶＣ拡張およびＭＶＣ拡張の次元のような、複数の異なるスケーラブルな次元をサポートするように構成され得る。本開示は、様々なスケーラブルな次元に対する異なるＨＥＶＣ拡張をサポートしようとすると、様々な問題が起こり得ることを認める。たとえば、異なる拡張では、異なるタイプのＮＡＬユニットヘッダ拡張が必要とされ得る。様々な異なるタイプのＮＡＬユニットヘッダ拡張を提供することによって、ＨＥＶＣの最終的な仕様は、複数のＮＡＬユニットヘッダ拡張シンタックステーブルを有することになる可能性があり、これは、ビデオデータの処理に関してデバイスの複雑さを高め得る。
[0028]あるいは、ＨＥＶＣの最終的な仕様は、すべての可能性のあるシンタックス要素をサポートするために、最大の数のビットを有するＮＡＬユニットヘッダを規定する可能性がある。ＮＡＬユニットヘッダが固有の固定長の設計を有する場合、多くのシンタックス要素はデフォルト値（たとえば、０）に設定されることがあり、シンタックス要素のいくつかのみが設定された値を有することがあり、これはビットの浪費である。言い換えると、すべての可能性のあるスケーラブルな次元を同時にサポートするのに十分なビットを有するＮＡＬユニットヘッダは、いくつかのスケーラブルな次元が使用されない場合、オーバーヘッドにおけるビットの浪費につながり得る。
[0029]本開示は、ビデオデータのスケーラブルな次元の特性をシグナリングすることに関する、様々な技法を説明する。本開示は、たとえば、ＮＡＬユニットヘッダが可変長を有することを認めることによって、様々なスケーラブルな次元を効率的にサポートすることができる、ＮＡＬユニットヘッダをコーディングするためのいくつかの技法を説明する。たとえば、次元範囲パラメータセットは、１つまたは複数のスケーラブルな次元のうちのいずれがビットストリームに対してアクティブである（すなわち、イネーブルされる）か、を示すことができ、さらに、アクティブかつスケーラブルな次元の値をコーディングするために使用されるビットの数を示すデータを提供することができる。したがって、ＮＡＬユニットヘッダは、アクティブかつスケーラブルな次元のシンタックス要素を含んでよく、アクティブではないスケーラブルな次元のシンタックス要素（たとえば、１つのみの可能な値を有し、シーケンスパラメータセット（ＳＰＳ）のような別個のデータ構造において代わりにシグナリングされ得る）を省略する。このようにして、スケーラブルであることがイネーブルされない次元（たとえば、１つの値がシグナリングされ、変更されずに保たれる次元）に対して、値は、ＮＡＬユニットヘッダにおいてシグナリングされる必要はない。その上、値マッピングテーブルに対するインデックスは、アクティブかつスケーラブルな次元の中の値にインデックス値をマッピングすることができるので、アクティブである様々なスケーラブルな次元の特性をシグナリングするために、より少数のビットがＮＡＬユニットヘッダにおいて使用され得る。
[0030]別の例では、ＮＡＬユニットヘッダマップは、ＮＡＬユニットヘッダ中のフィールドのレイアウトを規定することができる。すなわち、ＮＡＬユニットヘッダマップは、上で説明された次元範囲パラメータセットの代わりに使用され得る。ＮＡＬユニットヘッダマップは、ＮＡＬユニットヘッダマップパラメータセットまたはシーケンスパラメータセット（ＳＰＳ）に含まれ得る。１つのＮＡＬユニットヘッダマップは、ビットストリーム全体に適用可能であり得る。この例のＮＡＬユニットヘッダマップを使用することで、追加のスケーラブルな次元を加えるために使用され得るさらなる拡張が、既存の規格および既存の拡張と後方互換性を有することが確実になり得る。この例の技法はまた、たとえば、次元範囲パラメータセットおよびＳＰＳにＮＡＬユニットヘッダ拡張を含めるのを避けることによって、ＮＡＬユニットヘッダおよびＳＰＳが解析され得ることを確実にし得る。さらに、この例のＮＡＬユニットヘッダは、ＨＥＶＣ ＷＤ７で規定されるように、開始コードを模擬するデータを含めるのを避けることができる。その上、これらの技法は、ＳＶＣおよびＭＶＣのｐｒｉｏｒｉｔｙ＿ｉｄ値と同様に、ＮＡＬユニットヘッダ中に優先度識別子（ｐｒｉｏｒｉｔｙ＿ｉｄ）を含めることに関連するいくつかの利益を活かすことができる。
[0031]図１は、ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示されるように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化されたビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介してビデオデータを宛先デバイス１４に与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に対応し得る。
[0032]宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体１６は、ソースデバイス１２から宛先デバイス１４に符号化されたビデオデータを移動させることができる任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、符号化されたビデオデータをリアルタイムで宛先デバイス１４に直接送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路のような、任意のワイヤレスまたは有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークのような、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を支援するのに有用であり得る、ルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0033]いくつかの例では、符号化されたデータは、出力インターフェース２２からストレージデバイスに出力され得る。同様に、符号化されたデータは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは、符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ファイルサーバ、またはソースデバイス１２によって生成された符号化されたビデオを記憶し得る別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス１４に送信することができる任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を介して符号化されたビデオデータにアクセスすることができる。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適切なワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ接続）、有線接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。ストレージデバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0034]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、種々のマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0035]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
[0036]図１の示されるシステム１０は一例にすぎない。ビデオデータのスケーラブルな次元の特性をシグナリングするための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。一般に、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコーディングされたビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化コンポーネントとビデオ復号コンポーネントとを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話のための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートすることができる。
[0037]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブされたビデオとコンピュータにより生成されたビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き携帯電話またはビデオ電話を形成することができる。しかしながら、上述のように、本開示で説明される技法は、全般にビデオコーディングに適用可能であってよく、ワイヤレスおよび／または有線の適用例に適用可能であってよい。各々の場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータにより生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
[0038]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたは有線ネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、たとえば、ネットワーク送信を介して、ソースデバイス１２から符号化されたビデオデータを受信し、宛先デバイス１４に符号化されたビデオデータを与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化されたビデオデータを受信し、その符号化されたビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
[0039]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコーディングされたユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのいずれかを備え得る。
[0040]ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作することができ、ＨＥＶＣ Ｔｅｓｔ Ｍｏｄｅｌ（ＨＭ）に準拠することができる。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ １０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合されてよく、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。
[0041]ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、Ｊｏｉｎｔ Ｖｉｄｅｏ Ｔｅａｍ（ＪＶＴ）として知られる共同パートナーシップの成果として、ＩＳＯ／ＩＥＣ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）とともにＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）によって策定された。いくつかの態様では、本開示で説明される技法は、一般にＨ．２６４規格に準拠するデバイスに適用され得る。Ｈ．２６４規格は、ＩＴＵ−Ｔ研究グループによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４「Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｆｏｒ ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ」に記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ばれ得る。Ｊｏｉｎｔ Ｖｉｄｅｏ Ｔｅａｍ（ＪＶＴ）はＨ．２６４／ＭＰＥＧ−４ ＡＶＣへの拡張に取り組み続けている。
[0042]ビデオエンコーダ２０およびビデオデコーダ３０は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、種々の適切なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装される場合、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。
[0043]ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣ Ｔｅｓｔ Ｍｏｄｅｌ（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。
[0044]一般に、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ）に分割され得ることを記載している。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続的なツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。一般に、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
[0045]４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義されてよく、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的な分割が存在しない場合でも、リーフＣＵの４つのサブＣＵをリーフＣＵとも呼ぶ。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６のＣＵが決して分割されなくても、４つの８×８のサブＣＵをリーフＣＵとも呼ぶ。
[0046]ＣＵは、ＣＵがサイズの差異を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、４つの子ノード（サブＣＵとも呼ばれる）に分割されてよく、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割されてよい。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コーディングされたビットストリームに関連するシンタックスデータは、最大ＣＵ深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義することができ、また、コーディングノードの最小サイズを定義することができる。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ）も定義することができる。本開示では、ＨＥＶＣの状況におけるＣＵ、ＰＵ、またはＴＵ、あるいは他の規格の状況における同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。
[0047]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８のピクセルから最大６４×６４以上のピクセルをもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非正方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。
[0048]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従った変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用して、より小さいユニットに再分割され得る。ＲＱＴのリーフノードは、変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、変換係数を生成するように変換されてよく、その変換係数は量子化され得る。
[0049]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。一般に、ＰＵは、対応するＣＵの全部または一部分に対応する空間的エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのデータは、ＰＵに対応するＴＵのイントラ予測モードを記述するデータを含み得る、残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、もしくはリストＣ）を記述し得る。
[0050]１つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上で論じられたように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットはさらに、さらなるサブＴＵに分割され得る。ＴＵがさらに分割されないとき、そのＴＵはリーフＴＵと呼ばれ得る。一般に、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、一般に、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して、各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵはＰＵよりも大きくまたは小さくなり得る。イントラコーディングの場合、ＰＵは、同じＣＵのための対応するリーフＴＵと同じ位置にあり得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。
[0051]その上、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは一般にリーフＣＵに対応し、ＣＵ４分木のルートノードは一般にツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。一般に、本開示では、別段明記しない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
[0052]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、一般に、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。各ピクチャのスライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定のサイズまたは可変のサイズを有してよく、指定のコーディング規格に応じてサイズが異なり得る。
[0053]一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ ＰＵと下部の２Ｎ×１．５Ｎ ＰＵとで水平方向に区分された２Ｎ×２Ｎ ＣＵを指す。
[0054]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ただし、Ｎは非負整数値を表す。ブロック中のピクセルは行と列とに構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備えてよく、ただし、Ｍは必ずしもＮに等しいとは限らない。
[0055]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備えてよく、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後の、変換領域にける係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。
[0056]変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、一般に、さらなる圧縮を実現する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化される処理を指す。量子化処理は、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値へと切り捨てられてよく、ただし、ｎはｍよりも大きい。
[0057]量子化の後に、ビデオエンコーダは、変換係数を走査することができ、量子化された変換係数を含む２次元行列から１次元ベクトルを生成する。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、あらかじめ定義された走査順序を利用して、量子化された変換係数を走査し、エントロピー符号化され得る直列化されたベクトルを生成し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。量子化された変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディング、または別のエントロピー符号化方法に従って、１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化されたビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
[0058]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が０ではないかどうかに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに対して可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢（more probable）シンボルに対応し、より長いコードが劣勢（less probable）シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルに対して等長のコードワードを使用する場合よりも、ビットの節約を達成し得る。確率の決定は、シンボルに割り当てられるコンテキストに基づき得る。
[0059]全般に、本開示は、ソースデバイス１２、宛先デバイス１４、ビデオエンコーダ２０、ビデオデコーダ３０、または、ビデオデータの処理、転送、記憶、もしくは取り出し（retrieval）に関与する他のデバイスによって実行され得る、様々な技法を説明する。説明のために、本開示の技法は、ビデオエンコーダ２０およびビデオデコーダ３０に関して説明される。しかしながら、ビデオプリプロセシングユニットもしくはビデオポストプロセシングユニット、カプセル化器、カプセル化解除器、マルチプレクサ、デマルチプレクサ、メディア認識ネットワーク要素（ＭＡＮＥ）、または、ビデオデータの処理に関連する他のデバイスのような他のデバイスも、これらの技法のいずれかまたはすべてによって構成され得る。様々な技法が、単独で、または任意の組合せで一緒に実行され得る。
[0060]本開示は、ビデオエンコーダ２０およびビデオデコーダ３０によってコーディングされ得る、次元範囲パラメータセットを導入する。次元範囲パラメータセットは、あるビットストリームに対して、各々のスケーラブルな次元のスケーラビリティレベルの範囲を規定することができる。たとえば、次元範囲パラメータセットは、空間次元、時間次元、ＳＮＲ／品質次元、ビュー次元、カラービット深度次元、クロマサンプルフォーマット次元または他のそのようなスケーラブルな次元のいずれかまたはすべての範囲を規定することができる。次元範囲パラメータセットは、ビットストリーム全体に適用可能であり得る。言い換えると、ビデオエンコーダ２０は、符号化されたビデオデータが次元範囲パラメータセットにおいてシグナリングされるデータに従うように、ビットストリームのすべてのビデオデータを符号化することができるが、ビデオデコーダ３０は、次元範囲パラメータセットにおいてシグナリングされるデータに少なくとも一部基づいて、ビットストリームのすべてのコーディングされたビデオデータを復号することができる。
[0061]特定のスケーラブルな次元に属するＮＡＬユニットの特性は、次元範囲パラメータセットのデータによって示されるように、ビットストリーム中で変化してもしなくてもよい。たとえば、スケーラブルな次元の特定の特性が変化せず、ビットストリームがその特定のスケーラブルな次元においてスケーラブルではない場合、その特性は、ＮＡＬユニットヘッダにおいてシグナリングされる必要はない。
[0062]次元範囲パラメータセットによって示されるように、スケーラブルな次元の特性が変化できＮ個の可能な値を有し得る場合、そのスケーラブルな次元の特性を表すために、特定の数のビットがＮＡＬユニットヘッダ内で割り当てられ得る。たとえば、Ｎを整数とすると、ｃｅｉｌ（ｌｏｇ2（Ｎ））個のビットが、特性を表すためにＮＡＬユニットヘッダ内で割り当てられてよく、ｃｅｉｌ（Ｘ）はＸの「シーリング（最高限度）」、または（返される値が整数ではないとすると、次の最も近い整数への）切り上げ値を返す。
[0063]ＮＡＬユニットヘッダ中のすべての可能な次元のすべての特性を、特性セットとして、ビデオエンコーダ２０は一緒にシグナリングすることができ、ビデオデコーダ３０は一緒に取り出す（retrieval）ことができる。特性セットは、すべての次元のすべての特性にマッピングされ得る。
[0064]次元の特性は変化し得る。いくつかの例では、スケーラブルな次元の現実の値をシグナリングするのではなく、ビデオエンコーダ２０およびビデオデコーダ３０は、スケーラブルな次元の現実の値のインデックス値をコーディングし得る。たとえば、ビュー次元のビューのｖｉｅｗ＿ｉｄ値をシグナリングするのではなく、ビデオエンコーダ２０およびビデオデコーダ３０はビュー順序インデックス値をコーディングし、ビュー順序インデックス値は、別個のマッピングテーブルによって、それぞれのｖｉｅｗ＿ｉｄ値にマッピングされ得る。別の例として、ビットストリームのビット深度スケーラブル次元は、８ビット、１０ビット、および１２ビットの信号を含み得る。そのようなカラービット深度のためにＮＡＬユニットヘッダにおいて「８」、「１０」、および「１２」をシグナリングするのではなく、ビデオエンコーダ２０およびビデオデコーダ３０は、値「０」、「１」、および「２」を使用することができ、これらが再び、それぞれ「８」、「１０」、および「１２」にマッピングされ得る。したがって、ビデオエンコーダ２０およびビデオデコーダ３０は、ビットストリームのための値マッピングテーブルに対するインデックスをコーディングするように構成され得る。値マッピングテーブルに対するインデックスは、次元範囲パラメータセットの一部を形成することができ、データの別個のセットとしてコーディングされ得る。そのようなマッピングテーブルは、特定のコーディングされたビデオシーケンス、またはビットストリーム全体に適用可能であり得る。
[0065]本開示はまた、サブビットストリーム拡張に適用可能であり得る技法を説明する。ビットストリームが１つまたは複数のスケーラブルな次元を含む場合、いくつかの宛先デバイスは、特定の次元の様々なレベルを要求することができるが、他の宛先デバイスは、特定の次元の単一のレベル、たとえば基本レベルのみを要求してよい。ネットワーク内のメディアアウェアネットワーク要素（ＭＡＮＥ：media-aware network element）（図１には示されないが、一般に、接続１６に沿ったデバイスに対応し得る）は、サブビットストリーム拡張を実行して、要求されたデータを様々な宛先デバイスに提供することができる。
[0066]たとえば、ビュー次元は複数の異なるビューを含み得る。１つの宛先デバイスは、多視点３次元再生（multi-perspective three-dimensional playback）が可能であり得るので、すべての利用可能なビューを要求することができる。それに従って、ＭＡＮＥは、すべての利用可能なビューを含むサブビットストリーム（またはフルビットストリーム）をこの宛先デバイスに提供することができる。別の宛先デバイスは、ステレオスコピック３次元再生（stereoscopic there-dimensional playback）のみが可能であり得るので、宛先デバイスは２つのビューのみを要求する。したがって、すべてのビューをこの宛先デバイスに送信するのではなく、ＭＡＮＥは、２つのビューのみを有するサブビットストリームを抽出し、このサブビットストリームを宛先デバイスに送信することができる。
[0067]本開示の技法によれば、ＭＡＮＥのようなサブビットストリーム抽出を実行するデバイスは、抽出されたサブビットストリーム中のＮＡＬユニットのＮＡＬユニットヘッダが、フルビットストリーム中の対応するＮＡＬユニットの元のＮＡＬユニットヘッダよりも使用するビットが少なくなるように、次元範囲パラメータセットと、与えられれば値マッピングテーブルに対するインデックスとを調整することができる。たとえば、宛先デバイスがステレオスコピック３次元再生のみが可能であり、たとえばｖｉｅｗ＿ｉｄ ３２および１５９にマッピングされるビュー順序インデックス「１」および「７」を有するビューを受信する上記の場合、ＭＡＮＥは、ビュー順序インデックスの値をそれぞれ「０」および「１」にするように調整し、ビュー順序インデックス「０」をｖｉｅｗ＿ｉｄ ３２にマッピングし、ビュー順序インデックス「１」をｖｉｅｗ＿ｉｄ １５９にマッピングするように、マッピングテーブルを調整することができる。
[0068]以下の表１は、次元範囲パラメータセットに対するシンタックスの例示的なセットを提供する。
Figure 2014522187
[0069]表１の様々なシンタックス要素の例示的な意味が、以下で説明される。Ｄｉｍ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、次元範囲パラメータセットの識別情報を示し得る。いくつかの例では、レイヤ化された（スケーラブルな）コーディングされたビデオシーケンス全体の復号の間、１つのみの次元パラメータセットが、アクティブになることが許される。複数のコーディングされたビデオシーケンスが同じｄｉｍ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを共有する場合、次元範囲パラメータは、ビットストリーム中の複数のコーディングされたビデオシーケンスのために使用され得る。次元範囲パラメータセットは、シーケンスパラメータセットよりも、パラメータセット階層においてより高い層にあり得る。さらに、対応する次元範囲パラメータセットを識別するデータが、ＳＰＳにおいてコーディングされ得る。
[0070]Ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔ＿ｂｉｔは、ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、この値が０に等しい場合、時間スケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｔｅｍｐｏｒａｌ＿ｉｄを有すると推測される。ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔ（以下の表２に関して説明される）の値によって示されるような、このコーディングされるビデオシーケンスでサポートされる時間レベルの数／カウントは、両端を含めて０から（２＜＜ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔ＿ｂｉｔ−１）にわたってよく、「＜＜」はビットごとの左シフトの演算子を表す。
[0071]Ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔ＿ｂｉｔは、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、この値が０に等しい場合、クロマサンプルフォーマットのスケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、プロファイルに応じて、４−２−０または４−４−４のサンプリングフォーマットを有すると推測される。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔ（以下の表２に関して説明される）の値によって示される、このコーディングされるビデオシーケンスでサポートされるクロマサンプルフォーマットの数／カウントは、両端を含めて０から（２＜＜ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔ＿ｂｉｔ−１）にわたる。
[0072]Ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔ＿ｂｉｔは、ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔ＿ｂｉｔの値が０に等しい場合、カラービット深度のスケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、プロファイルに応じて、８ビットまたは１０ビットまたは１２ビットとしてコーディングされると推測される。ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔの値によって示される、このコーディングされるビデオシーケンスにおいてサポートされるビット深度の数／カウントは、両端を含めて０から（２＜＜ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔ−１）にわたり得る。
[0073]Ｄｅｐｅｎｄｅｎｃｙ＿ｃｎｔ＿ｂｉｔは、ｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、ｄｅｐｅｎｄｅｎｃｙ＿ｃｎｔ＿ｂｉｔの値が０に等しい場合、時間スケーラビリティまたはＣＧＳはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｄｅｐｅｎｄｅｎｃｙ＿ｉｄを有すると推測される。このコーディングされるビデオシーケンスにおいてサポートされる依存性レイヤの数／カウントは、両端を含めて０から（２＜＜ｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔ＿ｂｉｔ−１）にわたり得る。
[0074]Ｑｕａｌｉｔｙ＿ｃｎｔ＿ｂｉｔは、ｑｕａｌｉｔｙ＿ｌｅｖｅｌ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、ｑｕａｌｉｔｙ＿ｃｎｔ＿ｂｉｔの値が０に等しい場合、品質／ＳＮＲのスケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｑｕａｌｉｔｙ＿ｉｄを有すると推測される。このコーディングされるビデオシーケンスにおいてサポートされる品質レベルの数／カウントは、両端を含めて０から（２＜＜ｑｕａｌｉｔｙ＿ｃｎｔ＿ｂｉｔ−１）にわたり得る。
[0075]Ｖｉｅｗ＿ｃｎｔ＿ｂｉｔは、ｖｉｅｗ＿ｃｎｔをシグナリングするために使用されるビットの数を示すことができ、これは以下の表２に関して説明される。いくつかの例では、ｖｉｅｗ＿ｃｎｔ＿ｂｉｔの値が０に等しい場合、１つのみのビューがサポートされ、各ＶＣＬ ＮＡＬユニットは、０に等しいｖｉｅｗ＿ｉｄとビュー順序インデックスとを有すると推測される。このコーディングされるビデオシーケンスにおいてサポートされるビューの数／カウントは、両端を含めて０から（２＜＜ｖｉｅｗ＿ｃｎｔ＿ｂｉｔ−１）にわたり得る。
[0076]０に等しいＤｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔ＿ｂｉｔは、深度データがビットストリームに含まれないことを示し得る。ｄｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔ＿ｂｉｔの値が１に等しいことは、深度ＶＣＬ ＮＡＬユニットがビットストリームに含まれることを示すことができ、ＮＡＬユニットがテクスチャビュー成分か深度ビュー成分かを示す１ビットが、ＮＡＬユニットヘッダ中にあり得る。
[0077]上の表１は、要素ｄｉｍ＿ｃｎｔ＿ｔａｂｌｅ（）を含む。下の表２は、表１のｄｉｍ＿ｃｎｔ＿ｔａｂｌｅ（）のシンタックス要素のセットの一例を表す。一般に、表１に関して上で論じられるシンタックス要素の値によって示されるような、表２のあるシンタックス要素のみを、ビデオエンコーダ２０はシグナリングし、ビデオデコーダ３０は受信することができる。
Figure 2014522187
[0078]表２の様々なシンタックス要素の例示的な意味が、以下で論じられる。Ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔは、コーディングされたビデオシーケンスにおいてサポートされる時間レベルの数を規定することができる。ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔが存在するかどうかは、表１のｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0079]Ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔは、コーディングされたビデオシーケンスにおいてサポートされる異なるクロマサンプルフォーマットの数を規定することができる。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔが存在するかどうかは、表１のｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0080]Ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔは、コーディングされたビデオシーケンスにおいてサポートされる異なるカラービット深度の数を規定することができる。ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔが存在するかどうかは、表１のｂｉｔ＿ｄｅｐｔｈ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0081]Ｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔは、コーディングされたビデオシーケンスにおいてサポートされる依存性レベルの数を規定することができる。ｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔが存在するかどうかは、表１のｄｅｐｅｎｄｅｎｃｙ＿ｌａｙｅｒ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0082]Ｑｕａｌｉｔｙ＿ｌｅｖｅｌ＿ｃｎｔは、コーディングされたビデオシーケンスの各々の依存性レイヤにおいてサポートされる品質レベルの最大の数を規定することができる。たとえば、１つのｑｕａｒｔｅｒ ｃｏｍｍｏｎ ｉｎｔｅｒｍｅｄｉａｔｅ ｆｏｒｍａｔ（ｑｃｉｆ）レイヤは、３つの品質レイヤを含んでよく、別のｃｏｍｍｏｎ ｉｎｔｅｒｍｅｄｉａｔｅ ｆｏｒｍａｔ（ｃｉｆ）レイヤは、１つの品質レイヤを含んでよく、ｑｕａｌｉｔｙ＿ｃｎｔは、この場合３に設定され得る。ｑｕａｌｉｔｙ＿ｌｅｖｅｌ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｑｕａｌｉｔｙ＿ｌｅｖｅｌ＿ｃｎｔが存在するかどうかは、表１のｑｕａｌｉｔｙ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0083]Ｖｉｅｗ＿ｃｎｔは、コーディングされたビデオシーケンスに含まれるビューの数を規定することができる。ｖｉｅｗ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｖｉｅｗ＿ｃｎｔが存在するかどうかは、表１のｖｉｅｗ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。
[0084]Ｄｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔは、マルチビュープラス深度フォーマットが関係する限り、ビュー成分中のサブビュー成分の異なるタイプの数を規定することができる。ｄｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔの値は、存在しない場合は１であると推測され得る。ｄｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔが存在するかどうかは、表１のｄｅｐｔｈ＿ｐｒｅｓｅｎｔ＿ｃｎｔ＿ｂｉｔの値に基づいて決定され得る。これらの技法の概念はさらに、各々のビュー成分の１つまたは複数の補助的なピクチャ、またさらにはレイヤ化された深度を含む、任意の３Ｄビデオフォーマットに対して拡張され得る。
[0085]いくつかの例では、上で説明されたシンタックス要素は、ルミナンス（ルーマ）成分またはクロミナンス（クロマ）成分のような、特定の成分に対して特有であり得る。その上、ビット深度値のような、別個の値が、ルーマとクロマに対してシグナリングされ得る。
[0086]上の表２に示されるような、スケーラブルな次元のシンタックス要素は、一般に２つのカテゴリのうちの１つに対応する。たとえば、ｔａｍｐｏｒａｌ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｄｅｐｅｎｄｅｎｃｙ＿ｉｄを含み得る第１のカテゴリでは、シグナリングされるインデックス値と、対応するスケーラブルな次元の値とは同等である。たとえば、ｔｅｍｐｏｒａｌ＿ｌｅｖｅｌ＿ｃｎｔが３である場合、ｔｅｍｐｏｒａｌ＿ｉｄの値は、すべてのＶＣＬ ＮＡＬユニットにおいて、両端を含めて０から２にわたり得る。
[0087]たとえば、ビュー次元およびカラービット深度次元を含み得る、他のカテゴリでは、ｖｉｅｗ＿ｉｄおよびｂｉｔ＿ｄｅｐｔｈのような厳密な特性の値は通常、インデックスよりも多くのビットを使用する。たとえば、ｖｉｅｗ＿ｃｎｔは３に等しく設定されてよく、３つのビューがｖｉｅｗ＿ｉｄの値４、６、８を有してよく、ＮＡＬユニットにおいて４、６、および８がシグナリングされるべきである場合、最大で４ビットが必要であり得る。一方、０、１、２のみがシグナリングされるべきである場合、２ビットのみが必要である。よって、値マッピングテーブルに対するインデックスは、このカテゴリに属するスケーラブルな次元に対して、インデックス値（より効率的である）から実際の特性（アプリケーションにとってより意味がある）を決定するためにシグナリングされ得る。以下の表３は、値マッピングテーブルに対するインデックスのシンタックスの例を表す。
Figure 2014522187
[0088]表３の値マッピングテーブルに対するインデックスの例示的な意味が、以下で説明される。Ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ［ｉ］は、ｉに等しいクロマインデックスを有するＶＣＬ ＮＡＬユニットにおける、ルーマサンプリングに対するクロマサンプリングを規定することができる。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値は、両端を含めて０から３の範囲にあり得る。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃが存在しない場合、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値は、１に等しいと推測され得る（４−２−０クロマフォーマット）。ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値は、表４に示されるように、クロマフォーマットにマッピングされ得る。
Figure 2014522187
[0089]再び表３を参照すると、ｂｉｔ＿ｄｅｐｔｈ＿ｍｉｎｕｓ８［ｉ］プラス８は、ｉに等しいビット深度インデックスを有するＶＣＬ ＮＡＬユニット中の、色成分のサンプルのビット深度を規定することができる。Ｖｉｅｗ＿ｉｄ［ｉ］は、ｉに等しいビューインデックスを有するＮＡＬユニットのビュー識別子を規定することができる。
[0090]あるいは、各次元において、カウントが１より大きい場合、値のみがシグナリングされ得る。カウントが１である場合、０インデックスに対応する値は、明示的にシグナリングされるのではなく、プロファイルによって推測され得る。以下の表５は、この例のシンタックスデータの例示的なセットを提供し、値は、カウントが１より大きい場合にのみ、シグナリングされる。
Figure 2014522187
[0091]以下の表６は、本開示の技法による、シーケンスパラメータセット（ＳＰＳ）のシンタックスの例示的なセットを提供する。いくつかのシンタックス要素は、ＨＥＶＣ ＷＤ７のＳＰＳと同じままであり得る。これらのシンタックス要素の意味も、ＨＥＶＣ ＷＤ７のＳＰＳと同じままであり得る。表６の例の追加されたまたは修正されたシンタックス要素の意味の例が、以下で説明される。
Figure 2014522187
[0092]表６のＳＰＳの例では、ＨＥＶＣ ＷＤ７のＳＰＳに対して追加または修正されたシンタックス要素は、ｄｉｍ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄと、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｘと、ｓｐｓ＿ｖｉｅｗ＿ｅｘｔｅｎｓｉｏｎ（）と、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘとを含む。関数ｆｕｎｃｔｉｏｎ＿ｃｈｒｏｍａ＿ｉｄｃ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、次のように定義され得る。すなわち、ｆｕｎｃｔｉｏｎ＿ｃｈｒｏｍａ＿ｉｄｃ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、そのようなｐｒｏｆｉｌｅ＿ｉｄｃがデフォルトのクロマサンプルフォーマット、たとえば４−２−０を有する場合、０を返し、それ以外の場合１を返す。関数ｆｕｎｃｔｉｏｎ＿ｖｉｅｗ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、次のように定義され得る。すなわち、ｆｕｎｃｔｉｏｎ＿ｖｉｅｗ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、そのようなｐｒｏｆｉｌｅ＿ｉｄｃが複数のビューコーディングに関連する場合、０を返し、それ以外の場合１を返す。Ｓｐｓ＿ｖｉｅｗ＿ｅｘｔｅｎｓｉｏｎ（）シンタックステーブルは、ビュー依存性と、マルチビュービデオコーディングまたは３Ｄビデオに関連する他の情報とを含み得る。関数ｆｕｎｃｔｉｏｎ＿ｂｉｔ＿ｄｅｐｔｈ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、次のように定義され得る。すなわち、ｆｕｎｃｔｉｏｎ＿ｂｉｔ＿ｄｅｐｔｈ（ｐｒｏｆｉｌｅ＿ｉｄｃ）は、そのようなｐｒｏｆｉｌｅ＿ｉｄｃが８ビットよりも大きなビット深度によってコーディングされる場合、０を返し、それ以外の場合１を返す。
[0093]以下の表７は、本開示の技法による、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットヘッダのシンタックスの例示的なセットを提供する。いくつかのシンタックス要素は、ＨＥＶＣ ＷＤ７のＮＡＬユニットヘッダと同じままであり得る。これらのシンタックス要素の意味も、ＨＥＶＣ ＷＤ７のＮＡＬユニットヘッダと同じままであり得る。表７の例の追加されたまたは修正されたシンタックス要素の意味の例が、以下で説明される。
Figure 2014522187
[0094]表７のＮＡＬユニットヘッダの例では、ＨＥＶＣ ＷＤ７に対して追加または修正されたシンタックス要素は、ｎａｌＵｎｉｔＳｃａｌａｂｌｅＣｈａｒＳｅｔとｒｅｓｅｒｖｅｄ＿ｂｉｔｓ、さらには、ｍ、ｒ、およびｎａｌＵｎｉｔＨｅａｄｅｒＢｙｔｅｓの計算を含む。ＮａｌＵｎｉｔＳｃａｌａｂｌｅＣｈａｒＳｅｔは、ＮＡＬユニットのスケーラブルな特性セットを規定することができる。ｎａｌＵｎｉｔＳｃａｌａｂｌｅＣｈａｒＳｅｔ中のビットは、たとえば、表１の次元範囲パラメータセットに基づいて、異なる次元に分離され得る。
[0095]一例では、ビデオエンコーダ２０およびビデオデコーダ３０は、ｍの値を以下のように計算することができる。
m= temporal_level_cnt_bit (2)+ chroma_format_cnt_bit (0) +
bit_depth_cnt_bit(0) + dependency_cnt_bit (1) + quality_cnt_plus1_bit (0) + view_cnt_plut1_bit(1)
[0096]この例では、ｍは４ビットに等しい。この例のビットストリームは、たとえば各ビューに対して異なる空間レイヤを有するステレオスコピック（２つのビューの）コンテンツを表すことができ、ビットストリームは最大で３つの時間レイヤを有し得る。
[0097]別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、ｍの値を以下のように計算することができる。
m= temporal_level_cnt_bit (3)+ chroma_format_cnt_bit (0) +
bit_depth_cnt_bit(0) + dependency_cnt_bit (0) + quality_cnt_plus1_bit (0) + view_cnt_plut1_bit(1)
[0098]この例では、ｍは４ビットに等しい。これは、たとえば、時間スケーラビリティを伴う７つのビューを有する、通常のマルチビューデータのビットストリームを表し得る。
[0099]別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、ｍの値を以下のように計算することができる。
m= temporal_level_cnt_bit (1)+ chroma_format_cnt_bit (0) +
bit_depth_cnt_bit(1) + dependency_cnt_bit (0) + quality_cnt_plus1_bit (0) + view_cnt_plut1_bit(0)
[0100]この例は、ＩＢＰＢＰ（ＩはＩフレームに対応し、ＢはＢフレームに対応し、ＰはＰフレームに対応する）でコーディングされるビットストリームを表すことができ、ビット深度のスケーラビリティは８ビットから１０ビットである。この例では、ｍは２ビットに等しい。
[0101]次元範囲パラメータセットは、ＮＡＬユニットヘッダ中のそれぞれのシンタックス要素を、より高機能なまたはより高度な特性へとマッピングすることを含んでよく、この特性は、それぞれのシンタックス要素によって直接伝えられないことがある。たとえば、ビュー順序インデックスまたは同様の代表的なシンタックス要素は、ＮＡＬユニットヘッダ中に存在し得るが、ｖｉｅｗ＿ｉｄ情報はＮＡＬユニットヘッダ中に存在しないことがあり、ビュー順序インデックス値のｖｉｅｗ＿ｉｄ値へのマッピングは、異なるシーケンスでは変化し得る。そのようなマッピングは、ＮＡＬユニットヘッダ中のシンタックス要素以外の情報を伝えることができ、たとえばｖｉｅｗ＿ｉｄ値に基づいて、より高度な適合を実現することができる。一般に、特定の次元のインデックスは、値マッピングテーブルに対するインデックス（たとえば、表３と表５のいずれかのｄｉｍ＿ｉｎｄｅｘ＿２＿ｖａｌｕｅ＿ｔａｂｌｅ）において定義されるように、ｉの値に対応し得る。すなわち、スケーラブルな次元のインデックス「ｉｄｘ」は、値マッピングテーブルに対するインデックスにおいてシグナリングされるような、スケーラブルな次元のｉ番目の値に対応し得る。このテーブルはまた、値シンタックスマッピングテーブルに対するインデックスと呼ばれ得る。
[0102]いくつかの例では、本開示の技法は、統一されたＮＡＬユニットヘッダという改善された設計に関する。たとえば、ＮＡＬユニットヘッダマップが、上で説明された次元範囲パラメータセットの代わりにコーディングされ得る。ＮＡＬユニットヘッダマップは、ＮＡＬユニットヘッダマップパラメータセット（ＮＰＳ）またはシーケンスパラメータセット（ＳＰＳ）においてコーディングされ得る。ＮＡＬユニットヘッダマップでは、各々のスケーラビリティ次元またはビュー次元、たとえば、空間スケーラビリティ次元、時間スケーラビリティ次元、品質スケーラビリティ次元、またはビュースケーラビリティ次元は、ＮＡＬユニットヘッダ中のシンタックス要素に対応し得る。その上、様々なスケーラビリティ次元のシンタックス要素は、ＮＡＬユニットヘッダに対する規定された長さを有し得る。すなわち、シンタックスデータは、スケーラビリティ次元に対応するＮＡＬユニットヘッダ中のシンタックス要素に対する長さを定義することができる。
[0103]特定のスケーラブルな次元の値がコーディングされたビデオシーケンス全体（たとえば、全体のビットストリーム）に対して変化しない場合、スケーラブルな次元に対応するシンタックス要素の長さは、ＮＡＬユニットヘッダにおいてゼロ（０）ビットとして定義されてよく、これは、シンタックス要素がＮＡＬユニットヘッダ中に存在しないことを意味するので、デフォルト値が、対応するビットストリーム中のすべてのＮＡＬユニットのスケーラブルな次元に対して導かれ得る。
[0104]いくつかの例では、ＮＡＬユニットヘッダ中のシンタックス要素は、より小型の方式でシグナリングされ得る。たとえば、シンタックス要素のＭ個の可能な値があるが、値がＮビットを占め得る場合（ここで、Ｎは、たとえば１＜＜ｃｅｉｌ（ｌｏｇ2（Ｍ＋１））よりもはるかに大きい）、ＮＡＬユニットヘッダ中のシンタックス要素のシグナリングはさらに、インスタンス、すなわちシンタックス要素の値に対するインデックスのみをシグナリングすることによって、最適化され得る。たとえば、Ｈ．２６４／ＡＶＣのマルチビュー拡張におけるｖｉｅｗ＿ｉｄは通常、１０ビットを使用する。しかしながら、ビューの選択されたセットが、たとえば、４５、５０、５５、および６０として、ｖｉｅｗ＿ｉｄ値のインスタンスを有する場合、２ビットのビューインデックス（ｖｉｅｗ＿ｉｄｘｓ）が、それぞれ、たとえばビュー「００」、「０１」、「１０」、および「１１」を表すために使用され得る。その上、シンタックスデータはビューインデックスとｖｉｅｗ＿ｉｄとの間のマッピングを定義する。
[0105]ＮＰＳ ＮＡＬユニットおよびＳＰＳ ＮＡＬユニットのＮＡＬユニットヘッダは、以下の表１２のＮＡＬユニットシンタックスにおいて示されるように、１バイトに固定されてよく、ｎａｌ＿ｒｅｆ＿ｆｌａｇは１に等しく設定されてよい。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、ＮＳＰ ＮＡＬユニットに対しては１０に等しくてよく、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、ＳＰＳ ＮＡＬユニットに対しては５に等しくてよい。他のタイプのＮＡＬユニットは、様々なＮＡＬユニットのタイプを使用することができる。あるいは、いくつかの例では、ＶＣＬ ＮＡＬユニットのみが、たとえば表１２に示されるように、拡張ＮＡＬユニットヘッダを含み、一方、非ＶＣＬ ＮＡＬユニットは、１バイトのＮＡＬユニットヘッダを含み得る。
[0106]以下の表８は、上の表１の次元範囲パラメータセットの代替として、本開示の技法による、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットヘッダマップパラメータセット（ＮＰＳ）のシンタックスの例示的なセットを提供する。表８の例のシンタックス要素の意味の例が、以下で説明される。
Figure 2014522187
[0107]表８の例示的なＮＡＬユニットヘッダマップパラメータセットシンタックスにおいて、ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎ、ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎ、およびｖｉｅｗ＿ｉｄｘ＿ｌｅｎの記述子が、ＨＥＶＣ ＷＤ７に対して修正される。加えて、表８の例示的なＮＡＬユニットヘッダマップパラメータセットシンタックスは、シンタックス要素ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎと、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓ＿ｌｅｎと、ｐｒｉｏｒｉｔｙ＿ｍａｐ（）と、条件付きで信号ｖｉｅｗ＿ｉｄｘ２ｉｄ＿ｔａｂｌｅ（）とを加える。ＮＡＬユニットヘッダマップパラメータシンタックスの他のシンタックス要素は、ＨＥＶＣ ＷＤ７と同じままであり得る。ＮＡＬユニットヘッダマップパラメータセット（ＮＰＳ）は一般に、ＮＡＬユニットヘッダマップを規定することができる。いくつかの例では、各々のコーディングされたビデオシーケンスにおいて、ただ１つのＮＡＬユニットヘッダがアクティブであり得る。すなわち、いくつかの例では、１つだけのＮＡＬユニットヘッダマップが、特定のビットストリームに適用される。
[0108]Ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐ＿ｉｄは、ＮＡＬユニットヘッダマップパラメータセットの識別情報を規定することができる。上で述べられたように、いくつかの例では、各々のコーディングされたビデオシーケンスにおいて、ただ１つのＮＡＬユニットヘッダマップがアクティブであり得る。代替的な例では、ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐ＿ｉｄは存在せず、各々のコーディングされたビデオシーケンスは、コーディングされたビデオシーケンス中の最初のＮＡＬユニットとして、１つのＮＡＬユニットヘッダマップＮＡＬユニットを含み得る。
[0109]Ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎは、ＮＡＬユニットヘッダ中のｐｒｉｏｒｉｔｙ＿ｉｄシンタックス要素と、優先度マップシンタックス構造中のｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］とを表すために使用されるビットの数を規定することができる。いくつかの例では、ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎが０に等しい場合、各ＶＣＬ ＮＡＬユニットは、０に等しいｐｒｉｏｒｉｔｙ＿ｉｄを有すると推測され得る。ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中でサポートされる優先度レイヤの数は、両端を含めて１から（２＜＜ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎ）の範囲にあり得る。
[0110]Ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎは、ＮＡＬユニットヘッダ中のｔｅｍｐｏｒａｌ＿ｉｄシンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎの両方が０に等しい場合、時間スケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｔｅｍｐｏｒａｌ＿ｉｄを有すると推測され得る。ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中でサポートされる時間レイヤの数は、（ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎ）の範囲にあってよく、または、（ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎ）の範囲にあってよい。いくつかの例では、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎの少なくとも１つは０に等しい。
[0111]Ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎは、ＮＡＬユニットヘッダ中のｄｅｐｅｎｄｅｎｃｙ＿ｉｄシンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎの両方が０に等しい場合、空間スケーラビリティまたは粗粒度のスケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｄｅｐｅｎｄｅｎｃｙ＿ｉｄを有すると推測され得る。ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中でサポートされる依存性レイヤの数は、（ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎ）の範囲にあってよく、または、（ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎ）の範囲にあってよい。いくつかの例では、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎの少なくとも１つは０に等しい。
[0112]Ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎは、ＮＡＬユニットヘッダ中のｑｕａｌｉｔｙ＿ｉｄシンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎの両方が０に等しい場合、品質／ＳＮＲのスケーラビリティはサポートされず、各ＶＣＬ ＮＡＬユニットは、０に等しいｑｕａｌｉｔｙ＿ｉｄを有すると推測され得る。ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中でサポートされる品質レイヤの数は、（ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎ）の範囲にあってよく、または、（ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎ）の範囲にあってよい。いくつかの例では、ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎの少なくとも１つは０に等しい。
[0113]Ｖｉｅｗ＿ｉｄｘ＿ｌｅｎは、ｖｉｅｗ＿ｉｄｘシンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｖｉｅｗ＿ｃｎｔ＿ｌｅｎおよびｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎの両方が０に等しい場合、１つのみのビューがサポートされ、各ＶＣＬ ＮＡＬユニットは、両方が０に等しいｖｉｅｗ＿ｉｄとビュー順序インデックスとを有すると推測される。ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中でサポートされるビューの数は、（ｖｉｅｗ＿ｉｄｘ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｖｉｅｗ＿ｉｄｘ＿ｌｅｎ）の範囲にあってよく、または、（ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎが０より大きい場合）両端を含めて１から（２＜＜ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎ）の範囲にあってよい。いくつかの例では、ｖｉｅｗ＿ｉｄｘ＿ｌｅｎとｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎの少なくとも１つは０に等しい。
[0114]Ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓ＿ｌｅｎは、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓシンタックス要素を表すために使用されるビットの数を規定することができる。ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓが１つまたは複数のシンタックス要素に割り当てられる場合、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓ＿ｌｅｎは、それに従って修正されてよく、新しい１つまたは複数のシンタックス要素のための長さシンタックス要素は、ＮＰＳにおいてシグナリングされ得る。
[0115]０に等しいＮｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｎｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素がＮＡＬユニットヘッダマップパラメータセットＲＢＳＰシンタックス構造中に存在することを規定することができる。Ｎｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、これらの例示的な技法に従うと、ビットストリーム中で０に等しくてよい。ｎｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために確保されていてよい。拡張が採用されビデオデコーダによってサポートされない限り、ビデオデコーダは、ＮＡＬユニットヘッダマップパラメータセットＮＡＬユニット中のｎｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１の後の、すべてのデータを無視するように構成され得る。
[0116]Ｎｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、任意の値を有し得る。このことは、本開示の技法によれば、プロファイルへの一致に現在は影響しない。
[0117]表８に示されるように、いくつかの例では、ｐｒｉｏｒｉｔｙ ｍａｐ（）シンタックス要素がシグナリングされ得る。以下の表９は、表８のｐｒｉｏｒｉｔｙ ｍａｐ（）のためのシンタックスデータの例示的なセットを提供する。表９のシンタックス要素の意味が、以下で説明される。一般に、優先度マップシンタックス構造は、各々のｐｒｉｏｒｉｔｙ＿ｉｄ値に対して、ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲と、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲と、ｑｕａｌｉｔｙ＿ｉｄ値の範囲と、ｖｉｅｗ＿ｉｄｘ値の数とのうちの、１つまたは複数を規定する。
Figure 2014522187
[0118]Ｎｕｍ＿ｐｒｉｏｒｉｔｙ＿ｉｄｓは、ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンス中のｐｒｉｏｒｉｔｙ＿ｉｄ値の数を規定することができる。ｎｕｍ＿ｐｒｉｏｒｉｔｙ＿ｉｄｓを表すために使用されるビットの数は、ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎに等しくてよい。
[0119]Ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎは、ｔｅｍｐｏｒａｌ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎの値は、存在しない場合、０に等しいと推測され得る。
[0120]Ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎは、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎの値は、０に等しいと推測され得る。
[0121]Ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎは、ｑｕａｌｉｔｙ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎの値は、０に等しいと推測され得る。
[0122]Ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎは、ｖｉｅｗ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。いくつかの例では、ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎの値は、０に等しいと推測され得る。
[0123]Ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］は、ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲、ｑｕａｌｉｔｙ＿ｉｄ値の範囲、およびｖｉｅｗ＿ｉｄ値の範囲のうちの１つまたは複数が以下のシンタックス要素によって規定される、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄ値を規定することができる。ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］を表すために使用されるビットの数は、ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎであってよい。
[0124]Ｔ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｔ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｔｅｍｐｏｒａｌ＿ｉｄ値の範囲を規定することができる。ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲は、両端を含めてｔ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｔ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎであってよい。いくつかの例では、この範囲は、存在しない場合、０から０であると推測され得る。
[0125]Ｄ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｄ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲を規定することができる。ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲は、両端を含めてｄ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｄ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらの２つのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎであってよい。いくつかの例では、この範囲は、存在しない場合、０から０であると推測され得る。
[0126]Ｑ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｑ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｑｕａｌｉｔｙ＿ｉｄ値の範囲を規定することができる。ｑｕａｌｉｔｙ＿ｉｄ値の範囲は、両端を含めてｑ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｑ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらの２つのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎであってよい。いくつかの例では、この範囲は、存在しない場合、０から０であると推測され得る。
[0127]ビデオエンコーダ２０およびビデオデコーダ３０は、次のように変数ＤＱＲａｎｇｅ［ｉ］を導出することができる。

DQRange[i] = [ d_id_low_range[i]*maxQlayer + q_id_low_range[i], d_id_high_range[i]*maxQlayer + q_id_high_range[i] ] (1)

ここで、ｍａｘＱｌａｙｅｒは、ＮＡＬユニットヘッダマップパラメータセットを参照する、すべてのコーディングされたビデオシーケンスのｑｕａｌｉｔｙ＿ｉｄの最大値である。
[0128]いくつかの例では、任意の２つのｐｒｉｏｒｉｔｙ＿ｉｄ値に対して、他のスケーラビリティ次元範囲が同じであれば、２つのｐｒｉｏｒｉｔｙ＿ｉｄ値のＤＱ範囲は重複しない。
[0129]Ｎｕｍ＿ｖｉｅｗｓ＿ｆｏｒ＿ｐｒｉｏｒｉｔｙ＿ｍｉｎｕｓ１［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｖｉｅｗ＿ｉｄｘ値の数を規定することができる。ｎｕｍ＿ｖｉｅｗｓ＿ｆｏｒ＿ｐｒｉｏｒｉｔｙ＿ｍｉｎｕｓ１の値は、両端を含めて０から（（１＜＜ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎ）−１）の範囲にあり得る。
[0130]Ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄ値に対応する、ｊ番目のビュー順序インデックスを規定することができる。ｖｉｅｗ＿ｉｄ［ｉ］［ｊ］を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎであってよい。いくつかの例では、ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］の値は、存在しない場合、０に等しいと推測され得る。
[0131]表８に示されるように、いくつかの場合には、ビューＩＤテーブルに対するビューインデックス（ｖｉｅｗ＿ｉｄｘ２ｉｄ＿ｔａｂｌｅ（））は、ＮＡＬユニットヘッダマップパラメータセットにおいてシグナリングされ得る。ビューＩＤテーブルに対するビューインデックスに対するシンタックスの例示的なセットは、以下の表１０に示される。ビューＩＤテーブルに対するビューインデックスの例示的な意味は、以下で説明される。一般に、ビューＩＤテーブルに対するビューインデックスは、ビュー識別子の値への、各々のビューインデックス値のマッピングを規定する。ビューインデックス値は、ＮＡＬユニットヘッダ中でシグナリングされてよく、対応するビュー識別子は、ビューＩＤテーブルに対するビューインデックスにおいて規定されたデータから決定され得る。
Figure 2014522187
[0132]Ｖｉｅｗ＿ｃｎｔは、ＮＡＬユニットヘッダマップパラメータセットを参照する、コーディングされたビデオシーケンスに含まれるビューの最大の数を規定することができる。ｖｉｅｗ＿ｃｎｔを表すために使用されるビットの数は、ｖｉｅｗ＿ｉｄｘ＿ｌｅｎに等しくてよい。
[0133]Ｖｉｅｗ＿ｉｄ［ｉ］は、ｉに等しいビューインデックスを有する、ＮＡＬユニットのビュー識別子を規定することができる。
[0134]以下の表１１は、本開示の技法による、シーケンスパラメータセット（ＳＰＳ）のシンタックスデータの例示的なセットを示す。ＨＥＶＣ ＷＤ７に対して追加または変更されたシンタックス要素の意味が、以下で論じられる。この例示的なＳＰＳの他のシンタックス要素は詳しく論じられず、変更されないシンタックス要素の意味は、たとえばＨＥＶＣ ＷＤ７において定義されたものと同じままであり得る。
Figure 2014522187
[0135]表１１の例では、ＳＰＳは、追加のシンタックス要素「ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐ＿ｉｄ」を含む。上で述べられたように、示されず省略記号（ellipses）によって表されるものを含む、他のシンタックス要素の意味は、たとえばＨＥＶＣ ＷＤ７において定義されたものから変更されないままでよい。この例では、ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐ＿ｉｄは、シーケンスパラメータセットによって参照される、ＮＡＬユニットヘッダマップパラメータセットの識別子を規定することができる。したがって、ＳＰＳは、ＳＰＳに対応するシーケンスのコーディングの間に使用される、ＮＡＬユニットヘッダマップを識別することができる。
[0136]以下の表１２は、ＮＡＬユニットのシンタックス要素の例示的なセットを示す。やはり、いくつかのシンタックス要素が、ＨＥＶＣ ＷＤ７に対して追加または変更され、それらのシンタックス要素の例示的な意味が以下で説明される。ＨＥＶＣ ＷＤ７に対して変更されない他のシンタックス要素は、ＨＥＶＣ ＷＤ７において定義された意味を保ってよい。
Figure 2014522187
Figure 2014522187
[0137]この例では、ＮＡＬユニットヘッダが、０ｘ００００００、０ｘ０００００１、０ｘ０００００２、または０ｘ０００００３に等しい連続的な３バイトを含まないものとなるように、制約が定められ得る。ｐｒｉｏｒｉｔｙ＿ｉｄの意味は、ｐｒｉｏｒｉｔｙ＿ｉｄを表すために使用されるビットの数がｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎであり得ることを除き、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ＳＶＣにおける同じシンタックス要素と同様であり得る。ｔｅｍｐｏｒａｌ＿ｉｄの意味は、ｔｅｍｐｏｒａｌ＿ｉｄを表すために使用されるビットの数がｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎであり得ることを除き、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ＨＥＶＣ ＷＤ７の場合と同じであり得る。
[0138]この例では、ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔは、１に等しいものとする。ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔの値０は、関連するコーディング規格、たとえばＨＥＶＣのさらなる拡張によって規定され得る。ビデオデコーダ３０のようなデコーダは、ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔの値を無視するように構成され得る。
[0139]ｄｅｐｅｎｄｅｎｃｙ＿ｉｄの意味は、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄを表すために使用されるビットの数がｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎであり得ることを除き、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ＳＶＣの場合と同じシンタックス要素であり得る。ｑｕａｌｉｔｙ＿ｉｄの意味は、ｑｕａｌｉｔｙ＿ｉｄを表すために使用されるビットの数がｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎであり得ることを除き、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ＳＶＣにおける同じシンタックス要素と同じであり得る。Ｖｉｅｗ＿ｉｄｘは、ビューのビュー順序インデックスを規定することができる。ｖｉｅｗ＿ｉｄｘの意味は、ｖｉｅｗ＿ｉｄｘを表すために使用されるビットの数がｖｉｅｗ＿ｉｄｘ＿ｌｅｎであり得ることを除き、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ＭＶＣにおけるビュー順序インデックスと同じであり得る。
[0140]いくつかの例では、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの各ビットは１に等しくてよい。ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの他の値は、関連するコーディング規格、たとえばＨＥＶＣのさらなる拡張によって規定され得る。ビデオデコーダ３０のようなデコーダは、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの値を無視するように構成され得る。ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓを表すために使用されるビットの数は、たとえば表８による対応するｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿ｍａｐにおいて規定されるような、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓ＿ｌｅｎであってよい。いくつかの例では、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの各ビットは１に等しくてよい。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの他の値は、今後の規格、または、ＨＥＶＣの拡張のような規格の拡張によって規定され得る。ビデオデコーダ３０のようなデコーダは、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの値を無視するように構成され得る。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓを表すために使用されるビットの数は、（（（ｍ＋７＞＞３）＜＜３）−ｍ）であり得る。
[0141]上で説明された技法の代替として、ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎ、ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎ、ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎ、およびｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎは存在しなくてよく（すなわち、シグナリングされなくてよく）、他のシンタックス要素は、仕様におけるｐｒｉｏｒｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、およびｑｕａｌｉｔｙ＿ｉｄのシンタックス要素の最大値に応じて、固定長でシグナリングされてよく、または、ｕｅ（ｖ）、すなわち、符号のない整数指数ゴロム（Ｅｘｐ−Ｇｏｌｏｍｂ）ビットストリングによってシグナリングされ得る。
[0142]いくつかの例では、表９の優先度マップは、以下の表１３の優先度マップにより置き換えられてよい。
Figure 2014522187
[0143]表１３の優先度マップのシンタックス要素とその意味は、全般に表９のそれらと同じままであり得る。しかしながら、特定の優先度ＩＤに対するビューの数のビューインデックスをシグナリングするのではなく、表１３の優先度マップは、ｖ＿ｉｄｘ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］とｖ＿ｉｄｘ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］とを提供する。この例では、ｖ＿ｉｄｘ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｖ＿ｉｄｘ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｖｉｅｗ＿ｉｄｘ値の範囲を規定する。ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲は、両端を含めてｖ＿ｉｄｘ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｖ＿ｉｄｘ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらの２つの範囲の値を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎであってよい。この範囲は、存在しない場合、０から０であると推測され得る。
[0144]いくつかの例では、特定のシンタックス要素（たとえば、ｔｅｍｐｏｒａｌ＿ｉｄ）に対する低い範囲と高い範囲とをシグナリングする代わりに、範囲の高い側（または低い側）のみ、たとえばｔｅｍｐｏｒａｌ＿ｉｄ＿ｈｉｇｈをシグナリングすることが可能である。したがって、ビデオコーダは、範囲のシグナリングされない部分の値、たとえばｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｏｗに対してゼロを推測するように構成され得る。
[0145]いくつかの例では、ｐｒｉｏｒｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘのいずれも、ＮＡＬユニットヘッダにおいて明示的にシグナリングされない。代わりに、これらのシンタックスの１つまたは複数は、ｉｍｐｌｉｃｉｔ＿ｉｄ＿ｔａｂｌｅ（）という名称のシンタックス構造において暗黙的にシグナリングされてよく、ｉｍｐｌｉｃｉｔ＿ｉｄ＿ｔａｂｌｅ（）は、ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造を置き換え得る。ｉｍｐｌｉｃｉｔ＿ｉｄ＿ｔａｂｌｅ（）の例が表１４に示され、シンタックス要素の意味の例が以下で与えられる。
Figure 2014522187
[0146]表１４の例示的なシンタックス構造は、ｐｒｉｏｒｉｔｙ＿ｉｄ値の数を規定し、また、各々のｐｒｉｏｒｉｔｙ＿ｉｄ値に対して、ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲と、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲と、ｑｕａｌｉｔｙ＿ｉｄ値の範囲と、ｖｉｅｗ＿ｉｄｘ値の数とのうちの、１つまたは複数を規定する。Ｉｍｐｌｉｃｉｔ＿ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎは、ｎｕｍ＿ｐｒｉｏｒｉｔｙ＿ｉｄとｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］シンタックス要素とを表すために使用されるビットの数を規定することができる。ｉｍｐｌｉｃｉｔ＿ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎの値は、存在しない場合、０に等しいと推測され得る。Ｎｕｍ＿ｐｒｉｏｒｉｔｙ＿ｉｄｓは、ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］シンタックス要素の数を規定することができる。ｎｕｍ＿ｐｒｉｏｒｉｔｙ＿ｉｄｓを表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎに等しくてよい。Ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎは、ｔｅｍｐｏｒａｌ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎの値は、存在しない場合、０に等しいと推測され得る。
[0147]Ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎは、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎの値は、０に等しいと推測され得る。Ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎは、ｑｕａｌｉｔｙ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎの値は、０に等しいと推測され得る。Ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎは、ｖｉｅｗ＿ｉｄ［ｉ］シンタックス要素を表すために使用されるビットの数を規定することができる。ｐｒｉｏｒｉｔｙ＿ｍａｐ（）シンタックス構造が存在しない場合、ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎの値は、０に等しいと推測され得る。
[0148]Ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］は、ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲、ｑｕａｌｉｔｙ＿ｉｄ値の範囲、およびｖｉｅｗ＿ｉｄ値の範囲のうちの１つまたは複数が、ｔ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］、ｔ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］、ｄ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］、ｄ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］、ｑ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］、およびｑ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］というシンタックス要素によって規定される、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄ値を規定することができる。ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｐｒｉｏｒｉｔｙ＿ｉｄ＿ｌｅｎであってよい。あるいは、ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］は存在しなくてよく、ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］は、ｉに等しい、または、ｉの関数としての何らかの他の値であると推測され得る。
[0149]Ｔ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｔ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｔｅｍｐｏｒａｌ＿ｉｄ値の範囲を規定することができる。ｔｅｍｐｏｒａｌ＿ｉｄ値の範囲は、両端を含めてｔ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｔ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｌｅｎであってよい。この範囲は、存在しない場合、０から０であると推測され得る。
[0150]Ｄ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｄ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲を規定することができる。ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ値の範囲は、両端を含めてｄ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｄ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらの２つのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ＿ｌｅｎであってよい。この範囲は、存在しない場合、０から０であると推測され得る。
[0151]Ｑ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］およびｑ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｑｕａｌｉｔｙ＿ｉｄ値の範囲を規定することができる。ｑｕａｌｉｔｙ＿ｉｄ値の範囲は、両端を含めてｑ＿ｉｄ＿ｌｏｗ＿ｒａｎｇｅ［ｉ］からｑ＿ｉｄ＿ｈｉｇｈ＿ｒａｎｇｅ［ｉ］−１であってよい。これらの２つのシンタックス要素を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｑｕａｌｉｔｙ＿ｉｄ＿ｌｅｎであってよい。この範囲は、存在しない場合、０から０であると推測され得る。
[0152]変数ＤＱＲａｎｇｅ［ｉ］は、次のように導出され得る。
DQRange[i] = [ d_id_low_range[i]*maxQlayer + q_id_low_range[i],
d_id_high_range[i]*maxQlayer + q_id_high_range[i] ],
ここで、ｍａｘＱｌａｙｅｒは、ＮＡＬユニットヘッダマップパラメータセットを参照する、すべてのコーディングされたビデオシーケンスのｑｕａｌｉｔｙ＿ｉｄの最大値である。
[0153]任意の２つのｐｒｉｏｒｉｔｙ＿ｉｄ値に対して、他のスケーラビリティ次元範囲が同じである場合、それらのＤＱ範囲は、ＤＱ範囲が重複しないように設定され得る。
[0154]Ｎｕｍ＿ｖｉｅｗｓ＿ｆｏｒ＿ｐｒｉｏｒｉｔｙ＿ｍｉｎｕｓ１［ｉ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄに対応するｖｉｅｗ＿ｉｄｘ値の数を規定することができる。ｎｕｍ＿ｖｉｅｗｓ＿ｆｏｒ＿ｐｒｉｏｒｉｔｙ＿ｍｉｎｕｓ１の値は、両端を含めて０から（（１＜＜ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄ＿ｌｅｎ）−１）の範囲にあり得る。Ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］は、ｉ番目のｐｒｉｏｒｉｔｙ＿ｉｄ値に対応する、ｊ番目のビュー順序インデックスを規定することができる。ｖｉｅｗ＿ｉｄ［ｉ］［ｊ］を表すために使用されるビットの数は、ｉｍｐｌｉｃｉｔ＿ｖｉｅｗ＿ｉｄｘ＿ｌｅｎであってよい。ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］の値は、存在しない場合、０に等しいと推測され得る。
[0155]したがって、一例では、ビデオエンコーダ２０およびビデオデコーダ３０（またはソースデバイス１２および宛先デバイス１４の他の要素）は、表１〜７のいずれかまたはすべてに従ってシンタックスデータをコーディングして、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対して有効かを表す情報をコーディングし、有効なビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、有効ではないビデオコーディング次元の値をコーディングすることなく、有効なビデオコーディング次元の各々の値をコーディングするように構成され得る。
[0156]あるいは、別の例では、ビデオエンコーダ２０およびビデオデコーダ３０（またはソースデバイス１２および宛先デバイス１４の他の要素）は、表８〜１４のいずれかまたはすべてに従ってシンタックスデータをコーディングして、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対して有効かを表す情報をコーディングし、有効なビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、有効ではないビデオコーディング次元の値をコーディングすることなく、有効なビデオコーディング次元の各々の値をコーディングするように構成され得る。
[0157]さらに他の例では、表１〜１４の様々な態様は、これらの例のハイブリッドを形成するように任意の組合せで組み合わされて、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対して有効かを表す情報をコーディングし、有効なビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、有効ではないビデオコーディング次元の値をコーディングすることなく、有効なビデオコーディング次元の各々の値をコーディングすることができる。
[0158]ビデオエンコーダ２０およびビデオデコーダ３０は各々、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合されてよい。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
[0159]図２は、ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を実施し得るビデオエンコーダ２０の例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングとインターコーディングとを実行し得る。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去する。インターコーディングは、時間的予測を利用して、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード（Ｉモード）は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
[0160]図２に示されるように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照フレームメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピーコーディングユニット５６とを含む。モード選択ユニット４０は、今度は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、区分ユニット４８とを含む。ビデオブロックの復元のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。復元されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングする、デブロッキングフィルタ（図２に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは一般に、加算器６２の出力をフィルタリングすることになる。また、デブロッキングフィルタに加えて追加のフィルタ（ループ内またはループ後）が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、（ループ内フィルタとして）加算器５０の出力をフィルタリングし得る。
[0161]符号化処理中に、ビデオエンコーダ２０はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的な予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は代替的に、空間的な予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
[0162]その上、区分ユニット４８は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、さらに、ＬＣＵをサブＣＵに区分することを示す４分木データ構造を生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。
[0163]モード選択ユニット４０は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラまたはインターのうちの１つを選択することができ、残差ブロックデータを生成するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器５０に与え、参照フレームとして使用するための符号化されたブロックを復元するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器６２に与える。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報のような、シンタックス要素をエントロピーコーディングユニット５６に与える。
[0164]動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成する処理である。動きベクトルは、たとえば、現在のフレーム（または他のコーディングされたユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコーディングされたユニット）内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるブロックに精密に一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照フレームメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0165]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライスにおけるビデオブロックのＰＵのための動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択されてよく、その各々は、参照フレームメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。
[0166]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを含み得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。現在のビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、参照ピクチャリストのうちの１つにおいて動きベクトルが指す予測ブロックの位置を特定し得る。加算器５０は、以下で論じられるように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するための、ビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
[0167]イントラ予測ユニット４６は、上で説明されたように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、たとえば、別個の符号化パスの間に、様々なイントラ予測モードを使用して現在ブロックを符号化することができ、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから、使用するのに適切なイントラ予測モードを選択することができる。
[0168]たとえば、イントラ予測ユニット４６は、様々なテストされたイントラ予測モードに対するレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化されたブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を示すかを決定するために、様々な符号化されたブロックのひずみおよびレートから比率を計算し得る。
[0169]ブロックのイントラ予測モードを選択した後に、イントラ予測ユニット４６は、エントロピーコーディングユニット５６にブロックのための選択されたイントラ予測モードを示す情報を与え得る。エントロピーコーディングユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、各コンテキストについて使用すべき、最も可能性の高いイントラ予測モード、イントラ予測モードインデックステーブル、および修正されたイントラ予測モードインデックステーブルの指示とを含み得る、構成データを含み得る。
[0170]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数のコンポーネントを表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送信し得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化処理は、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化された変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。
[0171]量子化の後に、エントロピーコーディングユニット５６は量子化された変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースのエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピーコーディングユニット５６によるエントロピーコーディングの後に、符号化されたビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されてよく、あるいは、後の送信または取り出しのためにアーカイブされてよい。
[0172]逆量子化ユニット５８および逆変換ユニット６０は、それぞれ逆量子化と逆変換とを適用し、たとえば、参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを復元する。動き補償ユニット４４は、残差ブロックを参照フレームメモリ６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、復元された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６２は、復元された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照フレームメモリ６４に記憶するための復元されたビデオブロックを生成する。復元されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために、動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。
[0173]加えて、ビデオエンコーダ２０は、１つまたは複数の様々なスケーラブルなビデオコーディング次元を有するビデオデータをコーディングするように構成され得る。たとえば、ビデオエンコーダ２０は、様々なビュー、品質レイヤ（たとえば、信号対雑音比（ＳＮＲ）レイヤ）、優先度レイヤ、空間分解能レイヤ、時間レイヤ、カラービット深度レイヤ、クロマサンプルフォーマットレイヤ、依存性レイヤ、または他のそのようなスケーラブルな次元をコーディングするように構成され得る。一般に、スケーラブルな次元は、１つの値（たとえば、ビデオデータはその次元ではスケーリングされない）と値の範囲とのいずれかを有する。一般性を失うことなく、あるスケーラブルな次元に対する値の範囲において「低い」値が、範囲中のより高い値をコーディングするための基礎として使用されると仮定する。したがって、基本レイヤ（たとえば、基本ビュー、基本品質レイヤ、基本スケーラブルレイヤなど）が、スケーラブルな次元の１つまたは複数のより高層のレイヤをコーディングする時、基準として使用され得る。
[0174]例として、マルチビュービデオコーディングでは、基本レイヤ（たとえば、基本ビュー）は、２次元のビデオ表示のために、さらには、次元に沿ったより高層のレイヤのための基準として使用され得る。言い換えると、基本ビューは、ビュー内コーディングされてよく、すなわち、他のビューを何ら参照することなくコーディングされてよい。他のビューは、ビュー間コーディングされてよく、たとえば、基本ビューのような別のビューに対してコーディングされてよい。このようにして、ビデオデータを含むビットストリームは、単一のビューレイヤのみ（すなわち、あるビュー次元に対して単一の値）を含んでよく、または複数のビューレイヤ（すなわち、あるビュー次元に対して複数の可能性のある値）を含んでよい。
[0175]ビュー間予測を実行するために、ビデオエンコーダ２０は、現在のピクチャと同じ時間的な位置を有する、以前にコーディングされたビューの１つまたは複数のピクチャに対して、特定のビューの現在のピクチャのブロックを予測することができる。すなわち、現在のピクチャおよび参照ピクチャは各々、最終的にアクセスユニット内にカプセル化される場合、同じアクセスユニット内でカプセル化され得る。したがって、現在のピクチャおよび参照ピクチャは、最終的に表示される場合、実質的に同時に表示され得る。その上、現在のピクチャおよび参照ピクチャは、同一の相対的なピクチャ順序カウント（ＰＯＣ）値を有し得る。
[0176]より具体的には、ビュー間予測は、現在のビューにおける現在のピクチャの現在のブロックに対して、１つまたは複数の視差ベクトルを計算することを伴い得る。視差ベクトルは一般に、以前にコーディングされたビューの基準ピクチャにおける、精密に一致するブロックの位置を表し得る。動き推定ユニット４２は、以前にコーディングされたビューの参照ピクチャにおける、この精密に一致するブロックの探索を実行するように構成され得る。したがって、いくつかの例では、動き推定ユニット４２は、「動き／視差推定ユニット」と呼ばれ得る。視差ベクトルは全般に、視差ベクトルが異なるビューの参照ピクチャに対する変位を表すということを除き、視差ベクトルと同様の方式で機能し得る。その上、異なるビューは、互いに対して水平方向に移動されたカメラの視点に対応するので、視差ベクトルは通常、水平方向のオフセットのみを表す。
[0177]別の例として、空間分解能次元（spatial resolution dimension）に対して、ビデオエンコーダ２０は、２つ以上のレイヤ、すなわち、１つの基本レイヤ、１つ以上のエンハンスメントレイヤとを使用して、元の空間分解能を有するピクチャをコーディングするように構成され得る。基本レイヤのピクチャは、元の空間分解能よりも低い分解能を有してよく、エンハンスメントレイヤのピクチャは、基本レイヤピクチャの分解能を上げるためのデータを含み得る。たとえば、元の空間分解能は、１０８０ｐに相当し得る。この例では、４８０ｐの空間分解能を有するピクチャを含む基本レイヤと、７２０ｐの空間分解能を達成するための第１のエンハンスメントレイヤと、１０８０ｐの空間分解能を達成するための第２のエンハンスメントレイヤという、３つのレイヤがあり得る。
[0178]ビデオエンコーダ２０は、あらゆる他のレイヤに対して独立に、基本レイヤのビデオデータをコーディングすることができる。ビデオエンコーダ２０は次いで、下層のレイヤ、たとえば基本レイヤまたはより下層のエンハンスメントレイヤに対して、エンハンスメントレイヤのビデオデータをコーディングすることができる。元のデータからこれらのレイヤを生成するために、ビデオエンコーダ２０はまず、元のピクチャの空間分解能を縮小し（decimate）、サブサンプリングし、または低減して、基本レイヤのピクチャを生成することができる。ビデオエンコーダ２０は次いで、上で説明されたようなピクチャ内コーディング技法またはピクチャ間（たとえば、時間的）コーディング技法を使用して、基本レイヤのピクチャをコーディングすることができる。
[0179]ビデオエンコーダ２０は次いで、基本レイヤのピクチャを復号しアップサンプリング（たとえば、補間）して、次のエンハンスメントレイヤにおける空間分解能を有するピクチャを生成することができる。ビデオエンコーダ２０はまた、元のピクチャの分解能を下げて、このエンハンスメントレイヤの空間分解能を有するピクチャを生成することができる。ビデオエンコーダ２０は次いで、分解能が下げられたピクチャとアップサンプリングされた基本レイヤのピクチャとのピクセルごとの差を計算して、エンハンスメントレイヤのための残差データを生成することができ、ビデオエンコーダ２０はこの残差データを、変換し、量子化し、エントロピー符号化することができる。ビデオエンコーダ２０はこの処理を繰り返すことができ、コーディングされるべきすべてのエンハンスメントレイヤに対して、直近にコーディングされたエンハンスメントレイヤを基本レイヤとして扱う。同様に、ビデオエンコーダ２０は、様々な他のスケーラブルな次元に対して、様々な他のレイヤにおけるピクチャを符号化することができる。
[0180]さらに別の例として、ビデオエンコーダ２０は、スケーラブルな時間次元を有するビデオデータをコーディングすることができる。一般に、ビデオエンコーダ２０は、時間識別子がピクチャの属する時間レイヤを表すために使用され得るように、時間識別子をピクチャに割り当てることができる。その上、ビデオエンコーダ２０は、ある特定の時間レイヤにおいて、ビデオデータがその時間レイヤまたはより下層の時間レイヤにおける他のビデオデータのみに対して予測されるように、ビデオデータをコーディングすることができる。このようにして、サブビットストリームの抽出を実行して、フルビットストリームのフレームレートに対して、下げられたフレームレートのためのサブビットストリームを抽出することができ、サブビットストリームは適切に復号可能であり、それは、抽出されないビデオデータは、抽出されたサブビットストリームに対する基準として使用されないからである。
[0181]ビデオエンコーダ２０は、複数のスケーラブルな次元に従ってビデオデータを符号化することができる。一般に、ビデオエンコーダ２０は最終的に、スケーラブルな次元の各々の特定の共通部分に対応する、ＮＡＬユニットのセットを生成する。たとえば、特定のビットストリームに対して、時間次元がスケーラブルであり、空間分解能次元がスケーラブルであり、他の次元は固定されていると仮定する。さらに、時間次元には４つの時間レイヤがあり、空間分解能次元には３つの空間分解能レイヤがあると仮定する。したがって、各アクセスユニットは、すべての３つの空間分解能に対するＮＡＬユニットを含み得る。このようにして、サブビットストリームは、特定の時間レイヤまでアクセスユニットを抽出することによって、かつ／または、特定の空間分解能レイヤまでそれらのアクセスユニットからＮＡＬユニットを抽出することによって、抽出され得る。
[0182]別の例として、特定のビットストリームに対して、ビュー次元がスケーラブルであり、空間分解能次元がスケーラブルであり、他の次元は固定されていると仮定する。さらに、ビュー次元には８つのビューがあり、空間分解能次元には３つの空間分解能レイヤがあると仮定する。したがって、各アクセスユニットは、２４個のピクチャ、すなわち、８つのビューおよびこれらの８つのビューの各々に対する３つの空間分解能に対する、ＮＡＬユニットを含み得る。この例では、サブビットストリームは、どのビューを取り出す（retrieve）べきかということと、これらのビューのいずれの空間分解能を取り出す（retrieve）べきかということとを決定し、決定されたビューのビュー識別子と決定された空間分解能とを有するＮＡＬユニットを抽出することによって、抽出され得る。
[0183]より一般的には、ビットストリームのための、イネーブルされたスケーラブルな次元の数をＮとし、Ｎは整数である。イネーブルされたスケーラブルな次元の各々Ｄ1、Ｄ2、…ＤNに対して、レイヤの範囲を１〜ＭａｘKとし、ここで１＜＝Ｋ＜＝である。次いで、ビットストリームに対して、ピクチャの総数は、Ｍａｘ1×Ｍａｘ2×…×ＭａｘN、すなわち
Figure 2014522187
であり得る。スケーラブルな次元の各々は、ある特定のピクチャにおいて交わることがあり、この特定のピクチャに対して、対応するアクセスユニットにおいて１つまたは複数のＮＡＬユニットがあり得る。本開示の技法によれば、ＮＡＬユニットの各々は、ピクチャのうちのいずれにＮＡＬユニットが対応するかを示すデータを含み得る。その上、ＮＡＬユニットは、非スケーラブルな次元に対するデータを含む必要はない。したがって、全体でＰ個の可能性のあるスケーラブルな次元があり得るが、ＮがＰより小さければ、ＮＡＬユニットは、（Ｐ−Ｎ）個のイネーブルされていないスケーラブルな次元の値を含めることなく、Ｎ個のイネーブルされたスケーラブルな次元の値を示すために、Ｎ個のイネーブルされたスケーラブルな次元のデータを含めるだけでよい。その上、ビデオエンコーダ２０は、スケーラブルな次元のうちのいずれがアクティブであるかということと、いくつかの場合には、アクティブかつスケーラブルな次元の各々のデータを表すために使用されるＮＡＬユニットヘッダ中のビットの数とを示すために、次元範囲パラメータセットまたはＮＡＬユニットヘッダマップパラメータセットをコーディングすることができる。
[0184]したがって、８つのビューおよび３つの空間スケーラビリティレイヤがある上の例を再び参照すると、ビデオエンコーダ２０は、３ビットをＮＡＬユニットヘッダのビュー識別子部分に割り当て、２ビットをＮＡＬユニットヘッダの空間スケーラビリティレイヤ部分に割り当てることができる。これらの５ビットは一緒に、ＮＡＬユニットが対応するビューと、ＮＡＬユニットが対応する空間スケーラビリティレイヤの両方を示すことができる。たとえば、「０００１０」は基本ビュー「０００」と空間スケーラビリティレイヤの第１のエンハンスメントレイヤ「１０」とに対応してよく、一方「１１１００」は、８つのビュー「１１１」と空間スケーラビリティレイヤの基本レイヤ「００」とに対応してよい。一般に、特定の有効かつスケーラブルな次元に対してＮ個の可能な値があると仮定すると、ビデオエンコーダ２０は、ＮＡＬユニットヘッダ中でｃｅｉｌ（ｌｏｇ2（Ｎ））を割り当てることができ、ｃｅｉｌ（Ｘ）は、次の最高の整数値に切り上げられたＸの値を返す。したがって、Ｘが整数値である場合、ｃｅｉｌ（Ｘ）はＸを返し、一方ＸがＡ．Ｂと表される有理数であるとき、ｃｅｉｌ（Ｘ）は（Ａ＋１）を返す。
[0185]ビデオエンコーダ２０は、外部のソース、たとえばユーザまたは構成データから、イネーブルされた（「アクティブ」とも呼ばれる）スケーラブルな次元の数の定義を受信することができる。加えて、この定義はまた、イネーブルされたスケーラブルな次元の各々に対する可能性のある値の範囲を示す情報を含み得る。したがって、ビデオエンコーダ２０は、これらの受信された定義に基づいて、様々なスケーラブルな次元に対して、ＮＡＬユニットヘッダにおいて使用されるべきビットの数を割り当てることができる。ビデオエンコーダ２０は次いで、これらの割り当てに基づいて、次元範囲パラメータセットまたはＮＡＬユニットヘッダマップパラメータセットを構築し、また、割り当てられたビットに基づいてＮＡＬユニットヘッダをコーディングすることができる。
[0186]加えて、特定のスケーラブルな次元の値が１だけアトミックに（atomically）増えない場合（たとえば、ｖｉｅｗ＿ｉｄの場合）、ビデオエンコーダ２０は、スケーラブルな次元の値にインデックス値をマッピングする、マッピングテーブルをコーディングすることができる。たとえば、１、1８、４６、１６９、２００、２５０、３８５、および３９９というｖｉｅｗ＿ｉｄを有するビットストリームに対して、８つのビューがあると仮定する。ビデオエンコーダ２０は、０、１、２、３、４、５、６、および７というビューインデックスをこれらのｖｉｅｗ＿ｉｄ値にマッピングし、それに従ってマッピングテーブルをコーディングすることができる。このようにして、ビデオエンコーダ２０は、ｖｉｅｗ＿ｉｄを直接コーディングするのではなく、ビューインデックスを示すＮＡＬユニットヘッダをコーディングすることができる。ビデオデコーダ３０のようなデコーダは、ビューインデックスに基づいて、ＮＡＬユニットのｖｉｅｗ＿ｉｄを決定するために、マッピングテーブルを参照することができる。
[0187]このようにして、図２のビデオエンコーダ２０は、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされたかを表す情報をコーディングし、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングするように構成される、ビデオエンコーダの例を表す。
[0188]図３は、ビデオデータのスケーラブルな次元の特性をシグナリングするための技法を実施し得るビデオデコーダ３０の例を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照フレームメモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明された符号化パスとは全般に逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成することができ、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成することができる。
[0189]復号処理中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化されたビデオスライスのビデオブロックと、関連するシンタックス要素とを表す、符号化されたビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化された係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。
[0190]ビデオスライスがイントラコーディングされた（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの以前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた（すなわち、Ｂ、ＰまたはＧＰＢ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャの１つから生成され得る。ビデオデコーダ３０は、参照フレームメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照フレームリスト、すなわち、リスト０とリスト１とを構築し得る。
[0191]動き補償ユニット７２は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックのための予測情報を決定し、その予測情報を使用して、復号されている現在のビデオブロックの予測ブロックを生成する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数の構築情報と、スライスの各々のインター符号化されたビデオブロックの動きベクトルと、スライスの各々のインターコーディングされたビデオブロックのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。
[0192]動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための補間された値を計算し得る。この場合、動き補償ユニット７２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。
[0193]逆量子化ユニット７６は、ビットストリーム中で与えられエントロピー復号ユニット８０によって復号された、量子化された変換係数を、逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化処理は、量子化の程度を判定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ３０によって計算される量子化パラメータＱＰYの使用を含み得る。
[0194]逆変換ユニット７８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換処理を変換係数に適用して、ピクセル領域において残差ブロックを生成する。
[0195]動き補償ユニット８２が、動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット８２によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数のコンポーネントを表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタリングするためのデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化し、または他の方法でビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ９２に記憶される。参照フレームメモリ８２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上で後で表示するために、復号されたビデオを記憶する。
[0196]ビデオデコーダ３０はまた、１つまたは複数のスケーラブルな次元に従ってコーディングされるビデオデータを復号するように構成され得る。たとえば、ビデオデコーダ３０は、様々なビュー、品質レイヤ（たとえば、信号対雑音比（ＳＮＲ）レイヤ）、優先度レイヤ、空間分解能レイヤ、時間レイヤ、カラービット深度レイヤ、クロマサンプルフォーマットレイヤ、依存性レイヤ、または他のそのようなスケーラブルな次元を有するビデオデータを復号することができる。一般に、ビデオデコーダ３０は、レイヤを符号化するために使用されるのと全般に反対の方式で、これらのレイヤを復号することができる。
[0197]その上、ビデオデコーダ３０（またはビデオデコーダ３０に通信可能に結合される別のユニット）は、ＮＡＬユニットヘッダデータを使用して、特定のＮＡＬユニットのビデオデータが対応する１つまたは複数のレイヤを決定することができる。たとえば、ビットストリームが、ビュー次元、空間分解能次元、および時間次元に関してスケーラブルである場合、ビデオデコーダ３０は、本開示の技法に従って、ＮＡＬユニットヘッダからのＮＡＬユニットのデータに対する、ビューと、空間分解能レイヤと、時間識別子とを決定することができる。ビデオデータが対応するレイヤの決定は、ビデオデータの解析および／または復号がどのように実行されるかに影響し得る。たとえば、ＮＡＬユニットがマルチビュービデオデータの基本ビューに対応する場合、ビデオデコーダ３０は、ＮＡＬユニットのビデオデータがビュー間コーディングされるかどうかを決定することを試みる必要はない。
[0198]さらに、ＮＡＬユニットヘッダを解釈するために、ビデオデコーダ３０は、次元範囲パラメータセットまたはＮＡＬユニットヘッダマップパラメータセットにおいてシグナリングされるシンタックスデータのような、他のシンタックスデータを参照し得る。そのようなシンタックスデータは、複数のスケーラブルな次元のうちのいずれがイネーブルされるかということと、イネーブルされるスケーラブルな次元の各々に割り当てられるＮＡＬユニットヘッダ中のビットの数とを示し得る。このようにして、ビデオデコーダ３０がビット「０１０１１０１」を受信し、最初の３ビットがビューインデックスを特定し、次の２ビットが空間分解能レイヤを特定し、最後の２ビットが時間レイヤを特定することを、シンタックスデータが示す場合、ビデオデコーダ３０は、ビューインデックスは「０１０」（たとえば、２）であり、空間分解能レイヤは「１１」（たとえば、３）であり、時間レイヤは「０１」（たとえば、１）であると決定することができる。いくつかの場合には、これらの値は、マッピングテーブルに対するインデックスとして機能することができ、マッピングテーブルは、インデックスを、対応する次元の実際の値にマッピングすることができる。したがって、ビデオデコーダ３０はさらに、マッピングテーブルを使用して、インデックスから実際の値を決定することができる。
[0199]このようにして、図３のビデオデコーダ３０は、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされているかを表す情報をコーディングし、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングするように構成される、ビデオデコーダの例を表す。
[0200]図４は、ビデオデータのスケーラブルな次元の特性をシグナリングするための本開示の技法を実行し得るデバイスの別のセットを含むシステム１００を示すブロック図である。システム１００は、コンテンツ準備デバイス１２０と、サーバデバイス１６０と、クライアントデバイス１４０と、メディア認識ネットワーク要素（ＭＡＮＥ）１７２とを含む。いくつかの例では、コンテンツ準備デバイス１２０およびサーバデバイス１６０は、同じサービスに対応し得るが、図４では説明のために別々に示される。この例では、コンテンツ準備デバイス１２０は、オーディオソース１２２と、ビデオソース１２４と、オーディオエンコーダ１２６と、ビデオエンコーダ１２８と、カプセル化ユニット１３０と、出力インターフェース１３２とを含む。ビデオソース１２４は、ビデオソース１８（図１）に実質的に対応し得るが、ビデオエンコーダ１２８は、ビデオエンコーダ２０（図１および図２）に実質的に対応し得る。
[0201]ネットワーク１７０Ａおよびネットワーク１７０Ｂは、ネットワーク通信のための、１つまたは複数のデバイスのネットワークを表す。一般に、ネットワーク１７０Ａ、１７０Ｂは、ネットワーク通信データを送信するための、ルータ、ハブ、スイッチ、ゲートウェイ、ファイアーウォールなどのような、１つまたは複数のネットワークデバイスを含む。いくつかの例では、ネットワーク１７０Ａおよびネットワーク１７０Ｂは、同じネットワーク、たとえばインターネットを表し得る。他の例では、ネットワーク１７０Ａおよびネットワーク１７０Ｂは、異なるネットワークを表し得る。たとえば、ネットワーク１７０Ａはインターネットを表してよく、ネットワーク１７０Ｂはコンテンツ配信ネットワークを表してよい。この例では、ＭＡＮＥ １７２は、ネットワーク１７０Ａとネットワーク１７０Ｂとの間に存在する。ＭＡＮＥ １７２は、ネットワーク１７０Ａとネットワーク１７０Ｂとの間のＭＡＮＥ １７２を通過するネットワーク通信において、メディアデータを認識し処理するように構成され得る。
[0202]一般に、オーディオソース１２２およびビデオソース１２４は、それぞれ、互いに対応するオーディオデータとビデオデータとを提供することができる。たとえば、オーディオソース１２２はマイクロフォンを備えてよく、ビデオソース１２４はビデオカメラを備えてよく、オーディオソース１２２は、ビデオソース１２４がビデオデータをキャプチャするのと実質的に同時にオーディオデータをキャプチャすることができる。あるいは、オーディオソース１２２およびビデオソース１２４はそれぞれ、オーディオデータとビデオデータとを生成する、コンピュータ生成ソースに対応し得る。いずれの場合でも、コンテンツ準備デバイス１２０は、互いに対応する、すなわち実質的に同時に一緒に再生されるべき、オーディオデータとビデオデータとを示すシンタックスデータ、たとえばタイムスタンプを提供することができる。オーディオエンコーダ１２６は、種々のオーディオコーディング技法のいずれかを使用して、オーディオソース１２２から受信されたオーディオデータを符号化し、符号化されたオーディオデータをカプセル化ユニット１３０に提供することができる。同様に、ビデオエンコーダ１２８は、符号化されたビデオデータをカプセル化ユニット１３０に提供することができる。符号化されたビデオデータは、１つまたは複数の様々なスケーラブルな次元のデータを含み得る。
[0203]この例では、カプセル化ユニット１３０は、１つまたは複数のスケーラブルな次元のデータを含むＮＡＬユニットヘッダのコーディングに関連する、本開示の様々な技法を実行することができる。たとえば、カプセル化ユニット１３０は、ビデオエンコーダ１２８からのビデオデータのコーディングされたスライスを、ＮＡＬユニットへとカプセル化することができる。その上、カプセル化ユニット１３０は、ＮＡＬユニットの各々に対して、１つまたは複数のスケーラブルな次元の値を決定し、これらの値を表すデータを含むＮＡＬユニットヘッダを生成することができる。さらに、カプセル化ユニット１３０は、複数のスケーラブルな次元のうちのいずれがカプセル化されたオーディオデータとビデオデータとを含むビットストリームに対して有効かを示し、有効かつスケーラブルな次元の各々に割り当てられたＮＡＬユニットヘッダ内で割り当てられたビットを示す、次元範囲パラメータセットまたはＮＡＬユニットヘッダマップパラメータセットのような、高水準のシンタックスデータを生成することができる。カプセル化ユニット１３０はまた、オーディオエンコーダ１２６から受信された、符号化されたオーディオデータをカプセル化することができる。カプセル化ユニット１３０はさらに、オーディオデータまたはビデオデータを含むＮＡＬユニットを、それぞれのアクセスユニットへカプセル化することができる。
[0204]オーディオデータとビデオデータとをカプセル化した後、カプセル化ユニット１３０は、カプセル化されたデータを出力インターフェース１３２に提供することができる。出力インターフェース１３２は、記憶インターフェース、ネットワークインターフェース、またはデータを出力するための他のインターフェースを備え得る。出力インターフェース１３２によって提供されるデータは、サーバデバイス１６０に配信され、コーディングされたメディアデータ１６２として記憶され得る。サーバデバイス１６０はまた、たとえば、クライアントデバイス１４０から受信されたネットワーク要求に応答して、コーディングされたメディアデータ１６２の複数の部分を取り出すための、メディア検索（retrieval）ユニット１６４を含む。ネットワークインターフェース１６６は、この例では、ネットワーク１７０Ａを介して、要求されたメディアデータをクライアントデバイス１４０に提供する。ネットワークインターフェース１６６は、有線ネットワークインターフェースまたはワイヤレスネットワークインターフェースを備え得る。
[0205]クライアントデバイス１４０は、ネットワークインターフェース１５４と、検索アプリケーション１５２と、カプセル化解除ユニット１５０と、オーディオデコーダ１４６と、ビデオデコーダ１４８と、オーディオ出力１４２と、ビデオ出力１４４とを含む。オーディオ出力１４２は、１つまたは複数のスピーカーを備えてよく、ビデオ出力１４４は、３次元ビデオデータを表示するように構成され得る１つまたは複数のディスプレイを備え得る。たとえば、ビデオ出力１４４は、１つまたは複数の立体視ディスプレイまたはオートステレオスコピックディスプレイを備え得る。オーディオ出力１４２は、様々なタイプのオーディオ出力も可能であり得る。たとえば、オーディオ出力１４２は、様々な組合せで複数のスピーカーを含み得る（たとえば、２スピーカーステレオ、４以上のスピーカーのサラウンドサウンド、センタースピーカーを有しもしくは有さない、および／または、サブウーファー（subwoofer）を有しもしくは有さない）。このようにして、オーディオ出力１４２およびビデオ出力１４４は、様々な出力特性を有し得る。たとえば、ビデオ出力１４４は、様々なレンダリング特性を有し得る。
[0206]オーディオデコーダ１４６は一般に、符号化されたオーディオデータを復号できるが、ビデオデコーダ１４８は一般に、符号化されたビデオデータを復号できる。クライアントデバイス１４０は、実質的に同時に提示されるべきオーディオデータおよびビデオデータが、オーディオ出力１４２およびビデオ出力１４４による提示のために利用可能となるように、オーディオデコーダ１４６とビデオデコーダ１４８との間の復号処理を調整することができる。オーディオデコーダ１４６は何らかの復号能力を有してよく、一方ビデオデコーダ１４８は何らかの復号能力（すなわち、何らかの復号特性）を有してよい。たとえば、ビデオデコーダ１４８は、特定のビデオコーディング規格、または、ビデオコーディング規格の特定のプロファイルもしくはプロファイルのレベルに従い得る。すなわち、ビデオデコーダ１４８は、何らかのビデオコーディング技法を使用することが可能であり得るが、他のビデオコーディング技法を使用することは可能ではないことがある。
[0207]一般に、ネットワークインターフェース１５４は、ネットワーク１７０Ｂを介してメディアデータを受信し、受信されたデータを検索アプリケーション１５２に提供する。たとえば、検索アプリケーション１５２は、たとえばｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）に従って、メディアデータを取り出し処理するように構成されるウェブブラウザを備え得る。検索アプリケーション１５２は、オーディオデコーダ１４６、ビデオデコーダ１４８、オーディオ出力１４２、およびビデオ出力１４４の復号能力とレンダリング能力とをそれぞれ定義する情報によって構成され得る。したがって、検索アプリケーション１５２は、オーディオデコーダ１４６、ビデオデコーダ１４８、オーディオ出力１４２、およびビデオ出力１４４の能力に基づいて、メディアデータを選択することができる。たとえば、ビデオ出力１４４がステレオスコピックビデオ表示のみが可能である場合、検索アプリケーション１５２は、３つ以上のビューを有するメディアデータの検索を避けることができる。このようにして、検索アプリケーション１５２は、使用できないデータ、たとえば３つ以上のビューを有するメディアデータの検索を避けることができ、これによって、不十分な帯域幅リソースを節減し、３つ以上のビューを含むビットストリームを不必要に解析し復号するのを避けることができる。
[0208]そのようなビットストリームを取得するために、検索アプリケーション１５２は、オーディオデコーダ１４６、ビデオデコーダ１４８、オーディオ出力１４２、およびビデオ出力１４４の特性を示すデータをＭＡＮＥ １７２に提供することができる。上の例を続けると、検索アプリケーション１５２は、ビデオ出力１４４がステレオスコピックビデオデータの出力のみが可能であることを示すデータを、ＭＡＮＥ １７２に与えることができる。したがって、ＭＡＮＥ １７２がクライアントデバイス１４０によって要求されたビットストリームを受信し、ビットストリームが３つ以上のビューを含む場合、ＭＡＮＥ １７２は、クライアントデバイス１４０のために、２つのビューしか有さないサブビットストリームを抽出することができる。
[0209]言い換えると、サブビットストリーム抽出処理の間、次元中にある範囲の値を有するいくつかのＮＡＬユニットが、たとえばＭＡＮＥ １７２によって、除去され得る。したがって、上で論じられたように、ＭＡＮＥ １７２は、いくつかの次元に対する調整された数のビットを含む、データ構造１７４Ｂによって表される、新たな次元範囲パラメータセット（または新たなＮＡＬユニットヘッダパラメータセット）を生成することができる。次元範囲パラメータセットの例に関して、ｄｉｍ＿ｃｎｔ＿ｔａｂｌｅならびにｄｉｍ＿ｉｎｄｅｘ＿２＿ｖａｌｕｅ＿ｔａｂｌｅも、元の次元範囲パラメータセットに対して調整され得る。その上、ｎａｌＵｎｉｔＳｃａｌａｂｌｅＣｈａｒＳｅｔへとグループ化される現実の空ではないシンタックス要素は変更されるか、または特定の要素を表すために使用されるビットの数が減らされ得る。
[0210]その上、本開示の技法によれば、ＭＡＮＥ １７２は、特定のビットストリームに対するイネーブルされたスケーラブルな次元を表すデータ構造１７４Ａを受信することができる。たとえば、データ構造１７４Ａが、スケーラブルな次元の中でもとりわけ、ビュー次元がイネーブルされ、その上、８つのビューのデータがビットストリーム中に存在するということを示すと仮定する。しかしながら、上の例を続けると、クライアントデバイス１４０は、ステレオスコピックビデオ表示のみが可能であり得る。したがって、ＭＡＮＥ １７２は、２つのビューしか有さないサブビットストリームを抽出することができる。その上、ＭＡＮＥ １７２は、抽出されたサブビットストリームの特性を示す修正されたデータ構造１７４Ｂを形成するように、データ構造１７４Ａを修正することができる。
[0211]たとえば、抽出されたサブビットストリームの２つのビューがビューインデックス「２」と「６」とを有する場合、ＭＡＮＥ １７２は、それぞれ代わりに「０」と「１」という値を有するようにビューインデックスを調整することができる。マッピングテーブルがデータ構造１７４Ａにおいて提供される場合、ＭＡＮＥ １７２はさらに、新たなインデックス値を適切なビュー識別子（または他のスケーラブルな次元の他のデータ）にマッピングするように、マッピングテーブルを調整することができる。さらに、サブビットストリームのＮＡＬユニットに対して、ＭＡＮＥ １７２は、たとえば、フルビットストリームに対して範囲が狭められたスケーラブルな次元の不必要なビットを除去することによって、または、抽出されたサブビットストリームに対してイネーブルされていないスケーラブルな次元に対し、ＮＡＬユニットヘッダからシグナリングデータ全体を除去することによって、ＮＡＬユニットヘッダがフルビットストリームの元のＮＡＬユニットヘッダよりも短くなる（たとえば、より少数のビットを含む）ように、ＮＡＬユニットヘッダを変更することができる。
[0212]修正されたデータ構造１７４Ｂを作成しサブビットストリームを抽出した後で、ＭＡＮＥ １７２は、修正されたデータ構造１７４Ｂと抽出されたサブビットストリームとを、ネットワーク１７０Ｂを介してクライアントデバイス１４０に提供することができる。クライアントデバイス１４０は、有線ネットワークインターフェースまたはワイヤレスネットワークインターフェースを備え得るネットワークインターフェース１５４を介して、修正されたデータ構造１７４Ｂと抽出されたサブビットストリームとを受信することができる。
[0213]このようにして、ＭＡＮＥ １７２は、第１のＮＡＬユニットを備えるビットストリームのサブビットストリームを抽出することと、サブビットストリームは第１のＮＡＬユニットのビデオデータの少なくとも一部分を含む第２のＮＡユニットを備え、サブビットストリームのために、複数のビデオコーディング次元のうちのいずれがサブビットストリームに対してイネーブルされているかを表す情報をコーディングすることと、第２のＮＡＬユニットの変更されたＮＡＬユニットヘッダにおいて、イネーブルされていないビデオコーディング次元の値をコーディングすることなく、サブビットストリームに対してイネーブルされたビデオコーディング次元の各々の値をコーディングすることと、変更されたＮＡＬユニットヘッダは、第１のＮＡＬユニットのＮＡＬユニットヘッダのビット長よりも短いビット長を有する、を行うように構成される、デバイスの例を表す。
[0214]ＭＡＮＥ １７２は、これらの技法を実行するように構成される制御ユニットを含み得る。制御ユニットは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組合せで実装され得る。ソフトウェアおよび／またはファームウェアで実装される場合、１つまたは複数のプロセッサによって実行され得る命令を記憶するための１つまたは複数のプロセッサおよびメモリのような、必須のハードウェアも設けられると推定される。同様に、コンテンツ準備デバイス１２０、サーバデバイス１６０、およびクライアントデバイス１４０の要素も、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せで実装されてよく、やはり、ソフトウェアまたはファームウェアが使用される場合にそれらを実行するために、必須のハードウェアが設けられると推測される。
[0215]図５Ａおよび図５Ｂは、本開示の技法の様々な例による、ＮＡＬユニットヘッダの例を示す概念図である。図５Ａおよび図５Ｂは全般に、ＮＡＬユニットヘッダに含まれ得るスケーラビリティまたはビューの次元識別子のセット（すなわち、スケーラブルな次元の識別子）の例を表す。図５Ａは、ｔｅｍｐｏｒａｌ＿ｉｄ １８２と、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｘ １８４と、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘ １８６と、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ １８８と、ｑｕａｌｉｔｙ＿ｉｄ １９０と、ｖｉｅｗ＿ｉｄｘ １９２と、ｔｅｘｔｕｒｅ＿ｄｅｐｔｈ＿ｉｄｘ １９４とを含む、例示的なＮＡＬユニットヘッダ１８０を示す。一般に、ｔｅｍｐｏｒａｌ＿ｉｄ １８２、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｘ １８４、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘ １８６、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ １８８、ｑｕａｌｉｔｙ＿ｉｄ １９０、ｖｉｅｗ＿ｉｄｘ １９２、およびｔｅｘｔｕｒｅ＿ｄｅｐｔｈ＿ｉｄｘ １９４のいずれかまたはすべての値は、対応する次元がスケーラブルなものとして有効かどうかに基づいて、シグナリングされ得る。
[0216]さらに、ｔｅｍｐｏｒａｌ＿ｉｄ １８２、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｘ １８４、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘ １８６、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ １８８、ｑｕａｌｉｔｙ＿ｉｄ １９０、ｖｉｅｗ＿ｉｄｘ １９２、およびｔｅｘｔｕｒｅ＿ｄｅｐｔｈ＿ｉｄｘ １９４のいずれかまたはすべてに割り当てられるビットの数は、たとえば上で論じられた表１に従って、次元範囲パラメータセット中で示され得る。このようにして、ＮＡＬユニットヘッダ１８０は、表１の次元範囲パラメータセットに従って構築された、ＮＡＬユニットヘッダの例を表す。したがって、ｔｅｍｐｏｒａｌ＿ｉｄ １８２、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｘ １８４、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘ １８６、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ １８８、ｑｕａｌｉｔｙ＿ｉｄ １９０、ｖｉｅｗ＿ｉｄｘ １９２、およびｔｅｘｔｕｒｅ＿ｄｅｐｔｈ＿ｉｄｘ １９４の値は、存在する場合、ＮＡＬユニットヘッダ１８０によってカプセル化されるＮＡＬユニットに対応するこれらの様々な次元の共通部分に基づいて、割り当てられ得る。イネーブルされないスケーラブルな次元（すなわち、ビットストリーム中に１つの可能な値しか有さないスケーラブルな次元）に対して、データは、ＮＡＬユニット１８０のＮＡＬユニットヘッダにおいてシグナリングされる必要はない。たとえば、ビットストリームに対して１ビットの深度しかない場合、ｂｉｔ＿ｄｅｐｔｈ＿ｉｄｘ １８６に対してデータは提供されなくてよい。
[0217]図５Ｂは、ｐｒｉｏｒｉｔｙ＿ｉｄ ２０２と、ｔｅｍｐｏｒａｌ＿ｉｄ ２０４と、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ ２０６と、ｑｕａｌｉｔｙ＿ｉｄ ２０８と、ｖｉｅｗ＿ｉｄｘ ２１０とを含む、別の例示的なＮＡＬユニットヘッダ２００を示す。このようにして、ＮＡＬユニットヘッダ２００は、表８のＮＡＬユニットヘッダマップパラメータセットに従って構築された、ＮＡＬユニットヘッダの例を表す。ＮＡＬユニットヘッダ２００は、他の部分についてはＮＡＬユニットヘッダ１８０に実質的に従う。当然、ＮＡＬユニットヘッダ２００のシンタックス要素は、ＮＡＬユニットヘッダ１８０に含まれてよく、同様に、ＮＡＬユニットヘッダ１８０のシンタックス要素は、様々な例において、上の表のシンタックスおよび意味に対する適切な変更を伴って、ＮＡＬユニットヘッダ２００に含まれてよい。
[0218]ＮＡＬユニットヘッダは、様々な異なる状況に対して設計され得る。以下に、いくつかの例が与えられる。しかしながら、他の例も、本開示の技法を使用して、想起され提示され得ることを理解されたい。
[0219]一例では、スケーラブルなビデオビットストリームは、Ｑｕａｒｔｅｒ Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ（ＱＶＧＡ）からＶｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ（ＶＧＡ）までの空間スケーラビリティを有するが、依存性レイヤは３つの時間レイヤを有する。そのような場合、３ビットが、ＮＡＬユニットヘッダ中でスケーラビリティ次元および／またはビュー次元をシグナリングするために使用され得る。たとえば、２ビットが、ｔｅｍｐｏｒａｌ＿ｉｄ ２０４を表すために割り当てられてよく、１ビットが、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ ２０６を表すために割り当てられてよく、ｑｕａｌｉｔｙ＿ＩＤ ２０８とｖｉｅｗ＿ＩＤＸ ２１０とを表すためのビットは割り当てられなくてよい。
[0220]別の例では、ステレオスコピックビットストリームは各ビューに対して２つの空間レイヤを有してよく、ビューの各々は３つの時間レイヤを有し得る。そのような場合、全体で４ビットがＮＡＬユニットヘッダを表すために使用されてよく、そのうち２ビットがｔｅｍｐｏｒａｌ＿ｉｄ ２０４を表すためのものであり、１ビットがｄｅｐｅｎｄｅｎｃｙ＿ｉｄ １８８を表すためのものであり、１ビットがｖｉｅｗ＿ｉｄｘ ２１０を表すためのものであり、０ビットがｑｕａｌｉｔｙ＿ｉｄ ２０８を表すためのものである。
[0221]別の例では、マルチビュービットストリームは、各々が２つの品質レイヤを有する８つのビューを含み得る。ビットストリームはまた、１６というＧＯＰサイズ（すなわち、４つの時間レイヤ）を有する階層的Ｂ予測構造によってコーディングされ得る。この例では、全体で７ビットが、ＮＡＬユニットヘッダにおいてスケーラビリティ次元および／またはビュー次元をシグナリングするために使用されてよく、そのうち３ビットがｔｅｍｐｏｒａｌ＿ｉｄ ２０４のためであり、０ビットがｄｅｐｅｎｄｅｎｃｙ＿ｉｄ ２０６のためであり、１ビットがｑｕａｌｉｔｙ＿ｉｄ ２０８のためであり、３ビットがｖｉｅｗ＿ｉｄｘ ２１０のためである。
[0222]図６は、ビデオデータのスケーラブルな次元の特性をシグナリングするための例示的な方法を示すフローチャートである。図６の方法は、例示のためにビデオエンコーダ２０に関して説明される。しかしながら、ソースデバイス１２（図１）の他のユニットまたはコンテンツ準備デバイス１２０および／もしくはサーバデバイス１６０（図４）のコンポーネントのような他のデバイスが、図６の方法を実行するように構成され得ることを理解されたい。同様に、ＭＡＮＥ １７２（図４）は、図６の方法のある態様を実行するように構成され得る。その上、図６の方法のあるステップは、省略されてよく、または異なる順次的な順序で実行されてよく、または並列に実行されてよく、他のステップが追加されてよいことを、理解されたい。
[0223]この例では、ビデオエンコーダ２０は、ビットストリームへと符号化され形成されるべきビデオデータに対する、１つまたは複数のスケーラブルな次元をイネーブルにする（２５０）。たとえば、ビデオエンコーダ２０は、優先度次元、空間分解能次元、時間次元、品質次元（たとえば、信号対雑音比（ＳＮＲ）次元）、ビュー次元、カラービット深度次元、クロマサンプルフォーマット次元、および／または依存性次元のうちの１つまたは複数のような、１つまたは複数のスケーラブルな次元を使用して、受信されたビデオデータがコーディングされるべきであるという指示を、外部のソース（たとえば、ユーザ）から受け取ることができる。
[0224]ビデオエンコーダ２０は次いで、イネーブルされたスケーラブルな次元に対する値の範囲を決定することができる（２５２）。たとえば、ビデオエンコーダ２０は、各次元に対して符号化されるべきレイヤの数を決定することができる。例として、受信されたビデオデータがＶ個のビューを有し、Ｖが整数である場合、ビデオエンコーダ２０は、Ｖ個の値がビュー次元の範囲において必要であると決定することができる。別の例として、空間分解能次元がイネーブルされ、１つの基本レイヤおよび２つのエンハンスメントレイヤという３つのレイヤがあるべきである場合、ビデオエンコーダ２０は、３つの値が空間分解能次元の範囲において必要であると判定することができる。一般に、各次元に対して、ビデオエンコーダ２０は、その次元内のレイヤ（またはビュー）を識別するための、次元中の値の範囲を決定することができる。
[0225]ビデオエンコーダ２０は次いで、決定された範囲に基づいて、イネーブルされたスケーラブルな次元のＮＡＬユニットヘッダにビットを割り当てることができる（２５４）。たとえば、Ｎをイネーブルされた次元の数とし、ＲKを次元Ｋの範囲のサイズを表すものとし、１≦Ｋ≦Ｎである。次元Ｋの値を表すために必要なビットの数を計算するために、ビデオエンコーダ２０は、ｃｅｉｌ（ｌｏｇ2（ＲK））を計算することができる。したがって、決定された範囲に基づいて、イネーブルされたスケーラブルな次元のＮＡＬユニットヘッダにおいて必要とされるビットの総数を計算するために、ビデオエンコーダ２０は、
Figure 2014522187
を計算することができ、ここでｃｅｉｌ（Ｘ）は、Ｘ以上の最大の整数に切り上げられるＸの値を返す。すなわち、Ｘが整数である場合、整数（Ｘ）をＸに返し、一方ＸがＡ．Ｂとして表される整数ではない有理数である場合、ｃｅｉｌ（Ｘ）は（Ａ＋１）を返す。このようにして、これらの値の合計は、各次元に対する値の決定された範囲に基づいて、イネーブルされた次元のＮＡＬユニットヘッダにおいて使用されるべきビットの総数を表し得る。
[0226]ビデオエンコーダ２０は次いで、ＮＡＬユニットヘッダに対するビットの割り当てを示すデータ構造をコーディングすることができる（２５６）。たとえば、ビデオエンコーダ２０は、上で説明されたように、表１に従って次元範囲パラメータセットをコーディングすることができ、または表８に従ってＮＡＬユニットヘッダマップをコーディングすることができる。データ構造は、固有の独立のデータ構造を形成することができ、または、シーケンスパラメータセット（ＳＰＳ）のような別のデータ構造に含まれてよい。いずれの場合でも、データ構造は一般に、有効な次元の各々に対するＮＡＬユニットヘッダ中のビットの数を示し得る。さらに、データ構造が０ビットをＮＡＬユニットヘッダ中の特定の次元に割り当てる場合、次元は、スケーラビリティがイネーブルされていないと決定され得る。言い換えると、０ビットがＮＡＬユニットヘッダにおいて割り当てられる次元は、対応するビットストリームに対してスケーラブルではないことがある。このようにして、データ構造はまた、スケーラブルな次元のいずれのスケーラビリティがイネーブルされているかの指示を提供する。
[0227]いくつかの例では、次元のレイヤの値は、１だけアトミックに増えないことがある。たとえば、ビュー次元のビュー識別子（ｖｉｅｗ＿ｉｄ）は、必ずしも、１という値だけ増えるとは限らない。別の例として、たとえばカラービット深度のビット深度値は、８ビット、１０ビット、および１２ビットの値を含み得る。したがって、上で論じられたような値の範囲を決定する時、範囲は、次元におけるレベルの実際の値に対する、インデックス値の範囲を含み得る。インデックス値は次いで、マッピングテーブルによって実際の値にマッピングされてよく、マッピングテーブルは、上記のコーディングされたデータ構造に含まれてよく、または別個のデータ構造として提供されてよい。マッピングテーブルは、単独で、または任意の組合せで、表３、表５、表９、表１０、または表１３のいずれかまたはすべてのシンタックスと意味（セマンティック）とに対応してよく、これらのテーブルの組合せは、１つのテーブルまたは複数の別個のテーブルとしてシグナリングされ得る。
[0228]ビデオエンコーダ２０は次いで、イネーブルされたスケーラブルな次元の共通部分に対するビデオデータのスライスをコーディングすることができる（２５８）。たとえば、ビデオエンコーダ２０が、ビュー次元と、空間分解能次元と、時間次元とをイネーブルにした場合、ビデオエンコーダ２０は、基本ビューのスライスと、０という時間識別子を有する空間分解能次元の基本レイヤとをコーディングすることを開始することができる。一般に、ステップ２５８においてコーディングされたスライスは、ビットストリームの任意に選択されたいずれのスライスをも表し得る。スライスのコーディングは一般に、イネーブルな次元に基づいてスライスをコーディングすることを伴う。したがって、ビュー次元のスケーラビリティがイネーブルであり、スライスが基本ビューではない場合、ビデオエンコーダ２０は、ビュー間予測を使用してスライスをコーディングすることができる。別の例として、空間分解能のスケーラビリティがイネーブルであり、スライスが基本レイヤではない場合、ビデオエンコーダ２０は、レイヤ間予測を使用してスライスをコーディングすることができる。複数のスケーラブルな次元がイネーブルである場合、ビデオエンコーダ２０は、スライスが基本レイヤ（または基本ビュー）において生じない次元のいずれに対して、イネーブルされたスケーラブルな次元のいずれかまたはすべてのためのレイヤ間予測を使用してスライスをコーディングすることができる。
[0229]ビデオエンコーダ２０は次いで、コーディングされたスライスをＮＡＬユニットにカプセル化することができる（２６０）。特に、ビデオエンコーダ２０は、スライスのためのイネーブルされたスケーラブルな次元の値を示す、スライスのＮＡＬユニットヘッダをコーディングすることができる（２６２）。特に、ビデオエンコーダ２０は、各々のスケーラブルな次元のレイヤまたはビューのいずれに、コーディングされたスライスが対応するかに基づいて、ＮＡＬユニットヘッダのビット値を決定する。たとえば、ビュー次元および空間分解能次元がイネーブルされ、８つのビューおよび３つの空間分解能レイヤがあり、最近コーディングされたスライスが、ビューインデックス「０１０」が割り当てられたビューと空間分解能インデックス「１１」が割り当てられた空間分解能レイヤとに対応する場合、ビデオエンコーダ２０は、ＮＡＬユニットヘッダにおいて「０１０１１」をコーディングし、イネーブルされたスケーラブルな次元の値を示すことができる。
[0230]このようにして、図６の方法は、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルされているかを表す情報をコーディングすることと、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングすることと、を含む方法の例を表す。
[0231]図７は、ビデオデータのスケーラブルな次元のシグナリングされた特性を使用するための例示的な方法を示すフローチャートである。図７の方法は、例示のためにビデオデコーダ３０に関して説明される。しかしながら、宛先デバイス１４（図１）の他のユニットまたはサーバデバイス１６０もしくはクライアントデバイス１４０（図４）のコンポーネントのような他のデバイスが、図７の方法を実行するように構成され得ることを理解されたい。同様に、ＭＡＮＥ １７２（図４）は、図７の方法のある態様を実行するように構成され得る。その上、図７の方法のあるステップは、省略されてよく、または異なる順次的な順序で実行されてよく、または並列に実行されてよく、他のステップが追加されてよいことを、理解されたい。
[0232]この例では、ビデオデコーダ３０は、ビットストリームのＮＡＬユニットに対するビットの割り当てを示す、データ構造を受信する（２８０）。たとえば、ビデオデコーダ３０は、次元範囲パラメータセットまたはＮＡＬユニットヘッダマップパラメータセットを受信することができ、これらは、独立のデータ構造としてシグナリングされてよく、または、シーケンスパラメータセットのような別のデータ構造内でシグナリングされてよい。加えて、ビデオデコーダ３０はまた、値マッピングテーブルに対するインデックスのような、インデックス値をスケーラブルな次元の実際の値にマッピングするマッピングテーブルを受信することができる。
[0233]一般に、データ構造中でシグナリングされるＮＡＬユニットに対するビットの割り当ては、複数のスケーラブルな次元のうちのいずれがビットストリームに対してイネーブルされているかということの指示を与えることができる。すなわち、ビデオデコーダ３０は、１つまたは複数のビットがＮＡＬユニットヘッダにおいて割り当てられるスケーラブルな次元のスケーラビリティがイネーブルであると、決定することができる。ビデオデコーダ３０は、０ビットがＮＡＬユニットヘッダにおいて割り当てられる他の次元がイネーブルされていないと、決定することができる。したがって、ビデオデコーダ３０は、ビットストリーム中のＮＡＬユニットに対する、イネーブルされていないスケーラブルな次元のデフォルト値を推測することができる。
[0234]ビデオデコーダ３０は次いで、コーディングされたビデオデータのスライスを含むＮＡＬユニットを受信することができる（２８２）。このＮＡＬユニットは、ビットストリームのいずれの任意のＮＡＬユニットをも表し得る。ビデオデコーダ３０は、イネーブルされたスケーラブルな次元の値を示す、ＮＡＬユニットヘッダを復号することができる（２８４）。すなわち、ビデオデコーダ３０は、ＮＡＬユニットヘッダに対するビットの割り当てを示すデータ構造を使用して、受信されたＮＡＬユニットのＮＡＬユニットヘッダの値を解釈することができる。その上、マッピングテーブルが受信された場合、ビデオデコーダ３０は、マッピングテーブルを使用して、対応するスケーラブルな次元の実際の値に対する、ＮＡＬユニットヘッダ中のインデックス値をさらに解釈することができる。
[0235]ビデオデコーダ３０は次いで、ＮＡＬユニットをカプセル化解除して、ＮＡＬユニットからコーディングされたスライスを取り出すことができる（２８６）。ビデオデコーダ３０は次いで、ＮＡＬユニットヘッダから決定されたように、イネーブルされたスケーラブルな次元の値に基づいて、スライスを復号することができる（２８８）。これらの値に基づいてスライスを復号することは、たとえば、スライスが各々のイネーブルされたスケーラブルな次元のいずれのレイヤ（またはビュー）に対応するかを決定することと、必要であれば、レイヤ間予測を使用してスライスを復号することとを含み得る。その上、レイヤ間予測が様々なスケーラブルな次元の１つまたは複数に対して利用可能かどうかに応じて、シンタックスデータの様々なセットが、スライスに対してシグナリングされ得る。たとえば、スライスが特定のスケーラブルな次元の基本レイヤに対応する場合、ビデオデコーダ３０は、対応するスケーラブルな次元のレイヤ間予測のための参照レイヤを示す、シンタックス要素を受信しないように構成され得る。
[0236]このようにして、図７の方法も、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルであるかを表す情報をコーディングすることと、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされてないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングすることと、を含む方法の例を表す。
[0237]図８は、ビデオデータのスケーラブルな次元の特性をシグナリングし、シグナリングされた特性を使用するための、別の例示的な方法を示すフローチャートである。図８の例は、ＭＡＮＥ（たとえば、図４のＭＡＮＥ １７２）およびクライアントデバイス（たとえば、図４のクライアントデバイス１４０）に関して説明される。他のデバイスが図８の方法の様々なステップを実行するように構成され得ることを、理解されたい。その上、ステップは、異なる順序で、または並列に実行されてよく、いくつかのステップは省略されてよく、一方他のステップが追加されてよい。
[0238]この例では、クライアントデバイス１４０は最初に、イネーブルされた利用可能かつスケーラブルな次元のサブセットを有するビデオデータを要求する（３００）。この要求は、クライアントデバイス１４０の、たとえば、ビデオデコーダ１４８およびビデオ出力１４４のコーディング能力およびレンダリング能力に基づき得る。要求は、サポートされるコーディング能力およびレンダリング能力の指示を表すことができ、特定のビットストリームに対するイネーブルされたスケーラブルな次元の特定のセットに対する明示的な要求を必ずしも表さないことがある。
[0239]ＭＡＮＥ １７２は、たとえばサーバデバイス１６０から、要求を受信し（３０２）、複数のスケーラブルな次元を有するビットストリームを受信する（３０４）ことができる。ビットストリームを受信することは、ビットストリームの一部分を受信することに対応してよく、このステップでビットストリーム全体を受信することには必ずしも対応しないことがある。ビットストリームは、ビットストリームに対するイネーブルされたスケーラブルな次元を示すデータ構造、ならびに、イネーブルされたスケーラブルな次元のＮＡＬユニットヘッダにおいてシグナリングされる値に対するビットの割り当てを含み得る。やはり、ＭＡＮＥ １７２によるこのデータ構造の受信は、図４の矢印１７４Ａによって表される。ＭＡＮＥ １７２は次いで、クライアントデバイス１４０から受信された要求に基づいて抽出されるべきサブビットストリームに基づいて、データ構造を変更することができる（３０６）。マッピングテーブルが提供される場合、ＭＡＮＥ １７２はさらに、マッピングテーブルを変更することができる。
[0240]たとえば、ビットストリームが８つのビューを含むが、クライアントデバイス１４０がステレオスコピック３Ｄ再生しかサポートしない場合、ＭＡＮＥ １７２は、抽出されるべきサブビットストリームが８つすべてではなく２つのビューのみを含むべきであると、決定することができる。特定のＮＡＬユニットに対応するビューを識別するために、元のデータ構造が３ビットをＮＡＬユニットヘッダに割り当てていた場合、ＭＡＮＥ １７２は代わりに、ビュー識別子（またはビューインデックス）のために、ＮＡＬユニットヘッダ中で１ビットのみを割り当てることができる。加えて、マッピングテーブルがビューインデックスをビュー識別子にマッピングした場合、ＭＡＮＥ １７２は、マッピングテーブルを変更して、抽出されたサブビットストリームに含まれるべき２つのみのビューのマッピングを反映することができる。
[0241]ＭＡＮＥ １７２は次いで、変更されたデータ構造をクライアントデバイス１４０に送信することができる（３０８）。やはり、変更されたデータ構造をクライアントデバイス１４０に送信することは、図４の矢印１７４Ｂによって表される。クライアントデバイス１４０は、今度は変更されたデータ構造を受信することができる（３１０）。
[0242]続いて、ＭＡＮＥ １７２は、ビットストリームからＮＡＬユニットを抽出することができる（３１２）。抽出されたＮＡＬユニットは、イネーブルされたスケーラブルな次元のすべての値を有し得る。しかしながら、ＭＡＮＥ １７２は、要求に基づいて、クライアントデバイス１４０に送信されるべき、サブビットストリームのＮＡＬユニットを変更することができる（３１４）。たとえば、ＭＡＮＥ １７２は、クライアントデバイス１４０によってサポートされないスケーラブルな次元の値を示すデータを、ＮＡＬユニットヘッダから除去することができる。ＭＡＮＥ １７２は、クライアントデバイスによってサポートされない、または必要とされない、スケーラブルな次元のレイヤのＮＡＬユニットを、クライアントデバイス１４０に送信しなくてよい。代わりに、ＭＡＮＥ １７２は、クライアントデバイス１４０によって要求されるデータを含むＮＡＬユニットのみを抽出し、必要に応じてＮＡＬユニットヘッダを変更することができる。
[0243]例として、元のビットストリームが８つのビューのデータを含んでいたが、クライアントデバイス１４０が２つのビューしか要求しなかった場合、ＭＡＮＥ １７２は、クライアントデバイス１４０に送信されるべき２つのビューに対応するＮＡＬユニットのみを抽出することができる。さらに、ＭＡＮＥ １７２は、ＮＡＬユニットヘッダを変更して、これらのＮＡＬユニットのビュー識別子（またはビューインデックス）の変更を反映することができる。たとえば、クライアントデバイス１４０に対して選択された２つのビューの元のＮＡＬユニットが、「０１０」および「１１０」というビューインデックス値を含んでいたと仮定する。ＭＡＮＥ １７２は、これらの値を、それぞれ、変更されたデータ構造のビット割り当てに基づいて、また変更されたマッピングテーブルに基づいて、「０」および「１」に変更することができる。
[0244]ＭＡＮＥ １７２は次いで、変更されたＮＡＬユニットをクライアントデバイス１４０に送信することができる（３１６）。クライアントデバイス１４０は、今度は、変更されたＮＡＬユニットを受信し（３１８）、変更されたＮＡＬユニットを復号する（３２０）ことができる。変更されたＮＡＬユニットを復号することは一般に、図７で説明された処理に対応し得る。したがって、本開示の技法によれば、クライアントデバイス１４０から見ると、サブビットストリームを処理することは全般に、ビットストリームを処理することとは必ずしも異ならない。
[0245]このようにして、図８の方法も、ビットストリームのために、複数のビデオコーディング次元のうちのいずれがそのビットストリームに対してイネーブルかを表す情報をコーディングすることと、イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていないビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングすることと、を含む方法の例を表す。ＭＡＮＥ １７２とクライアントデバイス１４０の両方が、そのような情報と値とをコーディングするデバイスを表す。
[0246]例によっては、本明細書で説明された技法のうちいずれかの、いくつかの行為またはイベントは、異なる順番で実行されてよく、追加され、統合され、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが、本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。
[0247]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されてよく、あるいは、コンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する、任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0248]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体を備え得る。同様に、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
[0249]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明される技法の実装に適切な他の構造のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内で与えられてよく、あるいは複合コーデックに組み込まれてよい。また、本技法は、１つまたは複数の回路または論理要素中で完全に実装され得る。
[0250]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネント、モジュール、またはユニットが説明されたが、それらのコンポーネント、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上で説明されたように、様々なユニットが、適切なソフトウェアおよび／またはファームウェアとともに、上で説明された１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられてよく、または相互動作するハードウェアユニットの集合によって与えられてよい。
[0251]様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
本出願は、２０１１年８月１日に出願された米国仮出願第６１／５１３，９９６号、２０１１年９月２７日に出願された米国仮出願第６１／５３９，９２５号、２０１１年１１月８日に出願された米国仮出願第６１／５５７，３００号、および２０１１年１１月２３日に出願された米国仮出願第６１／５６３，３５９号の利益を主張する。

Claims (48)

  1. ビデオデータをコーディングする方法であって、
    ビットストリームのために、複数のビデオコーディング次元のうちのいずれが前記ビットストリームに対してイネーブルされているかを表す情報をコーディングすることと、
    前記イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備える、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていない前記ビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、前記イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングすることと、
    を備える方法。
  2. 前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングすることは、
    前記イネーブルされたビデオコーディング次元の各々に対して、前記それぞれの値をコーディングするために使用される前記シンタックス要素のビットのそれぞれの数を決定することと、
    前記決定されたそれぞれのビットの数に基づいて、前記イネーブルされたビデオコーディング次元の前記シンタックス要素の前記値をコーディングすることと、
    を備える、請求項１に記載の方法。
  3. 前記ビットストリームのすべてのビデオデータに対して、イネーブルされていない前記ビデオコーディング次元のデフォルト値を推定することをさらに備える、請求項２に記載の方法。
  4. 前記複数のビデオコーディング次元は、複数のスケーラブルなビデオコーディング次元を備え、前記複数のスケーラブルなビデオコーディング次元は、優先度次元、空間次元、時間次元、信号対雑音比（ＳＮＲ）次元、品質次元、ビュー次元、カラービット深度次元、クロミナンス（クロマ）サンプルフォーマット次元、および依存性次元のうちの１つまたは複数を備える、請求項２に記載の方法。
  5. 前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングすることは、次元範囲パラメータセットをコーディングすることを備える、請求項２に記載の方法。
  6. 前記次元範囲パラメータセットに対応する、シーケンスパラメータセットの次元範囲パラメータセット識別子要素の値をコーディングすることをさらに備える、請求項５に記載の方法。
  7. 前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングすることは、ＮＡＬユニットヘッダマップをコーディングすることを備える、請求項２に記載の方法。
  8. 前記ＮＡＬユニットヘッダ中のビットと前記イネーブルされたビデオコーディング次元中のビットとの対応を表す情報をコーディングすることをさらに備える、請求項２に記載の方法。
  9. 前記イネーブルされたビデオコーディング次元の１つまたは複数の前記値は、前記それぞれのイネーブルされたビデオコーディング次元の可能な値のそれぞれのセットに対するインデックス値を備え、
    前記方法は、前記インデックス値の各々と、前記それぞれのインデックス値がマッピングされる前記それぞれのセットの前記値の１つとの間のマッピングを決定することをさらに備える、請求項２に記載の方法。
  10. 前記値がインデックス値を備える前記イネーブルされたビデオコーディング次元の前記１つまたは複数に対する前記マッピングを定義する情報を含む、値マッピングテーブルに対するインデックスをコーディングすることをさらに備える、請求項９に記載の方法。
  11. 前記イネーブルされたビデオコーディング次元の１つはビュー次元を備え、前記インデックス値をコーディングすることは、前記ＮＡＬユニットヘッダにおいて、前記ビュー次元のビュー順序インデックス値をコーディングすることを備え、
    前記マッピングを決定することは、前記ビュー次元の前記ビュー順序インデックス値とビュー識別子（ｖｉｅｗ＿ｉｄ）値との間のマッピングを決定することを備える、請求項９に記載の方法。
  12. 前記マッピングを決定することは、ビデオコーダのための事前に定義された構成データから前記マッピングを決定することを備える、請求項９に記載の方法。
  13. 前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ＮＡＬユニットの前記ビデオデータをコーディングすることをさらに備える、請求項２に記載の方法。
  14. 前記ビデオデータをコーディングすることは、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを復号することを備える、請求項１３に記載の方法。
  15. 前記ビデオデータをコーディングすることは、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを符号化することを備える、請求項１３に記載の方法。
  16. ビデオデータをコーディングするためのデバイスであって、ビットストリームのために、複数のビデオコーディング次元のうちのいずれが前記ビットストリームに対してイネーブルされているかを表す情報をコーディングし、前記イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備えるネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていない前記ビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、前記イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングするように構成される、ビデオコーダを備える、デバイス。
  17. 前記有効なビデオコーディング次元の各々の前記値をコーディングするために、前記ビデオコーダは、前記イネーブルされたビデオコーディング次元の各々に対して、前記それぞれの値を表すために使用されるビットのそれぞれの数を決定し、前記決定されたそれぞれのビットの数に基づいて、前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングするように構成される、請求項１６に記載のデバイス。
  18. 前記複数のビデオコーディング次元が、複数のスケーラブルなビデオコーディング次元を備え、前記複数のスケーラブルなビデオコーディング次元は、優先度次元、空間次元、時間次元、信号対雑音比（ＳＮＲ）次元、品質次元、ビュー次元、カラービット深度次元、クロミナンス（クロマ）サンプルフォーマット次元、および依存性次元のうちの１つまたは複数を備える、請求項１７に記載のデバイス。
  19. 前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングするために、前記ビデオコーダは、次元範囲パラメータセットをコーディングするように構成される、請求項１７に記載のデバイス。
  20. 前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングするために、前記ビデオコーダは、ＮＡＬユニットヘッダマップをコーディングするように構成される、請求項１７に記載のデバイス。
  21. 前記ＮＡＬユニットヘッダマップをコーディングするために、前記ビデオコーダは、前記ＮＡＬユニットヘッダマップのデータを備えるＮＡＬユニットヘッダマップパラメータセット（ＮＰＳ）と、前記ＮＡＬユニットヘッダマップのデータを備えるシーケンスパラメータセット（ＳＰＳ）との少なくとも１つをコーディングするように構成される、請求項２０に記載のデバイス。
  22. 前記ビデオコーダは、前記ビットストリームのすべてのビデオデータに対して、イネーブルされていない前記ビデオコーディング次元のデフォルト値を推定するように構成される、請求項１７に記載のデバイス。
  23. 前記イネーブルされたビデオコーディング次元の１つまたは複数の前記値は、前記それぞれのイネーブルされたビデオコーディング次元の可能な値のそれぞれのセットに対するインデックス値を備え、
    前記ビデオコーダは、前記インデックス値の各々と、前記それぞれのインデックス値がマッピングされる前記それぞれのセットの前記値の１つとの間のマッピングを決定するように構成される、請求項１７に記載のデバイス。
  24. 前記ビデオコーダはさらに、前記値がインデックス値を備える前記イネーブルされたビデオコーディング次元の前記１つまたは複数に対する前記マッピングを定義する情報を含む、値マッピングテーブルに対するインデックスをコーディングするように構成される、請求項２３に記載のデバイス。
  25. 前記有効なビデオコーディング次元の１つはビュー次元を備え、
    前記インデックス値をコーディングするために、前記ビデオコーダは、前記ＮＡＬユニットヘッダにおいて、前記ビュー次元のビュー順序インデックス値をコーディングするように構成され、
    前記マッピングを決定するために、前記ビデオコーダは、前記ビュー次元の前記ビュー順序インデックス値とビュー識別子（ｖｉｅｗ＿ｉｄ）値との間のマッピングを決定するように構成される、請求項２３に記載のデバイス。
  26. 前記ビデオコーダはさらに、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ＮＡＬユニットの前記ビデオデータをコーディングするように構成される、請求項１７に記載のデバイス。
  27. 前記ビデオコーダはビデオデコーダを備える、請求項２６に記載のデバイス。
  28. 前記ビデオコーダはビデオエンコーダを備える、請求項２６に記載のデバイス。
  29. 前記デバイスは、
    集積回路と、
    マイクロプロセッサと、
    前記ビデオコーダを含むワイヤレス通信デバイスと、
    のうちの少なくとも１つを備える、請求項１６に記載のデバイス。
  30. ビデオデータをコーディングするためのデバイスであって、
    ビットストリームのために、複数のビデオコーディング次元のうちのいずれが前記ビットストリームに対してイネーブルされているかを表す情報をコーディングする手段と、
    前記イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備える、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていない前記ビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、前記イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングする手段と、
    を備える、デバイス。
  31. 前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングする前記手段は、
    前記イネーブルされたビデオコーディング次元の各々に対して、前記それぞれの値を表すために使用されるビットのそれぞれの数を決定する手段と、
    前記決定されたそれぞれのビットの数に基づいて、前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングする手段と、
    を備える、請求項３０に記載のデバイス。
  32. 前記複数のビデオコーディング次元は、複数のスケーラブルなビデオコーディング次元を備え、前記複数のスケーラブルなビデオコーディング次元は、優先度次元、空間次元、時間次元、信号対雑音比（ＳＮＲ）次元、品質次元、ビュー次元、カラービット深度次元、クロミナンス（クロマ）サンプルフォーマット次元、および依存性次元のうちの１つまたは複数を備える、請求項３１に記載のデバイス。
  33. 前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングする前記手段は、次元範囲パラメータセットとＮＡＬユニットヘッダマップの少なくとも１つをコーディングする手段を備える、請求項３１に記載のデバイス。
  34. 前記イネーブルされたビデオコーディング次元の１つまたは複数の前記値は、前記それぞれのイネーブルされたビデオコーディング次元の可能な値のそれぞれのセットに対するインデックス値を備え、
    前記インデックス値の各々と、前記それぞれのインデックス値がマッピングされる前記それぞれのセットの前記値の１つとの間のマッピングを決定する手段と、
    前記値がインデックス値を備える前記イネーブルされたビデオコーディング次元の各々に対する前記マッピングを定義する情報を含む、値マッピングテーブルに対するインデックスをコーディングする手段と、
    をさらに備える、請求項３１に記載のデバイス。
  35. 前記イネーブルされたビデオコーディング次元の１つはビュー次元を備え、前記インデックス値をコーディングする前記手段は、前記ＮＡＬユニットヘッダにおいて、前記ビュー次元のビュー順序インデックス値をコーディングする手段を備え、
    前記マッピングを決定する前記手段は、前記ビュー次元の前記ビュー順序インデックス値とビュー識別子（ｖｉｅｗ＿ｉｄ）値との間のマッピングを決定する手段を備える、
    請求項３４に記載のデバイス。
  36. 前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ＮＡＬユニットの前記ビデオデータをコーディングする手段をさらに備える、請求項３１に記載のデバイス。
  37. 前記ビデオデータをコーディングするための前記手段が、前記有効なビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを復号するための手段を備える、請求項３６に記載のデバイス。
  38. 前記ビデオデータをコーディングする前記手段は、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを符号化する手段を備える、請求項３６に記載のデバイス。
  39. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
    ビットストリームのために、複数のビデオコーディング次元のうちのいずれが前記ビットストリームに対してイネーブルされているかを表す情報をコーディングさせ、
    前記イネーブルされたビデオコーディング次元の各々の値に従ってコーディングされたビデオデータを備える、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのＮＡＬユニットヘッダにおいて、イネーブルされていない前記ビデオコーディング次元を表すシンタックス要素の値をコーディングすることなく、前記イネーブルされたビデオコーディング次元を表すシンタックス要素の値をコーディングさせる、コンピュータ可読記憶媒体。
  40. 前記プロセッサに、前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングさせる前記命令は、前記プロセッサに、
    前記イネーブルされたビデオコーディング次元の各々に対して、前記それぞれの値を表すために使用されるビットのそれぞれの数を決定させ、
    前記決定されたそれぞれのビットの数に基づいて、前記イネーブルされたビデオコーディング次元の各々の前記値をコーディングさせる命令を備える、
    請求項３９に記載のコンピュータ可読記憶媒体。
  41. 前記複数のビデオコーディング次元は、複数のスケーラブルなビデオコーディング次元を備え、前記複数のスケーラブルなビデオコーディング次元は、優先度次元、空間次元、時間次元、信号対雑音比（ＳＮＲ）次元、品質次元、ビュー次元、カラービット深度次元、クロミナンス（クロマ）サンプルフォーマット次元、および依存性次元のうちの１つまたは複数を備える、請求項４０に記載のコンピュータ可読記憶媒体。
  42. 前記プロセッサに、前記複数のビデオコーディング次元のうちのいずれがイネーブルされているかを表す前記情報をコーディングさせる前記命令は、前記プロセッサに、次元範囲パラメータセットとＮＡＬユニットヘッダマップの少なくとも１つをコーディングさせる命令を備える、請求項４０に記載のコンピュータ可読記憶媒体。
  43. 前記イネーブルされたビデオコーディング次元の１つまたは複数の前記値は、前記それぞれのイネーブルされたビデオコーディング次元の可能な値のそれぞれのセットに対するインデックス値を備え、前記コンピュータ可読記憶媒体は、前記プロセッサに、
    前記インデックス値の各々と、前記それぞれのインデックス値がマッピングされる前記それぞれのセットの前記値の１つとの間のマッピングを決定させ、
    前記値がインデックス値を備える前記イネーブルされたビデオコーディング次元の各々に対する前記マッピングを定義する情報を含む、値マッピングテーブルに対するインデックスをコーディングさせる命令をさらに備える、
    請求項４０に記載のコンピュータ可読記憶媒体。
  44. 前記イネーブルされたビデオコーディング次元の１つがビュー次元を備え、
    前記プロセッサに前記インデックス値をコーディングさせる前記命令は、前記プロセッサに、前記ＮＡＬユニットヘッダにおいて、前記ビュー次元のビュー順序インデックス値をコーディングさせる命令を備え、
    前記プロセッサに前記マッピングを決定させる前記命令は、前記プロセッサに、前記ビュー次元の前記ビュー順序インデックス値とビュー識別子（ｖｉｅｗ＿ｉｄ）値との間のマッピングを決定させる命令を備える、
    請求項４３に記載のコンピュータ可読記憶媒体。
  45. 前記ＮＡＬユニットは前記ビットストリームの第１のＮＡＬユニットを備え、前記コンピュータ可読記憶媒体は、前記プロセッサに、
    前記ビットストリームのサブビットストリームを抽出することと、前記サブビットストリームは、前記第１のＮＡＬユニットの前記ビデオデータの少なくとも一部分を含む第２のＮＡＬユニットを備え、
    前記サブビットストリームのために、前記複数のビデオコーディング次元のうちのいずれが前記ビットストリームに対してイネーブルされているかを表す情報をコーディングすることと、
    前記第２のＮＡＬユニットの変更されたＮＡＬユニットヘッダにおいて、イネーブルされていない前記ビデオコーディング次元の値をコーディングすることなく、前記サブビットストリームの前記イネーブルされたビデオコーディング次元の各々の値をコーディングすることと、前記変更されたＮＡＬユニットヘッダは、前記第１のＮＡＬユニットの前記ＮＡＬユニットヘッダのビット長よりも短いビット長を有し、
    を行わせる命令をさらに備える、請求項４０に記載のコンピュータ可読記憶媒体。
  46. 前記プロセッサに、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ＮＡＬユニットの前記ビデオデータをコーディングさせる命令をさらに備える、請求項４０に記載のコンピュータ可読記憶媒体。
  47. 前記プロセッサに前記ビデオデータをコーディングさせる前記命令は、前記プロセッサに、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを復号させる命令を備える、請求項４６に記載のコンピュータ可読記憶媒体。
  48. 前記プロセッサに前記ビデオデータをコーディングさせる前記命令は、前記プロセッサに、前記イネーブルされたビデオコーディング次元の各々の前記値に基づいて、前記ビデオデータを符号化させる命令を備える、請求項４６に記載のコンピュータ可読記憶媒体。
JP2014524033A 2011-08-01 2012-07-31 ビデオコーディングにおける様々な次元に対するコーディングパラメータセット Active JP5869126B2 (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201161513996P 2011-08-01 2011-08-01
US61/513,996 2011-08-01
US201161539925P 2011-09-27 2011-09-27
US61/539,925 2011-09-27
US201161557300P 2011-11-08 2011-11-08
US61/557,300 2011-11-08
US201161563359P 2011-11-23 2011-11-23
US61/563,359 2011-11-23
US13/561,754 US10237565B2 (en) 2011-08-01 2012-07-30 Coding parameter sets for various dimensions in video coding
US13/561,754 2012-07-30
PCT/US2012/049041 WO2013019811A1 (en) 2011-08-01 2012-07-31 Coding parameter sets for various dimensions in video coding

Publications (2)

Publication Number Publication Date
JP2014522187A true JP2014522187A (ja) 2014-08-28
JP5869126B2 JP5869126B2 (ja) 2016-02-24

Family

ID=47626941

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014524033A Active JP5869126B2 (ja) 2011-08-01 2012-07-31 ビデオコーディングにおける様々な次元に対するコーディングパラメータセット

Country Status (10)

Country Link
US (1) US10237565B2 (ja)
EP (1) EP2740268B1 (ja)
JP (1) JP5869126B2 (ja)
KR (1) KR101553787B1 (ja)
CN (1) CN103733623B (ja)
BR (1) BR112014002479B1 (ja)
CA (1) CA2843748C (ja)
IN (1) IN2014CN00319A (ja)
RU (1) RU2575986C2 (ja)
WO (1) WO2013019811A1 (ja)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8379727B2 (en) * 2008-09-26 2013-02-19 General Instrument Corporation Method and apparatus for scalable motion estimation
KR101215152B1 (ko) 2011-04-21 2012-12-24 한양대학교 산학협력단 인루프 필터링을 적용한 예측 방법을 이용한 영상 부호화/복호화 방법 및 장치
US9674525B2 (en) 2011-07-28 2017-06-06 Qualcomm Incorporated Multiview video coding
US9635355B2 (en) 2011-07-28 2017-04-25 Qualcomm Incorporated Multiview video coding
US9591318B2 (en) 2011-09-16 2017-03-07 Microsoft Technology Licensing, Llc Multi-layer encoding and decoding
US9712874B2 (en) * 2011-12-12 2017-07-18 Lg Electronics Inc. Device and method for receiving media content
US9258559B2 (en) 2011-12-20 2016-02-09 Qualcomm Incorporated Reference picture list construction for multi-view and three-dimensional video coding
US11089343B2 (en) * 2012-01-11 2021-08-10 Microsoft Technology Licensing, Llc Capability advertisement, configuration and control for video coding and decoding
US9451252B2 (en) 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
US9313486B2 (en) * 2012-06-20 2016-04-12 Vidyo, Inc. Hybrid video coding techniques
US9179145B2 (en) * 2012-07-02 2015-11-03 Vidyo, Inc. Cross layer spatial intra prediction
US9686542B2 (en) * 2012-09-05 2017-06-20 Qualcomm Incorporated Network abstraction layer header design
US10021394B2 (en) 2012-09-24 2018-07-10 Qualcomm Incorporated Hypothetical reference decoder parameters in video coding
EP2901688B1 (en) * 2012-09-28 2019-10-23 Nokia Technologies Oy An apparatus and a method for video coding and decoding
US9325997B2 (en) * 2012-11-16 2016-04-26 Huawei Technologies Co., Ltd Signaling scalability information in a parameter set
US10178400B2 (en) * 2012-11-21 2019-01-08 Dolby International Ab Signaling scalability information in a parameter set
US9774927B2 (en) * 2012-12-21 2017-09-26 Telefonaktiebolaget L M Ericsson (Publ) Multi-layer video stream decoding
US9462287B2 (en) * 2013-01-04 2016-10-04 Dolby International Ab Implicit signaling of scalability dimension identifier information in a parameter set
US9426468B2 (en) 2013-01-04 2016-08-23 Huawei Technologies Co., Ltd. Signaling layer dependency information in a parameter set
US9826244B2 (en) * 2013-01-08 2017-11-21 Qualcomm Incorporated Device and method for scalable coding of video information based on high efficiency video coding
RU2619886C2 (ru) * 2013-03-26 2017-05-19 Долби Лабораторис Лайсэнзин Корпорейшн Кодирование перцепционно-квантованного видеоконтента в многоуровневом кодировании vdr
US9998735B2 (en) * 2013-04-01 2018-06-12 Qualcomm Incorporated Inter-layer reference picture restriction for high level syntax-only scalable video coding
US9467700B2 (en) 2013-04-08 2016-10-11 Qualcomm Incorporated Non-entropy encoded representation format
US9602822B2 (en) * 2013-04-17 2017-03-21 Qualcomm Incorporated Indication of cross-layer picture type alignment in multi-layer video coding
KR102161741B1 (ko) * 2013-05-02 2020-10-06 삼성전자주식회사 ＨＥＶＣ(high efficiency video coding)에서 코딩 유닛에 대한 양자화 파라미터를 변화시키는 방법과 장치, 및 시스템
US9510006B2 (en) * 2013-05-03 2016-11-29 Empire Technology Development Llc Scalable video coding prioritization
JP6361866B2 (ja) * 2013-05-09 2018-07-25 サン パテント トラスト 画像処理方法および画像処理装置
WO2014196198A1 (ja) * 2013-06-05 2014-12-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 画像符号化方法、画像復号方法、画像符号化装置及び画像復号装置
JP2016523483A (ja) * 2013-06-18 2016-08-08 ヴィド スケール インコーポレイテッド Ｈｅｖｃ拡張のためのレイヤ間パラメータセット
WO2015006281A2 (en) * 2013-07-09 2015-01-15 Sony Corporation High level syntax improvement on inter-layer prediction for shvc/mv-hevc
US9912943B2 (en) * 2013-07-15 2018-03-06 Qualcomm Incorporated Signaling of bit rate information and picture rate information in VPS
US20160156915A1 (en) * 2013-07-18 2016-06-02 Samsung Electronics Co., Ltd. Video encoding method and apparatus and video decoding method and apparatus using video format parameter delivery
JP5774652B2 (ja) 2013-08-27 2015-09-09 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10284858B2 (en) * 2013-10-15 2019-05-07 Qualcomm Incorporated Support of multi-mode extraction for multi-layer video codecs
US9628800B2 (en) * 2013-11-18 2017-04-18 Qualcomm Incorporated Adaptive control for transforms in video coding
US10306265B2 (en) 2013-12-30 2019-05-28 Qualcomm Incorporated Simplification of segment-wise DC coding of large prediction blocks in 3D video coding
WO2015103462A1 (en) * 2014-01-02 2015-07-09 Vidyo, Inc. Overlays using auxiliary pictures
JP2015136060A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
US10645404B2 (en) * 2014-03-24 2020-05-05 Qualcomm Incorporated Generic use of HEVC SEI messages for multi-layer codecs
CN106233736B (zh) * 2014-04-25 2020-06-05 索尼公司 发送设备、发送方法、接收设备以及接收方法
JP2016015009A (ja) * 2014-07-02 2016-01-28 ソニー株式会社 情報処理システム、情報処理端末、および情報処理方法
US9583113B2 (en) * 2015-03-31 2017-02-28 Lenovo (Singapore) Pte. Ltd. Audio compression using vector field normalization
GB2538997A (en) * 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
US10291923B2 (en) * 2016-05-24 2019-05-14 Qualcomm Incorporated Mapping of tile grouping and samples in HEVC and L-HEVC file formats
US10938878B2 (en) * 2017-05-16 2021-03-02 Red Hat, Inc. Separate cache servers for storing objects in different dedicated size ranges
GB201817784D0 (en) * 2018-10-31 2018-12-19 V Nova Int Ltd Methods,apparatuses, computer programs and computer-readable media
JP6648811B2 (ja) * 2018-12-13 2020-02-14 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10812818B2 (en) * 2018-12-14 2020-10-20 Tencent America LLC Network abstraction unit layer type classes in network abstraction layer unit header
CN114666595A (zh) 2019-03-11 2022-06-24 杜比实验室特许公司 帧速率可伸缩视频编码
EP3939317A1 (en) 2019-03-11 2022-01-19 Dolby Laboratories Licensing Corporation Video coding using reference picture resampling supporting region of interest
CN114521327A (zh) * 2019-07-05 2022-05-20 威诺瓦国际有限公司 视频译码中的残差的量化
JP2022543627A (ja) 2019-08-06 2022-10-13 ドルビー ラボラトリーズ ライセンシング コーポレイション 描画面サイズ拡張可能ビデオコーディング
GB2611864B (en) * 2019-08-23 2023-12-06 Imagination Tech Ltd Random accessible image data compression
US11375182B2 (en) * 2019-12-17 2022-06-28 Hfi Innovation Inc. Method and apparatus of constrained layer-wise video coding
JP6773205B2 (ja) * 2019-12-19 2020-10-21 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US11750843B2 (en) 2021-06-28 2023-09-05 Tencent America LLC Multiview-related supplementary enhancement information messages

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010102650A1 (en) * 2009-03-13 2010-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Technique for bringing encoded data items into conformity with a scalable coding protocol
WO2010126612A2 (en) * 2009-05-01 2010-11-04 Thomson Licensing Reference picture lists for 3dv

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7302490B1 (en) * 2000-05-03 2007-11-27 Microsoft Corporation Media file format to support switching between multiple timeline-altered media streams
WO2002054779A2 (de) 2001-01-08 2002-07-11 Siemens Aktiengesellschaft Verfahren zur header-kompression bei einer video-codierung
US20050254575A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Multiple interoperability points for scalable media coding and transmission
GB0518300D0 (en) 2005-09-08 2005-10-19 Hendrickson Europ Ltd Vehicle suspensions
US20100158133A1 (en) 2005-10-12 2010-06-24 Peng Yin Method and Apparatus for Using High-Level Syntax in Scalable Video Encoding and Decoding
AU2007204168B2 (en) 2006-01-11 2011-02-24 Nokia Technologies Oy Backward-compatible aggregation of pictures in scalable video coding
US20070230564A1 (en) 2006-03-29 2007-10-04 Qualcomm Incorporated Video processing with scalability
KR100959538B1 (ko) 2006-03-30 2010-05-27 엘지전자 주식회사 비디오 신호를 디코딩/인코딩하기 위한 방법 및 장치
CN101491095B (zh) 2006-03-30 2013-07-10 Lg电子株式会社 用于解码/编码视频信号的方法和装置
FR2899758A1 (fr) 2006-04-07 2007-10-12 France Telecom Procede et dispositif de codage de donnees en un flux scalable
MX2009003968A (es) 2006-10-16 2009-06-01 Nokia Corp Sistema y método para usar segmentos decodificables paralelamente para codificación de video de vistas múltiples.
RU2387094C1 (ru) 2006-11-09 2010-04-20 ЭлДжи ЭЛЕКТРОНИКС ИНК. Способ и устройство для кодирования/декодирования видеосигнала
EP3041195A1 (en) 2007-01-12 2016-07-06 University-Industry Cooperation Group Of Kyung Hee University Packet format of network abstraction layer unit, and algorithm and apparatus for video encoding and decoding using the format
US20100266042A1 (en) 2007-03-02 2010-10-21 Han Suh Koo Method and an apparatus for decoding/encoding a video signal
US8548261B2 (en) 2007-04-11 2013-10-01 Samsung Electronics Co., Ltd. Method and apparatus for encoding and decoding multi-view image
US20090003431A1 (en) 2007-06-28 2009-01-01 Lihua Zhu Method for encoding video data in a scalable manner
WO2009003499A1 (en) 2007-06-29 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Scalable video coding supporting pixel value refinement scalability
BRPI0818444A2 (pt) 2007-10-12 2016-10-11 Qualcomm Inc codificação adaptativa de informação de cabeçalho de bloco de vídeo
FR2924887B1 (fr) 2007-12-07 2011-07-15 Thales Sa Procede et dispositif de transmission robuste d'en-tetes reseau compresses
KR20090079838A (ko) 2008-01-17 2009-07-22 엘지전자 주식회사 Ｉｐｔｖ 수신 시스템 및 그 데이터 처리 방법
EP2319248A1 (en) 2008-08-26 2011-05-11 Koninklijke Philips Electronics N.V. Method and system for encoding a 3d video signal, encoder for encoding a 3-d video signal, encoded 3d video signal, method and system for decoding a 3d video signal, decoder for decoding a 3d video signal
KR101619448B1 (ko) 2008-11-18 2016-05-10 엘지전자 주식회사 영상 신호 처리 방법 및 장치
EP2392138A4 (en) * 2009-01-28 2012-08-29 Nokia Corp METHOD AND APPARATUS FOR VIDEO ENCODING AND DECODING
RU2550552C2 (ru) 2009-04-28 2015-05-10 Панасоник Корпорэйшн Способ декодирования изображений и устройство декодирования изображений
US8780999B2 (en) 2009-06-12 2014-07-15 Qualcomm Incorporated Assembling multiview video coding sub-BITSTREAMS in MPEG-2 systems
US8344917B2 (en) * 2010-09-30 2013-01-01 Sharp Laboratories Of America, Inc. Methods and systems for context initialization in video coding and decoding
US9635355B2 (en) 2011-07-28 2017-04-25 Qualcomm Incorporated Multiview video coding

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010102650A1 (en) * 2009-03-13 2010-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Technique for bringing encoded data items into conformity with a scalable coding protocol
WO2010126612A2 (en) * 2009-05-01 2010-11-04 Thomson Licensing Reference picture lists for 3dv

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
JPN6014048181; Ｐｅｔｅｒ　Ａｍｏｎ　ｅｔ　ａｌ．: 'Ｈｉｇｈ-Ｌｅｖｅｌ　Ｓｙｎｔａｘ　ｆｏｒ　ＳＶＣ' Ｊｏｉｎｔ　Ｖｉｄｅｏ　Ｔｅａｍ　（ＪＶＴ）　ｏｆ　ＩＳＯ／ＩＥＣ　ＭＰＥＧ　＆　ＩＴＵ-Ｔ　ＶＣＥＧ　（ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１　ａｎｄ　ＩＴＵ-Ｔ　ＳＧ１６　Ｑ．６） ＪＶＴ-Ｐ１００, 200507, ｐｐ．１-７, １６ｔｈ　Ｍｅｅｔｉｎｇ：　Ｐｏｚｎａｎ，　ＰＬ *
JPN6014048184; Ｄｏｕｇ　Ｙｏｕｎｇ　Ｓｕｈ: 'Ａ　Ｓｈｏｒｔｅｎｅｄ　ＮＡＬ　Ｈｅａｄｅｒ　ｆｏｒ　Ｌｉｇｈｔ　Ａｐｐｌｉｃａｔｉｏｎｓ' Ｊｏｉｎｔ　Ｖｉｄｅｏ　Ｔｅａｍ　（ＪＶＴ）　ｏｆ　ＩＳＯ／ＩＥＣ　ＭＰＥＧ　＆　ＩＴＵ-Ｔ　ＶＣＥＧ　（ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１　ａｎｄ　ＩＴＵ-Ｔ　ＳＧ１６　Ｑ．６） ＪＶＴ-Ｖ１２９ｒ１, 200701, ｐｐ．１-５, ２２ｎｄ　Ｍｅｅｔｉｎｇ：　Ｍａｒｒａｋｅｃｈ，　Ｍｏｒｏｃｃｏ *
JPN6015041869; Ｙｅ-Ｋｕｉ　Ｗａｎｇ　ａｎｄ　Ｚｈｅｎｙｕ　Ｗｕ: 'Ｏｎ　ＮＡＬ　ｕｎｉｔ　ｈｅａｄｅｒ' Ｊｏｉｎｔ　Ｃｏｌｌａｂｏｒａｔｉｖｅ　Ｔｅａｍ　ｏｎ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　（ＪＣＴ-ＶＣ）　ｏｆ　ＩＴＵ-Ｔ　ＳＧ１６　ＷＰ３　ａｎｄ　ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＪＣＴＶＣ-Ｄ０８０, 201101, ｐｐ．１-３, ４ｔｈ　Ｍｅｅｔｉｎｇ：　Ｄａｅｇｕ，　ＫＲ *
JPN6015048871; Ｙｅ-Ｋｕｉ　Ｗａｎｇ: 'ＮＡＬ　ｕｎｉｔ　ｈｅａｄｅｒ　ａｎｄ　ｓｕｂ-ｂｉｔｓｔｒｅａｍ　ｅｘｔｒａｃｔｉｏｎ' Ｊｏｉｎｔ　Ｃｏｌｌａｂｏｒａｔｉｖｅ　Ｔｅａｍ　ｏｎ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　（ＪＣＴ-ＶＣ）　ｏｆ　ＩＴＵ-Ｔ　ＳＧ１６　ＷＰ３　ａｎｄ　ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＪＣＴＶＣ-Ｅ３４５, 201103, ｐｐ．１-５, ５ｔｈ　Ｍｅｅｔｉｎｇ：　Ｇｅｎｅｖａ，　ＣＨ *
JPN6015048874; Ｒｉｃｋａｒｄ　Ｓｊｏｂｅｒｇ　ｅｔ　ａｌ．: 'ＮＡＬ　ｕｎｉｔ　ｈｅａｄｅｒ　ｃｏｎｃｅｐｔ　ｗｉｔｈ　ｓｕｐｐｏｒｔ　ｆｏｒ　ｂｉｔ　ｓｔｒｅａｍ　ｓｃａｌａｂｉｌｉｔｙ' Ｊｏｉｎｔ　Ｃｏｌｌａｂｏｒａｔｉｖｅ　Ｔｅａｍ　ｏｎ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　（ＪＣＴ-ＶＣ）　ｏｆ　ＩＴＵ-Ｔ　ＳＧ１６　ＷＰ３　ａｎｄ　ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＪＣＴＶＣ-Ｅ４２２, 201103, ｐｐ．１-６, ５ｔｈ　Ｍｅｅｔｉｎｇ：　Ｇｅｎｅｖａ，　ＣＨ *
JPN6015048875; Ｙｉｎｇ　Ｃｈｅｎ　ｅｔ　ａｌ．: 'Ｕｎｉｆｉｅｄ　ＮＡＬ　ｕｎｉｔ　ｈｅａｄｅｒ　ｄｅｓｉｇｎ　ｆｏｒ　ＨＥＶＣ　ａｎｄ　ｉｔｓ　ｅｘｔｅｎｓｉｏｎｓ' Ｊｏｉｎｔ　Ｃｏｌｌａｂｏｒａｔｉｖｅ　Ｔｅａｍ　ｏｎ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　（ＪＣＴ-ＶＣ）　ｏｆ　ＩＴＵ-Ｔ　ＳＧ１６　ＷＰ３　ａｎｄ　ＩＳＯ／ＩＥＣ　ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＪＣＴＶＣ-Ｇ３３６, 201111, ｐｐ．１-７, ７ｔｈ　Ｍｅｅｔｉｎｇ：　Ｇｅｎｅｖａ，　ＣＨ *

Also Published As

Publication number Publication date
EP2740268B1 (en) 2020-11-18
CA2843748A1 (en) 2013-02-07
KR20140043840A (ko) 2014-04-10
BR112014002479A2 (pt) 2017-02-21
CA2843748C (en) 2018-01-16
BR112014002479B1 (pt) 2022-06-07
CN103733623B (zh) 2017-08-04
WO2013019811A1 (en) 2013-02-07
CN103733623A (zh) 2014-04-16
US20130034170A1 (en) 2013-02-07
US10237565B2 (en) 2019-03-19
IN2014CN00319A (ja) 2015-04-03
KR101553787B1 (ko) 2015-09-16
EP2740268A1 (en) 2014-06-11
RU2575986C2 (ru) 2016-02-27
JP5869126B2 (ja) 2016-02-24
RU2014107877A (ru) 2015-09-10

Similar Documents

Publication Publication Date Title
JP5869126B2 (ja) ビデオコーディングにおける様々な次元に対するコーディングパラメータセット
JP6400660B2 (ja) Ｈｅｖｃおよび拡張のためのビデオパラメータセット
JP6509842B2 (ja) 高効率ビデオコーディング拡張におけるターゲット出力レイヤの選択
JP6141386B2 (ja) 深度範囲パラメータのシグナリング
JP6117243B2 (ja) ビデオコーディング用のコーディングパラメータセットおよびｎａｌユニットヘッダ
JP6594967B2 (ja) 階層化されたｈｅｖｃビットストリームの搬送のための動作点
JP6377623B2 (ja) ビデオコーディングにおけるターゲット出力レイヤ
JP6502357B2 (ja) マルチレイヤビデオコーディングにおける色域スケーラビリティのための３ｄルックアップテーブルに関する区分情報のシグナリング
JP2016197869A (ja) マルチビュービデオコード化（ｍｖｃ）適合３次元ビデオコード化（３ｄｖｃ）のためのパラメータセットのアクティブ化
KR20160071415A (ko) 다중-계층 비디오 코딩에서의 3차원 룩업 테이블 기반 색역 스케일러빌리티
JP6363190B2 (ja) Ｖｐｓ内のビットレート情報およびピクチャレート情報のシグナリング
JP2016514426A (ja) ビュー内でのおよびビューにわたる深度ルックアップテーブルの予測コーディング
JP2017515386A (ja) 色域スケーラビリティのための３ｄ色予測のために参照レイヤを信号伝達すること
US10277918B2 (en) Video encoding and decoding method and apparatus using the same

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140401

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140401

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150127

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150424

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20151208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160106

R150 Certificate of patent or registration of utility model

Ref document number: 5869126

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250