[0020]概して、本開示は、シーケンスパラメータセット(SPS)中で1つまたは複数のコード化プロパティを示すための技法について説明する。より詳細には、本開示の技法は、ビデオシーケンスのコード化プロパティを示すためにプロファイル、ティア、およびレベルシンタックス構造を使用する。profile_tier_levelシンタックス構造は、高効率ビデオコーディング(HEVC)規格などのビデオ規格によるビデオコーディングではSPSまたはビデオパラメータセット(VPS)中でシグナリングされ得る。本明細書で説明する技法は、profile_tier_levelシンタックス構造を理解するように設計されたトランスポート規格のビデオプロパティへの軽量アクセスを改善する。
[0021]HEVCなどのいくつかの規格は、シンタックス構造に関連するビデオデータを解釈および/またはコーディングする際に使用されるシンタックス要素を含むprofile_tier_levelシンタックス構造を定義する。プロファイル、ティア、およびレベルは、同様の機能要件をもつ様々なアプリケーションにわたって相互運用可能な方法で、HEVCなどの規格を実装するためのコンフォーマンスポイント(conformance point)を指定する。さらに、ビデオデータをコーディングするために使用される他のビデオプロパティを示すシンタックス要素またはフラグは、SPSまたはビデオパラメータセット(VPS)中の他の場所など、profile_tier_levelシンタックス構造外のシンタックス構造中に含まれ得る。これらのシンタックス要素またはフラグは、様々なコーディングツールがビデオデータのために使用イネーブルにされているかどうかを示し得る。
[0022]たとえば、国際標準化機構(ISO)ベースメディアファイルフォーマット、MPEG−2システム、ハイパーテキスト転送プロトコル(HTTP:Hypertext Transfer Protocol)を介した動的適応ストリーミング(DASH:Dynamic Adaptive Streaming over HTTP)、およびリアルタイムトランスポートプロトコル(RTP:real-time transport protocol)を含む、いくつかのビデオデバイスのために使用されるトランスポート規格は、profile_tier_levelシンタックス構造の少なくとも最初の数ビットを理解するように設計され得る。ただし、profile_tier_levelシンタックス構造のほかに、SPSまたはVPS中に含まれる他の追加情報はアクセスしにくい。したがって、本開示のいくつかの技法は、通常ならば、SPSまたはVPSのアクセスしにくい部分中に含まれたであろう様々なコーディングツールがイネーブルにされているかどうかを示すためにフラグを与えるために、profile_tier_levelシンタックス構造の1つまたは複数のビットを使用する。いくつかの例では、1つまたは複数のコーディングイネーブルツールビットは、プロファイルおよびレベル情報を含むシンタックス構造の一部であるか、またはそれに連続するリザーブビットシンタックス要素中にコード化され得る。シンタックス構造は、profile_tier_levelシンタックス構造であり得、パラメータセット中に置かれ得る。
[0023]HEVC Working Draft 8(本明細書では「WD8」と呼ぶ)などのHEVCのドラフトは、将来の目的のためにビットを予約するgeneral_reserved_zero_16bitsシンタックス要素を含む。本開示における技法は、様々なコーディングツールがイネーブルにされているかどうかを示すためにフラグを与えるためにprofile_tier_levelシンタックス構造中の予約済みビットのいくつかを使用する。コーディングツールの例には、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために明示的重み付け予測(デフォルト値(1/2,1/2)(1,0)または(0,1)を除く)および/またはタイル(tile)がイネーブルにされているかを含む。シグナリングされ得る追加の例示的なコーディングツールには、ウエーブフロント(wavefront:波面)がイネーブルにされているかどうか、時間動きベクトル予測(TMVP)がイネーブルにされているかどうか、スケーリングリストデータが存在しているかどうか、または現在のビットストリームが8ビットであるかどうか、を含む。これらの技法は、所与のプロファイル、ティア、およびレベル内のコーデック間により多くの差別化を与える。言い換えれば、所与のプロファイル/ティア/レベル内で、本開示の技法は、いくつかのコーディングツールがイネーブル(使用可能)にされているかどうかを示すために、コーディングツールイネーブルビットとして予約済みビットの1つまたは複数のビットを使用することができる。いくつかの例では、1つまたは複数のフラグ、general_no_weighted_prediction_flagフラグおよびgeneral_no_tiles_flagフラグも、シンタックス要素の一部として含まれ得る。さらに、コーディングツールの上記の指示のすべては互いに無関係であり得る。
[0024]profile_tier_levelシンタックス構造中にいくつかのコーディングツールについてのシンタックス要素を含めることによって、それらがSPS中に概して存在する必要がなくなる。これらの技法を使用すると、シンタックス要素は、profile_tier_levelシンタックス構造の最初のいくつかのバイト中にあり得る。したがって、profile_tier_levelシンタックス構造の少なくとも最初の数ビットを理解するように設計されたトランスポート規格を使用するビデオデバイスは、関連するビデオデータのためにいくつかのコーディングツールがイネーブルにされているかどうかを決定することが可能であり得る。
[0025]profile_tier_levelシンタックス構造は、SPS中に、または代替的に、VPS中にあり得る。SPSは、ビデオデータの各レイヤに必要とされ、その結果、複数のSPSがコーディングされ、送信される。対照的に、VPSは、ビデオデータのすべてのレイヤについて1回だけ送られる。したがって、SPS中ではなくVPS中にprofile_tier_levelシンタックス構造を含めると、送られる全体的なビット数が低減する。
[0026]図1は、本開示で説明する技法による、いくつかのコード化プロパティを示すための技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示すように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを提供するソースデバイス12を含む。特に、ソースデバイス12は、ストレージデバイス34であり得るコンピュータ可読媒体16を介してビデオデータを宛先デバイス14に与える。ソースデバイス12および宛先デバイス14は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備され得る。
[0027]ソースデバイス12および宛先デバイス14などのデジタルビデオデバイスは、MPEG−2、MPEG−4、ITU−T H.263、ITU−T H.264/MPEG−4,Part 10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、HEVC規格によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法など、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および/または記憶し得る。
[0028]宛先デバイス14は、コンピュータ可読媒体16を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動させることができる任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が、符号化ビデオデータを宛先デバイス14にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルあるいは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0029]代替的に、符号化データは、出力インターフェース22からストレージデバイス34に出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイス34からアクセスされ得る。ストレージデバイス34は、ハードドライブ、ブルーレイ(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス34は、ソースデバイス12によって生成された符号化ビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介してストレージデバイス34から、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi−Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含み得る。ストレージデバイス34からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。
[0030]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。
[0031]ソースデバイス12および宛先デバイス14は、たとえば、profile_tier_levelシンタックス構造の少なくとも最初の数ビット中に埋め込まれたコードまたはシンタックス要素を解釈し理解するように設計され得る、国際標準化機構(ISO)ベースメディアファイルフォーマット、MPEG−2システム、DASH、およびリアルタイムトランスポートプロトコル(RTP)を含むトランスポート規格を使用するように構成され得る。ただし、シーケンスパラメータセットまたはビデオパラメータセット中の他の追加情報は、いくつかのデバイスにとってアクセスしにくい。したがって、いくつかのHEVC設計は、ビデオプロパティへの軽量(lightweight)アクセスをサポートしない。
[0032]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、プロファイル、ティア、およびレベルシンタックス構造中のビットを再使用することによってシーケンスパラメータセットでコード化プロパティを示すための技法を適用するように構成され得る。したがって、ビデオコーディングプロパティを示すためにSPSまたはVPS中の他の場所で提示されるシンタックス要素および/またはシンタックス構造を使用する代わりに、またはそれに加えて、プロファイル、ティア、およびレベルシンタックス構造の、たとえば、general_reserved_zero_16bits中のビットのうちの1つまたは複数が、本開示で説明するように、ビデオコーディングプロパティのうちの1つまたは複数を示すために使用され得る。
[0033]様々な例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
[0034]図1の図示のシステム10は一例にすぎない。プロファイル、ティア、およびレベルシンタックス構造を再使用することによってシーケンスパラメータセットでビデオコーディングプロパティを示すための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。さらに、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14に送信するためのコード化ビデオデータを生成するようなコーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話のための、ビデオデバイス12とビデオデバイス14との間の一方向または双方向のビデオ送信をサポートすることができる。
[0035]ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラ付き携帯電話またはビデオ電話を形成することができる。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16またはストレージデバイス34上に出力され得る。
[0036]コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくはワイヤードネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu−ray(登録商標)ディスク、または他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバは、ソースデバイス12から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス14に与え得る。同様に、ディスクスタンピング設備などの媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化ビデオデータを受信し、その符号化ビデオデータを含むディスクを生成し得る。したがって、様々な例では、コンピュータ可読媒体16は、様々な形態の1つまたは複数のコンピュータ可読媒体を含むと理解され得る。
[0037]宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、ブロックおよび他のコード化ユニット、たとえば、GOPの特性および/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、復号ビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。
[0038]ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディング(HEVC)規格などのビデオコーディング規格に従って動作し得、HEVCテストモデル(HM)に準拠し得る。HEVCは、インターレースビデオの指示のためのフィールド指示SEIメッセージと、フレームパッキング立体3Dビデオの指示のためのフレームパッキング配置(FPA)SEIメッセージとの仕様を含む。HEVCが、現在、ITU−T Video Coding Experts Group(VCEG)とISO/IEC Motion Picture Experts Group(MPEG)とのJoint Collaboration Team on Video Coding(JCT−VC)によって開発されている。HEVCの最近のワーキングドラフト(WD)は、Working Draft 8(以下では「HEVC WD8」と呼ぶ)である。http://phenix.int−evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC−J1003−v8.zipからの、2013年9月12日時点で入手可能な、Brossら、High Efficiency Video Coding(HEVC)Text Specification Draft 8、2012年7月、Stockholm。本開示で説明する技法は、HEVC規格に関して説明されるが、本開示の態様は、そのように限定されず、他のビデオコーディング規格および所有権を主張できるビデオコーディング技法に拡張され得る。
[0039]代替的に、ビデオエンコーダ20およびビデオデコーダ30は、他のプロプライエタリ規格または業界規格に従って動作し得る。別の規格の例は、代替的に、MPEG−4,Part 10、アドバンストビデオコーディング(AVC)と呼ばれる(ISO/IEC MPEG−4 AVCとしても知られる)ITU−T H.264規格またはそのような規格の拡張である。それに従ってビデオエンコーダ20およびビデオデコーダ30が動作し得る他のビデオコーディング規格には、MPEG−2システム、DASH、およびRPTがある。それに従ってビデオエンコーダ20およびビデオデコーダ30が動作し得るビデオコーディング規格の他の例には、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)拡張を含むITU−T H.264がある。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、2つ以上の規格に従って動作するように構成され得る。ただし、本開示の技法は、特定のコーディング規格に限定されないが、特に、HEVCビデオコーディングプロセスにおいて有用であり得る。
[0040]いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
[0041]ITU−T H.264/MPEG−4(AVC)規格は、Joint Video Team(JVT)として知られる共同パートナーシップの成果として、ISO/IEC Moving Picture Experts Group(MPEG)とともにITU−T Video Coding Experts Group(VCEG)によって策定された。いくつかの態様では、本開示で説明する技法は、一般にH.264規格に準拠するデバイスに適用することができる。H.264規格は、ITU−T研究グループによる2005年3月付けのITU−T勧告H.264「Advanced Video Coding for generic audiovisual services」に記載されており、本明細書ではH.264規格またはH.264仕様、あるいはH.264/AVC規格または仕様と呼ぶ。Joint Video Team(JVT)はH.264/MPEG−4 AVCへの拡張に取り組み続けている。
[0042]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非時間的コンピュータ可読媒体にソフトウェアの命令を記憶し、1つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合され得る。
[0043]JCT−VCは、HEVC規格のさらなる開発に取り組んでいる。HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。HMは、たとえば、ITU−T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、H.264は9つのイントラ予測符号化モードを提供するが、HMは33個ものイントラ予測符号化モードを提供し得る。
[0044]一般に、HMの作業モデルは、ビデオフレームまたはピクチャが、ルーマとクロマの両方のサンプルを含む一連のツリーブロックまたは最大コーディングユニット(LCU)に分割され得ることを記載する。次回のHEVC規格はまた、LCUを「コーディングツリーユニット」と称する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるLCUのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に分割され得る。一般に、4分木データ構造はCUごとに1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割された場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
[0045]4分木データ構造の各ノードは、対応するCUのシンタックスデータを与え得る。たとえば、4分木のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含み得る。CUのシンタックス要素は、再帰的に定義され得、CUがサブCUに分割されるかどうかに依存し得る。CUがさらに分割されない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的分割が存在しない場合でも、リーフCUの4つのサブCUをリーフCUとも呼ぶ。たとえば、16×16サイズのCUがさらに分割されない場合、この16×16CUが決して分割されなくても、4つの8×8サブCUをリーフCUとも呼ぶ。
[0046]CUは、CUがサイズ差異を有さないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、4つの子ノード(サブCUとも呼ばれる)に分割され得、各子ノードは、今度は親ノードとなり、別の4つの子ノードに分割され得る。4分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コーディングビットストリームに関連するシンタックスデータは、最大CU深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズも定義し得る。それに応じて、ビットストリームは最小コーディングユニット(SCU:smallest coding unit)をも定義し得る。本開示では、HEVCのコンテキストにおけるCU、PU、またはTU、あるいは他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれのサブブロック)のいずれかを指すために「ブロック」という用語を使用する。
[0047]CUは、コーディングノードと、コーディングノードに関連する予測ユニット(PU:prediction unit)および変換ユニット(TU:transform unit)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。CUのサイズは、8×8ピクセルから最大64×64以上のピクセルを有するツリーブロックのサイズまでに及び得る。各CUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。CUに関連するシンタックスデータは、たとえば、CUを1つまたは複数のPUに区分することを記述し得る。区分モードは、CUが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。PUは、形状が非方形になるように区分され得る。CUに関連するシンタックスデータは、たとえば、4分木に従って、CUを1つまたは複数のTUに区分することも記述し得る。TUは、形状が正方形または非正方形(たとえば、矩形)であり得る。
[0048]HEVC規格は、CUごとに異なり得るTUに従った変換を可能にする。TUは、一般に、区分されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。TUは、一般にPUと同じサイズであるかまたはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用して、より小さいユニットに再分割され得る。RQTのリーフノードは変換ユニット(TU)と呼ばれることがある。TUに関連するピクセル差分値は、量子化され得る変換係数を生成するために変換され得る。
[0049]リーフCUは、1つまたは複数の予測ユニット(PU)を含むことができる。一般に、PUは、対応するCUの全部または一部に対応する空間的エリアを表し、そのPU用の参照サンプルを取り出すためのデータを含むことができる。その上、PUは、予測に関係するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUのデータは、PUに対応するTUのイントラ予測モードを記述するデータを含み得る、残差4分木(RQT)中に含まれ得る。別の例として、PUがインターモード符号化されるとき、PUは、PUのための1つまたは複数の動きベクトルを定義するデータを含み得る。PUの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度もしくは1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルの参照ピクチャリスト(たとえば、リスト0、リスト1、もしくはリストC)を記述し得る。
[0050]1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換ユニット(TU)を含み得る。変換ユニットは、上記で説明したように、(TU4分木構造とも呼ばれる)RQTを使用して指定され得る。たとえば、分割フラグは、リーフCUが4つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらに、さらなるサブTUに分割され得る。TUがさらに分割されないとき、そのTUはリーフTUと呼ばれ得る。概して、イントラコーディングの場合、リーフCUに属するすべてのリーフTUは同じイントラ予測モードを共有する。すなわち、概して、リーフCUのすべてのTUの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフTUの残差値を、TUに対応するCUの一部と元のブロックとの間の差分として計算し得る。TUは、必ずしもPUのサイズに制限されるとは限らない。したがって、TUはPUよりも大きくまたは小さくなり得る。イントラコーディングの場合、PUは、同じCUについて対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
[0051]さらに、リーフCUのTUはまた、残差4分木(RQT)と呼ばれる、それぞれの4分木データ構造に関連付けられ得る。すなわち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含み得る。TU4分木のルートノードは概してリーフCUに対応し、CU4分木のルートノードは概してツリーブロック(またはLCU)に対応する。分割されないRQTのTUはリーフTUと呼ばれる。概して、本開示では、特に明記しない限り、リーフCUおよびリーフTUに言及するためにそれぞれCUおよびTUという用語を使用する。
[0052]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ(GOP)は、概して、ビデオピクチャのうちの一連の1つまたは複数を備える。GOPは、GOP中に含まれるいくつかのピクチャを記述するシンタックスデータを、GOPのヘッダ中、ピクチャのうちの1つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコーディングノードに対応し得る。ビデオブロックは、サイズを固定することも変更することもでき、指定のコーディング規格に応じてサイズが異なることがある。
[0053]一例として、HMは、様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズでのイントラ予測をサポートし、2N×2N、2N×N、N×2N、またはN×Nの対称的なPUサイズでのインター予測をサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、または「Right」という表示によって示される。したがって、たとえば、「2N×nU」は、上部の2N×0.5N PUと下部の2N×1.5N PUとで水平方向に区分された2N×2N CUを指す。
[0054]本開示では、「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は非負整数値を表す。ブロック内のピクセルは行と列で構成することができる。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはN×Mピクセルを備えてよく、ただし、Mは必ずしもNに等しいとは限らない。
[0055]CUのPUを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ20は、CUのTUのための残差データを計算し得る。PUは、(ピクセル領域とも呼ばれる)空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、TUは、変換、たとえば、残差ビデオデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、TUを変換して、CUの変換係数を生成し得る。
[0056]変換係数を生成するための任意の変換の後に、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にnビット値がmビット値に切り捨てられ得、ただし、nはmよりも大きい。
[0057]量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む2次元行列から1次元ベクトルを生成し得る。走査は、より高いエネルギー(したがってより低い周波数)の係数をアレイの前方に配置し、より低いエネルギー(したがってより高い周波数)の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は適応走査を実行し得る。量子化変換係数を走査して1次元ベクトルを形成した後に、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC:context-adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context-adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
[0058]CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非0であるか否かに関係し得る。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボルのための可変長コードを選択し得る。VLCにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、VLCの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率決定は、シンボルに割り当てられるコンテキストに基づき得る。
[0059]ビデオエンコーダ20は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびGOPベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはGOPヘッダ中でビデオデコーダ30に送り得る。GOPシンタックスデータは、それぞれのGOP中のいくつかのフレームを記述し得、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化/予測モードを示し得る。
[0060]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、適用可能なとき、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な好適なエンコーダまたはデコーダ回路のいずれかとして実装され得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを備え得る。
[0061]HEVCなどのいくつかの規格は、profile_tier_levelシンタックス構造を定義する。プロファイル、ティア、およびレベルは、同様の機能要件をもつ様々なアプリケーションにわたって相互運用可能な方法で、HEVCなどの規格を実装するためのコンフォーマンスポイントを指定する。プロファイルは、準拠したビットストリームを生成するために使用され得るコーディングツールまたはアルゴリズムのセットを定義する。レベルは、たとえば、デコーダ処理負荷能力およびメモリ能力に対応するビットストリームのいくつかのパラメータに制約を加える。レベル制限は、最大サンプルレート、最大ピクチャサイズ、最大ビットレート、最小圧縮比、ならびに復号ピクチャバッファ(DPB:decoded picture buffer)およびコード化ピクチャバッファ(CPB:coded picture buffer)の容量に関して確立される。いくつかのレベルは、メインティア(Main Tier)および高ティア(High Tier)の指定された2つのティアを有する。
[0062]ソースデバイス12、宛先デバイス14、およびコンピュータ可読媒体16のうちの1つまたは複数は、少なくともprofile_tier_levelシンタックス構造を理解するように設計された1つまたは複数のトランスポート規格を実装し得る。そのようなトランスポート規格は、たとえば、ISOベースメディアファイルフォーマット、MPEG−2システム、DASH、およびリアルタイム転送プロトコル(RTP)であり得る。本明細書で説明する技法に従って、ビデオエンコーダ20およびは、ビデオシーケンスを符号化し、たとえば、コード化ビデオシーケンスのためのprofile_tier_levelシンタックス構造のためのgeneral_reserved_zero_16bits中のビットのうちの1つが、コーデックプロパティうちの1つまたは複数を示すなど、予約済みビットシンタックス要素の1つまたは複数のビットを符号化するように構成され得る。いくつかの態様では、これらの1つまたは複数のビットは、1つまたは複数のコーディングツールイネーブルビットとして働き得る。1つまたは複数のコーディングツールイネーブルビットは、ビデオエンコーダ20および/またはビデオデコーダ30による使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す。さらに、ビデオデコーダ30は、1つまたは複数のコーディングツールイネーブルビットとして、たとえば、コード化ビデオシーケンスのためのprofile_tier_levelシンタックス構造のためのgeneral_reserved_zero_16bits中のビットのうちの1つなど、予約済みビットシンタックス要素の1つまたは複数のビットを復号するように構成され得る。
[0063]いくつかの態様では、1つまたは複数のコーディングツールイネーブルビットは、ビデオデコーダ30による使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す。ビデオデコーダ30による使用のためにイネーブルにされているとして示された1つまたは複数のコーディングツールイネーブルビットによって示された1つまたは複数のコーディングツールを使用して、ビデオデコーダ30は、符号化ビデオシーケンスを復号し得る。すなわち、ビデオデコーダ30は、コード化ビデオデータを復号するためにイネーブルにされたコーディングツールを使用し得る。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、profile_tier_levelシンタックス構造中のgeneral_reserved_zero_16bits予約済みビットシンタックス要素の1つまたは複数のビットとしてコーディングされる。1つまたは複数のコーディングツールイネーブルビットは、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために明示的重み付け予測(デフォルト値(1/2,1/2)(1,0)または(0,1)ではない)がイネーブルにされているかどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのためにタイルがイネーブルにされているかどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのためにウエーブフロント処理がイネーブルにされているかどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームに時間動きベクトル予測がイネーブルにされているかどうか、スケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうか、ならびに現在のビットストリームが8ビットであるかどうか、のコーデックプロパティのうちの1つまたは複数を示し得る。現在のビットストリームが8ビットであることを示すことにより、ビデオデコーダ30は、ビットストリームが他のビット深度ではなく、8ビットの深度を有すると決定することが可能になる。
[0064]コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのためにタイルがイネーブルにされているかどうかを1つまたは複数のコーディングツールイネーブルビットが示す例では、1つまたは複数のコーディングツールイネーブルビットは、さらにまたは代替として、タイルが単独で復号可能にされているかどうかを示し得る。タイルは、HEVCの並列処理能力を補助し得るビデオデータのピクチャの矩形領域である。ピクチャは、何らかの共有ヘッダ情報で符号化される単独で復号可能な領域であるタイルに区分され得る。いくつかの例では、タイルはまた、ビデオピクチャのローカル領域への空間ランダムアクセスのために使用され得る。ピクチャの1つの例示的なタイル構成は、ピクチャを、各タイル中にほぼ等しい数のコーディングツリーユニットをもつ複数の矩形領域にセグメント化することを含む。
[0065]いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、ウエイブフロントがイネーブルにされているかどうかを示す。本明細書では、ウエーブフロントは、概して、ウエーブフロント並列処理(WPP:wavefront parallel processing)を指す。WPPがイネーブルにされているとき、ビデオデータのスライスはコーディングツリーユニット(CTU:coding tree unit)の行(row)に分割される。第1の行は、典型的な方法で処理され得、第2の行は、第1の行中で2つだけCTUが処理された後に処理され得、第3の行は、第2の行中で2つだけCTUが処理された後に処理が開始され得、以下同様である。各行中のエントロピーコーダのコンテキストモデルは、2CTU処理ラグで前の行中のコンテキストモデルから推論され得る。タイルはピクチャレベルに作用するのに対し、ウエーブフロント並列処理はスライスレベルに作用するので、ウエーブフロント並列処理は、タイルよりも比較的精細である並列処理の形態を与え得る。
[0066]本開示の技法によれば、1つまたは複数のフラグ、general_no_weighted_prediction_flagフラグおよびgeneral_no_tiles_flagフラグは、予約済みビットシンタックス要素の一部として含まれ得る。1に等しいgeneral_no_weighted_prediction_flagフラグは、コード化ビデオシーケンス中で、ピクチャが重み付け予測を用いてコーディングされず、シンタックス要素weighted_pred_flagおよびweighted_bipred_flagが、ピクチャパラメータセット(PPS:picture parameter set)中で0に等しくなるべきであることを示す。0に等しいフラグgeneral_no_weighted_prediction_flagは、コード化ビデオシーケンス中で、重み付け予測が使用され得ることを示す。1に等しいフラグgeneral_no_tiles_flagは、コード化ビデオシーケンス中の各ピクチャに対し、各ピクチャ中の1つのタイルが使用され、シンタックス要素tiles_enabled_flagがPPS中で0に等しくなるべきであることを示す。0に等しいフラグgeneral_no_tiles_flagは、ピクチャ中に2つ以上のタイルがあり得ることを示す。
[0067]図2は、プロファイル、ティア、およびレベルシンタックス構造を使用することによってシーケンスパラメータセットでコード化プロパティを示すための技法を実装し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラ(I)モードは、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
[0068]図2に示されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照フレームメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。モード選択ユニット40は、今度は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、区分ユニット48とを含む。ビデオブロックの復元のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。復元されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングする、デブロッキングフィルタも含まれ得る。所望される場合、デブロッキングフィルタは一般に、加算器62の出力をフィルタリングすることになる。また、デブロッキングフィルタに加えて追加のフィルタ(ループ内またはループ後)が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理し得る。
[0069]符号化プロセス中に、ビデオエンコーダ20はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間的な予測を行うために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は代替的に、空間的な予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
[0070]その上、区分ユニット48は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット48は、初めにフレームまたはスライスをLCUに区分し、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブCUに区分し得る。モード選択ユニット40は、さらに、LCUをサブCUに区分することを示す4分木データ構造を生成し得る。4分木のリーフノードCUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。
[0071]モード選択ユニット40は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラまたはインターのうちの1つを選択することができ、残差ブロックデータを生成するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器50に与え、参照フレームとして使用するための符号化されたブロックを復元するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器62に与える。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット56に与える。
[0072]動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(または他のコード化ユニット)内でコーディングされている現在のブロックに対する参照フレーム(または他のコード化ユニット)内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。予測ブロックは、絶対値差分和(SAD)、2乗差分和(SSD)、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるブロックに精密に一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ20は、参照フレームメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0073]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのPUについての動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの参照ピクチャリストの各々は、参照フレームメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56と動き補償ユニット44とに送る。
[0074]動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット42と動き補償ユニット44とは機能的に統合され得る。現在のビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つにおいて動きベクトルが指す予測ブロックの位置を特定し得る。加算器50は、以下で説明するように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット42はルーマ成分に対して動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
[0075]イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
[0076]たとえば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測ユニット46は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのひずみおよびレートから比率を計算し得る。
[0077]ブロック用のイントラ予測モードを選択した後、イントラ予測ユニット46は、ブロック用に選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット56に提供することができる。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ20は、(コードワードマッピングテーブルとも呼ばれる)複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブルと、様々なブロック用の符号化コンテキストの定義と、最確イントラ予測モードの指示とを含む送信されたビットストリーム構成データの中に、コンテキストの各々について使用する、イントラ予測モードインデックステーブルと修正されたイントラ予測モードインデックステーブルとを含めることができる。
[0078]ビデオエンコーダ20は、コーディングされている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
[0079]量子化の後、エントロピー符号化ユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングの後、符号化ビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、または後で送信するかもしくは取り出すためにアーカイブすることができる。
[0080]逆量子化ユニット58および逆変換ユニット60は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット44は、残差ブロックを参照フレームメモリ64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算して、参照フレームメモリ64に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
[0081]図2のビデオエンコーダ20は、符号化されるべきビデオシーケンスを決定することと、ビデオシーケンスを符号化することと、1つまたは複数のコーディングツールイネーブルビットとして符号化ビデオシーケンスについての予約済みビットシンタックス要素の1つまたは複数のビットを符号化することと、を行うように構成されたビデオエンコーダの一例を示し、ここで、1つまたは複数のコーディングツールイネーブルビットは、ビデオエンコーダによる使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す。たとえば、特定のコーディングツールがイネーブルにされている場合、符号化ビデオシーケンスは、特定のコーディングツールを使用して復号され得る。いくつかの例では、予約済みビットシンタックス要素は、profile_tier_levelシンタックス構造の一部である。profile_tier_levelシンタックス構造は、general_reserved_zero_16bits予約済みビットシンタックス構造を含む。general_reserved_zero_16bits予約済みビットシンタックス構造中のビットのうちの少なくともいくつかは、コーディングツールイネーブルビットとして使用され得る。したがって、コーディングツールイネーブルビットは、必ずしもSPSまたはVPS中の他の場所でシグナリングされる必要がない。代わりに、コーディングツールイネーブルビットは、通常ならば使用されなかったであろうgeneral_reserved_zero_16bits予約済みビットシンタックス構造中のビットを使用することによって提示され、それによって、ビデオコーディングプロパティの効率的なシグナリングをサポートし得る。profile_tier_levelシンタックス構造は、符号化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)中に含まれ得る。他の例では、profile_tier_levelシンタックス構造は、シーケンスパラメータセット(SPS)シンタックス情報中に含まれ得る。
[0082]ビデオエンコーダ20は、1つまたは複数のエンコーダデコーダ(コーデック)プロパティを示すために1つまたは複数のコーディングツールイネーブルビットを符号化し得る。たとえば、1つまたは複数のコーディングツールイネーブルビットは、符号化ビデオシーケンス、符号化ビデオシーケンスのビットストリーム、または符号化ビデオシーケンスのエレメンタリストリームについて、明示的重み付け予測がイネーブルにされているかどうか、タイルがイネーブルにされているかどうか、ウエーブフロントがイネーブルにされているかどうか、時間動きベクトル予測がイネーブルにされているかどうか、あるいはスケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうかのうちの1つまたは複数を示し得る。1つまたは複数のコーディングツールイネーブルビット中でタイルがイネーブルにされているかどうかを示すフラグをビデオエンコーダ20が符号化する一例では、1つまたは複数のコーディングツールイネーブルビットは、タイルが単独で符号化可能であるかどうかをさらに示し得る。別の例では、ビデオエンコーダ20は、タイルがイネーブルにされているかどうかを示すフラグを直接符号化することなしにタイルが単独で符号化可能であるかどうかを示すフラグを符号化する。いくつかの例では、ビデオエンコーダ20は、符号化ビデオシーケンスのビットストリームが8ビットのビット深度を有するかどうかを示すために1つまたは複数のコーディングツールイネーブルビットを符号化する。ビデオエンコーダ20はまた、予約済みビットシンタックス要素の一部としてgeneral_no_weighted_prediction_flagフラグとgeneral_no_tiles_flagフラグとを含む1つまたは複数のビットを符号化し得る。上記で説明した指示のすべては互いに無関係であり得る。
[0083]ビデオエンコーダ20は、general_reserved_zero_16bits予約済みビットシンタックス構造の一部として1つまたは複数のコーディングツールイネーブルビットを符号化し得る。いくつかの例では、ビデオエンコーダ20は、シーケンスパラメータセット(SPS)に1つまたは複数のコーディングツールイネーブルビットを符号化する。他の例では、ビデオエンコーダ20は、コード化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)の一部として1つまたは複数のコーディングツールイネーブルビットを符号化する。
[0084]符号化ビデオシーケンスのための予約済みビットシンタックス構造の一部として1つまたは複数のコーディングツールイネーブルビットを符号化することを通して、ビデオエンコーダ20は、符号化ビデオシーケンスのビデオプロパティへの軽量アクセスを可能にする。したがって、profile_tier_levelシンタックス構造を理解することができるトランスポートプロトコルを使用するデバイスは、符号化ビデオプロパティにアクセスすることが可能であり得る。
[0085]図3は、プロファイル、ティア、およびレベルシンタックス構造を再使用することによってシーケンスパラメータセットでコード化プロパティを示すための技法を実装し得るビデオデコーダ30の一例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照フレームメモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20に関して説明した符号化パスとは概して逆の復号パスを実行し得る(図2)。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
[0086]復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット70は、動きベクトルtoと他の予測シンタックス要素とを動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0087]ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた(すなわち、B、PまたはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの1つの中の参照ピクチャの1つから生成され得る。ビデオデコーダ30は、参照フレームメモリ82に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。動き補償ユニット72は、動きベクトルと他のシンタックス要素とを解析することによって現在ビデオスライスのビデオブロックについての予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスの参照ピクチャリストのうちの1つまたは複数についての構成情報と、スライスの各インター符号化ビデオブロックについての動きベクトルと、スライスの各インターコーディングビデオブロックについてのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。
[0088]動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。
[0089]逆量子化ユニット76は、ビットストリーム中で与えられ、エントロピー復号ユニット70によって復号された量子化変換係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、ビデオスライス中の各ビデオブロックについてビデオデコーダ30によって計算される量子化パラメータQPYを使用して量子化の程度を決定し、同様に、適用すべき逆量子化の程度を決定することを含み得る。
[0090]逆変換ユニット78は、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換処理を変換係数に適用して、ピクセル領域において残差ブロックを生成する。
[0091]動き補償ユニット72が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、(コーディングループ内またはコーディングループ後の)他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照フレームメモリ82に記憶される。参照フレームメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。
[0092]図3のビデオデコーダ30は、コード化ビデオシーケンスを受信することと、1つまたは複数のコーディングツールイネーブルビットとしてコード化ビデオシーケンスについての予約済みビットシンタックス要素の1つまたは複数のビットを復号することと、を行うように構成されたビデオデコーダの一例を表し、ここで、1つまたは複数のコーディングツールイネーブルビットは、ビデオデコーダによる使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す。いくつかの例では、予約済みビットシンタックス要素は、profile_tier_levelシンタックス構造の一部である。profile_tier_levelシンタックス構造は、符号化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)中に含まれ得る。他の例では、profile_tier_levelシンタックス構造は、シーケンスパラメータセット(SPS)シンタックス情報中に含まれ得る。
[0093]ビデオデコーダ30は、1つまたは複数のエンコーダデコーダ(コーデック)プロパティを決定するために1つまたは複数のコーディングツールイネーブルビットを復号し得る。たとえば、1つまたは複数のコーディングツールイネーブルビットは、符号化ビデオシーケンス、符号化ビデオシーケンスのビットストリーム、または符号化ビデオシーケンスのエレメンタリストリームについて、明示的重み付け予測がイネーブルにされているかどうか、タイルがイネーブルにされているかどうか、ウエーブフロントがイネーブルにされているかどうか、時間動きベクトル予測がイネーブルにされているかどうか、あるいはスケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうかのうちの1つまたは複数を示し得る。1つまたは複数のコーディングツールイネーブルビット中でタイルがイネーブルにされているかどうかを示すフラグをビデオデコーダ30が復号する一例では、1つまたは複数のコーディングツールイネーブルビットは、タイルが単独で符号化可能かどうかをさらに示し得る。別の例では、ビデオデコーダ30は、タイルがイネーブルにされているかどうかを示すフラグを直接復号することなしにタイルが単独で符号化可能かどうかを示すフラグを復号する。いくつかの例では、ビデオデコーダ30は、符号化ビデオシーケンスのビットストリームが8ビットのビット深度を有するかどうかを示すために1つまたは複数のコーディングツールイネーブルビットを復号する。ビデオデコーダ30はまた、予約済みビットシンタックス要素の一部としてgeneral_no_weighted_prediction_flagフラグとgeneral_no_tiles_flagフラグとを復号し得る。上記で説明した指示のすべては互いに無関係であり得る。ビデオデコーダ30は、1つまたは複数のコーディングツールイネーブルビットに基づいてビデオシーケンスを復号し得る。たとえば、ビデオデコーダ30は、復号された1つまたは複数のコーディングツールイネーブルビットによってイネーブルにされていると示された1つまたは複数のコーディングツールを使用して符号化ビデオシーケンスを復号する。
[0094]ビデオデコーダ30は、general_reserved_zero_16bits予約済みビットシンタックス構造の一部として1つまたは複数のコーディングツールイネーブルビットを復号し得る。いくつかの例では、ビデオデコーダ30は、シーケンスパラメータセット(SPS)から1つまたは複数のコーディングツールイネーブルビットを復号する。他の例では、ビデオデコーダ30は、コード化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)の一部として1つまたは複数のコーディングツールイネーブルビットを復号する。
[0095]ビデオデコーダ30は、予約済みビットシンタックス構造の一部として1つまたは複数のコーディングツールイネーブルビットを復号することを通して、符号化ビデオシーケンスのビデオプロパティへの軽量アクセスを有し得る。したがって、profile_tier_levelシンタックス構造を理解することができるトランスポートプロトコルを使用するデバイスは、符号化ビデオプロパティにアクセスすることが可能であり得る。たとえば、ビデオプロパティへの軽量アクセスを有するビデオデコーダ30は、ビットストリーム上で可変長コーディングなどのコーディングを実行することなしに、ビットストリームから1つまたは複数のコーディングイネーブルツールビットを抽出することが可能であり得る。1つまたは複数のコーディングイネーブルツールビットがVPS中にコーディングされる一例では、1つまたは複数のコーディングイネーブルツールビットがビットストリームの最初の4バイト内にあり得る。1つまたは複数のコーディングイネーブルツールビットがSPS中にコーディングされる一例では、1つまたは複数のコーディングイネーブルツールビットがSPS NALユニットを含むパケットの最初の4バイト内にあり得る。最初の4バイトは、固定長コーディングされ得、ビットストリーム中の他のバイトよりも比較的パースしやすいことがある。
[0096]図4は、本開示で説明する技法による、ビデオシーケンスを復号する例示的な方法を示すフローチャートである。図4の方法は、図1および図3のビデオデコーダ30など、本明細書で説明する任意のビデオ復号デバイスによって実行され得る。例示的な方法は、ビデオデコーダ30などのビデオデコーダによってコード化ビデオシーケンスを受信することを含む(100)。ビデオシーケンスは、たとえば、ビデオデコーダ30においてビットストリーム中で受信され得る。
[0097]本方法は、1つまたは複数のコーディングツールイネーブルビットとしてコード化ビデオシーケンスについての予約済みビットシンタックス要素の1つまたは複数のビットを復号すること、をさらに含み、予約済みビットシンタックス要素は、プロファイルおよびレベル情報を含むシンタックス構造の一部であり、1つまたは複数のコーディングツールイネーブルビットは、ビデオデコーダによる使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す(102)。プロファイルおよびレベル情報を含むシンタックス構造は、profile_tier_levelシンタックス構造であり得る。たとえば、予約済みビットシンタックス要素は、プロファイルおよびレベル情報を含むビットに連続する複数のビットを有する。すなわち、コード化ビデオシーケンスのビットストリーム中で、1つまたは複数のコーディングイネーブルツールビットを含む、予約済みビットシンタックス要素のビットは、プロファイルおよびレベル情報を示す1つまたは複数のビットに連続する。別の例では、予約済みビットシンタックス要素は、プロファイル、ティア、およびレベル情報を含むビットに連続する複数のビットを有する。
[0098]いくつかの例では、予約済みビットシンタックス要素は、プロファイルおよびレベル情報のいくつかの連続バイト内のコード化ビデオシーケンスのバイストリーム中に存在するシンタックス構造の一部である。たとえば、1つまたは複数のコーディングツールの使用可能性(enablement)を示す1つまたは複数のコーディングツールイネーブルビットは、プロファイル、ティア、またはレベル情報を搬送するために使用されるビットの数バイト前に置かれ得る。別の例では、1つまたは複数のコーディングツールの使用可能性を示す1つまたは複数のコーディングツールイネーブルビットは、プロファイル、ティア、またはレベル情報を搬送するために使用されるビットの数バイト後に置かれ得る。
[0099]また別の例では、予約済みビットシンタックス要素ならびにプロファイルおよびレベル情報を含むシンタックス構造は、1つまたは複数のコーディングイネーブルツールビットならびにプロファイル、ティア、およびレベル情報のみを含み得る。
[0100]本方法は、1つまたは複数のコーディングツールイネーブルビットがビデオデコーダによる使用のためにイネーブルされていることを示す1つまたは複数のコーディングツールを使用して、コード化ビデオシーケンスを復号することをさらに含み得る。
[0101]一例では、予約済みビットシンタックス要素は、profile_tier_levelシンタックス構造の一部である。profile_tier_levelシンタックス構造は、HEVCコーディング規格に準拠し得る。シンタックス要素は、general_reserved_zero_16bitsシンタックス要素であり得る。以下の表1に、プロファイル、ティア、およびレベルシンタックス構造の一例を与える。
[0102]シンタックス要素general_profile_spaceは、両端値を含む0〜31の範囲内のiのすべての値についてgeneral_profile_idcとgeneral_profile_compatibility_flag[i]との解釈についてのコンテキストを指定する。general_profile_spaceの値は、HEVC勧告/インターナショナル規格に準拠するビットストリームでは0に等しくなるべきである。たとえば、general_profile_spaceの値は、本開示の技法およびHEVC WD8に準拠するビットストリームでは0に等しくなるべきである。general_profile_spaceの他の値は、ITU−TおよびISO/IECによる将来の使用のために予約済みであり得る。いくつかの例では、general_profile_spaceが0に等しくない場合、ビデオデコーダ30はコード化ビデオシーケンスを無視すべきである。
[0103]シンタックス要素general_tier_flagは、HEVC WD8の添付書類A(Annex A)において指定されているようにgeneral_level_idcの解釈についてのティアコンテキストを指定する。
[0104]シンタックス要素general_profile_idcは、general_profile_spaceが0に等しくなるとき、添付書類Aにおいて指定されているようにコード化ビデオシーケンスが準拠するプロファイルを示す。HEVC規格は、ビットストリームが添付書類Aにおいて指定されるもの以外のgeneral_profile_idcの値を含むべきでないことを示す。general_profile_idcの他の値は、ITU−Tおよび/またはISO/IECによる将来の使用のために予約済みである。
[0105]1に等しいシンタックス要素general_profile_compatibility_flag[i]は、general_profile_spaceが0に等しくなるとき、添付書類Aにおいて指定されているようにコード化ビデオシーケンスがiに等しいgeneral_profile_idcによって示されるプロファイルに準拠することを示す。general_profile_spaceが0に等しくなるとき、general_profile_compatibility_flag[general_profile_idc]は1に等しくなる。general_profile_compatibility_flag[i]の値は、添付書類Aにおいてgeneral_profile_idcの許容値として指定されていないiの任意の値について0に等しくなる。
[0106]シンタックス要素general_reserved_zero_16bitsは、この勧告/国際規格に準拠するビットストリームでは0に等しくなるべきである。general_reserved_zero_16bitsの他の値は、ITU−TおよびISO/IECによる将来の使用のために予約済みである。デコーダは、general_reserved_zero_16bitsの値を無視すべきである。
[0107]ISOベースメディアファイルフォーマット、MPEG−2システム、HTTPを介した動的適応ストリーミング(DASH)、リアルタイムトランスポートプロトコル(RTP)を含むトランスポート規格は、profile_tier_levelシンタックス構造の少なくとも最初の数ビットを理解するように設計され得る。ただし、シーケンスパラメータセットまたはビデオパラメータセット中の他の追加情報はアクセスしにくい。したがって、現在のHEVC設計は、ビデオプロパティへの軽量アクセスをサポートしない。
[0108]本開示の技法に従ってコーディングされたビットストリームは、ビデオプロパティへの軽量アクセスをサポートする。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、1つまたは複数のエンコーダデコーダ(コーデック)プロパティを示すためにgeneral_reserved_zero_16bitsで提示される。たとえば、ビデオデコーダ30は、ビットストリーム中でコード化プロパティを受信し、プロパティを決定するためにシンタックス要素を復号する。いくつかの例では、コーデックプロパティを示すためにシンタックス要素のビットのすべてよりも少ないビットが使用される。
[0109]本明細書で説明する技法によれば、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために明示的重み付け予測(デフォルト値(1/2,1/2)(1,0)または(0,1)ではない)がイネーブルにされているかどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのためにタイルがイネーブルにされているかどうかのコーデックプロパティのうちの1つまたは複数を示すためにgeneral_reserved_zero_16bits中のビットのうちの1つが使用され得る。代替的に、または追加として、general_reserved_zero_16bits中のビットは、タイルが単独で復号可能にされているどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのためにウエーブフロントがイネーブルにされているかどうか、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために時間動きベクトル予測がイネーブルにされているかどうか、スケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうか、ならびに現在のビットストリームが8ビットであるかどうかを示し得る。いくつかの例では、上記の指示のすべては、互いに無関係であるか、または互いと組み合わせて使用され得る。いくつかの例では、1つまたは複数のコーデックプロパティを搬送するためにシンタックス要素のただ1つのビットが使用される。たとえば、スケーリングリストデータが存在するかどうかをシグナリングするためにgeneral_reserved_zero_16bitsの単一ビットが使用される。他の例では、1つまたは複数のコーデックプロパティを搬送するために2つ以上のビットが使用される。
[0110]以下の表2に、プロファイル、ティア、およびレベルシンタックス要素の例示的なシンタックスを与える。
[0111]1に等しいシンタックス要素general_no_weighted_prediction_flagは、コード化ビデオシーケンス中で、ピクチャが重み付け予測を用いてコーディングされず、シンタックス要素weighted_pred_flagおよびweighted_bipred_flagが、ピクチャパラメータセット(PPS)中で0に等しくなるべきであることを示す。0に等しいシンタックス要素general_no_weighted_prediction_flagは、コード化ビデオシーケンス中で、重み付け予測が使用され得ることを示す。
[0112]1に等しいシンタックス要素general_no_tiles_flagは、各ピクチャ中の1つのタイルが、コード化ビデオシーケンス中の各ピクチャについて使用され、シンタックス要素tiles_enabled_flagはピクチャパラメータセット中で0に等しくなるべきであることを示す。general_no_tiles_flagが0に等しいとき、フラグは、ピクチャ中に2つ以上のタイルがあり得ることを示す。
[0113]1に等しいシンタックス要素general_no_tile_depedency_flagは、2つ以上のタイルが使用されるとき、タイル間に相互関係がなく、ピクチャパラメータセット中のシンタックス要素loop_filter_across_tiles_enabled_flagが0に等しくなるべきであることを示す。general_no_tile_depedency_flagが0に等しいとき、フラグは、2つ以上のタイルが使用されるとき、タイル間に相互関係があり得ることを示す。
[0114]シンタックス要素general_no_tiles_flagが1に等しいとき、シンタックス要素general_no_tile_depedency_flagは0になるように予約される。
[0115]1に等しいシンタックス要素general_no_tmvp_flagは、時間動きベクトル予測がコード化ビデオシーケンス全体のためにディセーブル(disable)になっておらず、シーケンスパラメータセット(SPS)中でsps_temporal_mvp_enable_flagが0に等しくなることを示す。0に等しいシンタックス要素general_no_tmvp_flagは、時間動きベクトル予測がイネーブルにされ得ないことを示す。
[0116]1に等しいシンタックス要素general_no_scaling_list_flagは、コード化ビデオシーケンス全体の任意のピクチャの変換係数のスケーリングプロセスのためにスケーリングリストが使用されず、シンタックス要素scaling_list_enable_flagが1に等しくなるべきであることを示す。シンタックス要素general_no_scaling_list_flagを0に等しく設定することは、スケーリングリストが使用され得ることを示す。
[0117]1に等しいシンタックス要素general_bit_depth_higher_8_flagは、コード化ビデオシーケンス全体のピクチャのために8に等しいビット深度のみが使用されることを示し、0に等しいgeneral_bit_depth_higher_8_flagは、コード化ビデオシーケンス中でピクチャのためにより高い(さらにはより低い)ビット深度が使用され得ることを示す。
[0118]上記で説明したシンタックス要素general_no_weighted_prediction_flag、general_no_tiles_flag、general_no_tile_depedency_flag、general_no_tmvp_flag、general_no_scaling_list_flagおよびgeneral_bit_depth_higher_8_flagのうちの1つまたは複数は、予約済みビットシンタックス要素の1つまたは複数のビットの一部としてコーディングされ得る。ビデオデコーダ30は、符号化ビデオストリームを復号する際に使用するためのフラグの値を決定するために、予約済みビットシンタックス要素の1つまたは複数のビットを復号し得る。このようにして、シグナリングされたコーデックプロパティは、コード化ビデオシーケンス、コード化ビデオシーケンスのビットストリーム、またはコード化ビデオシーケンスのエレメンタリストリームについて、明示的重み付け予測がイネーブルにされているかどうか、タイルがイネーブルにされているかどうか、ウエーブフロントがイネーブルにされているかどうか、時間動きベクトル予測がイネーブルにされているかどうか、あるいはスケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうかのうちの1つまたは複数を示し得る。いくつかの例では、シグナリングされたコーデックプロパティは、イネーブルにされている場合、任意のタイルが単独で復号可能にされているかどうかをさらに示す。
[0119]いくつかの例では、profile_tier_levelシンタックス構造は、コード化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)中に含まれる。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、シーケンスパラメータセット(SPS)シンタックス情報中に含まれず、general_reserved_zero_16bits予約済みビットシンタックス要素の一部として含まれる。いくつかの例では、予約済みビットシンタックス要素は、general_reserved_zero_16bitsである。いくつかの例では、1つまたは複数のビットは、予約済みビットシンタックス要素の一部としてgeneral_no_weighted_prediction_flagフラグとgeneral_no_tiles_flagフラグとを含み得る。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、ビデオパラメータセット(VPS)シンタックス情報とシーケンスパラメータセット(SPS)シンタックス情報とを含む、パラメータセット中のシンタックス構造外の他のシンタックス要素として含まれない。
[0120]以下の表3に、profile_tier_levelシンタックス要素についての代替例を示す。この例では、どのツールがイネーブルにされているか、またはディセーブルにされているかを示すシーケンスパラメータセット中のフラグは、現在の位置から除去されるが、general_reserved_zero_16bitsの一部として追加され得る。代替として、シーケンスパラメータセット中のフラグの選択された1つまたは複数のフラグのみが除去され、general_reserved_zero_16bitsの一部として含まれる。代替的に、シーケンスパラメータセットから除去されたそれらのフラグは、general_no_weighted_prediction_flag、general_no_tiles_flagなどの他のフラグとともに、general_reserved_zero_16bitsの一部として共存し得る。たとえば、通常はSPSまたはVPS中の他の場所でシグナリングされたであろう1つまたは複数のフラグは、general_reserved_zero_16bitsに追加され、通常はそれらがSPSまたはVPS中でシグナリングされたであろう場所にそれらを維持するか、あるいはそこから除去し得る。
[0121]profile_tier_levelのこの例は、scaling_list_enable_flag、amp_enabled_flag、sample_adaptive_offset_enabled_flag、sps_temporal_mvp_enable_flag、およびpcm_enabled_flagのシンタックス要素を含む。
[0122]以下の表4に、例示的なシーケンスパラメータセットローバイトシーケンスペイロード(RBSP:raw byte sequence payload)シンタックスを与える。このseq_parameter_set_rbsp()シンタックスの例では、いくつかのシンタックス要素がHEVC WD8における同様の例から除去されている。これらは、pcm_enabled_flag、scaling_list_enable_flag、amp_enabled_flag、sample_adaptive_offset_enabled_flag、およびsps_temporal_mvp_enable_flagを含む。これらのフラグは、現在、profile_tier_levelシンタックス構造のgeneral_reserved_zero_16bits予約済みビット中に提示され得、ビットスチーム中の他の場所にそのような情報を複製する必要がないので、それらは、RBSPシンタックスから除去され得る。これらの削除されたシンタックス要素は、この例ではそれらがseq_parameter_set_rbsp()中に含まれないことを示すために取消し線を用いて表4中に含まれている。
[0123]図5は、本開示で説明する技法による、ビデオシーケンスを符号化する例示的な方法を示すフローチャートである。図5の方法は、図1および図2のビデオデコーダ20など、本明細書で説明する任意のビデオ符号化デバイスによって実行され得る。例示的な方法は、符号化されるべきビデオシーケンスを決定することを含む(200)。ビデオエンコーダ20は、たとえば、ビデオソース18からのビットストリーム中でビデオシーケンスを受信し得る。
[0124]本方法はまた、ビデオエンコーダによって、ビデオシーケンスを符号化することを含み得る(202)。たとえば、ビデオエンコーダ20は、1つまたは複数のコーディングツールを使用してビデオシーケンスを符号化し得る。本方法は、1つまたは複数のコーディングツールイネーブルビットとして符号化ビデオシーケンスについての予約済みビットシンタックス要素の1つまたは複数のビットを符号化すること、をさらに含み、予約済みビットシンタックス要素は、プロファイルおよびレベル情報を含むシンタックス構造の一部であり、1つまたは複数のコーディングツールイネーブルビットは、ビデオエンコーダによる使用のために1つまたは複数のコーディングツールがイネーブルにされているかどうかを示す(204)。プロファイルおよびレベル情報を含むシンタックス構造は、profile_tier_levelシンタックス構造であり得る。たとえば、予約済みビットシンタックス要素は、プロファイルおよびレベル情報を含むビットに連続する複数のビットを有する。すなわち、コード化ビデオシーケンスのビットストリーム中で、1つまたは複数のコーディングイネーブルツールビットを含む、予約済みビットシンタックス要素のビットは、プロファイルおよびレベル情報を示す1つまたは複数のビットに連続する。別の例では、予約済みビットシンタックス要素は、プロファイル、ティア、およびレベル情報を含むビットに連続する複数のビットを有する。
[0125]ビデオエンコーダ20は、コード化プロパティをシグナリングするためにシンタックス要素を符号化する。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、1つまたは複数のエンコーダデコーダ(コーデック)プロパティを示す。いくつかの例では、ビデオシーケンスを符号化することは、1つまたは複数のコーディングツールのサブセットを使用してビデオシーケンスを符号化することをさらに含む。予約済みビットシンタックス要素の1つまたは複数のビットを符号化することは、1つまたは複数のコーディングツールイネーブルビットが、1つまたは複数のコーディングツールのサブセットがイネーブルにされていることを示すように、1つまたは複数のコーディングツールイネーブルビットを符号化することをさらに含み得る。ビデオエンコーダ20は、ビデオシーケンスを符号化するためにビデオエンコーダ20が使用しなかった1つまたは複数のコーディングツールのいずれかに関連する1つまたは複数のコーディングツールイネーブルビットを、当該1つまたは複数のコーディングツールがディセーブルにされていることを示すために、符号化する。予約済みビットシンタックス要素は、HEVC WD8における将来の使用のための予約済みであるビットのセット、general_reserved_zero_16bitsであり得る。
[0126]予約済みビットシンタックス要素は、profile_tier_levelシンタックス構造の一部であり得る。profile_tier_levelシンタックス構造は、SPS中に、または代替的に、VPS中にある。たとえば、シンタックス構造は、HEVC規格に準拠するprofile_tier_levelシンタックス構造であり得、予約済みビットシンタックス要素は、profile_tier_levelシンタックス構造のgeneral_reserved_zero_16bits予約済みビットシンタックス要素であり得る。
[0127]profile_tier_levelシンタックス構造は、符号化ビデオシーケンスの複数のレイヤに適用可能な情報を含むビデオパラメータセット(VPS)中に含まれ得る。代替例では、ビデオエンコーダ20は、シーケンスパラメータセット(SPS)シンタックス情報中にある1つまたは複数のコーディングツールイネーブルビットを含み得る。他の例では、1つまたは複数のコーディングツールイネーブルビットは、SPSシンタックス情報中に含まれないが、general_reserved_zero_16bits予約済みビットシンタックス要素の一部として含まれる。SPSは、ビデオデータの各レイヤに必要とされ、その結果、複数のSPSがコーディングされ、送信される。
対照的に、VPSは、ビデオデータのすべてのレイヤについて1回だけ送られる。したがって、SPS中ではなくVPS中にprofile_tier_levelシンタックス構造を含めると、送られる全体的なビット数が低減する。言い換えれば、本開示の一例では、(ビデオデータのレイヤごとに)各SPS中にprofile_tier_levelシンタックス構造を含める必要はない。代わりに、単一のVPS中の単一のprofile_tier_levelシンタックス構造が与えられ得る。一例では、profile_tier_levelシンタックス構造は、コード化ビデオシーケンスの複数のレイヤに適用可能な情報を含むVPS中に含まれる。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、ビデオパラメータセット(VPS)シンタックス情報とシーケンスパラメータセット(SPS)シンタックス情報とを含む、パラメータセット中のシンタックス構造外の他のシンタックス要素として含まれない。すなわち、1つまたは複数のコーディングツールイネーブルビットは、シンタックス構造の外で繰り返されない。
[0128]1つまたは複数のコーディングツールイネーブルビットは、符号化ビデオシーケンス、符号化ビデオシーケンスのビットストリーム、または符号化ビデオシーケンスのエレメンタリストリーム、あるいはコード化ビデオシーケンスのオペレーションポイントについて、明示的重み付け予測がイネーブルにされているかどうか、タイルがイネーブルにされているかどうか、ウエーブフロントがイネーブルにされているかどうか、時間動きベクトル予測がイネーブルにされているかどうか、あるいはスケーリングリストデータが存在し、コード化ビデオシーケンス、ビットストリーム、またはエレメンタリストリームのために使用されるかどうかのうちの1つまたは複数を示し得る。1つまたは複数のコーディングツールイネーブルビットは、タイルがイネーブルにされている場合、任意のタイルが単独でコード化可能であることをさらに示し得る。いくつかの例では、1つまたは複数のコーディングツールイネーブルビットは、符号化ビデオシーケンスのビットストリームが8ビットのビット深度を有するかどうかを示す。
[0129]シグナリングされたコーデックプロパティは、ビットストリームが8ビットであるかどうかを示し得る。他の例では、シグナリングされたコーデックプロパティは、時間動きベクトル予測がイネーブルにされていないことを示す。いくつかの例では、general_reserved_zero_16bitsシンタックス要素は、profile_tier_levelシンタックス構造の一部である。
[0130]いくつかの例では、シーケンスパラメータセットシンタックス情報中の1つまたは複数のフラグは、シーケンスパラメータセットシンタックス情報中に含まれず、general_reserved_zero_16bitsシンタックス要素の一部として含まれる。別の例では、シーケンスパラメータセットシンタックス情報中の1つまたは複数のフラグは、ビデオパラメータセットシンタックス情報中に含まれず、general_reserved_zero_16bitsシンタックス要素の一部として含まれる。シーケンスパラメータセットシンタックス情報中でどのツールがイネーブルにされているか、またはディセーブルにされているか示す1つまたは複数のフラグは、general_reserved_zero_16bitsシンタックス要素の一部として含まれ得る。一例では、1つまたは複数のフラグ、general_no_weighted_prediction_flagフラグおよびgeneral_no_tiles_flagフラグは、general_reserved_zero_16bitsシンタックス要素の一部として含まれる。
[0131]このようにして、ビデオエンコーダ20は、いくつかのビデオプロパティが、profile_tier_levelシンタックス構造を理解するように設計されたトランスポート規格を使用してデバイスによってアクセスされ得るように、ビデオシーケンスを符号化し得る。
[0132]本明細書で説明する様々な例では、general_reserved_zero_16bits予約済みビット中で利用可能な任意のビット数(たとえば、最高16ビットの予約済みビット総数)が、選択されたコーディングツールまたは他のビデオプロパティのフラグのために使用され得る。たとえば、ビデオエンコーダ20が、本開示の技法によるフラグを用いてシグナリングされ得る8つのコーディングツールを使用する場合、ビデオエンコーダ20は、profile_tier_levelシンタックス構造の8ビットを符号化し得る。他の例では、general_reserved_zero_16bits予約済みビットの最初のn個のビットは、n個のフラグを示すために使用され得、ここにおいて、nは、両端値を含む0と16との間の整数。他の例では、n個のビットは、必ずしも最初のn個のビットであるとは限らないことがある。さらに、フラグのために使用されるn個のビットは、連続することも、連続しないこともある。
[0133]例によっては、本明細書で説明された技法のうちいずれかの、いくつかの行為またはイベントは、異なる順番で実行される可能性があり、追加され、統合され、または完全に除外され得る(たとえば、すべての説明された行為またはイベントが、本技法の実施のために必要であるとは限らない)ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。
[0134]1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0135]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
[0136]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)などの1つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素中に十分に実装され得る。
[0137]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明した1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
[0138]様々な例について説明してきた。これらおよび他の例は以下の特許請求の範囲内に入る。