特許 6440735 マルチレイヤビデオコーデックのためのレベル定義

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6440735

(24)【登録日】2018年11月30日

(45)【発行日】2018年12月19日

(54)【発明の名称】マルチレイヤビデオコーデックのためのレベル定義

(51)【国際特許分類】

   H04N 19/127 20140101AFI20181210BHJP

   H04N 19/156 20140101ALI20181210BHJP

   H04N 19/187 20140101ALI20181210BHJP

   H04N 19/33 20140101ALI20181210BHJP

   H04N 19/436 20140101ALI20181210BHJP

   H04N 19/70 20140101ALI20181210BHJP

【ＦＩ】

   H04N19/127

   H04N19/156

   H04N19/187

   H04N19/33

   H04N19/436

   H04N19/70

【請求項の数】30

【全頁数】57

(21)【出願番号】特願2016-557225(P2016-557225)

(86)(22)【出願日】2015年3月16日

(65)【公表番号】特表2017-513330(P2017-513330A)

(43)【公表日】2017年5月25日

(86)【国際出願番号】US2015020662

(87)【国際公開番号】WO2015142694

(87)【国際公開日】20150924

【審査請求日】2017年12月5日

(31)【優先権主張番号】61/954,495

(32)【優先日】2014年3月17日

(33)【優先権主張国】US

(31)【優先権主張番号】14/656,573

(32)【優先日】2015年3月12日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】507364838

【氏名又は名称】クアルコム，インコーポレイテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100163522

【弁理士】

【氏名又は名称】黒田 晋平

(72)【発明者】

【氏名】イェ−クイ・ワン

(72)【発明者】

【氏名】クリシュナカンス・ラパカ

(72)【発明者】

【氏名】ジエンレ・チェン

(72)【発明者】

【氏名】フヌ・ヘンドリー

(72)【発明者】

【氏名】アダルシュ・クリシュナン・ラマスブラモニアン

【審査官】 岩井 健二

(56)【参考文献】

【文献】 特表２００７−５３７６３９（ＪＰ，Ａ）

【文献】 国際公開第２０１４／０１１５９５（ＷＯ，Ａ１）

【文献】 国際公開第２０１３／１５１８１４（ＷＯ，Ａ１）

【文献】 Jianle Chen et al.，SHVC Draft Text 1，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11，12th Meeting: Geneva, CH，２０１３年 ３月，JCTVC-L1008，pp.i-iii,6-23

【文献】 High efficiency video coding，Recommendation ITU-T H.265，ITU-T，２０１３年 ４月，H.265 (04/2013)，pp.200-208

【文献】 Jill Boyce，Strawman SHVC level constraints，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，16th Meeting: San Jose, US，２０１４年 １月，JCTVC-P0134，pp.1-3

【文献】 Miska M. Hannuksela，REXT/MV-HEVC/SHVC/3D-HEVC HLS: On indication of decoding process and profile-level-tier combinations，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，16th Meeting: San Jose, US，２０１４年 １月，JCTVC-P0137，pp.1-4

【文献】 Gerhard Tech et al.，Preliminary version of MV-HEVC Draft Text 6 ，Joint Collaborative Team on 3D Video Coding Extension Development of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，２０１４年 １月，pp.i.12-62,67-71，ＵＲＬ，http://phenix.it-sudparis.eu/jct/doc_end_user/documents/16_San%20Jose/wg11/JCTVC-P0137-v1.zipのJCTVC-P0137_JCT3V-G0137 spectext.doc

【文献】 Miska M. Hannuksela，On SHVC level limits，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，16th Meeting: San Jose, US，２０１４年 １月，JCTVC-P0142v2，pp.1-3

【文献】 Miska M. Hannuksela，MV-HEVC/SHVC HLS: On additional layer sets, rewriting of simulcast layers, and profile-tier-level indication for auxiliary picture layers，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，17th Meeting: Valencia, ES，２０１４年 ３月，JCTVC-Q0078，pp.1-7

【文献】 Ye-Kui Wang et al.，MV-HEVC/SHVC HLS: On level definitions，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，17th Meeting: Valencia, ES，２０１４年 ３月，JCTVC-Q0145，pp.1-3

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ １９／００ − １９／９８

(57)【特許請求の範囲】

【請求項1】

デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定する方法であって、前記デコーダが複数のシングルレイヤデコーダコアに基づいて実装され、
レイヤの少なくとも1つのセットへの前記マルチレイヤビットストリームのレイヤの少なくとも1つの割振りを特定するステップと、
レイヤの各セットが前記マルチレイヤビットストリームの前記復号のために前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出するステップと、
レイヤの各セットが前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出することに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するステップと、
を備え、
前記デコーダの最大ルーマピクチャサイズを決定するステップと、
前記デコーダのレベル定義と関連付けられる規模を指定するステップと
をさらに備え、
前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するステップが前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、方法。

【請求項2】

前記デコーダのレベル定義を指定するステップをさらに備え、
前記デコーダの最大ルーマピクチャサイズを決定するステップが、前記デコーダの前記レベル定義に少なくとも一部基づいて、前記デコーダの最大ルーマピクチャサイズを決定するステップを備える、請求項1に記載の方法。

【請求項3】

前記マルチレイヤビットストリーム中のレイヤの解像度の合計を計算するステップをさらに備え、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、解像度の前記計算された合計に少なくとも一部基づく、請求項2に記載の方法。

【請求項4】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、解像度の前記合計が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる積以下であるかどうかに少なくとも一部基づく、請求項3に記載の方法。

【請求項5】

前記マルチレイヤビットストリームの最上位レイヤの解像度を決定するステップと、
前記マルチレイヤビットストリームの識別子リスト中のレイヤの数を決定するステップと、
前記識別子リスト中のレイヤの前記数を前記最上位レイヤの前記解像度と乗算することを介して、解像度の前記合計を計算するステップとをさらに備える、請求項3に記載の方法。

【請求項6】

前記マルチレイヤビットストリーム中のレイヤの数を決定することを介して、前記マルチレイヤビットストリームのレベル定義を決定するステップをさらに備える、請求項2に記載の方法。

【請求項7】

前記マルチレイヤビットストリームの前記レベル定義に少なくとも一部基づいて、前記マルチレイヤビットストリームの最大のピクチャサイズを決定するステップをさらに備える、請求項6に記載の方法。

【請求項8】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、前記マルチレイヤビットストリームの前記最大のピクチャサイズに少なくとも一部基づく、請求項7に記載の方法。

【請求項9】

前記マルチレイヤビットストリーム中のレイヤの前記数を前記マルチレイヤビットストリームの前記最大のピクチャサイズと乗算することにより得られる第1の積が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる第2の積以下であるかどうかを決定するステップと、
前記第1の積が前記第2の積以下であるかどうかに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するステップとをさらに備える、請求項8に記載の方法。

【請求項10】

各レイヤ、復号ピクチャバッファ(DPB)、またはサブDPBの少なくとも1つに対する、サイズに関連する制約を指定するステップをさらに備える、請求項2に記載の方法。

【請求項11】

デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定するための装置であって、前記デコーダが複数のシングルレイヤデコーダコアに基づいて実装され、
レイヤの少なくとも1つのセットへの前記マルチレイヤビットストリームのレイヤの少なくとも1つの割振りを特定し、
レイヤの各セットが前記マルチレイヤビットストリームの前記復号のために前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出し、
レイヤの各セットが前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出することに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定する
ように構成される少なくとも1つのプロセッサを備え、
前記少なくとも1つのプロセッサがさらに、
前記デコーダの最大ルーマピクチャサイズを決定し、
前記デコーダのレベル定義と関連付けられる規模を指定する
ように構成され、
前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定することが前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、装置。

【請求項12】

前記少なくとも1つのプロセッサがさらに、
前記デコーダのレベル定義を指定するように構成され、
前記デコーダの最大ルーマピクチャサイズを決定することが、前記デコーダの前記レベル定義に少なくとも一部基づいて、前記デコーダの最大ルーマピクチャサイズを決定することを備える、請求項11に記載の装置。

【請求項13】

前記少なくとも1つのプロセッサがさらに、前記マルチレイヤビットストリーム中のレイヤの解像度の合計を計算するように構成され、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップが前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、請求項12に記載の装置。

【請求項14】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、解像度の前記合計が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる積以下であるかどうかに少なくとも一部基づく、請求項13に記載の装置。

【請求項15】

前記少なくとも1つのプロセッサがさらに、
前記マルチレイヤビットストリームの最上位レイヤの解像度を決定し、
前記マルチレイヤビットストリームの識別子リスト中のレイヤの数を決定し、
前記識別子リスト中のレイヤの前記数を前記最上位レイヤの前記解像度と乗算することを介して、解像度の前記合計を計算するように構成される、請求項13に記載の装置。

【請求項16】

前記少なくとも1つのプロセッサがさらに、前記マルチレイヤビットストリーム中のレイヤの数を決定することを介して、前記マルチレイヤビットストリームのレベル定義を決定するように構成される、請求項12に記載の装置。

【請求項17】

前記少なくとも1つのプロセッサがさらに、前記マルチレイヤビットストリームの前記レベル定義に少なくとも一部基づいて、前記マルチレイヤビットストリームの最大のピクチャサイズを決定するように構成される、請求項16に記載の装置。

【請求項18】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、前記マルチレイヤビットストリームの前記最大のピクチャサイズに少なくとも一部基づく、請求項17に記載の装置。

【請求項19】

前記少なくとも1つのプロセッサがさらに、
前記マルチレイヤビットストリーム中のレイヤの前記数を前記マルチレイヤビットストリームの前記最大のピクチャサイズと乗算することにより得られる第1の積が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる第2の積以下であるかどうかを決定し、
前記第1の積が前記第2の積以下であるかどうかに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するように構成される、請求項18に記載の装置。

【請求項20】

前記少なくとも1つのプロセッサがさらに、各レイヤ、復号ピクチャバッファ(DPB)、またはサブDPBの少なくとも1つに対する、サイズに関連する制約を指定するように構成される、請求項12に記載の装置。

【請求項21】

実行されると、デバイスのプロセッサに、
複数のシングルレイヤデコーダコアに基づいて実装されるデコーダがマルチレイヤビットストリームを復号することが可能かどうかを決定する際に使用するための、レイヤの少なくとも1つのセットへのビデオ情報を含む前記マルチレイヤビットストリームのレイヤの少なくとも1つの割振りを特定させ、
レイヤの各セットが前記マルチレイヤビットストリームの前記復号のために前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出させ、
レイヤの各セットが前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出することに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定させる
命令を記憶し、
実行されると、前記プロセッサに、
前記デコーダの最大ルーマピクチャサイズを決定させ、
前記デコーダのレベル定義と関連付けられる規模を指定させる
命令をさらに記憶し、
前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定させることが前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、非一時的コンピュータ可読記憶媒体。

【請求項22】

実行されると、前記プロセッサに、
前記デコーダのレベル定義を指定させる
命令をさらに記憶し、前記デコーダの最大ルーマピクチャサイズを決定させることが、前記デコーダの前記レベル定義に少なくとも一部基づいて、前記デコーダの最大ルーマピクチャサイズを決定させることを備える、請求項21に記載の非一時的コンピュータ可読記憶媒体。

【請求項23】

実行されると、前記プロセッサに、前記マルチレイヤビットストリーム中のレイヤの解像度の合計を計算させる命令をさらに記憶しており、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、解像度の前記計算された合計に少なくとも一部基づく、請求項22に記載の非一時的コンピュータ可読記憶媒体。

【請求項24】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを前記決定するステップがさらに、解像度の前記合計が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる積以下であるかどうかに少なくとも一部基づく、請求項23に記載の非一時的コンピュータ可読記憶媒体。

【請求項25】

実行されると、前記プロセッサに、
前記マルチレイヤビットストリームの最上位レイヤの解像度を決定させ、
前記マルチレイヤビットストリームの識別子リスト中のレイヤの数を決定させ、
前記識別子リスト中のレイヤの前記数を前記最上位レイヤの前記解像度と乗算すること
を介して、解像度の前記合計を計算させる
命令をさらに記憶した、請求項23に記載の非一時的コンピュータ可読記憶媒体。

【請求項26】

デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定するように構成されるビデオコーディングデバイスであって、前記デコーダが複数のシングルレイヤデコーダコアに基づいて実装され、
レイヤの少なくとも1つのセットへの前記マルチレイヤビットストリームのレイヤの少なくとも1つの割振りを特定するための手段と、
レイヤの各セットが前記マルチレイヤビットストリームの前記復号のために前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出するための手段と、
レイヤの各セットが前記シングルレイヤデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出することに少なくとも一部基づいて、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するための手段と
を備え、
前記デコーダの最大ルーマピクチャサイズを決定するための手段と、
前記デコーダのレベル定義と関連付けられる規模を指定するための手段
をさらに備え、
前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定することが前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、ビデオコーディングデバイス。

【請求項27】

前記デコーダのレベル定義を指定するための手段をさらに備え、
前記デコーダの最大ルーマピクチャサイズを決定することが、前記デコーダの前記レベル定義に少なくとも一部基づいて、前記デコーダの最大ルーマピクチャサイズを決定することを備える、請求項26に記載のビデオコーディングデバイス。

【請求項28】

前記マルチレイヤビットストリーム中のレイヤの解像度の合計を計算するための手段をさらに備え、前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するための前記手段が前記規模と前記デコーダの前記最大ルーマピクチャサイズとに少なくとも一部基づく、請求項27に記載のビデオコーディングデバイス。

【請求項29】

前記デコーダが前記マルチレイヤビットストリームを復号することが可能かどうかを決定するための前記手段が、解像度の前記合計が、前記規模を前記デコーダの前記最大のピクチャサイズと乗算することにより得られる積以下であるかどうかを決定するための手段を備える、請求項28に記載のビデオコーディングデバイス。

【請求項30】

前記マルチレイヤビットストリームの最上位レイヤの解像度を決定するための手段と、
前記マルチレイヤビットストリームの識別子リスト中のレイヤの数を決定するための手段と、
前記識別子リスト中のレイヤの前記数を前記最上位レイヤの前記解像度と乗算することを介して、解像度の前記合計を計算するための手段とをさらに備える、請求項28に記載のビデオコーディングデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ビデオコーディングの分野に関し、より具体的には、ビデオ情報を含むマルチレイヤビットストリームの状況におけるデコーダ能力に関する。

【背景技術】

【0002】

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話または衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、Moving Picture Experts Group-2(MPEG-2)、MPEG-4、International Telegraph Union-Telecommunication Standardization Sector(ITU-T) H.263、ITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)、High Efficiency Video Coding(HEVC)規格、およびそのような規格の拡張によって定義される規格に記載されるような、ビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信し、受信し、符号化し、復号し、かつ/または記憶することができる。

【0003】

スケーラブルHEVC(SHVC)およびマルチビューHEVC(MV-HEVC)のようなビデオコーディング規格は、デコーダ能力を定義するためのレベル定義を提供する。以下では、既存のレベル定義および本発明が行われた時点でのSHVCの他の状況に基づいて、問題および解決法が説明されるが、この解決法はMV-HEVCに、および他のマルチレイヤコーデックにも適用される。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】文書JCTVC-L1003、Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のJoint Collaborative Team on Video Coding(JCT-VC)、第12回会合:ジュネーブ、スイス、2013年1月14日〜2013年1月23日

【発明の概要】

【課題を解決するための手段】

【0005】

本開示のシステム、方法、およびデバイスは各々、いくつかの革新的な態様を有し、それらの態様のうちのいずれの1つも、本明細書で開示される望ましい属性を単独では担わない。

【0006】

一態様では、デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定するための方法であって、デコーダが複数のシングルレイヤデコーダコアに基づいて実装される、方法は、レイヤの少なくとも1つのセットへのビットストリームのレイヤの少なくとも1つの割振りを特定するステップと、レイヤの各セットがビデオ情報を復号するためにデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出するステップと、レイヤの各セットがデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出したことに少なくとも一部基づいて、デコーダがビットストリームを復号することが可能かどうかを決定するステップとを備える。

【0007】

別の態様では、デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定するための装置であって、デコーダが複数のシングルレイヤデコーダコアに基づいて実装される、装置は、レイヤの少なくとも1つのセットへのビットストリームのレイヤの少なくとも1つの割振りを特定し、レイヤの各セットがビットストリームの復号のためにデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出し、レイヤの各セットがデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出したことに少なくとも一部基づいて、デコーダがビットストリームを復号することが可能かどうかを決定するように構成される、少なくとも1つのプロセッサを備える。

【0008】

別の態様では、非一時的コンピュータ可読記憶媒体は、実行されると、デバイスのプロセッサに、複数のシングルレイヤデコーダコアに基づいて実装されるデコーダがビットストリームを復号することが可能かどうかを決定する際に使用するための、レイヤの少なくとも1つのセットへの、ビデオ情報を含むマルチレイヤビットストリームのレイヤの少なくとも1つの割振りを特定させ、レイヤの各セットがビットストリームの復号のためにデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出させ、レイヤの各セットがデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出したことに少なくとも一部基づいて、デコーダがビットストリームを復号することが可能かどうかを決定させる、命令を記憶している。

【0009】

さらに別の態様では、デコーダがビデオ情報を含むマルチレイヤビットストリームを復号することが可能かどうかを決定するように構成されるビデオコーディングデバイスであって、デコーダが複数のシングルレイヤデコーダコアに基づいて実装される、ビデオコーディングデバイスは、レイヤの少なくとも1つのセットへのビットストリームのレイヤの少なくとも1つの割振りを特定するための手段と、レイヤの各セットがビットストリームの復号のためにデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出するための手段と、レイヤの各セットがデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出したことに少なくとも一部基づいて、デコーダがビットストリームを復号することが可能かどうかを決定するための手段とを備える。

【図面の簡単な説明】

【0010】

【図1A】本開示で説明される態様による技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図である。

【図1B】本開示で説明される態様による技法を実行し得る別の例示的なビデオ符号化および復号システムを示すブロック図である。

【図2A】本開示で説明される態様による技法を実装し得るビデオエンコーダの例を示すブロック図である。

【図2B】本開示で説明される態様による技法を実装し得るビデオエンコーダの別の例を示すブロック図である。

【図3A】本開示で説明される態様による技法を実装し得るビデオデコーダの例を示すブロック図である。

【図3B】本開示で説明される態様による技法を実装し得るビデオデコーダの別の例を示すブロック図である。

【図4A】本開示において説明される態様による、デコーダ能力を定義するための処理のある例示的な実施形態のフローチャートである。

【図4B】本開示において説明される態様による、デコーダ能力をさらに定義するための処理のある例示的な実施形態のフローチャートである。

【図5A】本開示において説明される態様による、ある例示的なマルチレイヤビットストリームを示す図である。

【図5B】本開示において説明される態様による、図5Aのマルチレイヤビットストリームを復号するための複数の例示的な選択肢を示す図である。

【図6A】本開示において説明される態様による、別の例示的なマルチレイヤビットストリームを示す図である。

【図6B】本開示において説明される態様による、図6Aのマルチレイヤビットストリームを復号するための複数の例示的な選択肢を示す図である。

【発明を実施するための形態】

【0011】

一般に、本開示は、利点の中でも特に、効率的に高いピクチャ品質を可能にするためにレベルの制約がレイヤの数に対してスケーラブルであり得るように、マルチレイヤビデオコーデックの状況においてビットストリームとデコーダの両方のためのレベルを指定することに対する改善に関する。

【0012】

ビデオコーディング規格は、ITU-T H.261と、ISO/IEC MPEG-1 Visualと、ITU-T H.262またはISO/IEC MPEG-2 Visualと、ITU-T H.263と、ISO/IEC MPEG-4 Visualと、そのスケーラブルビデオコーディング(SVC)拡張およびマルチビュービデオコーディング(MVC)拡張を含む(ISO/IEC MPEG-4 AVCとしても知られる) ITU-T H.264とを含む。

【0013】

加えて、新しいビデオコーディング規格、すなわち、High Efficiency Video Coding(HEVC)が、ITU-T Video Coding Experts Group(VCEG)およびISO/IEC MPEGのJoint Collaboration Team on Video Coding(JCT-VC)によって開発されている。HEVC Draft 10の完全な引用は、文書JCTVC-L1003、Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のJoint Collaborative Team on Video Coding(JCT-VC)、第12回会合:ジュネーブ、スイス、2013年1月14日〜2013年1月23日である。HEVCのマルチビュー拡張すなわちMV-HEVC、およびSHVCという名称であるHEVCのスケーラブル拡張も、それぞれ、JCT-3V(ITU-T/ISO/IEC Joint Collaborative Team on 3D Video Coding Extension Development)およびJCT-VCによって開発されている。MV-HEVCの最近のワーキングドラフト(WD)は、以後MV-HEVC WD7と呼ばれる。SHVCの最近のWDは、以後SHVC WD5と呼ばれる。

【0014】

既存のレベル定義の手法は、マルチレイヤビットストリームの効率的な復号のためのデコーダ能力を定義するのに十分な情報を提供しない。たとえば、各々720pの解像度の5つ以上の信号対雑音比(SNR)スケーラブルレイヤ(等価な解像度を有するレイヤ)を復号するために、レベル5以上のデコーダが必要とされる。その結果、ルミナンスコーディングツリーブロック(CTB)サイズは、32×32または64×64に等しい(すなわち、16×16のようなより小さなコーディングサイズは使用され得ない)。しかしながら、720p以下の解像度を有するレイヤのような一部のレイヤに対しては、この制約は最適ではないコーディング効率をもたらし得る。

【0015】

いくつかの例では、デコーダは、複数の既存のシングルレイヤデコーダを再使用することによって製造され得る。ある例では、4つのシングルレイヤHEVCレベル3.1デコーダからなるSHVCデコーダは、既存のレベル定義によれば、720pの4つのSNRレイヤを復号するためにレベル4以上に適合しなければならない。この定義により、デコーダは任意のレベル4ビットストリームを復号することが可能でなければならない。しかしながら、デコーダハードウェアへの変更がなければ、そのようなデコーダは、1080pの解像度の2つのSNRレイヤを伴うSHVCレベル4ビットストリームを復号することが可能ではないであろう。

【0016】

既存のHEVCレベル定義の別の問題は、1080pのシングルレイヤHEVCビットストリームと720pの2レイヤSHVCビットストリームの両方を復号することが可能であるような方法で実装されるデコーダが、レベル3.1として分類されるということである。しかしながら、レベル3.1という分類は、1080pのシングルレイヤビットストリームを復号する能力を表さない。

【0017】

別の例では、既存のレベル定義によれば、720pの4つのSNRレイヤを復号することが可能であるように4つのシングルレイヤHEVC 3.1デコーダを使用して実装されるデコーダについて、そのデコーダはレベル4以上に適合しなければならない。したがって、デコーダは、4つ以上のタイル行と4つ以上のタイル列とを有するビットストリームを復号することが可能であることを要求され、各タイルは256個のルーマサンプルの幅と144個のルーマサンプルの高さとを有する。しかしながら、デコーダのレベル3.1の制限により、一部のそのようなビットストリームを復号することが可能ではない。

【0018】

SHVCの既存の設計のもとでは、HEVCテキストのA.4.1項のすべての項目が、各レイヤに適用されるように指定される。しかしながら、一部の項目は各レイヤに直接適用可能ではない。たとえば、復号ピクチャバッファ(DPB)のサイズに対する項目dについて、シーケンスパラメータセット(SPS)シンタックス要素はエンハンスメントレイヤに対して適用可能ではない。また、SHVC WD5におけるDPBは、共有サブDPB設計であるので、項目dは各レイヤに直接適用され得ない。別の例として、コーディングされたピクチャバッファ(CPB)のサイズに対する項目hおよびiに対して、ビットストリーム固有のCPB動作のために、パラメータは各レイヤに適用され得ない。

【0019】

CPBのサイズに対するビットストリーム固有の制約(HEVCテキストのA.4.1項における項目hおよびiによる)が必要とされる。しかしながら、HEVCテキストのA.4.1項の項目hおよびiはビットストリームレベルに対して直接適用されることが可能ではなく、それは、直接適用されると、シングルレイヤビットストリームに対する同じCPBサイズの制限がマルチレイヤビットストリームに対する制限ともなるからである。これはレイヤの数に対してスケーラブルではなく、多数のレイヤがあるときに低いピクチャ品質しか可能にしない。

【0020】

HEVCテキストのA.4.2項における項目b、c、d、g、h、i、およびjによる制約は、レイヤだけに固有であるように指定される。しかしながら、これらの項目によるビットストリーム固有の制約が、それらの項目によるレイヤ固有の制約が指定されるかどうかにかかわらず、指定されるべきである。

【0021】

ある実施形態が、本明細書でHEVC規格および/またはH.264規格の文脈で説明されるが、当業者は、本明細書で開示されるシステムおよび方法が、任意の適切なビデオコーディング規格または標準的ではないビデオコーデック設計に適用可能であり得ることを了解し得る。たとえば、本明細書で開示される実施形態は、以下の規格、すなわち、国際電気通信連合(ITU) Telecommunication Standardization Sector(ITU-T) H.261、国際標準化機構/国際電気標準会議(ISO/IEC) MPEG-1 Visual、ITU-T H.262、またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびスケーラブル拡張とマルチビュー拡張とを含む、(ISO/IEC MPEG-4 AVCとしても知られる)ITU-T H.264の1つまたは複数に適用可能であり得る。

【0022】

HEVCは全般に、多くの点で、前のビデオコーディング規格のフレームワークに従う。HEVCにおける予測のユニットは、いくつかの前のビデオコーディング規格における予測のユニット(たとえば、マクロブロック)とは異なる。実際、いくつかの前のビデオコーディング規格において理解されているようなマクロブロックの概念は、HEVCに存在しない。マクロブロックは、4分木方式に基づく階層構造と置き換えられ、このことは、あり得る利点の中でもとりわけ、高い柔軟性を実現し得る。たとえば、HEVC方式では、コーディングユニット(CU)、予測ユニット(PU)、および変換ユニット(TU)という3つのタイプのブロックが定義される。CUは、領域分割の基本単位を指し得る。CUはマクロブロックの概念に類似すると見なされることがあるが、HEVCは、CUの最大サイズを制限せず、コンテンツ適応性を改善するために4つの等しいサイズのCUへの再帰的分割を許容し得る。PUはインター/イントラ予測の基本単位と見なされることがあり、単一のPUは、不規則な画像パターンを効果的にコーディングするために、複数の任意の形状区分を含むことがある。TUは、変換の基本単位と見なされることがある。TUは、PUとは無関係に定義され得るが、TUのサイズは、TUが属するCUのサイズに制限され得る。3つの異なる概念へのブロック構造のこの分離により、各ユニットをユニットのそれぞれの役割に従って最適化することが可能になり、このことはコーディング効率の改善をもたらし得る。

【0023】

単に説明の目的で、本明細書で開示されるいくつかの実施形態は、ビデオデータの2つのレイヤ(たとえば、ベースレイヤのなどの下位レイヤおよびエンハンスメントレイヤなどの上位レイヤ)のみを含む例とともに説明される。ビデオデータの「レイヤ」は、一般に、ビュー、フレームレート、解像度などの、少なくとも1つの共通の特性を有するピクチャのシーケンスを指し得る。たとえば、レイヤは、マルチビュービデオデータの特定のビュー(たとえば、視点)と関連付けられたビデオデータを含み得る。別の例として、レイヤは、スケーラブルビデオデータの特定のレイヤと関連付けられたビデオデータを含み得る。したがって、本開示は、ビデオデータのレイヤおよびビューに交換可能に言及することがある。すなわち、ビデオデータのビューはビデオデータのレイヤと呼ばれることがあり、ビデオデータのレイヤはビデオデータのビューと呼ばれることがある。加えて、マルチレイヤコーデック(マルチレイヤビデオコーダまたはマルチレイヤエンコーダデコーダとも呼ばれる)は、マルチビューコーデックまたはスケーラブルコーデック(たとえば、MV-HEVC、3D-HEVC、SHVC、または別のマルチレイヤコーディング技法を使用してビデオデータを符号化および/または復号するように構成されるコーデック)を一緒に指すことがある。ビデオ符号化およびビデオ復号は、一般に、両方ともビデオコーディングと呼ばれることがある。そのような例は、複数のベースレイヤおよび/またはエンハンスメントレイヤを含む構成に適用可能であり得ることを理解されたい。加えて、説明を簡単にするために、以下の開示は、いくつかの実施形態に関して「フレーム」または「ブロック」という用語を含む。しかしながら、これらの用語は限定的なものではない。たとえば、下で説明される技法は、ブロック(たとえば、CU、PU、TU、マクロブロックなど)、スライス、フレームなどの、任意の適切なビデオユニットとともに使用され得る。

【0024】

ビデオコーディング規格
ビデオ画像、TV画像、静止画像、またはビデオレコーダもしくはコンピュータによって生成された画像のようなデジタル画像は、水平な線および垂直な線に並べられたピクセルまたはサンプルからなり得る。単一の画像中のピクセルの数は、一般に数万個である。各ピクセルは、一般に、ルミナンス情報とクロミナンス情報とを含む。圧縮がなければ、画像エンコーダから画像デコーダに搬送されるべき著しい量の情報により、リアルタイムの画像送信は不可能になるであろう。送信されるべき情報の量を減らすために、JPEG、MPEG、およびH.263規格のような、いくつかの異なる圧縮方法が開発された。ビデオコーディング規格は、本明細書で前に列挙された規格を含む。

【0025】

ビデオコーディングシステム
添付の図面を参照して、新規のシステム、装置、および方法の様々な態様が以下でより十分に説明される。しかしながら、本開示は、多くの異なる形態で具現化されてよく、本開示全体を通じて示される任意の特定の構造または機能に限定されるものと解釈されるべきでない。そうではなく、これらの態様は、本開示が十分なものであり、完全であるように、また本開示の範囲を当業者に十分伝えるように提供される。本明細書の教示に基づいて、本開示の範囲は、本開示の他の態様と無関係に実装されるか、または本開示の他の態様と組み合わせて実装されるかにかかわらず、本明細書で開示される新規のシステム、装置、および方法の任意の態様を包含することを、当業者は了解されたい。たとえば、本明細書に記載される任意の数の態様を使用して、装置が実装されてよく、または方法が実践されてよい。さらに、本開示の範囲は、本明細書に記載される本開示の様々な態様に加えて、またはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実践されるような装置または方法を包含するものとする。本明細書で開示される任意の態様は、特許請求の範囲の1つまたは複数の要素により具現化され得ることを理解されたい。

【0026】

特定の態様が本明細書で説明されるが、これらの態様の多数の変形および置換が、本開示の範囲内にある。好ましい態様のいくつかの利益および利点が説明されるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、その一部が例として図面および好ましい態様の以下の説明において示される、異なるワイヤレス技術と、システム構成と、ネットワークと、伝送プロトコルとに幅広く適用可能であることが意図されている。詳細な説明および図面は、限定的ではなく本開示の例示にすぎず、本開示の範囲は、添付の特許請求の範囲およびその均等物によって定義される。

【0027】

添付の図面は例を示している。添付の図面中の参照番号によって示される要素は、以下の説明における同様の参照番号によって示される要素に対応する。本開示では、序数語(たとえば、「第1の」、「第2の」、「第3の」など)で始まる名前を有する要素は、必ずしもそれらの要素が特定の順序を有することを暗示するとは限らない。むしろ、そのような序数語は、同じまたは同様のタイプの、異なる要素を指すために使用されるにすぎない。

【0028】

図1Aは、本開示で説明される態様による技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用される場合、「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化とビデオ復号とを総称的に指し得る。ビデオエンコーダおよびビデオデコーダに加えて、本出願で説明される態様は、トランスコーダ(たとえば、ビットストリームを復号し、別のビットストリームを再符号化することができるデバイス)およびミドルボックス(たとえば、ビットストリームを修正し、変換し、かつ/または別様に操作することができるデバイス)のような、他の関連するデバイスに拡張され得る。

【0029】

図1Aに示されるように、ビデオコーディングシステム10は、宛先デバイス14によって後で復号されるべき符号化されたビデオデータを生成するソースデバイス12を含む。図1Aの例では、ソースデバイス12および宛先デバイス14は、別個のデバイスを構成する。しかしながら、ソースデバイス12および宛先デバイス14は、図1Bの例に示されるように、同じデバイス上にあるかまたは同じデバイスの一部であり得ることに留意されたい。

【0030】

もう一度図1Aを参照すると、ソースデバイス12および宛先デバイス14は、それぞれ、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。様々な実施形態では、ソースデバイス12および宛先デバイス14は、ワイヤレス通信に対応し得る。

【0031】

宛先デバイス14は、復号されるべき符号化されたビデオデータを、リンク16を介して受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化されたビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。図1Aの例では、リンク16は、ソースデバイス12が符号化されたビデオデータをリアルタイムで宛先デバイス14に送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、高周波(RF)スペクトルまたは1つもしくは複数の物理伝送線路のような、任意のワイヤレスまたは有線の通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワークのようなパケットベースネットワーク、またはインターネットのようなグローバルネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を支援するのに有用であり得る任意の他の機器を含み得る。

【0032】

代替的に、符号化されたデータは、出力インターフェース22から記憶デバイス31(任意選択で存在する)に出力され得る。同様に、符号化されたデータは、たとえば、宛先デバイス14の入力インターフェース28によって記憶デバイス31からアクセスされ得る。記憶デバイス31は、ハードドライブ、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる例では、記憶デバイス31は、ソースデバイス12によって生成された符号化されたビデオを保持し得るファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して記憶デバイス31から記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を通じて符号化されたビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、ワイヤレスローカルエリアネットワーク(WLAN)接続)、有線接続(たとえば、デジタル加入者線(DSL)、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイス31からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはその両方の組合せであり得る。

【0033】

本開示の技法は、ワイヤレスの適用例または設定に限定されない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信(たとえば、ハイパーテキスト転送プロトコル(HTTP)上での動的適応ストリーミングなど)、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例のような、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、ビデオコーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話のような用途をサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。

【0034】

図1Aの例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。いくつかの場合、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえばビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、あるいはそのようなソースの組合せを含み得る。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、図1Bの例に示されているように、いわゆる「カメラ電話」または「ビデオ電話」を形成し得る。しかしながら、本開示で説明される技法は、ビデオコーディング全般に適用可能であってよく、ワイヤレスおよび/または有線の適用例に適用され得る。

【0035】

キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータにより生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に送信され得る。符号化されたビデオデータはさらに(または代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのために記憶デバイス31に記憶され得る。図1Aおよび図1Bに示されるビデオエンコーダ20は、図2Aに示されるビデオエンコーダ20、図2Bに示されるビデオエンコーダ23、または本明細書で説明される任意の他のビデオエンコーダを備え得る。

【0036】

図1Aの例では、宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。いくつかの場合、入力インターフェース28は、受信機および/またはモデムを含み得る。宛先デバイス14の入力インターフェース28は、リンク16を通じて、および/または記憶デバイス31から、符号化されたビデオデータを受信し得る。リンク16を通じて通信され、または記憶デバイス31上に与えられた、符号化されたビデオデータは、ビデオデータを復号する際に、ビデオデコーダ30のようなビデオデコーダが使用するためのビデオエンコーダ20によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体に記憶されるか、またはファイルサーバに記憶される、符号化されたビデオデータとともに含まれ得る。図1Aおよび図1Bに示されるビデオデコーダ30は、図3Aに示されるビデオデコーダ30、図3Bに示されるビデオデコーダ33、または本明細書で説明される任意の他のビデオデコーダを備えてよい。

【0037】

ディスプレイデバイス32は、宛先デバイス14と一体化されるか、またはその外部にあり得る。いくつかの例では、宛先デバイス14は、一体型のディスプレイデバイスを含むことがあり、外部ディスプレイデバイスとインターフェースするように構成されることもある。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのいずれかを備え得る。

【0038】

関連する態様では、図1Bは例示的なビデオコーディングシステム10'を示し、ソースデバイス12および宛先デバイス14はデバイス11上にあるかまたはデバイス11の一部である。デバイス11は、「スマート」フォンなどのような電話ハンドセットであり得る。デバイス11は、ソースデバイス12および宛先デバイス14と動作可能に通信しているプロセッサ/コントローラデバイス13(任意選択で存在する)を含み得る。図1Bのビデオコーディングシステム10'は、ビデオエンコーダ20と出力インターフェース22との間にビデオ処理ユニット21をさらに含み得る。いくつかの実装形態では、図1Bに示されているように、ビデオ処理ユニット21は別個のユニットであるが、他の実装形態では、ビデオ処理ユニット21は、ビデオエンコーダ20および/またはプロセッサ/コントローラデバイス13の一部分として実装され得る。ビデオコーディングシステム10'はまた、ビデオシーケンス中の対象オブジェクトを追跡することができるトラッカー29(任意選択で存在する)を含み得る。追跡されるべき対象オブジェクトは、本開示の1つまたは複数の態様に関して説明される技法によって区切られ得る。関係する態様では、追跡は、単独でまたはトラッカー29とともに、ディスプレイデバイス32によって実行され得る。図1Bのビデオコーディングシステム10'およびそのコンポーネントは、その他の点では図1Aのビデオコーディングシステム10およびそのコンポーネントと同様である。

【0039】

ビデオエンコーダ20およびビデオデコーダ30は、HEVCのようなビデオ圧縮規格に従って動作することができ、HEVCテストモデル(HM)に準拠することができる。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、AVCと呼ばれるITU-T H.264規格のような、他のプロプライエタリ規格もしくは業界規格、またはそのような規格の拡張に従って動作し得る。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例には、MPEG-2およびITU-T H.263がある。

【0040】

図1Aおよび図1Bの例には示されていないが、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。

【0041】

ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアのような、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれもが、それぞれのデバイスにおいて複合エンコーダ/デコーダ(たとえば、コーデック)の一部として統合されてよい。

【0042】

ビデオコーディング処理
上で簡単に述べられたように、ビデオエンコーダ20はビデオデータを符号化する。ビデオデータは、1つまたは複数のピクチャを備え得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。いくつかの事例では、ピクチャはビデオ「フレーム」と呼ばれ得る。ビデオエンコーダ20がビデオデータを符号化するとき、ビデオエンコーダ20はビットストリームを生成し得る。ビットストリームは、ビデオデータのコーディングされた表現を形成するビットのシーケンスを含み得る。ビットストリームは、コーディングされたピクチャと関連データとを含み得る。コーディングされたピクチャは、ピクチャのコーディングされた表現である。

【0043】

ビットストリームを生成するために、ビデオエンコーダ20は、ビデオデータ中の各ピクチャに対して符号化動作を実行し得る。ビデオエンコーダ20がピクチャに対して符号化動作を実行するとき、ビデオエンコーダ20は、一連のコーディングされたピクチャと関連データとを生成し得る。関連データは、ビデオパラメータセット(VPS)と、シーケンスパラメータセット(SPS)と、ピクチャパラメータセット(PPS)と、適応パラメータセット(APS)と、他のシンタックス構造とを含み得る。SPSは、0個以上のピクチャのシーケンスに適用可能なパラメータを含み得る。PPSは、0個以上のピクチャに適用可能なパラメータを含み得る。APSは、0個以上のピクチャに適用可能なパラメータを含み得る。APS中のパラメータは、PPS中のパラメータよりも変化する可能性が高いパラメータであり得る。

【0044】

コーディングされたピクチャを生成するために、ビデオエンコーダ20は、ピクチャを等しいサイズのビデオブロックに区分し得る。ビデオブロックは、サンプルの2次元アレイであり得る。ビデオブロックの各々は、ツリーブロックと関連付けられる。いくつかの事例では、ツリーブロックは、最大コーディングユニット(LCU)と呼ばれ得る。HEVCのツリーブロックは、H.264/AVCのような、以前の規格のマクロブロックに広い意味で類似し得る。しかしながら、ツリーブロックは、特定のサイズに必ずしも限定されず、1つまたは複数のコーディングユニット(CU)を含み得る。ビデオエンコーダ20は、4分木区分を使用して、ツリーブロックのビデオブロックを、CUと関連付けられたビデオブロックに区分することができ、したがって「ツリーブロック」という名前がある。

【0045】

いくつかの例では、ビデオエンコーダ20はピクチャを複数のスライスに区分し得る。スライスの各々は、整数個のCUを含み得る。いくつかの事例では、スライスは整数個のツリーブロックを備える。他の事例では、スライスの境界はツリーブロック内にあり得る。

【0046】

ピクチャに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実行し得る。ビデオエンコーダ20がスライスに対して符号化動作を実行するとき、ビデオエンコーダ20は、スライスと関連付けられた符号化されたデータを生成し得る。スライスと関連付けられた符号化されたデータは「コーディングされたスライス」と呼ばれ得る。

【0047】

コーディングされたスライスを生成するために、ビデオエンコーダ20は、スライス中の各ツリーブロックに対して符号化動作を実行し得る。ビデオエンコーダ20がツリーブロックに対して符号化動作を実行するとき、ビデオエンコーダ20はコーディングされたツリーブロックを生成し得る。コーディングされたツリーブロックは、ツリーブロックの符号化されたバージョンを表すデータを備え得る。

【0048】

ビデオエンコーダ20がコーディングされたスライスを生成するとき、ビデオエンコーダ20は、ラスター走査順序に従って、スライス中のツリーブロックに対して符号化動作を実行し得る(たとえば、そのツリーブロックを符号化し得る)。たとえば、ビデオエンコーダ20は、スライス中のツリーブロックの一番上の行にわたって左から右に進み、次いでツリーブロックの次の下の行にわたって左から右に進み、以下同様に進む順序で、ビデオエンコーダ20がスライス中のツリーブロックの各々を符号化するまで、スライスのツリーブロックを符号化し得る。

【0049】

ラスター走査順序に従ってツリーブロックを符号化した結果として、所与のツリーブロックの上および左のツリーブロックは符号化されていることがあるが、所与のツリーブロックの下および右のツリーブロックはまだ符号化されていない。したがって、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの上および左のツリーブロックを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの下および右のツリーブロックを符号化することによって生成された情報にアクセスすることが不可能であり得る。

【0050】

コーディングされたツリーブロックを生成するために、ビデオエンコーダ20は、ツリーブロックのビデオブロックに対して4分木区分を再帰的に実行して、ビデオブロックを徐々により小さくなるビデオブロックに分割し得る。より小さなビデオブロックの各々は、異なるCUと関連付けられ得る。たとえば、ビデオエンコーダ20は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し、サブブロックの1つまたは複数を、4つの等しいサイズのサブサブブロックに区分することができ、以下同様である。区分されたCUは、そのビデオブロックが他のCUと関連付けられるビデオブロックに区分された、CUであり得る。区分されていないCUは、そのビデオブロックが他のCUと関連付けられたビデオブロックに区分されていない、CUであり得る。

【0051】

ビットストリーム中の1つまたは複数のシンタックス要素は、ビデオエンコーダ20がツリーブロックのビデオブロックを区分し得る最大の回数を示し得る。CUのビデオブロックは、形状が正方形であり得る。CUのビデオブロックのサイズ(たとえば、CUのサイズ)は、8×8のピクセルから、最大で64×64以上のピクセルをもつツリーブロックのビデオブロックのサイズ(たとえば、ツリーブロックのサイズ)にまで及び得る。

【0052】

ビデオエンコーダ20は、z走査順序に従って、ツリーブロックの各CUに対して符号化動作を実行し得る(たとえば、各CUを符号化し得る)。言い換えれば、ビデオエンコーダ20は、左上のCUと、右上のCUと、左下のCUと、次いで右下のCUとを、その順序で符号化し得る。ビデオエンコーダ20が、区分されたCUに対して符号化動作を実行するとき、ビデオエンコーダ20は、z走査順序に従って、区分されたCUのビデオブロックのサブブロックと関連付けられたCUを符号化し得る。言い換えれば、ビデオエンコーダ20は、左上のサブブロックと関連付けられたCUと、右上のサブブロックと関連付けられたCUと、左下のサブブロックと関連付けられたCUと、次いで右下のサブブロックと関連付けられたCUとを、その順序で符号化し得る。

【0053】

z走査順序に従ってツリーブロックのCUを符号化した結果として、所与のCUの上、左上、右上、左、および左下のCUは符号化されていることがある。所与のCUの下および右のCUはまだ符号化されていない。したがって、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接するいくつかのCUを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接する他のCUを符号化することによって生成された情報にアクセスすることが不可能であり得る。

【0054】

ビデオエンコーダ20が区分されていないCUを符号化するとき、ビデオエンコーダ20は、CUのために1つまたは複数の予測ユニット(PU)を生成し得る。CUのPUの各々は、CUのビデオブロック内の異なるビデオブロックと関連付けられ得る。ビデオエンコーダ20は、CUの各PUのための予測されたビデオブロックを生成し得る。PUの予測されたビデオブロックは、サンプルのブロックであり得る。ビデオエンコーダ20は、イントラ予測またはインター予測を使用して、PUのための予測されたビデオブロックを生成し得る。

【0055】

ビデオエンコーダ20がイントラ予測を使用してPUの予測されたビデオブロックを生成するとき、ビデオエンコーダ20は、PUと関連付けられたピクチャの復号されたサンプルに基づいて、PUの予測されたビデオブロックを生成し得る。ビデオエンコーダ20がイントラ予測を使用してCUのPUの予測されたビデオブロックを生成する場合、CUはイントラ予測されたCUである。ビデオエンコーダ20がインター予測を使用してPUの予測されたビデオブロックを生成するとき、ビデオエンコーダ20は、PUと関連付けられたピクチャ以外の1つまたは複数のピクチャの復号されたサンプルに基づいて、PUの予測されたビデオブロックを生成し得る。ビデオエンコーダ20がインター予測を使用してCUのPUの予測されたビデオブロックを生成する場合、CUはインター予測されたCUである。

【0056】

さらに、ビデオエンコーダ20がインター予測を使用してPUのための予測されたビデオブロックを生成するとき、ビデオエンコーダ20はPUの動き情報を生成し得る。PUの動き情報は、PUの1つまたは複数の参照ブロックを示し得る。PUの各参照ブロックは、参照ピクチャ内のビデオブロックであり得る。参照ピクチャは、PUと関連付けられたピクチャ以外のピクチャであり得る。いくつかの事例では、PUの参照ブロックは、PUの「参照サンプル」と呼ばれることもある。ビデオエンコーダ20は、PUの参照ブロックに基づいて、PUのための予測されたビデオブロックを生成し得る。

【0057】

ビデオエンコーダ20がCUの1つまたは複数のPUのための予測されたビデオブロックを生成した後、ビデオエンコーダ20は、CUのPUのための予測されたビデオブロックに基づいて、CUの残差データを生成し得る。CUの残差データは、CUのPUのための予測されたビデオブロック中のサンプルと、CUの元のビデオブロック中のサンプルとの間の差を示し得る。

【0058】

さらに、区分されていないCUに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、CUの残差データに対して再帰的な4分木区分を実行して、CUの残差データを、CUの変換ユニット(TU)と関連付けられた残差データの1つまたは複数のブロック(たとえば、残差ビデオブロック)に区分し得る。CUの各TUは、異なる残差ビデオブロックと関連付けられ得る。

【0059】

ビデオエンコーダ20は、TUと関連付けられた変換係数ブロック(たとえば、変換係数のブロック)を生成するために、TUと関連付けられた残差ビデオブロックに1つまたは複数の変換を適用し得る。概念的に、変換係数ブロックは変換係数の2次元(2D)行列であり得る。

【0060】

変換係数ブロックを生成した後、ビデオエンコーダ20は、変換係数ブロックに対して量子化処理を実行し得る。量子化は、一般に、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を実現する処理を指す。量子化処理は、変換係数の一部またはすべてと関連付けられるビット深度を低減することができる。たとえば、量子化中にnビットの変換係数がmビットの変換係数へと切り捨てられることがあり、ただしnはmよりも大きい。

【0061】

ビデオエンコーダ20は、各CUを量子化パラメータ(QP)値と関連付け得る。CUと関連付けられたQP値は、ビデオエンコーダ20が、CUと関連付けられた変換係数ブロックをどのように量子化するかを決定し得る。ビデオエンコーダ20は、CUと関連付けられたQP値を調整することによって、CUと関連付けられた変換係数ブロックに適用される量子化の程度を調整し得る。

【0062】

ビデオエンコーダ20が変換係数ブロックを量子化した後、ビデオエンコーダ20は、量子化された変換係数ブロック中で変換係数を表すシンタックス要素のセットを生成し得る。ビデオエンコーダ20は、これらのシンタックス要素のうちのいくつかに、コンテキスト適応型バイナリ算術コーディング(CABAC)動作のようなエントロピー符号化動作を適用し得る。コンテキスト適応型可変長コーディング(CALVC)、確率間隔区分エントロピー(PIPE)コーディング、または他のバイナリ算術コーディングのような、他のエントロピーコーディング技法も使用され得る。

【0063】

ビデオエンコーダ20によって生成されるビットストリームは、一連のネットワーク抽象化レイヤ(NAL)ユニットを含み得る。NALユニットの各々は、NALユニット中のデータのタイプの指示と、データを含むバイトとを含む、シンタックス構造であり得る。たとえば、NALユニットは、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、コーディングされたスライス、補足エンハンスメント情報(SEI)、アクセスユニットデリミタ、フィラーデータ、または別のタイプのデータを表すデータを含み得る。NALユニット中のデータは、様々なシンタックス構造を含み得る。

【0064】

ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信し得る。ビットストリームは、ビデオエンコーダ20によって符号化されたビデオデータのコーディングされた表現を含み得る。ビデオデコーダ30がビットストリームを受信するとき、ビデオデコーダ30は、ビットストリームに対して解析動作を実行し得る。ビデオデコーダ30が解析動作を実行するとき、ビデオデコーダ30は、ビットストリームからシンタックス要素を抽出し得る。ビデオデコーダ30は、ビットストリームから抽出されたシンタックス要素に基づいて、ビデオデータのピクチャを再構築し得る。シンタックス要素に基づいてビデオデータを再構築するための処理は、一般に、シンタックス要素を生成するためにビデオエンコーダ20によって実行される処理とは逆であり得る。

【0065】

ビデオデコーダ30がCUと関連付けられたシンタックス要素を抽出した後、ビデオデコーダ30は、シンタックス要素に基づいて、CUのPUのための予測されたビデオブロックを生成し得る。加えて、ビデオデコーダ30は、CUのTUと関連付けられた変換係数ブロックを逆量子化し得る。ビデオデコーダ30は、変換係数ブロックに対して逆変換を実行して、CUのTUと関連付けられた残差ビデオブロックを再構築し得る。予測されたビデオブロックを生成し、残差ビデオブロックを再構築した後、ビデオデコーダ30は、予測されたビデオブロックと残差ビデオブロックとに基づいてCUのビデオブロックを再構築し得る。このようにして、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて、CUのビデオブロックを再構築し得る。

【0066】

ビデオエンコーダ
図2Aは、本開示で説明される態様による技法を実装し得るビデオエンコーダ20の例を示すブロック図である。ビデオデコーダ20は、HEVCの場合のように、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオエンコーダ20は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。いくつかの例では、本開示で説明される技法は、ビデオエンコーダ20の様々なコンポーネント間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示されず)が、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。

【0067】

説明の目的で、本開示は、HEVCコーディングの状況においてビデオエンコーダ20を説明する。しかしながら、本開示の技法は他のコーディング規格または方法に適用可能であり得る。図2Aに示される例は、シングルレイヤコーデックのためのものである。しかしながら、図2Bに関してさらに説明されるように、ビデオエンコーダ20の一部またはすべてが、マルチレイヤコーデックの処理のために複製され得る。

【0068】

ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去する。インターコーディングは、時間的予測を利用して、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)のようなインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。

【0069】

図2Aの例では、ビデオエンコーダ20は複数の機能コンポーネントを含む。ビデオエンコーダ20の機能コンポーネントは、予測処理ユニット100と、残差生成ユニット102と、変換処理ユニット104と、量子化ユニット106と、逆量子化ユニット108と、逆変換ユニット110と、再構築ユニット112と、フィルタユニット113と、復号ピクチャバッファ114と、エントロピー符号化ユニット116とを含む。予測処理ユニット100は、インター予測ユニット121と、動き推定ユニット122と、動き補償ユニット124と、イントラ予測ユニット126と、レイヤ間予測ユニット128とを含む。他の例では、ビデオエンコーダ20は、より多数の、より少数の、または異なる機能コンポーネントを含み得る。さらに、動き推定ユニット122および動き補償ユニット124は、高度に統合され得るが、図2Aの例では、説明の目的で別々に表されている。

【0070】

ビデオエンコーダ20は、ビデオデータを受信し得る。ビデオエンコーダ20は、様々なソースからビデオデータを受信し得る。たとえば、ビデオエンコーダ20は、(たとえば、図1Aまたは図1Bに示された)ビデオソース18、または別のソースからビデオデータを受信し得る。ビデオデータは、一連のピクチャを表し得る。ビデオデータを符号化するために、ビデオエンコーダ20は、ピクチャの各々に対して符号化動作を実行し得る。ピクチャに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実行し得る。スライスに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、スライス中のツリーブロックに対して符号化動作を実行し得る。

【0071】

ツリーブロックに対して符号化動作を実行することの一部として、予測処理ユニット100は、ツリーブロックのビデオブロックに対して4分木区分を実行して、ビデオブロックを徐々により小さくなるビデオブロックに分割し得る。より小さなビデオブロックの各々は、異なるCUと関連付けられ得る。たとえば、予測処理ユニット100は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し、サブブロックの1つまたは複数を、4つの等しいサイズのサブサブブロックに区分することができ、以下同様である。

【0072】

CUと関連付けられたビデオブロックのサイズは、8×8のサンプルから、最大で64×64以上のサンプルをもつツリーブロックのサイズにまで及び得る。本開示では、「N×N(NxN)」および「N×N(N by N)」は、垂直方向の寸法および水平方向の寸法に関するビデオブロックのサンプルの寸法、たとえば、16×16(16x16)のサンプルまたは16×16(16 by 16)のサンプルを指すために交換可能に使用され得る。一般に、16×16のビデオブロックは、垂直方向に16個のサンプルを有し(y=16)、水平方向に16個のサンプルを有する(x=16)。同様に、N×Nのブロックは、一般に、垂直方向にN個のサンプルを有し、水平方向にN個のサンプルを有し、ここで、Nは非負の整数値を表す。

【0073】

さらに、ツリーブロックに対して符号化動作を実行することの一部として、予測処理ユニット100は、ツリーブロックのための階層的な4分木データ構造を生成し得る。たとえば、ツリーブロックは、4分木データ構造のルートノードに対応し得る。予測処理ユニット100がツリーブロックのビデオブロックを4つのサブブロックに区分する場合、ルートノードは、4分木データ構造中に4つの子ノードを有する。子ノードの各々は、サブブロックの1つと関連付けられたCUに対応する。予測処理ユニット100がサブブロックの1つを4つのサブサブブロックに区分する場合、サブブロックと関連付けられたCUに対応するノードは、サブサブブロックの1つと関連付けられたCUに各々が対応する、4つの子ノードを有し得る。

【0074】

4分木データ構造の各ノードは、対応するツリーブロックまたはCUのシンタックスデータ(たとえば、シンタックス要素)を含み得る。たとえば、4分木の中のノードは、そのノードに対応するCUのビデオブロックが4つのサブブロックに区分(たとえば、分割)されているかどうかを示す分割フラグを含み得る。CUのためのシンタックス要素は、再帰的に定義されてよく、CUのビデオブロックがサブブロックに分割されているかどうかに依存し得る。ビデオブロックが区分されていないCUは、4分木データ構造におけるリーフノードに対応し得る。コーディングされたツリーブロックは、対応するツリーブロックのための4分木データ構造に基づくデータを含み得る。

【0075】

ビデオエンコーダ20は、ツリーブロックの区分されていない各々のCUに対して符号化動作を実行し得る。ビデオエンコーダ20が、区分されていないCUに対して符号化動作を実行するとき、ビデオエンコーダ20は、区分されていないCUの符号化された表現を表すデータを生成する。

【0076】

CUに対して符号化動作を実行することの一部として、予測処理ユニット100は、CUの1つまたは複数のPUの中で、CUのビデオブロックを区分し得る。ビデオエンコーダ20およびビデオデコーダ30は、様々なPUサイズをサポートし得る。特定のCUのサイズが2N×2Nであると仮定すると、ビデオエンコーダ20およびビデオデコーダ30は、2N×2NまたはN×NというPUサイズと、2N×2N、2N×N、N×2N、N×N、2N×nU、nL×2N、nR×2N、または同様の対称なPUサイズでのインター予測とをサポートし得る。ビデオエンコーダ20およびビデオデコーダ30は、2N×nU、2N×nD、nL×2N、およびnR×2NというPUサイズに対する非対称区分もサポートし得る。いくつかの例では、予測処理ユニット100は、CUのビデオブロックの辺と直角に交わらない境界に沿ってCUのPUの間でCUのビデオブロックを区分するように、幾何学的な区分を実行し得る。

【0077】

インター予測ユニット121は、CUの各PUに対してインター予測を実行し得る。インター予測は、時間圧縮を実現し得る。PUに対してインター予測を実行するために、動き推定ユニット122は、PUのための動き情報を生成し得る。動き補償ユニット124は、PUベースの動き情報およびCUと関連付けられたピクチャ以外のピクチャ(たとえば、参照ピクチャ)の復号されたサンプルのための、予測されたビデオブロックを生成し得る。本開示では、動き補償ユニット124によって生成される予測されたビデオブロックは、インター予測されたビデオブロックと呼ばれることがある。

【0078】

スライスは、Iスライス、Pスライス、またはBスライスであり得る。動き推定ユニット122および動き補償ユニット124は、PUがIスライス中にあるか、Pスライス中にあるか、またはBスライス中にあるかに応じて、CUのPUのために異なる動作を実行し得る。Iスライス中では、すべてのPUがイントラ予測される。したがって、PUがIスライス中にある場合、動き推定ユニット122および動き補償ユニット124は、PUに対してインター予測を実行しない。

【0079】

PUがPスライス中にある場合、PUを含むピクチャは、「リスト0」と呼ばれる参照ピクチャのリストと関連付けられる。リスト0中の参照ピクチャの各々は、他のピクチャのインター予測に使用され得るサンプルを含む。動き推定ユニット122が、Pスライス中のPUに関して動き推定動作を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索し得る。PUの参照ブロックは、PUのビデオブロック中のサンプルに最も密接に対応するサンプルのセット、たとえば、サンプルのブロックであり得る。動き推定ユニット122は、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定するために、様々な尺度を使用し得る。たとえば、動き推定ユニット122は、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分尺度によって、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定し得る。

【0080】

Pスライス中のPUの参照ブロックを識別した後、動き推定ユニット122は、参照ブロックを含むリスト0中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。様々な例において、動き推定ユニット122は、動きベクトルを変化する精度で生成し得る。たとえば、動き推定ユニット122は、1/4サンプル精度、1/8サンプル精度、または他の分数のサンプル精度で動きベクトルを生成し得る。分数のサンプル精度の場合、参照ブロック値は、参照ピクチャ中の整数位置のサンプル値から補間され得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって識別された参照ブロックに基づいて、PUの予測されるビデオブロックを生成し得る。

【0081】

PUがBスライス中にある場合、PUを含むピクチャは、「リスト0」および「リスト1」と呼ばれる参照ピクチャの2つのリストと関連付けられ得る。いくつかの例では、Bスライスを含むピクチャは、リスト0およびリスト1の組合せである、リストの組合せと関連付けられ得る。

【0082】

さらに、PUがBスライス中にある場合、動き推定ユニット122は、PUのための単方向予測または双方向予測を実行し得る。動き推定ユニット122がPUのための単方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0またはリスト1の参照ピクチャを探索し得る。動き推定ユニット122は次いで、参照ブロックを含む、リスト0またはリスト1中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと、予測方向インジケータと、動きベクトルとを出力し得る。予測方向インジケータは、参照インデックスがリスト0中の参照ピクチャを示すのかまたはリスト1中の参照ピクチャを示すのかを示し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測されたビデオブロックを生成し得る。

【0083】

動き推定ユニット122がPUのための双方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索することができ、また、PUのための別の参照ブロックについて、リスト1中の参照ピクチャを探索することができる。動き推定ユニット122は次いで、参照ブロックを含む、リスト0およびリスト1中の参照ピクチャを示す参照インデックスと、参照ブロックとPUとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、PUの参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測されるビデオブロックを生成し得る。

【0084】

いくつかの事例では、動き推定ユニット122は、PUのための動き情報の完全なセットをエントロピー符号化ユニット116に出力しない。そうではなく、動き推定ユニット122は、別のPUの動き情報を参照して、PUの動き情報をシグナリングし得る。たとえば、動き推定ユニット122は、PUの動き情報が、隣接PUの動き情報と十分に類似していると決定し得る。この例では、動き推定ユニット122は、PUと関連付けられたシンタックス構造において、PUが隣接PUと同じ動き情報を有することをビデオデコーダ30に示す値を示し得る。別の例では、動き推定ユニット122は、PUと関連付けられたシンタックス構造において、隣接PUと動きベクトル差分(MVD)とを識別し得る。動きベクトル差分は、PUの動きベクトルと、示される隣接PUの動きベクトルとの差分を示す。ビデオデコーダ30は、示される隣接PUの動きベクトルと、動きベクトルの差分とを使用して、PUの動きベクトルを決定し得る。第2のPUの動き情報をシグナリングするときに第1のPUの動き情報を参照することによって、ビデオエンコーダ20は、より少数のビットを使用して、第2のPUの動き情報をシグナリングすることが可能であり得る。

【0085】

CUに対して符号化動作を実行することの一部として、イントラ予測ユニット126は、CUのPUに対してイントラ予測を実行し得る。イントラ予測は、空間圧縮を実現し得る。イントラ予測ユニット126がPUに対してイントラ予測を実行するとき、イントラ予測ユニット126は、同じピクチャ中の他のPUの復号されたサンプルに基づいて、PUのための予測データを生成し得る。PUのための予測データは、予測されるビデオブロックと様々なシンタックス要素とを含み得る。イントラ予測ユニット126は、Iスライス、Pスライス、およびBスライス中のPUに対してイントラ予測を実行し得る。

【0086】

PUに対してイントラ予測を実行するために、イントラ予測ユニット126は、PUのための予測データの複数のセットを生成するために、複数のイントラ予測モードを使用し得る。イントラ予測ユニット126がイントラ予測モードを使用してPUのための予測データのセットを生成するとき、イントラ予測ユニット126は、イントラ予測モードと関連付けられる方向および/または勾配で、隣接PUのビデオブロックからPUのビデオブロックにわたってサンプルを延ばし得る。PU、CU、およびツリーブロックについて左から右、上から下の符号化順序を仮定すると、隣接PUは、PUの上、右上、左上、または左にあり得る。イントラ予測ユニット126は、PUのサイズに応じて、様々な数のイントラ予測モード、たとえば、33個の方向性イントラ予測モードを使用し得る。

【0087】

予測処理ユニット100は、PUについて動き補償ユニット124によって生成された予測データ、またはPUについてイントラ予測ユニット126によって生成された予測データの中から、PUのための予測データを選択し得る。いくつかの例では、予測処理ユニット100は、予測データのセットのレート/ひずみの尺度に基づいて、PUのための予測データを選択する。

【0088】

予測処理ユニット100が、イントラ予測ユニット126によって生成された予測データを選択する場合、予測処理ユニット100は、PUの予測データを生成するために使用されたイントラ予測モード、たとえば、選択されたイントラ予測モードをシグナリングし得る。予測処理ユニット100は、選択されたイントラ予測モードを様々な方法でシグナリングし得る。たとえば、選択されたイントラ予測モードは、隣接PUのイントラ予測モードと同じである可能性があり得る。言い換えれば、隣接PUのイントラ予測モードは、現在のPUに対して最も可能性のあるモードであり得る。したがって、予測処理ユニット100は、選択されたイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示すための、シンタックス要素を生成し得る。

【0089】

上で説明されたように、ビデオエンコーダ20は、レイヤ間予測ユニット128を含み得る。レイヤ間予測ユニット128は、SHVCにおいて利用可能である1つまたは複数の異なるレイヤ(たとえば、ベースレイヤまたは参照レイヤ)を使用して、現在のブロック(たとえば、EL中の現在のブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット128は、レイヤ間の冗長性を低減するための予測方法を利用し、それによって、コーディング効率を改善し、計算リソースの要件を下げる。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するために、ベースレイヤの中で併置されているブロックの再構築を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動作を予測するために、ベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するために、ベースレイヤの残差を使用する。

【0090】

予測処理ユニット100がCUのPUのための予測データを選択した後、残差生成ユニット102は、CUのビデオブロックからCUのPUの予測されたビデオブロックを差し引くこと(たとえば、マイナス符号によって示される)によって、CUの残差データを生成し得る。CUの残差データは、CUのビデオブロック中のサンプルの異なるサンプル成分に対応する、2D残差ビデオブロックを含み得る。たとえば、残差データは、CUのPUの予測されるビデオブロック中のサンプルのルミナンス成分と、CUの元のビデオブロック中のサンプルのルミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。加えて、CUの残差データは、CUのPUの予測されるビデオブロック中のサンプルのクロミナンス成分と、CUの元のビデオブロック中のサンプルのクロミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。

【0091】

予測処理ユニット100は、4分木区分を実行して、CUの残差ビデオブロックをサブブロックに区分し得る。分割されていない各残差ビデオブロックは、CUの異なるTUと関連付けられ得る。CUのTUと関連付けられる残差ビデオブロックのサイズおよび位置は、CUのPUと関連付けられたビデオブロックのサイズおよび位置に基づいてよく、または基づかなくてよい。「残差4分木」(RQT)と呼ばれる4分木構造は、残差ビデオブロックの各々と関連付けられたノードを含み得る。CUのTUは、RQTのリーフノードに対応し得る。

【0092】

変換処理ユニット104は、TUと関連付けられた残差ビデオブロックに1つまたは複数の変換を適用することによって、CUの各TUのための1つまたは複数の変換係数ブロックを生成し得る。変換係数ブロックの各々は、変換係数の2D行列であり得る。変換処理ユニット104は、TUと関連付けられた残差ビデオブロックに様々な変換を適用し得る。たとえば、変換処理ユニット104は、離散コサイン変換(DCT)、方向性変換、または概念的に同様の変換を、TUと関連付けられた残差ビデオブロックに適用し得る。

【0093】

変換処理ユニット104が、TUと関連付けられた変換係数ブロックを生成した後、量子化ユニット106は、変換係数ブロック中の変換係数を量子化し得る。量子化ユニット106は、CUと関連付けられたQP値に基づいて、CUのTUと関連付けられた変換係数ブロックを量子化し得る。

【0094】

ビデオエンコーダ20は、様々な方法でQP値をCUと関連付け得る。たとえば、ビデオエンコーダ20は、CUと関連付けられたツリーブロックに対してレートひずみ分析を実行し得る。レートひずみ分析では、ビデオエンコーダ20は、ツリーブロックに対して符号化動作を複数回実行することによって、ツリーブロックの複数のコーディングされた表現を生成し得る。ビデオエンコーダ20がツリーブロックの異なる符号化された表現を生成するとき、ビデオエンコーダ20は、異なるQP値をCUと関連付け得る。ビデオエンコーダ20は、最小のビットレートおよびひずみの尺度を有するツリーブロックのコーディングされた表現において所与のQP値がCUと関連付けられるとき、所与のQP値がCUと関連付けられることをシグナリングし得る。

【0095】

逆量子化ユニット108および逆変換ユニット110は、変換係数ブロックから残差ビデオブロックを再構築するために、それぞれ、逆量子化と逆変換とを変換係数ブロックに適用し得る。再構築ユニット112は、TUと関連付けられる再構築されたビデオブロックを生成するために、再構築された残差ビデオブロックを、予測処理ユニット100によって生成された1つまたは複数の予測されたビデオブロックからの対応するサンプルに追加し得る。このようにCUの各TUのためのビデオブロックを再構築することによって、ビデオエンコーダ20は、CUのビデオブロックを再構築し得る。

【0096】

再構築ユニット112がCUのビデオブロックを再構築した後、フィルタユニット113は、CUと関連付けられたビデオブロックにおけるブロッキングアーティファクトを低減するために、デブロッキング動作を実行し得る。1つまたは複数のデブロッキング動作を実行した後、フィルタユニット113は、CUの再構築されたビデオブロックを復号ピクチャバッファ114に記憶し得る。動き推定ユニット122および動き補償ユニット124は、再構築されたビデオブロックを含む参照ピクチャを使用して、後続のピクチャのPUに対してインター予測を実行し得る。加えて、イントラ予測ユニット126は、復号ピクチャバッファ114の中の再構築されたビデオブロックを使用して、CUと同じピクチャ中の他のPUに対してイントラ予測を実行し得る。

【0097】

エントロピー符号化ユニット116は、ビデオエンコーダ20の他の機能コンポーネントからデータを受信し得る。たとえば、エントロピー符号化ユニット116は、量子化ユニット106から変換係数ブロックを受け取ることができ、予測処理ユニット100からシンタックス要素を受け取ることができる。エントロピー符号化ユニット116がデータを受信するとき、エントロピー符号化ユニット116は、1つまたは複数のエントロピー符号化動作を実行して、エントロピー符号化されたデータを生成し得る。たとえば、ビデオエンコーダ20は、CALVC動作、CABAC動作、変数間(V2V)レングスコーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)動作、確率間隔区分エントロピー(PIPE)コーディング動作、または別のタイプのエントロピー符号化動作をデータに対して実行し得る。エントロピー符号化ユニット116は、エントロピー符号化されたデータを含むビットストリームを出力し得る。

【0098】

データに対してエントロピー符号化動作を実行することの一部として、エントロピー符号化ユニット116は、コンテキストモデルを選択し得る。エントロピー符号化ユニット116がCABAC動作を実行している場合、コンテキストモデルは、特定の値を有する特定のビンの確率の推定値を示し得る。CABACの状況では、「ビン」という用語は、シンタックス要素の2値化されたバージョンのビットを指すために使用される。

【0099】

マルチレイヤビデオエンコーダ
図2Bは、本開示で説明される態様による技法を実装し得る(単にビデオエンコーダ23とも呼ばれる)マルチレイヤビデオエンコーダ23の例を示すブロック図である。ビデオエンコーダ23は、SHVCおよびMV-HEVCの場合のように、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオエンコーダ23は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。

【0100】

ビデオエンコーダ23はビデオエンコーダ20Aとビデオエンコーダ20Bとを含み、それらの各々はビデオエンコーダ20として構成されてよく、ビデオエンコーダ20に関して上で説明された機能を実行し得る。さらに、参照番号の再使用によって示されるように、ビデオエンコーダ20Aおよび20Bは、ビデオエンコーダ20としてのシステムおよびサブシステムの少なくともいくつかを含み得る。ビデオエンコーダ23は、2つのビデオエンコーダ20Aおよび20Bを含むように示されるが、ビデオエンコーダ23は、そのように限定されず、任意の数のビデオエンコーダ20のレイヤを含み得る。いくつかの実施形態では、ビデオエンコーダ23は、アクセスユニット中の各ピクチャまたは各フレームに対してビデオエンコーダ20を含み得る。たとえば、5つのピクチャを含むアクセスユニットは、5つのエンコーダレイヤを含むビデオエンコーダによって処理または符号化され得る。いくつかの実施形態では、ビデオエンコーダ23は、アクセスユニット中のフレームよりも多くのエンコーダレイヤを含み得る。いくつかのそのような場合では、ビデオエンコーダのレイヤのいくつかは、いくつかのアクセスユニットを処理するときに無効であり得る。

【0101】

ビデオエンコーダ20Aおよび20Bに加えて、ビデオエンコーダ23は、リサンプリングユニット90を含み得る。いくつかの場合、リサンプリングユニット90は、たとえば、エンハンスメントレイヤを作成するために、受信されたビデオフレームのベースレイヤをアップサンプリングし得る。リサンプリングユニット90は、フレームの受信されたベースレイヤと関連付けられた特定の情報をアップサンプリングし得るが、他の情報をアップサンプリングしないことがある。たとえば、リサンプリングユニット90は、ベースレイヤの空間サイズまたはピクセルの数をアップサンプリングし得るが、スライスの数またはピクチャ順序カウントは一定のままであり得る。いくつかの場合、リサンプリングユニット90は、受信されたビデオを処理しないことがあり、および/または任意選択であり得る。たとえば、いくつかの場合、予測処理ユニット100は、アップサンプリングを実行し得る。いくつかの実施形態では、リサンプリングユニット90は、レイヤをアップサンプリングし、スライス境界の規則および/またはラスター走査の規則のセットに適合するように1つまたは複数のスライスを再編成し、再定義し、修正し、または調整するように構成される。アクセスユニット中のベースレイヤまたは下位レイヤをアップサンプリングするものとして主に説明されたが、いくつかの場合、リサンプリングユニット90は、レイヤをダウンサンプリングし得る。たとえば、ビデオのストリーミングの間に帯域幅が減少した場合、フレームは、アップサンプリングされるのではなく、ダウンサンプリングされ得る。

【0102】

リサンプリングユニット90は、下位レイヤエンコーダ(たとえば、ビデオエンコーダ20A)の復号ピクチャバッファ114からピクチャまたはフレーム(またはピクチャと関連付けられたピクチャ情報)を受信し、ピクチャ(または受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤエンコーダと同じアクセスユニット中のピクチャを符号化するように構成された、上位レイヤエンコーダ(たとえば、ビデオエンコーダ20B)の予測処理ユニット100に提供され得る。いくつかの場合、上位レイヤエンコーダは、下位レイヤエンコーダから除去された1つのレイヤである。他の場合には、図2Bのレイヤ0ビデオエンコーダとレイヤ1エンコーダとの間に、1つまたは複数の上位レイヤエンコーダがあり得る。

【0103】

いくつかの場合、リサンプリングユニット90は、省略またはバイパスされ得る。そのような場合、ビデオエンコーダ20Aの復号ピクチャバッファ114からのピクチャは、直接、または少なくともリサンプリングユニット90に提供されずに、ビデオエンコーダ20Bの予測処理ユニット100に提供され得る。たとえば、ビデオエンコーダ20Bに提供されたビデオデータ、およびビデオエンコーダ20Aの復号ピクチャバッファ114からの参照ピクチャが、同じサイズまたは解像度である場合、参照ピクチャは、いかなるリサンプリングも伴わずにビデオエンコーダ20Bに提供され得る。

【0104】

いくつかの実施形態では、ビデオエンコーダ23は、ビデオエンコーダ20Aにビデオデータを提供する前に、ダウンサンプリングユニット94を使用して下位レイヤエンコーダに供給されるべきビデオデータをダウンサンプリングする。代替的に、ダウンサンプリングユニット94は、ビデオデータをアップサンプリングまたはダウンサンプリングすることが可能なリサンプリングユニット90であり得る。さらに他の実施形態では、ダウンサンプリングユニット94は省略され得る。

【0105】

図2Bに示されるように、ビデオエンコーダ23はさらに、マルチプレクサ(すなわちmux)98を含み得る。mux98は、ビデオエンコーダ23から合成されたビットストリームを出力することができる。合成されたビットストリームは、ビデオエンコーダ20Aおよび20Bの各々からビットストリームを取り、所与の時間においてどちらのビットストリームが出力されるかを切り替えることによって作成され得る。いくつかの場合には、2つの(または、3つ以上のビデオエンコーダレイヤの場合には、より多くの)ビットストリームからのビットが一度に1ビット切り替えられ得るが、多くの場合、ビットストリームは異なるように合成され得る。たとえば、出力ビットストリームは、選択されたビットストリームを一度に1ブロック切り替えることによって作成され得る。別の例では、出力ビットストリームは、ビデオエンコーダ20Aおよび20Bの各々から1:1ではない比のブロックを出力することによって作成され得る。たとえば、ビデオエンコーダ20Aから出力された各ブロックについて、2つのブロックがビデオエンコーダ20Bから出力され得る。いくつかの実施形態では、mux98からの出力ストリームは事前にプログラムされ得る。他の実施形態では、mux98は、ビデオエンコーダ23の外部のシステムから、たとえばソースデバイス12を含むソースデバイス上のプロセッサから受信された制御信号に基づいて、ビデオエンコーダ20A、20Bからのビットストリームを合成し得る。制御信号は、ビデオソース18からのビデオの解像度またはビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザと関連付けられるサブスクリプション(たとえば、有料サブスクリプション対無料サブスクリプション)に基づいて、またはビデオエンコーダ23から望まれる解像度出力を決定するための任意の他の要因に基づいて生成され得る。

【0106】

ビデオデコーダ
図3Aは、本開示で説明される態様による技法を実装し得るビデオデコーダ30の例を示すブロック図である。ビデオデコーダ30は、HEVCの場合のように、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオデコーダ30は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。いくつかの例では、本開示で説明される技法は、ビデオデコーダ30の様々なコンポーネント間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示されず)が、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。

【0107】

説明の目的で、本開示は、HEVCコーディングの状況においてビデオデコーダ30を説明する。しかしながら、本開示の技法は他のコーディング規格または方法に適用可能であり得る。図3Aに示される例は、シングルレイヤコーデックのためのものである。しかしながら、図3Bに関してさらに説明されるように、ビデオデコーダ30の一部またはすべてが、マルチレイヤコーデックの処理のために複製され得る。

【0108】

図3Aの例では、ビデオデコーダ30は複数の機能コンポーネントを含む。ビデオデコーダ30の機能コンポーネントは、エントロピー復号ユニット150と、予測処理ユニット152と、逆量子化ユニット154と、逆変換ユニット156と、再構築ユニット158と、フィルタユニット159と、復号ピクチャバッファ160とを含む。予測処理ユニット152は、動き補償ユニット162と、イントラ予測ユニット164と、レイヤ間予測ユニット166とを含む。いくつかの例では、ビデオデコーダ30は、図2Aのビデオエンコーダ20に関して説明された符号化経路とは全般に逆の復号経路を実行し得る。他の例では、ビデオデコーダ30は、より多数の、より少数の、または異なる機能コンポーネントを含み得る。

【0109】

ビデオデコーダ30は、符号化されたビデオデータを備えるビットストリームを受信し得る。ビットストリームは、複数のシンタックス要素を含み得る。ビデオデコーダ30がビットストリームを受信するとき、エントロピー復号ユニット150は、ビットストリームに対して解析動作を実行し得る。ビットストリームに対して解析動作を実行した結果として、エントロピー復号ユニット150は、ビットストリームからシンタックス要素を抽出し得る。解析動作を実行することの一部として、エントロピー復号ユニット150は、ビットストリーム中のエントロピー符号化されたシンタックス要素をエントロピー復号し得る。予測処理ユニット152、逆量子化ユニット154、逆変換ユニット156、再構築ユニット158、およびフィルタユニット159は、ビットストリームから抽出されたシンタックス要素に基づいて復号されたビデオデータを生成する、再構築動作を実行し得る。

【0110】

上で論じられたように、ビットストリームは、一連のNALユニットを備え得る。ビットストリームのNALユニットは、ビデオパラメータセットNALユニット、シーケンスパラメータセットNALユニット、ピクチャパラメータセットNALユニット、SEI NALユニットなどを含み得る。ビットストリームに対して解析動作を実行することの一部として、エントロピー復号ユニット150は、シーケンスパラメータセットNALユニットからのシーケンスパラメータセット、ピクチャパラメータセットNALユニットからのピクチャパラメータセット、SEI NALユニットからのSEIデータなどを抽出しエントロピー復号する、解析動作を実行し得る。

【0111】

さらに、ビットストリームのNALユニットは、コーディングされたスライスNALユニットを含み得る。ビットストリームに対して解析動作を実行することの一部として、エントロピー復号ユニット150は、コーディングされたスライスNALユニットからコーディングされたスライスを抽出しエントロピー復号する、解析動作を実行し得る。コーディングされたスライスの各々は、スライスヘッダと、スライスデータとを含み得る。スライスヘッダは、スライスに関するシンタックス要素を含み得る。スライスヘッダ中のシンタックス要素は、スライスを含むピクチャと関連付けられたピクチャパラメータセットを識別するシンタックス要素を含み得る。エントロピー復号ユニット150は、コーディングされたスライスヘッダ中のシンタックス要素に対してCABAC復号動作のようなエントロピー復号演算を実行して、スライスヘッダを復元し得る。

【0112】

コーディングされたスライスNALユニットからスライスデータを抽出することの一部として、エントロピー復号ユニット150は、スライスデータ中のコーディングされたCUからシンタックス要素を抽出する解析動作を実行し得る。抽出されたシンタックス要素は、変換係数ブロックと関連付けられるシンタックス要素を含み得る。エントロピー復号ユニット150は次いで、シンタックス要素のいくつかに対してCABAC復号動作を実行し得る。

【0113】

エントロピー復号ユニット150が区分されていないCUに対して解析動作を実行した後、ビデオデコーダ30は、区分されていないCUに対して再構築動作を実行し得る。区分されていないCUに対して再構築動作を実行するために、ビデオデコーダ30はCUの各TUに対して再構築動作を実行し得る。CUの各TUについて再構築動作を実行することによって、ビデオデコーダ30は、CUと関連付けられた残差ビデオブロックを再構築し得る。

【0114】

TUに対して再構築動作を実行することの一部として、逆量子化ユニット154は、TUと関連付けられた変換係数ブロックを逆量子化(inverse quantize)、たとえば、逆量子化(de-quantize)し得る。逆量子化ユニット154は、HEVCのために提案された、またはH.264復号規格によって定義された逆量子化処理と同様の方式で、変換係数ブロックを逆量子化し得る。逆量子化ユニット154は、変換係数ブロックのCUのためにビデオエンコーダ20によって計算される量子化パラメータQPを使用して、量子化の程度を決定し、同様に、逆量子化ユニット154が適用すべき逆量子化の程度を決定し得る。

【0115】

逆量子化ユニット154が変換係数ブロックを逆量子化した後、逆変換ユニット156は、変換係数ブロックと関連付けられたTUのための残差ビデオブロックを生成し得る。逆変換ユニット156は、変換係数ブロックに逆変換を適用して、TUのための残差ビデオブロックを生成し得る。たとえば、逆変換ユニット156は、変換係数ブロックに、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT)、逆回転変換、逆方向変換、または別の逆変換を適用し得る。いくつかの例では、逆変換ユニット156は、ビデオエンコーダ20からのシグナリングに基づいて、変換係数ブロックに適用すべき逆変換を決定し得る。そのような例では、逆変換ユニット156は、変換係数ブロックと関連付けられたツリーブロックの4分木のルートノードにおけるシグナリングされた変換に基づいて、逆変換を決定し得る。他の例では、逆変換ユニット156は、ブロックサイズ、コーディングモードなどのような、1つまたは複数のコーディング特性から逆変換を推測し得る。いくつかの例では、逆変換ユニット156はカスケード逆変換を適用し得る。

【0116】

いくつかの例では、動き補償ユニット162は、補間フィルタに基づく補間を実行することによって、PUの予測されるビデオブロックを改良し得る。サブサンプル精度を有する動き補償のために使用されるべき補間フィルタのための識別子は、シンタックス要素に含まれ得る。動き補償ユニット162は、PUの予測されたビデオブロックの生成の間にビデオエンコーダ20によって使用されたのと同じ補間フィルタを使用して、参照ブロックのサブ整数サンプルのための補間された値を計算し得る。動き補償ユニット162は、受信されたシンタックス情報に従って、ビデオエンコーダ20によって使用された補間フィルタを決定し、その補間フィルタを使用して予測されたビデオブロックを生成し得る。

【0117】

PUが、イントラ予測を使用して符号化される場合、イントラ予測ユニット164は、イントラ予測を実行して、PUのための予測されたビデオブロックを生成し得る。たとえば、イントラ予測ユニット164は、ビットストリーム中のシンタックス要素に基づいて、PUのためのイントラ予測モードを決定し得る。ビットストリームは、PUのイントラ予測モードを決定するためにイントラ予測ユニット164が使用し得るシンタックス要素を含み得る。

【0118】

いくつかの事例では、シンタックス要素は、イントラ予測ユニット164が現在のPUのイントラ予測モードを決定するために別のPUのイントラ予測モードを使用すべきであることを、示し得る。たとえば、現在のPUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることが起こり得る。言い換えれば、隣接PUのイントラ予測モードは、現在のPUに対して最も可能性のあるモードであり得る。したがって、この例では、ビットストリームは、PUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示す、小さいシンタックス要素を含み得る。イントラ予測ユニット164は次いで、イントラ予測モードを使用して、空間的に隣接するPUのビデオブロックに基づいてPUのための予測データ(たとえば、予測されるサンプル)を生成し得る。

【0119】

上で説明されたように、ビデオデコーダ30もレイヤ間予測ユニット166を含み得る。レイヤ間予測ユニット166は、SHVCにおいて利用可能である1つまたは複数の異なるレイヤ(たとえば、ベースレイヤまたは参照レイヤ)を使用して、現在のブロック(たとえば、エンハンスメントレイヤ中の現在のブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット166は、レイヤ間の冗長性を低減するための予測方法を利用し、それによって、コーディング効率を改善し、計算リソースの要件を下げる。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するために、ベースレイヤの中で併置されているブロックの再構築を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動作を予測するために、ベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するために、ベースレイヤの残差を使用する。レイヤ間予測方式の各々が、以下でより詳細に説明される。

【0120】

再構築ユニット158は、適用可能なとき、CUのTUと関連付けられた残差ビデオブロックとCUのPUの予測されたビデオブロックとを使用して、たとえば、イントラ予測データまたはインター予測データのいずれかを使用して、CUのビデオブロックを再構築し得る。したがって、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて、予測されたビデオブロックと残差ビデオブロックとを生成することができ、予測されたビデオブロックと残差ビデオブロックとに基づいて、ビデオブロックを生成することができる。

【0121】

再構築ユニット158がCUのビデオブロックを再構築した後、フィルタユニット159は、デブロッキング動作を実行して、CUと関連付けられるブロッキングアーティファクトを低減し得る。フィルタユニット159が、デブロッキング動作を実行してCUと関連付けられたブロッキングアーティファクトを低減した後、ビデオデコーダ30はCUのビデオブロックを復号ピクチャバッファ160に記憶し得る。復号ピクチャバッファ160は、後続の動き補償、イントラ予測、および図1Aまたは図1Bのディスプレイデバイス32のようなディスプレイデバイス上での提示のために、参照ピクチャを提供し得る。たとえば、ビデオデコーダ30は、復号ピクチャバッファ160中のビデオブロックに基づいて、他のCUのPUに対してイントラ予測動作またはインター予測動作を実行し得る。

【0122】

マルチレイヤデコーダ
図3Bは、本開示で説明される態様による技法を実装し得る(単にビデオデコーダ33とも呼ばれる)マルチレイヤビデオデコーダ33の例を示すブロック図である。ビデオデコーダ33は、SHVCおよびマルチビューコーディングの場合のように、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオデコーダ33は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。

【0123】

ビデオデコーダ33はビデオデコーダ30Aとビデオデコーダ30Bとを含み、それらの各々はビデオデコーダ30として構成されてよく、ビデオデコーダ30に関して上で説明された機能を実行し得る。さらに、参照番号の再使用によって示されるように、ビデオデコーダ30Aおよび30Bは、ビデオデコーダ30としてのシステムおよびサブシステムのうちの少なくともいくつかを含み得る。ビデオデコーダ33は、2つのビデオデコーダ30Aおよび30Bを含むように示されるが、ビデオデコーダ33は、そのように限定されず、任意の数のビデオデコーダ30のレイヤを含み得る。いくつかの実施形態では、ビデオデコーダ33は、アクセスユニット中の各ピクチャまたは各フレームに対してビデオデコーダ30を含み得る。たとえば、5つのピクチャを含むアクセスユニットは、5つのデコーダレイヤを含むビデオデコーダによって処理または復号され得る。いくつかの実施形態では、ビデオデコーダ33は、アクセスユニット中のフレームよりも多くのデコーダレイヤを含み得る。いくつかのそのような場合には、ビデオデコーダのレイヤのいくつかは、いくつかのアクセスユニットを処理するときに無効であり得る。

【0124】

ビデオデコーダ30Aおよび30Bに加えて、ビデオデコーダ33は、アップサンプリングユニット92を含み得る。いくつかの実施形態では、アップサンプリングユニット92は、受信されたビデオフレームのベースレイヤをアップサンプリングして、フレームまたはアクセスユニットのための参照ピクチャリストに追加されるべきエンハンストレイヤを作成し得る。このエンハンストレイヤは、復号ピクチャバッファ160に記憶され得る。いくつかの実施形態では、アップサンプリングユニット92は、図2Aのリサンプリングユニット90に関して説明された実施形態の一部またはすべてを含み得る。いくつかの実施形態では、アップサンプリングユニット92は、レイヤをアップサンプリングし、スライス境界の規則および/またはラスター走査の規則のセットに準拠するように、1つまたは複数のスライスを再編成し、再定義し、修正し、または調整するように構成される。いくつかの場合は、アップサンプリングユニット92は、受信されたビデオフレームのレイヤをアップサンプリングおよび/またはダウンサンプリングするように構成されたリサンプリングユニットであり得る。

【0125】

アップサンプリングユニット92は、下位レイヤデコーダ(たとえば、ビデオデコーダ30A)の復号ピクチャバッファ160からピクチャまたはフレーム(またはピクチャと関連付けられたピクチャ情報)を受信し、ピクチャ(または受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは次いで、下位レイヤデコーダと同じアクセスユニット中のピクチャを復号するように構成された上位レイヤデコーダ(たとえば、ビデオデコーダ30B)の予測処理ユニット152に与えられ得る。いくつかの場合、上位レイヤデコーダは、下位レイヤデコーダから除去された1つのレイヤである。他の場合には、図3Bのレイヤ0デコーダとレイヤ1デコーダとの間に1つまたは複数の上位レイヤデコーダがあり得る。

【0126】

いくつかの場合は、アップサンプリングユニット92は、省略またはバイパスされ得る。そのような場合、ビデオデコーダ30Aの復号ピクチャバッファ160からのピクチャは、直接、または少なくともアップサンプリングユニット92に提供されずに、ビデオデコーダ30Bの予測処理ユニット152に提供され得る。たとえば、ビデオデコーダ30Bに提供されたビデオデータ、およびビデオデコーダ30Aの復号ピクチャバッファ160からの参照ピクチャが、同じサイズまたは解像度である場合、参照ピクチャは、アップサンプリングを伴わずにビデオデコーダ30Bに提供され得る。さらに、いくつかの実施形態では、アップサンプリングユニット92は、ビデオデコーダ30Aの復号ピクチャバッファ160から受信された参照ピクチャをアップサンプリングまたはダウンサンプリングするように構成された、リサンプリングユニット90であり得る。

【0127】

図3Bに示されるように、ビデオデコーダ33はさらに、デマルチプレクサ(すなわちdemux)99を含み得る。demux99は、符号化されたビデオビットストリームを複数のビットストリームに分割することができ、demux99によって出力された各ビットストリームは、異なるビデオデコーダ30Aおよび30Bに提供される。複数のビットストリームはビットストリームを受信することによって作成されてよく、ビデオデコーダ30Aおよび30Bの各々は所与の時間においてビットストリームの一部分を受信する。いくつかの場合、demux99において受信されるビットストリームからのビットは、ビデオデコーダの各々(たとえば、図3Bの例ではビデオデコーダ30Aおよび30B)の間で、一度に1ビット切り替えられ得るが、多くの場合、ビットストリームは異なるように分割される。たとえば、ビットストリームは、どのビデオデコーダがビットストリームを受信するかを一度に1ブロック切り替えることによって分割され得る。別の例では、ビットストリームは、1:1ではない比のブロックによって、ビデオデコーダ30Aおよび30Bの各々に分割され得る。たとえば、2つのブロックは、ビデオデコーダ30Aに提供される各ブロックについてビデオデコーダ30Bに提供され得る。いくつかの実施形態では、demux99によるビットストリームの分割は、事前にプログラムされ得る。他の実施形態では、demux99は、ビデオデコーダ33の外部のシステムから、たとえば宛先デバイス14を含む宛先デバイス上のプロセッサから受信された制御信号に基づいて、ビットストリームを分割し得る。制御信号は、入力インターフェース28からのビデオの解像度またはビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザと関連付けられたサブスクリプション(たとえば、有料サブスクリプション対無料サブスクリプション)に基づいて、またはビデオデコーダ33によって取得可能な解像度を決定するための任意の他の要因に基づいて生成され得る。

【0128】

イントラランダムアクセスポイント(IRAP)ピクチャ
いくつかのビデオコーディング方式は、様々なランダムアクセスポイントを、ビットストリームの中でそれらのランダムアクセスポイントに先行するいかなるピクチャも復号する必要なく、それらのランダムアクセスポイントのいずれかからビットストリームの復号が開始され得るように、ビットストリーム全体にわたって提供し得る。そのようなビデオコーディング方式では、ランダムアクセススキップ先頭(RASL)ピクチャを除き、復号順序においてランダムアクセスポイントに後続するすべてのピクチャが、ランダムアクセスポイントに先行するいずれのピクチャも使用することなく正しく復号され得る。たとえば、ビットストリームの一部分が送信の間または復号の間に失われても、デコーダは、次のランダムアクセスポイントからビットストリームの復号を再開することができる。ランダムアクセスのサポートは、たとえば、動的なストリーミングサービス、検索動作、チャネル切替えなどを容易にし得る。

【0129】

いくつかのコーディング方式では、そのようなランダムアクセスポイントは、イントラランダムアクセスポイント(IRAP)ピクチャと呼ばれるピクチャによって提供され得る。たとえば、アクセスユニット(「auA」)に含まれるエンハンスメントレイヤ(「layerA」)中のエンハンスメントレイヤIRAPピクチャと関連付けられたランダムアクセスポイントは、各参照レイヤ(「layerB」)中にあり復号順序においてauAに先行するアクセスユニット(「auB」)に含まれるピクチャと関連付けられたランダムアクセスポイント(または、auAに含まれるランダムアクセスポイント)を有するlayerAの各layerB(たとえば、layerAを予測するために使用されるレイヤである参照レイヤ)について、復号順序においてauAに後続する(auAの中に位置するピクチャを含む)layerA中のピクチャが、auAに先行するlayerA中のいかなるピクチャも復号する必要なく正しく復号可能であるように、レイヤ特有のランダムアクセスを提供し得る。

【0130】

IRAPピクチャは、イントラ予測を使用してコーディングされてよく(たとえば、他のピクチャを参照することなくコーディングされてよく)かつ/またはレイヤ間予測を使用してコーディングされてよく、たとえば、瞬時デコーダリフレッシュ(IDR)ピクチャと、クリーンランダムアクセス(CRA)ピクチャと、ブロークンリンクアクセス(BLA)ピクチャとを含み得る。ビットストリーム中にIDRピクチャがあるとき、復号順序においてIDRピクチャに先行するすべてのピクチャは、IDRピクチャに後続するピクチャによる予測のために使用されない。ビットストリーム中にCRAピクチャがあるとき、CRAピクチャに後続するピクチャは、復号順序においてCRAピクチャに先行するピクチャを予測のために使用することがあり、または使用しないことがある。復号順序においてCRAピクチャに後続するが、復号順序においてCRAピクチャに先行するピクチャを使用するピクチャは、RASLピクチャと呼ばれ得る。復号順序においてIRAPピクチャに後続し、出力順序においてIRAPピクチャに先行することができる別のタイプのピクチャは、復号順序においてIRAPピクチャに先行するいかなるピクチャへの参照も含まないことがあるランダムアクセス復号可能先頭(RADL)ピクチャである。CRAピクチャに先行するピクチャが利用可能でない場合、RASLピクチャはデコーダによって廃棄され得る。BLAピクチャは、(たとえば、2つのビットストリームが互いに接合され、BLAピクチャが復号順序において第2のビットストリームの最初のピクチャであるので)BLAピクチャに先行するピクチャがデコーダにとって利用可能でないことがあることを、デコーダに示す。IRAPピクチャであるベースレイヤピクチャ(たとえば、0というレイヤID値を有する)を含むアクセスユニット(たとえば、複数のレイヤにわたって同じ出力時間と関連付けられたすべてのコーディングされたピクチャからなるピクチャのグループ)は、IRAPアクセスユニットと呼ばれ得る。

【0131】

ビットストリームおよびコーデックのためのレベル
本開示の1つまたは複数の態様によれば、スケーラブルビデオ符号化されたビットストリーム(ビットストリームとも単に呼ばれる)は、参照レイヤまたはベースレイヤ(BL)と1つまたは複数のエンハンスメントレイヤ(EL)とを有する。いくつかの例では、ビットストリームはマルチビューのビデオ符号化されたビットストリームであってよく、ここでレイヤの各々が異なるビューを構成し得る。マルチビュービットストリームの一例は、左目ビューレイヤと右目ビューレイヤとを含む、3次元(3D)ビデオビットストリームである。

【0132】

ビットストリームは、複数のアクセスユニット(AU)を含み得る。各アクセスユニットは、ベースレイヤからのピクチャと各エンハンスメントレイヤからのピクチャとを含み得る。

【0133】

ビットストリームは、レベルによって定義され得る。いくつかの例では、レベル定義は、レイヤの数(ベースレイヤおよびエンハンスメントレイヤELを含む)および/またはレイヤの解像度の合計の関数であり得る。ビットストリームは識別子リストを有してよく、識別子リストはビットストリームの1つまたは複数のレイヤを識別し得る。ビットストリームのレベルを定義することによって、ビデオコーディングシステムは、デコーダがビットストリームを復号することが可能かどうかを予測し得る。本開示の実装形態では、マルチレイヤビットストリームのレベルは他の要因によっても定義されてよく、レベルは規模と関連付けられることがある。

【0134】

「プロファイル」は、ビットストリームシンタックス全体のサブセットである。所与のプロファイルのシンタックスによって課される範囲内でも、復号されるピクチャの指定されるサイズのようなビットストリーム中のシンタックス要素がとる値に応じて、エンコーダおよびデコーダの性能に非常に大きな変動を必要とする可能性がある。多くの適用例では、ある特定のプロファイル内のシンタックスのすべての仮想的な使用法(シンタックス要素のすべての可能な値を含む)に対処することが可能なデコーダを実装するのは、現実的でも経済的でもない。

【0135】

この問題に対処するために、「層」および「レベル」が各プロファイル内で指定される。層のレベルは、ビットストリーム中のシンタックス要素の値に課される制約の指定されるセットである。これらの制約は、値に対する単純な制限であり得る。あるいは、それらは、値の算術的な組合せ(たとえば、ピクチャの幅とピクチャの高さと1秒当たりに復号されるピクチャの数とを乗じたもの)に対する制約の形をとり得る。より低い層に対して指定されるレベルは、より高い層に対して指定されるレベルよりも制約される。

【0136】

プロファイル
本明細書では、Scalable MainおよびScalable Main 10という2つの例示的なプロファイルが説明される。Scalable Main 10は、各レイヤ中のピクチャの各成分を8から10ビットに制限するためにそのように命名され、一方、Scalable Mainに対する同じ制限は8ビットだけである。本開示のいくつかの実装形態では、Scalable MainおよびScalable Main 10プロファイルが、以下で説明されるように定義される。

【0137】

【表1A】

【0138】

【表1B】

【0139】

層およびレベル
上で論じられたように、層のレベルは、ビットストリーム中のシンタックス要素の値に課される制約の指定されるセットである。レベルは、ビットストリームとデコーダの両方に対して指定され得る。デコーダのレベル定義は、デコーダの能力の上限を与える。レベルがデコーダに対して定義されると、デコーダは、(デコーダが特定のプロファイルおよび層のビットストリームを復号できれば)デコーダレベル以下のレベルのあらゆるビットストリームを復号することが可能であると予期される。たとえば、レベル4.0デコーダは、レベル4、3、2、および1のビットストリームを復号することが可能であると予測される。しかしながら、本明細書で説明されるように、いくつかの例では、既存のレベル定義は、デコーダ能力を不正確に定義することがある。

【0140】

デコーダ能力をより正確に定義するために、情報が制約に追加され得る。たとえば、本開示のいくつかの実装形態では、制約は、shvcScaleFactorおよびmaxAuSliceSegsを含む、1つまたは複数の変数を導入するように、以下で論じられるように修正され得る。いくつかの実施形態では、shvcScaleFactorは、シングルレイヤビットストリームのために定義された制約が、マルチレイヤビットストリームに対して適切であるように修正されることを可能にし得る。たとえば、MaxCPBおよびMaxLumaSrのようなパラメータは、シングルレイヤビットストリームのために定義された。しかしながら、shvcScaleFactorを加算することによって、MaxCPBおよびMaxLumaSrは、これらのパラメータのための新たな値のセットを定義することなく使用され得る。いくつかの実装形態では、shvcScaleFactorはCeil(auSizeInSampleY/MaxLumaPs)に等しく設定され、ここでMaxLumaPsは、出力レイヤセットのサブビットストリームが適合するレベルのために、Table A-1において指定される。すなわち、shvcScaleFactorは、サブビットストリーム中のすべてのレイヤの解像度の合計の概略的な指数(すなわち、auSizeInSamplesY)と、そのレベルに対する最大のルーマピクチャサイズとを与える。shvcScaleFactorの値は、SNRスケーラビリティのためにサブビットストリーム中のレイヤの数に等しいことに留意されたい(すなわち、サブビットストリーム中のすべてのレイヤが同じ空間解像度を有する)。レイヤ間にまたがる空間スケーラビリティまたはピクチャレートスケーラビリティが存在するとき、上で定義されたものよりも小さなshvcScaleFactorの値が使用され得る。

【0141】

あるいは、shvcScaleFactorは、Ceil((NumLayersInIdList[LayerSetIdxForOutputLayerSet[optLsIdx]] * (最上位レイヤのPicSizeInSamplesY)) / MaxLumaPs)に等しく設定され得る。または、言い換えると、AuSizeInSamplesY = NumLayersInIdList[LayerSetIdxForOutputLayerSet[optLsIdx]] * (最上位レイヤのPicSizeInSamplesY)である。以下で提案される修正は、shvcScaleFactorの上の定義のいずれかに対して適用され得る。

【0142】

また、変数maxAuSliceSegsは、shvcScaleFactor * MaxSliceSegmentsPerPictureに等しく設定されてよく、ここでMaxSliceSegmentsPerPictureはA-1において指定される。

【0143】

例示的な実施形態1
本開示のいくつかの実装形態では、一般的な層およびレベルの制限が、shvcScaleFactorを含むように以下で説明されるように修正され得る。本開示の例示的な実施形態は、SHVCおよびMV-HEVC(たとえば、SHVC WD5およびMV-HEVC WD7)の以前のバージョンの文脈において与えられる。SHVCおよびMV-HEVCの以前のバージョンに対する追加は斜体および下線によって示されおり、以前のバージョンからの削除は取消線によって示されている。注記は太字で示されている。

【0144】

【表2A】

【0145】

【表2B】

【0146】

【表2C】

【0147】

プロファイル固有の層およびレベルの制限
例示的な実施形態2
本開示のいくつかの実装形態では、Scalable MainおよびScalable Main 10に対するプロファイル固有の層およびレベルの制限は、以下で説明されるように修正され得る。本開示の例示的な実施形態は、SHVCおよびMV-HEVC(たとえば、SHVC WD5およびMV-HEVC WD7)の以前のバージョンの文脈において与えられる。SHVCおよびMV-HEVCの以前のバージョンに対する追加は斜体および下線によって示されおり、以前のバージョンからの削除は取消線によって示されている。注記は太字で示されている。

【0148】

【表3A】

【0149】

【表3B】

【0150】

デコーダ能力
本開示のいくつかの実装形態では、適合するデコーダの複数のカテゴリが指定される。デコーダの1つのカテゴリ(たとえば、カテゴリIデコーダと呼ばれる)は、より高いレベルに適合する一部のビットストリームを復号できるが、レイヤの数はデコーダのレベルと関連付けられる規模よりも小さく、一方でデコーダの別のカテゴリ(たとえば、カテゴリIIデコーダと呼ばれる)は、(プロファイルおよび層が同じであるとすれば)同じまたはより低いレベルに適合するビットストリームだけを復号することができる。カテゴリIデコーダは、既存のシングルレイヤHEVCデコーダのハードウェアコアを再使用することによって、または既存のシングルレイヤHEVCデコーダをまったく使用せずに(すなわち、最初から設計される)、1つの既存のシングルレイヤHEVCデコーダを使用して実装され得る。カテゴリIIは、変更することなくそのままハードウェアコアを再使用することによって、2つ以上の既存のシングルレイヤHEVCデコーダを使用して実装されることが可能であり、カテゴリIデコーダはこのように実装されることが可能ではない。

【0151】

本開示の実施形態は、ビットストリームまたはサブビットストリーム中の一部またはすべてのレイヤの空間解像度の合計を制限するために、規模のような変数Nを導入し得る。この規模は、以下の制約のもとで使用されるときにデコーダの能力のかなり正確な記述を提供する、任意の数であり得る。たとえば、この規模は、2から63の範囲にある任意の値に等しくてよく、SHVC/MV-HEVCはビットストリームにおいて最高で63個のレイヤをサポートすることに留意されたい。したがって、デコーダ能力は、プロファイル、層、レベル、および規模を含む、種々の記述子の1つまたは複数によって定義され得る。

【0152】

例示的な実施形態3
以下で説明される修正されたデコーダ能力では、各カテゴリに対して異なるように能力が定義され得る。本開示の例示的な実施形態は、SHVCおよびMV-HEVC(たとえば、SHVC WD5およびMV-HEVC WD7)の以前のバージョンの文脈において与えられる。SHVCおよびMV-HEVCの以前のバージョンに対する追加は斜体および下線によって示されおり、以前のバージョンからの削除は取消線によって示されている。注記は太字で示されている。

【0153】

【表4A】

【0154】

【表4B】

【0155】

【表4C】

【0156】

上の定義は、デコーダ能力を定義するために、規模Nを使用するための例示的な方法を提供する。しかしながら、他の選択肢が存在する。たとえば、「auSizeInSamplesYがN * MaxLumaPs以下であり、ここでMaxLumaPsはデコーダの指定されたレベルに対してTable A-1において指定される」という制約は、「numlayersInSubBitstream * MaxBsLumaPsがN * MaxDeLumaPs以下であり、ここでMaxBsLumaPsはサブビットストリームのレベルに対してTable A-1において指定され、MaxDeLumaPsはデコーダに対してTable A-1において指定されるMaxLumaPsである」によって置換され得る。これらの選択肢のいずれを使用するかの決定は、変数auSizeInSamplesYおよびnumlayersInSubBitstreamのいずれがユーザに知られているかに依存し得る。いずれにしても、numlayersInSubBitstreamまたはauSizeInSamplesYの値は、セッションネゴシエーションにおいてもまたはそれ以外でも、直接利用可能であるべきである。ファイルフォーマットでは、この値はサンプル記述においてシグナリングされるべきである。リアルタイム転送プロトコル(RTP)ペイロードフォーマットでは、メディアタイプパラメータがこのために定義されるべきである。auSizeInSamplesYが、たとえばVPS拡張またはVPS VUIにおいて直接シグナリングされる場合、auSizeInSamplesYを使用することは有効な選択肢であり得る。

【0157】

前に論じられたように、カテゴリIIデコーダは、ハードウェアデコーダコアを変更することなく、複数のHEVCシングルレイヤデコーダを再使用することによって実装され得る。カテゴリIIデコーダのための上のデコーダ能力の記述の重要な点は次の通りである。すなわち、レイヤの少なくとも1つのセットへのすべてのレイヤの割振りが存在し、レイヤの各セットが復号のためにデコーダコアの1つに排他的に割り当てられ得る。これは、レイヤの各セットの累積ピクチャサイズ、ビットレート、CPBサイズ、およびDPBサイズが、対応するデコーダコアのレベルの最大のピクチャサイズ、ビットレート、CPBサイズ、およびDPBサイズを超えてはならないという要件を含む。すべてのレイヤを割り振る1つの特定の例は、各レイヤが復号のために1つのデコーダコアに排他的に割り当てられ得るように、1つのセット中の各レイヤを割り振るというものである。

【0158】

図4Aは、本開示において説明される態様による、デコーダ能力を定義するためのある例示的な方法または処理400のフローチャートを示す。一実施形態では、処理400はブロック401において開始する。

【0159】

ブロック405において、処理400は、レイヤの少なくとも1つのセットへのビットストリームのレイヤの少なくとも1つの割振りを特定するステップを伴い得る。たとえば、5つのレイヤを有するマルチレイヤビットストリームは、レイヤの5つのセットに割り振られ得る。

【0160】

ブロック410において、処理400は、レイヤの各セットがビットストリームの復号のためにデコーダコアの1つに排他的に割り振られることが可能かどうかを検出するステップを伴い得る。ある実施形態では、一部のデコーダ(すなわち、カテゴリIIデコーダ)は、2つ以上の既存のシングルレイヤデコーダを使用して実装され得る。ブロック410において、そのようなデコーダがマルチレイヤビットストリームのレイヤの各セットを復号することが可能かどうかが決定され得る。たとえば、レイヤの5つのセットを有するマルチレイヤビットストリームのレイヤの各セットは、4つのシングルレイヤデコーダコアしか備えないデコーダのデコーダコアに排他的に割り当てられることが可能ではないことがある。

【0161】

ブロック415において、処理400は、レイヤの各セットがデコーダコアの1つに排他的に割り当てられることが可能かどうかを検出したことに少なくとも一部基づいて、デコーダがビットストリームを復号することが可能かどうかを決定するステップを伴い得る。たとえば、マルチレイヤビットストリームのレイヤのセットが各々、デコーダの個々のコアに排他的に割り当てられることが可能ではない場合、デコーダがビットストリームを復号することは可能ではないと決定され得る。しかしながら、いくつかの実施形態では、デコーダがビットストリームを復号することが可能かどうかを決定することに対して、他の要因が寄与することがある。これらの実施形態のいくつかでは、そのような要因が、デコーダの能力を定義する際に、個々にまたは組み合わせて使用され得る。

【0162】

処理400は、ブロック420において終了する。実装形態によっては、ブロックが処理400において追加および/または省略されることがあり、かつ具体的な実装形態によっては、処理400のブロックは異なる順序で実行されることがある。

【0163】

ある実施形態では、デコーダ能力をさらに定義するために、デコーダのレベル定義が指定され得る。レベル定義は、ビットストリームを復号するためのデコーダの能力に関する情報を伝え得る。いくつかの例では、レベルは、デコーダが復号できる最大のビットストリームレベル(たとえば、レイヤの数)を与え得る。定義されたレベルから、デコーダは、デコーダレベル以下のレベルを有する任意のビットストリームを復号することが可能であると予想され得る。システムはまた、デコーダが復号できる最大のルーマピクチャサイズを決定し得る。いくつかの例では、デコーダのレベル定義は、デコーダの最大のルーマピクチャサイズを示し得る。たとえば、Table A-1は、各デコーダレベルに対する最大のルーマピクチャサイズを与える。システムはまた、ビットストリーム中のレイヤの解像度の合計を計算し得る。いくつかの例では、ビットストリームの解像度の合計は、1つのアクセスユニット中のピクチャの解像度を使用して計算され得る。ユーザは規模を指定することもできる。デコーダ能力が次いで、規模およびレベル定義をデコーダと関連付けることによって定義され得る。

【0164】

図4Bは、本開示において説明される態様による、デコーダ能力をさらに定義するためのある例示的な処理400'のフローチャートを示す。処理400'は、図4Aを参照して上で説明された処理400の一部であってよく、または処理400とは別の独立の処理であってよいことに留意されたい。一実施形態では、処理400'はブロック450において開始する。

【0165】

ブロック455において、処理400'は、デコーダのレベル定義を指定するステップを伴い得る。レベル定義は、ビットストリームを復号するためのデコーダの能力に関する情報を伝え得る。いくつかの例では、レベルは、デコーダが復号できる最大のビットストリームレベル(たとえば、レイヤの数)を与え得る。定義されたレベルから、デコーダは、デコーダレベル以下のレベルを有する任意のビットストリームを復号することが可能であると予想され得る。

【0166】

ブロック460において、処理400'は、デコーダが復号できる最大のルーマピクチャサイズを決定するステップを伴い得る。いくつかの例では、デコーダのレベル定義は、デコーダの最大のルーマピクチャサイズを示し得る。たとえば、Table A-1は、各デコーダレベルに対する最大のルーマピクチャサイズを与える。

【0167】

ブロック465において、処理400'は、ビットストリームのレベルと関連付けられる規模を指定するステップを伴い得る。適切な規模を決定するために、ユーザまたはシステムは、特定の規模Nを使用して本明細書で説明されるデコーダ能力によって指定されるような、可能な限り多くのビットストリームをデコーダが復号できることを、確認することができる。

【0168】

判断ブロック470において、処理400'は、ビットストリーム中のレイヤの解像度の合計を使用して、デコーダの能力を決定するかどうかを決めるステップを伴い得る。いくつかの例では、ビットストリーム中のレイヤの解像度の合計を使用してデコーダの能力を決定することが有利であり得る。たとえば、auSizeInSamplesYが、たとえばVPS拡張またはVPS VUIにおいて直接シグナリングされる場合、auSizeInSamplesYを使用することはデコーダ能力を決定する有用な方法であり得る。しかしながら、システムは、ビットストリーム中のレイヤの数またはauSizeInSamplesYがより容易に利用可能かどうかということを含む、解像度の合計を使用するかどうかを決定するために、種々の試験の1つまたは複数を利用し得る。SNRスケーラビリティでは(すなわち、すべてのレイヤが同じ解像度を有する場合)、ビットストリーム中のレイヤの数を使用することまたはauSizeInSamplesYを使用することは等価である。この場合、システムは、ビットストリーム中のレイヤの数を使用することができ、それはこの選択肢がより簡単であるからである。

【0169】

ブロック475において、処理400'が解像度の合計を使用すると(判断ブロック420において決定されるように)決めるステップを伴う場合、処理400'は、解像度の合計を計算するステップも伴い得る。

【0170】

しかしながら、処理400'が解像度の合計を使用しないと(判断ブロック470において決定されるように)決めるステップを伴う場合、処理400'は、ブロック480において、ビットストリーム中のレイヤの数を決定するステップを伴い得る。

【0171】

ブロック485において、処理400'は、ビットストリームのレベル定義を定義するために、ビットストリーム中のレイヤの数および/またはビットストリームの任意の他の識別情報を使用するステップを伴い得る。

【0172】

ブロック490において、デコーダと同様に、処理400'は、ビットストリームの最大のルーマピクチャサイズを決定するステップを伴い得る。たとえば、システムは、ビットストリームのレベル定義を使用してビットストリームの最大のルーマピクチャサイズを決定するために、Table A-1を使用することができる。

【0173】

ブロック495において、処理400'は、デコーダがビットストリームを復号することが可能かどうかを決定するステップを伴い得る。決定された要因に応じて、処理400'は、解像度の合計またはビットストリームのレイヤの数のいずれかを使用して、デコーダ能力を決定するステップを伴い得る。能力がこれらの要因からどのように決定されるかに関するさらなる情報が、本明細書において開示される。

【0174】

処理400'は、ブロック496において終了する。実装形態によっては、ブロックが処理400'において追加および/または省略されることがあり、かつ具体的な実装形態によっては、処理400'のブロックは異なる順序で実行されることがある。

【0175】

規模の加算は、デコーダ能力がより正確に定義されることを可能にし得る、幅広い有用な情報を与え得る。たとえば、既存のレベル定義を使用すると、720pの解像度の5つ以上のSNRレイヤ(または等価な数のルーマピクセル、たとえば組み合わされた空間レイヤおよびSNRレイヤを伴うより多くのレイヤ)が復号されることになる場合、レベル5以上のデコーダが必要とされる。その結果、ルミナンスCTBサイズは32×32または64×64に等しく、これは、16×16のようなより小さなCTBサイズが使用され得ないので、解像度720p以下に対して最適ではないコーディング効率をもたらし得る。しかしながら、規模をレベル4デコーダと関連付けることによって、いくつかのレベル4デコーダが720pの解像度の4つのSNRレイヤを復号するのに適していることが、明確に決定される。これは、32×32よりも小さなCTBサイズの使用を可能にし、コーディング効率の改善をもたらし得る。

【0176】

別の例では、4つのシングルレイヤHEVCレベル3.1デコーダからなるカテゴリIIデコーダ(すなわち、複数の既存のシングルレイヤデコーダを再使用することによって製造されるもの)は、既存のレベル定義によれば、720pの4つのSNRレイヤを復号するためにレベル4以上に適合しなければならない。この定義により、デコーダは任意のレベル4ビットストリームを復号することが可能でなければならない。しかしながら、デコーダハードウェアへの変更がなければ、そのようなデコーダは、1080pの解像度の2つのSNRレイヤを伴うSHVCレベル4ビットストリームを復号することが可能ではないであろう。この問題は、レベル定義の変更により、特に、レベルと関連付けられる規模の加算、さらにはデコーダ能力の要件の変更により解決される。これらの変更の結果として、720pの解像度の4つのSNRレイヤを伴うビットストリームを復号することが可能な適合するデコーダは、1080pの解像度の2つのSNRレイヤを伴うビットストリームを復号することが可能であることを要求されない。

【0177】

既存のHEVCレベル定義により引き起こされる別の例示的な問題は、1080pのシングルレイヤHEVCビットストリームと720pの2レイヤSHVCビットストリームの両方を復号することが可能であるような方法で実装されるデコーダが、レベル3.1として分類されるということである。しかしながら、レベル3.1という分類は、1080pのシングルレイヤビットストリームを復号する能力を表さない。この問題は、規模をデコーダと関連付けて、上で説明されたようなデコーダ能力をさらに定義することによって解決される。具体的には、レベル3.1デコーダは2という規模と関連付けられ、これは、1080pの単一のレイヤを伴うビットストリームと、720pの2つのレイヤを伴うビットストリームとの両方を復号するための能力を伝える。

【0178】

別の例では、既存のレベル定義によれば、720pの4つのSNRレイヤを復号することが可能であるように4つのシングルレイヤHEVC 3.1デコーダを使用して実装されるデコーダについて、そのデコーダはレベル4以上に適合しなければならない。したがって、デコーダは、4つ以上のタイル行と4つ以上のタイル列とを有するビットストリームを復号することが可能であることを要求され、各タイルは256個のルーマサンプルの幅と144個のルーマサンプルの高さとを有する。しかしながら、デコーダのレベル3.1の制限により、一部のそのようなビットストリームを復号することが可能ではない。この問題は、説明されたデコーダがレベル3.1に適合し、4という関連する規模を有するが、レベル4および1という規模に適合しないような、上で説明されたようなレベル定義の変更およびデコーダ能力の要件の変更によって解決される。したがって、レベル3.1に対するタイル行およびタイル列の数に対する既存の制約が(レベル4に対するそれらの代わりに)適用される。

【0179】

カテゴリIIは、既存のデコーダハードウェアコアを再使用することによって実装されるので、2つのデコーダハードウェアコアにより任意の単一のピクチャを合同で復号することは、デコーダ能力の定義における制約により許可されてはならない。これは、図5A〜図5Bおよび図6A〜図6Bにおいて示される。

【0180】

図5Aは、本開示において説明される態様に従って、例示的なマルチレイヤビットストリームを示し、ビットストリームは、レイヤ0(510における)がQuad High-Definition(QHD)(960×540)であり、レイヤ1(511における)、2(512における)、3(513における)、および4(514における)がHigh-Definition(HD)(1080p)である、5レイヤのSHVCビットストリームである。

【0181】

図5Bは、本開示において説明される態様による、図5Aのマルチレイヤビットストリームを復号するための複数の例示的な選択肢を示す。本実施形態では、選択肢1(521における)は5つのレベル4.0デコーダコアを使用することを表し、各デコーダコアがビットストリームの1つのレイヤを復号する。選択肢2(522における)は、4つのレベル4.0デコーダコアを使用してすべての5つのレイヤを復号することを表す。この選択肢は、auSizeInSamplesYの制約(auSizeInSamplesY < 4*MaxLumaPs)に基づくカテゴリIデコーダを使用して、可能である。デコーダコアは、1つの完全なレイヤと1つの部分的なレイヤとを復号する。しかしながら、これはカテゴリIIデコーダ(既存のデコーダハードウェアコアを変更することなく再使用することによって実装されるもの)を使用すると、可能ではない。選択肢3(523における)は、4つのレベル5.0対応デコーダコアを使用することを表す。この選択肢では、デコーダコアは整数個の完全なレイヤを復号する。この選択肢は、いずれのカテゴリのデコーダを使用しても可能である。

【0182】

図6Aは、本開示の態様による、別の例示的なマルチレイヤビットストリームを示す。本実施形態では、ビットストリームは、レイヤ0〜4(610〜614)がExtended Graphics Array(XGA)(960×540)である5レイヤのSHVCビットストリームである。ビットストリームはSNRスケーラビリティを表す(すなわち、すべてのレイヤが同じ解像度を有する)。

【0183】

図6Bは、本開示の態様による、図6Aのマルチレイヤビットストリームを復号するための複数の例示的な選択肢を示す。本実施形態では、選択肢1(621における)は5つのレベル3.1デコーダコアを使用することを表し、各デコーダコアがビットストリームの1つのレイヤを復号する。選択肢2(622における)は、4つのレベル3.1デコーダコアを使用してすべての5つのレイヤを復号することを表す。図5Bを参照して上で論じられた理由で、この選択肢は、カテゴリIデコーダに対しては利用可能であるが、カテゴリIIデコーダに対しては利用可能ではない。

【0184】

本開示のいくつかの実装形態は、1つまたは複数の復号ピクチャバッファ(DPB)を含み得る。各DPBはさらに、複数のサブDPBを含み得る。DPBおよびサブDPBは、データを記憶し移送するように構成され得る。いくつかの実装形態では、DPBおよび/またはサブDPBに関する、複数のサイズに関連する制約が定義され得る。そのような制約は、解像度の数字、ルーマピクチャサイズ、クロマピクチャサイズ、コーディングされたピクチャバッファのサイズ、ピクチャ当たりのスライスセグメント、タイル行の数、列の数などのような、種々の要因に基づき得る。さらに、サイズに関連する制約は、ビットストリームの個々のレイヤのために、さらには一般にはサブDPBのために指定され得る。たとえば、あるサイズに関連する制約はビットストリームの各レイヤのために指定されてよく、別のサイズに関連する制約は各サブDPBのために指定されてよい。

【0185】

加えて、CPBサイズに対するビットストリーム固有の制約は、レイヤの数に対してスケーラブルな方法で指定され得る。このようにして、多数のレイヤがあるときに、改善された高いピクチャ品質が達成され得る。HEVCテキストのA.4.2項における項目b、c、d、g、h、i、およびjに対応するビットストリーム固有の制約は、レイヤの数に対してスケーラブルである方法で指定される。

【0186】

本開示の実施形態はまた、出力レイヤセットのビットストリームまたはサブビットストリーム中のレイヤの数の値をシグナリングするための、システムおよび方法を提供する。このシグナリングは、ISOメディアファイルフォーマット、RTPペイロードフォーマットのメディアタイプパラメータ、セッション記述プロトコル(SDP)パラメータ、Dynamic Adaptive Streaming over HTTP(DASH)コンテンツのMedia Presentation Description(MPD)におけるMPDパラメータなどに従った、ファイルのサンプル記述におけるパラメータによって達成され得る。

【0187】

さらに、いくつかの実施形態は、ビットストリーム中の出力レイヤセットのビットストリームまたはサブビットストリーム中のすべてのレイヤに対して、ルーマサンプルの数の合計の値をシグナリングするためのシステムおよび方法を提供することができる。このシグナリングは、たとえば、ISOメディアファイルフォーマット、RTPペイロードフォーマットのメディアタイプパラメータ、SDPパラメータ、または、DASHコンテンツのMPDにおけるMPDパラメータに従った、ファイルのサンプル記述におけるパラメータによって達成され得る。

【0188】

本明細書で開示された実施形態に関して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、全般にそれらの機能に関して上で説明された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、具体的な適用例およびシステム全体に課されるおよび設計上の制約に依存する。当業者は、説明された機能を具体的な適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を生じさせるものと解釈されるべきではない。

【0189】

本明細書で説明された技術は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスのような、様々なデバイスのいずれかにおいて実装され得る。モジュールまたはコンポーネントとして説明された任意の特徴が、集積論理デバイス内で一緒に、または個別であるが相互動作可能な論理デバイスとして別々に実装され得る。ソフトウェアで実装された場合、本技法は、実行されると上で説明された方法の1つまたは複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含み得るコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリ、磁気または光学データ記憶媒体などのような、メモリまたはデータ記憶媒体を備え得る。本技法は、追加または代替として、伝搬される信号または波のような、命令またはデータ構造の形態でプログラムコードを搬送または伝達し、コンピュータによってアクセスされ、読み取られ、かつ/または実行され得る、コンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。

【0190】

プログラムコードは、1つまたは複数のDSPなどの1つまたは複数のプロセッサ、汎用マイクロプロセッサ、ASIC、FPGA、または他の等価の集積回路もしくはディスクリート論理回路を含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明された技法のいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替的に、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。したがって、本明細書で使用される「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明される技法の実装に適した他の構造もしくは装置のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用のソフトウェアモジュールもしくはハードウェアモジュール内で提供されてよく、または複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれてよい。

【0191】

本明細書で論じられるコーディング技法は、例示的なビデオ符号化および復号システムにおける実施形態であり得る。システムは、宛先デバイスによって後で復号されるべき符号化されたビデオデータを提供するソースデバイスを含む。具体的には、ソースデバイスは、コンピュータ可読媒体を介して宛先デバイスにビデオデータを提供する。ソースデバイスおよび宛先デバイスは、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。いくつかの場合、ソースデバイスおよび宛先デバイスは、ワイヤレス通信に対応し得る。

【0192】

宛先デバイスは、コンピュータ可読媒体を介して、復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体は、ソースデバイスから宛先デバイスに符号化されたビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。1つの例では、コンピュータ可読媒体は、ソースデバイスが符号化されたビデオデータをリアルタイムで宛先デバイスに直接送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイスに送信され得る。通信媒体は、高周波(RF)スペクトルまたは1つもしくは複数の物理伝送線路のような、任意のワイヤレスまたは有線の通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワークのようなパケットベースネットワーク、またはインターネットのようなグローバルネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイスから宛先デバイスへの通信を支援するために有用であり得る任意の他の機器を含み得る。

【0193】

いくつかの例では、符号化されたデータは、出力インターフェースから記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェースによって、記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、DVD、CD-ROM、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、種々の分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる例では、記憶デバイスは、ソースデバイスによって生成された符号化されたビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイスは、ストリーミングまたはダウンロードを介して記憶デバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイスに送信することが可能な、任意のタイプのサーバであり得る。例示的なファイルサーバは、ウェブサーバ(たとえば、ウェブサイトのための)、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイスは、インターネット接続を含む、任意の標準的なデータ接続を通じて符号化されたビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに好適である、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。

【0194】

本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、dynamic adaptive streaming over HTTP(DASH)のようなインターネットストリーミングビデオ送信、データ記憶媒体に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例のような、種々のマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システムは、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

【0195】

一例では、ソースデバイスは、ビデオソースと、ビデオエンコーダと、出力インターフェースとを含む。宛先デバイスは、入力インターフェースと、ビデオデコーダと、ディスプレイデバイスとを含み得る。ソースデバイスのビデオエンコーダは、本明細書で開示される技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは構成を含み得る。たとえば、ソースデバイスは、外部のカメラのような外部のビデオソースからビデオデータを受信し得る。同様に、宛先デバイスは、統合されたディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースし得る。

【0196】

上の例示的なシステムは一例にすぎない。ビデオデータを並列に処理するための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。本開示の技法は一般にビデオ符号化デバイスによって実行されるが、本技法は、通常は「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法は、ビデオプロセッサによっても実行され得る。ソースデバイスおよび宛先デバイスは、宛先デバイスへ送信するためのコーディングされたビデオデータをソースデバイスが生成するような、コーディングデバイスの例にすぎない。いくつかの例では、ソースデバイスおよび宛先デバイスは、デバイスの各々がビデオ符号化および復号コンポーネントを含むように、実質的に対称的な方式で動作し得る。よって、例示的なシステムは、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話のために、ビデオデバイス間の一方向または双方向のビデオ送信をサポートし得る。

【0197】

ビデオソースは、ビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、および/または、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースのような、ビデオキャプチャデバイスを含み得る。さらなる代替形態として、ビデオソースは、ソースビデオ、または、ライブビデオ、アーカイブされたビデオ、およびコンピュータにより生成されたビデオの組合せとして、コンピュータグラフィックスベースのデータを生成することができる。いくつかの場合、ビデオソースがビデオカメラである場合、ソースデバイスおよび宛先デバイスは、いわゆるカメラ電話またはビデオ電話を形成し得る。上で言及されたように、しかしながら、本開示で説明される技法は、ビデオコーディング全般に適用可能であってよく、ワイヤレスおよび/または有線の適用例に適用され得る。各々の場合において、キャプチャされたビデオ、事前にキャプチャされたビデオ、またはコンピュータにより生成されたビデオは、ビデオエンコーダによって符号化され得る。符号化されたビデオ情報は次いで、コンピュータ可読媒体へと出力インターフェースによって出力され得る。

【0198】

述べられたように、コンピュータ可読媒体は、ワイヤレスブロードキャスト送信もしくは有線ネットワーク送信のような一時的媒体、または、ハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、もしくは他のコンピュータ可読媒体のような、記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示されず)は、ソースデバイスから符号化されたビデオデータを受信し、符号化されたビデオデータを、たとえばネットワーク送信を介して宛先デバイスに提供することができる。同様に、ディスクスタンピング施設のような、媒体生産施設のコンピューティングデバイスは、ソースデバイスから符号化されたビデオデータを受信し、符号化されたビデオデータを含むディスクを生産することができる。したがって、コンピュータ可読媒体は、様々な例において、様々な形式の1つまたは複数のコンピュータ可読媒体を含むと理解され得る。

【0199】

宛先デバイスの入力インターフェースは、コンピュータ可読媒体から情報を受信する。コンピュータ可読媒体の情報は、ブロックの特性および/または処理ならびに他のコーディングされたユニット、たとえばピクチャグループ(GOP)を記述するシンタックス要素を含む、ビデオデコーダによっても使用される、ビデオエンコーダによって定義されるシンタックス情報を含み得る。ディスプレイデバイスは、復号されたビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスのような、種々のディスプレイデバイスのいずれかを備え得る。本発明の様々な実施形態が説明されてきた。

【符号の説明】

【0200】

10 ビデオコーディングシステム
11 デバイス
12 ソースデバイス
13 プロセッサ/コントローラデバイス
14 宛先デバイス
16 リンク
18 ビデオソース
20 ビデオエンコーダ
21 ビデオ処理ユニット
22 出力インターフェース
23 ビデオエンコーダ
28 入力インターフェース
29 トラッカー
30 ビデオデコーダ
31 記憶デバイス
32 ディスプレイデバイス
33 ビデオデコーダ
90 リサンプリングユニット
92 アップサンプリングユニット
94 ダウンサンプリングユニット
98 マルチプレクサ
99 デマルチプレクサ
100 予測処理ユニット
102 残差生成ユニット
104 変換処理ユニット
106 量子化ユニット
108 逆量子化ユニット
110 逆変換ユニット
112 再構築ユニット
113 フィルタユニット
114 復号ピクチャバッファ
116 エントロピー符号化ユニット
121 インター予測ユニット
122 動き推定ユニット
124 動き補償ユニット
126 イントラ予測ユニット
128 レイヤ間予測ユニット
150 エントロピー復号ユニット
152 予測処理ユニット
154 逆量子化ユニット
156 逆変換ユニット
158 再構築ユニット
159 フィルタユニット
160 復号ピクチャバッファ
162 動き補償ユニット
164 イントラ予測ユニット
166 レイヤ間予測ユニット
400 方法
400' 方法
510 レイヤ0
511 レイヤ1
512 レイヤ2
513 レイヤ3
514 レイヤ4
521 選択肢1
522 選択肢2
523 選択肢3

【図1A】

【図1B】

【図2A】

【図2B】

【図3A】

【図3B】

【図4A】

【図4B】

【図5A】

【図5B】

【図6A】

【図6B】