JP6576351B2 - 画面キャプチャデータの符号化 - Google Patents

Description

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

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

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

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

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

したがって、本明細書で開示される一側面によると、動画データ（moving image data）を受け取るための入力部と、動画データを符号化する際に使用するための動き予測モジュールとを備えるエンコーダが提供される。動画データは、符号化されるフレームのシーケンスを備え、各フレームは、２次元の複数のブロックに分割され、各ブロックは、その２次元の複数のピクセルを備える。ブロックは、例えばH.264又はH.265等のH.26x規格のブロック又はマクロブロックと呼ばれる区分とすることができる。動き予測モジュールは、各ブロック（ターゲットブロック）をシーケンスの別のフレームのそれぞれの参照部分（reference portion）（参照「ブロック」（reference block））との相対で符号化することによってインターフレーム符号化を実行し、この場合、それぞれの参照は、それぞれの動きベクトルによる、ターゲットブロックからのオフセットである。さらに、本開示によると、複数のフレームの動画データは、画面キャプチャストリーム（screen capture stream）を備え、動き予測モジュールは、画面キャプチャストリームの動きベクトルの各々を、上記の次元の少なくとも１つにおいて整数ピクセルに制限するように構成される。

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

したがって、諸実施形態では、エンコーダは、動き予測モジュールを、２つのモード：すなわち、第１のモードと第２のモードの間で切り替えるように動作可能なコントローラも備え得る。第１のモードでは、動きベクトルは、（いずれの次元でも）整数ピクセルに制限されないが、第２のモードでは、動きベクトルは、少なくとも１つの次元（実施形態によっては双方の次元）において整数ピクセルに制限される。コントローラは、現在符号化されている動画データが画面キャプチャストリームを備えると判断したことに応じて、動き予測モジュールを第２のモードに切り替えるように構成される。

例えば動画データは、画面キャプチャストリーム及びビデオストリームを備えることがある（例えばこれらは、インターネットのようなパケットベースのネットワーク上で実施される呼のライブストリームであってよく、あるいは後の再生が意図されるストリームを格納してもよい）。動画データの一部のフレームが画像キャプチャストリームのフレームであり、他の時間には、動画データのそのフレームがビデオフレームである可能性があり、あるいは各フレーム内の異なる領域が、それぞれ画像キャプチャストリームとビデオストリーム（例えば異なるスライス）を備える可能性がある。そのようなケースに適応するために、コントローラは、現在符号化されている動画データが画面キャプチャストリームであるか又はビデオストリームであるかを判断し、画面キャプチャについては第２のモードに、ビデオについては第１のモードに動き予測モジュールを設定するように構成され得る。あるいは、別の例として、画面キャプチャデータストリームとビデオストリームが同じフレームの一部の異なる領域に含まれる場合、コントローラは、フレームが少しでも画面キャプチャデータを含む場合には、第２のモードを選択し、そうではなく、フレームが画面キャプチャデータを含まない場合にのみ第１のモードを選択するように構成されてよく；あるいは反対に、コントローラは、フレームが画面キャプチャデータのみを含みビデオは含まない場合には、第２のモードに切り替え、そうではなく、フレームが少しでもビデオを含む場合には第１のモードを選択するように構成されてもよい。

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

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

ビデオストリームの概略的な表現である。 通信システムの概略的なブロック図である。 符号化ビデオストリームの概略的な表現である。 エンコーダの概略的なブロック図である。 デコーダの概略的なブロック図である。 インターフレーム符号化スキームの概略的な表現である。 別のインターフレーム符号化スキームの概略的な表現である。

図１は、カメラからキャプチャされ、符号化ビットストリームを生成するようビデオエンコーダによって符号化される空間区分（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又は別のピクセルから予測された可能性もあるが、制約に起因して、ピクセル間の補完からは予測することはできない。なお、任意の所与のブロックについて、図６の例に図示されるような四分の一ピクセル予測は、最も低い残差を与えた場合、偶然に、補間を伴わない全体的なピクセルオフセットを生成する可能性があることに留意されたい。しかしながら、そのようにすることには制約されず、サイズ調整可能な画像に対して、それがすべてのブロックについて起こることは全くありそうにないことである。

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

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

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

更なる実施形態では、コントロールは、任意選択で、ベクトルの垂直成分又は水平成分に対して個別に適用されてもよい。これは、水平又は垂直にスケーリングされる画面ビデオの符号化にとって有益であり得る。

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

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

あるいは、実施形態によっては、必ずしも、整数ピクセルベクトルを実装するために既存の規格のプロトコルを更新する必要がない。代わりに動きベクトルは整数オフセットに制限され得るが、それでもなお、これらの整数の動きベクトルを、従来の分数（例えば１／４ピクセル）スケールの符号化ビットストリーム３３で表すことができる。したがって、１／４ピクセル解像度の場合、１つの全体のピクセルのオフセットはやはり、従来的な方法で、値４（例えばコードワード００１１１）によって表されることになるが、エンコーダで適用される制約に起因して、例えばピクセルの３／４が、値３（例えばコードワード００１００）によって表される可能性はないであろう。この場合、整数の動きベクトルのビットレートの節約は達成されないが、動きベクトル検索の複雑性を整数オフセットに制限することによって、処理リソースは依然として節約され得る。

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

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

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

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

上述のスケーリングは、HEVC（H.265）で起こるものである。動きベクトルが何らかの他のフレームを符号化するために使用される場合、何が、（ｉ）現在のピクチャと、（ｉｉ）その参照ピクチャとの間の相対的な位置変位に関して等価なものとなる動きベクトルとなるかを計算することができることが狙いである。これは、別のピクチャの共同配置される（co-located）部分内の動きベクトルによって示される変位の相対的な位置に基づいており、また、（ｉｉｉ）そのピクチャと、（ｉｖ）その参照ピクチャとして参照していたピクチャとの間の相対的な位置に基づいている。なお、符号化データの時間的な（temporal）フレームレートは常に一定ではなく、ピクチャがビットストリーム内に符号化される順番と、そのピクチャがキャプチャされて表示される順番との間には差がある可能性があるので、基本的に同じ方向の同じ動きの速さを表すよう、これらの時間的な関係を計算して、動きベクトルをスケーリングするのに使用することができることに留意されたい。これは、時間的な動きベクトル予測（temporal motion vector prediction）としても知られる。

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

シンタックスの変更に関して：新たな２ビットのインジケータが含まれることになり、これらは、motion_vector_resolution_control_idcと呼ばれ、PPS拡張で動きベクトル解像度制御モードを示すことがある。３つのモードが定義される。モードが０のとき、動きベクトルは１／４ピクセル精度で符号化され、すべての復号プロセスは変更されないままである。モードが１であるとき、PPSを参照するスライス内の動きベクトルのすべてが、フルピクセル精度で符号化される。そして、モードが２のとき、動きベクトル解像度は、スライスヘッダ内のフラグによって、スライスごとの単位で制御される。motion_vector_resolution_control_idcが存在しないとき、その値は０と推論される。

motion_vector_resolution_control_idcが２に等しいとき、slice_motion_vector_resolution_flagと呼ばれる追加のフラグがスライスヘッダ内で信号伝達される。フラグがゼロのとき、このスライスの動きベクトルは、１／４ピクセル精度で符号化され、フラグが１のとき、動きベクトルはフルピクセル精度で符号化される。フラグが存在しないとき、その値はmotion_vector_resolution_control_idcの値に等しいと推論される。

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

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

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

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

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

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

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

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

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

さらに、多くの場合、動きベクトル自体を異なるように符号化してもよいことに留意されたい。動きベクトルが整数のピクセル等に制限される場合、これは異なるように符号化された動きベクトルの形式が、そのように制限されることを意味する。

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

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

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

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

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

Claims (15)

1. エンコーダにおいて、
   符号化されるフレームのシーケンスを備える動画データを受け取るための入力部であって、各フレームが二次元の複数のブロックを備え、各ブロックが前記二次元の複数のピクセル値を備え、前記動画データが、画面キャプチャコンテンツ及び／又はカメラビデオコンテンツを備える、入力部と；
   前記動画データを符号化する際に使用して符号化データを生成するための動き予測モジュールであって、
   前記フレームのうちの少なくとも１つのフレームの動きベクトル（ＭＶ）精度が領域ごとに制御されるかどうかを決定するステップと、
   前記少なくとも１つのフレームのためのヘッダ内にインジケータの値を設定するステップであって、前記インジケータが前記少なくとも１つのフレームのＭＶ精度が領域ごとに制御されるかどうかを示すステップと、
   前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合、前記少なくとも１つのフレームの領域ごとに、
   前記領域のコンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかに少なくとも部分的に基づいて、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定するステップと、
   前記領域のためのヘッダ内にフラグの値を設定するステップであって、前記フラグが、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示すステップと、
   を含む動作を実行することにより、前記インジケータと、前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合には前記少なくとも１つのフレームの領域ごとに、該領域のＭＶ精度を示す前記フラグとを含むビットストリームの一部として、前記符号化データを生成する動き予測モジュールと；
   を備えるエンコーダ。
2. 当該エンコーダは、前記動き予測モジュールを、前記ＭＶ精度が整数サンプル精度に制限されない第１のモードと、前記ＭＶ精度が少なくとも１つの次元で整数サンプル精度に制限される第２のモードとの間で切り替えるように動作可能なコントローラを備える、
   請求項１に記載のエンコーダ。
3. 前記コントローラは、前記二次元の各々において個々に前記ＭＶ精度を適用すべきかどうかを選択するように構成される。
   請求項２に記載のエンコーダ。
4. 前記ブロックは、H.26xビデオ符号化規格のブロック又はマクロブロックである、
   請求項１乃至３のいずれかに記載のエンコーダ。
5. 前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御されない場合、
   前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定するステップを更に含み、前記インジケータは更に、前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示す、
   請求項１に記載のエンコーダ。
6. 前記少なくとも１つのフレームのための前記ヘッダは、シーケンスパラメータセット（SPS）又はピクチャパラメータセット（PPS）であり、前記領域はスライスであり、前記領域のための前記ヘッダは、スライスヘッダである、
   請求項１に記載のエンコーダ。
7. 前記動作は更に、
   アプリケーション又はオペレーティングシステムから、前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す指示を受け取るステップ、
   前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す性能ヒューリスティックを測るステップ、
   前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す履歴統計データを決定するステップ、又は
   マルチパス分析を実行して前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを決定するステップ、
   を含む、請求項１に記載のエンコーダ。
8. 前記コンテンツタイプが画面キャプチャコンテンツの場合、前記ＭＶ精度は整数サンプル精度であり、前記コンテンツタイプがカメラビデオコンテンツの場合、前記ＭＶ精度は１／４サンプル精度である、
   請求項１に記載のエンコーダ。
9. 動画データを符号化するためのコンピュータプログラムであって、実行されると、コンピュータに、
   符号化されるフレームのシーケンスを備える動画データを受け取るステップであって、各フレームが二次元の複数のブロックを備え、各ブロックが前記二次元の複数のピクセル値を備え、前記動画データが、画面キャプチャコンテンツ及び／又はカメラビデオコンテンツを備えるステップと；
   前記動画データを符号化して符号化データを生成するステップであって、
   前記フレームのうちの少なくとも１つのフレームの動きベクトル（ＭＶ）精度が領域ごとに制御されるかどうかを決定することと、
   前記少なくとも１つのフレームのためのヘッダ内にインジケータの値を設定することであって、前記インジケータが前記少なくとも１つのフレームのＭＶ精度が領域ごとに制御されるかどうかを示すことと、
   前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合、前記少なくとも１つのフレームの領域ごとに、
   前記領域のコンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかに少なくとも部分的に基づいて、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定することと、
   前記領域のためのヘッダ内にフラグの値を設定することであって、前記フラグが、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示すことと、
   によって、前記インジケータと、前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合には前記少なくとも１つのフレームの領域ごとに、該領域のＭＶ精度を示す前記フラグとを含むビットストリームの一部として、前記符号化データを生成するステップと；
   を実行させる、コンピュータプログラム。
10. 当該コンピュータプログラムは、前記二次元の各々において個々に前記ＭＶ精度を適用すべきかどうかを選択するように構成される、
    請求項９に記載のコンピュータプログラム。
11. 前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御されない場合、前記コンピュータに、
    前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定するステップを更に実行させ、前記インジケータは更に、前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示す、
    請求項９に記載のコンピュータプログラム。
12. 前記コンピュータに、
    アプリケーション又はオペレーティングシステムから、前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す指示を受け取るステップ、
    前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す性能ヒューリスティックを測るステップ、
    前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを示す履歴統計データを決定するステップ、又は
    マルチパス分析を実行して前記コンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかを決定するステップ、
    を更に実行させる、
    請求項９に記載のコンピュータプログラム。
13. 前記コンテンツタイプが画面キャプチャコンテンツの場合、前記ＭＶ精度は整数サンプル精度であり、前記コンテンツタイプがカメラビデオコンテンツの場合、前記ＭＶ精度は１／４サンプル精度である、
    請求項９に記載のコンピュータプログラム。
14. 動画データを符号化するためのコンピュータ実施方法であって：
    符号化されるフレームのシーケンスを備える動画データを受け取るステップであって、各フレームが二次元の複数のブロックを備え、各ブロックが前記二次元の複数のピクセル値を備え、前記動画データが、画面キャプチャコンテンツ及び／又はカメラビデオコンテンツを備えるステップと；
    前記動画データを符号化して符号化データを生成するステップであって、
    前記フレームのうちの少なくとも１つのフレームの動きベクトル（ＭＶ）精度が領域ごとに制御されるかどうかを決定することと、
    前記少なくとも１つのフレームのためのヘッダ内にインジケータの値を設定することであって、前記インジケータが前記少なくとも１つのフレームのＭＶ精度が領域ごとに制御されるかどうかを示すことと、
    前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合、前記少なくとも１つのフレームの領域ごとに、
    前記領域のコンテンツタイプが画面キャプチャコンテンツであるかカメラビデオコンテンツであるかに少なくとも部分的に基づいて、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定することと、
    前記領域のためのヘッダ内にフラグの値を設定することであって、前記フラグが、前記領域のＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示すことと、
    によって、前記インジケータと、前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御される場合には前記少なくとも１つのフレームの領域ごとに、該領域のＭＶ精度を示す前記フラグとを含むビットストリームの一部として、前記符号化データを生成するステップと；
    を含む、方法。
15. 前記少なくとも１つのフレームの前記ＭＶ精度が領域ごとに制御されない場合、
    前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを決定することを更に含み、前記インジケータは更に、前記少なくとも１つのフレームの前記ＭＶ精度が整数サンプル精度であるか１／４サンプル精度であるかを示す、
    請求項１４に記載の方法。
    

Images