JP2015515807A - 映像圧縮レポジトリおよびモデル再利用 - Google Patents

Abstract

【課題】高次のモデリングを適用することにより、従来の映像エンコーダと同じ一般処理フロー及び一般処理フレームワークを維持しながら、従来のコーデックのインター予測プロセスの根本的な限界を解消し、向上したインター予測を提供する。【解決手段】映像データの提供方法は、大域的な特徴モデルライブラリからの特徴モデルを利用する特徴ベース圧縮プロセスにより、特徴モデルを暗示的に用いることによって対象の映像内の符号化するマクロブロックを指定し、符号化された映像データを得る過程と、要求に応答して、要求側のデバイスに符号化された映像データを送信する過程とを含む。大域的な特徴モデルライブラリは、対象の映像ストリームと異なる少なくとも１つの入力映像を受け取り、入力映像のそれぞれについて、特徴情報および対応する特徴モデルを生成することによって構成される。【選択図】図９Ｂ

Description

関連出願

本願は、2012年5月22日付出願の米国仮特許出願第61/650,363号および2012年3月27日付出願の米国仮特許出願第61/616,334号の利益を主張する。本願は、さらに、2013年2月20日付出願の米国特許出願第13/772,230号の利益を主張する。この2013年2月20日付出願の米国特許出願第13/772,230号は、2008年10月7日付出願の米国仮特許出願第61/103,362号の利益を主張する2009年10月6日付出願の米国指定かつ英語で記載されたPCT/US2009/059653の米国移行出願である、2009年10月6日付出願の米国特許出願第13/121,904号の一部継続出願である。この米国特許出願第13/121,904号は、2007年1月23日付出願の米国仮特許出願第60/881,966号の利益を主張する2008年1月4日付出願の米国指定かつ英語で記載されたPCT/US2008/000090の米国移行出願である、2008年1月4日付出願の米国特許出願第12/522,322号の一部継続出願である。この2008年1月4日付出願の米国特許出願第12/522,322号は、2006年6月8日付出願の米国仮特許出願第60/811,890号に関連し、さらに、2006年3月31日付出願の米国特許出願第11/396,010号の一部継続出願である。この2006年3月31日付出願の米国特許出願第11/396,010号は、2006年1月20日付出願の米国特許出願第11/336,366号の一部継続出願であり、現在では2008年11月25日付特許の米国特許第7,457,472号である。その2006年1月20日付出願の米国特許出願第11/336,366号は、2005年11月16日付出願の米国特許出願第11/280,625号の一部継続出願であり、現在では2008年10月14日付特許の米国特許第7,436,981号である。その2005年11月16日付出願の米国特許出願第11/280,625号は、2004年11月17日付出願の米国仮特許出願第60/628,819号および2004年11月17日付出願の米国仮特許出願第60/628,861号の利益を主張し、さらに、2005年9月20日付出願の米国特許出願第11/230,686号の一部継続出願であり、現在では2008年11月25日付特許の米国特許第7,457,435号である。その2005年9月20日付出願の米国特許出願第11/230,686号は、2005年7月28日付出願の米国特許出願第11/191,562号の一部継続出願であり、現在では2008年9月16日付特許の米国特許第7,426,285号である。その2005年7月28日付出願の米国特許出願第11/191,562号は、2004年7月30日付出願の米国仮特許出願第60/598,085号の利益を主張し、現在では2007年1月2日付特許の米国特許第7,158,680号である。上記の米国特許出願第11/396,010号は、さらに、2005年3月31日付出願の米国仮特許出願第60/667,532号および2005年4月13日付出願の米国仮特許出願第60/670,951号の利益を主張する。

本願は、さらに、2012年12月21日付出願の米国特許出願第13/725,940号に関連する。この2012年12月21日付出願の米国特許出願第13/725,940号は、2012年9月28日付出願の米国仮特許出願第61/707,650号および2012年3月26日付出願の米国仮特許出願第61/615,795号の利益を主張する。

上記の特許出願の全教示内容は、参照をもって本願に取り入れたものとする。

動画像圧縮（映像圧縮）は、デジタル映像データを、少ないビット数で記憶または伝送可能な形式で表現するプロセスであると言える。映像圧縮アルゴリズムは、映像データの空間的な、時間的なまたは色空間の冗長性や非関連性を利用することにより、圧縮を達成することができる。典型的に、映像圧縮アルゴリズムは、映像データをフレームのグループやペルのグループなどの各部位に分割して、その映像に含まれる冗長な部分を特定し、当該冗長な部分を元々の映像データよりも少ないビット数で表現し得る。このような冗長性を縮小させることにより、より大きな圧縮を達成することができる。映像データを符号化フォーマットに変換する際にはエンコーダを用いる。そして、デコーダを用いることにより、符号化された映像を本来の映像データにほぼ匹敵する形態に変換する。エンコーダ／デコーダを実現するものはコーデックと称される。

標準的なエンコーダは、映像フレームの符号化にあたって、１つの映像フレームを、互いに重複しない複数の符号化単位すなわちマクロブロック（複数の隣接するペルからなる矩形ブロック）に分割する。典型的に、マクロブロック（ＭＢ）は、フレームの左から右の走査順序や上から下の走査順序で処理される。圧縮は、これらのマクロブロックが先に符号化されたデータを用いて予測・符号化される場合に、行われる。同じフレーム内の空間的に隣接する先に符号化したマクロブロックサンプルを用いてマクロブロックを符号化するプロセスは、イントラ予測と称される。イントラ予測は、データに含まれる空間的な冗長性を利用しようとするものである。先に符号化したフレームからの類似する領域と動き予測モデルとを用いてマクロブロックを符号化するプロセスは、インター予測と称される。インター予測は、データに含まれる時間的な冗長性を利用しようとするものである。

エンコーダは、符号化するデータと予測（予測結果）との差分を測定することにより、残差を生成し得る。この残差は、予測されたマクロブロックと本来のマクロブロックとの差分となり得る。また、エンコーダは、動きベクトル情報（例えば、符号化中または復号化中のマクロブロックに対する参照フレーム内のマクロブロックの位置を示す動きベクトル情報）を生成し得る。これらの予測、動きベクトル（インター予測用）、残差および関連データを、空間変換、量子化、エントロピー符号化、ループフィルタなどの他のプロセスと組み合せることにより、映像データの効率的な符号を生成することができる。量子化及び変換を受けた残差は、処理されてから前記予測に加算され、復号化したフレームに組み込まれて、フレームストア（フレームを記憶する手段又は記憶部）に記憶される。このような映像符号化技術の詳細は、当業者であればよく知っている。

Ｈ.２６４／ＭＰＥＧ−４ Ｐａｒｔ１０ ＡＶＣ（Advanced Video Encoding）は、ブロックベースの動き予測・補償を利用して比較的低いビットレートで高品質映像を表現することが可能なコーデック規格である（以降では、「Ｈ．２６４」と称する）。Ｈ．２６４は、ブルーレイディスクだけでなく、インターネット上のビデオストリーミング、テレビ会議、ケーブルテレビおよび直接衛星テレビを含む主要な映像配信チャネルに利用される符号化方式の選択肢の１つである。Ｈ．２６４の符号化基本単位は、１６×１６マクロブロックである。Ｈ．２６４は、広く普及している最新の動画像圧縮規格である。

基礎的なＭＰＥＧ規格は、フレーム内のマクロブロックの符号化方法によって、３種類のフレーム（またはピクチャ）を規定する。そのうちの１つであるＩフレーム（イントラ符号化ピクチャ）は、そのフレームに含まれるデータのみを用いて符号化する。一般的に、映像信号データを受け取ったエンコーダは、まずＩフレームを生成して、映像フレームデータを複数のマクロブロックに分割し、イントラ予測を用いて各マクロブロックを符号化する。このように、Ｉフレームは、イントラ予測マクロブロック（または「イントラマクロブロック」）だけで構成される。Ｉフレームは、符号化済みのフレームからの情報の利用せずに符号化を実行するので、符号化コストが高くなる。Ｐフレーム（予測ピクチャ）は、先に符号化したＩフレーム又はＰフレームからのデータ（参照フレームとも称される）を用いた前方向予測により符号化する。Ｐフレームは、イントラマクロブロックおよび（前方向）予測マクロブロックのいずれも含み得る。Ｂフレーム（双予測ピクチャ）は、前のフレームと後のフレームの両方からのデータを用いた双方向予測により符号化する。Ｂフレームは、イントラマクロブロック、（前方向）予測マクロブロックおよび双予測マクロブロックのいずれも含み得る。

既述したように、従来のインター予測は、ブロックベースの動き予測・補償（ＢＢＭＥＣ）に基づいている。ＢＢＭＥＣプロセスは、ターゲットのマクロブロック（符号化する現在のマクロブロック）と先に符号化した参照フレーム内の同サイズの領域との最良のマッチを探索する。最良のマッチが見つかると、エンコーダは動きベクトルを送信し得る。この動きベクトルは、その最良のマッチのフレーム内位置に対するポインタ、さらに、その最良のマッチと当該最良のマッチに対応する前記ターゲットのマクロブロックとの差分に関する情報を含み得る。映像の「データキューブ」（高さ×幅×フレーム）にわたってこのような探索を徹底的に実行して、マクロブロック毎に最良のマッチを見つけ出すことも可能ではあるが、一般的に演算負荷があまりにも大きくなってしまう。したがって、ＢＢＭＥＣ探索プロセスは制限されて、時間的には探索する参照フレームに制限され、空間的には探索する隣接領域に制限される。すなわち、「最良の」マッチが必ずしも常に見つかるとは限らず、高速で変化するデータの場合には特にそうである。

参照フレームの特定の集合のことを、Group of Pictures（ピクチャのグループ）（ＧＯＰ）と称する。ＧＯＰは、各参照フレーム内の復号化したペルのみを含み、マクロブロックまたはフレームがどのように符号化されていたか（Ｉフレーム、ＢフレームまたはＰフレーム）についての情報を含まない。ＭＰＥＧ−２などの古い映像圧縮規格では、Ｐフレームの予測に１つの参照フレーム（過去のフレーム）を利用し、Ｂフレームの予測に２つの参照フレーム（１つ前のフレームと１つ後のフレーム）を利用する。対照的に、Ｈ．２６４規格では、Ｐフレームの予測にもＢフレームの予測にも、複数の参照フレームを利用することができる。現在のフレームと時間的に隣接するフレームを参照フレームに用いるのが典型的であるが、時間的に隣接するフレームのセット以外のフレームを参照フレームとして指定することも可能である。

従来の圧縮方法では、複数のフレームからの複数のマッチをブレンディング（混合）することにより、現在のフレームの領域を予測し得る。ブレンディングは、複数のマッチの線形混合であったり対数線形混合であったりする。このような双予測方法は、例えば、ある画像から別の画像への移行に経時的なフェードが設けられている際に有効である。フェードプロセスは２つの画像の線形ブレンディングであり、双予測によって効率的にモデル化できる場合がある。従来の標準的なエンコーダの中には、例えばＭＰＥＧ−２内挿モードのように、多数のフレームにわたって線形パラメータの内挿により双予測モデルを合成できるものもある。

Ｈ．２６４規格は、さらに、フレームを、１つ以上の互いに隣接するマクロブロックで構成された領域、具体的には、スライスと称さる空間的に互いに独立した領域に分割することにより、さらなる符号化の自由度を提供する。同じフレーム内の各スライスは、他のスライスとは独立して符号化される（つまり、互いに独立して復号化される）。そして、既述した３種類のフレームと同様に、Ｉスライス、ＰスライスおよびＢスライスが定義される。したがって、１つのフレームは、複数の種類のスライスによって構成され得る。さらに、エンコーダ側では、一般的に、処理したスライスの順番を自由に決めることができる。これにより、デコーダは、デコーダ側に到達するスライスを任意の順番で処理することができる。

過去、ＢＢＭＥＣ予測の限界を回避する目的で、数多くのモデルベース圧縮スキームが提案されてきた。このようなモデルベース圧縮スキーム（この種のスキームとして、ＭＰＥＧ−４ Ｐａｒｔ７規格が最も良く知られている）は、映像内のオブジェクトや特徴を検出及び追跡し、同じ映像フレーム内の残りの部分とは別にそれらオブジェクトや特徴を符号化する。しかし、そのようなモデルベース圧縮スキームでは、映像フレームをオブジェクト領域とオブジェクトでない領域と（特徴領域と特徴でない領域と）に分割することによる問題に直面する。第一に、オブジェクトのサイズは多種多様なので、符号化時には、オブジェクトのテクスチャ（カラーコンテンツ）だけでなく、そのオブジェクトの形状も符号化する必要がある。第二に、動きを伴うオブジェクトを複数追跡することは困難であり、トラッキング（追跡）の精度が低下し、セグメンテーションに誤りが生じる。すると、通常、圧縮性能の低下につながる。第三の問題は、どの映像もオブジェクトや特徴で構成されるとは限らないので、オブジェクト／特徴が存在しない場合には、代わりの符号化スキームが必要となる。

Ｈ．２６４規格により、コーデックは、ＭＰＥＧ−２やＭＰＥＧ−４ＡＳＰ（Advanced Simple Profile）などの古い規格に比べて、小さいファイルサイズで優れた品質の映像を提供することができる。しかし、Ｈ．２６４規格を組み込んだ「従来の」圧縮コーデックで、限られた帯域幅のネットワークで動作し且つ限られたメモリを有するデバイス（例えば、スマートフォンや他のモバイルデバイスなど）での映像の品質向上や解像度向上に対する需要に応える際には、一般的に悪戦苦闘を強いられてきた。そのようなデバイスで満足のいく再生を実現するには、映像の品質や解像度を妥協せざるを得ないことが多い。さらに、映像の解像度を向上させようとするとファイルサイズも増加するので、当該映像を前記デバイスで記憶したり前記デバイス外部に記憶したりする際に課題となる。

本願の出願人による同時係属出願である米国特許出願第13/725,940号（以降では、「940’号出願」と称する）には、上記のセグメンテーションに係る問題を回避することが可能なモデルベース圧縮スキームが記載されている。本願の出願人による同時係属出願である940’号出願のモデルベース圧縮フレームワーク内においても、オブジェクト／特徴を検出及び追跡するが、これによって当該オブジェクト／特徴を明示的に（そのまま）符号化するのではなく、むしろ、映像フレーム内の符号化する重要な領域を特定するのに利用する。そして、そのオブジェクト／特徴を近傍のマクロブロックと関連付けてから、「従来の」コーデックと同様にマクロブロックを符号化する。このようにモデル化情報を暗示的（潜在的）に利用することにより、前述のセグメンテーションに係る問題を、次の２つの仕組みによって軽減する。まず、符号化単位（マクロブロック）のサイズを一定に維持することができる（つまり、オブジェクト／特徴の形状を符号化する必要がなくなる）。さらに、トラッキング精度の低下による影響を抑えることができる（というのも、トラッキングは動き予測過程を支援するだけで、動き予測過程を決定付けるものではないからである）。その他にも、本願の出願人による同時係属出願である940’号出願のＭＢＣＦ内では、オブジェクト／特徴が存在しない場合に従来の方式での圧縮法を利用できる代替的選択肢も含め、複数の忠実度で映像データをモデル化することができる。このようなハイブリッド符号化スキームにより、必要なときにだけモデル化情報を利用し、必要でないときには、そのようなモデル化情報が不正確に利用されるのを確実に防ぐことができる。

Meadに付与された米国特許第6,088,484号には、標準的なモデルベース圧縮スキームを拡張させたものが提案されている。具体的には、所与の映像内で検出されたオブジェクトを記憶し、別の映像内での類似するオブジェクトの圧縮時に、そのオブジェクトを再利用することによって当該圧縮を支援する。しかし、このMeadの特許のモデルベース圧縮スキームでは、対象の（new）映像内のオブジェクト／特徴を明示的に（すなわち、直接）符号化するので、前述のセグメンテーションに係る問題と同じ問題（つまり、オブジェクト／特徴とオブジェクト／特徴でないものとを正確に分割しなければならないという問題）に直面する。これに対し、本発明は、オブジェクトモデル／特徴モデルを暗示的に使用することによって符号化対象の重要なマクロブロックを示すという、本願の出願人による同時係属出願である940’出願のフレームワーク内で、モデル再利用圧縮スキームを提案する。これにより、モデル化によるほぼ全ての利点を維持しながら、前述のセグメンテーションに係る問題を回避することができるので、エンコーダの予測が向上する。

本発明は、従来の映像コーデックのインター予測プロセスの根本的な限界を認識し、高次のモデリング（モデル化）を適用することにより、従来のエンコーダと同じ一般処理フロー及び一般処理フレームワークを維持しながら、上記のような限界を解消し、向上したインター予測を提供する。

本発明は、同じ映像内の特徴を検出、モデル化及び追跡し、その特徴情報を用いて前記同じ映像内の後続データの予測及び符号を向上させる、本願の出願人による同時係属出願である940’出願に記載されたモデルベース圧縮アプローチをベースとする。このように、940’出願では、同じ映像内で特徴情報を生成し、その特徴情報を用いて前記同じ映像内の後続の映像セグメントの符号化を支援する「オンライン」特徴ベース予測を実行する。一方で、本発明では、そのような「オンライン」特徴ベース予測を拡張させた「オフライン」特徴ベース予測を実行する。具体的には、所与の映像からの特徴情報をモデルライブラリ内に持続させ（すなわち、保存し）、これを別の映像内のターゲットのマクロブロックを特定するのに再利用することにより、その別の映像のデータの符号化を支援する。しかも、本発明では、ターゲットの映像内における特徴をセグメンテーション（分離）せずに済む。標準的な圧縮法や940’出願のオンライン予測は１つの映像内の時間的な冗長性を利用しようとするのに対し、本発明にかかるオフライン予測は複数の映像に及ぶ冗長性を利用する。

本発明にかかるオフライン特徴ベース圧縮スキームの主要なコンポーネントは：（ｉ）少なくとも１つの入力映像から特徴モデルおよび対応する情報を生成し、その特徴情報を保存すること；（ｉｉ）保存した特徴情報を再利用して、（前記入力映像と異なるか又は前記入力映像と関連しない）別の映像の圧縮時に、その別の映像内の特徴をセグメンテーションすることなく当該圧縮を向上させること；（ｉｉｉ）入力映像の大規模な集合からの特徴情報で構成された特徴モデルライブラリを形成すること；および（ｉｖ）その特徴モデルライブラリを用いて、非関連の映像又はターゲットの映像を復号化すること；の４つである。形成されるモデルライブラリは、個人用ライブラリ（パーソナルライブラリ）、「スマート」モデルライブラリ、差分ライブラリ、予測型ライブラリなどに特化され得る。予測型モデルライブラリは、様々な需要シナリオに対処できるように変更可能である。

前述の内容は、添付の図面に示す本発明の例示的な実施形態についての以下の詳細な説明から明らかになる。異なる図をとおして、同一の符号は同一の構成又は構成要素を指している。図面は必ずしも縮尺どおりではなく、むしろ、本発明の実施形態を示すことに重点を置いている。

本発明の一実施形態にかかる特徴モデリングを示すブロック図である。 本発明の一実施形態にかかる特徴トラッキング（特徴の追跡）を示すブロック図である。 レポジトリの例示的な一実施形態によるモデル抽出および特徴モデル生成の様子を示すフロー図である。 具体例における特徴ベース圧縮ツールのスクリーンショットである。 具体例における特徴ベース圧縮ツールのスクリーンショットである。 マクロブロックを、マクロブロックの境界と整合した特徴としてモデル化する際の処理過程を示すブロック図である。 レポジトリによるインデックス生成過程を示すブロック図である。 レポジトリによるインデックス利用過程を示すブロック図である。 相関関係テーブルの集合である正規化キューブを示すブロック図である。 インデックスの生成過程の例示的な一実施形態を示すフロー図である。 インデックスを用いて特徴をルックアップする過程の例示的な一実施形態を示すフロー図である。 レポジトリの例示的な実施形態による他の処理を示すフロー図である。 レポジトリの例示的な実施形態による一処理を示すフロー図である。 クライアントデバイスにネットワークを介して動作可能に接続されるレポジトリの例示的な一実施形態を示すブロック図である。 クライアントデバイスとネットワークを介して通信するレポジトリの例示的な他の実施形態を示すブロック図である。 クライアントデバイスにネットワークを介して動作可能に接続されるレポジトリの例示的な一実施形態を示すブロック図である。 実施形態を実現するためのコンピュータネットワーク環境を示す概略図である。 図１１Ａのネットワークのコンピュータノードを示すブロック図である。

全ての特許公報、全ての特許公開公報およびこれらの公報に引用されている全ての文献の全教示内容は、参照をもって本明細書に取り入れたものとする。以下では、本発明の例示的な実施形態について説明する。

本発明は、標準的な各種符号化方法や各種符号化単位（コーディングユニット）に適用可能である。以下では、特記しない限り、「従来」や「標準的」といった用語（「圧縮」、「コーデック」、「符号」、「エンコーダ」といった用語と共に使用し得る）はＨ．２６４のことを指し、さらに、「マクロブロック」とは、一般性を失うことなくＨ．２６４の符号化基本単位のことを指すものとする。

＜特徴モデルの生成および保存＞

＜特徴の定義＞

本発明の構成要素には、記憶時または伝送時にデジタル映像データを最適に表現することができる映像圧縮プロセス及び映像解凍プロセスが含まれ得る。当該プロセスは、映像データの空間的な、時間的なまたはスペクトル的な冗長性や非関連性を有効活用する少なくとも１つの映像圧縮／符号化アルゴリズムを備え得るか又はそのようなアルゴリズムとインターフェースし得る。また、そのような有効活用は、特徴ベースのモデル／パラメータの使用及び保持によって行われ得る。以降では、「特徴」および「オブジェクト」という用語を置き換え可能に使用する。オブジェクトとは、一般性を失うことなく「大規模な特徴」と定義することができる。データのモデル化には、特徴およびオブジェクトのどちらも利用することができる。

特徴とは、互いに近接するペルのグループであって、データ複雑性を示すグループのことを言う。データ複雑性は、後述するように様々な基準（criteria）で検出可能である。圧縮の観点からみると、データ複雑性の特徴とは、究極的に言えば「符号化コストが高いこと」である。符号化コストが高いとは、従来の映像圧縮法によるペルの符号が、「効率的な符号化」と考えられる閾値を超えることを指している。所与の領域に対し、従来のエンコーダが過度の帯域量（bandwidth）を割り当てる場合（従来のインターフレーム探索では、従来の参照フレーム内に当該所与の領域に対する良好なマッチを見つけ出せない場合）には、その領域は「特徴に富んで」おり、特徴モデルベースの圧縮法により、その領域の圧縮を大幅に向上できる可能性が高いことを示唆している。

＜特徴の検出＞

図１には、少なくとも１つの映像フレーム２０−１，２０−２，…，２０−ｎで検出された、特徴のインスタンス（特徴インスタンス）１０−１，１０−２，…，１０−ｎが示されている。典型的に、このような特徴は、ペルから導き出される構造的情報に基づく複数の条件に基づいて、さらに、従来の圧縮法ではその特徴領域（特徴の領域）の符号化に過度の帯域量を利用しなければならないことを示す複雑性基準に基づいて検出され得る。さらに、特徴の各インスタンスは、図１に示すように、フレーム２０−１，２０−２，…，２０−ｎ内で空間的な広がり又は境界を有する「領域」３０−１，３０−２，…，３０−ｎとして空間的に特定され得る。特徴のこのような領域（特徴領域）３０−１，３０−２，…，３０−ｎは、例えば、ペルデータで構成される単純な直方形領域として抽出され得る。本発明の一実施形態において、前記特徴領域のサイズは、Ｈ．２６４のマクロブロックと同じ１６×１６のサイズである。

過去の文献には、ペル自体の構造に基づいて特徴を検出するアルゴリズムとして、ペルデータの各種変換に対してロバスト（頑健）であるノンパラメトリックな特徴検出アルゴリズムの種類を含む、数多くのアルゴリズムが提案されている。例えば、スケール不変特徴量変換（ＳＩＦＴ）［Lowe, David, 2004, "Distinctive image features from scale-invariant keypoints," Int. J. of Computer Vision, 60(2):91-110］は、画像にガウス関数の差分を畳み込むことで斑点状の特徴を検出する。高速化ロバスト特徴（ＳＵＲＦ）アルゴリズム［Bay, Herbert et al., 2008, "SURF: Speeded up robust features," Computer Vision and Image Understanding, 110(3):346-359］も、ヘシアン演算子の行列式を用いることで斑点状の特徴を検出する。本発明の一実施形態では、ＳＵＲＦアルゴリズムを用いて特徴を検出する。

他の特徴検出アルゴリズムとして、特定の種類の特徴（例えば、顏など）を見つけ出すように構成されたものが挙げられる。本発明の別の実施形態では、横顔や正面顔を検出する一環として、Haar-like特徴を検出する［Viola, Paul and Jones, Michael, 2001, "Rapid object detection using a boosted cascade of simple features," Proc. of the 2001 IEEE Conf. on Computer Vision and Pattern Recognition, 1 :511-518］。

別の実施形態では、本願の出願人による同時係属出願である2009年10月6日付出願の米国特許出願第13/121,904号に全容が記載されているように、従来のエンコーダでの符号化複雑性（帯域量）に基づいて、特徴が検出され得る。なお、この米国特許出願の全教示内容は、参照をもって本明細書に取り入れたものとする。一例として、符号化複雑性は、特徴が現れる領域を従来の圧縮法（例えば、Ｈ．２６４など）で符号化するのに必要な帯域量（ビット数）を分析することによって判断され得る。すなわち、検出アルゴリズムが異なればその動作も異なるが、いずれにしても実施形態では、どの検出アルゴリズムであっても、映像データ全体にわたる映像フレームシーケンス全体に対して適用される。本発明を限定しない一例として、Ｈ．２６４エンコーダによる第１の符号化パスが行われて「帯域量マップ」が生成される。この帯域量マップにより、Ｈ．２６４による符号化コストが、各フレームのどの箇所で最も高くなるのかが定義されるか、あるいは、その帯域量マップがそれを判断する。

典型的に、Ｈ．２６４などの従来のエンコーダは、映像フレームを、互いに重なり合わないように並んだ複数の一様なタイル（例えば、１６×１６マクロブロック、当該マクロブロックのサブタイルなど）に分割する。一実施形態において、各タイルは、Ｈ．２６４でそのタイルを符号化するのに必要な相対的帯域量に基づいて、特徴候補として分析され得る。一例として、Ｈ．２６４でタイルを符号化するのに必要な帯域量が、一定の閾値と比較され得る。そして、帯域量がその閾値を超える場合には、タイルが「特徴」と判断され得る。その閾値は、所定の数値であってもよい。その場合、この所定の数値は、特徴の検出時に簡単にアクセスできるようにデータベースに記憶され得る。前記閾値は、過去に符号化した特徴に割り当てられた帯域量の平均値として設定される数値であってもよい。同様に、前記閾値は、過去に符号化した特徴に割り当てられた帯域量の中央値として設定される数値であってもよい。あるいは、フレーム全体（または映像全体）にわたってタイルの帯域量の蓄積分布関数を算出し、全タイルの帯域量の上位パーセンタイル内に入る帯域量を有する全てのタイルを「特徴」と判断するようにしてもよい。

別の実施形態では、映像フレームが、互いに重なり合うタイルに分割され得る。この重なり合いのサンプリングは、１つのタイルの中心に当該タイルと重なり合う４つのタイルの角の交差点が位置するようにオフセットされ得る。このように過剰な分割により、最初のサンプリング位置で特徴を検出できる可能性が高まる。その他にも、より複雑な分割方法として、トポロジー的な分割方法が挙げられる。

特徴として検出された小規模の空間的領域を分析し、所与の整合性基準（coherency criteria（一貫性を満たす基準））に基づき当該小規模の空間的領域同士を組み合わせて大規模の空間的領域にできるか否かを判断するようにしてもよい。前記空間的領域のサイズは、ペルの小規模のグループから、実際のオブジェクトまたは実際のオブジェクトの一部に相当し得る大規模な部分まで多種多様であり得る。ただし、検出される特徴は、オブジェクトやサブオブジェクトなどの互いに区別可能な単一のエンティティーと必ずしも対応関係にある必要はない。１つの特徴に、２つ以上のオブジェクトのそれぞれのエレメント（構成要素）が含まれることもあれば、オブジェクトのエレメントが全く含まれないこともある。本発明にかかる特徴の重要な側面は、特徴モデルベースの圧縮法により、従来の圧縮法に比べて、特徴を構成するペルの集合を効率的に圧縮できるという点である。

小規模の領域同士を組み合わせて大規模の領域にする際の整合性基準には、動きの類似性、動き補償後の外観の類似性、および符号化複雑性の類似性が含まれ得る。整合性を有する動きは、高次の動きモデルにより見つけ出され得る。一実施形態では、小規模の各領域の並進動きがアフィン運動モデルに組み込まれ得る。このモデルにより、それら小規模の各領域の動きモデルを近似することができる。小規模の領域のセットについて、それらの動きを常に集約モデルに組み込むことができる場合、これは、当該小規模の領域間が依存しており整合性があることを示唆している。そのような整合性は、集約特徴モデルによって有効活用することができる。

＜特徴モデルの形成＞

重要なのは、複数の映像フレームで特徴を検出した後、同じ特徴の複数のインスタンスを相関させることである。このプロセスは「特徴相関」と称されるプロセスであり、後述するように、（特定の特徴の経時的位置を定める）特徴トラッキングの基礎となる。ただし、この特徴相関プロセスを効果的に行うには、まず、類似する特徴インスタンスを類似しない特徴インスタンスから区別するために用いられる「特徴モデル」を定義する必要がある。

一実施形態では、特徴のペル（特徴ペル）自体を用いて特徴をモデル化し得る。特徴のペルの領域は二次元であり、ベクトル化可能である。異なる特徴のペルのベクトル間の平均二乗誤差（ＭＳＥ）の最小化又は当該異なる特徴のペルのベクトル間の内積の最大化により、類似する特徴を特定することができる。この構成の問題点として、特徴ペルのベクトルが並進、回転、拡大／縮小などの特徴の小規模の変化、さらには、特徴の照度の変化に敏感な点が挙げられる。映像をとおして特徴はこのような変化を頻繁に起こすので、特徴ペルのベクトルを用いて特徴をモデル化・相関させる場合、そのような変化を考慮する必要がある。本発明の一実施形態では、従来のコーデック（例えば、Ｈ．２６４など）に見受けられる、特徴の並進動きを考慮するための標準的な動き予測・補償アルゴリズムを適用するという極めて単純な方法により、特徴の上述したような変化を考慮する。他の実施形態では、より複雑な方法を用いて、フレーム間の特徴の回転、拡大／縮小および照度変化を考慮し得る。

代替の実施形態において、特徴モデルは、特徴の小規模の回転、並進、拡大／縮小、および場合によっては照度変化に対して「不変な」、特徴のコンパクトな表現（所与の種類の変換の適用時に変化しない表現）である（ここで、「コンパクト」とは、本来の特徴ペルのベクトルの次元よりも低次元であることを意味する）。すなわち、フレーム間で特徴が小規模の変化を起こしても、この場合の特徴モデルは比較的一定のままである。このようなコンパクトな特徴モデルは、しばしば「記述子（descriptor）」と称される。一例として、本発明の一実施形態では、ＳＵＲＦの特徴記述子の長さが、Ｈａａｒウェーブレット変換応答の和に基づいて６４とされる（これに対し、特徴ペルのベクトルの長さは２５６である）。別の実施形態では、特徴ペルのカラーマップから、５個のビンのカラーヒストグラムが構築され、この５つのコンポーネントからなるヒストグラムが、特徴記述子として機能する。さらなる別の実施形態では、二次元ＤＣＴにより、特徴領域が変換される。そして、係数行列の上三角部分および下三角部分にわたって、二次元ＤＣＴ係数が合計される。この合計が、エッジ特徴空間を構成し、前記特徴記述子として機能し得る。

特徴記述子を用いて特徴をモデル化した場合、（特徴のペル間のベクトルの代わりに、）特徴記述子間のＭＳＥの最小化又は当該特徴記述子間の内積の最大化により、類似する特徴が特定され得る。

＜特徴相関（特徴関連付け）および特徴トラッキング＞

特徴を検出・モデル化した後の次の過程は、類似する特徴を、複数のフレームにわたって相関させる（関連付ける）ことである。それぞれのフレーム内に現れる各特徴インスタンスは、当該特徴の外観のサンプルである。複数の特徴インスタンスは、複数のフレームにわたって相関されることで、同じ特徴に「属する」と見なされる。同じ特徴に属するように相関された複数の特徴インスタンスは、特徴トラックを形成するように集約してもよいし、あるいは、集合体行列４０（図１）に集めるようにしてもよい。

「特徴トラック」は、映像フレームに対する特徴の位置（ｘ，ｙ）として定義される。一実施形態では、特徴の新たに検出されたインスタンスを、追跡した特徴と関連付ける（映像の最初のフレームの場合には、検出した特徴又は過去に検出された特徴と関連付ける）。これを基礎として、現在のフレームにおける特徴インスタンスが、これまでに構築された特徴トラックのうちのどのトラックの延長上に属するのかを決定する。現在のフレームにおける特徴インスタンスを、これまでに構築した特徴トラック（映像の最初のフレームの場合には、検出した特徴又は過去に検出された特徴と関連付けることで、特徴の追跡が行われる。

図２に、特徴追跡手段（特徴トラッカー）７０を用いて特徴６０−１，６０−２，…，６０−ｎを追跡する様子を示す。特徴検出手段８０（例えば、ＳＩＦＴ、ＳＵＲＦなど）を用いて、現在のフレームにおける特徴を特定する。現在のフレーム９０において検出された特徴インスタンスが、検出された（又は追跡された）特徴５０と照らし合わされる。一実施形態では、前述した相関過程よりも前に、HarrisとStephensのコーナー検出アルゴリズム［Harris, Chris and Mike Stephens, 1988, "A combined corner and edge detector," in Proc. of the 4th Alvey Vision Conference, pp. 147-151］に見受けられるように、ガウシアンフィルタの微分で特徴の自己相関行列の画像勾配を算出することで、当該特徴の自己相関行列に基づく特徴強度を表す自己相関分析（ＡＣＡ）量を用いることにより、現在のフレームにおける特徴検出候補のセットのなかで順位を決めるようにしてもよい。大きいＡＣＡ量を有する特徴インスタンスが、トラック延長の候補として優先される。一実施形態では、ＡＣＡ順位リストのなかで低い順位にある特徴インスタンスが、そのリストのなかで高い順番にある特徴インスタンスの所与の距離（例えば、１ペルなど）内に位置する場合には、特徴候補のセットから取り除かれる。

種々の実施形態では、特徴記述子（例えば、ＳＵＲＦ記述子など）または特徴ペルのベクトルが、トラック延長（追跡の続き）を判断する際の特徴モデルとして機能し得る。一実施形態では、追跡したトラック（図２の領域６０−１，６０−２，…，６０−ｎ）が、１つずつ、現在のフレーム９０で新たに検出された特徴の中から、トラック延長について調べられる。一実施形態では、各特徴トラックの一番最近の特徴インスタンスが、現在のフレームにおけるトラック延長の探索の焦点（すなわち、「ターゲットの特徴」）とされる。現在のフレームにおいて、そのターゲットの特徴の位置の所与の距離（例えば、１６ペルなど）内にある全ての特徴検出候補が調べられ、そのターゲットの特徴に対する（ペル空間または既述子空間の）ＭＳＥが最小となる候補が特徴トラックの延長に選択される。別の実施形態では、ターゲットの特徴に対するＭＳＥが所与の閾値を超える特徴候補については、トラック延長の資格がないとして除外する。

さらなる実施形態では、現在のフレームにおいて、所与の特徴トラックの延長となる資格を有する特徴検出候補がない場合、その現在のフレームにおいて、Ｈ．２６４内の動き補償予測（ＭＣＰ）または汎用的な動き予測・補償（ＭＥＣ）を用いて、マッチング領域を見つけ出すための限定的な探索を実行する。ＭＣＰおよびＭＥＣは、いずれも勾配降下探索を実行して、過去のフレームにおけるターゲットの特徴に対するＭＳＥが最小となる（ＭＳＥ閾値を満足する）、現在のフレーム内のマッチング領域を探索する。現在のフレームにおいて、前記ターゲットの特徴に対するマッチが前記特徴検出候補からも前記ＭＣＰ／ＭＥＣ探索プロセスからも見つけられなかった場合には、その対応する特徴トラックを「無効」または「終了」と判断する。

さらなる実施形態では、２つ以上の特徴トラックについて、現在のフレームにおけるそれぞれの特徴インスタンスが、所与の閾値（例えば、７０％の重複）を超えて合致している場合には、それらの特徴トラックのうちの１つ以外を、今後の検討対象から全て削除又は除外する。この削除プロセスにより、最も長い履歴を有し、かつ、全ての特徴インスタンスを総計した合計ＡＣＡ量が最も大きい特徴トラックを維持することができる。

別の実施形態では、特徴トラックに対し、中点（mid-point（ミッドポイント））正規化を実行し得る。具体的には、トラック位置の「平滑化」セットを算出し、正規化後の中点から「離れた」特徴位置を調節する。このプロセスを「中心調節（center adjustment）」と称する。

以上をまとめると、特徴検出（ＳＵＲＦや顏）、特徴モデリング（ＳＵＲＦ記述子、スペクトルヒストグラム）、ＡＣＡベースの特徴候補の順位決め、さらに、トラック延長のためのＭＣＰ／ＭＥＣ探索法およびトラックの中心調節で補助しながら行う、特徴候補のＭＳＥの最小化による特徴相関及び特徴トラッキングが、本発明の数多くの実施形態において共通の過程として実行される。ＳＵＲＦ記述子を用いて追跡を行う場合、その処理ストリームはＳＵＲＦ追跡手段（トラッカー）と称される。カラーヒストグラムを用いて追跡を行う場合、その処理ストリームはスペクトル追跡手段（トラッカー）と称される。

図３は、上述した特徴ベース処理ストリーム（ＦＰＳ）の基本的過程を示すフロー３００である。特定の映像が与えられたＦＰＳは、まず、映像内の特徴を検出する（過程３１０）。次に、ＦＰＳは、検出した特徴のインスタンス同士を、特徴のペルではなくコンパクトな特徴モデルを用いて、相関させる（互いに関連付ける）（過程３２０）。次に、ＦＰＳは、検出して相関させた特徴を追跡する（過程３１２）。また、ＦＰＳは、特徴の相関されたインスタンス間の類似性を判断し（過程３２２）、特徴の相関された類似するインスタンスに対して中点正規化を実行する（過程３２４）。ＦＰＳは、正規化された中点に基づいて、相関された特徴の中心を調節し（過程３２６）、これを追跡手段（トラッカー）３１２にフィードバックする。ＦＰＳは、特徴トラック３１２、相関された特徴インスタンス３２０、および中心調節後の相関された特徴インスタンス３２６のうちの少なくとも１つに基づいて、相関された特徴インスタンスの特徴集合を構築する（過程３１４）。他の実施形態において、ＦＰＳは、様々な条件に基づいて前記特徴集合を分割または合体し得る（過程３１６）。ＦＰＳは、さらに、モデルの状態を設定し得る（例えば、「分離」に設定する）（過程３１８）。一実施形態では、最終決定したのでこれ以上編集する必要がないモデルを分離する。他の実施形態において、前記レポジトリ（保管装置）は、モデルの生成時に映像の複雑性も分析し得る（過程３２８）。当業者であれば、これらの過程が必ずしも上記の順番で実行されなくてもよく、任意の順番で実行されてよいことを理解するであろう。

＜特有特徴および特徴クラスタリング＞
上記のセクションでは、映像（本明細書では、分かり易いように「入力」映像と称する場合がある）の複数のフレームにわたって特徴を検出、モデル化、相関及び追跡する方法について説明した。本発明では、所与の入力映像内に含まれる、別の「ターゲットの」映像（符号化する映像）の圧縮を向上させるのに有用な全ての特徴情報を保管する（すなわち、「持続させる」）。一実施形態において、前記特徴情報はファイルに記憶される。他の実施形態において、前記特徴情報は、リレーショナルデータベース、オブジェクトデータベース、ＮｏＳＱＬデータベースまたはその他のデータ構造に記憶され得る。特徴情報を記憶する構成に関しては、後で詳述する。ただし、別の映像の圧縮を向上させるのに有用かつ効果的な、入力映像からの特徴情報とは、その入力映像の特徴内容を包括的に且つ簡潔に捉えたものでなければならない。

入力映像からの特徴情報は、特徴の検出過程、モデル化過程、相関過程及び追跡過程を経ることにより、特徴トラックのセット内に収められる。この情報を適宜にコンパクトで且つ象徴的な形態に縮小するために、まず最初の過程として、特徴トラックごとに、その特徴トラックの代表的な特徴（すなわち、特有特徴）を選択する。一実施形態において、所与の特徴トラックの特有特徴は、そのトラックに含まれる一番最初の（最も古い）特徴インスタンスである。他の実施形態において、所与の特徴トラックの特有特徴は、そのトラックに含まれる全ての特徴インスタンスの算術平均である。各特徴トラックに対して特有特徴を選択するプロセスにより、入力映像からの特徴情報を、特徴トラックのセットから特有特徴のセットに縮小することができる。

入力映像からの特徴情報を適宜にコンパクトで且つ象徴的な形態に縮小するための次の過程は、類似する特有特徴同士をクラスタ化することである。特有特徴同士の集団化（すなわち、クラスタ化）は、当該技術分野において周知の技術を用いることによって達成することができる。前記追跡手段をスペクトル追跡手段とする実施形態では、前記特有特徴のスペクトルカラーマップに基づいてクラスタ化が行われる。ＹＵＶ色空間データからの「Ｕ」および「Ｖ」（クロマ）コンポーネントを、２つのコンポーネントからなるベクトルとして取り扱い得る。Ｕ／Ｖコンポーネントの異なる値は、スペクトルカラーマップの異なる色に相当する。そのカラーマップから、ヒストグラムが生成される。このヒストグラムは、Ｕ／Ｖコンポーネント値の全範囲をまとめた任意の個数ｋのビンを含むものであってもよい。一実施形態において、ｋ＝５である。前記追跡手段をＳＵＲＦ追跡手段とする実施形態では、前記特有特徴の長さ６４のＳＵＲＦ特徴記述子ベクトルに基づいてクラスタ化が行われる。クラスタ化に用いる特徴モデルドメイン（例えば、上記の実施形態のカラーヒストグラム、ＳＵＲＦ記述子など）の決定後、任意の標準的なクラスタ化アルゴリズムを適用して前記クラスタ化を実行し得る。好ましい一実施形態では、ｋ平均クラスタ化アルゴリズムを用いてクラスタ化が行われる。ｋ平均アルゴリズムでは、入力映像内の全ての特有特徴を、ｍ個のクラスタにそれぞれ割り当てる。一実施形態において、ｍ＝５である。そして、前記ｋ平均アルゴリズムは、クラスタごとに、そのクラスタのメンバ（クラスタメンバ）の算術平均を表した、クラスタの重心（クラスタ重心）を算出する。

図４Ａは、スペクトル追跡手段を用いた具体例における特徴ベース表示ツールのスクリーンショットである。図４Ｂは、ＳＵＲＦ追跡手段を用いた具体例における特徴ベース表示ツールのスクリーンショットである。各図の左上側には、スペクトルカラーマップに基づいた特有特徴のクラスタ化の結果（図４Ａの符号４１６）又はＳＵＲＦ記述子に基づいた特有特徴のクラスタ化の結果（図４Ｂの符号４２０）が表示されている。各特有特徴は、少なくとも１つの特徴メンバ（符号４１４によれば２４個）の代表である。各クラスタ（符号４１６によれば１０個、符号４２０によれば１２個）は、そのクラスタ重心のペルおよび対応する特徴モデル（符号４１６によればスペクトルカラーマップ、符号４２０によればＳＵＲＦ記述子）によって表現される。各クラスタは、一定数の特有特徴メンバを含む。図４Ａのカラースペクトルクラスタ４１８の例では、８個の特有特徴メンバ４１８が表示されている。図４ＢのＳＵＲＦクラスタ４２０の例では、２０を超える数の特有特徴メンバ４２２が表示されている。

前記ｍ個のクラスタにおいて、クラスタメンバの数が多すぎる場合には、一段下位のサブクラスタ化を実行してもよい。例示的な一実施形態として、ｍ個のカラースペクトルクラスタが、それぞれｌ個のサブクラスタに分割される（ｍは５、ｌは２〜４）。

ｍ個のクラスタの初期セットの形成後、入力映像からの特徴情報を適宜にコンパクトで且つ象徴的な形態に縮小するための最後の過程は、クラスタごとに、そのクラスタを代表するｎ個のクラスタメンバで構成された部分セットを選択することである。この過程が必要な理由としては、１つのクラスタに含まれるクラスタメンバの数は膨大になり得るが、圧縮時に効果的に利用するには、代表的なクラスタ要素の数ｎを比較的小さくしなければならないからである。例示的な一実施形態として、ｎ＝５である。通常、代表的なクラスタ要素は、クラスタ重心に基づいて選択される。一実施形態では、直交マッチング追跡（ＯＭＰ）アルゴリズムを用いて、対応するクラスタ重心を最も冗長なく最良に近似することができるｎ個のクラスタメンバを選択する。別の実施形態では、対応するクラスタ重心との内積が最大になるｎ個のクラスタメンバを選択する。ただし、この方法で選択されたクラスタメンバは、ＯＭＰを用いて選択されたクラスタメンバよりも冗長性が高くなる。

クラスタごとに当該クラスタを最も代表するクラスタメンバを選択することにより、入力映像からの特徴情報を保存する用意が整う。保存される特徴情報は、それぞれｎ個のクラスタメンバからなるｍ個のクラスタで構成され、各クラスタメンバは特定の特徴トラックにおける特有特徴であり、各特有特徴は当該特有特徴に関連付けられる特徴領域（本発明の一実施形態では１６×１６）に対応したペルセットを有する。各クラスタ重心のペルおよび対応する特徴モデル（例えば、カラーヒストグラム、ＳＵＲＦ記述子など）も保存される。前記保存される特徴情報には、さらに、各クラスタメンバの特徴領域を取り囲む周辺領域のペルも含まれる。これは、本発明における、その保存された情報を符号化に利用する際の利用方法（「オフセット処理」；後で詳述する）が理由である。一実施形態において、「周辺」領域は、各方向における１６×１６マクロブロック１つ分を合計した領域である。したがって、特徴領域とその周辺領域とによって４８×４８「スーパー」領域が形成される。つまり、前記保存される特徴情報は、それぞれｎ個のスーパー領域からなるｍ個のクラスタのペルと、ｍ個のクラスタ重心のペルおよび特徴モデルとによって構成される。

上記の特徴ベース処理ストリーム（特徴の検出、モデル化、相関及び追跡、特有特徴の選択、クラスタ化、クラスタメンバの選択、さらに、特徴情報の保存）は、１つの入力映像から複数の入力映像に拡張させることができる。複数の入力映像がある場合には、全ての入力映像からの特徴トラックを利用し、各特徴トラックを代表する特有特徴を用いることにより、前述したようなクラスタを生成することができる。

＜オフライン特徴ベース圧縮のための、特徴モデルの再利用＞

＜モデルベース圧縮フレームワーク＞

所与の入力映像（又は複数の入力映像）に対する前記特徴ベース処理ストリーム（図３の符号３００）の適用後、保存された特徴情報は、「ターゲットの」映像（符号化する映像であって、前記入力映像と異なる場合が多い）の圧縮時に、その圧縮を向上させるために再利用することができる。さらに、このような特徴情報の再利用による圧縮は、本願の出願人による同時係属出願である940’出願に記載されたモデルベース圧縮フレームワーク（ＭＢＣＦ）内で実行される。関連する構成要素（包括的に付号９２４で示す）については、後で説明する。

ＭＢＣＦの開始時の過程は、前述した特徴ベース処理ストリームと同様である。具体的には、ターゲットの映像について特徴を検出、モデル化及び相関させる。好ましい一実施形態において、特徴は、ＳＵＲＦ検出アルゴリズムを用いて検出され、ＳＵＲＦ記述子を用いてモデル化及び相関される。

次に、ＭＢＣＦは、図５に示すように特徴トラックを用いて、特徴をマクロブロックと関連付ける。所与の特徴トラックは、複数のフレームにわたって特徴の位置を示す。そして、その特徴には、フレームにわたって動きがある。現在のフレームからみて一番最近の２つのフレームにおけるその特徴の位置を用いることにより、当該現在のフレームにおけるその特徴の位置を推測することができる。そして、その特徴の推測位置には、対応する最も近傍のマクロブロックが存在する。そのようなマクロブロックは、前記特徴の推測位置と最も大きく重複するマクロブロックとして定義される。このため、このマクロブロック（符号化されている最中のターゲットマクロブロック）は、特定の特徴トラックに対して関連付けられたことになる。この特定の特徴トラックの現在のフレームにおける推測位置は、前記マクロブロックの近傍である（図５の過程５００）。ＭＢＣＦの一実施形態において、１つのマクロブロックに複数の特徴を関連付けることが可能な場合には、そのマクロブロックと最も大きく重複する特徴を、そのマクロブロックと関連付ける特徴として選択する。

次に、ＭＢＣＦは、現在のフレームにおける、ターゲットのマクロブロック（ターゲットマクロブロック）と特徴の推測位置とのオフセットを算出する（過程５１０）。オンラインモード（復号化したペルを用いた予測を、同じ映像内で生成するモード）で動作している場合のＭＢＣＦは、このオフセット、さらには、前記関連付けられた特徴トラックにおける過去の特徴インスタンスを用いることにより、前記ターゲットのマクロブロックに対する予測を生成する。参照フレーム内において、当該参照フレームにおけるインスタンスとのオフセットが、現在のフレームにおけるターゲットのマクロブロックと特徴の推測位置とのオフセットと同じである領域を見つけ出すことにより（過程５２０，５３０）、前記ターゲットのマクロブロックに対するオンライン予測を生成することができる。

ＭＢＣＦは、ターゲットのマクロブロック（符号化されている最中の現在のマクロブロック）、これに関連付けられた特徴、およびその特徴の特徴トラックが与えられることで、当該ターゲットのマクロブロックに対する一次的予測（またはキー予測）を生成することができる。キー予測のデータ（ペル）は、その特徴が現れる（最新のフレームからみて）一番最近のフレームから取得する。以降では、この一番最近のフレームを、キーフレームと称する。キー予測は、動きモデルおよびペルのサンプリングスキームを選択したうえで生成される。ＭＢＣＦの一実施形態において、前記動きモデルは、特徴がキーフレームと現在のフレームとの間で静止していると仮定する「零次」か、あるいは、特徴の動きが２番目に一番最近の参照フレームとキーフレームと現在のフレームとの間で線形であると仮定する「一次」とされ得る。いずれの場合も、特徴の動きを、当該特徴と関連付けられた、現在のフレームにおけるマクロブロックに（時間的に逆方向に）適用することにより、キーフレームにおけるそのマクロブロックに対する予測が得られる。ＭＢＣＦの一実施形態において、前記ペルのサンプリングスキームは、動きベクトルを整数に四捨五入して（整数に丸めて）キー予測のペルをキーフレームから直接取り出す「直接」か、あるいは、Ｈ．２６４などの従来の圧縮法の内挿スキームを用いて動き補償されたキー予測を導き出す「間接」とされ得る。つまり、本発明にかかるＭＢＣＦでは、前記動きモデル（零次または一次）に応じて、さらに、前記サンプリングスキーム（直接または間接）に応じて、４種類の相異なるキー予測を得ることができる。

ＭＢＣＦは、サブタイル化プロセスを用いて局所的な変形成分をモデル化することにより、キー予測を改良することもできる。サブタイル化プロセスでは、マクロブロックの相異なる局所部位について、それぞれの動きベクトルを算出する。ＭＢＣＦの一実施形態において、前記サブタイル化プロセスは、１６×１６のマクロブロックを８×８の４つの１／４部位（quadrant）に分割し、それぞれに対する予測を別個に算出することで実行され得る。別の実施形態では、前記サブタイル化プロセスが、Ｙ／Ｕ／Ｖ色空間ドメインにおいて、Ｙ色チャネル、Ｕ色チャネルおよびＶ色チャネルの予測を別個に算出することで実行され得る。

ＭＢＣＦは、ターゲットのマクロブロックに対する一次的予測／キー予測に加えて、そのターゲットのマクロブロックに関連付けられた特徴の、当該キーフレームよりも過去の参照フレームにおける位置に基づいて、副次的予測を生成してもよい。一実施形態では、現在のフレームにおける、ターゲットのマクロブロックから当該ターゲットのマクロブロックに関連付けられた特徴の位置（推測位置）までのオフセットを、過去の参照フレームにおける当該特徴の位置に基づいて副次的予測を見つけ出すための動きベクトルとして使用し得る。このようにして、特徴が関連付けられた所与のターゲットのマクロブロックに対する副次的予測を、（その特徴が現れたフレームごとに１つずつ）複数生成することができる。一実施形態では、探索対象とする過去の参照フレームの数を制限する（例えば、２５個とする）ことにより、副次的予測の数を制限するようにしてもよい。

ターゲットのマクロブロックに対する一次的予測（キー予測）および副次的予測の生成後に、これらの予測に基づいて、そのターゲットのマクロブロックの全体的な再構成を算出することができる。ＭＢＣＦの一実施形態において、前記再構成は、従来のコーデックにならって、キー予測のみに基づいた再構成とされる。以降では、このような再構成を、キー単独（ＫＯ）再構成と称する。

ＭＢＣＦの別の実施形態において、前記再構成は、前記キー予測と前記副次的予測のうちの１つを重み付けしたものとを合計した複合予測に基づいた再構成とされる。以降では、このようなアルゴリズムを、ＰＣＡ−Ｌｉｔｅ（ＰＣＡ−Ｌ）と称する。ＰＣＡ−Ｌｉｔｅは、以下の手順を含む：

１． ターゲットのマクロブロックの（一次元）ベクトル（ターゲットベクトルｔと称する）およびキー予測の（一次元）ベクトル（キーベクトルｋと称する）を生成する；

２． ターゲットベクトルからキーベクトルを減算することにより、残差ベクトルｒを算出する；

３． 副次的予測の集合をベクトル化してベクトルｓ_ｉを形成する（一般性を失うことなく、これらの副次的ベクトルは、単位ノルムを有するものと仮定する）。次に、全ての副次的ベクトルからキーベクトルを減算することにより、キー減算集合ｓ_ｉ−ｋを生成する。これは、副次的ベクトルからキーベクトルの射影を減算するようなものである；

４． それぞれの副次的ベクトルについて、重み付け係数ｃ＝ｒ^Ｔ（ｓ_ｉ−ｋ）を算出する；および

５． それぞれの副次的ベクトルについて、複合予測ｔ^＾＝ｋ＋ｃ×（ｓ_ｉ−ｋ）を算出する。

概すれば、ＰＣＡ−Ｌｉｔｅアルゴリズムの上記手順は、周知の直交マッチング追跡アルゴリズム［Pati, Y.C. et al., 1993, "Orthogonal matching pursuit: Recursive function approximation with applications to wavelet decomposition," in Proc. of the 27th Asilomar Conference, pp. 40-44］の手順に似ているが、上記の複合予測は、一次的予測および副次的予測からの冗長な寄与を含まないように意図されている。別の実施形態では、前記ＰＣＡ−Ｌｉｔｅアルゴリズムにおいて、上述した手順３〜５のキーベクトルをキーベクトルと副次的ベクトルとの平均に置き換える。以降では、このような変更入りアルゴリズムを、ＰＣＡ−Ｌｉｔｅ−Ｍｅａｎと称する。

上記のＰＣＡ−Ｌｉｔｅアルゴリズムは、一部の標準的なコーデックで見受けられる双予測アルゴリズムと異なるタイプの複合予測を提供することができる。標準的な双予測アルゴリズムは、各予測に用いる参照フレームと現在のフレームとの時間的距離に基づいて、複数の予測をブレンディング（混合）する。対照的に、ＰＣＡ−Ｌｉｔｅは、各予測の「内容」に基づいて複数の予測を混合し、複合予測を生成する。

なお、上記の複合予測は、特徴ベースのモデリングでなくても可能である。すなわち、どのような予測の集合（セット）を用いても、所与のターゲットのマクロブロックについての複合予測を生成することは可能である。しかし、特徴ベースのモデリングでは、所与のターゲットのマクロブロックについての予測の集合が、自然と互いに関連性を有するものになる。そして、複合予測とすることにより、それらの複数の予測からの情報を効率良く組み合わせることができる。

＜モデルベース圧縮フレームワーク内でのオフラインストリームのための、モデルの再利用＞

前記モデルベース圧縮フレームワーク（ＭＢＣＦ）は、前述した特徴ベース処理ストリームによって生成及び記憶される特徴情報を用いることにより、オフラインモードで動作することもできる。

一実施形態において、オフラインモードのＭＢＣＦは、ＳＵＲＦ検出アルゴリズムを用いてターゲットの映像内の特徴を検出し、当該検出された特徴をＳＵＲＦ記述子を用いてモデル化し、（特徴がキーフレームと現在のフレームとの間で静止していると仮定して）「零次」の動きモデルおよび「直接」の内挿スキームに基づいてキー予測を生成する。

次に、オフラインモードのＭＢＣＦは、前記特徴ベース処理ストリームによって記憶された、少なくとも１つの入力映像からの適切な特徴情報を読み出す（既述したように、保存された特徴情報は、それぞれｎ個のスーパー領域からなるｍ個のクラスタのペルと、ｍ個のクラスタ重心のペルおよび特徴モデルとによって構成される）。一実施形態において、ＭＢＣＦは、ターゲットのマクロブロック（符号化されている最中の現在のマクロブロック）と関連付けられた特徴について、当該特徴のＳＵＲＦ記述子に最も近い（平均二乗誤差が最小になる）ＳＵＲＦ記述子を有するクラスタから、そのクラスタ要素を読み出す。

オフラインモードのＭＢＣＦは、特定のクラスタを読み出した後、そのクラスタ内の各スーパー領域について、そのスーパー領域のペルのうち、当該スーパー領域の中心からのオフセットが、ターゲットの映像内でのターゲットのマクロブロックと当該マクロブロックに関連付けられた特徴とのオフセットと同じであるペルを抽出することにより、副次的予測を生成する。これにより、クラスタメンバにつき１つずつ、ｎ個の副次的予測を生成することができる。

一実施形態では、オフラインモードのＭＢＣＦによって生成された副次的予測が、前述したＰＣＡ−ＬｉｔｅアルゴリズムまたはＰＣＡ−Ｌｉｔｅ−Ｍｅａｎアルゴリズムを用いてキー予測と組み合わされる。

別の実施形態において、副次的予測によって誤差が減少するか又は符号化コストが低下する場合には、そのような副次的予測を一次的予測として取り扱い、場合によっては、同じ映像内のキー予測と置き換えるようにしてもよい。そのような実施形態では、一次的予測がオフラインのソース（ターゲットの映像以外）に由来することになるが、そのような場合には、（例えばアフィン動きモデルを前提とした）正規化をオフライン予測に適用することにより、ターゲットのマクロブロックに対するマッチングの度合いが、より確実に優れるようにしてもよい。

以上をまとめると、オフラインモードのＭＢＣＦは、圧縮のための特徴モデルの再利用を、次の手順により行う：（１）ターゲットの映像のフレームごとに特徴を検出する；（２）検出された特徴をモデル化する；（３）相異なるフレーム内の特徴を相関させて、特徴トラックを生成する；（４）特徴トラックを用いて、符号化されている最中の「現在の」フレームにおける特徴の位置を予測する；（５）現在のフレームにおけるその特徴の予測位置の近傍に存在するマクロブロックに関連付ける；（６）前記（５）におけるマクロブロックについて、それと関連付けられた特徴の、一番最近に符号化されたキーフレームにおける位置に基づいて、当該マクロブロックのキー予測を生成する；（７）入力映像から生成された特徴情報の読出しを、ターゲットの映像内の特徴の記述子に最も近い重心記述子を有するクラスタを決定することにより行う；および（８）前記（７）で読み出した特徴情報から副次的予測を生成する。

＜特徴モデルライブラリの形成＞

＜単純モデルライブラリ；特徴情報のみの直接保存＞

既述したように、入力映像から、特徴情報の基本セットを生成することができるので、これを保管するようにしてもよい。そして、符号化する別の「ターゲットの」映像の圧縮を向上させる目的で、この特徴情報を、モデルベース圧縮フレームワーク（ＭＢＣＦ）内で再利用することができる。特徴情報をファイル、データベースまたはデータストアに直接保存したものは、少なくとも１つの入力映像からの特徴情報を整理及びカタログ化する特徴モデルライブラリの、最も単純な形態を成す。

一実施形態では、特徴検出過程および特徴追跡過程からの情報が、ファイル、データベースまたはデータストアに保存される。この情報には、特徴が検出された入力映像の名前、それぞれ対応する特徴ＩＤが付けられた複数の特徴トラックからなるリスト、各特徴トラックの「長さ」（当該トラックに含まれる特徴インスタンスの数に等しい）、当該トラックに含まれる全ての特徴インスタンスを従来の圧縮法（例えば、Ｈ．２６４など）で符号化するのに必要な総ビット数として定義される合計帯域量、所与のトラックにおける各特徴インスタンスの検出に用いた検出法の種類（例えば、ＳＵＲＦ、顏など）、所与のトラックにおける各特徴インスタンスを検出したフレーム、所与のトラックにおける各特徴（特徴インスタンス）の中心のｘ／ｙ座標、所与のトラックにおける各特徴（特徴インスタンス）の帯域量、および各特徴トラックの特有特徴（代表的な特徴）のペルが含まれ得るが、必ずしもこれらに限定されない。

注目すべきは、入力映像の特徴検出過程および特徴追跡過程からの情報を、ターゲットの映像をモデルベース圧縮フレームワーク内で圧縮するにあたって、その特徴検出・追跡過程からそのまま利用しないという点である。ただし、特徴モデルライブラリに複数の入力映像からの特徴情報を蓄積しなければならない場合、複数の映像からのトラックを組み合わせた際に、圧縮に利用する特徴クラスタの組成が変化することから、上記の特徴検出・追跡情報を保存する必要がある。

一実施形態において、特徴クラスタリング（特徴のクラスタ化）過程からの情報は、前記特徴検出・追跡情報とは別に、ファイル、データベースまたはデータストアに保存される。このような特徴クラスタリング情報には、それぞれ対応するインデックスが付けられた複数のクラスタからなるリスト、各クラスタのメンバ（クラスタメンバ）の数、各クラスタのクラスタ重心のペル及び特徴モデル、各クラスタメンバ（それ自体が特徴トラックを代表する特有特徴）を取り囲む「スーパー領域」のペル、各クラスタメンバの特徴モデル、およびクラスタ化を実行した際の各種パラメータ（例えば、ｋ平均クラスタ化の許容範囲、繰返しなど）が含まれ得るが、必ずしもこれらに限定されない。

特徴モデルライブラリで複数の入力映像からの特徴情報を蓄積しなければならない場合のアプローチとして、幾つかのアプローチが考えられる。一実施形態において、全ての入力映像からの特徴トラックを単純に集約し、この特徴トラックの集約セットに対して再びクラスタ化を実行する。しかし、このアプローチでは、特徴トラックの総数が増加するにつれて、特徴クラスタのサイズが大きくなる（これにより、クラスタの有益性）が減少する）ので問題になるか、あるいは、特徴クラスタの数が多くなる（これにより、クラスタにインデックスを付ける符号化コストが増加する）こと自体が問題になる。

特徴モデルライブラリに複数の入力映像を含ませる別の実施形態では、クラスタ化に先立って、特徴トラック間で優先順位を決め得る。つまり、最も「重要な」特徴トラックだけがクラスタ化用に保持されるように、そのクラスタ化に先立って、特徴トラックの前記集約セットの中から不要なものを取り除く。一実施形態において、特徴トラックは、そのトラックに含まれる全ての特徴インスタンスを従来の圧縮法（例えば、Ｈ．２６４など）で符号化するのに必要な総ビット数として定義されるトラック帯域量に応じて優先順位が決められる。従来の圧縮法では符号化が困難である特徴が、高優先として特定される。他の実施形態において、特徴トラックは、１つのトラック内での所与の特徴の反復性（変化の無さ）として漠然と定義される冗長性に応じて優先順位が決められる。特徴トラックの冗長性は、そのトラック内の相異なる特徴インスタンスで構成される集合体行列に伴う各種統計値（ランク、条件数）を算出することによって測定され得る。所与の入力映像内で高い冗長性を有する特徴は、その入力映像内で繰返し現れることが多いので、圧縮に重要なものとして特定される。別の実施形態において、特徴トラックは、特定の種類の重要な特徴（例えば、顏など）に対する類似度に応じて優先順位が決められる。特定の特徴種類に属する特徴が、重要なものとして特定される。さらなる実施形態において、前記特定の特徴種類は、意味のあるコンテンツ（例えば、特定のスポーツチーム、特定のＴＶ番組など）に従って特化したものであってもよい。

図６Ａに、図３に示す特徴ベース処理ストリーム（ＦＰＳ）の後、前述した特徴モデルライブラリに特徴情報を記憶してアクセスする際の一般過程をまとめる。ＦＰＳは、特徴を検出、モデル化、相関及び追跡した後、特徴トラックの特有特徴を生成し記憶する（過程６１０）。ＦＰＳは、さらに、特有特徴の空間記述子（ＳＵＲＦ記述子）を生成して記憶し（過程６１２）、特有特徴のスペクトル記述子（カラーヒストグラム）を生成して記憶する（過程６２０）。ＦＰＳは、前記空間記述子及び前記スペクトル記述子をクラスタ化し（過程６１４）、当該クラスタの重心（クラスタ重心）を算出する。ＦＰＳは、前記クラスタから、特徴のインデックス（特徴インデックス）を生成する（過程６１６）。この特徴インデックスの要素は、前記クラスタ重心の記述子とされる。次に、レポジトリが、クラスタ内の特徴にアクセスするための識別子を、前記特徴インデックスに基づいて生成する（過程６１８）。図６Ｂでは、前述したモデルベース圧縮フレームワーク（ＭＢＣＦ）を用いて新たなターゲットの映像を符号化する際に、ＦＰＳは、そのターゲットの映像内で検出された特徴に反応して、インデックスにアクセスし（過程６３２）、当該インデックスに関連付けられた、クラスタメンバで構成された対応する結果セットを取り出す（過程６３４）。そのクラスタメンバは、既述したようにＭＢＣＦ内で、前記ターゲットの映像における対応する特徴領域の圧縮に利用することができる。当業者であれば、これらの過程が必ずしも上記の順番で実行されなくてもよく、任意の順番で実行されてよいことを理解するであろう。

＜高度モデルライブラリ：映像レポジトリのハッシュベースのインデックス付け＞

上記のように特徴情報をファイル、データベースまたはデータストアに明示的に直接保存して最も単純な形態の特徴モデルライブラリを形成する代わりに、映像レポジトリ内のデータにアクセスするためのハッシュベースのインデックスを付けることにより、より高度な特徴モデルライブラリを形成してもよい。この場合の映像レポジトリは、特徴ベース処理ストリーム（ＦＰＳ）によって生成された特徴モデル９８０（図９Ａ、図９Ｂ）に加えて、当該ＦＰＳによる処理（符号３００）を受けた少なくとも１つの入力映像のデータペルも含む。これは、特徴ペルおよび対応するモデルしか含まず、少なくとも１つの入力映像全体のペルを含まない前述した単純な特徴モデルライブラリと対照的である。ハッシュベースのインデックスを付ける構成により、映像レポジトリ内の特徴情報に効率良くアクセスすることができる。特徴ベース処理は、フレーム（７０４Ａ〜７０４Ｆ）×行（７０８Ａ〜７０８Ｆ）×列（７０６Ａ〜７０６Ｆ）の次元を有する映像データキューブ７０２（図７）を対象とした、スパースな（疎な）サンプリングと見なすことができる。通常、特徴インスタンスは、所与の映像データキューブ内のごく僅かな位置にしか存在しない。

図８Ａは、ハッシュベースのインデックスを生成する過程の例示的な一実施形態を示すフロー図である。図８Ａにおいて、特徴ベース処理ストリーム（ＦＰＳ）は、まず、入力映像のフレーム８０２内の特徴を検出する（過程８０２）。次に、ＦＰＳは、検出された特徴のそれぞれにハッシュタグを付ける（過程８０４）。このハッシュタグは、一方向性ハッシュ関数を用いて、検出された特徴を特定する情報（当該特徴のｘ／ｙ位置、フレーム、広がりおよび対応するモデル９８０）をハッシュ値に変換し、後で映像レポジトリから当該特徴に容易にアクセスできるようにする。次に、ＦＰＳは、ハッシュ値が付けられた各特徴およびそれに対応するハッシュ値をインデックスに追加する（過程８０６）。このインデックスは、前記映像レポジトリ内に、符号化された映像と共に記憶される。次に、ＦＰＳは、その入力映像の全てのフレームが分析されたか否かを判断する（過程８０８）。全てのフレームの分析が完了している場合、ＦＰＳは、インデックスの生成を停止する（過程８１０）。全てのフレームの分析が完了していない場合、ＦＰＳは、次のフレーム内の特徴の検出に移行する（過程８０２）。

図８Ｂは、ハッシュベースのインデックスを用いて特徴にアクセスする過程の例示的な一実施形態を示すフロー図である。ＦＰＳは、入力映像のフレームを分析して特徴を検出する（過程８１２）。次に、ＦＰＳは、検出された特徴にハッシュ関数を適用して（過程８１４）、その特徴のハッシュ値を生成する。次に、ＦＰＳは、その検出された特徴のハッシュ値を用いて前記インデックスを検索し、前記映像レポジトリ内でそれに対応する特徴（および対応する特徴モデル９８０）を見つけて抽出する（過程８１６，８１８）。別の実施形態において、ＦＰＳは、１つの特徴に対して、前記映像データキューブから複数の特徴モデルを抽出し得る。次に、ＦＰＳは、抽出された特徴モデル９８０又は対応する特徴情報に基づいて、検出された特徴を圧縮する（過程８２０）。

当業者であれば、上記の圧縮方法を複数のフレームに適用することが可能であり、さらに、上記の圧縮方法を必ずしもフレーム１つごとに行う必要がないことが分かるであろう。ただし、図８Ｂは、符号化した映像のレポジトリ内に含まれる、スパースに（疎に）詰め込まれた映像データキューブ内の特徴情報に、インデックスを用いてアクセスする際の一般原理が例示しているに過ぎない。このようにしてアクセスした特徴情報を用いて、新たなターゲットの映像の圧縮を支援することができる。

ここで、図８Ａ及び図８Ｂの基礎となる特徴ベース処理ストリーム（ＦＰＳ）が、特徴の検出のみでなく特徴の追跡及びクラスタ化も実行する前述の（図３及び図６Ａで説明した）ＦＰＳと異なる点に注意されたい。具体的に述べると、図８Ａ及び図８ＢのＦＰＳは、（図３〜図６ＡのＦＰＳのように）特徴ペルおよび特徴情報のみを含むファイル集合内の特徴情報にアクセスするのではなく、入力映像の全てのペルも含んだ映像レポジトリ内の特徴情報にアクセスする。

図８Ｃは、本発明の例示的な一実施形態における、図８Ａ及び図８Ｂの基礎となるＦＰＳの一般過程を示すフロー８２２である。ＦＰＳは、入力映像を処理し（過程８２４）、本願で説明する方法によってその映像から特徴を検出する（過程８３２）。次に、ＦＰＳは、その映像内の特徴についてハッシュベースのインデックスを生成する（過程８３４）。ＦＰＳは、抽出された特徴（過程８３２）および生成されたインデックス（過程８３４）を用いて、その映像を、当該技術分野において周知の圧縮法および／または本願で説明する圧縮法にしたがってトランスコードする（過程８２６）。ＦＰＳは、生成されたインデックス（過程８３４）に基づいて、データの配信を管理する（過程８３６）。例えば、符号化された映像を、前記映像レポジトリ内の特定のサーバクラスタ（サーバで構成されるクラスタ）に記憶し得る。任意で、その映像は、映像の大規模な集合用に組織化されたストレージ構造、データベースまたはその他のデータ構造に記憶され得る（過程８２８）。映像へのアクセスの要求を受けて、前記レポジトリは、要求された映像にアクセスしてロードし（過程８３０）、その要求された映像をストリームする（過程８４０）。ＦＰＳは、データの配信の管理（過程８３６）後、前記レポジトリからモジュールを配信して（過程８３８）映像のストリーミングを支援する（過程８４０）。一実施形態において、ＦＰＳは、前記レポジトリからモジュールをクライアントデバイスに配信して（過程８３８）、そのデバイスに対する映像のストリーミングを支援する（過程８４０）。当業者であれば、これらの過程が必ずしも上記の順番で実行されなくてもよく、任意の順番で実行されてよいことを理解するであろう。

＜汎用的な圧縮処理ストリームの場合の映像レポジトリ＞

前記映像レポジトリは、必ずしも特徴ベース処理ストリームで使用されないといけないわけではない。図８Ｄに、必ずしもモデルベース処理を必要としない圧縮スキームでの場合の、映像レポジトリの一般的な使用の様子を示す。図８Ｄの一般処理フロー（ＧＰＦ）８５０は、まず、レポジトリに記憶すべきターゲットの映像を受け取る（過程８５２）。レポジトリは、その映像を、当該技術分野において周知の圧縮法（必ずしもモデルベースである必要はない）および／または本願で説明する圧縮法にしたがってトランスコードする（過程８５４）。ＧＰＦは、任意で、その映像を、映像の大規模な集合用に組織化されたストレージ構造、データベースまたはその他のデータ構造に記憶する（過程８５６）。映像へのアクセスの要求を受けて、ＧＰＦは、前記レポジトリにアクセスし、要求された映像をロードする（過程８５８）。そして、ＧＰＦは、その要求された映像をストリームする（過程８６０）。当業者であれば、これらの過程が必ずしも上記の順番で実行されなくてもよく、任意の順番で実行されてよいことを理解するであろう。例えば、一実施形態において、ＧＰＦは、映像にアクセス（過程８５８）した後であって当該映像をストリームする（過程８６０）前に、その映像をトランスコードするものであってもよい（過程８５４）。別の実施形態において、ＧＰＦは、映像が入力（過程８５２）された後に最初のトランスコードを行い、さらに、その映像にアクセス（過程８５８）した後であって当該映像をストリームする（過程８６０）前に、その映像に対してさらなるトランスコードを行うものであってもよい（過程８５４）。

＜モデルライブラリの用途＞

＜基本動作：大域的なモデルライブラリおよび（個人用）スマートモデルライブラリ＞

本発明の構成には、特徴モデルライブライをサーバ／クラウドに記憶する構成が含まれ得る。本発明では、モデルライブラリをクラウドに記憶し、必要なときに当該ライブラリ内の特徴情報にアクセスすることにより、高精細度映像を、従来のコーデックよりも少ない帯域量で且つ映像品質の低下を僅かに抑えながら又は全く低下させることなくストリームすることができる。モデル９８０は、１つの映像内で再利用可能なだけでなく（前述したモデルベース圧縮フレームワーク［ＭＢＣＦ］の「オンライン」モード）、完全に相異なる複数の映像にわたって再利用することができる（前記ＭＢＣＦの「オフライン」モード）。このようなシステムは、所与の高精細度映像からモデルを特定及び認識し、これを別の映像において再利用することによって動画像を処理して当該別の映像に提供することができる。このようなモデル９８０の再利用により、ライブラリのファイルサイズが縮小するので、デバイスが映像データをストリームするときに必要な帯域量を減少させることができる。

前記特徴モデルライブラリは、（私的または公的な）クラウド設備に存在し得る。好ましくは、前記特徴モデルライブラリは、必要なときにだけユーザのモバイルデバイスにダウンロードされる。本発明は、Ａｍａｚｏｎ社のＫｉｎｄｌｅ（登録商標）デバイスのアプリケーションや、Ａｐｐｌｅ社のｉＰａｄ（登録商標）デバイスのアプリケーションでの、クラウドとユーザデバイスとの間の今日のコンテンツ管理方法と同様の技術により、オフラインでモデルライブラリを記憶し、必要に応じてユーザデバイスに関連モデル９８０を提供することができる。このようにして、本発明は、映像の圧縮／解凍を支援する。

図９Ａは、クライアントデバイス９０８にネットワーク１７０を介して動作可能に接続される映像レポジトリ９０２の例示的な一実施形態を示すブロック図である。レポジトリ９０２は、符号化された映像の集合（セット）９０４を含む。映像の集合９０４は、第１組の映像９０６Ａ、第２組の映像９０６Ｂ、第３組の映像９０６Ｃおよび第Ｎ組の映像９０６Ｄを含む。当業者であれば、映像の集合９０４にあらゆる数の又はあらゆる組数の映像が含まれ得ることを分かるであろう。映像の集合９０４内の各組の映像９０６Ａ〜９０６Ｄは、互いに関連する物であり得る。例えば、第１組の映像９０６Ａは、第１の特定のテレビ連続番組における所与のシーズンの全エピソードであり得る。第２組の映像９０６Ｂは、第２の特定のテレビ連続番組における所与のシーズンの全エピソードであり得る。同様に、第３組の映像９０６Ｃや第Ｎ組の映像９０６Ｄは、別のシーズンまたは別のテレビ連続番組を含み得る。当業者であれば、各組の映像９０６Ａ〜９０６Ｄが同じテレビ連続番組のエピソード、互いに関連する映画（例えば、続編、三部作など）、スポーツ放送またはその他の関連映像を含み得ることを理解するであろう。

レポジトリ９０２は、ネットワーク１７０を介してクライアントデバイス９０８に動作可能に接続される。クライアントデバイスは、要求生成手段９１４を含む。要求生成手段９１４は、ネットワーク１７０を介してレポジトリ９０８に対して映像の要求９１６を送信する。レポジトリ９０８は、要求受信手段９１８でその映像の要求９１６を受信する。映像の要求９１６は、映像の集合９１８内に含まれる映像を要求するものである。クライアントデバイス９０８は、映像の要求９１６の発行後、要求した映像の受信を待ちながら、任意で、その要求した映像に応じた受信ビットストリームを復号化するために、適切なコーデックを用意する。

要求された映像をクライアントデバイス９０８に送信できるように、レポジトリ９０２は、要求受信手段９１８に、要求された映像のルックアップ９２０を、映像の集合９０４に対して発行させる。要求された映像のルックアップ９２０は、映像の集合９０４のデータ構造に対するルックアップ機能を起動する要求であり得る。要求された映像のルックアップ要求９２０は、映像の集合９０４内に含まれるその要求された映像を効率良く見つけ出すことが可能な、生成済みインデックスに対する要求であり得る。映像の集合９０４は、要求された映像のルックアップ９２０に対し、その要求された映像９２２をストリーム生成手段９２４に出力することにより応答する。

ストリーム生成手段９２４は、要求された映像に対応する生成済みライブラリ９２６とその要求された映像の符号９２８とを出力する。生成済みライブラリ９２６（スマートモデルライブラリとも称される）は、要求された符号化映像（要求された映像を符号化したもの）９２８を復号化するのに必要な特徴モデルを含む。一実施形態において、生成済みスマートモデルライブラリ９２６内のモデルは、前記映像レポジトリ、および当該映像レポジトリ内に含まれる映像を参照する、特徴モデル９８０に付けられたハッシュベースのインデックスから導き出される。

別の実施形態において、前記生成済みスマートモデルライブラリ９２６内のモデルは、再利用可能なモデル（例えば、特徴モデルなど）の集合（セット）を含む大域的なモデルライブラリ９８０から導き出される。大域的なライブラリ内のモデルは、１つの映像内で再利用可能なだけでなく、完全に相異なる複数の映像にわたって再利用することができる。

以上をまとめると、映像レポジトリ９０２は、符号化された映像９０４と大域的なモデルライブラリ９８０とを記憶するか、あるいは、符号化された映像９０４と、映像を参照する、モデルに付けられたハッシュベースのインデックスとを記憶する。

生成済みライブラリ９２６および符号化された映像９２８は、ネットワーク１７０を介してクライアントデバイス９０８に送信される。ライブラリ９２６は、ｉＰａｄ、スマートフォンおよびタブレットを含む、あらゆるデバイスに送信され得る。クライアントデバイス９０８は、ストリーム復号化手段９１０で、生成済みライブラリ９２６および符号化された映像９２８を受信する。ストリーム復号化手段９１０は、生成済みライブラリ９２６内に含まれる情報を用いて、かつ、任意で当該ストリーム復号化手段９１０における他のコーデックを用いて、符号化された映像９２８を復号化する。ストリーム復号化手段９１０は、復号化された映像９１１を出力する。復号化された映像９１１は、メモリ９１２Ａ、ディスプレイ９１２Ｂおよびストレージ手段９１２Ｃのうちの少なくとも１つに送信され得る。

＜バージョン式（個人用）モデルライブラリ＞

図９Ｂは、クライアントデバイス９０８とネットワーク１７０を介して通信する映像レポジトリ９０２の例示的な別の実施形態を示すブロック図である。レポジトリ９０２の動作およびクライアントデバイス９０８の動作は、図９Ａで説明したものとほぼ同じである。ただし、図９Ｂには、さらなる手段、方法および構成が追加されている。当業者であれば、本明細書で説明する相異なる実施形態における、レポジトリ９０２内の手段およびクライアントデバイス９０８内の手段を、実施形態間で置き換えることもできることが分かるであろう。

一実施形態において、レポジトリ９０２およびクライアントデバイス９０８は、映像を復号化するのに用いるライブラリをバージョン化する。クライアントデバイス９０８は、要求生成手段９１４を含む。既述したように、要求生成手段９１４は、映像の要求９１６を要求受信手段９１８に対して発行する。既述したように、要求受信手段９１８は、要求された映像のルックアップ９２０を映像の集合９０４に対して発行する。図９Ａとは異なり、一実施形態において、要求受信手段９１８は、バージョン化手段９５４に対し、要求された映像についてのクライアントバージョンのライブラリのルックアップ９５２を発行する。バージョン化手段は、ルックアップ９５２に基づいて、要求された映像についてのクライアントバージョンのライブラリ９５６を決定する。多くの場合、クライアントデバイスは、コーデック又はライブラリが互いに関連する、互いに関連した映像（関連映像又は関連性のある映像）を要求及びダウンロードし得る。関連映像の一例として、同じテレビ番組の後続エピソードが挙げられる。そのような後続エピソードは、同じテレビ番組の俳優やセット（舞台）間に共通性があるので、類似するフレームを含む可能性が高い。他の例として、スポーツイベントが挙げられる。スポーツイベントの場合、複数のフレームにわたって、フィールド、スタジアム、選手、ロゴ、スポーツ器具などの間に共通性がある。したがって、クライアントデバイス９０８は、符号化された映像９２８と関連する映像及び関連するライブラリを既にダウンロードしている場合、その符号化された映像９２８を復号化するのに必要なモデルのうちの多く又は全てを既に有している可能性が高い。このシナリオでは、既に有しているライブラリを更新するだけで、クライアントが、復号化された映像９２８を復号化できる可能性が高い。完全なライブラリを送信する代わりに、更新のみを送信するだけでよいので、クライアントデバイス９０８に対するデータ送信の帯域量を節約することができる。これにより、ダウンロードサイズが小さくなるので、クライアントデバイス９０８のユーザが要求した映像を視聴できるまでの時間を短くすることができる。

一実施形態において、ストリーム生成手段９２４は、差分ライブラリ生成手段９５８および映像符号化手段９６０を有する。ストリーム生成手段９２４は、要求された映像９２２を映像の集合（セット）９０４から受信する。差分ライブラリ生成手段９５８は、要求された映像およびその要求された映像についてのクライアントバージョンのライブラリ９５６を受信する。一実施形態において、差分ライブラリ生成手段９５８は、要求された映像９２２、モデル９８０およびその要求された映像についてのクライアントバージョンのライブラリ９５６に基づいて、クライアントデバイス９０８がモデルベース圧縮フレームワーク内で映像を復号化するのに必要な更新を決定する。

別の実施形態において、差分ライブラリ生成手段９５８は、要求された映像９２２、ハッシュベースのインデックスおよびその要求された映像についてのクライアントバージョンのライブラリ９５６に基づいて、クライアントデバイス９０８がモデルベース圧縮フレームワーク内で映像を復号化するのに必要な更新を決定する。

差分ライブラリ生成手段９５８は、クライアントデバイス９０８のライブラリ記憶手段９６４に既に記憶されているライブラリに対して必要な更新（追加の特徴モデル）のみを含む、差分ライブラリ９６２を生成する。映像符号化手段９６０は、差分ライブラリ９６２および要求された映像についてのクライアントバージョンのライブラリ９５６に基づいて、符号化された映像９２８を生成する。クライアント固有のバージョンのライブラリを使用することにより、映像配信元は、クライアントが受信するモデルに応じて、様々なレベルの視聴体験を提供することができる。例えば、あるクライアントのライブラリでは、そのモデルにより、視聴中の映像の品質を向上させるようなことが可能になる。

別の実施形態において、映像符号化手段９６０は、単純に最適な圧縮をもたらすモデルを使用することにより、符号化された映像を生成する。差分ライブラリ生成手段９５８は、その映像の符号化に使用したモデル、およびクライアントデバイスに存在するクライアントバージョンのライブラリに関する知識に基づいて、差分ライブラリ９６２を生成する。この実施形態では、追加すべきモデルのみが、前記差分ライブラリに含められる。

クライアントデバイス９０８は、差分ライブラリ９６２および符号化された映像９２８を受信する。クライアントデバイス９０８は、ライブラリ構築手段９６６で差分ライブラリ９６２を受信する。ライブラリ構築手段９６６は、ライブラリ記憶手段９６４から、要求した映像についてのクライアントバージョンのライブラリ９５６をロードする。ライブラリ構築手段９６６は、差分ライブラリ９６２と要求した映像についてのクライアントバージョンのライブラリ９５６とを統合して、統合ライブラリ９７０を生成する。次に、ストリーム復号化手段９１０が、その統合ライブラリ９７０を用いて前記符号化された映像９２８を復号化し、復号化された映像９１１を生成する。この復号化された映像９１１は、メモリ９１２Ａ、ディスプレイ９１２Ｂおよびストレージ手段９１２Ｃのうちの少なくとも１つに配信され得る。このようなシステムは、所与の高精細度映像からのモデルを特定及び認識し、これを別の映像において再利用することによって動画像を処理して当該別の映像に提供することができる。このようにしてモデルを再利用する構成では、複数の映像の復号化に同じモデルを再利用できる場合があり、そのような場合には、クライアントデバイス９０８で複数の映像を復号化するのに必要なライブラリの合計ファイルサイズを縮小させることができる。

＜予測型モデルライブラリ＞

図１０は、クライアントデバイス９０８にネットワーク１７０を介して動作可能に接続される映像レポジトリ９０２の例示的なさらなる他の実施形態を示すブロック図である。ライブラリを予測によって生成及び配信する構成は、例えばネットワーク１７０が使用ピーク時である場合などに、クライアントデバイス９０８のユーザにとって有利な構成となり得る。例えば、ネットワークが高トラフィック状態になっても、クライアントデバイス９０８に既にライブラリが生成及び送信されており、レポジトリがライブラリを送信する必要がない場合には、これは当該ネットワーク１７０の使用集中時の帯域量の低減をもたらす。

図１０に示す映像レポジトリ９０２は、ストリーム生成手段９２４を含む。ストリーム生成手段９２４は、予測型ライブラリ生成手段１００２を有する。予測型ライブラリ生成手段１００２は、ユーザプロファイル生成手段１００４によって生成されたユーザのプロファイル（ユーザプロファイル）１００６を受信する。ユーザプロファイル生成手段１００４は、ユーザの情報（ユーザ情報）を記憶する。そのようなユーザ情報としては、例えば、デモグラフィック情報、地理的情報、ソーシャルネットワーキング情報、応援する少なくとも１つのスポーツチームなどが挙げられる。ユーザプロファイル生成手段１００４は、さらに、ユーザが視聴する可能性が高い種類の映像に関する、個人嗜好データを有し得る。例えば、バスケットボールやＮＡＳＣＡＲやＦａｍｉｌｙ Ｇｕｙなどを好む人間もいれば、Ｍａｄ Ｍｅｎやリアリティ番組などを楽しむ人間もいるであろう。ユーザの嗜好は、レポジトリ９０２から過去にダウンロードされた映像のリストなどのビデオオンデマンド（ＶＯＤ）データ、ユーザサブスクリプション（例えば、シーズンパスなど）、ユーザの映像用のキュー、ユーザによるリリース前の購入、あるいは、これらのデータソースの任意の組合せの協調フィルタリングから導き出され得る。また、ユーザの視聴の嗜好及びふるまいを用いて、各個人のデバイスに供給される特徴モデルライブラリを改良することをも可能である。例えば、ユーザの嗜好データを配信スケジュールと組み合わせることにより、さらなる改良を実現することができる。

予測型ライブラリ生成手段１００２は、モデルライブラリ１０１２を生成するために、ユーザプロファイル１００６に基づき、映像を予測によって符号化する要求１００８を生成する。例えば、予測型ライブラリ生成手段１００２は、特定のテレビ番組のファンであることがユーザプロファイル１００６に示されていることに応じて、このファン用のライブラリを、予測によって生成し得る。

レポジトリの配信及びキャッシュ格納を予測することにより、映像へのアクセス、インデックス付けおよび記録保管を向上させることができる。また、需要シナリオを予測することにより、映像及び当該映像に対応するライブラリの配信及びキャッシュ格納の予測が容易になる。

一実施形態において、需要シナリオは、依存性（関係があること）に基づいたものであり得るか、ＶＯＤの予測される事前配信に基づいたものであり得るか、またはスケジュール配信に基づいたものであり得る。このような需要シナリオには、ロングテールＶＯＤ（すなわち、一般的に選ばれない映像の要求）、推奨システム、デモグラフィックプロファイル、配信スケジュール、応援する少なくとも１つのスポーツチーム、ソーシャルネットワーク、協調フィルタ、キュー、シーズンパス、リリース前の購入などが含まれ得る。どのシナリオも、映像の記憶要件及び配信の最適化に影響し得る。

一実施形態において、需要シナリオは、ロングテールＶＯＤシナリオである。ロングテールＶＯＤは、ユーザにストリーム可能な映像の集合の中から、ユーザが映像（おそらく、人気のない映像）を選択することを伴う。このときの映像選択プロセスは、その集合に含まれたあらゆる映像データに対して平等にアクセスできるように、バランスが取られたものとされる。ロングテールＶＯＤシナリオでは、ロングテールＶＯＤ（一般的に選ばれない映像）を、高需要の映像特徴モデルで符号化することができる場合が多い。これにより、モデルデータがクライアントデバイスに存在する確率が高くなり、（高需要データの配信後に残る映像データは、理想的にはごく僅かなので）残りの映像データの配信が容易になる。

別の実施形態において、需要シナリオは、推奨システムである。推奨システムは、各ユーザのこれまでの映像の嗜好（映像嗜好）を分析し、そのユーザのこれまでの映像嗜好と高い確率で合うダウンロード可能な映像データを、ユーザに選択するように促す。特徴モデルは、ユーザのこれまでの映像嗜好に基づいて整理され、配信を支援し得る。ネットワーク需要が大きい場合（多数のユーザがネットワークを使用している状態）にそなえて、予測されるユーザ需要（ユーザの需要）に対応する特徴モデルを予め配信するようにしてもよい。

別の実施形態において、需要シナリオは、（例えば、デモグラフィックプロファイル情報などからの）地域的な嗜好（又は地域ごとの嗜好）である。現時点までの嗜好を、デモグラフィックプロファイル情報から導き出すことにより、レポジトリが、地域に応じてユーザにコンテンツを促すものであってもよい。コンテンツ配信元が、そのようなコンテンツをユーザに促す際のリソースコストを負担するようにしてもよい。

別の実施形態において、需要シナリオは、配信スケジュールである。この場合、配信スケジュール（例えば、予定ネットワークスケジュールなど）に基づいて、モデルが配信又は導き出され得る。モデルを、所与のチャンネルからの記録に基づいて生成し、別のチャンネルのプログラムを符号化したもの又は同じチャンネルの別のプログラムを符号化したものにおいて、当該モデルを再利用するようにしてもよい。モデルは、ＤＶＤ、ケーブルなどから入手可能な映像データから導き出され得る。一実施形態において、モデルの送信には、映像データの品質および／または解像度を向上させるエンハンスメント情報（向上用情報）が含まれ得る。レポジトリは、既存の放送モデルを補助する、派生「品質向上」サービスを提供し得る。

別の実施形態において、需要シナリオは、応援する少なくとも１つのスポーツチームである。ユーザが応援するスポーツ／チームに基づくモデルは、映像データにおいて一貫性（例えば、同じ選手の顔、チームロゴ、ユニフォーム、チームのスタジアムなど）を有し得る。また、そのようなモデルの配信ターゲットが、地理的に定まり得る。モデルは、マルチビューブラウジング（multi-view browsing）に基づいたものであり得るか、再生に基づいたものであり得るか、時間的高分解能に基づいたものであり得るか、あるいは、リアルタイムの需要に基づいたものであり得る。モデルの配信は、ティアード（料金別）にされてもよい。

別の実施形態において、需要シナリオは、ソーシャルネットワーキングおよび／または協調フィルタリングである。ソーシャルネットワークの場合、ユーザの交流者（peer）／人脈／友人の映像需要を決定することで需要を予測し得る。協調フィルタの場合、ユーザの需要を、交流者に基づいて間接的に予測し得る。モデルは、ソーシャルネットワークまたは協調フィルタに基づいてユーザが視聴すると予測される映像から導き出され得る。

別の実施形態において、需要シナリオは、映像用のキューである。キューは、キューに入れられる映像データまたは遅延もしくはシフトされる時間をユーザが選択することによる、予測需要についてのユーザ指定の優先順位であり得る。モデルは、キューの中身に対してモデル利用を最適化させることに基づいて配信され得る。

別の実施形態において、需要シナリオは、シーズンパスである。この場合、需要コンテンツの収益性及び独占配信度が高まり、そのような収益化及び独占配信度がコンテンツに直接関係することから、モデルは、アドオンの１回きりでない追加コンテンツに基づいたものであり得る。この需要シナリオの場合、配信されたコンテンツが維持される可能性およびコンテンツが確実に配信されている可能性が高くなる。さらに、スポーツの映像データの場合と同様に、配信内容のデータ間の自己類似度（self-similarity）（例えば、複数のエピソードにわたって同じ俳優、同じセット（部隊）、同じグラフィクスなど）が高くなる。

別の実施形態において、需要シナリオは、リリース前の購入である。リリース前の購入には、リリース前の映像データ、トレイラー、ショートフィルム、「ウェビソード」サンプルなどが含まれ得る。映像およびモデルライブラリの配信は、配信されるリリース前の購入に基づいたものであり得る。

レポジトリ内のデータの編成を決定するための使用シナリオは、予め決められていても、予め決められていなくてもよい。予め決められた使用シナリオは、映像データの一般的な表現に処理を集中させる。予め決められていない使用シナリオは、映像データの詳細な表現に処理を集中させる。

一実施形態において、図１０に示す映像の集合９０４は、予測によって映像を符号化する要求１００８に対し、符号化すべき映像１０１０を出力すると共に、対応する映像モデルのハッシュベースのインデックスを出力する。

別の実施形態では、予測型ライブラリ生成手段１００２が、ハッシュベースのインデックスの代わりに、モデルライブラリからモデル９８２を取得して当該モデル９８２を使用する。そして、予測型ライブラリ生成手段１００２は、予測によって生成されたライブラリ１０１２を出力する。予測によって生成されたライブラリ１０１２は、ネットワーク１７０を介してクライアントデバイス９０８に送信される。クライアントデバイス９０８は、この予測によって生成されたライブラリ１０１２を、ライブラリ記憶手段９６４に記憶する。当業者であれば、クライアントデバイス９０８が、前記予測によって生成されたライブラリ１０１２の記憶及び当該ライブラリ１０１２の使用を、復号化対象の符号化された適切な映像を受信すると同時に行うことを理解するであろう。また、当業者であれば、このように予測によってライブラリを生成する実施形態と、レポジトリ９０８およびクライアントデバイス９０８に係る他の実施形態とを、互いに組み合わせられることが分かるであろう。例えば、ライブラリを予測によって生成し、これを図９Ｂを参照しながら説明したように差分の形態でクライアントデバイス９０８に送信することが可能である。

前述した本発明の実施形態は、互いに適宜組み合わせられることにより、また、組み合わせられなくても、さらなる実施形態を構成することができる。

本発明を例示的な実施形態を参照しながら具体的に図示・説明したが、当業者であれば、添付の特許請求の範囲に包含される本発明の範囲から逸脱することなく、形態および細部の詳細な変更が可能であることを理解するであろう。例えば、本明細書では、コーデック、エンコーダ、デコーダなどの様々なシステムコンポーネントを用いて説明したが、当業者であれば、それ以外の適切なハードウェア又はソフトウェアのデジタル処理により、本明細書で説明した映像処理技術を実現できることを理解するであろう。一例として、本発明は、あらゆる種類のコンピュータアーキテクチャで実現することが可能である。図１１Ａ及び図１１Ｂのコンピュータネットワークは例示に過ぎず、本発明を限定するものではない。

本発明は、全体がハードウェアの実施形態にもなり得るし、全体がソフトウェアの実施形態にもなり得るし、ハードウェア構成要素とソフトウェア構成要素の両方を含む実施形態にもなり得る。好ましい一実施形態において、本発明はソフトウェアによって実現される。そのようなソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含み得るが、必ずしもこれらに限定されない。

また、本発明は、コンピュータ利用可能な媒体内の又はコンピュータ読取可能な媒体内のアクセス可能なコンピュータプログラムプロダクトであって、コンピュータもしくは任意の命令実行システムにより使用されるか又はコンピュータもしくは任意の命令実行システムとの関連で使用されるプログラムコードを提供する、コンピュータプログラムプロダクトの形態を取り得る。本明細書において、コンピュータ利用可能な媒体又はコンピュータ読取可能な媒体とは、命令実行システム、装置もしくはデバイスにより使用されるか又は命令実行システム、装置もしくはデバイスとの関連で使用されるプログラムを含んだり、そのようなプログラムの記憶、通信、伝播、輸送などを行ったりする、あらゆる装置のことを言う。

前記媒体は、電子、磁気、光学、電磁、赤外線、半導体系などの、システム（もしくは装置もしくはデバイス）または伝播媒体であり得る。プログラムコードを記憶および／または実行するのに適したデータ処理システムは、メモリ構成要素にシステムバスを介して直接又は間接的に接続される、少なくとも１つのプロセッサを備える。このようなメモリ構成要素は、プログラムコードの実際の実行時に利用されるローカルメモリ、大容量記憶装置、実行時に大容量記憶装置からコードを取り出す回数を減らすために少なくとも一部のプログラムコードを一時的に記憶するキャッシュメモリなどを含み得る。

前記データ処理システムにネットワークアダプタを接続することにより、当該システムを、私用または公用のネットワークを介して、別のデータ処理システム、離れたプリンター、離れたストレージデバイスなどに接続できるようにすることも可能である。現在入手可能な種類のネットワークアダプタの幾つかの例として、モデム、ケーブルモデム、イーサネット（登録商標）カードなどが挙げられる。

図１１Ａには、そのような実施形態の一例が示されている。少なくとも１つのクライアントコンピュータ／デバイス１１１０およびクラウド（またはサーバーコンピュータもしくはその集団）１１１２は、アプリケーションプログラムを実行する処理機能、記憶機能および入出力装置などを実現し得る。少なくとも１つのクライアントコンピュータ／デバイス１１１０は、通信ネットワーク１１１６を介して、（別のクライアントデバイス／プロセス１１１０および少なくとも１つの別のサーバーコンピュータ１１１２も含め）別のコンピューティングデバイスに接続可能である。通信ネットワーク１１１６は、リモートアクセスネットワークの一部、グローバルネットワーク（例えば、インターネットなど）の一部、世界規模のコンピュータの集まりの一部、ローカルエリアネットワークの一部、ワイドエリアネットワークの一部、あるいは、各種プロトコル（ＴＣＰ／ＩＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）を用いて相互通信するゲートウェイの一部であり得る。それ以外の電子デバイス／コンピュータネットワークアーキテクチャも使用可能である。

図１１Ｂは、図１１Ａの処理環境における所与のコンピュータ／コンピューティングノード（例えば、クライアントプロセッサ／デバイス１１１０、サーバーコンピュータ１１１２など）の内部構造を示す図である。各コンピュータ１１１０，１１１２は、コンピュータ（又は処理システム）の構成品間のデータ転送に用いられる実在する又は仮想的なハードウェアラインのセットである、システムバス１１３４を備える。バス１１３４は、コンピュータシステムの相異なる構成品（例えば、プロセッサ、ディスクストレージ、メモリ、入力／出力ポートなど）同士を接続する共有の配管のようなものであり、それら構成品間の情報のやり取りを可能にする。システムバス１１３４には、様々な入出力装置（例えば、キーボード、マウス、ディスプレイ、プリンター、スピーカーなど）をコンピュータ１１１０，１１１２に接続するためのＩ／Ｏ装置インターフェース１１１８が取り付けられている。コンピュータ１１１０，１１１２は、ネットワークインターフェース１１２２を介して、ネットワーク（例えば、図１１Ａのネットワーク１１１６など）に取り付けられた他の様々なデバイスに接続することができる。メモリ１１３０は、本発明の一実施形態（例えば、図１〜図１０を参照しながら説明したコーデック、ビデオエンコーダ／デコーダ、特徴モデル、モデルライブラリ、支援コードなど）を実現するのに用いられるコンピュータソフトウェア命令１１２４およびデータ１１２８を記憶する揮発性メモリである。ディスクストレージ１１３２は、本発明の一実施形態を実施するのに用いられるコンピュータソフトウェア命令１１２４（「ＯＳプログラム」１１２６と同等）およびデータ１１２８を記憶する不揮発性ストレージである。ディスクストレージ１１３２は、モデルを長期的に記憶するのに使用され得る。また、ディスクストレージ１１３２は、映像を圧縮フォーマットで長期的に記憶するのにも使用され得る。システムバス１１３４には、さらに、コンピュータ命令を実行する中央演算処理装置１１２０も取り付けられている。なお、本明細書をとおして、「コンピュータソフトウェア命令」と「ＯＳプログラム」は互いに等価物である。

一実施形態において、プロセッサルーチン１１２４およびデータ１１２８は、本発明にかかるシステム用のソフトウェア命令の少なくとも一部を提供するコンピュータプログラムプロダクト（概して符号１１２４で示す）である。コンピュータプログラムプロダクト１１２４としては、ストレージデバイス１１２８に記憶可能なコンピュータ読み取り可能な媒体が挙げられる。コンピュータプログラムプロダクト１１２４は、当該技術分野において周知である任意の適切なソフトウェアインストール方法によってインストール可能なものであり得る。他の実施形態において、前記ソフトウェア命令の少なくとも一部は、ケーブルおよび／または通信および／または無線接続を介してダウンロード可能なものであり得る。さらなる他の実施形態において、本発明にかかるプログラムは、伝播媒体による伝播信号（例えば、無線波、赤外線波、レーザ波、音波、インターネットなどのグローバルネットワークやその他のネットワークによって伝播される電波など）によって実現される、コンピュータプログラム伝播信号プロダクト１１１４（図８Ａ）である。このような搬送媒体または搬送信号が、本発明にかかるルーチン／プログラム１１２４，１１２６用のソフトウェア命令の少なくとも一部を提供する。

さらなる他の実施形態において、前記伝播信号は、伝播媒体によって搬送されるアナログ搬送波またはデジタル信号である。例えば、前記伝播信号は、グローバルネットワーク（例えば、インターネットなど）、電気通信ネットワークまたはその他のネットワークによって搬送されるデジタル信号であり得る。一実施形態において、前記伝播信号は、所与の期間のあいだ伝播媒体によって送信される信号であり、例えば、数ミリ秒、数秒、数分またはそれ以上の期間のあいだネットワークによってパケットで送信される、ソフトウェアアプリケーション用の命令などであり得る。他の実施形態において、コンピュータプログラムプロダクト１１２４の前記コンピュータ読み取り可能な媒体は、コンピュータシステム１１１０が受け取って読み取り可能な伝播媒体である。例えば、コンピュータシステム１１１０は、前述したコンピュータプログラム伝播信号プロダクトの場合のように、伝播媒体を受け取ってその伝播媒体内に組み込まれた伝播信号を特定する。

図示のデータ経路／実行経路及び構成要素は例示に過ぎず、各構成要素の動作及び構成並びに各構成要素からのデータフロー及び各構成要素へのデータフローが、実施形態や圧縮する映像データの種類によって変わり得ることは、当業者であれば理解できる。つまり、あらゆる構成のデータモジュール／データ経路を採用することが可能である。

本発明を例示的な実施形態を参照しながら具体的に図示・説明したが、当業者であれば、添付の特許請求の範囲に包含される本発明の範囲から逸脱することなく、形態および細部の詳細な変更が可能であることを理解するであろう。

Claims (23)

1. 映像データを提供する方法であって、
   大域的な特徴モデルライブラリからの特徴モデルを利用する特徴ベース圧縮プロセスにより、対象の映像ストリームを符号化する過程であって、前記対象の映像内の符号化するマクロブロックを指定するように前記特徴モデルを暗示的に用いて、符号化された映像データを取得する過程と、
   要求に応答して、要求側のデバイスに前記符号化された映像データを送信する過程であって、前記大域的な特徴モデルライブラリからの前記特徴モデルが当該要求側のデバイスに利用可能とされ、前記符号化された映像データが当該要求側のデバイスにおいて復号化可能である過程と、
   を備え、前記大域的な特徴モデルライブラリが、
   前記対象の映像ストリームと異なる少なくとも１つの入力映像を受け取り、
   前記入力映像のそれぞれについて、特徴情報および対応する特徴モデルを生成する、
   ことによって構成される、映像データの提供方法。
2. 請求項１に記載の映像データの提供方法において、前記特徴ベース圧縮プロセスは、前記特徴モデルに基づいて、相異なる複数の映像ソースにわたって特徴ベース予測を適用し、当該相異なる複数の映像ソースが、少なくとも、前記大域的な特徴モデルライブラリの前記入力映像および前記対象の映像ストリームである、映像データの提供方法。
3. 請求項１に記載の映像データの提供方法において、前記大域的な特徴モデルライブラリが、さらに、
   前記入力映像から生成された前記特徴モデルをデータストアまたはクラウドストレージに記憶する、
   ことによって構成され、
   前記データストアまたは前記クラウドストレージは、関係する特徴モデルを、前記特徴ベース圧縮プロセスおよび前記要求側のデバイスに提供する、映像データの提供方法。
4. 請求項１に記載の映像データの提供方法において、前記大域的な特徴モデルライブラリが、さらに、
   入力映像ごとに、当該入力映像内の特徴を特定し当該特徴にインデックスを付け、インデックスが付けられた特徴が前記対応する特徴モデルを構成する、
   ことによって構成され、
   前記インデックスは、前記入力映像内における前記特定された特徴の位置を示し、
   前記要求側のデバイスでは、前記符号化された映像データを復号化する際に、前記インデックスが付けられた特徴および前記入力映像内における当該特徴の対応する位置を用いることにより、前記特徴モデルを得て前記符号化された映像データを復号化する、映像データの提供方法。
5. 請求項４に記載の映像データの提供方法において、特徴に付ける前記インデックスが、ハッシュベースのインデックスである、映像データの提供方法。
6. 請求項１に記載の映像データの提供方法において、前記大域的な特徴モデルライブラリからの前記特徴モデルが、要求側のデバイスごと又は対象の映像ストリームごとに特化した、実用的なモデルの部分集合のライブラリを構成する、映像データの提供方法。
7. 請求項１に記載の映像データの提供方法において、前記大域的な特徴モデルライブラリからの前記特徴モデルが、前記要求側のデバイスに存在するライブラリの状態に対する差分ライブラリである、実用的なモデルの部分集合のライブラリを構成する、映像データの提供方法。
8. 請求項１に記載の映像データの提供方法において、前記大域的な特徴モデルライブラリからの前記特徴モデルが、前記要求側のデバイスのエンドユーザのプロファイルに関係した特徴モデルを記憶する予測型モデルライブラリである、実用的なモデルの部分集合のライブラリを構成する、映像データの提供方法。
9. 請求項８に記載の映像データの提供方法において、前記予測型モデルライブラリが、様々な需要シナリオへの適用を可能にする変更可能な（設定可能な）パラメータを有する、映像データの提供方法。
10. 映像データシステムであって、
    映像データを記憶し、映像をストリームするソースとして機能するレポジトリと、
    前記レポジトリに動作可能に接続されたコーデックであって、映像の要求に応答して、プロセッサによって、（ｉ）前記要求された映像に該当する、前記レポジトリに記憶された映像データを符号化し、（ｉｉ）前記レポジトリから前記符号化された映像データをストリームするように実行されるコーデックと、
    を備え、
    前記コーデックが、大域的な特徴モデルライブラリからの特徴モデルを用いて特徴ベース予測を適用し、
    前記大域的な特徴モデルライブラリは、
    前記要求された映像に該当する、前記レポジトリに記憶された映像データと異なる少なくとも１つの入力映像を受け取り、
    前記入力映像のそれぞれについて、特徴情報および対応する特徴モデルを生成する、
    ことによって構成され、
    前記コーデックが、相異なる複数の映像データにわたって、前記要求された映像に該当する、前記レポジトリに記憶された映像データに関する特徴ベース予測を適用し、当該相異なる複数の映像データが、前記大域的な特徴モデルライブラリの前記入力映像を含む、映像データシステム。
11. 請求項１０に記載の映像データシステムにおいて、前記コーデックが、前記特徴モデルに基づいて特徴ベース予測を適用する特徴ベース圧縮により、前記レポジトリに記憶された前記映像データを符号化し、前記レポジトリからストリームされる映像データであるその符号化された映像データを要求側のデバイスに送信する、映像データシステム。
12. 請求項１１に記載の映像データシステムにおいて、前記大域的な特徴モデルライブラリからの前記特徴モデルが、前記要求側のデバイスに利用可能であり、前記符号化された映像データが当該要求側のデバイスにおいて復号化可能である、映像データシステム。
13. 請求項１１に記載の映像データシステムにおいて、前記大域的な特徴モデルライブラリが、さらに、
    入力映像ごとに、当該入力映像内の特徴を特定し当該特徴にインデックスを付け、インデックスが付けられた特徴が前記対応する特徴モデルを構成する、
    ことによって構成され、
    前記インデックスは、前記入力映像内における前記特定された特徴の位置を指定し、
    前記要求側のデバイスでは、前記符号化された映像データを復号化する際に、前記インデックスが付けられた特徴および前記入力映像内における当該特徴の対応する位置を用いることにより、前記特徴モデルを取得して前記符号化された映像データを復号化する、映像データシステム。
14. 請求項１３に記載の映像データシステムにおいて、特徴に付ける前記インデックスが、ハッシュベースのインデックスである、映像データシステム。
15. 請求項１０に記載の映像データシステムにおいて、前記特徴モデルが、前記レポジトリに記憶される、映像データシステム。
16. 請求項１０に記載の映像データシステムにおいて、前記大域的な特徴モデルライブラリからの前記特徴モデルが、要求側のデバイスごとに又はストリームされる符号化された映像データごとに特化した、実用的なモデルの部分集合のライブラリを構成する、映像データシステム。
17. 請求項１０に記載の映像データシステムにおいて、前記大域的な特徴モデルライブラリからの前記特徴モデルが、要求側のデバイスに存在するライブラリの状態に対する差分ライブラリである、実用的なモデルの部分集合のライブラリを構成する、映像データシステム。
18. 請求項１０に記載の映像データシステムにおいて、前記大域的な特徴モデルライブラリからの前記特徴モデルが、エンドユーザのプロファイルに関係した特徴モデルを記憶する予測型モデルライブラリである、実用的なモデルの部分集合のライブラリを構成する、映像データシステム。
19. 請求項１８に記載の映像データシステムにおいて、前記予測型モデルライブラリが、様々な需要シナリオへの適用を可能にする変更可能なパラメータを有する、映像データシステム。
20. プログラムコード手段を備えるコンピュータプログラムプロダクトであって、
    前記プログラムコード手段は、コンピュータにロードされることにより、請求項１から１９のいずれか一項に記載の映像データシステムを実行するように当該コンピュータを制御する、コンピュータプログラムプロダクト。
21. プログラムコード手段を備えるコンピュータプログラムプロダクトであって、
    前記プログラムコード手段は、コンピュータにロードされることにより、請求項１に記載のシステムの実現を促す命令を実行するように当該コンピュータを制御する、コンピュータプログラムプロダクト。
22. プログラムコード手段を備えるコンピュータプログラムプロダクトであって、
    前記プログラムコード手段は、コンピュータにロードされることにより、請求項１０に記載の映像データシステムの実現を促す命令を実行するように当該コンピュータを制御する、コンピュータプログラムプロダクト。
23. 映像データシステムであって、
    映像データを記憶し、映像をストリームするソースとして機能するレポジトリ手段と、
    前記レポジトリ手段に動作可能に接続されたコーデック手段であって、映像の要求に応答して、プロセッサ手段によって、（ｉ）前記要求された映像に該当する、前記レポジトリ手段に記憶された映像データを符号化し、（ｉｉ）前記レポジトリ手段から前記符号化された映像データをストリームするように実行されるコーデック手段と、
    を備え、
    前記コーデック手段が、大域的な特徴モデルライブラリからの特徴モデルを用いて特徴ベース予測を適用し、
    前記大域的な特徴モデルライブラリは、
    前記要求された映像に該当する、前記レポジトリ手段に記憶された映像データと異なる少なくとも１つの入力映像を受け取り、
    前記入力映像のそれぞれについて、特徴情報および対応する特徴モデルを生成する、
    ことによって構成され、
    前記コーデック手段が、相異なる複数の映像データにわたって、前記要求された映像に該当する、前記レポジトリ手段に記憶された映像データに関する特徴ベース予測を適用し、当該相異なる複数の映像データが、前記大域的な特徴モデルライブラリの前記入力映像を含む、映像データシステム。