本発明に関する理解を助けるために詳細な説明の一部に含まれる、添付図は、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的特徴を説明する。
以下、本明細書にかかる好ましい実施形態を添付図を参照として詳細に説明する。添付図と共に以下に開示される詳細な説明は、本明細書の例示的な実施形態を説明しようとするものであり、本明細書が実施され得る唯一の実施形態を示そうとするものではない。以下の詳細な説明は、本明細書の完全な理解を提供するために具体的な細部事項を含む。しかしながら、当業者は、本明細書がこのような具体的な細部事項がなくても実施され得ることを知る。
いくつかの場合、本明細書の概念が曖昧になることを避けるために、公知の構造および装置は省略されるか、各構造および装置の中核機能を中心としたブロック図の形式で示し得る。
また、本明細書で使用される用語は、できる限り現在広く使用される一般的な用語を選択しているが、特定の場合は、出願人が任意に選定した用語を使用して説明する。そのような場合は、該当部分の詳細な説明でその意味を明確に記載するので、本明細書の説明で使用された用語の名称だけで単純に解釈されてはならず、その該当用語の意味まで把握して解釈されるべきであることを明らかにしておく。
以下の説明で使用される特定の用語は、本明細書の理解を助けるために提供されたものであり、このような特定の用語の使用は、本明細書の技術的思想を外れない範囲で他の形態に変更され得る。例えば、信号、データ、サンプル、ピクチャ、スライス、タイル、フレーム、ブロックの場合、各コーディング過程で適切に代替して解釈され得る。
以下、本明細書における「処理ユニット」は、予測、変換および/または量子化などのエンコーディング/デコーディングの処理過程が行われる単位を意味する。また、処理ユニットは、輝度(luma)成分に対する単位と、色差(chroma)成分に対する単位と、を含む意味として解釈され得る。例えば、処理ユニットは、ブロック(block)、コーディングユニット(Coding Unit、CU)、予測ユニット(Prediction Unit、PU)、または変換ブロック(Transform Unit、TU)に該当し得る。
また、処理ユニットは、輝度成分に対する単位または色差成分に対する単位として解釈され得る。例えば、処理ユニットは、輝度成分に対するCTB(Coding Tree Block)、CB(Coding Block)、PUまたはTB(Transform Block)に該当し得る。あるいは、処理ユニットは、色差成分に対するCTB、CB、PUまたはTBに該当し得る。また、これに限定されるわけではなく、処理ユニットは、輝度成分に対する単位と色差成分に対する単位とを含む意味として解釈されることもある。
また、処理ユニットは、必ずしも正方形のブロックに限定されるわけではなく、3つ以上の頂点を有する多角形の形態で構成されることもある。
また、以下、本明細書で、ピクセル、画素、または係数(変換係数または1次変換を経た変換係数)は、サンプルと通称される。また、サンプルを利用するというのは、ピクセル値、画素値、または係数(変換係数または1次変換を経た変換係数)などを利用することを意味し得る。
図1は、本明細書の実施例にかかるビデオコーディングシステムの例を示す。
ビデオコーディングシステムは、ソースデバイス10および受信デバイス20を含むことができる。ソースデバイス10は、エンコードされたビデオ/映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して受信デバイス20に伝達することができる。
ソースデバイス10は、ビデオソース11、エンコード装置12、送信器13を含み得る。受信デバイス20は、受信器21、デコード装置22およびレンダラ23を含み得る。エンコード装置10は、ビデオ/映像のエンコード装置と呼ばれ、デコード装置20は、ビデオ/映像のデコード装置と呼ばれる。送信器13は、エンコード装置12に含まれ得る。受信器21は、デコード装置22に含まれ得る。レンダラ23は、ディスプレイ部を含んでもよく、ディスプレイ部は、別のデバイスまたは外部のコンポーネントで構成されてもよい。
ビデオソースは、ビデオ/映像のキャプチャ、合成または生成過程などを介してビデオ/映像を獲得することができる。ビデオソースは、ビデオ/映像のキャプチャデバイスおよび/またはビデオ/映像の生成デバイスを含み得る。ビデオ/映像のキャプチャデバイスは、例えば、1つまたは複数のカメラ、以前にキャプチャされたビデオ/映像を含むビデオ/映像のアーカイブなどを含み得る。ビデオ/映像の生成デバイスは、例えば、コンピュータ、タブレット、およびスマートフォンなどを含んでもよく(電子的に)ビデオ/映像を生成することができる。例えば、コンピュータなどを介して仮想のビデオ/映像が生成され得、この場合、関連データが生成される過程は、ビデオ/映像のキャプチャ過程と代わることができる。
エンコード装置12は、入力ビデオ/映像をエンコードすることができる。エンコード装置12は、圧縮およびコーディングの効率のために予測、変換、量子化等一連の手続を行うことができる。エンコードされたデータ(エンコードされたビデオ/映像情報)は、ビットストリーム(bit stream)の形態で出力されることができる。
送信部13は、ビットストリームの形態で出力されたエンコードされたビデオ/映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して、受信デバイスの受信部に伝達することができる。デジタル記憶媒体は、USB(Universal Serial Bus)、SD(Secure Digital)、CD(Compact Disk)、DVD(Digital Video Disk)、ブルーレイ(blu-ray)、HDD(Hard Disk Drive)、SSD(Solid State Drive)などの多様な記憶媒体を含み得る。送信部13は、予め決められたファイルフォーマットを介してメディアファイルを生成するためのエレメントを含んでもよく、放送/通信ネットワークを介した送信のためのエレメントを含んでもよい。受信器21は、ビットストリームを抽出し、デコード装置22に伝達することができる。
デコード装置22は、エンコード装置12の動作に対応する逆量子化、逆変換、予測等の一連の手続を行い、ビデオ/映像をデコードすることができる。
レンダラ23は、デコードされたビデオ/映像をレンダリングすることができる。レンダリングされたビデオ/映像は、ディスプレイ部を介して表示されることができる。
図2は、本明細書の実施例にかかるビデオ/イメージ信号のエンコーディングのためのエンコード装置の概略ブロック図を示す。
図2を参照すると、エンコード装置100は、映像分割部110、減算部115、変換部120、量子化部130、逆量子化部140、逆変換部150、加算部155、フィルタリング部160、メモリ170、インター予測部180、イントラ予測部185、およびエントロピエンコーディング部190を含み得る。インター予測部180およびイントラ予測部185は、予測部と通称され得る。すなわち、予測部は、インター予測部180およびイントラ予測部185を含み得る。変換部120、量子化部130、逆量子化部140、逆変換部150は、残差(residual)処理部に含まれ得る。残差処理部は、減算部115をさらに含んでもよい。前述した映像分割部110、減算部115、変換部120、量子化部130、逆量子化部140、逆変換部150、加算部155、フィルタリング部160、インター予測部180、イントラ予測部185、およびエントロピエンコーディング部190は、実施例によって(かかって)1つのハードウェアコンポーネント(例えば、エンコーダまたはプロセッサ)によって構成され得る。また、メモリ170は、実施例によって1つのハードウェアコンポーネント(例えば、メモリまたはデジタル記憶媒体)によって構成され得、メモリ170は、DPB(Decoded Picture Buffer)175を含み得る。
映像分割部110は、エンコード装置100に入力された入力映像(または、ピクチャ、フレーム)を、1つまたは複数の処理ユニット(processing unit)に分割することができる。一例として、処理ユニットは、コーディングユニット(CU)と呼ばれる。この場合、コーディングユニットは、コーディングツリーユニット(Coding Tree Unit、CTU)または最大のコーディングユニット(Largest Coding Unit、LCU)からQTBT(Quad-Tree Binary-Tree)構造によって、再帰的に(recursively)分割されることができる。例えば、1つのコーディングユニットは、四分木(クアッドツリー)構造および/または二分木(バイナリツリー)構造に基づいて、下位(deeper)デプスの複数のコーディングユニットに分割され得る。この場合、例えば、四分木構造が先に適用され、二分木構造が後に適用され得る。あるいは、二分木構造が先に適用されることもある。これ以上分割されない最終的なコーディングユニットに基づいて、本明細書にかかるコーディング手続が行われる。この場合、映像の特性によるコーディングの効率などに基づいて、最大のコーディングユニットが直ぐに最終的なコーディングユニットとして使用され得、あるいは必要に応じて、コーディングユニットは再帰的に(recursively)より下位デプスのコーディングユニットに分割され、最適なサイズのコーディングユニットが最終的なコーディングユニットとして使用され得る。ここで、コーディング手続というのは、後述する予測、変換、および復元などの手続を含み得る。別の例として、処理ユニットは、予測ユニット(PU)または変換ユニット(TU)をさらに含み得る。この場合、予測ユニットおよび変換ユニットは、それぞれ前述した最終的なコーディングユニットから分割またはパーティショニングされ得る。上記予測ユニットは、サンプル予測の単位であってもよく、上記変換ユニットは、変換係数を導出する単位および/または変換係数から残差信号(residual signal)を導出する単位であってもよい。
ユニットは、場合によって、ブロック(block)または領域(area)などの用語と混用してもよい。一般的な場合、MxNのブロックは、M個の列とN個の行とからなるサンプルまたは変換係数(transform coefficient)の集合を表し得る。サンプルは、一般的にピクセルまたはピクセルの値を表し得、輝度(luma)成分のピクセル/ピクセル値のみを表すこともあり、彩度(chroma)成分のピクセル/ピクセル値のみを表すこともある。サンプルは、1つのピクチャ(または映像)をピクセル(pixel)またはペル(pel)に対応する用語として使用され得る。
エンコード装置100は、入力映像信号(オリジナル(原本)ブロック、オリジナルサンプルアレイ)から、インター予測部180またはイントラ予測部185から出力された予測信号(予測されたブロック、予測サンプルアレイ)を減算して残差信号(残差(残余)ブロック、残差サンプルアレイ)を生成することができ、生成された残差信号は、変換部120へ送信される。この場合、示すように、エンコード装置100内で入力映像信号(オリジナルブロック、オリジナルサンプルアレイ)から予測信号(予測ブロック、予測サンプルアレイ)を減算するユニットは、減算部115と呼ばれる。予測部は、処理対象のブロック(以下、現ブロックという)に対する予測を行い、現ブロックに対する予測サンプルを含む予測されたブロック(predicted block)を生成することができる。予測部は、ブロックもしくはCU単位でイントラ予測が適用されるか、またはインター予測が適用されるかを決定できる。予測部は、各予測モードに関する説明で後述するように、予測モード情報のように予測に関する多様な情報を生成してエントロピエンコーディング部190へ伝達することができる。予測に関する情報は、エントロピエンコーディング部190でエンコードされ、ビットストリームの形態で出力されることができる。
イントラ予測部185は、現ピクチャ内のサンプルを参照して現ブロックを予測することができる。参照されるサンプルは、予測モードに応じて、上記現ブロックの周辺(neighbor)に位置してもよく、あるいは離れて位置してもよい。イントラ予測で予測モードは、複数の非方向性モードと複数の方向性モードとを含み得る。非方向性モードは、例えば、DCモードおよび平面モード(Planarモード)を含み得る。方向性モードは、予測方向の細密な程度によって、例えば、33個の方向性予測モードまたは65個の方向性予測モードを含み得る。ただし、これは例であって、設定によってそれ以上またはそれ以下の数の方向性予測モードが使用され得る。イントラ予測部185は、周辺ブロックに適用された予測モードを用いて、現ブロックに適用される予測モードを決定することもできる。
インター予測部180は、参照ピクチャ上で動きベクトルにより特定される参照ブロック(参照サンプルアレイ)に基づき、現ブロックに対する予測されたブロックを導出することができる。この際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報をブロック、サブブロックまたはサンプル単位で予測することができる。動き情報は、動きベクトルおよび参照ピクチャのインデックスを含み得る。動き情報は、インター予測方向(L0予測、L1予測、Bi予測など)の情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック(spatial neighboring block)と、参照ピクチャに存在する時間的周辺ブロック(temporal neighboring block)と、を含み得る。参照ブロックを含む参照ピクチャと時間的周辺ブロックを含む参照ピクチャとは、同一であってもよく、異なってもよい。時間的周辺ブロックは、同位置の(コロケート)参照ブロック(collocated reference block)、同位置のCU(colCU)などの名称で呼ばれ、時間的周辺ブロックを含む参照ピクチャは、同位置のピクチャ(collocated picture、colPic)とも呼ばれる。例えば、インター予測部180は、周辺ブロックに基づいて動き情報の候補リストを構成し、現ブロックの動きベクトルおよび/または参照ピクチャのインデックスを導出するために、どの候補が使用されるかを指示する情報を生成することができる。様々な予測モードに基づいてインター予測が行われ、例えば、スキップモードおよびマージモードの場合に、インター予測部180は、周辺ブロックの動き情報を現ブロックの動き情報として利用することができる。スキップモードの場合、マージモードと異なり、残差信号が送信されないことがある。動きベクトル予測(Motion Vector Prediction、MVP)モードの場合、周辺ブロックの動きベクトルを動きベクトル予測子(motion vector predictor)として利用し、動きベクトル差分(motion vector difference)をシグナリングすることによって、現ブロックの動きベクトルを指示することができる。
インター予測部180またはイントラ予測部185を介して生成された予測信号は、復元信号を生成するために利用されるか、残差信号を生成するために利用されることができる。
変換部120は、残差信号に変換技法を適用して変換係数(transform coefficients)を生成することができる。例えば、変換技法は、DCT(Discrete Cosine Transform)、DST(Discrete Sine Transform)、KLT(Karhunen-Loeve transform)、GBT(Graph-Based Transform)、またはCNT(Conditionally Non-linear Transform)のうちの少なくとも1つを含んでもよい。ここで、GBTは、ピクセル間の関係情報をグラフで表現する際、このグラフから得られた変換を意味する。CNTは、以前に復元された全てのピクセル(all previously reconstructed pixel)を利用して予測信号を生成し、それに基づいて獲得される変換を意味する。また、変換過程は、正方形の同じサイズを有するピクセルブロックに適用されてもよく、正方形ではない可変サイズのブロックにも適用されてもよい。
量子化部130は、変換係数を量子化してエントロピエンコーディング部190に送信し、エントロピエンコーディング部190は、量子化された信号(量子化された変換係数に関する情報)をエンコードしてビットストリームに出力することができる。量子化された変換係数に関する情報は、残差情報と呼ばれる。量子化部130は、係数のスキャン順序(scan order)に基づいてブロックの形態の量子化された変換係数を1次元のベクトルの形態で再整列することができ、1次元のベクトルの形態の量子化された変換係数に基づいて上記量子化された変換係数に関する情報を生成することもできる。エントロピエンコーディング部190は、例えば、指数ゴロム(exponential Golomb)、CAVLC(Context-Adaptive Variable Length Coding)、CABAC(Context-Adaptive Binary Arithmetic Coding)などの多様なエンコード方法を行うことができる。エントロピエンコーディング部190は、量子化された変換係数以外のビデオ/イメージの復元に必要な情報(例えば、シンタックス要素(syntax elements)の値など)を共に、または別にエンコードすることもできる。エンコードされた情報(例えば、ビデオ/映像の情報)は、ビットストリームの形態でNAL(Network Abstraction Layer)ユニット単位で送信または記憶されることができる。ビットストリームは、ネットワークを介して送信されることができ、またはデジタル記憶媒体に記憶されることができる。ここで、ネットワークは、放送網および/または通信網などを含んでもよく、デジタル記憶媒体は、USB、SD、CD、DVD、ブルーレイ、HDD、SSDなどの多様な記憶媒体を含んでもよい。エントロピエンコーディング部190から出力された信号を送信する送信部(図示せず)および/もしくは記憶する記憶部(図示せず)は、エンコード装置100の内/外部のエレメントとして構成されてもよく、または送信部は、エントロピエンコーディング部190の構成要素であってもよい。
量子化部130から出力された量子化された変換係数は、予測信号を生成するために利用されることができる。例えば、量子化された変換係数に対して、ループ内の逆量子化部140および逆変換部150を介して逆量子化および逆変換を適用することによって、残差信号が復元されることができる。加算部155は、復元された残差信号をインター予測部180またはイントラ予測部185から出力された予測信号に加えることによって、復元(reconstructed)信号(復元ピクチャ、復元ブロック、復元サンプルアレイ)を生成すことができる。スキップモードが適用された場合のように、処理対象のブロックに対する残差がない場合、予測されたブロックは、復元ブロックとして使用されることができる。加算部155は、復元部または復元ブロック生成部と称される。復元信号は、現ピクチャ内の次の処理対象のブロックのイントラ予測のために使用されることができ、後述するようにフィルタリングを経て、次のピクチャのインター予測のために使用されることもできる。
フィルタリング部160は、復元信号にフィルタリングを適用し、主観的/客観的画質を向上させることができる。例えば、フィルタリング部160は、復元ピクチャに多様なフィルタリング方法を適用して、修正された(modified)復元ピクチャを生成することができ、修正された復元ピクチャを復号ピクチャバッファ170に送信することができる。多様なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット(sample adaptive offset)、適応ループフィルタ(adaptive loop filter)、両方向フィルタ(bilateral filter)を含み得る。フィルタリング部160は、各フィルタリング方法に関する説明で後述するように、フィルタリングに関する多様な情報を生成してエントロピエンコーディング部190へ伝達することができる。フィルタリングに関する情報は、エントロピエンコーディング部190でエンコードされてビットストリームの形態で出力されることができる。
復号ピクチャバッファ170に送信された修正された復元ピクチャは、インター予測部180で参照ピクチャとして使用されることができる。エンコード装置100は、これを介して、インター予測が適用される場合、エンコード装置100およびデコード装置200における予測のミスマッチを避けることができ、符号化の効率も向上させることができる。
復号ピクチャバッファ170は、修正された復元ピクチャをインター予測部180における参照ピクチャとして使用するために記憶することができる。
図3は、本明細書の実施例として、映像信号のデコーディングのためのデコード装置の概略ブロック図を示す。
図3を参照すると、デコード装置200は、エントロピデコーディング部210、逆量子化部220、逆変換部230、加算部235、フィルタリング部240、メモリ250、インター予測部260、およびイントラ予測部265を含んで構成されることができる。インター予測部260およびイントラ予測部265は、予測部と通称され得る。すなわち、予測部は、インター予測部180およびイントラ予測部185を含み得る。逆量子化部220および逆変換部230は、残差処理部と通称され得る。すなわち、残差処理部は、逆量子化部220および逆変換部230を含むことができる。エントロピデコーディング部210、逆量子化部220、逆変換部230、加算部235、フィルタリング部240、インター予測部260、およびイントラ予測部265は、実施例によって1つのハードウェアコンポーネント(例えば、デコーダまたはプロセッサ)により構成されることができる。また、復号ピクチャバッファ250は、実施例によって1つのハードウェアコンポーネント(例えば、メモリまたはデジタル記憶媒体)によって実現されることができる。また、メモリ250は、DPB175を含むことができ、デジタル記憶媒体によって構成されることもできる。
ビデオ/イメージの情報を含むビットストリームが入力されると、デコード装置200は、図2のエンコード装置100でビデオ/イメージの情報が処理されたプロセスに対応し、映像を復元することができる。例えば、デコード装置200は、エンコード装置100で適用された処理ユニットを利用してデコーディングを行うことができる。したがって、デコーディングの際の処理ユニットは、例えば、コーディングユニットであってもよく、コーディングユニットは、コーディングツリーユニットまたは最大のコーディングユニットから四分木構造および/または二分木構造に従って分割されることができる。また、デコード装置200を介してデコーディングおよび出力された復元映像信号は、再生装置を介して再生されることができる。
デコード装置200は、図2のエンコード装置100から出力された信号をビットストリームの形態で受信することができ、受信した信号は、エントロピデコーディング部210を介してデコードされることができる。例えば、エントロピデコーディング部210は、ビットストリームをパージングして、映像復元(またはピクチャ復元)に必要な情報(例えば、ビデオ/映像の情報)を導出することができる。例えば、エントロピデコーディング部210は、指数ゴロム符号化、CAVLCまたはCABACなどのコーディング方法に基づいてビットストリーム内の情報をデコードし、映像の復元に必要なシンタックスエレメントの値、残差に関する変換係数の量子化された値を出力することができる。より詳細には、CABACエントロピデコード方法は、ビットストリームで各構文要素に該当するビン(bin)を受信し、デコーディング対象の構文要素情報ならびに周辺およびデコーディング対象のブロックのデコーディング情報、または以前の段階でデコードされたシンボル/ビンの情報を利用してコンテキスト(context)モデルを決定し、決定されたコンテキストモデルによってビンの発生確率を予測し、ビンの算術復号(デコーディング)(arithmetic decoding)を行い、各構文要素の値に該当するシンボルを生成することができる。この際、CABACエントロピデコード方法は、コンテキストモデルの決定後、次のシンボル/ビンのコンテキストモデルのためにデコードされたシンボル/ビンの情報を利用してコンテキストモデルをアップデートすることができる。エントロピデコーディング部210でデコードされた情報のうちの予測に関する情報は、予測部(インター予測部260およびイントラ予測部265)に提供され、エントロピデコーディング部210でエントロピデコーディングが行われた残差値、すなわち、量子化された変換係数および関連のパラメータ情報は、逆量子化部220に入力されることができる。また、エントロピデコーディング部210でデコードされた情報のうちのフィルタリングに関する情報は、フィルタリング部240に提供されることができる。一方、エンコード装置100から出力された信号を受信する受信部(図示せず)が、デコード装置200の内/外部のエレメントとしてさらに構成されることができ、または、受信部は、エントロピデコーディング部210の構成要素であってもよい。
逆量子化部220では、量子化された変換係数を逆量子化することによって変換係数を出力することができる。逆量子化部220は、量子化された変換係数を2次元のブロックの形態で再整列することができる。この場合、エンコード装置100で行われた係数のスキャン順序に基づいて再整列が行われ得る。逆量子化部220は、量子化パラメータ(例えば、量子化ステップサイズ情報)を利用して量子化された変換係数に対する逆量子化を行い、変換係数(transform coefficient)を獲得することができる。
逆変換部230は、変換係数に対する逆変換を適用することによって残差信号(残差ブロック、残差サンプルアレイ)を出力することができる。
予測部は、現ブロックに対する予測を行い、現ブロックに対する予測サンプルを含む予測されたブロック(predicted block)を生成することができる。予測部は、エントロピデコーディング部210から出力された予測に関する情報に基づいて、現ブロックにイントラ予測が適用されるか、またはインター予測が適用されるかを決定することができ、具体的なイントラ/インター予測モードを決定することができる。
イントラ予測部265は、現ピクチャ内のサンプルを参照することによって現ブロックを予測することができる。参照されるサンプルは、予測モードに応じて現ブロックの周辺(neighbor)に位置してもよく、または離隔して位置してもよい。イントラ予測における予測モードは、複数の非方向性モードおよび複数の方向性モードを含むことができる。イントラ予測部265は、周辺ブロックに適用された予測モードを利用して、現ブロックに適用される予測モードを決定することもできる。
インター予測部260は、参照ピクチャ上で動きベクトルにより特定される参照ブロック(参照サンプルアレイ)に基づき、現ブロックに対する予測されたブロックを導出することができる。この際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報をブロック、サブブロック、またはサンプル単位で予測することができる。動き情報は、動きベクトルおよび参照ピクチャのインデックスを含むことができる。動き情報は、インター予測方向(L0予測、L1予測、Bi予測など)に関する情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック(spatial neighboring block)と参照ピクチャに存在する時間的周辺ブロック(temporal neighboring block)とを含み得る。例えば、インター予測部260は、周辺ブロックに基づいて動き情報の候補リストを構成し、受信した候補選択情報に基づいて、現ブロックの動きベクトルおよび/または参照ピクチャのインデックスを導出することができる。多様な予測モードに基づいてインター予測が行われ得、予測に関する情報は、現ブロックに対するインター予測のモードを指示する情報を含むことができる。
加算部235は、獲得された残差信号をインター予測部260またはイントラ予測部265から出力された予測信号(予測されたブロック、予測サンプルアレイ)に加えることによって、復元信号(復元ピクチャ、復元ブロック、復元サンプルアレイ)を生成することができる。スキップモードが適用された場合のように、処理対象のブロックに対する残差がない場合、予測されたブロックは、復元ブロックとして使用されることができる。
加算部235は、復元部または復元ブロック生成部と呼ばれる。生成された復元信号は、現ピクチャ内の次の処理対象のブロックのイントラ予測のために使用されることができ、後述するように、フィルタリングを経て次のピクチャのインター予測のために使用されることもできる。
フィルタリング部240は、復元信号にフィルタリングを適用することによって、主観的/客観的画質を向上させることができる。例えば、フィルタリング部240は、復元ピクチャに多様なフィルタリング方法を適用し、修正された(modified)復元ピクチャを生成することができ、修正された復元ピクチャを復号ピクチャバッファ250に送信することができる。多様なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット(Sample Adaptive Offset、SAO)、適応ループフィルタ(Adaptive Loop Filter、ALF)、両方向フィルタ(bilateral filter)などを含み得る。
復号ピクチャバッファ250に送信された修正された復元ピクチャは、インター予測部260により参照ピクチャとして使用されることができる。
本明細書において、エンコード装置100のフィルタリング部160、インター予測部180、およびイントラ予測部185で説明された実施例は、それぞれデコード装置のフィルタリング部240、インター予測部260、およびイントラ予測部265にも同一または対応するように適用されることができる。
図4は、本明細書の実施例にかかるコンテンツストリーミングシステムの構造図の例を示す。
本明細書が適用されるコンテンツストリーミングシステムは、概してエンコードサーバ410、ストリーミングサーバ420、ウェブサーバ430、メディアストレージ440、ユーザ装置450、およびマルチメディア入力装置460を含むことができる。
エンコードサーバ410は、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置から入力されたコンテンツをデジタルデータに圧縮してビットストリームを生成し、これをストリーミングサーバ420に送信することができる。別の例として、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置460がビットストリームを直接生成する場合、エンコードサーバ410は省略され得る。
ビットストリームは、本明細書が適用されるエンコード方法またはビットストリームの生成方法により生成されることができ、ストリーミングサーバ420は、ビットストリームを送信または受信する過程で、一時的にビットストリームを記憶することができる。
ストリーミングサーバ420は、ウェブサーバ430を介したユーザの要求(要請)に基づいて、マルチメディアデータをユーザ装置450に送信し、ウェブサーバ430は、ユーザにどのようなサービスがあるかを知らせる媒介体の役割を担う。ユーザがウェブサーバ430に希望するサービスを要求すると、ウェブサーバ430は、これをストリーミングサーバ420に伝達し、ストリーミングサーバ420は、ユーザにマルチメディアデータを送信する。この際、コンテンツストリーミングシステムは、別途の制御サーバを含むことができ、この場合、制御サーバは、コンテンツストリーミングシステム内の各装置間の命令/応答を制御する役割を担う。
ストリーミングサーバ420は、メディアストレージ440および/またはエンコードサーバ410からコンテンツを受信することができる。例えば、ストリーミングサーバ420は、エンコードサーバ410からコンテンツをリアルタイムで受信することができる。この場合、円滑なストリーミングサービスを提供するために、ストリーミングサーバ420は、ビットストリームを一定時間の間記憶することができる。
例えば、ユーザ装置450は、携帯電話、スマートフォン(smart phone)、ラップトップパソコン(laptop computer)、デジタル放送用端末機、PDA(Personal Digital Assistants)、PMP(Portable Multimedia Player)、ナビゲーション、スレートPC(slate PC)、タブレットPC(tablet PC)、ウルトラブック(ultrabook)、ウェアラブルデバイス(wearable device)、例えば、腕時計(ウォッチ)型端末機(smartwatch)、眼鏡(ガラス)型端末機(smart glass)、HMD(Head Mounted Display)、デジタルTV、デスクトップコンピュータ、デジタルサイネージを含み得る。
コンテンツストリーミングシステム内の各サーバは、分散サーバとして運用されることができ、この場合、各サーバで受信するデータは、分散処理されることができる。
図5は、本明細書の実施例にかかるビデオ信号を処理するための装置のブロック図の例を示す。図5のビデオ信号処理装置は、図2のエンコード装置100または図3のデコード装置200に該当し得る。
本明細書の実施例にかかるビデオ信号処理装置500は、ビデオ信号を記憶するメモリ520と、上記メモリと結合されつつ、ビデオ信号を処理するプロセッサ510と、を含み得る。
本明細書の実施例にかかるプロセッサ510は、ビデオ信号の処理のための少なくとも1つの処理(プロセシング)回路で構成されることができ、ビデオ信号のエンコーディングまたはデコーディングのためのコマンドを実行することによって、映像信号を処理することができる。すなわち、プロセッサ510は、以下で説明されるエンコードまたはデコード方法を実行することによって、原本ビデオ信号をエンコードするか、エンコードされたビデオ信号をデコードすることができる。
図6は、本明細書の実施例にかかるブロックの分割構造の例であって、図6aは、QT(quad Tree、以下「QT」と称される)、図6bは、BT(Binary Tree、以下「BT」と称される)、図6cは、TT(Ternary Tree、以下「TT」と称される)、図6dは、AT(Asymmetric Tree、以下「AT」と称される)によるブロックの分割構造の例を示す。
ビデオコーディングにおける1つのブロックは、QTベースで分割されることができる。また、QTによって分割された1つのサブブロック(subblock)は、QTを使用して再帰的にさらに分割されることができる。これ以上QT分割されないリーフブロック(leaf block)は、BT、TTまたはATのうちの少なくとも1つの方式によって分割されることができる。BTは、horizontal BT(2NxN、2NxN)とvertical BT(Nx2N、Nx2N)との2つの形態の分割を有することができる。TTは、horizontal TT(2Nx1/2N、2NxN、2Nx1/2N)とvertical TT(1/2Nx2N、Nx2N、1/2Nx2N)との2つの形態の分割を有することができる。ATは、horizontal−up AT(2Nx1/2N、2Nx3/2N)、horizontal−down AT(2Nx3/2N、2Nx1/2N)、vertical−left AT(1/2Nx2N、3/2Nx2N)、vertical−right AT(3/2Nx2N、1/2Nx2N)の4つの形態の分割を有することができる。それぞれのBT、TT、ATは、BT、TT、ATを使用して再帰的にさらに分割されることができる。
図6aは、QTの分割の例を示す。ブロックAは、QTによって4つのサブブロック(A0、A1、A2、A3)に分割されることができる。サブブロックA1は、再度QTによって4つのサブブロック(B0、B1、B2、B3)に分割されることができる。
図6bは、BTの分割の例を示す。QTによってこれ以上分割されないブロックB3は、vertical BT(C0、C1)またはhorizontal BT(D0、D1)に分割されることができる。ブロックC0のようにそれぞれのサブブロックは、horizontal BT(E0、E1)またはvertical BT(F0、F1)の形態のように再帰的にさらに分割されることができる。
図6cは、TTの分割の例を示す。QTによってこれ以上分割されないブロックB3は、vertical TT(C0、C1、C2)またはhorizontal TT(D0、D1、D2)に分割されることができる。ブロックC1のようにそれぞれのサブブロックは、horizontal TT(E0、E1、E2)またはvertical TT(F0、F1、F2)の形態のように再帰的にさらに分割されることができる。
図6dは、ATの分割の例を示す。QTによってこれ以上分割されないブロックB3は、vertical AT(C0、C1)またはhorizontal AT(D0、D1)に分割されることができる。ブロックC1のようにそれぞれのサブブロックは、horizontal AT(E0、E1)またはvertical TT(F0、F1)の形態のように再帰的にさらに分割されることができる。
一方、BT、TT、ATの分割は、結合され(組み合わせられ)得る。例えば、BTによって分割されたサブブロックは、TTまたはATによる分割が可能である。また、TTによって分割されたサブブロックは、BTまたはATによる分割が可能である。ATによって分割されたサブブロックは、BTまたはTTによる分割が可能である。例えば、horizontal BTの分割以降、それぞれのサブブロックがverti−cal BTに分割されることができ、またはvertical BTの分割以降、それぞれのサブブロックがhorizontal BTに分割されることもできる。上記2種類の分割方法は、分割の順序は異なるが、最終的に分割された形状(模様)(shapes)は同一である。
また、ブロックが分割されると、ブロックを探索する順序が多様に定義され得る。一般に、左側から右側に、上段から下段に探索を行い、ブロックを探索するというのは、各分割されたサブブロックの更なるブロックの分割が可能か否かを決定する順序を意味するか、ブロックがこれ以上分割されない場合、各サブブロックの符号化順序を意味するか、またはサブブロックから他の隣接ブロックの情報を参照する際の探索順序を意味し得る。
図7および図8は、インター予測に基づくビデオ/映像のエンコーディング手続、およびエンコード装置内のインター予測部を示す。
エンコード装置100は、現ブロックに対するインター予測を行う(S710)。エンコード装置100は、現ブロックのインター予測モードおよび動き情報を導出し、現ブロックの予測サンプルを生成することができる。ここで、インター予測モードの決定、動き情報の導出、および予測サンプルの生成手続は、同時に行われてもよく、いずれかの手続が他の手続より先に行われてもよい。例えば、エンコード装置100のインター予測部180は、予測モード決定部181、動き情報導出部182、予測サンプル導出部183を含むことができ、予測モード決定部181で現ブロックに対する予測モードを決定し、動き情報導出部182で現ブロックの動き情報を導出し、予測サンプル導出部183で現ブロックの予測サンプルを導出することができる。例えば、エンコード装置100のインター予測部180は、動き推定(motion estimation)を介して参照ピクチャの一定領域(サーチ領域)内で上記現ブロックと類似するブロックをサーチし、現ブロックとの差が最小または一定基準以下である参照ブロックを導出することができる。これに基づいて、上記参照ブロックが位置する参照ピクチャを指す参照ピクチャのインデックスを導出し、参照ブロックと現ブロックとの位置の差異に基づいて動きベクトルを導出することができる。エンコード装置100は、多様な予測モードのうち、現ブロックに対して適用されるモードを決定することができる。エンコード装置100は、多様な予測モードに対するRDコスト(cost)を比較し、現ブロックに対する最適な予測モードを決定することができる。
例えば、エンコード装置100は、現ブロックにスキップモードまたはマージモードが適用される場合、後述するマージ候補リストを構成し、マージ候補リストに含まれるマージ候補の指す参照ブロックのうち、現ブロックとの差が、最小または一定基準以下である参照ブロックを導出することができる。この場合、導出された参照ブロックと関連するマージ候補が選択され、選択されたマージ候補を指すマージインデックス情報が生成され、デコード装置200にシグナリングされることができる。選択されたマージ候補の動き情報を利用し、現ブロックの動き情報が導出されることができる。
別の例として、エンコード装置100は、現ブロックに(A)MVPモードが適用される場合、後述する(A)MVP候補リストを構成し、(A)MVP候補リストに含まれるMVP(Motion Vector Predictor)候補のうち選択されたMVP候補の動きベクトルを現ブロックのMVPとして利用できる。この場合、例えば、前述した動き推定によって導出された参照ブロックを指す動きベクトルが、現ブロックの動きベクトルとして利用されることができ、MVP候補のうち、現ブロックの動きベクトルとの差が最も小さい動きベクトルを有するMVP候補が選択されたMVP候補になることができる。現ブロックの動きベクトルからMVPを引いた差分であるMVD(Motion Vector Difference)が導出されることができる。この場合、MVDに関する情報がデコード装置200にシグナリングされることができる。また、(A)MVPモードが適用される場合、参照ピクチャのインデックスの値は、参照ピクチャのインデックス情報として構成され、別にデコード装置200にシグナリングされることができる。
エンコード装置100は、予測サンプルに基づいて残差サンプルを導出することができる(S720)。エンコード装置100は、現ブロックのオリジナルサンプルと予測サンプルとの比較を通じて、残差サンプルを導出することができる。
エンコード装置100は、予測情報および残差情報を含む映像情報をエンコードする(S730)。エンコード装置100は、エンコードされた映像情報をビットストリームの形態で出力することができる。予測情報は、予測手続に関する情報として、予測モード情報(例えば、スキップフラグ、マージフラグ、またはモードインデックス)および動き情報を含み得る。動き情報は、動きベクトルを導出するための情報である候補選択情報(例えば、マージインデックス、mvpフラグ、またはmvpインデックス)を含み得る。また、動き情報は、前述したMVDに関する情報および/または参照ピクチャのインデックス情報を含み得る。さらに、動き情報は、L0予測、L1予測、または双(bi)予測が適用されるか否かを示す情報を含み得る。残差情報は、残差サンプルに関する情報である。残差情報は、残差サンプルに対する量子化された変換係数に関する情報を含み得る。
出力されたビットストリームは、(デジタル)記憶媒体に記憶されてデコード装置に伝達されることができ、またはネットワークを介してデコード装置に伝達されることもできる。
一方、前述したように、エンコード装置は、上記参照サンプルおよび上記残差サンプルに基づいて、復元ピクチャ(復元サンプルおよび復元ブロック含む)を生成することができる。これは、デコード装置200で行われるものと同一の予測結果をエンコード装置100から導出するためであり、これを介して、コーディングの効率を高めることができるためである。したがって、エンコード装置100は、復元ピクチャ(または復元サンプル、復元ブロック)をメモリに記憶し、インター予測のための参照ピクチャとして活用できる。復元ピクチャにインループフィルタリング手続などがさらに適用できることは前述した通りである。
図9および図10は、インター予測に基づくビデオ/映像のデコーディング手続、およびデコード装置内のインター予測部を示す。
デコード装置200は、エンコード装置100で行われた動作と対応する動作を行うことができる。デコード装置200は、受信した予測情報に基づいて現ブロックに対して予測を行い、予測サンプルを導出することができる。
具体的には、デコード装置200は、受信した予測情報に基づいて、現ブロックに対する予測モードを決定することができる(S910)。デコード装置200は、予測情報内の予測モード情報に基づいて、現ブロックにどのようなインター予測モードが適用されるかを決定できる。
例えば、デコード装置200は、マージフラグ(merge flag)に基づいて、現ブロックにマージモードが適用されるか、または(A)MVPモードが決定されるか否かを決定することができる。あるいは、デコード装置200は、モードインデックス(mode index)に基づいて、多様なインター予測モードの候補のうちの一つを選択することができる。インター予測モードの候補は、スキップモード、マージモードおよび/もしくは(A)MVPモードを含んでもよく、または後述する多様なインター予測モードを含んでもよい。
デコード装置200は、決定されたインター予測モードに基づいて、現ブロックの動き情報を導出する(S920)。例えば、デコード装置200は、現ブロックにスキップモードまたはマージモードが適用される場合、後述するマージ候補リストを構成し、マージ候補リストに含まれるマージ候補のうちの一つのマージ候補を選択し得る。マージ候補の選択は、マージインデックス(merge index)に基づいて行われ得る。選択されたマージ候補の動き情報から現ブロックの動き情報が導出され得る。選択されたマージ候補の動き情報が現ブロックの動き情報として利用され得る。
別の例として、デコード装置200は、現ブロックに(A)MVPモードが適用される場合、後述する(A)MVP候補リストを構成し、(A)MVP候補リストに含まれるMVP候補のうち選択されたMVP候補の動きベクトルを現ブロックのMVPとして利用し得る。MVPの選択は、前述した選択情報(MVPフラグまたはMVPインデックス)に基づいて行われ得る。この場合、デコード装置200は、MVDに関する情報に基づいて上記現ブロックのMVDを導出し得、現ブロックのMVPおよびMVDに基づいて、現ブロックの動きベクトルを導出し得る。また、デコード装置200は、参照ピクチャのインデックス情報に基づいて、現ブロックの参照ピクチャのインデックスを導出し得る。現ブロックに関する参照ピクチャリスト内で、参照ピクチャのインデックスの指すピクチャが、現ブロックのインター予測のために参照される参照ピクチャとして導出され得る。
一方、後述するように、候補リストの構成なしで、上記現ブロックの動き情報が導出され得、この場合、後述する予測モードで開始された手続によって、現ブロックの動き情報が導出され得る。この場合、前述したような候補リストの構成は省略され得る。
デコード装置200は、現ブロックの動き情報に基づいて、現ブロックに対する予測サンプルを生成することができる(S930)。この場合、デコード装置200は、現ブロックの参照ピクチャのインデックスに基づいて参照ピクチャを導出し、現ブロックの動きベクトルが参照ピクチャ上で指す参照ブロックのサンプルを利用し、現ブロックの予測サンプルを導出し得る。この場合、後述するように、場合によって、現ブロックの予測サンプルのうち、全てまたは一部に対する予測サンプルのフィルタリング手続がさらに行われ得る。
例えば、デコード装置200のインター予測部260は、予測モード決定部261、動き情報導出部262、予測サンプル導出部263を含み得、予測モード決定部181で受信した予測モード情報に基づいて上記現ブロックに対する予測モードを決定し、動き情報導出部182で受信した動き情報に関する情報に基づいて、上記現ブロックの動き情報(動きベクトルおよび/または参照ピクチャのインデックスなど)を導出し、予測サンプル導出部183から上記現ブロックの予測サンプルを導出し得る。
デコード装置200は、受信した残差情報に基づいて、上記現ブロックに対する残差サンプルを生成する(S940)。デコード装置200は、予測サンプルおよび残差サンプルに基づいて現ブロックに対する復元サンプルを生成し、これに基づいて復元ピクチャを生成することができる(S950)。以降、上記復元ピクチャにインループフィルタリング手続などがさらに適用され得ることは前述した通りである。
前述したようにインター予測手続は、インター予測モード決定段階、決定された予測モードによる動き情報導出段階、導出された動き情報に基づく予測実行(予測サンプルの生成)段階を含み得る。
インター予測モードの決定(Determination of inter prediction mode)
ピクチャ内の現ブロックの予測のために、様々なインター予測モードが使用され得る。例えば、マージモード、スキップモード、MVPモード、アフィン(Affine)モードなどの様々なモードが使用され得る。DMVR(Decoder side Motion Vector Refinement)モード、AMVR(Adaptive Motion Vector Resolution)モードなどが付随的なモードとしてさらに使用され得る。アフィンモードは、アフィン動き予測(affine motion prediction)モードと呼ばれてもよい。MVPモードは、AMVP(Advanced Motion Vector Prediction)モードと呼ばれてもよい。
現ブロックのインター予測モードを指す予測モード情報が、エンコード装置からデコード装置200にシグナリングされ得る。予測モード情報は、ビットストリームに含まれてデコード装置200で受信され得る。予測モード情報は、多数の候補モードのうちの一つを指示するインデックス情報を含み得る。あるいは、フラグ情報の階層的シグナリングを介して、インター予測モードを指示することもある。この場合、予測モード情報は、1つまたは複数のフラグを含み得る。例えば、エンコード装置100は、スキップフラグをシグナリングしてスキップモードの適用が可能か否かを指示し、スキップモードが適用されない場合に、マージフラグをシグナリングしてマージモードの適用が可能か否かを指示し、マージモードが適用されない場合に、MVPモードが適用されるものと指示するか、更なる区分(区別)のためのフラグをさらにシグナリングすることもある。アフィンモードは、独立したモードでシグナリングされてもよく、またはマージモードもしくはMVPモードなどに従属するモードでシグナリングされてもよい。例えば、アフィンモードは、後述するように、マージ候補リストまたはMVP候補リストの1つの候補で構成されることもできる。
インター予測モードによる動き情報の導出(Derivation of motion information according to inter prediction mode)
エンコード装置100またはデコード装置200は、現ブロックの動き情報を利用してインター予測を行うことができる。エンコード装置100は、動き推定(motion estimation)手続を介して、現ブロックに対する最適な動き情報を導出し得る。例えば、エンコード装置100は、現ブロックに対するオリジナルピクチャ内のオリジナルブロックを利用し、相関性の高い類似の参照ブロックを参照ピクチャ内の決められた探索範囲内で分数(端数)ピクセル単位で探索し得、これを介して、動き情報を導出し得る。ブロックの類似性は、位相(phase)ベースのサンプル値の差に基づいて導出され得る。例えば、ブロックの類似性は、現ブロック(または現ブロックのテンプレート)と参照ブロック(または参照ブロックのテンプレート)との間のSAD(Sum of Absolute Difference)に基づいて計算され得る。この場合、サーチスペース(探索領域)内のSADが、最も小さい参照ブロックに基づいて動き情報を導出し得る。導出された動き情報は、インター予測モードに基づいて、様々な方法によってデコード装置にシグナリングされ得る。
マージモードおよびスキップモード
マージモード(merge mode)が適用される場合、現在の予測ブロックの動き情報が直接送信されず、周辺の予測ブロックの動き情報を利用し、現在の予測ブロックの動き情報を導出することになる。したがって、エンコード装置100は、マージモードを利用したことを知らせるフラグ情報、および周辺のどの予測ブロックを利用したかを知らせるマージインデックスを送信することによって、現在の予測ブロックの動き情報を指示し得る。
エンコード装置100は、マージモードを行うために、現在の予測ブロックの動き情報を導出するために利用されるマージ候補ブロック(merge candidate block)をサーチすべきである。例えば、マージ候補ブロックは、最大5つまで利用され得るが、本明細書はこれに限定されない。そして、マージ候補ブロックの最大の数は、スライスヘッダで送信され得、本明細書はこれに限定されない。マージ候補ブロックを見付けた後、エンコード装置100は、マージ候補リストを生成し得、これらのうち、最も小さいコストを有するマージ候補ブロックを最終的なマージ候補ブロックとして選択し得る。
本明細書は、マージ候補リストを構成するマージ候補ブロックに対する様々な実施例を提供する。
マージ候補リストは、例えば、5つのマージ候補ブロックを利用し得る。例えば、4つの空間的マージ候補(spatial merge candidate)と1つの時間的マージ候補(temporal merge candidate)とを利用し得る。
図11は、現ブロックに対する空間的マージ候補の構成の例を示す。
図11を参照すると、現ブロックの予測のために、左側の隣接ブロックA1、左下側(bottom-left)の隣接ブロックA2、右上側(top-right)の隣接ブロックB0、上側の隣接ブロックB1、左上側(top-left)の隣接ブロックB2のうちの少なくとも1つが使用され得る。現ブロックに対するマージ候補リストは、図12のような手続に基づいて構成され得る。
図12は、本明細書の実施例にかかるマージ候補リストの構成のフローチャートの例を示す。
コーディング装置(エンコード装置100またはデコード装置200)は、現ブロックの空間的周辺ブロックを探索して導出された空間的マージ候補をマージ候補リストに挿入する(S1210)。例えば、空間的周辺ブロックは、現ブロックの左下側角の周辺ブロック、左側の周辺ブロック、右上側角の周辺ブロック、上側の周辺ブロック、左上側角の周辺ブロックを含み得る。ただし、これは、例として前述した空間的周辺ブロック以外にも、右側の周辺ブロック、下側の周辺ブロック、右下側の周辺ブロックなどの更なる周辺ブロックが、さらに上記空間的周辺ブロックとして使用され得る。コーディング装置は、空間的周辺ブロックを優先順位に基づいて探索して使用可能なブロックを検出し、検出されたブロックの動き情報を空間的マージ候補として導出し得る。例えば、エンコード装置100またはデコード装置200は、図11に示す5つのブロックをA1、B1、B0、A0、B2の順に探索し、使用可能な候補を順次インデキシングして、マージ候補リストを構成することができる。
コーディング装置は、現ブロックの時間的周辺ブロックを探索して導出された時間的マージ候補を上記マージ候補リストに挿入する(S1220)。時間的周辺ブロックは、現ブロックが位置する現ピクチャと異なるピクチャである参照ピクチャ上に位置し得る。時間的周辺ブロックが位置する参照ピクチャは、同位置のピクチャ(collocated picture)またはコロケート(コル)ピクチャ(col picture)と呼ばれ得る。時間的周辺ブロックは、コロケートピクチャ上における現ブロックに対する同位置のブロック(co-located block)の右下側角の周辺ブロックおよび右下側のセンターブロックの順に探索され得る。一方、動きデータ圧縮(motion data compression)が適用される場合、コロケートピクチャに一定の記憶単位ごとに特定の動き情報を代表の動き情報として記憶し得る。この場合、上記一定の記憶単位内の全てのブロックに対する動き情報を記憶する必要がなく、これを介して動きデータ圧縮の効果が得られる。この場合、一定の記憶単位は、例えば、16x16のサンプル単位、または8x8のサンプル単位などと予め決められることもあり、あるいは、エンコード装置100からデコード装置200に一定の記憶単位に対するサイズ情報がシグナリングされることもある。動きデータ圧縮が適用される場合、時間的周辺ブロックの動き情報は、時間的周辺ブロックが位置する一定の記憶単位の代表の動き情報に代替され得る。すなわち、この場合、実現の側面で見ると、時間的周辺ブロックの座標に位置する予測ブロックではなく、時間的周辺ブロックの座標(左上段のサンプルポジション)に基づいて、一定値だけ算術右シフトの後、算術左シフトした位置をカバーする予測ブロックの動き情報に基づいて時間的マージ候補が導出され得る。例えば、一定の記憶単位が2nx2nのサンプル単位である場合、時間的周辺ブロックの座標が(xTnb、yTnb)とすれば、修正された位置である((xTnb>>n)<<n)、(yTnb>>n)<<n))に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。具体的には、例えば、一定の記憶単位が16x16のサンプル単位である場合、時間的周辺ブロックの座標が(xTnb、yTnb)とすれば、修正された位置である((xTnb>>4)<<4)、(yTnb>>4)<<4))に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。あるいは、例えば、一定の記憶単位が8x8のサンプル単位である場合、時間的周辺ブロックの座標が(xTnb、yTnb)とすれば、修正された位置である((xTnb>>3)<<3)、(yTnb>>3)<<3))に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。
コーディング装置は、現在のマージ候補の数が最大のマージ候補の数より小さいか否かを確認することができる(S1230)。最大のマージ候補の数は、予め定義されるか、またはエンコード装置100からデコード装置200にシグナリングされ得る。例えば、エンコード装置100は、最大のマージ候補の数に関する情報を生成し、エンコードしてビットストリームの形態でデコード装置200に伝達し得る。最大のマージ候補の数が全て満たされると、以降の候補追加過程は行われなくてもよい。
確認の結果、現在のマージ候補の数が上記最大のマージ候補の数より小さい場合、コーディング装置は、追加のマージ候補をマージ候補リストに挿入する(S1240)。追加のマージ候補は、例えば、ATMVP(Adaptive Temporal Motion Vector Prediction)、結合された両方向予測(combined bi-predictive)マージ候補(現在スライスのスライスタイプがBタイプである場合)および/またはゼロベクトル(zero vector)マージ候補を含み得る。
図13は、予測候補リスト(MVP候補リスト)を構成するフローチャートの例を示す。
MVP(Motion Vector Prediction)モードが適用される場合、復元された空間的周辺ブロック(例えば、図11の周辺ブロック)の動きベクトルおよび/または時間的周辺ブロック(またはColブロック)に対応する動きベクトルを用いて、動きベクトル予測子(Motion Vector Predictor、MVP)候補リストが生成され得る。すなわち、復元された空間的周辺ブロックの動きベクトルおよび/または時間的周辺ブロックに対応する動きベクトルは、動きベクトル予測子の候補として使用され得る。上記予測に関する情報は、上記リストに含まれる動きベクトル予測子の候補のうちから選択された最適な動きベクトル予測子の候補を指示する選択情報(例えば、MVPフラグまたはMVPインデックス)を含み得る。この際、予測部は、上記選択情報を用いて、動きベクトル候補リストに含まれる動きベクトル予測子の候補のうちから、現ブロックの動きベクトル予測子を選択し得る。エンコード装置100の予測部は、現ブロックの動きベクトルと動きベクトル予測子との間の動きベクトル差分(MVD)を求めることができ、これをエンコードし、ビットストリームの形態で出力することができる。すなわち、MVDは、現ブロックの動きベクトルから上記動きベクトル予測子を引いた値で求められる。この際、デコード装置の予測部は、上記予測に関する情報に含まれる動きベクトル差分を獲得し、上記動きベクトル差分と上記動きベクトル予測子との加算を介して、現ブロックの上記動きベクトルを導出し得る。デコード装置の予測部は、参照ピクチャを指示する参照ピクチャのインデックスなどを上記予測に関する情報から獲得または導出し得る。例えば、動きベクトル予測子候補リストは、図13のように構成され得る。
図13を参照すると、コーディング装置は、動きベクトルの予測のための空間的候補ブロックを探索して予測候補リストに挿入する(S1310)。例えば、コーディング装置は、決められた探索の順序に従って周辺ブロックに対する探索を行い、空間的候補ブロックに対する条件を満たす周辺ブロックの情報を予測候補リスト(MVP候補リスト)に追加し得る。
空間的候補ブロックリストを構成した後、コーディング装置は、予測候補リストに含まれる空間的候補リストの数と、既設定された基準の数(例えば、2)と、を比較する(S1320)。予測候補リストに含まれる空間的候補リストの数が基準の数(例えば、2)より大きいか等しい場合、コーディング装置は、予測候補リストの構成を終了し得る。
しかしながら、予測候補リストに含まれる空間的候補リストの数が基準の数(例えば、2)より小さい場合、コーディング装置は、時間的候補ブロックを探索して予測候補リストに追加挿入し(S1330)、時間的候補ブロックが使用されることができない場合、ゼロ動きベクトルを予測候補リストに追加する(S1340)。
予測サンプルの生成(Generation of prediction sample)
予測モードに応じて導出された動き情報に基づいて、現ブロックに対する予測されたブロックが導出され得る。予測されたブロックは、現ブロックの予測サンプル(予測サンプルアレイ)を含み得る。現ブロックの動きベクトルが分数サンプル単位を指す場合、補間(interpolation)手続が行われ得、これを介して参照ピクチャ内で分数サンプル単位の参照サンプルに基づいて、上記現ブロックの予測サンプルが導出され得る。現ブロックにアフィン(affine)インター予測が適用される場合、サンプル/サブブロック単位の動きベクトル(motion vector)に基づいて予測サンプルが生成され得る。両方向(bi-direction)の予測が適用される場合、第1方向の予測(例えば、L0予測)に基づいて導出された予測サンプルと、第2方向の予測(例えば、L1予測)に基づいて導出された予測サンプルの(位相による)加重和を介して、最終的な予測サンプルが導出され得る。導出された予測サンプルに基づいて復元サンプルおよび復元ピクチャが生成され得、以降、インループフィルタリングなどの手続が行われ得ることは、前述した通りである。
アフィン動き予測(Affine motion prediction)
図14は、本発明の実施例にかかる動きモデル(motion models)の例を示す。
従来の映像圧縮技術(例えば、HEVC(High Efficiency Video Coding))は、符号化ブロックの動き(motion)を表現するために、1つの動きベクトル(motion vector)を使用する。ブロックごとに1つの動きベクトルを使用する方式がブロック単位の最適な動きを表現していることがあるが、実際の各画素の最適な動きではないことがある。したがって、画素単位で最適な動きベクトルを決定することができれば、符号化効率を高めることができる。そのため、本発明の実施例は、多数の動きモデル(multi motion model)を使用し、ビデオ信号を符号化または復号する動き予測(motion prediction)方法について説明する。特に、2つ乃至4つの制御点の動きベクトルを用いて、ブロックの各画素単位またはサブブロック単位で動きベクトルを表現し得、このような複数の制御点の動きベクトルを使用した予測技法は、アフィン動き予測(affine motion prediction)、アフィン予測(affine prediction)などと称される。
本発明の実施例にかかるアフィン動きモデル(affine motion model)は、図14に示すような4つの動きモデルを表現し得る。アフィン動きモデル(Affine motion model)が表現し得る動きのうちの3つの動き(トランスレーション(translation)、スケール(scale)、ローテート(rotate))を表現するアフィン動きモデル(affine motion model)を類似アフィン動きモデル(similarity (or simplified) affine motion model)と称し、本発明の実施例を説明するにあたって、説明の便宜のために、類似アフィン動きモデル(similarity (or simplified) affine motion model)を基準に説明するが、本発明がこれに限定されるわけではない。
図15は、本発明の実施例にかかるアフィン動き予測のための制御点の動きベクトルの例を示す。
図15のように、アフィン動き予測は、2つの制御点の動きベクトル(Control Point Motion Vector、CPMV)ペア(pair)、v_0およびv_1を用いて、ブロックが含む画素位置(またはサブブロック)の動きベクトルを決定し得る。この際、動きベクトルの集合は、アフィン動きベクトルフィールド(Motion Vector Field、MVF)と称される。この際、アフィン動きベクトルフィールドは、下記の数式1を用いて決定され得る。
数式1で、v_0(v_0={v_0x,v_0y})は、現ブロック1500の左上側位置の第1の制御点の動きベクトル(CPMV0)を表し、v_1(v_1={v_1x,v_1y})は、現ブロック1500の右上側位置の第2の制御点の動きベクトル(CPMV1)を表す。また、wは、現ブロック1500の幅(width)を表す。v(v={v_x,v_y})は、{x,y}位置における動きベクトルを表す。サブブロック(または画素)単位の動きベクトルは、上記数式1を用いて導出され得る。一実施例において、動きベクトルの精度は、1/16の精度で丸められ得る。
図16は、本発明の実施例にかかるアフィン動き予測が適用されたブロックの各サブブロック別の動きベクトルの例を示す。
図16を参照すると、符号化または復号の過程でアフィン動きベクトルフィールド(MVF)は、画素単位もしくはブロック単位で決定され得る。すなわち、アフィン動き予測において、現ブロックの動きベクトルは、画素単位またはサブブロック単位で導出され得る。
画素単位でアフィン動きベクトルフィールドが決定される場合、各画素値を基準に動きベクトルが得られ、ブロック単位の場合、ブロックの中央画素値を基準に該当ブロックの動きベクトルが得られる。本文書で、図16のようにアフィン動きベクトルフィールド(MVF)が4*4のブロック単位で決定される場合が仮定される。ただし、これは、説明の便宜のためのものであり、本発明の実施例が限定されるわけではない。図16は、符号化ブロックが16*16個のサンプルで構成され、4*4サイズのブロック単位でアフィン動きベクトルフィールド(MVF)が決定される場合の例を示す。
アフィン動き予測(affine motion prediction)は、アフィンマージモード(affine merge modeまたはAF_MERGE)と、アフィンインターモード(affine inter modeまたはAF_INTER)と、を含み得る。AF_INTERモードは、4つのパラメータベース動きモデルを用いるAF_4_INTERモードと、6つのパラメータベース動きモデルを用いるAF_6_INTERモードと、を含み得る。
アフィンマージモード(Affine merge mode)
AF_MERGEは、アフィン動き予測としてコーディングされた周辺ブロックのアフィン動きモデルに応じて、制御点の動きベクトル(Control Point Motion Vector:CPMV)を決定する。検索順序でアフィンコーディングされた周辺ブロックは、AF_MERGEのために使用され得る。1つまたは複数の隣接ブロックがアフィン動き予測としてコーディングされる際、現ブロックは、AF_MERGEとしてコーディングされ得る。
すなわち、アフィンマージモードが適用される場合、周辺ブロックのCPMVを用いて現ブロックのCPMVを導出し得る。この場合、周辺ブロックのCPMVが、そのまま現ブロックのCPMVに使用されることもあり、周辺ブロックのCPMVが、上記周辺ブロックのサイズ、および上記現ブロックのサイズなどに基づいて修正され、現ブロックのCPMVに使用されることもある。
図17は、本発明の実施例にかかるアフィンマージモード(affine merge mode)でアフィン動き予測に使用される周辺ブロックの例を示す。
アフィンマージ(AF_MERGE)モードで、エンコーダは、下記のような過程の符号化を行うことができる。
ステップ−1:現在の符号化ブロック1700の周辺ブロックA乃至E1710、1720、1730、1740、1750をアルファベット順でスキャン(scanning)し、スキャン順序の基準の1番目にアフィン予測モードで符号化されたブロックをアフィンマージ(AF_MERGE)の候補ブロックに決定
ステップ−2:決定された候補ブロックの制御点の動きベクトル(CPMV)を用いてアフィン動きモデルを決定
ステップ−3:候補ブロックのアフィン動きモデルに応じて、現ブロック1700の制御点の動きベクトル(CPMV)が決定され、現ブロック1700のMVFを決定
図18は、本発明の実施例にかかるアフィン動き予測が適用された周辺ブロックを使用し、アフィン動き予測が行われるブロックの例を示す。
例えば、図18のようにブロックA1820がアフィンモード(affine mode)で符号化された場合、ブロックA1820を候補ブロックとして決定した後、ブロックA1820の制御点の動きベクトル(CPMV)(例えば、v2およびv3)を用いてアフィン動きモデル(affine motion model)を導出した後、現ブロック1800の制御点の動きベクトル(CPMV)v0およびv1を決定し得る。現ブロック1800の制御点の動きベクトル(CPMV)に基づいて、現ブロック1800のアフィン動きベクトルフィールド(MVF)が決定され、符号化が行われ得る。
図19は、本発明の実施例にかかる周辺のアフィン符号化ブロックを用いてマージ候補リストを生成する方法を説明する図である。
図19を参照すると、アフィンマージ候補を用いてCPMVペアを決定する場合、図19に示すような候補が使用され得る。図19で、候補リストのスキャン順序は、A、B、C、D、Eに設定された場合を仮定する。ただし、本発明がこれに限定されるわけではなく、様々な順序で予め設定され得る。
実施例として、周辺ブロック(すなわち、A、B、C、D、E)で利用可能なアフィンモード(またはアフィン予測)で符号化された候補(以下、アフィン候補と称される)の数が0であるとき、現ブロックのアフィンマージモードはスキップされ得る。利用可能なアフィン候補の数が1つである場合(例えば、A)、該当候補の動きモデルが現ブロックの制御点の動きベクトル(CPMV_0およびCPMV_1)を導出するのに利用され得る。この場合、該当候補を指示するインデックスが要求(またはコーディング)されなくてもよい。利用可能なアフィン候補の数が2つ以上である場合、スキャンの順序上、2つの候補がAF_MERGEに対する候補リストで構成され得る。この場合、候補リスト内で選択された候補を指示するインデックスと同一の候補選択情報がシグナリングされ得る。上記選択情報は、フラグまたはインデックス情報であってもよく、AF_MERGE_flag、AF_merge_idxなどと称される。
本発明の実施例において、現ブロックに対する動き補償は、サブブロックの大きさに基づいて行われ得る。この場合、アフィンブロック(すなわち、現ブロック)のサブブロックの大きさが導出される。サブブロックの幅および高さがいずれも4つのルマサンプルより大きい場合、各サブブロックに対する動きベクトルが導出され、DCT−IFベースの動き補償(輝度に対する1/16ペルおよび色差に対する1/32)がサブブロックに対して行われ得る。そうでなければ、向上したバイリニア(二重線形)補間フィルタベース動き補償(enhanced bi-linear interpolation filter based motion compensation)が全アフィンブロックに対して行われ得る。
本発明の実施例において、マージ/スキップフラグ(merge/skip flag)が真であり、CUに対する幅および高さがいずれも8より大きいか等しいとき、CUレベルでアフィンフラグは、アフィンマージモードが使用されるかを指示するビットストリーム(bit stream)を介してシグナリングされる。CUがAF_MERGEとしてコーディングされる際、最大値「5」を有するマージ候補のインデックスは、アフィンマージ候補リストにおける動き情報の候補がCUのために使用されることを指定するためにシグナリングされる。
図20および図21は、本発明の実施例にかかるアフィン予測で符号化された周辺ブロックを使用し、アフィンマージ候補リストを構成する方法を説明する図である。
図20を参照すると、アフィンマージ候補リストは、次の段階によって構成される。
1)モデルベースアフィン候補の挿入
モデルベースアフィン候補は、候補がアフィンモードでコーディングされた有効な周辺の再構成されたブロックから導出されることを意味する。図20に示すように、候補ブロックに対するスキャン順序は、左側(A)、上側(b)、右上側(C)、および左下側(D)から左上側(E)である。
周辺の左下側ブロック(A)が6−パラメータアフィンモードでコーディングされると、ブロック(A)を含むCUの左上側角、右上側角、および左下側角の動きベクトル(v_4、v_5、v_6)を得ることになる。現ブロック上の左上側角の動きベクトル(v_0、v_1、v_2)は、6−パラメータアフィンモデルによる動きベクトル(v_4、v_5、and v_6)に従って計算される。
周辺の左下側ブロック(A)が4−パラメータアフィンモードでコーディングされると、ブロック(A)を含むCUの左上側角および右上側角の動きベクトル(v_4、v_5)を得ることになる。現ブロック上の左上側角の動きベクトル(v_0、v_1)は、4−パラメータアフィンモデルによる動きベクトル(v_4、v_5)に従って計算される。
2)制御点ベースアフィン候補の挿入
図20を参照すると、制御点ベース候補は、各制御点の周辺の動き情報を結合して候補が構成されることを意味する。
制御点に対する動き情報は、まず、図20に示す指定された空間の隣接ブロックおよび時間の隣接ブロックから導出される。CP_k(k=1、2、3、4)は、k番目の制御点を表す。また、A、B、C、D、E、F、およびGは、CP_k(k=1、2、3)を予測するための空間位置であり、Hは、CP4を予測するための時間位置である。
CP_1、CP_2、CP_3、およびCP_4の座標は、それぞれ(0,0)、(W,0)、(H,0)、および(W,H)であり、ここで、WおよびHは、現ブロックの幅および高さである。
各制御点の動き情報は、次の優先順位に従って得られる。
CP_1に対して、チェックの優先順位は、A→B→Cであり、Aが利用可能であれば、Aが使用される。そうでなく、Bが利用可能であれば、Bが使用される。AもBも利用可能でなければ、Cが使用される。3つの候補がいずれも利用可能でなければ、CP1の動き情報が得られない。
CP_2に対して、チェックの優先順位は、E→Dである。
CP_3に対して、チェックの優先順位は、G→Fである。
CP_4に対して、Hが使用される。
第二に、制御点の組み合わせが動きモデルを構成するのに使用される。
2つの制御点の動きベクトルは、4−パラメータアフィンモデルで変換パラメータを算出するのに必要である。2つの制御点は、次の6つの組み合わせ({CP_1,CP_4}、{CP_2,CP_3}、{CP_1,CP_2}、{CP_2,CP_4}、{CP_1,CP_3}、{CP_3,CP_4})のいずれかから選択され得る。例えば、4−パラメータアフィン動きモデルを構成するのにCP_1およびCP_2の制御点を使用することは、「Affine(CP_1,CP_2)」と表記される。
3つの制御点の動きベクトルは、6−パラメータアフィンモデルで変換パラメータを算出するのに必要である。3つの制御点は、次の4つの組み合わせ({CP_1,CP_2,CP_4}、{CP_1,CP_2,CP_3}、{CP_2,CP_3,CP_4}、{CP_1,CP_3,CP_4})のいずれかから選択され得る。例えば、6−パラメータアフィン動きモデルを構成するのにCP_1、CP_2、およびCP_3の制御点を使用することは、「Affine(CP_1,CP_2,CP_3)」と表記される。
また、本発明の実施例において、アフィンマージモードで、アフィンマージ候補が存在すれば、それは、常時6−パラメータアフィンモードとして考慮され得る。
アフィンインターモード(affine inter mode)
図22は、本発明の実施例にかかるアフィンインターモード(affine inter mode)でアフィン動き予測に使用される周辺ブロックの例を示す。
図22を参照すると、アフィン動き予測(affine motion prediction)は、アフィンマージモード(affine merge modeまたはAF_MERGE)と、アフィンインターモード(affine inter modeまたはAF_INTER)と、を含み得る。アフィンインターモード(AF_INTER)で、2つの制御点の動きベクトル予測(Control Point Motion Vector Prediction、CPMVP)およびCPMVを決定した後、差に該当する制御点の動きベクトル差分値(Control Point Motion Vector Difference、CPMVD)がエンコーダからデコーダへ送信され得る。具体的なアフィンインターモード(AF_INTER)の符号化過程は、下記の通りである。
ステップ−1:2つのCPMVPペア(pair)の候補(candidate)を決定
ステップ−1.1:最大12個のCPMVP候補の組み合わせを決定(下記の数式2を参照)
数式2で、v_0は、現ブロック2200の左上側制御点2210における動きベクトル(CPMV0)、v_1は、現ブロック2200の右上側制御点2211における動きベクトル(CPMV1)、v_2は、現ブロック2200の左下側制御点2212における動きベクトル(CPMV2)であり、v_Aは、現ブロック2200の左上側制御点2210の左上側に隣接する周辺ブロックA2220の動きベクトル、v_Bは、現ブロック2200の左上側制御点2210の上側に隣接する周辺ブロックB2222の動きベクトル、vCは、現ブロック2200の左上側制御点2210の左側に隣接する周辺ブロックC2224の動きベクトル、v_Dは、現ブロック2200の右上側制御点2211の上側に隣接する周辺ブロックD2226の動きベクトル、v_Eは、現ブロック2200の右上側制御点2211の右上側に隣接する周辺ブロックE2228の動きベクトル、v_Fは、現ブロック2200の左下側制御点2212の左側に隣接する周辺ブロックF2230の動きベクトル、v_Gは、現ブロック2200の左下側制御点2212の左側に隣接する周辺ブロックG2232の動きベクトルを表す。
ステップ−1.2:CPMVP候補の組み合わせのうち、差異値(Difference Value、DV)が小さい値を基準に整列(sorting)し、上位2つの候補を使用(下記の数式3を参照)
v_0xは、現ブロック2200の左上側制御点2210の動きベクトル(V0またはCPMV0)のx軸エレメント、v_1xは、現ブロック2200の右上側制御点2211の動きベクトル(V1またはCPMV1)のx軸エレメント、v_2xは、現ブロック2200の左下側制御点2212の動きベクトル(V_2またはCPMV_2)のx軸エレメント、v_0yは、現ブロック2200の左上側制御点2210の動きベクトル(V_0またはCPMV_0)のy軸エレメント、v_1yは、現ブロック2200の右上側制御点2211の動きベクトル(V_1またはCPMV_1)のy軸エレメント、v_2yは、現ブロック2200の左下側制御点2212の動きベクトル(V_2またはCPMV_2)のy軸エレメント、wは、現ブロック2200の幅(width)、hは、現ブロック2200の高さ(height)を表す。
ステップ−2:制御点動きベクトル予測子(CPMVP)ペアの候補が2より小さい場合、AMVP候補リストを使用
ステップ−3:2つの候補それぞれに対して制御点の動きベクトル予測子(CPMVP)を決定し、RDコストを比較し、小さい値を有する候補およびCPMVを最適に選択
ステップ−4:最適な候補に該当するインデックスと制御点の動きベクトル差分値(Control Point Motion Vector Difference、CPMVD)とを送信
本発明の実施例において、AF_INTERで、CPMVP候補の構成過程が提供される。AMVPと同じように、候補の数は2であり、候補リストの位置を指示するインデックスがシグナリングされる。
CPMVP候補リストの構成過程は、次の通りである。
1)周辺ブロックをスキャンし、これがアフィン動き予測としてコーディングされるかをチェックする。スキャンされたブロックがアフィン予測としてコーディングされると、候補の数が2になるまでスキャンされた周辺ブロックのアフィン動きモデルから現ブロックの動きベクトルペアを導出する。
2)候補の数が2より小さい場合、候補の構成過程を行う。また、本発明の実施例において、4−パラメータ(2−制御点)アフィンインターモードが、ズーム−イン/アウト(zoom-in/out)および回転の動きモデルならびにコンテンツを予測するのに使用される。図15に示すように、ブロックのアフィン動きフィールド(field)は、2つの制御点の動きベクトルにより記述される。
ブロックの動きベクトルフィールド(Motion Vector Field:MVF)は、前述した式1により記述される。
従来技術で、AMVP(Advanced Motion Vector Prediction)モードは、MVP(Motion Vector Prediction)インデックスおよびMVDs(Motion Vector Differences)をシグナリングするのに必要である。AMVPモードが本発明に適用される際、アフィン_フラグ(affine_flag)は、アフィン予測が使用されるかを指示するようにシグナリングされる。アフィン予測が適用されると、inter_dir、ref_idx、mvp_indexおよび2つのMVDs(mvd_xおよびmvd_y)のシンタックスがシグナリングされる。2つのアフィンMVPペアを含むアフィンMVPペアの候補リストが生成される。シグナリングされたmvp_indexは、これらのうちの一つを選択するのに使用される。アフィンMVPペアは、2つの種類のアフィンMVP候補により生成される。1つは、空間的継承アフィン候補(spatial inherited affine candidate)であり、もう1つは、コーナ導出されたアフィン候補(corner derived affine candidate)である。周辺のCUがアフィンモードでコーディングされると、空間的継承アフィン候補が生成され得る。周辺のアフィンコーディングされたブロックのアフィン動きモデルは、2−制御点のMVPペア(two-control-point MVP pair)の動きベクトルを生成するのに使用される。空間的継承アフィン候補の2−制御点MVPペアのMVは、次の数式を使用することによって導出される。
<数式4>
V0x = VB0x + (VB2_x - VB0x ) * ( posCurCU_Y - posRefCU_Y ) / RefCU_height+ (VB1x - VB0x ) * (posCurCU_X - posRefCU_X) / RefCU_width
<数式5>
V0y = VB0y + (VB2_y - VB0y ) * (posCurCU_Y - posRefCU_Y) / RefCU_height+ (VB1y - VB0y ) * (posCurCU_X - posRefCU_X) / RefCU_width
V_B0、V_B1、およびV_B2が、ある参照/周辺のCUの左上側MV、右上側MV、および左下側MVに代替されることができる場合、(posCurCU_X、posCurCU_Y)は、フレームの左上側サンプルに対する現在のCUの左上側サンプルの位置であり、(posRefCU_X、posRefCU_Y)は、フレームの左上側サンプルに対する参照/周辺のCUの左上側サンプルの位置である。
<数式6>
V1x = VB0x + (VB1x - VB0x) * CU_width / RefCU_width
<数式7>
V1y = VB0y + (VB1y - VB0y) * CU_width / RefCU_width
図23は、本発明の実施例にかかるアフィンインターモード(affine inter mode)でアフィン動き予測に使用される周辺ブロックの例を示す。
図23を参照すると、MVPペアの数が2より小さい場合、コーナ導出されたアフィン候補が使用される。周辺の動きベクトルは、図23に示すように、アフィンMVPペアを導出するのに使用される。第1のコーナ導出されたアフィン候補に対して、セットA(A0、A1、およびA2)で第1の利用可能なMVとセットB(B0およびB1)で第1の利用可能なMVとは、第1のMVPペアを構成するのに使用される。第2のコーナ導出されたアフィン候補に対して、セットAで第1の利用可能なMVとセットC(C0およびC1)で第1の利用可能なMVとは、右上側制御点のMVを計算するのに使用される。セットAで第1の利用可能なMVと計算された右上側制御点MVとは、第2のMVPペアである。
本発明の実施例において、2つ(3つ)の候補{mv_0,mv_1}({mv_0,mv_1,mv_2})を含む2つの候補セットは、アフィン動きモデルの2つ(3つ)の制御点を予測するのに使用される。与えられた動きベクトルの差分(mvd_0,mvd_1,mvd_2)および制御点は、次の式を使用することによって計算される。
図24および図25は、本発明の実施例にかかるアフィンインターモード(affine inter mode)で周辺ブロックの動き情報を用いて動きベクトル候補を導出する方法を例示する図である。
上記アフィン候補リストは、アフィン動きを空間的隣接ブロック(外挿されたアフィン候補)から延びて、空間的隣接ブロック(仮想のアフィン候補)からの動きベクトルの組み合わせにより添付される(appended)(上記アフィン候補リストにおいて、アフィン動きが空間的隣接ブロックから拡張され(外挿されたアフィン候補)、このアフィン候補リストに、上記空間的隣接ブロックからの動きベクトルの組み合わせ(仮想のアフィン候補)がアペンドされる(In the affine candidate list, an affine motion is extended from spatial neighboring blocks (extrapolated affine candidates), and the affine candidate list is appended by a combination of motion vectors from the spatial neighboring blocks (virtual affine candidates)))。候補の集合は、下記のように設定される。
1.最大2つの異なるアフィンMV予測子の集合が隣接ブロックのアフィン動きから導出される。隣接ブロックA0、A1、B0、B1、およびB2が図24に示すように確認される。隣接ブロックがアフィン動きモデルによって符号化され、その参照フレームが現ブロックの参照フレームと同一である場合、現ブロックの(4−パラメータアフィンモデルに対する)2つまたは(6−パラメータアフィンモデルに対する)3つの制御点が隣接ブロックのアフィンモデルから導出される。
2.図25は、仮想のアフィン候補の集合を生成するために使用される隣接ブロックを示す。隣接MVは、3つのグループに分割される:S_0={mv_A,mv_B,mv_C}、S_1={mv_D,mv_E}、S_2={mv_F,mv_G}。mv_0は、S0で現ブロックと同一の参照ピクチャを参照する1番目のMVである。mv_2は、S1で現ブロックと同一の参照ピクチャを参照する1番目のMVである。
mv_0およびmv_1が与えられると、mv_2は、下記の数式9により導出され得る。
数式9で、現ブロックのサイズは、WxHである。
mv_0およびmv_2のみが与えられると、mv_1は、下記の数式10により導出され得る。
本発明の一実施例において、アフィンインター予測は、下記のシーケンス(sequence)によって行われ得る。
入力:アフィン動きパラメータ、参照ピクチャのサンプル
出力:CUの予測ブロック
プロセス
− アフィンブロックのサブブロックのサイズを導出
− サブブロックの幅と、幅モード4のルマサンプル(luma samples)より大きい場合(サブブロックの幅および幅の両方が4つのルマサンプルより大きい場合(If both the width and height of a sub-block are larger than 4 luma samples))、
− それぞれのサブブロックに対して
− サブブロックの動きベクトルを導出
− DCT−IFベースの動き補償(ルマに対して1/16ペル、色差に対して1/32ペル)をサブブロックに対して実行(invoked)
− そうでなければ、向上したバイリニア補間フィルタ(enhanced bi-linear interpolation filter)ベースの補償が全アフィンブロックに対して実行される(invoked)
また、本発明の一実施例において、マージ/スキップフラグが偽(虚)(false)であり、CUに対する幅および高さが8より大きいか等しければ、CUレベルでアフィンフラグが、アフィンインターモードが使用されるか否かを指示するためにシグナリングされる。CUがアフィンインターモードとしてコーディングされると、モデルフラグが4−パラメータまたは6−パラメータアフィンモデルが上記CUに対して適用されるか否かを指示するためにシグナリングされる。モデルフラグが真(true)である場合、AF_6_INTER mode(6−パラメータアフィンモデル)が適用され、3つのMVDがパージングされ、そうでなければ、AF_4_INTER mode4−パラメータアフィンモデル)が適用され、2つのMVDがパージングされる。
AF_4_INTERモードで、アフィンマージモードと同様に、アフィン(アフィン)モードによりコーディングされた隣接ブロックから外挿された動きベクトルペアが生成され、1番目に候補リストに挿入される。
以降、候補リストのサイズが4より小さい場合、動きベクトルペア{(v_0,v_1)|v0={v_A,v_B,v_c}、v_1={v_D,v_E}}を有する候補が隣接ブロックを使用することによって生成される。図25に示すように、v_0は、ブロックA、B、Cの動きベクトルから選択される。隣接ブロックからの動きベクトルは、参照リスト、隣接ブロックに対する参照のPOC、現在のCUに対する参照のPOCおよび現在のCUの間の関係によってスケーリングされる。また、隣接ブロックDおよびEからv_1を選択するアプローチ方式は類似する。候補リストが4より大きい場合、候補は、(候補ペアにおける2つの動きベクトルと同様に)隣接動きベクトルの一貫性(consistency)によって優先的に整列され、最初(1番目)の4つの候補が記憶される。
候補リストの数が4より小さい場合、リストは、各AMVP候補を複製することによって、動きベクトルペアによりパディングされる(padded)。
AF_6_INTERモードで、アフィンマージモードと同様に、アフィン(アフィン)モードでコーディングされた隣接ブロックから外挿された動きベクトルトリプル(affine motion vector triples)が生成され、候補リストに優先的に挿入される。
以降、候補リストのサイズが4より小さい場合、動きベクトルトリプル{(v_0,v_1,v_2)|v0={v_A,v_B,v_c}、v1={v_D,v_E}、v2={v_G,v_H}}を含む候補が隣接ブロックを使用して生成される。図25で示すように、v_0は、ブロックA、B、またはCの動きベクトルから選択される。隣接ブロックからの動きベクトルは、参照リスト、隣接ブロックに対する参照のPOC、現CUに対する参照のPOC、および現CUのPOCの関係によってスケーリングされる。また、隣接ブロックDおよびEからv_1を選択するためのアプローチ(接近)と、FとGからv_2を選択するためのアプローチと、は類似する。候補リストが4より大きい場合、候補は、(3つの候補における2つの動きベクトルと同様に)隣接動きベクトルの一貫性によって整列され、最初の4つの候補が記憶される。
候補リストの数が4より小さい場合、リストは、各AMVP候補を複製することによって(duplicating)構成される動きベクトルトリプルによりパディングされ得る。
現CUのCPMVが導出された後、アフィンパラメータの数によって、現CUのMVFが4−パラメータアフィンモデルに対する下記の数式11によって生成され、6−パラメータアフィンモデルに対する下記の数式12によって生成される。
ここで、サブブロックのサイズMxNは、下記の数式13で導出され、MvPreは、動きベクトル部分の精度(正確度)(1/16)である。
数式12により導出された後、MおよびNは、wおよびhの分母(divisor)にするために必要であれば下方修正しなければならない。MまたはNが8より小さい場合、WIFが適用され、そうでなければ、サブブロックベースのアフィン動き補償が適用される。
図26は、本発明の実施例にかかるサブブロック単位のアフィン動きベクトルフィールドを導出する方法の一例を示す。
図26を参照すると、各MxNのサブブロックの動きベクトルを導出するために、図26に示すような各サブブロックの中央サンプルの動きベクトルは、数式11または数式12によって計算され、1/16部分の精度で丸められる(rounded)。SHVCアップ(上方)サンプリング補間フィルタが、導出された動きベクトルを使用して各サブブロックの予測を生成するために適用される。
HEVC動き補償補間フィルタと同一のフィルタ長さおよび正規化因子を有するSHVCアップサンプリング補間フィルタは、更なる部分(端数)ペル位置(additional fractional pel positions)に対する動き補償補間フィルタとして使用され得る。クロマ成分の動きベクトルの精度は、1/32サンプルであり、1/32ペル部分の位置の更なる補間フィルタは、2つの隣接する1/16ペル部分の位置のフィルタの平均を使用することによって導出される。
AF_MERGEモードは、通常のマージモードの選択が行われるのと同じ方式でエンコーダ側で選択され得る。候補リストが優先的に生成され、候補で最小のRD−コストが、他のインターモードのRD−コストと比較するために選択される。比較の結果は、AF_MERGEが適用されるか否かに対する決定である。
AF_4_INTERモードのために、RDコストの確認は、いずれの動きベクトルペアの候補が現CUの制御点の動きベクトル予測(Control Point Motion Vector Prediction、CPMVP)として選択されるかを決定するために使用される。現在のアフィンCUのCPMVPが決定された後、アフィン動きの推定が適用され、制御点の動きベクトル(Control Point Motion Vector、CPMV)が獲得される。そうすると、CPMVとCPMVPとの差が決定される。
エンコーダ側で、AF_MERGEまたはAF_4_INTERモードが以前のモード選択ステージで最適なモードとして決定される際にのみ、AF_6_INTERモードが確認される。
本発明の一実施例において、アフィンインター(アフィンAMVP)モードは、下記のように行われ得る。
1)AFFINE_MERGE_IMPROVE:アフィンモードである1番目の隣接ブロックを探索する代わりに、改善点(improvement)は、最大のコーディングユニットのサイズを有する隣接ブロックをアフィンマージ候補として探索しようとすることである。
2)AFFINE_AMVL_IMPROVE:アフィンモードである隣接ブロックを通常のAMVP手続と同様にアフィンAMVP候補リストに追加する。
詳細なアフィンAMVP候補リストの生成過程は、下記の通りである。
第一に、左側下の隣接ブロックがアフィン動きモデルを使用し、現在の参照インデックスと同一の参照インデックスを有するか否かが確認される。存在しなければ、左側の隣接ブロックが同じ方法で確認される。存在しなければ、左側下の隣接ブロックがアフィン動きモデルを使用し、異なる参照インデックスを有するか否かが確認される。存在すれば、スケーリングされたアフィン動きベクトルが参照ピクチャリストに追加される。存在しなければ、左側の隣接ブロックが同じ方式で確認される。
第二に、右側上部の隣接ブロック、上部の隣接ブロック、および左側上部の隣接ブロックが同じ方式で確認される。
前述した過程以降、2つの候補を探索すると、アフィンAMVP候補リストを生成する動作を終了する。2つの候補を探索することができない場合、JEMソフトウェア内の元の動作がアフィンAMVP候補リストを生成するために行われる。
3)AFFINE_SIX_PARAM:4−パラメータアフィン動きモデル以外に、6−パラメータアフィン動きモデルが更なるモデルとして追加される。
6−パラメータアフィン動きモデルが下記の数式14を介して導出される。
前述した動きモデルに6−パラメータが存在するので、左側上部の位置MV_0、右側上部の位置MV_1および左側下部の位置MV_2における3つの動きベクトルがモデルを決定するために要求される。3つの動きベクトルが4−パラメータアフィン動きモデルで2つの動きベクトルと類似の方式で決定され得る。アフィンモデルマージは、常時6−パラメータアフィン動きモデルとして設定される。
4)AFFINE_CLIP_REMOVE:全てのアフィン動きベクトルに対する動きベクトルの制約(constraints)を除去する。動き補償の過程が動きベクトルの制約そのものを制御するようにする。
アフィン動きモデル(Affine motion model)
前述したように、アフィンインター予測(Affine inter prediction)で様々なアフィン動きモデル(affine motion model)が使用または考慮され得る。例えば、アフィン動きモデルは、前述した図14のように、4つの動きを表現し得る。アフィン動きモデルが表現し得る動きのうち、3つの動き(トランスレーション(translation)、スケール(scale)、ローテート(rotate))を表現するアフィン動きモデルは、類似アフィン動きモデル(similarity (or simplified) affine motion model)といえる。上記アフィン動きモデルのうち、どのモデルを使用するかによって、導出されるCPMVの数および/または現ブロックのサンプル/サブブロック単位のMVの導出方法が変わり得る。
本発明の一実施例において、適応的な4つおよび6つのパラメータ動きモデルが使用される。AF_INTERで、6−パラメータ動きモデルがJEMで存在する4−パラメータ動きモデルに加えて提案される。6−パラメータアフィン動きモデルが下記の数式15のように説明される。
ここで、係数a、b、c、d、e、およびfは、アフィン動きパラメータであり、(x,y)および(x’,y’)は、アフィン動きモデルの変換以前および以降のピクセル位置の座標である。ビデオコーディングでアフィン動きモデルを使用するために、CPMV0、CPMV1、およびCPMV2が、CP0(左上側)、CP1(右上側)、およびCP2(左下側)に対するMVであれば、数式16が下記のように説明され得る。
ここで、CPMV_0={v_0x,v_0y}、CPMV_1={v_1x,v_1y}、CPMV_2={v_2x,v_2y}、ならびに、wおよびhは、それぞれコーディングブロックの幅(width)および高さ(height)である。数式16は、ブロックの動きベクトルフィールド(Motion Vector Field、MVF)である。
フラグが、隣接ブロックがアフィン予測でコーディングされた際に4−パラメータまたは6−パラメータアフィン動きモデルが使用されるか否かを指示するために、CUレベルでパージングされる。アフィン予測でコーディングされた隣接ブロックがなければ、フラグは省略され、4−パラメータのモデルがアフィン予測のために使用される。言い換えると、6−パラメータモデルは、1つまたは複数の隣接ブロックがアフィン動きモデルでコーディングされるという条件で考慮される。CPMVDの数に関して、2つおよび3つのCPMVDが、4−パラメータおよび6−パラメータアフィン動きモデルに対してそれぞれシグナリングされる。
また、本発明の一実施例において、パターンマッチングされた動きベクトル加工(pattern-matched motion vector refinement)が使用され得る。JEMのパターンマッチングされた動きベクトル導出(JEMのエンコーダの説明で、名付けてPMMVD、以下PMVDと略称)において、デコーダは、CUレベルの探索のために開始のMV候補を決定するために、いくつかの動きベクトル(Motion Vector、MV)を評価する必要がある。サブCUレベルの探索で、最適なCUレベルのMVに加えて、いくつかのMV候補が追加される。デコーダは、最適なMVを探索するために、このようなMV候補を評価する必要があり、これは、多くのメモリ帯域を要求する。提案されたパターンマッチング(キャッチング)された動きベクトル精製(Pattern-Matched Motion Vector Refinement、PMVR)で、JEMでPMVDにおけるテンプレートマッチング(template matching)および両方向マッチング(bilateral matching)のコンセプトが採択される。PMVRが使用可能か否かを指示するために、スキップモードまたはマージモードが選択された際、1つのPMVR_flagがシグナリングされる。PMVDと比較し、意味あるようにメモリ帯域幅の要求を減少させるために、MV候補リストが生成され、PMVRが適用されると、開始のMV候補のインデックスが明示的にシグナリングされる。
マージ候補リストの生成プロセスを使用することによって候補リストが生成されるが、サブCUマージ候補、例えば、アフィン候補およびATMVP候補は除外される。両方向マッチング(bilateral matching)のために、ただ単方向予測(uni-prediction)MV候補のみが含まれる。両方向予測(bi-prediction)MV候補は、2つの単方向予測MV候補に分割される。また、(MVの差が予め定義された閾(臨界)値より少ない)類似のMV候補がやはり除去される。CUレベルの探索のために、ダイヤモンド探索MV精製(diamond search MV refinement)がシグナリングされたMV候補から始めて行われる。
サブCUレベルの探索は、ただ両方向マッチングマージモード(bilateral matching merge mode)でのみ使用可能である。全てのサブCUに対するサブCUレベルの探索の探索ウィンドウは、CUレベルの探索の探索ウィンドウと同一である。したがって、更なる帯域幅がサブCUレベルの探索において要求されない。
モードでMVPを精製するために、テンプレートマッチングも使用される。AMVPモードで、2つのMVPがHEVC MVP生成プロセスを使用することによって生成され、1つのMVPインデックスがそれらのうちの1つを選択するためにシグナリングされる。選択されたMVPは、PMVRでテンプレートマッチングを使用することによってさらに精製される。適応的動きベクトル解像度(Adaptive Motion Vector Resolution、AMVR)が適用されると、テンプレートマッチングの精製以前に、MVPは、該当する精度で丸められる(rounded)。このような精製過程は、パターンマッチングされた動きベクトル予測子精製(Pattern-Matched Motion Vector Predictor Refinement、PMVPR)と名付けられる。本文書の残りで特に定義しなければ、PMVRは、テンプレートマッチングPMVR、両方向マッチングPMVR、およびPMVPRを含む。
メモリ帯域幅の要求を減少させるために、PMVRは、4x4、4x8、および8x4のCUに対して使用できなくなる。更なるメモリ帯域幅の要求量の減少のために、64と同一のCU領域に対する{テンプレートマッチング、両方向マッチング}の探索範囲が{±2,±4}と縮小し得、64より大きいCU領域に対する{テンプレートマッチング、両方向マッチング}の探索範囲が{±6,±8}と縮小し得る。本文書のPMVRセクションで説明された前述した全ての方法を使用することによって、HEVCにおける最悪の場合に比べて、要求されるメモリ帯域幅がJEM−7.0のPMVDで45.9xからPMVRで3.1xと減少した。
HMVP(History-based Motion Vector Prediction)一般
一般に、映像圧縮技術は、2つの主要な技法として空間的および時間的冗長(重複)性(redundancy)に対する探索(exploiting)を用いる。例えば、HEVC(High Efficiency Video Coding、HEVC)およびVVCは、いずれもインターコーディング(inter coding)に基づいて(の基底で)2つの動き圧縮技法を使用する。1つは、マージ(merge)動きであり、もう1つは、AMVP(Advanced Motion Vector Prediction)である。このような2つの予測モードに対する改善のために、様々な変更(modifications)が議論されている。これらは、候補の数を増加させることから始めて、より空間的に拡張される候補に対する探索、および非慣習的な(non-traditional)位置における時間的候補を検査することなどを含む。このような2つの技法は、一次的に可能な候補でリストを構成し、RD(Rate Distortion)コストを最小にし、ビットストリームで選択された候補をシグナリングする。
特に、最近の映像圧縮技術では、以前にコーディングされたブロックの動き情報を記憶し、記憶された動き情報を以降でコーディングされるブロックの動き予測に用いるHMVP(History-based Motion Vector Prediction)が議論される。このようなHMVPは、マージリスト(または、マージ候補リスト)またはAMVPリスト(またはAMVP候補リスト)に追加され得る。
デコーダは、HMVPのためにFIFO(First In First Out)システム(または方式)で動作するLUT(Look-Up Table)を維持する。本明細書において、LUTは、その名称に制限されず、テーブル、HMVPテーブル、HMVP候補テーブル、バッファ、HMVPバッファ、HMVP候補バッファ、HMVPリスト、HMVP候補リストなどと称される。具体的には、非アフィン(non-affine)PU(Prediction Unit)(または、CU(Coding Unit))がデコードされる際、その動き情報は、LUTに記憶され、デコーダは、次のPUに対するデコーディングを進める。この際、記憶される動き情報は、x(水平)およびy(垂直)方向の動きベクトル、参照インデックス情報、ならびにモード情報などを含み得る。
デコーダは、漸進的に(progressively)デコードされた非アフィン候補の動き情報が記憶されるLUTを維持することができる。LUTのサイズは、予め定義されたS個の候補に制限され得る。一実施例として、LUTは、スライスの開始、CTU行の開始、またはCTUの開始でリセット(reset)され得る。
HMVPは、マージモードおよびAMVPモードでいずれも適用され得る。マージリストは、B個の候補を有し得、AMVPリストは、2つの候補を有し得る。従来の映像圧縮技術で、マージリストは、次の候補で構成される:i)空間候補、ii)時間候補、iii)両方向予測(Bi−Pred)候補、iv)ゼロ動き候補(zero motion candidate)。最近、ATMVP(Advanced Motion Vector Prediction)がさらに候補として考慮される方法が議論される。一例として、ATMVP候補は、時間候補以前にマージリストに挿入され得る。マージリストの候補は、最大のマージリストのサイズに到達するまでマージリストに追加される。重複候補(duplicate candidate)は、マージリストに追加されなくてもよい。AMVPリストは、2つの候補が挿入され得る。一例として、2つの候補のうちの1つは、使用可能な空間候補から選択され、2番目の候補は、時間候補から選択され得、リストが満たされない場合、ゼロ動きベクトル候補が追加され得る。
HMVPは、LUTで候補が投入された順序と同じようにテーブルから取り出される(抜け出す)FIFOベースで適用される。
一実施例において、HMVPがマージリストの構成に適用される際、HMVP候補は、下記のようにリストの3番目の位置に挿入(または追加)され得る。
1.空間候補(Spatial Candidate)
2.時間候補(Temporal Candidate)
3.LUTに対する最大S個のHMVP候補(Up to S HMVP Candidates for a LUT)
4.結合された両方向予測候補(Combined Bi-Pred Candidate)
5.ゼロ動きベクトル候補(Zero Motion Vector Candidate)
一実施例において、HMVPがAMVPリストの構成に適用される際、HMVPは、下記のように時間候補以降、3番目の位置に挿入され得る。
1.空間的候補(Spatial Candidate)
2.時間的候補(Temporal Candidate)
3.最大K個のHMVP候補(Up to K HMVP Candidates)
4.ゼロ動きベクトル候補(Zero Motion Vector Candidate)
図27は、本明細書の実施例にかかるHMVPを記憶する方法を説明するフローチャートである。
図27を参照すると、デコーダは、現PU(またはCU)をデコードする(S2701)。
デコーダは、現PUが非アフィンモードでコーディングされたブロックであるかを確認する(S2702)。HMVP候補の使用を容易にするために、現PUがアフィンモードでコーディングされたブロックである場合、デコーダは、現PUの動き情報をテーブルに記憶しない。
現PUが非アフィンモードでコーディングされたブロックである場合、デコーダは、現PUの動き情報をテーブルに記憶(またはアップデート)する(S2703)。
本明細書の実施例において、HMVPテーブルは、2つの方法、すなわち、i)非制限的FIFO(unconstrained FIFO)、ii)制限的FIFO(constraint FIFO)方法でアップデートされ得る。前者において、重複する動き情報が存在し得るが、淘汰プロセスは適用されない。これは、全般的なプロセスの複雑度を低減させるのに寄与する。一方、後者において、淘汰プロセスが適用され、HMVPテーブル内の重複する動き情報は存在しない。下記の図を参照して説明する。
図28は、本明細書の実施例にかかる非制限的FIFO方式で動作するHMVPテーブルを説明する図である。
図28を参照すると、テーブルに追加される候補は、テーブルの終端(右側)に追加される。反面、FIFO方式によってテーブルで排出される候補は、テーブルの前端(左側、最も古い候補)に位置する。
インデックスL−1(すなわち、終端)において、テーブルが予め定義された最大数の候補で完全に満たされなければ、除去される候補なく、新しい候補が追加される。反面、テーブルが既に完全に満たされた場合、すなわち、テーブルの最大数を満たす場合、テーブルで最も古い前端に位置する候補が除去され、新しい候補が追加される。
図29は、本明細書の実施例にかかる制限的FIFO方式で動作するHMVPテーブルを説明する図である。
図29を参照すると、制限的FIFOが使用される場合、新しい候補を追加することが重複を引き起こす場合(すなわち、新しい候補が重複する動き情報を有する場合)淘汰が行われる。実施例として、重複する動き情報を有する候補がテーブルに存在すると、テーブル内の重複する候補は除去され、現在の候補の動き情報が追加され得る。
HMVP候補に対して、多くの場合で最も最近の履歴MVが空間候補(または空間隣接候補)の動き情報と重複し得る。したがって、本実施例では、HMVP候補をAMVPまたはマージリストに追加する際、候補の追加順序をHMVP LUTインデックスの順序と異なって設定する方法を提案する。
本明細書の実施例によれば、HMVP候補を適応的に調節することによって、候補リストを効率的に構成でき、これを介して、二値化(binarization)に使用されるシグナリングビンの数を減少させ、コーディング効率を高めることができる。すなわち、マージリストまたはAMVPリストに追加されるHMVP候補は、HMVPリスト内のインデックスにより制限されないことがある。一実施例として、次の表1は、AMVPまたはマージリストにHMVP候補を追加する順序を変更する方法を例示する。
表1を参照すると、前述したように、最も最近に挿入されたHMVP候補は、空間候補の動き情報と同一である可能性が高いため、これを考慮し、HMVP候補の追加順序をHMVPインデックスと関係なく予め定義し得る。
また、一実施例において、エンコーダ/デコーダは、HMVPリスト内でn番目の候補から始まるHMVP候補からマージリストまたはAMVPリストに追加し得る。次の表2は、AMVPまたはマージリストに候補を追加する変更された順序を例示する。
表2を参照すると、HMVP候補は、2番目のインデックスからマージリストまたはAMVPリストに追加され得る。
一実施例において、テーブル(LUT)内におけるHMVP候補の追加順序に関する情報は、エンコーダからデコーダにシグナリングされ得る。例えば、このような順序の情報は、上位レベルのシンタックス(High Level Syntax、HLS)を介して送信され得る。上記上位レベルのシンタックスは、例えば、シーケンスパラメータセット(sequence parameter set)、ピクチャパラメータセット(picture parameter set)、スライスヘッダ(slice header)、コーディングツリーユニット(coding tree unit)、コーディングユニット(coding unit)および/または他の適切なシンタックスデータヘッダであり得る。
下記の表3は、本明細書で提案する方法が適用され得る上位レベルのシンタックス構造を例示する。
表3を参照すると、set_HMVP_order_flagが1であることは、set_HMVP_order_flagがCVSで非IDR(non-IDR)ピクチャ内のスライスヘッダで存在することを指示する。set_HMVP_order_flagが0であることは、set_HMVP_order_flagがスライスヘッダで存在せず、VCSで適応的HMVPが使用されないことを指示する。
下記の表4は、本明細書で提案する方法が適用され得るスライスセグメントヘッダシンタックス構造を例示する。
表4を参照すると、slice_HMVP_idxは、使用される候補の順序に対するインデックスを意味する。例えば、slice_HMVP_idxが0であることは、0、1、2、3などの基本HMVPの順序を表現し得る。同様に、1のインデックス値は、3、2、1、0のHMVP順序を表現するために使用され得る。
また、本明細書の一実施例において、HMVP LUTに加えて、ロングタームリスト(long term list)を動き予測のために使用する方法を提案する。これを介して、維持されるHMVP候補の数を増加させ得る。実施例として、2−HMVPテーブルを考慮し得、ここで、1つは、一般HMVP候補を保管し、もう1つは、維持がさらに必要な候補をさらに保管するロングターム(long term)リストに使用できる。
次は、ロングタームリスト(または、ロングタームHMVPリスト)を初期化して構成する方法を例示する。
− CTU行の1番目のCTUをデコードした後、以降のCTUの1つまたは複数の履歴MVがロングタームHMVP LUTに追加され得る。このようなロングタームHMVP LUTは、次のCTU行まで使用されるか、アップデートされないことがある。
− 次のCTU行の開始で、ロングタームHMVP LUTが、通常のHMVP LUTを初期化するために使用され得る。その理由は、CTU行の開始でCTUのHMVP候補が以前のCTU行の端における履歴MVよりさらに互いに関連(co-relate)し得るためである。
− 前述したプロセスは、繰り返され得る。
図30は、本明細書の実施例にかかるHMVP LUT、およびロングタームHMVP LUTを例示する図である。
図30を参照すると、エンコーダ/デコーダは、HMVP候補を記憶するための2つのLUTを含み得る。このうちの1つは、HMVP LUT(または、一般HMVP LUT、ショートタームHMVP LUT)であり、もう1つは、ロングタームHMVP LUTであり得る。HMVP候補は、マージまたはAMVPリストに全て追加される際、図30に示すように、HMVP LUTまたはロングタームLUTから追加され得る。
前述したロングタームLUTの使用は、新しいシンタックスエレメントを用いてシグナリングされ得る。実施例として、上記シンタックスエレメントは、上位レベルのシンタックスを介してシグナリングされ得る。例えば、シンタックスエレメントは、シーケンスパラメータセット(sequence parameter set)、ピクチャパラメータセット(picture parameter set)、スライスヘッダ(slice header)、コーディングツリーユニット(coding tree unit)、コーディングユニット(coding unit)および/または他のシンタックスデータヘッダに存在し得る。
また、本明細書の一実施例において、HMVP候補をHMVP LUTに追加するにあたって、デコーディングのための柔軟性(flexibility)を考慮する方法を提案する。エンコーダ/デコーダは、HMVP候補をテーブルに追加するにあたって、PU(またはCU)の1つまたは複数の特性に対する決定(decision)の基準を考慮し得る。
実施例として、エンコーダ/デコーダは、HMVP候補をテーブルに追加するにあたって、次のような事項を考慮し得る。エンコーダ/デコーダは、PUのモード(例えば、マージモード、アフィンモード、AMVPモードなど)および/またはブロックのサイズなどの特性を、個別にまたは組み合わせて考慮して候補として追加し得る。一実施例において、これ以外に他の更なる特性が考慮されることもある。例えば、HMVP LUTのアップデートを考慮するマージタイプ(例えば、空間候補または時間候補)、サブPUであるか否かなどが、候補の選択基準として考慮され得る。前述した選択基準は、以前の履歴(または、以前のHMVP)との重複を減少させるために決定され得る。例えば、PUがマージモードでコーディングされ、マージタイプが空間マージである場合、デコーダは、該当PUの動き情報でHMVP LUTをアップデートしなくてもよい。
図31は、本明細書の実施例にかかるHMVP LUTをアップデートする方法の一例を示す図である。
図31を参照すると、エンコーダ/デコーダは、コーディングされた候補の動き情報を獲得する(S3101)。
エンコーダ/デコーダは、上記候補の動き情報でLUTをアップデートするか否かを予め定義された決定の基準によって評価する(S3102)。前述したように、上記決定の基準は、上記候補のモード(例えば、マージモード、アフィンモード、AMVPモードなど)、上記候補のブロックサイズおよび/または上記候補のマージタイプの少なくとも1つに関する特性を含み得る。
エンコーダ/デコーダは、上記決定の基準に基づいてLUTをアップデートする(S4303)。すなわち、上記候補が予め定義された決定の基準を満たす場合、エンコーダ/デコーダは、上記候補の動き情報をLUTに追加し得る。
また、本明細書の一実施例において、HMVP候補をマージリスト(またはAMVPリスト)に追加するための冗長性チェックに対する制限を提案する。冗長性チェックに対する制限は、様々な方法で定義(または実現)され得る。
一実施例において、エンコーダ/デコーダは、マージリスト内の最初の特定数の候補に対する淘汰チェックの数を制限し得る。実施例として、エンコーダ/デコーダは、マージリストの1番目の候補から特定数番目の候補までの候補に対する淘汰チェックの数を制限し得る。例えば、エンコーダ/デコーダは、マージリストの1番目の候補から特定数番目の候補までの候補に対する淘汰プロセスを行うことができる。また、淘汰チェックの対象になるHMVP候補は、予め定義された数に制限され得る。
また、一実施例において、エンコーダ/デコーダは、淘汰チェックをマージリスト内のマージ候補の特定タイプに対して行うことによって、淘汰チェックを制限し得る。例えば、エンコーダ/デコーダは、HMVP候補を追加するにあたって、マージリストの空間候補に対してのみ淘汰チェックを行うことができる。あるいは、例えば、エンコーダ/デコーダは、HMVP候補を追加するにあたって、マージリストの空間候補の一部に対してのみ淘汰チェックを行うことができる。上記空間候補の一部は、予め定義され得る。例えば、上記予め定義される空間候補の一部は、左側の隣接空間候補および/または上側の隣接空間候補の少なくとも1つであってもよい。あるいは、例えば、エンコーダ/デコーダは、HMVP候補を追加するにあたって、マージリストの空間候補の一部に対してのみ淘汰チェックを行うことができ、上記空間候補の一部は、左側および上側に予め定義され得る。前述した例により、本明細書の実施例がこれに制限されるわけではなく、様々なタイプのマージ候補が組み合わされ、淘汰チェックの対象に制限され得る。
図32は、本明細書の実施例にかかる淘汰チェックの対象になるHMVP候補の数を制限する方法を例示する図である。
図32を参照すると、本明細書の一実施例において、淘汰チェックの対象になるHMVP候補の数は、M個に制限され得る。エンコーダ/デコーダは、HMVP候補を用いてマージリストを構成するにあたって、HMVP LUT内のM個の候補と上記マージリストのマージ候補との間の動き情報の冗長性をチェックすることができる。
あるいは、エンコーダ/デコーダは、現在デコードされた処理ブロック(例えば、PU)の動き情報をHMVP LUTに追加するにあたって、HMVP LUT内のM個の候補と上記デコードされたPUとの動き情報の間の冗長性をチェックできる。
図33は、本明細書の実施例にかかる淘汰チェックの実行方法の一例を示すフローチャートである。
図33を参照すると、エンコーダ/デコーダは、デコードされた候補の動き情報を獲得し、淘汰チェックの数を決定(またはデコード(復号(解読)))する(S3301、S3302)。上記淘汰チェックの数は、上記で説明した(例えば、図32で説明した)方法によって、エンコーダ/デコーダにおいて予め定義され得る。エンコーダ/デコーダは、決定された淘汰チェックの数に基づいて、淘汰チェックを行う(S4503)。
一実施例において、上記表3および表4と同様の方法で、淘汰チェックに関する情報は、上位レベルのシンタックスを介してシグナリングされ得る。この際、エンコーダからデコーダへ送信されるシンタックスエレメントは、淘汰チェックの数を指示するために、特定の上位レベルのシンタックスを介してシグナリングされ得る。上記上位レベルのシンタックスは、例えば、シーケンスパラメータセット(sequence parameter set)、ピクチャパラメータセット(picture parameter set)、スライスヘッダ(slice header)、コーディングツリーユニット(coding tree unit)、コーディングユニット(coding unit)および/または他のシンタックスデータヘッダに含まれ得る。
本明細書の一実施例において、HMVP候補を選択する効率的な方法を提案する。履歴動きベクトル候補(すなわち、HMVP候補)をマージリスト(またはAMVPリスト)に挿入する際、HMVP候補は、既存のマージリストと重複しないようにするために、淘汰チェックが行われ得る。この際、Mの大きさのマージリストとNの大きさの履歴LUTとの間の全体の冗長性チェックを行うためには、(M−1)xN回のチェックを必要とする。
したがって、本明細書の実施例において、HMVP候補の数は、マージ候補に依存し得る。例えば、HMVP候補の数は、マージリストに存在する空間候補の数に依存し得る。あるいは、例えば、HMVP候補の数は、マージリストに存在する空間候補および時間候補の数に依存し得る。
マージリストに存在するマージ候補がさらに存在する場合、マージリストのマージ候補の数および/またはHMVPの数に基づく特定の基準(または規則)に従って、淘汰チェックを行うHMVP候補の数が減少し得る。これを通じて、最悪のケースにおける冗長性チェックの数が減ることがある。
例えば、大きさ(または長さ)が6であるマージリストの場合、マージリストが満たされなければ、マージリストは、最大5個の空間または他のマージ候補を含み得る。6個のHMVPリストでHMVP候補を挿入するためには、最悪の場合、30個の冗長性チェックが必要であるかもしれない。
一実施例において、淘汰チェックの対象になるHMVPの数に対する制限に関する例は、次の数式17および表5の通りである。
<数式17>
if (existing_candidates >= 3)
number_hist_to_check = 7 - existing_candidates
表5を参照すると、淘汰チェックの対象になるHMVPの数を2つに制限することによって、最悪のケースで、HMVPの追加のための冗長性チェックの数は、30回の代わりに12回と減少し得る。
本明細書の一実施例において、履歴ベース空間時間動きベクトル予測(History-Based Spatial Temporal Motion Vector Prediction、H−STMVP)を使用してマージリストを構成する方法を提案する。H−STMVPは、2つの履歴ベース空間MVPおよびTMVPの平均として導出される候補を表す。上記2つの空間HMVPは、HMVPバッファから獲得され得、上記TMVPは、現在のマージリストから獲得され得る。ここで、上記空間候補は、現ブロックの以前のデコーディング順序で最後の2つのコーディングされたMVから獲得された候補であり得る。
例えば、最後にコーディングされたMV(本明細書でMV_Lと称する)、最後から2番目にコーディングされたMV(本明細書でMV_(L−1)と称する)、およびMV_TMVPは、マージリストに挿入されるH−STMVP候補を生成するのに使用され得る。
前述した3つの候補を全て使用できる場合、マージリストに追加されるMVは、次の数式18により計算され得る。
一実施例として、前述した3つの候補のうちの2つのみが利用可能であれば、2つの候補に対してのみ平均化され、H−STMVPが生成され得る。同様に、1つの候補のみ使用可能であれば、上記1つの候補のみ使用され得る。使用可能な候補がない場合、H−STMVPは、マージリストの構成に使用されなくてもよい。
本明細書の一実施例において、前述した数式18以外に他の方法を利用し、H−STMVP候補の動きベクトルを獲得する方法を提案する。
例えば、3つ以上の候補を一度に平均化する代わりに、空間候補を先に平均化した後、この結果を使用して2つの候補を再度平均化することが計算的にさらに簡単であるかもしれない。これに関する例は、次の数式の通りである。
あるいは、次のように平均値を獲得することもできる。
エンコーダ/デコーダは、数式19乃至21のように、まず、2つの候補を平均し、3番目の候補を用いて結果値を最終的に平均化できる。あるいは、エンコーダ/デコーダは、数式22のように、2だけシフト演算を適用することによって、候補、すなわち、MV_Lにさらに高い重要度/重みを付与し得る。前述した数式19乃至22を使用し、シフト演算だけで割り算の演算なしで平均値を導出し得る。
本明細書の一実施例において、H−STMVPを導出するにあたって、2つの履歴ベース空間候補の代わりに、任意の数(n)の空間候補を使用する方法を提案する。これらのn個の候補は、必ずしも連続するデコーディング順序である必要はない。任意に、または一部の規則に従って選択できる。
したがって、上記で説明した数式18は、次の数式23のようにより一般的な方式で表現され得る。
別の一実施例において、5つの空間候補を使用する場合を仮定すると、時間候補に適用される重みを向上させることによって、H−STMVP候補を生成するために増加した空間候補の影響を最小にし、空間候補および時間候補を適切に反映することができる。
したがって、このために次の数式24を用いて空間候補を共に平均した後、その結果を使用してMV_TMVPを平均化することによって、前述した目的を達成することができる。
本明細書の一実施例において、H−STMVPを導出するために用いられる動きベクトル候補に重み(加重値)(または加重因子)を追加する方法を提案する。この際、上記重みは、経験的に決定されることもあり、固定された参照フレームまでの時間距離を考慮して決定されることもあり、または履歴テーブルにおける位置を考慮することによって決定されることもある。一例として、新しい候補は、以前の候補よりさらに多くの重みを有し得る。
すなわち、例において、本実施例において、上記で説明した数式18は、次の数式25のように表現され得る。
この際、重みは、同じ値を有してもよく、不均等に分散された値を有してもよい。
本明細書の一実施例において、H−STMVP候補を導出するために使用される動きベクトルを単一参照ピクチャとしてスケーリングする方法を提案する。
図34は、本明細書の一実施例にかかる互いに異なる参照ピクチャを参照する動きベクトルを用いて、H−STMVP候補を導出する方法を説明する図である。
図34を参照すると、MV_L、MV_L−1、およびMV_TMVP候補は、それぞれ互いに異なる参照ピクチャを参照(または指示)する場合を仮定する。すなわち、図34は、H−STMVP候補を生成するのに使用された各候補が異なる参照インデックスを有し得、結果として、異なる参照フレームを有し得ることを示す。
近接の参照フレームのあるフレームが、本質的にH−STMVPの動きベクトルにさらに大きな影響を与え得るので、前述した数式18乃至25の平均を不均等な結果値にし得る。したがって、均等な比較および反映のために、全ての動きベクトルを単一参照フレームにスケーリングする方法を提案する。
この際、エンコーダでRDの最適化の一部として行われ、どの単一フレームが参照フレームに使用するのに最適であるかを決定し得る(エンコーダは、RDの最適化の一部として行われたどの単一フレームが、参照フレームとして使用するのに最適であるかを決定し得る(the encoder may determine which single frame performed as part of RD optimization is most suitable for being used as a reference frame))。実施例として、選択された参照フレームは、スライスヘッダに存在するTMVP配列インデックスと類似のスライスヘッダでシグナリングされ得る。例えば、固定された規則を使用し、使用される参照フレームを生成することが可能である。あるいは、例えば、L0から1番目に利用可能な参照(基準)フレームにスケーリングされるか、現ピクチャの順序のカウントに基づいてスケーリングされ得る。
一実施例において、前述した目的を達成するために、シーケンスパラメータセット、ピクチャパラメータセット、スライスヘッダ、コーディングツリーユニットおよび/または他のデータヘッダの一部であり得る上位レベルのシンタックス(HLS)を用いて、単一の固定されたピクチャに関する情報を、エンコーダがデコーダへ送信し得る。例えば、次の表6および/または表7のような上位レベルのシンタックス構造が定義され得る。
表6を参照すると、set_HSTMVP_ref_pic_flagが1と同一である場合、set_HSTMVP_idxがCVSで非IDRピクチャのスライスヘッダに存在することを示す。set_HSTMVP_ref_pic_flagが0である場合、set_HSTMVP_idxがスライスヘッダに存在しないことを示す。
表7を参照すると、slice_HMVP_idxは、参照インデックスを指定する。一実施例として、参照インデックスは、リストL0に対して選択され得る。
本明細書の実施例において、上記で説明した実施例に関して、より詳細な実施例を説明する。具体的には、現ブロックのCPMVを計算(または導出)するために、位置および次元情報を使用してアフィンHMVP候補を間接的に使用する方法を提案する。本明細書において、導出されたCPMVは、継承されたアフィンHMVP候補と称され得る。本明細書の実施例にかかる継承されたアフィンHMVP候補は、前述したアフィンマージリストおよび/またはアフィンAMVPリストの生成プロセスで使用され得る。
図35は、本明細書の実施例にかかる継承されたアフィンHMVP候補を導出するためのブロックの位置を例示する図である。
図35を参照すると、アフィンHMVP候補の位置および次元に基づいて、現ブロック3501のCPMVは、一般的な継承されたCPMVを周辺ブロックから導出する方法と類似の方法で導出され得る。すなわち、エンコーダ/デコーダは、アフィンHMVP候補である参照ブロック3502の位置および次元(例えば、幅および高さ)の情報に基づいて、現ブロック3501の制御点の動きベクトルを導出し得る。
一実施例として、現ブロックの継承されたアフィンHMVPのCPMVは、次の数式26および27を用いて導出され得る。
<数式26>
V0x = VB0x + (VB2_x - VB0x ) * ( posCurCU_Y - posRefCU_Y ) / RefCU_height
+ (VB1x - VB0x ) * (posCurCU_X - posRefCU_X) / RefCU_width
<数式27>
V0y = VB0y + (VB2_y - VB0y ) * (posCurCU_Y - posRefCU_Y) / RefCU_height
+ (VB1y - VB0y ) * (posCurCU_X - posRefCU_X) / RefCU_width
数式26および27で、posCurCU_Yは、現ブロック3501の左上段のサンプルの垂直方向の座標値を表し、posRefCU_Yは、参照ブロック3502の左上段のサンプルの垂直方向の座標値を表す。posCurCU_Xは、現ブロック3501の左上段のサンプルの水平方向の座標値を表し、posRefCU_Xは、参照ブロック3502の左上段のサンプルの水平方向の座標値を表す。RefCU_heightは、参照ブロック3502の高さを表し、RefCU_widthは、参照ブロック3502の幅を表す。
本明細書の一実施例において、アフィンHMVP候補(直接または継承されたHMVP)を追加する際、アフィンマージまたはアフィンAMVPリストの生成に使用され得るアフィンHMVP候補を選択するように制限事項が追加され得る。
一例として、アフィンHMVP候補は、上記アフィンHMVP候補が現ブロックに隣接する場合にのみ、アフィンマージまたはアフィンAMVPリストに追加され得る。
別の一例として、アフィンHMVP候補は、上記アフィンHMVP候補が現ブロックから特定の距離内に位置(または存在)する場合にのみ、アフィンマージまたはアフィンAMVPリストに追加され得る。例えば、上記特定の距離は、予め定義されたピクセル距離であり得る。エンコーダ/デコーダは、アフィンHMVP候補が利用可能であるかを判断するために、上記アフィンHMVP候補が予め定義された特定の距離内に位置するか否かを判断(または決定)できる。
別の一例として、アフィンHMVP候補は、現ブロックを基準に特定の位置に位置(または存在)する場合にのみ、アフィンマージまたはアフィンAMVPリストに追加され得る。例えば、上記特定の位置に存在する場合は、上記アフィンHMVP候補が現ブロックの左側または上側の隣接ブロックの場合であり得る。
N個のエレメントを有するアフィンHMVP LUTに対して、全てのエレメントまたは最初のM個のエレメントに対する前述した確認プロセスが、マージもしくはAMVPリストが満たされるまで、または予め定義された特定のHMVP候補の数に到達するまで、行われ得る。
本明細書の一実施例において、アフィンHMVP候補は、アフィンマージリストおよび/またはアフィンAMVPリストにおける既に存在する継承されたアフィン候補を代替するのに使用する方法を提案する。
図36は、本明細書の実施例にかかるアフィンマージリストまたはアフィンAMVPリストを例示する図である。
図36を参照すると、エンコーダ/デコーダは、既存のアフィンマージリストまたはアフィンAMVPリストに存在する継承された候補を継承されたアフィンHMVP候補で代替することができる。すなわち、エンコーダ/デコーダは、現ブロックにサブブロックベースのマージモードが適用される場合、継承されたアフィン候補、および構成されたアフィン候補を用いてサブブロックベースのマージ候補リストを生成し、継承されたアフィンHMVP候補を導出し、上記サブブロックベースのマージ候補リストに含まれる少なくとも1つの継承されたアフィン候補を継承されたアフィンHMVP候補で代替することができる。
また、本発明の一実施例において、アフィンHMVPのルックアップテーブル(LUT)は、スライス、CTU行(row)、またはCTUの開始で初期化され得る。これを介して、並列処理の遂行性を向上させることができる。
以下、後述する実施例では、HMVPからの最悪の淘汰チェック(pruning check)の数を減少させるための方法を提案する。
本明細書の実施例において、HMVP候補がマージリストに追加される場合、淘汰チェックの数は、マージリスト内の利用可能な候補の数、およびマージリストに追加され得るHMVP候補の数に基づいて決定され得る。以下で、本明細書の実施例を説明するにあたって、説明の便宜のために下記のように変数を定義して説明する。
− NST:マージリスト内における利用可能な(または存在する)候補の数
− NHMVP:テーブル内におけるHMVP候補の数(すなわち、HMVPテーブルの大きさ)
− NmrgToBeAdded:マージリストに追加されるHMVP候補の数
− NHMVPChecked:淘汰チェックされるHMVP候補の数
− Nmax_hmvp_prunning:HMVP候補をマージリストに追加するために要求される最悪の場合の淘汰チェックの数
本明細書の一実施例において、HMVP候補は、次の条件によってマージリストに追加され得る。
− 第1の条件:LUTは、以前に淘汰されている場合(すなわち、HMVP LUT内の候補間で同一のmvはない場合)
− 第2の条件:HMVP LUTテーブルの大きさが6である場合
− 第3の条件:HMVP候補をマージリストに追加するために利用可能な(または存在する)マージ候補の最大の数が4である場合。すなわち、最大のマージリストの大きさ(または最大のマージ候補)から1を減算した値よりもマージリスト内のマージ候補の数が小さい場合。例えば、最大のマージリストの大きさは6であってもよく、現在利用可能なマージ候補の数が5より小さい場合、HMVP候補を追加(または挿入)し得る。言い換えると、HMVP候補は、マージリストのインデックス5までのみ追加され得る。
HMVP候補がマージリストに追加されると(すなわち、マージ候補になると)、各HMVP候補は、マージ候補間の重複を除去するために淘汰チェックが必要なことがある。既存の映像圧縮技術によると、マージリストにHMVPを追加するために必要な最悪の(または最悪の場合の)淘汰チェックの数は、次の表8のように計算され得る。
表8を参照すると、既存の映像圧縮技術によると、HMVPテーブル(またはHMVPリスト、HMVP候補リスト)内の6つのHMVP候補に対して淘汰チェックが行われ得る。
具体的には、1)マージリスト内の候補が1つである場合、マージリストに追加されるHMVP候補は4つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は4であってもよい。2)マージリスト内の候補が2つである場合、マージリストに追加されるHMVP候補は3つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は7であってもよい。3)マージリスト内の候補が3つである場合、マージリストに追加されるHMVP候補は2つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は9であってもよい。4)マージリスト内の候補が4つである場合、マージリストに追加されるHMVP候補は1つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は10であってもよい。
本明細書の実施例において、上記で説明した最悪の淘汰チェックの数を減らすための方法を提案する。マージリストにマージ候補がより多く存在する場合、マージ候補(すなわち、非HMVP候補)が増加するのに伴って、HMVPのコーディングの影響が減少するため、淘汰チェックするHMVP候補の数が減少する必要があり得る。したがって、本明細書の実施例において、エンコーダ/デコーダは、最悪の淘汰チェックを減らすために、チェックされるHMVP候補の数(NHMVPChecked)を、追加される利用可能なHMVP候補の数(NmrgToBeAdded)と同じように設定され得る。この場合、最悪の淘汰チェックの数は、次の表9のように計算され得る。
表9を参照すると、従来の映像圧縮技術と比較した際、HMVPのための最悪の淘汰チェックの数は、10個から6つに減り得る。
表9を参照すると、一実施例において、1)マージリスト内の候補が1つである場合、マージリストに追加されるHMVP候補は4つであってもよい。また、4つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は4であってもよい。2)マージリスト内の候補が2つである場合、マージリストに追加されるHMVP候補は3つであってもよい。また、3つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は6であってもよい。3)マージリスト内の候補が3つである場合、マージリストに追加されるHMVP候補は2つであってもよい。また、2つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は6であってもよい。4)マージリスト内の候補が4つである場合、マージリストに追加されるHMVP候補は1つであってもよい。また、1つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は4であってもよい。
本明細書の実施例において、最悪の淘汰チェックを減らすために、エンコーダ/デコーダは、淘汰チェックされるHMVP候補の数(NHMVPChecked)を、追加される利用可能なHMVP候補の数(NmrgToBeAdded)とKとの和と同じ値に設定し得る。ここで、Kは、予め定義された定数値を表す。一例として、Kが1である場合、最悪の淘汰チェックの数は、次の表10のように計算され得る。
表10を参照すると、一実施例において、1)マージリスト内の候補が1つである場合、マージリストに追加されるHMVP候補は4つであってもよい。また、5つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は4であってもよい。2)マージリスト内の候補が2つである場合、マージリストに追加されるHMVP候補は3つであってもよい。また、4つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は7であってもよい。3)マージリスト内の候補が3つである場合、マージリストに追加されるHMVP候補は2つであってもよい。また、3つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は8であってもよい。4)マージリスト内の候補が4つである場合、マージリストに追加されるHMVP候補は1つであってもよい。また、2つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は7であってもよい。
本明細書の実施例において、最悪の場合、淘汰チェックを減少させるために、チェックされるHMVP候補の数(NHMVPChecked)は、次の数式28のように定義され得る。
数式28で、Cは、予め定義された定数値を表す。Cが2である場合、最悪の淘汰チェックの数は、次の表11のように計算され得る。
表11を参照すると、一実施例において、1)マージリスト内の候補が1つである場合、マージリストに追加されるHMVP候補は4つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は4であってもよい。2)マージリスト内の候補が2つである場合、マージリストに追加されるHMVP候補は3つであってもよい。また、6つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は7であってもよい。3)マージリスト内の候補が3つである場合、マージリストに追加されるHMVP候補は2つであってもよい。また、4つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は9であってもよい。4)マージリスト内の候補が4つである場合、マージリストに追加されるHMVP候補は、1つであってもよい。また、2つのHMVP候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は7であってもよい。
HMVPがマージリストおよび/またはAMVPリストの構成に追加される場合、マージリストおよび/またはAMVPリスト内に存在する候補との重複を避けるために、淘汰が再度行われる必要性がある。HMVP LUTが上記図29で説明したように、制限的FIFO動作により既に淘汰されている場合、HMVP候補をマージリストに挿入(または追加)する際、HMVP候補の間で比較(または淘汰チェック)は必要ではないかもしれない。これによって、上記図28で説明したような非制限的FIFOテーブルを使用する場合に比べて淘汰チェックの数は減ることができる。何故なら、HMVP候補間の淘汰チェックは、HMVP候補をマージリストに挿入する際に必要なためである。前述したように、本明細書において、HMVP LUTは、その名称に制限されず、LUT、テーブル、HMVPテーブル、HMVP候補テーブル、バッファ、HMVPバッファ、HMVP候補バッファ、HMVPリスト、HMVP候補リスト、HMVPマージ候補リスト、履歴ベースマージ候補リストなどと称される。
本明細書の一実施例において、マージリストおよび/またはAMVPリストの構成のためのHMVP候補の挿入プロセスを考慮したHMVPルックアップテーブル(LUT)の大きさを定義し得る。具体的には、HMVP候補は、予め定義されたマージリストの大きさまで追加され得る。例えば、最大のマージリストの大きさが6で定義された場合、HMVPは、6番目の候補にならなくてもよい。マージリストに5つのマージ候補が利用可能な(または存在する)場合、HMVP候補は追加されなくてもよい。この場合、6番目の候補は、HMVPを除いた候補(またはこれ以外の異なる方法)から選択され得る。したがって、前述したHMVP候補の挿入プロセスを考慮すると、本明細書の一実施例において、次のようなHMVP LUTの大きさの選択方法を提案する。
一実施例として、HMVP LUTテーブルの大きさは、(MaxNumMergeCand − K)と同じように定義(または設定)され得る。ここで、MaxNumMergeCandは、最大のマージ候補リスト(またはマージ候補リストの最大の数、最大のマージ候補の数)を表し、この際、MaxNumMergeCandは、6で定義され得る。Kは、予め定義された定数を表す。例えば、Kは1であってもよく、この際、HMVP LUTの大きさは5であってもよい。
本明細書の実施例によれば、HMVPをMaxNumMergeCand − K(前述したように、例えば、Kは1)に制限することによって、HMVPをマージリストおよび/またはHMVPテーブルに追加する際、最悪の(または最悪の場合の)淘汰チェックの数は減り得る(上記図29で説明した制限されたFIFO動作)。また、本発明の実施例によれば、HMVP LUTの記憶のためのメモリが減少し得る。
本明細書の実施例において、前述したHMVPテーブルの大きさを考慮し、HMVP動き候補を有するテーブルに対して、以下で説明する実施例のようなアップデートプロセスが適用され得る。以下の実施例は、HMVPテーブルのアップデートプロセスの一例であって、本明細書の実施例がこれに限定されるわけではない。
HMVPテーブルのアップデートプロセス
まず、HMVPテーブルのアップデートプロセスの入力は、次のように定義され得る。
− 動きベクトルmvL0およびmvL1
− 参照インデックスrefIdxL0およびrefIdxL1
− 予測リスト活用フラグのpredFlagL0およびpredFlagL1
本アップデートプロセスの出力は、HMVP候補リストの修正された配列であってもよい。本プロセスで、mvCandは、上記動きベクトル、上記参照インデックス、上記予測リスト活用フラグを有する動きベクトル候補を示す(指称する)変数を表す。
本アップデートプロセスは、次のような段階で行われ得る。
1.変数identicalCandExistは、偽(false)に設定され、変数tempIdxは、0に設定される。ここで、identicalCandExistは、HMVP候補リストに同一の動き情報が存在するかを表す変数であり、tempIdxは、HMVP候補リスト内で現在の動きベクトルと同一の動き情報を有するHMVP候補のインデックスを表す変数である。
2.HMVPCandNumが0より大きい場合、HMVPIdx=0..HMVPCandNum−1であるそれぞれのインデックスHMVPIdxに対して、identicalCandExistの変数が真(true)になるまで次の段階が適用され得る。ここで、HMVPCandNumは、HMVP候補リストのHMVP候補の数を表し、HMVPIdxは、HMVP候補リスト内のHMVP候補に割り当てられたインデックスを表す。
− mvCandがHMVPCandList[HMVPIdx](すなわち、HMVP候補リスト内のHMVPIdxを有するHMVP候補)と同一の動きベクトルおよび同一の参照インデックスを有する場合、identicalCandExistは真に設定され、tempIdxは、HMVPIdxに設定され得る。
3.また、HMVP候補リストは、次の段階によってアップデートされ得る。
(1)identicalCandExistが真であるか、またはHMVPCandNumがMaxNumMergeCand−Kである場合(と同一である場合)、以下の段階が適用され得る。ここで、MaxNumMergeCandは、マージリスト(またはマージ候補リスト)の大きさ(または、マージリストの最大候補の数、最大のマージ候補の数)を表す変数であり、Kは、任意の定数である。一実施例において、Kは、予め定義され得る。また、一実施例において、Kは1に設定され得、MaxNumMergeCand値が6に定義されることによって、MaxNumMergeCand−Kは、5であってもよい。また、一実施例において、MaxNumMergeCand−Kは5に設定され得る。例えば、identicalCandExistが真であるか、またはHMVPCandNumが5である場合、以下の段階が適用され得る。
− idx=(tempIdx+1)..(HMVPCandNum−1)であるそれぞれのインデックスidxに対して、HMVPCandList[idx−1]は、HMVPCandList[idx]に設定され得る。すなわち、tempIdx以降のインデックスを有するHMVP候補のインデックスは、その値が1だけ減った値に設定され得る。
− HMVPCandList[HMVPCandNum−1]は、mvCandに設定され得る。
(2)そうでなければ(すなわち、identicalCandExistは偽であり、HMVPCandNumがMaxNumMergeCand−Kより小さい場合)、以下の段階が適用され得る。前述したように、一実施例において、MaxNumMergeCand−Kは、5に設定され得る。例えば、そうでなければ(すなわち、identicalCandExistは偽であり、HMVPCandNumが5より小さい場合)、以下の段階が適用され得る。
− HMVPCandList[HMVPCandNum++]は、mvCandに設定され得る。
一例として、本アップデートプロセスは、現在のスライスがPまたはBスライスである際に呼び出され得る。この際、変数HMVPCandNumは0に設定され、変数HMVPCandListは、MaxNumMergeCand−Kのエレメント配列で定義され得る。前述したように、一実施例において、MaxNumMergeCand−Kは5に設定され得る。例えば、この際、変数HMVPCandNumは0に設定され、変数HMVPCandListは、5のエレメント配列で定義され得る。
以下では、HMVPテーブルのアップデートプロセスの別の一例を説明する。
まず、本アップデートプロセスの入力は、次のように定義され得る。
− 動きベクトルmvL0およびmvL1
− 参照インデックスrefIdxL0およびrefIdxL1
− 予測リスト活用フラグpredFlagL0およびpredFlagL1
本アップデートプロセスの出力は、HMVP候補リストの修正された配列であってもよい。本プロセスで、mvCandは、上記動きベクトル、上記参照インデックス、上記予測リスト活用フラグを有する動きベクトル候補を示す変数を表す。
本アップデートプロセスは、次のような段階で行われ得る。
1.HMVPIdx=0..HMVPCandNum−1であるそれぞれのインデックスHMVPIdxに対して、変数sameCandが真(true)になるまで次の段階が順序通り適用され得る。ここで、sameCandは、HMVP候補リストに同一の動き情報が存在するかを表す変数である。
− mvCandがHMVPCandList[HMVPIdx]と同一の動きベクトルおよび同一の参照インデックスを有する場合、sameCandは真に設定される。
− そうでなければ、sameCandは、偽(false)に設定される。
− HMVPIdx++(すなわち、HMVPIdxは、1だけ増加する)
2.変数tempIdxは、HMVPCandNumに設定される。
3.sameCandが真であるか、またはHMVPCandNumがMaxNumMergeCand−Kである場合、tempIdx=(sameCand? HMVPIdx:1)..HMVPCandNum−1であるそれぞれのインデックスtempIdxに対して、HMVPCandList[tempIdx]は、HMVPCandList[tempIdx−1]に複写(または設定)される。Kは、任意の定数である。一実施例において、Kは、予め定義され得る。また、一実施例において、Kは1に設定され得、MaxNumMergeCand値が6として定義されることによって、MaxNumMergeCand−Kは5であってもよい。また、一実施例において、MaxNumMergeCand−Kは5に設定され得る。
4.mvCandは、HMVPCandList[tempIdx]に複写される。
5.HMVPCandNumがMaxNumMergeCand−Kより小さい場合、HMVPCandNumは1ずつ増加する。前述したように、一実施例において、MaxNumMergeCand−Kは5に設定され得る。
以上で説明した本明細書の実施例は、説明の便宜上、それぞれの実施例を区分して説明したが、本発明がこれに制限されるわけではない。すなわち、上記で説明した実施例はそれぞれ独立して行われてもよく、1つまたは複数の様々な実施例が組み合わされて行われてもよい。
図37は、本発明が適用される実施例にかかる履歴ベース動きベクトル予測に基づいてビデオ信号を処理する方法を例示するフローチャートである。
図37を参照すると、説明の便宜のためにデコーダを中心に説明するが、本発明がこれに限定されるわけではなく、本明細書の実施例にかかる履歴ベース動きベクトル予測ベースのビデオ信号処理方法は、エンコーダとデコーダとで同様に行われ得る。
デコーダは、現ブロックの空間的(spatial)および時間的(temporal)隣接ブロックに基づいてマージ候補リスト(merge candidate list)を構成する(S3701)。
デコーダは、上記現ブロックの履歴ベースマージ候補(history based merge candidate)を上記マージ候補リストに追加する(S3702)。
デコーダは、上記マージ候補リスト内で上記現ブロックのインター予測に用いられるマージ候補を指示するマージインデックス(merge index)を獲得する(S3703)。
デコーダは、上記マージインデックスにより指示されるマージ候補の動き情報に基づいて、上記現ブロックの予測サンプルを生成する(S3704)。
デコーダは、上記動き情報に基づいて履歴ベースマージ候補リスト(history based merge candidate list)をアップデートする(S3705)。
前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれるマージ候補のうち、予め定義されたマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。
前述したように、実施例として、上記履歴ベースマージ候補リストは、上記マージ候補リストの最大のマージ候補の数に基づいて決定される大きさを有するように定義され得る。
前述したように、実施例として、上記履歴ベースマージ候補リストは、上記マージ候補リストの最大のマージ候補の数から1を減算した値の大きさを有するように定義され得る。
前述したように、実施例として、上記履歴ベースマージ候補リストの大きさは、5で定義され得る。
前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれるマージ候補のうち、予め定義された特定の数のマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。
前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれる特定の空間のマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。
前述したように、実施例として、上記履歴ベースマージ候補は、上記履歴ベースマージ候補リスト内で予め定義された特定の数の候補から導出され得る。
前述したように、実施例として、デコーダは、上記マージ候補リストが上記マージリストの最大数を満たしていない場合は、ゼロ動きベクトルを上記マージリストに追加し得る。
本発明で説明した実施例は、プロセッサ、マイクロプロセッサ、コントローラ、またはチップ上で実現されて行われ得る。例えば、各図で示す機能ユニットは、コンピュータ、プロセッサ、マイクロプロセッサ、コントローラまたはチップ上で実現されて行われ得る。
また、本発明が適用されるデコーダおよびエンコーダは、マルチメディア放送の送受信装置、モバイル通信端末、ホームシネマビデオ装置、デジタルシネマビデオ装置、監視用カメラ、ビデオ対話装置、ビデオ通信などのリアルタイムの通信装置、モバイルストリーミング装置、記憶媒体、カムコーダ、オーダメイドビデオ(VoD)サービス提供装置、OTTビデオ(Over the top video)装置、インターネットストリーミングサービス提供装置、3次元(3D)ビデオ装置、画像電話ビデオ装置、および医療用ビデオ装置などに含まれ得、ビデオ信号またはデータ信号を処理するために使用され得る。例えば、OTTビデオ(Over The Top video)装置としては、ゲームコンソール、ブルーレイプレーヤ、インターネット接続TV、ホームシアターシステム、スマートフォン、タブレットPC、DVR(Digital Video Recorder)などを含み得る。
また、本発明が適用される処理方法は、コンピュータで実行されるプログラムの形態で生産されることができ、コンピュータが読み取られる記録媒体に記憶され得る。本発明によるデータ構造を有するマルチメディアデータもまた、コンピュータが読み取られる記録媒体に記憶され得る。上記コンピュータが読み取られる記録媒体は、コンピュータで読み取られるデータが記憶される全ての種類の記憶装置および分散記憶装置を含む。上記コンピュータが読み取られる記録媒体は、例えば、ブルーレイディスク(BD)、ユニバーサルシリアル(汎用直列)バス(USB)、ROM、PROM、EPROM、EEPROM、RAM、CD−ROM、磁気テープ、フロッピ(登録商標)ディスク、および光学データ記憶装置を含み得る。また、上記コンピュータが読み取られる記録媒体は、搬送波(例えば、インターネットを介した送信)の形態で実現されたメディアを含む。また、エンコード方法で生成されたビットストリームが、コンピュータが読み取られる記録媒体に記憶されるか、有無線通信ネットワークを介して送信され得る。
また、本発明の実施例は、プログラムコードによるコンピュータプログラム製品で実現されることができ、上記プログラムコードは、本発明の実施例によってコンピュータで実行されることができる。上記プログラムコードは、コンピュータによって読み取り可能なキャリア上に記憶されることができる。
本明細書が適用されるデコード装置およびエンコード装置は、デジタル機器(digital de-vice)に含まれ得る。「デジタル機器(digital device)」とは、例えば、データ、コンテンツ、サービスなどを送信、受信、処理および出力の少なくとも1つを実行可能な全てのデジタル機器を含む。ここで、デジタル機器がデータ、コンテンツ、サービスなどを処理することは、データ、コンテンツ、サービスなどをエンコーディングおよび/またはデコードする動作を含む。このようなデジタル機器は、有/無線ネットワーク(wire/wireless network)を介して、他のデジタル機器、外部サーバ(external server)などとペアリングまたは接続(連結)(pairing or connecting)(以下「ペアリング」)されてデータを送受信し、必要に応じて変換(converting)する。
デジタル機器は、例えば、ネットワークTV(network TV)、HBBTV(Hybrid Broadcast Broadband TV)、スマートTV(Smart TV)、IPTV(Internet Protocol Television)、PC(Personal Computer)などの固定型機器(standing device)と、PDA(Personal Digital Assistant)、スマートフォン(Smart Phone)、タブレットPC(Tablet PC)、ラップトップなどのモバイル機器(mobile device or handheld device)と、をいずれも含む。本明細書では、便宜上、後述する図33ではデジタルTVを、図34ではモバイル機器をデジタル機器の実施例として示して説明する。
一方、本明細書で記述される「有/無線ネットワーク」とは、デジタル機器またはデジタル機器と外部サーバとの間で相互接続および/またはデータの送受信のために様々な通信規格またはプロトコルをサポート(支援)する通信ネットワークを通称する。このような有/無線ネットワークは、規格により、現在または今後サポートされる通信ネットワークとそのための通信プロトコルをいずれも含み得るので、例えば、USB(Universal Serial Bus)、CVBS(Composite Video Banking Sync)、コンポーネント、S−ビデオ(アナログ)、DVI(Digital Visual Interface)、HDMI(High Definition Multimedia Interface)(登録商標)、RGB、D−SUBなどの有線接続のための通信規格またはプロトコルと、ブルートゥース(Bluetooth)(登録商標)、RFID(Radio Frequency Identification)、赤外線通信(IrDA、infrared Data Association)、UWB(Ultra Wideband)、ジグビ(ZigBee)、DLNA(Digital Living Network Alliance)(登録商標)、WLAN(Wireless LAN)(Wi−Fi)、Wibro(Wireless broadband)、Wimax(World Interoperability for Microwave Access)、HSDPA(High Speed Down-link Packet Access)、LTE(Long Term Evolution)、Wi−Fiダイレクト(Direct)などの無線接続のための通信規格と、によって形成され得る。
以下、本明細書でただデジタル機器と名付ける場合には、コンテキストに応じて、固定型機器またはモバイル機器を意味するか、両者とも含む意味であってもよい。
一方、デジタル機器は、例えば、放送受信機能、コンピュータ機能(またはサポート)、少なくとも1つの外部入力(external input)をサポートするインテリジェント(知能型)機器であって、前述した有/無線ネットワークを介してEメール(e-mail)、ウェブブラウジング(web browsing)、バンキング(banking)、ゲーム(game)、アプリケーション(application)などをサポートできる。また、上記デジタル機器は、手動(手記)方式の入力装置、タッチスクリーン(touch screen)、空間リモコン(space remote control)などの少なくとも1つの入力または制御手段(以下、入力手段)をサポートするためのインターフェース(interface)を備えることができる。デジタル機器は、標準化された汎用OS(Operating System)を用いることができる。例えば、デジタル機器は、汎用OSのカーネル(kernel)上に様々なアプリケーション(application)を追加(adding)、削除(deleting)、修正(amending)、アップデート(updating)などを行うことができ、それを介してさらにユーザフレンドリ(user-friendly)な環境を構成して提供できる。
一方、本明細書で記述される外部入力は、外部入力機器、すなわち、前述したデジタル機器と有/無線で接続され、それを介して関連データを送/受信して処理可能な全ての入力手段またはデジタル機器を含む。ここで、上記外部入力は、例えば、HDMI(High Definition Multimedia Interface)(登録商標)、プレイステーション(play station)やエックスボックス(X−Box)などのゲーム機器、スマートフォン、タブレットPC、プリンター、スマートTVなどのデジタル機器をいずれも含む。
また、本明細書で記述される「サーバ(server)」とは、クライアント(client)、すなわち、前述したデジタル機器にデータを供給する全てのデジタル機器またはシステムを含む意味であって、プロセッサ(processor)とも呼ぶ。このようなサーバとしては、例えば、ウェブページまたはウェブコンテンツを提供するポータルサーバ(portal server)、広告データ(advertising data)を提供する広告サーバ(advertising server)、コンテンツを提供するコンテンツサーバ(content server)、SNS(Social Network Service)サービスを提供するSNSサーバ(SNS server)、メーカで提供するサービスサーバ(service server or manufacturing server)などが含まれ得る。
その他に、本明細書で記述される「チャンネル(channel)」とは、データを送受信するための経路(path)、手段(means)などを意味するものであって、放送チャンネル(broadcasting channel)を例に挙げることができる。ここで、放送チャンネルは、デジタル放送の活性化によって物理チャンネル(physical channel)、仮想チャンネル(virtual channel)、論理チャンネル(logical channel)などの用語で表現される。放送チャンネルは、放送網と呼ばれ得る。このように、放送チャンネルは、放送局で提供する放送コンテンツを提供または受信器でアクセス(接近)するためのチャンネルをいうもので、上記放送コンテンツは、主にリアルタイム放送(real-time broadcasting)に基づくので、ライブチャンネル(live channel)ともいう。ただし、最近では、放送のための媒体(medium)がさらに多様化され、リアルタイム放送以外に非リアルタイム(non-real time)放送も活性化されており、ライブチャンネルは、ただリアルタイム放送だけでなく、場合によっては、非リアルタイム放送を含む放送チャンネル全体を意味する用語と理解されることもある。
本明細書では、前述した放送チャンネル以外に、チャンネルに関して「任意のチャンネル(arbitrary channel)」をさらに定義する。上記任意のチャンネルは、放送チャンネルと共にEPG(Electronic Program Guide)のようなサービスガイド(service guide)と共に提供されることもでき、任意のチャンネルだけでサービスガイド、GUI(Graphic User Interface)またはOSD画面(On-Screen Dis-play screen)を構成/提供することもできる。
一方、送受信器間で予め約束されたチャンネル番号(ナンバ)を有する放送チャンネルと異なり、任意のチャンネルは、受信器で任意に割り当てられるチャンネルであって、上記放送チャンネルを表現するためのチャンネル番号とは基本的に重複しないチャンネル番号が割り当てられる。例えば、受信器は、特定の放送チャンネルをチューニングすると、チューニングされたチャンネルを介して放送コンテンツとそのためのシグナリング情報(signaling information)とを送信する放送信号を受信する。ここで、受信器は、上記シグナリング情報からチャンネル情報をパージング(parsing)し、パージングされたチャンネル情報に基づいてチャンネルブラウザ(channel browser)、EPGなどを構成してユーザに提供する。ユーザは、入力手段を介してチャンネル切換の要求を行うと、受信器は、それに応答する(対する方式である)。
このように、放送チャンネルは、送受信端間で予め約束された内容であるので、任意のチャンネルを放送チャンネルと重複して割り当てる場合には、ユーザの混同を招いたり、混同の可能性が存在するので、前述したように重複して割り当てないことが好ましい。一方、上記のように、任意のチャンネル番号を放送チャンネル番号と重複して割り当てなくても、ユーザのチャンネルサーフィン過程で依然として混同の恐れがあるので、これを考慮し、任意のチャンネル番号を割り当てることが要求される。何故なら、本明細書による任意のチャンネルもやはり、従来の放送チャンネルと同じように入力手段を介したユーザのチャンネル切換の要求によって、同じ方式で対応し、放送チャンネルのようにアクセスされるように実現できるためである。したがって、任意のチャンネル番号は、ユーザの任意のチャンネルへのアクセスに対する便宜と放送チャンネル番号の区分または識別に対する便宜とのために、放送チャンネルのように数字の形態ではなく、任意のチャンネル−1、任意のチャンネル−2などのように文字が併記された形で定義して表示できる。一方、この場合、任意のチャンネル番号の表示は、任意のチャンネル−1のように文字が併記された形であるが、受信器内部的には、上記放送チャンネルの番号のように数字の形で認識して実現できる。その他に、任意のチャンネル番号は、放送チャンネルのように数字の形で提供されてもよく、動画チャンネル−1、タイトル−1、ビデオ−1などのように放送チャンネルと区分可能な様々な方式でチャンネル番号を定義して表示してもよい。
デジタル機器は、ウェブサービス(web service)のためにウェブブラウザ(web browser)を実行して、様々な形態のウェブページ(web page)をユーザに提供する。ここで、上記ウェブページには、動画(video content)が含まれるウェブページも含まれるが、本明細書では、動画をウェブページから別途で、または独立して分離して処理する。また、上記分離される動画は、前述した任意のチャンネル番号を割り当て、サービスガイドなどを介して提供し、ユーザがサービスガイドや放送チャンネルの視聴過程で、チャンネル切換の要求によって出力されるように実現できる。その他に、ウェブサービス以外にも、放送コンテンツ、ゲーム、アプリケーションなどのサービスに対しても、所定のコンテンツ、イメージ、オーディオ、項目などを上記放送コンテンツ、ゲーム、アプリケーション自体から独立して分離処理し、その再生、処理などのために任意のチャンネル番号を割り当て、前述したように実現できる。
図38は、デジタル機器を含むサービスシステム(service system)の一例を概略的に示す図である。
デジタル機器を含むサービスシステムは、コンテンツプロバイダ(提供者)(Content Provider;CP)3810、サービスプロバイダ(Service Provider;SP)3820、ネットワークプロバイダ(Network Provider;NP)3830、およびHNED(Home Network End User)(Customer)3840を含む。ここで、HNED3840は、例えば、クライアント3800、すなわち、デジタル機器である。コンテンツプロバイダ3810は、各種のコンテンツを作製して提供する。このようなコンテンツプロバイダ3810として、図38に示すように、地上波放送業者(送出者)(terrestrial broadcaster)、ケーブル放送事業者(cable SO (System Operator))またはMSO(Multiple SO)、衛星放送業者(satellite broadcaster)、様々なインターネット放送業者(Internet broadcaster)、個人コンテンツプロバイダ(Private CPs)などを例示することができる。一方、コンテンツプロバイダ3810は、放送コンテンツ以外にも様々なアプリケーションなどを提供する。
サービスプロバイダ3820は、コンテンツプロバイダ3810が提供するコンテンツをサービスパッケージ化してHNED3840に提供する。例えば、図38のサービスプロバイダ3820は、第1の地上波放送、第2の地上波放送、ケーブルMSO、衛星放送、様々なインターネット放送、アプリケーションなどをパッケージ化してHNED3840に提供する。
サービスプロバイダ3820は、ユニキャスト(uni-cast)またはマルチキャスト(multi-cast)方式でクライアント300にサービスを提供する。一方、サービスプロバイダ3820は、データを予め登録された多数のクライアント3800に一度に送信できるが、このためにIGMP(Internet Group Management Protocol)プロトコルなどを用いることができる。
前述したコンテンツプロバイダ3810およびサービスプロバイダ3820は、同一のエンティティ(same or single entity)であってもよい。例えば、コンテンツプロバイダ3810が作製したコンテンツをサービスパッケージ化してHNED3840に提供することによって、サービスプロバイダ3820の機能も共に行うか、その反対のこともある。
ネットワークプロバイダ3830は、コンテンツプロバイダ3810および/またはサービスプロバイダ3820とクライアント3800との間のデータ交換のためのネットワーク網を提供する。
クライアント3800は、ホームネットワークを構築してデータを送受信できる。
一方、サービスシステム内のコンテンツプロバイダ3810および/またはサービスプロバイダ3820は、送信されるコンテンツの保護のために、制限受信(conditional access)またはコンテンツ保護(content protection)手段を利用することができる。この場合、クライアント3800は、上記制限受信やコンテンツ保護に対応し、ケーブルカード(Cable CARD)(POD:Point of Deployment)、DCAS(Downloadable CAS)などの処理手段を利用することができる。
その他に、クライアント3800も、ネットワーク網(または通信網)を介して、両方向のサービスを利用することができる。このような場合、むしろクライアント3800がコンテンツプロバイダの機能を行ってもよく、既存のサービスプロバイダ3820は、これを受信して再度他のクライアントへ送信してもよい。
図39は、デジタル機器の一実施例を説明するために示す構成のブロック図である。ここで、図39は、例えば、図38のクライアント3800に該当し得、前述したデジタル機器を意味する。
デジタル機器3900は、ネットワークインターフェース部(network interface)3901、TCP/IPマネージャ(TCP/IP manager)3902、サービス配送(伝達)マネージャ(service delivery manager)3903、SIデコーダ3904、逆多重化部(demux)3905、オーディオデコーダ(audio decoder)3906、ビデオデコーダ(video decoder)3907、ディスプレイ部(display A/V and OSD module)3908、サービス制御マネージャ(service control manager)3909、サービスディスカバリマネージャ(service discovery manager)3910、SI&メタデータのデータベース(SI&Metadata DB)3911、メタデータマネージャ(metadata manager)3912、サービスマネージャ3913、UIマネージャ3914などを含んで構成される。
ネットワークインターフェース部3901は、ネットワーク網を介してIPパケット(Internet Protocol (IP) packets)を受信または送信する。すなわち、ネットワークインターフェース部3901は、ネットワーク網を介してサービスプロバイダ3820からサービス、コンテンツなどを受信する。
TCP/IPマネージャ3902は、デジタル機器3900が受信するIPパケットおよびデジタル機器3900が送信するIPパケットに対して、すなわち、送信元(ソース)(source)と送信先(目的地)(destination)との間のパケットの伝達に関与する。また、TCP/IPマネージャ3902は、受信したパケットを適切なプロトコルに対応するように分類し、サービス配送マネージャ3903、サービスディスカバリマネージャ3910、サービス制御マネージャ3909、メタデータマネージャ3912などに分類されたパケットを出力する。サービス配送マネージャ3903は、受信されるサービスデータの制御を担当する。例えば、サービス配送マネージャ3903は、リアルタイムストリーミング(real-time streaming)データを制御する場合には、RTP/RTCPを使用することができる。上記リアルタイムストリーミングデータをRTPを使用して送信する場合、サービス配送マネージャ3903は、上記受信したデータパケットをRTPによってパージング(parsing)して逆多重化部3905に送信するか、サービスマネージャ3913の制御によって、SI&メタデータのデータベース3911に記憶する。また、サービス配送マネージャ3903は、RTCPを用いて上記ネットワークの受信情報をサービスを提供するサーバ側にフィードバック(feedback)する。逆多重化部3905は、受信したパケットを、オーディオ、ビデオ、SI(System Information)データなどで逆多重化し、それぞれオーディオ/ビデオデコーダ3906/3907、SIデコーダ3904に送信する。
SIデコーダ3904は、例えば、PSI(Program Specific Information)、PSIP(Program And System Information Protocol)、DVB−SI(Digital Video Broadcasting-Service Information)などのサービス情報をデコードする。
また、SIデコーダ3904は、デコードされたサービス情報を、例えば、SI&メタデータのデータベース3911に記憶する。このように記憶されたサービス情報は、例えば、ユーザの要求などによって該当構成により読み出されて用いられる。
オーディオ/ビデオデコーダ3906/3907は、逆多重化部3905で逆多重化された各オーディオデータおよびビデオデータをデコードする。このようにデコードされたオーディオデータおよびビデオデータは、ディスプレイ部3908を介してユーザに提供される。
アプリケーションマネージャは、例えば、UIマネージャ3914およびサービスマネージャ3913を含んで構成され得る。アプリケーションマネージャは、デジタル機器3900の全般的な状態を管理してユーザインターフェースを提供し、他のマネージャを管理することができる。
UIマネージャ3914は、ユーザのためのGUI(Graphic User Interface)をOSD(On Screen Display)などを用いて提供し、ユーザからキーの入力を受けて、上記記入力による機器動作を行う。例えば、UIマネージャ3914は、ユーザからチャンネルの選択に関するキーの入力を受けると、上記キーの入力信号をサービスマネージャ3913に送信する。
サービスマネージャ3913は、サービス配送マネージャ3903、サービスディスカバリマネージャ3910、サービス制御マネージャ3909、メタデータマネージャ3912などのサービスに関するマネージャを制御する。
また、サービスマネージャ3913は、チャンネルマップ(channel map)を作り、ユーザインターフェースマネージャ3914から受信したキーの入力によって、上記チャンネルマップを用いてチャンネルを選択する。また、サービスマネージャ3913は、SIデコーダ3904からチャンネルのサービス情報が送信されて選択されたチャンネルのオーディオ/ビデオPID(Packet IDentifier)を逆多重化部3905に設定する。このように設定されるPIDは、前述した逆多重化過程に用いられる。したがって、逆多重化部3905は、上記PIDを用いてオーディオデータ、ビデオデータ、およびSIデータをフィルタリング(filtering)する。
サービスディスカバリマネージャ3910は、サービスを提供するサービスプロバイダを選択するのに必要な情報を提供する。サービスマネージャ3913からチャンネルの選択に関する信号を受信すると、サービスディスカバリマネージャ3910は、上記情報を用いてサービスを見つける。
サービス制御マネージャ3909は、サービスの選択および制御を担当する。例えば、サービス制御マネージャ3909は、ユーザが既存の放送方式のような生放送(live broadcasting)サービスを選択する場合、IGMPまたはRTSPなどを使用し、VOD(Video On Demand)のようなサービスを選択する場合には、RTSPを使用してサービスの選択、制御を行う。上記RTSPプロトコルは、リアルタイムストリーミングに対してトリックモード(trick mode)を提供できる。また、サービス制御マネージャ3909は、IMS(IP Multimedia Subsystem)、SIP(Session Initiation Protocol)を用いて、IMSゲートウェイ3950を介したセクションを初期化して管理できる。プロトコルは、一実施例であり、実現例によって他のプロトコルを使用することもできる。
メタデータマネージャ3912は、サービスに関するメタデータを管理し、上記メタデータをSI&メタデータのデータベース3911に記憶する。
SI&メタデータのデータベース3911は、SIデコーダ3904がデコードしたサービス情報、メタデータマネージャ3912が管理するメタデータ、およびサービスディスカバリマネージャ3910が提供するサービスプロバイダを選択するのに必要な情報を記憶する。また、SI&メタデータのデータベース3911は、システムに対するセットアップデータなどを記憶し得る。
SI&メタデータのデータベース3911は、不揮発性メモリ(non-volatile RAM、NVRAM)またはフラッシュメモリ(flash memory)などを使用して実現されることもできる。
一方、IMSゲートウェイ3950は、IMSベースのIPTVサービスにアクセスするために必要な機能を集めたゲートウェイである。
図40は、デジタル機器の別の実施例を説明するために示す構成のブロック図である。特に、図40は、デジタル機器の別の実施例であって、モバイル機器の構成のブロック図を例示したものである。
図40を参照すると、モバイル機器4000は、無線通信部4010、A/V(Audio/Video)入力部4020、ユーザ入力部4030、センシング部4040、出力部4050、メモリ4060、インターフェース部4070、制御部4080、および電源供給部4090などを含み得る。図40に示す構成要素は必須のものではないので、それより多くの構成要素を有するか、それよりも少ない構成要素を有するモバイル機器が実現されることもある。
無線通信部4010は、モバイル機器4000と無線通信システムとの間、またはモバイル機器とモバイル機器が位置するネットワークとの間の無線通信を可能にする1つまたは複数のモジュールを含み得る。例えば、無線通信部4010は、放送受信モジュール4011、移動通信モジュール4012、無線インターネットモジュール4013、近距離通信モジュール4014、および位置情報モジュール4015などを含み得る。
放送受信モジュール4011は、放送チャンネルを介して外部の放送管理サーバから放送信号および/または放送に関連する情報を受信する。ここで、放送チャンネルは、衛星チャンネル、地上波チャンネルを含み得る。放送管理サーバは、放送信号および/もしくは放送関連の情報を生成して送信するサーバ、または既に生成された放送信号および/もしくは放送関連の情報を提供されて端末機に送信するサーバを意味し得る。放送信号は、TV放送信号、ラジオ放送信号、データ放送信号を含むだけでなく、TV放送信号またはラジオ放送信号にデータ放送信号が結合した形態の放送信号も含み得る。
放送関連の情報は、放送チャンネル、放送プログラムまたは放送サービスプロバイダに関する情報を意味し得る。放送関連の情報は、移動通信網を介しても提供できる。このような場合には、移動通信モジュール4012により受信され得る。
放送関連の情報は、様々な形態、例えば、EPG(Electronic Program Guide)またはESG(Electronic Service Guide)などの形態で存在し得る。
放送受信モジュール4011は、例えば、ATSC、DVB−T(Digital Video Broadcasting-Terrestrial)、DVB−S(Satellite)、MediaFLo(Media Forward Link Only)、DVB−H(Handheld)、ISDB−T(Integrated Services Digital Broadcast-Terrestrial)などのデジタル放送システムを用いてデジタル放送信号を受信することができる。もちろん、放送受信モジュール511は、前述したデジタル放送システムだけでなく、他の放送システムに適するように構成されることもできる。
放送受信モジュール4011を介して受信した放送信号および/または放送関連の情報は、メモリ4060に記憶され得る。
移動通信モジュール4012は、移動通信網上で基地局、外部端末、サーバの少なくとも1つと無線信号を送受信する。無線信号は、音声信号、画像通話信号、または文字/マルチメディアメッセージの送受信による様々な形態のデータを含み得る。
無線インターネットモジュール4013は、無線インターネットアクセスのためのモジュールを含めて、モバイル機器4000に内装されるか外装され得る。無線インターネット技術としては、WLAN(Wireless LAN)(Wi−Fi)、Wibro(Wireless broadband)、Wimax(World interoperability for microwave access)、HSDPA(High Speed Downlink Packet Access)などが用いられる。
近距離通信モジュール4014は、近距離通信のためのモジュールをいう。近距離通信(short range communication)技術として、ブルートゥース(Bluetooth)(登録商標)、RFID(Radio Frequency IDentification)、赤外線通信(IrDA,Infrared Data Association)、UWB(Ultra WideBand)、ZigBee、RS−232、RS−485などが用いられる。
位置情報モジュール4015は、モバイル機器4000の位置情報の獲得のためのモジュールとして、GPS(Global Position System)モジュールを例に挙げることができる。
A/V入力部4020は、オーディオおよび/またはビデオ信号の入力のためのものであって、ここでは、カメラ4021およびマイク4022などが含まれ得る。カメラ4021は、画像通話モードまたは撮影モードでイメージセンサにより得られる静止画(停止映像)または動画などの画像フレームを処理する。処理された画像フレームは、ディスプレイ部4051に表され得る。
カメラ4021で処理された画像フレームは、メモリ4060に記憶されるか無線通信部4010を介して外部へ送信され得る。カメラ4021は、使用環境によって2つ以上が備えられることもある。
マイク4022は、通話モードまたは録音モード、音声認識モードなどでマイクロフォン(microphone)により外部の音響信号が入力され、電気的な音声データで処理する。処理された音声データは、通話モードである場合、移動通信モジュール4012を介して移動通信基地局へ送信可能な形態に変換されて出力されることができる。マイク4022では、外部の音響信号が入力される過程で発生する雑音(noise)を除去するための様々な雑音除去のアルゴリズムが実現され得る。
ユーザ入力部4030は、ユーザが端末機の動作制御のための入力データを発生させる。ユーザ入力部4030は、キーパッド(key pad)、ドームスイッチ(dome switch)、タッチパッド(定圧/静電)、ジョグホイール(jog wheel)、ジョグスイッチ(jog switch)などで構成され得る。
センシング部4040は、モバイル機器4000の開閉状態、モバイル機器4000の位置、ユーザの接触の有無、モバイル機器の方位、モバイル機器の加速/減速などのように、モバイル機器4000の現在の状態を感知し、モバイル機器4000の動作制御のためのセンシング信号を発生させる。例えば、モバイル機器4000が移動されるか傾いた場合、モバイル機器の位置または傾きなどをセンシングできる。また、電源供給部4090の電源供給の有無、インターフェース部4070の外部機器の結合の有無等もセンシングすることもできる。一方、センシング部4040は、NFC(Near Field Communication)を含む近接センサ4041を含み得る。
出力部4050は、視覚、聴覚、または触覚などに関する出力を発生させるためのものであって、ディスプレイ部4051、音響出力モジュール4052、アラーム部4053、およびハプティックモジュール4054などが含まれ得る。
ディスプレイ部4051は、モバイル機器4000で処理される情報を表示(出力)する。例えば、モバイル機器が通話モードである場合、通話と関連するUI(User Interface)またはGUI(Graphic User Interface)を表示する。モバイル機器4000が画像通話モードまたは撮影モードである場合には、撮影および/または受信した映像またはUI、GUIを表示する。
ディスプレイ部4051は、液晶ディスプレイ(Liquid Crystal Display、LCD)、薄膜トランジスタの液晶ディスプレイ(Thin Film Transistor-Liquid Crystal Display、TFT LCD)、有機発光ダイオード(Organic Light-Emitting Diode、OLED)、フレキシブルディスプレイ(flexible display)、3次元ディスプレイ(3D display)の少なくとも1つを含み得る。
これらのうちの一部のディスプレイは、それを介して外部を見ることができるように透明型または光透過型で構成され得る。これは、透明ディスプレイと呼ばれるが、上記透明ディスプレイの代表的な例としては、TOLED(transparent OLED)などがある。ディスプレイ部4051の後方構造もまた光透過型構造で構成され得る。このような構造により、ユーザは、端末機の本体(ボディ)のディスプレイ部4051の占める領域を介して、端末機の本体(body)の後方に位置する物を見ることができる。
モバイル機器4000の実現形態によって、ディスプレイ部4051が2つ以上存在し得る。例えば、モバイル機器4000には、複数のディスプレイ部が1つの面に離隔されるか一体で配置されてもよく、また、互いに異なる面にそれぞれ配置されてもよい。
ディスプレイ部4051とタッチ動作を感知するセンサ(以下「タッチセンサ」という)とが相互レイヤ構造をなす場合(以下「タッチスクリーン」という)に、ディスプレイ部4051は、出力装置以外に入力装置としても使用され得る。タッチセンサは、例えば、タッチフィルム、タッチシート、タッチパッドなどの形態を有し得る。
タッチセンサは、ディスプレイ部4051の特定部位に加えられた圧力、またはディスプレイ部4051の特定部位に発生する静電容量などの変化を電気的な入力信号に変換するように構成され得る。タッチセンサは、タッチされる位置および面積だけでなく、タッチ時の圧力までも検出できるように構成され得る。
タッチセンサに対するタッチ入力がある場合、それに対応する信号は、タッチ制御器に送られる。タッチ制御器は、その信号を処理した後、対応するデータを制御部4080に送信する。これによって、制御部4080は、ディスプレイ部4051のどの領域がタッチされているか否かなどが分かるようになる。
タッチスクリーンにより包まれるモバイル機器の内部領域、または上記タッチスクリーンの近辺に近接センサ4041が配置され得る。上記近接センサは、所定の検出面にアプローチする物体、あるいは、近傍に存在する物体の有無を電磁界の力または赤外線を用いて機械的接触なしで検出するセンサをいう。近接センサは、接触式センサより、その寿命が長く、その活用もまた高い。
近接センサの例としては、透過型光電センサ、直接反射型光電センサ、ミラー反射型光電センサ、高周波発振型近接センサ、静電容量型近接センサ、磁気型近接センサ、赤外線近接センサなどがある。上記タッチスクリーンが静電式である場合には、上記ポインタの近接による電界の変化でポインタの近接を検出するように構成される。この場合、タッチスクリーン(タッチセンサ)は、近接センサに分類されることもある。
以下では、説明の便宜のために、タッチスクリーン上にポインタが接触され(ない)ながらも、近接されてポインタがタッチスクリーン上に位置することが認識されるようにする行為を「近接タッチ(proximity touch)」と称し、上記タッチスクリーン上にポインタが実際に接触する行為を「接触タッチ(contact touch)」と称する。タッチスクリーン上でポインタで近接タッチされる位置というのは、ポインタが近接タッチされる際、ポインタがタッチスクリーンに対して垂直に対応する位置を意味する。
近接センサは、近接タッチと、近接タッチパターン(例えば、近接タッチ距離、近接タッチ方向、近接タッチ速度、近接タッチ時間、近接タッチ位置、近接タッチ移動状態など)と、を感知する。感知された近接タッチ動作および近接タッチパターンに相応する情報は、タッチスクリーン上に出力されることができる。
音響出力モジュール4052は、呼信号の受信、通話モードまたは録音モード、音声認識モード、放送受信モードなどで無線通信部4010から受信されるか、メモリ4060に記憶されたオーディオデータを出力することができる。音響出力モジュール4052は、モバイル機器4000で行われる機能(例えば、呼信号の受信音、メッセージ受信音など)に関する音響信号を出力することもある。このような音響出力モジュール4052には、レシーバ(receiver)、スピーカ(speaker)、ブザー(buzzer)などが含まれ得る。
アラーム部4053は、モバイル機器4000のイベントの発生を知らせるための信号を出力する。モバイル機器で発生するイベントの例としては、呼信号の受信、メッセージ受信、キー信号入力、タッチ入力などがある。アラーム部4053は、ビデオ信号やオーディオ信号以外に異なる形態、例えば、振動でイベントの発生を知らせるための信号を出力することもできる。
ビデオ信号やオーディオ信号は、ディスプレイ部4051や音声出力モジュール4052を介しても出力されることができ、ディスプレイ部および音声出力モジュール4051、4052は、アラーム部4053の一部に分類されることもできる。
ハプティックモジュール(haptic module)4054は、ユーザが感じる様々な触覚効果を発生させる。ハプティックモジュール4054が発生させる触覚効果の代表的な例としては、振動がある。ハプティックモジュール4054が発生する振動の強さとパターンなどは制御可能である。例えば、互いに異なる振動を合成して出力するか、順次出力することもできる。
ハプティックモジュール4054は、振動以外にも、接触皮膚面に対して垂直運動するピン配列、噴射口や吸入口を介した空気の噴射力や吸入力、皮膚表面に対する擦れ、電極(electrode)の接触、静電気力などの刺激による効果と、吸熱や発熱可能な素子を用いた冷温感の再現による効果などと、様々な触覚効果を発生させることができる。
ハプティックモジュール4054は、直接的な接触を介して触覚効果を伝達することができるだけでなく、ユーザが指や腕などの筋感覚を介して触覚効果を感じることができるように実現することもできる。ハプティックモジュール4054は、モバイル機器4000の構成様態によって2つ以上が備えられる。
メモリ4060は、制御部4080の動作のためのプログラムを記憶することができ、入/出力されるデータ(例えば、電話帳(フォンブック)、メッセージ、静止画、動画など)を一時(仮)記憶することもできる。メモリ4060は、上記タッチスクリーン上のタッチ入力の際に出力される様々なパターンの振動および音響に関するデータを記憶することができる。
メモリ4060は、フラッシュメモリタイプ(flash memory type)、ハードディスクタイプ(hard disk type)、マルチメディアカードマイクロタイプ(multimedia card micro type)、カードタイプのメモリ(例えば、SDまたはXDメモリなど)、ラム(Random Access Memory、RAM)、SRAM(Static Random Access Memory)、ロム(Read-Only Memory、ROM)、EEPROM(Electrically Erasable Programmable Read-Only Memory)、PROM(Programmable Read-Only Memory)、磁気メモリ、磁気ディスク、光ディスクの少なくとも1つのタイプの記憶媒体を含み得る。モバイル機器4000は、インターネット(internet)上でメモリ4060の記憶機能を行うウェブストレージ(web storage)に関して動作することもできる。
インターフェース部4070は、モバイル機器4000に接続される全ての外部機器との通信路の役割を担う。インターフェース部4070は、外部機器からデータの送信を受けるか、電源が供給され、モバイル機器4000内部の各構成要素に伝達するか、モバイル機器4000内部のデータが外部機器へ送信されるようにする。例えば、有/無線ヘッドセットポート、外部充電器ポート、有/無線データポート、メモリカード(memory card)ポート、識別モジュールが備えられた装置を接続するポート、オーディオI/O(Input/Output)ポート、ビデオI/Oポート、イヤホーンポートなどがインターフェース部4070に含まれ得る。
識別モジュールは、モバイル機器4000の使用権限を認証するための各種情報を記憶したチップであって、ユーザ認証(識別)モジュール(User Identify Module、UIM)、加入者認証モジュール(Subscriber Identify Module、SIM)、汎用ユーザ認証モジュール(Universal Subscriber Identity Module、USIM)などを含み得る。識別モジュールが備えられた装置(以下「識別装置」)は、スマートカード(smart card)の形式で作製され得る。したがって、識別装置は、ポートを介して端末機4000と接続され得る。
インターフェース部4070は、移動端末機4000が外部のクレードル(cradle)と接続される際、クレードルからの電源が移動端末機4000に供給される通信路になるか、ユーザによりクレードルで入力される各種の命令信号が移動端末機に伝達される通信路になり得る。クレードルから入力される各種の命令信号または電源は、移動端末機がクレードルに正確に装着されたことを認知するための信号として動作されることもある。
制御部4080は、通常、モバイル機器の全般的な動作を制御する。例えば、音声通話、データ通信、画像通話などのための関連する制御および処理を行う。制御部4080は、マルチメディアの再生のためのマルチメディアモジュール4081を備えることもできる。マルチメディアモジュール4081は、制御部4080内に実現されてもよく、制御部4080と別に実現されてもよい。制御部4080、特にマルチメディアモジュール4081は、前述したエンコード装置100および/またはデコード装置200を含み得る。
制御部4080は、タッチスクリーン上で行われる筆記入力または絵を描く入力をそれぞれ文字およびイメージで認識できるパターン認識処理を行うことができる。
電源供給部4090は、制御部4080の制御により外部の電源、内部の電源が認可され、各構成要素の動作に必要な電源を供給する。
ここに説明される様々な実施例は、例えば、ソフトウェア、ハードウェア、またはこれらの組み合わせたものを用いて、コンピュータまたはこれと類似する装置で読み取られる記録媒体内で実現されることができる。
ハードウェア的な実現によると、ここに説明される実施例は、ASICs(Application Specific Integrated Circuits)、DSPs(Digital Signal Processors)、DSPDs(Digital Signal Processing Devices)、PLDs(Programmable Logic Devices)、FPGAs(Field Programmable Gate Arrays、プロセッサ、制御器、マイクロコントローラ(micro-controllers)、マイクロプロセッサ(microprocessors)、その他の機能を実行するための電気的なユニットの少なくとも1つを用いて実現され得る。一部の場合に、本明細書で説明される実施例が制御部4080自体で実現され得る。
ソフトウェア的な実現によると、本明細書で説明される手続および機能のような実施例は、別途のソフトウェアモジュールで実現され得る。ソフトウェアモジュールのそれぞれは、本明細書で説明される1つまたは複数の機能および動作を行うことができる。適切なプログラム言語で書かれたソフトウェアアプリケーションでソフトウェアコードが実現され得る。ここで、ソフトウェアコードは、メモリ4060に記憶され、制御部4080により実行され得る。
図41は、デジタル機器のさらに他の実施例を説明するために示す構成のブロック図である。
デジタル機器4100の別の例は、放送受信部4105、外部装置インターフェース部4135、記憶部4140、ユーザ入力インターフェース部4150、制御部4170、ディスプレイ部4180、オーディオ出力部4185、電源供給部4190、および撮影部(図示せず)を含み得る。ここで、放送受信部4105は、少なくとも1つのチューナ4110、復調部4120、およびネットワークインターフェース部4130を含み得る。ただし、場合によって、放送受信部4105は、チューナ4110および復調部4120を備えるが、ネットワークインターフェース部4130を含まないことがあり、その反対の場合もある。また、放送受信部4105は、示していないが、多重化部(multiplexer)を備えてチューナ4110を経て復調部4120で復調された信号とネットワークインターフェース部4130を経て受信した信号とを多重化することもできる。その他に、放送受信部4025は、やはり示していないが、逆多重化部(demultiplexer)を備えて上記多重化された信号を逆多重化するか、上記復調された信号または上記ネットワークインターフェース部4130を経た信号を逆多重化することができる。
チューナ4110は、アンテナを介して受信されるRF(Radio Frequency)放送信号のうち、ユーザにより選択されたチャンネル、または既に記憶された全てのチャンネルをチューニングしてRF放送信号を受信する。また、チューナ4110は、受信したRF放送信号を中間周波数(Intermediate Frequency、IF)信号またはベースバンド(baseband)信号に変換する。
例えば、受信したRF放送信号がデジタル放送信号である場合、デジタルIF信号(DIF)に変換し、アナログ放送信号である場合、アナログベースバンド映像または音声信号(CVBS/SIF)に変換する。すなわち、チューナ4110は、デジタル放送信号またはアナログ放送信号を全て処理することができる。チューナ4110で出力されるアナログベースバンド映像または音声信号(CVBS/SIF)は、制御部4170に直接入力されることができる。
また、チューナ4110は、ATSC(Advanced Television System Committee)方式による単一キャリアのRF放送信号またはDVB(Digital Video Broadcasting)方式による複数のキャリアのRF放送信号を受信することができる。
一方、チューナ4110は、アンテナを介して受信されるRF放送信号のうち、チャンネル記憶機能を介して記憶された全ての放送チャンネルのRF放送信号を順次チューニングおよび受信し、これを中間周波数信号またはベースバンド信号に変換することができる。
復調部4120は、チューナ4110で変換されたデジタルIF信号(DIF)を受信して復調する。例えば、チューナ4110で出力されるデジタルIF信号がATSC方式である場合、復調部4120は、例えば、8−VSB(8-Vestigal Side Band)復調を行う。また、復調部4120は、チャネルの復号を行うこともできる。このため、復調部4120は、トレリスデコーダ(trellis decoder)、デインターリーバ(de-interleaver)、およびリードソロモンデコーダ(Reed-Solomon decoder)などを備え、トレリス復号、デインターリーブ、およびリードソロモン復号を行うことができる。
例えば、チューナ4110で出力されるデジタルIF信号がDVB方式である場合、復調部4120は、例えば、COFDMA(Coded Orthogonal Frequency Division Modulation)復調を行う。また、復調部4120は、チャネルの復号を行うこともできる。このため、復調部4120は、コンボリューションデコーダ(convolution decoder)、デインターリーバ、およびリードソロモンデコーダなどを備え、コンボリューション復号、デインターリーブ、およびリードソロモン復号を行うことができる。
復調部4120は、復調およびチャネルの復号を行った後、ストリーム信号(TS)を出力することができる。この際、ストリーム信号は、映像信号、音声信号またはデータ信号が多重化された信号であってもよい。一例として、ストリーム信号は、MPEG−2規格の映像信号、ドルビ(Dolby)AC−3規格の音声信号などが多重化されたMPEG−2 TS(Transport Stream)であってもよい。具体的には、MPEG−2 TSは、4バイト(byte)のヘッダ(header)および184バイトのペイロード(payload)を含み得る。
一方、前述した復調部4120は、ATSC方式およびDVB方式によってそれぞれ別に備えられることが可能である。すなわち、デジタル機器は、ATSC復調部およびDVB復調部をそれぞれ別に備えることができる。
復調部4120で出力したストリーム信号は、制御部4170に入力されることができる。制御部4170は、逆多重化、映像/音声信号の処理などを制御し、ディスプレイ部4180を介して映像を、オーディオ出力部4185を介して音声の出力を制御することができる。
外部装置インターフェース部4135は、デジタル機器4100と様々な外部装置がインターフェースを取れるように環境を提供する。このため、外部装置インターフェース部4135は、A/V入出力部(図示せず)または無線通信部(図示せず)を含み得る。
外部装置インターフェース部4135は、DVD(Digital Versatile Disk)、ブルーレイ(blu-ray)、ゲーム機器、カメラ、カムコーダ、コンピュータ(ノートパソコン、タブレット)、スマートフォン、ブルートゥース機器(Bluetooth device)(登録商標)、クラウド(cloud)などの外部装置と有/無線で接続され得る。外部装置インターフェース部4135は、接続された外部装置を介して外部で入力される映像、音声またはデータ(イメージ含む)信号をデジタル機器の制御部4170に伝達する。制御部4170は、処理された映像、音声またはデータ信号を接続された外部装置に出力されるように制御できる。このため、外部装置インターフェース部4135は、A/V入出力部(図示せず)または無線通信部(図示せず)をさらに含み得る。
A/V入出力部は、外部装置の映像および音声信号をデジタル機器4100に入力できるように、USB端子、CVBS(Composite Video Banking Sync)端子、コンポーネント端子、S−ビデオ端子(アナログ)、DVI(Digital Visual Interface)端子、HDMI(High Definition Multimedia Interface)(登録商標)端子、RGB端子、D−SUB端子などを含み得る。
無線通信部は、他の電子機器と近距離無線通信を行うことができる。デジタル機器4100は、例えば、ブルートゥース(Bluetooth)(登録商標)、RFID(Radio Frequency Identification)、赤外線通信(IrDA、infrared data association)、UWB(Ultra Wideband)、ジグビ(ZigBee)、DLNA(Digital Living Network Alliance)(登録商標)などの通信プロトコルによって、他の電子機器とネットワークで接続され得る。
また、外部装置インターフェース部4135は、多様なセットトップボックスや前述した各種端子の少なくとも1つを介して接続され、セットトップボックスと入力/出力動作を行うこともできる。
一方、外部装置インターフェース部4135は、隣接する外部装置内のアプリケーションまたはアプリケーションリストを受信し、制御部4170または記憶部4140へ伝達できる。
ネットワークインターフェース部4130は、デジタル機器4100をインターネット網を含む有/無線ネットワークと接続するためのインターフェースを提供する。ネットワークインターフェース部4130は、有線ネットワークとの接続のために、例えば、イーサネット(Ethernet)(登録商標)端子などを備えることができ、無線ネットワークとの接続のために、例えば、WLAN(Wireless LAN)(Wi−Fi)、Wibro(Wireless broadband)、Wimax(World interoperability for microwave access)、HSDPA(High Speed Downlink Packet Access)の通信規格などを用いることができる。
ネットワークインターフェース部4130は、接続されたネットワークまたは接続されたネットワークにリンクされた他のネットワークを介して、他のユーザまたは他のデジタル機器とデータを送信または受信できる。特に、デジタル機器4100に予め登録された他のユーザまたは他のデジタル機器のうちの選択されたユーザまたは選択されたデジタル機器に、デジタル機器4100に記憶された一部のコンテンツデータを送信することができる。
一方、ネットワークインターフェース部4130は、接続されたネットワークまたは接続されたネットワークにリンクされた他のネットワークを介して、所定のウェブページに接続することができる。すなわち、ネットワークを介して所定のウェブページに接続し、該当サーバとデータを送信または受信することができる。その他、コンテンツプロバイダまたはネットワーク運営者が提供するコンテンツまたはデータを受信することができる。すなわち、ネットワークを介して、コンテンツプロバイダまたはネットワークプロバイダから提供される、映画、広告、ゲーム、VOD、放送信号などのコンテンツ、およびそれに関する情報を受信することができる。また、ネットワーク運営者が提供するファームウェア(firmware)のアップデート情報およびアップデートファイルを受信することができる。さらに、インターネットもしくはコンテンツプロバイダまたはネットワーク運営者にデータを送信することができる。
また、ネットワークインターフェース部4130は、ネットワークを介して、公衆に公開(open)されたアプリケーションのうち、希望するアプリケーションを選択して受信できる。
記憶部4140は、制御部4170内の各信号処理および制御のためのプログラムを記憶することもでき、信号処理された映像、音声またはデータ信号を記憶することもできる。
また、記憶部4140は、外部装置インターフェース部4135またはネットワークインターフェース部4130から入力される、映像、音声、またはデータ信号の一時記憶のための機能を行うこともできる。記憶部4140は、チャンネル記憶機能を介して、所定の放送チャンネルに関する情報を記憶することができる。
記憶部4140は、外部装置インターフェース部4135またはネットワークインターフェース部4130から入力される、アプリケーションまたはアプリケーションリストを記憶することができる。
また、記憶部4140は、後述して説明する様々なプラットフォーム(platform)を記憶することもできる。
記憶部4140は、例えば、フラッシュメモリタイプ(flash memory type)、ハードディスクタイプ(hard disk type)、マルチメディアカードマイクロタイプ(multimedia card micro type)、カードタイプのメモリ(例えば、SDまたはXDメモリなど)、ラム(RAM)、ロム(EEPROMなど)の少なくとも1つのタイプの記憶媒体を含み得る。デジタル機器4100は、記憶部4140内に記憶されているコンテンツファイル(動画ファイル、静止画ファイル、音楽ファイル、文書ファイル、アプリケーションファイルなど)を再生してユーザに提供できる。
図41は、記憶部4140が制御部4170と別に備えられた実施例を示しているが、本明細書の範囲はこれに限定されない。すなわち、記憶部4140は、制御部4170内に含まれることもある。
ユーザ入力インターフェース部4150は、ユーザが入力した信号を制御部4170へ伝達するか、制御部4170の信号をユーザに伝達する。
例えば、ユーザ入力インターフェース部4150は、RF通信方式、赤外線(IR)通信方式など、多様な通信方式によって、遠隔制御装置5700から電源のオン/オフ、チャンネル選択、画面設定などの制御信号を受信して処理するか、制御部4170の制御信号を遠隔制御装置5700へ送信するように処理することができる。
また、ユーザ入力インターフェース部4150は、電源キー、チャンネルキー、ボリュームキー、設定値などのローカルキー(図示せず)で入力される制御信号を制御部4170に伝達できる。
ユーザ入力インターフェース部4150は、ユーザのジェスチャ(gesture)をセンシング(sensing)するセンシング部(図示せず)から入力される制御信号を制御部4170に伝達するか、制御部4170の信号をセンシング部(図示せず)へ送信できる。ここで、センシング部(図示せず)は、タッチセンサ、音声センサ、位置センサ、動作センサなどを含み得る。
制御部4170は、チューナ4110、復調部4120または外部装置インターフェース部4135を介して入力されるストリームを逆多重化するか、逆多重化された信号を処理し、映像または音声の出力のための信号を生成および出力できる。制御部4170は、前述したエンコード装置および/またはデコード装置を含み得る。
制御部4170で処理された映像信号は、ディスプレイ部4180に入力され、該当映像信号に対応する映像で表され得る。また、制御部4170で映像処理された映像信号は、外部装置インターフェース部4135を介して外部出力装置に入力され得る。
制御部4170で処理された音声信号は、オーディオ出力部4185にオーディオ出力され得る。また、制御部4170で処理された音声信号は、外部装置インターフェース部4135を介して外部出力装置に入力され得る。
図41では示していないが、制御部4170は、逆多重化部、映像処理部などを含み得る。
制御部4170は、デジタル機器4100の全般的な動作を制御することができる。例えば、制御部4170は、チューナ4110を制御し、ユーザが選択したチャンネルまたは既に記憶されたチャンネルに該当するRF放送をチューニング(tuning)するように制御できる。
制御部4170は、ユーザ入力インターフェース部4150を介して入力されたユーザ命令、または内部のプログラムによってデジタル機器4100を制御することができる。特に、ネットワークに接続してユーザが希望するアプリケーションまたはアプリケーションリストをデジタル機器4100内にダウンロードするようにすることができる。
例えば、制御部4170は、ユーザ入力インターフェース部4150を介して受信した所定のチャンネルの選択命令によって選択したチャンネルの信号が入力されるようにチューナ4110を制御する。また、選択したチャンネルの映像、音声またはデータ信号を処理する。制御部4170は、ユーザが選択したチャンネル情報などが、処理された映像または音声信号と共に、ディスプレイ部4180またはオーディオ出力部4185を介して出力されることができるようにする。
別の例として、制御部4170は、ユーザ入力インターフェース部4150を介して受信した外部装置の映像再生命令によって、外部装置インターフェース部4135を介して入力される外部装置、例えば、カメラまたはカムコーダからの映像信号または音声信号が、ディスプレイ部4180またはオーディオ出力部4185を介して出力されることができるようにする。
一方、制御部4170は、映像を表示するようにディスプレイ部4180を制御することができる。例えば、チューナ4110を介して入力される放送映像、または外部装置インターフェース部4135を介して入力される外部入力映像、またはネットワークインターフェース部を介して入力される映像、または記憶部4140に記憶された映像を、ディスプレイ部4180に表示するように制御できる。この際、ディスプレイ部4180に表示される映像は、静止画または動画であってもよく、2D映像または3D映像であってもよい。
また、制御部4170は、コンテンツを再生するように制御できる。この際のコンテンツは、デジタル機器4100内に記憶されたコンテンツ、または受信した放送コンテンツ、外部から入力される外部入力コンテンツであってもよい。コンテンツは、放送映像、外部入力映像、オーディオファイル、静止画、接続されたウェブ画面、および文書ファイルの少なくとも1つであってもよい。
一方、制御部4170は、アプリケーションビューの項目を入力する(に進入する)場合、デジタル機器4100内または外部のネットワークからダウンロード可能なアプリケーションまたはアプリケーションリストを表示するように制御できる。
制御部4170は、様々なユーザインターフェースと共に、外部のネットワークからダウンロードされるアプリケーションをインストール(設置)および駆動するように制御できる。また、ユーザの選択により、実行されるアプリケーションに関する映像がディスプレイ部4180に表示されるように制御できる。
一方、図に示していないが、チャンネル信号または外部の入力信号に対応するサムネイルのイメージを生成するチャンネルブラウジング処理部がさらに備えられることも可能である。
チャンネルブラウジング処理部は、復調部4120で出力したストリーム信号(TS)または外部装置インターフェース部4135で出力したストリーム信号などの入力を受け、入力されるストリーム信号から映像を抽出し、サムネイルの映像を生成することができる。
生成されたサムネイルの映像は、そのまま、または符号化され、制御部4170に入力され得る。また、生成されたサムネイルの映像は、ストリームの形態で符号化され、制御部4170に入力されることも可能である。制御部4170は、入力されたサムネイルの映像を用いて、複数のサムネイルの映像を備えるサムネイルリストをディスプレイ部4180に表示することができる。一方、このようなサムネイルリスト内のサムネイルの映像は、次第にまたは同時にアップデートされ得る。これによって、ユーザは、複数の放送チャンネルの内容を簡便に把握できるようになる。
ディスプレイ部4180は、制御部4170で処理された映像信号、データ信号、OSD信号、または外部装置インターフェース部4135で受信される映像信号、データ信号などを、それぞれR、G、B信号に変換して駆動信号を生成する。
ディスプレイ部4180は、PDP、LCD、OLED、フレキシブルディスプレイ(flexible display)、3次元ディスプレイ(3D display)などが可能である。
一方、ディスプレイ部4180は、タッチスクリーンで構成され、出力装置以外に入力装置として使用されることも可能である。
オーディオ出力部4185は、制御部4170で音声処理された信号、例えば、ステレオ信号、3.1チャンネル信号または5.1チャンネル信号の入力を受け、音声で出力する。音声出力部4185は、様々な形態のスピーカで実現され得る。
一方、ユーザのジェスチャを感知するために、前述したように、タッチセンサ、音声センサ、位置センサ、動作センサの少なくとも1つを備えるセンシング部(図示せず)がデジタル機器4100にさらに備えられる。センシング部(図示せず)で感知された信号は、ユーザ入力インターフェース部4150を介して制御部4170へ伝達されることができる。
一方、ユーザを撮影する撮影部(図示せず)がさらに備えられる。撮影部(図示せず)で撮影された映像情報は、制御部4170に入力され得る。
制御部4170は、撮影部(図示せず)から撮影された映像、またはセンシング部(図示せず)からの感知された信号を、それぞれまたは組み合わせてユーザのジェスチャを感知することもできる。
電源供給部4190は、デジタル機器4100全般にわたって、該当電源を供給する。
特に、システムオンチップ(System On Chip、SOC)の形態で実現され得る制御部4170と、映像表示のためのディスプレイ部4180と、オーディオの出力のためのオーディオ出力部4185と、に電源を供給することができる。
このため、電源供給部4190は、交流電源を直流電源に変換するコンバータ(図示せず)を備えることができる。一方、例えば、ディスプレイ部4180が多数のバックライトランプを備える液晶パネルとして実現される場合、輝度可変またはディミング(dimming)駆動のために、PWM動作可能なインバータ(図示せず)をさらに備えることもできる。
遠隔制御装置4200は、ユーザ入力をユーザ入力インターフェース部4150へ送信する。このため、遠隔制御装置4200は、ブルートゥース(Bluetooth)(登録商標)、RF(Radio Frequency)通信、赤外線(IR)通信、UWB(Ultra Wideband)、ジグビ(ZigBee)方式などを使用することができる。
また、遠隔制御装置4200は、ユーザ入力インターフェース部4150で出力した映像、音声またはデータ信号などを受信し、これを遠隔制御装置4200で表示するか、音声または振動を出力することができる。
前述したデジタル機器4100は、固定型または移動型のATSC方式またはDVB方式のデジタル放送信号の処理が可能なデジタル放送受信器であり得る。
その他に、本明細書によるデジタル機器は、示している構成のうち、必要に応じて一部の構成を省略するか、逆に示していない構成をさらに含むこともある。一方、デジタル機器は、前述したものと異なり、チューナおよび復調部を備えず、ネットワークインターフェース部または外部装置インターフェース部を介してコンテンツを受信して再生することもできる。
図42は、図39乃至図41の制御部の詳細構成の一実施例を説明するために示した構成のブロック図である。
制御部の一例は、逆多重化部4210、映像処理部4220、OSD(On-Screen Display)生成部4240、ミキサ(mixer)4250、フレームレート変換部(Frame Rate Converter、FRC)4255、およびフォーマット(formatter)4260を含み得る。その他、上記制御部は示していないが、音声処理部およびデータ処理部をさらに含み得る。
逆多重化部4210は、入力されるストリームを逆多重化する。例えば、逆多重化部4210は、入力されるMPEG−2 TSを、映像、音声およびデータ信号に逆多重化できる。ここで、逆多重化部4210に入力されるストリーム信号は、チューナまたは復調部または外部装置インターフェース部で出力されるストリーム信号であり得る。
映像処理部4220は、逆多重化された映像信号の映像処理を行う。このため、映像処理部4220は、映像デコーダ4225およびスケーラ4235を備えることができる。
映像デコーダ4225は、逆多重化された映像信号を復号し、スケーラ4235は、復号された映像信号の解像度をディスプレイ部で出力可能なようにスケーリング(scaling)する。
映像デコーダ4225は、様々な規格をサポートすることができる。例えば、映像デコーダ4225は、映像信号がMPEG−2規格で符号化された場合には、MPEG−2デコーダの機能を行い、映像信号がDMB(Digital Multimedia Broadcasting)方式またはH.264規格で符号化された場合には、H.264デコーダの機能を行うことができる。
一方、映像処理部4220で復号された映像信号は、ミキサ4250に入力される。
OSD生成部4240は、ユーザ入力によって、または自主的にOSDデータを生成する。例えば、OSD生成部4240は、ユーザ入力インターフェース部の制御信号に基づいて、ディスプレイ部4180の画面に各種データをグラフィック(graphic)やテキスト(text)の形態で表示するためのデータを生成する。生成されるOSDデータは、デジタル機器のユーザインターフェース画面、様々なメニュ画面、ウィジェット(widget)、アイコン(icon)、視聴率情報(viewing rate information)などの様々なデータを含む。
OSD生成部4240は、放送映像の字幕またはEPGに基づく放送情報を表示するためのデータを生成することもできる。
ミキサ4250は、OSD生成部4240で生成されたOSDデータと映像処理部で映像処理された映像信号とをミキシングして、フォーマット4260に提供する。復号された映像信号とOSDデータとがミキシングされることによって、放送映像または外部入力映像上にOSDがオーバーレイ(overlay)されて表示される。
フレームレート変換部(FRC)4255は、入力される映像のフレームレート(frame rate)を変換する。例えば、フレームレート変換部4255は、入力される60Hz映像のフレームレートをディスプレイ部の出力周波数によって、例えば、120Hzまたは240Hzのフレームレートを有するように変換できる。上記のように、フレームレートを変換する方法には様々な方法が存在し得る。一例として、フレームレート変換部4255は、フレームレートを60Hzから120Hzに変換する場合、第1のフレームと第2のフレームとの間に同一の第1のフレームを挿入するか、第1のフレームおよび第2のフレームから予測された第3のフレームを挿入することによって変換できる。別の例として、フレームレート変換部4255は、フレームレートを60Hzから240Hzに変換する場合、既存のフレーム間に同一のフレームまたは予測されたフレームを3つさらに挿入して変換できる。一方、別の(separate)フレームの変換を行わない場合には、フレームレート変換部4255をバイパス(bypass)することもできる。
フォーマット4260は、入力されるフレームレート変換部4255の出力をディスプレイ部の出力フォーマットに合わせて変更する。例えば、フォーマット4260は、R、G、Bデータ信号を出力することができ、このようなR、G、Bデータ信号は、低い電圧差分信号(Low Voltage Differential Signaling、LVDS)またはmini−LVDSで出力されることができる。また、フォーマット4260は、入力されるフレームレート変換部4255の出力が3D映像信号である場合には、ディスプレイ部の出力フォーマットに合わせて3Dの形態で構成して出力することによって、ディスプレイ部を介して3Dサービスをサポートすることもできる。
一方、制御部内の音声処理部(図示せず)は、逆多重化された音声信号の音声処理を行うことができる。このような音声処理部(図示せず)は、様々なオーディオフォーマットを処理するようにサポートすることができる。一例として、音声信号がMPEG−2、MPEG−4、AAC、HE−AAC、AC−3、BSACなどのフォーマットで符号化された場合にも、これに対応するデコーダを備えて処理できる。
また、制御部内の音声処理部(図示せず)は、ベース(base)、トレブル(treble)、音量調節などを処理することができる。
制御部内のデータ処理部(図示せず)は、逆多重化されたデータ信号のデータ処理を行うことができる。例えば、データ処理部は、逆多重化されたデータ信号が符号化された場合にも、これを復号することができる。ここで、符号化されたデータ信号としては、各チャンネルで放映される放送プログラムの開始時刻、終了時刻などの放送情報が含まれるEPG情報であり得る。
一方、前述したデジタル機器は、本明細書による例であって、各構成要素は、実際に実現されるデジタル機器の仕様によって、統合、追加、または省略され得る。すなわち、必要に応じて、2以上の構成要素が1つの構成要素に合わせられるか、1つの構成要素が2以上の構成要素に細分化され得る。また、各ブロックで行う機能は、本明細書の実施例を説明するためのものであり、その具体的な動作や装置は、本明細書の権利範囲を制限しない。
一方、デジタル機器は、装置内に記憶された映像または入力される映像の信号処理を行う映像信号処理装置であり得る。映像信号処理装置の別の例としては、図41に示しているディスプレイ部4180およびオーディオ出力部4185が除外されたセットトップボックス(STB)、前述したDVDプレーヤ、ブルーレイプレーヤ、ゲーム機器、コンピュータなどがさらに例示され得る。
図43は、一実施例にかかるデジタル機器のスクリーンがメイン映像(main image)と補助映像(sub image)とを同時に表示する一例を示す図である。
一実施例にかかるデジタル機器は、スクリーン4300にメイン映像4310と補助映像4320とを同時に表示できる。メイン映像4310は、第1の映像と呼ばれ、補助映像4320は、第2の映像と呼ばれる。メイン映像4310および補助映像4320は、動画、スチルイメージ、EPG(Electronic Program Guide)、GUI(Graphical User Interface)、OSD(On-Screen Display)などを含み得、これに限定されない。メイン映像4310は、電子装置のスクリーン4300に補助映像4320と同時に表示されながら、電子装置のスクリーン4300より大きさが相対的に小さい映像を意味し得、PIP(Picture In Picture)と称することもある。図43では、メイン映像4310がデジタル機器のスクリーン4300の左側上段に表示されるものとして示されているが、メイン映像4310が表示される位置は、これに限定されず、メイン映像4310は、デジタル機器のスクリーン4300内の任意の位置で表示され得る。
メイン映像4310および補助映像4320は、相互直接または間接的に関連し得る。一例として、メイン映像4310は、ストリーミング(streaming)動画であり、補助映像4320は、ストリーミング動画と類似する情報を含む動画のサムネイル(thumbnail)を順次表示するGUIであり得る。別の例として、メイン映像4310は、放送映像(broadcasted image)であり、補助映像4320は、EPGであり得る。さらに他の例として、メイン映像4310は、放送映像であり、補助映像4320は、GUIであり得る。メイン映像4310および補助映像4320の例は、これに限定されない。
一実施例において、メイン映像4310は、放送チャンネル(broadcasting channel)を介して受信した放送映像(broadcasting image)であり、補助映像4320は、放送チャンネルを介して受信した放送映像に関する情報であり得る。放送チャンネルを介して受信した放送映像に関する情報は、例えば、総合チャンネル編成表、放送プログラムの詳細情報などを含むEPG情報、放送プログラムの再放送情報などを含み得、これに限定されない。
別の一実施例において、メイン映像4310は、放送チャンネルを介して受信した放送映像であり、補助映像4320は、デジタル機器に既に記憶された情報に基づいて生成された映像であり得る。デジタル機器に既に記憶された情報に基づいて生成された映像は、例えば、EPGの基本UI(User Interface)、基本チャンネル情報、映像解像度(resolution)の操作UI、就寝予約UIなどを含み得、これに限定されない。
さらに他の一実施例において、メイン映像4310は、放送チャンネルを介して受信した放送映像であり、補助映像4320は、ネットワーク網を介して受信した放送映像に関する情報であり得る。ネットワーク網を介して受信した放送映像に関する情報は、例えば、ネットワークに基づく検索エンジンを介して獲得された情報であり得る。より具体的に例を挙げると、ネットワークに基づく検索エンジンを介して、現在のメイン映像4310に表示されている登場人物に関する情報が獲得され得る。
しかしながら、例はこれに限定されず、ネットワーク網を介して受信した放送映像に関する情報は、例えば、人工知能(Artificial Intelligence、AI)システムを使用することによって獲得され得る。より具体的に例を挙げると、ネットワークに基づくディープラーニング(deep-learning)を用いて、現在のメイン映像4310に表示されている場所の地図上推定位置(estimated-location in map)が獲得され得、デジタル機器は、ネットワーク網を介して、現在のメイン映像4310に表示されている場所の地図上推定位置に関する情報を受信することができる。
一実施例にかかるデジタル機器は、外部からメイン映像4310の映像情報および補助映像4320の映像情報の少なくとも1つを受信することができる。メイン映像4310の映像情報は、例えば、放送チャンネル(broadcasting channel)を介して受信した放送信号(broadcasting signal)、メイン映像4310のソースコード(source code)情報、ネットワーク網を介して受信したメイン映像4310のIPパケット(internet protocol packet)情報などを含み得、これに限定されない。同様に、補助映像4320の映像情報は、例えば、放送チャンネルを介して受信した放送信号、補助映像4320のソースコード情報、ネットワーク網を介して受信した補助映像4320のIPパケット情報などを含み得、これに限定されない。デジタル機器は、外部から受信したメイン映像4310の映像情報または補助映像4320の映像情報をデコードして用いることができる。ただし、場合によって、デジタル機器は、メイン映像4310の映像情報または補助映像4320の映像情報を内部に自主的に記憶していることもある。
デジタル機器は、メイン映像4310の映像情報および補助映像4320に関する情報に基づいて、メイン映像4310および補助映像4320をデジタル機器のスクリーン4300に表示できる。
一例で、デジタル機器のデコード装置200は、メイン映像のデコード装置および補助映像のデコード装置を含み、メイン映像のデコード装置および補助映像のデコード装置は、それぞれメイン映像4310の映像情報および補助映像4320の映像情報をデコードすることができる。レンダラは、メイン映像のレンダラ(第1のレンダラ)および補助映像のレンダラ(第2のレンダラ)を含み、メイン映像のレンダラは、メイン映像のデコード装置でデコードされた情報に基づいて、メイン映像4310をデジタル機器のスクリーン4300の第1の領域に表示されるようにすることができ、補助映像のレンダラは、補助映像のデコード装置でデコードされた情報に基づいて、補助映像4320をデジタル機器のスクリーン4300の第2の領域に表示されるようにすることができる。
さらに他の例で、デジタル機器のデコード装置200は、メイン映像4310の映像情報および補助映像4320の映像情報をデコードすることができる。デコード装置200でデコードされた情報に基づいて、レンダラは、メイン映像4310および補助映像4320を共に処理して、同時にデジタル機器のスクリーン4300に表示されるようにすることができる。
すなわち、本文書によると、デジタル機器で映像サービス処理方法を提供することができる。上記映像サービス処理方法によると、映像情報を受信する段階と、上記映像情報に基づいて(メイン)映像をデコードする段階と、デコードされた映像をディスプレイ内の第1の領域にレンダリングまたは表示する段階と、ディスプレイ内の第2の領域に補助映像をレンダリングまたは表示する段階と、を含み得る。この場合、第1の映像をデコードする段階は、前述した図3によるデコード装置200におけるデコーディング手続に従うことができる。例えば、前述したように、第1の映像をデコードする段階は、インターまたはイントラ予測に基づいて現ブロックに対する予測サンプルを導出する段階と、受信した残差情報に基づいて現ブロックに対する残差サンプルを導出する段階(省略可能)と、予測サンプルおよび/または残差サンプルに基づいて復元サンプルを生成する段階と、を含み得る。さらに、第1の映像をデコードする段階は、復元サンプルを含む復元ピクチャにインループフィルタリング手続を行うことを含むこともできる。
例えば、上記補助映像は、EPG(Electronic Program Guide)、OSD(On Screen Display)、またはGUI(Graphic User Interface)であってもよい。例えば、上記映像情報は、放送網(broadcast network)を介して受信され、上記補助映像に関する情報は、上記放送網を介して受信されることができる。例えば、上記映像情報は、通信網(communication network)を介して受信され、上記補助映像に関する情報は、上記通信網を介して受信されることができる。例えば、上記映像情報は、放送網を介して受信され、上記補助映像に関する情報は、通信網を介して受信されることができる。例えば、上記映像情報は、放送網または通信網を介して受信され、上記補助映像に関する情報は、上記デジタル機器内の記憶媒体に記憶されていてもよい。
以上で説明された実施例は、本発明の構成要素および特徴が所定の形態で結合されたものである。各構成要素または特徴は、別途の明示的言及がない限り、選択的なものと考慮されるべきである。各構成要素または特徴は、他の構成要素や特徴と結合されない形態で実施され得る。また、一部の構成要素および/または特徴を結合し、本発明の実施例を構成することも可能である。本発明の実施例で説明される動作の順序は変更され得る。いずれかの実施例の一部の構成や特徴は、他の実施例に含まれてもよく、または他の実施例の対応する構成または特徴と代替され(交替し)得る。特許請求の範囲で明示的な引用関係がない請求項を結合して実施例を構成するか、出願後の補正によって新しい請求項に含め得ることは自明である。
本発明にかかる実施例は、様々な手段、例えば、ハードウェア、ファームウェア(firmware)、ソフトウェアまたはそれらの結合などにより実現され得る。ハードウェアによる実現の場合、本発明の一実施例は、1つまたは複数のASICs(Application Specific Integrated Circuits)、DSPs(Digital Signal Processors)、DSPDs(Digital Signal Processing Devices)、PLDs(Programmable Logic Devices)、FPGAs(Field Programmable Gate Arrays)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現され得る。
ファームウェアやソフトウェアによる実現の場合、本明細書の一実施例は、以上で説明された機能または動作を行うモジュール、手続、関数などの形態で実現され得る。ソフトウェアコードは、メモリに記憶され、プロセッサによって駆動され得る。上記メモリは、上記プロセッサの内部または外部に位置し、既に公知となった多様な手段により上記プロセッサとデータをやり取りすることができる。
本発明は、本発明の必須的特徴を外れない範囲で、他の特定の形態で具体化できることは当業者にとって自明である。したがって、前述した詳細な説明は、全ての面で制限的に解釈されてはならず、例示的なものと考慮されるべきである。本発明の範囲は、添付された請求項の合理的解釈によって決定されなければならず、本発明の等価的範囲内における全ての変更は、本発明の範囲に含まれる。