JP4199973B2 - 映像又はビデオ処理のための一般化されたリファレンスデコーダ - Google Patents

Description

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

【００５９】
典型的には、ｔ_ｉ＋１−ｔ_ｉ＝１／Ｍ秒である。ここで、Ｍはビットストリームに対するフレームレート（フレーム／秒）である。
【００６０】
パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットモデルは、デコーダバッファ２０８（図２）でアンダーフローがなければ、１つのビットストリームを格納する。エンコーダとデコーダのバッファ満杯量は互いに補完するため、これはエンコーダバッファ２０４がオーバフローしないことと等価である。しかし、エンコーダバッファ２０４（リーキーバケット）は、空きとなることが許され、あるいは同等に、さらに、エンコーダバッファ２０４からデコーダバッファ２０８に更なるビットが伝送されない点において、デコーダバッファ２０８はフルになってもよい。従ってデコーダバッファ２０８は、フルの場合はビットの受信を停止する。これが、上記の二番目の方程式でｍｉｎ演算子を使っている理由である。これらが補完するため、デコーダバッファ２０８がフルであることは、可変ビットレート（ＶＢＲ）のストリームに関して以下に記述されるように、エンコーダバッファ２０４が空きであることを意味している。
【００６１】
所定のビデオストリームは種々のリーキーバケットの構成に含まれてもよいことを付記する。例えば、あるビデオストリームがパラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに格納されている場合、それはより大きなバッファ（Ｒ，Ｂ’，Ｆ）のリーキーバケットにも格納される。ここに、Ｂ’はＢよりも大きい。あるいは、この場合より高いピーク伝送レート（Ｒ’，Ｂ，Ｆ）のリーキーバケットにも格納される。ここで、Ｒ’はＲよりも大きい。さらに、いかなるビットレートＲ’に対しても、（時間が限定された）ビデオビットストリームを格納するバッファサイズがある。最悪の場合、すなわちＲ’が０に近づく場合、バッファサイズはビットストリーム自体と同じ大きさである必要がある。言い換えれば、ビデオビットストリームは、バッファサイズが十分大きい限りは（そのクリップの平均レートに関係なく）いかなるレートでも伝送することができる。
【００６２】
図４は、所定のビットストリームのためのピークビットレートＲ_ｍｉｎに対する、上記の二番目の方程式を使って得た最小バッファサイズＢ_ｍｉｎのグラフである。ここで、所望の初期バッファ満杯量は、総バッファサイズの一定の部分で設定される。図４の曲線は、ピークビットレートｒでストリームを伝送するためには、デコーダは、少なくともＢ_ｍｉｎ（ｒ）ビットをバッファする必要があることを示している。さらに、グラフから理解されるように、より高いピークレートはより小さいバッファサイズを要求し、それゆえ、より短い立上りバッファ遅延が要求される。あるいはまたこのグラフは、デコーダバッファのサイズがｂの場合は、このビットストリームを伝送するため必要とされる最小ピークレートはそれに関連するＲ_ｍｉｎ（ｂ）であることを示している。さらに、（図４にあるような）いかなるビットストリームに対する（Ｒ_ｍｉｎ，Ｂ_ｍｉｎ）の組の曲線は、部分的には線形であり、かつ凸状である。
【００６３】
本発明の一つの形態にしたがって、曲線の少なくとも二点がエンハンストエンコーダ２０２により与えられれば、一般化されたリファレンスデコーダ２１０は、１点を選択し、二点間の線形内挿を取り、又はそれらの点を外挿して（Ｒ_ｍｉｎ，Ｂ_ｍｉｎ）よりもわずかだが安全サイドに大きい、ある点（Ｒ_{ｉｎｔｅｒｐ}，Ｂ_{ｉｎｔｅｒｐ}）に到達することができる。重要な結果として、多くの場合、平均レートでビットストリームを格納している単一のリーキーバケットに比べて、オーダ単位で安全にバッファサイズを減らしてもよい。それにより、遅延も同様に減少する。あるいはまた同じ遅延に対して、ピーク伝送レートは、（多分）係数４だけ減らしてもよいし、また、信号雑音比率（ＳＮＲ）を、（多分）数ｄＢ改善してもよい。
【００６４】
このために、所定のビデオ又は映像クリップのために有用な（例えば、Ｒ及び／又はＢの範囲に関して合理的に分割された。）レート−バッファ曲線上の少なくとも二点に対応するリーキーバケットパラメータ２１４、例えば（Ｒ_１，Ｂ_１，Ｆ_１）、（Ｒ_２，Ｂ_２，Ｆ_２）…、（Ｒ_Ｎ，Ｂ_Ｎ，Ｆ_Ｎ）の少なくとも２つのセットを生成するようにエンコーダ２０２を構成することでエンコーダ２０２をエンハンスする。このエンハンストエンコーダ２０２は、初期ストリームヘッダに、あるいはまた帯域外の何らかの方法でこれらリーキーバケットパラメータセットを挿入するといったことにより、一般化されたリファレンスデコーダ２１０に対し、数Ｎと共に、これらのリーキーバケットパラメータセットを提供する。相対的に大きなＮ（Ｒ-Ｂ曲線を合理的に表すためには２から４バケット有れば通常十分であるが、例えば数ダースのバケット）に対してさえ、この情報を提供するため必要とされる追加のバイトの量（例えば、Ｎに対して１バイトに加えて、リーキーバケットモデルあるいはパラメータセットごとに８バイト）は、一般のビデオ又は映像データと比べると無視できることを付記する。
【００６５】
さらに、より高いビットレートでは、コンテンツ製作者はそのビットストリームの中で異なる時間において異なるリーキーバケットモデルを特定するよう決定してもよいことを特に付記する。これは、いつ伝送中に接続が切れ、ビットストリームの中間で再スタートした場合でも有用である。例えば、リーキーバケットモデルを１５分間隔で与えて、デコーダがその動作条件（例えば、バッファサイズ又はレート）を、所望に応じて、適当な回数、再選択、再内挿又は再外挿することによって変えてもよい。
【００６６】
Ｎの所望値は、エンコーダで選択することができる（Ｎ＝１の場合、一般化されたデコーダ２１０は、ＭＰＥＧビデオバッファ検定器のように点を外挿することに留意する）。エンコーダは、予めリーキーバケットの値を選択し、リーキーバケットの制約が充たされようにレート制御を行ってビットストリームを符号化するか、ビットストリームを符号化してから上述の方程式を使ってＮ個の異なるＲの値においてビットストリームを格納するリーキーバケットパラメータのセットを計算するか、またその両方を行うことを選択することができる。最初のやり方は、ライブ又はオンデマンド伝送に適用することができるが、その他は、オンデマンドに適用される。
【００６７】
本発明の場合には、一般化されたリファレンスデコーダ２１０でいったん受信されると、デコーダ２１０は、それに可能なピークビットレート及び／又は物理的なバッファサイズを考慮して、どのリーキーバケットを使うのが望ましいかを決定することができる。あるいはまた、一般化されたリファレンスデコーダ２１０は、これらの点の間で線形内挿をもとめるか又はこれらの点から線形外挿を求めて、所定の設定に対し適当なパラメータセットを探索するようにしてもよい。
【００６８】
図５は、２つのリーキーバケットパラメータセット及びそれらの線形内挿された（Ｒ，Ｂ）値を示している。参考のために、計算されたＲ−Ｂ曲線は細かい破線で表され、リーキーバケットモデル（Ｒ_ｘ，Ｂ_ｘ）及び（Ｒ_ｙ，Ｂ_ｙ）において与えられるＲとＢの値は星印によって表される。（Ｒ_ｘ，Ｂ_ｘ）から（Ｒ_ｙ，Ｂ_ｙ）への実線は、内挿された値を表している。この実線上で選択されたいかなるＲ又はＢの組も、デコーダバッファ２０８を適切に（例えば、オーバフロー又はアンダフローなしに）維持する。リーキーバケットパラメータは、図５の粗い破線で表され、これらの点から外挿することもでき、そしてまた、実線上で選ばれたいかなるＲ又はＢの組もデコーダバッファ２０８を適切に維持する。
【００６９】
点ｋと点ｋ＋１の間の内挿されたバッファサイズＢは次の直線に従う。
【００７０】
【数２】

【００７１】
ここで、Ｒ_ｋ＜Ｒ＜Ｒ_ｋ＋１である。
同様に、初期デコーダバッファ満杯量Ｆは、線形内挿することができる。
【００７２】
【数３】

【００７３】
ここで、Ｒ_ｋ＜Ｒ＜Ｒ_ｋ＋１である。
【００７４】
このようにして得られた、パラメータ（Ｒ，Ｂ，Ｆ）を持つリーキーバケットは、ビットストリームを含むことが保証される、その理由は、（数学的に証明出来るように）最小バッファサイズＢ_ｍｉｎがＲとＦの両方に凸状である、すなわち、任意の凸結合（Ｒ，Ｆ）＝ａ（Ｒ_ｋ，Ｆ_ｋ）＋（１−ａ）（Ｒ_ｋ＋１，Ｆ_ｋ＋１）、０＜ａ＜１に対応する最小バッファサイズＢ_ｍｉｎは、Ｂ＝ａＢ_ｋ＋（１−ａ）Ｂ_ｋ＋１以下だからである。
【００７５】
上述したように、ＲがＲ_Ｎよりも大きい場合、リーキーバケット（Ｒ，Ｂ_Ｎ，Ｆ_Ｎ）もまたビットストリームを含む。ここで、Ｂ_ＮとＦ_ＮはＲ_Ｎのときに望ましいバッファサイズと初期デコーダバッファ満杯量である。Ｒが、Ｒ_１よりも小さいならば、上限Ｂ＝Ｂ_１＋（Ｒ_１−Ｒ）Ｔを用いることができる。ここで、Ｔは秒単位でのストリームの時間長である。Ｎ点の範囲を超えたこれらの（Ｒ，Ｂ）の値は外挿してもよい。
【００７６】
デコーダは、リーキーバケットのパラメータを選択し、内挿し、あるいは外挿する必要はないが、もう一つのやり方はむしろデコーダへ単一のセットを送るためのパラメータを選択することであり、それによりデコーダはその単一のセットを使う。例えば、デコーダの要求などのある情報が与えられると、サーバは、（選択、内挿又は外挿によって）デコーダへ送るためのリーキーバケットパラメータの適切なセットを決定することができ、ついで、デコーダは、一つのパラメータセットのみを使って復号化することができる。サーバ又はデコーダのためのプロキシもまた、デコーダが２以上のリーキーバケットを見ることすらなしに、リーキーバケット情報の選択、内挿または外挿の選択をすることができる。言い換えれば、デコーダが決定する代わりに、多分サーバとクライアントのデコーダがパラメータをネゴシエートしながらサーバが決定することができる。しかし、一般的には、そして本発明の場合には、少なくとも２つのリーキーバケットモデルに基づいて適正なリーキーバケットモデルの決定が行われる。
【００７７】
所定のビットストリームに対するＲ−Ｂ曲線の値は、図３で示されるように、デコーダバッファのプロットの中で最高の満杯量と最低の満杯量が発生する時刻から計算することができる。より詳しくは、パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに含まれるビットストリームに対して、デコーダバッファの最高満杯量と最低満杯量のそれぞれ２つの時刻（ｔＭ，ｔｍ）を事前に又は動的に考える。満杯量は最高と最低の値に数回達してもよいが、ｔＭ＜ｔｍとなるような最も大きな値の（ｔＭ，ｔｍ）の組を考える。リーキーバケットが適切に計算できると仮定すると、Ｂは、値Ｒ、Ｆに対するビットストリームを含む最低バッファサイズである。
【００７８】
【数４】

【００７９】
ここで、ｂ（ｔ）は、時刻ｔでのフレームのビット数であり、Ｍはフレーム／秒でのフレームレートである。この方程式において、ｎは時刻ｔＭとｔｍとの間のフレーム数であり、ｃはこれらフレームに対するビットの合計である。
【００８０】
この方程式は、ｒ＝Ｒで、−ｎ／Ｍが線の傾斜となる直線Ｂ（ｒ）の点として解釈することができる。値ｔＭとｔｍの最大の組が同じ値に留まるようなビットレート範囲ｒ∈［Ｒ−ｒ１，Ｒ＋ｒ２］が存在する。ここで、上記方程式は、ビットレートｒに関連する最小バッファサイズを定める直線に対応する。ビットレートｒが上記範囲外にある場合は、値ｔＭ及び／又はｔｍの少なくとも一つが変化する。ここで、ｒ＞Ｒ＋ｒ２のときは、ｔＭとｔｍとの間の時間間隔はより小さくなる。そして、Ｂ（ｒ）を定める新たな直線におけるｎの値もより小さくなり、および各線の傾斜はより大きくなる（より負でなくなる）。ｒ＜Ｒ−ｒ１のときは、ｔＭとｔｍとの間の時間間隔は大きくなり、およびＢ（ｒ）を定める直線におけるｎの値も増大する。線の傾斜はこのとき、より小さくなる（より負になる）。
【００８１】
ビットレートの範囲に対する（ｔＭ，ｔｍ）の組の値（あるいはこれに関連するｎの値）とｃのいくつかの値（任意の組に対して少なくとも一つ）は、ビットストリームのヘッダに格納してもよく、それゆえ上記方程式を用いて、部分的に線形のＢ（ｒ）曲線を得ることができる。加えて、この方程式を用いて、エンコーダがビットストリームを生成した後、リーキーバケットモデルのパラメータの計算を簡易化するようにしてもよい。
【００８２】
試みに、図５のビットストリームは、７９７Ｋｂｐｓの平均ビットレートを発生するように生成された。図５に一般的に示されるように、７９７Ｋｂｐｓの一定の伝送レートでは、デコーダは、約１８，０００Ｋビットのバッファサイズ（Ｒ_ｘ，Ｂ_ｘ）を必要とする。初期デコーダバッファ満杯量が１８，０００Ｋビットに等しい場合は、立上り遅延は、約２２．５秒となる。そのため、その全符号化長に対して本質的に可能な限り最良の品質を達成するために、この（レート制御なしに生成された）符号化により２２．５秒までビットがシフトされる。
【００８３】
図５は、ピーク伝送レート２,５００Ｋｂｐｓ（例えば、２倍速ＣＤのビデオビットレートの部分）では、デコーダはたった２,２７２Ｋビットのバッファサイズ（Ｒ_ｙ，Ｂ_ｙ）を必要とするだけであり、これは、コンシューマ向けハードウェア装置としては妥当なものである。初期バッファ満杯量が２,２７２Ｋビットに等しい場合、その立上り遅延は約０.９秒に過ぎない。
【００８４】
それゆえ、この符号化にとって、典型的には２つのリーキーバケットモデル、例えば、（Ｒ＝７９７Ｋｂｐｓ，Ｂ＝１８，０００Ｋビット，Ｆ＝１８，０００Ｋビット）及び（Ｒ＝２，５００Ｋｂｐｓ，Ｂ＝２，２７２Ｋビット，Ｆ＝２，２７２Ｋビット）のモデルが有用である。この最初のリーキーバケットのパラメータセットは、約２２．５秒の遅延でビデオを一定のビットレートのチャネルにわたって伝送することを許容する。多くのシナリオにとって、この遅延はあまりに大きいが、例えば映画のインターネットストリーミングのためにはおそらく、許容しうるものである。リーキーバケットパラメータの二番目のセットは、約０．９秒の遅延で、ピークレート２，５００Ｋｂｐｓの共用ネットワークを介してビデオを伝送し、又は２倍速ＣＤからローカルで再生することを許容する。この１秒未満の遅延は、ＶＣＲ（ビデオカセットレコーダ）と同様の機能を持つランダムアクセス再生に対して許容される。
【００８５】
この利点は、そのビットストリームにおいて第１のリーキーバケットのみが特定されるものの、第２のリーキーバケットが特定されない場合に起こることを考えれば、明らかである。このような場合、ピークビットレート２，５００Ｋｂｐｓのチャネルで再生する場合でさえ、デコーダは１８，０００Ｋビットのバッファサイズを使い、従って、その遅延はＦ／Ｒ＝１８，０００Ｋビット／２，５００Ｋｂｐｓ＝７．２秒となろう。このような遅延はＶＣＲ同様の機能を持つようなランダムアクセスの再生では許容されないことを理解することができる。しかし、第２のリーキーバケットがさらに特定されると、２，５００Ｋｂｐｓのレートにおいてバッファサイズは、２，２７２Ｋビットに低下し、その遅延は上述したとおり０．９秒に低下する。
【００８６】
他方、第２のリーキーバケットのみ特定され、第１のリーキーバケットが特定されなかったときには、７９７Ｋｂｐｓの一定の伝送レートにおいて、洗練されたデコーダでさえも、必要とされるよりもずっと大きなバッファを用いてバッファがオーバフローしないことを確実にすることを余儀なくされる。すなわち、Ｂ’＝Ｂ＋（Ｒ−Ｒ’）Ｔ＝２，２７２Ｋビット＋（２，５００Ｋｂｐｓ−７９７Ｋｂｐｓ）×１３０秒＝２２３，６６２Ｋビットとなる。このような多大な記憶がある装置において可能であっても、これは、２８１秒すなわちほぼ５分という初期遅延に対応するが、これは許容限度をはるかに超えている。しかし、第１のリーキーバケットも特定される場合、７９７Ｋｂｐｓのレートにおいて、バッファサイズは１８，０００Ｋビットに低下し、および遅延は、上述したように、２２．５秒に低下する。
【００８７】
さらに、双方のリーキーバケットが特定されると、デコーダはこれらの間で、７９７Ｋｂｐｓと２，５００Ｋｂｐｓとの間の任意のビットレートＲに対して、（上記の内挿公式を使って）線形内挿し、それにより所与のレートにおいてほぼ最小のバッファサイズ及び遅延を実現できる。外挿もまた７９７Ｋｂｐｓより低く、２，５００Ｋｂｐｓより高い双方で（粗い破線で図５に示されている）、７９２Ｋｂｐｓと２，５００Ｋｂｐｓとの間（両端含む）の任意の個所での単一のリーキーバケットを用いた外挿と比較すると、より効率的である。
【００８８】
上記実施例により例示されているように、わずか２セットのリーキーバケットパラメータでさえ、バッファサイズをオーダ単位で削減することができ（例えば、ある場合は、２２３，６６２Ｋビットから１８，０００Ｋビットへ、および他の場合は、１８，０００Ｋビットから２，２７２Ｋビットへ）、所与のピーク伝送レートにおける遅延もオーダ単位で削減される（例えば、ある場合は、２８１秒から２２．５秒へ、および、他の場合は、７．２秒から０．９秒へ削減）。
【００８９】
あるいはまた、所与のデコーダバッファサイズに対するピーク伝送レートを減少させることもできる。実際、図５から明らかなように、複数のリーキーバケットを内挿及び／又は外挿することによりＲ−Ｂ曲線が得られるならば、固定の物理的バッファサイズをもつデコーダが、デコーダバッファのアンダーフローなしに安全にビットストリームを復号化するために必要とされる最小のピーク伝送レートを選ぶことができる。例えば、デコーダがサイズ１８,０００Ｋビットの固定バッファを有するならば、符号化のためのピーク伝送レートは７９７Ｋｂｐｓ程度の低さにすることができる。しかし、第２のリーキーバケットが特定されるものの、第１のリーキーバケットは特定されない場合、デコーダは、ビットレートをＲ’＝Ｒ−（Ｂ’−Ｂ）／Ｔ＝２,５００Ｋｂｐｓ−（１８,０００Ｋビット−２,２７２Ｋビット）／１３０秒＝２,３７９Ｋｂｐｓより低いビットレートまでも減らすことができる。この場合、単一のリーキーバケットを用いるのに比べ、２つのリーキーバケットを使うだけで、同じデコーダバッファサイズに対して係数４だけピーク伝送レートを減らすことになる。
【００９０】
複数のリーキーバケットパラメータを有することにより、同じ平均符号化レートで再構成されたビデオの質もまた改善できる。双方のリーキーバケットが符号化に用いることができる場合を考える。上述のように、デコーダにおけるこの情報をもって、ピーク伝送レートが７９７Ｋｂｐｓの場合は、２２.５秒の遅延で、そして、ピーク伝送レートが２,５００Ｋｂｐｓの場合は、０.９秒の遅延で、符号化して再生することができる。
【００９１】
しかし、第２のリーキーバケットが用いることができないとすると、遅延は２,５００Ｋｂｐｓで０.９秒から７.２秒に増加する。第２のリーキーバケットの利点なしに遅延を０.９秒に減らす１つの方法は、（第１のリーキーバケットの）バッファサイズを１８,０００Ｋビットから（０.９秒×２,５００Ｋｂｐｓ）＝２,２５０Ｋビットに減らすことにより、レートを制御してクリップを再符号化することである。これにより、７９７Ｋｂｐｓにおける遅延が２２.５秒から２.８秒に減少しても、ピーク伝送レートが２,５００Ｋｂｐｓならば、遅延はたった０.９秒になることが確かである。しかし、結果として、品質（ＳＮＲ）もまた、数ｄＢと推定される量だけ、特に大きなダイナミックレンジを持つクリップに対して減少する。
【００９２】
従って、第２のリーキーバケットを特定することにより、クリップあたり無視しうる量の追加のビットを除いて、第２のリーキーバケットを特定することで、平均ビットレートを変えることなく、ＳＮＲを多分数ｄＢ増やすことができる。ＳＮＲにおけるこの増加は、各ピーク伝送レートに対して再生の際顕著である。
【００９３】
一般化されたリファレンスデコーダに複数のリーキーバケットを特定することの利点は、単一の符号化が行われ、異なるピークレートのチャネルを介して伝送され、又は、異なる物理的バッファサイズを持つ装置に伝送される場合に理解される。しかし、実際には、これは、ますます普通になりつつある。例えば、オフラインで符号化され、ディスクに格納されたコンテンツは、異なるピークレートをもつネットワークを流れるとともに、しばしば、ローカルで再生される。ローカルの再生においてさえ、種々の駆動速度（例えば、１倍速ＣＤから８倍速ＤＶＤ）がピーク伝送レートに影響する。さらに、ネットワーク接続を通したピーク伝送レートは、一般的にエンドユーザに近い制限リンク（例えば、１００又は１０ｂａｓｅＴイーサネット（登録商標）、Ｔ１、ＤＳＬ、ＩＳＤＮ、モデムその他）の速度に劇的に従う。再生装置のバッファ容量もまた、数ギガバイトのバッファ空間を持つデスクトップコンピュータから数オーダ小さいバッファ空間を持つ小型コンシューマ向け電子機器へと大きく変化する。複数のリーキーバケットと本発明により提案された一般化されたリファレンスデコーダとによって、同一のビットストリームが、最小立上り遅延、最小デコーダバッファ要求及び最大可能品質を持つ種々のチャネルを介して伝送されることを可能とする。これは、オフラインで符号化されるビデオだけでなく、異なるチャネルを介して異なる装置に同時に配信されるライブビデオにも適用される。要約すれば、本発明により提案された一般化されたリファレンスデコーダは、既存のビットストリームに大きな柔軟性を加えるということである。
【００９４】
先に詳述したことから理解できる通り、先行技術に対して改良された一般化されたリファレンスデコーダが提供される。一般化されたリファレンスデコーダは、エンコーダからの少量の情報のみを（例えば、ビットストリームのヘッダにおいて）必要とするだけで、帯域幅がさまざまであり、及び／又は端末が種々のビットレート及びバッファ容量を持つ現代のネットワークを介してのビットストリームの配信に対して、より高い柔軟性を提供する。本発明のリファレンスデコーダは、可能な帯域幅に対して伝送遅延を最小に減らす一方、これらの新しいシナリオを可能にし、さらに加えて、所与の物理的バッファサイズの制限をもつ装置に対する配信のためのチャネルビットレート要件を仮想的に最小化する。
【００９５】
本発明は、種々の変更や代案の構成が可能であるが、図示された実施例を図面に表し、上記に詳細に記述してきた。しかし、本発明を開示された特定の形態に限定しようという意図がなく、これとは反対に、すべての変更、代案の構成及び本発明の精神と意向のうちにある均等物すべてを包含する意図があることは理解されるべきである。
【図面の簡単な説明】
【図１】本発明を取り入れたコンピュータシステムの一例を示すブロック図である。
【図２】本発明の一態様にしたがってビデオ又は映像データを符号化及び復号化するためのエンハンストエンコーダと一般化されたリファレンスデコーダ及びそれらのそれぞれのバッファを示すブロック図である。
【図３】パラメータ（Ｒ，Ｂ，Ｆ）のリーキーバケットに含まれているバッファ満杯量を時間にわたって示すグラフである。
【図４】代表的なビデオクリップに対するレート対バッファサイズの曲線を示すグラフである。
【図５】本発明の一態様に従って内挿及び外挿するための一般化されたリファレンスデコーダに提供された２つのリーキーバケットモデル（のパラメータセット）をもつ代表的なビデオクリップに対するレート対バッファサイズの曲線を示すグラフである。
【符号の説明】
１２０ 動作環境
１２２ プロセッサ
１２４ メモリ
１２６ ディスプレイ
１２８ キーボード
１３０ オペレーティングシステム
１３２ アプリケーションプログラム
１３４ 通知管理プログラム
１３６ 電源
１４０ ＬＥＤ
１４４ オーディオ発生器
２００ 入力データ
２０２ エンハンストエンコーダ
２０４ エンコーダバッファ
２０６ 伝送媒体（パイプ）
２０８ デコーダバッファ
２１０ 一般化されたリファレンスデコーダ
２１２ 出力データ
２１４ リーキーバケットパラメータ

Claims (22)

1. 所与のビデオクリップについての符号化されたデータのビットストリームのために提供されるパラメータの複数のセットであって、各々が該所与のビデオクリップについての符号化されたデータのビットストリームためのリファレンスデコーダのモデルを特徴付け、前記所与のビデオクリップについての符号化されたデータのビットストリームためのレートパラメータおよびデコーダバッファサイズパラメータを含むパラメータの複数のセットを受信するステップと、
   前記パラメータの複数のセットの各々によって前記所与のビデオクリップの符号化されたデータを復号するためのピークレートまたはピークデコーダバッファサイズを含む動作条件が決定されるよう、前記パラメータの複数のセットを処理するステップと
   を備えたことを特徴とするコンピュータに実装される方法。
2. 前記所与のビデオクリップについての符号化されたデータのビットストリームのために提供される前記パラメータのセットの数を示す情報を受信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
3. 前記所与のビデオクリップについての符号化されたデータのビットストリームのために提供される別のパラメータの複数のセットを受信するステップと、
   前記別のパラメータの複数のセットによって前記動作条件が決定されるよう、前記別のパラメータの複数のセットを処理するステップと
   をさらに備えたことを特徴とする請求項１に記載の方法。
4. 前記パラメータの複数のセットは、帯域外で提供されることを特徴とする請求項１に記載の方法。
5. 前記パラメータの複数のセットは、該パラメータの複数のセットが挿入された、前記ビデオビットストリームのストリームヘッダから処理を開始されることを特徴とする請求項１に記載の方法。
6. 前記パラメータの複数のセットを処理するステップは、前記動作条件を決定するステップを含むことを特徴とする請求項１に記載の方法。
7. 前記動作条件を決定するステップは、前記パラメータの複数のセットのうちの１つのから１つのパラメータを選択するステップを含むことを特徴とする請求項６に記載の方法。
8. 前記動作条件を決定するステップは、前記パラメータの複数のセットのうちの２つのセットの間を内挿するステップを含むことを特徴とする請求項６に記載の方法。
9. 前記動作条件を決定するステップは、前記パラメータの複数のセットのうちの２つのセットについて外挿するステップを含むことを特徴とする請求項６に記載の方法。
10. 前記ピークレートは最小ピークレートであり、前記動作条件を決定するステップは、前記パラメータの複数のセットの１または２以上のデコーダバッファサイズパラメータを用いて前記最小ピークレートを決定するステップを含むことを特徴とする請求項６に記載の方法。
11. 前記動作条件を決定するステップは、前記パラメータの複数のセットの１または２以上の前記レートパラメータを用いて前記デコーダバッファサイズを決定するステップを含むことを特徴とする請求項６に記載の方法。
12. 前記パラメータの複数のセットの各々は、初期バッファ満杯パラメータをさらに含むことを特徴とする請求項１ないし１１のいずれかに記載の方法。
13. 前記パラメータの複数のセットの各々は、前記所与のビデオクリップについての符号化されたデータのビットストリームのためのリファレンスデコーダの別のリーキーバケットモデルを特徴付けることを特徴とする請求項１ないし１１のいずれかに記載の方法。
14. 前記パラメータの複数のセットの各々は、前記所与のビデオクリップについての符号化されたデータのビットストリームのためのレート−デコーダバッファサイズ曲線に沿って異なる点を表していることを特徴とする請求項１ないし１１のいずれかに記載の方法。
15. 前記デコーダバッファサイズパラメータは、前記パラメータの複数のセットの各々について異なることを特徴とする請求項１ないし１１のいずれかに記載の方法。
16. 前記レートパラメータは、前記パラメータの複数のセットの各々について異なることを特徴とする請求項１ないし１１のいずれかに記載の方法。
17. 前記ピークレートは、前記符号化されたデータを復号する際のディスクの駆動速度に対応することを特徴とする請求項１ないし１１のいずれかに記載の方法。
18. 前記ピークレートは、前記符号化されたデータを復号する際のネットワーク接続の伝送レートに対応することを特徴とする請求項１ないし１１のいずれかに記載の方法。
19. 前記符号化されたデータの復号は、前記所与のビデオクリップのライブビデオ伝送の間になされることを特徴とする請求項１ないし１１のいずれかに記載の方法。
20. 前記符号化されたデータの復号は、前記所与のビデオクリップのオンデマンド伝送の間になされることを特徴とする請求項１ないし１１のいずれかに記載の方法。
21. 請求項１ないし１１のいずれかの方法を実行するようコンピュータシステムに実行させるコンピュータ実行可能な命令を格納したコンピュータ読取可能な媒体。
22. 請求項１ないし１１のいずれかの方法を実行するよう調整されたコンピュータシステム。

Images