パケットロスのリカバリを改善するためのフレームキャッシングの使用
【課題】フレームキャッシングを使用してパケットロスのリカバリを改良するための、新規で進歩性のある種々の装置および方法を提供すること。
【解決手段】開示された実施形態の１つは、エンコーダおよびそれに対応するデコーダにおいて、定期的で同期されたフレームキャッシングを使用するための方法である。デコーダは、パケットロスを発見したとき、エンコーダに通知し、次いで、エンコーダが、エンコーダとデコーダの両方で格納され共有されたフレームの１つに基づいて、フレームを生成する。デコーダは、この生成されたフレームを受け取ったとき、この生成されたフレームを、デコーダでローカルにキャッシュしたフレームを使用してデコードすることができる。
【解決手段】開示された実施形態の１つは、エンコーダおよびそれに対応するデコーダにおいて、定期的で同期されたフレームキャッシングを使用するための方法である。デコーダは、パケットロスを発見したとき、エンコーダに通知し、次いで、エンコーダが、エンコーダとデコーダの両方で格納され共有されたフレームの１つに基づいて、フレームを生成する。デコーダは、この生成されたフレームを受け取ったとき、この生成されたフレームを、デコーダでローカルにキャッシュしたフレームを使用してデコードすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ビデオ、画像、および他のデジタルメディアコンテンツの、エンコード、デコード、および処理をデジタルで行うための技術に関する。本発明は、詳細には、フレームキャッシング（ｆｒａｍｅ ｃａｃｈｉｎｇ）により、パケットロスを改善することに関する。
【背景技術】
【０００２】
この特許書類の開示の一部分は、著作権の保護を受けている資料を含む。この著作権の保有者は、特許開示のいずれかによる複写に対して、それが特許商標庁のファイルまたは記録に見られるとき、異議がないが、そうでなければ、何にせよすべての著作権を留保する。
【０００３】
デジタルビデオは、大量の記憶容量および伝送容量を消費する。一般的な未加工のデジタルビデオシーケンスは、毎秒１５または３０フレームを含む。各フレームは、数万または数十万の（ペル（ｐｅｌ）とも呼ばれる）ピクセルを含むことができる。各ピクセルは、ピクチャ（ｐｉｃｔｕｒｅ）の極めて小さな要素を表す。未加工の形式では、コンピュータは、１ピクセルを、３つのサンプルのからなる合計２４ビットのセットとして表す。例えば、ピクセルは、ピクセルのグレイスケール（ｇｒａｙｓｃａｌｅ）成分を定義する、１つの８ビット輝度サンプル（ルマ（ｌｕｍａ）サンプルとも呼ばれる）と、ピクセルの色成分を定義する、２つの８ビットクロミナンス（ｃｈｒｏｍｉｎａｎｃｅ）サンプル（クロマ（ｃｈｒｏｍａ）サンプルとも呼ばれる）を含むことができる。したがって、一般的な未加工のデジタルビデオシーケンスの１秒あたりのビット数またはビットレートは、毎秒５００万ビット以上である。
【０００４】
多くのコンピュータおよびコンピュータネットワークは、未加工のデジタルビデオを処理するためのリソースが不足している。そのため、エンジニアは、デジタルビデオのビットレートを下げるために（符号化またはエンコードとも呼ばれる）圧縮を使用する。圧縮は、ビデオをより低速のビットレート形式に変換することによって、ビデオを格納し送信するコストを減少させる。（デコードとも呼ばれる）解凍は、圧縮された形式から元のバージョンのビデオを再構成する。「コーデック」とは、エンコーダ／デコーダシステムである。ビデオの品質は損なわれないがビットレートの低下はビデオデータの（ときとしてエントロピと呼ばれる）変動性の固有の量によって制限される圧縮は、ロスレス（ｌｏｓｓｌｅｓｓ）（可逆）でありうる。あるいは、ビデオの品質は損なわれビットレートの達成可能な低下がより著しい圧縮は、ロッシー（ｌｏｓｓｙ）（不可逆）でありうる。ロッシー圧縮が情報の近似を確立し、ロスレス圧縮技術がその近似を表すために適用されるシステム設計において、ロッシー圧縮は、ロスレス圧縮と併せてしばしば使用される。
【０００５】
ビデオ圧縮技術は、一般に、「イントラピクチャ（ｉｎｔｒａｐｉｃｔｕｒｅ）」圧縮と「インターピクチャ（ｉｎｔｅｒｐｉｃｔｕｒｅ）」圧縮を含み、ピクチャは、例えば、プログレッシブスキャンビデオフレーム（ｐｒｏｇｒｅｓｓｉｖｅｌｙ ｓｃａｎｎｅｄ ｖｉｄｅｏ ｆｒａｍｅ）、（ビデオフィールドにおいて交互のラインを有する）インタレースビデオフレーム、または、インターレースビデオフィールドである。一般的に言えば、ビデオシーケンスは、所与のフレーム内および連続したフレーム間に、かなり量の冗長を含む。例えば、人間の眼は、連続したビデオフレームにおける他の点では同様の背景のわずかな違いには気付かない。圧縮は、送信されているビットストリーム内の冗長マテリアルの特定の部分を除去し、次いで、ピクチャが解凍されるときに受信側でそれらを追加して戻すことによって、このような冗長を活用する。ビデオフレームから抜き取られる２つの共通の冗長は、空間的および時間的なものである。空間的冗長は、単一のフレーム内の隣接ピクセル間に存在する。イントラフレーム（ｉｎｔｒａｆｒａｍｅ）またはＩフレームとして知られる空間的冗長を使用して圧縮されるフレームは、フレームそれ自体の内に画像を再構成するための必要なすべての情報を含み、つまり自己完結している。ＰフレームおよびＢフレームのような時間的冗長を使用するフレームは、デコードされる他のフレームからの情報を必要とする。Ｐフレーム（予測的にエンコードされるフレーム）は、エンコードされ、そして、先行のＩおよび／またはＰフレームからの情報を使用してデコードされる必要がある。Ｂフレーム（双方向で予測的にエンコードされるフレーム）は、先行および後続のＩおよびＰフレームの両方からの情報を使用してエンコードされる。動き検出は、参照フレームとして知られる先行してエンコードされた画像から作成された、動きの予測された画像とともに、固有の事項をエンコードすることにより、連続したビデオフレーム（フレーム間）における時間的冗長を除去する。参照フレームが失われた場合、後続の予測フレームは復号されることができず、すなわち、伝送エラーが、後続のフレームに伝播する。
【０００６】
プログレッシブフレームに関しては、イントラピクチャ圧縮技術が、（通常、Ｉフレームまたはキーフレームと呼ばれる）独立したフレームを圧縮し、インターピクチャ圧縮技術が、（通常、参照フレームまたはアンカーフレームと呼ばれる）先行および／または後続のフレームを参照して、（通常、予測フレーム、Ｐフレーム、またはＢフレームと呼ばれる）フレームを圧縮する。（自己完結した）Ｉフレーム、および（一般に先行フレームを参照する）Ｐフレームは、それら自体を参照フレームとすることができ、一方、先行および後続フレームの両方を参照する、Ｂフレームは、通常はそれら自体が参照として使用されることはまったくない。
【０００７】
結果のビデオが表示されるのに先立ってデータが圧縮されるとき、デコーダは、通常、圧縮の逆の操作を実行する。例えば、デコーダは、データを圧縮する際に、エントロピデコード、逆量子化、および逆変換を実行することができる。動き補償が使用される場合、デコーダ（およびエンコーダ）は、１つまたは複数の先行して再構成された（参照フレームとして現在使用されている）フレームから、フレームを再構成し、次いで、新しく再構成されたフレームが、より後のフレームの動き補償のための参照フレームとして使用されうる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ネットワークを介して送られたパケットは、欠損する、つまり廃棄されるおそれがある。この損失は、ランダムで予測できない形で起きる。さらに、ビデオ圧縮ストリームデータは遅延の影響を大変受けやすく、あまりに多くの遅延したパケットにより、飛び飛びの分断された信号が生じ、パケットを送られた順序と同じ順序になるように再組み立てする必要がある。伝送遅延の問題は、新しいＩフレームを再送する際にも起きるおそれがあり、新しいフレームは、失われた参照フレームを破棄したのと同じすべての問題の影響を受けやすい。さらに、非可逆符号化方式では、圧縮は、記憶および伝送についての目標ビットレートを満たすように設計されている。再構成される画像の質を低下させることにより、高圧縮が達成される。そのため、廃棄されまたは遅延されたパケットにより生じた余分な損失は、画像の質を許容水準より低くするおそれがある。
【０００９】
パケットロスに対処する能力は、損失を生じやすいノイズを伴うネットワークでリアルタイムビデオコーデック（ＲＴＣ）が良好に動作するために極めて重要である。ほとんどの既存のビデオコーデックは、参照フレームが失われたとき新しいＩフレームを要求することによってパケットロスに対処している。他の既存のビデオコーデックは、スライスベースの符号化を使用し、それによりシグナリングオーバーヘッド（ｓｉｇｎａｌｉｎｇ ｏｖｅｒｈｅａｄ）が増加する。図１は、新しいＩフレームを要求することによる、従来のパケットロスのリカバリを示す。
【００１０】
この従来技術の方法では、Ｉフレーム１０４が、デコーダ１０２で受け取られる。次いで、そのフレームは、後続の従属するＰフレーム１０６を解釈／再構成するために使用される。次の従属フレームであるＰフレーム１０８は、充分なパケットが、ばらばらの順序で受け取られるかまたは失われたとき、破棄される。次のＰフレーム１１０および後続のフレームを、もはや再構成することができない。（ここではデコーダ１０２により表されている）宛先ノードで、Ｉフレーム要求が生成され、（ここではエンコード１１４により表される）ソースノードに送られる。各後続のＰフレームまたはＢフレームを、新しいＩフレームが受け取られるまで再構成することができない。ソースノード１１４は、要求を受け取ると、新しいＩフレーム１１２を組み立て、通信チャネルを使用して、それを宛先ノード１０２に送る。新しいＩフレーム１１２を受け取った後、宛先チャネルは、後続のＰフレームを正常にデコードすることができる。しかし、この結果、最初の要求を送るために必要な時間と等しい遅延１１６に加え、Ｉフレームをエンコードする時間、および、Ｉフレームを宛先ノード１０２に送る時間が生じる。さらに、送信側と受信側が、大きな物理的距離によって隔てられていることがあり、この長い距離の移動により、顕著な遅延時間が発生し、それに対応するビデオの質の低下がもたらされる。
【００１１】
他の従来技術の方法では、Ｉフレーム１０４、１１２は、一定の間隔で送られる。Ｉフレーム１１２が、破棄または遅延により失われた場合、デコーダは、次のＩフレームが受け取られるまで、後続のＰフレーム１１０、１０８、１０６を不正確にはデコードせずに待機する。
【００１２】
したがって、非可逆パケットベースのネットワークを介して、圧縮されたビデオを送信するための、改良された方法およびシステムが必要とされる。
【課題を解決するための手段】
【００１３】
本明細書に記載のビデオコーデックは、エンコーダにおいてフレームキャッシュ（ｆｒａｍｅ ｃａｃｈｅ）を含み、デコーダにおいてそれに対応するフレームキャッシュを含み、それぞれのフレームキャッシュは、同期して動作する。デコーダキャッシュ内のフレームは、デコーダにおいてフレームを解釈するのを助けるために使用される。解釈するフレームを、エンコーダキャッシュに格納される同じフレームのコピーを用いて生成することができる。
【００１４】
システムの実装形態も提供される。それは、データパケットをフレーム内にエンコードするエンコーダ、および、フレームまたはその一部分を格納することができるエンコーダキャッシュを含む。それは、さらに、フレームまたはその一部分を同様に格納することができるデコーダキャッシュを有するデコーダを含む。デコーダは、パケットロスを検出することができる。いくつかの実施形態では、そのような損失が検出されたとき、エンコーダは、エンコーダキャッシュで格納されたフレームを使用してフレームをエンコードし、次いで、そのフレームは、デコーダキャッシュに格納されたフレームを使用してデコーダでデコードされる。
【００１５】
このキャッシングメカニズムは、下記の主要な特徴を提供する。
ａ）パケットロスのリカバリの際のより効率的な帯域幅の使用
ｂ）スライスベースの符号化に関連するシグナリングオーバーヘッドの除去
本発明の他の特徴および利点は、添付の図面を参照して行われる以下の実施形態の詳細な説明から明らかにされる。
【図面の簡単な説明】
【００１６】
【図１】フレームレベルのパケットロスのリカバリを示す従来技術の図である。
【図２】本明細書に記載のフレームキャッシングを利用するビデオを示すブロック図である。
【図３】本明細書に記載のフレームキャッシングを利用するビデオデコーダを示すブロック図である。
【図４】フレームキャッシングを利用してパケットロスからリカバリするための例示的方法を示すフローチャートである。
【図５Ａ】フレームをキャッシングするエンコーダ、およびそれと同じフレームをキャッシングするデコーダを示す、フレームレベルの図である。
【図５Ｂ】デコーダに到着する破棄されたＰフレームを示すフレームレベルの図である。
【図５Ｃ】Ｐフレームを解釈するために、キャッシュされたフレームを使用するデコーダを示すフレームレベルの図である。
【図５Ｄ】フィードバック経路を介したパケットロスの報告を示すブロック図である。
【図６】ビデオエンコーダ／デコーダキャッシングを実装するための適切な方法を示すフローチャートである。
【図７】図２および３のビデオエンコーダ／デコーダのための適切なコンピューティング環境を示すブロック図である。
【発明を実施するための形態】
【００１７】
以下の説明は、優雅なパケットロスのリカバリ、および効率的な帯域幅の利用の効率的な組合せを可能にするように設計された、ビデオエンコーダとビデオデコーダの双方におけるフレームキャッシュの実装に関する。フレームキャッシュの例示的適用は、画像またはビデオエンコーダおよびデコーダにおいて行われる。したがって、フレームキャッシュを、一般的な画像またはビデオエンコーダおよびデコーダのコンテキストで説明されるが、代替として、後で説明するこの例示的装置とは詳細が異なることがある他の様々な画像およびビデオコーデックのエンコーダおよびデコーダに組み込むこともできる。
【００１８】
１．汎用ビデオエンコーダおよびデコーダ
図２は、一般的なビデオエンコーダ２００のブロック図であり、図３は、一般的ビデオデコーダ３００のブロック図であり、それらにフレームキャッシュが組み込まれる。
【００１９】
エンコーダおよびデコーダ内のモジュール間に示される関係は、エンコーダおよびデコーダにおける情報の主な流れを示し、他の関係は単純化するために図示していない。特に、図２および３は、一般に、ビデオシーケンス、フレーム、マクロブロック（ｍａｃｒｏｂｌｏｃｋ）、およびブロックなどに使用されるエンコーダ設定、モード、およびテーブルなどを示すサイド情報を図示していない。このようなサイド情報は、通常、サイド情報のエントロピ符号化の後に、出力ビットストリームとして送られる。出力ビットストリームのフォーマットは、Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ Ｖｉｄｅｏフォーマットまたは他のフォーマットとすることができる。
【００２０】
所望の圧縮の実装形態およびタイプに応じて、エンコーダ２００またはデコーダ３００のモジュールについて、追加、省略、複数のモジュールへの分割、他のモジュールとの結合、および／または、同様のモジュールとの置換を行うことができる。代替実施形態では、異なるモジュール、および／または他の構成のモジュールを有する、エンコーダまたはデコーダが、ここに記載の技術の１つまたは複数を実行する。
【００２１】
Ａ．ビデオエンコーダ
図２は、一般的なビデオエンコーダシステム２００のブロック図である。エンコーダシステム２００は、現行のフレーム２０５を含むビデオフレームのシーケンスを受け取り、圧縮されたビデオ情報２９５を出力として生成する。ビデオエンコーダの特定の実施形態では、通常、一般的エンコーダ２００の変形形態または補足されたバージョンを使用する。
【００２２】
エンコーダシステム２００は、予測されたフレームとキーフレームを圧縮する。図２では、説明のために、エンコーダシステム２００を介したキーフレームの経路と、順方向予測（ｆｏｒｗａｒｄ−ｐｒｅｄｉｃｔｅｄ）フレームの経路を示している。エンコーダシステム２００のコンポーネントの多くは、キーフレームと予測フレームの両方を圧縮するために使用される。これらのコンポーネントによって行われる正確な動作は、圧縮されている情報のタイプに応じて大きく異なる。
【００２３】
（Ｐフレーム、Ｂフレーム（双方向予測）、またはフレーム間符号化（ｉｎｔｅｒ−ｃｏｄｅｄ）フレームであり得る）予測フレームは、１つまたは複数の他のフレームからの予測（または差異）の観点から表される。予測残差は、予測されたものと元のフレームの間の差異である。これに対して、（Ｉフレームまたはフレーム内符号化フレームとも呼ばれる）キーフレームは、他のフレームを参照することなく圧縮される。
【００２４】
現行のフレーム２０５が順方向予測フレームの場合、動き検出器２１０が、現行フレーム２０５の、マクロブロックまたはピクセルの他のセットの動きを、フレームストア（ｆｒａｍｅ ｓｔｏｒｅ）２２０にバッファされた再構成された先行フレームである参照フレーム２２５に関連して推定する。代替実施形態では、参照フレームは、より後のフレームとすることができ、あるいは、現行フレームは、双方向で予測されうる。動き検出器２１０は、動きベクトルなどの動き情報２１５をサイド情報として出力する。動き補償器２３０は、動き情報２１５を、再構成された先行フレーム２２５に適用して、動き補償された現行フレーム２３５を形成する。ただし、この予測は、めったに完全ではなく、動き補償された現行フレーム２３５と元の現行フレーム２０５の差異は、予測残差２４５である。あるいは、動き検出器２１０および動き補償器２３０は、他のタイプの動き検出／補償を適用する。
【００２５】
周波数変換器２６０は、空間領域のビデオ情報を、周波数領域（すなわちスペクトル）のデータに変換する。ブロックベースのビデオフレームでは、周波数変換器２６０は、離散コサイン変換（「ＤＣＴ」）と同様の性質を有する、後の節で説明する変換を適用する。いくつかの実施形態では、周波数変換器２６０は、周波数変換を、キーフレームについての空間予測残余のブロックに適用する。周波数変換器２６０は、８×８、８×４、４×８、または他のサイズの周波数変換を適用することができる。
【００２６】
次いで、量子化器２７０が、空間データ係数のブロックを量子化する。量子化器２７０は、均一なスカラ量子化を、フレーム毎または他の単位ごとに異なる刻み幅で、スペクトルデータに適用する。あるいは、量子化器２７０は、他のタイプの量子化、例えば、非均一、ベクトル、または非適応の量子化をスペクトルデータ係数に適用する、または、周波数変換を使用しないエンコーダシステムにおいて空間領域データを直接量子化する。適応的量子化に加えて、エンコーダ２００は、レート制御のために、フレームドロップ（ｆｒａｍｅ ｄｒｏｐｐｉｎｇ）、適応フィルタリング、または他の技術を使用することができる。
【００２７】
再構成された現行のフレームが、後続の動き検出／補償のために必要とされるとき、逆量子化器２７６は、量子化スペクトルデータ係数に対して逆量子化を実行する。次いで、周波数逆変換器２６６が、周波数変換器２６０の逆の操作を実行し、（予測されたフレームに対する）再構成された予測残差、または再構成されたキーフレームを生成する。現行フレーム２０５がキーフレームであった場合、再構成されたキーフレームは、再構成された現行フレーム（図示せず）と見なされる。現行フレーム２０５が、予測フレームであった場合、再構成された予測残差は、動き補償された現行フレーム２３５に加えられて、再構成された現行フレームが形成される。フレームストア２２０は、再構成された現行フレームを、次のフレームを予測する際に使用するためにバッファする。いくつかの実施形態では、エンコーダ２００は、フレームのブロックにおける不連続を適応的に平滑化するために、デブロッキングフィルタ（ｄｅｂｌｏｃｋｉｎｇ ｆｉｌｔｅｒ）を再構成されたフレームに適用する。
【００２８】
エントロピ符号化器２８０は、量子化器２７０の出力、ならびにサイド情報（例えば、動き情報２１５、量子化刻み幅）を圧縮する。典型的エントロピ符号化技術には、算術符号化、差分符号化、ハフマン符号化（Ｈｕｆｆｍａｎ ｃｏｄｉｎｇ）、ランレングス符号化（ｒｕｎ ｌｅｎｇｔｈ）符号化、ＬＺ符号化、辞書型符号化、およびそれらの組合せが含まれる。エントロピ符号化器２８０は、通常、異なる種類の情報（例えば、ＤＣ係数、ＡＣ係数など）に対して異なる符号化技術を使用し、ある特定の符号化技術において複数のコード表のうちから選択をすることができる。
【００２９】
エントロピ符号化器２８０は、ビデオ情報２９５をバッファ２９０に入れる。バッファレベルの標識が、ビットレート適応モジュールにフィードバックされる。圧縮されたビデオ情報２９５は、バッファ２９０から一定または比較的一定のビットレートで消耗し、そのビットレートで後続のストリーミングのために格納される。あるいは、エンコーダシステム２００は、圧縮されたビデオ情報２９５を直ちにストリームし圧縮を続ける。
【００３０】
バッファ２９０より先または後に、圧縮されたビデオ情報２９５は、ネットワークを介する送信のためにチャネル符号化されうる。チャネル符号化は、エラー検出および訂正データを、圧縮されたビデオ情報２９５に適用することができる。
【００３１】
Ｂ．ビデオデコーダ
図３は、一般的なビデオデコーダシステム３００のブロック図である。デコーダシステム３００は、圧縮されたビデオフレームのシーケンスに関する情報３９５を受け取り、再構成されたフレーム３０５を含む出力を生成する。ビデオデコーダのいくつかの特定の実施形態は、通常、一般的なデコーダ３００の変形形態または補足されたバージョンを用いる。
【００３２】
デコーダシステム３００は、予測フレームおよびキーフレームを圧縮する。図３では、説明のために、デコーダシステム３００を介するキーフレームの経路と、順方向予測フレームの経路を示している。デコーダシステム３００のコンポーネントの多数は、キーフレームと予測フレームの両方を圧縮するために使用される。これらのコンポーネントにより行われる正確な動作は、圧縮される情報のタイプによって変化しうる。
【００３３】
バッファ３９０は、圧縮されたビデオシーケンスに関する情報３９５を受け取り、受け取った情報をエントロピデコーダ３８０に使用可能にする。バッファ３９０は、時間に対してかなり一定のレートで情報を受け取り、また、帯域幅または送信における短期の変動を平滑化するためのジッタバッファを含む。バッファ３９０は、再生バッファおよび他のバッファも含むことができる。あるいは、バファ３９０は、変動するレートで情報を受け取る。圧縮されたビデオ情報３９５は、バッファ３９０に到達する前、またはバッファ３９０から離れた後、またはその両方において、エラー検出および訂正のためにデコードされ処理されうる。
【００３４】
エントロピデコーダ３８０は、エントロピ符号化された量子化データ、ならびにエントロピ符号化されたサイド情報（例えば、動き情報、量子化刻み幅）をデコードし、通常は、エンコーダ２００で行われたエントロピ符号化の逆を行う。エントロピデコード技術には、算術デコード、差分デコード、ハフマンデコード、ランレングスデコード、ＬＺデコード、辞書型デコード、およびそれらの組合せが含まれる。エントロピデコーダ３８０は、異なる種類の情報（例えば、ＤＣ係数、ＡＣ係数、異なる種類のサイド情報）に対して異なるデコード技術を使用し、ある特定のデコード技術において複数のコード表のうちから選択をすることができる。
【００３５】
再構成されるフレーム３０５が、前進予測フレームである場合、動き補償器３３０は、動き情報３１５を参照フレーム３２５に適用して、再構成されるフレーム３０５の予測３３５を形成する。例えば、動き補償器３３０は、マクロブロック動きベクトル（ｍａｃｒｏｂｌｏｃｋ ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を使用して、参照フレーム３２５におけるマクロブロックを見つける。フレームバッファ３２０は、先行の再構成されたフレームを参照フレームとして使用するために格納する。あるいは、動き補償器は、他のタイプの動き補償を用いる。動き補償器３３０による予測は、完全であることは稀であり、したがって、デコーダ３００は、予測残差３４５の再構成もする。
【００３６】
デコーダ３００が、後続の動き補償のために再構成されたフレームを必要とするとき、フレーム３２０は、次のフレームを予測する際に使用するために、再構成されたフレーム３０５をバッファする。いくつかの実施形態では、エンコーダ２００は、デブロッキングフィルタを、再構成されたフレーム３０５に適用して、フレームのブロックにおける不連続を適応的に平滑化する。
【００３７】
逆量子化器３７０は、エントロピデコードされたデータを逆量子化する。一般に、逆量子化器３７０は、均一のスカラ逆量子化を、エントロピデコードされたデータに、フレーム毎または他の単位で異なる刻み幅で適用する。あるいは、逆量子化３７０は、他のタイプの逆量子化、例えば、非均一、ベクトル、または非適応量子化をデータに適用する、または、周波数逆変換を使用しないデコーダシステムにおける空間領域データを直接逆量子化する。
【００３８】
周波数逆変換器３６０は、量子化された周波数領域データを、空間領域ビデオ情報に変換する。ブロックベースのビデオフレームについて、周波数逆変換器３６０は、後の節で説明される逆変換を適用する。いくつかの実施形態では、周波数逆変換器３６０は、キーフレームについての空間予測残差のブロックに、周波数逆変換を施す。周波数逆変換器３６０は、８×８、８×４、４×８、またの他のサイズの周波数逆変換を施すことができる。
【００３９】
Ｃ．フレームキャッシング
本明細書に記載のビデオコーデックアーキテクチャにおけるフレームキャッシングを使用する実装形態では、参照フレームは、エンコーダおよびデコーダの両方で順次キャッシュされることが好ましい。参照フレームが失われたとき、後続の従属フレームは、デコーダにおいてキャッシュされた適切な参照フレームを使用してデコードされうる。これにより、以下の利益がもたらされる。
【００４０】
Ａ）より効率的な帯域幅の利用：従来技術の方法は、Ｉフレームが生成されエンコーダに送られることを必要とする。本方法では、特別なタイプのフレーム、すなわちＳＰフレームが、デコーダに送られ、次いで、必要とされるまでキャッシュされることを可能にする。ＳＰフレームは、一般に、同じ品質のＩフレームよりも少ないビット数で符号化することができ、したがって、等価のＩフレームを使用するよりも小さい帯域幅を使用する。
【００４１】
Ｂ）より速いエラーリカバリ：パケットロスが発生したとき、ＳＰフレームがデコーダにおいて既にキャッシュされていることが好ましく、これにより、ほとんど遅延時間なしに、ストリームにおける次のＰフレームを解釈することを可能にする。
【００４２】
２．例示的方法の概要
ここに記載の実施形態は、デコーダにおけるフレームをキャッシュし、次いで、キャッシュしたフレームを使用して、破棄されたまたは失われている参照フレームに基づいてＰフレームおよびＢフレームを再構成するための技術およびツールを含む。キャッシュを、ビデオデコーダ３００（図３）の一部分として、またはビデオエンコーダ２００（図２）の一部分として組み込むことができ、好ましくはその両方において組み込むことができる。パケットロスがデコーダによって検出されると、デコーダは、エンコーダ２００にメッセージを送り、次いで、エンコーダ２００は、共有されたキャッシュされたフレームの１つに基づいて新しい参照フレームを生成する。次いで、生成された参照フレームは、デコーダに送られる。キャッシュされたフレームは、別の参照フレームがデコーダに到着するまで、生成されたフレームおよび後続の従属フレームをデコードするためにデコーダで使用される。本明細書に記載のフローチャートの要素は、例に過ぎず、記載の技術に応じて、他のフローチャート要素を使用することができる。さらに、フローチャート要素は、記載の技術およびツールに応じて、異なる順序で行い、あるいは特定の処理ブロックを省略することができる。
【００４３】
記載の技術およびツールは、互いに組み合わせてまたは他の技術およびツールと組み合わせて、あるいは別個に使用されうる。
【００４４】
図４を参照すると、フローチャート４００は、本明細書に開示の方法の簡潔な概観を示している。プロセスブロック４０２で、ネットワークを介して送信されるビデオ信号の一部分がパケットに割り当てられる。プロセスブロック４０４で、エンコーダは、パケットの少なくとも一部をフレーム内にエンコードする。これらのフレームは、ＩフレームおよびＰフレームのような参照フレーム３２５からなり、他の任意のフレームに対する参照として使用されないＢフレームからなることもある。スキップフレーム（ｓｋｉｐ ｆｒａｍｅ）のような代替タイプのフレームも、フレーム内にエンコードされうる。任意選択のプロセスブロック４０６で、エンコーダでフレームをキャッシュすることができ、このフレームは、一般的には参照フレームである。フレームは、キャッシュされた場合、「Ｃａｃｈｅｄ−Ｆｒａｍｅ」（ＣＦ）タイプがそのフレームヘッダにおいて割り当てられる。次いで、キャッシュされたフレームは、プロセスブロック４０８で、他のフレームと一緒に送信される。ブロック４１０で、フレームは、デコーダに到着した後、デコーダキャッシュ内にキャッシュされる。通常のキャッシュフレームのタイプは、ＰフレームおよびＩフレームである。
【００４５】
後続参照フレームが失われた場合、プロセスブロック４１２に示すように、キャッシュされたフレームを、後続の従属フレームを解凍するために使用することができる。フローチャート４００は、単に１つの例示的実施形態を示しているに過ぎず、何らかの限定をするものとして解釈されるべきではない。例えば、判断ブロック４０６でのエンコーダに関連するキャッシュは任意選択である。方法４００を、図２および図３に示されるように、ビデオコーデックで実装することができ、ビデオコーデックを、ソフトウェア、ハードウェア、または両方の組合せで実装することができる。
【００４６】
３．フレームをキャッシュするための例示的方法
図５Ａ〜５Ｄは、ノイズを伴うネットワークにおいてビデオコーデックの最適なパフォーマンスを可能にするためにフレームをキャッシュする例示的方法を示す。図５Ｄを参照すると、例示的実施形態では、フレームは、ＲＴＰ（リアルタイム転送プロトコル）５０８Ｄなどの主要チャネルを介して、エンコーダ５０２Ｄからデコーダ５０６Ｄにフレームが送信されている。インターネットは、しばしば、パケットを欠損したり、パケットをばらばらの順序で送達することがある。パケットは、あるランダムな時間量で遅延することもあり、これによりパケットが使用できないようになることもある。パケットロスは、デコーダ５０６Ｄによって検出され、フィードバック経路を介して、デコーダからエンコーダ５０２Ｄにその信号が送られる。メッセージを正しく再構成するために、いくつかの実施形態では、ＲＴＰ５０８Ｄヘッダが、情報およびシーケンス番号を含み、この両方により、受信側が、パケットを正しく並べ変え、失われたパケットの番号を決定することを可能にする。ＲＴＰ５０８Ｄは、その制御プロトコル（ＲＴＰＣ）５０４Ｄによって増強され、データの送達を監視するために使用することができるフィードバック経路を提供するために使用される。各データパケットは、シーケンス番号を有し、通常、シーケンス番号は、各後続データパケットにつき１つ増分される。例示的実施形態では、シーケンス番号が受け取られないとき、パケットロスは、デコーダ５０６Ｄによって検出される。デコーダ５０６Ｄは、パケットロスを検出すると、フィードバック経路５０４Ｄを介してメッセージを送り、どのパケット（または複数のパケット）が失われたかをエンコーダ５０２Ｄに通知する。いくつかの実施形態では、失われた最初のパケットについての情報のみが供給される。いくつかの実施形態では、廃棄されたパケットの番号、または失われた特定のパケットのリストなどの追加の情報も供給される。好ましくは、パケットロスの位置が、最も初期のパケットロスのタイムスタンプを使用して報告ウィンドウに伝えられる。この情報により、エンコーダ５０２Ｄが、どのキャッシュされた参照を使用するかを決定できるようになる。
【００４７】
図５Ａを参照すると、エンコーダ５０２Ａは、定期的にフレームをフレームキャッシュ５０４Ａにキャッシュしている。どのフレームがキャッシュされるか、どのくらいの頻度でキャッシュを行うべきか、ならびに、一度にキャッシュできるべきフレーム数は、実装形態に大きく依存する。いくつかの実施形態では、キャッシュされるフレームは、参照フレーム、すなわちＰフレームおよびＩフレームである。他のフレームタイプをキャッシュすることもできる。キャッシュされたフレーム５０６Ａ（またはそのコピー）はまた、デコーダ５１２Ａに送られる。エンコーダキャッシュ５０４Ａにも格納される、このようなフレームは、そのヘッダ内でフレームタイプＣＦ（キャッシュされたフレーム）として定義される。いくつかの実施形態では、このヘッダにより、後で使用するためにこの特定のフレームをデコーダキャッシュ５１０Ａに格納すべきであることを、デコーダ５１２Ａに知らせることによって、エンコーダ５０２Ａとデコーダ５１２Ａの同期が可能になる。下記の表１は、ＣＦ（キャッシュされたフレーム）タイプを含む、フレームタイプコードの例示的実施形態を示している。
【００４８】
【表１】
【００４９】
タイプＣＦのフレーム５０８Ａは、デコーダ５１２Ａに到達すると、デコーダフレームキャッシュ５１０Ａに格納される。タイプＣＦの各フレームをデコーダ５１２Ａにおいて格納することは、エンコーダおよびデコーダのフレームキャッシュ５０４Ａおよび５１０Ａを同期させる１つの方法である。ただし、これらのフレームキャッシュを同期させる他の方法も企図される。
【００５０】
パケットロス５０２Ｂがデコーダ５０４Ｂで検出されたとき、フィードバック経路５０４Ｄを使用して、その報告がエンコーダ５０２Ａに返される。この報告は、好ましくは、エンコーダ５０２Ａが参照のために適切なキャッシュされたフレーム５０４Ａを選ぶことをできるようにするタイムスタンプ情報を含む。他の実施形態では、最新のキャッシュされたフレームが使用される。キャッシュされたフレームが選ばれると（５０４Ｃ）、そのフレームは、エンコーダ５０２Ｃによって、次のフレーム５０６Ｃをエンコードするために使用される。次のフレーム５０６Ｃは、好ましくは、Ｐフレームであるが、Ｉフレームおよび他のフレームタイプをエンコードすることもできる。キャッシュされたフレーム５０６Ｃは、「Ｓｕｐｅｒ−Ｐ」フレーム（ＳＰフレーム）として知られ、そのヘッダでそのように示される。ＳＰフレームの例示的フレームタイプコードワードは、上記の表１に示されている。
【００５１】
デコーダ５１２Ｃは、ＳＰフレーム５０８Ｃを受け取ると、そのローカルでキャッシュされたフレーム５１０Ｃを使用して、ＳＰフレーム５０８Ｃを解凍されたフレーム（Ｕフレーム）５１４Ｃ内にデコードする。この方法を使用すると、デコーダ５１２Ｃにおけるリカバリ時間は、パケットロスイベントとＳＰフレームの到着の間の期間である。この生成されたＳＰフレーム５０８Ｃが、送信中に失われた場合、デコーダ５１２Ｃは、（一般に、タイプＰ、ＳＰ、またはＩの）新しい参照フレームの到着まで、パケットロスの報告を送り続ける。パケットロスからの実際のリカバリ時間は、主にパケットロス報告の間隔の関数となる。
【００５２】
いくつかの実装形態では、エンコーダ５０２Ａは、フレーム５０４Ａをキャッシュし、キャッシュされたフレーム５０６Ａのコピーを、デコーダに定期的に送る。キャッシュされたフレームが送られる時間間隔は、実装形態に大きく依存する。いくつかの実装形態では、等しい間隔でフレームをキャッシュすることができる。他の実装形態では、ネットワークの速度やネットワークが経験するロスの量などのそれ自体のシステム変数に依存する間隔でフレームをキャッシュすることができる。
【００５３】
４．例示的システムの実施形態
図６は、デコーダおよびエンコーダベースのフレームキャッシングを実装することができる、ビデオシステム６００の他の例示的実施形態を示す。本発明を、様々な汎用または専用のビデオシステムで実装することができ、ビデオシステム６００は、本発明の使用または機能の範囲に関して、どのような限定も示唆するものでもない。
【００５４】
ビデオシステムは、少なくとも１つのエンコーダ６０２を含む。このエンコーダは、さらに、エンコーダキャッシュ６０４を含む。図示の実施形態では、キャッシュは、エンコーダ６０２内に存在するが、他の実装形態では、ビデオシステム内の他の場所に存在することがある。エンコーダキャッシュ６０４は、１つまたは複数のビデオフレーム６０６の部分を格納することが可能である。限定ではなく示唆として、これらのフレームの部分は、いくつかのブロック、マクロブロック、いくつかのスライス、フレーム全体、フレームのグループ、または当業者が想定できる他の任意のフレームの区分から構成されうる。エンコーダキャッシュ６０４は、単に１つのフレーム部分、２つのフレーム部分、または与えられた実装形態に望ましい任意の数のフレーム部分をキャッシュすることができる。ビデオシステム６００はまた、デコーダ６０８を含む。エンコーダ６０２と同様に、デコーダ６０８は、１つまたは複数のビデオフレーム６１２の部分を格納するために使用される、デコーダキャッシュ６１０を含む。これらのビデオフレーム部分は、１つまたは複数のブロック、マクロブロック、スライス、フレーム全体、フレームのグループ、または当業者が想定することができる他のフレームの区分を含むことができる。デコーダキャッシュ６１０を、１つのフレーム部分、２つのフレーム部分、または他の任意の数のフレーム部分を格納するように構成することができる。
【００５５】
ビデオシステム６００はまた、エンコーダ６０４およびデコーダ６１０が、実質的に同じ情報を含むことを保証するために使用される、シンクロナイザ６１４を含む。前述のように、シンクロナイザは、エンコーダ６０２によって施される、いくつかの特定のフレームまたはフレームの部分に付加された一意のフレームヘッダを含むことができ、そのフレームヘッダは、特定のフレームまたはフレームの部分がキャッシュされるべきことをデコーダ６０８に通知する。例えば、あるフレームがエンコーダキャッシュ６０４に格納され、また、デコーダ６０８にも送られる場合がある。そのフレームは、エンコーダキャッシュ６０４に格納されたそのコピーが存在することを示す、特有のＣＦ（Ｃａｃｈｅｄ Ｆｒａｍｅ）ヘッダを有することができる。デコーダ６０８がフレームのデコードを困難または不可能にするパケットロスまたは他の破棄を検出したとき、エンコーダキャッシュ６０４に格納されたフレームからの、エンコーダ６０２によってエンコードされる後続のフレームは、このフレームがデコーダキャッシュ６１０におけるフレームからデコードすることができることを示すようにマーク付けされうる。いくつかの実装形態では、デコーダキャッシュ６１０において複数のフレームを格納することができ、このような場合、ヘッダは、どのキャッシュされたフレームが使用されるべきかを決定するための充分な他の情報も任意選択で含むことができる。他の同期化の方法も企図される。送信機６１６が、エンコーダ６０２からデコーダ６０８にフレームを送信する。
【００５６】
５．コンピューティング環境
上記のフレームキャッシングの実装形態を、特に例として、コンピュータ、画像およびビデオ録画、送受信装置、携帯ビデオプレイヤビデオ会議、ウェブビデオストリーミングアプリケーションなどを含む、画像およびビデオ信号処理が実行される、任意の様々な装置で実施することができる。画像およびビデオ符号化技術は、ハードウェア回路（例えば、ＡＳＩＣ、ＦＰＧＡなどの回路）、ならびに、図７に示されるような、コンピュータまたは他のコンピューティング環境において実行される（中央処理装置（ＣＰＵ）、専用グラフィックプロセッサ、またはビデオカードなどで実行される）画像およびビデオ処理ソフトウェアで実装することができる。
【００５７】
図７は、上述のフレームキャッシングを実装することができる、適切なコンピューティング環境７００の一般的な例を示す。本発明を、様々な汎用または専用のコンピューティング環境で実装することができ、コンピューティング環境７００は、本発明の使用または機能の範囲に関して、どのような限定も示唆するものでもない。
【００５８】
コンピューティング環境７００は、少なくとも１つの処理装置７１０およびメモリ７２０を含む。この最も基本的構成７３０は、破線内に含まれている。処理装置７１０は、コンピュータ実行可能命令を実行し、現実または仮想のプロセッサとすることができる。多重処理システムにおいては、複数の処理装置が、コンピュータ実行可能命令を実行して処理能力を高める。メモリ７２０は、揮発性メモリ（例えば、レジスタ、キャッシュ、ＲＡＭなど）、不揮発性メモリ（例えば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなど）、またはこの２つの何らかの組合せとすることができる。メモリ７２０は、上述のエンコーダ／デコーダキャッシングを実装するソフトウェア７８０を格納する。
【００５９】
コンピューティング環境は、追加の特徴を有することができる。例えば、コンピューティング環境７００は、ストレージ７４０、１つまたは複数の入力装置７５０、１つまたは複数の出力装置７６０、および１つまたは複数の通信接続７７０を含む。バス、コントローラ、またはネットワークなどの相互接続メカニズム（図示せず）は、コンピューティング環境７００のコンポーネントを相互接続する。オペレーティングシステムソフトウェア（図示せず）は、一般に、コンピューティング環境７００で実行される他のソフトウェアのための動作環境を提供し、コンピューティング環境７００のコンポーネントの活動を調整する。
【００６０】
ストレージ７４０は、リムーバルまたは固定とすることができ、また、磁気ディスク、磁気テープまたはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、あるいは、情報を格納するために使用可能でコンピューティング環境７００においてアクセスすることができる他の任意の媒体を含む。ストレージ７４０は、エンコーダ／デコーダキャッシング方式を実装するソフトウェア７８０のための命令を格納する。
【００６１】
（複数の）入力装置７５０は、キーボード、マウス、ペン、またはトラックボールなどのタッチ入力装置、音声入力装置、スキャン装置、あるいは、コンピューティング環境７００に入力を提供する他の装置とすることができる。オーディオに関しては、（複数の）入力装置７５０は、アナログまたはデジタル形式でオーディオ入力を受け入れるサウンドカードまたは同様のデバイス、あるいは、オーディオサンプルをコンピューティング環境７００に提供するＣＤ−ＲＯＭリーダとすることができる。（複数の）出力装置７６０は、ディスプレイ、プリンタ、スピーカ、ＣＤライタ、あるいは、コンピューティング環境７００からの出力を提供する他の装置とすることができる。
【００６２】
（複数の）通信接続７７０は、通信媒体を介して他のコンピューティングエンティティと通信することを可能にする。通信媒体は、コンピュータ実行可能命令、圧縮されたオーディオまたはビデオ情報、または被変調データ信号における他のデータなどの情報を搬送する。被変調データ信号は、情報を信号にエンコードするようにセットまたは変更された１つまたは複数の信号特性を有する信号である。通信媒体には、限定ではなく例として、電気、光、ＲＦ、赤外線、音響、または他の搬送波によって実装される有線または無線技術が含まれる。
【００６３】
本明細書におけるエンコーダ／デコーダフレームキャッシング技術を、コンピュータ可読媒体の一般的なコンテキストで記述することができる。コンピュータ可読媒体は、コンピューティング環境７００においてアクセスすることができる任意の使用可能な媒体である。限定ではなく例として、コンピューティング環境７００では、コンピュータ可読媒体には、メモリ７２０、ストレージ７４０、通信媒体、およびこれらの任意の組合せが含まれる。
【００６４】
本明細書におけるエンコーダ／デコーダフレームキャッシングを、対象の現実または仮想のプロセッサ上のコンピューティング環境で実行されるプログラムモジュールに含まれるような、コンピュータ実行可能命令の一般的なコンテキストで記述することができる。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象データ型を実装する、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、およびデータ構造などが含まれる。プログラムモジュールの機能を、様々な実施形態の必要に応じて、組み合わせることも、プログラムモジュール間で分割することもできる。プログラムモジュールのためのコンピュータ実行可能命令を、ローカルまたは分散コンピューティング環境で実行することができる。
【００６５】
説明のために、上述の詳細な説明では、「決定する（ｄｅｔｅｒｍｉｎｅ）」、「送信する（ｔｒａｎｓｍｉｔ）」、「エンコード」、「デコード」、「適用する（ａｐｐｌｙ）」などの言葉を使用して、コンピューティング環境におけるコンピュータの動作を記述している。これらの言葉は、コンピュータによって行われる動作の高度に抽象化したものであり、人間によって行われる行為と混同されるべきではない。これらの言葉に対応する実際のコンピュータの動作は、実装形態に応じて異なる。
【００６６】
本発明の原理を適用することができる多数の可能な実施形態に鑑みて、詳述された実施形態は、例示に過ぎず、本発明の範囲を限定するものとして解釈されるべきではない。むしろ、本発明では、そのようなすべての実施形態が、添付の特許請求の範囲とその均等物の範囲および趣旨に含まれるものとして請求される。
【符号の説明】
【００６７】
１０２ デコーダ
１０４ Ｉフレーム
１０６ Ｐフレーム
１０８ Ｐフレーム
１１０ Ｐフレーム
１１２ Ｉフレーム
１１４ エンコーダ
１１６ リカバリ時間
２００ エンコーダ
２０５ 現行フレーム
２１０ 動き推定器
２１５ 動き情報
２２０ フレームストア
２２５ 参照フレーム
２３０ 動き補償器
２３５ 動き補償された現行フレーム
２４５ 残差
２６０ 周波数変換器
２６６ 周波数逆変換器
２７０ 量子化器
２７６ 逆量子化器
２８０ エントロピ符号化器
２９０ バッファ
２９５ 圧縮されたビデオ情報
３００ デコーダ
３０５ 再構成されたフレーム
３２０ フレームストア
３２５ 参照フレーム
３３０ 動き補償器
３３５ 予測フレーム
３４５ 再構成された残差
３６０ 周波数逆変換器
３７０ 逆量子化器
３８０ エントロピデコーダ
３９０ バッファ
３９５ 圧縮されたビデオ情報
４００ フローチャート
４０２ 信号の一部分をパケットに割り当てる
４０４ パケットをフレーム内にエンコードする
４０６ エンコーダにおいてフレームをキャッシュする
４０８ フレームをデコーダに送信する
４１０ デコーダにおいてフレームをキャッシュする，Ｐフレーム，Ｉフレーム
４１２ キャッシュされたフレームに基づいてフレームを解釈する
５０２Ａ エンコーダ
５０４Ａ ＣＦ
５０６Ａ ＣＦ
５０８Ａ ＣＦ
５１０Ａ ＣＦ
５１２Ａ デコーダ
５０２Ｂ パケットロス
５０４Ｂ デコーダ
５０２Ｃ エンコーダ
５０４Ｃ ＣＦ
５０６Ｃ ＳＰ
５０８Ｃ ＳＰ
５１０Ｃ ＣＦ
５１２Ｃ デコーダ
５１４Ｃ Ｕ
５０２Ｄ エンコーダ
５０４Ｄ ＲＴＰＣ
５０６Ｄ デコーダ
５０８Ｄ ＲＴＰ
６００ ビデオシステム
６０２ エンコーダ
６０４ エンコーダキャッシュ
６０６ フレーム部分ストレージ
６０８ デコーダ
６１０ デコーダキャッシュ
６１２ フレーム部分ストレージ
６１４ シンクロナイザ
６１６ 送信機
７００ コンピューティング環境
７１０ 処理装置
７２０ メモリ
７４０ ストレージ
７５０ （複数の）入力装置
７６０ （複数の）出力装置
７７０ （複数の）通信接続
７８０ キャッシングを有するビデオエンコーダ／デコーダを実装するソフトウェア
【技術分野】
【０００１】
本発明は、一般に、ビデオ、画像、および他のデジタルメディアコンテンツの、エンコード、デコード、および処理をデジタルで行うための技術に関する。本発明は、詳細には、フレームキャッシング（ｆｒａｍｅ ｃａｃｈｉｎｇ）により、パケットロスを改善することに関する。
【背景技術】
【０００２】
この特許書類の開示の一部分は、著作権の保護を受けている資料を含む。この著作権の保有者は、特許開示のいずれかによる複写に対して、それが特許商標庁のファイルまたは記録に見られるとき、異議がないが、そうでなければ、何にせよすべての著作権を留保する。
【０００３】
デジタルビデオは、大量の記憶容量および伝送容量を消費する。一般的な未加工のデジタルビデオシーケンスは、毎秒１５または３０フレームを含む。各フレームは、数万または数十万の（ペル（ｐｅｌ）とも呼ばれる）ピクセルを含むことができる。各ピクセルは、ピクチャ（ｐｉｃｔｕｒｅ）の極めて小さな要素を表す。未加工の形式では、コンピュータは、１ピクセルを、３つのサンプルのからなる合計２４ビットのセットとして表す。例えば、ピクセルは、ピクセルのグレイスケール（ｇｒａｙｓｃａｌｅ）成分を定義する、１つの８ビット輝度サンプル（ルマ（ｌｕｍａ）サンプルとも呼ばれる）と、ピクセルの色成分を定義する、２つの８ビットクロミナンス（ｃｈｒｏｍｉｎａｎｃｅ）サンプル（クロマ（ｃｈｒｏｍａ）サンプルとも呼ばれる）を含むことができる。したがって、一般的な未加工のデジタルビデオシーケンスの１秒あたりのビット数またはビットレートは、毎秒５００万ビット以上である。
【０００４】
多くのコンピュータおよびコンピュータネットワークは、未加工のデジタルビデオを処理するためのリソースが不足している。そのため、エンジニアは、デジタルビデオのビットレートを下げるために（符号化またはエンコードとも呼ばれる）圧縮を使用する。圧縮は、ビデオをより低速のビットレート形式に変換することによって、ビデオを格納し送信するコストを減少させる。（デコードとも呼ばれる）解凍は、圧縮された形式から元のバージョンのビデオを再構成する。「コーデック」とは、エンコーダ／デコーダシステムである。ビデオの品質は損なわれないがビットレートの低下はビデオデータの（ときとしてエントロピと呼ばれる）変動性の固有の量によって制限される圧縮は、ロスレス（ｌｏｓｓｌｅｓｓ）（可逆）でありうる。あるいは、ビデオの品質は損なわれビットレートの達成可能な低下がより著しい圧縮は、ロッシー（ｌｏｓｓｙ）（不可逆）でありうる。ロッシー圧縮が情報の近似を確立し、ロスレス圧縮技術がその近似を表すために適用されるシステム設計において、ロッシー圧縮は、ロスレス圧縮と併せてしばしば使用される。
【０００５】
ビデオ圧縮技術は、一般に、「イントラピクチャ（ｉｎｔｒａｐｉｃｔｕｒｅ）」圧縮と「インターピクチャ（ｉｎｔｅｒｐｉｃｔｕｒｅ）」圧縮を含み、ピクチャは、例えば、プログレッシブスキャンビデオフレーム（ｐｒｏｇｒｅｓｓｉｖｅｌｙ ｓｃａｎｎｅｄ ｖｉｄｅｏ ｆｒａｍｅ）、（ビデオフィールドにおいて交互のラインを有する）インタレースビデオフレーム、または、インターレースビデオフィールドである。一般的に言えば、ビデオシーケンスは、所与のフレーム内および連続したフレーム間に、かなり量の冗長を含む。例えば、人間の眼は、連続したビデオフレームにおける他の点では同様の背景のわずかな違いには気付かない。圧縮は、送信されているビットストリーム内の冗長マテリアルの特定の部分を除去し、次いで、ピクチャが解凍されるときに受信側でそれらを追加して戻すことによって、このような冗長を活用する。ビデオフレームから抜き取られる２つの共通の冗長は、空間的および時間的なものである。空間的冗長は、単一のフレーム内の隣接ピクセル間に存在する。イントラフレーム（ｉｎｔｒａｆｒａｍｅ）またはＩフレームとして知られる空間的冗長を使用して圧縮されるフレームは、フレームそれ自体の内に画像を再構成するための必要なすべての情報を含み、つまり自己完結している。ＰフレームおよびＢフレームのような時間的冗長を使用するフレームは、デコードされる他のフレームからの情報を必要とする。Ｐフレーム（予測的にエンコードされるフレーム）は、エンコードされ、そして、先行のＩおよび／またはＰフレームからの情報を使用してデコードされる必要がある。Ｂフレーム（双方向で予測的にエンコードされるフレーム）は、先行および後続のＩおよびＰフレームの両方からの情報を使用してエンコードされる。動き検出は、参照フレームとして知られる先行してエンコードされた画像から作成された、動きの予測された画像とともに、固有の事項をエンコードすることにより、連続したビデオフレーム（フレーム間）における時間的冗長を除去する。参照フレームが失われた場合、後続の予測フレームは復号されることができず、すなわち、伝送エラーが、後続のフレームに伝播する。
【０００６】
プログレッシブフレームに関しては、イントラピクチャ圧縮技術が、（通常、Ｉフレームまたはキーフレームと呼ばれる）独立したフレームを圧縮し、インターピクチャ圧縮技術が、（通常、参照フレームまたはアンカーフレームと呼ばれる）先行および／または後続のフレームを参照して、（通常、予測フレーム、Ｐフレーム、またはＢフレームと呼ばれる）フレームを圧縮する。（自己完結した）Ｉフレーム、および（一般に先行フレームを参照する）Ｐフレームは、それら自体を参照フレームとすることができ、一方、先行および後続フレームの両方を参照する、Ｂフレームは、通常はそれら自体が参照として使用されることはまったくない。
【０００７】
結果のビデオが表示されるのに先立ってデータが圧縮されるとき、デコーダは、通常、圧縮の逆の操作を実行する。例えば、デコーダは、データを圧縮する際に、エントロピデコード、逆量子化、および逆変換を実行することができる。動き補償が使用される場合、デコーダ（およびエンコーダ）は、１つまたは複数の先行して再構成された（参照フレームとして現在使用されている）フレームから、フレームを再構成し、次いで、新しく再構成されたフレームが、より後のフレームの動き補償のための参照フレームとして使用されうる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ネットワークを介して送られたパケットは、欠損する、つまり廃棄されるおそれがある。この損失は、ランダムで予測できない形で起きる。さらに、ビデオ圧縮ストリームデータは遅延の影響を大変受けやすく、あまりに多くの遅延したパケットにより、飛び飛びの分断された信号が生じ、パケットを送られた順序と同じ順序になるように再組み立てする必要がある。伝送遅延の問題は、新しいＩフレームを再送する際にも起きるおそれがあり、新しいフレームは、失われた参照フレームを破棄したのと同じすべての問題の影響を受けやすい。さらに、非可逆符号化方式では、圧縮は、記憶および伝送についての目標ビットレートを満たすように設計されている。再構成される画像の質を低下させることにより、高圧縮が達成される。そのため、廃棄されまたは遅延されたパケットにより生じた余分な損失は、画像の質を許容水準より低くするおそれがある。
【０００９】
パケットロスに対処する能力は、損失を生じやすいノイズを伴うネットワークでリアルタイムビデオコーデック（ＲＴＣ）が良好に動作するために極めて重要である。ほとんどの既存のビデオコーデックは、参照フレームが失われたとき新しいＩフレームを要求することによってパケットロスに対処している。他の既存のビデオコーデックは、スライスベースの符号化を使用し、それによりシグナリングオーバーヘッド（ｓｉｇｎａｌｉｎｇ ｏｖｅｒｈｅａｄ）が増加する。図１は、新しいＩフレームを要求することによる、従来のパケットロスのリカバリを示す。
【００１０】
この従来技術の方法では、Ｉフレーム１０４が、デコーダ１０２で受け取られる。次いで、そのフレームは、後続の従属するＰフレーム１０６を解釈／再構成するために使用される。次の従属フレームであるＰフレーム１０８は、充分なパケットが、ばらばらの順序で受け取られるかまたは失われたとき、破棄される。次のＰフレーム１１０および後続のフレームを、もはや再構成することができない。（ここではデコーダ１０２により表されている）宛先ノードで、Ｉフレーム要求が生成され、（ここではエンコード１１４により表される）ソースノードに送られる。各後続のＰフレームまたはＢフレームを、新しいＩフレームが受け取られるまで再構成することができない。ソースノード１１４は、要求を受け取ると、新しいＩフレーム１１２を組み立て、通信チャネルを使用して、それを宛先ノード１０２に送る。新しいＩフレーム１１２を受け取った後、宛先チャネルは、後続のＰフレームを正常にデコードすることができる。しかし、この結果、最初の要求を送るために必要な時間と等しい遅延１１６に加え、Ｉフレームをエンコードする時間、および、Ｉフレームを宛先ノード１０２に送る時間が生じる。さらに、送信側と受信側が、大きな物理的距離によって隔てられていることがあり、この長い距離の移動により、顕著な遅延時間が発生し、それに対応するビデオの質の低下がもたらされる。
【００１１】
他の従来技術の方法では、Ｉフレーム１０４、１１２は、一定の間隔で送られる。Ｉフレーム１１２が、破棄または遅延により失われた場合、デコーダは、次のＩフレームが受け取られるまで、後続のＰフレーム１１０、１０８、１０６を不正確にはデコードせずに待機する。
【００１２】
したがって、非可逆パケットベースのネットワークを介して、圧縮されたビデオを送信するための、改良された方法およびシステムが必要とされる。
【課題を解決するための手段】
【００１３】
本明細書に記載のビデオコーデックは、エンコーダにおいてフレームキャッシュ（ｆｒａｍｅ ｃａｃｈｅ）を含み、デコーダにおいてそれに対応するフレームキャッシュを含み、それぞれのフレームキャッシュは、同期して動作する。デコーダキャッシュ内のフレームは、デコーダにおいてフレームを解釈するのを助けるために使用される。解釈するフレームを、エンコーダキャッシュに格納される同じフレームのコピーを用いて生成することができる。
【００１４】
システムの実装形態も提供される。それは、データパケットをフレーム内にエンコードするエンコーダ、および、フレームまたはその一部分を格納することができるエンコーダキャッシュを含む。それは、さらに、フレームまたはその一部分を同様に格納することができるデコーダキャッシュを有するデコーダを含む。デコーダは、パケットロスを検出することができる。いくつかの実施形態では、そのような損失が検出されたとき、エンコーダは、エンコーダキャッシュで格納されたフレームを使用してフレームをエンコードし、次いで、そのフレームは、デコーダキャッシュに格納されたフレームを使用してデコーダでデコードされる。
【００１５】
このキャッシングメカニズムは、下記の主要な特徴を提供する。
ａ）パケットロスのリカバリの際のより効率的な帯域幅の使用
ｂ）スライスベースの符号化に関連するシグナリングオーバーヘッドの除去
本発明の他の特徴および利点は、添付の図面を参照して行われる以下の実施形態の詳細な説明から明らかにされる。
【図面の簡単な説明】
【００１６】
【図１】フレームレベルのパケットロスのリカバリを示す従来技術の図である。
【図２】本明細書に記載のフレームキャッシングを利用するビデオを示すブロック図である。
【図３】本明細書に記載のフレームキャッシングを利用するビデオデコーダを示すブロック図である。
【図４】フレームキャッシングを利用してパケットロスからリカバリするための例示的方法を示すフローチャートである。
【図５Ａ】フレームをキャッシングするエンコーダ、およびそれと同じフレームをキャッシングするデコーダを示す、フレームレベルの図である。
【図５Ｂ】デコーダに到着する破棄されたＰフレームを示すフレームレベルの図である。
【図５Ｃ】Ｐフレームを解釈するために、キャッシュされたフレームを使用するデコーダを示すフレームレベルの図である。
【図５Ｄ】フィードバック経路を介したパケットロスの報告を示すブロック図である。
【図６】ビデオエンコーダ／デコーダキャッシングを実装するための適切な方法を示すフローチャートである。
【図７】図２および３のビデオエンコーダ／デコーダのための適切なコンピューティング環境を示すブロック図である。
【発明を実施するための形態】
【００１７】
以下の説明は、優雅なパケットロスのリカバリ、および効率的な帯域幅の利用の効率的な組合せを可能にするように設計された、ビデオエンコーダとビデオデコーダの双方におけるフレームキャッシュの実装に関する。フレームキャッシュの例示的適用は、画像またはビデオエンコーダおよびデコーダにおいて行われる。したがって、フレームキャッシュを、一般的な画像またはビデオエンコーダおよびデコーダのコンテキストで説明されるが、代替として、後で説明するこの例示的装置とは詳細が異なることがある他の様々な画像およびビデオコーデックのエンコーダおよびデコーダに組み込むこともできる。
【００１８】
１．汎用ビデオエンコーダおよびデコーダ
図２は、一般的なビデオエンコーダ２００のブロック図であり、図３は、一般的ビデオデコーダ３００のブロック図であり、それらにフレームキャッシュが組み込まれる。
【００１９】
エンコーダおよびデコーダ内のモジュール間に示される関係は、エンコーダおよびデコーダにおける情報の主な流れを示し、他の関係は単純化するために図示していない。特に、図２および３は、一般に、ビデオシーケンス、フレーム、マクロブロック（ｍａｃｒｏｂｌｏｃｋ）、およびブロックなどに使用されるエンコーダ設定、モード、およびテーブルなどを示すサイド情報を図示していない。このようなサイド情報は、通常、サイド情報のエントロピ符号化の後に、出力ビットストリームとして送られる。出力ビットストリームのフォーマットは、Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ Ｖｉｄｅｏフォーマットまたは他のフォーマットとすることができる。
【００２０】
所望の圧縮の実装形態およびタイプに応じて、エンコーダ２００またはデコーダ３００のモジュールについて、追加、省略、複数のモジュールへの分割、他のモジュールとの結合、および／または、同様のモジュールとの置換を行うことができる。代替実施形態では、異なるモジュール、および／または他の構成のモジュールを有する、エンコーダまたはデコーダが、ここに記載の技術の１つまたは複数を実行する。
【００２１】
Ａ．ビデオエンコーダ
図２は、一般的なビデオエンコーダシステム２００のブロック図である。エンコーダシステム２００は、現行のフレーム２０５を含むビデオフレームのシーケンスを受け取り、圧縮されたビデオ情報２９５を出力として生成する。ビデオエンコーダの特定の実施形態では、通常、一般的エンコーダ２００の変形形態または補足されたバージョンを使用する。
【００２２】
エンコーダシステム２００は、予測されたフレームとキーフレームを圧縮する。図２では、説明のために、エンコーダシステム２００を介したキーフレームの経路と、順方向予測（ｆｏｒｗａｒｄ−ｐｒｅｄｉｃｔｅｄ）フレームの経路を示している。エンコーダシステム２００のコンポーネントの多くは、キーフレームと予測フレームの両方を圧縮するために使用される。これらのコンポーネントによって行われる正確な動作は、圧縮されている情報のタイプに応じて大きく異なる。
【００２３】
（Ｐフレーム、Ｂフレーム（双方向予測）、またはフレーム間符号化（ｉｎｔｅｒ−ｃｏｄｅｄ）フレームであり得る）予測フレームは、１つまたは複数の他のフレームからの予測（または差異）の観点から表される。予測残差は、予測されたものと元のフレームの間の差異である。これに対して、（Ｉフレームまたはフレーム内符号化フレームとも呼ばれる）キーフレームは、他のフレームを参照することなく圧縮される。
【００２４】
現行のフレーム２０５が順方向予測フレームの場合、動き検出器２１０が、現行フレーム２０５の、マクロブロックまたはピクセルの他のセットの動きを、フレームストア（ｆｒａｍｅ ｓｔｏｒｅ）２２０にバッファされた再構成された先行フレームである参照フレーム２２５に関連して推定する。代替実施形態では、参照フレームは、より後のフレームとすることができ、あるいは、現行フレームは、双方向で予測されうる。動き検出器２１０は、動きベクトルなどの動き情報２１５をサイド情報として出力する。動き補償器２３０は、動き情報２１５を、再構成された先行フレーム２２５に適用して、動き補償された現行フレーム２３５を形成する。ただし、この予測は、めったに完全ではなく、動き補償された現行フレーム２３５と元の現行フレーム２０５の差異は、予測残差２４５である。あるいは、動き検出器２１０および動き補償器２３０は、他のタイプの動き検出／補償を適用する。
【００２５】
周波数変換器２６０は、空間領域のビデオ情報を、周波数領域（すなわちスペクトル）のデータに変換する。ブロックベースのビデオフレームでは、周波数変換器２６０は、離散コサイン変換（「ＤＣＴ」）と同様の性質を有する、後の節で説明する変換を適用する。いくつかの実施形態では、周波数変換器２６０は、周波数変換を、キーフレームについての空間予測残余のブロックに適用する。周波数変換器２６０は、８×８、８×４、４×８、または他のサイズの周波数変換を適用することができる。
【００２６】
次いで、量子化器２７０が、空間データ係数のブロックを量子化する。量子化器２７０は、均一なスカラ量子化を、フレーム毎または他の単位ごとに異なる刻み幅で、スペクトルデータに適用する。あるいは、量子化器２７０は、他のタイプの量子化、例えば、非均一、ベクトル、または非適応の量子化をスペクトルデータ係数に適用する、または、周波数変換を使用しないエンコーダシステムにおいて空間領域データを直接量子化する。適応的量子化に加えて、エンコーダ２００は、レート制御のために、フレームドロップ（ｆｒａｍｅ ｄｒｏｐｐｉｎｇ）、適応フィルタリング、または他の技術を使用することができる。
【００２７】
再構成された現行のフレームが、後続の動き検出／補償のために必要とされるとき、逆量子化器２７６は、量子化スペクトルデータ係数に対して逆量子化を実行する。次いで、周波数逆変換器２６６が、周波数変換器２６０の逆の操作を実行し、（予測されたフレームに対する）再構成された予測残差、または再構成されたキーフレームを生成する。現行フレーム２０５がキーフレームであった場合、再構成されたキーフレームは、再構成された現行フレーム（図示せず）と見なされる。現行フレーム２０５が、予測フレームであった場合、再構成された予測残差は、動き補償された現行フレーム２３５に加えられて、再構成された現行フレームが形成される。フレームストア２２０は、再構成された現行フレームを、次のフレームを予測する際に使用するためにバッファする。いくつかの実施形態では、エンコーダ２００は、フレームのブロックにおける不連続を適応的に平滑化するために、デブロッキングフィルタ（ｄｅｂｌｏｃｋｉｎｇ ｆｉｌｔｅｒ）を再構成されたフレームに適用する。
【００２８】
エントロピ符号化器２８０は、量子化器２７０の出力、ならびにサイド情報（例えば、動き情報２１５、量子化刻み幅）を圧縮する。典型的エントロピ符号化技術には、算術符号化、差分符号化、ハフマン符号化（Ｈｕｆｆｍａｎ ｃｏｄｉｎｇ）、ランレングス符号化（ｒｕｎ ｌｅｎｇｔｈ）符号化、ＬＺ符号化、辞書型符号化、およびそれらの組合せが含まれる。エントロピ符号化器２８０は、通常、異なる種類の情報（例えば、ＤＣ係数、ＡＣ係数など）に対して異なる符号化技術を使用し、ある特定の符号化技術において複数のコード表のうちから選択をすることができる。
【００２９】
エントロピ符号化器２８０は、ビデオ情報２９５をバッファ２９０に入れる。バッファレベルの標識が、ビットレート適応モジュールにフィードバックされる。圧縮されたビデオ情報２９５は、バッファ２９０から一定または比較的一定のビットレートで消耗し、そのビットレートで後続のストリーミングのために格納される。あるいは、エンコーダシステム２００は、圧縮されたビデオ情報２９５を直ちにストリームし圧縮を続ける。
【００３０】
バッファ２９０より先または後に、圧縮されたビデオ情報２９５は、ネットワークを介する送信のためにチャネル符号化されうる。チャネル符号化は、エラー検出および訂正データを、圧縮されたビデオ情報２９５に適用することができる。
【００３１】
Ｂ．ビデオデコーダ
図３は、一般的なビデオデコーダシステム３００のブロック図である。デコーダシステム３００は、圧縮されたビデオフレームのシーケンスに関する情報３９５を受け取り、再構成されたフレーム３０５を含む出力を生成する。ビデオデコーダのいくつかの特定の実施形態は、通常、一般的なデコーダ３００の変形形態または補足されたバージョンを用いる。
【００３２】
デコーダシステム３００は、予測フレームおよびキーフレームを圧縮する。図３では、説明のために、デコーダシステム３００を介するキーフレームの経路と、順方向予測フレームの経路を示している。デコーダシステム３００のコンポーネントの多数は、キーフレームと予測フレームの両方を圧縮するために使用される。これらのコンポーネントにより行われる正確な動作は、圧縮される情報のタイプによって変化しうる。
【００３３】
バッファ３９０は、圧縮されたビデオシーケンスに関する情報３９５を受け取り、受け取った情報をエントロピデコーダ３８０に使用可能にする。バッファ３９０は、時間に対してかなり一定のレートで情報を受け取り、また、帯域幅または送信における短期の変動を平滑化するためのジッタバッファを含む。バッファ３９０は、再生バッファおよび他のバッファも含むことができる。あるいは、バファ３９０は、変動するレートで情報を受け取る。圧縮されたビデオ情報３９５は、バッファ３９０に到達する前、またはバッファ３９０から離れた後、またはその両方において、エラー検出および訂正のためにデコードされ処理されうる。
【００３４】
エントロピデコーダ３８０は、エントロピ符号化された量子化データ、ならびにエントロピ符号化されたサイド情報（例えば、動き情報、量子化刻み幅）をデコードし、通常は、エンコーダ２００で行われたエントロピ符号化の逆を行う。エントロピデコード技術には、算術デコード、差分デコード、ハフマンデコード、ランレングスデコード、ＬＺデコード、辞書型デコード、およびそれらの組合せが含まれる。エントロピデコーダ３８０は、異なる種類の情報（例えば、ＤＣ係数、ＡＣ係数、異なる種類のサイド情報）に対して異なるデコード技術を使用し、ある特定のデコード技術において複数のコード表のうちから選択をすることができる。
【００３５】
再構成されるフレーム３０５が、前進予測フレームである場合、動き補償器３３０は、動き情報３１５を参照フレーム３２５に適用して、再構成されるフレーム３０５の予測３３５を形成する。例えば、動き補償器３３０は、マクロブロック動きベクトル（ｍａｃｒｏｂｌｏｃｋ ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を使用して、参照フレーム３２５におけるマクロブロックを見つける。フレームバッファ３２０は、先行の再構成されたフレームを参照フレームとして使用するために格納する。あるいは、動き補償器は、他のタイプの動き補償を用いる。動き補償器３３０による予測は、完全であることは稀であり、したがって、デコーダ３００は、予測残差３４５の再構成もする。
【００３６】
デコーダ３００が、後続の動き補償のために再構成されたフレームを必要とするとき、フレーム３２０は、次のフレームを予測する際に使用するために、再構成されたフレーム３０５をバッファする。いくつかの実施形態では、エンコーダ２００は、デブロッキングフィルタを、再構成されたフレーム３０５に適用して、フレームのブロックにおける不連続を適応的に平滑化する。
【００３７】
逆量子化器３７０は、エントロピデコードされたデータを逆量子化する。一般に、逆量子化器３７０は、均一のスカラ逆量子化を、エントロピデコードされたデータに、フレーム毎または他の単位で異なる刻み幅で適用する。あるいは、逆量子化３７０は、他のタイプの逆量子化、例えば、非均一、ベクトル、または非適応量子化をデータに適用する、または、周波数逆変換を使用しないデコーダシステムにおける空間領域データを直接逆量子化する。
【００３８】
周波数逆変換器３６０は、量子化された周波数領域データを、空間領域ビデオ情報に変換する。ブロックベースのビデオフレームについて、周波数逆変換器３６０は、後の節で説明される逆変換を適用する。いくつかの実施形態では、周波数逆変換器３６０は、キーフレームについての空間予測残差のブロックに、周波数逆変換を施す。周波数逆変換器３６０は、８×８、８×４、４×８、またの他のサイズの周波数逆変換を施すことができる。
【００３９】
Ｃ．フレームキャッシング
本明細書に記載のビデオコーデックアーキテクチャにおけるフレームキャッシングを使用する実装形態では、参照フレームは、エンコーダおよびデコーダの両方で順次キャッシュされることが好ましい。参照フレームが失われたとき、後続の従属フレームは、デコーダにおいてキャッシュされた適切な参照フレームを使用してデコードされうる。これにより、以下の利益がもたらされる。
【００４０】
Ａ）より効率的な帯域幅の利用：従来技術の方法は、Ｉフレームが生成されエンコーダに送られることを必要とする。本方法では、特別なタイプのフレーム、すなわちＳＰフレームが、デコーダに送られ、次いで、必要とされるまでキャッシュされることを可能にする。ＳＰフレームは、一般に、同じ品質のＩフレームよりも少ないビット数で符号化することができ、したがって、等価のＩフレームを使用するよりも小さい帯域幅を使用する。
【００４１】
Ｂ）より速いエラーリカバリ：パケットロスが発生したとき、ＳＰフレームがデコーダにおいて既にキャッシュされていることが好ましく、これにより、ほとんど遅延時間なしに、ストリームにおける次のＰフレームを解釈することを可能にする。
【００４２】
２．例示的方法の概要
ここに記載の実施形態は、デコーダにおけるフレームをキャッシュし、次いで、キャッシュしたフレームを使用して、破棄されたまたは失われている参照フレームに基づいてＰフレームおよびＢフレームを再構成するための技術およびツールを含む。キャッシュを、ビデオデコーダ３００（図３）の一部分として、またはビデオエンコーダ２００（図２）の一部分として組み込むことができ、好ましくはその両方において組み込むことができる。パケットロスがデコーダによって検出されると、デコーダは、エンコーダ２００にメッセージを送り、次いで、エンコーダ２００は、共有されたキャッシュされたフレームの１つに基づいて新しい参照フレームを生成する。次いで、生成された参照フレームは、デコーダに送られる。キャッシュされたフレームは、別の参照フレームがデコーダに到着するまで、生成されたフレームおよび後続の従属フレームをデコードするためにデコーダで使用される。本明細書に記載のフローチャートの要素は、例に過ぎず、記載の技術に応じて、他のフローチャート要素を使用することができる。さらに、フローチャート要素は、記載の技術およびツールに応じて、異なる順序で行い、あるいは特定の処理ブロックを省略することができる。
【００４３】
記載の技術およびツールは、互いに組み合わせてまたは他の技術およびツールと組み合わせて、あるいは別個に使用されうる。
【００４４】
図４を参照すると、フローチャート４００は、本明細書に開示の方法の簡潔な概観を示している。プロセスブロック４０２で、ネットワークを介して送信されるビデオ信号の一部分がパケットに割り当てられる。プロセスブロック４０４で、エンコーダは、パケットの少なくとも一部をフレーム内にエンコードする。これらのフレームは、ＩフレームおよびＰフレームのような参照フレーム３２５からなり、他の任意のフレームに対する参照として使用されないＢフレームからなることもある。スキップフレーム（ｓｋｉｐ ｆｒａｍｅ）のような代替タイプのフレームも、フレーム内にエンコードされうる。任意選択のプロセスブロック４０６で、エンコーダでフレームをキャッシュすることができ、このフレームは、一般的には参照フレームである。フレームは、キャッシュされた場合、「Ｃａｃｈｅｄ−Ｆｒａｍｅ」（ＣＦ）タイプがそのフレームヘッダにおいて割り当てられる。次いで、キャッシュされたフレームは、プロセスブロック４０８で、他のフレームと一緒に送信される。ブロック４１０で、フレームは、デコーダに到着した後、デコーダキャッシュ内にキャッシュされる。通常のキャッシュフレームのタイプは、ＰフレームおよびＩフレームである。
【００４５】
後続参照フレームが失われた場合、プロセスブロック４１２に示すように、キャッシュされたフレームを、後続の従属フレームを解凍するために使用することができる。フローチャート４００は、単に１つの例示的実施形態を示しているに過ぎず、何らかの限定をするものとして解釈されるべきではない。例えば、判断ブロック４０６でのエンコーダに関連するキャッシュは任意選択である。方法４００を、図２および図３に示されるように、ビデオコーデックで実装することができ、ビデオコーデックを、ソフトウェア、ハードウェア、または両方の組合せで実装することができる。
【００４６】
３．フレームをキャッシュするための例示的方法
図５Ａ〜５Ｄは、ノイズを伴うネットワークにおいてビデオコーデックの最適なパフォーマンスを可能にするためにフレームをキャッシュする例示的方法を示す。図５Ｄを参照すると、例示的実施形態では、フレームは、ＲＴＰ（リアルタイム転送プロトコル）５０８Ｄなどの主要チャネルを介して、エンコーダ５０２Ｄからデコーダ５０６Ｄにフレームが送信されている。インターネットは、しばしば、パケットを欠損したり、パケットをばらばらの順序で送達することがある。パケットは、あるランダムな時間量で遅延することもあり、これによりパケットが使用できないようになることもある。パケットロスは、デコーダ５０６Ｄによって検出され、フィードバック経路を介して、デコーダからエンコーダ５０２Ｄにその信号が送られる。メッセージを正しく再構成するために、いくつかの実施形態では、ＲＴＰ５０８Ｄヘッダが、情報およびシーケンス番号を含み、この両方により、受信側が、パケットを正しく並べ変え、失われたパケットの番号を決定することを可能にする。ＲＴＰ５０８Ｄは、その制御プロトコル（ＲＴＰＣ）５０４Ｄによって増強され、データの送達を監視するために使用することができるフィードバック経路を提供するために使用される。各データパケットは、シーケンス番号を有し、通常、シーケンス番号は、各後続データパケットにつき１つ増分される。例示的実施形態では、シーケンス番号が受け取られないとき、パケットロスは、デコーダ５０６Ｄによって検出される。デコーダ５０６Ｄは、パケットロスを検出すると、フィードバック経路５０４Ｄを介してメッセージを送り、どのパケット（または複数のパケット）が失われたかをエンコーダ５０２Ｄに通知する。いくつかの実施形態では、失われた最初のパケットについての情報のみが供給される。いくつかの実施形態では、廃棄されたパケットの番号、または失われた特定のパケットのリストなどの追加の情報も供給される。好ましくは、パケットロスの位置が、最も初期のパケットロスのタイムスタンプを使用して報告ウィンドウに伝えられる。この情報により、エンコーダ５０２Ｄが、どのキャッシュされた参照を使用するかを決定できるようになる。
【００４７】
図５Ａを参照すると、エンコーダ５０２Ａは、定期的にフレームをフレームキャッシュ５０４Ａにキャッシュしている。どのフレームがキャッシュされるか、どのくらいの頻度でキャッシュを行うべきか、ならびに、一度にキャッシュできるべきフレーム数は、実装形態に大きく依存する。いくつかの実施形態では、キャッシュされるフレームは、参照フレーム、すなわちＰフレームおよびＩフレームである。他のフレームタイプをキャッシュすることもできる。キャッシュされたフレーム５０６Ａ（またはそのコピー）はまた、デコーダ５１２Ａに送られる。エンコーダキャッシュ５０４Ａにも格納される、このようなフレームは、そのヘッダ内でフレームタイプＣＦ（キャッシュされたフレーム）として定義される。いくつかの実施形態では、このヘッダにより、後で使用するためにこの特定のフレームをデコーダキャッシュ５１０Ａに格納すべきであることを、デコーダ５１２Ａに知らせることによって、エンコーダ５０２Ａとデコーダ５１２Ａの同期が可能になる。下記の表１は、ＣＦ（キャッシュされたフレーム）タイプを含む、フレームタイプコードの例示的実施形態を示している。
【００４８】
【表１】
【００４９】
タイプＣＦのフレーム５０８Ａは、デコーダ５１２Ａに到達すると、デコーダフレームキャッシュ５１０Ａに格納される。タイプＣＦの各フレームをデコーダ５１２Ａにおいて格納することは、エンコーダおよびデコーダのフレームキャッシュ５０４Ａおよび５１０Ａを同期させる１つの方法である。ただし、これらのフレームキャッシュを同期させる他の方法も企図される。
【００５０】
パケットロス５０２Ｂがデコーダ５０４Ｂで検出されたとき、フィードバック経路５０４Ｄを使用して、その報告がエンコーダ５０２Ａに返される。この報告は、好ましくは、エンコーダ５０２Ａが参照のために適切なキャッシュされたフレーム５０４Ａを選ぶことをできるようにするタイムスタンプ情報を含む。他の実施形態では、最新のキャッシュされたフレームが使用される。キャッシュされたフレームが選ばれると（５０４Ｃ）、そのフレームは、エンコーダ５０２Ｃによって、次のフレーム５０６Ｃをエンコードするために使用される。次のフレーム５０６Ｃは、好ましくは、Ｐフレームであるが、Ｉフレームおよび他のフレームタイプをエンコードすることもできる。キャッシュされたフレーム５０６Ｃは、「Ｓｕｐｅｒ−Ｐ」フレーム（ＳＰフレーム）として知られ、そのヘッダでそのように示される。ＳＰフレームの例示的フレームタイプコードワードは、上記の表１に示されている。
【００５１】
デコーダ５１２Ｃは、ＳＰフレーム５０８Ｃを受け取ると、そのローカルでキャッシュされたフレーム５１０Ｃを使用して、ＳＰフレーム５０８Ｃを解凍されたフレーム（Ｕフレーム）５１４Ｃ内にデコードする。この方法を使用すると、デコーダ５１２Ｃにおけるリカバリ時間は、パケットロスイベントとＳＰフレームの到着の間の期間である。この生成されたＳＰフレーム５０８Ｃが、送信中に失われた場合、デコーダ５１２Ｃは、（一般に、タイプＰ、ＳＰ、またはＩの）新しい参照フレームの到着まで、パケットロスの報告を送り続ける。パケットロスからの実際のリカバリ時間は、主にパケットロス報告の間隔の関数となる。
【００５２】
いくつかの実装形態では、エンコーダ５０２Ａは、フレーム５０４Ａをキャッシュし、キャッシュされたフレーム５０６Ａのコピーを、デコーダに定期的に送る。キャッシュされたフレームが送られる時間間隔は、実装形態に大きく依存する。いくつかの実装形態では、等しい間隔でフレームをキャッシュすることができる。他の実装形態では、ネットワークの速度やネットワークが経験するロスの量などのそれ自体のシステム変数に依存する間隔でフレームをキャッシュすることができる。
【００５３】
４．例示的システムの実施形態
図６は、デコーダおよびエンコーダベースのフレームキャッシングを実装することができる、ビデオシステム６００の他の例示的実施形態を示す。本発明を、様々な汎用または専用のビデオシステムで実装することができ、ビデオシステム６００は、本発明の使用または機能の範囲に関して、どのような限定も示唆するものでもない。
【００５４】
ビデオシステムは、少なくとも１つのエンコーダ６０２を含む。このエンコーダは、さらに、エンコーダキャッシュ６０４を含む。図示の実施形態では、キャッシュは、エンコーダ６０２内に存在するが、他の実装形態では、ビデオシステム内の他の場所に存在することがある。エンコーダキャッシュ６０４は、１つまたは複数のビデオフレーム６０６の部分を格納することが可能である。限定ではなく示唆として、これらのフレームの部分は、いくつかのブロック、マクロブロック、いくつかのスライス、フレーム全体、フレームのグループ、または当業者が想定できる他の任意のフレームの区分から構成されうる。エンコーダキャッシュ６０４は、単に１つのフレーム部分、２つのフレーム部分、または与えられた実装形態に望ましい任意の数のフレーム部分をキャッシュすることができる。ビデオシステム６００はまた、デコーダ６０８を含む。エンコーダ６０２と同様に、デコーダ６０８は、１つまたは複数のビデオフレーム６１２の部分を格納するために使用される、デコーダキャッシュ６１０を含む。これらのビデオフレーム部分は、１つまたは複数のブロック、マクロブロック、スライス、フレーム全体、フレームのグループ、または当業者が想定することができる他のフレームの区分を含むことができる。デコーダキャッシュ６１０を、１つのフレーム部分、２つのフレーム部分、または他の任意の数のフレーム部分を格納するように構成することができる。
【００５５】
ビデオシステム６００はまた、エンコーダ６０４およびデコーダ６１０が、実質的に同じ情報を含むことを保証するために使用される、シンクロナイザ６１４を含む。前述のように、シンクロナイザは、エンコーダ６０２によって施される、いくつかの特定のフレームまたはフレームの部分に付加された一意のフレームヘッダを含むことができ、そのフレームヘッダは、特定のフレームまたはフレームの部分がキャッシュされるべきことをデコーダ６０８に通知する。例えば、あるフレームがエンコーダキャッシュ６０４に格納され、また、デコーダ６０８にも送られる場合がある。そのフレームは、エンコーダキャッシュ６０４に格納されたそのコピーが存在することを示す、特有のＣＦ（Ｃａｃｈｅｄ Ｆｒａｍｅ）ヘッダを有することができる。デコーダ６０８がフレームのデコードを困難または不可能にするパケットロスまたは他の破棄を検出したとき、エンコーダキャッシュ６０４に格納されたフレームからの、エンコーダ６０２によってエンコードされる後続のフレームは、このフレームがデコーダキャッシュ６１０におけるフレームからデコードすることができることを示すようにマーク付けされうる。いくつかの実装形態では、デコーダキャッシュ６１０において複数のフレームを格納することができ、このような場合、ヘッダは、どのキャッシュされたフレームが使用されるべきかを決定するための充分な他の情報も任意選択で含むことができる。他の同期化の方法も企図される。送信機６１６が、エンコーダ６０２からデコーダ６０８にフレームを送信する。
【００５６】
５．コンピューティング環境
上記のフレームキャッシングの実装形態を、特に例として、コンピュータ、画像およびビデオ録画、送受信装置、携帯ビデオプレイヤビデオ会議、ウェブビデオストリーミングアプリケーションなどを含む、画像およびビデオ信号処理が実行される、任意の様々な装置で実施することができる。画像およびビデオ符号化技術は、ハードウェア回路（例えば、ＡＳＩＣ、ＦＰＧＡなどの回路）、ならびに、図７に示されるような、コンピュータまたは他のコンピューティング環境において実行される（中央処理装置（ＣＰＵ）、専用グラフィックプロセッサ、またはビデオカードなどで実行される）画像およびビデオ処理ソフトウェアで実装することができる。
【００５７】
図７は、上述のフレームキャッシングを実装することができる、適切なコンピューティング環境７００の一般的な例を示す。本発明を、様々な汎用または専用のコンピューティング環境で実装することができ、コンピューティング環境７００は、本発明の使用または機能の範囲に関して、どのような限定も示唆するものでもない。
【００５８】
コンピューティング環境７００は、少なくとも１つの処理装置７１０およびメモリ７２０を含む。この最も基本的構成７３０は、破線内に含まれている。処理装置７１０は、コンピュータ実行可能命令を実行し、現実または仮想のプロセッサとすることができる。多重処理システムにおいては、複数の処理装置が、コンピュータ実行可能命令を実行して処理能力を高める。メモリ７２０は、揮発性メモリ（例えば、レジスタ、キャッシュ、ＲＡＭなど）、不揮発性メモリ（例えば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなど）、またはこの２つの何らかの組合せとすることができる。メモリ７２０は、上述のエンコーダ／デコーダキャッシングを実装するソフトウェア７８０を格納する。
【００５９】
コンピューティング環境は、追加の特徴を有することができる。例えば、コンピューティング環境７００は、ストレージ７４０、１つまたは複数の入力装置７５０、１つまたは複数の出力装置７６０、および１つまたは複数の通信接続７７０を含む。バス、コントローラ、またはネットワークなどの相互接続メカニズム（図示せず）は、コンピューティング環境７００のコンポーネントを相互接続する。オペレーティングシステムソフトウェア（図示せず）は、一般に、コンピューティング環境７００で実行される他のソフトウェアのための動作環境を提供し、コンピューティング環境７００のコンポーネントの活動を調整する。
【００６０】
ストレージ７４０は、リムーバルまたは固定とすることができ、また、磁気ディスク、磁気テープまたはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、あるいは、情報を格納するために使用可能でコンピューティング環境７００においてアクセスすることができる他の任意の媒体を含む。ストレージ７４０は、エンコーダ／デコーダキャッシング方式を実装するソフトウェア７８０のための命令を格納する。
【００６１】
（複数の）入力装置７５０は、キーボード、マウス、ペン、またはトラックボールなどのタッチ入力装置、音声入力装置、スキャン装置、あるいは、コンピューティング環境７００に入力を提供する他の装置とすることができる。オーディオに関しては、（複数の）入力装置７５０は、アナログまたはデジタル形式でオーディオ入力を受け入れるサウンドカードまたは同様のデバイス、あるいは、オーディオサンプルをコンピューティング環境７００に提供するＣＤ−ＲＯＭリーダとすることができる。（複数の）出力装置７６０は、ディスプレイ、プリンタ、スピーカ、ＣＤライタ、あるいは、コンピューティング環境７００からの出力を提供する他の装置とすることができる。
【００６２】
（複数の）通信接続７７０は、通信媒体を介して他のコンピューティングエンティティと通信することを可能にする。通信媒体は、コンピュータ実行可能命令、圧縮されたオーディオまたはビデオ情報、または被変調データ信号における他のデータなどの情報を搬送する。被変調データ信号は、情報を信号にエンコードするようにセットまたは変更された１つまたは複数の信号特性を有する信号である。通信媒体には、限定ではなく例として、電気、光、ＲＦ、赤外線、音響、または他の搬送波によって実装される有線または無線技術が含まれる。
【００６３】
本明細書におけるエンコーダ／デコーダフレームキャッシング技術を、コンピュータ可読媒体の一般的なコンテキストで記述することができる。コンピュータ可読媒体は、コンピューティング環境７００においてアクセスすることができる任意の使用可能な媒体である。限定ではなく例として、コンピューティング環境７００では、コンピュータ可読媒体には、メモリ７２０、ストレージ７４０、通信媒体、およびこれらの任意の組合せが含まれる。
【００６４】
本明細書におけるエンコーダ／デコーダフレームキャッシングを、対象の現実または仮想のプロセッサ上のコンピューティング環境で実行されるプログラムモジュールに含まれるような、コンピュータ実行可能命令の一般的なコンテキストで記述することができる。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象データ型を実装する、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、およびデータ構造などが含まれる。プログラムモジュールの機能を、様々な実施形態の必要に応じて、組み合わせることも、プログラムモジュール間で分割することもできる。プログラムモジュールのためのコンピュータ実行可能命令を、ローカルまたは分散コンピューティング環境で実行することができる。
【００６５】
説明のために、上述の詳細な説明では、「決定する（ｄｅｔｅｒｍｉｎｅ）」、「送信する（ｔｒａｎｓｍｉｔ）」、「エンコード」、「デコード」、「適用する（ａｐｐｌｙ）」などの言葉を使用して、コンピューティング環境におけるコンピュータの動作を記述している。これらの言葉は、コンピュータによって行われる動作の高度に抽象化したものであり、人間によって行われる行為と混同されるべきではない。これらの言葉に対応する実際のコンピュータの動作は、実装形態に応じて異なる。
【００６６】
本発明の原理を適用することができる多数の可能な実施形態に鑑みて、詳述された実施形態は、例示に過ぎず、本発明の範囲を限定するものとして解釈されるべきではない。むしろ、本発明では、そのようなすべての実施形態が、添付の特許請求の範囲とその均等物の範囲および趣旨に含まれるものとして請求される。
【符号の説明】
【００６７】
１０２ デコーダ
１０４ Ｉフレーム
１０６ Ｐフレーム
１０８ Ｐフレーム
１１０ Ｐフレーム
１１２ Ｉフレーム
１１４ エンコーダ
１１６ リカバリ時間
２００ エンコーダ
２０５ 現行フレーム
２１０ 動き推定器
２１５ 動き情報
２２０ フレームストア
２２５ 参照フレーム
２３０ 動き補償器
２３５ 動き補償された現行フレーム
２４５ 残差
２６０ 周波数変換器
２６６ 周波数逆変換器
２７０ 量子化器
２７６ 逆量子化器
２８０ エントロピ符号化器
２９０ バッファ
２９５ 圧縮されたビデオ情報
３００ デコーダ
３０５ 再構成されたフレーム
３２０ フレームストア
３２５ 参照フレーム
３３０ 動き補償器
３３５ 予測フレーム
３４５ 再構成された残差
３６０ 周波数逆変換器
３７０ 逆量子化器
３８０ エントロピデコーダ
３９０ バッファ
３９５ 圧縮されたビデオ情報
４００ フローチャート
４０２ 信号の一部分をパケットに割り当てる
４０４ パケットをフレーム内にエンコードする
４０６ エンコーダにおいてフレームをキャッシュする
４０８ フレームをデコーダに送信する
４１０ デコーダにおいてフレームをキャッシュする，Ｐフレーム，Ｉフレーム
４１２ キャッシュされたフレームに基づいてフレームを解釈する
５０２Ａ エンコーダ
５０４Ａ ＣＦ
５０６Ａ ＣＦ
５０８Ａ ＣＦ
５１０Ａ ＣＦ
５１２Ａ デコーダ
５０２Ｂ パケットロス
５０４Ｂ デコーダ
５０２Ｃ エンコーダ
５０４Ｃ ＣＦ
５０６Ｃ ＳＰ
５０８Ｃ ＳＰ
５１０Ｃ ＣＦ
５１２Ｃ デコーダ
５１４Ｃ Ｕ
５０２Ｄ エンコーダ
５０４Ｄ ＲＴＰＣ
５０６Ｄ デコーダ
５０８Ｄ ＲＴＰ
６００ ビデオシステム
６０２ エンコーダ
６０４ エンコーダキャッシュ
６０６ フレーム部分ストレージ
６０８ デコーダ
６１０ デコーダキャッシュ
６１２ フレーム部分ストレージ
６１４ シンクロナイザ
６１６ 送信機
７００ コンピューティング環境
７１０ 処理装置
７２０ メモリ
７４０ ストレージ
７５０ （複数の）入力装置
７６０ （複数の）出力装置
７７０ （複数の）通信接続
７８０ キャッシングを有するビデオエンコーダ／デコーダを実装するソフトウェア
【特許請求の範囲】
【請求項１】
エンコーダが実施する方法であって、
キーフレーム及び予測フレームを含むエンコードされたフレームのシーケンスを送信するステップであって、前記エンコードされたフレームの少なくとも一部は、当該フレームがデコーダでキャッシュされるフレームであることを示すフレームタイプコード有するステップと、
パケットロス検出信号を受信するステップと、
前記パケットロス検出信号に応じて、前記キャッシュされたフレームの少なくとも１つを参照して生成された、エンコードされたフレームを送信するステップと
を備えることを特徴とする方法。
【請求項２】
前記エンコードされたフレームの少なくとも一部は、キーフレームであることを特徴とする請求項１に記載の方法。
【請求項３】
前記エンコードされたフレームの少なくとも一部は、前記関連するフレームがキャッシュされないことを示すフレームタイプコードを有することを特徴とする請求項１に記載の方法。
【請求項４】
当該フレームが前記デコーダでキャッシュされることを示すタイプコードを有するフレームが、定期的に送信されることを特徴とする請求項１に記載の方法。
【請求項５】
前記デコーダでキャッシュされるフレームの送信間隔は、固定された間隔、または変動する間隔であることを特徴とする請求項４に記載の方法。
【請求項６】
前記エンコーダで、当該フレームが前記デコーダでキャッシュされることを示すタイプコードを有するフレームをキャッシュするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項７】
前記パケットロス検出信号が、フィードバック経路を介して受信されることを特徴とする請求項１に記載の方法。
【請求項８】
前記パケットロス検出信号は、パケットロスに関連するタイムスタンプを有することを特徴とする請求項１に記載の方法。
【請求項９】
前記キャッシュされたフレームの少なくとも一つを参照して生成され、前記パケットロス検出信号に応じて送信された前記エンコードされたフレームは、前記パケットロスに関連する前記タイプスタンプに基づいて選択されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記エンコードされたフレームは、フレームヘッダをさらに含み、前記フレームタイプコードは、前記フレームヘッダにおいて定義されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記フレームは、画像データ、ビデオデータ、オーディオデータ、または音声データを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
請求項１に記載の方法をコンピュータシステムに実施させるためのコンピュータ実行可能命令を格納することを特徴とするコンピュータ可読媒体。
【請求項１３】
エンコーダであって、
キーフレーム及び予測フレームを含むエンコードされたフレームのシーケンスを送信するステップであって、前記エンコードされたフレームの少なくとも一部は、当該フレームがデコーダでキャッシュされるフレームであることを示すフレームタイプコード有するステップと、
前記デコーダにおけるパケットロス検出の指示を受信するステップと、
パケットロスの前記指示に応じて、前記エンコーダでキャッシュされると示された少なくとも１つのフレームを参照して生成された、エンコードされたフレームを送信するステップと
を備えることを特徴とするエンコーダ。
【請求項１４】
前記エンコードされたフレームは、フレームヘッダをさらに含み、前記フレームタイプコードは、前記フレームヘッダにおいて定義されることを特徴とする請求項１３に記載のエンコーダ。
【請求項１５】
前記パケットロス検出信号は、失われたと示されたパケットに関連するタイムスタンプを含み、前記パケットロス検出信号に応じて送信された前記フレームを生成するために使用された、前記エンコーダでキャッシュされた前記少なくとも１つのフレームは、前記タイムスタンプに基づいて選択されることを特徴とする請求項１３に記載のエンコーダ。
【請求項１６】
前記エンコードされたフレームは、シーケンス番号を含むことを特徴とする請求項１３に記載のエンコーダ。
【請求項１７】
前記パケットロス検出信号に応じて送信された前記フレームを生成するために使用された、前記エンコーダでキャッシュされた前記少なくとも１つのフレームは、前記パケットロスに関連するシーケンス番号に基づいて選択されることを特徴とする請求項１６に記載のエンコーダ。
【請求項１８】
当該フレームが前記デコーダでキャッシュされることを示すフレームタイプコードを有する前記エンコードされたフレームの少なくとも一部は、キーフレームであることを特徴とする請求項１３に記載のエンコーダ。
【請求項１９】
前記エンコードされたフレームの少なくとも一部は、前記関連するフレームがキャッシュされないことを示すフレームタイプコードを有することを特徴とする請求項１３に記載のエンコーダ。
【請求項２０】
当該フレームが前記デコーダでキャッシュされることを示すフレームタイプコードを有するフレームは、定期的に送信されることを特徴とする請求項１３に記載のエンコーダ。
【請求項１】
エンコーダが実施する方法であって、
キーフレーム及び予測フレームを含むエンコードされたフレームのシーケンスを送信するステップであって、前記エンコードされたフレームの少なくとも一部は、当該フレームがデコーダでキャッシュされるフレームであることを示すフレームタイプコード有するステップと、
パケットロス検出信号を受信するステップと、
前記パケットロス検出信号に応じて、前記キャッシュされたフレームの少なくとも１つを参照して生成された、エンコードされたフレームを送信するステップと
を備えることを特徴とする方法。
【請求項２】
前記エンコードされたフレームの少なくとも一部は、キーフレームであることを特徴とする請求項１に記載の方法。
【請求項３】
前記エンコードされたフレームの少なくとも一部は、前記関連するフレームがキャッシュされないことを示すフレームタイプコードを有することを特徴とする請求項１に記載の方法。
【請求項４】
当該フレームが前記デコーダでキャッシュされることを示すタイプコードを有するフレームが、定期的に送信されることを特徴とする請求項１に記載の方法。
【請求項５】
前記デコーダでキャッシュされるフレームの送信間隔は、固定された間隔、または変動する間隔であることを特徴とする請求項４に記載の方法。
【請求項６】
前記エンコーダで、当該フレームが前記デコーダでキャッシュされることを示すタイプコードを有するフレームをキャッシュするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項７】
前記パケットロス検出信号が、フィードバック経路を介して受信されることを特徴とする請求項１に記載の方法。
【請求項８】
前記パケットロス検出信号は、パケットロスに関連するタイムスタンプを有することを特徴とする請求項１に記載の方法。
【請求項９】
前記キャッシュされたフレームの少なくとも一つを参照して生成され、前記パケットロス検出信号に応じて送信された前記エンコードされたフレームは、前記パケットロスに関連する前記タイプスタンプに基づいて選択されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記エンコードされたフレームは、フレームヘッダをさらに含み、前記フレームタイプコードは、前記フレームヘッダにおいて定義されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記フレームは、画像データ、ビデオデータ、オーディオデータ、または音声データを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
請求項１に記載の方法をコンピュータシステムに実施させるためのコンピュータ実行可能命令を格納することを特徴とするコンピュータ可読媒体。
【請求項１３】
エンコーダであって、
キーフレーム及び予測フレームを含むエンコードされたフレームのシーケンスを送信するステップであって、前記エンコードされたフレームの少なくとも一部は、当該フレームがデコーダでキャッシュされるフレームであることを示すフレームタイプコード有するステップと、
前記デコーダにおけるパケットロス検出の指示を受信するステップと、
パケットロスの前記指示に応じて、前記エンコーダでキャッシュされると示された少なくとも１つのフレームを参照して生成された、エンコードされたフレームを送信するステップと
を備えることを特徴とするエンコーダ。
【請求項１４】
前記エンコードされたフレームは、フレームヘッダをさらに含み、前記フレームタイプコードは、前記フレームヘッダにおいて定義されることを特徴とする請求項１３に記載のエンコーダ。
【請求項１５】
前記パケットロス検出信号は、失われたと示されたパケットに関連するタイムスタンプを含み、前記パケットロス検出信号に応じて送信された前記フレームを生成するために使用された、前記エンコーダでキャッシュされた前記少なくとも１つのフレームは、前記タイムスタンプに基づいて選択されることを特徴とする請求項１３に記載のエンコーダ。
【請求項１６】
前記エンコードされたフレームは、シーケンス番号を含むことを特徴とする請求項１３に記載のエンコーダ。
【請求項１７】
前記パケットロス検出信号に応じて送信された前記フレームを生成するために使用された、前記エンコーダでキャッシュされた前記少なくとも１つのフレームは、前記パケットロスに関連するシーケンス番号に基づいて選択されることを特徴とする請求項１６に記載のエンコーダ。
【請求項１８】
当該フレームが前記デコーダでキャッシュされることを示すフレームタイプコードを有する前記エンコードされたフレームの少なくとも一部は、キーフレームであることを特徴とする請求項１３に記載のエンコーダ。
【請求項１９】
前記エンコードされたフレームの少なくとも一部は、前記関連するフレームがキャッシュされないことを示すフレームタイプコードを有することを特徴とする請求項１３に記載のエンコーダ。
【請求項２０】
当該フレームが前記デコーダでキャッシュされることを示すフレームタイプコードを有するフレームは、定期的に送信されることを特徴とする請求項１３に記載のエンコーダ。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【公開番号】特開２０１２−９０３２９（Ｐ２０１２−９０３２９Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１１−２８５９０５（Ｐ２０１１−２８５９０５）
【出願日】平成２３年１２月２７日（２０１１．１２．２７）
【分割の表示】特願２００５−３７５５０８（Ｐ２００５−３７５５０８）の分割
【原出願日】平成１７年１２月２７日（２００５．１２．２７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２３年１２月２７日（２０１１．１２．２７）
【分割の表示】特願２００５−３７５５０８（Ｐ２００５−３７５５０８）の分割
【原出願日】平成１７年１２月２７日（２００５．１２．２７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]