JP6588441B2 - 符号化ビットストリームにおける動きベクトルの提示 - Google Patents

Description

最近の通信システムでは、ビデオ信号は、有線及び／又は無線ネットワークのような媒体を介して、しばしばインターネットのようなパケットベースのネットワークを介してある端末から別の端末へ送信され得る。例えばビデオは、デスクトップやラップトップコンピュータ、タブレット又はスマートフォンのようなユーザ端末において実行されるVoIP（ボイスオーバーインターネットプロトコル）クライアントアプリケーションから実施されるVoIP呼の一部であり得る。

典型的に、ビデオのフレームは、ネットワーク上での転送のためにこれらのフレームを圧縮するよう、送信端末にあるエンコーダによって符号化される。所与のフレームの符号化は、イントラフレーム符号化を備えることがあり、イントラフレーム符号化により、ブロックが同じフレーム内の他のブロックとの相対で符号化される。この場合、ターゲットブロックは、そのブロックと近傍ブロックとの間の差（残差）に関して符号化される。あるいは、一部のフレームについての符号化は、インターフレーム符号化を備えることがあり、インターフレーム符号化により、ターゲットフレーム内のブロックが、典型的には動き予測に基づいて、先行フレームの対応する部分との相対で符号化される。この場合、ターゲットブロックは、そのブロックと予測が行われる対応する部分との間のオフセット、及び、そのブロックと予測が行われる対応する部分との間の差（残差）を識別する動きベクトルに関して符号化される。レシーバにおける対応するデコーダは、デコーダ側のスクリーンへの出力のためフレームを圧縮解除するよう、受け取ったビデオ信号のフレームを適切なタイプの予測に基づいて復号する。

ビデオを符号化（圧縮）するとき、動きベクトルを使用して、現在のフレームのインターフレーム予測を生成する。エンコーダは最初に、現在のブロック（ターゲットブロック）に最も良く合致する以前の符号化フレーム内で類似ブロック（参照ブロック（reference block））を探し、参照ブロックとターゲットブロックとの間の変位を、符号化ビットストリームの一部としてデコーダへ信号伝達する。変位は典型的に、水平及び垂直のｘ及びｙ座標として表され、動きベクトルと呼ばれる。

参照「ブロック」は、実際には、参照フレーム内の実際のブロック位置にあることに制約されない。すなわち、参照ブロックは、ターゲットブロックと同じグリッドに制限されず、むしろ、動きベクトルによる、ターゲットブロックの位置に対する参照フレームのオフセットの対応するサイズの部分（correspondingly-sized portion）である。現在の規格によると、動きベクトルは、分数のピクセル解像度（fractional pixel resolution）で表される。例えばH.264規格では、各動きベクトルは、１／４ピクセル解像度で表される。したがって、例として現在のフレーム内の１６×１６ブロックを、ターゲットブロックの位置の１ピクセル左にある以前のフレーム内の１６×１６フレームから予測する場合、動きベクトルは（４，０）である。あるいは、ターゲットブロックを、例えばターゲットブロックの左にわずか３／４ピクセルにある参照ブロックから予測する場合、動きベクトルは（３，０）である。分数のピクセル位置にある参照ブロックは、実際にはそれ自体は存在していないが、参照フレームのピクセル間の補完によって生成される。サブピクセルの動きベクトルは、圧縮効果に関してかなりのパフォーマンスを達成することができる。

しかしながら、分数のピクセル解像度を使用することは、動きベクトルを符号化するために、動きベクトルを整数のピクセル解像度で推定した場合よりも多くのビットを伴い、また、最も良く合致する参照を探す際にもより多くの処理リソースを伴う。例えばビデオ符号化では、例えば縮小されたサイズのより良く合致する残差は、一般に、動きベクトルの符号化に生じるビットよりも重要である可能性があり、あるいは達成される品質は、そのリソースを正当化すると考えることができるので、これは価値のあることであり得る。しかしながら、符号化される必ずしもすべての動画像がビデオ（すなわちカメラからキャプチャされる）とは限らない。本明細書では、カメラではなく画面からキャプチャされる動画像を符号化（圧縮）するとき、符号化ビットストリーム内の動きベクトルの大部分は概して整数ピクセルを指すが、これらの動きベクトルのうちのほんの一部が分数のピクセル部分で見つかる傾向があることを認識している。したがって、エンコーダは通常、１／４ピクセルの単位でビットストリーム内の動きベクトルを表すが、画面共有又は記録アプリケーションでは、実際には、１ピクセル単位のみで動きベクトルを符号化することによって、必要以上の品質損失を伴わずに、帯域幅を確保することができる。

それでもなお、分数の動きベクトルが（カメラによってキャプチャされる）通常のビデオ、恐らくは他の動画像（例えばアニメーション）にとって依然として有益である可能性があることを考えると、動きベクトルは柔軟な方法で信号伝達され得る：ビデオソースが、キャプチャされた画面からのものであるとき、動きベクトルは１ピクセル単位で信号伝達され得るが、通常のビデオ及び／又は他の動画像については、依然として分数のピクセル単位（fractional pixel unit）を使用してもよい。

より一般的には、例えばどのようにデコーダの設計者が任意の所望のトレードオフ又は効果を実装するよう望むかに依存して、分数又は整数ピクセルの動きベクトルの解像度を使用するかどうかに対する制御を持つのに有益であり得る、様々な環境が存在し得る。例えば恐らくは一部のビデオ又はアニメーションは、その性質の何らかの側面に起因して、動き推定において整数ピクセル解像度によって、より効果的に供給されることになり、一方、他のビデオや他のタイプの動画は、分数ピクセル解像度によって、より効果的に供給されることがある。

したがって、本明細書で開示される一側面によると、動画データを符号化する際に使用するためのフォーマットが提供され、これにより、そのフォーマットに従って符号化される動画データは、下記を備える：
− 少なくとも１つの領域が動き推定を使用して符号化されている複数のフレームを含む、一連のフレームと；
− これらのフレームのそれぞれ各１つについて、又はこれらのフレームの各フレーム内の１つ以上の領域のそれぞれ各１つについて、動き推定の動きベクトルを表す動きベクトル値のそれぞれのセットと；
− それぞれのフレーム又は領域のそれぞれの動きベクトル値が第１の解像度で符号化されているか又は第２の解像度で符号化されているかを示す、それぞれのフレーム又は領域の各々に関連付けられる少なくとも１つのそれぞれのインジケータ。

動きベクトル値は、第１の解像度で符号化される動きベクトル値が、より多くの数のより精細なステップ（finer step）を有するスケールで表され、第２の解像度で符号化されるベクトル値が、より少ない数のより粗いステップ（coarser step）を有するスケールで表されて、符号化ビットストリーム内で平均してより少ないビット数を要する、というプロトコルに従って符号化される。より粗いステップは、整数ピクセル単位を表し、より精細なステップは、分数ピクセル単位を表す。

本明細書で開示される更なる側面によると、上記フォーマット又はプロトコルに従って符号化される動画データのビットストリームを担持するネットワーク要素又はコンピュータ読取可能記録媒体が提供される。

実施形態において、複数のフレーム又は領域のうち第１の解像度で符号化されたフレーム又は領域と、複数のフレーム又は領域のうち第２の解像度で符号化された他のフレーム又は領域とを備えるビットストリームを提供することができ、それぞれのインジケータは、複数の（インターフレーム符号化された）フレーム又は領域の各々について個々に解像度を指示する。

実施形態において、各フレーム又は領域の動きベクトル値の各々は、符号化ビットストリーム内の動きベクトルフィールドに含まれてもよく、上記プロトコルによると、動きベクトルフィールドは、その動きベクトルが第２の解像度で符号化されるフレーム又は領域について、減少されたサイズを有することがある。

本明細書で開示される別の態様によると、符号化形式の動画データを受け取るための入力部と、動き予測モジュールとを備えるデコーダが提供される。動画データは、本明細書で開示される実施形態のいずれに係るフォーマット又はプロトコルに基づいて、少なくとも１つの領域が動き推定を使用して符号化されている複数のフレーム（すなわち、インターフレーム符号化されたフレーム）を含む。動き予測モジュールは、動きベクトル値に基づいて、（インターフレーム符号化された）フレーム又は領域を復号する。これは、インジケータの各々を読み取って、それぞれのフレーム又は領域の動きベクトル値が第１の解像度で符号化されているか、第２の解像度で符号化されているかを判断し、第１の解像度の場合、動きベクトル値を分数ピクセル単位で解釈し、第２の解像度の場合、動きベクトル値を整数ピクセル単位で解釈することを含む。

実施形態においては、動画データは、フレーム又は領域の各々に関連付けられる２つのそれぞれのインジケータを備え、該２つのインジケータは、二次元のそれぞれの動きベクトルの解像度を示し、動き予測モジュールは、両インジケータを読み取り、それに従ってそれぞれの動きベクトル値を解釈するように構成される。

実施形態において、フレームの少なくとも一部の各々は、複数の領域に分割され；動画データは、複数の領域のそれぞれ各１つの領域の動きベクトル値が第１の解像度で符号化されているか、第２の解像度で符号化されているかを個々に示す、複数の領域のそれぞれ各１つの領域に関連付けられる少なくとも１つのそれぞれのインジケータを備え；動き予測モジュールは、インジケータを読み取って、各それぞれの領域の動きベクトル値が第１の解像度で符号化されているか、第２の解像度で符号化されているかを判断し、それに従ってそれぞれの動きベクトル値を分数ピクセル単位又は整数ピクセル単位で解釈するように構成される。実施形態において、領域は、H.26x規格のスライスである。

実施形態において、動画データは、動きベクトル値の解像度が領域ごとに指示されているか又はフレームごとに指示されているかを設定する設定（setting）を更に備え、動き予測モジュールは、設定を読み取って、それに従って動きベクトル値を解釈するように構成される。

実施形態において、動き予測モジュールは、それぞれのインジケータがフレーム又は領域の１つについて存在しない場合、デフォルトとして、それぞれの動きベクトル値を分数ピクセル単位で解釈するように構成される。

また更なる実施形態では、動きベクトルを含む動画データは更に、可逆符号化技術に従って符号化され得る。デコーダは、動き予測モジュールによる復号に先行する、可逆符号化段階の逆を備え得る。

更なる側面によると、コンピュータ読取可能記録媒体上に具現化され、実行されると、本明細書に開示される実施形態のいずれかに係るデコーダの動作を実行されるように構成されるコンピュータプログラム製品が提供される。

この発明の概要は、以下の発明の詳細な説明において更に説明される概念の選択を簡単な形で紹介するために提供される。この発明の概要は、特許請求に係る主題の主要な特徴又は本質的な特徴を特定するようには意図されておらず、特許請求に係る主題の範囲を限定するよう使用されることも意図されていない。特許請求に係る主題は、本明細書で指摘される欠点のいずれか又は全てを解決する実装にも限定されない。

本開示の理解を助け、実施形態を実施する方法を示すために、例として添付の図面への参照を行う。

ビデオストリームの概略的な表現である。

通信システムの概略的なブロック図である。

符号化ビデオストリームの概略的な表現である。

エンコーダの概略的なブロック図である。

デコーダの概略的なブロック図である。

インターフレーム符号化スキームの概略的な表現である。

別のインターフレーム符号化スキームの概略的な表現である。

図１は、カメラからキャプチャされ、符号化ビットストリームを生成するようビデオエンコーダによって符号化される空間区分（spatial division）に分割される、入力ビデオ信号の概略図を提供する。信号は、時間で複数のフレーム（F）に分割されるビデオ動画を備え、各フレームは、時間内のそれぞれ異なる瞬間（…t-1、t、t+1…）における画像を表す。各フレーム内では、フレームは、各々が複数のピクセルを表す複数の区分へ空間で分けられる。これらの区分は、ブロックとも呼ばれる。特定のスキームでは、フレームは、異なるブロックレベルに分割及びサブ分割される。例えば各フレームはマクロブロック（MB）に分割され、各マクロブロックはブロック（b）に分割され得る。例えば各ブロックは、フレーム内の８×８ピクセルの領域を表し、各マクロブロックは、２×２ブロック（１６×１６ピクセル）の領域を表す。特定のスキームでは、各フレームを、独立に復号可能なスライス（S）へ分割することもでき、各スライスが複数のマクロブロックを備える。スライスSは、一般に任意の形状を取ってよく、例えば各スライスはマクロブロック内の１つ以上の行とすることができ、あるいは（例えば画像内の関心領域ROIに対応する）マクロブロックのイレギュラーな又は任意に定義される選択である。

「ピクセル」という用語に関して、以下では、この用語は、ピクチャアレイのサンプリンググリッド内のサンプル及びサンプリング位置を示すのに使用される（文献では時々、代わりに、「ピクセル」という用語を使用して、１つの単一の空間的位置に対応する３つの色成分すべてを指し、時々、単一のアレイ内の単一の位置又は単一の整数サンプル値を指すのに使用される）。サンプリンググリッドの解像度は、ルマ・サンプリングアレイとクロマ・サンプリングアレイとの間で異なることが多い。実施形態では、以下は、４：４：４表現に適用され得るが、潜在的には、例えば４：２：２及び４：２：０にも適用され得る。

任意の所与の規格はブロック又はマクロブロックという用語に特有の意味を与えるが、ブロックという用語は、多くの場合、当技術分野ではより一般的に、イントラ予測又はインター予測のような符号化及び復号動作が実行されるレベルにおけるフレームの区分を指すことにも使用され、そうでないことが特に記載されない限り、本明細書で使用されることになるのは、このより一般な意味であることに留意されたい。例えば本明細書で参照されるブロックは、実際には、H.26x規格ではブロック又はマクロブロックと呼ばれる区分である可能性があり、様々な符号化及び復号段階は、渦中の符号化モード、アプリケーション及び／又は規格に適切であるように、任意のそのような区分のレベルで動作することができる。

キャプチャされる入力信号内のブロックは、通常、空間領域で表され、各色空間チャネルは、ブロック内の空間位置に応じて表される。例えばYUV色空間では、ルミナンス（Y）及びクロミナンス（U,V）チャネルの各々を、デカルト座標x及びyの関数として表すことができる：Y（x,y）、U（x,y）及びV(x,y)。あるいはRGB色空間では、赤（R）、緑（G）及び青（B）チャネルの各々を、デカルト座標の関数として表すことができる：R（x,y）、G（x,y）及びB(x,y)。この表現では、色空間の各チャネルがピクセル位置の別個のセットの各々におけるそのチャネルのそれぞれの規模に関して表されるように、各ブロック又は部分は、異なる空間座標、例えばx及びy座標おけるピクセル値のセットによって表される。

しかしながら、量子化に先行して、ブロックを、符号化プロセスの一部として変換領域表現に、典型的には空間周波数領域表現（時々、単に周波数領域とも呼ばれる）に変換することができる。周波数領域では、ブロック内の各色空間チャネルは、二次元のうちの各次元で空間周波数の関数（１／長さの次元）として表される。例えばこれを、それぞれ水平及び垂直方向における波数k_x及びk_yによって示すことができ、その結果、チャネルを、YUV空間ではY（k_x,k_y）、U（k_x,k_y）及びV（k_x,k_y）として表し、RGB空間ではR（k_x,k_y）、G（k_x,k_y）及びB（k_x,k_y）として表すことができる。したがって、ピクセル位置の別個のセットの各々における規模に関して色空間チャネルを表す代わりに、変換は、ブロックを形成する空間周波数成分の別個のセットの各々に関連付けられる係数に関して、すなわちブロックにわたる空間変動の異なる周波数に対応する空間周波数項（term）の別個のセットの各々の振幅に関して、各色空間チャネルを表す。そのような変換の可能性は、フーリエ変換、離散コサイン変換（DCT）、カルーネン・レーベル変換（KLT）又は他のものを含む。

図２のブロック図は、本開示の技術を用いることができる通信システムの例を提供する。通信システムは、第１の送信端末１２と、第２の受信端末２２を備える。例えば各端末１２、２２は、携帯電話又はスマートフォン、タブレット、ラップトップコンピュータ、デスクトップコンピュータ、あるいはテレビジョンセット、セットトップボックス、ステレオシステム等のような他の家庭用機器のうちの１つを備え得る。第１及び第２の端末１２、２２はそれぞれ通信ネットワーク３２に動作可能に結合され、これにより第１の送信端末１２は、第２の受信端末２２によって受信されることになる信号を送信するように構成される。当然、送信端末１２は、受信端末２２から信号を受信する能力も有することができ、またその逆もあり得るが、説明の目的で、本明細書では送信については第１の端末１２の観点から説明し、受信については第２の端末２２の観点から説明する。通信ネットワーク３２は、例えばワイドエリアインターネット及び／又はローカルエリアネットワークのようなパケットベースのネットワーク、並びに／あるいは携帯電話ネットワークを備え得る。

第１の端末１２は、フラッシュメモリ若しくは他の電子メモリ、磁気ストレージデバイス及び／又は光ストレージデバイスのようなコンピュータ読取可能記録媒体１４を備える。第１の端末１２は、１つ以上の実行ユニットを有するプロセッサ又はCPUの形の処理装置１６、トランスミッタ（Tx）１８を有する有線又は無線モデムのようなトランシーバ、ビデオカメラ１５及び画面１７（すなわち、ディスプレイ又はモニタ）も備える。カメラ１５及び画面１７の各々は、端末１２の残りの部分として同じケーシング内に収納されてもよく、あるいは収納されなくてもよい（さらにトランスミッタ１８は内蔵であっても外付けであってもよく、例えば後者の場合にはドングル又は無線ルータを備える）。記録媒体１４、ビデオカメラ１５、画面１７及びトランスミッタ１８はそれぞれ、処理装置１６に動作可能に結合され、トランスミッタ１８は、有線又は無線リンクを介してネットワーク３２に動作可能に結合される。同様に、第２の端末２２は、電子、磁気及び／又は光ストレージデバイス等のようなコンピュータ読取可能記録媒体２４と、１つ以上の実行ユニットを有するCPUの形の処理装置２６を備える。第２の端末は、少なくともレシーバ（RX）２８を有する有線又は無線モデムのようなトランシーバと、端末２２の残りの部分として同じケーシング内に収納されても、収納されなくてもよい画面２５を備える。第２の端末の記録媒体２４、画面２５及びレシーバ２８は各々、それぞれの処理装置２６に動作可能に結合され、レシーバ２８は有線又は無線リンクを介してネットワーク３２に動作可能に結合される。

第１の端末１２上のストレージ１４は、動画データを符号化するために少なくともエンコーダを格納する。エンコーダは、それぞれの処理装置１６上で実行されるよう構成される。実行されると、エンコーダは、ビデオカメラ１５から「生の」（符号化されていない）入力ビデオストリームを受け取り、このビデオストリームを、より低ビットレートのストリームに圧縮するように符号化するよう動作可能であり、トランスミッタ１８及び通信ネットワーク３２を介して第２の端末２２のレシーバ２８へ送信するために符号化ビデオストリームを出力する。第２の端末２２上のストレージ２４は、自身の処理装置２６上で実行されるよう構成されるビデオデコーダを少なくとも格納する。実行されると、デコーダは、レシーバ２８から符号化ビデオストリームを受け取り、画面２５への出力のためにこの符号化ビットストリームを復号する。

エンコーダ及びデコーダは、画面共有ストリームを含め、他のタイプの動画データを符号化及び復号するようにも動作可能である。画面共有ストリームは、符号化側で画面１７からキャプチャされる画像データであり、これにより、１以上の他のリモートのユーザは、符号化側のユーザが画面上で何を見ているかを知ることができ、あるいはその画面のユーザは、１人以上の他のユーザに対して後に再生するために、画面上で起こっていることを記録することができる。送信端末１２と受信端末２２との間で実施される呼の場合、送信端末１２の画面１７の動画コンテンツ（moving content）が、受信端末２２の画面２５上で復号及び表示されるように、ライブ（リアルタイム）で符号化されて送信されることになる。例えばエンコーダ側のユーザは、そのユーザがオペレーティングシステムのデスクトップ又は何らかのアプリケーションをどのように動かしているかを、別のユーザと共有したいことがある。

画面共有ストリームが画面等からキャプチャされると言う場合、これは、そのようにするための任意の特定の機構に限定しないことに留意されたい。例えばデータは、画面１７の画面バッファから読み取られる可能性があり、あるいはデータは、画面１７における表示のためにオペレーティングシステムから又はアプリケーションから出力される同じグラフィカルデータのインスタンスを受け取ることによって、キャプチャされる可能性がある。

図３は、送信端末１２上で動作しているエンコーダから受信端末２２上で動作しているデコーダへ送信されるであろう符号化ビットストリーム３３の概略的な表現を提供する。ビットストリーム３３は、フレーム又はスライスごとに符号化済み画像データ３４を備え、符号化済み画像データ３４は、任意の関連する動きベクトルとともに、そのフレーム又はスライスのブロックについての符号化サンプルを備える。一適用では、ビットストリームは、送信端末１２と受信端末２２との間のVoIP呼のような、ライブ（リアルタイム）の呼の一部として伝送され得る（VoIP呼は、ビデオ及び画面共有も含むことができる）。ビットストリーム３３は、各フレーム又はスライスに関連付けられるヘッダ情報３６も備える。実施形態では、ヘッダ３６は、以下でより詳細に説明されるように、少なくとも１つのフラグ３７の形で、動きベクトルの解像度を示す少なくとも１つの追加の要素を含むように構成される。

図４は、送信端末１２上で実装されるような、エンコーダを示すブロック図である。エンコーダは、離散コサイン変換（DCT）モジュール５１、量子化器（Q）５３、逆変換モジュール６１、逆量子化器６３、イントラ予測モジュール４１、インター予測モジュール４３、スイッチ４７、減算段階（−）４９及び可逆符号化段階６５を備える主符号化モジュール４０を備える。エンコーダは更に、インター予測モジュール４３に結合される制御モジュール５０を備える。これらのモジュール又は段階の各々は、送信端末の記録媒体１４上に格納され、その処理装置１６における実行のために構成されるコードの一部として実装され得るが、これらの一部又は全てが全体又は部分的に専用のハードウェア回路内で実装される可能性は除外されない。

減算段階４９は、複数のフレーム（F）にわたる複数のブロックを備える入力信号のインスタンスを受け取るように構成される。入力ストリームは、カメラ１５から受け取られるか、画面１７上に表示されているものからキャプチャされる。イントラ又はインター予測４１、４３は、別の既に符号化されているブロック又は対応するサイズの参照部分からの予測に基づいて、符号化されるべき現在の（ターゲット）ブロックの予測バージョン（predicted version）を生成する。予測バージョンは、減算段階４９の入力に供給され、減算段階４９では、空間領域の入力信号（すなわち、実際の信号）から減算されて、ブロックの予測バージョンと、実際の入力信号内に対応するブロックとの間の差を表す残差信号が生成される。

イントラ予測モードでは、イントラ予測４１は、同じフレームの別の既に符号化されているブロック、典型的には近傍ブロックからの予測に基づいて、符号化されるべき現在の（ターゲット）ブロックの予測バージョンを生成する。イントラフレーム符号化を実行するときは、フレーム内の画像データの或る部分が、同じフレーム内の別の部分とどのように異なるかについての指標（measure）のみを符号化して送信することがその狙いである。次いで、その部分を（開始する何らかの絶対データ（absolute data）を所与として）デコーダで予測することができ、したがって、その実際のデータ自体ではなく、予測と実際のデータとの間の差を送信すれば良いだけである。差分信号は典型的に、大きさがより小さいので、符号化にかかるビットはより少ない（これは可逆圧縮段階６５の動作に起因する−以下を参照されたい）。

インター予測モードでは、インター予測モジュール４３は、現在のブロックとは異なるフレームの別の既に符号化されている参照部分からの予測に基づいて、符号化されるべき現在の（ターゲット）ブロックの予測バージョンを生成する。参照部分は、ブロックのサイズを有するが、インター予測モジュール４３によって予測される、動きベクトルによる空間領域内のターゲットブロックに対するオフセットである（インター予測は、動き予測又は動き推定と呼ばれることもある）。インター予測モジュール４３は、空間領域内において、ターゲットフレーム以外の１つ以上のフレーム内のそれぞれの可能性のある複数の動きベクトルによってオフセットされる複数の候補参照部分を検索し、適切なメトリックに従ってターゲットブロックに対して残差を最小にする候補を選択することによって、所与のターゲットブロックについて最適な参照を選択する。インター予測モジュール４３は、スイッチ４７により、イントラフレーム予測段階４１の代わりにフィードバック経路へ切り替えられ、したがって、イントラフレームを他のフレームのものに対して符号化するために、あるフレームと別のフレームのブロックの間にフィードバックループが作成される。すなわち、残差はここでは、インター予測ブロックと実際の入力ブロックとの間の差を表す。これは典型的に、イントラフレーム符号化よりも、符号化すべきビットはより少ない。
する。

残差信号（予測が入力信号から減算された後の残差ブロックを備える）は、減算段階４９から、残差値を周波数領域に変換する変換（DCT）モジュール５１（又は他の適切な変換）を通って、変換された値を実質的に離散量子化インデックス（discrete quantization indices）に変換する量子化器５３へと出力される。変換モジュール５１及び量子化モジュール５３によって生成される残差の量子化されて変換されたインデックス、並びに予測モジュール４１、４３において使用される予測の指示及びインター予測モジュール４３によって生成される任意の動きベクトルは、すべて、符号化ビデオストリーム３３に含まれるように出力されるが（図３の要素３４を参照されたい）、その際に、ゴロムエンコーダ又はエントロピーエンコーダ等の可逆符号化段階６５を更に経由し、この可逆符号化段階６５において、動きベクトル及び変換及び量子化されたインデックスが、当技術分野で公知の可逆符号化技術を使用して更に圧縮される。

量子化されて変換された信号のインスタンスはまた、逆量子化器６３及び逆変換モジュール６１を通ってフィードバックされ、以前に符号化されたブロックの逆量子化及び逆変換されたバージョンに基づいて、符号化されている現在のターゲットブロックを予測した方法と同じ方法で、符号化されるべき後続のブロックを予測する際に、選択された予測モジュール４１又は４３により使用するために、（デコーダにおいて見られるような）ブロックの予測バージョンを生成する。スイッチ４７は、現在符号化されているフレーム又はブロックに使用される符号化に適切であるように、逆量子化器６３の出力をイントラ予測モジュール４１又はインター予測モジュール４３のいずれかの入力へ渡すように構成される。

図５は、受信端末２２上で実装され得るようなデコーダを例示するブロック図である。デコーダは、可逆符号化の逆９５と、逆量子化段階８３と、逆DCT変換段階８１と、スイッチ７０と、イントラ予測段階７１及び動き補償段階７３を備える。これらのモジュール又は段階の各々は、受信端末の記録媒体２４上に格納され、その処理装置２６における実行のために構成されるコードの一部として実装され得るが、これらの一部又は全てが全体又は部分的に専用のハードウェア回路内で実装される可能性は除外されない。

逆量子化器８３は、符号化信号３３を、エンコーダからレシーバ２８及び逆の可逆符号化段階９５を介して受け取るように構成される。逆量子化器８３は、符号化信号内の量子化インデックスを、（残差ブロックを備える）残差信号の逆量子化（de-quantize）されたサンプルへと変換し、逆量子化されたサンプルを、逆DCTモジュール８１に渡し、逆DCTモジュール８１では、これらのサンプルを、周波数領域から空間領域へと戻すよう変換する。スイッチ７０は次いで、逆量子化された空間領域残差サンプルを、復号されている現在のフレーム又はブロックに使用される予測モードに適切であるように、イントラ予測モジュール７１又はインター予測モジュール７３に渡し、イントラ予測モジュール７１又はインター予測モジュール７３はそれぞれ、イントラ又はインター予測を使用してブロックを復号する。どのモードを使用すべきかは、符号化ビットストリーム３３内の符号化サンプル３４とともに受け取られる任意の動きベクトル及び／又は予測の指示を使用して決定される。この段階から続いて、復号されたブロックが出力され、受信端末２２における画面２５を通して再生されるようになる。

説明したように、従来の規格に従うコーデックは、四分の一のピクセルの解像度で動き予測を実行し、これは、動きベクトルが四分の一のピクセルステップに関して表されることも意味する。四分の一のピクセル解像度の動き推定の例が図６に示されている。この例では、ターゲットブロックの左上の角にあるピクセルpが、ピクセルa、b、c及びdの間の補完から予測され、ターゲットブロックの他のピクセルも、あるフレームのターゲットブロックと、他のフレーム内の参照部分との間のオフセットに従って、参照フレーム内のピクセルのそれぞれのグループ間の同様の補完に基づいて予測されることになる（これらのブロックは図６では太字の破線で示されている）。しかしながら、以下に説明されるように、この粒度で動き推定を実行することは重要性を有する。

可逆コーダ６５及びデコーダ９５を参照すると、可逆符号化は、（量子化のように）情報を捨てることによるのではなく、可逆符号化段階６５によって符号化されることになるデータ内で、異なる値が生じる可能性がどの程度か又はどの程度頻繁に生じるかに応じて、異なる長さのコードワードを使用して異なる値を表することによって機能する、圧縮形式である。例えばコードワード内で１にぶつかる前の先頭の０の数は、コードワードの長さを示し、したがって、１が最も短いコードワードであり、０１０、０１１が次に短く、その後に００１００等と続いていくことになる。したがって、最も短いコードワードは、均一のコードワード長を使用した場合に必要とされることになる長さよりもかなり短いが、最も長いものはそれよりも長い。しかし、最も頻繁な値又は最も可能性の高い値を最も短いコードワードに割り当て、最も可能性が低い又は生じる頻度が最も少ない値のみを長いコードワードに割り当てることによって、結果として得られるビットストリーム３３は、均一のコードワード長を使用した場合よりも、符号化される値ごとに必要とするビット数は少なく、したがって、いずれかの更なる情報を破棄する必要なしに、圧縮を達成することができる。

可逆符号化段階６５に先行するエンコーダ４０の多くは、可逆符号化段階６５を通過する前に、できるだけ多くの値を可能な限り小さくするように設計される。値がより頻繁に生じると、より小さな値は、より大きな値よりも符号化ビットストリーム３３内において低いビットレートを招くことになる。これが、絶対サンプル（absolute sample）とは対照的に残差を符号化する理由である。また、多くのサンプルが変換領域のゼロ又は小さな係数へと変換する傾向があるので、これは変換５１の背後にある根拠でもある。

同様の検討を、動きベクトルの符号化に適用することができる。

例えばH.264/MPEG-4 Part10及びH.265/HEVCでは、動きベクトルは、指数ゴロム符号で符号化される。以下の表は、動きベクトル値及び符号化ビットを示す。
値 コードワード 発生するビット数
０ １ １
１ ０１０ ３
２ ０１１ ３
３ ００１００ ５
４ ００１１１ ５
５ ０００１０００ ７
・・・

上記の表から、値が大きいほど、より多くのビットが使用されることがわかる。これは、動きベクトルの解像度がより高いほど、より多くのビットが必要とされることを意味する。例えば四分の一のピクセル解像度では、１ピクセルのオフセットは、値４で表さなければならず、符号化ビットストリームの５ビットを必要とする。

（カメラからキャプチャされる）ビデオの符号化では、より精細な解像度が、より低いコストの残差参照の検索においてより良い機会を提供するので、動きベクトルにおけるこの解像度のコストは、価値がある可能性がある。しかしながら、ここでは、画面からキャプチャされる動画について、空間変位の大部分が、フルピクセル変位となる傾向があり、これらのほんの一部が分数ピクセル位置となる傾向があるので、動きベクトルの大部分が、整数のピクセル値を指す傾向があり、分数ピクセル値を指すものは非常に少ないことが観察される。

そのような基準において、１ピクセル解像度の画面からキャプチャされる画像データの動きベクトルを符号化することが望ましいことがある。そのようなコンテンツについて動きベクトルの分数部分（端数部分（fractional parts）に対してビットを費やす必要がないという事実を考慮すると、これは、そのようなコンテンツを符号化する際に必要とされるビットレートを減らすことができることを意味する。

例えばエンコーダは通常、１／４ピクセルのオフセット単位でビットストリーム内の動きベクトルを解釈するが、エンコーダは実際には、しばしば、この解像度を諦めて、代わりに、画像符号化アプリケーションの動きベクトルを整数のピクセルオフセット単位で符号化することによって、ビットレートを節約することが可能である。動きベクトルの精度を４倍減らすことになるが、そのような精度は一般に、画面共有又は記録アプリケーションにとっては価値が低く、また、これはベクトルを符号化するのに必要なビット数を減らす。現在の（ターゲット）ブロックを、そのターゲットブロックの１ピクセル左の参照ブロックから予測するために、動きベクトルは（4,0）の代わりに（1,0）となるであろう。上記のゴロム符号化を使用すると、これは、動きベクトルを符号化するために必要とされるビットが、（00111,1）から（010,1）に変化し、したがってこの場合、２ビットが節約されることを意味する。

さらに、減少した解像度の動きベクトルは、動きベクトルの検索を整数値に制限し、したがって検索によって発生する処理リソースを減らすことによって、エンコーダにおいて実行される動き推定の複雑性も減らすことができる。あるいは、通常の検索を実行して、結果として得られる動きベクトルを丸めて整数値にすることも可能であろう。

図７は、全体のピクセルの解像度のみに制約される動き予測の例を示す。この場合、動きベクトルは、全体のピクセルステップのみに制約される。図６とは対照的に、ピクセルpは、補間なしに単一の全体のピクセルのみから予測される。あるいは、（やはり太い破線で示される）あるフレーム内のターゲットブロックと、他のフレーム内に参照部分との間のオフセットに応じて、ピクセルb、c、d又は別のピクセルから予測された可能性もあるが、制約に起因して、ピクセル間の補完からは予測することはできない。なお、任意の所与のブロックについて、図６の例に図示されるような四分の一ピクセル予測は、最も低い残差を与えた場合、偶然に、補間を伴わない全体的なピクセルオフセットを生成する可能性があることに留意されたい。しかしながら、そのようにすることには制約されず、サイズ調整可能な画像に対して、それがすべてのブロックについて起こることは全くありそうにないことである。

分数の動きベクトル値が、カメラキャプチャされたコンテンツにとってやはり非常に有益な可能性があることを考えると、諸実施形態において、エンコーダ４０に、動き予測モジュール４３と結合されるコントローラ５０を提供する。コントローラ５０は、柔軟な方法で動きベクトルの解像度を選択するように構成され、ソースデータが、キャプチャされた画面１７からのものであり、分数のピクセル動きが存在しないとき、動きベクトルを、全体のピクセル単位のみで符号化して送信するが、カメラコンテンツのビデオについては、やはり動きベクトルを分数のピクセル精度で符号化して送信する。

これを行うために、コントローラ５０は、キャプチャされているコンテンツのタイプが画面コンテンツであるという事実を示す、性能ヒューリスティックを測るように構成され得る。それに応じて、次いで、画面コンテンツ符号化のために分数ピクセル動き補償を無効にする。あるいは、コントローラ５０は、符号化のためにエンコーダに供給しているのはどのタイプのデータであるかに関して、アプリケーション又はオペレーションシステムから指示を受け取ることがあり、コントローラ５０は、これに基づいてモード間を選択することができる。別のオプションとして、履歴データに基づいてその選択を行うことができる。選択は１フレームごとに行うことができ、あるいは、モードは、フレーム内の異なる領域について個々に、例えば１スライスごとに個々に選択されてもよい。

したがって、フレーム又はスライスを符号化する前に、エンコーダは、履歴統計データ、そのタイプのアプリケーションの知識、マルチパス分析又は何らかの他のそのような技術等のファクタに基づいて、動きベクトル解像度を決めることができる。エンコーダが、フルピクセルの動き推定のみを使用すると決めた場合、分数のピクセル検索はスキップされる。スケーリングされた動きベクトル予測が分数部分を有する場合、予測は整数値に丸められてよい。

更なる実施形態では、コントロールは、任意選択で、ベクトルの垂直成分又は水平成分に対して個別に適用されてもよい。これは、水平又は垂直にスケーリングされる画面ビデオの符号化にとって有益であり得る。例えばエンコーダが、水平又は垂直にサイズ変更される画面共有と連動している場合を考える。この場合、動きベクトルの成分の一方が分数部分を有し、他方の成分は有しないことになる。ビットレートを制御するため、エンコーダは、所定の範囲内で量子化パラメータ（QP）を調整することができる。QPが、許容される上限に到達しており、ビットレートがまだ高すぎる場合。エンコーダは内部サイズ調整器（internal resizer）をトリガすることができる。これは、入ってくるピクチャを垂直にサイズ調整し、デコーダ側では、復号されるピクチャは、元の幅まで伸張される。したがって、水平の動きベクトルと垂直の動きベクトルを別個に取り扱うことが有益であるという状況が生じることがある。

整数ピクセルの単位又はステップの減少された解像度スケールで動きベクトルを表し、したがって、従来的なコーデックにわたって関連するビットレートの節約を達成するために、動きベクトルを信号伝達するためのプロトコルは、将来のコーデック規格のために更新されなければならないであろう。諸実施形態では、これは、H.265（HEVC：（High Efficiency Video Coding））規格に対する更新として実装され得る。キャプチャされる画面コンテンツを符号化するために、符号化データ３４のフォーマットには、各動きベクトルについて、減少されたサイズの動きベクトルのフィールドが与えられるであろう。整数ピクセルモードで符号化される符号化画面キャプチャストリームでは、関連するデータ３４は、ビットストリーム３３内の整数の動きベクトルを備え、実施形態によってはビットストリーム３３内の整数の動きベクトルのみを備えるであろう。

実施形態においては、これは任意選択であり、ヘッダ３６に含まれるフラグ３７を用いて、関連するフレーム又はスライスの符号化に分数ピクセル（例えば１／４ピクセル）解像度が使用されているのか整数ピクセル解像度が使用されているのかを示す（再び図３を参照されたい）。水平及び垂直解像度を別個に選択することができる場合、フレーム又はスライスに対して、２つのフラグ３７が必要とされるであろう。

以下に、H.265規格に対する更新に基づく例示の実施形態を開示する。修正は、動きベクトルを、符号化ビットストリーム３３内の減少した整数のピクセルスケールで表すことを可能にし、水平及び垂直成分の動きベクトルの解像度を伝達するために、圧縮されたストリームのヘッダ情報３６にスライスごとに２つのフラグ３７を追加する。

修正は、ヘッダレベル以外はシンタックス又は解析プロセスを変更しないが、動きベクトルの差を整数として解釈し、スケーリングされたMV予測因子を丸めて整数値にすることによって、復号プロセスを修正する。修正は、テストされる画面コンテンツシーケンスについて、符号化効率を７％ほど、平均で約２％向上させることがわかっており、したがって、符号化及び復号プロセスの複雑性も低減させることができる。

動きベクトルの解釈の解像度を示す高レベルのインジケータが（SPS、PPS及び／又はスライスヘッダレベルで）追加される。

復号プロセスでは、動きベクトルはフルピクセル解像度であるよう指示され、スケーリングされた動きベクトル予測が分数部分を有する場合、次いで実施形態によっては、予測が整数値に丸められる。動きベクトルの差は、１／４−サンプルオフセットではなく、整数オフセットとして簡単に解釈される。すべての他の復号プロセスは同じままである。（ヘッダレベルより下の）解析プロセスも変更されない。動きベクトルが、フルサンプル精度で符号化され、入力画像データが４：４：４又は４：２：０サンプリングを使用するとき、クロマ動きベクトルは通常のやり方で導出され、これは１／２−サンプルクロマ動き変位を生じることになる。あるいは、クロマ動きベクトルは、整数値に丸められてもよい。

動きベクトル解像度を伝達するためのシンタックスの変更に関して、実施形態によっては、３つの可能なモードが存在し、この場合、モードインジケータが、ピクチャパラメータセット（PPS）のような（フレーム当たり）より高いヘッダレベル、あるいはシーケンスパラメータセット（SPS）のような更に高いヘッダレベルで信号伝達される。モードインジケータは３つの選択可能な値を有する。１つの値は、動きベクトルが常に（このPPSを使用するピクチャにおいて）１／４サンプルオフセットを表すように解釈されることを示す。２つめの値は、動きベクトルが常に（このPPSを使用するピクチャにおいて）整数オフセットを表すように解釈されることを示す。３つめの値は、より低いレベルにおいて、その低いレベルで適用される解釈を適応的に選択する信号が存在することを示す。この低レベルの指示は、この第３のモードで動作するときにのみ存在することになるスライスヘッダ内のフラグとすることができる。

これを実装するために、実施形態においては、動きベクトル解像度の制御モードを示す新たな２ビットのインジケータがPPS拡張に含まれることになる。このインジケータは、motion_vector_resolution_control_idcと呼ばれることがある。モードが０のとき、動きベクトルは１／４ピクセル精度で符号化され、すべての復号プロセスは変更されないままである。モードが１であるとき、PPSを参照するスライス内の動きベクトルのすべてが、フルピクセル精度で符号化される。そして、モードが２のとき、動きベクトル解像度は、スライスヘッダ内のフラグによって、スライスごとの単位で制御される。motion_vector_resolution_control_idcが存在しないとき、その値は０と推論される。motion_vector_resolution_control_idcが２に等しいとき、slice_motion_vector_resolution_flagと呼ばれる追加のフラグがスライスヘッダ内で信号伝達される。フラグがゼロのとき、このスライスの動きベクトルは、１／４ピクセル精度で符号化され、フラグが１のとき、動きベクトルはフルピクセル精度で符号化される。フラグが存在しないとき、その値はmotion_vector_resolution_control_idcの値に等しいと推論される。
修正されたPPSシンタックスは、次のように例示される：

修正されたスライスヘッダシンタックスは、次のように例示される：

上述のスケーリングに関し、これは、例えばHEVC（H.265）で起こるものである。動きベクトルが何らかの他のフレームを符号化するために使用される場合、何が、（ｉ）現在のピクチャと、（ｉｉ）その参照ピクチャとの間の相対的な位置変位に関して等価なものとなる動きベクトルとなるかを計算することができることが狙いである。これは、別のピクチャの共同配置される（co-located）部分内の動きベクトルによって示される変位の相対的な位置に基づいており、また、（ｉｉｉ）そのピクチャと、（ｉｖ）その参照ピクチャとして参照していたピクチャとの間の相対的な位置に基づいている。すなわち、動きベクトル自体は、予測に基づいて符号化され、この場合、現在のターゲットフレーム内のターゲットブロックについての動きベクトルは、以前のフレーム内の空間的に対応するブロックについての以前の動きベクトルとの相対で符号化される。ターゲットブロックについての動きブロックは、次いで、予測バージョンと実際のバージョンとの間の差（典型的にはデルタ）のみに関して、符号化ビットストリーム３３内で伝達される。デコーダは、次いで、デコーダ側で同じ予測を実行して、デルタを追加することによって符号化された動きベクトルを再作成することができる。

しかしながら、符号化データの時間的な（temporal）フレームレートは常に一定ではなく、ピクチャがビットストリーム内に符号化される順番と、そのピクチャがキャプチャされて表示される順番との間には差がある可能性がある。基本的に同じ方向の同じ動きの速さを表すよう、これらの時間的な関係を計算して、動きベクトルをスケーリングするのに使用することができる。すなわち、動きベクトルの予測バージョンは、参照ベクトルに完全に等しくはなく、むしろそのスケーリングされたバージョンである。これは、時間的な動きベクトル予測（temporal motion vector prediction）としても知られる。

HEVC規格における現在の動きベクトル（MV）復号プロセスは、次のように要約され得る：
１．MVがデコーダにおいてどのように予測されるか判断し、動きベクトルデルタ（MVD）が、エンコーダからの符号化ビットストリームで送信されているか否かを判断する（これは何らかのシンタックス指示を伴うことがある）。
２．予測動きベクトル（PMV：predicted motion vector）を生成する。これは整数のペア（px,py）を作成する。整数は、ルマ領域において四分の一のサンプル位置の精度でオフセットを表すように想定される。
３．MVDが送信されない場合、MV値（mx,my）を（px,py）に設定し、そうでない場合、整数のペア（px,py）を（dx,dy）として復号し、MV（mx,my）を（px+dx,py+dy）に設定する。MVは、ルマ領域における１／４−サンプルオフセットを表すものとして解釈される。注：ルマの区別（luma distinction）は、ビデオが、クロマチャネルと異なる解像度をルマチャネルで使用する、４：２：２又は４：２：０等のフォーマットの場合にのみ問題となる；代わりに、ビデオが、例えば４：４：４フォーマットである場合、オフセットは、すべてのサンプリンググリッドについて１／４サンプルユニットを有するものとして解釈される。
４．後続のPMVを生成するために（及びデブロッキングフィルタ等を制御するために）後に使用するために最後の値（mx,my）を格納する。

本開示の実施形態では、整数ピクセルベクトルモードが使用されているとき、スケーリングされた動きベクトルは、整数ピクセル解像度に対する制約に適応するよう、復号プロセスで丸められることがある。例えば動きベクトル復号プロセスは、次のように修正され得る。
１．MVがデコーダにおいてどのように予測されるか判断し、動きベクトルデルタ（MVD）が、エンコーダからの符号化ビットストリームで送信されている否かを判断する（これは何らかのシンタックス指示を伴うことがある）。
２．予測動きベクトル（PMV）を生成する。これは整数のペア（px,py）を作成する。整数は、ルマ領域において四分の一のサンプル位置の精度でオフセットを表すように想定される。
３．整数精度モードで動作する場合、これを行う：
ａ．整数オブセットに対応させるように予測値の端数を切り捨てる−例えばcreate（rx,ry）＝（round（px/4）,round（py/4））
ｂ．MVDが送信されない場合、MV値（mx,my）を（4*rx,4*ry）に設定し、そうでない場合、整数のペア（px,py）を（dx,dy）として復号し、MV（mx,my）を（4*(rx+dx),4*(ry+dy)）に設定する。MVは、ルマ領域における１／４−サンプルオフセットを表すものとして解釈される。（注：やはり、ルマの区別は、ビデオが４：２：２又は４：２：０等のフォーマットの場合にのみ問題となる。）
４．そうでない場合（すなわち、１／４−サンプリング精度モードで動作する場合）、これを行う：MVDが送信されない場合、MV値（mx,my）を（px,py）に設定し、そうでない場合、整数のペア（px,py）を（dx,dy）として復号し、MV（mx,my）を（px+dx,py+dy）に設定する。MVはやはり、ルマ領域における１／４−サンプルオフセットを表すものとして解釈される。
５．後続のPMVを生成するために（及びデブロッキングフィルタ等を制御するために）後に使用するために最後の値（mx,my）を格納する。

しかしながら、上述のプロセスは、必ずしも全ての可能性のある実施形態に必要ではない。上記に概説されたアプローチは、動きベクトル予測が１／４ピクセル領域で生じるよう、デコーダが、開始から１／４ピクセル領域で動作することを想定している。しかしながら、実際には、デコーダは必ずしも、この段階でその単位（unit）が何を意味しているかを知る必要はない。したがって、実際に画像を生成するために後に使用されるまで、その単位に対するいずれの解釈も提起（place）されないという、代替的なアプローチを取ることも可能である。

以下は、そのような代替的なアプローチの実施形態による復号プロセスを説明する。上記のように、動きベクトル値のうちの少なくとも１つが異なるように符号化され、この場合、動き予測モジュール７３は、その動きベクトル値のうちの別の動きベクトル値をスケーリングすることによって、動きベクトル値を予測するように構成される。動きベクトル値の少なくとも１つは、デルタ値に関して異なるように符号化され、動き予測モジュール７３は、動きベクトル値のうちの別の動きベクトル値をスケーリングして、スケーリングされた動きベクトル値を生成し、次いでデルタ値をスケーリングされた動きベクトル値に追加することによって、動きベクトル値を予測するように構成され得る。しかしながら、上記とは異なり、動き予測モジュール７３は、（整数モードが使用されているとき）スケーリング後に整数ピクセル解像度へ丸めることなく、その整数ピクセル単位（integer pixel units）で動きベクトル値を解釈するように更に構成される。これは、スケーリングの際に、その単位に対する解釈を提起することをやめることによって可能になる。動き推定モジュール７３は、スケーリングされた動きベクトルの値へのデルタの追加を実行することにより、スケーリングされた動きベクトル値を整数ピクセル解像度へ丸めることなく、整数ピクセル単位で動きベクトル値を解釈するように構成され得る。結果として得られる動きベクトル値は単に、画像を生成するのに使用されるときに、整数又は分数ピクセル単位に関して解釈される。また、結果として得られる値は、整数又は分数単位に関して格納された値に対する解釈を提起することなく、１つ以上の後続の動きベクトルを予測する際に使用するために格納される。

例えばそのような代替によると、動きベクトルの復号プロセスは、以下のように実装され得る。
１．MVがデコーダにおいてどのように予測されるか判断し、動きベクトルデルタ（MVD）が、エンコーダからの符号化ビットストリームで送信されている否かを判断する（これは何らかのシンタックス指示を伴うことがある）。
２．予測動きベクトル（PMV）を生成する。これは整数のペア（px,py）を作成する。しかしながら、これが何を表し得るのかについては気にしない−すなわち、この段階では、その単位に対していかなる解釈も提起しない。
３．MVDが送信されない場合、MV値（mx,my）を（px,py）に設定し、そうでない場合、整数のペア（px,py）を（dx,dy）として復号し、MV（mx,my）を（px+dx,py+dy）に設定する。整数精度モードで動作するとき、MVを、ルマ領域内の全体の整数のオフセット（whole-integer offset）を表すように解釈する。すなわち、１／４−サンプルオフセット単位で値（4*mx,4*my）を表すように解釈する。そうでない場合（すなわち、１／４−サンプリング精度モードで動作する場合）、MVを、ルマ領域内の１／４−サンプルオフセットを表すように解釈する。すなわち、１／４−サンプルオフセット単位で値（mx,my）を表すように解釈する（注：やはり、ルマの区別は、ビデオが４：２：２又は４：２：０等のフォーマットの場合にのみ問題となる。）
４．後続のPMVを生成するために（及びデブロッキングフィルタ等を制御するために）後に使用するために最後の値（mx,my）を格納する。やはり、これが何を表し得るのかについては気にしない。

したがって、上記の丸めステップ３ａは、ここでは除外される。数の解釈のみが修正される。これは、MV予測プロセスの修正が必要とされないので、復号プロセスをあまり複雑でないものにする。

上述の丸めは、１／４（又は分数）解像度から整数解像度への丸めを指すことに留意されたい。現在の規格では、動きベクトル精度の一部として、更により精細な精度から、１／４精度への丸めも存在する。上記の代替的な実施形態では、そのような事前丸めも存在することは除外されない。

このやり方では、幾つかの動作の副作用が存在することがある。１つの副作用は、一部のピクチャが他とは異なるモードを使用する場合、時間的なMV予測のためにMV予測プロセスで使用されるスケーリングが正しくない可能性があることである。しかしながら、これは非常に些細な影響である。特に、異なるモードで動作するというこの状況があることは珍しく、または時間的なMV予測は通常、非常に小さな利点しかもたらさないためである。別の副作用は、デブロッキングフィルタ制御の結果が、異なるスケール因子で解釈されるMV値に依存し得ることである。しかしながら、この影響も小さいであろう。特に画面コンテンツを符号化するときに、デブロッキングは無効にされ得るか、あまり影響を持たないことがあるからである。

常に整数動きのみを使用して、時間的な動きベクトル予測を無効にするという別の可能性もあり得る。エンコーダにその機能の使用を無効にさせるHEVCのシンタックスが既に存在する。それは、差が整数として符号化されるか、分数値として部号化されるかに応じて異なるように動作する特別なプロセスを、デコーダに持たせる必要性を回避するためにあり得る方法であろう。時間的動きベクトル予測から得られる利益は、これらの使用ケースではいずれにしても小さく（又はゼロ）、これを無効にすることは、必ずしも望ましくないことはない。

上記の実施形態は、単に例として説明されていることが認識されよう。

例えば上記は、ブロックに関して説明されているが、これは必ずしもいずれかの特定の規格においてブロックと呼ばれる区分に限定されない。例えば本明細書で言及されるブロックは、H.26x規格でブロック又はマクロブロックと呼ばれる区分であってもよい。

任意の特定のコーデック又は規格に限定されている本開示の範囲、一般的には本明細書で開示される技術を、H.264又はH.265のようなH.26x規格又は任意の別の規格であるかどうかに関わらず、既存の規格又は既存の規格に対する更新のコンテキストのいずれかにおいて実装することができ、あるいは特注のコーデックで実装してもよい。さらに本開示の範囲は、RGB、YUV又は他のものに関するかどうかに関わらず、ビデオサンプルについてのいずれかの特定の表現に特に制限されない。また、その範囲はいずれかの特定の量子化に限定されず、DCT変換にも限定されない。例えばKL変換（KLT：Karhunen-LoeveTransform）のような代替的な変換を使用することができ、あるいは変換を使用しなくてもよい。さらに、本開示は、VoIP通信やいずれかの特定の種類のネットワークを介する通信に限定されないが、データを通信する能力を有するいずれかの任意のネットワーク又は媒体において使用することも可能である。

動きベクトルオフセットが、整数のピクセル等に制限される又は制限されないと言う場合、これは、色空間チャネルのうちのいずれか１つ又は２つにおける動き推定、あるいは３つの色チャネルすべてにおける動き推定を指すことがある。

さらに、本発明は、整数ピクセルと四分の一ピクセルの解像度との間を選択することに限定されない。一般に、本明細書で説明される技術を、整数ピクセルの解像度と任意の分数ピクセル解像度、例えば１／２ピクセル解像度との間を選択すること、あるいは整数ピクセル解像度と複数の異なる分数ピクセルモードとの間を選択すること、例えば整数と１／２及び１／４ピクセルモードとの間を選択することに適用することができる。

さらに、本開示の範囲は、符号化ビデオ及び／又は画面キャプチャストリームがネットワークを介して送信される適用に限定されず、ストリームがライブストリームである適用にも限定されない。例えば別の適用では、ストリームは、光ディスク、ハードドライブ又は他の磁気ストレージ、あるいは「フラッシュ」メモリスティック又は他の電子メモリのような、ストレージデバイス上に格納され得る。したがって、画面共有ストリームは、（確かに１つのオプションではあるが）必ずしもライブシェアリングを意味する必要はないことに留意されたい。あるいはまた、後に１以上の他のユーザと共有するために格納されてもよく、あるいは、キャプチャされた画像は共有されずに、ある時間に画面を使用していたユーザのために単に記録されればよいこともある。一般に、画面キャプチャは、（確かに１つのオプションではあるが、必ずしも画面バッファからの読み取りではなくてよい）任意の適切な手段によってキャプチャされる、キャプチャされたエンコーダ側の画面コンテンツからなる任意の動画データであってよく、１以上の他のユーザと（ライブであってもなくてもよい）共有されるか、キャプチャしているユーザの利益のため又は単にアーカイブのために（恐らくはターンアウトされると、実際には再び見ることはできない）単に記録されることになる。

コーデックは、必ずしも画面キャプチャデータ及びビデオの符号化に限定されないことに留意されたい。実施形態によっては、コーデックは、他のタイプの動画データ、例えばアニメーションを符号化する能力を有することがある。そのような他のタイプの動画データは、分数ピクセルモード又は整数ピクセルモードで符号化され得る。

さらに、インターフレーム符号化は、必ずしも常に以前のフレームとの相対で符号化する必要はなく、より一般的には、一部のコーデックは、ターゲットフレーム以外の異なるフレーム、すなわち（適切な外部バッファを想定すると）ターゲットフレームの先行フレーム又は前方のフレームに対する符号化を許容することに留意されたい。

さらに、以前に説明したように、動きベクトル自体を異なるように符号化してもよいことに留意されたい。符号化ビットストリーム内で伝達されるような動きベクトルが整数のピクセル等に制限される場合、これは異なるように符号化された動きベクトルの形式が、そのように制限されることを意味する（例えばデルタ）。

さらに、デコーダは、必ずしもエンドユーザ端末で実装されなくてもよく、受信端末における即時の使用のために、動画データを出力しなくてもよい。代替的な実装では、受信端末は、動画データを復号又はトランスコードされた形で別の端末に出力し、あるいは後の使用のために復号データを格納するため、デコーダソフトウェアを実行するサーバのような中間端末であってよい。同様に、エンコーダは、エンドユーザ端末で実装される必要はなく、送信端末から発信される動画データを符号化する必要がない。他の実施形態において、送信端末は、例えば動画データを未符号化あるいは別の形でコード化された形で別の端末から受け取り、サーバで格納するためにそのデータを符号化又はトランスコードし、あるいは受信端末へ転送するため、円エンコーダソフトウェアを実行するサーバのような中間端末であってよい。

一般に、本明細書で説明される機能はいずれも、ソフトウェア、ファームウェア、ハードウェア（例えば固定の論理回路）又はこれらの実装の組合せを使用して実装され得る。「モジュール」、「機能」、「コンポーネント」及び「ロジック」という用語は、本明細書で使用されるとき、ソフトウェア、ファームウェア、ハードウェア又はその組合せを表す。ソフトウェア実装の場合、モジュール、機能又はロジックは、プロセッサ（例えば１つ又は複数のCPU）で実行されると、指定のタスクを実行するプログラムコードを表す。プログラムコードは、１つ以上のコンピュータ読取可能メモリデバイス内に格納され得る。以下に説明される技術の機能は、プラットフォーム独立であり、これは、本技術が、様々はプロセッサを有する様々な市販のコンピューティングプラットフォーム上で実装され得ることを意味する。

例えば端末は、ユーザ端末のハードウェアに、例えばプロセッサ機能ブロック等のような動作を実行させるエンティティ（例えばソフトウェア）を含み得る。例えば端末はコンピュータ読取可能媒体を含んでよく、コンピュータ読取可能媒体は、ユーザ端末、より具体的にはユーザ端末のオペレーションシステム及び関連するハードウェアに動作を実行させる命令を保持するように構成され得る。したがって、このようにして動作を実行するようにオペレーティングシステム及び関連するハードウェアを構成する命令機能の結果、機能を実行するようオペレーションシステム及び関連するハードウェアの変換につながる。命令は、コンピュータ読取可能媒体により、様々な異なる構成を通して端末へと提供され得る。

コンピュータ読取可能媒体の１つのそのような構成は、信号担持媒体であり、したがって、命令を（例えば搬送波として）ネットワーク等を介してコンピューティングデバイスへ伝送するよう構成される。コンピュータ読取可能媒体は、コンピュータ読取可能記録媒体として構成されてもよく、これは信号担持媒体ではない。コンピュータ読取可能記録媒体の例には、磁気技術、光技術及び命令や他のデータを格納する他の技術を含め、ランダムアクセスメモリ（RAM）、読取専用メモリ（ROM）、光ディスク、フラッシュメモリ、ハードディスクメモリ及び他のメモリデバイスが含まれる。

本主題は、構造的特徴及び／又は方法的動作に特有の言葉で説明されているが、添付の特許請求の範囲で定義される主題は、必ずしも上述の具体的な特徴又は動作に限定されないことを理解されたい。むしろ、上述の具体的な特徴及び動作は、特許請求の範囲を実装する例示の形式として開示される。

Claims (11)

1. 動き推定を使用して領域が符号化されている複数のフレームを含む、符号化形式の動画データを受け取るための入力部であって、前記動画データは、前記フレームのそれぞれ各１つに関連付けられるか、前記フレームの各フレーム内のそれぞれ各１領域に関連付けられる、動きベクトル値のそれぞれのセットを含み、前記動画データは更に、それぞれの動きベクトル値が第１の解像度で符号化されているか又は第２の解像度で符号化されているかを示す、それぞれのフレーム又は領域の各々に関連付けられる２つのそれぞれのインジケータであって、二次元のそれぞれの動きベクトルの解像度を示す２つのそれぞれのインジケータをヘッダ情報内に含んでいる、入力部と；
   前記動きベクトル値に基づいて前記フレーム又は領域を復号するための動き予測モジュールであって、前記復号が：
   前記ヘッダ情報から前記インジケータの各々を読み取ることと、
   前記読み取ったインジケータから、前記それぞれのフレーム又は領域の前記動きベクトル値が前記第１の解像度で符号化されているか又は前記第２の解像度で符号化されているかを判断することと、
   前記動きベクトル値を、前記第１の解像度について分数ピクセル単位で解釈し、前記第２の解像度について整数ピクセル単位で解釈することと、
   を含む、動き予測モジュールと；
   を備える、デコーダ。
2. 前記複数のフレームの少なくとも１つが、複数の領域に分割され、
   前記動画データは、前記複数の領域の前記動きベクトル値が前記第１の解像度で符号化されているか又は前記第２の解像度で符号化されているかを個々に示すように、前記複数の領域のそれぞれ各１つに関連付けられるインジケータを備え、
   前記動き予測モジュールは、前記インジケータを読み取って、それぞれの領域の前記動きベクトル値が前記第１の解像度で符号化されているか又は前記第２の解像度で符号化されているかを判断し、それに従って前記それぞれの領域の前記動きベクトル値を前記分数ピクセル単位又は前記整数ピクセル単位で解釈する、
   請求項１に記載のデコーダ。
3. 前記領域は、H.26x規格のスライスである、
   請求項２に記載のデコーダ。
4. 前記動画データは、前記動きベクトル値の解像度が領域ごとに指示されているか又はフレームごとに指示されているかを設定する設定を更に備え、前記動き予測モジュールは、前記設定を読み取って、それに従って前記動きベクトル値を解釈するように構成される、
   請求項２又は３に記載のデコーダ。
5. 前記動き予測モジュールは、前記フレーム又は領域の１つについてインジケータが存在しない場合、デフォルトとして前記それぞれの動きベクトル値を前記分数ピクセル単位で解釈する、
   請求項１乃至４のいずれかに記載のデコーダ。
6. 前記動画データが、前記動きベクトル値のうちの少なくとも１つの動きベクトル値について、予測バージョンと実際のバージョンとの間の差を示すデルタ値を含むとき、
   前記動き予測モジュールは、前記動きベクトル値のうちの別の動きベクトル値をスケーリングすることによって、前記少なくとも１つの動きベクトル値を推定し、
   前記動き予測モジュールは、前記スケーリングされた動きベクトル値への前記デルタ値の追加を実行することによって、前記スケーリングされた動きベクトル値を整数ピクセル解像度へと丸めることなく、前記少なくとも１つの動きベクトル値を前記整数ピクセル単位で解釈する、
   請求項１乃至５のいずれかに記載のデコーダ。
7. 当該デコーダは、前記動き予測モジュールによる復号に先行する、可逆符号化段階の逆を備える、
   請求項１乃至６のいずれかに記載のデコーダ。
8. プロセッサによる実行に応答して、
   領域が動き推定を使用して符号化されている複数のフレームを含む、符号化形式の動画データを受け取る動作であって、前記動画データは、前記フレームのそれぞれ各１つに関連付けられるか、前記フレームの各フレーム内のそれぞれ各領域に関連付けられる、動きベクトル値のそれぞれのセットを含み、前記動画データは更に、それぞれの動きベクトル値が第１の解像度で符号化されているか又は第２の解像度で符号化されているかを示す、それぞれのフレーム又は領域の各々に関連付けられる２つのそれぞれのインジケータであって、二次元のそれぞれの動きベクトルの解像度を示す２つのそれぞれのインジケータをヘッダ情報内に含んでいる、動作と；
   前記ヘッダ情報から前記インジケータの各々を読み取る動作と；
   前記読み取ったインジケータから、前記それぞれのフレーム又は領域の前記動きベクトル値が前記第１の解像度で符号化されているか、前記第２の解像度で符号化されているかを判断する動作と；
   前記動きベクトル値を、前記第１の解像度について分数ピクセル単位で解釈し、前記第２の解像度について整数ピクセル単位で解釈する動作と；
   前記の解釈に従って前記分数ピクセル単位又は前記整数ピクセル単位で解釈される前記動きベクトル値に基づいて、前記フレーム又は領域を復号する動作と；
   を実行させる、コンピュータプログラム。
9. 前記フレームの少なくとも１つが、複数の領域に分割され、
   前記動画データは、前記複数の領域の前記動きベクトル値が前記第１の解像度で符号化されているか又は前記第２の解像度で符号化されているかを個々に示すよう、前記複数の領域のそれぞれ各１つに関連付けられるインジケータを含み、
   当該コンピュータプログラムは、前記インジケータを読み取って、各それぞれの領域の前記動きベクトル値が前記第１の解像度で符号化されているか又は前記第２の解像度で符号化されているかを判断し、それに従って前記それぞれの領域の前記動きベクトル値を前記分数ピクセル単位又は前記整数ピクセル単位で解釈する動作を更に実行する、
   請求項８に記載のコンピュータプログラム。
10. 前記動画データは、前記動きベクトル値の解像度が領域ごとに指示されているか又はフレームごとに指示されているかを設定するモード設定を更に備え、当該コンピュータプログラムは、前記設定を読み取って、それに従って前記動きベクトル値を解釈する動作を更に実行する、
    請求項９に記載のコンピュータプログラム。
11. 当該コンピュータプログラムは、前記フレーム又は領域の１つについてインジケータが存在しない場合、デフォルトとして前記それぞれの動きベクトル値を前記分数ピクセル単位で解釈する動作を更に実行する、
    請求項８乃至１０のいずれかに記載のコンピュータプログラム。

Images