(57)【特許請求の範囲】
【請求項１】
所望のビデオクリップの符号化されたデータのビットストリームのためのＮ（Ｎは２以上）のパラメータのセットを生成するステップであって、前記Ｎのパラメータのセットの各々が異なる組のレートパラメータと、前記所望のビデオクリップの符号化されたデータのビットストリームのためのデコーダバッファサイズパラメータとを含み、前記パラメータのセットは、前記所望のビデオクリップの符号化されたデータを復号するため、前記パラメータのセットに従って動作するリファレンスデコーダのデコーダバッファがアンダーフローにならないように、前記ビットストリームを含む、ステップと、
前記ビットストリームとともに数字Ｎを示す情報を提供するステップと、
各々のＮのパラメータのセットを動作条件の決定に使用できるようにするために、前記ビットストリームとともに前記Ｎのパラメータのセットを提供するステップであって、前記動作条件は前記所望のビデオクリップの符号化されたデータを復号するためのピークレートまたはデコーダバッファサイズである、ステップと
を備えたことを特徴とするコンピュータに実装される方法。
【請求項２】
前記レファレンスデコーダのために複数の追加のパラメータのセットを生成するステップと、
各々の複数の追加のパラメータのセットを前記動作条件の再決定に使用できるようにするために、前記ビットストリームとともに前記複数の追加のパラメータのセットを提供するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記Ｎのパラメータのセットは、前記ビットストリームのストリームヘッダにおいて提供されることを特徴とする請求項１に記載の方法。
【請求項４】
前記Ｎのパラメータのセットは、前記ビットストリームの帯域外で提供されることを特徴とする請求項１に記載の方法。
【請求項５】
デコーダとともに、前記Ｎのパラメータのセットのいずれかを使用して前記動作条件を決定するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項６】
前記ピークレートは、ディスクの駆動速度に対応することを特徴とする請求項５に記載の方法。
【請求項７】
前記ピークレートは、ネットワーク接続の伝送レートに対応することを特徴とする請求項５に記載の方法。
【請求項８】
前記動作条件を決定するステップは、前記Ｎのパラメータのセットのうちの１つから１つのパラメータを選択するステップを含むことを特徴とする請求項５に記載の方法。
【請求項９】
前記動作条件を決定するステップは、前記Ｎのパラメータのセットのうちの２つのセットの間を内挿するステップを含むことを特徴とする請求項５に記載の方法。
【請求項１０】
前記動作条件を決定するステップは、前記Ｎのパラメータのセットのうちの２つのセットについて外挿するステップを含むことを特徴とする請求項６に記載の方法。
【請求項１１】
前記ピークレートは最小ピークレートであり、前記動作条件を決定するステップは、前記Ｎのパラメータのセットの１または２以上のデコーダバッファサイズパラメータから前記最小ピークレートを決定するステップを含むことを特徴とする請求項５に記載の方法。
【請求項１２】
前記動作条件を決定するステップは、前記Ｎのパラメータのセットの１または２以上の前記レートパラメータから前記デコーダバッファサイズを決定するステップを含むことを特徴とする請求項５に記載の方法。
【請求項１３】
前記生成するステップは、エンコーダによって前記所望のビデオクリップを符号化した後に実行され、前記生成するステップは、前記ビットストリームを含む前記Ｎのパラメータのセットの計算値を含むことを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項１４】
前記符号化は、オフライン符号化であることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記生成するステップは、エンコーダによって前記所望のビデオクリップを符号化する前に実行され、前記生成するステップは、前記ビットストリームを含む前記Ｎのパラメータのセットの値を予め選択するステップを含むことを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項１６】
前記符号化は、前記所望のビデオクリップのライブビデオ伝送の間になされることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記符号化は、オフライン符号化であることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記Ｎのパラメータのセットのうちの少なくとも１つのためのレートパラメータおよびデコーダバッファサイズパラメータは、前記所望のビデオクリップのインターネットストリーミングを使用するために設定されることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項１９】
前記Ｎのパラメータのセットのうちの少なくとも１つのためのレートパラメータおよびデコーダバッファサイズパラメータは、前記所望のビデオクリップのランダムアクセス再生機能を使用するために設定されることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２０】
前記Ｎのパラメータのセットの各々は、初期バッファ満杯パラメータをさらに含むことを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２１】
前記Ｎのパラメータのセットの各々は、前記所望のビデオクリップのための符号化されたデータのビットストリームの別のリーキーバケットモデルを特徴付けることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２２】
前記Ｎのパラメータのセットの各々は、前記所望のビデオクリップのための符号化されたデータのビットストリームのレート−デコーダバッファサイズ曲線に沿って異なる点を表していることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２３】
前記デコーダバッファサイズパラメータは、前記Ｎのパラメータのセットの各々について異なることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２４】
前記レートパラメータは、前記Ｎのパラメータのセットの各々について異なることを特徴とする請求項１ないし１２のいずれかに記載の方法。
【請求項２５】
請求項１ないし１２のいずれかの方法を実行するようコンピュータシステムに実行させるコンピュータ実行可能な命令を格納したコンピュータ読取可能な記録媒体。
【請求項２６】
請求項１ないし１２のいずれかの方法を実行するよう調整されたコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像及びビデオ信号並びに音声及びオーディオのような他の時間変動信号の復号化に関する。
【背景技術】
【０００２】
ビデオ符号化の標準では、ビットストリームは、それが少なくとも理論的に復号化できるものであれば、エンコーダの出力に接続されたデコーダの数学的モデルに従う。このようなモデルデコーダは、Ｈ．２６３符号化標準の仮定リファレンスデコーダ（ＨＲＤ）及びＭＰＥＧ符号化標準のビデオバッファ検定器として知られている。一般的に、実際のデコーダ装置（又は端末）は、デコーダバッファ、デコーダ及び表示装置を有する。実際のデコーダ装置が、デコーダの数学的モデルに従って構成されており、数学的モデルに従ったビットストリームが特定の条件のもとに伝送されるならば、デコーダバッファはオーバフローあるいはアンダーフローとならず、復号化は正確になされる。
【０００３】
従来のリファレンス（モデル）デコーダでは、ビットストリームは所定の一定のビットレートでチャネルを通して伝送し、（所定のバッファ遅延の後）所定のバッファサイズをもつ装置により復号化されると仮定されている。それ故、このようなモデルは非常に柔軟性のないものとなり、種々のバッファサイズをもつ装置に対するライブビデオを放送したり、種々のピークビットレートをもつネットワーク経路を介しての符号化済みのビデオオンデマンドのようなストリーミングの今日の重要なビデオアプリケーションのうちの多くの要求に対応できない。
【０００４】
従来のリファレンスデコーダにおいては、ビデオビットストリームは所定の一定のビットレート（通常、ストリームのビット／秒での平均レート）で受信され、そして、そのバッファが所望のレベルの満杯量（ｆｕｌｌｎｅｓｓ）に達するまでデコーダバッファに格納される。例えば、復号化することによりビデオ情報からの出力フレームが再現される前に、少なくともビデオ情報の１つの初期フレームに対応するデータが必要とされる。この所望のレベルは、初期デコーダバッファ満杯量（ｉｎｉｔｉａｌ ｄｅｃｏｄｅｒ ｂｕｆｆｅｒ ｆｕｌｌｎｅｓｓ）と称され、一定のビットレートでは、伝送又は立上り（バッファ）遅延に直接に比例する。この満杯量に達すると、デコーダは（抜本的に）瞬時にそのシーケンスの最初のビデオフレームのためのビットを除去し、これらのビットを復号化してフレームを表示する。引続いての時間間隔で、次に来るフレームのためのビットもまた瞬時に除去され、復号化され、そして表示される。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このようなリファレンスデコーダは固定のビットレート、バッファサイズ及び初期遅延で動作する。しかし、多くの現代のビデオアプリケーション（例えば、インターネットあるいはＡＴＭネットワークを経由したビデオストリーミング）においては、ピーク帯域幅がネットワーク経路により変化する。例えば、ネットワークへの接続が、モデム、ＩＳＤＮ、ＤＳＬ、ケーブルその他によるかに基づいてピーク帯域幅は異なる。さらに、ネットワーク条件、例えば、ネットワークの混雑、接続されるユーザ数及び他の既知の要因によってもピーク帯域幅は時間的に変動する。さらに、ハンドセット、パーソナル デジタル アシスタント（ＰＤＡ）、パソコン、ポケットサイズ計算機、テレビジョン セットトップボックス、ＤＶＤ等のプレーヤを含む、バッファ容量が異なる種々の装置にビデオビットストリームは送られ、例えば、低遅延ストリーミング、プログレッシブダウンロードなど、異なる遅延要求をもつシナリオのために生成される。
【０００６】
既存のリファレンスデコーダはこのような変動を調整しない。同時に、エンコーダは一般的に、所定の受信者のために変化する条件がどうなるかは事前に、分からないし、知ることもできない。結果として、資源及び／又は遅延時間はしばしば不必要に浪費され、多くの場合不適当なものとなる。
【課題を解決するための手段】
【０００７】
簡単に言えば、本発明は、所定のビットストリームのためのレート及びバッファのパラメータのセットがいかなる個数であっても、それに従って動作するよう改良された一般化されたリファレンスデコーダを提供する。各々のセットは、リーキーバケット（ｌｅａｋｙ ｂｕｃｋｅｔ）モデルと呼ばれるものあるいはそのパラメータセットを特徴付け、及び、３つの値（Ｒ，Ｂ，Ｆ）を含む。ここで，Ｒは伝送ビットレート、Ｂはバッファサイズ、Ｆは初期デコーダバッファ満杯量である。Ｆ／Ｒは立上り又は初期バッファ遅延であることが理解される。
【０００８】
エンコーダは、所望個数Ｎ個のリーキーバケットが含まれたビデオビットストリームを生成させ、あるいはビットストリームが発生した後、Ｎセットのパラメータを単に計算することができる。エンコーダは、（少なくとも）一回、初期ストリームヘッダ又は帯域外のような、何らかの方法で、その個数を対応する個数の（Ｒ，Ｂ，Ｆ）セットとともにデコーダに送る。
【０００９】
デコーダで受信した場合、少なくとも２つのセットがあるときは、一般化されたリファレンスデコーダは１つを選択するか，それらのリーキーバケットパラメータ間に内挿（ｉｎｔｅｒｐｏｌａｔｅ）し、そうすることで、いかなる所望のピークビットレート、バッファサイズあるいは遅延でも動作することができる。さらに特に、デコーダの側で認識される、所望のピーク伝送レートＲ'が与えられた場合、一般化されたリファレンスデコーダは、バッファのオーバフローあるいはアンダーフローに妨げられることなくビットストリームを復号化することができる最小のバッファサイズ及び遅延を（（Ｒ，Ｂ，Ｆ）セットの１つを選択するか、２以上の間で内挿するか、あるいは外挿（ｅｘｔｒａｐｏｌａｔｅ）するかによって可能な（Ｒ，Ｂ，Ｆ）のセットに従い）選択する。あるいまた、所定のデコーダバッファＢ'に対して、仮定のデコーダは要求される最小のピーク伝送レートを選択し、そのレートで動作する。
【００１０】
一般化されたリファレンスデコーダの利点には、コンテンツ・プロバイダが一度ビットストリームを生成させ、そしてサーバはそれを異なる性能をもつ複数の装置に、異なるピーク伝送レートの種々のチャネルを用いて送ることができるということが含まれる。あるいはまた、サーバと端末は所定のネットワーク条件に対して最良のリーキーバケットパラメータをネゴシエートすることができる。例えば、最低の立上り（バッファ）遅延を生成するもの、あるいは装置の所定のバッファサイズに対して、最低のピーク伝送レートを要求するものなどである。実際には、リーキーバケット情報を通信するための無視できる量の追加のビットを除き、端末のためのバッファサイズと遅延はオーダ単位（ｏｒｄｅｒ ｏｆ ｍａｇｎｉｔｕｄｅ）で減少させることができ、又は、ピーク伝送レートは大きな係数（例えば４倍）だけ減少させることができ、及び／又は信号対雑音比（ＳＮＲ）は、平均ビットレートを増大することなしに、おそらく数ｄＢ増大させることができる。
本発明は、上述した課題を解決することを目的とし、単一のビデオビットストリームの所望のビデオクリップのために提供されるＮ（Ｎは２以上）のパラメータのセットであって、各々がレートパラメータおよびデコーダバッファサイズパラメータを含み、単一のビデオビットストリームの所望のビデオクリップの符号化されたデータを復号するため、パラメータのセットに従って動作するリファレンスデコーダのデコーダバッファがアンダーフローにならないように、単一のビデオビットストリームを含むＮのパラメータのセットを生成するステップと、単一のビデオビットストリームとともに数字Ｎを示す情報を提供するステップと、単一のビデオビットストリームとともにＮのパラメータのセットを提供するステップとを備えたことを特徴とする。
【発明を実施するための最良の形態】
【００１１】
他の利点及び優位点は、以下の図面と合せて、以下の詳細な説明より明らかになる。
【００１２】
〔典型的な動作環境〕
図１は、特に映像及び／又はビデオデータを符号化するために、本発明を実施することができる適当な動作環境１２０の例を図示している。動作環境１２０は適合する動作環境の一例に過ぎず、本発明の使用範囲あるいは機能に関して、いかなる制限を示唆する意図はない。本発明とともに使用するのに適した他のよく知られた計算機システム、環境及び／又は構成はパーソナルコンピュータ、サーバ、ハンドヘルドあるいはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサに基づいたシステム、プログラム可能なコンシューマ向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム計算機、以上のシステムあるいは装置のいずれをも含む分散型コンピューティング環境及び同様のものが含まれるが、これに限られない。例えば、映像及び／又はビデオ画像データを符号化することはしばしば、現代のハンドヘルドパーソナルコンピュータよりもさらに高い処理能力をもつコンピュータで処理されるが、符号化がこの例示された装置で実行できない、あるいはより強力な装置では復号化されないという理由はないと思われる。
【００１３】
本発明は、１つ又は２つ以上のコンピュータ又は他の装置により実行されるプログラムモジュールのような、コンピュータ実行可能な命令の一般的コンテクストで記述されてもよい。一般的に、プログラムモジュールは、特定のタスクを実行し、あるいは、特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。典型的には、プログラムモジュールの機能は、種々の実施形態で求められるように、組み合わされあるいは分散されてもよい。計算装置１２０は、典型的には、少なくともいくつかの形態のコンピュータ読み取り可能な記録媒体を含む。コンピュータ読み取り可能な記録媒体は、計算装置１２０がアクセスできる、いかなる媒体とすることもできる。例として、しかしこれに限定されないが、コンピュータ読み取り可能な記録媒体は、計算機の記憶媒体及び通信媒体を含んでもよい。計算機の記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールあるいはその他のデータのような情報を格納するため、いかなる方法又は技術によっても実現される揮発性及び不揮発性、取り外し可能な及び不可能な媒体を含む。計算機の記録媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ又は他の光学記憶、磁気カセット、磁気テープ、磁気ディスク記憶又は他の磁気記憶装置、あるいは、所望の情報を記憶するために使用でき、計算装置１２０がアクセスできるいかなる他の媒体も含まれるが、これに制限されない。通信媒体は代表的には、搬送波や他の伝達手法のように変調されたデータ信号におけるコンピュータ読み取り可能な命令、データ構造、プログラムモジュール又は他のデータを具現化し、そして、情報を配信するいかなる媒体をも含む。用語「変調されたデータ信号」とは、信号中の情報を符号化するように設定され又は変化したその１つ又は２つ以上の特性を有する信号を意味する。例として、通信媒体は、有線ネットワークや直接結線された接続などの有線媒体及びオーディオ、ＲＦ（ラジオ無線）、赤外線、及び他の無線媒体を含むが、これに限られない。上記のいかなる組み合わせも、コンピュータ読み取り可能な記録媒体の範囲に含まれなければならない。
【００１４】
図１は、このようなハンドヘルド計算装置１２０の機能的構成を示しており、これには、プロセッサ１２２、メモリ１２４、ディスプレイ１２６及びキーボード１２８（物理的あるいは仮想的なキーボードでもよい。）が含まれる。メモリ１２４は、一般に、揮発性メモリ（例えばＲＡＭ）及び不揮発性メモリ（例えばＲＯＭ、ＰＣＭＣＩＡカードなど）の双方を含む。オペレーティングシステム１３０は、マイクロソフト（登録商標）社のウィンドウズ（登録商標）ＣＥ、あるいは他のオペレーティングシステムのように、メモリ１２４に常駐し、プロセッサ１２２上で実行される。
【００１５】
１つ又は２つ以上のアプリケーションプログラム１３２は、メモリ１２４にロードされ、オペレーティングシステム１３０上で走る。アプリケーションの例としては、ｅメールプログラム、スケジューリングプログラム、ＰＩＭ（ｐｅｒｓｏｎａｌ ｉｎｆｏｒｍａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラム及びその他が含まれる。ハンドヘルドパーソナルコンピュータ１２０は、また、メモリ１２４にロードされ、プロセッサ１２２上で実行される通知管理プログラム１３４を含んでもよい。通知管理プログラム１３４は、例えば、アプリケーションプログラム１３２からの通知要求を処理する。
【００１６】
ハンドヘルドパーソナルコンピュータ１２０は、１つ又は２つ以上のバッテリとして実施される電源１３６を有する。電源１３６は、ＡＣアダプタや電源供給されたドッキングクレードルのように、組み込みバッテリを優先し、又は再充電する外部の電力源を、さらに含んでもよい。
【００１７】
図１に示された一例のハンドヘルドパーソナルコンピュータ１２０は、３つの種類の外部通知機構：１つ又は２つ以上の発光ダイオード（ＬＥＤ）１４０及びオーディオ発生器１４４を持っている。これらの装置は、電源１３６に直接結合して、起動されたときに、ハンドヘルドパーソナルコンピュータのプロセッサ１２２及び他の構成部品がバッテリ電力を保存するために、電源供給を止められた場合でも、通知機構により定められている期間にわたってオン状態を維持するようにする。ＬＥＤ１４０は、ユーザが操作をするまで無期限にオン状態を維持するのが好ましい。現代のオーディオ発生器１４４は、今日のハンドヘルドパーソナルコンピュータのバッテリに対してあまりに多くの電力を使用し、そして、このため、システムのその他の部分が動作しているとき、又は起動後一定の持続時間にわたって、オフにされるよう構成される。
【００１８】
〔一般化されたリファレンスデコーダ〕
リーキーバケットは、エンコーダ又はデコーダバッファの状態（あるいは満杯量）を時間の関数として概念化したモデルである。図２は、この概念を示しており、図２においては、入力データ２００は、エンハンストエンコーダ２０２に供給され、ここでそのデータを（後述するように）符号化してエンコーダバッファ２０４に入力する。符号化されたデータは、伝送媒体（ｐｉｐｅ）２０６を通って、デコーダバッファ２０８まで伝送され、ついでデコーダ２１０によって映像又はビデオフレームのような出力データに復号化される。単純化のために、デコーダバッファ２０８を主として記述する。その理由は、エンコーダ及びデコーダバッファの満杯量は、概念的には互いに相補関係にあり、すなわちデコーダバッファに多くのデータがあるほど、エンコーダバッファにあるデータは少なくなり、逆もまた同様だからである。
【００１９】
リーキーバケットモデルは、３つのパラメータＲ、Ｂ及びＦの組により特徴付けられる。ここで、Ｒはデコーダバッファ２０８にビットが入るときのピークビットレート（ビット／秒）である。ビットレートが一定のシナリオでは、Ｒはしばしばチャネルのビットレート及びビデオ又はオーディオクリップの平均ビットレートであり、概念的にはパイプ２０６の幅に対応すると考えることができる。Ｂは、ビデオビットレートの変動を平滑化するバケットあるいはデコーダバッファ２０８の（ビット単位での）サイズである。このバッファサイズは、デコーダ装置の物理的バッファよりも大きくすることはできない。Ｆは、デコーダがそのバッファからビットを除去しはじめる前に必要とされる初期デコーダバッファ満杯量（これもまたビット単位）である。Ｆは、最初のフレームを表わす符号化されたデータの量と少なくとも同じ大きさである。処理時間は、本実施例の目的のためには瞬時と考えてよいと思われるが、この処理時間を考慮に入れなければ、ＦとＲで、初期又は立上り遅延Ｄが決定される。ここで、Ｄ＝Ｆ/Ｒ（秒）である。
【００２０】
従ってリーキーバケットモデルでは、ビットは、満杯量のレベルがＦになるまで（すなわちＤ秒間）デコーダバッファ２０８にレートＲで入力され、ついで最初のフレームのために必要なビットｂ０は、（本実施例では瞬時に）除去される。ビットは、レートＲでバッファに入力されつづけ、デコーダは、以降のフレームのｂ１、ｂ２、…、ｂｎ−１のビットを所定の瞬時に、典型的には（しかし、必須ではなく）１／Ｍ秒ごとに除去する。ここで、Ｍは、ビデオのフレームレートである。
【００２１】
図３は、パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに格納されているビットストリームに対するデコーダバッファ満杯量の時間変化を示すグラフである。ここで、上述したように、ｉ番目のビットは、ｂｉである。図３では，符号化されたビデオフレームは、バッファ満杯量における低下量（ｄｒｏｐ）によって表されるように、（一般的には、ビデオフレームレートに従って）バッファから除去される。さらに特に、時間ｔｉにおいて、ｂｉビットを除去する直前のデコーダバッファ満杯量をＢｉとする。一般的なリーキーバケットモデルは以下の方程式に従って動作する。
【００２２】
【数１】
0004489794.tif 000002
【００２３】
典型的には、ｔｉ＋１−ｔｉ＝１／Ｍ秒である。ここで、Ｍはビットストリームに対するフレームレート（フレーム／秒）である。
【００２４】
パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットモデルは、デコーダバッファ２０８（図２）でアンダーフローがなければ、１つのビットストリームを格納する。エンコーダとデコーダのバッファ満杯量は互いに補完するため、これはエンコーダバッファ２０４がオーバフローしないことと等価である。しかし、エンコーダバッファ２０４（リーキーバケット）は、空きとなることが許され、あるいは同等に、さらに、エンコーダバッファ２０４からデコーダバッファ２０８に更なるビットが伝送されない点において、デコーダバッファ２０８はフルになってもよい。従ってデコーダバッファ２０８は、フルの場合はビットの受信を停止する。これが、上記の二番目の方程式でｍｉｎ演算子を使っている理由である。これらが補完するため、デコーダバッファ２０８がフルであることは、可変ビットレート（ＶＢＲ）のストリームに関して以下に記述されるように、エンコーダバッファ２０４が空きであることを意味している。
【００２５】
所定のビデオストリームは種々のリーキーバケットの構成に含まれてもよいことを付記する。例えば、あるビデオストリームがパラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに格納されている場合、それはより大きなバッファ（Ｒ，Ｂ’，Ｆ）のリーキーバケットにも格納される。ここに、Ｂ’はＢよりも大きい。あるいは、この場合より高いピーク伝送レート（Ｒ’，Ｂ，Ｆ）のリーキーバケットにも格納される。ここで、Ｒ’はＲよりも大きい。さらに、いかなるビットレートＲ’に対しても、（時間が限定された）ビデオビットストリームを格納するバッファサイズがある。最悪の場合、すなわちＲ’が０に近づく場合、バッファサイズはビットストリーム自体と同じ大きさである必要がある。言い換えれば、ビデオビットストリームは、バッファサイズが十分大きい限りは（そのクリップの平均レートに関係なく）いかなるレートでも伝送することができる。
【００２６】
図４は、所定のビットストリームのためのピークビットレートＲｍｉｎに対する、上記の二番目の方程式を使って得た最小バッファサイズＢｍｉｎのグラフである。ここで、所望の初期バッファ満杯量は、総バッファサイズの一定の部分で設定される。図４の曲線は、ピークビットレートｒでストリームを伝送するためには、デコーダは、少なくともＢｍｉｎ（ｒ）ビットをバッファする必要があることを示している。さらに、グラフから理解されるように、より高いピークレートはより小さいバッファサイズを要求し、それゆえ、より短い立上りバッファ遅延が要求される。あるいはまたこのグラフは、デコーダバッファのサイズがｂの場合は、このビットストリームを伝送するため必要とされる最小ピークレートはそれに関連するＲｍｉｎ（ｂ）であることを示している。さらに、（図４にあるような）いかなるビットストリームに対する（Ｒｍｉｎ，Ｂｍｉｎ）の組の曲線は、部分的には線形であり、かつ凸状である。
【００２７】
本発明の一つの形態にしたがって、曲線の少なくとも二点がエンハンストエンコーダ２０２により与えられれば、一般化されたリファレンスデコーダ２１０は、１点を選択し、二点間の線形内挿を取り、又はそれらの点を外挿して（Ｒｍｉｎ，Ｂｍｉｎ）よりもわずかだが安全サイドに大きい、ある点（Ｒｉｎｔｅｒｐ，Ｂｉｎｔｅｒｐ）に到達することができる。重要な結果として、多くの場合、平均レートでビットストリームを格納している単一のリーキーバケットに比べて、オーダ単位で安全にバッファサイズを減らしてもよい。それにより、遅延も同様に減少する。あるいはまた同じ遅延に対して、ピーク伝送レートは、（多分）係数４だけ減らしてもよいし、また、信号雑音比率（ＳＮＲ）を、（多分）数ｄＢ改善してもよい。
【００２８】
このために、所定のビデオ又は映像クリップのために有用な（例えば、Ｒ及び／又はＢの範囲に関して合理的に分割された。）レート−バッファ曲線上の少なくとも二点に対応するリーキーバケットパラメータ２１４、例えば（Ｒ１，Ｂ１，Ｆ１）、（Ｒ２，Ｂ２，Ｆ２）…、（ＲＮ，ＢＮ，ＦＮ）の少なくとも２つのセットを生成するようにエンコーダ２０２を構成することでエンコーダ２０２をエンハンスする。このエンハンストエンコーダ２０２は、初期ストリームヘッダに、あるいはまた帯域外の何らかの方法でこれらリーキーバケットパラメータセットを挿入するといったことにより、一般化されたリファレンスデコーダ２１０に対し、数Ｎと共に、これらのリーキーバケットパラメータセットを提供する。相対的に大きなＮ（Ｒ-Ｂ曲線を合理的に表すためには２から４バケット有れば通常十分であるが、例えば数ダースのバケット）に対してさえ、この情報を提供するため必要とされる追加のバイトの量（例えば、Ｎに対して１バイトに加えて、リーキーバケットモデルあるいはパラメータセットごとに８バイト）は、一般のビデオ又は映像データと比べると無視できることを付記する。
【００２９】
さらに、より高いビットレートでは、コンテンツ製作者はそのビットストリームの中で異なる時間において異なるリーキーバケットモデルを特定するよう決定してもよいことを特に付記する。これは、いつ伝送中に接続が切れ、ビットストリームの中間で再スタートした場合でも有用である。例えば、リーキーバケットモデルを１５分間隔で与えて、デコーダがその動作条件（例えば、バッファサイズ又はレート）を、所望に応じて、適当な回数、再選択、再内挿又は再外挿することによって変えてもよい。
【００３０】
Ｎの所望値は、エンコーダで選択することができる（Ｎ＝１の場合、一般化されたデコーダ２１０は、ＭＰＥＧビデオバッファ検定器のように点を外挿することに留意する）。エンコーダは、予めリーキーバケットの値を選択し、リーキーバケットの制約が充たされようにレート制御を行ってビットストリームを符号化するか、ビットストリームを符号化してから上述の方程式を使ってＮ個の異なるＲの値においてビットストリームを格納するリーキーバケットパラメータのセットを計算するか、またその両方を行うことを選択することができる。最初のやり方は、ライブ又はオンデマンド伝送に適用することができるが、その他は、オンデマンドに適用される。
【００３１】
本発明の場合には、一般化されたリファレンスデコーダ２１０でいったん受信されると、デコーダ２１０は、それに可能なピークビットレート及び／又は物理的なバッファサイズを考慮して、どのリーキーバケットを使うのが望ましいかを決定することができる。あるいはまた、一般化されたリファレンスデコーダ２１０は、これらの点の間で線形内挿をもとめるか又はこれらの点から線形外挿を求めて、所定の設定に対し適当なパラメータセットを探索するようにしてもよい。
【００３２】
図５は、２つのリーキーバケットパラメータセット及びそれらの線形内挿された（Ｒ，Ｂ）値を示している。参考のために、計算されたＲ−Ｂ曲線は細かい破線で表され、リーキーバケットモデル（Ｒｘ，Ｂｘ）及び（Ｒｙ，Ｂｙ）において与えられるＲとＢの値は星印によって表される。（Ｒｘ，Ｂｘ）から（Ｒｙ，Ｂｙ）への実線は、内挿された値を表している。この実線上で選択されたいかなるＲ又はＢの組も、デコーダバッファ２０８を適切に（例えば、オーバフロー又はアンダフローなしに）維持する。リーキーバケットパラメータは、図５の粗い破線で表され、これらの点から外挿することもでき、そしてまた、実線上で選ばれたいかなるＲ又はＢの組もデコーダバッファ２０８を適切に維持する。
【００３３】
点ｋと点ｋ＋１の間の内挿されたバッファサイズＢは次の直線に従う。
【００３４】
【数２】
0004489794.tif 000003
【００３５】
ここで、Ｒｋ＜Ｒ＜Ｒｋ＋１である。同様に、初期デコーダバッファ満杯量Ｆは、線形内挿することができる。
【００３６】
【数３】
0004489794.tif 000004
【００３７】
ここで、Ｒｋ＜Ｒ＜Ｒｋ＋１である。
【００３８】
このようにして得られた、パラメータ（Ｒ，Ｂ，Ｆ）を持つリーキーバケットは、ビットストリームを含むことが保証される、その理由は、（数学的に証明出来るように）最小バッファサイズＢｍｉｎがＲとＦの両方に凸状である、すなわち、任意の凸結合（Ｒ，Ｆ）＝ａ（Ｒｋ，Ｆｋ）＋（１−ａ）（Ｒｋ＋１，Ｆｋ＋１）、０＜ａ＜１に対応する最小バッファサイズＢｍｉｎは、Ｂ＝ａＢｋ＋（１−ａ）Ｂｋ＋１以下だからである。
【００３９】
上述したように、ＲがＲＮよりも大きい場合、リーキーバケット（Ｒ，ＢＮ，ＦＮ）もまたビットストリームを含む。ここで、ＢＮとＦＮはＲＮのときに望ましいバッファサイズと初期デコーダバッファ満杯量である。Ｒが、Ｒ１よりも小さいならば、上限Ｂ＝Ｂ１＋（Ｒ１−Ｒ）Ｔを用いることができる。ここで、Ｔは秒単位でのストリームの時間長である。Ｎ点の範囲を超えたこれらの（Ｒ，Ｂ）の値は外挿してもよい。
【００４０】
デコーダは、リーキーバケットのパラメータを選択し、内挿し、あるいは外挿する必要はないが、もう一つのやり方はむしろデコーダへ単一のセットを送るためのパラメータを選択することであり、それによりデコーダはその単一のセットを使う。例えば、デコーダの要求などのある情報が与えられると、サーバは、（選択、内挿又は外挿によって）デコーダへ送るためのリーキーバケットパラメータの適切なセットを決定することができ、ついで、デコーダは、一つのパラメータセットのみを使って復号化することができる。サーバ又はデコーダのためのプロキシもまた、デコーダが２以上のリーキーバケットを見ることすらなしに、リーキーバケット情報の選択、内挿または外挿の選択をすることができる。言い換えれば、デコーダが決定する代わりに、多分サーバとクライアントのデコーダがパラメータをネゴシエートしながらサーバが決定することができる。しかし、一般的には、そして本発明の場合には、少なくとも２つのリーキーバケットモデルに基づいて適正なリーキーバケットモデルの決定が行われる。
【００４１】
所定のビットストリームに対するＲ−Ｂ曲線の値は、図３で示されるように、デコーダバッファのプロットの中で最高の満杯量と最低の満杯量が発生する時刻から計算することができる。より詳しくは、パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに含まれるビットストリームに対して、デコーダバッファの最高満杯量と最低満杯量のそれぞれ２つの時刻（ｔＭ，ｔｍ）を事前に又は動的に考える。満杯量は最高と最低の値に数回達してもよいが、ｔＭ＜ｔｍとなるような最も大きな値の（ｔＭ，ｔｍ）の組を考える。リーキーバケットが適切に計算できると仮定すると、Ｂは、値Ｒ、Ｆに対するビットストリームを含む最低バッファサイズである。
【００４２】
【数４】
0004489794.tif 000005
【００４３】
ここで、ｂ（ｔ）は、時刻ｔでのフレームのビット数であり、Ｍはフレーム／秒でのフレームレートである。この方程式において、ｎは時刻ｔＭとｔｍとの間のフレーム数であり、ｃはこれらフレームに対するビットの合計である。
【００４４】
この方程式は、ｒ＝Ｒで、−ｎ／Ｍが線の傾斜となる直線Ｂ（ｒ）の点として解釈することができる。値ｔＭとｔｍの最大の組が同じ値に留まるようなビットレート範囲ｒ∈［Ｒ−ｒ１，Ｒ＋ｒ２］が存在する。ここで、上記方程式は、ビットレートｒに関連する最小バッファサイズを定める直線に対応する。ビットレートｒが上記範囲外にある場合は、値ｔＭ及び／又はｔｍの少なくとも一つが変化する。ここで、ｒ＞Ｒ＋ｒ２のときは、ｔＭとｔｍとの間の時間間隔はより小さくなる。そして、Ｂ（ｒ）を定める新たな直線におけるｎの値もより小さくなり、および各線の傾斜はより大きくなる（より負でなくなる）。ｒ＜Ｒ−ｒ１のときは、ｔＭとｔｍとの間の時間間隔は大きくなり、およびＢ（ｒ）を定める直線におけるｎの値も増大する。線の傾斜はこのとき、より小さくなる（より負になる）。
【００４５】
ビットレートの範囲に対する（ｔＭ，ｔｍ）の組の値（あるいはこれに関連するｎの値）とｃのいくつかの値（任意の組に対して少なくとも一つ）は、ビットストリームのヘッダに格納してもよく、それゆえ上記方程式を用いて、部分的に線形のＢ（ｒ）曲線を得ることができる。加えて、この方程式を用いて、エンコーダがビットストリームを生成した後、リーキーバケットモデルのパラメータの計算を簡易化するようにしてもよい。
【００４６】
試みに、図５のビットストリームは、７９７Ｋｂｐｓの平均ビットレートを発生するように生成された。図５に一般的に示されるように、７９７Ｋｂｐｓの一定の伝送レートでは、デコーダは、約１８，０００Ｋビットのバッファサイズ（Ｒｘ，Ｂｘ）を必要とする。初期デコーダバッファ満杯量が１８，０００Ｋビットに等しい場合は、立上り遅延は、約２２．５秒となる。そのため、その全符号化長に対して本質的に可能な限り最良の品質を達成するために、この（レート制御なしに生成された）符号化により２２．５秒までビットがシフトされる。
【００４７】
図５は、ピーク伝送レート２,５００Ｋｂｐｓ（例えば、２倍速ＣＤのビデオビットレートの部分）では、デコーダはたった２,２７２Ｋビットのバッファサイズ（Ｒｙ，Ｂｙ）を必要とするだけであり、これは、コンシューマ向けハードウェア装置としては妥当なものである。初期バッファ満杯量が２,２７２Ｋビットに等しい場合、その立上り遅延は約０.９秒に過ぎない。
【００４８】
それゆえ、この符号化にとって、典型的には２つのリーキーバケットモデル、例えば、（Ｒ＝７９７Ｋｂｐｓ，Ｂ＝１８，０００Ｋビット，Ｆ＝１８，０００Ｋビット）及び（Ｒ＝２，５００Ｋｂｐｓ，Ｂ＝２，２７２Ｋビット，Ｆ＝２，２７２Ｋビット）のモデルが有用である。この最初のリーキーバケットのパラメータセットは、約２２．５秒の遅延でビデオを一定のビットレートのチャネルにわたって伝送することを許容する。多くのシナリオにとって、この遅延はあまりに大きいが、例えば映画のインターネットストリーミングのためにはおそらく、許容しうるものである。リーキーバケットパラメータの二番目のセットは、約０．９秒の遅延で、ピークレート２，５００Ｋｂｐｓの共用ネットワークを介してビデオを伝送し、又は２倍速ＣＤからローカルで再生することを許容する。この１秒未満の遅延は、ＶＣＲ（ビデオカセットレコーダ）と同様の機能を持つランダムアクセス再生に対して許容される。
【００４９】
この利点は、そのビットストリームにおいて第１のリーキーバケットのみが特定されるものの、第２のリーキーバケットが特定されない場合に起こることを考えれば、明らかである。このような場合、ピークビットレート２，５００Ｋｂｐｓのチャネルで再生する場合でさえ、デコーダは１８，０００Ｋビットのバッファサイズを使い、従って、その遅延はＦ／Ｒ＝１８，０００Ｋビット／２，５００Ｋｂｐｓ＝７．２秒となろう。このような遅延はＶＣＲ同様の機能を持つようなランダムアクセスの再生では許容されないことを理解することができる。しかし、第２のリーキーバケットがさらに特定されると、２，５００Ｋｂｐｓのレートにおいてバッファサイズは、２，２７２Ｋビットに低下し、その遅延は上述したとおり０．９秒に低下する。
【００５０】
他方、第２のリーキーバケットのみ特定され、第１のリーキーバケットが特定されなかったときには、７９７Ｋｂｐｓの一定の伝送レートにおいて、洗練されたデコーダでさえも、必要とされるよりもずっと大きなバッファを用いてバッファがオーバフローしないことを確実にすることを余儀なくされる。すなわち、Ｂ’＝Ｂ＋（Ｒ−Ｒ’）Ｔ＝２，２７２Ｋビット＋（２，５００Ｋｂｐｓ−７９７Ｋｂｐｓ）×１３０秒＝２２３，６６２Ｋビットとなる。このような多大な記憶がある装置において可能であっても、これは、２８１秒すなわちほぼ５分という初期遅延に対応するが、これは許容限度をはるかに超えている。しかし、第１のリーキーバケットも特定される場合、７９７Ｋｂｐｓのレートにおいて、バッファサイズは１８，０００Ｋビットに低下し、および遅延は、上述したように、２２．５秒に低下する。
【００５１】
さらに、双方のリーキーバケットが特定されると、デコーダはこれらの間で、７９７Ｋｂｐｓと２，５００Ｋｂｐｓとの間の任意のビットレートＲに対して、（上記の内挿公式を使って）線形内挿し、それにより所与のレートにおいてほぼ最小のバッファサイズ及び遅延を実現できる。外挿もまた７９７Ｋｂｐｓより低く、２，５００Ｋｂｐｓより高い双方で（粗い破線で図５に示されている）、７９２Ｋｂｐｓと２，５００Ｋｂｐｓとの間（両端含む）の任意の個所での単一のリーキーバケットを用いた外挿と比較すると、より効率的である。
【００５２】
上記実施例により例示されているように、わずか２セットのリーキーバケットパラメータでさえ、バッファサイズをオーダ単位で削減することができ（例えば、ある場合は、２２３，６６２Ｋビットから１８，０００Ｋビットへ、および他の場合は、１８，０００Ｋビットから２，２７２Ｋビットへ）、所与のピーク伝送レートにおける遅延もオーダ単位で削減される（例えば、ある場合は、２８１秒から２２．５秒へ、および、他の場合は、７．２秒から０．９秒へ削減）。
【００５３】
あるいはまた、所与のデコーダバッファサイズに対するピーク伝送レートを減少させることもできる。実際、図５から明らかなように、複数のリーキーバケットを内挿及び／又は外挿することによりＲ−Ｂ曲線が得られるならば、固定の物理的バッファサイズをもつデコーダが、デコーダバッファのアンダーフローなしに安全にビットストリームを復号化するために必要とされる最小のピーク伝送レートを選ぶことができる。例えば、デコーダがサイズ１８,０００Ｋビットの固定バッファを有するならば、符号化のためのピーク伝送レートは７９７Ｋｂｐｓ程度の低さにすることができる。しかし、第２のリーキーバケットが特定されるものの、第１のリーキーバケットは特定されない場合、デコーダは、ビットレートをＲ’＝Ｒ−（Ｂ’−Ｂ）／Ｔ＝２,５００Ｋｂｐｓ−（１８,０００Ｋビット−２,２７２Ｋビット）／１３０秒＝２,３７９Ｋｂｐｓより低いビットレートまでも減らすことができる。この場合、単一のリーキーバケットを用いるのに比べ、２つのリーキーバケットを使うだけで、同じデコーダバッファサイズに対して係数４だけピーク伝送レートを減らすことになる。
【００５４】
複数のリーキーバケットパラメータを有することにより、同じ平均符号化レートで再構成されたビデオの質もまた改善できる。双方のリーキーバケットが符号化に用いることができる場合を考える。上述のように、デコーダにおけるこの情報をもって、ピーク伝送レートが７９７Ｋｂｐｓの場合は、２２.５秒の遅延で、そして、ピーク伝送レートが２,５００Ｋｂｐｓの場合は、０.９秒の遅延で、符号化して再生することができる。
【００５５】
しかし、第２のリーキーバケットが用いることができないとすると、遅延は２,５００Ｋｂｐｓで０.９秒から７.２秒に増加する。第２のリーキーバケットの利点なしに遅延を０.９秒に減らす１つの方法は、（第１のリーキーバケットの）バッファサイズを１８,０００Ｋビットから（０.９秒×２,５００Ｋｂｐｓ）＝２,２５０Ｋビットに減らすことにより、レートを制御してクリップを再符号化することである。これにより、７９７Ｋｂｐｓにおける遅延が２２.５秒から２.８秒に減少しても、ピーク伝送レートが２,５００Ｋｂｐｓならば、遅延はたった０.９秒になることが確かである。しかし、結果として、品質（ＳＮＲ）もまた、数ｄＢと推定される量だけ、特に大きなダイナミックレンジを持つクリップに対して減少する。
【００５６】
従って、第２のリーキーバケットを特定することにより、クリップあたり無視しうる量の追加のビットを除いて、第２のリーキーバケットを特定することで、平均ビットレートを変えることなく、ＳＮＲを多分数ｄＢ増やすことができる。ＳＮＲにおけるこの増加は、各ピーク伝送レートに対して再生の際顕著である。
【００５７】
一般化されたリファレンスデコーダに複数のリーキーバケットを特定することの利点は、単一の符号化が行われ、異なるピークレートのチャネルを介して伝送され、又は、異なる物理的バッファサイズを持つ装置に伝送される場合に理解される。しかし、実際には、これは、ますます普通になりつつある。例えば、オフラインで符号化され、ディスクに格納されたコンテンツは、異なるピークレートをもつネットワークを流れるとともに、しばしば、ローカルで再生される。ローカルの再生においてさえ、種々の駆動速度（例えば、１倍速ＣＤから８倍速ＤＶＤ）がピーク伝送レートに影響する。さらに、ネットワーク接続を通したピーク伝送レートは、一般的にエンドユーザに近い制限リンク（例えば、１００又は１０ｂａｓｅＴイーサネット（登録商標）、Ｔ１、ＤＳＬ、ＩＳＤＮ、モデムその他）の速度に劇的に従う。再生装置のバッファ容量もまた、数ギガバイトのバッファ空間を持つデスクトップコンピュータから数オーダ小さいバッファ空間を持つ小型コンシューマ向け電子機器へと大きく変化する。複数のリーキーバケットと本発明により提案された一般化されたリファレンスデコーダとによって、同一のビットストリームが、最小立上り遅延、最小デコーダバッファ要求及び最大可能品質を持つ種々のチャネルを介して伝送されることを可能とする。これは、オフラインで符号化されるビデオだけでなく、異なるチャネルを介して異なる装置に同時に配信されるライブビデオにも適用される。要約すれば、本発明により提案された一般化されたリファレンスデコーダは、既存のビットストリームに大きな柔軟性を加えるということである。
【００５８】
先に詳述したことから理解できる通り、先行技術に対して改良された一般化されたリファレンスデコーダが提供される。一般化されたリファレンスデコーダは、エンコーダからの少量の情報のみを（例えば、ビットストリームのヘッダにおいて）必要とするだけで、帯域幅がさまざまであり、及び／又は端末が種々のビットレート及びバッファ容量を持つ現代のネットワークを介してのビットストリームの配信に対して、より高い柔軟性を提供する。本発明のリファレンスデコーダは、可能な帯域幅に対して伝送遅延を最小に減らす一方、これらの新しいシナリオを可能にし、さらに加えて、所与の物理的バッファサイズの制限をもつ装置に対する配信のためのチャネルビットレート要件を仮想的に最小化する。
【００５９】
本発明は、種々の変更や代案の構成が可能であるが、図示された実施例を図面に表し、上記に詳細に記述してきた。しかし、本発明を開示された特定の形態に限定しようという意図がなく、これとは反対に、すべての変更、代案の構成及び本発明の精神と意向のうちにある均等物すべてを包含する意図があることは理解されるべきである。
【図面の簡単な説明】
【００６０】
【図１】本発明を取り入れたコンピュータシステムの一例を示すブロック図である。
【図２】本発明の一態様にしたがってビデオ又は映像データを符号化及び復号化するためのエンハンストエンコーダと一般化されたリファレンスデコーダ及びそれらのそれぞれのバッファを示すブロック図である。
【図３】パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに含まれているバッファ満杯量を時間にわたって示すグラフである。
【図４】代表的なビデオクリップに対するレート対バッファサイズの曲線を示すグラフである。
【図５】本発明の一態様に従って内挿及び外挿するための一般化されたリファレンスデコーダに提供された２つのリーキーバケットモデル（のパラメータセット）をもつ代表的なビデオクリップに対するレート対バッファサイズの曲線を示すグラフである。
【符号の説明】
【００６１】
１２０  動作環境
１２２  プロセッサ
１２４  メモリ
１２６  ディスプレイ
１２８  キーボード
１３０  オペレーティングシステム
１３２  アプリケーションプログラム
１３４  通知管理プログラム
１３６  電源
１４０  ＬＥＤ
１４４  オーディオ発生器
２００  入力データ
２０２  エンハンストエンコーダ
２０４  エンコーダバッファ
２０６  伝送媒体（パイプ）
２０８  デコーダバッファ
２１０  一般化されたリファレンスデコーダ
２１２  出力データ
２１４  リーキーバケットパラメータ
【図１】
0004489794.tif 000006
【図２】
0004489794.tif 000007
【図３】
0004489794.tif 000008
【図４】
0004489794.tif 000009
【図５】
0004489794.tif 000010