JP4949591B2 - ビデオ誤り回復方法 - Google Patents

Description

【０００１】
（技術分野）
本発明は、通信ネットワーク上でのマルチメディア・データ転送、特に、エラーを起こしやすいネットワーク上でのビデオ・データ転送に関する。本発明は、データ損失によるビデオ画像の知覚品質の劣化を軽減することができる新しい方法を提供する。
【０００２】
（背景技術）
本発明の利点を理解してもらうためには、従来技術による周知の通常のマルチメディア・コンテンツの生成および検索システムの枠組みの再検討をし、圧縮ビデオ・シーケンスの特徴を紹介すれば、理解がかなり容易になると考える。以下の説明においては、情報が、パケットをベースとするデータ・プロトコル（例えば、インターネット）により送信されるネットワーク内に記憶されているマルチメディア・データの検索を重点的に説明するが、本発明は、同じように固定ラインPSTN（公衆電話網）または移動PLMN（公衆陸上移動通信網）電話システムにも適用することができることを理解されたい。本発明は、また、パケットをベースとするプロトコルと回線交換データ伝送プロトコルの組合わせを使用するネットワークでも適用することができる。例えば、現在標準化が行われている汎用移動電話システム（UMTS）は、回線交換素子およびパケットをベースとする素子の両方を含むことができる。本発明は、ビデオ・ストリーミングのような非リアルタイムの用途にも適用することができるし、ビデオ電話のようなリアルタイムの通信の用途にも適用することができる。
【０００３】
図１は、通常のマルチメディア・コンテンツ生成および検索システムである。全体を参照番号１で示すこのシステムは、１つまたはそれ以上のマルチメディア・コンテンツ・ソース１０を持つ。これらのソースは、例えば、ビデオ・カメラおよびマイクロホンを含むことができるが、他の素子も含むことができる。例えば、マルチメディア・コンテンツは、また、コンピュータ・アニメ・グラフィックス、またはネットワークで接続しているハードドライブのような大容量記憶媒体上に記憶しているデータ・ファイルのライブラリを含むことができる。
【０００４】
（「トラック」と呼ばれる）異なる媒体タイプからなるマルチメディア・クリップを構成するために、種々のソース１０から捕捉または検索した生のデータを結合させることができる。図１のマルチメディア生成および検索システムの場合には、このタスクはエディタ１２により行われる。生のマルチメディア・データが必要とする記憶スペースは、通常、メガバイト単位の巨大なものである。それ故、特に低いビット速度のチャネルを通じて魅力的なマルチメディア検索サービスを容易に行うために、通常、編集プロセスの際にマルチメディア・クリップが圧縮される。マルチメディア・クリップを形成するために、生のデータの種々のソースが結合され、圧縮されると、クリップは、マルチメディア・サーバ１４に送られる。通常、多数のクライアント１６が、同じ形式のネットワークを通してサーバにアクセスすることができるが、分かりやすくするために、図１にはクライアントは１つしか図示していない。
【０００５】
サーバ１４は、クライアントが提示する要求および制御コマンド１５に応答することができる。サーバの主なタスクは、クライアント１６に必要なマルチメディア・クリップを送信することである。クライアントがクリップを受信すると、このクリップは、クライアントの端末装置のところで解凍され、マルチメディア・コンテンツが「再生」される。再生の段階で、マルチメディア・クリップの各成分は、クライアントの端末装置内に設置されている適当な再生手段１８上に表示される。例えば、ビデオコンテンツは、端末装置のディスプレイ上に表示され、オーディオコンテンツはラウドスピーカ等で再生される。
【０００６】
図２を参照しながら、マルチメディア・クリップ・エディタ１２の動作をさらに詳細に説明する。生のデータは、１つまたはそれ以上のデータ・ソース１０から捕捉デバイス２０により捕捉される。データはハードウェア、専用デバイス・ドライバ（すなわち、ソフトウェア）およびそのデバイス・ドライバを制御することによりハードウェアを使用する捕捉アプリケーション・プログラムにより捕捉される。例えば、データ・ソースがビデオ・カメラである場合には、ビデオ・データを捕捉するのに必要なハードウェアは、パーソナル・コンピュータに取り付けられているビデオ・グラッバ・カードから構成することができる。捕捉デバイス２０の出力は、一般に、圧縮していないデータ、または圧縮していないデータと比較した場合、品質に無関係な若干圧縮したデータである。例えば、ビデオ・グラッバ・カードの出力は、圧縮していないYUV4:2:0フォーマット、またはモーションＪＰＥＧ画像フォーマットのビデオ・フレームであってもよい。「ストリーム」という用語は、実際には、多くの場合、マルチメディア・データがリアルタイムで種々のソースから、生のデータの連続している「流れ」から捕捉されることを意味する。他の方法としては、マルチメディア・データのソースを、ネットワーク・ハードドライブのような大容量記憶媒体上に常駐する、予め記憶したファイルの形にすることもできる。
【０００７】
エディタ２２は、個々の媒体ソース１０から入手した別々の媒体ストリームを１つの時間的ラインにリンクする。例えば、オーディオコンテンツおよびビデオコンテンツのような同時に再生しなければならないマルチメディア・ストリームは、各フレームの必要な再生時間を表示してリンクされる。他のマルチメディア・ストリームの必要な再生時間の表示も行うことができる。最初は独立していたマルチメディア・ストリームが、このような方法で現在リンクしていることを表示するために、この点から、マルチメディア「トラック」という用語が、マルチメディア・コンテンツを表示するための一般的な用語として使用される。また、エディタ２２は、種々の方法でマルチメディア・トラックを編集することもできる。例えば、ビデオ・フレーム速度を半分に減速することもできるし、ビデオ画像の空間的解像度を低減することもできる。
【０００８】
圧縮段階２４においては、問題の媒体タイプに対して適当な方法で、各媒体トラックを別々に圧縮することができる。例えば、圧縮していないYUV4:2:0ビデオ・トラックを低ビット速度ビデオ符号化用のITU-T勧告H.263により圧縮することができる。多重化段階２６においては、１つのビット・ストリームとなるように圧縮媒体トラックがインターリーブされる。多数の異なる媒体タイプからなる、この１本のビット・ストリームは、「マルチメディア・クリップ」と呼ばれる。しかし、マルチメディア・ビット・ストリームを供給する場合、多重化が不可欠なものではないことに留意されたい。次に、クリップは、マルチメディア・サーバ１４に送られる。
【０００９】
図３のフローチャートを参照しながら、マルチメディア・サーバ１４の動作をより詳細に説明する。通常、マルチメディア・サーバは、２つの動作モード、すなわち、非リアルタイム・モードとリアルタイム・モードとを持つ。すなわち、マルチメディア・サーバは、予め記憶しているマルチメディア・クリップ、または生の（リアルタイムの）マルチメディア・ストリームを供給することができる。前者の場合には、最初にサーバのデータベース３０内にクリップを記憶しなければならない。次に、サーバが、「オンデマンド」モードでこのデータベースにアクセスする。後者の場合、マルチメディア・クリップは、エディタ１２により、連続的媒体ストリームとしてサーバに送られ、直ちにクライアント１６に送られる。サーバは、多重化フォーマットで使用されるヘッダ情報の中のいくつかを除去し、圧縮することができ、また媒体クリップをネットワーク上で送るのに適当なパケット内に収容することもできる。クライアントは、「制御プロトコル」１５により、サーバの動作を制御する。制御プロトコルが供給する最小の一組の制御は、必要な媒体クリップを選択する機能からなる。さらに、サーバは、もっと高度の制御をサポートすることができる。例えば、クライアント１６は、クリップの送信をストップすることができ、またはその送信を一時的にストップし、再開することもできる。さらに、クライアントは、伝送チャネルの処理能力が何らかの理由で変動した場合、媒体の流れを制御することができる。この場合、サーバは、動的に送信のために使用できる帯域幅を利用するために、ビット・ストリームを調整する。
【００１０】
図４は、通常のマルチメディア検索クライアント１６に属するモジュールである。マルチメディア・サーバから圧縮および多重化した媒体クリップを検索している場合、クライアントは、クリップ内に含まれている異なる媒体トラックを分離するために、最初にクリップ４０を逆多重化する。その後で、個々の媒体トラックが解凍される（４２）。次に、解凍された（再構成された）媒体トラックが、クライアントの出力デバイス１８により再生される。これらの動作の他に、クライアントは、エンド・ユーザに対してインターフェースとして機能し、ユーザ入力により再生を制御し、クライアント−サーバ制御トラヒックを処理するコントローラ・ユニット４６を含む。逆多重化動作、解凍動作および再生動作は、クリップの以降の部分をダウンロードしながら行うことができることに留意されたい。この方法は、通常、「ストリーミング」と呼ばれる。他の方法としては、クライアントは、全クリップをダウンロードし、それを逆多重化し、個々の媒体トラックのコンテンツを解凍し、その後にのみ、再生機能をスタートすることができる。
【００１１】
次に、通信ネットワークでの送信に適しているデジタル・ビデオ・シーケンスの性質について説明する。フィルム上に記録された通常の映画のようなビデオ・シーケンスは、一連の静止画像を含み、通常は、１５〜３０フレーム／秒の比較的速い速度で画像を順次表示することにより、画像が動いているように見せる。フレーム速度が比較的速いために、連続しているフレーム内の画像は、非常によく似ている傾向があり、そのため、かなりの量の冗長な情報を含む。例えば、通常、１つのシーンは、例えば、背景および、例えば、ニュースキャスターの顔、交通等のような多くの種々の形をとる、ある種の動いている領域のようないくつかの静止素子を含む。他の方法としては、そのシーンを撮影しているカメラ自身が移動することができ、その場合、画像のすべての素子は、同じ種類の動作をする。多くの場合、このことは、あるビデオ・フレームと次のビデオ・フレームとの間の全体の変化が、どちらかといえば小さいことを意味する。もちろん、このような変化は、運動の性質により異なる。例えば、動作が速ければ速いほど、あるフレームと次のフレームとの間の変化は大きい。同様に、あるシーンが多数の運動する素子を含んでいる場合には、あるフレームと次のフレームとの間の変化は、１つの素子だけが運動している場合よりも大きい。
【００１２】
ビデオ圧縮方法の基本は、ビデオ・シーケンスの冗長で知覚上関係のない部分を低減することである。ビデオ・シーケンス内の冗長な部分は、空間的な冗長な部分、時間的に冗長な部分、スペクトル的に冗長な部分に分類することができる。「空間的に冗長な部分」は、隣接するピクセル間の相互関連を示すために使用する用語である。「時間的に冗長な部分」という用語は、１つの画像内に現れる対象物が、後続の画像内に現れる対象物に類似していることを表す用語であり、一方、「スペクトル的に冗長な部分」は同じ画像の異なるカラー成分間の相互関連を表す。
【００１３】
単に、画像の所与のシーケンス内の種々の形の冗長な部分を低減するだけでは、普通、十分効率的な圧縮を行うことはできない。それ故、大部分の現在のビデオ・エンコーダは、主観的に最も重要でないビデオ・シーケンスのこれらの部分の品質も低減する。さらに、符号化されたビット・ストリーム自身の冗長な部分も、圧縮パラメータおよび係数の効率的で損失の少ない符号化により削除される。通常、この削除は、「可変長符号化」（ＶＬＣ）と呼ばれる技術により行われる。
【００１４】
ビデオ圧縮方法は、通常、「動作補正時間的予測」を使用する。この方法は、フレーム間の画像の対象物または領域の動きを追跡することにより、シーケンス内の他のフレームからビデオ・シーケンス内のいくつかの（多くの場合、多数の）フレームを「予測」することができる時間的に冗長な部分を削除する方法である。時間的に冗長な部分の削除方法を使用しない圧縮画像は、通常、INTRAまたはＩフレームと呼ばれ、一方、時間的に予測された画像は、INTERまたはＰフレームと呼ばれる。INTERフレームの場合には、予測した（動作補正）画像が十分正確であることはほとんどない。それ故、空間的に圧縮された予測誤り画像は、各INTERフレームとも関連している。多くのビデオ圧縮スキームは、通常、Ｂ画像またはＢフレームと呼ばれる２方向予測フレームも導入する。Ｂ画像は、基準またはいわゆる「アンカー」画像のペア（ＩまたはＰフレーム）の間に挿入され、図５に示すように、アンカー画像の一方または両方から予測される。図を見れば分かるように、シーケンスは、INTRAまたはＩフレーム５０からスタートする。Ｂ画像（全体を参照番号５２で示す）は、通常、順方向予測Ｐ画像５４と比較した場合、圧縮比が高い。図５の場合には、矢印５１ａおよび５１ｂは、２方向の予測プロセスを示し、一方、矢印５３は順方向の予測を示す。Ｂ画像は、アンカー画像としては使用されない、すなわち、Ｂ画像からは他のフレームは予測されない。それ故、Ｂ画像は、ビデオ・シーケンスから捨てられるが、それにより将来の画像の品質は劣化しない。Ｂ画像はＰ画像と比較した場合、圧縮性能を改善するが、構成のために、より大容量のメモリを必要とし、その処理要件はもっと複雑になり、Ｂ画像を使用すると遅延が大きくなる。
【００１５】
時間的予測の上記説明を読めば、所与のフレーム内で画像コンテンツの劣化を招くデータ損失の影響は、時間と共に伝播し、そのフレームから予測される後続のフレームを劣化させることがはっきりわかるだろう。また、ビデオ・シーケンスの符号化は、INTRAフレームからスタートすることも分かる。何故なら、シーケンスのスタート部分では、予測の基準を形成するために、前のフレームを使用することができないからである。しかし、例えば、クライアントの端末装置１８に表示された場合に、フレームの再生順序は、符号化／復号化の順序とは異なる場合があることに留意されたい。それ故、INTRAフレームから符号化／復号化動作がスタートするが、このことは、フレームをINTRAフレームから再生しなければならないことを意味していない。
【００１６】
低いビット速度のビデオ符号化で使用される、異なる画像タイプについての詳細な情報は、１９９８年１１月の、ビデオ技術用の回路およびシステムに関するＩＥＥＥ議事録の、Ｇ．コート、Ｂ．エロール、Ｍ．ギャラント、およびＦ．コセンティニの論文、「H.263＋：低いビット速度でのビデオ符号化」を参照されたい。
【００１７】
現在周知のマルチメディア検索システムおよびビデオ符号化（圧縮）技術の性質に関する上記情報から考えて、通信ネットワークによるビデオ・シーケンスの検索／ストリーミングで重要な問題が発生することを理解されたい。ビデオ・フレームは、通常、あるフレームが他のフレームから予測されるので、圧縮ビデオ・シーケンスは、特に伝送誤りを起こしやすい。ネットワーク伝送誤りによりデータ損失が発生した場合には、ビット・ストリームのコンテンツに関する情報が失われる。伝送誤りの影響は変化する場合がある。ビデオ・フレームの再構成に極めて重要な情報（例えば、画像ヘッダ内に記憶している情報）に損失があると、受信クライアントのところで画像を表示することができなくなる。それ故、全フレームおよびそれから予測したフレームの任意のシーケンスも失われる（すなわち、再構成し表示することができない）。情報の損失が軽度の場合には、画像コンテンツの一部だけが影響を受ける。しかし、劣化したフレームから予測したフレームも影響を受け、次のINTRAフレームが送信され、正しく再構成されるまで、エラーが、画像シーケンス内を時間的かつ空間的に伝播する。この問題は、（例えば、INTRAフレームが10秒毎に送信されるというような）INTRAフレームが頻繁に送信されない非常に低いビット速度通信の場合には、非常に深刻な問題になる。
【００１８】
伝送誤りの性質は、問題の通信ネットワークにより異なる。固定ラインおよび移動電話システムのような回線交換ネットワークの場合には、伝送誤りは、通常、ビットの反転という形をとる。すなわち、例えば、マルチメディア・ストリームのビデオコンテンツを示すデジタル・データは、１が０になったり、０が１になったりするように劣化し、画像コンテンツが誤って表示される結果となる。移動電話ネットワークの場合には、ビット反転誤りは、通常、無線リンク品質の劣化により発生する。
【００１９】
パケット交換データ通信を使用するネットワークの場合には、伝送誤りは、パケット損失の形をとる。このタイプのネットワークの場合には、データ・パケットは、通常、ネットワーク内の混雑のために失われる。ネットワークが混雑すると、ゲートウェイ・ルータのようなネットワーク素子が、データ・パケットを捨てる場合があり、UDP（ユーザ・データグラム・プロトコル）のような信頼性の低い転送プロトコルを使用している場合には、損失パケットは再送信されない。さらに、ネットワークの観点からいえば、数百バイトを含む比較的大きなパケットを送信するほうが有利であり、それ故、損失パケットは、低いビット速度のビデオ・シーケンスのいくつかの画像を含んでいる場合がある。通常、大多数のビデオ・フレームは、時間的に予測されたINTERフレームであり、それ故、１つまたはそれ以上のこのような画像に損失があると、クライアントの端末のところで再構成した場合、ビデオ・シーケンスの品質に重大な影響を与える。１つまたはそれ以上のフレームに損失が生じるばかりでなく、これらのフレームから予測したすべての後続の画像も劣化する。
【００２０】
多くの従来技術の方法は、伝送誤りによる圧縮ビデオ・シーケンスの劣化に関連する問題に取り組んでいる。通常、これらの方法は、「誤り回復」方法とよばれ、通常、２つの分類、すなわち、誤り訂正方法および隠蔽方法に分類される。誤り訂正は、最初の場所に全然誤りが起こらなかったかのように、誤ったデータを完全に回復する機能である。例えば、再送信は、誤り訂正方法であると見なすことができる。誤り隠蔽は、再構成したビデオにおいて、目で見てほとんど誤りに気がつかないように伝送誤りの影響を覆い隠す機能である。誤り隠蔽方法は、通常、３つの分類、すなわち順方向誤り隠蔽、後処理による誤り隠蔽、および会話型誤り隠蔽に分けられる。順方向誤り隠蔽は、伝送誤りが発生しても、受信機がデータを容易に回復することができるように、送信端末が送信データにある程度の冗長性を与える技術である。例えば、送信ビデオ・エンコーダは、圧縮ビデオ信号の予測経路を短縮することができる。一方、後処理による誤り隠蔽は、完全に受信機指向の技術である。これらの方法は、間違って受信したデータの正しい表現を推定しようとする。送信機および受信機は、伝送誤りの影響を最低限度に低減するために協力することができる。これらの方法は、主に受信機からのフィードバック情報に依存している。後処理による誤り隠蔽は、受動的誤り隠蔽と呼ぶこともできる。一方、他の２つの分類は、能動的誤り隠蔽である。本発明は、ビデオ圧縮の際に使用する予測経路を短縮する方法に属する。下記の方法は、パケット交換ネットワークまたは回線交換ネットワークを通して送信される圧縮ビット・ストリームにも同様に適用することができることに留意されたい。基本的データ・ネットワークおよび発生する伝送誤りのタイプの性質は、従来技術の上記説明および本発明の適用の両方に本質的に無関係である。
【００２１】
ビデオ・シーケンスの予測経路を短縮する誤り回復方法は、下記の原理に基づいている。ビデオ・シーケンスがINTERフレームの長いトレーンを含んでいる場合には、伝送誤りによる画像データ損失は、すべての後続の復号化INTERフレームの劣化を引き起こし、エラーは伝播し、復号化ビデオ・ストリームで長時間目で見ることができるようになる。それ故、システムの誤り回復は、ビデオ・ビット・ストリーム内のINTERフレーム・シーケンスの長さを短くすることにより、改善することができる。このような改善は、１．ビデオ・ストリーム内のINTRAフレームの頻度を増大すること、２．Ｂフレームを使用すること、３．基準画像を選択すること、４．ビデオ冗長性符号化と呼ばれる技術を使用すること、により行うことができる。
【００２２】
ビデオ・シーケンス内の予測経路の長さを短縮するための従来技術による方法は、すべて圧縮シーケンスのビット速度を増大する傾向があることを実証することができる。このような傾向は、特に、低いビット速度の伝送チャネル、または使用できる全部の帯域幅を複数のユーザの間で共有しなければならないチャネル内においては、望ましくない影響である。ビット速度の増大は、使用する方法および符号化するビデオ・シーケンスの正確な性質により異なる。
【００２３】
マルチメディア検索システム、および圧縮ビデオ・シーケンスの性質に関連する上記の説明から考えて、知覚画像品質に対する伝送誤りの影響の制限に関連する重要な問題があることを理解することができるだろう。ある種の従来技術の方法は、圧縮ビデオ・シーケンス内で使用する予測経路の長さを制限することによりこの問題を解決しているが、ほとんどの場合、このような方法を使用すると、シーケンスを符号化するのに必要なビット速度が増大する結果になる。それ故、本発明の１つの目的は、ビット速度を許容できる低い速度に維持しながら、伝送誤りへの圧縮ビデオ・シーケンスの回復力を改善することである。
【００２４】
（発明の開示）
上記目的に従い、第１の態様においては、本発明は、圧縮ビデオ・シーケンスを形成するために、ビデオ・フレーム・シーケンスを符号化するための方法を提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマットおよび第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記方法は、第１のビデオ・フレームが、第１の圧縮ビデオ・フレーム・フォーマットに符号化されるべきことを示す、上記第１のビデオ・フレームに関連する第１の表示を識別するステップと、上記第１の表示を第２のビデオ・フレームに関連づけるステップと、上記第１の圧縮ビデオ・フレーム・フォーマットに上記第２のビデオ・フレームを符号化するステップと、上記第２のビデオ・フレームの前に発生するＮ個のビデオ・フレームを含む第１の組のビデオ・フレームを定義するステップと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第１の組のビデオ・フレームを符号化するステップと、上記第２のビデオ・フレームの後に発生するＭ個のビデオ・フレームを含む第２の組のビデオ・フレームを定義するステップと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第２の組のビデオ・フレームを符号化するステップとを含むことを特徴とする。
【００２５】
第２の態様によれば、本発明は、圧縮ビデオ・シーケンスを形成するために、ビデオ・フレーム・シーケンスを符号化するためのビデオ・エンコーダを提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記エンコーダは、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化されるべきことを示す、第１のビデオ・フレームに関連する第１の表示を識別するための手段と、上記第１の表示を第２のビデオ・フレームに関連づけるための手段と、上記第１の圧縮ビデオ・フレーム・フォーマットに上記第２のビデオ・フレームを符号化するための手段と、上記第２のビデオ・フレームの前に発生するＮ個のビデオ・フレームを含む第１の組のビデオ・フレームを定義するための手段と、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第１の組のビデオ・フレームを符号化するための手段と、上記第２のビデオ・フレームの後に発生するＭ個のビデオ・フレームを含む第２の組のビデオ・フレームを定義するための手段と、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第２の組のビデオ・フレームを符号化するための手段とを含むことを特徴とする。
【００２６】
第３の態様によれば、本発明は、本発明の第２の態様のビデオ・エンコーダを含むビデオ・コーデックを提供する。
第４の態様によれば、本発明は、本発明の第２の態様のビデオ・エンコーダを含むマルチメディア・コンテンツ生成システムを提供する。
第５の態様によれば、本発明は、本発明の第２の態様のビデオ・エンコーダを含むマルチメディア端末を提供する。
第６の態様によれば、本発明は、上記端末が無線通信デバイスであることを特徴とする、本発明の第５の態様のマルチメディア端末を提供する。
【００２７】
第７の態様によれば、本発明は、解凍ビデオ・フレーム・シーケンスを形成するために、圧縮ビデオ・フレーム・シーケンスを復号化する方法を提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記方法は、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化される第１のビデオ・フレームに関連する第１の表示を識別するステップと、上記第１のビデオ・フレームを復号化するステップと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの前に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＮ個のビデオ・フレームの第１の組を受信するステップと、Ｎ個のビデオ・フレームの上記第１の組を復号化するステップと、第１の組のフレームに関連する再生情報により第１の組のフレームを再編成するステップと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの後に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＭ個のビデオ・フレームの第２の組を受信するステップと、ビデオ・フレームの上記第２の組を復号化するステップとを含むことを特徴とする。
【００２８】
第８の態様によれば、本発明は、解凍ビデオ・フレーム・シーケンスを形成するために、圧縮ビデオ・シーケンスを復号化するためのビデオ・デコーダを提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。デコーダは、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化される第１のビデオ・フレームに関連する第１の表示を識別するための手段と、上記第１のビデオ・フレームを復号化するための手段と、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの前に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＮ個のフレームの第１の組を受信するための手段と、Ｎ個のビデオ・フレームの第１の組を復号化するための手段と、上記第１の組のフレームに関連する再生情報により上記第１の組のフレームのフレームを順序づけるための手段と、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの後に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＭ個のビデオ・フレームの第２の組を受信するための手段と、ビデオ・フレームの上記第２の組を復号化するための手段とを備えることを特徴とする。
【００２９】
第９の態様によれば、本発明は、本発明の第８の態様のビデオ・デコーダを含むビデオ・コーデックを提供する。
第１０の態様によれば、本発明は、本発明の第８の態様のビデオ・デコーダを含むマルチメディア・コンテンツ検索システムを提供する。
第１１の態様によれば、本発明は、本発明の第８の態様のビデオ・デコーダを含むマルチメディア端末を提供する。
第１２の態様によれば、本発明は、上記端末が無線通信デバイスであることを特徴とする、本発明の第１１の態様のマルチメディア端末を提供する。
【００３０】
第１３の態様によれば、本発明は、圧縮ビデオ・シーケンスを形成するために、ビデオ・フレーム・シーケンスを符号化するためのビデオ・エンコーダとしてコンピュータを動作させるためのコンピュータ・プログラムを提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記コンピュータ・プログラムは、上記第１のビデオ・フレームを上記第１の圧縮ビデオ・フレーム・フォーマットに符号化すべきことを示す、第１のビデオ・フレームに関連する第１の表示を識別するためのコンピュータ実行コードと、上記第１の表示を第２のビデオ・フレームに関連づけるためのコンピュータ実行コードと、上記第１の圧縮ビデオ・フレーム・フォーマットに上記第２のビデオ・フレームを符号化するためのコンピュータ実行コードと、上記第２のビデオ・フレームの前に発生するＮ個のビデオ・フレームを含む第１の組のビデオ・フレームを定義するためのコンピュータ実行コードと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第１の組のビデオ・フレームを符号化するためのコンピュータ実行コードと、上記第２のビデオ・フレームの後に発生するＭ個のビデオ・フレームを含む第２の組のビデオ・フレームを定義するためのコンピュータ実行コードと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第２の組のビデオ・フレームを符号化するためのコンピュータ実行コードとを含むことを特徴とする。
【００３１】
第１４の態様によれば、本発明は、圧縮ビデオ・フレーム・シーケンスを形成するために、圧縮ビデオ・フレーム・シーケンスを復号化するためのビデオ・デコーダとしてコンピュータを動作させるためのコンピュータ・プログラムを提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記コンピュータ・プログラムは、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化される第１のビデオ・フレームに関連する第１の表示を識別するためのコンピュータ実行コードと、上記第１のビデオ・フレームを復号化するためのコンピュータ実行コードと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの前に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＮ個のフレームの第１の組を受信するためのコンピュータ実行コードと、Ｎ個のビデオ・フレームの上記第１の組を復号化するためのコンピュータ実行コードと、上記第１の組のフレームに関連する再生情報に従って上記第１の組のフレームのフレームを順序づけるためのコンピュータ実行コードと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの後に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＭ個のビデオ・フレームの第２の組を受信するためのコンピュータ実行コードと、ビデオ・フレームの上記第２の組を復号化するためのコンピュータ実行コードとを含むことを特徴とする。
【００３２】
第１５の態様によれば、本発明は、本発明の第１３および１４の態様のコンピュータ・プログラムを提供する。
【００３３】
他の態様によれば、本発明は、圧縮ビデオ・フレーム・シーケンスを形成するために、ビデオ・フレーム・シーケンスを符号化するためのビデオ・エンコーダとしてコンピュータを動作させるためのコンピュータ・プログラムを含む記憶媒体を提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記記憶媒体は、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化されるべきことを示す、第１のビデオ・フレームに関連する第１の表示を識別するためのコンピュータ実行コードと、上記第１の表示を第２のビデオ・フレームに関連づけるためのコンピュータ実行コードと、上記第１の圧縮ビデオ・フレーム・フォーマットに上記第２のビデオ・フレームを符号化するためのコンピュータ実行コードと、上記第２のビデオ・フレームの前に発生するＮ個のビデオ・フレームを含む第１の組のビデオ・フレームを定義するためのコンピュータ実行コードと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第１の組のビデオ・フレームを符号化するためのコンピュータ実行コードと、上記第２のビデオ・フレームの後に発生するＭ個のビデオ・フレームを含む第２の組のビデオ・フレームを定義するためのコンピュータ実行コードと、上記第２の圧縮ビデオ・フレーム・フォーマットに上記第２の組のビデオ・フレームを符号化するためのコンピュータ実行コードとを含むことを特徴とする。
【００３４】
他の態様によれば、本発明は、解凍ビデオ・フレーム・シーケンスを形成するために、圧縮ビデオ・フレーム・シーケンスを復号化するためのビデオ・デコーダとして、コンピュータを動作させるためのコンピュータ・プログラムを含む記憶媒体を提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマット、および第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記記憶媒体は、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化される第１のビデオ・フレームに関連する第１の表示を識別するためのコンピュータ実行コードと、上記第１のビデオ・フレームを復号化するためのコンピュータ実行コードと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの前に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＮ個のフレームの第１の組を受信するためのコンピュータ実行コードと、Ｎ個のビデオ・フレームの第１の組を復号化するためのコンピュータ実行コードと、第１の組のフレームに関連する再生情報により第１の組のフレームを順序づけるためのコンピュータ実行コードと、上記解凍ビデオ・シーケンス内の上記第１のビデオ・フレームの後に挿入するために、上記第２の圧縮ビデオ・フレーム・フォーマットのＭ個のビデオ・フレームの第２の組を受信するためのコンピュータ実行コードと、ビデオ・フレームの上記第２の組を復号化するためのコンピュータ実行コードとを含むことを特徴とする。
【００３５】
他の態様によれば、本発明は、圧縮ビデオ・シーケンスを形成するために、ビデオ・フレーム・シーケンスを符号化するための方法を提供する。上記圧縮ビデオ・シーケンスは、少なくとも第１の圧縮ビデオ・フレーム・フォーマットおよび第２の圧縮ビデオ・フレーム・フォーマットに符号化されたフレームを含み、上記第１の圧縮ビデオ・フレーム・フォーマットは、非時間的予測フォーマットであり、上記第２の圧縮ビデオ・フレーム・フォーマットは、時間的予測フォーマットである。上記方法は、上記第１のビデオ・フレームが、上記第１の圧縮ビデオ・フレーム・フォーマットに符号化されるべきことを示す、第１のビデオ・フレームに関連する第１の表示を識別するステップと、上記圧縮ビデオ・シーケンス内の予測経路の長さを短縮するように上記第１の表示を第２のビデオ・フレームに関連づけるステップとを含むことを特徴とする。
【００３６】
本発明のビデオ符号化方法は、従来の方法により符号化したビット・ストリームよりも大きな誤り回復力を持つ符号化されたビデオ・データ・ストリームを提供する。より詳細に説明すると、本発明は、時間的予測画像の劣化を引き起こすデータ損失の影響が、従来技術のビデオ・コーデックと比較した場合、伝播する範囲が狭いビデオ符号化／復号化システムを提供する。本発明によれば、時間的予測フレームの劣化は、ビデオ・シーケンス内の予測経路を短縮することにより軽減する。このようなフレームの劣化の軽減は、INTRA符号化フレームの挿入を効果的に遅らせることにより行われる。このようなフレームの劣化の軽減は、例えば、周期的なINTRAフレーム要求の後で、遠隔地の端末からのINTRAフレーム更新要求またはシーン・カットにより行うことができる。本発明によれば、周期的なINTRA要求、INTRA更新要求、またはシーン・カットに関連するフレームのような、INTRAフォーマットに符号化されるフレームは、それ自身はINTRAフォーマットに符号化されない。上記符号化を行う代わりに、ビデオ・シーケンス内で後に発生するフレームは、INTRAフォーマットに符号化するために選択される。好適には、（「実際の」INTRAフレームと呼ばれる）INTRAフォーマットに実際に符号化されたフレームは、周期的なINTRA要求、INTRAフレーム要求またはシーン・カットの間のほぼ中央に位置するように選択することが好ましい。実際のINTRAフレームの前に発生するフレームは、実際のINTRAフレームからスタートして、逆方向に時間的予測により符号化される。一方、その後で発生するこれらのフレームは、順方向の時間的予測により符号化される。本発明の好適な実施形態の場合には、反対方向に予測されたこれらフレームは、INTER（Ｐフレーム）フォーマットに符号化される。他の実施形態の場合には、Ｂフレーム・フォーマットに符号化されたフレームによる反対方向の予測が使用される。
【００３７】
本発明は、周期的なINTRA要求、INTRAフレーム更新要求、またはシーン・カットに関連するフレーム自身がINTRAフォーマットに符号化される従来のビデオ符号化方法と比較した場合、実質的に改善された誤り回復を提供する。より詳細に説明すると、本発明を使用すれば、伝送誤りによるフレーム損失の百分率が有意に低減する。予測経路の長さを短縮することにより誤り回復を改善することを目的とする従来の方法と比較した場合、本発明は、ビット速度を著しく増大させない。
【００３８】
本発明は、例えば、ビデオが、UDPのような信頼性の低いパケットをベースとする転送プロトコルの一番上に流れるマルチメディア検索システムで実行することができる。本発明は、また、リアルタイム・ビデオ電話の分野で実行することができる。本発明は、通信リンクの少なくとも一部が、無線チャネルで形成されている移動通信分野に特に適している。無線通信リンクは、ビット誤り率が比較的高い傾向があり、また帯域幅が制限されているので、本発明による高い誤り回復力が特に有利である。特に、ビット速度が著しく増大しないからである。
【００３９】
ネットワークの正確な性質、接続のタイプ、および送信プロトコルは、本発明の実行のために重要なものではないことをさらに強調しておきたい。ネットワークは、固定ライン（PSTN）および、通信リンクの少なくとも一部が無線チャネルにより形成されている移動体通信ネットワーク（PLMN）の両方を含むことができる。ネットワーク内のデータ伝送は、完全にパケットをベースとするものにすることもできるし、完全に回線交換にすることもできるし、または回線交換データ伝送およびパケット交換データ伝送の両方を含むことができる。例えば、ネットワークは、回線交換データ伝送が使用されている他のネットワーク素子に接続しているパケットをベースとするデータ伝送を使用しているいくつかの素子（例えば、コア・ネットワーク）を含むことができる。このタイプのシステムの一例としては、ネットワークの少なくとも一部が回線交換送信に依存することができる現在提案されているUMTS第三世代移動電話ネットワークがある。
【００４０】
データ・ストリームに影響を与える伝送誤りの正確な性質も、本発明の適用とは無関係である。さらに、本発明の暗号化、復号化および再生方法は、予め記憶しているオンデマンド・ビデオ、および生の（リアルタイムの）ビデオ圧縮にも使用することができる。本発明は、上記のようなビデオ・シーケンス内の予測経路の長さを短縮するための従来の方法を含む従来技術の誤り訂正、隠蔽および回復方法とは別に、または一緒に使用することができることを重ねて強調しておきたい。
【００４１】
（発明を実施するための最良の形態）
本発明およびその利点をもっとよく理解してもらうために、図７および図８を比較しながら、本発明のビデオ符号化方法の好適な実施形態について説明するが、これは単に例示としてのものに過ぎない。図７は、従来の方法により構成されている圧縮ビデオ・シーケンスであり、図８は、本発明の方法により構成された圧縮ビデオ・シーケンスである。両図のシーケンスは、同じ画像コンテンツを示し、より長いシーケンスのビデオ形成部分のいくつかの連続フレームを含む。既述のように、INTRAフォーマットに符号化したフレームは、総称的に参照番号５０で表し、INTERフレームは参照番号５４で表す。INTERフレームを構成する順方向予測プロセスは、従来通り、参照番号５３で表す。両シーケンスの頭の部分には、シーン・カット７０が位置している。以下の説明においては、ビデオ・シーケンス内のシーン・カットに関連して、本発明の方法の適用について重点的に説明するが、本発明は、同じように、従来通り、シーン・カット、遠隔地の端末からのINTRAフレーム要求、または周期的なINTRAフレーム・リフレッシュ動作を含むが、これらに限定されない、INTRAフォーマットへのフレームの符号化が行われる任意の状況に適用できることを理解されたい。
【００４２】
図７の一連のフレームは、INTRAフレーム５０が、シーケンス内のシーン・カット７０の直後に挿入される従来の符号化スキームを示す。シーン・カットが発生すると、以降の画像コンテンツは、シーン・カット以前の画像コンテンツとはかなり異なる。それ故、前のフレームから順方向に予測されたINTERフレームとして、シーン・カット直後にフレームを符号化することはできないか、実行不能である。それ故、この従来の符号化スキームの場合には、INTRAフレーム５０（ｌ１）は、シーン・カットの直後に挿入される。次に、例えば、次のシーン・カット、周期的なINTRA要求、またはINTRAフレーム更新要求（７０）が発生するまで、以降のフレームが、そのINTRAフレームから順方向に予測（INTER符号化）される。
【００４３】
すでに説明したように、本発明の方法は、図８に示すように、INTRAフレームの挿入を遅らせる方法に基づいている。本発明によれば、INTRAフレームは、ビデオ・ストリーム内に直ちに挿入されるのではなく、ビデオ・シーケンス内で後に発生したフレームが、選択され、INTRAフォーマットに符号化される。図８においては、このフレームをｌ１で示す。図８を見れば分かるように、シーン・カット７０とｌ１との間のフレーム（図８のＰ２およびＰ３）は、矢印８０で示すように、ｌ１とは反対方向にINTERフレームとして予測される。それ故、これらフレームは、ｌ１の復号化が行われる前には復号化することができない。何故なら、前の画像コンテンツを復号化するには、それより前にｌ１を再構成しておかなければならないからである。このことは、本発明によるビデオ・シーケンスの再生中に必要な最初のバッファリング遅延は、通常、シーン・カットとその後のINTRAフレームとの間の時間より、長くなければならないことを意味する。
【００４４】
INTERフレームＰ５を復号化できるようにするためには、どれだけの数のフレームを連続的に送信しなければならないかを検討することにより、本発明の方法の主な利点を実証することができる。図７の従来のフレーム順序付けスキームを使用した場合には、Ｐ５の復号化を成功させるには、ｌ１、Ｐ２、Ｐ３、Ｐ４およびＰ５を正しく送信し、復号化しなければならない。それ故、例えば、フレームｌ１内のような、シーケンス内で早期にデータ損失（例えば、パケット損失）が発生すると、復号化した画像コンテンツにエラーが発生し、このエラーは、Ｐ５までシーケンスを通して広がる。本発明の方法の場合には、Ｐ５の復号化を成功させるには、ｌ１、Ｐ４およびＰ５だけを正しく送信し、復号化しさえすればよい。すなわち、本発明の方法を使用した場合には、画像シーケンス内の予測経路は、効果的に短縮し、その結果、フレームＰ５が正しく復号化される可能性が高くなる。さらに、シーケンス内のエラーの時間的伝播が減少する。例えば、フレームＰ２内でのような、シーケンス内の早期のデータ損失によりフレームＰ２およびＰ３の復号化した画像コンテンツにエラーが発生する。
【００４５】
以下に本発明のビデオ符号化方法について詳細に説明する。本発明の方法により実行したビデオ・エンコーダの機能を、図９のその動作内容９０を示す、従来のビデオ・エンコーダの動作と比較し、対比する。
従来技術のビデオ・エンコーダ９０の場合には、符号化されていない生の画像は、最初、フレーム・グラバーまたは生のビデオ・フレームを記憶しているコンピュータ・ハードドライブのような記憶デバイスに接続しているビデオ・カメラからエンコーダに送られる。他の方法としては、エンコーダは、ビデオ・ソースまたは記憶デバイスに制御コマンドを発することにより、圧縮するための新しいフレームを要求することができる。図９のステップ９１は、圧縮するための新しいビデオ・フレームの入手プロセスを示す。符号化されていないフレームがエンコーダに送られる速度は、固定速度であっても、可変速度であってもよい。
【００４６】
通常、ビデオ・シーケンスのビット速度は、フレームをスキップすることにより、すなわち、それらフレームをビデオ・シーケンスから省略することにより遅くすることができる。特定のフレームを符号化すべきか否かの決定は、ビデオ・エンコーダのビット速度制御アルゴリズムにより行われる。図９のステップ９２は、そのプロセスを示す。ビット速度制御ロジックが、所与のフレームを符号化すべきであると決定した場合には、従来のビデオ・エンコーダは、次に、そのフレームを符号化するモードを決定する。ステップ９４は、この意志決定プロセスを示す。周期的INTRAリフレッシュが要求された場合、INTRAフレーム更新要求を遠隔端末から受信した場合、またはシーン・カットが発生した場合には、ステップ９８に示すように、フレームは、INTRAフォーマットに符号化される。そうでない場合には、ステップ９６において、フレームはINTERフレーム・フォーマットに符号化される。分かりやすくするために、この説明は、いくぶん簡単にしてあり、他のフレーム・タイプ、すなわち、２方向予測Ｂフレームの処理は、ここでは説明しない。しかし、このように説明を簡単にしたが、それは従来技術のエンコーダの動作を理解するのには支障はない。
【００４７】
比較のために、図１０に本発明のビデオ符号化方法の手続要素を示す。上記の従来技術のビデオ・エンコーダと同等の機能を行う、本発明の方法の素子には、図９の参照番号と同じ参照番号を使用している。
最初に、符号化していない生のビデオ・フレームが、エンコーダに送られるか、またはエンコーダが、圧縮するための新しいフレームを要求することができる。これは、図１０のステップ９１で表される。次に、エンコーダは、画像コンテンツを、例えば、シーン・カット、周期的INTRAフレーム・リフレッシュ・インターバルの時間切れ、または遠隔端末からのINTRAフレーム更新要求の受信の結果として画像コンテンツをINTRAフォーマットに符号化すべきかどうかを決定する（ステップ９４）。本発明によれば、エンコーダが、何らかの理由で、INTRAフレームが必要であると決定した場合には、エンコーダは、図１０のステップ１０１に示すように、このようなINTRAフレームが必要であることを記録する。INTRAフレームが必要であることを示すこのような記録は、例えば、そのフレームに対してフラッグをセットし、フレーム・バッファ内に、そのフラッグを記憶することにより行うことができる。INTRAフレームに対する要求を表示する方法については、以下にさらに詳細に説明する。しかし、INTRA要求を表示する正確な方法は、本発明を実行するのに重要なものではないことを理解されたい。次に、フレームは、バッファされる（１０２）。
【００４８】
本発明のエンコーダは、圧縮の前に生の画像データを記憶するために使用するバッファを維持する。都合のよいことに、バッファは、時間の長さ（Ｔ）に対応する多数の生の画像フレームを収容するのに十分な容量を持っている。いくつかのいわゆる「メタ」データは、画像データの各フレームに関連している。メタデータは、符号化すべきフレームに関する情報を供給し、すでに説明したように、上記要求が行われた場合には、INTRAフレーム要求の表示を含む。INTRAフォーマットに符号化すべきフレームに対して、メタデータは、（基準フレームが前に符号化したフレームでない場合には）、動き補正のために使用する基準フレームの数を含むことができる。すべてのフレームに対するメタデータは、その中に圧縮されていないビデオ・フレームを符号化するための順序を含む圧縮順序番号ＣＯを含む。各入力フレームは、バッファに記憶される。
【００４９】
最初に、符号化をスタートする前に、バッファが空にされる。符号化がスタートすると、時間の長さＴに対応する多数のフレームを含むまで、バッファがフレームで満たされる（１０２）。バッファが満杯になった時を決定するために、バッファが監視される（ステップ１０３）。バッファが満杯になると、「最も古い」フレームが、すなわち、バッファに最初にロードされたフレームが、バッファから除去される。図１０のステップ１０４は、この動作を示す。エンコーダは、例えば、メタデータに対応するフレームをチェックし、INTRA要求フラッグがセットされているかどうかを決定することにより、問題のフレームがINTRAフレーム要求に関連しているかどうかを決定する（ステップ１０５）。フレームがINTRA要求に関連していない場合には、エンコーダのビット速度制御アルゴリズムは、フレームをスキップすべきかどうかを決定し（ステップ９２）、またはフレームをINTERフレームとして符号化すべきかどうかを決定する（ステップ１０７）。フレームがスキップされ、そのフレームが、前のフレーム以外のフレームを動き補正用の基準として使用すべきであることを示す表示を含んでいる場合には、その表示がバッファ内で次のフレームを記載しているメタデータにコピーされる。フレームをスキップしないという決定がなされた場合には、そのフレームは、シーケンス内の前のフレームを基準として、またはメタデータにより動き補正基準として表示されたものにより、INTERフォーマットに符号化される（ステップ１０７）。
【００５０】
バッファから検索したフレームが、INTRAフレーム要求に関連している場合には、全体を参照番号１０８で示す、INTRAフレーム処理手順が実行される。図１１は、ステップ１０８の手続要素の詳細図である。現在のINTRAフレーム要求が、時点Ｔ１のところで発生する。INTRAフレーム処理手順の第１のステップは、次のINTRAフレーム要求、すなわち、現在処理されているものの次のINTRAフレーム要求の位置を知るために、フレーム・バッファの探索を行うことである。図１１のステップ１１０は上記探索を示す。次のINTRA要求の発生時間Ｔ２は、その関連メタデータから決定される。次に、INTRAフォーマットに符号化される実際のフレームが、２つの要求されたINTRAフレームからの違いがほぼ等しくなるように決定される。すなわち、現在のINTRA要求が、その発生時間がＴ１であるフレームと関連している場合には、Ｔ３−Ｔ１がほぼＴ２−Ｔ３に等しくなるように、バッファからその発生時間がＴ３であるフレームが選択される。この新しく発見されたフレームが、INTRAフォーマットへの符号化のために選択される。図１１の参照番号１１２は、今説明したこのプロセスを示す。本発明によれば、INTRAフォーマットに実際に符号化されるフレーム（以後「実際の」INTRAフレームと呼ぶ）は、最初のINTRA符号化要求には関連していないが、ビデオ・シーケンス内で後で発生するある他のフレームに関連する。バッファがINTRAフレーム要求に関連する他のフレームを含んでいない場合には、INTRAフォーマットに符号化される実際のフレームは、その発生時間Ｔ３と時間Ｔ１におけるINTRA要求との間の時間差が、Ｔ３とバッファの最後のフレームとの間の時間差に、ほぼ等しくなるように選択される。
【００５１】
次に、ステップ１１４において、INTRAフォーマットに符号化される実際のフレームがバッファから除去され、実際のINTRAフレーム以前のフレームの順番が反対になる。実際のINTRAフレームの直前および直後のフレームには、これらフレームが動き補正用の基準として、実際のINTRAフレームを使用すべきとの表示を含むようにマークが付けられる。最後に、INTRAフォーマットに符号化するために選択されたフレームが、INTRAフレームとして符号化され（ステップ１１６）、またＴ２に対応するフレームまでのフレームであって、Ｔ２に対応するフレームを含まないフレームが、動き補正時間的予測符号化により符号化される。実際のINTRAフレーム以前に発生するこれらのフレームは、実際のINTRAフレームからスタートして、逆方向に符号化され、一方、実際のINTRAフレーム以後に発生するこれらのフレームは、順方向に符号化される。実際のINTRAフレームに先行するフレームの順序を反対にしても、必ずしも、バッファの物理的な再配置をしなくてもよいことを理解されたい。以下にさらに詳細に説明するように、バッファ内でのフレームの効果的な反転は、各フレームに割り当てられた圧縮順序（ＣＯ）番号により行うことができる。
【００５２】
１つの例を考えると、上記INTRAフレーム処理手順をもっとよく理解することができる。この場合、ビデオ捕捉／検索システムのビデオ・エンコーダは、本発明の方法を実行するために設計されているものと仮定する。エンコーダは、圧縮していないフォーマットのビデオ・データを５秒間（＋１フレーム）記憶することができるバッファを含む。エンコーダは、毎秒２５フレームの一定の速度で、ビデオ・フレーム・ソースにより圧縮していない、（すなわち、生の）ビデオ・フレームの供給を受ける。それ故、連続しているフレーム間の時間差は、一定で、４０ミリ秒である。表１は、シーケンス内の任意の瞬間におけるバッファのコンテンツを示す。
【００５３】
【表１】

表１においては、所与の生のビデオ・フレームの再生／捕捉時間は、時間ｔを基準にしてミリ秒で表される。すでに説明したように、メタデータは、フレームを圧縮し、解凍する順序を示すために使用される圧縮順序番号（ＣＯ）を含む、圧縮していないビデオ・フレームに関する追加情報を記憶するために使用される。
【００５４】
この例で考慮の対象にする特定のビデオ・シーケンスにおいては、シーン・カットは存在しないで、５秒毎に周期的なINTRAリフレッシュが要求される。関連INTRAフレーム要求表示は、圧縮していない各ビデオ・フレームと一緒に供給されるメタデータ内に含まれている。表１を見れば分かるように、この例の目的のために、最初のINTRA要求は、時間ｔにおいて発生するものと仮定する。INTRA要求は５秒毎に行われるので、次のこのような要求は、ｔ＋5000msの時点で行われる。圧縮していないビデオ・フレームと一緒に供給されるメタデータにより、エンコーダは、INTRA要求が何時おこなわれるのかを判断することができる。
【００５５】
本発明の方法を使用する場合には、エンコーダは、INTRA要求に直接関連するフレームにはINTRA符号化を適用しないが、現在のINTRA要求と後続のINTRA要求との間の時間のほぼ中間で、INTRAフォーマットに符号化されるフレームを選択する。必ずしも、連続するINTRA要求間の正確に等距離のフレームを選択できるわけではない。何故なら、この選択は、連続しているINTRA要求間の時間的間隔、およびビデオ・シーケンスのフレーム速度により異なるからである。本発明の、フレームが40msの間隔で分離していて、INTRA要求が5000msの一定の間隔で発生するこの例の場合には、INTRAフォーマットに符号化するのに最も適しているフレームは、ｔ＋2480ms、またはｔ＋2520msにおいて発生するフレームのどちらかである（表１参照）。それ故、エンコーダは、t＋2480msまたはt＋2520msで発生するフレームを実際のINTRAフレームとして選択することができる。これら２つのフレームのどちらかは、INTRAフォーマットへの符号化のための、同じ程度に適当な選択とみなすことができる。実際のINTRAフレームの選択を決定するために使用する基準は、方法の実行に従って変化するが、この場合には、t＋2480msにおいて発生するフレームを、実際のINTRAフレームとして選択するものと仮定する。
【００５６】
都合のよいことに、エンコーダは、圧縮順序（ＣＯ）番号をバッファ内の圧縮していないフレームに割り当てる。バッファ内のすべてのフレームは、実際のINTRAフレーム、すなわち、INTRAフォーマットに符号化するためにすでに選択したフレームを示す圧縮順序番号がつけられる。好適には、この圧縮順序情報は、表２に示すように、各フレームに関連するメタデータ内に記憶するのが好ましい。
【００５７】
【表２】

【００５８】
エンコーダ・バッファ内の実際のINTRAフレームに先行する圧縮していないフレームには、バッファ内で早期に発生するフレームに大きな圧縮順序番号がつけられるように、圧縮順序番号が順次割り当てられる。実際のINTRAフレームには、圧縮順序番号、ＣＯ＝０が割り当てられる。それ故、現在説明している例の場合、実際のINTRAフレーム直前のフレーム（すなわち、t＋2440msにおいて発生するフレーム）には、圧縮順序番号ＣＯ＝1が割り当てられる。その前のフレームには、圧縮順序番号ＣＯ＝2が割り当てられる。そのフレームの前のフレームには、圧縮順序番号ＣＯ＝3が割り当てられる。以下同様。現在説明している例の場合には、この圧縮順序番号割当てスキームによれば、バッファ内の最初のフレームには、圧縮順序番号ＣＯ＝62が割り当てられる。当業者であれば、この圧縮順序番号割当てスキームを使用すれば、実際のINTRAフレームに先行するフレームを、最初のINTRA要求に関連したフレーム（すなわち、時間ｔにおいて発生するフレーム）から順方向にではなく、実際のINTRAフレームから逆方向に予測すべきであることをはっきりと示していることを理解することができるだろう。
【００５９】
実際のINTRAフレーム直後のフレーム（すなわち、t＋2520msにおいて発生するフレーム）の圧縮順序番号、および以降のフレームの圧縮順序番号は、実際のINTRAフレームに先行するシーケンス内の最初のフレームの圧縮順序番号から順番につけられる。それ故、現在説明している例の場合には、エンコーダのフレーム・バッファ内の実際のINTRAフレームの直後に発生する圧縮していないビデオ・フレームには、圧縮順序番号ＣＯ＝63が割り当てられ、次のフレームには、圧縮順序番号ＣＯ＝64が割り当てられ、次のフレームには圧縮順序番号ＣＯ＝65が割り当てられる。以下同様。さらに、本発明の場合には、実際のINTRAフレームの直後のフレームには、その基準画像（そこから予測が行われるフレーム）が、前の圧縮順序番号を持つフレームではなく、圧縮順序番号ＣＯ＝０を持つ実際のINTRAフレームになるように、圧縮順序番号が割り当てられる。都合のよいことに、この表示は、実際のINTRAフレームの直後に発生するフレームに関連するメタデータ内に収容される。現在説明している例の場合には、このことは、圧縮順序番号ＣＯ＝63を持つ実際のINTRAフレームの直後のフレームは、圧縮順序番号ＣＯ＝62を持つフレームから予測されるのではなく、圧縮順序番号、ＣＯ＝０を持つ実際のINTRAフレームから予測されることを意味する。
表２は、圧縮順序番号割当て後のビデオ・バッファの内容を示す。
【００６０】
次に、エンコーダは、バッファから実際のINTRAフレームを除去し、前に割り当てられた圧縮順序番号に従って、バッファを再編成し、選択した（すなわち、実際の）INTRAフレームを符号化する。
バッファの物理的再編成に対する要件は、使用するバッファのタイプにより異なることを強調しておきたい。エンコーダがバッファを探索し、ランダムにそのコンテンツにアクセスすることができる（すなわち、バッファは、ランダム・アクセス・バッファである）場合には、圧縮順序番号が示す順序で符号化するために直接フレームを選択することができ、その場合、物理的な再編成を行う必要はない。一方、この例の場合に仮定したように、バッファには先入れ先出し方式で容易にアクセスすることができ、圧縮順序番号によりフレームを物理的に再編成するのが得策である。
【００６１】
実際のINTRAフレームは、任意の適当な方法で符号化することができる。符号化方法の正確な選択は、例えば、後で圧縮ビデオ・データを送信するために使用する通信チャネルの特性により異なる。使用できるビット速度は、符号化方法の選択を定めることができる１つの可能な基準である。例えば、固定ライン・ビデオ検索またはビデオ電話システムの場合には、使用可能なp×64kbit／sのビット速度で、通信システムで最適な性能を供給するように特に設計されている、ITU-T勧告H.261により選択した（実際の）INTRAフレームを符号化するのが適している。他の方法としては、ビデオ・データをマルチメディア・ビット・ストリームに含ませたいなら、ＭＰＥＧ４規格による符号化の方が適している。非常に遅いビット速度の通信を、特に無線通信チャネルを通して行う場合には、別の代替ビデオ符号化スキームとして、ITU-T勧告H.263を使用することもできる。
【００６２】
表３は、上記の再編成動作後のバッファの内容を示す。
【表３】

【００６３】
（t＋5000に対応するフレームを除く）バッファ内の残りのフレームは、INTERフォーマットに符号化される。フレームが順次予測されるシーケンスは、その圧縮順序番号および関連メタデータにより供給される基準画像選択に関する情報により決定される。ここでもまた、使用するINTER符号化の正確な詳細は、本発明の方法の適用にとって重要ではない。ビデオ・フレームが符号化される順序は、その割り当てられた圧縮順序番号によって決まるので、符号化プロセスは下記のように行われる。圧縮順序番号ＣＯ＝1からＣＯ＝62までの圧縮順序番号を持つフレームは、実際のINTRAフレーム（圧縮順序番号ＣＯ＝0）からスタートして、相互に順次予測される。すなわち、圧縮順序番号ＣＯ＝1を持つフレームは、基準画像として実際のINTRAフレームによりINTER符号化され、圧縮順序番号ＣＯ＝2を持つフレームは、その圧縮順序番号がＣＯ＝1である復号化したINTER符号化フレームから予測される。以下同様。このプロセスは、順方向予測プロセスのように見える。しかし、圧縮していないフレームには、逆方向に圧縮順序番号が割り当てられるので、フレームＣＯ＝1からＣＯ＝62は、実際のINTRAフレームから逆の順序で効果的に予測される。
【００６４】
このプロセスは、圧縮順序番号ＣＯ＝63まで継続して行われる。このフレームは、実際のINTRAフレーム（ＣＯ＝0）から順方向に予測したINTERフォーマットに符号化すべきであり、フレームＣＯ＝62から予測すべきではない。本発明の方法の場合には、これはフレームＣＯ＝63に関連するメタデータ内に表示される。このメタデータは、フレームＣＯ＝63のINTER予測符号化の際に使用する基準画像の圧縮順序番号が、ＣＯ＝０、すなわち、実際のINTRAフレームであることを表示する。予測の原点がフレームＣＯ＝0にリセットされると、エンコーダは、順次バッファ内の残りの圧縮していないビデオ・フレーム、（圧縮順序番号ＣＯ＝63からＣＯ＝124を持つフレーム）を継続的に符号化する。すなわち、フレームＣＯ＝63が、その基準画像としてのフレームＣＯ＝0（すなわち、実際のINTRAフレーム）により、INTERフォーマットに符号化され、フレームＣＯ＝64が、ＣＯ＝63から予測され、フレームＣＯ＝65がフレームＣＯ＝64から予測される。以下同様。
【００６５】
上記説明においては、本発明のビデオ符号化方法を、ビデオ・シーケンスが、主に２つのタイプのビデオ・フレーム、すなわち、非時間的予測INTRAフレーム、および時間的予測INTRAフレームに基づいて符号化された例により、本発明を説明した。しかし、当業者であれば、本発明の方法は、他のタイプのビデオ・フレームを含むように広く適用することができることを理解されたい。より詳細に説明すると、順方向、逆方向、または順方向および逆方向の両方向に時間的予測を使用するＢ画像を、本発明と一緒に使用することができる。すなわち、実際のINTRAフレーム、または実際のINTRAフレームから逆方向に予測した、INTERフォーマット・フレーム中の任意のフレームをＢ画像の構成のためのアンカー画像として使用することができる。Ｂ画像は、順方向の予測、逆方向の予測またはこれら２つの予測の組合わせにより構成することができる。同様に、また、Ｂ画像を実際のINTRAフレームから順方向に予測した、INTERフォーマット・フレームを含むシーケンスの一部に含ませることもできる。
【００６６】
今説明したプロセスにより、ビデオ・データの各フレームを、選択した（実際の）INTRAフレームを参照して、簡単な方法で符号化することができる。しかし、その割り当てられた圧縮順序番号によるビデオ・フレームの符号化は、符号化プロセスの実行を容易にするが、フレームを復号化する際に問題が起こる。より詳細に説明すると、ビデオ・フレームは、再生のための正しい順序で符号化することができない。表３の再生／捕捉時間を見れば、このことを理解することができるだろう。それ故、フレームが符号化され、その後で、この順序でデコーダに通信チャネルを通して送信されると、デコーダは、フレームが正しい順序で必ず再生されるように、その意図する再生時間によりフレームを再編成する。
【００６７】
このプロセスについては、本明細書中に以下にさらに詳細に説明するが、ここでは、情報は、デコーダにおける必要な再生時間に関連する各フレームに関連していることに留意されたい。上記情報は、画像データ自身および各フレームの圧縮順序番号を含むメタデータと一緒にデコーダに送信される。あるパケット交換ネットワークの場合には、データ・パケットは、これらデータ・パケットが送信されたのと同じ順序で受信機に到着しない場合があることに留意されたい。ＲＴＰ（信頼性の高い送信プロトコル）のようなある種の送信プロトコルは、データ・パケットが送信される順序、いわゆる「シーケンス番号」の表示を供給する。これにより、データ・パケットを、受信機においてその正しい順序に組み立てることができる。このタイプのシステムの場合には、ビデオ・データと一緒に圧縮順序番号を送信する必要は全然ない。何故なら、ビデオ・フレームが符号化された順序を受信データ・パケットのシーケンス番号から推定することができるからである。しかし、送信プロトコルによりシーケンス番号が供給されないシステムの場合には、圧縮順序についての情報を送信する必要がある。各ビデオ・フレームの予定再生時間に関する情報は、ビデオ・データを通信リンクを通してビデオ・データを送信する際に使用するファイルまたは多重化／送信フォーマット・ヘッダ内に容易に組込むことができ、またビデオ符号化フォーマット／構文自身内に含ませることができる。
【００６８】
本発明は、本質的に、INTRA要求後のINTRAフレームの挿入を遅らせるので、INTRAフォーマットに実際に符号化されるフレームの前に、逆方向予測INTERフレームを表示しなければならない。本発明の方法の他の実施形態の場合には、図１４に示すように、Ｂフレームを使用することができる。この方法は、圧縮ビデオ構文または周囲のファイルまたは送信フォーマットが、以降のアンカー・フレーム（ｌ１）の前に、逆の順序で予測したフレーム（例えば、図８のINTER符号化フレームＰ２およびＰ３）の再生ができないような状況の場合には有利である場合がある。通常、例えば、ITU-T勧告H.263のように、Ｂフレームは、逆方向、順方向または両方向の予測をサポートする。それ故、本発明の符号化方法は、以降のアンカー・フレーム（ｌ１）から、逆方向に予測されるＢフレームにより実行することができる。しかし、この技術は、本発明の好適な実施形態において前に説明した方法よりも圧縮効率が悪い。
【００６９】
図１４について説明すると、本発明の他の実施形態の符号化方法は、実際のINTRAフレームが選択された点に関しては、好適な実施形態と類似の方法で進行する。エンコーダのバッファ内の実際のINTRAフレームに先行するフレームは、Ｂフレーム５２として符号化され、各Ｂフレームは、図１４に示すように、実際のINTRAフレームから直接逆方向に予測された５１ｂである。Ｂフレームの逆方向の予測は、ITU-T H.263のようなビデオ符号化勧告によりすでにサポートされているので、この他の実施形態の場合には、実際のINTRAフレームに先行するフレームに逆の順序でＣＯ番号を割り当てる必要はない。各フレームを、予測基準としての実際のINTRAフレームにより、Ｂフレーム・フォーマットに符号化しなければならないことを表示するだけで十分である。この情報は、実際のINTRAフレームに先行する各フレームに関連するメタデータに含ませることができる。バッファの実際のINTRAフレームに続くこれらのフレームは、次に、INTERフォーマットに順次符号化される。実際のINTRAフレームを実際のINTRAフレームの直後のフレームに対する予測基準として使用すべきであるという表示は、そのフレームに対するメタデータに含められる。
【００７０】
本発明の方法の他の実施形態は、ビデオ圧縮方法が、基準画像選択をサポートしない場合に使用することができる。この場合には、ビデオ・コーデックを制御し、呼び出す層（例えば、制御プログラム）は、コーデックの基準フレーム・バッファの内容を、それを参照すべき瞬間の直前の時点で、実際のINTRAフレームで置き換えることができる。上記例について説明すると、このことは、フレームＣＯ＝63の符号化または復号化をスタートした場合には、基準フレーム・バッファに、フレームＣＯ＝0をロードしなければならないことを意味する。この本発明の他の実施形態を使用できるようにするために、圧縮ビデオ構文または多重化／送信フォーマットは、実際のINTRAフレームを識別し、フレーム中のどれがそれを基準として必要とするかを示す情報を含んでいなければならない。
【００７１】
次に、すでに説明したビデオ符号化方法と一緒に使用するのに適している復号化方法およびビデオ再生方法の例示としての実施形態について説明する。図１２は、本発明の復号化方法を示す。復号化プロセスの場合には、デコーダは、伝送チャネルから符号化されたフレームを受信し、フレームをバッファする（１２０）。次に、デコーダは、バッファしたフレーム１２２を復号化する。この場合、伝送チャネルとしては、圧縮ビデオまたはマルチメディア・データの送信に適している任意の通信チャネルを使用することができる。送信は、インターネット、ISDNまたはPSTN（公衆交換電話回線網）のような固定ライン・ネットワークを通して行われる。他の方法としては、ネットワークの少なくとも一部は、PLMN（公衆陸上移動通信網）が供給するような無線リンクを含むことができる。「伝送チャネル」という通常の用語は、例えば、表示または他の処理用のコンピュータのハードドライブのような記憶媒体から記憶ファイルを検索する場合に行われるデータの送信を含むことも理解されたい。
【００７２】
圧縮ビデオ・シーケンスの各フレームは、符号化された方法により、当業者であれば周知の本質的に標準的な方法で復号化される。このような復号化が可能なのは、本発明の方法は、INTRAおよびINTER符号化フレーム自身のフォーマットを必ずしも変更しないからである。それ故、圧縮していない各ビデオ・フレームの符号化は、すでに説明したように、標準化されたまたは専用の任意の適当なスキームにより行うことができる。
【００７３】
復号化後に、圧縮していないフレームは、再生バッファ内に記憶される（１２４）。エンコーダで使用するバッファの長さがＴである場合には（符号化段階の上記説明参照）、デコーダで使用するバッファは、少なくとも0.5×T秒の圧縮していないビデオ画像を保持することができれば有利である。次に、解凍ビデオ・フレームは、その正しい再生シーケンスに順序づけられる。デコーダは、各フレームに関連する再生時間情報に従ってフレームを順序づける。すでに説明したように、この情報は、エンコーダのバッファ内にビデオ・フレームを記憶している場合には、データ構造体に組込むことができ、圧縮ビデオ構文で、または圧縮ビデオ・フレームをデコーダに送信する場合には、多重化／送信フォーマットにより実行することができる。ある種の状況においては、例えば、通信チャネルの処理能力が低下した場合には、デコーダは、その予定再生時間の後でフレームを実際に受信することができる。その予定再生時間の後でフレームを受信した場合には、またはフレームをその予定再生時間の前に受信したが、正確に時間通りに確実に再生するために十分に迅速に復号化できなかった場合には、そのようなフレームはデコーダの入力バッファ内にまったく記憶しないこともできる。しかし、後で到着するフレームを記憶する方が有利な場合もあり、その予定の再生に間に合って復号化できない場合もある。何故なら、これらのフレームは、例えば、他のフレームの誤り隠蔽を改善するために使用できるからである。
【００７４】
図１３は、本発明の例示としての実施形態による、ビデオ再生「エンジン」の手順ステップを示す。再生エンジンは、その入力として、ビデオ・デコーダのバッファ１２４から、その予定再生時間に従って正しく順序づけられた解凍ビデオ・フレームを受信する。新しいビデオ・シーケンスの再生がスタートした場合、入力ビデオ・フレームは、再生バッファ１３２内にバッファされる。一時的な中止なしでビデオ・シーケンスを確実に再生するために、この最初のバッファ時間は、少なくとも0.5×T秒でなければならない。最初のバッファ時間の後で、再生プロセスは、ステップ１３４、１３６および１３８からなる通常の再生ループに入る。ループの最初のステップ１３４においては、再生が予定されているフレームが、再生バッファ内にあるかどうかの判断が行われる。そのようなフレームが存在する場合には、それが表示される（１３６）。そのようなフレームが存在していない場合、またはフレームが表示されたばかりである場合には、プロセスは、周期的待機状態、またはアイドル状態（１３８）に入る。都合のよいことに、再生ループの動作速度は、元の捕捉されたシーケンスの（最大）フレーム速度である。例えば、シーケンスが毎秒25フレームの速度で捕捉された場合には、再生ループは、40ミリ秒毎に実行される。
【００７５】
図１５は、本発明のマルチメディア・コンテンツ生成システムの例示としての実施形態である。この図の場合には、システムは３つの媒体ソース１０、すなわち、オーディオ・ソース１５１ａ、ビデオ・ソース１５１ｂおよびデータ・ソース１５１cを含む。当業者であれば、媒体ソースの数は、この図に示す３つの例に制限されないことを理解することができるだろう。また、各ソースは、「生の」ソース、すなわち、リアルタイムの媒体コンテンツ、および、例えば、ネットワークで接続しているハードドライブ等のような大容量記憶媒体に常駐している媒体コンテンツのファイルのような、リアルタイムでない媒体ソースを含むが、これらに限定されない多数の異なる形をとることができることは明らかである。
【００７６】
本発明のマルチメディア・コンテンツ生成システムは、その全体を参照番号２０で示すマルチメディア捕捉手段を含む。この例示としての実施形態の場合には、専用捕捉装置が、各媒体ソース用に設置されている。それ故、捕捉手段２０は、オーディオ捕捉装置１５２ａ、ビデオ捕捉装置１５２ｂ、およびデータ捕捉装置１５２ｃを含む。オーディオ捕捉装置は、例えば、マイクロホン、アナログ−デジタル変換器、およびデジタル化したオーディオ・データのフレームを形成するための信号処理電子回路を含むことができる。ビデオ捕捉装置は、すでに説明したように、アナログ・ビデオ入力からデジタルビデオ・フレームを生成するためのビデオ・グラッバ・カードを含むことができる。各媒体ソースに対して、捕捉装置は、また、媒体ソースおよびその関連する捕捉装置の動作を制御するために必要な専用デバイス・ドライバおよびアプリケーション・プログラムのようなソフトウェアを含むことができる。マルチメディア捕捉手段２０の出力は、一組の圧縮していない媒体ストリームであり、各ストリームは、媒体ソース１５１ａ−１５１ｃ中の１つに対応する。
【００７７】
他の方法としては、１つまたはそれ以上の媒体ソースが、マルチメディア・コンテンツ・エディタ２２への適用にすでに適している形でその内容を供給する場合には、その媒体内容を直接エディタに適用することができる。これは、例えば、媒体ソースが、例えば、大容量記憶媒体上に記憶しているファイルからデジタルの形で検索したオーディオまたはビデオ・フレームである場合である。
【００７８】
マルチメディア・コンテンツ・エディタ２２は、マルチメディア捕捉手段が供給する各媒体ストリームを受信し、それらストリームを一緒にリンクして１つの時間ラインとする。例えば、オーディオおよびビデオコンテンツのような同時に再生されなければならないマルチメディア・ストリームは、各フレームの必要な再生時間の表示をつけてリンクされる。他のマルチメディア・ストリームの必要な再生時間に関する表示も供給することができる。このようにリンクされた場合、マルチメディア・コンテンツの各成分は、「トラック」と呼ばれる。エディタ２２は、また、媒体トラックを種々の方法で編集する可能性を供給する。例えば、ビデオ・フレーム速度を半分に減速することもできるし、ビデオ画像の空間的解像度を低減することもできる。
【００７９】
符号化ユニット２４は、エディタ２２から媒体トラックを受信する。この例示としての実施形態の場合には、各トラックは、問題の媒体タイプに適した方法で、別々に符号化され、個々のエンコーダが、各媒体タイプに対して使用される。それ故、この例の場合には、３つのエンコーダ、すなわち、オーディオ・エンコーダ１５７ａ、ビデオ・エンコーダ１５７ｂ、およびデータ・エンコーダ１５７ｃが使用される。ここでもまた、本発明の方法を実行するためには、個々のエンコーダの正確な数は重要でないことを理解することができるだろう。また、データ・エンコーダの場合には、符号化方法が、データの性質により異なる場合があることに留意されたい。各エンコーダは、媒体トラックが、例えば、狭い帯域幅を持つ通信リンクを通して送信するのに適している、もっとコンパクトな方法で表現されるように、各媒体トラック内の冗長な情報を除去する。使用する圧縮技術は、損失を起こさない圧縮方法および損失を起こす圧縮方法の両方を含むことができる。オーディオ・トラックおよびビデオ・トラックは、任意の適当な方法で符号化することができ、その選択は、受信クライアントに、さらにマルチメディア・データを送信するために使用する通信チャネルの性質により異なる。例えば、オーディオ・トラックは、GSM EFR音声コーデックにより符号化することができる。ビデオ・エンコーダ１５７ｂは、本明細書にすでに記載した方法により実施される。ビデオ・エンコーダは、動き補正時間的予測を使用し、すでに説明したように、本発明の方法により画像シーケンス内で使用する予測経路の長さを短縮するような方法で動作し、データ損失によるエラーに対して、より大きな回復力を持つ圧縮ビデオ・トラックを供給する。
【００８０】
符号化ユニット２４により生成された圧縮媒体トラックは、マルチプレクサ２６により受信される。この場合、これら圧縮媒体トラックは、マルチメディア「クリップ」と呼ばれる１本のビット・ストリームを形成するようにインターリーブされる。次に、クリップは、マルチメディア・サーバ１４に送られ、そこからさらに通信リンクを通して受信クライアントに送信することができる。
【００８１】
図１６は、本発明の方法を使用することができる別な状況を示す。この図は、ITU-T勧告H.324により実行されるマルチメディア端末１６０を示す。上記端末は、マルチメディア・トランシーバ・デバイスと見なすことができる。この端末は、通信ネットワークを通して送信するために、マルチメディア・データ・ストリームを捕捉し、符号化し、多重化する素子、および受信マルチメディア・コンテンツを受信し、逆多重化し、復号化し、再生する素子を含む。ITU-T勧告H.324は、端末の動作を全体的に定義し、端末装置の種々の素子の動作を制御する他の勧告に言及している。通常、このようなマルチメディア端末は、ビデオ電話のようなリアルタイムのマルチメディア用途に使用されるが、その用途はこのような用途に限定されない。例えば、H.324マルチメディア端末は、また、例えば、マルチメディア・コンテンツ・サーバからマルチメディア・コンテンツをダウンロードまたはストリーミングするためのマルチメディア・コンテンツ検索クライアントとして使用することができる。
【００８２】
本発明の場合には、図１６のH.324端末は、本発明の方法を実行するのに適している多数の他のマルチメディア端末の１つに過ぎない。端末装置の位置決めおよび実行については、多くの別の方法があることに留意されたい。図１６に示すように、マルチメディア端末は、アナログPSTN（公衆交換電話回線網）のような固定ライン電話網に接続している通信装置内に設置することができる。この場合、マルチメディア端末は、ITU-T勧告V.8、V.34およびそうしたい場合には、V.8bisに適合するモデム１７１を装備することができる。他の方法としては、マルチメディア端末は、外部モデムに接続することもできる。このモデムは、多重化デジタル・データおよびマルチメディア端末が生成する制御信号を、PSTNを通して送信するのに適しているアナログの形に変換することができる。上記モデムは、さらに、マルチメディア端末が、PSTNからアナログの形でデータおよび制御信号を受信することができるようにし、上記データおよび制御信号を端末が適当な方法で逆多重化し、処理することができるデジタル・データ・ストリームに変換する。
【００８３】
H.324マルチメディア端末は、また、ISDN（デジタル総合サービス網）のようなデジタル固定ライン・ネットワークに直接接続可能でも良い。この場合、端末は、H.324／Ｉ（ITU-T勧告H.324の付属書類Ｄ）に従って実施され、モデム１７１の代わりに、ITU-T I.400勧告シリーズによるISDNユーザ・ネットワーク・インターフェースが使用される。図１６の場合には、ブロック１７２が、このISDNユーザ・インターフェースである。
【００８４】
H.324マルチメディア端末は、また、移動通信用途でも使用することができる。勧告H.324の付属書類Ｃは、H.324端末を、エラーが発生しやすい送信環境で使用できるよう適応させる多くの修正を示す。これらの修正の大部分は、データ・ストリームの結合に使用される多重化プロトコル（ITU-T勧告H.223）であり、データ損失およびチャネル・エラーによる劣化により強いビット・ストリームを生成するためのものである。これらの修正の使用は移動通信に限定されないが、このタイプの通信リンクの場合に通常使用される比較的高いビット誤り率により移動用途での使用に特に適している。H.324付属書類Ｃは、また、移動用途の場合には、モデム１７１の代わりに、図１６のブロック１７３で示すような任意の適当な無線インターフェースを使用することができる。それ故、H.324付属書類Ｃに従って実施された移動マルチメディア端末（通常、H.324／M端末と呼ばれる）は、任意の現在または未来の移動体通信ネットワークでの使用に適している無線部分を内蔵することができる。例えば、H.324／Mマルチメディア端末は、現在の第二世代のGSM移動電話ネットワーク、または提案されている第三世代のUMTS（汎用移動電話システム）に接続することができる無線トランシーバを含むことができる。
【００８５】
しかし、場所が何処であれ、マルチメディア端末を実施すると、回線交換、およびパケットをベースとする無線通信リンクの両方を含み、無線リンクを含む移動体通信ネットワークを含むことができる、通信ネットワークと、マルチメディア・コンテンツを交換する可能性がでてくる。例えば、ISDNネットワークに接続しているH.324／Ｉマルチメディア端末は、PLMN移動電話ネットワークで、H.324／Ｍ端末と接続することができる。ネットワークを通して端末間で送信されるマルチメディア・データは、エラーおよびデータ損失の種々のソースの影響を受ける。これらは、例えば、無線通信リンクに影響を与える干渉、およびコアISDNネットワーク内で発生する恐れがある混雑によるパケット損失により、ビット反転誤りを含んでいる場合が多い。それ故、伝送誤りに対して高度の回復力を持つビデオ・ビット・ストリームを供給するように通信マルチメディア端末のビデオ・エンコーダを実施することが望ましい。すでに説明したように、本発明のビデオ符号化方法は、誤り回復力がさらに強化された時間的予測技術により圧縮されたビデオ・シーケンスを供給する。それ故、本発明のビデオ符号化方法は、マルチメディア端末で実施するのに理想的なものであり、特にエラーを起こしやすい通信チャネルを通して使用されることが多いデバイスで使用するのに特に適している。
【００８６】
二方向通信、すなわち、ビデオ・データの送受信用に設計されているマルチメディア端末においては、本発明により実施したビデオ・エンコーダとビデオ・デコーダの両方を使用しなければならない。本発明のある実施形態のビデオ・エンコーダは、フレームが圧縮されている順序を変更することができるので、受信端末のビデオ・デコーダは、表示する前に、受信フレームを正しく順序づけなければならない。それ故、本発明の通常のマルチメディア端末は、上記符号化／復号化方法を行うエンコーダ／デコーダのペアを含む。このようなエンコーダおよびデコーダのペアは、多くの場合、「コーデック」という名前の１つの結合機能ユニットとして実施される。一方、マルチメディア端末を、マルチメディア検索クライアントとしてだけ使用する場合には、本発明により実施されたデコーダだけを含んでいるだけでよい。
【００８７】
図１６を参照しながら、通常のH.324マルチメディア端末について以下にさらに詳細に説明する。マルチメディア端末１６０は、種々のいわゆる「端末装置」を含む。このマルチメディア端末装置は、全体をそれぞれ参照番号１６１、１６２および１６３で示すビデオ・デバイス、オーディオ・デバイスおよびテレマティック装置を含む。ビデオ装置１６１は、例えば、ビデオ画像を捕捉するためのビデオ・カメラ、受信ビデオコンテンツを表示するためのモニタ、およびオプションとして処理装置を含むことができる。オーディオ装置１６２は、通常、例えば、言語によるメッセージを捕捉するためのマイクロホン、および受信したオーディオコンテンツを再生するためのラウドスピーカを含む。オーディオ装置は、また、他のオーディオ処理ユニットを含むこともできる。テレマティック装置１６３は、データ端末、キーボード、電子ホワイトボードまたはファックス・ユニットのような静止画像トランシーバを含むことができる。
【００８８】
ビデオ装置は、ビデオ・コーデック１６５に接続している。ビデオ・コーデックは、ビデオ・エンコーダおよび対応するビデオ・デコーダを備える。このビデオ・コーデックは、通信リンクを通してさらに送信するために、捕捉したビデオ・データを適当な形に符号化し、通信ネットワークから受信した圧縮ビデオコンテンツを復号化する。図１６の例の場合には、ビデオ・コーデックは、遅いビット速度のビデオ会議用に使用するのに特に適している、ITU-T勧告H.263により実行される。この場合、通信リンクは使用できる帯域幅が、例えば、20kbpsである無線チャネルである。
【００８９】
同様に、端末オーディオ装置は、図１６に参照番号１６６で示すオーディオ・コーデックに接続している。この例の場合には、オーディオ・コーデックは、ITU-T勧告G.723.1に従って実施される。ビデオ・コーデックのように、オーディオ・コーデックもエンコーダ／デコーダのペアを備えている。オーディオ・コーデックは、端末のオーディオ装置が捕捉したオーディオ・データを、通信リンクを通して送信するのに適している形に変換し、ネットワークから受信した符号化されたオーディオ・データを、例えば、端末のラウドスピーカで再生するのに適している形に変換する。オーディオ・コーデックの出力は、遅延ブロック１６７に送られる。この遅延ブロックは、ビデオ符号化による遅延を補正し、それにより、オーディオコンテンツおよびビデオコンテンツを確実に同期させる。
【００９０】
マルチメディア端末のシステム制御ブロック１６４は、送信端末と受信端末との間に通常の動作モードを確立するために、端末−ネットワーク間の信号送信を制御する。H.324は、エンドツーエンド信号方式は、ITU-T勧告H.245が定義する制御プロトコルにより実行すべきことを規定している。図１６に参照番号１６８で示すH.245制御プロトコルは、送信端末および受信端末の符号化機能および復号化機能に関する情報を交換し、ビデオ・エンコーダの種々の符号化モードを動作できるようにすることができる。システム制御ブロック１６４は、また、ITU-T勧告H.233により、データ暗号化の使用を制御する。データ伝送の際に使用する暗号化のタイプに関する情報は、暗号化ブロック１６９からマルチプレクサ／デマルチプレクサ（MUX/DMUXユニット）１７０に送られる。
【００９１】
マルチメディア端末からのデータの送信中、MUX/DMUXユニット１７０は、１本のビット・ストリームを形成するために、符号化され、同期しているビデオ・ストリームおよびオーディオ・ストリームをテレマティック装置１６３からのデータ入力と結合する。暗号化ブロック１６９が供給する、ビット・ストリームに適用されるデータ暗号化のタイプ（もし使用する場合）に関する情報は、暗号化モードを選択するために使用される。それに応じて、多重化され、また恐らく暗号化されているマルチメディア・ビット・ストリームを受信した場合には、MUX/DMUXユニット１７０は、ビット・ストリームを復号化し、それをその構成マルチメディア成分に分割し、復号化および再生のために、これらの成分を適当なコーデックおよび／または端末装置に送る。H.324規格によれば、MUX/DMUXユニット１７０は、ITU-T勧告H.223を実行しなければならない。
【００９２】
本発明のマルチメディア・コンテンツ生成システム、マルチメディア端末、マルチメディア検索クライアント、ビデオ・エンコーダ、デコーダおよびビデオ・コーデックの機能素子は、ソフトウェアまたは専用ハードウェア、またはこれら２つの組合わせとして実施することができることに留意されたい。本発明のビデオ符号化および復号化方法は、本発明の機能ステップを実行するための機械が読むことができる命令を含むコンピュータ・プログラムの形で実施するのに特に適している。それ故、本発明のエンコーダおよびデコーダは、記憶媒体上に記憶しているソフトウェアとして実施することができ、コンピュータにビデオ符号化および／または復号化機能を供給するために、デスクトップ型パーソナル・コンピュータのようなコンピュータで実行することができる。
【００９３】
本発明の利点を強調するために、シミュレーション実験の結果を考慮することによって、パケット損失の場合の動作を検討する。この例の場合、本発明の符号化方法を実施するように設計されたビデオ・エンコーダを、毎秒10フレームの速度で、QCIF（１／４共通中間フォーマット）ビデオ・フレームを符号化するために使用するものと仮定する。周期的INTRAフレーム要求は、５秒の間隔で発生するが、ビデオ・シーケンス内のシーン・カットのために、INTRAフレーム要求は発生しない。INTRA符号化フレームを表すのに必要なデータの量は２０００バイトであり、INTERフレームの大きさは約２００バイトであると仮定する。これらの数字は、ITU-T勧告H.263のような現在使用しているビデオ符号化により符号化したINTRAおよびINTER符号化QCIFフォーマット・フレームの通常の数字である。
【００９４】
インターネットおよびローカル・エリア・ネットワーク（LAN）でデータ伝送用に使用するプロトコル・データ・ユニットの一般的な最大サイズは、約1500バイトである。このパケット・サイズの場合には、通常のINTRA符号化フレームは、その送信のために２つのパケットを必要とする。一方、１つのパケットは、７つのINTERフレームを運ぶことができる。このことは、５秒間のビデオを構成する50フレームを送信するためには、全部で９つのパケットが必要であることを意味する。（通常のように）シーケンスがINTRAフレームでスタートする場合には、通常の５秒間のビデオ・シーケンスは、１つのINTRAフレームと、49のINTER符号化フレームを含む。すでに説明したように、INTRAフレーム要求は、それを送信するために２つのパケットを必要とし、一方、残りの４９のINTER符号化フレームは、７つのパケット内に収容することができる。それ故、全部で９つのパケットが必要になる。インターネットを通してデータを送信するには、大きなパケットを使用すると有利であることに留意されたい。第一に、インターネット・バックボーン内において、パケット損失の確率は、本質的には、パケット・サイズとは無関係であり、第二に、大きなパケット・サイズを使用すると、パケット・ヘッダ・オーバーヘッドが低減するからである。
【００９５】
本発明の符号化方法を適用した場合、エンコーダは、QCIFフォーマットの入力ビデオ・フレームを記憶するために、その持続時間が５秒＋１フレームであるバッファを使用する。符号化プロセスがスタートすると、バッファは最初空になり、その後で、圧縮していないQCIFビデオ・フレームで満たされる。シーケンス内の第１のフレームは、INTRA要求に関連する。この例のバッファの長さは、周期的INTRAリフレッシュ要求速度と一致するように選択され、考慮対象の時間内にシーン・カットまたはINTRAフレーム更新要求が発生しないと仮定しているので、バッファ内に記憶された最後のフレームは、次のINTRA要求と関連する。それ故、エンコーダは、その発生時間が２つのINTRAフレーム要求のほぼ中間である、バッファ内の圧縮していないフレームの位置を知ることができる。このフレームは、INTRAフォーマットへの符号化のために選択され（すなわち、実際のINTRAフレームとなるように選択され）、上記符号化プロセスが、バッファ内のフレームに適用される。ここで考慮するシミュレーションの場合には、さらに、すでに符号化済みであり、現在、圧縮ビデオ・フレームが、パケットをベースとする通信ネットワークを通して送信中であり、通信チャネルは混雑していて、その結果、送信パケットにある割合で損失が生じるものと仮定する。シミュレーションしたビット速度は、18880bpsであり、インターネットを通るオーディオ・ビジュアル・ストリーミングの目標ビット速度は、28.8kbpsモデムを使用する。
【００９６】
下記の表においては、本発明の符号化方法の誤り回復と、INTRA要求に関連するすべてのフレーム自身が、（図７に示すように）INTRAフォーマットに符号化される従来の符号化スキームの誤り回復とが比較されている。表４は、平均、９つのパケット内で１つのパケットが喪失する場合の、フレーム損失の数値（１１％のパケット損失）を示す。一方、表５は、９つのパケット中の２つのパケットが喪失する状況の、対応する数値（２２％のパケット損失）を示す。
【００９７】
【表４】

【００９８】
【表５】

上記の両方のケースは、本発明の方法を使用した場合には、フレーム損失が少ないことを示す。
【００９９】
以上の説明においては、本発明の方法を、例示としての実施形態を参照しながら説明した。当業者であれば、本発明は、上記の例示としての実施形態の正確な詳細に限定されないこと、およびその本質的な属性および特徴から逸脱することなしに、他の形式で実施することができることを理解することができるだろう。それ故、上記の例示としての実施形態は、本発明を制限するものではなく、説明のためのものであるとみなすべきである。それ故、本発明の範囲については、添付の特許請求の範囲、および本明細書に記載する発明のコンセプトの一般的な説明を参照されたい。
【０１００】
さらに、（特許請求の範囲を含む）本明細書に記載し、図面に示す各機能は、他の開示および／または図に示す機能とは独立しているもので、本発明に含まれる。この点に関して、本発明は、それが特許請求の範囲に関連していてもいなくても、または解決すべき問題のいずれかまたはすべてを緩和するか否かを問わず、本明細書にはっきりとまたは一般的な表現で開示したすべての新規な機能または機能の組合わせを含む。
本明細書と一緒に提出された添付の要約を引用によって本明細書の記載に援用する。
【図面の簡単な説明】
【図１】 従来技術のマルチメディア・コンテンツ生成および検索システムである。
【図２】 通常のマルチメディア・クリップ・エディタが実行する動作である。
【図３】 通常のマルチメディア・サーバの入力および出力である。
【図４】 マルチメディア・クリップの検索中に通常のクライアント端末が実行する動作である。
【図５】 圧縮ビデオ・シーケンス内のＩ、ＰおよびＢフレーム間の予測依存性を示す。
【図６】 INTERフレーム符号化を使用するビデオ・シーケンスの一例である。
【図７】 シーン・カット直後におけるINTRAフレームのビデオ・フレーム・シーケンスへの挿入を示す。
【図８】 本発明のビデオ符号化方法により形成したビデオ・シーケンスの一例である。
【図９】 従来技術のビデオ・エンコーダの動作を示すフローチャートである。
【図１０】 本発明の好適な実施形態のビデオ符号化方法を示すフローチャートである。
【図１１】 本発明の方法によるINTRAフレームの処理を示すフローチャートである。
【図１２】 本発明の好適な実施形態によるビデオ復号化方法の手順ステップを示すフローチャートである。
【図１３】 ビデオ再生中の本発明による方法の動作を示すフローチャートである。
【図１４】 Ｂフレームを使用した、本発明の他の実施形態によるビデオ符号化方法の手順ステップを示す。
【図１５】 本発明に従って実行される、ビデオ・エンコーダが組込まれたマルチメディア・コンテンツ生成および検索システムである。
【図１６】 本発明のビデオ符号化／復号化を実行できるビデオ・エンコーダおよびビデオ・デコーダを備えるビデオ・コーデックを含む汎用H.324マルチメディア端末のブロック図である。

Claims (48)

1. 対応する符号化したビデオ・フレームの組を形成するために、時間的順序を有する符号化していないビデオ・フレームの組を符号化するための方法であって、前記方法が、
   前記符号化していない組の特定のビデオ・フレームに関連する標示であって、前記時間的順序の特定の位置に発生する前記特定のビデオ・フレームが非時間的予測ビデオ・フレーム・フォーマットに符号化されるものであることと時間的予測ビデオ・フレーム・フォーマットにおいてフレーム予測の開始位置として使用されるものであることを示す、前記標示を受信するステップと、
   前記符号化していない組のビデオ・フレームを選択するステップであって、前記選択されたビデオ・フレームは、以下である：
   前記特定のビデオ・フレーム以外であって、
   前記特定のビデオ・フレームに代わって前記非時間的予測ビデオ・フレーム・フォーマットに符号化され、
   前記選択されたビデオ・フレームの前に発生する前記符号化していない組のＮ個のビデオ・フレームと、前記選択されたビデオ・フレームの後に発生する前記符号化していない組のＭ個のビデオ・フレームの前記時間的順序の位置に発生する、前記選択するステップと、
   前記特定のビデオ・フレームに代わって前記選択されたビデオ・フレームを前記非時間的予測ビデオ・フレーム・フォーマットに符号化するステップと、
   前記Ｎ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的逆方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第１のサブセットを形成するステップと、
   前記Ｍ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的順方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第２のサブセットを形成するステップとを含み、
   前記選択されたビデオ・フレームの選択は、伝送エラーを起こしやすい通信チャネルを通して前記符号化したビデオ・フレームの組が送信される時の伝送エラー伝播の可能性を、前記特定のビデオ・フレームが時間的予測の開始位置として用いられた場合における前記符号化したビデオ・フレームの組に対する伝送エラー伝播の可能性と比較して少なくする、前記符号化したビデオ・フレームの第１および第２のサブセットの各予測経路の長さを提供することを特徴とする方法。
2. 請求項１に記載の方法において、前記非時間的予測ビデオ・フレーム・フォーマットが、ＩＮＴＲＡフレーム・フォーマットであることを特徴とする方法。
3. 請求項１に記載の方法において、前記Ｎ個のビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化することによって、前記符号化したビデオ・フレームの第１のサブセットを形成するステップを含むことを特徴とする方法。
4. 請求項１に記載の方法において、前記Ｎ個のビデオ・フレームをＰフレーム・フォーマットに符号化することによって、前記符号化したビデオ・フレームの第１のサブセットを形成するステップを含むことを特徴とする方法。
5. 請求項１に記載の方法において、前記Ｎ個のビデオ・フレームをＢフレーム・フォーマットに符号化することによって、前記符号化したビデオ・フレームの第１のサブセットを形成するステップを含むことを特徴とする方法。
6. 請求項１に記載の方法において、前記Ｍ個のビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化することによって、前記符号化したビデオ・フレームの第２のサブセットを形成するステップを含むことを特徴とする方法。
7. 請求項１に記載の方法において、前記Ｍ個のビデオ・フレームをＰフレーム・フォーマットに符号化することによって、前記符号化したビデオ・フレームの第２のサブセットを形成するステップを含むことを特徴とする方法。
8. 請求項３に記載の方法において、前記Ｎ個の各ビデオ・フレームにシーケンシャルな圧縮順序番号を割り当てるステップであって、前記Ｎ個のビデオ・フレームの前記時間的順序において最も新しく発生するビデオ・フレームに最も小さな圧縮順序番号が割り当てられ、前記Ｎ個のビデオ・フレームの前記時間的順序において最も先に発生するビデオ・フレームに最も大きな圧縮順序番号を割り当てるステップと、
   前記選択されたビデオ・フレームを、前記最も小さな圧縮順序番号を持つ前記ビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するための予測基準フレームとして標示するステップと、
   圧縮順序番号の昇順に、連続してＩＮＴＥＲフレーム・フォーマットに前記Ｎ個のビデオ・フレームのビデオ・フレームを符号化するステップと、により前記Ｎ個のビデオ・フレームを符号化するステップを含むことを特徴とする方法。
9. 請求項１に記載の方法において、前記Ｎ個の各ビデオ・フレームに圧縮順序番号を割り当てるステップと、前記Ｎ個のビデオ・フレームの各々に割り当てられた圧縮順序番号により決定された順序で前記Ｎ個のビデオ・フレームを符号化するステップとを含むことを特徴とする方法。
10. 請求項５に記載の方法において、前記選択されたビデオ・フレームを前記Ｎ個の各ビデオ・フレームの予測基準フレームとして標示するステップと、
    前記選択されたビデオ・フレームを参照して前記Ｂフレーム・フォーマットに符号化することによって、ビデオ・フレームの第１のサブセットを形成するステップと、により前記Ｎ個のビデオ・フレームを符号化するステップを含むことを特徴とする方法。
11. 請求項１に記載の方法において、前記Ｍ個の各ビデオ・フレームにシーケンシャルな圧縮順序番号を割り当てるステップであって、前記Ｍ個のビデオ・フレームの前記時間的順序において最も先に発生するビデオ・フレームに最も小さな圧縮順序番号が割り当てられ、前記Ｍ個のビデオ・フレームの前記時間的順序において最も新しく発生するビデオ・フレームに最も大きな圧縮順序番号を割り当てるステップと、
    前記選択されたビデオ・フレームを、前記最も小さな圧縮順序番号を持つ前記ビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するための予測基準フレームとして標示するステップと、
    圧縮順序番号の昇順に、連続してＩＮＴＥＲフレーム・フォーマットに前記Ｍ個のビデオ・フレームのビデオ・フレームを符号化するステップと、により前記Ｍ個のビデオ・フレームを符号化するステップを含む、ことを特徴とする方法。
12. 請求項１に記載の方法において、前記Ｍ個の各ビデオ・フレームに圧縮順序番号を割り当てるステップと、前記Ｍ個のビデオ・フレームの各々に割り当てられた圧縮順序番号により決定された順序で前記Ｍ個のビデオ・フレームを符号化するステップとを含むことを特徴とする方法。
13. 請求項１に記載の方法において、前記標示はシーン・カットを伴うＩＮＴＲＡフレーム要求であることを特徴とする方法。
14. 請求項１に記載の方法において、前記標示は周期的ＩＮＴＲＡフレーム要求であることを特徴とする方法。
15. 請求項１に記載の方法において、前記標示は受信端末からフィードバックとしてＩＮＴＲＡフレーム更新要求であることを特徴とする方法。
16. 請求項１ないし１５のいずれか一項に記載の方法において、
    符号化していないビデオ・フレームの前記組のほぼ中間に発生するビデオ・フレームとして前記選択されたビデオ・フレームを選択するステップを含むことを特徴とする方法。
17. 請求項１ないし１６のいずれか一項に記載の方法において、さらに、前記ビデオ・フレームの意図された再生順序に関する情報を提供するステップを含むことを特徴とする方法。
18. 請求項１ないし１７のいずれか一項に記載の方法において、さらに、前記ビデオ・フレームの意図された再生時間に関する情報を提供するステップを含むことを特徴とする方法。
19. 請求項４に記載の方法において、前記Ｐフレーム・フォーマットに符号化されたＮ個のビデオ・フレームの連続するビデオ・フレーム間のＢフレームを符号化するステップを含むことを特徴とする方法。
20. 請求項７に記載の方法において、前記Ｐフレーム・フォーマットに符号化されたＭ個のビデオ・フレームの連続するビデオ・フレーム間のＢフレームを符号化するステップを含むことを特徴とする方法。
21. 対応する符号化したビデオ・フレームの組を形成するために、時間的順序を有する符号化していないビデオ・フレームの組を符号化するためのエンコーダであって、前記エンコーダが、
    前記符号化していない組の特定のビデオ・フレームに関連する標示であって、前記時間的順序の特定の位置に発生する前記特定のビデオ・フレームが非時間的予測ビデオ・フレーム・フォーマットに符号化されるものであることと時間的予測ビデオ・フレーム・フォーマットにおいてビデオ・フレーム予測の開始位置として使用されるものであることを示す、前記組の特定の標示を受信する手段と、
    前記符号化していない組のビデオ・フレームを選択する手段であって、前記選択されたビデオ・フレームは、以下である：
    前記特定のビデオ・フレーム以外であって、
    前記特定のビデオ・フレームに代わって前記非時間予測ビデオ・フレーム・フォーマットに符号化され、
    前記選択されたビデオ・フレームの前に発生する前記符号化していない組のＮ個のビデオ・フレームと、前記選択されたビデオ・フレームの後に発生する前記符号化していない組のＭ個のビデオ・フレームの前記時間的順序の位置に発生する、前記選択する手段と、
    前記特定のビデオ・フレームに代わって前記選択されたビデオ・フレームを前記非時間的予測ビデオ・フレーム・フォーマットに符号化する手段と、
    前記Ｎ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて、時間的逆方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第１のサブセットを形成する手段と、
    前記Ｍ個のビデオ・フレームを時間的予測の開始位置として前記選択されたビデオ・フレームを用いて、時間的順方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第２のサブセットを形成する手段とを含み、
    前記選択されたビデオ・フレームの選択は、伝送エラーを起こしやすい通信チャネルを通して前記符号化したビデオ・フレームの組が送信される時の伝送エラー伝播の可能性を、前記特定のビデオ・フレームが時間的予測の開始位置として用いられた場合における前記符号化したビデオ・フレームの組に対する伝送エラー伝播の可能性と比較して少なくする、前記符号化したビデオ・フレームの第１および第２のサブセットの各予測経路の長さを提供することを特徴とするエンコーダ。
22. 請求項２１に記載のエンコーダにおいて、前記非時間的予測ビデオ・フレーム・フォーマットが、ＩＮＴＲＡフレーム・フォーマットであることを特徴とするエンコーダ。
23. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段は、前記Ｎ個のビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するよう構成されることを特徴とするエンコーダ。
24. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段は、前記Ｎ個のビデオ・フレームをＰフレーム・フォーマットに符号化するよう構成されることを特徴とするエンコーダ。
25. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段は、前記Ｎ個のビデオ・フレームをＢフレーム・フォーマットに符号化するよう構成されることを特徴とするエンコーダ。
26. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第２のサブセットを形成する前記手段は、前記Ｍ個のビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するよう構成されることを特徴とするエンコーダ。
27. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第２のサブセットを形成する前記手段は、前記Ｍ個のビデオ・フレームをＰフレーム・フォーマットに符号化するよう構成されることを特徴とするエンコーダ。
28. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段が、
    前記Ｎ個の各ビデオ・フレームにシーケンシャルな圧縮順序番号を割り当てる手段であって、前記Ｎ個のビデオ・フレームの前記時間的順序において最も新しく発生するビデオ・フレームに最も小さな圧縮順序番号が割り当てられ、前記Ｎ個のビデオ・フレームの前記時間的順序において最も先に発生するビデオ・フレームに最も大きな圧縮順序番号を割り当てる手段と、
    前記選択されたビデオ・フレームを、前記最も小さな圧縮順序番号を持つ前記ビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するための予測基準フレームとして標示する手段と、
    圧縮順序番号の昇順に、連続してＩＮＴＥＲフレーム・フォーマットに前記Ｎ個のビデオ・フレームのビデオ・フレームを符号化する手段とを含むことを特徴とするエンコーダ。
29. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段は、前記第１のサブセットのビデオ・フレームの前記Ｎ個の各ビデオ・フレームに圧縮順序番号を割り当て、前記Ｎ個のビデオ・フレームの各々に割り当てられた圧縮順序番号により決定された順序で前記Ｎ個のビデオ・フレームを符号化するよう構成されることを特徴とするエンコーダ。
30. 請求項２５に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する前記手段が、
    前記選択されたビデオ・フレームを前記Ｎ個の各ビデオ・フレームの予測基準フレームとして標示する手段と、
    前記選択されたビデオ・フレームを参照して前記Ｎ個のビデオ・フレームを前記Ｂフレーム・フォーマットに符号化する手段と、
    を含むことを特徴とするエンコーダ。
31. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第２のサブセットを形成する前記手段が、
    前記Ｍ個の各ビデオ・フレームにシーケンシャルな圧縮順序番号を割り当てる手段であって、前記Ｍ個のビデオ・フレームの前記時間的順序において最も先に発生するビデオ・フレームに最も小さな圧縮順序番号が割り当てられ、前記Ｍ個のビデオ・フレームの前記時間的順序において最も新しく発生するビデオ・フレームに最も大きな圧縮順序番号を割り当てる手段と、
    前記選択されたビデオ・フレームを、前記最も小さな圧縮順序番号を持つ前記ビデオ・フレームをＩＮＴＥＲフレーム・フォーマットに符号化するための予測基準フレームとして標示する手段と、
    圧縮順序番号の昇順に、連続してＩＮＴＥＲフレーム・フォーマットに前記Ｍ個のビデオ・フレームのビデオ・フレームを符号化する手段とを含むことを特徴とするエンコーダ。
32. 請求項２１に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第２のサブセットを形成する前記手段は、前記第２のサブセットのビデオ・フレームの前記Ｍ個の各ビデオ・フレームに圧縮順序番号を割り当て、前記Ｍ個のビデオ・フレームの各々に割り当てられた圧縮順序番号により決定された順序で前記Ｍ個のビデオ・フレームを符号化するよう構成されることを特徴とするエンコーダ。
33. 請求項２１に記載のエンコーダにおいて、標示を受信する前記手段が、シーン・カットを伴うＩＮＴＲＡフレーム要求を受信するよう構成され、前記ＩＮＴＲＡフレーム要求は前記特定のビデオ・フレームが前記非時間的予測ビデオ・フレーム・
    フォーマットに符号化されることを標示することを特徴とするエンコーダ。
34. 請求項２１に記載のエンコーダにおいて、標示を受信する前記手段が、周期的ＩＮＴＲＡフレーム要求を受信するよう構成され、前記周期的ＩＮＴＲＡフレーム要求は前記特定のビデオ・フレームが前記非時間的予測ビデオ・フレーム・フォーマットに符号化されることを標示することを特徴とするエンコーダ。
35. 請求項２１に記載のエンコーダにおいて、標示を受信する前記手段が、受信端末からフィードバックとしてＩＮＴＲＡフレーム更新要求を受信するよう構成され、前記ＩＮＴＲＡフレーム更新要求は前記特定のビデオ・フレームが前記非時間的予測ビデオ・フレーム・フォーマットに符号化されることを標示することを特徴とするエンコーダ。
36. 請求項２１ないし３５のいずれか一項に記載のエンコーダにおいて、前記選択する手段は、
    符号化していないビデオ・フレームの前記組のほぼ中間に発生するビデオ・フレームとして前記選択されたビデオ・フレームを選択するよう構成されることを特徴とするエンコーダ。
37. 請求項２１ないし３６のいずれか一項に記載のエンコーダにおいて、前記エンコーダはさらに、前記ビデオ・フレームの意図された再生順序に関する情報を提供する手段を含むことを特徴とするエンコーダ。
38. 請求項２１ないし３７のいずれか一項に記載のエンコーダにおいて、前記エンコーダはさらに、前記ビデオ・フレームの意図された再生時間に関する情報を提供する手段を含むことを特徴とするエンコーダ。
39. 請求項２４に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第１のサブセットを形成する手段は、前記Ｐフレーム・フォーマットに符号化されたＮ個のビデオ・フレームの連続するビデオ・フレーム間のＢフレームを符号化する手段を含むことを特徴とするエンコーダ。
40. 請求項２７に記載のエンコーダにおいて、前記符号化したビデオ・フレームの第２のサブセットを形成する手段は、前記Ｐフレーム・フォーマットに符号化されたＭ個のビデオ・フレームの連続するビデオ・フレーム間のＢフレームを符号化する手段を含むことを特徴とするエンコーダ。
41. ビデオ・コーデックであって、請求項２１ないし４０のいずれか一項に記載のエンコーダを含むことを特徴とするビデオ・コーデック。
42. マルチメディア・コンテンツ生成システムであって、請求項２１ないし４０のいずれか一項に記載のエンコーダを含むことを特徴とするマルチメディア・コンテンツ生成システム。
43. マルチメディア端末であって、請求項２１ないし４０のいずれか一項に記載のエンコーダを含むことを特徴とするマルチメディア端末。
44. 請求項４３に記載のマルチメディア端末において、前記マルチメディア端末が、無線通信デバイスであることを特徴とするマルチメディア端末。
45. 対応する符号化したビデオ・フレームの組を形成するために、時間的順序を有する符号化していないビデオ・フレームの組を符号化するためのエンコーダとしてコンピュータを動作させるためのコンピュータ・プログラムであって、符号化される前記ビデオ・フレームは時間的順序を有し、前記コンピュータ・プログラムが、
    前記符号化していない組の特定のビデオ・フレームに関連する標示であって、前記時間的順序の特定の位置に発生するビデオ・フレームが非時間的予測ビデオ・フレーム・フォーマットに符号化されるものであることと、時間的予測ビデオ・フレーム・フォーマットにおいてビデオ・フレーム予測の開始位置として使用されるものであることを示す、前記標示を受信するためのコンピュータ・コードと、
    前記符号化していない組のビデオ・フレームを選択するためのコンピュータ・コードであって、前記選択されたビデオ・フレームは、以下である：
    前記特定のビデオ・フレーム以外であって、
    前記特定のビデオ・フレームに代わって前記非時間的予測ビデオ・フレーム・フォーマットに符号化され、
    前記選択されたビデオ・フレームの前に発生する前記符号化していない組のＮ個のビデオ・フレームと、前記選択されたビデオ・フレームの後に発生する前記符号化していない組のＭ個のビデオ・フレームの前記時間的順序の位置に発生する、前記選択するためのコンピュータ・コードと、
    前記特定のビデオ・フレームに代わって前記選択されたビデオ・フレームを前記非時間的予測ビデオ・フレーム・フォーマットに符号化するためのコンピュータ・コードと、
    前記Ｎ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的逆方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第１のサブセットを形成するためのコンピュータ・コードと、
    前記Ｍ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的順方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第２のサブセットを形成するためのコンピュータ・コードとを含み、
    前記選択されたビデオ・フレームの選択は、伝送エラーを起こしやすい通信チャネルを通して前記符号化したビデオ・フレームの組が送信される時の伝送エラー伝播の可能性を、前記特定のビデオ・フレームが時間的予測の開始位置として用いられた場合における前記符号化したビデオ・フレームの組に対する伝送エラー伝播の可能性と比較して少なくする、前記符号化したビデオ・フレームの第１および第２のサブセットの各予測経路の長さを提供することを特徴とするコンピュータ・プログラム。
46. 請求項４５に記載のコンピュータ・プログラムを含む記憶媒体。
47. 対応する符号化したビデオ・フレームの組を形成するために、時間的順序を有する符号化していないビデオ・フレームの組を符号化するための装置であって、前記装置が、
    前記符号化していない組の特定のビデオ・フレームに関連する標示であって、前記時間的順序の特定の位置に発生する前記特定のビデオ・フレームが非時間的予測ビデオ・フレーム・フォーマットに符号化されるものであることと時間的予測ビデオ・フレーム・フォーマットにおいてビデオ・フレーム予測の開始位置として使用されるものであることを示す、前記標示を受信し、
    前記符号化していない組のビデオ・フレームを選択することであって、前記選択されたビデオ・フレームは、以下である：
    前記特定のビデオ・フレーム以外であって、
    前記選択されたビデオ・フレームの前に発生する前記符号化していない組のＮ個のビデオ・フレームと、前記選択されたビデオ・フレームの後に発生する前記符号化していない組のＭ個のビデオ・フレームの前記時間的順序の位置に発生する、前記選択をし、
    前記特定のビデオ・フレームに代わって前記選択されたビデオ・フレームを前記非時間的予測ビデオ・フレーム・フォーマットに符号化し、
    前記Ｎ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的逆方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第１のサブセットを形成し、
    前記Ｍ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的順方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第２のサブセットを形成するように構成され、
    前記選択されたビデオ・フレームの選択は、前記符号化したビデオ・フレームの組が、前記特定のビデオ・フレームが時間的予測の開始位置として用いられた場合の前記組に対する伝送エラー伝播の可能性と比較して、伝送エラーを起こしやすい通信チャネルを通して送信される時の伝送エラー伝播の可能性を少なくする、前記符号化したビデオ・フレームの第１および第２のサブセットの各予測経路の長さを提供することを特徴とする装置。
48. 対応する符号化したビデオ・フレームの組を形成するために、時間的順序を有する符号化していないビデオ・フレームの組を符号化するための装置であって、前記装置が、
    前記符号化していない組の特定のビデオ・フレームに関連する標示であって、前記時間的順序の特定の位置に発生する前記特定のビデオ・フレームが非時間的予測ビデオ・フレーム・フォーマットに符号化されるものであることと時間的予測ビデオ・フレーム・フォーマットにおいてビデオ・フレーム予測の開始位置として使用されるものであることを示す、前記標示を受信するように構成されるユニットと、
    前記符号化していない組のビデオ・フレームを選択することであって、前記選択されたビデオ・フレームは、以下である：
    前記特定のビデオ・フレーム以外であって、
    前記特定のビデオ・フレームに代わって前記非時間的予測ビデオ・フレーム・フォーマットに符号化され、
    前記選択されたビデオ・フレームの前に発生する前記符号化していない組のＮ個のビデオ・フレームと、前記選択されたビデオ・フレームの後に発生する前記符号化していない組のＭ個のビデオ・フレームの前記時間的順序の位置に発生する、前記選択するように構成される選択ユニットと、
    前記特定のビデオ・フレームに代わって前記選択されたビデオ・フレームを前記非時間的予測ビデオ・フレーム・フォーマットに符号化するように構成されるエンコーダと、
    前記Ｎ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的逆方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第１のサブセットを形成するように構成されるエンコーダと、
    前記Ｍ個のビデオ・フレームを前記選択されたビデオ・フレームを時間的予測の開始位置として用いて時間的順方向予測ビデオ・フレーム・フォーマットに符号化することによって、符号化したビデオ・フレームの第２のサブセットを形成するように構成されるエンコーダとを含み、
    前記選択されたビデオ・フレームの選択は、伝送エラーを起こしやすい通信チャネルを通して前記符号化したビデオ・フレームの組が送信される時の伝送エラー伝播の可能性を、前記特定のビデオ・フレームが時間的予測の開始位置として用いられた場合における前記符号化したビデオ・フレームの組に対する伝送エラー伝播の可能性と比較して少なくする、前記符号化したビデオ・フレームの第１および第２のサブセットの各予測経路の長さを提供することを特徴とする装置。

Images