JP5738434B2

JP5738434B2 - 改善されたｎａｌユニットヘッダ

Info

Publication number: JP5738434B2
Application number: JP2013549495A
Authority: JP
Inventors: ダニー・ホン; ジル・ボイス; ウォン・カプ・ジャン; シュテファン・ウェンガー
Original assignee: ヴィディオ・インコーポレーテッド
Priority date: 2011-01-14
Filing date: 2012-01-10
Publication date: 2015-06-24
Anticipated expiration: 2032-01-10
Also published as: AU2012205650A1; JP2014504118A; CN103416003B; EP2664075A4; US20120269276A1; CA2824741A1; AU2012205650B2; CA2824741C; WO2012096981A1; US20120183077A1; EP2664075A1; US8649441B2; CN103416003A

Description

関連出願の相互参照
本出願は、2011年1月14日に出願された米国仮特許出願第61/432,836号「Improved NAL Unit Header for Supporting Quality/Spatial Scalability」の優先権を主張するものであり、その開示全体を参照により本明細書に組み込む。

本出願はビデオ圧縮システムに関し、より詳細には、所与のビデオ信号を表すために2つ以上のレイヤが使用される、スケーラブル/同時放送/マルチビュービデオ符号化技法を使用するシステムに関する。

いくつかの商業用ビデオ圧縮技法は、ベンダー間の相互運用性を可能にするために、ビデオ符号化規格を使用することができる。本開示は、このようなビデオ符号化規格、特に、国際電気通信連合(「ITU」)、Place des Nations、CH-1211 Geneva 20、Switzerland、またはhttp://www.itu.int/rec/T-REC-H.264から入手可能な、ITU-T Rec. H.264、「Advanced video coding for generic audiovisual services」、2010年3月で使用でき、その全体を参照により本明細書に組み込む。

H.264の最初のバージョンは2003年に批准されており、たとえば、時間スケーラビリティを可能にする、柔軟な参照画像選択モデルなどの符号化ツールを含んでいた。2007年に批准された後続のバージョンは、信号対ノイズ比(SNR)スケーラビリティとしても知られている空間スケーラビリティおよび品質スケーラビリティのための技法を含む、スケーラブルなビデオ符号化(SVC)への拡張を付属書類Gに追加した。2009年に批准された別のバージョンは、マルチビュー符号化(MVC)を付属書類Hに含んだ。

H.264の初期のバージョンは、後のバージョンの要件を特に考慮せずに設計された。これは、たとえば、ネットワークアダプテーションレイヤ(NAL:Network Adaptation Layer)ユニットヘッダの設計に、いくつかの特定のアーキテクチャの弱点をもたらし、そのうちのいくつかは本開示の主題によって対処されている。開示全体を参照により本明細書に組み込む、2012年1月4日に出願された同時係属中の米国特許出願第13/343,266号「High Layer Syntax for Temporal Scalability」は、少なくとも時間スケーラビリティのシグナリングにおける潜在的な弱点に対処しており、開示全体を参照により本明細書に組み込む、2012年3月10日に出願された同時係属中の米国仮特許出願第61/451,454号「Dependency Parameter Set for Scalable Video Coding」は、少なくともレイヤ依存性のシグナリングに関連する潜在的な弱点に対処している。

H.264では、ビットストリームがNALユニットに論理的に細分される。それぞれの符号化された画像は、1つまたは複数のスライスNALユニットに符号化される。他の多くのNALユニットカテゴリも、たとえばパラメータセット、SEIメッセージなどの異なるデータのタイプについて定義される。場合によっては、NALユニットは、NALユニットの損失は、他のNALユニットの有意義な復号および使用を妨げる可能性がないという点で「構文解析非依存」でもよい。したがって、NALユニットは、パケット損失を被るパケットネットワークのパケットに配置されうる。この使用ケースは、MPEG-2(ITU-T Rec. H.262「Information technology-Generic coding of moving pictures and associated audio information:Video」、2000年2月、http://www.itu.int/rec/T-REC-H.262から入手可能であり、MPEG-2ビデオとしても知られており、参照により本明細書に組み込む)などの、初期のビデオ圧縮規格から知られているビットストリーム概念よりもNALユニット概念を導入する動機のうちの1つである。

本開示全体を通じて、H.264で指定された協約に従ってシンタックステーブル図が使用されている。それらの協約を簡単に要約するために、C言語スタイルのテーブル記法が使用される。太字の文字列は、ビットストリームからフェッチしたシンタックス要素を指す(たとえば、開始コードまたはパケットヘッダによって分離されたNALユニットから構成されうる)。シンタックス図表の「記述子」の列は、データのタイプの情報を提供する。たとえば、u(2)は、2ビット長の符号なし整数を指し、f(1)はあらかじめ定められた値の単一のビットを指す。

図1は、ベースラインH.264のNALユニットヘッダ、ならびにSVCおよびMVC拡張を示している。ベースラインNALユニットヘッダは、NALユニットシンタックス仕様の一部であり、本開示を曖昧にしないためにいくつかの部分が省略された(101)に示されている。特に、NALユニットヘッダは、forbidden_zero_bit(102)、復号処理(nal_ref_idc、103)のためのNALユニットの相対的重要性を示す2つのビット、およびNALユニットタイプ(104)を示す5つのビットを含む。特定のNALユニットタイプ、if()命令文(105)によって示される、スケーラブルかつマルチビュー符号化のスライスタイプとして定義された、すなわちタイプ14および20では、svc_extension_flagによって示されるように(107)、さらなるsvc_extension_flag_bit(106)、ならびにnal_unit_header_svc_extension()(108)かnal_unit_header_mvc_extension()(109)のどちらか(107)が含まれる。

nal_unit_header_svc_extension()のC言語関数スタイル参照およびnal_unit_header_mvc_extension()は、それぞれSVC NALユニットヘッダ拡張(110)およびMVC NALユニットヘッダ拡張(120)として示されるシンタックステーブルを指している。

本開示の文脈で特に関連するSVC NALユニットヘッダ拡張(110)は、以下のフィールドである。

priority_idフィールド(111)は、エンコーダによって決定されるように、同じスケーラブルなビットストリームの他のレイヤに関連するレイヤの相対的重要性を線形に信号伝達するために使用でき、レイヤは時間的、空間的、またはSNRスケーラブルレイヤのいずれでもよい。依存レイヤは、自身が依存するレイヤよりも高いpriority_idを有する。priority_idはH.264復号処理定義によっては使用されないが、たとえば、特定のレイヤ(そのレイヤが、レイヤ階層において、高いpriority_id値を有するNALユニットが属するレイヤよりも下位の場合)を復号するために必要ではないNALユニットを識別するために、デコーダまたはメディアアウェアネットワーク要素(MANE:Media-Aware Network Element)によって使用されうる。H.264は、dependency_id、quality_id、およびtemporal_idの値に基づいて、その値の特定の制約を指定する。

no_inter_layer-Pred_flag(112)は、NALユニットが属しているレイヤは、予測するために他のどのレイヤも参照しないことを示している。所与のレイヤのすべてのNALユニットについて設定した場合、このフラグは、レイヤが他のどのレイヤとも関係なく復号されうることを示すことができ、同時放送などの技法を可能にする。

dependency_id field(113)は、NALユニットが属する空間レイヤまたは粗粒度SNRスケーラブルレイヤを示しており、値が大きいほど、レイヤはより上位になる。quality_idおよびtemporal_idは、SNRスケーラブルおよび時間スケーラブルレイヤの同様の特性を示している。

MVC NALユニット拡張ヘッダ(120)は、以下の関連フィールドを含む。

priority_id(121)およびtemporal_id(123)は、SVCヘッダpriority_id(111)およびtemporal_id(115)フィールドについて上述したものと同様の意味を有する。view_idはマルチビューシステムの1024個までの「ビュー」のうちの1つを識別し、それは、たとえば異なるカメラから、3次元スペースで同じシーンをキャプチャする異なる幾何学的位置で符号化された信号でもよい。MVCによって、予測によって除去されうる冗長性がビュー間に存在しうるという観察に基づいて、ビュー間予測が可能になる。

H.264のスケーラブルな拡張の仕様の間の1つの目標は、スケーラブルな拡張の批准以前に設計された従来のデコーダによって、たとえばH.264の2003バージョンの任意のプロファイルに準拠したデコーダによって、スケーラブルなベースレイヤを復号することができるようにすることである。この理由および他の理由で、後方互換性のない変更は、ベースレイヤシンタックスに導入されていない。しかし、スケーラブルな符号化コンテキストにおけるベースレイヤ復号に関する、またはそれに影響を及ぼす、一定の制御情報がある場合があるので(すなわち、少なくとも1つの強化レイヤとともに)、それは分離してベースレイヤの復号の文脈で必要とされないことがあり、したがって、たとえばH.264の2003バージョンに含まれていない。この情報の一部は、MVCにも関連しうる。このカテゴリーの情報のシンタックスは、たとえば後述するメカニズムによって、H.264のスケーラブルな拡張に追加された。

第1のメカニズムは、スケーラブルな、またはマルチビュー符号化に属するスライスデータへの異なるNALユニットタイプの使用であり、既に記述したように、NALユニットヘッダにおいてさらなるフィールドの存在をトリガしうる。

第2のメカニズムは、プリフィックスNALの導入である。プリフィックスNALは以前に確保したNALユニットタイプのうちの1つを使用し、これは確保されたタイプを認識しない従来のデコーダはその内容を無視するが、スケーラブルな、またはマルチビューデコーダはその内容を解釈することができることを意味する。プリフィックスNALユニット(201)のシンタックスは、図2に示されている。NALユニットは、とりわけ、およびさらなる条件が満たされる場合のみ、情報(203)をマーキングする基本画像の存在を示す、store_ref_base_pic_flag(202)を含みうる。このような情報の正確な性質は本開示に特に関係ないかもしれないが、その内容はスケーラブルな復号状況における復号処理に必要である。

第3のメカニズムは、スケーラビリティ情報SEIメッセージとして知られている。H.264に定義された補助的拡張情報(SEI:Supplementary Enhancement Information)メッセージは、復号処理に必要な情報を含むべきではないが、デコーダに役立つ情報であるMANE、または、レンダリングなどの全体的なシステムレイアウトの他の部分を対象とする。

スケーラビリティ情報SEIメッセージは、そのレイヤの記述、レイヤ間依存性などの態様を含む、スケーラブルなビットストリームの記述と見なすことができる。H.264仕様におけるSEIメッセージのシンタックステーブルは、約2ページ長である。本開示に関連するいくつかの部分は、図3で再現される。スケーラビリティ情報SEIメッセージ(301)は、スケーラブルなビットストリーム(すなわち、全てのレイヤ)に関係するいくつかのフラグを含み、レイヤの数を示す整数(302)が続く。レイヤごとに、以下のフィールドが利用可能である。

layer_id(303)フィールドは、レイヤの識別を提供する。layer_id(303)フィールドは、たとえば、レイヤと、示されていないSEIメッセージの一部に配置される他のレイヤ記述(たとえば、レイヤ間依存性記述など)とを相互参照するために使用されうる。たとえば、SEIメッセージ内の依存レイヤとそれが依存するレイヤとの間の結合は、layer_idを通じて確立される。

priority_id(304)、dependency_id(305)、quality_id(306)、およびtemporal_id(307)のフィールドは、同じ名前を有するSVC NALユニットヘッダフィールドの文脈で既に記述した意味と類似する意味を有する。

すべての3つのメカニズムは、H.264の非スケーラブルバージョン(2007年以前に批准されたバージョン)への「追加」として記述されうる。後方互換性を維持しながら、この設計は一般的にエレガント(elegant)と特徴付けされず、スケーラブル拡張のNALユニットおよび画像に不要に高いオーバーヘッドを引き起こすことがあり、誤り耐性の問題を有することがある。

不要に高いオーバーヘッドの例として、H.264のバイトストリームシンタックスを使用する際、ビットストリーム内の所与のNALユニットのオーバーヘッドは、開始コードについて少なくとも4オクテットである。同様に、IPネットワークを使用してNALユニットをそれ自体のパケット内に配置する際、オーバーヘッドは40オクテット以上(TPヘッダ用に12オクテット、UDPヘッダ用に8オクテット、およびRTPヘッダ用に20オクテット)でもよい。集約技法ならびにヘッダ圧縮技法は、そのオーバーヘッドをある程度まで減らすことができるが、オーバーヘッドをさらに減らすこと、および/または完全に回避することが好ましい。

誤り耐性に関して、図4はビデオ会議システムの簡略化されたブロック図を示している。エンコーダ(401)は、複数のレイヤに属するNALユニットを備えるスケーラブルなビットストリーム(402)を生成することができる。ビットストリーム(402)は、一定のビットレートを有することを示すために太線で示されている。ビットストリーム(402)は、ネットワークリンクを介してメディアアウェアネットワーク要素(MANE)(403)に転送されうる。MANE(403)機能は、たとえば最上位のレイヤに属するそれらのNALユニットを選択的に除去することによって、第2のネットワークリンクによって提供される一定のビットレートにまでビットストリームを「低減する(prune)」ことができる。これは、MANE(403)からデコーダ(405)に送信されるビットストリーム(404)の点線によって示されている。スケーラブルなビットストリーム(402)がベースレイヤおよび1つの強化レイヤのNALユニットだけを含む場合、除去後、ビットストリーム(404)はベースレイヤのNALユニットだけを含む。デコーダ(405)は、MANE(403)から除去されたビットストリーム(404)を受信して、復号およびレンダリングすることができる。

このようなアプリケーションでは、接続の非常に初期、理想的には、任意のレイヤの任意の符号化されたスライスNALユニットがビットストリーム(402)内のMANEによって受信される以前の、MANEでのスケーラビリティ情報SEIメッセージの潜在的な利用不可能性は、デコーダの振舞いに負の結果をもたらす、および/またはデコーダの実装に不要な高コストを発生させる場合がある。たとえば、スケーラビリティ構造(たとえば、レイヤの数およびそれらの依存性)を知らずに、MANE(403)は受信するすべてのNALユニットを転送する必要がある場合があり、デコーダ(405)は受信するすべてのNALユニットをバッファして、可能な限り、受信するすべてのNALユニットを、レンダリングするために使用しないNALユニットまでも復号する必要がある場合がある(たとえば、それらはハンドヘルドデバイスのディスプレイよりも解像度の高い空間レイヤに属するので)。同様に、MANE(403)は、複雑度の高い(レイヤが多い)スケーラブルなビットストリームを受信すると、機能が限られているデコーダにどのNALユニットを転送するべきかを決定するのが大いに困難であるが、受信するデコーダは非スケーラブルなビットストリームまたは複雑性の低い(レイヤがわずかである)スケーラブルなビットストリームだけを処理することができることを知っている。スケーラビリティ情報SEIメッセージを含むSEIメッセージは、たとえばビットストリーム(402)を送信する間に失われたために、または、メッセージのビットを節約するためにエンコーダ(401)がSEIメッセージを送信しないと決定したために利用できない場合がある(アプリケーション設計の観点からは望ましくないが、規格に準拠している)。

また、MANEは、除去について十分な情報に基づいた決定を下すために、特にスケーラビリティ情報SEIメッセージの内容に関して、状況を維持する必要がある。このような状況は、すべてのこのようなSEIメッセージを遮断して解釈することによってのみ確立されうる。ほとんどのMANEは、有意義な決断を下すために、パラメータセット情報などのいくつかのビットストリーム情報の遮断および解釈を必要とするが、MANEに対して何らかの意味を有するのは多数のSEIメッセージのうちの非常にわずかである。MANEに対して有意義である、それらのわずかなものを抽出して解釈するためだけにすべてのSEIメッセージを遮断することは、煩わしく、コンピュータコストの高い処理になる場合がある。

要するに、NALユニットヘッダに関連するH.264のスケーラブルおよびマルチビューシンタックスは、スケーラブルおよびマルチビュー拡張の「追加」設計の結果、いくつかの潜在的な弱点を含む。第1に、拡張ヘッダのNALユニットのNALユニットヘッダが不要に大きい場合がある。画像バッファ管理に関する情報が、それ自体のNALユニット(プリフィックスNALユニット)に送信され、不要に高いオーバーヘッドを引き起こす場合がある。さらに、特定のアプリケーションにとって重要な情報(スケーラビリティ情報SEIメッセージで搬送される情報など)がSEIメッセージ内で搬送され、それは(a)重大な性質を反映せず(SEIが廃棄されうる)、(b)たとえばNALユニットヘッダ(dependency_id、quality_id、view_idなど)内のいくつかの情報の不要な複製を必要とする場合がある。

近年、高効率ビデオコーディング(HEVC)が標準化のために考慮されている。以下で「WD4」と呼ばれるHEVCの作業草案は、(http://wftp3.itu.int/av-arch/jctvc-site/2011_07_F_Torino/から入手可能な、B. Brossら、「WD4:Working Draft 4 of High-Efficiency Video Coding」)で見つけることができ、これは参照により本明細書に組み込まれている。HEVCは、H.264の多くの高位のシンタックス特徴を受け継ぐ。規格が批准される前に、上記のH.264の潜在的な弱点が対処されていれば、HEVCの成功のために有利でありうる。

米国特許出願第13/343,266号米国仮特許出願第61/451,454号米国特許出願第61/451,454号

ITU-T Rec. H.264、「Advanced video coding for generic audiovisual services」、2010年3月 ITU-T Rec. H.262、「Information technology-Generic coding of moving pictures and associated audio information:Video」、2000年2月 B. Brossら、「WD4:Working Draft 4 of High-Efficiency Video Coding」

開示された主題は、H.264またはWD4に記述されるものよりも効率的になることができ、軽量なMANEおよびデコーダの実装を可能にする、NALユニットヘッダを提供する。依存性パラメータセット(DPS)などの他の技法とともに、同時係属中の米国仮特許出願第61/451,454号に記述されるように、また本出願と同時に出願され、共通の譲受人に譲渡され、その開示を参照により本明細書に組み込む、本出願人の同時係属中の特許出願「Techniques for Layered Video Encoding and Decoding」に記述されるように高位のシンタックスアーキテクチャに組み込まれるように、開示された主題は、上述の潜在的な弱点を克服することができる。

実施形態では、NALユニットヘッダはlayer_idを含む。たとえばlayer_idは、たとえば6ビットの整数によって表されうる。layer_idは、レイヤ記述のテーブル内に配置されたレイヤ記述を指すことができる。

同じまたは別の実施形態では、レイヤ記述のテーブルは依存性パラメータセット、または依存性パラメータセットに実質的に類似する目的を果たす高レベルシンタックス構造に含まれる。

同じまたは別の実施形態では、NALユニットヘッダ内のlayer_idと呼ばれるレイヤの記述は、dependency_id、quality_id、view_id、depth_map_flag、およびdependent_flagのうちの少なくとも1つのフィールドを含む。

同じまたは別の実施形態では、depth_map_flagは、関連付けられるレイヤがデプスマップであることを示すことができる。サンプルベースごとに、サンプルの第3次元(深度)をビューとともに示すことができるデプスマップとの関連は、view_idを使用して確立されうる。

同じまたは別の実施形態では、NALユニットヘッダはtemporal_idおよびlayer_idを含む。temporal_idは、layer_idによって参照される記述によって定義される(spatial/quality/view/depth-map)レイヤの時間サブレイヤを指すことができる。概念的に、これは、layer_idを割り当てたという点でレイヤとは見なされない時間レイヤをもたらし、現在開発中のHEVCバージョン1が時間的スケーラビリティを可能にするが、空間/品質スケーラビリティまたはマルチビュー特性を可能にしないと予測される点で、HEVCのアーキテクチャにマッピングする。

同じまたは別の実施形態では、layer_idの1つのあらかじめ定められた値が拡張メカニズムのために確保される。

同じまたは別の実施形態では、layer_idは、H.264におけるpriority_idの共通使用(しかし表現、制約、または導出メカニズムではない)と異なることなく、レイヤ階層内のレイヤの位置の表示としての機能をともに果たすことができる。

同じまたは別の実施形態では、NALユニットヘッダは、store_ref_base_pic_flag、およびuse_ref_base_pic_flagのうちの少なくとも1つを含む。

同じまたは別の実施形態では、スライスヘッダは、store_ref_base_pic_flag、およびuse_ref_base_pic_flagのうちの少なくとも1つを含む。

同じまたは別の実施形態では、エンコーダは、上述のように、少なくとも1つのNALユニットヘッダを作成することができる。

同じまたは別の実施形態では、MANEまたはデコーダは、layer_idがレイヤ階層内のレイヤの位置を示すことができることを考慮して、layer_idに基づいてスケーラブルなビットストリームを除去することができる。

H.264による、NALユニットヘッダおよび拡張のシンタックス図である。 H.264による、プリフィックスNALユニットのシンタックス図である。 H.264による、スケーラビリティ情報SEIメッセージのシンタックス図である。エンコーダ、MANE、およびデコーダを備えるビデオ会議システムの概略図である。開示された主題の実施形態による、改良されたNALユニットヘッダのシンタックス図である。レイヤ階層のレイヤによって使用され、レイヤ記述のテーブル内のレイヤの記述を参照する、layer_idおよびtemporal_idの概略図である。開示された主題の実施形態による、改良されたNALユニットヘッダのシンタックス図である。レイヤ階層のレイヤによって使用され、レイヤの記述のテーブル内のレイヤ記述を参照する、layer_idの概略図である。 2レイヤ階層のレイヤの同時放送レイヤによって使用され、レイヤの記述のテーブル内のレイヤ記述を参照する、layer_idの概略図である。 NALユニットヘッダを使用するデコーダの流れ図である。開示された主題の実施形態による、ビデオ符号化のためのコンピュータシステムを示す図である。

図面は、本開示に組み込まれて、本開示の一部を構成する。図面全体を通じて、同じ参照番号および文字は、特に記載のない限り、図示された実施形態の同様の特徴、要素、構成要素、または部分を示すために使用される。さらに、図面を参照して開示された主題を詳細に説明するが、説明は例示的実施形態とともに行われる。

図5は、開示された主題による、NALユニットヘッダ(501)のシンタックス図を示している。NALユニットヘッダは、以下のフラグおよびフィールドを含みうる。

MPEG-2システムなどの特定の多重フォーマットで開始コードエミュレーションを防ぐために、forbidden_zero_bit(502)(たとえば、1ビット長で、0になるよう強制される)が含まれうる。

nal_ref_flag(503)(たとえば、1ビット長)が含まれうる。1に設定されると、フラグは、NALユニットが復号処理に必要であることを示すことができる。このフラグは、MANEおよび/またはデコーダが、復号処理には必要でないNALユニットを識別して、たとえばビットレートおよび/または処理サイクルが不十分な場合に、そのような識別されたNALユニットを廃棄することを可能にすることができる。

nal_unit_type(504)(たとえば、6ビット長)が含まれうる。nal_unit_typeは、NALユニットのタイプを示している。H.264は、割り当てられた24個のユニットタイプのほとんどすべてを使い果たしたので、異なるNALユニットタイプを同じ値のnal_unit_typeに多重化するために特定の拡張メカニズムを必要としている。6ビットフィールドは、最大64個のNALユニットタイプが可能であり、したがって、このような拡張メカニズムの使用を回避するために役立つ。たとえば、NALユニットタイプは、異なるタイプのNALユニットのパラメータセット(依存性パラメータセット、シーケンスパラメータセット、画像パラメータセットなど)、異なるタイプのスライスNALユニット(IDRスライス、Pスライス、Bスライス)、SEIメッセージNALユニットなどを指すことができる。

符号化されたスライス(if()命令文505によって表される)を参照するNALユニットタイプのために、NALユニットヘッダは、NALユニットが属する時間サブレイヤを識別するtemporal_id(3ビット)(506)をさらに含みうる。時間レイヤは、たとえば米国特許出願第13/343,266号に記述されている。また、符号化されたスライスについてのNALユニットヘッダに含まれているのはlayer_id(506)(5ビット)でもよい。

NALユニットヘッダのフィールドは、固定長の整数またはフラグとして示されている。固定長の整数またはフラグの使用は、たとえばNALユニットヘッダをRTPペイロードヘッダとしても使用されうるという点で、実装および仕様の観点から利点を有する。NALユニットヘッダ内のデータの整数またはブール表現はこの観点から好ましい一方で、NALユニットヘッダ情報の他のエントロピー符号化メカニズムを容認しうる他の事項がある。

図6は、改良されたNALユニットヘッダ(601)の使用の例を示している。この例では、NALユニットタイプは1であり、スライスを示している。layer_idは2に設定され、temporal_idは1に設定され、第1の時間強化サブレイヤへの参照を示している。

layer_idは、レイヤ記述(604)のテーブル内の同じlayer_id(603)でエントリを参照する(602)ために使用されうる。layer_id2(603)のエントリでは、dependency_idが1に設定され、quality_idも1に設定される。図示されていないのは、レイヤ間の予測関係を示す情報であり、同時係属中の米国特許出願第61/451,454号(DPS)は、この情報の詳細な記述を含む。この参照(602)は、後述するように、NALユニットヘッダ内のlayer_idとレイヤ記述のテーブル内のlayer_idとの間の論理的参照と、レイヤ間予測関係とを区別するために、断続的な線(punctuated line)で示されている。

レイヤ構造も示されている。0のtemporal_idを有する(図面内の「T0」によって示される)ベースレイヤ(605)は、やはり0のtemporal_idを有する空間強化レイヤ(606)によって予測するために使用される。空間強化レイヤ(606)は、品質強化レイヤ(607)によって参照されている。レイヤ間予測は、太線の矢印(608)および(609)で示されるように、参照する。これらのレイヤ間予測関係の表現は、既に言及したようにレイヤ記述のテーブルにも存在しうる。

layer_id=2(603)によって参照されるレイヤ記述のテーブル内のエントリは、NALユニットのdependency_idおよびquality_idの逆参照がH.264内の目標レイヤを識別するために使用されるのと同じ方法で、dependency_idおよびquality_idの値を通じて品質強化レイヤ(607)を参照する。

T1またはT2で示される(それぞれ、第1および第2の時間強化サブレイヤについて)、多くの時間強化サブレイヤも示されている。たとえば、品質強化レイヤ(607)は2つの時間強化サブレイヤT1(610)およびT2(611)を有する。時間強化サブレイヤおよびそれらのレイヤ間予測関係は、ベースレイヤおよび強化レイヤ、ならびにそれらレイヤ間予測関連を示すために使用される太線とは逆に点線で示されている。temporal_idフィールドは、layer_idによって参照される基本または強化レイヤに(間接的に)基づくtemporal_enhancementサブレイヤを直接参照する。

layer_idは、レイヤ階層における所与のレイヤの位置の表示としてともに役立つ(co-serve)ことができる。例では、レイヤ(605)がlayer_id0を有し、レイヤ(606)がlayer_id1を有し、レイヤ(607)がlayer_id2を有する。レイヤまたはサブレイヤのNALユニットを廃棄する必要があるMANEまたはデコーダ自身は、廃棄されうるレイヤに属するNALユニットを識別することができる。たとえば、MANEまたはデコーダが、レイヤ(606)(layer_id1によって識別される)に属するNALユニットを廃棄する必要があることに気づくと、レイヤ間予測関係(609)を維持することができず、したがって、MANEまたはデコーダは1よりも大きいlayer_id、たとえばlayer_id=2を有するNALユニットも廃棄することができることが明らかである。同じことが、時間サブレイヤに属するNALユニットの除去に関して当てはまる。

図7は、NALユニットヘッダ(701)の異なる設計のシンタックス図を示している。第1のオクテットは、図5に図示および記述されるNALユニットヘッダと類似していてもよい。しかし、第2のオクテットは少なくとも部分的にlayer_id(702)によってポピュレートされるが、temporal_idを省略する。第2のオクテットのゼロまたは複数のビットは、確保済み(reserved)として残ることができ、このような1つのビット(703)が示されている。このような設計では、図8に示されるように、時間レイヤはサブレイヤと見なされないがレイヤと見なされる。レイヤ構造は、図6のレイヤ構造と類似している。しかし、レイヤ記述テーブル(801)はすべての空間、品質、および時間強化レイヤによってポピュレートされる。したがって、テーブル内に現在7つのエントリがある。NALユニットヘッダ(802)は、レイヤ記述テーブル(801)内の1つのエントリ(805)を参照する(804)layer_id(803)を含む。このエントリは、可能であれば他のフィールドの中でdependency_id、quality_id、およびtemporal_idを識別して、すべての空間、品質、および時間次元におけるレイヤを識別する(806)ために使用されうる。既に記述したように、レイヤ記述テーブルは、たとえばview_id、および/またはdepth_map_flagなどの他の次元についてのエントリを含むこともできる。

上述のメカニズムは同時放送もサポートする。本明細書では、同時放送は、図9に示されるように複数のベースレイヤがありうるメカニズムを指す。

レイヤ構造内の複数のベースレイヤをサポートするために、レイヤ間予測のために他のどのレイヤも必要としないそれらのレイヤを識別するためにno_inter_layer_prediction_flagが使用されうる。フラグは、レイヤ記述テーブル内のエントリ内に配置されうる。

図9は2つのレイヤ構造を示している。ベースレイヤ(901)が、品質強化レイヤ(902)による予測のために使用され、ひいては、品質強化レイヤ(902)が、時間強化レイヤ(903)によって参照されている。第2のベースレイヤ(904)は、時間強化レイヤ(905)によって強化されうる。2つのベースレイヤは、たとえばそれらの空間分解能において異なる場合があり、これは同時放送のために1つの使用ケースである。この例では、ベースレイヤ(904)はベースレイヤ(901)よりも高い空間分解能を有するものと仮定される。この例では、時間および品質強化レイヤだけが使用されているので、任意の強化レイヤの空間サイズはそれぞれの(参照した)ベースレイヤと同じであってもよい。その結果、2つの分解能が、異なる時間および/または品質バージョンでスケーラブルな同時放送ビットストリーム内で利用可能である。

レイヤ記述テーブル(906)は、2つのベースレイヤ(902)(904)についてのそれぞれのエントリ(907)(909)、および空間強化レイヤ(903)についてのエントリ(908)でポピュレートされうる。2つのベースレイヤは、1に設定されたno_inter_layer_prediction_flag(910)によって識別され、一方、空間強化レイヤについてのレイヤ記述テーブルエントリでは、(予測のために別のレイヤを必要としうる)no_inter_layer_prediction_flagは0に設定される。

エンコーダは、layer_idに使用される値を制御することができる。例では、1つのベースレイヤがlayer_id0を使用して、その他のベースレイヤがlayer_id16を使用することができるように、エンコーダは、5ビットバイナリ符号化layer_idフィールドによって許可された(例では)番号付け範囲を分割することによってこの制御を行使している。

また、テーブル(909)内の対応するエントリを参照する(914)layer_id(912)を含むNALユニットヘッダ(911)、および選択された時間レイヤ(905)を参照する(915)temporal_id(913)が示されている。

Pre-SVC(pre 2007)NALユニットヘッダシンタックスに関するH.264の、ある潜在的な弱点は、拡張メカニズムがないことである。実施形態では、拡張メカニズムは、あらかじめ定められたlayer_id、たとえばlayer_id31(5ビットバイナリ符号化整数で表すことのできる最も高いlayer_id)を、NALユニットヘッダ情報の少なくとも1つ多いオクテットが続くことの表示として確保することによって追加されうる。この拡張オクテットのシンタックスは、現在は必ずしも定義される必要がない場合がある。拡張の制定以前の標準バージョンに準拠しないデコーダは、たとえば拡張オクテットを無視できる。

H.264の高レベルシンタックスの別の潜在的な弱点は、プリフィックスNALユニットの存在であった。既に記述したように、このNALユニットは2つのフラグuse_ref_base_pic_flag、およびstore_ref_base_pic_flagを含みうる。H.264では、これらのフラグは、中間粒度スケーラビリティ(MGS)として知られる技法のために使用される。HEVCにおけるMGSをサポートするために、ベースレイヤスライスのスライスヘッダ内にこれらのフラグを配置することができる。

use_ref_base_pic_flagは、拡張品質レイヤ画像が、ベースレイヤ画像からのレイヤ間予測を使用して符号化されることを示すことができる。フラグは、ベースレイヤ画像に属するスライスのスライスヘッダ内に配置されうる。

store_ref_base_pic_flagは、現在のベースレイヤ画像を、今後使用する可能性があるので参照画像バッファに格納するためにデコーダを必要とする場合がある。store_ref_base_pic_flagは、参照画像バッファに格納されるべきベースレイヤ画像に属するスライスのスライスヘッダ内に配置されうる。

use_ref_base_pic_flagおよび/またはstore_ref_base_pic_flagは、既に記述したように同様の目的に役立つ、NALユニットヘッダ内のフィールド内に配置されてもよい。スライスヘッダまたはNALユニットヘッダ内へのフラグの配置のオーバーヘッドは、ほぼ同じでもよい。

上述のシンタックスは、たとえば、以下のデコーダで使用されうる。

図10を参照すると、デコーダは、符号化されたレイヤ記述のテーブルを受信して復号することができる。同時係属中の米国特許出願第61/451,454号(DPS)は、とりわけこのステップについてのメカニズムを記述している。レイヤ記述のテーブルは、たとえばシーケンス(すべてのレイヤ内のIDR画像によって識別される)、または画像のグループの間は静的であると仮定されうる。同時係属中の第61/451,454号は、レイヤ記述のテーブル内の変化が、スケーラブルなビットストリーム内の明確に定義されたポイントでのみ発生しうることを確実にするために使用されうる依存性パラメータセットのための活性化メカニズムを記述している。

開示された主題によれば、スケーラブルなビットストリームを復号することができないデコーダを含むどのようなデコーダも、レイヤ記述のテーブルの受信および復号することができうる。たとえば品質拡張レイヤを復号することができないデコーダは、レイヤ記述のテーブルを解釈することによって、品質拡張レイヤについてのlayer_id値を識別して、たとえば受信しうるすべてのこのようなNALユニットを廃棄することによってそれに応じて反応しうる。どのスケーラブルメカニズムも不可能なデコーダであっても、依然として1つまたは複数(同時放送の場合)の個別に復号可能なベースレイヤのlayer_idを識別することができる。

受信および復号されたレイヤ記述があれば、レイヤ記述のテーブル内に記述されたそのレイヤのNALユニットの復号を開始することができる。NALユニットが受信されうる(1002)。パラメータセットNALユニットなどの非スライスNALユニット、SEIメッセージ、および他のものを、nal_unit_typeフィールドを解釈することによって識別することができ(1003)、対処することができる(1004)。

スライスNALユニットはlayer_idを含むことができ、layer_idは解釈されて(1005)、たとえばNALユニットの復号または廃棄をトリガしうる。解釈は、たとえば、既に記述したようにレイヤ記述のテーブル内のエントリに対処するために、layer_idを逆参照することを含みうる。この情報に基づいて、デコーダはNALユニットが復号されるべきレイヤに属するかどうかを判断できる。この判断は多くのオプションを含みうる。たとえば、デコーダはNALユニットを復号しないと決定でき、デコーダがNALユニットのレイヤのタイプを理解しないために、デコーダが十分な復号サイクルを有しないために、デコーダが受信されたNALユニットが依存するレイヤが損傷している(すなわち、パケット損失を通じて)ことを知っているために、デコーダがNALユニットを復号することができない場合、レイヤはユーザに十分な利益を与えない(すなわち、スクリーン分解能が小さすぎて、レイヤの高い空間分解能のレンダリングを実用的または有用にすることができない)、などである。このオプションのうちのいくつかは、符号化されたビットストリーム性質のすべてのNALユニットに適用するという点で静的でよく(すなわち、特定の強化レイヤタイプに復号技法を実装しないデコーダは、そのタイプの任意のNALユニットを廃棄することができる)、その他は動的であってもよい(すなわち、依存強化レイヤのNALユニットは通常は復号することができるが、ベースレイヤが損傷している場合は廃棄されうる)。

レイヤ記述のテーブル内に存在しないlayer_idを有するいかなるNALユニットも、準拠しないスケーラブルなビットストリームの表示でよい。デコーダの多くの反応は、準拠しないビットストリームに可能である。この状況で、1つの合理的なデコーダ設計は、受信したNALユニットを廃棄することとすることができる。

上記に基づいて、デコーダは、NALユニットを復号する(1007)ことを、または廃棄することを決定する(1006)。

動作は、スケーラブルなビットストリームの次のNALユニットに継続する(1008)。

MANEは、MANEは通常スライスNALユニットを復号せず、むしろ選択的にデコーダに転送することを除いて、同様のステップを実行することができる。

上述のビデオ符号化のための方法は、コンピュータ可読命令を使用する、およびコンピュータ可読記憶媒体内に物理的に格納された、コンピュータソフトウェアとして実装されうる。コンピュータソフトウェアは、任意の適切なコンピュータ言語を使用して符号化されうる。ソフトウェア命令は様々なタイプのコンピュータに実行されうる。たとえば、図11は、本開示の実施形態の実装に適したコンピュータシステム1100を示している。

図11に示される、コンピュータシステム1100のコンポーネント1100は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能の範囲に関していかなる限定も示唆することを意図するものではない。コンポーネントの構成も、コンピュータシステムの例示的な実施形態に示される構成要素のいずれか1つまたは組合せに関するいかなる依存性または要件も有すると解釈されるべきではない。コンピュータシステム1100は、集積回路、プリント回路基板、小型のハンドヘルドデバイス(たとえば、モバイル電話またはPDAなど)、パーソナルコンピュータ、またはスーパーコンピュータを含む、多くの物理的形態を有することができる。

コンピュータシステム1100は、ディスプレイ1132、1つまたは複数の入力デバイス1133(たとえば、キーパッド、キーボード、マウス、スタイラスなど)、1つまたは複数の出力デバイス1134(たとえば、スピーカ)、1つまたは複数のストレージデバイス1135、様々なタイプのストレージ媒体1136を含む。

システムバス1140は、幅広い種類のサブシステムをリンクする。当業者によって理解されるように、「バス」は、共通の機能を果たす複数のデジタル信号線を指す。システムバス1140は、メモリバス、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかのタイプのバス構造のいずれでもよい。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ(ISA)バス、拡張ISA(EISA)バス、マイクロチャネルアーキテクチャ(MCA)バス、ビデオエレクトロニクススタンダーズアソシエーションローカル(VLB)バス、ペリフェラルコンポーネントインターコネクト(PCI)バス、PCI-Expressバス(PCI-X)、およびアクセラレーテッドグラフィックスポート(AGP)バスがある。

プロセッサ1101(中央処理装置、またはCPUとも呼ばれる)は、命令、データ、またはコンピュータアドレスの一時的なローカルストレージのためのキャッシュメモリユニット1102を任意で含んでいる。プロセッサ1101は、メモリ1103を含むストレージデバイスに結合されている。メモリ1103は、ランダムアクセスメモリ(RAM)1104および読出し専用メモリ(ROM)1105を含む。当分野ではよく知られているように、ROM1105は、データおよび命令をプロセッサ1101に単方向に転送するために機能し、RAM1104は概して、データおよび命令を双方向的に転送するために使用される。これらのタイプのメモリは両方とも、後述の任意の適切なコンピュータ可読記憶媒体を含むことができる。

固定ストレージ1108も、任意でストレージ制御ユニット1107を介して、プロセッサに1101に双方向的に結合されている。固定ストレージ1108は、追加のデータストレージ容量を提供し、また、後述するコンピュータ可読記憶媒体のうちのいずれかを含むことができる。ストレージ1108は、オペレーティングシステム1109、EXEC1110、アプリケーションプログラム1112、データ1111、および同等物を格納するために使用することができ、一般的には一次ストレージよりも遅い二次ストレージ媒体(ハードディスクなど)である。ストレージ1108内に保持された情報は、適切な場合には、標準的な方法で仮想メモリとしてメモリ1103内に組み込むことができることが理解されるべきである。

プロセッサ1101が、グラフィック制御1121、ビデオインターフェース1122、入力インターフェース1123、出力インターフェース1124、ストレージインタフェース1125などの様々なインターフェースにも結合されており、ひいては、これらのインターフェースが、適切なデバイスに結合されている。概して、入力/出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロフォン、タッチセンサ式ディスプレイ、トランスデューサカードリーダー、磁気または紙のテープリーダー、タブレット、スタイラス、音声または手書き文字認識装置、バイオメトリクスリーダー、または他のコンピュータのうちのいずれでもよい。プロセッサ1101は、ネットワークインターフェース1120を使用して、別のコンピュータまたは遠隔通信ネットワーク1130に結合されうる。このようなネットワークインターフェース1120があれば、CPU1101がネットワーク1130から情報を受信しうる、または上述の方法を実行する過程で、ネットワークへ情報を出力しうると考えられる。さらに、本開示の方法の実施形態は、CPU1上で単独で実行することもでき、処理の一部を共有するリモートCPU1101と連携してインターネットなどのネットワーク1130を介して実行することもできる。

様々な実施形態によれば、ネットワーク環境内にある場合、すなわちコンピュータシステム1100がネットワーク1130に接続されている場合、コンピュータシステム1100は、やはりネットワーク1130に接続された他のデバイスと通信することができる。通信は、ネットワークインターフェース1120を介してコンピュータシステム1100へ、かつそこから送信されうる。たとえば、1つまたは複数のパケットの形式の、別のデバイスからの要求または応答などの着信通信は、ネットワークインターフェース1120でネットワーク1130から受信されて、処理するためにメモリ1103内の選択されたセクションに格納されうる。やはり1つまたは複数のパケットの形式の、別のデバイスへの要求または応答などの発信通信も、メモリ1103内の選択されたセクションに格納されて、ネットワークインターフェース1120でネットワーク1130に送出されうる。プロセッサ1101は、処理するためにメモリ1103に格納されたこれらの通信パケットにアクセスすることができる。

さらに、本開示の実施形態は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有するコンピュータ可読記憶媒体を備えたコンピュータストレージ製品にさらに関連する。媒体およびコンピュータコードは、本開示の目的のために特に設計および構築されたものであってもよく、当コンピュータソフトウェア技術分野の技術者によく知られており、入手可能な種類のものであってもよい。コンピュータ可読記憶媒体の例には、これに限定されないが、ハードディスク、フロッピー(登録商標)ディスク、および磁気テープなどの磁気媒体、CD-ROMおよびホログラフィックデバイスなどの光学式媒体、光ディスクなどの光磁気媒体、ならびに特定用途向け集積回路(ASIC)、プログラム可能論理デバイス(PLD)、ROMおよびRAMデバイスなどの、プログラムコードを格納して実行するように特に構成されたハードウェアデバイスがある。コンピュータコードの例には、コンパイラによって生成されるものなどのマシンコード、およびインタプリタを使用してコンピュータによって実行されるより高いレベルのコードを含むファイルがある。当業者は、本開示主題とともに使用されるとき、「コンピュータ可読記憶媒体」という用語は、送信媒体、搬送波、または他の一時的信号を包含しないことも理解するべきである。

限定ではないが例として、アーキテクチャ1100を有するコンピュータシステムは、プロセッサ1101が、メモリ1103などの1つまたは複数の有形のコンピュータ可読記憶媒体に具現化されたソフトウェアを実行する結果として機能を提供することができる。本開示の様々な実施形態を実装するソフトウェアは、メモリ1103に格納されて、プロセッサ1101によって実行されうる。コンピュータ可読記憶媒体は、具体的なニーズに応じて、1つまたは複数のメモリデバイスを含むことができる。メモリ1103は、たとえば、大容量ストレージデバイス1135などの1つまたは複数の他のコンピュータ可読記憶媒体から、または通信インターフェースを介して1つまたは複数の他のソースから、ソフトウェアを読み取ることができる。ソフトウェアは、プロセッサ1101に、メモリ1103に格納されたデータ構造を定義すること、およびソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理または特定の処理の特定の一部を実行させることができる。加えて、または代替として、コンピュータシステムは、ハードワイヤード論理、あるいは回路内に組み込まれた論理の結果として機能を提供することができ、本明細書に記載の特定の処理または特定の処理の特定の一部を実行するためのソフトウェアの代わりに、またはそれと一緒に動作させることができる。ソフトウェアへの参照は論理を包含することができ、適切な場合は逆もまた同様である。コンピュータ可読記憶媒体への参照は、実行するためのソフトウェアを格納する回路(集積回路(IC)など)、実行するための論理を具現化する回路、または適切な場合はその両方を包含しうる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組合せを包含する。

本開示はいくつかの例示的実施形態を説明してきたが、本開示の範囲に含まれる変更形態、置換形態、および様々な代わりの均等形態がある。したがって、当業者は、本明細書に明示的に図示または記載されていないが、本開示の原理を具現化し、本開示の趣旨および範囲内にある、多数のシステムおよび方法を考案することができることが理解されよう。

401 エンコーダ
405 デコーダ
501 NALユニットヘッダ
601 NALユニットヘッダ
701 NALユニットヘッダ
906 レイヤ記述テーブル
1100 コンピュータシステム
1100 アーキテクチャ
1101 プロセッサ
1102 キャッシュメモリユニット
1103 メモリ
1104 ランダムアクセスメモリ(RAM)
1105 読出し専用メモリ(ROM)
1107 ストレージ制御ユニット
1108 固定ストレージ
1109 オペレーティングシステム
1110 EXEC
1111 データ
1112 アプリケーションプログラム
1120 ネットワークインターフェース
1121 グラフィック制御
1122 ビデオインターフェース
1123 入力インターフェース
1124 出力インターフェース
1125 ストレージインタフェース
1130 遠隔通信ネットワーク
1132 ディスプレイ
1133 入力デバイス
1134 出力デバイス
1135 ストレージデバイス
1136 ストレージ媒体
1140 システムバス

Claims

ビデオ復号のための方法であって、
複数のレイヤを含む符号化されたビデオシーケンスに関連するレイヤ記述のテーブルを受信するステップであって、前記レイヤ記述のテーブルが、各々が第1のlayer_idによって識別され、各々がレイヤに関連し、各々が少なくとも1つの前記レイヤの特性を含む、複数のレイヤ記述を含む、ステップと、
第2のlayer_idを含んだネットワークアダプテーションレイヤ(NAL)ユニットヘッダを受信するステップと、
前記第2のlayer_idを前記第1のlayer_idとマッチングすることによって、前記レイヤ記述のテーブルの前記複数のレイヤ記述のうちの1つを識別するステップと、
前記複数のレイヤ記述のうちの前記識別された1つから前記NALユニットが属する前記レイヤの少なくとも1つの特性を決定するステップと
を含み、
前記第2のlayer_idのある値が拡張を表すために使用され、
前記NALユニットヘッダの長さが前記符号化されたビデオシーケンスのレイヤ数から独立しており、
前記NALユニットヘッダがtemporal_idをさらに含む、方法。
前記少なくとも1つの特性が、dependency_id、quality_id、view_id、depth_map_flag、およびdependent_flagのうちの少なくとも1つを含む、請求項1に記載の方法。
前記temporal_idが、前記layer_idによって識別されたレイヤの時間サブレイヤを識別する、請求項1に記載の方法。
レイヤ記述の前記テーブルが依存性パラメータセットの一部である、請求項1に記載の方法。
前記depth_map_flagが、前記NALユニットが属する第1のレイヤがデプスマップであり、前記第1のレイヤと同じview_idを有することによって識別される第2のレイヤに関連付けられることを示す、請求項2に記載の方法。
前記第2のlayer_idのあらかじめ定められた値が拡張データの存在を識別する、請求項1に記載の方法。
前記第1のlayer_idが、レイヤ階層内の前記レイヤの位置の表示である、請求項1に記載の方法。
前記NALユニットヘッダが、store_ref_base_pic_flagおよびuse_ref_base_pic_flagのうちの少なくとも1つをさらに含む、請求項1に記載の方法。
前記NALユニットヘッダがスライスNALユニットヘッダであり、前記NALユニットにおいて搬送されたスライスのスライスヘッダが、store_ref_base_pic_flagおよびuse_ref_base_pic_flagのうちの少なくとも1つを含む、請求項1に記載の方法。
ビデオ符号化のための方法であって、
第1のlayer_idを有する少なくとも1つのレイヤを含むレイヤ構造を決定するステップと、
符号化されたビデオシーケンスに関連するレイヤ記述のテーブルを符号化するステップであって、前記レイヤ記述のテーブルが、各々が第1のlayer_idによって識別され、各々がレイヤに関連し、各々が少なくとも1つの前記レイヤの特性を含む、複数のレイヤ記述を含み、前記レイヤ記述のテーブルが前記レイヤ構造の表現を含む、ステップと、
NALユニットヘッダを含む少なくとも1つのネットワークアダプテーションレイヤ(NAL)ユニットを符号化するステップであって、前記NALユニットヘッダが第2のlayer_idを含む、ステップと
を含み、
前記第2のlayer_idのある値が拡張を表すために使用され、
前記NALユニットヘッダの長さが前記符号化されたビデオシーケンスのレイヤ数から独立しており、
前記NALユニットヘッダがtemporal_idをさらに含む、方法。
前記少なくとも1つの特性が、dependency_id、quality_id、view_id、depth_map_flag、およびdependent_flagのうちの少なくとも1つを含む、請求項10に記載の方法。
前記temporal_idが、前記layer_idによって識別されたレイヤの時間サブレイヤを識別する、請求項10に記載の方法。
レイヤ記述の前記テーブルが依存性パラメータセットの一部である、請求項10に記載の方法。
前記depth_map_flagが、前記NALユニットが属する第1のレイヤがデプスマップであり、前記第1のレイヤと同じview_idを有することによって識別される第2のレイヤに関連付けられることを示す、請求項11に記載の方法。
前記第2のlayer_idのあらかじめ定められた値が拡張データの存在を識別する、請求項10に記載の方法。
前記第1のlayer_idが、レイヤ階層内の前記レイヤの位置の表示である、請求項10に記載の方法。
前記NALユニットヘッダが、store_ref_base_pic_flagおよびuse_ref_base_pic_flagのうちの少なくとも1つをさらに含む、請求項10に記載の方法。
前記NALユニットヘッダがスライスNALユニットヘッダであり、前記NALユニットにおいて搬送されたスライスのスライスヘッダが、store_ref_base_pic_flagおよびuse_ref_base_pic_flagのうちの1つを含む、請求項10に記載の方法。
スケーラブルなビットストリームからネットワークアダプテーションレイヤ(NAL)ユニットを除去するための方法であって、
複数のレイヤを含む符号化されたビデオシーケンスに関連するレイヤ記述のテーブルを受信して復号するステップであって、前記レイヤ記述のテーブルが、各々が第1のlayer_idによって識別され、各々がレイヤに関連し、各々が少なくとも1つの前記レイヤの特性を含む、複数のレイヤ記述を含む、ステップと、
第2のlayer_idを含んだNALユニットヘッダを含むスライスNALユニットを受信するステップと、
前記第2のlayer_idを前記第1のlayer_idとマッチングすることによって、前記レイヤ記述のテーブルの前記複数のレイヤ記述のうちの1つを識別するステップと、
前記複数のレイヤ記述のうちの前記識別された1つが、前記NALユニットが除去されるべきレイヤに属していることを表している場合のみ、除去するステップと
を含み、
前記第2のlayer_idのある値が拡張を表すために使用され、
前記NALユニットヘッダの長さが前記符号化されたビデオシーケンスのレイヤ数から独立しており、
前記NALユニットヘッダがtemporal_idをさらに含む、方法。
レイヤ記述の前記テーブルが、それぞれがlayer_idを有する複数のレイヤ記述を含み、第1のレイヤ記述によって記述されるどの第1のレイヤも、第2のレイヤ記述によって記述される第2のレイヤに依存せず、前記第2のレイヤ記述の前記layer_idが前記レイヤ記述のテーブルに存在していない、請求項19に記載の方法。
プロセッサに請求項1に記載の方法を実行させるための命令のセットを含む、持続性コンピュータ可読記憶媒体。
プロセッサに請求項10に記載の方法を実行させるための命令のセットを含む、持続性コンピュータ可読記憶媒体。
プロセッサに請求項19に記載の方法を実行させるための命令のセットを含む、持続性コンピュータ可読記憶媒体。
前記NALユニットヘッダの前記長さが16ビットである、請求項1に記載の方法。
前記NALユニットヘッダの前記長さが16ビットである、請求項11に記載の方法。
前記NALユニットヘッダの前記長さが16ビットである、請求項19に記載の方法。