JP2022537662A - ビデオエンコーディングにおける適応ループフィルタのためのクリッピングインデックスコード化 - Google Patents

Abstract

ビデオコーダは、固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化するように構成されている。ビデオコーダは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。【選択図】図１０

Description

相互参照

［０００１］
本出願は、２０１９年６月１１日に出願された米国仮出願第６２／８５９９４８号の利益を主張する、２０２０年６月９日に出願された米国特許出願第１６／８９７０４９号に対する優先権を主張し、これらのそれぞれの全内容は、参照により本明細書に組み込まれている。

［０００２］
本開示は、ビデオエンコーディングおよびビデオデコーディングに関連する。

背景

［０００３］
デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、ｅ－ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラまたは衛星無線電話機、いわゆる「スマートフォン」、ビデオ電話会議デバイス、ビデオストリーミングデバイス、および、これらに類するものを含む、幅広い範囲のデバイスに組み込むことができる。デジタルビデオデバイスは、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４、パート１０、高度ビデオコーディング（ＡＶＣ）、ＩＴＵ－Ｔ Ｈ．２６５／高効率ビデオコーディング（ＨＥＶＣ）、および、このような標準規格の拡張によって規定される標準規格に記述されているもののような、ビデオコーディング技法を実現する。ビデオデバイスは、このようなビデオコーディング技法を実現することによって、より効率的にデジタルビデオ情報を送信、受信、エンコード、デコード、および／または、記憶してもよい。

［０００４］
ビデオコーディング技法は、ビデオシーケンスに内在する冗長を低減または取り除くために、空間的（イントラピクチャー）予測、および／または、時間的（インターピクチャー）予測を含んでいる。ブロックベースのビデオコーディングに対して、ビデオスライス（例えば、ビデオピクチャーまたはビデオピクチャーの一部分）は、コーディングツリーユニット（ＣＴＵ）、コーディングユニット（ＣＵ）および／またはコーディングノードとして呼ばれることもあるかもしれないビデオブロックに区分してもよい。ピクチャーのイントラコード化された（Ｉ）スライスにおけるビデオブロックは、同じピクチャーにおける隣接ブロック中の参照サンプルに関する空間的予測を使用してエンコードされる。ピクチャーのインターコード化された（ＰまたはＢ）スライスにおけるビデオブロックは、同じピクチャーにおける隣接ブロック中の参照サンプルに関する空間的予測、または、他の参照ピクチャーにおける参照サンプルに関する時間的予測を使用してもよい。ピクチャーは、フレームとして呼ばれることがあり、参照ピクチャーは参照フレームとして呼ばれることがある。

概要

［０００５］
一般的に、本開示は、ビデオコーディングにおける適応ループフィルタ（ＡＬＦ）のためのクリッピングインデックスをシグナリングするための技法を説明する。本開示の技法は、ＩＴＵ－Ｔ Ｈ．２６５、高効率ビデオコーディング（ＨＥＶＣ）標準規格に準拠するコーデックのような既存のビデオコーデックに適用してもよく、または、バーサタイルビデオコーディング（ＶＶＣ）のような現在開発中の標準規格におけるコーディングツールとして、および、他の将来のビデオコーディング標準規格に使用してもよい。

［０００６］
１つの例では、ビデオデータをコード化する方法は、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化することと、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用することとを含んでいる。

［０００７］
別の例では、ビデオデータをコード化するためのデバイスは、ビデオデータを記憶するように構成されているメモリと、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、ＡＬＦクリッピングインデックスをコード化するようにと、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用するように構成されている１つ以上の処理回路とを含んでいる。

［０００８］
別の例では、ビデオデータをコード化するためのデバイスは、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、ＡＬＦクリッピングインデックスをコード化する手段と、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用する手段とを含んでいる。

［０００９］
別の例では、コンピュータ読取可能記憶媒体は、命令によりエンコードされており、命令は、実行されるときに、プログラマブルプロセッサに、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、ＡＬＦクリッピングインデックスをコード化させ、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用させる。

［００１０］
１つ以上の例の詳細が、添付の図面および以下の説明に記載されている。他の特徴、目的および利点は、説明、図面および特許請求の範囲から明らかになるであろう。

［００１１］ 図１は、本開示の技法を実行してもよい、例示的なビデオエンコーディングおよびデコーディングシステムを図示するブロック図である。 ［００１２］ 図２Ａは、例示的な５×５ダイヤモンド形状適応ループフィルタ（ＡＬＦ）サポートを図示する概念図である。 ［００１３］ 図２Ｂは、例示的な７×７ダイヤモンド形状ＡＬＦサポートを図示する概念図である。 ［００１４］ 図３は、例示的な５×５ダイヤモンド形状フィルタサポートを図示する概念図である。 ［００１５］ 図４Ａは、異なる幾何学的変換を有する例示的な５×５フィルタサポートを図示する概念図である。 図４Ｂは、異なる幾何学的変換を有する例示的な５×５フィルタサポートを図示する概念図である。 図４Ｃは、異なる幾何学的変換を有する例示的な５×５フィルタサポートを図示する概念図である。 ［００１６］ 図５Ａは、例示的な４分ツリー２分ツリー（ＱＴＢＴ）構造と、対応するコーディングツリーユニット（ＣＴＵ）とを図示する概念図である。 図５Ｂは、例示的な４分ツリー２分ツリー（ＱＴＢＴ）構造と、対応するコーディングツリーユニット（ＣＴＵ）とを図示する概念図である。 ［００１７］ 図６は、本開示の技法を実行してもよい、例示的なビデオエンコーダを図示するブロック図である。 ［００１８］ 図７は、本開示の技法を実行してもよい、例示的なビデオデコーダを図示するブロック図である。 ［００１９］ 図８は、ビデオデータの現在ピクチャーの現在ブロックをエンコードするための例示的な方法を図示するフローチャートである。 ［００２０］ 図９は、ビデオデータの現在ピクチャーの現在ブロックをデコードするための例示的な方法を図示するフローチャートである。 ［００２１］ 図１０は、本開示の１つ以上の技法による、ビデオデータをコード化するための例示的な動作を図示するフローチャートである。

詳細な説明

［００２２］
ビデオエンコーダおよびビデオデコーダは、デコードされたビデオ信号中のピクチャーのサンプルに適応ループフィルタ（ＡＬＦ）を適用してもよい。ＡＬＦの適用は、デコードされたビデオ信号の品質を向上させるかもしれない。ＡＬＦの適用の間に、ビデオコーダ（例えば、ビデオエンコーダまたはビデオデコーダ）は、現在サンプルに対するフィルタされた値を決定してもよい。現在サンプルに対するフィルタされた値を決定するために、ビデオコーダは、現在サンプルに対するＡＬＦフィルタサポートのクリップされたサンプルに、対応するフィルタ係数を乗算してもよい。サポートは、フィルタされているサンプルに対する値を導出するために使用されるサンプルのセットである。ビデオコーダは、その後、結果的に得られた乗算積の和に、現在サンプルの値を加算することにより、現在サンプルに対するフィルタされた値を決定してもよい。

［００２３］
上述のように、ビデオコーダは、クリッピングされたサンプルに、対応するフィルタ係数を乗算する。クリッピングは、クリッピング値のセットにより制御される。クリッピング値は、サンプルの値における上限および下限を指定する。ビデオコーダは、異なる状況において、異なるクリッピング値を使用してもよい。したがって、ビデオエンコーダは、クリッピング値の適用可能なセットのインデックス（すなわち、ＡＬＦクリッピングインデックス）をシグナリングしてもよい。例えば、ビデオエンコーダは、適応パラメータセット（ＡＰＳ）中で、ＡＬＦクリッピングインデックスをシグナリングしてもよい。

［００２４］
ＶＶＣテストモデル５．０（ＶＴＭ－５．０）（Ｃｈｅｎ氏ら，「バーサタイルビデオコーディングおよびテストモデル５（ＶＴＭ５）に対するアルゴリズム説明」、ＩＴＵ－Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＯ１１のジョイントビデオエキスパートチーム（ＪＶＥＴ）、第１４回ミーティング、スイス国、ジュネーブ、２０１９年３月１９日～２７日、ドキュメントＪＶＥＴ－Ｎ１００１）では、ＡＬＦクリッピングインデックスは、指数ゴロム（ｅｘｐ－Ｇｏｌｏｍｂ）コードを使用してシグナリングされる。ｅｘｐ－ＧｏｌｏｍｂコードとしてＡＬＦクリッピングインデックスをシグナリングすることは、デコーディングプロセスを速度低下させるかもしれない。その理由は、ｅｘｐ－Ｇｏｌｏｍｂコードの意味を決定することは、複数の比較動作を実行することを伴うかもしれず、これは、比較的遅くなりがちであるからである。

［００２５］
本開示は、この問題を取り扱うことができる。本明細書で説明するように、ビデオコーダ（例えば、ビデオエンコーダまたはビデオデコーダ）は、固定長符号なし整数として、ＡＬＦクリッピングインデックスをコード化してもよい。ビデオコーダは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。ＡＬＦクリッピングインデックスが固定長符号なし整数としてシグナリングされるので、ビデオデコーダは、デコーディングプロセスをより速く実行することができるかもしれない。

［００２６］
図１は、本開示の技法を実行してもよい、例示的なビデオエンコーディングおよびデコーディングシステム１００を図示するブロック図である。本開示の技法は、一般的に、ビデオデータをコード化（エンコードおよび／またはデコード）することに向けられている。一般的に、ビデオデータは、ビデオを処理するための任意のデータを含んでいる。したがって、ビデオデータは、生のエンコードされていないビデオ、エンコードされたビデオ、デコードされた（例えば、再構築された）ビデオ、および、シグナリングデータのようなビデオメタデータを含んでいてもよい。

［００２７］
図１に示すように、システム１００は、この例では、宛先デバイス１１６によってデコードされ、表示されることになる、エンコードされたビデオデータを提供する、発信元デバイス１０２を含んでいる。特に、発信元デバイス１０２は、コンピュータ読取可能媒体１１０を介して、ビデオデータを宛先デバイス１１６に提供する。発信元デバイス１０２および宛先デバイス１１６は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、スマートフォンのような電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス、または、これらに類するものを含む、広範囲のデバイスのうちのいずれを備えていてもよい。いくつかのケースでは、発信元デバイス１０２および宛先デバイス１１６は、ワイヤレス通信のために備えられてもよく、したがって、ワイヤレス通信デバイスとして呼ばれることがある。

［００２８］
図１の例では、発信元デバイス１０２は、ビデオソース１０４と、メモリ１０６と、ビデオエンコーダ２００と、出力インターフェース１０８とを含んでいる。宛先デバイス１１６は、入力インターフェース１２２と、ビデオデコーダ３００と、メモリ１２０と、ディスプレイデバイス１１８とを含んでいる。本開示によると、発信元デバイス１０２のビデオエンコーダ２００および宛先デバイス１１６のビデオデコーダ３００は、ビデオエンコーディングにおける適応ループフィルタのためのクリッピングインデックスをシグナリングするための技法を適用するように構成されていてもよい。したがって、発信元デバイス１０２はビデオエンコーディングデバイスの例を表す一方で、宛先デバイス１１６はビデオデコーディングデバイスの例を表している。他の例では、発信元デバイスおよび宛先デバイスは、他のコンポーネントまたは構成を含んでいてもよい。例えば、発信元デバイス１０２は、外部カメラのような外部ビデオソースからビデオデータを受け取ってもよい。同様に、宛先デバイス１１６は、統合されたディスプレイデバイスを含むよりもむしろ、外部ディスプレイデバイスとインターフェースしていてもよい。

［００２９］
図１に示されているシステム１００は１つの例にすぎない。一般的に、任意のデジタルビデオエンコーディングおよび／またはデコーディングデバイスが、ビデオエンコーディングにおける適応ループフィルタのためのクリッピングインデックスをシグナリングするための技法を実行してもよい。発信元デバイス１０２および宛先デバイス１１６は、発信元デバイス１０２が宛先デバイス１１６への送信のためにコード化されたビデオデータを発生させる、このようなコーディングデバイスの例にすぎない。本開示は、データのコーディング（エンコーディングおよび／またはデコーディング）を実行するデバイスとして「コーディング」デバイスに言及する。したがって、ビデオエンコーダ２００およびビデオデコーダ３００は、コーディングデバイスの例を、特に、それぞれビデオエンコーダおよびビデオデコーダを表している。いくつかの例では、デバイス１０２、１１６は、デバイス１０２、１１６のそれぞれがビデオエンコーディングコンポーネントとビデオデコーディングコンポーネントとを含むように、実質的に対称的に動作してもよい。したがって、システム１００は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、または、ビデオ電話に対する、発信元デバイス１０２と宛先デバイス１１６との間の一方向または双方向ビデオ送信をサポートしてもよい。

［００３０］
一般的に、ビデオソース１０４は、ビデオデータ（すなわち、生のエンコードされていないビデオデータ）のソースを表し、ビデオデータの（「フレーム」としても呼ばれる）シーケンシャルな一連のピクチャーを、ピクチャーに対するデータをエンコードするビデオエンコーダ２００に提供する。発信元デバイス１０２のビデオソース１０４は、ビデオカメラのようなビデオキャプチャデバイス、以前にキャプチャされた生のビデオを含んでいるビデオアーカイブ、および／または、ビデオコンテンツプロバイダからビデオを受け取るためのビデオフィードインターフェースを含んでいてもよい。さらなる代替として、ビデオソース１０４は、ソースビデオとしてのコンピュータグラフィックスベースのデータを、または、ライブビデオとアーカイブビデオとコンピュータ発生ビデオとの組み合わせを発生させてもよい。各ケースにおいて、ビデオエンコーダ２００は、キャプチャされた、事前キャプチャされた、または、コンピュータが発生させたビデオデータをエンコードする。ビデオエンコーダ２００は、（ときには「表示順序」として呼ばれる）受け取った順序から、コーディングのためのコーディング順序にピクチャーを再構成してもよい。ビデオエンコーダ２００は、エンコードされたビデオデータを含むビットストリームを発生させてもよい。発信元デバイス１０２は、その後、例えば、宛先デバイス１１６の入力インターフェース１２２による受け取りおよび／または取り出しのために、出力インターフェース１０８を介して、コンピュータ読取可能媒体１１０上に、エンコードされたビデオデータを出力してもよい。

［００３１］
発信元デバイス１０２のメモリ１０６および宛先デバイス１１６のメモリ１２０は、汎用メモリを表している。いくつかの例では、メモリ１０６、１２０は、生のビデオデータ、例えば、ビデオソース１０４からの生ビデオと、ビデオデコーダ３００からの生のデコードされたビデオデータとを記憶してもよい。追加的にまたは代替的に、メモリ１０６、１２０は、例えば、ビデオエンコーダ２００およびビデオデコーダ３００それぞれによって実行可能なソフトウェア命令を記憶していてもよい。この例では、メモリ１０６およびメモリ１２０は、ビデオエンコーダ２００およびビデオデコーダ３００とは別個に示されているが、ビデオエンコーダ２００およびビデオデコーダ３００はまた、機能的に同様または同等の目的のために内部メモリを含んでいてもよいことを理解すべきである。さらに、メモリ１０６、１２０は、例えば、ビデオエンコーダ２００から出力され、ビデオデコーダ３００に入力される、エンコードされたビデオデータを記憶してもよい。いくつかの例では、メモリ１０６、１２０の一部分は、１つ以上のビデオバッファとして割り振られ、例えば、生のデコードされたおよび／またはエンコードされたビデオデータを記憶してもよい。

［００３２］
コンピュータ読取可能媒体１１０は、発信元デバイス１０２から宛先デバイス１１６へとエンコードされたビデオデータを転送することが可能な任意のタイプの媒体またはデバイスを表していてもよい。１つの例では、コンピュータ読取可能媒体１１０は、発信元デバイス１０２が、例えば、無線周波数ネットワークまたはコンピュータベースのネットワークを介して、エンコードされたビデオデータをリアルタイムで宛先デバイス１１６に直接送信することを可能にする通信媒体を表している。ワイヤレス通信プロトコルのような通信標準規格にしたがって、出力インターフェース１０８は、エンコードされたビデオデータを含む送信信号を変調してもよく、入力インターフェース１２２は、受け取った送信信号を復調してもよい。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つ以上の物理送信ラインのような、何らかのワイヤレスまたはワイヤード通信媒体を備えていてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、または、インターネットのようなグローバルネットワークのような、パケットベースのネットワークの一部を形成していてもよい。通信媒体は、ルータ、スイッチ、基地局、または、発信元デバイス１０２から宛先デバイス１１６への通信を容易にするのに役立つかもしれない他の何らかの機器を含んでいてもよい。

［００３３］
いくつかの例では、コンピュータ読取可能媒体１１０は、記憶デバイス１１２を含んでいてもよい。発信元デバイス１０２は、出力インターフェース１０８から記憶デバイス１１２にエンコードされたデータを出力してもよい。同様に、宛先デバイス１１６は、入力インターフェース１２２を介して、記憶デバイス１１２からのエンコードされたデータにアクセスしてもよい。記憶デバイス１１２は、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは、エンコードされたビデオデータを記憶するための他の何らかの適切なデジタル記憶媒体のような、さまざまな分散またはローカルにアクセスされるデータ記憶媒体のいずれかを含んでいてもよい。

［００３４］
いくつかの例では、コンピュータ読取可能媒体１１０は、ファイルサーバ１１４を、または、発信元デバイス１０２によって発生されたエンコードされたビデオデータを記憶してもよい別の中間記憶デバイスを含んでいてもよい。発信元デバイス１０２は、エンコードされたビデオデータを、ファイルサーバ１１４に、または、発信元デバイス１０２によって発生されたエンコードされたビデオを記憶してもよい別の中間記憶デバイスに出力してもよい。宛先デバイス１１６は、ストリーミングまたはダウンロードを介して、ファイルサーバ１１４からの記憶されているビデオデータにアクセスしてもよい。ファイルサーバ１１４は、エンコードされたビデオを記憶することと、宛先デバイス１１６にエンコードされたビデオを送信することとができる、任意のタイプのサーバデバイスであってもよい。ファイルサーバ１１４は、（例えば、ウェブサイトに対する）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、コンテンツ配信ネットワークデバイス、または、ネットワーク接続記憶（ＮＡＳ）デバイスを表していてもよい。宛先デバイス１１６は、インターネット接続を含む任意の標準的なデータ接続を通して、ファイルサーバ１１４からのエンコードされたビデオデータにアクセスしてもよい。これは、ファイルサーバ１１４上に記憶されている、エンコードされたビデオデータにアクセスするのに適している、ワイヤレスチャネル（例えば、Ｗｉ－Ｆｉ接続）、ワイヤード接続（例えば、デジタル加入者線（ＤＳＬ）、ケーブルモデム等）、または、その両方の組み合わせを含んでいてもよい。ファイルサーバ１１４および入力インターフェース１２２は、ストリーミング送信プロトコル、ダウンロード送信プロトコル、または、これらの組み合わせにしたがって動作するように構成されていてもよい。

［００３５］
出力インターフェース１０８および入力インターフェース１２２は、ワイヤレス送信機／受信機、モデム、ワイヤードネットワーキングコンポーネント（例えば、イーサネット（登録商標）カード）、さまざまなＩＥＥＥ８０２．１１標準規格のいずれかにしたがって動作するワイヤレス通信コンポーネント、または、他の物理コンポーネントを表していてもよい。出力インターフェース１０８および入力インターフェース１２２がワイヤレスコンポーネントを備えている例では、出力インターフェース１０８および入力インターフェース１２２は、４Ｇ、４Ｇ－ＬＴＥ（登録商標）（ロングタームエボリューション）、ＬＴＥアドバンスト、５Ｇ、または、これらに類するもののようなセルラ通信標準規格にしたがって、エンコードされたビデオデータのようなデータを転送するように構成されていてもよい。出力インターフェース１０８がワイヤレス送信機を備えているいくつかの例では、出力インターフェース１０８および入力インターフェース１２２は、ＩＥＥＥ８０２．１１仕様、ＩＥＥＥ８０２．１５仕様（例えば、ＺｉｇＢｅｅ（商標））、Ｂｌｕｅｔｏｏｔｈ（登録商標）（商標）標準規格、または、これらに類するもののような他のワイヤレス標準規格にしたがって、エンコードされたビデオデータのようなデータを転送するように構成されていてもよい。いくつかの例では、発信元デバイス１０２および／または宛先デバイス１１６は、それぞれのシステムオンチップ（ＳｏＣ）デバイスを含んでいてもよい。例えば、発信元デバイス１０２は、ビデオエンコーダ２００および／または出力インターフェース１０８に備わる機能性を実行するためのＳｏＣデバイスを含んでいてもよく、宛先デバイス１１６は、ビデオデコーダ３００および／または入力インターフェース１２２に備わる機能性を実行するＳｏＣデバイスを含んでいてもよい。

［００３６］
本開示の技法は、無線テレビ放送、ケーブルテレビ送信、衛星テレビ送信、ＨＴＴＰを通した動的アダプティブストリーミング（ＤＡＳＨ）のようなインターネットストリーミングビデオ送信、データ記憶媒体上にエンコードされたデジタルビデオ、データ記憶媒体上に記憶されているデジタルビデオのデコーディング、または、他のアプリケーションのような、さまざまなマルチメディアアプリケーションのうちのいずれかをサポートするビデオコーディングに適用してもよい。

［００３７］
宛先デバイス１１６の入力インターフェース１２２は、コンピュータ読取可能媒体１１０（例えば、通信媒体、記憶デバイス１１２、ファイルサーバ１１４、または、これらに類するもの）からエンコードされたビデオビットストリームを受け取る。エンコードされたビデオビットストリームは、ビデオブロックまたは他のコード化されたユニット（例えば、スライス、ピクチャー、ピクチャーのグループ、シーケンス、または、これらに類するもの）の特性および／または処理を記述する値を有するシンタックス要素のような、ビデオエンコーダ２００によって規定され、ビデオデコーダ３００によっても使用されるシグナリング情報を含んでいてもよい。ディスプレイデバイス１１８は、デコードされたビデオデータのデコードされたピクチャーをユーザに表示する。ディスプレイデバイス１１８は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または、別のタイプのディスプレイデバイスのような、さまざまなディスプレイデバイスのうちのいずれかを表していてもよい。

［００３８］
図１には示されていないが、いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、それぞれオーディオエンコーダおよび／またはオーディオデコーダと統合されていてもよく、適切なＭＵＸ－ＤＥＭＵＸユニットあるいは他のハードウェアおよび／またはソフトウェアを含んでいて、共通のデータストリームにおけるオーディオおよびビデオの両方を含む多重化されたストリームを取り扱ってもよい。適用可能である場合には、ＭＵＸ－ＤＥＭＵＸユニットは、ＩＴＵ．Ｈ．２２３マルチプレクサプロトコル、または、ユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルにしたがっていてもよい。

［００３９］
ビデオエンコーダ２００およびビデオデコーダ３００はそれぞれ、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、または、これらの組み合わせのような、さまざまな適したエンコーダおよび／またはデコーダ回路のいずれかとして実現してもよい。技法が部分的にソフトウェアで実現されるとき、デバイスは、適切な、非一時的コンピュータ読取可能媒体においてソフトウェアに対する命令を記憶していてもよく、１つ以上のプロセッサを使用して、ハードウェアにおいて命令を実行して、本開示の技法を実行してもよい。ビデオエンコーダ２００およびビデオデコーダ３００のそれぞれは、１つ以上のエンコーダまたはデコーダ中に含まれていてもよく、エンコーダまたはデコーダのどちらかは、それぞれのデバイスにおいて、組み合わされたエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合されていてもよい。ビデオエンコーダ２００および／またはビデオデコーダ３００を含むデバイスは、集積回路、マイクロプロセッサ、および／または、セルラ電話機のようなワイヤレス通信デバイスを備えていてもよい。

［００４０］
ビデオエンコーダ２００およびビデオデコーダ３００は、高効率ビデオコーディング（ＨＥＶＣ）としても呼ばれるＩＴＵ－Ｔ Ｈ．２６５のようなビデオコーディング標準規格に、または、マルチビューおよび／またはスケーラブルビデオコーディング拡張のような、高効率ビデオコーディング（ＨＥＶＣ）に対する拡張にしたがって動作してもよい。代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、バーサタイルビデオコーディング（ＶＶＣ）としても呼ばれるＩＴＵ－Ｔ Ｈ．２６６のような、他のプロプライエタリまたは業界標準規格にしたがって動作してもよい。ＶＶＣ標準規格の最近のドラフトは、ブロスらにおける「バーサタイルビデオコーディング（ドラフト５）」、ＩＴＵ－Ｔ ＳＧ１６ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１のジョイントビデオエキスパートチーム（ＪＶＥＴ）、第１４回ミーティング：スイス国ジュネーブ、２０１９年３月１９日～２７日、ＪＶＥＴ－Ｍ１００１－ｖ３（以下「ＶＶＣドラフト５」）で説明されている。しかしながら、本開示の技術は、何らかの特定のコーディング標準規格には限定されない。

［００４１］
一般的に、ビデオエンコーダ２００およびビデオデコーダ３００は、ピクチャーのブロックベースコーディングを実行してもよい。「ブロック」という用語は、一般的に、処理される（例えば、エンコードされる、デコードされる、または、そうでなければ、エンコーディングおよび／またはデコーディングプロセスにおいて使用される）データを含む構造を指している。例えば、ブロックは、ルミナンスデータおよび／またはクロミナンスデータのサンプルの２次元行列を含んでいてもよい。一般的に、ビデオエンコーダ２００およびビデオデコーダ３００は、ＹＵＶ（例えば、Ｙ、Ｃｂ、Ｃｒ）フォーマットで表されるビデオデータをコード化してもよい。すなわち、ピクチャーのサンプルに対する赤、緑および青（ＲＧＢ）データをコード化するよりもむしろ、ビデオエンコーダ２００およびビデオデコーダ３００は、ルミナンス成分とクロミナンス成分とをコード化してもよく、クロミナンス成分は、赤の色相と青の色相の両方のクロミナンス成分を含んでいてもよい。いくつかの例では、ビデオエンコーダ２００は、エンコーディングの前に、受け取ったＲＧＢフォーマットされたデータをＹＵＶ表現に変換し、ビデオデコーダ３００は、ＹＵＶ表現をＲＧＢフォーマットに変換する。代替的に、（図示されていない）前処理および後処理ユニットがこれらの変換を実行してもよい。

［００４２］
本開示は、一般的に、ピクチャーのデータをエンコードまたはデコードするプロセスを含むように、ピクチャーのコーディング（例えば、エンコーディングおよびデコーディング）に言及しているかもしれない。同様に、本開示は、ブロックに対するデータをエンコードまたはデコードするプロセス、例えば、予測および／または残差コーディングを含むように、ピクチャーのブロックのコーディングに言及しているかもしれない。エンコードされたビデオビットストリームは、一般的に、コーディング決定（例えば、コーディングモード）とブロックへのピクチャーの区分とを表す、シンタックス要素に対する一連の値を含んでいる。したがって、ピクチャーまたはブロックをコード化することへの言及は、一般的に、ピクチャーまたはブロックを形成するシンタックス要素に対する値をコード化することとして理解すべきである。

［００４３］
ＨＥＶＣは、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ）および変換ユニット（ＴＵ）を含む、さまざまなブロックを規定する。ＨＥＶＣにしたがうと、（ビデオエンコーダ２００のような）ビデオコーダは、４分ツリー構造にしたがって、コーディングツリーユニット（ＣＴＵ）をＣＵに区分する。すなわち、ビデオコーダは、ＣＴＵおよびＣＵを４つの等しい、オーバーラップしない正方形に区分し、４分ツリーの各ノードは、ゼロまたは４つの子ノードのいずれかを有する。子ノードのないノードは、「リーフノード」として呼ばれることがあり、このようなリーフノードのＣＵは、１つ以上のＰＵおよび／または１つ以上のＴＵを含んでいてもよい。ビデオコーダは、ＰＵとＴＵとをさらに区分してもよい。例えば、ＨＥＶＣでは、残差４分ツリー（ＲＱＴ）はＴＵの区分を表している。ＨＥＶＣでは、ＰＵはインター予測データを表す一方で、ＴＵは残差データを表している。イントラ予測されるＣＵは、イントラモードインジケーションのようなイントラ予測情報を含んでいる。

［００４４］
別の例として、ビデオエンコーダ２００およびビデオデコーダ３００は、ＶＶＣにしたがって動作するように構成されていてもよい。ＶＶＣによると、（ビデオエンコーダ２００のような）ビデオコーダは、ピクチャーを複数のＣＴＵに区分する。成分のＣＴＢへの分割が区分であるように、コーディングツリーブロック（ＣＴＢ）は、Ｎの何らかの値に対するサンプルのＮ×Ｎブロックであってもよい。ＶＶＣにおいて、ＣＴＵは、ルーマサンプルのＣＴＢとして、３つのサンプルアレイを有するピクチャーのクロマサンプルの２つの対応するＣＴＢとして、あるいは、モノクロームピクチャーまたはサンプルをコード化するために使用される３つの別個の色平面およびシンタックス構造を使用してコード化されるピクチャーのサンプルのＣＴＢとして、規定されていてもよい。

［００４５］
ビデオエンコーダ２００は、４分ツリー－２分ツリー（ＱＴＢＴ）構造またはマルチタイプツリー（ＭＴＴ）構造のようなツリー構造にしたがって、ＣＴＵを区分してもよい。ＱＴＢＴ構造は、ＨＥＶＣのＣＵとＰＵとＴＵとの間の分離のような、複数の区分タイプの概念を除去する。ＱＴＢＴ構造は、４分ツリー区分にしたがって区分される第１のレベルと、２分ツリー区分にしたがって区分される第２のレベルと、の２つのレベルを含んでいる。ＱＴＢＴ構造のルートノードはＣＴＵに対応する。２分ツリーのリーフノードは、コーディングユニット（ＣＵ）に対応する。

［００４６］
ＭＴＴ区分構造では、４分ツリー（ＱＴ）区分を、２分ツリー（ＢＴ）区分を、および、３分ツリー（ＴＴ）区分の１つ以上のタイプを使用して、ブロックを区分してもよい。３分ツリー区分は、ブロックが３つのサブブロックに分割される区分である。いくつかの例では、３分ツリー区分は、中心を通して元のブロックを分けずに、ブロックを３つのサブブロックに分ける。ＭＴＴにおける区分タイプ（例えば、ＱＴ、ＢＴおよびＴＴ）は、対称または非対称であってもよい。

［００４７］
いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、単一のＱＴＢＴまたはＭＴＴ構造を使用して、ルミナンス成分とクロミナンス成分のそれぞれを表してもよい一方で、他の例では、ビデオエンコーダ２００およびビデオデコーダ３００は、ルミナンス成分のために１つのＱＴＢＴ／ＭＴＴ構造と、両方のクロミナンス成分のために別のＱＴＢＴ／ＭＴＴ構造（または、それぞれのクロミナンス成分のために２つのＱＴＢＴ／ＭＴＴ構造）のように、２つ以上のＱＴＢＴまたはＭＴＴ構造を使用してもよい。

［００４８］
ビデオエンコーダ２００およびビデオデコーダ３００は、ＨＥＶＣ毎の４分ツリー区分、ＱＴＢＴ区分、ＭＴＴ区分、または、他の区分構造を使用するように構成されていてもよい。説明のために、本開示の技法の説明は、ＱＴＢＴ区分に関して提示する。しかしながら、本開示の技法はまた、４分ツリー区分、または、他のタイプの区分も同様に使用するように構成されているビデオコーダに適用してもよいことを理解されたい。

［００４９］
本開示は、「Ｎ×Ｎ」および「ＮバイＮ」を交換可能に使用して、垂直寸法および水平寸法に関する（ＣＵまたは他のビデオブロックのような）ブロックのサンプル寸法、例えば、１６×１６サンプルまたは１６バイ１６サンプルを指すかもしれない。一般的に、１６×１６のＣＵは、垂直方向に１６個のサンプルを有し（ｙ＝１６）、水平方向に１６個のサンプルを有する（ｘ＝１６）。同様に、Ｎ×ＮのＣＵは、一般的に、垂直方向にＮ個のサンプルを有し、水平方向にＮ個のサンプルを有し、Ｎは非負整数値を表している。ＣＵ中のサンプルは、行および列に配置されていてもよい。さらに、ＣＵは、必ずしも水平方向に垂直方向と同じ数のサンプルを有する必要はない。例えば、ＣＵはＮ×Ｍのサンプルを備えていてもよく、Ｍは必ずしもＮに等しいとは限らない。

［００５０］
ビデオエンコーダ２００は、予測および／または残差情報を、ならびに、他の情報を表す、ＣＵに対するビデオデータをエンコードする。予測情報は、ＣＵに対する予測ブロックを形成するために、ＣＵがどのように予測されることになるかを示している。残差情報は、一般的に、エンコーディング前のＣＵのサンプルと予測ブロックとの間のサンプル毎の差分を表している。

［００５１］
ＣＵを予測するために、ビデオエンコーダ２００は、一般的に、インター予測またはイントラ予測を通して、ＣＵに対する予測ブロックを形成してもよい。インター予測は、一般的に、以前にコード化されたピクチャーのデータからＣＵを予測することを指す一方で、イントラ予測は、一般的に、同じピクチャーの以前にコード化されたデータからＣＵを予測することを指している。インター予測を実行するために、ビデオエンコーダ２００は、１つ以上の動きベクトルを使用して、予測ブロックを発生させてもよい。ビデオエンコーダ２００は、一般的に、動きサーチを実行して、例えば、ＣＵと参照ブロックとの間の差分に関して、ＣＵに密接に一致する参照ブロックを識別してもよい。ビデオエンコーダ２００は、絶対差分の和（ＳＡＤ）、二乗差分の和（ＳＳＤ）、平均絶対差分（ＭＡＤ）、平均二乗差分（ＭＳＤ）、または、他のこのような差分計算を使用して、差分メトリックを計算し、参照ブロックが現在ＣＵに密接に一致するか否かを決定してもよい。いくつかの例では、ビデオエンコーダ２００は、単方向予測または双方向予測を使用して、現在ＣＵを予測してもよい。

［００５２］
ＶＶＣのいくつかの例はまた、インター予測モードと見なしてもよいアフィン動き補償モードを提供する。アフィン動き補償モードでは、ビデオエンコーダ２００は、ズームインまたはズームアウト、回転、透視動き、または、他の不規則な動きタイプのような、並進しない動きを表す２つ以上の動きベクトルを決定してもよい。

［００５３］
イントラ予測を実行するために、ビデオエンコーダ２００は、イントラ予測モードを選択して、予測ブロックを発生させてもよい。ＶＶＣのいくつかの例は、さまざまな方向性モードとともに、ｐｌａｎａｒモードおよびＤＣモードを含む、６７個のイントラ予測モードを提供する。一般的に、ビデオエンコーダ２００は、現在ブロックのサンプルを予測する、現在ブロック（例えば、ＣＵのブロック）に隣接するサンプルを記述するイントラ予測モードを選択する。ビデオエンコーダ２００がラスター走査順序（左から右、上から下）でＣＴＵおよびＣＵをコード化すると仮定すると、このようなサンプルは、一般的に、現在ブロックと同じピクチャー中で、現在ブロックの上、左上または左にあってもよい。

［００５４］
ビデオエンコーダ２００は、現在ブロックに対する予測モードを表すデータをエンコードする。例えば、インター予測モードに対して、ビデオエンコーダ２００は、さまざまな利用可能なインター予測モードのうちのどれが使用されるかを表すデータとともに、対応するモードに対する動き情報をエンコードしてもよい。単方向または双方向インター予測に対して、例えば、ビデオエンコーダ２００は、高度動きベクトル予測（ＡＭＶＰ）またはマージモードを使用して、動きベクトルをエンコードしてもよい。ビデオエンコーダ２００は、類似するモードを使用して、アフィン動き補償モードに対する動きベクトルをエンコードしてもよい。

［００５５］
ブロックのイントラ予測またはインター予測のような予測に続いて、ビデオエンコーダ２００は、ブロックに対する残差データを計算してもよい。残差ブロックのような残差データは、ブロックと、対応する予測モードを使用して形成された、ブロックに対する予測ブロックとの間の、サンプル毎の差分を表している。ビデオエンコーダ２００は、１つ以上の変換を残差ブロックに適用して、サンプルドメインの代わりに変換ドメインにおいて、変換されたデータを生成させてもよい。例えば、ビデオエンコーダ２００は、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または、概念的に類似する変換を残差ビデオデータに適用してもよい。さらに、ビデオエンコーダ２００は、モード依存非分離２次変換（ＭＤＮＳＳＴ）、信号依存変換、カルーネンレーベ変換（ＫＬＴ）、または、これらに類するもののような、第１の変換に続く２次変換を適用してもよい。ビデオエンコーダ２００は、１つ以上の変換の適用に続いて、変換係数を生成させる。

［００５６］
上述のように、変換係数を生成させるための任意の変換に続いて、ビデオエンコーダ２００は、変換係数の量子化を実行してもよい。量子化は、一般的に、変換係数が量子化されて、変換係数を表すために使用されるデータの量を場合によっては低減させ、さらなる圧縮を提供するプロセスを指している。量子化プロセスを実行することによって、ビデオエンコーダ２００は、変換係数のいくつか、または、すべてに関係するビット深度を低減させてもよい。例えば、ビデオエンコーダ２００は、量子化の間にｎ－ビット値をｍ－ビット値に切り捨ててもよく、ｎはｍよりも大きい。いくつかの例では、量子化を実行するために、ビデオエンコーダ２００は、量子化されることになる値のビット単位の右シフトを実行してもよい。

［００５７］
量子化に続いて、ビデオエンコーダ２００は、変換係数を走査し、量子化された変換係数を含む２次元行列から１次元ベクトルを生成させてもよい。走査は、より高いエネルギー（したがって、より低い周波数）の変換係数をベクトルの前部に配置し、より低いエネルギー（したがって、より高い周波数）の変換係数をベクトルの後部に配置するように設計されていてもよい。いくつかの例では、ビデオエンコーダ２００は、予め規定された走査順序を利用して、量子化変換係数を走査し、シリアル化ベクトルを生成させ、その後、ベクトルの量子化変換係数をエントロピーエンコードしてもよい。他の例では、ビデオエンコーダ２００は、適応走査を実行してもよい。量子化変換係数を走査して１次元ベクトルを形成した後、ビデオエンコーダ２００は、例えば、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）にしたがって、１次元ベクトルをエントロピーエンコードしてもよい。ビデオエンコーダ２００はまた、ビデオデータをデコードする際に、ビデオデコーダ３００によって使用するために、エンコードされたビデオデータに関係するメタデータを記述するシンタックス要素に対する値をエントロピーエンコードしてもよい。

［００５８］
ＣＡＢＡＣを実行するために、ビデオエンコーダ２００は、コンテキストモデル内のコンテキストを送信されることになるシンボルに割り当ててもよい。コンテキストは、例えば、シンボルの隣接する値がゼロ値にされているか否かに関連していてもよい。確率決定は、シンボルに割り当てられているコンテキストに基づいていてもよい。

［００５９］
ビデオエンコーダ２００はさらに、例えば、ピクチャーヘッダ中で、ブロックヘッダ中で、スライスヘッダ中で、あるいは、シーケンスパラメータセット（ＳＰＳ）、ピクチャーパラメータセット（ＰＰＳ）、または、ビデオパラメータセット（ＶＰＳ）のような他のシンタックスデータ中で、ビデオデコーダ３００への、ブロックベースのシンタックスデータ、ピクチャーベースのシンタックスデータ、および、シーケンスベースのシンタックスデータのようなシンタックスデータを発生させてもよい。ビデオデコーダ３００は、同様に、このようなシンタックスデータをデコードして、対応するビデオデータをどのようにデコードするかを決定してもよい。

［００６０］
このようにして、ビデオエンコーダ２００は、エンコードされたビデオデータを含む、例えば、ブロック（例えば、ＣＵ）へのピクチャーの区分を記述するシンタックス要素と、ブロックに対する予測および／または残差情報とを含む、ビットストリームを発生させてもよい。最終的に、ビデオデコーダ３００は、ビットストリームを受け取り、エンコードされたビデオデータをデコードしてもよい。

［００６１］
一般的に、ビデオデコーダ３００は、ビデオエンコーダ２００によって実行されたプロセスとは逆のプロセスを実行して、ビットストリームのエンコードされたビデオデータをデコードする。例えば、ビデオデコーダ３００は、ビデオエンコーダ２００のＣＡＢＡＣエンコーディングプロセスと、逆ではあるが、実質的に類似する方法で、ＣＡＢＡＣを使用して、ビットストリームのシンタックス要素に対する値をデコードしてもよい。シンタックス要素は、ＣＴＵにピクチャーを区分するための区分情報と、ＱＴＢＴ構造のような、対応する区分構造にしたがって、各ＣＴＵを区分することとを規定して、ＣＴＵのＣＵを規定していてもよい。シンタックス要素は、ビデオデータのブロック（例えば、ＣＵ）に対する予測および残差情報をさらに規定していてもよい。

［００６２］
残差情報は、例えば、量子化変換係数によって表されていてもよい。ビデオデコーダ３００は、ブロックの量子化された変換係数を逆量子化および逆変換して、ブロックに対する残差ブロックを再生させてもよい。ビデオデコーダ３００は、シグナリングされた予測モード（イントラ予測またはインター予測）と、関連する予測情報（例えば、インター予測に対する動き情報）とを使用して、ブロックに対する予測ブロックを形成する。ビデオデコーダ３００は、その後、（サンプル毎のベースで）予測ブロックと残差ブロックとを組み合わせて、元のブロックを再生させてもよい。ビデオデコーダ３００は、デブロッキングプロセスを実行することのような、追加の処理を実行して、ブロックの境界に沿った視覚的アーティファクトを低減させてもよい。

［００６３］
ビデオエンコーディングの分野では、デコードされたビデオ信号の品質を向上させるために、フィルタリングを適用することが一般的である。フィルタは、フィルタされたフレームが将来のフレームの予測のために使用されないポストフィルタとして、または、フィルタされたフレームが将来のフレームを予測するために使用されるループ内フィルタとして適用することができる。フィルタは、例えば、元の信号とデコードされフィルタされた信号との間の誤差を最小化することにより、設計することができる。

［００６４］
ＶＶＣテストモデル５．０（ＶＴＭ－５．０）（Ｃｈｅｎ氏ら，「バーサタイルビデオコーディングおよびテストモデル５（ＶＴＭ５）に対するアルゴリズム説明」、ＩＴＵ－Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＯ１１のジョイントビデオエキスパートチーム（ＪＶＥＴ）、第１４回ミーティング、スイス国、ジュネーブ、２０１９年３月１９日～２７日、ドキュメントＪＶＥＴ－Ｎ１００１）では、デコードされたフィルタ係数ｆ（ｋ，ｌ）およびクリッピング値ｃ（ｋ，ｌ）は、以下のように、再構築された画像Ｒ（ｉ，ｊ）に適用される。

ＶＴＭ－５．０では、７×７フィルタがルーマ成分に適用され、５×５フィルタがクロマ成分に適用される。図２Ａは、例示的な５×５ダイヤモンド形状ＡＬＦサポートを図示する概念図である。図２Ｂは、例示的な７×７ダイヤモンド形状ＡＬＦサポートを図示する概念図である。式（１）では、ＫはＬ／２に等しくてもよく、Ｌはフィルタ長を示している。さらに、式（１）および本開示の他の個所では、ｃｌｉｐ３関数は、以下のものとして規定されていてもよい。

［００６５］
式（１）および本開示の他の個所では、クリッピング値ｃ（ｋ，ｌ）は、以下のように計算してもよい。ルーマ成分に対して、クリッピング値ｃ（ｋ，ｌ）は、以下のように計算してもよい。

式（１’）において、ＢｉｔＤｅｐｔｈＹは、ルーマ成分に対するビット深度であり、ｃｌｉｐＩｄｘ（ｋ，ｌ）は、ポジション（ｋ，ｌ）に対するクリッピングインデックスである。ｃｌｉｐＩｄｘ（ｋ，ｌ）は、０、１、２または３とすることできる。

［００６６］
クロマ成分に対して、クリッピング値ｃ（ｋ，ｌ）は、以下のように計算してもよい。

式（１’’）において、ＢｉｔＤｅｐｔｈＣは、クロマ成分に対するビット深度であり、ｃｌｉｐＩｄｘ（ｋ，ｌ）は、ポジション（ｋ，ｌ）に対するクリッピング値である。ｃｌｉｐＩｄｘ（ｋ，ｌ）は、０、１、２、または３とすることできる。

［００６７］
ルーマ成分に対して、ピクチャー全体の中の４×４ブロックが、１次元（１Ｄ）ラプラシアン方向（最大５つの方向）および２Ｄラプラシアンアクティビティ（最大５つのアクティビティ値）に基づいて分類される。方向Ｄｉｒ_ｂおよび量子化されていないアクティビティＡｃｔ_ｂが計算される。Ａｃｔ_ｂは、さらに、両端値を含む０から４までの範囲に量子化される。

［００６８］
最初に、ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、１Ｄラプラシアンを使用して、既存のＡＬＦ中で使用される水平勾配および垂直勾配に加えて、２つの斜勾配の値を計算する。以下の式（２）から（５）から分かるように、ターゲットピクセルをカバーする８×８ウィンドウ内のすべてのピクセルの勾配の和が、ターゲットピクセルの表される勾配として用いられ、Ｒ（ｋ，ｌ）は、ポジション（ｋ，ｌ）における再構築されたピクセルを示し、インデックスｉおよびｊは、４×４ブロック中の左上のピクセルの座標を指している。各ピクセルは、４つの勾配値に関係しており、垂直勾配はｇ_ｖにより示され、水平勾配はｇ_ｈにより示され、１３５度の斜勾配はｇ_ｄ１により示され、４５度の斜勾配はｇ_ｄ２により示される。

Ｖ_ｋ，ｌ＝｜２Ｒ（ｋ，ｌ）－Ｒ（ｋ，ｌ－１）－Ｒ（ｋ，ｌ＋１）｜、ｋとｌの両方が偶数であるとき、または、ｋとｌの両方が偶数でないとき。そうでなければ、０である。

Ｈ_ｋ，ｌ＝｜２Ｒ（ｋ，ｌ）－Ｒ（ｋ－１，ｌ）－Ｒ（ｋ＋１，ｌ）｜、ｋとｌの両方が偶数であるとき、または、ｋとｌの両方が偶数でないとき。そうでなければ、０である。

Ｄ１_ｋ，ｌ＝｜２Ｒ（ｋ，ｌ）－Ｒ（ｋ－１，ｌ－１）－Ｒ（ｋ＋１，ｌ＋１）｜、ｋとｌの両方が偶数であるとき、または、ｋとｌの両方が偶数でないとき。そうでなければ、０である。

Ｄ２_ｋ，ｌ＝｜２Ｒ（ｋ，ｌ）－Ｒ（ｋ－１，ｌ＋１）－Ｒ（ｋ＋１，ｌ－１）｜、ｋとｌの両方が偶数であるとき、または、ｋとｌの両方が偶数でないとき。そうでなければ、０である。

［００６９］
方向性Ｄｉｒ_ｂを割り当てるために、（以下の式（６）においてＲ_ｈ，ｖにより示されている）水平勾配および垂直勾配の最大値と最小値との比、ならびに、（以下の式（７）においてＲ_{ｄ１，ｄ２}により示されている）２つの斜勾配の最大値と最小値との比が、２つのしきい値ｔ_１およびｔ_２と互いに比較される。

式（６）および（７）ならびに本開示の他の個所において、ｇ_ｈ，ｖ ^ｍａｘは、水平勾配および垂直勾配の最大値を示し、ｇ_ｈ，ｖ ^ｍｉｎは、水平勾配および垂直勾配の最小値を示し、ｇ_{ｄ０，ｄ１} ^ｍａｘは、２つの斜勾配の最大値を示し、ｇ_ｈ，ｖ ^ｍｉｎは、２つの斜勾配の最小値を示している。

［００７０］
水平／垂直および斜勾配の検出された比を比較することにより、５つの方向モード、すなわち、両端値を含む［０、４］の範囲内のＤｉｒ_ｂが、以下の式（８）において規定される。Ｄｉｒ_ｂの値およびその物理的な意味は、表１に説明されている。

［００７１］
ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、アクティビティ値Ａｃｔを以下のように計算してもよい。

［００７２］
ビデオコーダは、両端値を含む０～４の範囲にＡｃｔをさらに量子化してもよい。Ａｃｔの量子化された値は、Ａ＾として示される。

［００７３］
Ａｃｔに対する量子化プロセスは、以下のように規定してもよい。

ＮＵＭ＿ＥＮＴＲＹは１６に設定され、ＳｃａｌｅＦａｃｔｏｒは６４に設定され、ｓｈｉｆｔは（４＋内部コード化ビット深度）であり、ＡｃｔｉｖｉｔｙＴｏＩｎｄｅｘ［ＮＵＭ＿ＥＮＴＲＹ］＝｛０、１、２、２、２、２、２、３、３、３、３、３、３、３、３、４｝である。関数Ｃｌｉｐ＿ｐｏｓｔ（ａ，ｂ）は、ａとｂのうち小さい方の値を返す。

［００７４］
合計で、各４×４ルーマブロックを、ビデオコーダにより２５個（５方向×５アクティビティレベル）のクラスのうちの１つに分類することができ、インデックスは、ブロックのＤｉｒ_ｂおよびＡｃｔ_ｂの値にしたがって、各４×４ブロックに割り当てられる。グループインデックスは、Ｃにより示され、５Ｄｉｒ_ｂ＋Ａ＾に等しく設定されてもよく、Ａ＾はＡｃｔ_ｂの量子化された値である。

［００７５］
いくつかの例では、ビデオコーダは、フィルタ係数に幾何学的変換を適用してもよい。例えば、いくつかのこのような例では、ビデオコーダは、各カテゴリーに対して、フィルタ係数とクリッピング値との１つのセットをシグナリングしてもよい。同じカテゴリーインデックスでマークされたブロックの異なる方向をよりよく識別するために、変換なし、斜め、垂直フリップ、および、回転を含む４つの幾何学的変換が導入される。３つの幾何学的変換を有する５×５フィルタサポートの例が、図４Ａ～図４Ｃに示されている。言い換えると、図４Ａ～図４Ｃは、異なる幾何学的変換を有する例示的な５×５フィルタサポートを図示する概念図である。図３および図４Ａ～図４Ｃを比較すると、３つの追加の幾何学的変換の式形態を、以下のように導出してもよい。

式（１０）において、Ｋはフィルタのサイズであり、０≦ｋ，ｌ≦Ｋ－１は係数座標であり、したがって、ロケーション（０，０）は左上隅にあり、ロケーション（Ｋ－１，Ｋ－１）は右下隅にある。ＶＶＣドラフト５のＡＬＦにおけるように、ダイヤモンドフィルタサポートが使用されるときには、フィルタサポート外の座標を有するフィルタ係数は、常に０に設定されることに留意されたい。幾何学的変換インデックスを示す１つの方法は、追加のオーバーヘッドを避けるために、幾何学的変換インデックスを暗黙的に導出することである。幾何学的ＡＬＦ（ＧＡＬＦ）では、そのブロックに対して計算された勾配値に依存して、（例えば、ビデオエンコーダ２００またはビデオデコーダ３００のようなビデオコーダにより）変換がフィルタ係数ｆ（ｋ，ｌ）に適用される。変換と、式（２）～式（５）を使用して計算された４つの勾配との間の関連は、以下の表２中で説明されている。要約すると、変換は、２つの勾配（水平および垂直、または、４５度および１３５度勾配）のうちの１つがより大きいことに基づいている。比較に基づいて、ビデオコーダは、より正確な方向情報を抽出するかもしれない。したがって、フィルタ係数のオーバーヘッドを増加させずに、変換により異なるフィルタリング結果を得ることができる。

［００７６］
フィルタ情報は、ビットストリーム中でシグナリングされてもよい。１つのルーマフィルタセットは、２５個のクラスすべてに対する（フィルタ係数およびクリッピング値を含む）フィルタ情報を含んでいる。固定フィルタは、各クラスに対するフィルタを予測するために使用することができる。このクラスがそのフィルタ予測子として固定フィルタを使用するか否かを示すために、各クラスに対して、フラグをシグナリングすることができる。はいの場合には（すなわち、クラスがそのフィルタ予測子として固定フィルタを使用することをクラスに対するフラグが示す場合には）、固定フィルタの情報がシグナリングされる。

［００７７］
フィルタ係数を表すのに必要なビット数を低減させるために、異なるクラスをマージすることができる。どのクラスがマージされるかに関する情報は、２５個のクラスのそれぞれに対して、インデックスｉ_Ｃを送ることにより提供してもよい。同じインデックスｉ_Ｃを有するクラスは、コード化される同じフィルタ係数を共有する。クラスとフィルタとの間のマッピングは、各ルーマフィルタセットに対してシグナリングされる。インデックスｉ_Ｃは、トランケーティドバイナリバイナリ化方法によりコード化される。シグナリングされたフィルタは、以前にシグナリングされたフィルタから予測することができる。

［００７８］
ビットストリームは、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットのシーケンスを含んでいてもよい。ＮＡＬユニットは、ＮＡＬユニット中のデータのタイプのインジケーションと、必要に応じてエミュレーション防止ビットが散在する生バイトシーケンスペイロード（ＲＢＳＰ）の形態でそのデータを含むバイトとを含むシンタックス構造である。ＮＡＬユニットのそれぞれは、ＮＡＬユニットヘッダを含んでいてもよく、ＲＢＳＰをカプセル化していてもよい。ＮＡＬユニットヘッダは、ＮＡＬユニットタイプコードを示すシンタックス要素を含んでいてもよい。ＮＡＬユニットのＮＡＬユニットヘッダにより指定されるＮＡＬユニットタイプコードは、ＮＡＬユニットのタイプを示している。ＲＢＳＰは、ＮＡＬユニット内にカプセル化されている整数個のバイトを含むシンタックス構造であってもよい。いくつかの事例では、ＲＢＳＰは０ビットを含んでいる。

［００７９］
上述したように、ビットストリームは、ビデオデータのエンコードされたピクチャーの表現と関係するデータとを含んでいてもよい。関係するデータは、パラメータセットを含んでいてもよい。ＮＡＬユニットは、ビデオパラメータセット（ＶＰＳ）と、シーケンスパラメータセット（ＳＰＳ）と、ピクチャーパラメータセット（ＰＰＳ）と、および、適応パラメータセット（ＡＰＳ）とに対するＲＢＳＰをカプセル化してもよい。ＶＰＳは、０個以上の全コード化ビデオシーケンス（ＣＶＳ）に適用されるシンタックス要素を含むシンタックス構造である。ＳＰＳも、０個以上の全ＣＶＳに適用されるシンタックス要素を含むシンタックス構造である。ＳＰＳは、ＳＰＳがアクティブであるときにアクティブであるＶＰＳを識別するシンタックス要素を含んでいてもよい。したがって、ＶＰＳのシンタックス要素は、ＳＰＳのシンタックス要素よりもさらに一般的に適用可能であるかもしれない。ＰＰＳは、０個以上のコード化ピクチャーに適用されるシンタックス要素を含むシンタックス構造である。ＰＰＳは、ＰＰＳがアクティブであるときにアクティブであるＳＰＳを識別するシンタックス要素を含んでいてもよい。スライスのスライスヘッダは、スライスがコード化されているときにアクティブであるＰＰＳを示しているシンタックス要素を含んでいてもよい。ＡＰＳは、スライスヘッダ中で見い出された０個以上のシンタックス要素により決定される、０個以上のスライスに適用されるシンタックス要素を含むシンタックス構造である。スライスのスライスヘッダは、スライスがコード化されているときにアクティブであるＡＰＳを示す１つ以上のシンタックス要素を含んでいてもよい。

［００８０］
ＶＴＭ－５．０では、ＡＰＳは、ビットストリーム中でＡＬＦフィルタ係数を搬送するために使用される。ＡＰＳは、ルーマフィルタのセットまたはクロマフィルタのセットあるいは両方を含むことができる。タイルグループ、スライス、または、ピクチャーは、そのタイルグループ中の現在タイルグループ、スライス、または、ピクチャーヘッダのために使用されるＡＰＳのインデックスのみをシグナリングする。

［００８１］
ＶＴＭ－５．０では、フィルタシグナリングのためのオーバーヘッドを節約するために、以前にコード化されたタイルグループ、スライス、または、ピクチャーから発生されたフィルタが、現在タイルグループ、スライス、または、ピクチャーのために使用されてもよい。ビデオエンコーダ２００は、ルーマＣＴＢに対して、固定フィルタセットからフィルタセットをＡＰＳからフィルタセットを選定してもよい。ビデオエンコーダ２００は、選定されたフィルタセットインデックスをシグナリングしてもよい。すべてのクロマＣＴＢは、同じＡＰＳからのフィルタを使用する。タイルグループ、スライス、または、ピクチャーヘッダでは、ビデオエンコーダ２００は、現在タイルグループ、スライス、または、ピクチャーの、ルーマおよびクロマＣＴＢに対して使用されるＡＰＳをシグナリングする。タイルは、ピクチャー中の特定のタイル列および特定のタイル行内のＣＴＢの矩形領域である。

［００８２］
ＶＴＭ－５．０のビデオデコーダ（例えば、ビデオデコーダ３００）では、ＡＬＦのフィルタ係数が最初に再構築される。その後、クリッピングインデックスが、非０フィルタ係数に対してデコードされる。０の値を有するフィルタ係数に対して、ビデオデコーダは、クリッピングインデックスが０であると推測する。指数ゴロム（すなわち、Ｅｘｐ－Ｇｏｌｏｍｂ）コーディングが、クリッピングインデックスのシグナリングのために使用される。クリッピングインデックスに対するＥｘｐ－Ｇｏｌｏｍｂコードの次数は、フィルタテンプレートにおけるそのポジションに依存する。

［００８３］
具体的には、ＶＴＭ－５．０において、ＡＰＳは、以下のようにパースされるルーマ成分に対するクリッピングインデックスを含んでいてもよく、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘは、クリッピングインデックスを指定する。

［００８４］
ＶＶＣドラフト５は、上記のシンタックス表に示されているシンタックス要素に対して、以下のセマンティクスを提供する。
ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１＋１は、ルーマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数を指定する。ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１の値は、両端値を含む０～６の範囲内にあるものとする。
１に等しいａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、ルーマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされることを指定する。０に等しいａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、ルーマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされないことを指定する。
ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘ［ｓｆＩｄｘ］［ｊ］の値をデコードするために使用されるｅｘｐ－Ｇｏｌｏｍｂコードの次数ｋＣｌｉｐＹ［ｉ］は、以下のように導出される。

ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘ［ｓｆＩｄｘ］［ｊ］は、ｓｆＩｄｘにより示されるシグナリングされたルーマフィルタのｊ番目の係数により乗算する前に使用する、クリッピング値のクリッピングインデックスを指定する。ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘ［ｓｆＩｄｘ］［ｊ］が存在しないときには、それは０に等しい（クリッピングなし）と推測される。ｓｆＩｄｘ＝０．．．ａｌｆ＿ｌｕｍａ＿ｎｕｍ＿ｆｉｌｔｅｒｓ＿ｓｉｇｎａｌｌｅｄ＿ｍｉｎｕｓ１およびｊ＝０．．．１１である、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘ［ｓｆＩｄｘ］［ｊ］の値が両端値を含む０～３の範囲内にあることがビットストリーム適合の要件である。
ｅｘｐ－Ｇｏｌｏｍｂバイナリ化ｕｅｋ（ｖ）の次数ｋは、以下のように導出される。

ｓｆＩｄｘ＝０．．．ａｌｆ＿ｌｕｍａ＿ｎｕｍ＿ｆｉｌｔｅｒｓ＿ｓｉｇｎａｌｌｅｄ＿ｍｉｎｕｓ１，ｊ＝０．．．１１である、変数ｆｉｌｔｅｒＣｌｉｐｓ［ｓｆＩｄｘ］［ｊ］は、以下のように初期化される。

ｆｉｌｔＩｄｘ＝０．．．ＮｕｍＡｌｆＦｉｌｔｅｒｓ－１およびｊ＝０．．．１１である、要素ＡｌｆＣｌｉｐ_Ｌ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］［ｆｉｌｔＩｄｘ］［ｊ］を有するルーマフィルタクリッピング値ＡｌｆＣｌｉｐ_Ｌ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］は、以下のように導出される。

［００８５］
本開示のシンタックス表において、ｕ（ｎ）は、ｎビットを使用して、符号なし整数を示している。タイプｕ（ｎ）の記述子における文字ｎがシンタックス表における「ｖ」であるときには、ビット数は、他のシンタックス要素の値に依存して変化する。記述子ｔｂ（ｖ）は、シンタックス要素のセマンティクス中で規定されているｍａｘＶａｌを有するｍａｘＶａｌビットまでを使用して、トランケーティドバイナリ値を示している。記述子ｔｕ（ｖ）は、シンタックス要素のセマンティクス中で規定されているｍａｘＶａｌを有するｍａｘＶａｌビットまでを使用して、トランケーティドユーナリー値を示している。記述子ｕｅ（ｖ）は、左ビットを先頭とする符号なし整数０次Ｅｘｐ－Ｇｏｌｏｍｂコード化シンタックス要素を示している。記述子ｕｅｋ（ｖ）は、左ビットを先頭とする符号なし整数ｋ次Ｅｘｐ－Ｇｏｌｏｍｂコード化シンタックス要素を示している。記述子ｓｅ（ｖ）は、左ビットを先頭とする符号付き整数０次Ｅｘｐ－Ｇｏｌｏｍｂコード化シンタックス要素を示している。

［００８６］
ＶＶＣドラフト５は、記述子ｔｂ（ｖ）を使用してコード化されたシンタックス要素に対して、以下のパースプロセスを提供する。
このプロセスは、７．３項中のシンタックス表中のシンタックス要素の記述子が、ｔｂ（ｖ）に等しいときに呼び出される。
このプロセスへの入力は、ＲＢＳＰからのビットおよび最大値ｍａｘＶａｌである。
このプロセスの出力は、シンタックス要素値である。
ｔｂ（ｖ）としてコード化されるシンタックス要素は、トランケーティドバイナリコード化される。シンタックス要素に対する可能性ある値の範囲が最初に決定される。このシンタックス要素の範囲は、両端値を含む０からｍａｘＶａｌであり、ｍａｘＶａｌは１以上である。シンタックス要素の値に等しいｓｙｎＶａｌは、以下により指定されるプロセスにより与えられる。

ｒｅａｄ＿ｂｉｔｓ（ｔｈ）から返される値は、最上位ビットが最初に書き込まれている符号なし整数のバイナリ表現として解釈される。

［００８７］
ＶＶＣドラフト５は、記述子ｔｕ（ｖ）を使用してコード化されたシンタックス要素に対して、以下のパースプロセスを提供する。
このプロセスは、７．３項中のシンタックス表中のシンタックス要素の記述子が、ｔｕ（ｖ）に等しいときに呼び出される。
このプロセスへの入力は、ＲＢＳＰからのビットおよび最大値ｍａｘＶａｌである。
このプロセスの出力は、シンタックス要素値である。
ｔｕ（ｖ）としてコード化されたシンタックス要素は、トランケーティドユーナリーコード化される。シンタックス要素に対する可能性ある値の範囲が最初に決定される。このシンタックス要素の範囲は両端値を含む０からｍａｘＶａｌまでであり、ｍａｘＶａｌは１以上である。シンタックス要素の値に等しいｃｏｄｅＮｕｍは、以下により指定されるプロセスにより与えられる。

［００８８］
ＶＶＣドラフト５は、記述子ｕｅ（ｖ）、ｕｅｋ（ｖ）およびｓｅ（ｖ）を使用してコード化されたシンタックス要素に対して、以下のパースプロセスを提供する。
このプロセスは、シンタックス表中のシンタックス要素の記述子が、ｕｅ（ｖ）、ｕｅｋ（ｖ）またはｓｅ（ｖ）に等しいときに呼び出される。
このプロセスへの入力は、ＲＢＳＰからのビットである。
このプロセスの出力は、シンタックス要素値である。
ｕｅ（ｖ）またはｓｅ（ｖ）としてコード化されたシンタックス要素は、０に等しい次数ｋでＥｘｐ－Ｇｏｌｏｍｂコード化され、ｕｅｋ（ｖ）としてコード化されたシンタックス要素は、次数ｋでＥｘｐ－Ｇｏｌｏｍｂコード化される。これらのシンタックス要素に対するパースプロセスは、ビットストリーム中の現在ロケーションから開始して最初の非０ビットまでを含むビットを読み出すことにより開始し、０に等しい先頭ビットの数をカウントする。このプロセスは、以下のように特定される。

変数ｃｏｄｅＮｕｍは、以下のように割り当てられる。

ｒｅａｄ＿ｂｉｔｓ（ｌｅａｄｉｎｇＺｅｒｏＢｉｔｓ）から返される値は、最上位ビットが最初に書き込まれている符号なし整数のバイナリ表現として解釈される。
表９－１は、ビットストリングを「ｐｒｅｆｉｘ」ビットと「ｓｕｆｆｉｘ」ビットとに分離することによる０次Ｅｘｐ－Ｇｏｌｏｍｂコードの構造を図示している。「ｐｒｅｆｉｘ」ビットは、ｌｅａｄｉｎｇＺｅｒｏＢｉｔｓの計算のために上記で指定されているようにパースされるビットであり、表９－１のビットストリング列において０または１のいずれかとして示されている。「ｓｕｆｆｉｘ」ビットは、ｃｏｄｅＮｕｍの計算においてパースされるビットであり、表９－１においてｘ_ｉとして示され、ｉは両端値を含む０からｌｅａｄｉｎｇＺｅｒｏＢｉｔｓ－１までの範囲内である。各ｘ_ｉは、０または１のいずれかに等しい。

表９－２は、ｃｏｄｅＮｕｍ値へのビットストリングの割り当てを明示的に示している。

記述子に依存して、シンタックス要素の値は、以下のように導出される。
シンタックス要素がｕｅ（ｖ）としてコード化される場合には、シンタックス要素の値は、ｃｏｄｅＮｕｍに等しい。
そうでない場合（シンタックス要素がｓｅ（ｖ）としてコード化される）、シンタックス要素の値は、ｃｏｄｅＮｕｍを入力として、９．２．２節で指定されているような符号付きＥｘｐ－Ｇｏｌｏｍｂコードに対するマッピングプロセスを呼び出すことにより導出される。
９．２．２符号付きＥｘｐ－Ｇｏｌｏｍｂコードに対するマッピングプロセス
このプロセスへの入力は、９．２節で指定されているようなｃｏｄｅＮｕｍである。
このプロセスの出力は、ｓｅ（ｖ）としてコード化されたシンタックス要素の値である。
シンタックス要素は、シンタックス要素をその絶対値により昇順で順序付け、より低いｃｏｄｅＮｕｍを用いて所定の絶対値に対する正の値を表すことにより、ｃｏｄｅＮｕｍに割り当てられる。表９－３は、割り当てルールを提供する。

［００８９］
ＶＶＣドラフト５において、クロマ成分に対するクリッピングインデックスは、以下のようにパースされる。

［００９０］
ＶＶＣドラフト５は、上記のシンタックス表に示されているシンタックス要素に対して、以下のセマンティクスを提供する。
０に等しいａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｆｌａｇは、線形適応ループフィルタリングがクロマ成分に適用されることを指定し、１に等しいａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｆｌａｇは、非線形適応ループフィルタリングがクロマ成分に適用されることを指定する。存在しないときには、ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｆｌａｇは、０に等しいと推測される。
ａｌｆ＿ｃｈｒｏｍａ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１＋１は、クロマフィルタ係数シグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数を指定する。ａｌｆ＿ｃｈｒｏｍａ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１の値は、両端値を含む０～６の範囲内にあるものとする。
１に等しいａｌｆ＿ｃｈｒｏｍａ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、クロマフィルタ係数シグナリング対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされることを指定する。０に等しいａｌｆ＿ｃｈｒｏｍａ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、クロマフィルタ係数シグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされないことを指定する。
ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ａｂｓ［ｊ］の値をデコードするために使用されるｅｘｐ－Ｇｏｌｏｍｂコードの次数ｅｘｐＧｏＯｒｄｅｒＣ［ｉ］は、以下のように導出される。

ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ａｂｓ［ｊ］は、ｊ番目のクロマフィルタ係数の絶対値を指定する。ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ａｂｓ［ｊ］が存在しないときには、それは０に等しいと推測される。ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ａｂｓ［ｊ］の値が両端値を含めて０～２^７－１の範囲内にあることがビットストリーム適合の要件である。
ｅｘｐ－Ｇｏｌｏｍｂバイナリ化ｕｅｋ（ｖ）の次数ｋは、以下のように導出される。

ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ｓｉｇｎ［ｊ］は、以下のように、ｊ番目のクロマフィルタ係数の符号を指定する。
ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ｓｉｇｎ［ｊ］が０に等しい場合には、対応するクロマフィルタ係数は正の値を有する。
そうでない場合（ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ｓｉｇｎ［ｊ］が１に等しい）、対応するクロマフィルタ係数は負の値を有する。
ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ｓｉｇｎ［ｊ］が存在しないときには、それは０に等しいと推測される。
ｊ＝０．．．５である、要素ＡｌｆＣｏｅｆｆ_Ｃ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］［ｊ］を有するクロマフィルタ係数ＡｌｆＣｏｅｆｆ_Ｃ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］は、以下のように導出される。

ｊ＝０．．．５である、ＡｌｆＣｏｅｆｆ_Ｃ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］［ｊ］の値が、両端値を含む－２^７－１～２^７－１の範囲内にあることがビットストリーム適合の要件である。
ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１＋１は、クロマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数を指定する。ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｍｉｎ＿ｅｇ＿ｏｒｄｅｒ＿ｍｉｎｕｓ１の値は、両端値を含む０～６の範囲内にあるものとする。
１に等しいａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、クロマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされることを指定する。０に等しいａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｅｇ＿ｏｒｄｅｒ＿ｉｎｃｒｅａｓｅ＿ｆｌａｇ［ｉ］は、クロマクリッピングインデックスシグナリングに対するｅｘｐ－Ｇｏｌｏｍｂコードの最小次数が１だけインクリメントされないことを指定する。
ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘ［ｊ］の値をデコードするために使用されるｅｘｐ－Ｇｏｌｏｍｂコードの次数ｅｘｐＧｏＯｒｄｅｒＣ［ｉ］は、以下のように導出される。

ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘ［ｊ］は、クロマフィルタのｊ番目の係数により乗算する前に使用する、クリッピング値のクリッピングインデックスを指定する。ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘ［ｊ］が存在しないときには、それは０に等しい（クリッピングなし）と推測される。ｊ＝０．．．５である、ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘ［ｊ］の値が両端値を含む０～３の範囲内にあることが、ビットストリーム適合の要件である。
ｅｘｐ－Ｇｏｌｏｍｂバイナリ化ｕｅｋ（ｖ）の次数ｋは、以下のように導出される。

ｊ＝０．．．５である、要素ＡｌｆＣｌｉｐ_Ｃ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］［ｊ］を有するクロマフィルタクリッピング値ＡｌｆＣｌｉｐ_Ｃ［ａｄａｐｔａｔｉｏｎ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ］は、以下のように導出される。

［００９１］
上述したように、クリッピングインデックスをパースするために、フィルタ係数が最初に再構築される。さらに、再帰的ｅｘｐ－Ｇｏｌｏｍｂコーディングが、クリッピングインデックスをパースするために使用される。最初にフィルタ係数を再構築し、再帰的ｅｘｐ－Ｇｏｌｏｍｂコーディングを使用することは、ビデオデコーダ３００における遅延を増加させるかもしれない。

［００９２］
本開示の態様は、ルーマ成分とクロマ成分の両方に対するクリッピングインデックスのパースを簡略化するかもしれない例を説明する。本開示の態様および例は、別々に、または、組み合わせて使用してもよい。本開示の態様は、ビデオデコーダ３００における遅延と、いくつかの例では、ビデオエンコーダ２００のデコーディングパスとを減少させるかもしれない。

［００９３］
本開示の第１の態様では、対応するフィルタ係数ｆ（ｋ，ｌ）が０である場合でも、クリッピングインデックスｃｌｉｐＩｄｘ（ｋ，ｌ）は常に（例えば、それぞれビデオエンコーダ２００またはビデオデコーダ３００により）シグナリング／パースされる。言い換えると、対応するフィルタ係数が非０であるという条件が取り除かれるかもしれない。例えば、上記のシンタックス表を参照すると、行「ｉｆ（ｆｉｌｔＣｏｅｆｆ［ｓｆＩｄｘ］［ｊ］）」および「ｉｆ（ａｌｆ＿ｃｈｒｏｍａ＿ｃｏｅｆｆ＿ａｂｓ［ｊ］）」が取り除かれるかもしれない。このようにして、ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、ＡＬＦの対応するフィルタ係数の値にかかわらず、ＡＬＦクリッピングインデックスをコード化してもよい。例えば、ビデオコーダは、対応するフィルタ係数が０に等しいことを決定し、ＡＬＦクリッピングインデックスを依然としてコード化（例えば、エンコードまたはデコード）してもよい。

［００９４］
本開示の第２の態様では、再帰的ｅｘｐ－Ｇｏｌｏｍｂコーディングが取り除かれる。例えば、本開示の第２の態様の１つの例では、以下のシンタックス表に示されているように、ｘを各コードワードの長さとした場合に、クリッピングインデックスをシグナリングするために、固定長コーディングを使用してもよい。

ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよびａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘが、（符号なし整数ｋ次Ｅｘｐ－Ｇｏｌｏｍｂコーディングを示す）記述子ｕｅｋ（ｖ）を有するＶＶＣドラフト５とは対照的に、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよびａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘは、この例では、（ｘビットを使用する符号なし整数を示す）記述子ｕ（ｘ）を有する。この例のシンタックス表は、ＡＰＳのシンタックス表の一部を形成していてもよい。

［００９５］
したがって、この例では、ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、固定長符号なし整数として、ＡＬＦクリッピングインデックスをコード化してもよい。さらに、ビデオコーダは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。

［００９６］
本開示の第２の態様のいくつかの例では、トランケーティドバイナリコーディングを使用して、クリッピングインデックスをシグナリングしてもよい。例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよび／またはａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘが、記述子ｔｂ（ｖ）を有していてもよい。

［００９７］
本開示の第２の態様のいくつかの例では、０次ゴロムを使用して、クリッピングインデックスをシグナリングしてもよい。例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよび／またはａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘが、記述子ｕｅ（ｖ）を有していてもよい。

［００９８］
本開示の第２の態様のいくつかの例では、ｘ次ゴロムを使用して、クリッピングインデックスをシグナリングしてもよく、ｘはゴロムコーディングの次数である。いくつかのこのような例では、ｘは成分に依存していてもよい。言い換えると、ルーマ成分とクロマ成分とではｘの値が異なっていてもよい。ｘは、１つ以上の成分におけるすべてのクリッピングインデックスに対して同じであってもよい。他の例では、ｘはフィルタインデックスに依存していてもよく、ｘは１つ以上のフィルタ中のすべてのクリッピングインデックスに対して同じであってもよい。

［００９９］
本開示の第２の態様のいくつかの例では、トランケーティドユーナリーコーディングを使用して、クリッピングインデックスをシグナリングしてもよい。例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよび／またはａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘが、記述子ｔｕ（ｖ）を有していてもよい。

［０１００］
本開示の第２の態様のいくつかの例では、コーディング方法は、色成分間で異なっていてもよい。例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘおよびａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘは、トランケーティドバイナリ、トランケーティドユニット、ｎビットを使用する符号なし整数、符号なし整数０次Ｅｘｐ－Ｇｏｌｏｍｂコーディング、および、符号なし整数ｋ次Ｅｘｐ－Ｇｏｌｏｍｂコーディング、のうちの異なるものを使用して、コード化されていてもよい。

［０１０１］
したがって、ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、固定長符号なし整数（記述子ｕ（ｘ））、トランケーティドバイナリバイナリ値（記述子ｔｂ（ｖ））、トランケーティドユーナリー値（記述子ｔｕ（ｖ））、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値（記述子（ｕｅ（ｖ））、のうちの１つとして、ＡＬＦクリッピングインデックスをコード化（例えば、エンコードまたはデコード）してもよい。ビデオコーダは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。ビデオコーダは、ルーマ成分とクロマ成分のいずれかまたは両方に対して、これを実行してもよい。したがって、ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックスまたはクロマＡＬＦクリッピングインデックスであってもよい。本開示の第１の態様に関して、ビデオコーダは、ＡＬＦの対応するフィルタ係数の値にかかわらず、ＡＬＦクリッピングインデックスをコード化してもよい。

［０１０２］
いくつかの例では、ＡＬＦクリッピングインデックスに基づいてＡＬＦを適用するために、ビデオコーダは、上記で説明したように、式（１’）または（１’’）に示されているように、クリッピングインデックスに基づいて、クリッピング値を決定してもよい。ビデオコーダは、その後、上記で説明したように、式（１）においてクリッピング値を使用してもよい。ビデオコーダは、本開示の他の場所で説明されるように、または、他の方法で、フィルタ係数を決定してもよい。

［０１０３］
本開示は、一般的に、シンタックス要素のような、ある情報を「シグナリングすること」に関連しているかもしれない。「シグナリング」という用語は、一般的に、シンタックス要素に対するおよび／またはエンコードされたビデオデータをデコードするのに使用される他のデータに対する値の通信に関連しているかもしれない。すなわち、ビデオエンコーダ２００は、ビットストリーム中でシンタックス要素に対する値をシグナリングしてもよい。一般的に、シグナリングは、ビットストリーム中で値を発生させることを指している。上述のように、発信元デバイス１０２は、実質的にリアルタイムで、または、宛先デバイス１１６による後の取り出しのために、シンタックス要素を記憶デバイス１１２中に記憶させるときに起こるかもしれないような、リアルタイムではなく、ビットストリームを宛先デバイス１１６に転送してもよい。

［０１０４］
図５Ａおよび図５Ｂは、例示的な４分ツリー２分ツリー（ＱＴＢＴ）構造１３０と、対応するコーディングツリーユニット（ＣＴＵ）１３２とを図示する概念図である。実線は４分ツリー分割を表し、点線は２分ツリー分割を表している。２分ツリーの各分割（すなわち、非リーフ）ノードにおいて、どの分割タイプ（すなわち、水平または垂直）が使用されるかを示すために１つのフラグがシグナリングされ、この例では、０が水平分割を示し、１が垂直分割を示している。４分ツリー分割に対して、４分ツリーノードは、ブロックを等しいサイズで４つのサブブロックに水平および垂直に分割するので、分割タイプを示す必要はない。したがって、ＱＴＢＴ構造１３０の領域ツリーレベル（すなわち、第１のレベル）に対する（分割情報のような）シンタックス要素（すなわち、実線）と、ＱＴＢＴ構造１３０の予測ツリーレベル（すなわち、第２のレベル）に対する（分割情報のような）シンタックス要素（すなわち、破線）を、ビデオエンコーダ２００はエンコードしてもよく、ビデオデコーダ３００は、デコードしてもよい。ＱＴＢＴ構造１３０の終端リーフノードにより表されるＣＵに対する予測データおよび変換データのようなビデオデータを、ビデオエンコーダ２００はエンコードしてもよく、ビデオデコーダ３００は、デコードしてもよい。

［０１０５］
一般的に、図５ＢのＣＴＵ１３２は、第１および第２のレベルにおけるＱＴＢＴ構造１３０のノードに対応するブロックのサイズを規定するパラメータと関係しているかもしれない。これらのパラメータは、（サンプル中のＣＴＵ１３２のサイズを表す）ＣＴＵサイズと、（ＭｉｎＱＴＳｉｚｅ、最小許容４分ツリーリーフノードサイズを表す）最小４分ツリーサイズと、（ＭａｘＢＴＳｉｚｅ、最大許容２分ツリールートノードサイズを表す）最大２分ツリーサイズと、（ＭａｘＢＴＤｅｐｔｈ、最大許容２分ツリー深度を表す）最大２分ツリー深度と、（ＭｉｎＢＴＳｉｚｅ、最小許容２分ツリーリーフノードサイズを表す）最小２分ツリーサイズとを含んでいてもよい。

［０１０６］
ＣＴＵに対応するＱＴＢＴ構造のルートノードは、ＱＴＢＴ構造の第１のレベルにおいて４つの子ノードを有してもよく、それぞれが４分ツリー区分にしたがって、区分されていてもよい。すなわち、第１のレベルのノードは、（子ノードを有さない）リーフノードであるか、または、４つの子ノードを有していてもよい。ＱＴＢＴ構造１３０の例は、親ノードと、分岐に対する実線を有する子ノードとを含むようなノードを表している。第１のレベルのノードが最大許容２分ツリールートノードサイズ（ＭａｘＢＴＳｉｚｅ）より大きくない場合には、その後、ノードは、それぞれの２分ツリーによりさらに区分することができる。分割により得られたノードが最小許容２分ツリーリーフノードサイズ（ＭｉｎＢＴＳｉｚｅ）または最大許容２分ツリー深度（ＭａｘＢＴＤｅｐｔｈ）に達するまで、１つのノードの２分ツリー分割を繰り返すことができる。ＱＴＢＴ構造１３０の例は、分岐に対して破線を有するようなノードを表している。２分ツリーリーフノードは、コーディングユニット（ＣＵ）として呼ばれ、これは、何らかのさらなる区分なく、予測（例えば、イントラピクチャーまたはインターピクチャー予測）および変換に対して使用される。上記で説明したように、ＣＵは、「ビデオブロック」または「ブロック」として呼ばれることもある。

［０１０７］
ＱＴＢＴ区分構造の１つの例では、ＣＴＵサイズは１２８×１２８（ルーマサンプルおよび２つの対応する６４×６４クロマサンプル）として設定され、ＭｉｎＱＴＳｉｚｅは１６×１６として設定され、ＭａｘＢＴＳｉｚｅは６４×６４として設定され、（幅および高さの両方に対して）ＭｉｎＢＴＳｉｚｅは４として設定され、ＭａｘＢＴＤｅｐｔｈは４として設定される。まず、ＣＴＵに対して４分ツリー区分を適用して、４分ツリーリーフノードを発生させる。４分ツリーリーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを有していてもよい。４分ツリーリーフノードが１２８×１２８である場合には、サイズがＭａｘＢＴＳｉｚｅ（すなわち、この例では、６４×６４）を超えることから、ノードは、２分ツリーにより、さらに分割されないだろう。そうでなければ、４分ツリーリーフノードは、２分ツリーにより、さらに区分されるであろう。したがって、４分ツリーリーフノードはまた、２分ツリーに対するルートノードであり、０としての２分ツリー深度を有する。２分ツリー深度がＭａｘＢＴＤｅｐｔｈ（この例では、４）に達するときには、それ以上の分割は許されない。２分ツリーノードがＭｉｎＢＴＳｉｚｅ（この例では、４）に等しい幅を有するときには、それ以上の垂直分割は許されないことを意味する。同様に、ＭｉｎＢＴＳｉｚｅに等しい高さを有する２分ツリーノードは、その２分ツリーノードに対してそれ以上の水平分割は許されないことを意味する。上述したように、２分ツリーのリーフノードはＣＵと呼ばれ、さらなる区分なしで、予測および変換にしたがって、さらに処理される。

［０１０８］
図６は、本開示の技法を実行してもよい、例示的なビデオエンコーダ２００を図示するブロック図である。図６は、説明の目的のために提供されており、本開示において広く例示し説明しているような技法の限定と見なすべきではない。説明の目的のために、本開示は、開発中のＨ．２６５（ＨＥＶＣ）ビデオコーディング標準規格およびＨ．２６６（ＶＣＣ）ビデオコーディング標準規格のような、ビデオコーディング標準規格の状況で、ビデオエンコーダ２００を説明している。しかしながら、本開示の技法は、これらのビデオコーディング標準規格には限定されず、一般的に、ビデオエンコーディングおよびデコーディングに適用可能である。

［０１０９］
図６の例では、ビデオエンコーダ２００は、ビデオデータメモリ２３０と、モード選択ユニット２０２と、残差発生ユニット２０４と、変換処理ユニット２０６と、量子化ユニット２０８と、逆量子化ユニット２１０と、逆変換処理ユニット２１２と、再構築ユニット２１４と、フィルタユニット２１６と、デコードピクチャーバッファ（ＤＢＰ）２１８と、エントロピーエンコーディングユニット２２０とを含んでいる。ビデオデータメモリ２３０と、モード選択ユニット２０２と、残差発生ユニット２０４と、変換処理ユニット２０６と、量子化ユニット２０８と、逆量子化ユニット２１０と、逆変換処理ユニット２１２と、再構築ユニット２１４と、フィルタユニット２１６と、ＤＢＰ２１８と、エントロピーエンコーディングユニット２２０のいずれかまたはすべてを、１つ以上のプロセッサ中で、または、処理回路中で実現してもよい。さらに、ビデオエンコーダ２００は、これらまたは他の機能を実行するために、追加または代替のプロセッサまたは処理回路を含んでいてもよい。

［０１１０］
ビデオデータメモリ２３０は、ビデオエンコーダ２００のコンポーネントによってエンコードされることになるビデオデータを記憶していてもよい。ビデオエンコーダ２００は、例えば、ビデオソース１０４（図１）からのビデオデータメモリ２３０中に記憶されているビデオデータを受け取ってもよい。ＤＰＢ２１８は、ビデオエンコーダ２００による後続のビデオデータの予測において使用するための参照ビデオデータを記憶する参照ピクチャーメモリとして機能してもよい。ビデオデータメモリ２３０およびＤＰＢ２１８は、同期ダイナミックランダムアクセスメモリ（ＤＲＡＭ）（ＳＤＲＡＭ）を含むＤＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または、他のタイプのメモリデバイスのような、さまざまなメモリデバイスのうちのいずれかによって形成されていてもよい。ビデオデータメモリ２３０およびＤＰＢ２１８は、同じメモリデバイスまたは別個のメモリデバイスによって提供されていてもよい。さまざまな例では、ビデオデータメモリ２３０は、図示するように、ビデオエンコーダ２００の他のコンポーネントとともにオンチップであってもよく、または、これらのコンポーネントに対してオフチップであってもよい。

［０１１１］
本開示では、ビデオデータメモリ２３０への参照は、そのように具体的に説明されない限り、ビデオエンコーダ２００に対して内部であるメモリ、または、そのように具体的に説明されない限り、ビデオエンコーダ２００に対して外部であるメモリに限定されるものとして解釈すべきではない。むしろ、ビデオデータメモリ２３０への参照は、ビデオエンコーダ２００がエンコードするために受け取るビデオデータ（例えば、エンコードされることになる現在ブロックに対するビデオデータ）を記憶する参照メモリとして理解すべきである。図１のメモリ１０６はまた、ビデオエンコーダ２００のさまざまなユニットからの出力の一時記憶装置を提供してもよい。

［０１１２］
図６のさまざまなユニットは、ビデオエンコーダ２００によって実行される動作の理解を助けるために図示されている。ユニットは、固定機能回路、プログラマブル回路、または、これらの組み合わせとして実現してもよい。固定機能回路は、特定の機能性を提供する回路を指し、実行できる動作に対して予め設定される。プログラマブル回路は、さまざまなタスクを実行するようにプログラムでき、実行できる動作において柔軟な機能性を提供できる回路を指している。例えば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって規定される方法でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行してもよい。固定機能回路は、（例えば、パラメータを受け取るまたはパラメータを出力するために）ソフトウェア命令を実行するかもしれないが、固定機能回路が実行する動作のタイプは一般的に不変である。いくつかの例では、ユニットのうちの１つ以上は、別個の回路ブロック（固定機能またはプログラマブル）であってよく、いくつかの例では、１つ以上のユニットは集積回路であってよい。

［０１１３］
ビデオエンコーダ２００は、プログラマブル回路から形成される、算術論理ユニット（ＡＬＵ）、基本機能ユニット（ＥＦＵ）、デジタル回路、アナログ回路、および／または、プログラマブルコアを含んでいてもよい。ビデオエンコーダ２００の動作がプログラマブル回路によって実行されるソフトウェアを使用して実施される例では、メモリ１０６（図１）は、ビデオエンコーダ２００が受け取って実行するソフトウェアのオブジェクトコードを記憶していてもよく、または、ビデオエンコーダ２００内の（図示されていない）別のメモリがこのような命令を記憶していてもよい。

［０１１４］
ビデオデータメモリ２３０は、受け取ったビデオデータを記憶するように構成されている。ビデオエンコーダ２００は、ビデオデータメモリ２３０からビデオデータのピクチャーを取り出し、ビデオデータを残差発生ユニット２０４およびモード選択ユニット２０２に提供してもよい。ビデオデータメモリ２３０中のビデオデータは、エンコードされることになる生のビデオデータであってもよい。

［０１１５］
モード選択ユニット２０２は、動き推定ユニット２２２と、動き補償ユニット２２４と、イントラ予測ユニット２２６とを含んでいる。モード選択ユニット２０２は、他の予測モードにしたがってビデオ予測を実行するための追加の機能ユニットを含んでいてもよい。例として、モード選択ユニット２０２は、パレットユニット、（動き推定ユニット２２２および／または動き補償ユニット２２４の一部であってもよい）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ）ユニット、または、これらに類するものを含んでいてもよい。

［０１１６］
モード選択ユニット２０２は、一般的に、複数のエンコーディングパスを調整して、エンコーディングパラメータの組み合わせをテストし、結果として、このような組み合わせに対するレート歪み値を得る。エンコーディングパラメータは、ＣＴＵのＣＵへの区分、ＣＵに対する予測モード、ＣＵの残差データに対する変換タイプ、ＣＵの残差データに対する量子化パラメータ等を含んでいてもよい。モード選択ユニット２０２は、最終的に、他のテストされた組み合わせよりも良好なレート歪み値を有するエンコーディングパラメータの組み合わせを選択してもよい。

［０１１７］
ビデオエンコーダ２００は、ビデオデータメモリ２３０から取り出されたピクチャーを一連のＣＴＵに区分し、スライス内に１つ以上のＣＴＵをカプセル化してもよい。モード選択ユニット２０２は、上記で説明したＱＴＢＴ構造またはＨＥＶＣの４分ツリー構造のようなツリー構造にしたがって、ピクチャーのＣＴＵを区分してもよい。上記で説明したように、ビデオエンコーダ２００は、ツリー構造にしたがってＣＴＵを区分することから１つ以上のＣＵを形成してもよい。このようなＣＵは、一般的に、「ビデオブロック」または「ブロック」として呼ばれることもある。

［０１１８］
一般的に、モード選択ユニット２０２はまた、そのコンポーネント（例えば、動き推定ユニット２２２、動き補償ユニット２２４、および、イントラ予測ユニット２２６）を制御して、現在ブロック（例えば、現在ＣＵ、または、ＨＥＶＣでは、ＰＵとＴＵとのオーバーラップする部分）に対する予測ブロックを発生させる。現在ブロックのインター予測のために、動き推定ユニット２２２は、動きサーチを実行して、１つ以上の参照ピクチャー（例えば、ＤＰＢ２１８中に記憶されている１つ以上の以前にコード化されたピクチャー）中の１つ以上の密接に一致する参照ブロックを識別してもよい。特に、動き推定ユニット２２２は、例えば、絶対差分の和（ＳＡＤ）、二乗差分の和（ＳＳＤ）、平均絶対差分（ＭＡＤ）、平均二乗差分（ＭＳＤ）、または、これらに類するものにしたがって、潜在的参照ブロックが現在ブロックにどれだけ類似しているかを表す値を計算してもよい。動き推定ユニット２２２は、一般的に、現在ブロックと考慮されている参照ブロックとの間のサンプル毎の差分を使用して、これらの計算を実行してもよい。動き推定ユニット２２２は、現在ブロックに最も密接に一致する参照ブロックを示す、これらの計算から結果的に生じる最低値を有する参照ブロックを識別してもよい。

［０１１９］
動き推定ユニット２２２は、現在ピクチャー中の現在ブロックのポジションに対する、参照ピクチャー中の参照ブロックのポジションを規定する、１つ以上の動きベクトル（ＭＶ）を形成してもよい。動き推定ユニット２２２は、その後、動きベクトルを動き補償ユニット２２４に提供してもよい。例えば、単方向インター予測に対して、動き推定ユニット２２２は単一の動きベクトルを提供するかもしれない一方で、双方向インター予測に対して、動き推定ユニット２２２は２つの動きベクトルを提供するかもしれない。動き補償ユニット２２４は、その後、動きベクトルを使用して、予測ブロックを発生させてもよい。例えば、動き補償ユニット２２４は、動きベクトルを使用して、参照ブロックのデータを取り出してもよい。別の例として、動きベクトルが小数サンプル精度を有する場合には、動き補償ユニット２２４は、１つ以上の補間フィルタにしたがって、予測ブロックに対する値を補間してもよい。さらに、双方向インター予測に対して、動き補償ユニット２２４は、それぞれの動きベクトルによって識別された２つの参照ブロックに対するデータを取り出し、例えば、サンプル毎の平均化または重み付き平均化を通してのように、取り出されたデータを組み合わせてもよい。

［０１２０］
別の例として、イントラ予測またはイントラ予測コーディングに対して、イントラ予測ユニット２２６は、現在ブロックに隣接するサンプルから予測ブロックを発生させてもよい。例えば、方向モードに対して、イントラ予測ユニット２２６は、一般的に、隣接サンプルの値を数学的に組み合わせ、現在ブロックに渡って規定された方向でこれらの計算された値を格納して、予測ブロックを生成させてもよい。別の例として、ＤＣモードに対して、イントラ予測ユニット２２６は、現在ブロックに対する隣接サンプルの平均を計算し、予測ブロックの各サンプルに対するこの結果として得られる平均を含むように予測ブロックを発生させてもよい。

［０１２１］
モード選択ユニット２０２は、予測ブロックを残差発生ユニット２０４に提供する。残差発生ユニット２０４は、ビデオデータメモリ２３０から現在ブロックの生のエンコードされていないバージョンを受け取り、モード選択ユニット２０２から予測ブロックを受け取る。残差発生ユニット２０４は、現在ブロックと予測ブロックとの間のサンプル毎の差分を計算する。結果として得られるサンプル毎の差分は、現在ブロックに対する残差ブロックを規定する。いくつかの例では、残差発生ユニット２０４はまた、残差ブロック中のサンプル値間の差分を決定して、残差パルスコード変調（ＲＤＰＣＭ）を使用して、残差ブロックを発生させてもよい。いくつかの例では、残差発生ユニット２０４は、バイナリ減算を実行する１つ以上の減算器回路を使用して形成されていてもよい。

［０１２２］
モード選択ユニット２０２がＣＵをＰＵに区分する例では、各ＰＵは、ルーマ予測ユニットおよび対応するクロマ予測ユニットに関係していてもよい。ビデオエンコーダ２００およびビデオデコーダ３００は、さまざまなサイズを有するＰＵをサポートしていてもよい。上記で示したように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指していてもよく、ＰＵのサイズは、ＰＵのルーマ予測ユニットのサイズを指していてもよい。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２００は、イントラ予測に対する２Ｎ×２ＮまたはＮ×ＮのＰＵサイズと、インター予測に対する２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、または、これらに類する対称ＰＵサイズとをサポートしていてもよい。ビデオエンコーダ２００およびビデオデコーダ３００はまた、インター予測のために、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、および、ｎＲ×２ＮのＰＵサイズに対する非対称区分をサポートしていてもよい。

［０１２３］
モード選択ユニットがＣＵをＰＵにさらに区分しない例では、各ＣＵは、ルーマコーディングブロックおよび対応するクロマコーディングブロックに関係していてもよい。上記のように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指していてもよい。ビデオエンコーダ２００およびビデオデコーダ３００は、２Ｎ×２Ｎ、２Ｎ×Ｎ、または、Ｎ×２ＮのＣＵサイズをサポートしていてもよい。

［０１２４］
イントラブロックコピーモードコーディング、アフィンモードコーディング、および、線形モデル（ＬＭ）モードコーディングのような、他のビデオコーディング技法に対して、いくつかの例として、モード選択ユニット２０２は、コーディング技法に関係するそれぞれのユニットを介して、エンコードされている現在ブロックに対する予測ブロックを発生させる。パレットモードコーディングのようないくつかの例では、モード選択ユニット２０２は、予測ブロックを発生させず、代わりに、選択されたパレットに基づいて、ブロックを再構築する方法を示すシンタックス要素を発生させてもよい。このようなモードでは、モード選択ユニット２０２は、これらのシンタックス要素を、エンコードされるようにエントロピーエンコーディングユニット２２０に提供してもよい。

［０１２５］
上記で説明したように、残差発生ユニット２０４は、現在ブロックおよび対応する予測ブロックに対するビデオデータを受け取る。残差発生ユニット２０４は、その後、現在ブロックに対する残差ブロックを発生させる。残差ブロックを発生させるために、残差発生ユニット２０４は、予測ブロックと現在ブロックとの間のサンプル毎の差分を計算する。

［０１２６］
変換処理ユニット２０６は、残差ブロックに１つ以上の変換を適用して、（ここでは「変換係数ブロック」として呼ばれる）変換係数のブロックを発生させる。変換処理ユニット２０６は、残差ブロックにさまざまな変換を適用して、変換係数ブロックを形成してもよい。例えば、変換処理ユニット２０６は、離散コサイン変換（ＤＣＴ）、方向変換、カルーネンレーベ変換（ＫＬＴ）、または、概念的に類似する変換を、残差ブロックに適用してもよい。いくつかの例では、変換処理ユニット２０６は、残差ブロックに対して複数の変換、例えば、回転変換のような、１次変換と２次変換とを実行してもよい。いくつかの例では、変換処理ユニット２０６は、残差ブロックに変換を適用しない。

［０１２７］
量子化ユニット２０８は、変換係数ブロック中の変換係数を量子化して、量子化された変換係数ブロックを生成させてもよい。量子化ユニット２０８は、現在ブロックに関係する量子化パラメータ（ＱＰ）値にしたがって、変換係数ブロックの変換係数を量子化してもよい。ビデオエンコーダ２００は（例えば、モード選択ユニット２０２を介して）、ＣＵに関係するＱＰ値を調節することによって、現在ブロックに関係する変換係数ブロックに適用される量子化の程度を調節してもよい。量子化は、情報の損失をもたらすかもしれず、したがって、量子化された変換係数は、変換処理ユニット２０６によって生成された元の変換係数よりも低い精度を有するかもしれない。

［０１２８］
逆量子化ユニット２１０および逆変換処理ユニット２１２は、逆量子化および逆変換をそれぞれ量子化された変換係数ブロックに適用して、変換係数ブロックから残差ブロックを再構築してもよい。再構築ユニット２１４は、再構築された残差ブロックと、モード選択ユニット２０２によって発生された予測ブロックとに基づいて、（潜在的にある程度の歪みを有するが）現在ブロックに対応する再構築されたブロックを生成させてもよい。例えば、再構築ユニット２１４は、再構築された残差ブロックのサンプルを、モード選択ユニット２０２によって発生された予測ブロックからの対応するサンプルに追加して、再構築されたブロックを生成させてもよい。

［０１２９］
フィルタユニット２１６は、再構築されたブロックに対して１つ以上のフィルタ動作を実行してもよい。例えば、フィルタユニット２１６は、デブロッキング動作を実行して、ＣＵのエッジに沿ったブロッキネスアーティファクトを低減させてもよい。いくつかの例では、フィルタユニット２１６の動作はスキップしてもよい。本開示の例によると、フィルタユニット２１６は、固定長符号なし整数としてコード化されたＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。

［０１３０］
ビデオエンコーダ２００は、再構築されたブロックをＤＰＢ２１８中に記憶させる。例えば、フィルタユニット２１６の動作が必要とされない例では、再構築ユニット２１４は、再構築されたブロックをＤＰＢ２１８中に記憶させてもよい。フィルタユニット２１６の動作が必要とされる例では、フィルタユニット２１６は、再構築されフィルタされたブロックをＤＰＢ２１８中に記憶させてもよい。動き推定ユニット２２２および動き補償ユニット２２４は、再構築された（そして、潜在的にフィルタ処理された）ブロックから形成された参照ピクチャーをＤＰＢ２１８から取り出して、後にエンコードされるピクチャーのブロックをインター予測してもよい。加えて、イントラ予測ユニット２２６は、現在ピクチャーのＤＰＢ２１８中の再構築されたブロックを使用して、現在ピクチャー中の他のブロックをイントラ予測してもよい。

［０１３１］
一般的に、エントロピーエンコーディングユニット２２０は、ビデオエンコーダ２００の他の機能的なコンポーネントから受け取ったシンタックス要素をエントロピーエンコードしてもよい。例えば、エントロピーエンコーディングユニット２２０は、量子化ユニット２０８からの量子化された変換係数ブロックをエントロピーエンコードしてもよい。別の例として、エントロピーエンコーディングユニット２２０は、モード選択ユニット２０２からの予測シンタックス要素（例えば、インター予測に対する動き情報またはイントラ予測に対するイントラモード情報）をエントロピーエンコードしてもよい。エントロピーエンコーディングユニット２２０は、ビデオデータの別の例であるシンタックス要素に関して、１つ以上のエントロピーエンコーディング動作を実行して、エントロピーエンコードされたデータを発生させてもよい。例えば、エントロピーエンコーディングユニット２２０は、データに、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）動作、ＣＡＢＡＣ動作、可変対可変（Ｖ２Ｖ）長コーディング動作、シンタックスベースのコンテキスト適応バイナリ算術コードディング（ＳＢＡＣ）動作、確率区間区分化エントロピー（ＰＩＰＥ）コーディング動作、指数ゴロムエンコーディング動作、または、別のタイプのエントロピーエンコーディング動作を実行してもよい。いくつかの例では、エントロピーエンコーディングユニット２２０は、シンタックス要素がエントロピーエンコードされないバイパスモードで動作してもよい。

［０１３２］
ビデオエンコーダ２００は、スライスまたはピクチャーのブロックを再構築するのに必要とされるエントロピーエンコードされたシンタックス要素を含むビットストリームを出力してもよい。特に、エントロピーエンコーディングユニット２２０が、ビットストリームを出力してもよい。

［０１３３］
上記で説明している動作は、ブロックに関して説明している。このような説明は、ルーマコーディングブロックおよび／またはクロマコーディングブロックに対する動作として理解すべきである。上述したように、いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、ＣＵのルーマ成分およびクロマ成分である。いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、ＰＵのルーマ成分およびクロマ成分である。

［０１３４］
いくつかの例では、ルーマコーディングブロックに関して実行される動作は、クロマコーディングブロックに対して繰り返す必要はない。１つの例として、ルーマコーディングブロックに対する動きベクトル（ＭＶ）および参照ピクチャーを識別する動作は、クロマブロックに対するＭＶおよび参照ピクチャーを識別するために繰り返す必要はない。むしろ、ルーマコーディングブロックに対するＭＶをスケーリングして、クロマブロックに対するＭＶを決定してもよく、参照ピクチャーは同じであってもよい。別の例として、イントラ予測プロセスは、ルーマコーディングブロックおよびクロマコーディングブロックに対して同じであってもよい。

［０１３５］
ビデオエンコーダ２００は、ビデオデータを記憶するように構成されているメモリと、回路中で実現され、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、ＡＬＦクリッピングインデックスをエンコードするように構成されている１つ以上の処理ユニットとを含む、ビデオデータをエンコードするように構成されているデバイスの例を表している。言い換えると、ビデオエンコーダ２００は、ビデオデータのエンコードされた表現を含むビットストリーム中に、ＡＬＦクリッピングインデックスシンタックス要素を含めてもよく、ＡＬＦクリッピングインデックスシンタックス要素は、これらのデータのタイプのうちの１つとしてフォーマットされている。いくつかの例では、ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘまたは別のシンタックス要素）、あるいは、クロマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘまたは別のシンタックス要素）である。さらに、ビデオエンコーダ２００の処理ユニットは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。例えば、ビデオエンコーダ２００のフィルタユニット２１６がＡＬＦを適用してもよい。

［０１３６］
図７は、本開示の技法を利用してもよい、例示的なビデオデコーダ３００を図示するブロック図である。図７は、説明の目的のために提供されており、本開示で広く例示し説明しているような技法には限定されない。説明の目的で、本開示は、ＶＶＣおよびＨＥＶＣの技法にしたがうビデオデコーダ３００を説明している。しかしながら、本開示の技法は、他のビデオコーディング標準規格にしたがって構成されているビデオコーディングデバイスによって実行してもよい。

［０１３７］
図７の例では、ビデオデコーダ３００は、コード化ピクチャーバッファ（ＣＰＢ）メモリ３２０と、エントロピーデコーディングユニット３０２と、予測処理ユニット３０４と、逆量子化ユニット３０６と、逆変換処理ユニット３０８と、再構築ユニット３１０と、フィルタユニット３１２と、デコードピクチャーバッファ（ＤＰＢ）３１４とを含んでいる。ＣＰＢメモリ３２０と、エントロピーデコーディングユニット３０２と、予測処理ユニット３０４と、逆量子化ユニット３０６と、逆変換処理ユニット３０８と、再構築ユニット３１０と、フィルタユニット３１２と、ＤＰＢ３１４のいずれかまたはすべてを、１つ以上のプロセッサ中で、または、処理回路中で実現してもよい。さらに、ビデオデコーダ３００は、これらまたは他の機能を実行するために、追加または代替のプロセッサまたは処理回路を含んでいてもよい。

［０１３８］
予測処理ユニット３０４は、動き補償ユニット３１６とイントラ予測ユニット３１８とを含んでいる。予測処理ユニット３０４は、他の予測モードにしたがって予測を実行するための追加ユニットを含んでいてもよい。例として、予測処理ユニット３０４は、パレットコーディングユニット、（動き補償ユニット３１６の一部を形成していてもよい）イントラブロックコピーコーディングユニット、アフィンコーディングユニット、線形モデル（ＬＭ）コーディングユニット、または、これらに類するものを含んでいてもよい。他の例では、ビデオデコーダ３００は、より多い、より少ない、または、異なる機能的コンポーネントを含んでいてもよい。

［０１３９］
ＣＰＢメモリ３２０は、ビデオデコーダ３００のコンポーネントによってデコードされることになる、エンコードされたビデオビットストリームのようなビデオデータを記憶してもよい。ＣＰＢメモリ３２０中に記憶されるビデオデータは、例えば、コンピュータ読取可能媒体１１０（図１）から取得されてもよい。ＣＰＢメモリ３２０は、エンコードされたビデオビットストリームからのエンコードされたビデオデータ（例えば、シンタックス要素）を記憶するＣＰＢを含んでいてもよい。また、ＣＰＢメモリ３２０は、ビデオデコーダ３００のさまざまなユニットからの出力を表す一時データのような、コード化されたピクチャーのシンタックス要素以外のビデオデータを記憶してもよい。ＤＰＢ３１４は、一般的に、デコードされたピクチャーを記憶し、エンコードされたビデオビットストリームの後続のデータまたはピクチャーをデコードするときに、ビデオデコーダ３００が、このデコードされたピクチャーを、参照ビデオデータとして出力および／または使用してもよい。ＣＰＢメモリ３２０およびＤＰＢ３１４は、ＳＤＲＡＭを含むＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ（登録商標）、または、他のタイプのメモリデバイスのような、さまざまなメモリデバイスのいずれかによって形成されていてもよい。ＣＰＢメモリ３２０およびＤＰＢ３１４は、同じメモリデバイスまたは別個のメモリデバイスによって提供されてもよい。さまざまな例では、ＣＰＢメモリ３２０は、ビデオデコーダ３００の他のコンポーネントとともにオンチップであるか、または、これらのコンポーネントに対してオフチップであってもよい。

［０１４０］
追加的にまたは代替的に、いくつかの例では、ビデオデコーダ３００は、メモリ１２０（図１）からコード化されたビデオデータを取り出してもよい。すなわち、メモリ１２０は、ＣＰＢメモリ３２０を用いて上記で説明したようなデータを記憶していてもよい。同様に、ビデオデコーダ３００の機能性のいくつかまたはすべてが、ビデオデコーダ３００の処理回路によって実行されるソフトウェアで実現されるとき、メモリ１２０は、ビデオデコーダ３００によって実行されることになる命令を記憶していてもよい。

［０１４１］
図７に示されているさまざまなユニットは、ビデオデコーダ３００によって実行される動作の理解を助けるために図示されている。ユニットは、固定機能回路、プログラマブル回路、または、これらの組み合わせとして実現してもよい。図６と同様に、固定機能回路は、特定の機能性を提供する回路を指し、実行できる動作に対して予め設定される。プログラマブル回路は、さまざまなタスクを実行するようにプログラムでき、実行できる動作において柔軟な機能性を提供できる回路を指している。例えば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって規定される方法でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行してもよい。固定機能回路は、（例えば、パラメータを受け取るまたはパラメータを出力するために）ソフトウェア命令を実行するかもしれないが、固定機能回路が実行する動作のタイプは一般的に不変である。いくつかの例では、ユニットのうちの１つ以上は、別個の回路ブロック（固定機能またはプログラマブル）であってもよく、いくつかの例では、１つ以上のユニットは集積回路であってもよい。

［０１４２］
ビデオデコーダ３００は、ＡＬＵ、ＥＦＵ、デジタル回路、アナログ回路、および／または、プログラマブル回路から形成されているプログラマブルコアを含んでいてもよい。ビデオデコーダ３００の動作がプログラマブル回路上で実行するソフトウェアによって実行される例では、オンチップまたはオフチップメモリが、ビデオデコーダ３００が受け取って実行するソフトウェアの命令（例えば、オブジェクトコード）を記憶していてもよい。

［０１４３］
エントロピーデコーディングユニット３０２は、ＣＰＢからエンコードされたビデオデータを受け取り、ビデオデータをエントロピーデコードして、シンタックス要素を再生させてもよい。予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構築ユニット３１０、および、フィルタユニット３１２は、ビットストリームから抽出されたシンタックス要素に基づいて、デコードされたビデオデータを発生させてもよい。

［０１４４］
一般的に、ビデオデコーダ３００は、ブロック毎のベースでピクチャーを再構築する。ビデオデコーダ３００は、各ブロックに対して個別に再構築動作を実行してもよい（現在再構築されている、すなわち、デコードされているブロックは、「現在ブロック」として呼ばれることがある）。

［０１４５］
エントロピーデコーディングユニット３０２は、量子化された変換係数ブロックの量子化された変換係数を規定するシンタックス要素とともに、量子化パラメータ（ＱＰ）および／または変換モードインジケーションのような変換情報をエントロピーデコードしてもよい。逆量子化ユニット３０６は、量子化変換係数ブロックに関係するＱＰを使用して、量子化の程度を、そして、同様に逆量子化ユニット３０６が適用する逆量子化の程度を決定してもよい。逆量子化ユニット３０６は、例えば、ビット単位の左シフト演算を実行して、量子化変換係数を逆量子化してもよい。それによって、逆量子化ユニット３０６は、変換係数を含む変換係数ブロックを形成してもよい。

［０１４６］
逆量子化ユニット３０６が変換係数ブロックを形成した後、逆変換処理ユニット３０８は、変換係数ブロックに１つ以上の逆変換を適用して、現在ブロックに関係する残差ブロックを発生させてもよい。例えば、逆変換処理ユニット３０８は、変換係数ブロックに、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向変換、または、別の逆変換を適用してもよい。

［０１４７］
さらに、予測処理ユニット３０４は、エントロピーデコーディングユニット３０２によってエントロピーデコードされた予測情報シンタックス要素にしたがって、予測ブロックを発生させる。例えば、現在ブロックがインター予測されることを予測情報シンタックス要素が示す場合、動き補償ユニット３１６が予測ブロックを発生させてもよい。このケースでは、予測情報シンタックス要素は、参照ブロックを取り出すことになるＤＰＢ３１４中の参照ピクチャーとともに、現在ピクチャー中の現在ブロックのポジションに対する、参照ピクチャー中の参照ブロックのポジションを識別する動きベクトルを示していてもよい。動き補償ユニット３１６は、一般的に、動き補償ユニット２２４（図６）に関して説明した方法と実質的に類似する方法で、インター予測プロセスを実行してもよい。

［０１４８］
別の例として、現在ブロックがイントラ予測されることを予測情報シンタックス要素が示している場合、イントラ予測ユニット３１８は、予測情報シンタックス要素によって示されているイントラ予測モードにしたがって、予測ブロックを発生させてもよい。再度説明すると、イントラ予測ユニット３１８は、一般的に、イントラ予測ユニット２２６（図６）に関して説明した方法と実質的に類似する方法で、イントラ予測プロセスを実行してもよい。イントラ予測ユニット３１８は、現在ブロックに対する隣接するサンプルのデータをＤＰＢ３１４から取り出してもよい。

［０１４９］
再構築ユニット３１０は、予測ブロックと残差ブロックとを使用して、現在ブロックを再構築してもよい。例えば、再構築ユニット３１０は、残差ブロックのサンプルを予測ブロックの対応するサンプルに追加して、現在ブロックを再構築してもよい。

［０１５０］
フィルタユニット３１２は、再構築されたブロックに対して１つ以上のフィルタ動作を実行してもよい。例えば、フィルタユニット３１２は、デブロッキング動作を実行して、再構築されたブロックのエッジに沿ったブロッキネスアーティファクトを低減させてもよい。フィルタユニット３１２の動作は、必ずしもすべての例において実行する必要はない。本開示の例によると、フィルタユニット３１２は、固定長符号なし整数としてコード化されたＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。

［０１５１］
ビデオデコーダ３００は、再構築されたブロックをＤＰＢ３１４中に記憶させてもよい。例えば、フィルタユニット３１２の動作が実行されない例では、再構築ユニット３１０が、再構築されたブロックをＤＰＢ３１４に記憶させてもよい。フィルタユニット３１２の動作が実行される例では、フィルタユニット３１２が、再構築されフィルタされたブロックをＤＰＢ３１４に記憶させてもよい。上記で説明したように、ＤＰＢ３１４は、イントラ予測に対する現在ピクチャーと、後続の動き補償のための以前にデコードされたピクチャーとのサンプルのような参照情報を、予測処理ユニット３０４に提供してもよい。さらに、ビデオデコーダ３００は、図１のディスプレイデバイス１１８のようなディスプレイデバイス上での後続の提示のために、ＤＰＢ３１４からデコードされたピクチャーを出力してもよい。

［０１５２］
このようにして、ビデオデコーダ３００は、ビデオデータを記憶するように構成されているメモリと、回路中で実現され、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、ＡＬＦクリッピングインデックスをデコードするように構成されている１つ以上の処理ユニットとを含む、ビデオデコーディングデバイスの例を表している。言い換えると、ビデオデコーダ３００は、ビットストリームからＡＬＦクリッピングインデックスシンタックス要素を取得して、これらのデータのタイプのうちの１つとして、ＡＬＦクリッピングインデックスシンタックス要素を解釈してもよい。いくつかの例では、ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘまたは別のシンタックス要素）、あるいは、クロマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘまたは別のシンタックス要素）である。さらに、ビデオデコーダ３００の処理ユニットは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい。例えば、ビデオデコーダ３００のフィルタユニット３１２がＡＬＦを適用してもよい。

［０１５３］
図８は、現在ブロックをエンコードするための方法の例を図示するフローチャートである。現在ブロックは、現在ＣＵを含んでいてもよい。ビデオエンコーダ２００（図１および図６）に関して説明したが、図８の方法と類似する方法を実行するように他のデバイスが構成されていてもよいことを理解されたい。

［０１５４］
この例では、ビデオエンコーダ２００は、最初に現在ブロックを予測する（３５０）。例えば、ビデオエンコーダ２００は、現在ブロックに対する予測ブロックを形成してもよい。ビデオエンコーダ２００は、その後、現在ブロックに対する残差ブロックを計算してもよい。（３５２）。残差ブロックを計算するために、ビデオエンコーダ２００は、現在ブロックに対する元のエンコードされていないブロックと予測ブロックとの間の差分を計算してもよい。ビデオエンコーダ２００は、その後、残差ブロックの変換係数を変換および量子化してもよい（３５４）。次に、ビデオエンコーダ２００は、残差ブロックの量子化された変換係数を走査してもよい（３５６）。走査の間、または、走査に続いて、ビデオエンコーダ２００は、変換係数をエントロピーエンコードしてもよい（３５８）。例えば、ビデオエンコーダ２００は、ＣＡＶＬＣまたはＣＡＢＡＣを使用して、変換係数をエンコードしてもよい。ビデオエンコーダ２００は、その後、ブロックのエントロピーエンコードされたデータを出力してもよい（３６０）。

［０１５５］
さらに、図８の例では、後続のブロックの予測をサポートするために、ビデオエンコーダ２００は、現在ブロックを再構築してもよい（３６２）。例えば、ビデオエンコーダ２００は、現在ブロックの変換係数を逆量子化し、逆変換を変換係数に適用して残差データを発生させ、現在ブロックに対する残差データを現在ブロックの予測ブロックに追加してもよい。さらに、ビデオエンコーダ２００は、現在ピクチャーの再構築されたブロックに１つ以上のフィルタを適用してもよい（３６４）。例えば、ビデオエンコーダ２００は、現在ピクチャーの再構築されたブロックにＡＬＦを適用してもよい。本開示の技法によれば、ビデオデコーダ３００におけるＡＬＦの対応する適用をサポートするために、ビデオエンコーダ２００は、ＡＬＦクリッピングインデックスをエンコードしてもよい。ビデオエンコーダ２００（例えば、ビデオエンコーダ２００のフィルタユニット２１６）は、ＡＬＦクリッピングインデックスに基づいて、現在ピクチャーのブロック（例えば、再構築されたブロック）にＡＬＦを適用してもよい。本開示の技法によれば、ビデオエンコーダ２００は、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値として、ＡＬＦクリッピングインデックスをエンコードしてもよい。

［０１５６］
図９は、ビデオデータの現在ピクチャーの現在ブロックをデコードするための例示的な方法を図示するフローチャートである。現在ブロックは、現在ＣＵを含んでいてもよい。ビデオデコーダ３００（図１および図７）に関して説明したが、図９の方法と類似する方法を実行するように他のデバイスが構成されていてもよいことを理解されたい。

［０１５７］
ビデオデコーダ３００は、現在ブロックに対応する残差ブロックの変換係数に対する、エントロピーエンコードされた予測情報およびエントロピーエンコードされたデータのような、現在ブロックに対するエントロピーエンコードされたデータを受け取ってもよい（３７０）。ビデオデコーダ３００はまた、ビットストリーム中でエントロピーエンコードされていないデータを受け取ってもよい。ビデオデコーダ３００は、エントロピーエンコードされたデータをエントロピーデコードして、現在ブロックに対する予測情報を決定し、残差ブロックの変換係数を再生させてもよい（３７２）。ビデオデコーダ３００は、例えば、現在ブロックに対する予測情報により示されているイントラ予測モードまたはインター予測モードを使用して現在ブロックを予測して、現在ブロックに対する予測ブロックを計算してもよい（３７４）。ビデオデコーダ３００は、その後、再生された変換係数を逆走査して、量子化された変換係数のブロックを生成させてもよい（３７６）。ビデオデコーダ３００（逆量子化ユニット３０６および逆変換処理ユニット３０８）は、その後、変換係数を逆量子化および逆変換して、残差ブロックを生成させてもよい（３７８）。ビデオデコーダ３００は、予測ブロックと残差ブロックとを組み合わせることにより、現在ブロックをデコードしてもよい（３８０）。

［０１５８］
さらに、図９の例では、予測ブロックと残差ブロックとを組み合わせて、現在ブロックを再構築した後に、ビデオデコーダ３００（例えば、ビデオデコーダ３００のフィルタユニット３１２）は、現在ピクチャーの再構築されたブロックに１つ以上のフィルタを適用してもよい（３８２）。例えば、ビデオデコーダ３００は、現在ピクチャーの再構築されたブロックにＡＬＦを適用してもよい。ビデオデコーダ３００は、ＡＬＦクリッピングインデックスをデコードし、ＡＬＦクリッピングインデックスに基づいて、現在ピクチャーのブロック（例えば、再構築されたブロック）にＡＬＦを適用してもよい。本開示の技法によれば、ビデオデコーダ３００は、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値として、ＡＬＦクリッピングインデックスをデコードしてもよい。

［０１５９］
図１０は、本開示の１つ以上の技法による、ビデオデータをコード化するための例示的な動作を図示するフローチャートである。図１０の例では、ビデオコーダ（例えば、ビデオエンコーダ２００またはビデオデコーダ３００）は、固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化（例えば、エンコードまたはデコード）してもよい（４００）。例えば、ビデオコーダがビデオエンコーダ２００のようなビデオエンコーダであるときには、ビデオエンコーダは、ＡＬＦクリッピングインデックスを表す固定長符号なし整数をビットストリーム中に含めることにより、ＡＬＦクリッピングインデックスをエンコードしてもよい。例えば、ビデオコーダがビデオデコーダ３００のようなビデオデコーダである例では、ビデオデコーダは、ＡＬＦクリッピングインデックスを表す固定長符号なし整数をビットストリームからパースすることにより、ＡＬＦクリッピングインデックスをデコードしてもよい。

［０１６０］
さらに、図１０の例では、ビデオコーダは、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用してもよい（４０２）。例えば、ビデオコーダは、例えば、上記の式（１’）または式（１’’）を使用して、ＡＬＦクリッピングインデックスを使用して、クリッピング値のセット（例えば、－ｃ（ｋ，ｌ）およびｃ（ｋ，ｌ））をルックアップまたは計算してもよい。ビデオコーダは、その後、（例えば、上記の式（１）中に示されているように）ブロックの再構築されたサンプルにＡＬＦを適用する際に、クリッピング値のセットを使用してもよい。ビデオコーダは、図８のアクション３６４または図９のアクション３８２の一部として、ＡＬＦを適用してもよい。ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｌｕｍａ＿ｃｌｉｐ＿ｉｄｘ）であってもよく、このケースでは、ビデオコーダは、ルーマＡＬＦクリッピングインデックスを使用して、ルーマサンプルにＡＬＦを適用する際に使用するためのクリッピング値を決定する。いくつかの例では、ＡＬＦクリッピングインデックスは、クロマＡＬＦクリッピングインデックスであり、このケースでは、ビデオコーダは、クロマＡＬＦクリッピングインデックス（例えば、ａｌｆ＿ｃｈｒｏｍａ＿ｃｌｉｐ＿ｉｄｘ）を使用して、クロマサンプルにＡＬＦを適用する際に使用するためのクリッピング値を決定する。ピクチャーのブロック（例えば、４×４ブロック）にＡＬＦを適用することは、例えば、式（１）中で説明されているように、ブロックに対するＡＬＦフィルタ係数を決定することと、ＡＬＦクリッピングインデックスを使用して、ブロックの少なくとも１つのサンプルに対するクリッピング値を決定することと、クリッピング値とＡＬＦフィルタ係数とを使用することとを含んでいてもよい。

［０１６１］
さらに、いくつかの例では、ビデオコーダは、第１の固定長の符号なし整数として、ルーマＡＬＦクリッピングインデックスをコード化してもよく、第２の固定長の符号なし整数として、クロマＡＬＦクリッピングインデックスをコード化してもよい。このような例では、ビデオコーダは、ルーマＡＬＦクリッピングインデックスに基づいて、ピクチャーのルーマブロックにＡＬＦを適用し、クロマＡＬＦクリッピングインデックスに基づいて、ピクチャーのクロマブロックにＡＬＦを適用してもよい。

［０１６２］
以下は、本開示の１つ以上の技法にしたがっている例の非限定的なリストである。

［０１６３］
例１． ビデオデータをコード化する方法において、方法は、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化することと、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦフィルタを適用することとを含んでいる。

［０１６４］
例２． ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックスである例１記載の方法。

［０１６５］
例３． ＡＬＦクリッピングインデックスは、クロマＡＬＦクリッピングインデックスである例１記載の方法。

［０１６６］
例４． ＡＬＦクリッピングインデックスは、ルーマＡＬＦクリッピングインデックスであり、ピクチャーのブロックは、ルーマブロックであり、方法は、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの１つとして、クロマＡＬＦクリッピングインデックスをコード化することと、ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのクロマブロックにＡＬＦフィルタを適用することとをさらに含む例１記載の方法。

［０１６７］
例５． ルーマＡＬＦクリッピングインデックスおよびクロマＡＬＦクリッピングインデックスは、固定長符号なし整数、トランケーティドバイナリ値、トランケーティドユーナリー値、または、符号なし０次Ｅｘｐ－Ｇｏｌｏｍｂコード化値、のうちの異なるものとしてコード化される例４記載の方法。

［０１６８］
例６． ＡＬＦクリッピングインデックスをコード化することは、ＡＬＦフィルタの対応するフィルタ係数の値にかかわらず、ＡＬＦクリッピングインデックスをコード化することを含む例１～５のいずれか１例記載の方法。

［０１６９］
例７． コーディングは、デコーディングを含む例１～６のいずれか１例記載の方法。

［０１７０］
例８． コーディングは、エンコーディングを含む例１～６のいずれか１例記載の方法。

［０１７１］
例９． ビデオデータをコード化するためのデバイスにおいて、デバイスが、例１～８のいずれか１例の方法を実行する１つ以上の手段を含むデバイス。

［０１７２］
例１０． １つ以上の手段が、回路中で実現されている１つ以上のプロセッサを備える例９記載のデバイス。

［０１７３］
例１１． ビデオデータを記憶するメモリをさらに含む例９または１０のいずれか１例記載のデバイス。

［０１７４］
例１２． デコードされたビデオデータを表示するように構成されているディスプレイをさらに含む例９～１１のいずれか１例記載のデバイス。

［０１７５］
例１３． デバイスが、カメラ、コンピュータ、移動体デバイス、ブロードキャスト受信機デバイス、または、セットトップボックスのうちの１つ以上を具備する例９～１２のいずれか１例記載のデバイス。

［０１７６］
例１４． デバイスが、ビデオデコーダを具備する例９～１３のいずれか１例記載のデバイス。

［０１７７］
例１５． デバイスが、ビデオエンコーダを具備する例９～１４のいずれか１例記載のデバイス。

［０１７８］
例１６． 実行されるときに、１つ以上のプロセッサに、例１～８のいずれか１例記載の方法を実行させる命令を記憶しているコンピュータ読取可能記憶媒体。

［０１７９］
例１７． ビデオデータをエンコードするためのデバイスにおいて、デバイスが、例１～８のいずれか１例記載の方法を実行する手段を含むデバイス。

［０１８０］
例１８． 実行されるときに、コンピューティングデバイスに、例１～８のいずれか１例記載の方法を実行させる命令を記憶しているコンピュータ読取可能データ記憶媒体。

［０１８１］
例に依存して、ここで説明した技法のうちのいずれかのある動作またはイベントは、異なるシーケンスで実行でき、追加してもよく、マージしてもよく、または、完全に省略してもよい（例えば、説明した動作またはイベントのすべてが本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、ある例では、動作またはイベントは、シーケンシャルによりもむしろ、例えば、マルチスレッド処理、割り込み処理、または、複数のプロセッサを通して、同時に実行してもよい。

［０１８２］
１つ以上の例において、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせで実現してもよい。ソフトウェアで実現される場合には、機能は、１つ以上の命令またはコードとしてコンピュータ読取可能媒体上に記憶されていてもよく、あるいは、１つ以上の命令またはコードとしてコンピュータ読取可能媒体上で送信されてもよく、ハードウェアベースの処理ユニットによって実行してもよい。コンピュータ読取可能媒体はまた、例えば、通信プロトコルにしたがって、コンピュータプログラムの１つの場所から別の場所への転送を容易にする何らかの媒体を含む通信媒体、または、データ記憶媒体のような有形の媒体に対応するコンピュータ読取可能記憶媒体を含んでいてもよい。このように、コンピュータ読取可能媒体は、一般的に、（１）有形コンピュータ読取可能記憶媒体、または、（２）信号または搬送波のような通信媒体に対応していてもよい。データ記憶媒体は、本開示で説明した技法を実現するための命令、コードおよび／またはデータ構造を取り出すために、１つ以上のコンピュータまたは１つ以上のプロセッサによってアクセスすることができる任意の利用可能な媒体であってもよい。コンピュータプログラム製品は、コンピュータ読取可能媒体を含んでいてもよい。

［０１８３］
限定ではなく例として、このようなコンピュータ読取可能記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ－ＲＯＭまたは他の光学ディスク記憶媒体、磁気ディスク記憶媒体または他の磁気記憶デバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態で望ましいプログラムコードを記憶するために使用され、コンピュータによってアクセスすることができる他の何らかの媒体のうちの１つ以上を備えることができる。また、任意の接続は、コンピュータ読取可能媒体と適切に呼ばれる。例えば、命令が、ウェブサイトから、サーバから、あるいは、同軸ケーブル、光ファイバケーブル、撚り対、デジタル加入者線（ＤＳＬ）、または、赤外線、無線、マイクロ波のようなワイヤレステクノロジーを使用している他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバケーブル、撚り対、ＤＳＬ、または、赤外線、無線およびマイクロ波のようなワイヤレステクノロジーは、媒体の定義に含まれる。しかしながら、コンピュータ読取可能記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または、他の一時的な媒体を含まないが、代わりに、非一時的な、有形の記憶媒体に向けられていることを理解すべきである。ここで使用するようなディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル汎用ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、および、ブルーレイ（登録商標）ディスクを含むが、通常、ディスク（ｄｉｓｋ）はデータを磁気的に再生する一方で、ディスク（ｄｉｓｃ）はデータをレーザにより光学的に再生する。上記の組み合わせも、コンピュータ読取可能媒体の範囲内に含むべきである。

［０１８４］
命令は、１つ以上のＤＳＰ、汎用マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、または、他の同等な集積またはディスクリート論理回路のような１つ以上のプロセッサによって実行してもよい。したがって、ここで使用されるように、用語「プロセッサ」および「処理回路」は、前述の構造、または、ここで説明した技術のインプリメンテーションに適した他の何らかの構造のいずれかを指していてもよい。加えて、いくつかの態様では、ここで説明した機能性は、エンコードおよびデコードするように構成されている専用のハードウェアおよび／またはソフトウェアモジュール内に提供してもよく、あるいは、組み合わされたコーデック中に組み込んでもよい。また、技法は、１つ以上の回路または論理エレメントにおいて、完全に実現することができる。

［０１８５］
本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置において実施してもよい。さまざまなコンポーネント、モジュール、または、ユニットは、開示した技法を実行するように構成されているデバイスの機能的な態様を強調するためにここ説明しているが、それらは、異なるハードウェアユニットによる実現を必ずしも要求するわけではない。むしろ、上記で説明したように、さまざまなユニットは、コーデックハードウェアユニットにおいて組み合わされるか、または、適切なソフトウェアおよび／またはファームウェアとともに、上記で説明したような１つ以上のプロセッサを含む、相互動作可能ハードウェアユニットの集合によって提供されてもよい。

［０１８６］
さまざまな例を説明してきた。これらおよび他の例は、以下の特許請求の範囲の範囲中にある。

Claims (37)

1. ビデオデータをコード化する方法において、
   固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化することと、
   前記ＡＬＦクリッピングインデックスに基づいて、前記ビデオデータのピクチャーのブロックにＡＬＦを適用することとを含む方法。
2. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスである請求項１記載の方法。
3. 前記ＡＬＦクリッピングインデックスが、クロマＡＬＦクリッピングインデックスである請求項１記載の方法。
4. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスであり、前記ピクチャーのブロックが、ルーマブロックであり、
   前記方法は、
   固定長符号なし整数として、クロマＡＬＦクリッピングインデックスをコード化することと、
   前記ＡＬＦクリッピングインデックスに基づいて、前記ピクチャーのクロマブロックに前記ＡＬＦを適用することとをさらに含む請求項１記載の方法。
5. 前記ＡＬＦクリッピングインデックスをコード化することが、前記ＡＬＦの対応するフィルタ係数の値にかかわらず、前記ＡＬＦクリッピングインデックスをコード化することを含む請求項１記載の方法。
6. 前記方法が、前記ＡＬＦの対応するフィルタ係数が０に等しいことを決定することをさらに含む請求項５記載の方法。
7. コード化が、デコーディングを含む請求項１記載の方法。
8. 前記ＡＬＦクリッピングインデックスをコード化することが、前記ビデオデータのエンコードされた表現を含むビットストリームから、前記固定長符号なし整数をパースすることを含む請求項６記載の方法。
9. コード化が、エンコーディングを含む請求項１記載の方法。
10. 前記ＡＬＦクリッピングインデックスをコード化することが、前記ビデオデータのエンコードされた表現を含むビットストリーム中に、前記固定長符号なし整数を含めることを含む請求項９記載の方法。
11. ビデオデータをコード化するためのデバイスにおいて、
    前記ビデオデータを記憶するように構成されているメモリと、
    回路中で実現されている１つ以上のプロセッサとを具備し、
    前記１つ以上のプロセッサは、
    固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化するようにと、
    前記ＡＬＦクリッピングインデックスに基づいて、前記ビデオデータのピクチャーのブロックにＡＬＦを適用するように構成されているデバイス。
12. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスである請求項１１記載のデバイス。
13. 前記ＡＬＦクリッピングインデックスが、クロマＡＬＦクリッピングインデックスである請求項１１記載のデバイス。
14. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスであり、前記ピクチャーのブロックが、ルーマブロックであり、
    前記１つ以上のプロセッサは、
    固定長符号なし整数として、クロマＡＬＦクリッピングインデックスをコード化するようにと、
    前記ＡＬＦクリッピングインデックスに基づいて、前記ピクチャーのクロマブロックに前記ＡＬＦを適用するようにさらに構成されている請求項１１記載のデバイス。
15. 前記ＡＬＦクリッピングインデックスをコード化することの一部として、前記１つ以上のプロセッサが、前記ＡＬＦの対応するフィルタ係数の値にかかわらず、前記ＡＬＦクリッピングインデックスをコード化するように構成されている請求項１１記載のデバイス。
    ことを含む
16. 前記１つ以上のプロセッサが、前記ＡＬＦの対応するフィルタ係数が０に等しいことを決定するように構成されている請求項１５記載のデバイス。
17. 前記ＡＬＦクリッピングインデックスをコード化するために、前記１つ以上のプロセッサが、前記ビデオデータのエンコードされた表現を含むビットストリームから、前記固定長符号なし整数をパースするように構成されている請求項１１記載のデバイス。
18. 前記ＡＬＦクリッピングインデックスをコード化するために、前記１つ以上のプロセッサが、前記ビデオデータのエンコードされた表現を含むビットストリーム中に、前記固定長符号なし整数を含めるように構成されている請求項１１記載のデバイス。
19. デコーダされたビデオデータを表示するように構成されているディスプレイをさらに具備する請求項１１記載のデバイス。
20. 前記デバイスが、カメラ、コンピュータ、移動体デバイス、ブロードキャスト受信機デバイス、または、セットトップボックスのうちの１つ以上を具備する請求項１１記載のデバイス。
21. 前記デバイスが、ビデオデコーダを具備する請求項１１記載のデバイス。
22. 前記デバイスが、ビデオエンコーダを具備する請求項１１記載のデバイス。
23. ビデオデータをコード化するためのデバイスにおいて、
    固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化する手段と、
    前記ＡＬＦクリッピングインデックスに基づいて、前記ビデオデータのピクチャーのブロックにＡＬＦを適用する手段とを具備するデバイス。
24. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスである請求項２３記載のデバイス。
25. 前記ＡＬＦクリッピングインデックスが、クロマＡＬＦクリッピングインデックスである請求項２３記載のデバイス。
26. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスであり、前記ピクチャーのブロックが、ルーマブロックであり、
    前記デバイスは、
    固定長符号なし整数として、クロマＡＬＦクリッピングインデックスをコード化する手段と、
    前記ＡＬＦクリッピングインデックスに基づいて、前記ピクチャーのクロマブロックに前記ＡＬＦを適用する手段とをさらに具備する請求項２３記載のデバイス。
27. 前記ＡＬＦクリッピングインデックスをコード化する手段が、前記ＡＬＦの対応するフィルタ係数の値にかかわらず、前記ＡＬＦクリッピングインデックスをコード化する手段を備える請求項２３記載のデバイス。
28. 前記ＡＬＦの対応するフィルタ係数が０に等しいことを決定する手段をさらに具備する請求項２７記載のデバイス。
29. 前記コード化する手段が、前記ビデオデータのエンコードされた表現を含むビットストリームから、前記固定長符号なし整数をパースする手段を備える請求項２３記載のデバイス。
30. 前記コード化する手段が、前記ビデオデータのエンコードされた表現を含むビットストリーム中に、前記固定長符号なし整数を含める手段を備える請求項２３記載のデバイス。
31. 命令を記憶しているコンピュータ読取可能記憶媒体において、
    前記命令は、実行されるときに、１つ以上のプロセッサに、
    固定長符号なし整数として、適応ループフィルタ（ＡＬＦ）クリッピングインデックスをコード化させ、
    前記ＡＬＦクリッピングインデックスに基づいて、ビデオデータのピクチャーのブロックにＡＬＦを適用させるコンピュータ読取可能記憶媒体。
32. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスである請求項３１記載のコンピュータ読取可能記憶媒体。
33. 前記ＡＬＦクリッピングインデックスが、クロマＡＬＦクリッピングインデックスである請求項３１記載のコンピュータ読取可能記憶媒体。
34. 前記ＡＬＦクリッピングインデックスが、ルーマＡＬＦクリッピングインデックスであり、前記ピクチャーのブロックが、ルーマブロックであり、
    前記命令の実行が、前記１つ以上にプロセッサに、
    固定長符号なし整数として、クロマＡＬＦクリッピングインデックスをコード化させ、
    前記ＡＬＦクリッピングインデックスに基づいて、前記ピクチャーのクロマブロックに前記ＡＬＦを適用させる請求項３１記載のコンピュータ読取可能記憶媒体。
35. 前記１つ以上のプロセッサに、前記ＡＬＦクリッピングインデックスをコード化させる命令が、実行されるときに、前記１つ以上のプロセッサに、前記ＡＬＦの対応するフィルタ係数の値にかかわらず、前記ＡＬＦクリッピングインデックスをコード化させる命令を含む請求項３１記載のコンピュータ読取可能記憶媒体。
36. 前記命令の実行が、さらに、前記１つ以上のプロセッサに、前記ＡＬＦの対応するフィルタ係数が０に等しいことを決定させる請求項３５記載のコンピュータ読取可能記憶媒体。
37. 前記１つ以上のプロセッサにＡＬＦクリッピングインデックスをコード化させる命令が、前記１つ以上のプロセッサに、前記ビデオデータのエンコードされた表現を含むビットストリームから、前記固定長符号なし整数をパースさせる命令を含む請求項３１記載のコンピュータ読取可能記憶媒体。
    
    

Images