JP2011050117A - トリックモードおよび速度移行 - Google Patents

Abstract

【課題】 本明細書で開示する実施形態は、データストリームを通信するための方法を目的とするものである。
【解決手段】 本発明の進歩的な方法は、第１のデータストリームの第１のタイムスロットを決定する工程と、第２のデータストリームの第２のタイムスロットを決定する工程とを含むものである。前記第２のデータストリームが前記第２のタイムスロットより大きい場合、前記第２のデータストリームの一部が前記第１のタイムスロットに移動される。さらに、前記方法は、前記移動部分の関数としてデータストレージ量を制御する工程を含む。また、前記方法は、前記第２のデータストリームのサイズおよび前記第２のタイムスロットのサイズを監視する。
【選択図】 図５

Description

本発明の開示はビデオデータを伝送するための方法に関する。

ビデオフレームは、早送り、巻き戻し、一時停止、停止、および再生が可能なデータを表すのに使用される場合がある。そのようなビデオフレームに関連付けられたデータの任意の時間またはタイムスロットに伝送または受信されるデータ量を使い、利用可能な帯域幅を決定することができる。ビデオフレームの１つのタイプは、「トリックモード（ｔｒｉｃｋｍｏｄｅ）」フレームと呼ばれるものであり、数多くの異なるビデオ伝送方法に使用されている。

ビデオ伝送におけるビデオフレームの伝送の管理は、望ましい質のビデオ制作を達成するための一つの考慮点である。トリックモードフレームの場合、任意のフレームに関連付けられたデータ量が予測不可能で、かつ変動する場合があり、これが管理上の問題点となることがある。例えば、利用可能なタイムスロット内にトリックモードフレームが確実に収まるようにするためにタイムスロット法が使用されることがあるが、このタイムスロット法では各スロットは最大のトリックモードフレームを伝送するのに十分な帯域幅の固定量を有する。しかし、その他のより短いトリックモードフレームで、タイムスロットが必要以上に大きい場合、帯域幅が未使用となる場合がある。その結果、未使用の帯域幅の量が増える。

また、多くの場合、トリックモードフレームの伝送前にトリックモードをバッファするために必要なメモリ量を予測することが難しい。その結果、時として、バッファを必要とするデータ量が、利用可能なメモリを超え、「バッファオーバーフロー」を引き起こす場合がある。このバッファオーバーフローの結果、ジャンプやジッタのような望ましくない様々な視覚的状況が発生する場合がある。

本発明はビデオデータを伝送するための方法を提供する。

図１は、ビデオ・バッファ・レベルの一例である。 図２は、対象画像群（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の長さを増す方法の一例である。 図３は、ビデオフレームのシーケンスがバッファレベルに与える影響を図示するものである。 図４は、ビデオストリームの分布曲線である。 図５は、トリックモードパケット調整を図示するものである。 図６は、トリックモードパケットの変化がバッファレベルに与える影響を示す図である。 図７は、トリックモードストリームを作成するためにバッファの最適化が使用される方法を図示するものである。 図８は、トリックモード・ビデオ・ストリームの出力を提供するものである。 図９は、スプライシング法を図示するものである。 図１０は、データストリームを通信するためのシステムである。 図１１は、データストリームを通信するための方法のフロー図である。 図１２は、データ・ストレージ・レベルの制御方法のフロー図である。

本発明の実施形態は、トリックモード・ビデオ・ストリームのようなビデオデータ通信において帯域幅を効率的に使用すると同時に、望ましいビデオ再生条件を提供するバッファレベルを維持する方法を提供する。Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ：エムペグ）のコンテクストで実施形態について説明するが、上述の方法をその他のタイプのデータ圧縮／解凍方法に用いることも可能であると理解されるべきである。

一部のビデオ圧縮／解凍方法では、ビデオはフレームに分割される場合がある。例えば、ＭＰＥＧは、Ｉフレーム、Ｐフレーム、Ｂフレームという少なくとも３つの異なるタイプのビデオフレームを使用する。Ｉフレームすなわち「ｉｎｔｒａ ｃｏｄｅｄ ｆｒａｍｅｓ」は、シーケンスに他の前フレームまたは将来フレームがなくてもＩフレームのデコードを可能にするイントラフレームマクロブロックを含む。ＭＰＥＧビデオのランダム再生では、デコーダはＩフレームからデコードを開始することができる。１２〜１５フレームごとにＩフレームを挿入可能であり、Ｉフレームを用いてシーケンスを開始することができるので、ランダムな位置からビデオを再生すること、および例えば早送りや巻き戻しなどトリックモード機能でビデオを再生することが可能である。

Ｐフレームは前フレームとの差分としてコード化される。新しいＰフレームは、前フレームおよび現在フレームの新しいピクセルの予測値を取り入れて予測することができる。Ｐフレームは、存在する動作量に応じてより高い圧縮比を提供する。

Ｂフレームすなわち「双方向フレーム」は、前Ｂフレームまたは後続Ｂフレームとの差分としてコード化されるものであり、前フレームおよび後続フレームを使って正確にデコードすることができる。このため、読み込まれるフレームの順序は、必ずしも表示順序と同じでない場合がある。すなわち、後続フレームが現在Ｂフレームの前に伝送およびデコードされても、現在フレームの後に表示される場合があることを意味する。例えば、Ｉ_１ Ｂ_２ Ｂ_３ Ｐ_４ Ｂ_５ Ｂ_６ Ｐ_７という表示シーケンスのフレームは、Ｉ_１ Ｐ_４ Ｂ_２ Ｂ_３ Ｐ_７ Ｂ_５ Ｂ_６と順序換えされて伝送される可能性もある。

ＭＰＥＧビデオのシーケンスは画像群（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ：ＧＯＰ）を含む。各ＧＯＰはビデオフレームを含む。ＧＯＰ構造には、ＧＯＰ構造が含むフレーム数（Ｎ）および２つの参照フレーム間の距離（Ｍ）が関連付けられている。例えば、典型的なＧＯＰ構造はＩＢＢＰＢＢＰＢＢＰＢＢＰＢＢＰ（この構造においてＮ＝１５、Ｍ＝３）、および／またはＩＢＢＰＢＢＰＢＢＰＢＢ（この構造においてＮ＝１２、Ｍ＝３）などである。当然、これら構造は変化するものであり、例えばＰＰＰＰＰＰＰＰなどＰフレームだけのストリームを含むこともある。

トリックモードＧＯＰは、Ｉフレームと、可変数のダミーＢフレームおよびＰフレームとを含むビデオシーケンスである。トリックモードＧＯＰのサイズには、トリックモードＧＯＰに含まれるフレーム数が関連付けられている場合がある。例えば、ＩＢＢＰＰＰというＧＯＰ構造のＧＯＰサイズは６である。ＧＯＰまたはトリックモードパケットのタイムスロットは、ＩフレームＤＴＳ（デコード・タイム・スタンプ）から次のＩフレームＤＴＳまでの期間が可能である。

トリックモードパケットはトリックモードＧＯＰと関連付けられており、有効なトランスポートストリームを調整するためのデータを含む。前記トリックモードパケットは、プログラム割り当てテーブル（Ｐｒｏｇｒａｍ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ：ＰＡＴ）と、プログラム・マップ・テーブル（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ：ＰＭＴ）と、「同期」パケットとして参照される同期のためのみの（例：データなし）プログラム・クロック・レファレンス（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ：ＰＣＲ）を有するトランスポート・ストリーム・パケットと、トリックモードＧＯＰと、様々なサイズのフィラー・ヌル・パケット（ｆｉｌｌｅｒ ｎｕｌｌ ｐａｃｋｅｔｓ）とを含む。

トリックモードパケットのサイズは、トリックモードパケット自体に基づくサイズである可能性がある。前記トリックモードパケットのサイズは、ストレージオーバーヘッド、ネットワークオーバーヘッド、およびビットレートコントロールに対応することもできる。例えば、Ｉフレームを含むファイルセグメントは、トランスポート・ストリーム・レベルで多重化されたその他のパケット識別子または「ＰＩＤ」（例：ＰＡＴ、ＰＭＴ、オーディオ）を含むこともできる。ブロックをメモリに読み込み、非ビデオパケットをヌル（例：「ミューティング」）に替えることも可能である。

トリックモードパケットは１３１６バイト（例：ユーザ・データグラム・プロトコル（ＵＤＰ）を介したＭＰＥＧ２トランスポートストリーム）も可能である。

図１は、固定タイムスロット割り当てを使ったＩフレームベースのトリックモードのビデオ・バッファ・レベルの一例である。図１が示すように、各ＧＯＰは７つのフレームを含む。その他のサイズのＧＯＰを使用することも可能である。図１で図示する横軸目盛（ｔ）は、フレーム期間（例：１／３０秒）を表す。例えば、当該「トリックモードＧＯＰ」構造はＩＢＢＰＰＰＰであってもよいし、または２つのダミーＢフレームおよび４つのＰフレームが後続するＩフレームであってもよい。この構造では３０秒毎に７つのＩフレーム（すなわち４．２８秒毎に１つのＩフレーム）が作成される。図１の縦線が示すように、第１のＧＯＰはｔ＝２で受信される。前記ＧＯＰ構造は７つのフレームで設定されているため、ｔ＝７まではデコードおよび提示されない。第２のＧＯＰ構造はｔ＝１３で受信される。この例では、前記第２のＧＯＰが伝送およびバッファされる間、デコーダはｔ＝７からｔ＝１３まで第１のＧＯＰを提示する。ｔ＝１４で、前記第２のＧＯＰはすでにバッファされており、デコードできる状態にある。

ＧＯＰのデコードおよび提示ができる状態にあるインターバルの前にＧＯＰを受信した場合、前記デコーディングプロセスに中断が起こらない。しかしながら、ＧＯＰのデコードおよび提示準備が整う前記インターバルの前にＧＯＰを受信可能であるため、未使用の帯域幅が存在する可能性がある。図１において、この未使用の帯域幅は長方形部分として描かれている。

無駄な帯域幅の問題を解決するための１つの試みは、例えばそのタイムスロットおよび／またはＧＯＰサイズを減らすことによって、毎秒送信されるＩフレーム数を増やすことである。例えば、図１を参照し、ＧＯＰを６フレームに減らすことによって、前記第１のＧＯＰによる未使用の帯域幅の量は１フレーム少なくなる。しかし、前記第２のＧＯＰは、そのデコードおよび提示後のｔ＝１３．５まで伝送状態ではない。前記第２のＧＯＰが伝送されるには約６．５フレーム（すなわち１３．５−７）のインターバルが必要なため、ｔ＝１２で前記第１のＧＯＰによって不完全な第２のＧＯＰがデコーダに提示されることになる。不完全な第２のＧＯＰをデコーダに提示すると、「バッファアンダーフロー（ｂｕｆｆｅｒ ｕｎｄｅｒｆｌｏｗ）」が生じる可能性がある。１実施形態において、ＧＯＰの長さおよびタイムスロットを、その後続ＧＯＰのサイズの関数とすることができる。例えば、図１のサンプル分布が示すように、一部のＩフレームは２フレームという短いタイムスロットのみを必要とし、他のＩフレームは６フレームという長さである場合もある。

図２は、対象ＧＯＰに後続するＧＯＰに基づき前記対象ＧＯＰの長さを増す方法の一例である。図２が示すように、同一のＧＯＰシーケンスを用い、各ＧＯＰについて合計インターバルをランダムにすることによって、未使用の帯域幅の量（長方形部分によって示される）をわずか１インターバル長に減少することができる。具体的には、前記第１のＧＯＰは４フレームのインターバルを有し、前記第２のＧＯＰは５インターバルを有する。それにより生成されるトリックモードシーケンスは、ランダムなインターバルで提示される新しいＩフレームを導入することができる。

図１および図２が示す方法は、すべてのＧＯＰがデコードされた後、バッファは残りのダミーＰフレームとＢフレームを含み、これらはごく小さいサイズであるため、ビデオバッファが空となるという前提に基づいて行われている。

データの取り込みプロセスは、受信される「Ｎ」個めのフレームごとに１フレームをデコードし、「Ｎ速度」のトリックモードストリームを生成するする。例えば、８ｘのストリームを生成するために、前記取り込みプロセスはフレーム１，９，１７，２５．．．（８ｎ＋ｌ）をデコードすることができる。次に、これらのフレームを使って、結果的に得られるストリームが例えば毎秒３０の一意のフレームを含むように、ＭＰＥＧ２トランスポートストリームを生成することができる。次に、フレームのシーケンスを、元のトランスポートストリームの一部の特性（フレームレート、ビットレート、ＰＩＤ割り当て、ビデオフォーマット、ビデオバッファ特性（例えば滑らかな速度移行のためのバッファサイズおよびバッファレベル）など）を維持する新しいＭＰＥＧ２トランスポートストリームにエンコードすることができる。この方法によって、より優れたトリックモードの品質を提供することが可能である。また、この方法は、より高いプロセッサ能力と追加的なストレージオーバーヘッド（例えば通常３０％）を使用する。

一部の実施形態では、ＩフレームベースのトリックモードはダミーＢフレームおよびＰフレームを挿入することもできる。また、前記実施形態の一部では、フレームジッタになる可能性のあるＰフレームおよびＢフレームを、フレーム予測を用いてエンコードすることができる。例えば、放送テレビジョン（すなわち全国テレビジョン方式委員会（Ｎａｔｉｏｎａｌ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅｅ：ＮＴＳＣ））を用いる実施形態では、各フレームは２つのインターレースフィールドから構成されており、合計毎秒６０フィールドとなる。２４ｆｐｓという映画のフレームレートと３０ｆｐｓというテレビのフレームレートの差分の結果、映画をテレビ用コンテンツに変換するために「３：２引き下げ」方法を採用することがある。

前記「３：２引き下げ」方法は、フレームを３フィールドと２フィールドに交互に変換することができる。例えば、２４ｆｐｓで４フレーム（すなわち６秒毎に１フレーム）では、３０ｆｐｓで１０フィールドまたは完全な５フレームが作成される。（プログレッシブモードではなく）インターレースモードを使ったエンコードでは、１フレームは２フィールド（上のＡと下のＢ）を含む。ダミーＢフレームとＰフレームを生成するためにフレーム予測を用いると、デコーダはその参照画像またはＩフレームから両方のフィールドをコピーすることができる。よって、例えば、構造ＩＢＢＰＰを持つトリックモードＧＯＰでは、前記デコーダはＡＢＡＢＡＢＡＢＡＢという構造を有する５フィールドのシーケンス（各フレームに２つのＡＢ）が作成される。

Ｉフレームは２つの異なる画像から生成されたフィールドを含む場合があり、ＡＢＡＢＡＢＡＢＡＢというフィールドのシーケンスは「ジッタ」の印象を与えることがある。

一部の実施形態では、トリックモード機能を開始する際、ＢフレームおよびＰフレームによって使用される参照フレームは、これらのフレームを出力ストリームにコピーするときに破壊される可能性がある。この原因の一部は、Ｎフレームから１フレームを選択することによってトリックモードファイルが生成されることにある。結果的に、前記ＢおよびＰフレームは前記出力ストリームにもはや存在しない可能性があるため、これらのフレームを欠落している参照フレームと伴に完全にデコードし、次に、異なる参照フレームを用いて前記トリックモードストリームのコンテクストで再エンコードする必要がある。

例えば、ＩＢＢＰＢＢＰＢＢＰＢＢＰＢＢＩＢＢＰＢＢＰＢＢＰＢＢＰＢＢＩＢＢＰというビデオ・フレーム・シーケンスは、前記トリックモードシーケンスに対しＩＢＢＰＢＢＰによって表すことができる。元のビデオ・フレーム・シーケンスのＢフレームは、前記トリックモード・シーケンス・ファイルの一部ではない前および後続のＩおよびＰフレームに依存する場合がある。また、前記トリックモードファイルでは、シーケンスへの挿入場所により、一部のフレームは異なる方法でエンコードされる。例えば、前記元のシーケンスのＩフレームを、前記トリックモードファイルでＰフレームとしてエンコードし、ＢフレームをＰフレームにすることも、全く異なる参照フレームを持つ別のＢフレームにすることも可能である。

ケーブル業界で使われる典型的な帯域速度は、ＣａｂｌｅＬａｂｓ（商標）コンテンツ仕様１．０［４］の説明によれば、３．７５メガビット／秒であり、毎秒３０フレームのストリームが３．７５メガビット／秒で取り込まれる。４つのトリックモードファイルを必要とするビデオ・オン・デマンド（ＶＯＤ）サーバの場合（例えば１５ｘ，−１５ｘ，６０ｘおよび−６０ｘの速度）、４つのエンコーダを平行して使用して元のビデオストリームから抽出およびデコードされたフレームを処理することによって、最高４つの異なるトリックモードファイルを生成することができる。

各トリックモードエンコーダは、毎秒２フレーム（２ｆｐｓ）（３０／１５）、２ｆｐｓ（３０／１５）、０．５ｆｐｓ（３０／６０）、および０．５ｆｐｓ（３０／６０）で受信することができ、４つのすべてのエンコーダで毎秒合計５フレームとなる。通常、例えば２．４ＧＨｚのＰｅｎｔｉｕｍ（登録商標）４プロセッサから得られる処理能力のすべてを実質的に使用することにより、約４５メガビット／秒の取り込み帯域幅で１２ストリームをエンコードすることが可能である。その結果得られるトリックモードファイルは、それぞれ前記元のファイルサイズの６．７％、６．７％、２．２％、および２．２％であり、合計約１６．６％のストレージとなる。よって、一部の実施形態では、標準トリックモードファイルを生成するために、かなり高度なコンピュータ処理能力およびコンピュータ論理が必要とされる場合がある。さらに、前記プロセスは一部のフレームを完全にデコードし、Ｂフレームのようなその他のフレームをデコードしない場合がある。

Ｉフレームの表示は前フレームまたは後続フレームに依存しないので、Ｉフレームをランダムアクセス機構に用いることが可能である。よって、一部の実施形態では、新しく作成されたストリームにＩフレームをマージし、ビットレートを制御するためにヌルパケットを挿入することによってトリックモードを使うことができる。

Ｉフレームの通信所要時間はフレーム間隔より長い場合がある。例えば、平均Ｉフレームサイズ４０ｋｂでは、３０ｆｐｓのＩフレーム専用トリックモードストリームは最低限９．８メガビット／秒（４０ｋｂ ｘ ８ ｘ ３０）すなわちケーブル産業で一般に使用される３．７５メガビット／秒という速度の約２．６倍の速度を必要とする。

一部の実施形態では、３０ｆｐｓのようにより高いフレームレートを維持するために、前記Ｉフレームレートを毎秒約１０Ｉフレームに減少させる場合がある。例えば、残りのＩフレームの代わりに他のフレームを挿入することによって速度を維持することができる。例えば、２若しくはそれ以上のフレーム期間またはフレーム間隔に１つのＩフレームを表示し、後続のＩフレームを伝送およびバッファすることができる。最後に表示されたフレームのコピーである「ダミー」ＢフレームまたはＰフレームをビデオストリームに挿入することができる。１実施形態において、「ダミー」または複製フレームは、平均Ｉフレームサイズよりも小さいサイズの「静止」フレームである場合がある。ダミーフレームは実質的に同時にエンコードできるので、プロセッサの効率を高めることができ、ＧＯＰのサイズを拡張するために出力ストリームに挿入可能である。

毎秒１０のＩフレームという速度のトリックモードは、「トリックモードＧＯＰ」すなわちビデオフレームのトリックモード・シーケンスを作成することによって達成できる。例えば、「トリックモードＧＯＰ」のシーケンスを、後続する２つのダミーＢフレームを持つ１つのＩフレームで作成することによって、例えばＩＢＢＩＢＢＩＢＢＩＢＢＩＢＢのようなシーケンスを作成することができる。前記ダミーＢフレームのサイズが例えば約１．２ｋｂであれば、その出力ストリームの平均ビットレートは３．５メガビット／秒（（４０ｋｂ＊８＊１０ Ｉ−フレーム／秒）＋（１．２ｋｂ＊８＊２０ Ｂ−フレーム／秒））となり、最大帯域速度３．７５メガビット／秒以内となる。

一部の実施形態では、タイムスロット割り当ておよびトリックモードＧＯＰサイズをＩフレームベースのトリックモードストリームで動的に調整し、帯域幅の使用を効率化する。これらの方法は、さらに、バッファオーバーフローを検出および予防することによってビデオバッファ稼働率を監視する。１態様においては、「ダミー」Ｐフレームを挿入する場合がある。

また、これらの方法を用いて帯域幅利用率を最大限にすると同時にバッファレベルを最少レベルに維持し、処理速度の変化につれてシステムの応答性を増すことができる。例えば、８ｘのストリームを生成するために、これらの方法は平均して毎秒約１０の一意のＩフレームを提供することができる。残りのフレーム（例えば毎秒３０フレームのストリームで毎秒２０フレーム）は、ダミーまたは静止ＢフレームおよびＰフレームが可能である。

１実施形態では、これらの方法をビデオ・ストリーム・ソフトウェア製品に組み入れる。また、この方法を、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを用いて達成することも可能である。

データ構造を用いてビデオの取り込みストリームを解析することができる。例えば、「ヒンター（Ｈｉｎｔｅｒ）」構造およびその解析データ（すなわちＩフレームおよびストリーム情報）を「ヒント（ＨＩＮＴ）」ファイルというファイルに保管することができる。ビデオの取り込み、例えば、通常のＰｅｎｔｉｕｍ（登録商標） ４２．４ＧＨｚプロセッサで約３００メガビット／秒の取り込みが可能であると理解される。前記ヒントファイルは、例えば約６４ｋのヘッダを含むことができる。また、前記ヒントファイルは、１つのＩフレームにつき約１２８バイトのＩフレームテーブルを含むことができ、関連付けられたＩフレームの位置を示すポインタを有することができる。３．７５メガビット／秒で毎秒２０のＩフレームを有する２時間の映画（すなわち合計１４４００のＩフレーム）では、元のファイルサイズの約０．０６％未満である約１．９メガバイトのサイズのヒントファイルが作成される。しかし、取り込み時に前記のトリックモードが生成されない場合があるので、例えばソフトウェアおよび／またはハードウェアのストリーミングに使われる場合、これらの方法は動的にトリックモードストリームを生成する場合がある。

図３は、Ｉフレームのシーケンスがバッファレベルに与える影響を図示する。縦軸はＩフレームのデコード時間を表す。図３が示すように、トリックモードパケットはバッファリングを利用することによって「パック」される。Ｉフレームの大型シーケンスによって、フレームレートにほとんど若しくは全く影響を与えずに、バッファレベルが短期間上がる場合がある。ダミーＰおよびＢフレームも伝送およびデコードされるが、それらはＩフレームの約３０倍小さく、それぞれ約１．３ｋである。

一部の実施形態では、バッファレベルの調整に用いられるこれらの方法は固定タイムスロットのトリックモードシーケンスから導き出されている場合がある。そのようなシーケンスは図１を参照して説明したシーケンスと類似している場合がある。また、比較的優れた表示品質を達成するために、これらの方法によって、実質的に一定の速度のＩフレームを生成する試みが行われる。前記のビデオストリームは任意の分布を有するＩフレームを含むことができるが、本発明の理解および明確化のために、以下の説明では、図４が示すように、入力ビデオストリームが一定のサイズの分布曲線を含むものと仮定する。

上記の方法は、与えられたサイズを満たさないＩフレームを含むタイムスロットの未使用の帯域幅を再分配し、超過サイズのＩフレームを取り入れることができる。これは、例えば、（ＧＯＰサイズに基づき）十分なトリックモードのタイムスロットサイズを選択し、バッファオーバーフローを発生せずに一式のトリックモードパケットが確実に調整または再配列されるよう十分に大きいタイムスロット調整または枠を選択することによって達成できる。

伝送前にトリックモードパケットのシーケンスを再配列することにより、帯域幅利用率を改善することができる。また、本発明の方法は、統計平均を採用し、任意のシーケンスのトリックモードパケットのＧＯＰサイズを取り入れることができる。１実施形態では、前記ＧＯＰサイズを確実にそのパケット調整のサイズ未満若しくは最低限そのサイズと同等にすることによって平均化が達成される。

実質的に固定されたＩフレームのタイムスロットからのＩフレームをこのように再分配および再配列する結果、前記の方法はデコードおよびそれに伴うバッファリングを含む場合がある。さらに、バッファされたデータの量を管理することにより、バッファオーバーフローまたはアンダーフローという状況を予防することができる。

図５は、トリックモードパケット調整を図示する。図５が示すように、上の枠５０１は、一部の超過サイズのトリックモードパケットがその固定タイムスロットおよび利用可能なタイムスロットに適合しない場合があることを図示している。例えば、トリックモードパケット５０６は図のタイムスロット５０３内に適合しているが、トリックモードパケット５０４は前記５０３の後続タイムスロット５０５内に適合していない。結果として、トリックモードパケット５０４の一部はタイムスロット５０７に入り込んでいる。

下の枠５０２は、前記タイムスロットを再配列または順序替えする方法を示している。そのような再配列によって、前または後続のトリックモードパケットからの利用可能な帯域幅または「ヌル」を、より大きいトリックモードパケットに使用することが可能になる。

以下の説明において、上述の概念を数学的に定量化する。しかし、本発明の開示がこれらの等式の計算または使用に限定されるものではないことが理解されるものである。むしろ、以下の説明は、この新規概念の理解を深めることを目的として提供されるものであり、例として与えられる等式は本発明の実施形態で考慮される可能な１つのアプローチに過ぎない。

ビットレートｂ_ｒ、フレームレートｆ_ｒ、およびｑフレームのＧＯＰサイズを有するデータストリームでは、与えられたタイムスロットにおいて伝送可能なデータ量Ｑは次のように表される。

そのＩフレームレートは次のように計算することができる。

場合によっては、よりよい表示品質を得るために、１ＧＯＰ当たりのフレームを定数にすることによりｑを整数として維持することが好ましい。あるいは、ＧＯＰごとにｑを変動させる（すなわちＧＯＰサイズを変動する）こともできる。その他の可能な実施形態は、ｑの平均値を用いる場合がある。例えば、２．４フレームのｑの値を、２，３，２，２，３というサイズを有し毎秒１２．５のＩフレームを提供するＧＯＰのシーケンスに対して設定することができる。

上記の等式をｂ_ｒ＝３．７５メガビット／秒、ｆ_ｒ＝３０ｆｐｓ、およびｑ＝３であるビデオストリームに適用することにより、ｒ＝毎秒１０のＩフレームであるＩフレームレートで、各タイムスロットにて４６，８７５バイトを伝送することができる。

ｎトリックモードパケットのある調整枠に必要な帯域幅を予測するために、多くの観点の予測を考慮する必要がある場合がある。例えば、Ｉフレームのサイズ、ダミーＢフレームとＰフレームの数およびそれらのサイズ、ＰＡＴ、ＰＭＴ、ＰＣＲパケットのようなオーバーヘッド・データのサイズ、およびディスクとネットワークのオーバーヘッドなどを考慮しなくてはならない場合がある。これらの値を予測することができる。例えば、元のストリームでのＩフレームのサイズが、特定の分布曲線に必ずしも従わない一定のサイズの分布（Ｉ，σ_１）を有することができると予測することができる。ディスクまたはストレージのオーバーヘッドは、トリックモードパケットのサイズを決定することによって予測することができる。

上記の予測は、ビデオ・バッファ・レベルを約１０％高く予測する場合がある。結果として、一部の実施形態では、ストレージから直接入手される４０ＫＢブロックにおいて、ビデオバッファに保管されることになる実際のビデオデータ３６ｋＢ以下を伝送しなくてはならない場合がある。残りの４ｋＢは、前記ブロックに埋め込まれていて「ヌル化」または「ミュート化」されたその他のＰＩＤ（例えばオーディオ、ＰＭＴ、ＰＡＴ）を含むことができる。あるいは、前記ビデオデータを再配列し、約３６ｋＢのビデオデータを送信することができる。

バッファオーバーフローを確実に避けるために、本発明の方法はバッファ能力の９０％という制限を設定することができる。この９０％制限は、上述の方法におけるエラーの増大を予防することもできる。前記バッファレベルはそのトリックモードシーケンスにおいて超過サイズのＩフレームの比較的大きいシーケンスを必要とするため、前記バッファレベルがその制限の９０％に到達する確率は比較的低い。さらに、前記バッファレベルを高めに予測することにより、前記トリックモードの性能をあまり劣化させずにバッファオーバーフローを検出する確率が高まる。

ｎ個のランダムなＩフレームのシーケンスにおける各Ｉフレームのサイズを決定する場合、合計サイズ

は

という分布を持つランダムな変数となる。ｎの値が大きいほど、前記ランダムな分布（Ｓ_ｎ）は正規分布に近づく。この予測の結果生じるすべてのエラーをＰフレーム挿入によって修正することができる。

さらに、前記のダミーＰフレームおよびＢフレーム（Ｐ）およびオーバーヘッドデータ（ＯＨ）のサイズを予測することによって、ｎタイムスロットを持つ調整枠に含まれるストリーミングデータ（Ｔ_ｎ）の合計量を以下の等式によって表すことができる。

前記調整枠にて利用可能な帯域幅を以下の等式によって表すことができる。

トリックモードパケットのシーケンスが指定調整枠に適合する確率を最大限にするために、本発明の方法は、一部の実施形態で、修正εを実行する必要が生じる確率を低く維持しようと試みることができ、ここで、１０^−３の階数の値に対しε>Ｐ（Ｔ_ｎ>Ｑ_ｎ）である。

Ｓ_ｎが正規分布と考慮され得るほどｎが十分大きいと考えれば、ｎは以下の等式を満たすのに十分な大きさである場合がある。

前記等式に、Ｂ_ｒ＝３．７５メガバイト／秒、ｆ_ｒ＝２９．９７ｆｐｓ、ｑ＝３フレーム、Ｉ＝４０４９１バイト、σ_Ｔ＝１０８３５バイト、Ｐ＝１．０ｋｂ、ＯＨ＝２．０ｋｂという実数値を投入すると、次のようになる。

ε＝１０^−３であれば、その調整枠は次のようになる。

ここで、Ｉフレームの平均サイズは選択されたタイムスロットのサイズよりわずかに小さく、本発明の方法は毎秒約１０のＩフレームのトリックモードストリームを可能にする。また、この例において、その帯域幅利用率は約９７％である（すなわち４４５８７バイト割る４５９２２バイト）。百分率で表す実際の帯域幅利用率はバッファオーバーフローを修正する必要性（例えばＰフレームの挿入）によって低下する場合がある。

以下の例は、１つの調整枠サイズを選択し、最大トリックモード速度または最小ＧＯＰサイズ（ｑ）を決定することによって、異なるアプローチを採用する。

ここで、調整枠サイズ（Ｎ）を６４サンプルに設定し、εを１０^−３として、許容Ｉフレームレートを算出する。そのストリームから統計を収集し、最大トリックモード速度を算出することによって、これを達成することが可能である。そのＩフレーム統計は、すでに説明したように、前記ストリームに関連付けられた「ヒント」ファイルに保管することができる。ｑ＝３．１２７という結果は毎秒約９．６のＩフレームであり、例えば３，３，３，３，３，４，３，３といった不正規のＧＯＰサイズを許容するものである。別の実施形態では、この結果を次の整数ｑ＝４に切り上げ、毎秒７．５のＩフレームとする。

このバッファ調整方法は、各トリックモードパケットからのパラメータ一式の計算を必要とする場合がある。これらのパラメータに指令を与え、Ｉフレームの選択、Ｉフレームのデータ収集、および制御変数の初期化をすることができる。

Ｉフレームの選択に関し、一定の速度（例えば１５ｘ、３０ｘ、−１０ｘ．．．）でトリックモードストリームを生成するためにＩフレームのシーケンスを決定することができる。前記Ｉフレームのシーケンスを、（１若しくはそれ以上の）速度、選択されたＧＯＰサイズ（ｑ）、および元のストリームから抽出された情報（フレームレート（ｆ_ｒ）およびそのストリームの毎秒の平均Ｉフレーム数など）に基づいて決定することができる。ＭＰＥＧ２ファイルが最初にヒントファイルに取り込みおよび保管されるときに、ヒント過程の一部としてＩ_ｒを算出することができる。

さらに理解を深めるために、以下に例示的な実施形態を提供する。毎秒平均２つのＩフレームでありトリックモードストリームが毎秒１０のＩフレームで生成されると仮定し、すべてのＩフレームが選択される場合、前記トリックモードストリームは５ｘという速度で生成されることになる。あるいは、１つおきに（すなわち２のインクリメントで）Ｉフレームが選択される場合、１０ｘのトリックモードストリームの生成が可能である。最後のＩフレームから最初のＩフレームにかけて１つおきに（逆順に−２のインクリメントで）Ｉフレームを選択すると、−１０ｘのトリックモード速度が得られる。

トリックモード速度がありＩフレーム／秒（Ｉ_ｒ）の平均を有するビデオストリームの場合、ｉ＝ｓｑＩ_ｒ／ｆ_ｒ．としてその指数インクリメント（ｉ）を算出することができる。前記指数インクリメントを用いて、同じく変数であるＩフレーム指数（ｘ）のシーケンスを算出することができる。実際のＩフレームは、以下の例で提供される指数のシーケンスを切り捨てることによって得られる。

Ｉ_ｒ＝２のＩフレーム／秒、ｂ＝３または１０のＩフレーム／秒（ｆｐｓ）およびｆ_ｒ＝３０フレーム／秒（ｆｐｓ）。トリックモードをＩフレーム番号６００から（すなわち映画の開始後約５分後）−１６ｘ（すなわち高速巻き戻し）の速度で実行する場合、Ｉフレーム指数のシーケンスは６００でありＩ＝３．２＝−１６ｘ３ｘ２／３０となる。よって、作成される指数のシーケンスは６００．０，５９６．８，５９３．６，５９０．４，５８７．２，５８４．０等となる。また、このバッファ調整アルゴリズムのために選択されるＩフレームのシーケンスは６００，５９７，５９４，５９０，５８７，５８４等である。

トリックモード再生速度がより小さい場合、例えば４倍小さい場合は、結果的に得られる指数インクリメントが１．０未満となり、フレームの繰り返しが生じる場合がある。これらのケースでは、算出された指数インクリメントに基づくＩフレーム選択中にＧＯＰサイズ（ｑ）を修正することができる。例えば、前記数値を用い、ＧＯＰサイズ（ｑ）を３．７５に修正し、４．０に切り上げることができる。これにより、毎秒の平均Ｉフレーム数は、毎秒１０のＩフレームから毎秒７．５のＩフレームに減少する。これにより、その指数インクリメントは約ｉ＝１．０６７になる。

また、一部の実施形態で、ＧＯＰサイズ（ｑ）を変数または浮動小数点として扱うことができ、従ってその指数インクリメントは１．０に切り上げられ、ｑは例えば３．７５など非整数の値を採ることができるものと理解さる。これにより、４，４，４，３等といったサイズのＧＯＰのシーケンスが作成される。

Ｉフレームのデータ収集に関しては、Ｉフレームのシーケンスがいったん決定されると、Ｉフレームに関する情報の収集および一部のデータ構造の初期化（例えばトリックモードパケット毎に１若しくはそれ以上）が可能である。適切なＩフレームのエントリを指すだけで、そのヒントファイルから前記データを入手することができる。

以下の説明は、使用可能なデータ情報のタイプのいくつかの例を提供する。「開始」データを収集することができる。開始データは、Ｉフレームに関連付けられたＰＥＳヘッダを含むトランスポート・ストリーム・パケットのオフセットである。これは、Ｉフレームの開始点のオフセットである場合がある。「終了」データも収集することができる。終了データは、ファイル内のＩフレームの最後のオフセットである場合がある。これは、最後のＩフレームのビデオデータの通過地点でのオフセットである。前記開始オフセットと終了オフセットの間に、他の非ビデオのトランスポート・ストリーム・パケットがファイル内に存在可能であると理解される。これらのパケットをストリーミング前にヌルに変換することができる。

「サイズ」データも収集することができる。サイズデータは、（終了から開始を引いた）差分すなわち送信可能であるＩフレーム全体を含むデータ量として算出することができる。「タイムコード」データも収集することができる。タイムコードデータは、ストリーム中の現在のタイムコードを後にクエリすることになる他のコンポーネントとのインタフェースを提供することができる。前記タイムコードはＧＯＰヘッダの中にある場合があり、ヒント過程中に抽出することができる。

「ファイルＰＣＲ」データも収集することができる。ファイルＰＣＲデータを前記開始オフセットに関連付け、ストリーミングソフトウェアがＰＣＲ再スタンプを実行できるようにすることができる。「ファイルＤＴＳ」データを収集することができ、これを元アセットにあるＩフレームに関連付けることによりＤＴＳ再スタンプを実行し、通常再生からトリックモードへ移行して再び通常再生に戻る間の滑らかなバッファ移行を実行することができる。「ファイルＰＴＳ」データを収集することができ、これを元アセットにあるＩフレームに関連付けることによりプレゼンテーション・タイム・スタンプ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ：ＰＴＳ）を実行し、全移行のフレーム間隔を維持することができる。

「ＣＣ開始」および「ＣＣ終了」データを収集することができる。ＣＣ開始データは、その開始パケットのトランスポートストリーム継続カウンタである。ＣＣ終了は、その終了パケットの継続カウンタである。ＣＣ開始およびＣＣ終了データは、ＣＣ再スタンプを実行するために一部の実施形態で必要な場合がある。

「次フィールド」データを収集することができる。次のフィールドデータを用い、「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」フラグを使ってＩフレームをエンコードし、２つでなく３つのフィールドをＩフレームが含むようにすることができる。移行中にフィールドのシーケンスを維持するために、移行の後に第１のダミーＢフレームにフィールド調整機構を用いることができる。

制御変数の初期化に関しては、一部のストリーミング変数を追跡し続けることが好ましい場合がある。例えば、ストリームオフセット、ストリームＰＣＲ、ストリームＤＴＳ、およびストリームＰＴＳである。前記ストリームオフセットは、そのストリーミングソフトウェアが作成する合計データ量である場合があり、そのファイルオフセットとは異なるものである。前記ストリームＰＣＲは、ＰＣＲ再スタンプ機構の後に出力ストリームで観察される実際のＰＣＲである場合がある。前記ストリーミングソフトウェアは一定のビットレートで動作するので、ストリームオフセットのインクリメントをストリームＰＣＲインクリメントと関連付けることができる。

一部のフィールドを初期化することができる。例えば、「フレーム」をフレーム数とすること、あるいは現在トリックモードパケットのＧＯＰサイズとすることが可能である。最初は前に算出された数ｑに設定しておき、この数を必要（例えばＰフレームの挿入の機構）に応じて増していくことができる。ｑを浮動小数点または変数として実行する場合、下記に示すエラー伝播機構に基づいて前記フレーム数を算出することができる。

パケット・サイズ・フィールドは、合計パケットサイズを表す。前記パケットサイズは前パケットのタイムスロットに基づき、非整数のＴＳパケットを作成する。このパケットサイズは前トリックモードパケットからの超過分を考慮するエラー伝播機構によって修正することが可能である。この時点で、例えば１８８バイト（トランスポートストリームのパケットサイズ）または１３１６バイト（ＵＤＰパケットサイズを超過するＭＰＥＧ２）など、ある程度の粒度をトリックモードパケット全体に実行する場合がある。

そのストリーミングエンジンの状態によって、最初のトリックモードパケットの扱いが異なる場合がある。例えば、前記ストリーミングエンジンが休止中（すなわち一時停止および停止）であれば、そのデコーダは休止中なのでバッファアンダーフローが生じる危険がない場合がある。そのパケットサイズをゼロに設定し、当該調整方法によって修正することができる。あるいは、そのストリーミングエンジンが再生中であれば、通常の速度で表示された最後のフレームのＤＴＳと現在ＰＣＲの差分に基づいて最初のタイムスロットを算出することができる。言い換えれば、そのバッファから「通常再生」データが実質的に取り除かれた後に、最初のトリックモードパケットをデコードすることができる。これは、「再生」から「トリックモード」への移行に使用される「デバッファリング（ｄｅｂｕｆｆｅｒｉｎｇ）」法である場合がある。

この例では、前記トリックモードパケットサイズを算出するシーケンスは、前パケット（ｆｒａｍｅｓ［ｊ−ｌ］＊ｆ_ｒ）のタイムスロットに基づく。前記パケットサイズおよびパケット超過分は浮動小数点または変数であり、次のように算出することができる。

パケット超過分は、トリックモードパケットに対するある特定の粒度の実行に使われる制御変数である場合があり、Ｐフレーム挿入法によって用いることにより、パケットサイズを拡張する場合にその粒度を維持することができる。データサイズは合計データサイズを表し、Ｉフレーム、ダミーＢフレームおよびＰフレーム、ＰＡＴ、ＰＭＴ、および前記トリックモードパケットの構築に関連付けられるオーバーヘッドを含む。データサイズは、以下のように算出することができる。

「Ｂｗ＿ｂａｌａｎｃｅ」は、バッファ調整に利用可能な帯域幅を表す。これは、前記ｐａｃｋｅｔ＿ｓｉｚｅと前記ｄａｔａ＿ｓｉｚｅの差分である場合がある。未使用の帯域幅をヌルで満たし、そのストリームのビットレートを維持することができる。

一部の実施形態では、トリックモードパケットの最小限のサイズが課される。これは、調整のために利用可能な帯域幅を、算出された実際に利用可能な帯域幅より少なくすることによって達成できる。一部の実施形態では、前記トリックモードパケットのサイズを決定するときに、ハードウェアの制限によって課されるトリックモードパケット間の最小「シークタイム」または最小遅延のようなハードウェア制約が考慮される場合がある。また、ｑはトリックモード帯域幅の可能な使用方法についての一部の仮定を変えるので、ｑの計算にこれらの考慮事項が含まれる場合がある。

加えて、調整に利用可能となるヌルパケットに特定の粒度が課される場合があり、例えばＵＤＰパケットのトランスポートストリームに対して１３１６の粒度が課される。これは、ストリーミングソフトウェアまたはハードウェアの具体的な実装に依存する場合がある。利用可能な帯域幅は以下のように算出することができる。

Ｂｗ＿ｂａｌａｎｃｅは、負の値は超過サイズのパケットを表すものと仮定することが多い。前記負の値は、そのトリックモードパケットに不足しているため他のトリックモードパケットから取り出す必要のある帯域幅の量である場合がある。これは、小パケットからの利用可能な帯域幅を使い、大パケットが必要とする帯域幅を均衡することによって達成することができる。その統計解析を用い、その調整枠にある利用可能な帯域幅の全体的なバランスが、前記のパラメータεに依存して正（Σｂｗ＿ｂａｌａｎｃｅ［ｉ］>０）となるようにすることができる。

「ストリームオフセット（Ｓｔｒｅａｍ ｏｆｆｓｅｔ）」は、パケットに期待される現在ストリームのオフセットである。前記現在パケットが最初に送信されるものである場合、そのパケットは上述のようにストリーミングエンジンから取り出されるストリームオフセットである場合がある。

「ストリームＰＣＲ（Ｓｔｒｅａｍ ＰＣＲ）」は、ディスクから検索したビデオデータの正確なＰＣＲ再スタンプをするために必要な場合がある。

「ストリームＤＴＳ（Ｓｔｒｅａｍ ＤＴＳ）」は、そのトリックモードＧＯＰの一部として送信されるＩフレームのデコード時間を表す。ＤＴＳおよびＰＴＳに３００を掛けることにより、それらをＰＣＲと同じ時間ベースにすることができる。再生からトリックモードへの移行がある場合は、前記ＤＴＳを２分の１フレーム修正することによって前述のようなフィールド調整を行う必要がある場合がある。そのような移行がない場合は、前記トリックモードパケットＤＴＳは次のように算出される。

「ストリームＰＴＳ（Ｓｔｒｅａｍ ＰＴＳ）」は、そのＩフレームの正確なプレゼンテーションタイムを次のように表す。

「バッファレベル」は、そのデコーダでの最大バッファレベルである場合があり、前記デコーダがビデオデータの最終ブロックを受信したときに達成され得るものであり、そのオフセットは次のように算出される：ｐｅａｋ＿ｏｆｆｓｅｔ［ｊ］＝ｓｔｒｅａｎ＼＿ｏｆｆｓｅｔＱ］＋ｄａｔａ＿ｓｉｚｅ［ｊ］。

前記バッファは、前ＧＯＰからのいくつかのダミーＢフレームおよびＰフレームを含むことができ、最大バッファレベルを次のように算出することができる。ｂｕｆｆｅｒＪｅｖｅｌ［ｊ］＝ｓｉｚｅ［ｊ］＋（ｆｒａｍｅｓ［ｉ］−ｌ）＊Ｐ＋（ｆｒａｍｅｓ［ｉ−ｌ］−ｌ）＊Ｐ。現在トリックモードパケットの伝送中に前ＧＯＰからのダミーＢフレームおよびＰフレームが消費されるので、実際のバッファレベルは上記数値より低くなる場合がある。前記バッファレベルは、オーバーフロー対策として多めに予測される場合がある。現在トリックモードパケットのＤＴＳ（すなわちＩフレームＤＴＳ）で、前ＧＯＰからのデータは消費済みである場合があり、その場合、そのバッファレベルは次のように算出することができる：ｂｕｆｆｅｒＪｅｖｅｌ［ｊ］＝ｓｉｚｅ［ｊ］＋（ｆｒａｍｅｓ［ｊ］−ｌ）＊Ｐ。

図２は、デコードバッファの経時変化を図示する。本発明の実施形態は、Ｉフレームがデコードされる前に、ＤＴＳ［ｊ］によって与えられた時点で前記バッファレベルを制御することができる。これは、バッファ調整によって前記バッファレベルのピークがこの位置に移動するからである。前トリックモードパケットからのダミーＢフレームおよびＰフレームのサイズは比較的小さく、しかも特に前記Ｉフレームのサイズは前述したように多めに予測されているため、そのデコード時間を表す「Ｓｔｒｅａｍ ＤＴＳ」を使う式を、リスクを伴わずに用いることができる。あるいは、そのバッファがオーバーフローに到達するのを確実に防ぐために、「Ｓｔｒｅａｍ ｏｆｆｓｅｔ」が現在ストリームである式を使うことができる。

説明したように、図５は、利用可能なタイムスロットインターバルを再配列するためにトリックモードパケットをどのように調整するかを図示している。説明したように、当該制御変数ｂｗ＿ｂａｌａｎｃｅｌ［ｊ］が負であるということは、最初に保留したタイムスロットでそのパケットを伝送できないことを示す。本発明の進歩的な方法は、図５が示すように、前記パケットサイズを変更および拡張し、前パケットからの利用可能な帯域幅を消費すると同時に、前記パケットを短縮する。

前記パケットサイズを変更および拡張し、前パケットからの利用可能な帯域幅を消費すると同時に、前記パケットを短縮するＣコードの例を以下に示す。

このコードセグメントは、利用可能な帯域幅をその調整枠内で再配列させることができ、そのトリックモードパケットのデコード時間（ＤＴＳ）が期限切れになる前に、それらを完全に伝送させることができる。

さらに、帯域幅の再配列のほかに、バッファレベルも考慮することが望ましい場合がある。また、一部の実施形態では、最初のトリックモードパケットのｂｗ−ｂａｌａｎｃｅ［ｊ］は負である場合があり、それがそのシーケンスにおける最初のパケットであるため、割り当てる帯域幅の元となる前パケットがない場合がある。以下のように、Ｐフレーム挿入および移行法を使用することができる。さらに、当該制御法は各トリックモードパケットのパラメータを計算するが、必ずしもそのストリームを生成するとは限らない。これは、前記トリックモードストリームを生成するための調整法を用いるストリーミングエンジンによって達成される。

図６は、トリックモードパケットの変化がバッファレベルに与える影響を表す図である。図６はトリックモードパケットの変化に対してバッファレベルが受ける影響を説明するものであるが、一部の実施形態では、他の帯域幅の制御法および他のデータ操作法はバッファ制御を必要とする場合があると理解される。

図６が示すように、上の枠６００は、そのトリックモードパケットを変更する前のバッファレベルを反映しており、下の枠６０１は、帯域幅の制御に従って前記トリックモードパケットを変更した後のバッファレベルを反映している。前記上の枠６００が示すように、図のパケット６０２はポイント６０３（すなわちそのデコード時間切れ）でのＤＴＳの後まで完全に受信されない。前記トリックモードパケットの変化によって、ＤＴＳで最大バッファ・ストレージ・レベル６０４が作成される。さらに、最大バッファレベルを、変更されたトリックモードパケット６０５のデータ量と同等にすることができる。その差分（ｄａｔａ＿ｓｉｚｅ［ｊ］−ｐａｃｋｅｔ＿ｓｉｚｅ［ｊ］）は、ＤＴＳ［ｊ−ｌ］の時点でそのデコーダバッファにて準備され、前記トリックモードパケットがデコードされる前にその完全なバッファが可能となる。

次のコードは、最大バッファレベルの予測の一例に過ぎない。

バッファレベルは、超過サイズのフレーム（すなわち保留タイムスロットを超過するサイズのフレーム）が送信される度に増す場合がある。超過サイズのフレームの長いシーケンスを調整するときに、バッファオーバーフローが生じる場合がある。利用可能なタイムスロットより大きいデータ量がいったん決定されたら、そのバッファオーバーフローを取り込むためのアクションを採ることが望ましい。これは、様々な方法を任意に用いて達成することができる。以下の例は、本実施形態で考えられるすべての方法を排除することを意味するものではない。

バッファオーバーフローを処理する１つの方法は、Ｐフレーム挿入を含む場合がある。Ｐフレーム挿入はＰフレームを追加するものであり、よって、付加的な帯域幅を生成するために前ＧＯＰのサイズを拡張する。付加的Ｐフレームの挿入を行う方法は多数ある。付加的な帯域幅を生成するためにＰフレームを挿入する１つの方法について説明する。しかし、ここで開示する実施形態は、この方法に限定されない。以下は一例である。

大型のトリックモードパケットを持つ３．７５メガビット／秒のビデオストリームを有するトリックモードストリームを伝送するには、６つのフレーム期間が必要である場合がある。しかし、そのタイムスロットは前パケットのＧＯＰサイズによって決定されるため、４フレームしかないという場合がある。上述したように、前記パケットを変更し、２フレーム期間拡張して、伝送に必要な付加的期間を取り込むことができる。説明したように、前記トリックモードパケットを２フレーム分変更することにより、その前パケットのピーク・バッファ・レベルが約３０ｋｂ増す場合がある。１００ｋｂというサイズのビデオバッファおよび９０ｋｂというサイズの前パケットの場合、さらに３０ｋｂのバッファを試みることによってバッファオーバーフローが生じることになる。

１実施形態では、ダミーＰフレームを追加することができる。例えば、各々がＰフレームにつき約１ｋｂである２つの余分なＰフレームを追加すると、その前ＧＯＰサイズを６に上げることができる。そのバッファレベルは９２ｋｂまで２ｋｂずつだけ増し、１００ｋｂという制限内に留まる。前記前ＧＯＰに２つの付加的ダミーＰフレームを加えることにより、現在パケットサイズは拡張され、「超過サイズ」パケット全体の伝送が可能となる。言い換えれば、この方法は、前のフレームを画面に２フレーム期間多く保留することにより、前記超過サイズフレームの完全な伝送を可能にするのである。さらに、挿入された各付加的Ｐフレームは後続のトリックモードパケットを約１フレーム期間拡張することができるので、付加的な帯域幅を得ることが可能となる。この例では、各々約１ｋｂのダミーＰフレームが、１フレーム期間に伝送可能なデータ量である約１５ｋｂの帯域幅を生成する。

また、ダミーＰフレームを挿入することにより、そのＩフレームレート全体を減少することができ、その調整枠を１フレーム拡張することができる。バッファオーバーフローが検出される度に余分な１フレームを挿入することができるコードセグメントの例を以下に示す。

また、一部の実施形態は、例えば少なくとも１つのトランスポート・ストリーム・パケット（例えば典型的に１８８バイト）など、トリックモードパケットの粒度の解析を考慮する場合もある。Ｐフレームの挿入によって生成される帯域幅は、次の等式によって決定される： インクリメント＝（ｂ／８）＊（ｌ／ｆｒ）；
上記の例において、インクリメントは１５，６２５バイトである。各トリックモードパケットのサイズをエラー伝播法によって元々決定したので、同様の方法を、より正確なメモリ量を計算するために考慮することができる。例えば、トリックモードのＧＯＰサイズをｑ＝４、ビデオバッファのサイズを１１０ｋｂ、トリックモードのデータサイズを２５ｋｂ、９０ｋｂ、４０ｋｂ、７０ｋｂ、８０ｋｂ、８０ｋｂ、および８０ｋｂ、パケット粒度を１３１６バイト（例えば１つのＵＤＰパケットに７つのトランスポート・ストリーム・パケット）として、これを決定することができる。

算出されるタイムスロットは６２，５００バイト＝４＊１５，６２５バイトとなる。よって、このエラー伝播法は、６１８５２、６１８５２、６３１６８、６１８５２、６１８５２、６３１６８、６１８５２というパケットサイズのシーケンスを生成することができる。また、この方法は、３５５３２、−３１５８４、２１０５６、−１０５２８、−２１０５６、−１９７４０、−２１０５６というｂｗ＿ｂａｌａｎｃｅ値を持つ０，６１８５２、１２３１６４、１８６３３２、２４８１８４、３１００３６、および３７３２０４というパケットオフセットを生成することができる。トリックモードのデータサイズと同一であると最初に予測されたバッファレベルで、最終パケット（指数６、０ベースの指数）から始まるバッファ調整を適用することにより、以下に示すようにそのヌルサイズを差分（ｐａｃｋｅｔ＿ｓｉｚｅからｄａｔａ＿ｓｉｚｅを減算して得られる差分）として算出することができる。（注記：ここではタイムスタンプは除外される（ＰＣＲ、ＤＴＳ、およびＰＴＳ））。

第２の段階では、以下が行われる。

この時点で、余分なダミーＰフレームをトリックモードパケット４に挿入し、そのＧＯＰサイズを５に変更することができる。Ｐフレームサイズを１３１６バイトと仮定すると、以下のシーケンスが提供される。

挿入された前記Ｐフレームによって、以下の付加的な帯域幅を提供することができる。

粒度が問題となる実施形態では、パケットサイズに対して上述のものと同じエラー伝播法を用い、新しいＧＯＰサイズに基づいてパケットサイズを再計算することができる。

図７は、トリックモードストリームを作成するために使用可能なバッファ最適化の方法を図示する。図７が示すように、調整が必要なパケットは斜線模様で示されており、調整に成功したパケットは点描模様で示されている。上の枠７００は、このバッファ最適化法が採用される前の、最初の計算でのトリックモードパケットを示す。第２の枠７０１は、最後の超過サイズフレームがどのように拡張および変更され、その前フレームがその利用可能な帯域幅を消費したかを示す。第２の枠７０１も、同一のパケットの変更がどのようにそのバッファレベルに影響し得るかを示す。第３の枠７０２は、調整に成功したパケットを示す。図８は、これらの方法を用いて生成されたトリックモードストリームの出力の例を提供する。

Ｉフレームベースの方法は「低遅延」モードで機能可能であり、従ってそのデコーダでバッファレベルが低く維持されると理解される。通常再生で映画を再開するために、前記デコーダはデータの０．５ｓから１．０ｓをバッファする場合がある。バッファレベルの相違がバッファアンダーフローを引き起こすことにより、画面の横揺れまたはちらつきが生じることがあり、一時的に完全に暗黒となることさえあり得る。

ファイルベースのトリックモードは、トリックモードファイルと正規ファイルの間で切り替わる場合がある。この方法は、その移行点でのバッファレベルの一致を要求することができるので、トリックモードファイルの生成時にバッファレベルを制御することができる。前記移行点で前記バッファレベルを調整するために、付加的ロジックを追加することができる。

１実施形態では、通常再生の再開時に、当該バッファ管理方法はより精度の高い移行のためにバッファレベルを増すことによって、最後のトリックモードフレーム（典型的に２〜４フレーム）を修正する動作をすることができる。このいわゆる「スプライシング（ｓｐｌｉｃｉｎｇ）」法は前記最後のフレームの速度を下げ、再バッファリングに使用可能な超過帯域幅を生成し、ビデオバッファを通常レベルに戻すことができる。動きの感覚を中断しない方法でこの方法を実施することができるので、その移行は比較的シームレスである。

再生シーケンス後にトリックモードの再生を開始するために、ビデオバッファに保管可能な再生データはそのデコーダによって消費される。これは、そのトリックモードストリームのデコードの開始時に起き、前記ビデオバッファに存在するデータは、そのトリックモード・ストリーミング・エンジンによって生成されるデータである。最初のトリックモードパケットを、そのＤＴＳを再生中の最後のフレームのＤＴＳとフレーム間隔に設定して送信することができる。また、そのＰＴＳを、表示されている最後のフレームに１フレームを足したＰＴＳに設定することができる。前記最後のフレームの「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」フラグを１に設定すれば、ＰＴＳおよびＤＴＳは１フレーム期間の半分でインクリメントする。

前記デバッファリング法の実施は、その最初のトリックモードパケットのサイズを現在位置（ＰＣＲ）からその再生バッファが空になるまで伝送可能なデータ量として設定することによって可能であり、その最初のトリックモードフレームは、次の等式を用いて予測される（例えば上述のＤＴＳ）：
ｆｒａｍｅ＿ｓｉｚｅ［０］＝（（ＳｒｒｅａｍＤＴＳ−ＳｔｒｅａｍＰＣＲ）／２７００００００．０）＊（ｂＩ／８）。

一部のビデオストリーム（例えばＭＰＥＧ２）は、３：２のプルダウンを実行する方法として、「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」および「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」といったいくつかの特別なフラグを使う場合がある。それらのストリームでフィールド継続性を維持するために、ある特定の方法をその移行シーケンスに適用することができる。

例えば、１つの方法は、表示された最後のフレームで「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」が０（最初にボトム）に設定され、かつ「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」が０に設定されている場合に使うことができる。これは、その最後のフレームが前記トップフィールドの表示を終了したことを示す。また、前記最後のフレームの「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」が１（最初にトップ）、その「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」が１に設定されていれば、表示された最後のフィールドがそのトップフィールドであったことを示す場合がある。いずれの場合も、次に期待されるフィールドは、そのボトムフィールドである場合がある。これらの方法は「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」であると仮定するので、フィールド調整フレームを挿入することができる。

これらの方法は、ダミーＢフレームである場合があるその最初のトリックモードフレームで「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」というフラグを０に設定し、「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」というフラグを１に設定することによって実行可能である。このシーケンス（ボトム、トップ、ボトム）は、その再生シーケンスからのフィールドシーケンシングを維持するだけでなく、後続フレームを前記トップフィールドで開始することを可能にする。

このフィールド調整法はそのＧＯＰサイズを２分の１フレーム（すなわち１フィールド分）拡張する。ディスクから読み込まれたすべてのＩフレームが確実に正しいフィールドシーケンシングを有するようにするために、前記Ｉフレームがディスクからメモリに読み込まれた後に実行される再スタンプ法によって、前記Ｉフレームにおいて前記「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」フラグを１に設定し、前記「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」フラグを０に設定することができる。

一部の実施形態では、その再生シーケンスが比較的低いバッファレベルで動作する場合、その最初のトリックモードパケットを伝送する時間が十分でない場合がある。前記再生シーケンスからの最後のフレームが消費される時点で、前記最初のトリックモードバケットがまだ伝送中である場合がある。一つの解決策は、前記トリックモードパケットの開始部分にＰフレームのシーケンスを添付することであり、これは前述のＰフレーム挿入法に類似している。これらＰフレームはそのトリックモードＧＯＰの一部である必要はなく、その前ＧＯＰ（すなわち再生シーケンス）を拡張し、いくつかのフレーム間隔のためにそのデコーダに最後の画像を繰り返させるので、そのトリックモードパケットを完全に伝送することができる。

さらに、トリックモードから通常再生に戻る移行に用いられる方法は、そのトリックモードシーケンスの最後のＧＯＰを拡張して利用可能な余分な帯域幅を生成することによって達成可能である。前記利用可能な帯域幅は、例えば高遅延モードで動作している新しい再生シーケンスからのビデオデータの再バッファリングに用いることができる。

前記再バッファリング法は、そのデコーダがダミーＰフレームの再生に使用されている間、そのバッファが前記新しい再生シーケンスを保管できるよう十分な時間にわたりその最後のトリックモードパケットを保持することを試みる。前記再バッファリング法は、前記最後のトリックモードパケットのＧＯＰサイズを増すことによって、その帯域幅を徐々に生成することができる。選択されたＧＯＰサイズが４であれば、前記最後のトリックモードパケットのＧＯＰサイズは５，７，１０等となり、視覚的印象としては完全停止ではなくスローダウンとして目に映る。

利用可能な帯域幅の合計が必要な帯域幅以上になるまで前記トリックモードパケットを挿入することが可能であり、よって、その再生シーケンスの完全な再バッファリングが可能になる。前記最後のトリックモードパケットについて、そのＩフレーム選択機構も変わる場合がある。これは、リクエストされた再生オフセットから離れすぎないようにするために必要である場合がある。その指数インクリメントを最小の１．０に設定することにより、各移行トリックモードパケットがそのストリームを約１／Ｉ_ｒだけそのリクエストされた位置から離れて移動するようにすることができる。典型的な結果は、再バッファリングを可能にするには約３〜５の移行パケットが必要であることを示しており、これはＩ_ｒ＝２Ｉフレーム／秒であるストリームでのリクエストされた再生位置からわずか１．５〜２．５ｓだけ離れていることを表す。

別の可能な方法は、正確な再生オフセットから始まるトリックモードパケットのシーケンスの利用可能な帯域幅を算定することであるが、この場合は指数インクリメントを−１．０として逆戻りする。その純帯域幅が必要な帯域幅以上になると、最後のパケットはその移行シーケンスで使われる最初のパケットになる。この方法により、その移行シーケンスは確実にリクエスト通りの再生オフセットで終了することが可能である。

同じ方法で、トリックモードが負の速度（すなわちＲＥＷ）で再生されると、十分な帯域幅が利用可能になるまでＩフレームが前方（インクリメントは＋１．０）から選択される場合がある。ここで、移行パケットのシーケンスを、実際の再生シーケンスが始まる位置の逆向きに現在位置から取り出すことができる。移行トリックモードパケットのシーケンスがいったん決定され、このバッファ最適化法にロードされると、データサイズを０に、トリックモードパケットのサイズを０に設定し、ｂｗ＿ｂａｌａｎｃｅをバッファリングに必要なデータ量に設定して、この調整法に「仮想トリックモードパケット」を挿入することが可能となる。

前記バッファ最適化法の使用により、前記トリックモードパケットの利用可能な帯域幅の消費および前記移行パケットの変更が生じ、新しい再生シーケンスのためのスペースが生成される。この方法は、図８の下のグラフが示すような、６，７，８，９というＧＯＰサイズの４つの移行パケットが観察され得るバッファ移行を可能にする。この方法を用いてトリックモードから再生に移行することにより、そのフレームシーケンスの中断を起こすことなく、「スローダウン」の印象を与えることができる。

上述の方法を早送りおよび巻き戻しに利用することができる。この例では、ビデオ・オン・デマンド（ＶＯＤ）サーバは、例えばユーザがＦＦボタンを解除したときに、セットトップボックスからフィードバックを受信することができる。しかし、前記サーバのバッファ管理アルゴリズムは、通常再生に戻る移行中に遅れを起こす場合がある。そのバッファを満たすために、入ってくるフレーム数が再生中のフレーム数を超過し、ユーザからの信号の受信後にバッファを満たすためにフレームの伝送が強化される場合がある。その時点で、通常のストリームに切り替わる場合がある。

当該方法は、いくつかの余分なＢフレームおよびＰフレームを生成することによって最後のフレームの速度を下げることで、そのデコーダのバッファを満たすものであり、前記ＢフレームおよびＰフレームは、比較的小さく容易に生成され、かつ表示時間未満に伝送可能なものである。「スローダウン」は、毎秒送信されるＩフレーム数を減少することができるため、一定の３０ｆｐｓであることが通常要求される実際のフレームレートへの影響はない。あらゆるＩフレームとともに送信されるＢフレームおよびＰフレームの数（これらは比較的小さい）を増やすことにより、平均ビットレートを前記トリックモード法によって減少することができる。次に、余分な帯域幅を使って、そのバッファを通常レベルに修復することができる。

いくつかの例では、一時停止および再開モードは通常のトランスポートストリームを利用する移行であるため、これらに上述の方法を使わない場合がある。一方、ジャンプでは、その移行点でバッファレベルが異なる場合があるため、バッファ調整が必要である。また、トリックモードに適用されたものと同じ方法をジャンプに適用することもでき、これは、デバッファリングを可能にすることによって、または再バッファリングを可能にするためにダミーＢフレームまたはＰフレームを挿入することによって行われる。バッファ制御は、ＰＣＲ、ＤＴＳ、ＰＴＳといったストリームパラメータの十分な調整に関連するため、これら制御変数の一致を確保することによって速度移行およびジャンプを実施する必要がある場合がある。

その移行点後のバッファレベルが、その前のバッファレベル未満である場合、ヌルのシーケンスを挿入することによってバッファレベルを十分なレベルにすることができる。この方法は、前記移行後の元のストリームの差分（ＤＴＳからＰＣＲを引いた差分）を維持する。この新シーケンスのデコードは、その前シーケンスの最後のフレームがデコードされてから約１フレーム後に始まる。フレームのシーケンスに中断が入らないようにするために、前記移行後の最初のパケットのＰＴＳを、その前シーケンスの最後のフレームが表示されてから１フレーム後に起こすことができる。

このジャンプ法は、いくつかのＧＯＰが開いている場合があることを考慮することもできる。言い換えれば、前記新しい再生シーケンスのＩフレームの前に表示される最初のＢフレームは、伝送された前ＧＯＰからのフレームをフォワードレファレンスすることができる。さらに、前記ジャンプ法は、フィールドシーケンシングを修正し、シーケンスに２つのトップフィールドまたは２つのボトムフィールドが存在しないようにすることができる。間違ったフィールドシーケンシングは、例えばセットトップボックスに、好ましくない画面の横揺れを起こす場合がある。

前記ジャンプ法は、その前ＧＯＰの完全な送信を確保するスプライシング法を含むことができ、それにより、そのデコーダの受信バッファに不完全な画像またはシーケンスが存在しないようにする。また、前記スプライシング法は、その新シーケンスのＤＴＳからＰＣＲを引いた差分が現在ストリームのＤＴＳからＰＣＲを引いた差分（すなわち古いシーケンスからのもの）より小さいことを判断し、それにより、そのバッファレベルの低下が必要であることを判断することができる。さらに、前記スプライシング法はそのＩフレームを検索し、ダミーＢフレームのシーケンスを添付することができる。ダミーＢフレームの数を、そのＩフレームの前の元のシーケンスにあるＢフレームの数と一致させることができる。これにより、開いたＧＯＰに関して説明した問題を避けることができる。

前記スプライシング法は、「ｔｏｐ ｆｉｅｌｄ ｆｉｒｓｔ」フラグおよび「ｒｅｐｅａｔ ｆｉｒｓｔ ｆｉｅｌｄ」フラグを最初のダミーＢフレームの中で適切に設定することによってフィールドシーケンシングを調整することができる。フィールド調整が必要であれば、ＤＴＳおよびＰＴＳを適宜調整することができる。この例では、その新しい再生シーケンスは１つのＩフレームを有することができ、次にＢフレームを再スタンプして前記新しい再生シーケンス（ＰＢＢＰＢＢＰ等）の残りと一致させることにより、中断を避けることができる。前記スプライシング法は、バッファレベルを調整するために挿入可能なヌルの量を、次の等式を用いて算出する。

前記スプライシング法は、ストリームの継続性を維持するために前記新シーケンスに追加する必要のある再スタンプオフセットを、次の等式を用いて算出することができる。

前記ＰＣＲ＿ｒｅｓｔａｍｐの量をＰＣＲに加え、（ＰＣＲ＿ｒｅｓｔａｍｐ／３００）の量をそのプログラムに関連するオーディオを含むエレメンタリストリームにあるＤＴＳおよびＰＴＳに加えることにより、その移行点に続くストリーミングデータを再スタンプすることができる。

図９は、このスプライシング法がどのように働くかを図示する。その新シーケンスでのバッファレベルが、その前シーケンスでのバッファレベルより高い場合は、別の方法を採用することができる。例えば、当該Ｐフレーム挿入法およびトリックモードから再生への移行で説明した同様のプロセスを用いて最後の画像を「フリーズ」することにより、前記新シーケンスをバッファすることができる。

前記再バッファリング法は、ヌルパケットの短いシーケンスが続く多数のＰフレームを挿入する工程を含む場合がある。その前シーケンスの終了直後に、ＳｔｒｅａｍＰＣＲで始まる前記新シーケンスが伝送される場合、ＳｔｒｅａｍＰＣＲ＋（ＤＴＳ_ａ−ｗ−ＰＣＲ_ｎｅｗ）によって与えられるインスタントで最初のフレームをデコードすることができる。前記新シーケンスの最初のフレームは、ＳｔｒｅａｍＤＴＳによって与えられるインスタントでデコードされるものと期待され、これは、その前シーケンスからの最後のデコード時間後の１フレームである。これを等式によって表すと、ＳｔｒｅａｍＰＣＲ＋（ＤＴＳ_ｎｅｗ−ＰＣＲ_ｎｅｗ）>ＳｔｒｅａｍＤＴＳまたは（ＤＴＳ_ｎｅｗ−ＰＣＲ_ｎｅｗ）>（ＳｔｒｅａｍＤＴＳ−ＳｔｒｅａｍＰＣＲ）となり、次にインターバルがあり、ここでそのデコーダはデコードを停止する（すなわちバッファアンダーフローである）。

フィールドが予測した、静止ＰフレームおよびＢフレームまたはダミーフレームを「フレーム」として画像構造でエンコードすること、およびマクロブロックを「フィールド」という予測タイプでエンコードすることが可能であると理解される。これは、Ｐフレームのマクロブロックを、動きベクトル＝（０，０）である「トップフィールド」をフォワードレファレンスする「トップフィールド」および動きベクトル＝（０，０）である「トップフィールド」をフォワードレファレンスする「ボトムフィールド」でエンコードすることによって達成可能である。Ｂフレームのマクロブロックは、動きベクトル＝（０，０）である「トップフィールド」をバックワードレファレンスする「トップフィールド」および動きベクトル＝（０，０）である「トップフィールド」をバックワードレファレンスする「ボトムフィールド」でエンコードすることができる。

図１０は、データストリーム通信のためのシステムを図示する。図１０が示すように、セットトップボックス１００２はデータサーバ１００３および帯域幅調整モジュール１００４と通信中である。帯域幅調整モジュール１００４は、指定タイムスロットが前記データストリームを処理するのに十分な大きさでない場合に、前記データストリームの一部（例えばトリックモードパケット）を別のタイムスロットに移動することができる。この場合のトリックモードパケットの例として、毎秒約１０フレームの速度で通信可能な一連のＩフレームが含まれる。また、帯域幅調整モジュール１００４は、前記トリックモードパケットにダミーデータ（例えばＢフレームおよびＰフレーム）を挿入することができる。

また、システム１０００は、セットトップボックス１００２と通信中の圧縮／解凍コーダ１００５を含むことができる。圧縮／解凍コーダ１００５は、ＭＰＥＧ標準に沿って動作可能である。また、システム１０００は、セットトップボックス１００２からの画像を表示するためのディスプレイ１００６、およびトリックモード再生（例えば早送り、巻き戻し、再生、一時停止、および停止）を開始するための、セットトップボックスと通信可能なユーザインタフェース１００７を含むことができる。ディスプレイ１００６は、従来のテレビである場合がある。ユーザインタフェース１００７は、ワイヤレス方法を用いてセットトップボックスと通信することができる。ユーザインタフェース１００７は、赤外線（ＩＲ）、無線周波（ＲＦ）、または他の任意の適切なタイプのリンクのようなワイヤレスリンクを使って通信可能な従来のリモートコントロールである場合がある。本書で開示する方法、装置、およびシステムは、例えばパーソナル・デジタル・アシスタント（ＰＤＡ）、ラップトップ、および携帯電話など、ビデオデータを表示可能なコンピュータ、またはポータブル若しくは携帯装置と共に使用することもできる。

図１１は、データストリーム通信のための方法のフロー図である。１１０１では、第１のデータストリームの第１のタイムスロットであり、１１０２では、第２のデータストリームの第２のタイムスロットである。１１０３で、前記第２のデータストリームが前記第２のタイムスロットより大きいかどうかが決定される。前記第２のデータストリームが前記第２のタイムスロットより大きくない場合、１１０４において、前記第２のデータストリームは前記第２のタイムスロットで伝送される。一方、前記第２のデータストリームが前記第２のタイムスロットより大きい場合、１１０５において、前記第２のデータストリームの一部が前記第１のタイムスロットに移動される。１１０６で、前記第２のデータストリームは伝送される。

さらに、上述の方法は、さらに、前記移動部分の関数としてデータストレージ量を制御することができ、前記第２のデータストリームのサイズおよび前記第２のタイムスロットを監視することができる。これらの方法は、ＭＰＥＧ標準規格に準拠して前記データストリームを圧縮および解凍し、前記第１のタイムスロットの未使用の帯域幅を前記第２のタイムスロットに再分配することができる。上述の方法は、前記データストリームを監視することにより、前記データストリームを通信するための最大速度を決定することができる。

図１２は、データストレージまたはバッファレベルの制御方法のフロー図である。１２０１において、Ｉフレームを有するデータストリームにデータフレーム（例えばＢまたはＰフレームのダミーフレーム）が追加される。１２０２において、前記データストリームの伝送速度が変更される。１２０３において、前記第１のモードから第２のモードへの切り替えを求めるコマンドが受信され、１２０４において、第１のモードから第２のモードへの移行が行われる。前記第１、第２のモードは、トリックモード再生モードおよび／または通常再生モードである。

本発明の開示の真の範囲は、本明細書にて図を用いて開示した実施形態に限定されない。例えば、効率的なトリックモードプレイバックを行うための前述の様々な方法の開示を、別個に用いること、あるいは相互の組み合わせによって用いることができる。さらに、開示した前記実施形態は、様々な画像サイズ（例えばＨＤＴＶ）およびフレームレートで動作するものであると理解される。これらの考えられる方法は、ビジュアルアーチファクト、ブラックスクリーン、アンダーフロー、バッファオーバーフローに典型的に伴うマクロブロッキング、あるいはバッファ管理なしに実行される移行に一般に生じる中断を起こすことなく、異なる再生速度と通常再生速度との間の滑らかな移行を可能にするものであると理解される。また、これら開示された方法の一部として、異なるダミーＢフレームおよびＰフレームのエンコーディングを使うことができる。例えば、一部の実施形態では、フレーム予測されたＢフレームおよびＰフレームを「静止」フレームとして使う代わりに、上述したように、異なるエンコーディングを使う場合があり、これは本発明の範囲に含まれる。これは、インターレース画像のような特定のタイプのフォーマットのために提供され得るものである。

さらに、当業者であれば理解するように、本明細書で開示された発明の態様の多くは、メディアストリーミングまたはビデオ・オン・デマンドのために採用されるのでないソフトウェアまたはハードウェアソリューションとして、コンピュータシステムに適用可能である。同様に、これらの実施形態は、ＶＯＤ（ビデオ・オン・デマンド）コンセプトを採用するシステムあるいは特定のタイプのコンピュータ、プロセッサ、スイッチ、ストレージデバイス、メモリ、アルゴリズム等を採用するシステムに限定されない。デジタルプロセシング機能、ネットワーキング機能、およびストレージ機能にかかるコストの急速な低下を鑑み、例えば、前記システムの本発明の動作を変えずに、ある特定の機能のためのプロセシングおよびストレージを、本明細書で説明した１機能的要素から別の機能的要素に移行させることは容易に可能である。多くの場合、本明細書で説明した実装の場所（すなわち機能的要素）は、単に設計者の好みの問題であり、絶対的な要件ではない。従って、限定されることが明示されていない限り、本発明の保護範囲は上述の具体的な実施形態に限定されることを意図しない。

本出願は、２００４年７月２３日に出願された「Ｂｕｆｆｅｒ Ｏｐｔｉｍｉｚｅｄ Ｔｒｉｃｋｍｏｄｅｓ ａｎｄ Ｓｐｅｅｄ Ｔｒａｎｓｉｔｉｏｎｓ」と題する米国特許仮出願第６０／５９０，５０４号に対する優先権を主張するものであり、前記仮出願はこの参照によりその全体が本明細書に組み込まれる。

１０００ システム
１００２ セットトップボックス
１００３ データサーバ
１００４ 帯域幅調整モジュール
１００５ 圧縮／解凍コーダ
１００６ ディスプレイ
１００７ ユーザインタフェース

Claims (30)

1. 帯域調整モジュールを有するシステムのためにデータストリームを通信する方法であって、
   （Ａ）前記帯域調整モジュールにより、第１のデータストリームのための第１のタイムスロットを決定する工程と、
   （Ｂ）前記帯域調整モジュールにより、第２のデータストリームのための第２のタイムスロットを決定する工程と、
   （Ｃ）前記帯域調整モジュールにより、前記第２のデータストリームが前記第２のタイムスロットより大きい場合、当該第２のデータストリームの一部を前記第１のタイムスロットに移動する工程と、
   を有し、
   前記工程（Ｃ）は、
   前記帯域調整モジュールにより、前記第１のタイムスロット及び前記第２のタイムスロットを１つのウインドウ内で選択し、前記データストリームの前記一部を調整してバッファオーバーフローを回避する工程、
   を更に有する、
   ことを特徴とする方法。
2. 前記工程（Ｃ）は、
   前記帯域調整モジュールにより、前記移動部分の関数として前記第１及び第２のデータストリームを格納するために用いられるバッファ量を制御する工程、
   を更に有する、
   ことを特徴とする請求項１記載の方法。
3. 前記工程（Ｃ）の前に、
   前記帯域調整モジュールにより、前記第２のデータストリームのサイズおよび前記第２のタイムスロットのサイズを監視する工程、
   を更に有する請求項１記載の方法。
4. 前記システムの圧縮／解凍デコーダにより、Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ：エムペグ）標準規格に準拠して前記第１及び第２のデータストリームを圧縮および解凍する工程、
   を更に有する請求項１記載の方法。
5. 前記第１および第２のデータストリームはトリックモードストリームである、
   ことを特徴とする請求項１記載の方法。
6. 前記トリックモードストリームはトリックモードパケットを有する、
   ことを特徴とする請求項５記載の方法。
7. 前記工程（Ｃ）の前に、
   前記帯域調整モジュールにより、前記第１のタイムスロットにおける未使用の帯域幅を前記第２のタイムスロットに再分配する工程、
   を更に有する、
   ことを特徴とする請求項１記載の方法。
8. 前記第１及び第２のデータストリームは、それぞれ固定長のタイムスロットである、
   ことを特徴とする請求項１記載の方法。
9. 前記帯域調整モジュールにより、前記第１及び第２のデータストリームを監視して、当該第１及び第２のデータストリームを通信するための最大速度を決定する工程、
   を更に有する請求項１記載の方法。
10. 情報を通信するための通信システムであって、
    他の機器と通信を行う帯域幅調整モジュール、
    を有し、
    前記帯域幅調整モジュールは、前記データストリームが第２のタイムスロットより大きい場合、前記データストリームの一部を第１のタイムスロットに移動することができ、
    前記データストリームの前記一部を調整してバッファオーバーフローを回避するために、前記第１のタイムスロット及び前記第２のタイムスロットは１つのウインドウ内にある、
    ことを特徴とするシステム。
11. 前記データストリームはトリックモードパケットである、
    ことを特徴とする請求項１０記載のシステム。
12. 前記トリックモードパケットはＩフレームを有する、
    ことを特徴とする請求項１１記載のシステム。
13. 前記Ｉフレームは毎秒１０フレームの速度で通信される、
    ことを特徴とする請求項１２記載のシステム。
14. 前記帯域幅調整モジュールはダミーデータを前記トリックモードパケットに挿入する、
    ことを特徴とする請求項１１記載のシステム。
15. 前記ダミーデータはＢフレームとＰフレームとを有する、
    ことを特徴とする請求項１４記載のシステム。
16. セットトップボックスと通信し、前記データストリームを圧縮／解凍する圧縮／解凍デコーダ、
    を更に有する請求項１０記載のシステム。
17. 前記圧縮／解凍デコーダはＭｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ：エムペグ）標準規格に準拠して動作する、
    ことを特徴とする請求項１６記載のシステム。
18. セットトップボックスと通信を行ってトリックモード再生を開始することが可能なユーザインタフェース、
    を更に有する請求項１０記載のシステム。
19. 前記ユーザインタフェースはワイヤレスである、
    ことを特徴とする請求項１８記載のシステム。
20. 前記トリックモード再生は、早送り、巻き戻し、再生、一時停止、および停止のうちの少なくとも１つを含む、
    ことを特徴とする請求項１８記載のシステム。
21. 前記データストリームはビデオストリームである、
    ことを特徴とする請求項１０記載のシステム。
22. セットトップボックスと通信を行う表示装置、
    を更に有する請求項１０記載のシステム。
23. 帯域調整モジュールを有するシステムのために前記第１及び第２のデータストリームを格納するために用いられるバッファ量を制御する方法であって、
    （Ａ）前記帯域調整モジュールにより、データストリームにデータフレームを追加する工程と、
    （Ｂ）前記帯域調整モジュールにより、前記データストリームの伝送速度を変更する工程と、
    （Ｃ）前記帯域調整モジュールにより、前記データストリームを第１のモードから第２のモードに移行する工程と
    を有し、
    前記工程（Ｃ）は、
    前記帯域調整モジュールにより、第１のデータストリームのための第１のタイムスロットを決定し、第２のデータストリームのための第２のタイムスロットを決定し、前記第２のデータストリームが前記第２のタイムスロットよりも大きい場合、前記第２のデータストリームの一部を前記第１のタイムスロットに移動する工程、
    前記帯域調整モジュールにより、前記第１のタイムスロット及び前記第２のタイムスロットを１つのウインドウ内で選択し、前記データストリームの前記一部を調整してバッファオーバーフローを回避する工程、
    を更に有し、
    前記第１のモードはトリックモード再生モード及び通常再生モードのうちの一方であり、前記第２のモードは該トリックモード再生モード及び該通常再生モードのうちの他方である、
    ことを特徴とする方法。
24. 前記工程（Ｃ）の前に、
    前記帯域調整モジュールに、前記第１のモードから第２のモードに切り替えるためのコマンドを受信させる工程、
    を更に有する請求項２３記載の方法。
25. 前記システムの圧縮／解凍デコーダにより、Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ：エムペグ）標準規格に準拠して前記データストリームを圧縮および解凍する工程、
    を更に有する請求項２３記載の方法。
26. 前記データフレームはダミーフレームである、
    ことを特徴とする請求項２３記載の方法。
27. ダミーフレームはＢフレームおよびＰフレームのうちの少なくとも１つである、
    ことを特徴とする請求項２６記載の方法。
28. 前記データストリームはＩフレームを有する、
    ことを特徴とする請求項２６記載の方法。
29. 前記データストリームはビデオストリームである、
    ことを特徴とする請求項２３記載の方法。
30. コンピュータのプロセッサにより実行されるためのコンピュータプログラムコードを具現化するコンピュータ可読記憶構造を有するコンピュータプログラムであって、
    前記コンピュータプログラムコードは、請求項１に記載の方法を実行する命令を有する、
    ことを特徴とするコンピュータプログラム。

Images