(57)【特許請求の範囲】
【請求項１】
複数のフレームからなるビデオセグメントの全体である第１の部分に対して、伝送ビットレートの特徴を示す第１の複数の値のセットを定義し、前記ビデオセグメントの開始点である第１のフレームに該第１の複数の値のセットを格納し、
前記第１の部分に対して、バッファサイズの特徴を示す第２の複数の値のセットを定義し、前記第１のフレームに該第２の複数の値のセットを格納し、
前記第１の部分に対して、ビデオシーケンスが提示されるまでの遅延の特徴を示す第３の複数の値のセットを定義し、前記第１のフレームに該第３の複数の値のセットを格納し、
前記ビデオセグメントの前記第１の部分における所定の位置以降の部分であって複数のフレームからなる第２の部分に対して、ビデオシーケンスが提示されるまでの遅延の特徴を示す第４の複数の値のセットを定義し、前記第２の部分の開始点である第２のフレームに該第４の複数の値のセットを格納し、
前記第１の複数の値のセット、前記第２の複数の値のセットおよび前記第３の複数の値のセットを、前記第１の部分においてオーバーフロー状態が発生しないように選択し、
前記第１の複数の値のセット、前記第２の複数の値のセットおよび前記第４の複数の値のセットを、前記第２の部分においてオーバーフロー状態が発生しないように選択することを特徴とする画像符号化方法。
【請求項２】
複数のフレームからなるビデオセグメントの全体である第１の部分に対して、伝送ビットレートの特徴を示す第１の複数の値のセットを定義し、前記ビデオセグメントの開始点である第１のフレームに該第１の複数の値のセットを格納する手段と、
前記第１の部分に対して、バッファサイズの特徴を示す第２の複数の値のセットを定義し、前記第１のフレームに該第２の複数の値のセットを格納する手段と、
前記第１の部分に対して、ビデオシーケンスが提示されるまでの遅延の特徴を示す第３の複数の値のセットを定義し、前記第１のフレームに該第３の複数の値のセットを格納する手段と、
前記ビデオセグメントの前記第１の部分における所定の位置以降の部分であって複数のフレームからなる第２の部分に対して、ビデオシーケンスが提示されるまでの遅延の特徴を示す第４の複数の値のセットを定義し、前記第２の部分の開始点である第２のフレームに該第４の複数の値のセットを格納する手段と、
前記第１の複数の値のセット、前記第２の複数の値のセットおよび前記第３の複数の値のセットを、前記第１の部分においてオーバーフロー状態が発生しないように選択する手段と、
前記第１の複数の値のセット、前記第２の複数の値のセットおよび前記第４の複数の値のセットを、前記第２の部分においてオーバーフロー状態が発生しないように選択する手段と、
を備えることを特徴とする画像符号化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像符号化方法、より詳細には、ハイポセティカル（仮想的）標準デコード方法に関する。
【背景技術】
【０００２】
デジタルビデオシステムは、音声と、画像と、ユーザに対する協調した提示のための補助的成分とを含む映像を組み立てるトランスミッタ及びレシーバを含む。トランスミッタシステムは、デジタルソースデータ（プログラムの音声、映像、及び補助的データ成分を表すエレメンタリ又はアプリケーションデータストリーム）の受信及び圧縮と、いくつかのエレメンタリデータストリームから単一のトランスポートビットストリームへのデータの多重化と、データのレシーバへの送信とを行うためにサブシステムを含む。レシーバにおいて、トランスポートビットストリームは、構成要素であるエレメンタリデータストリームへ逆多重化される。エレメンタリデータストリームはデコードされ、オーディオ及びビデオデータストリームは、協調したプログラムの一部として表示するために、レシーバの提示サブシステムに対して、同期したプログラム要素として送給される。
【０００３】
多くのビデオコーディング規格において、デコーダに対する規格準拠のビットストリームは、エンコーダの出力に概念的に接続され、デコーダバッファと、デコーダと、ディスプレイユニットとによって構成される仮想的なデコーダによってデコードされる。この仮想デコーダは、Ｈ．２６３において仮想標準デコーダ（ＨＲＤ）として知られており、ＭＰＥＧ−２においてビデオバッファリングベリファイヤ（ＶＢＶ）として知られている。エンコーダは、仮想的なデコーダバッファがオーバフロー又はアンダフローしないようにビットストリームを作成する。
【０００４】
結果として、レシーバがバッファする必要が生じ得るデータの量は、その容量を上回る恐れ（メモリオーバフローの状態）、或いはスループット能力を上回る恐れがある。あるいは、レシーバは、オーディオ又はビデオデータストリームにおいて指定された瞬間でのデコード及び同期した提示のために、データアクセス単位時間に全てのデータを受信できない恐れがあり、結果として、データの喪失と一貫性のないパフォーマンスとが生じる（メモリアンダフローの状態）かもしれない。
【０００５】
既存の仮想標準デコーダにおいて、ビデオビットストリームは、任意の一定のビットレート（通常は、ビット／秒の単位のストリームの平均レート）で受信され、バッファの蓄積量が所望のレベルに達するまで、デコーダバッファに格納される。こうした所望のレベルは、初期デコーダバッファ蓄積量と呼ばれ、伝送遅延又は開始（バッファ）遅延に正比例する。その時点で、デコーダは、シーケンスの第一のビデオフレーム用のビットを瞬間的に取り除き、ビットをデコードし、フレームを表示する。また後続のフレーム用のビットも、その後、時間間隔毎に瞬間的に取り除かれ、デコードされ、表示される。
【０００６】
従来の仮想標準デコーダは、固定されたビットレート、バッファサイズ、及び初期遅延で動作する。しかしながら、現在のビデオアプリケーション（例えば、インターネット又はＡＴＭネットワークを介したビデオストリーミング）の多くにおいて、利用可能な帯域幅は、ネットワーク経路（例えば、ユーザがネットワークにどのように接続するか、モデム、ＩＳＤＮ、ＤＬＳ、ケーブル、その他）によって変化し、更に、ネットワーク状態（例えば、混雑、接続ユーザ数、その他）によって時間内で変動する。加えて、ビデオビットストリームは、バッファ能力の異なる様々なデバイス（例えば、ハンドセット、ＰＤＡ、ＰＣ、セットトップボックス、ＤＶＤのようなプレイヤ、等々）に送給され、遅延要件の異なるシナリオ（例えば、低遅延ストリーミング、プログレッシブダウンロード、その他）のために作成される。結果として、こうしたアプリケーションは、異なるピークビットレートと、異なるバッファサイズ及び開始遅延とによりビットストリームをデコードできる更に柔軟な仮想標準デコーダを必要とする。
【０００７】
Ｊｏｒｄｉ  Ｒｉｂａｓ−Ｃｏｒｂｅｒａ及びＰｈｉｌｉｐ  Ａ．  Ｃｈｏｕは、２００１年９月４日の論文「Ｈ．２６Ｌ用の一般化仮想標準デコーダ」（非特許文献１）において、修正した仮想標準デコーダを提案している。デコーダは、所定のビットストリームに対するレート及びバッファパラメータのＮ個のセットに従って動作する。各セットは、孔あきバケツモデルとして知られるものを特徴付け、三つの値（Ｒ，Ｂ，Ｆ）を含む。ここで、Ｒは伝送ビットレート、Ｂはバッファサイズ、Ｆは初期デコーダバッファ蓄積量となる（Ｆ／Ｒは開始又は初期バッファ遅延）である。エンコーダは、いくつかの望ましいＮ個の孔あきバケツに含まれたビデオビットストリームを作成可能であり、或いは、ビットストリームが生成された後で、パラメータのＮ個のセットを単純に計算することができる。仮想標準デコーダは、孔あきバケツのパラメータ間を補間してよく、任意の望ましいピークビットレート、バッファサイズ、又は遅延で動作できる。例えば、ピーク伝送レートＲ’を前提として、仮想標準デコーダは、バッファアンダフロー又はオーバフローの影響を受けることなくビットストリームをデコード可能な最小のバッファサイズ及び遅延を（利用可能な孔あきバケツデータに従って）選択し得る。反対に、所定のバッファサイズＢ’に対して、仮想標準デコーダは、最低限必要なピーク伝送レートを選択して動作し得る。
【０００８】
こうした一般化仮想標準デコーダの使用には利点が存在する。例えば、コンテンツプロバイダは、ビットストリームを一度作成すればよく、サーバは、ピーク伝送レートの異なる様々なチャネルを使用して、能力の異なる複数のデバイスにビットストリームを送給できる。或いは、サーバ及び端末は、所定のネットワーク状態に対する最善の孔あきバケツ、例えば、最小の開始（バッファ）遅延を生成するもの、又はデバイスの所定のバッファサイズに対する最小のピーク伝送レートを必要とするものを取決めることができる。
【０００９】
文献ＶＣＥＧ−５８の第２．１乃至２．４節において説明されるように、孔あきバケツは、時間の関数としてのエンコーダ又はデコーダバッファの状態（蓄積量）に関するモデルである。エンコーダ及びデコーダバッファの蓄積量は、互いを補完するものである。孔あきバケツモデルは、次の三つのパラメータ（Ｒ，Ｂ，Ｆ）によって特徴付けられる。
Ｒは、ビットがデコーダバッファに入る際のピークビットレートである（単位は毎秒ビット）。ビットレートに対して一定であるシナリオにおいて、Ｒは、ビデオクリップのチャネルビットレート及び平均ビットレートとなる場合が多い。
Ｂは、ビデオビットレートの変動を平滑化する前記バケツ又はデコーダバッファのサイズである（単位はビット）。このバッファサイズは、デコードデバイスの物理バッファを上回ることはできない。
Ｆは、デコーダがバッファからのビットの除去を開始する前の初期デコーダバッファ蓄積量である（同じく単位はビット）。Ｆ及びＲは、初期又は開始遅延Ｄを決定し、Ｄ＝Ｆ／Ｒ秒となる。
【００１０】
孔あきバケツモデルにおいて、ビットは、蓄積量のレベルがＦとなるまで（即ち、Ｄ秒間）レートＲでバッファに入り、その後、第一のフレーム用のｂ０ビットが瞬間的に除去される。ビットはレートＲでバッファに入り続け、デコーダは、後続のフレーム用のｂ１、ｂ２．．．ｂｎ−１ビットをある所定の瞬間に除去する。ここでＭをビデオのフレームレートとすると、通常は（必ずではないが）１／Ｍ秒毎に除去する。図１は、パラメータ（Ｒ，Ｂ，Ｆ）の孔あきバケツで制約されたビットストリームのデコーダバッファ蓄積量を時間に沿って例示している。
【００１１】
時間ｔｉにおいてｂｉビットを除去する直前のデコーダバッファ蓄積量をＢｉとする。一般的な孔あきバケツモデルは、次の式に従って動作する。
Ｂ０＝Ｆ
Ｂｉ＋１＝ｍｉｎ（Ｂ，Ｂｉ−ｂｉ＋Ｒ（ｔｉ＋１−ｔｉ）），ｉ＝０，１，２．．．    （１）
通常、ｔｉ＋１−ｔｉ＝１／Ｍ秒であり、ここでＭはビットストリームのフレームレートである（通常、単位はフレーム／秒）。
【００１２】
パラメータ（Ｒ，Ｂ，Ｆ）を有する孔あきバケツモデルは、デコーダバッファのアンダフローが無ければ、ビットストリームを収容する。エンコーダ及びデコーダバッファ蓄積量は互いを補完するため、これは、エンコーダバッファにオーバフローが無いことに等しい。しかしながら、エンコーダバッファ（孔あきバケツ）は空になってもよく、或いは同等に、デコーダバッファは満杯になってもよく、この時点で、エンコーダバッファからデコーダバッファへ伝送されるビットは存在しなくなる。したがって、デコーダバッファは、満杯である時にビットの受領を停止し、式（１）にｍｉｎ演算子が含まれるのはこのためである。満杯のデコーダバッファは、単純に、エンコーダバッファが空であることを意味する。
【００１３】
以下の考察が可能となる。
所定のビデオストリームを多数の孔あきバケツに収容可能である。例えば、ビデオストリームがパラメータ（Ｒ，Ｂ，Ｆ）を有する孔あきバケツに収容される時、ビデオストリームは、更に大きなバッファ（Ｒ，Ｂ’，Ｆ），Ｂ’＞Ｂを有する孔あきバケツ、或いは更に高いピーク伝送レート（Ｒ’，Ｂ，Ｆ），Ｒ’＞Ｒを有する孔あきバケツにも収容される。
任意のビットレートＲ’に対して、システムは、（時間制限のある）ビデオビットストリームを収容するバッファサイズを常に見出せる。最悪の場合（Ｒ’が０に接近するとき）、バッファサイズは、ビットストリーム自体と同じ大きさにする必要がある。言い換えれば、ビデオビットストリームは、バッファサイズが十分に大きい限り、（そのクリップの平均ビットレートに関係なく）任意のレートで伝送できる。
【００１４】
システムが全ての孔あきバケツに対しＦ＝ａＢに固定すると仮定する。ここでａは、初期バッファ蓄積量のある望ましい分数である仮定する。ピークビットレートＲの各値に対して、システムは、式（１）を使用してビットストリームを収容する最小バッファサイズＢｍｉｎを見出せる。Ｒ−Ｂ値の曲線のプロットは、図２に示している。
【００１５】
注意深く見れば、任意のビットストリームの（Ｒｍｉｎ、Ｂｍｉｎ）ペアの曲線（図２のもの等）は、区分的に直線であり凸状である。したがって、曲線のＮ個の点が提供されれば、デコーダは、それらの値を直線的に補間して、僅かだが安全な形で（Ｒｍｉｎ、Ｂｍｉｎ）より大きい、いくつかの点（Ｒｉｎｔｅｒｐ、Ｂｉｎｔｅｒｐ）に到達できる。これにより、ビットストリームをその平均レートで収容する単一の孔あきバケツと比較して一桁、バッファサイズを低減可能であり、結果として遅延も低減できる。あるいは、同じ遅延に対して、ピーク伝送レートを四分の一にすることが可能であり、又は、信号対雑音比を数ｄＢの単位で改善できる可能性もある。
【００１６】
ＭＰＥＧビデオバッファリングベリファイヤ（ＶＢＶ）
ＭＰＥＧビデオバッファリングベリファイヤ（ＶＢＶ）は、二種類のモード、即ち、固定ビットレート（ＣＢＲ）及び可変ビットレート（ＶＢＲ）で動作できる。ＭＰＥＧ−１は、ＣＢＲモードのみをサポートするが、ＭＰＥＧ−２は、両モードをサポートする。
【００１７】
ＶＢＶは、ビットストリームがパラメータ（Ｒ，Ｂ，Ｆ）の孔あきバケツモデルに収容される時、ＣＢＲモードで動作し、次のようになる。
Ｒ＝Ｒｍａｘ＝ストリームの平均ビットレート
Ｂの値は、特別なサイズ単位（即ち、１６×１０２４ビット単位）を使用して、シンタックスパラメータｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅに格納される。
Ｆ／Ｒの値は、特別な時間単位（即ち、９０ＫＨｚクロックの周期数）を使用して、シーケンス内の第一のビデオフレームに関連するシンタックス要素ｖｂｖ＿ｄｅｌａｙに格納される。
【００１８】
デコーダバッファ蓄積量は、以下の式で表される。
Ｂ０＝Ｆ
Ｂｉ＋１＝Ｂｉ−ｂｉ＋Ｒｍａｘ／Ｍ，ｉ＝０，１，２．．．    （２）
エンコーダは、Ｂｉ−ｂｉが常にゼロ以上となり、Ｂｉが常にＢ以下となる状態を確保する必要がある。言い換えると、エンコーダは、デコーダバッファがアンダフロー又はオーバフローしない状態を確保する必要がある。
【００１９】
ＶＢＶは、ビットストリームがパラメータ（Ｒ，Ｂ，Ｆ）の孔あきバケツモデルに制約される時、ＶＢＲモードで動作し、次のようになる。
Ｒ＝Ｒｍａｘ＝ピーク又は最高レート。Ｒｍａｘは、ビットストリームの平均レートより高い。
Ｆ＝Ｂ、即ち、バッファは最初から満杯である。
Ｂの値は、ＣＢＲの場合のように、シンタックスパラメータｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅで表現される。
デコーダバッファ蓄積量は、次の式の通りとなる。
Ｂ０＝Ｂ
Ｂｉ＋１＝ｍｉｎ（Ｂ，Ｂｉ−ｂｉ＋Ｒｍａｘ／Ｍ），ｉ＝０，１，２．．．    （３）
【００２０】
エンコーダは、Ｂｉ−ｂｉが常にゼロ以上となる状態を確保する。即ち、エンコーダは、デコーダバッファがアンダフローしない状態を確保する必要がある。しかしながら、このＶＢＲの場合、エンコーダは、デコーダバッファがオーバフローしない状態を確保する必要はない。デコーダバッファが満杯になった場合には、エンコーダバッファが空であると想定され、したがって、エンコーダバッファからデコーダバッファへ伝送される更なるビットは存在しない。
【００２１】
ＶＢＲモードは、ピークレートＲｍａｘまでデータを読み取り可能なデバイスにとって有用である。例えば、ＤＶＤビデオストリームの平均レートは僅か４Ｍビット／秒であるが、ＤＶＤは、Ｒｍａｘが約１０Ｍビット／秒であるＶＢＲクリップを含み、Ｒｍａｘはディスクドライブの最大読み取り速度に対応する。
【００２２】
図３Ａ及び図３Ｂを参照すると、それぞれＣＢＲ及びＶＢＲモードで動作するあるビットストリームに対するデコーダバッファ蓄積量のプロットが図示されている。
大まかに言うと、ＣＢＲモードは、Ｒｍａｘが偶然にクリップの平均レートとなったＶＢＲの特殊なケースと考えられる。
【００２３】
Ｈ．２６３の仮想標準デコーダ（ＨＲＤ）
Ｈ．２６３用の仮想標準モデルは、以下の点を除き、上で説明したＭＰＥＧのＶＢＶのＣＢＲモードと同様である。
デコーダは、バッファ蓄積量をある時間間隔で検査し、フレームの全ビットが利用可能になるとすぐにフレームをデコードする。このアプローチの結果として、二つの利点が生じ、即ち、（ａ）Ｆは通常、第一のフレーム用のビット数よりも僅かに大きいため、遅延が最小化され、（ｂ）フレームのスキップが一般的である場合、デコーダは、単純に、次に利用可能なフレームまで待機する。後者は、ＭＰＥＧのＶＢＶの低遅延モードにおいても可能となる。
バッファオーバフローのチェックは、フレーム用のビットがバッファから除去された後で実行される。これにより、大きなＩフレームを時折送信するための制約が緩和されるが、最大のフレームに対する最大値が存在する。
Ｈ．２６３のＨＲＤは、基本的に、低遅延孔あきバケツの一種にマッピング可能である。
【００２４】
以前の仮想標準デコーダの制限
以前から存在する仮想標準デコーダは、図２の曲線の一点（Ｒ，Ｂ）のみで動作する。結果として、こうしたデコーダは、次の欠点を有する。
チャネルＲ’において利用可能なビットレートがＲより低い場合（これは例えば、インターネットストリーミング及びプログレッシブダウンロードにおいて、或いはＭＰＥＧ  ＶＢＲクリップをピークより低いレートで送信する必要がある時に、一般的である）、厳密に言えば、仮想標準デコーダは、ビットストリームをデコードできない。
利用可能な帯域幅Ｒ’がＲより大きい場合（これも例えば、インターネットストリーミングとローカルでの再生とにおいて、一般的である）、従来の仮想標準デコーダは、ＶＢＲモードで動作し、ビットストリームをデコードできる。しかしながら、レート−バッファ曲線上で更に多くの情報が利用可能である場合、ビットストリームをデコードするのに必要なバッファサイズ及び関連する開始遅延は、大幅に低減できる。
デコーダデバイスの物理バッファサイズがＢより小さい場合、デバイスは、そのビットストリームをデコードできない。
バッファサイズがＢより大きい場合、デバイスは、ビットストリームをデコードできるが、開始遅延は同じとなる。
更に一般的には、孔あきバケツ（Ｒ，Ｂ，Ｆ）に従って生成されたビットストリームは、通常、ビットレートがＲより小さい異なるネットワークを介して配信できず、バッファサイズがＢより小さい様々なデバイスに対して配信できない。更に、開始遅延は、最小化されない。
【００２５】
一般化仮想標準デコーダ（ＧＨＲＤ）
一般化仮想標準デコーダ（ＧＨＲＤ）は、Ｎ個の孔あきバケツモデルの情報、
（Ｒ１，Ｂ１，Ｆ１），（Ｒ２，Ｂ２，Ｆ２），．．．，（ＲＮ，ＢＮ，ＦＮ），  （４）
を前提として動作可能であり、孔あきバケツモデルのそれぞれがビットストリームを収容する。一般性を失うことなく、これらの孔あきバケツが、最小から最大のビットレートの順序、即ち、Ｒｉ＜Ｒｉ＋１の順序であると仮定する。更に、エンコーダは、これらの孔あきバケツモデルを正確に計算し、したがってＢｉ＜Ｂｉ＋１となると仮定する。
【００２６】
Ｎの望ましい値は、エンコーダによって選択できる。Ｎ＝１である場合、ＧＨＲＤは、ＭＰＥＧのＶＢＶと本質的に同等になる。エンコーダは、（ａ）孔あきバケツの値を事前に選択して、全ての孔あきバケツの制約を確実に満たすレート制御と共に、ビットストリームをエンコードすること、（ｂ）ビットストリームをエンコードし、その後、式（１）を使用して、Ｎ個の異なるＲの値でビットストリームを収容する孔あきバケツのセットを計算すること、或いは（ｃ）その両方を行うことを選択できる。第一のアプローチ（ａ）は、ライブ又はオンデマンド送信に適用可能であり、一方、（ｂ）及び（ｃ）は、オンデマンドのみに適用される。
【００２７】
孔あきバケツの数Ｎ及び孔あきバケツパラメータ（４）は、ビットストリームに挿入される。これにより、デコーダは、利用可能なピークビットレート及び／又は物理バッファサイズが分かっている状態で、どの孔あきバケツの使用を希望するかを判断できる。（４）の孔あきバケツモデルと、全ての直線的な補間又は外挿モデルとを使用できる。図４は、Ｎ個の孔あきバケツモデルのセットと、その補間又は外挿された（Ｒ，Ｂ）値とを例示している。
【００２８】
点ｋと点ｋ＋１との間での補間バッファサイズＢは、直線に従う。
Ｂ＝｛（Ｒｋ＋１−Ｒ）／（Ｒｋ＋１−Ｒｋ）｝Ｂｋ＋｛（Ｒ−Ｒｋ）／（Ｒｋ＋１−Ｒｋ）｝Ｂｋ＋１    Ｒｋ＜Ｒ＜Ｒｋ＋１
同様に、初期デコーダバッファ蓄積量Ｆは、直線的に補間できる。
Ｆ＝｛（Ｒｋ＋１−Ｒ）／（Ｒｋ＋１−Ｒｋ）｝Ｆｋ＋｛（Ｒ−Ｒｋ）／（Ｒｋ＋１−Ｒｋ）｝Ｆｋ＋１    Ｒｋ＜Ｒ＜Ｒｋ＋１
【００２９】
最小バッファサイズＢｍｉｎがＲ及びＦの両方について凸状であり、即ち、任意の凸状の組み合わせ（Ｒ，Ｆ）＝ａ（Ｒｋ，Ｆｋ）＋（１−ａ）（Ｒｋ＋１，Ｆｋ＋１），０＜ａ＜１に対応する最小バッファサイズＢｍｉｎが、Ｂ＝ａＢｋ＋（１−ａ）Ｂｋ＋１以下となるため、結果的に得られる、パラメータ（Ｒ，Ｂ，Ｆ）を有する孔あきバケツは、ビットストリームを収容する。
【００３０】
ＲがＲＮより大きい場合、孔あきバケツ（Ｒ，ＢＮ，ＦＮ）もビットストリームを収容し、したがって、ＢＮ及びＦＮは、Ｒ＞＝ＲＮである時に推奨されるバッファサイズ及び初期デコーダバッファ蓄積量であると考察される。ＲがＲ１より小さい場合には、上限Ｂ＝Ｂ１＋（Ｒ１−Ｒ）Ｔを発生させることが可能であり（一度、Ｆ＝Ｂに設定できる）、ここでＴは、秒を単位とするストリームの時間の長さとする。こうしたＮ個の点の範囲を外れた（Ｒ，Ｂ）値も、図４に図示されている。
【００３１】
ＩＳＯ／ＩＥＣ  ＭＰＥＧのジョイントビデオチーム及びＩＴＵ−Ｔ  ＶＣＥＧワーキングドラフト第二版改訂０（ＷＤ−２）は、Ｍｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎのＪｏｒｄｉ  Ｒｉｂａｓ−Ｃｏｂｅｒａらが提案した仮想標準デコーダの多数の概念を組み込んでおり、これは参照により本明細書に組み込むものとする。ＷＤ−２文書は、Ｍｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎのＪｏｒｄｉ  Ｒｉｂａｓ−Ｃｏｂｅｒａらが提案したデコーダに類似するが、シンタックスが幾分変形されている。加えて、ＷＤ−２では、所定のレートＲに対してＢ及びＦを計算するアルゴリズムの例を説明している。
【先行技術文献】
【非特許文献】
【００３２】
【非特許文献１】Ｊｏｒｄｉ  Ｒｉｂａｓ−Ｃｏｒｂｅｒａ及びＰｈｉｌｉｐ  Ａ．  Ｃｈｏｕ“Ａ  ｇｅｎｅｒｉｚｅｄ  ｈｙｐｏｔｈｅｔｉｃａｌ  ｒｅｆｅｒｅｎｃｅ  ｄｅｃｏｄｅｒ  ｆｏｒ  Ｈ．２６Ｌ（Ｈ．２６Ｌ用の一般化仮想標準デコーダ）”２００１年９月４日
【図面の簡単な説明】
【００３３】
【図１】デコーダバッファ蓄積量を例示する図である。
【図２】Ｒ−Ｂ曲線を例示する図である。
【図３Ａ】ＣＢＲ及びＶＢＲモードで動作するあるビットストリームに対するデコーダバッファ蓄積量のプロット図である。
【図３Ｂ】ＣＢＲ及びＶＢＲモードで動作するあるビットストリームに対するデコーダバッファ蓄積量のプロット図である。
【図４】Ｎ個の孔あきバケツモデルのセットと、その補間又は外挿された（Ｒ，Ｂ）値とを例示する図である。
【図５】レートがＲｊである時にユーザがシークするデコーダの任意の点に対する初期バッファリングＢｊを例示する図である。
【図６】特定のビデオストリームに対して先見的な形で定義された（Ｒ，Ｂ，Ｆ）のセットを例示する図である。
【図７】ビデオセグメントに対する初期バッファ蓄積量（単位はビット）を例示する図である。
【図８】図７の１０個の点のセットの選択基準を例示する図である。
【図９】選択基準を例示する図である。
【図１０】遅延の低減を例示する図である。
【発明を実施するための形態】
【００３４】
先に説明したように、ＪＶＴ規格（ＷＤ−２）は、ビットストリームに含まれる（Ｎ＞＝１）個の孔あきバケツ（Ｒ１，Ｂ１，Ｆ１），．．．，（ＲＮ，ＢＮ，ＦＮ）の値の格納を許容している。これらの値は、ヘッダに格納してよい。Ｆｉを初期バッファ蓄積量として使用し、Ｂｉをバッファサイズとして使用することで、入力ストリームがレートＲｉで着信する時に、デコーダバッファがアンダフローしない状態が保証される。これは、ユーザがエンコード済みビデオを始めから終わりまで提示したい場合に当てはまる。通常のビデオオンデマンドアプリケーションにおいて、ユーザは、ビデオストリームの様々な部分をシークしたい場合がある。ユーザがシークしたいポイントは、アクセスポイントと呼ばれる。ビデオデータを受信して、ビデオフレームを構築するプロセス中、バッファ内のデータ量は変動する。考察の結果、本発明者は、アクセスポイントからのビデオのデコードを開始する前に、初期バッファ蓄積量のＦｉ値（チャネルレートがＲｉの時）を使用した場合、デコーダがアンダフローを有する可能性があることに気付いた。例えば、アクセスポイント又はその後の何らかの時点において、ビデオの再構築に必要なビットの量は、現在バッファ内にあるビットより大きくなる場合があり、結果として、アンダフローが生じ、ビデオフレームをタイミング良く提示できなくなる。ビデオストリーム内において、デコーダにアンダフローがない状態を確保するのに必要な初期バッファ蓄積量の値が、ユーザのシークするポイントに基づいて変化することも同様に証明できる。この値は、Ｂｉに制限される。したがって、ビデオシーケンス全体に対して与えられたＢ及びＦの組み合わせは、ビデオの途中の点に対して使用された場合、適切ではない可能性が高く、結果として、アンダフローが生じ、したがって、フレームがフリーズする。
【００３５】
これまで認識されていない、こうしたアンダフローの可能性に基づいて、本発明者は、次に、ただ一組のＲ、Ｂ、及びＦ値がビデオセグメント全体に対して定義された場合、ユーザがアクセスポイントへジャンプした時に、レートＲに対応するバッファＢが満杯又は実質的に満杯（又は９０％より高い蓄積）となってフレームのデコードを開始するまでシステムは待機するべきであることに気付いた。これにより、バッファの初期蓄積量は最大となり、したがって、アクセスポイントから開始される後続のデコーディング中に、アンダフローの可能性は存在しなくなる。これは、既存のビットストリームに対する何らかの追加的な変更なく達成し得るものであり、そのため、既存のシステムに影響を与えない。したがって、図５に示したように、デコーダは、レートがＲｊである時に、ユーザがシークする任意のポイントに対して、初期バッファリング値Ｂｊを使用する。しかしながら、これは、残念なことに、ビデオの提示を始めるための異なる位置（例えば、アクセスポイント）を選択した後で、ビデオフレームが提示されるまでに大きな遅延を発生させる場合がある。
【００３６】
初期バッファ蓄積量（Ｆ）は、同様に、ビデオシーケンスを提示するまでの遅延として特徴付けられる。遅延は、初期バッファ蓄積量（Ｆ）に達するまでに必要な時間に関連する時間的な性質のものである。遅延及び／又はＦは、ビデオ全体又はアクセスポイントに関連付けられる。同様に、遅延は、本明細書で説明する全ての実施形態において、Ｆに代用してよいと理解される（例えば、（Ｒ，Ｂ，遅延）とする）。遅延の特定の値の一つは、特別な時間単位（９０ＫＨｚクロックの単位）を使用して、遅延＝Ｆ／Ｒとして計算することができる。
【００３７】
遅延の可能性を低減するために、本発明者は、（Ｒ，Ｂ，Ｆ）のセットを、特定のビデオストリームに対して、各アクセスポイントに定義し得ることに気付いた。図６を参照すると、こうした（Ｒ，Ｂ，Ｆ）のセットは、好ましくは、特定のビデオストリームに対して先見的な形で定義される。例えば、（Ｒ，Ｂ，Ｆ）値のセットは、ビデオストリーム全体に対して、従来の方法で計算してよく、加えて、例えばビデオストリーム全体のものと同じ（Ｒ，Ｂ）値について、Ｆ値のセットを、位置“２”以降のビデオストリームに対して、従来の方法で計算してもよい。同様のプロセスが、残りのアクセスポイントに対して用いられる。アクセスポイントは、ビデオシーケンス内の任意のフレームにしてよく、シーケンスのＩフレーム、シーケンスのＢフレーム、又はシーケンスのＰフレームにしてよい（Ｉ、Ｂ、及びＰフレームは、通常、ＭＰＥＧに基づくビデオエンコードに使用される）。したがって、ユーザは、アクセスポイントの一つを選択し、その後、（バッファＢｉ及びレートＲｉが変化しないと仮定して）望ましい初期蓄積量に対するそれぞれのＦｉｊを使用してよく、或いは、その他の場合には、Ｒｉ、Ｂｉ、Ｆｉｊのうち二つ以上のセットを使用してよい。
【００３８】
インデックス「ｉ」は、各孔あきバケツを表し、インデックス「ｊ」は、各ランダムアクセスポイントを表す。バッファＢｉ及びレートＲｉが変化しないと仮定した場合には、（Ｂｉ，Ｒｉ，Ｆｉｌ）の複数のセットが、ヘッダに格納される。ここでｉ＝１，２，．．．，Ｎであり、Ｆｉｌが初期バッファ蓄積量を表す値である。次に、Ｆｉｊが、各アクセスポイントｊに格納される。ここでｊ＝２，３，．．．，である。一方、バッファＢｉ及びレートＲｉが各アクセスポイントｊにおいて変化すると仮定した場合には、値（Ｂｉｊ，Ｒｉｊ，Ｆｉｊ）の複数のセットをアクセスポイントに格納してよい。前者のケースの利点は、Ｆｉｊの複数のセットのみが各アクセスポイントに格納されるため、データ量が節約されることであり、後者のケースの利点は、値のセットを、各アクセスポイントに対して、より適切に調整できることである。初期バッファ蓄積量（Ｆ）の代わりに、ビデオシーケンスが提示されるまでの遅延（Ｄ）が使用される時には、ＦｉｊをＤｉｊに置き換えることで、本発明を実現できる。この場合、Ｄｉｊは、遅延の値を表す。その結果、バッファＢｉ及びレートＲｉが変化しないと仮定する時、（Ｂｉ，Ｒｉ，Ｄｉｌ）がヘッダに格納され、Ｄｉｊが各アクセスポイントｊに格納される。バッファＢｉ及びレートＲｉが各アクセスポイントｊにおいて変化すると仮定する時には、値（Ｂｉｊ，Ｒｉｊ，Ｄｉｊ）の複数のセットをアクセスポイントに格納してよい。
【００３９】
各アクセスポイントに対するＲ，Ｂ，Ｆ値のセットは、任意の適切な位置に配置してよく、例えば、ビデオシーケンスの開始位置でビデオストリーム全体に対する（Ｒ，Ｂ，Ｆ）値のセットと共に、若しくはインデックスの必要性を回避するよう各アクセスポイントの前に配置してよく、或いは、ビデオストリーム自体の外部となるように格納してもよく、これはサーバ／クライアント環境において特に適している。
【００４０】
この手法は、次のモデルによって特徴付けてよい。
（Ｒ１，Ｂ１，Ｆ１，Ｍ１，ｆｌ１，ｔｌ１，．．．，ｆＭ１１，ｔＭ１１）．．．，（ＲＮ，ＢＮ，ＦＮ，ＭＮ，ｆｌＮ，ｔｌＮ，．．．，ｆＭＮＮ，ｔＭＮＮ）
ここで、ｆｋｊは、アクセスポイントｔｋｊ（タイムスタンプ）におけるレートＲｊでの初期バッファ蓄積量の値を意味する。Ｍｊの値は、入力パラメータとして提供してよく、或いは、自動的に選択してもよい。例えば、Ｍｊは、次のオプションを含んでよい。
（ａ）Ｍｊは、アクセスポイントの数と等しく設定してよい。これにより、ｆｋｊの値は、各レートＲｊで各アクセスポイントに対して格納し得る（ビデオストリームの開始位置でも、ビデオストリーム内でも、ビデオストリーム全体に分配としても、或いは他の任意の位置としてもよい）。
（ｂ）Ｍｊは、シーク可能性のサポートを望まない場合、ゼロに等しく設定してよい。
（ｃ）各レートＲｊに対するＭｊ値は、自動的に選択してよい（下で説明する）。
【００４１】
ユーザがアクセスポイントｔｋｊをシークする場合、システムは、所定のＲｊに対して、ｆｊｋに等しい初期バッファ蓄積量を使用してよい。これが起こるのは、ユーザがアクセスポイントでの開始を選択した時であり、その他の場合、システムは、ユーザの選択をアクセスポイントの一つに合わせて調整する。
【００４２】
（ビットストリーム内で）可変ビットレートが使用される場合、初期バッファ蓄積量の値（又は遅延）は、同じになり得るとしても、好ましくは、バッファサイズ（又はバッファサイズによって計算された遅延）とは異なることに留意されたい。ＭＰＥＧ−２での可変ビットレートの場合、ＶＢＶバッファでは、満杯になるまで、即ち、Ｆ＝Ｂとなるまで、蓄積が行われる（Ｂの値は、ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅによって表現される）。
【００４３】
本発明において、初期バッファ蓄積量の値は、任意のバッファアンダフロー及びオーバフローを回避するために、各ランダムアクセスポイントにおいて適切に選択できる。バッファ蓄積量の代わりに、ビデオシーケンスが提示されるまでの遅延が使用される場合、遅延の値は、任意のバッファアンダフロー及びオーバフローを回避するために、各ランダムアクセスポイントにおいて適切に選択できる。一般に、これは、ＶＢＶバッファが満杯になるまで蓄積を行うのに比べて、各ランダムアクセスポイントにおいて低い遅延が達成されることを意味する。したがって、本発明によって、バッファサイズ（又はバッファサイズによって計算された遅延）より小さなバッファ蓄積量の値（又は遅延）を決定することは、従来技術に比べ、デコードを開始する前にバッファする必要のあるデータが少ないことから、低遅延の利点を有する。
【００４４】
ユーザがアクセスポイントの形でビデオの任意のフレームにジャンプするのをシステムが認める場合、デコードするデータセットは、フレーム毎に提供される必要がある。許容されるものの、結果として生じるデータセットは、過度に大きくなり、データのために利用可能なビットレートを大量に消費することがある。より妥当なアプローチは、一秒毎、十秒毎、一分毎等のように、ユーザをビデオストリーム内の特定のアクセスポイントに制限することである。改善はされるものの、結果として生じるデータセットは、依然として幾分大きく、移動通信デバイスのように帯域幅を制限されたデバイスにとって過度なデータが生じる。
【００４５】
関連するデータセットを備えたアクセスポイントの一つではない位置をユーザが選択した場合、初期バッファ蓄積量は、特にアクセスポイントが適切に選択された場合は、ｔｋｊとｔ（ｋ＋１）ｊとの間の時間でのｍａｘ（ｆｋｊ，ｆ（ｋ＋１）ｊ）と等しくなり得る。これにより、システムでは、アンダフロー状態の発生のない値のセットを有する状態が保証され、或いは、そうでない場合でも、下で説明するように、アンダフロー状態の確率が低減される。
【００４６】
上記の選択基準を使用した時に、アンダフロー状態が存在しない（又は低減される）ことを確実にする値のセットを選択するために、図７を参照する。図７は、ビデオセグメントに対する初期バッファ蓄積量（単位はビット）を例示しており、ここでは先見的な初期バッファ蓄積量が十秒の増分で計算される。その後、システムは、好ましくは、ビデオシーケンスの開始位置にあるアクセスポイントと、ビデオセグメントの終了位置にあるアクセスポイントとを選択する。ビデオセグメントの開始と終了との間において、システムは、アクセスポイントとして含まれる極大値を選択する。更に、システムは、アクセスポイントとして含まれる極小値を選択してもよい。好ましくは、アクセスポイントの限定されたセットが望ましい場合、システムは、最初に極大値を選択し、その後、極小値を選択して、アンダフローのない状態の確保に役立てる。その後、システムは、更に、必要に応じて、中間点を選択してもよい。
【００４７】
前記選択基準に基づいて、図８に示したように、図７の十個の点を選択できる。図９を参照すると、十個の選択点は、破線の曲線で図示されている。全てのアクセスポイントで結果的に生じた初期バッファ蓄積量の値は、実線の曲線で図示されている。実線の曲線は、デコーダバッファがアンダフローしないような、ビデオ内の全ての点に対する「安全な」一組の値を例示している。鋭いスパイク等、処理において検出されなかった実際のビットストリームのビットレートでの極端な変動が生じた場合、アンダフローが生じ得るが、通常、可能性は低い。全てのアクセスポイントでの最適な初期バッファ蓄積量の値は、一点鎖線の曲線で図示している。図１０に例示したように、アクセスポイントにアクセスする時にバッファを満杯にする必要がある場合とは対照的に、バッファ時間遅延の大幅な低減が達成される。
【００４８】
加えて、異なるアクセスポイントを選択する際にビットレート及びバッファサイズが同じ状態を維持する場合には、単に、修正したバッファ蓄積量Ｆを提供するか、或いはその他の形でＦを決定する必要がある。
【００４９】
本明細書で引用した全ての参考資料は、出典を明示することにより本願明細書の一部とする。
【００５０】
上の明細書において利用した用語及び表現は、限定ではなく説明のための用語として使用されており、こうした用語及び表現の使用においては、図示及び説明した特徴の均等物又はその一部を除外するものではなく、本発明の範囲は、添付した特許請求の範囲によってのみ画定及び限定されることは理解されよう。
【図１】
0005444047.tif 000002
【図２】
0005444047.tif 000003
【図３Ａ】
0005444047.tif 000004
【図３Ｂ】
0005444047.tif 000005
【図４】
0005444047.tif 000006
【図５】
0005444047.tif 000007
【図６】
0005444047.tif 000008
【図７】
0005444047.tif 000009
【図８】
0005444047.tif 000010
【図９】
0005444047.tif 000011
【図１０】
0005444047.tif 000012