(57)【要約】  サーバからクライアントに送信されるビデオの符号化に使用されることになる少なくとも１つのビデオ符号化パラメータを適合させるための方法であって、前記ビデオの以前に符号化および送信されたフレームうちの連続したフレーム間の関心領域の移動速度が、所定の閾値を上回るかを判定するステップと、前記所定の閾値を上回る場合に、前記少なくとも１つのビデオ符号化パラメータを適合させるステップと含む方法。
2015526003.tif 000002
【特許請求の範囲】
【請求項１】
サーバ（Ｓ）からクライアント（Ｃ）に送信されるビデオの符号化に使用されることになる少なくとも１つのビデオ符号化パラメータを適合させるための方法であって、前記ビデオの以前に符号化および送信されたフレームのうち連続したフレーム間の関心領域の移動速度が、所定の閾値を上回るかを判定するステップと、前記所定の閾値を上回る場合に、前記少なくとも１つのビデオ符号化パラメータを適合させるステップとを含む、方法。
【請求項２】
前記関心領域の前記移動速度が、前記関心領域上の前記クライアントによって発行されるコマンドを監視することによって判定される、請求項１に記載の方法。
【請求項３】
前記関心領域の前記移動速度が、以前のフレームの符号化の間に使用された、以前に判定された符号化決定を監視することによって判定される、請求項１に記載の方法。
【請求項４】
前記少なくとも１つのパラメータが量子化パラメータであり、前記量子化パラメータが、前記関心領域の移動速度の増加とともに増加するように適合されている、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記少なくとも１つの符号化パラメータが、前記関心領域の前記移動速度が、前記所定の閾値を上回る場合に、マクロブロックのイントラ符号化が実施されるように、インター符号化からイントラ符号化に変更することに関する、請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記少なくとも１つの符号化パラメータが、前記関心領域の前記移動速度が、前記所定の閾値を上回る場合に実施される、デブロッキングフィルタの使用に関する、請求項１から５のいずれか一項に記載の方法。
【請求項７】
ビデオサーバ（Ｓ）に結合されたクライアント（Ｃ）への後続の送信のためにビデオを符号化するためのビデオサーバ（Ｓ）であって、前記ビデオの以前に符号化および送信されたフレームうちの連続したフレーム間の関心領域の移動速度が、所定の閾値を上回るかを判定し、前記所定の閾値を上回る場合に、少なくとも１つのビデオ符号化パラメータを適合させるように構成された、ビデオサーバ（Ｓ）。
【請求項８】
前記関心領域上の前記クライアントによって発行されるコマンドを監視することによって、前記関心領域の前記移動速度を判定するようにさらに構成されている、請求項７に記載のビデオサーバ（Ｓ）。
【請求項９】
以前のフレームの符号化の間に使用された、以前に判定された符号化決定を監視することによって、前記関心領域の前記移動速度を判定するようにさらに構成されている、請求項７に記載のビデオサーバ（Ｓ）。
【請求項１０】
前記少なくとも１つのパラメータが量子化パラメータであり、前記ビデオサーバが、前記関心領域の移動速度の増加とともに前記量子化パラメータを増加するように適合させることが可能である、請求項７から９のいずれか一項に記載のビデオサーバ（Ｓ）。
【請求項１１】
前記少なくとも１つの符号化パラメータが、前記関心領域の前記移動速度が、前記所定の閾値を上回る場合に、マクロブロックのイントラ符号化が実施されるように、インター符号化からイントラ符号化に変更することに関する、請求項７から１０のいずれか一項に記載のビデオサーバ（Ｓ）。
【請求項１２】
前記少なくとも１つの符号化パラメータが、前記関心領域の前記移動速度が、前記所定の閾値を上回る場合に実施される、デブロッキングフィルタの使用に関する、請求項７から１１のいずれか一項に記載のビデオサーバ（Ｓ）。
【請求項１３】
データ処理装置上で実行されると、請求項１から６のいずれか一項に記載の方法ステップを実行するように構成されたソフトウェアを備えた、コンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオエンコーダパラメータを適合させるための方法および装置に関する。
【背景技術】
【０００２】
超高解像度ビデオとも称される、高空間分解能ビデオがますます一般的になっている。このタイプのコンテンツは、フレームごとに１９２０×１０８０画素を有する高解像度（以下、ＨＤと略される）ビデオから、高度光学および画像センサで直接獲得されるか、または複数のカメラからの貼り合わせ画像（ｓｔｉｔｃｈｅｄ  ｖｉｅｗｓ）から取得されるかのいずれかによる、より高解像度のビデオにまで及ぶ。このタイプのコンテンツ全体を直接エンドユーザデバイスに配信することは、帯域幅の制約に起因して、不可能であることが多い。
【０００３】
考えられる解決策は、送信前に完全なコンテンツをダウンサンプルすることであるが、これは、低品質画像をもたらすことになり、望ましくない。
【０００４】
別の解決策では、エンドユーザが最初に、以下、本明細書の下記全体を通じてＲＯＩと省略される関心領域を操作する。このＲＯＩは、典型的には、ＵＨＤ入力ビデオと比較して、非常に小さく、ユーザデバイスの本来のディスプレイ解像度に適することがある。エンドユーザコマンドに応答して、画像は、符号化および送信前に、サーバ側において、所望のＲＯＩにトリミングされる。この解像度は、ユーザごとの符号化というコストを払って、より良い画像品質を提供する。しかしながら、このようなシステムは、非常に多数のユーザに合わせて調整することができず、しかしそれは、例えば、監視アプリケーションに対して非常に適するものとなる。拡張性を改善するために、各々が所定の数の隣接ユーザにサービスを提供する役割を果たす複数のプロキシサーバ上で、システムを分散することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
エンドユーザが、例えば、対話形式にそれらのＲＯＩをエンドユーザ自身のディスプレイ上で全体的に利用可能な空間的コンテンツに置き換えることによって、ナビゲートすることを開始する場合に、このような対話型ＲＯＩ符号化での問題が生じる。エンコーダの構成に応じて、このことに対する従来技術の解決策について、２つの見解をなすことができる：
ａ）コンスタントな品質の符号化（固定量子化）は、劇的な帯域幅の増加をもたらす。
ｂ）コンスタントなビットレートの符号化は、制御の下、帯域幅を維持するが、静的ＲＯＩの場合でさえ、品質は劣ることになる。
【０００６】
したがって、本発明の実施形態の目的は、知られているタイプであるが、上述した欠点を示さない方法を提示することにある。
【課題を解決するための手段】
【０００７】
本発明の実施形態によれば、この目的は、サーバからクライアントへ送信されるビデオの符号化に使用されることになる少なくとも１つのビデオ符号化パラメータを適合させるための方法によって達成され、前記方法は、前記ビデオの以前に符号化および送信されたフレームのうち連続したフレーム間の関心領域の移動速度が、所定の閾値を上回るかを判定するステップと、前記所定の閾値を上回る場合に、前記少なくとも１つのビデオ符号化パラメータを適合させるステップと含む。
【０００８】
このようにして、ＲＯＩの移動自体の速度に基づいて、エンコーダパラメータを適合させることによって、高速のＲＯＩの動きが検出される場合に、帯域幅のピークが回避される。加えて、ビデオ品質に関する影響を削減することができる。
【０００９】
実施形態では、前記関心領域の前記移動速度は、前記関心領域上の前記クライアントによって発行されるコマンドを監視することによって判定される。
【００１０】
このことは、ユーザのナビゲーションコマンドからの直接入力を使用することを可能にする。
【００１１】
別の実施形態では、前記関心領域の前記移動速度は、以前のフレームの符号化の間に使用された、以前に判定された符号化決定を監視することによって判定される。
【００１２】
この場合では、ＲＯＩの動きは、エンコーダによってなされた以前の符号化決定の一部の統計に基づいて、間接的に判定される。
【００１３】
適合されることになる少なくとも１つの符号化パラメータを、前記関心領域の移動速度の増加とともに増加するように適合することができる量子化パラメータとすることができる。
【００１４】
代わりに、前記少なくとも１つの符号化パラメータは、前記関心領域の前記移動速度が前記所定の閾値を上回る場合に、マクロブロックのイントラ符号化が実施されるように、インター符号化からイントラ符号化に変更することに関してもよい。
【００１５】
さらなる別の変形では、少なくとも１つの符号化パラメータは、前記関心領域の前記移動速度が前記所定の閾値を上回る場合に実施される、デブロッキングフィルタの使用に関してもよい。
【００１６】
本発明はなお、上記の方法を実行するためのビデオサーバの実施形態に関する。
【００１７】
本発明はなお、データ処理装置上で実行されると、請求項１から６のいずれかに一項に記載の方法ステップを実行するように構成されたソフトウェアを備えたコンピュータプログラム製品に関する。
【００１８】
特許請求の範囲において使用される用語「結合される（ｃｏｕｐｌｅｄ）」は、直接接続のみに限定されるものと解釈されるべきでないことが理解されよう。したがって、「デバイスＢに結合されたデバイスＡ」の表現の範囲は、デバイスＡの出力が、直接、デバイスＢの入力に接続される、デバイスまたはシステムに限定されるべきでない。Ａの出力とＢの入力との間に、他のデバイスまたは手段を含むパスとすることができる、パスが存在することを意味する。
【００１９】
特許請求の範囲において使用される用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」は、それ以降に記載された手段に限定されるものと解釈されるべきでないことが理解されよう。したがって、「手段ＡおよびＢを備えたデバイス」の表現の範囲は、コンポーネントＡおよびＢのみから構成されるデバイスに限定されるべきでない。本発明について、単にデバイスに関連するコンポーネントがＡおよびＢであることを意味する。
【００２０】
添付の図面と併用される、以下の実施形態の説明を参照することによって、発明の上記ならびに他の目的および特徴がより明確となり、発明自体が最もよく理解されるであろう。
【図面の簡単な説明】
【００２１】
【図１ａ】クライアント／サーバシステムの典型的な従来技術の構成を模式的に示す図である。
【図１ｂ】クライアント／サーバシステムの典型的な従来技術の構成を模式的に示す図である。
【図２】ＲＯＩの移動速度を測定する可能性を説明する図である。
【図３ａ】本発明によるクライアント／サーバ構成の実施形態を示す図である。
【図３ｂ】本発明によるクライアント／サーバ構成の実施形態を示す図である。
【図４】方法の実施形態を示す図である。
【発明を実施するための形態】
【００２２】
本明細書における任意のブロック図は、本発明の原理を具体化する例示的な回路の概念図を表すことを、当業者によって理解されるべきである。同様に、任意のフローチャート、フロー図、状態遷移図、および疑似コードなどが、コンピュータ可読媒体において実質的に表され、それで、コンピュータまたはプロセッサによって、そのようなコンピュータまたはプロセッサが明示的に示されるか否かにかかわらず、実行されてもよい、種々の処理を表すことが理解されよう。
【００２３】
図１ａおよび図１ｂは、例えば、可変ビットレート（ＶＢＲ）出力を有するＨ．２６４エンコーダに基づくことができる、従来技術のシステムを記す。図１ａにおいて記されるような典型的な構成では、多数のビデオファイルを記憶することができる、ビデオストレージデバイスＶＳは、これらのビデオファイルをクライアントデバイスＣに提供するためのサーバＳの一部である。代替的な実施形態では、このビデオストレージデバイスは、サーバＳに結合された別個のエンティティとすることができる。任意のタイプのメモリ、例えば、ハードディスクドライブ、電子的消去可能もしくは不揮発性メモリ、またはデジタルデータを記憶することが可能な任意の他のタイプのメモリから製作可能なストレージデバイスの記憶容量を考慮すると、ビデオファイルは、一般的に、圧縮形式で記憶される。これらの状況では、デコーダＤＳは、ビデオストレージとサーバとの間に置かれてもよく、または、図１ａに記されるような、サーバ自体の一部とすることができ、記憶された圧縮ビデオファイルを復元して、それらを元の非圧縮形式に戻す。代わりに、図１ｂに記されるように、非圧縮のビデオを出力することができる、１つまたは複数のカメラを備えた取得システムＡＳに、および、サーバのＲＯＩトリミングデバイスＣＲに直接、サーバを結合することができる。
【００２４】
したがって、両構成では、元のビデオファイルはこのようなＲＯＩトリミングデバイスＣＲによって受信され、ＣＲは、このトリミングについてクライアントデバイスＣから命令を受信するようにさらに構成される。クライアントデバイス自体は、一般的に、サーバからクライアントに送信されるビデオを示すためのディスプレイ（図１ａおよび図１ｂでは示されず）と、ユーザからトリミング命令を受信するためのユーザインタフェースとを備える。これらの命令は、ユーザＵによって、例えば、タッチインタフェース、キーボード、マウス、またはＲＯＩのロケーションについて、もしくは表示された画像をそれにトリミングすることをユーザが望むサイズについて、の情報を受信するための任意の他のタイプのジェスチャ検出インタフェースなどを備えることができる、任意のタイプのユーザインタフェース（図１ａおよび図１ｂでは示されず）を介して、入力されてもよい。それらは、一般的に、ＲＯＩのサイズが最初にエンドユーザのデバイスの解像度と等しいと想定される、パン／チルトコマンドなどの、表示されたＲＯＩナビゲーションコマンドが一般的である。また、ＲＯＩのサイズを変更することを可能にするズームコマンドを入力することができる。このユーザインタフェースは、サーバにおいて、これらのユーザインタフェースから受信された命令を、ＲＯＩトリミングデバイスＣＲによって理解可能な適切なコマンドに変換するように構成された、ユーザコマンドプロセッサＵＣＰに結合される。
【００２５】
別の構成では、トリミング命令は、ユーザコマンドプロセッサによって自律的に、したがって、ヒューマンユーザからのいかなる入力もなしに、クライアントデバイスのディスプレイのサイズの制限を考慮して提供される。例えば、サーバにおける画像の元のサイズが８０００×４０００画素を含み、クライアントのディスプレイが単に、１８８０×８００画素を示すように構成される場合、ユーザコマンドプロセッサは自律的に、デバイスをトリミングするＲＯＩへのトリミング命令を生成して、１８８０×８００画素の関心領域を選択するようにしてもよい（例えば、画像の左上角、または８ｋ×４ｋ画像上の中心の）。
【００２６】
これらのトリミング命令を受信すると、ＲＯＩをトリミングするデバイスはしたがって、大型画像をトリミングし、したがって、示された（選択され、または事前定義された）領域を、大型画像から所望の減じたサイズまで切り取り、この符号化されたＲＯＩをクライアントに送信するために、選択されたＲＯＩを符号化するためのエンコーダにこれを提供する。クライアントによってそれらが受信されると、クライアントのデコーダデバイスＤＣは次に、受信されたトリミング画像を復号し、ユーザＵによって見られるように、これをディスプレイデバイス（図１ａおよび図１ｂでは示されない）に提供する。元の画像の選択されたトリミング部分は、ＲＯＩ画像と呼ばれる。したがって、サーバエンコーダＥは、図１ａおよび図１ｂのように、トリミングＲＯＩ画像を受信する。
【００２７】
ユーザが、例えば、クライアントユーザインタフェースを介してパン／チルト入力命令を提供することによって、ＲＯＩナビゲーションを開始するときに、ユーザコマンドプロセッサＵＣＰは、デバイスをトリミングするＲＯＩに理解可能なコマンドにそれらを変換する。先に言及したように、エンドユーザが、それらのＲＯＩを、全体的に利用可能な部分コンテンツへナビゲートすること（すなわち、対話形式で置き換える）を開始する場合に、問題が生じることがある。エンコーダの構成に応じて、このことに対する従来技術の解決策について、２つの見解をなすことができる：
ａ）コンスタントな品質の符号化（固定量子化）は、劇的な帯域幅の増加をもたらす。確かに、高速なＲＯＩの移動に対し、動き補償が非常に小さく、または全くない可能性があり（参照フレームが、十分に現在のＲＯＩの位置にオーバーラップしない）、実効的に、イントラのみの符号化と同程度の帯域幅をもたらす。実験によれば、帯域幅が、ファクタ６以上で増加する可能性があることが示された。１Ｍｂｐｓストリーム（平均で）に対し、帯域幅が６Ｍｂｐｓまで増加し、さらにそれ以上さえ観察された。
ｂ）コンスタントなビットレートの符号化は、制御の下、帯域幅を維持するが、静的ＲＯＩの場合でさえ、品質は劣ることになる。
【００２８】
これらの従来技術の問題を解決するために、サーバＳは、ユーザによって入力されたＲＯＩの移動の速度に基づいて、エンコーダパラメータを動的に適合させるための追加的な機能性を含む。所定の閾値を上回るＲＯＩの動きが検出されるときに、帯域幅のピーク、および／または、ビデオ品質に関する非常に甚大な影響を回避するように、符号化パラメータが更新される。
【００２９】
この閾値を、例えば、フレームごとに３２画素などの、フレームごとの画素シフトの絶対数で表現することができる。それはまた、例えば、２つのマクロブロック（Ｈ．２６４符号化に対し、１６×１６画素に対応した１マクロブロックとして、３２画素に対応する）などの、フレームごとのマクロブロックシフトの絶対数で表現されてもよい。別の実施形態では、閾値は変化することができ、エンコーダの性能自体の統計的測定に基づくことができる。これらの、および他の例は、本明細書のさらなる段落においてより詳細に説明される。
【００３０】
実施形態では、動き検出、およびどのようにエンコーダパラメータが更新されることになるかの判定は、サーバの別個のモジュールにおいて実行される。このことは、サーバがレートコントローラモジュールＲＣＭを備えている、図３ａおよび図３ｂにおいて示される。図面への過負荷を避けるために、ビデオストレージ、デコーダ、取得システム、およびユーザは、それらが本発明に貢献する真の要素ではないものとして、図３ａおよび図３ｂではもはや示されない。
【００３１】
また、他の実施形態では、サーバが、この追加の機能性を組み込むために別個のモジュールＲＣＭを含む必要がなく、その上、１つまたは複数のコンピュータプログラムからその命令を受信することができる、１つのプロセッサデバイスの手段によってすべてのサーバ機能を実行することができ、当該命令は、コンパクトディスクなどのキャリア上で符号化され、またはサーバ内に取付可能もしくは組み込まれた別のタイプの固定もしくは移動可能なメモリ上に記憶されるかのいずれか、またはストレージサーバから、考慮されているビデオサーバにダウンロード可能であることが理解される。
【００３２】
ＲＯＩの移動の速度が、ユーザ入力コマンドに基づいて検出される実施形態では、レートコントローラモジュールＲＣＭの機能性は、ＲＯＩについて、または一般に表示された画像についてのユーザナビゲーションコマンドがまた、受信および分析されることになることを意味する。このことは、このレートコントローラブロックによるユーザコマンドｃｍｄのインターセプトおよび受信を示す、矢印１ａによって、図３ａにおいて示される。さらに、レートコントローラの機能性は、サーバエンコーダＥによって使用されることになる符号化パラメータの再計算、および、これらの、場合によっては適合されたパラメータのエンコーダへのプロビジョニングを意味する。このことは、矢印２によって示される。影響を受ける可能性がある符号化パラメータは、例えば、それが使用しなければならない量子化パラメータＱＰなどである。
【００３３】
図３ｂに記される代替的な実施形態では、ＲＯＩの移動は、サーバエンコーダの動き推定動作を監視することによって、間接的に検出される。この監視は、サーバエンコーダＥからレートコントローラモジュールＲＣＭへの、矢印２ａによって示される。
【００３４】
両実施形態はなお、より詳細に説明される。さらなる説明のために、ＩおよびＰフレームの単一のシーケンスを使用した表示順序と同一の順序で、フレームが符号化されることが想定される。表示および符号化順序が異なる場合、エンコーダはまた、レートコントローラに、符号化フレームの順序を指示することができる。このことは、レートコントローラが、現在のフレーム（以前のフレームと表示順序において異なってもよい）の符号化に使用されることになる参照フレームについて、ＲＯＩの動きを測定することを可能にする。
【００３５】
図３ａに記される実施形態では、ユーザナビゲーションコマンドからの直接入力は、レートコントローラに提供される。変形では、このようなユーザナビゲーションコマンドの連続する１つを、レートコントローラによってインターセプトすることができ、レートコントローラは、それらを分析し、２つの連続したフレーム間で、画素において表現される２Ｄ変換ベクトルをそれらから導出するように構成される。この情報に基づいて、レートコントローラは、変換ベクトルの長さとして表現されるＲＯＩ速度（画素／フレーム）を容易に導出することができる。
【００３６】
ＲＯＩの動きは次に、所定の閾値に対して比較され、したがって、計算された速度が、例えば、５画素／フレームを上回るなどの、この所与の閾値を上回るときに、高速であると見なされ得る。一部の実施形態では、最適な閾値を経験的に事前に判定することができる。
【００３７】
別の実施形態では、ＲＯＩの動きを判定するために、他の基準を算出することができる。例は、現在のＲＯＩと、現在のＲＯＩの符号化に使用される利用可能な参照フレームとの間でオーバーラップするエリアの割合を計算することによるものとすることができる。このことは、実線で記された現在のフレームｆとともに、現在のフレームｆの符号化に使用される２つの参照フレームｆ１ｒｅｆおよびｆ２ｒｅｆを示す、図２において例示される。検討されているＲＯＩの符号化に使用される、オーバーラップする領域Ａの統合が、閾値Ｔよりも小さい場合、ＲＯＩの動きが高速であり、閾値を上回っていると見なされ、符号化パラメータの適合を有効にする。このエリアが所定の閾値よりも小さい場合、ＲＯＩの動きがいまだに低速であると見なされ、当面の動き推定予測を依然として使用し、そのことは、符号化パラメータが適合されないことになることを意味する。この例では、閾値は、ＲＯＩからマクロブロックの２行かける２列をひいた全エリアによって与えられてもよい。このことは、エンコーダによって使用される参照フレームの選択された数について、任意の２Ｄ  ＲＯＩの動きをカバーすることを可能にする。
【００３８】
他の変形実施形態では、ユーザナビゲーションの入力がまた、例えば、ズーム比、３Ｄ回転行列などの、双方向性モードのタイプに応じて、他の形式で表現され得る。基準もまた、このようなデータから導出することができ、さらにはそれらの基準に対する所定の閾値に対して比較することができる。
【００３９】
図３ｂにおいて記される実施形態では、動き推定についてエンコーダＥがどのように動作しているかに関するフィードバックを取得することによって、ＲＯＩの動きも検出することができる。したがって、ＲＯＩの動きは、エンコーダによってなされる符号化決定に関する一部の統計に基づいて間接的に検出され、例えば：
−  インター予測フレームにおけるイントラ符号化マクロブロックの量が、所定の閾値を上回る場合
−  残余信号における平均エネルギーが、ある閾値を上回る場合
−  結果として生じるビットレートのピークが、事前定義されたターゲットビットレートおよびマージンを上回る場合
【００４０】
このような測定が、レートコントローラＲＣＭによってオンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）で使用されて、符号化パラメータを更新することができ、またはオフライン方式で使用されて、上記段落で説明された図３ａによる実施形態の場合に、どのように最良の閾値を定義するかを知ることができる。
【００４１】
図３ａおよび図３ｂについて説明されたすべての実施形態に対し、速いＲＯＩの動きが検出される場合に、適切な適合された符号化パラメータでエンコーダを指示することが目的となる。このことは、ビットレートのピークを回避し、可視的なアーチファクト（ｖｉｓｉｂｌｅ  ａｒｔｉｆａｃｔｓ）を防止し、および複雑な処理を低減することを可能にする。
【００４２】
実施形態では、ビットレートのピークを回避するように符号化パラメータが修正される。というのは、適切な動き推定をエンコーダが行うことが不可能であると、通常、イントラフレーム符号化情報が多くなるからである。ビットレートを減少させる基本手段は、ＲＯＩの動きに関する情報から量子化パラメータＱＰを修正することである。レートコントローラＲＣＭがこの情報を使用して、エンコーダに対するＱＰを変化させる方法は、ＲＯＩの速度が閾値未満である場合に、レートコントローラが低ＱＰ（高品質画像をもたらす）を出力するといったものである。実施形態では、１６以下のＱＰ値を、例えば、選択することができる。ＲＯＩの速度が増大するときに、出力ＱＰも増大される。一般的に、レートコントローラは、関数ＱＰ＝ｆ（ＲＯＩ−速度）を実装し、この関数は、線形、階段状などとすることができる。最良のマッチング関数を、実験を使用して判定することができる。非常にシンプルな階段関数は、例えば、以下のようになり得る。
−  低い動きに対するデフォルト：ＱＰ＝１６
−  高い動き：ＱＰ＝３２
【００４３】
別の実施形態では、品質に関するユーザが感知する影響を制限することを目的に、符号化パラメータを適合させることができる。本来、ＲＯＩの動きが高いときに、ユーザは、画素の精度への敏感性がより低くなる。しかしながら、高いＱＰにおいては、静的マクロブロックグリッド（ｍａｃｒｏｂｌｏｃｋ−ｇｒｉｄ）が明らかに見えてくることがある（ブロッキングアーチファクト（ｂｌｏｃｋｉｎｇ  ａｒｔｅｆａｃｔｓ））。この場合、エンコーダのインループデブロッキングフィルタを有効または強化することができる。Ｈ．２６４標準では、インループデブロッキングフィルタが定義される。そのパラメータを、ビットストリームにおける他の符号化パラメータから（特に、量子化パラメータから）推論し、またはフラグｄｅｂｌｏｃｋｉｎｇ＿ｆｉｌｔｅｒ＿ｃｏｎｔｒｏｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に設定されるときに、スライスヘッダにおいて明示的にシグナリングするかのいずれかとすることができる。エンコーダは、次に、ｄｉｓａｂｌｅ＿ｄｅｂｌｏｃｋｉｎｇ＿ｆｉｌｔｅｒを０に設定することによって、デブロッキングフィルタの強制使用をシグナリングし、デブロッキングフィルタの強度が、パラメータｓｌｉｃｅ＿ａｌｐｈａ＿ｃ０＿ｏｆｆｓｅｔ＿ｄｉｖ２およびｓｌｉｃｅ＿ｂｅｔａ＿ｏｆｆｓｅｔ＿ｄｉｖ２で、どのようにＱＰによって影響されるかを制御することができる。両パラメータの値が高くなると、より多くデブロッキングフィルタが、ブロック境界をまたがって適用される（所与のＱＰ値に対し）。
【００４４】
これらのパラメータを制御するためにレートコントローラがＲＯＩの速度を使用する方法は、以下の通りであり得る。上記説明されたように、高速のＲＯＩの動きが検出されるときに、場合によっては、経験的に判定されることになるフィルタリング制御に対して最適化された閾値で、フィルタを強制することができる。この場合、ｓｌｉｃｅ＿ａｌｐｈａ＿ｃ０＿ｏｆｆｓｅｔ＿ｄｉｖ２およびｓｌｉｃｅ＿ｂｅｔａ＿ｏｆｆｓｅｔ＿ｄｉｖ２が、ＲＯＩの速度の増加関数として定義される。最も満足のいくビジュアル効果を生み出す関数を、経験的に判定することができる。
【００４５】
第３の実施形態では、速いＲＯＩの動きが検出されるときに、エンコーダは、イントラモードにおいてマクロブロックを符号化することを決定してもよい。一部の計算サイクルを節約するために、レートコントローラはしたがって、高速のＲＯＩの動きが上記説明されたように検出されるときに（場合によっては、複雑性制御を処理するために最適化された閾値で）、マクロブロックのイントラ符号化を実施することができる。このことは、エンコーダが、動き推定に対する処理ステップをスキップすることを可能にする。
【００４６】
符号化パラメータの上述した適合を、他の実施形態において、どのような順序でも組み合わせることができることが明白である。図４は、方法の異なるステップを例示するフローチャートの実施形態を付与することによって、これを例示する。第１のステップ１００では、ＲＯＩの動きが、例えば、上記説明された方法によって検出されることになる。実施形態から実施形態へと変化することができる、適切な基準によって表現される、このＲＯＩの動きは、ステップ２００において所定の適切な閾値に対して比較されることになる。この閾値を上回るときに、１つまたは複数の符号化パラメータが適合されてもよい。３つの適合のリストは、ステップ３１０から３３０のそれぞれにおいて言及されるが、それらは、どのような順序で組み合わされてもよく、または、項目３００の下、１つの符号化パラメータの単に１つの選択された適合において実装されるように、独立して選択されてもよい。閾値を上回らないとき、符号化は変更されず、標準の符号化が、ステップ４００が示すように使用される。
【００４７】
本発明の原理が詳細な装置とともに上記説明されてきたが、この詳細な説明が単に例示的なものであり、添付の特許請求の範囲に定義されているような、本発明の範囲を限定するものではないことが明確に理解されることになる。特許請求の範囲では、指定された機能を実行するための手段として表現される任意の要素は、その機能を実行する任意の方法を包含するものと意図される。この方法は、例えば、電子的または機械的要素の組み合わせを含んでよく、これらは任意の形式（したがってファームウェアまたはマイクロコードなどを含む）で、―もしあれば、機能を実現するソフトウェアを実行するための適切な回路と組み合わされた形式、またソフトウェアで制御される回路に結合された機械的要素と組み合わせれた形式で―その機能またはソフトウェアを実行する。このような特許請求の範囲によって定義される本発明は、種々の定義された手段によって提供される機能性が結合され、特許請求の範囲が要求する方式で一緒にされ、特にそのように定義されない限り、任意の物理的構造は、特許請求される発明の新規性にほとんどまたは全く重要ではないという事実に帰する。したがって、出願人は、それらの機能性を提供することができる任意の手段を、本明細書で示されたそれらと均等なものと見なす。
【図１ａ】
2015526003.tif 000003
【図１ｂ】
2015526003.tif 000004
【図２】
2015526003.tif 000005
【図３ａ】
2015526003.tif 000006
【図３ｂ】
2015526003.tif 000007
【図４】
2015526003.tif 000008
【国際調査報告】
2015526003.tif 000009
2015526003.tif 000010
2015526003.tif 000011