JP5452495B2 - オーディオ・ビデオレンダリングの早期開始システム及び方法 - Google Patents

Description

本発明は、オーディオ・ビデオのレンダリング（rendering）に関し、特に、オーディオ・ビデオレンダリングの早期開始方法に関する。

このセクションは、以下に説明して特許を請求する本発明の様々な態様に関連する様々な態様の技術を読者に紹介することを意図するものである。この説明は、本発明の様々な態様の理解を容易にする背景情報を読者に提供する役に立つと思われる。従って、言うまでもなくこれらの記載は上記を考慮して読むべきであり、先行技術として認める（admissions of prior art）ものではない。

テレビジョン放送技術における変化により、ザッピング（zapping）時間が長くなった。アナログ放送テレビジョンではザッピングはすぐにできた。デジタルテレビではザッピングに時間がかかる。以下に例を示す。放送ネットワークを介したビデオ配信には、ＭＰＥＧ−２やＪＶＴ／Ｈ．２６４／ＭＰＥＧ ＡＶＣなどの標準的な圧縮システムが用いられる。ＭＰＥＧ標準ではグループ・オブ・ピクチャ（ＧｏＰ）が規定されている。ＧｏＰは連続したピクチャシーケンスＩ，Ｐ，Ｂである。これらのピクチャはＭＰＥＧ標準で定義されている。Ｉピクチャは他のピクチャを参照せずにエンコードされる。Ｐピクチャは先行するＩピクチャまたはＰピクチャを参照する。Ｂピクチャは先行するＩピクチャまたはＰピクチャと、後続のＩピクチャまたはＰピクチャを参照する。受信器は、新しい番組を受信すると、Ｉピクチャの受信を待ってその番組のデコードを開始する。ストリームの受信と、そのストリームのビデオ画面へのレンダリングとの間には遅延が生じる。

デジタルテレビジョンの帯域幅を削減するために用いるメカニズムが使うＩピクチャは減少しつつある。デコーダは、Ｉピクチャを見つけてデコードするのに時間がかかる。これには１／２秒かかることもある。さらに、インターネットプロトコルネットワークによるテレビジョントランスポートの場合、デコーダにバッファを設けて、ネットワークにおける配信の低信頼性を補正する必要がある。このため、番組の受信と、テレビジョンストリームのデコーダへの伝送との間の時間が長くなる。受信と、新しい番組の画面へのレンダリングとの間には２秒以上かかることもある。

このザッピング（zapping）時間を短くする技術が検討されている。特許文献１は、高速Ｉピクチャ検出（rapid I picture finding）などザッピング用に素早くデコードできる追加的ストリームを記載している。特許文献２は、デコーダにデータをためるユニキャストバーストプッシュ法を記載している。これらの方法では、ザッピングプロセス用に追加的ストリームをデコーダに送信することが必要である。

国際特許出願公開第ＷＯ２００５／１１２４６５Ａ１号 欧州特許出願公開第ＥＰ１５２３１９０号

本発明はオーディオ・ビデオレンダリングの早期開始方法に関する。本発明は、オーディオ・ビデオ情報の受信者における簡単な方法であり、オーディオ・ビデオ情報の送信者には何も影響を与えない。

このため、本発明は、レシーバにおける、標準的レンダリングスピードでレンダリングされるよう構成された離散的サンプルを含むストリームを再生する方法に関し、レシーバにおいて、ストリームの受信を開始する段階と、標準的レンダリングスピードより遅いスピードで離散的サンプルのレンダリングを開始する段階と、そのレンダリングスピードを標準的レンダリングスピードまで速める段階とを含む。

ストリームは他の装置から受信する。レシーバはストリームの受信を開始する。

標準的レンダリングスピードで離散的サンプルのレンダリングを開始せずに、本発明のレシーバは遅いスピードでレンダリングを開始する。これが遅く始めるレンダリングである。レンダリングスピードを、標準的レンダリングスピードまでゆっくりと連続的に速くする。これにより離散的サンプルを早くレンダリングできる。

本発明の一実施形態では、ストリームは連続的サンプルを含み、連続的および離散的サンプルは標準的レンダリングスピードで同期してレンダリングするよう構成され、方法はさらに、離散的サンプルをノーマルスピードより遅いスピードでレンダリングする時、連続的サンプルを標準的レンダリングスピードで、離散的サンプルと同期させないでレンダリングする段階と、離散的サンプルを標準的レンダリングスピードでレンダリングする時、連続的サンプルを標準的レンダリングスピードで、離散的サンプルと同期させてレンダリングする段階と、を含む。

ゆっくり始まる方法で連続的サンプルをレンダリングすると、エンドユーザにとっては不便である。連続的サンプルを同期してレンダリングするのがエンドユーザにとって受け入れられるようになる時を待っていたのでは、エンドユーザに取っては長すぎる。本発明の連続的サンプルのレンダリングは、離散的サンプルのレンダリングとは同期しない。本方法により、エンドユーザに受け入れられる、連続的サンプルの早いレンダリングを提供する。

本発明の一実施形態では、離散的サンプルと同期して連続的サンプルをレンダリングする段階は、離散的サンプルのレンダリングを連続的サンプルのレンダリングに合わせて開始する。

同期の始まりはエンドユーザには明らかである。

本発明の一実施形態では、離散的サンプルと同期しないで連続的サンプルをレンダリングする段階は、離散的サンプルを標準的レンダリングスピードでレンダリングする時に対応する時に開始する。

本発明の一実施形態では、ストリームは連続的サンプルを含み、連続的および離散的サンプルは標準的レンダリングスピードで同期してレンダリングするよう構成され、本方法はさらに、離散的サンプルをノーマルスピードより低いスピードでレンダリングし、連続的サンプルのレンダリングスピードが閾値に到達した時、離散サンプルと同期させて、ノーマルスピードより低いスピードで連続的サンプルをレンダリングする段階であって、スピードを標準レンダリングスピードまで連続的に早くする段階を含む。

エンドユーザに受け入れられるなら、標準的レンダリングスピードより遅いスピードで連続的サンプルをレンダリングすることも可能である。この方法により、レンダリングを早く始められ、連続的サンプルのレンダリングスピードが十分速く（convenient）なりしだい、離散的サンプルのレンダリングと同期できる。

本発明の一実施形態では、ストリームを受信する段階の前に、新しいプログラムをザッピングする段階を含む。

本発明のこの方法により、ザッピング時間を短くできる。

本発明の一実施形態では、離散的サンプルはビデオサンプルであり、連続的サンプルはオーディオサンプルである。

本発明の一実施形態では、ストリームはＭＰＥＧ−２ストリームである。

本発明の一実施形態では、離散的サンプルをレンダリングする時間は、同じレンダリング時間の連続的サンプルと離散的サンプルの受信の間の遅延に依存する。

離散的サンプルのレンダリング時間を長くすることにより、同じレンダリング時間に対応する連続的および離散的サンプルの受信の間の遅延が大きすぎる場合、連続的サンプルのレンダリングと同期できる。

開示した実施形態と同じ範囲の態様を以下に記載する。言うまでもなく、これらの態様は、読者に本発明が取り得る形態の簡単な概要を提供するためだけに記載するものであり、本発明の範囲を限定するものではない。実際、本発明は、以下に記載していない様々な態様を包含し得る。

本発明は、添付した図面を参照して以下の実施形態及び実施例により、よりよく理解でき、例示できるであろう。

実施形態によるシステムを示すブロック図である。 実施形態による受信器を示すブロック図である。 実施形態によるゆっくり開始するビデオレンダリングプロセスを示す図である。 第１の実施形態によるゆっくり開始するオーディオレンダリングプロセスを示す図である。 第２の実施形態によるゆっくり開始するオーディオレンダリングプロセスを示す図である。 第３の実施形態によるゆっくり開始するオーディオレンダリングプロセスを示す図である。 オーディオ・ビデオストリームの受信を示す図である。 オーディオとビデオの受信によるオーディオとビデオのプレゼンテーションを示す図である。 オーディオとビデオの受信によるオーディオとビデオのプレゼンテーションを示す図である。

図１と図２では、表示したブロックは純粋に機能的なものであり、必ずしも物理的なものとして分離していることを示すものではない。すなわち、これらのブロックは、ソフトウェアとして開発してもよいし、集積回路により実施してもよいし、ソフトウェアと集積回路の組み合わせにより実施してもよい。

実施形態によるシステムを図１に示した。本システムは、サーバ６とレシーバ４とビデオ画面５となどの装置を含む。サーバはビデオソースモジュール１とビデオエンコーダモジュール２とを含む。もちろん、ビデオソースモジュールとビデオエンコーダモジュールとは別々の装置に含まれていてもよい。サーバは、オーディオ・ビデオストリームをエンコードして、それを、インターネットプロトコルネットワーク３を介してレシーバに送信する。もちろん、オーディオ・ビデオストリームは、サーバからレシーバにオーディオ・ビデオストリームを送信できるネットワークであればどんなネットワークで送信してもよい。特に、ネットワークはローカルエリアネットワークであってもよい。オーディオ・ビデオの複数のコンポーネントを複数のネットワークを介して送信してもよい。この場合、コンポーネントにはレシーバにおいて同期する手段を有している。ビデオレシーバはセットトップボックスである。もちろん、ビデオレシーバは、ビデオデコーディングをするセットトップボックスの機能などの機能を有する装置であれば、どんな装置であってもよい。ビデオストリームは、セットトップボックスで受信され、デコードされ、ビデオ画面にレンダリング（rendered）される。

実施形態によるレシーバを図２に示した。本レシーバは、ネットワークを介してサーバからオーディオビデオデータを受信する通信モジュール２１を含む。オーディオデータとビデオデータとを記憶する記憶モジュール２３を含む。オーディオストリームとビデオストリームをデコードするオーディオ・ビデオデコーディングモジュール２５を含む。ユーザにレシーバを制御させるユーザインタフェース２４を含む。ユーザインタフェースによりザッピング（zapping）方法を起動または停止（deactivate）できる。以下に説明するすべての実施形態を同一のレシーバに実装して、ユーザインタフェースによりザッピング方法を選択してもよい。処理モジュール２２は、実施形態による方法を実行するように構成されている。データは内部バス２６を介してやりとりされる。

実施形態によるゆっくり開始するビデオレンダリングプロセスを図３に示す。図３には、時間の関数として、受信バッファのデータレベル（filling level）を示す図と、ビデオレンダリングのスピードを示す図とを含む。

ストリームは標準的なスピードで伝送される。これにより、レシーバは標準的なスピードでそのストリームをレンダリングできる。ステップＳ１において、ストリームをレシーバが受信する。画像は記憶されず、レンダリングもされない。ステップＳ２において、ストリーム中のＩピクチャを見つける。フェーズ１では、このＩピクチャを画面に表示する。レシーバは受信バッファにデータをため（filling）始める。バッファには受信レートでデータがたまる。受信したＩピクチャだけをレンダリングし、その他の画像は使わないからである。ステップＳ３において、受信バッファがレンダリング開始レベルに達する。このレベルは、ビデオを適切にレンダリングできる受信データ量に相当する。このレベル値を変更して、レンダリングをもう少し早く、または遅く開始することもできる。非常に早く開始すると、レンダリングされる画像は一連の静止画となる。それほど早くなければ、レンダリングされる画像はスローモーションビデオのように見える。この段階では、レンダリングは標準的なレンダリングスピードより遅いスピードで実行される。ここでフェーズ２が始まる。バッファには受信スピードでデータがたまるが、標準的なスピードより遅い、レンダリングスピードに対応するスピードでデータが出力される（emptied）。標準的なスピードでのレンダリングできるように、このデータが出力されるスピードをゆっくり加速する。そのため、バッファレベルは上がり続けるが、レンダリングスピードが標準スピードに近づくので、上がりかたは徐々に遅くなる。ステップＳ４において受信バッファがいっぱいになる時点まで、レンダリングスピードは加速される。この時点は、ビデオが標準スピードでレンダリングされるフェーズ３に対応する。

データを出力するスピード（emptying speed）は次のように加速される。ビデオバッファにはデータがＮ％たまっているとする。データを出力するスピードを １００／（１−Ｎ）×coeff／１００ と設定する。coeffの値はデフォルトで１に設定する。例えば、ビデオバッファにデータが６０％たまっていると、データを出力するスピードは標準スピードの７１．４％である。

coeffの値は１以外のどんな値に設定してもよい。coeffの値を１より小さくすると、満足できるレンダリングスピードには早く達するが、バッファにデータをためるのに時間がかかり、標準的スピードに達するには時間がかかる。coeffの値を１より大きくすると、バッファに早くデータがたまるが、最初のレンダリングスピードはゆっくりである。coeffの値をバッファサイズに応じて動的に変更してもよい。

バッファのデータ量が増えると、スピードも上がり、標準スピードになる。

ゆっくり始まるレンダリングプロセスはビデオの場合に好都合である。これは、一連の静止画であり、離散サンプルとも呼ばれる。コンテンツの離散サンプルは、ある時間表示すると、その時間中同じコンテンツを表示する。離散サンプルはある時間中１回だけレンダリングされる。ビデオは、速くまたはゆっくりレンダリングされる一連の離散サンプル、すなわち静止画である。ＭＰＥＧ−２では一般的に、ＰＡＬシステムの場合、ビデオは４０ｍｓごとに１ピクチャの頻度で表示される。これは１秒あたり２５ピクチャである。４０ｍｓごとに１ピクチャより頻度が高ければエンドユーザには受け入れられる。

ゆっくり始まるレンダリングプロセスは、オーディオなどの連続的サンプルには適合しないかも知れない。コンテンツの連続サンプルは、ある時間表示すると、その時間中、全コンテンツを連続的に表示する。連続サンプルはある時間に徐々に表示される。ＭＰＥＧ−１レイヤ２またはレイヤ３では一般的に、オーディオストリームは、例えば２４ｍｓごとに１サンプルの固定サイズのサンプルにエンコードされる。これは４８ｋＨｚサンプリングに相当する。このサンプルを通常のレートより低い、または高いレートでレンダリングすると、一般的には音声のピッチが変化する。レンダリングスピードが５％高くなるか低くなると、ピッチの変化が分かってしまう。

早いオーディオレンダリングの第１の実施形態では、図４に示したゆっくり始まるメカニズムを用いる。図４は、時間の関数として、オーディオ受信バッファのグラフとオーディオレンダリングスピードのグラフとを示す。オーディオレンダリングスピードのグラフは、図３に示したビデオレンダリングスピードと同じである。第１の実施形態では、ゆっくり始まるビデオレンダリングと同期して、オーディオをレンダリングする。

レシーバでは、サンプルの再生の際にピッチを変えないようにサンプル時間を修正できるアルゴリズムを用いる。かかるアルゴリズムは当業者には周知である。かかるアルゴリズムを以下ピッチアルゴリズムと呼ぶが、これを用いて、エンドユーザが気がつく強い効果を生じさせずに、レンダリングスピードを２５％上げる、または下げることができる。それゆえ、受信バッファにデータが７５％たまっているとき、レシーバはオーディオを透過的にレンダリングしてもよい。もちろん閾値は７５％より高くても低くてもよい。これは処理する音声の種類と、アルゴリズム自体に依存するだろう。

レシーバはビデオと同時にオーディオを受信する。オーディオをオーディオ受信バッファに記憶する。これがフェーズ１′であり、図３のフェーズ１に対応する。Ｓ′２（図３のＳ３に対応する）でビデオレンダリングが始まると、オーディオサンプルは同期して消費されるが、レンダリングはされない。これがフェーズ１．５′である。オーディオレンダリングのスピードが７５％に達すると、フェーズ２′のステップＳ′３でオーディオレンダリングが始まる。オーディオはビデオのレンダリングと同期される。フェーズ１．５′と２′において、オーディオバッファには徐々にデータがいっぱいまで入れられる。オーディオ受信バッファがいっぱいになると、ステップＳ′４でフェーズ３′になる。オーディオとビデオは標準スピードでレンダリングされる。フェーズ３′は図３のフェーズ３と同じである。

実施形態によっては、オーディオを低速でレンダリング処理するピッチアルゴリズムがない。こうした実施形態では、オーディオでは標準スピードしか使えない。前記の方法では、オーディオはフェーズ２の終わりフェーズ３に入る時に初めてレンダリングする。これには時間がかかる。

図５に第２の実施形態による早期オーディオレンダリングを示した。これはレシーバがピッチアルゴリズムを有さない場合の非同期的方法である。図５は、時間の関数として、オーディオ受信バッファとオーディオレンダリングスピードとを示す。オーディオレンダリングスピードのグラフは、図３に示したビデオレンダリングスピードと同じである。特に、フェーズ１の初めとフェーズ１ｂｉｓの初めは一致し、フェーズ３とフェーズ３ｂｉｓは一致する。実施形態では、レシーバはオーディオストリームを受信し、オーディオ受信バッファにデータを入れる。フェーズ１の終わりでバッファがいっぱいになると、レシーバはＳ３ｂｉｓとフェーズ２ｂｉｓにおいてオーディオを標準スピードでレンダリングする。そのため、フェーズ２ｂｉｓでは、オーディオのレンダリングはビデオのレンダリングと同期していない。オーディオは、低速のビデオレンダリングの開始よりも後にレンダリングされる。オーディオは、ステップＳ５ｂｉｓでビデオが標準スピードでレンダリングされると、ビデオと同期される。

図６に示したように、第３の実施形態では、ピッチアルゴリズムを用いる方法を非同期的方法と組み合わせる。レシーバはピッチアルゴリズムを実行する手段を有する。レシーバは、フェーズ１ｔｅｒで、オーディオを受信し、ビデオバッファと同じスピードでオーディオ受信バッファにデータを入れる（fill）。ビデオレンダリングが始まってもオーディオレンダリングは始まらない。オーディオの閾値に到達しておらず、オーディオのレンダリングはエンドユーザにとって満足できるものではない（unacceptable）。オーディオバッファが閾値に達すると、ピッチアルゴリズムはステップＳ′′３で、オーディオを低いスピード（ここでは８５％）でレンダリングする。ここでフェーズ１′ｔｅｒが始まる。オーディオはビデオのレンダリングと同期されない。

オーディオバッファにデータが入っているレベル（filling level）は、ビデオバッファにデータが入っているレベルより高い。オーディオバッファにデータが入っているレベルがビデオバッファにデータが入っているレベルになると、ステップＳ′′５でオーディオをビデオと同期する。ここでフェーズ２ｔｅｒが始まる。同期したオーディオ・ビデオのレンダリングスピードはゆっくりと高くなり、第１の実施形態で示したように、ステップＳ′′４とフェーズ３ｔｅｒで標準スピードに到達する。

オーディオとビデオが、同期すべき時（例えば、非同期的方法におけるフェーズ２の終わり）に、正確には一致しない場合、オーディオコンポーネントをビデオコンポーネントに合わせるより、ビデオコンポーネントをオーディオコンポーネントに合わせる方が容易である。その時にレンダリングされるビデオピクチャを、元の時間より長くまたは短くレンダリングして、対応するオーディオサンプルに追いつくようにする。オーディオコンポーネントの調整はビデオコンポーネントの調整ほど容易ではない。ピッチアルゴリズムが無いシステムの場合、オーディオコンポーネントの調整により、短い無音状態やスクラッチノイズなどのエンドユーザに対する音声的インパクトが生じる。

オーディオとビデオのバッファサイズはオーディオサンプルとビデオサンプルの受信時間に応じて決まる。図７に示すように、これらのサンプルは、同時に、または異なる時間に受信される。ＰＴＳはＭＰＥＧ−２トランスポートストリームに準拠したプレゼンテーションタイムスタンプ（presentation time stamp）である。トランスポートプレーンは受信したパケットのＰＴＳの値を示し、ＰＴＳの受信時間の差を示す。図では、図示を目的として、ＰＴＳは長さが等しいサンプルを表している。これはＭＰＥＧシステムでは技術的には正しくない。バッファプレーンは受信時間の差に応じて必要となる最小受信バッファサイズを示す。レンダリングプレーンは、オーディオとビデオを同期してレンダリングする時を示す。

オーディオサンプルとビデオサンプルは、同時に受信されると、受信した時の同じＰＴＳを有する。オーディオバッファとビデオバッファには同時にデータが入れられる（filled）。そのため、オーディオバッファとビデオバッファとは時間単位のサイズは同じである。

オーディオコンポーネントとビデオコンポーネントは、トランスポートレベルでは同期しておらず、同時に受信されない。７０２では、オーディオの前にビデオを受信し、その差は２ＰＴＳである。Δ＝２で示した。７０３では、オーディオの後にビデオを受信し、その差は２ＰＴＳである。Δ＝−２で示した。

レシーバではバッファ調整が必要となる。７０２では、バッファプレーンにおけるビデオバッファサイズが時間的に２ＰＴＳ大きい。７０３では、バッファプレーンにおけるオーディオバッファサイズが時間的に２ＰＴＳ大きい。レンダリングプレーンでは、オーディオとビデオが同じＰＴＳでレンダリングされる。

しかし、非同期的方法では、ザッピングフェーズ（zapping phase）において、オーディオレンダリングを非常に早くすることが可能である。

図８と図９は、オーディオとビデオを同時に受信していない場合のオーディオとビデオのプレゼンテーションを示す図である。図８に示したように、オーディオコンポーネントをビデオコンポーネントより遅く受信する。ビデオバッファサイズを大きくする必要はない。ビデオバッファサイズの大きさは十分であり、フェーズ２以降同期できる。仮想ビデオラインに到達すると、オーディオが非同期で始まる。仮想ビデオラインについては後で説明する。

図９に示したように、トランスポートレベルでオーディオコンポーネントをビデオコンポーネントより非常に遅く受信すると、ビデオバッファサイズを大きくして新しいビデオバッファサイズにする。これが必要なのは、デフォルトのビデオバッファサイズが十分に大きくなく、フェーズ２以降、オーディオに同期できないからである。仮想ビデオラインはこの新しいビデオバッファサイズに基づき計算される。仮想ビデオラインに到達すると、オーディオが非同期で始まる。

非同期のオーディオをレンダリングする時点は、仮想ビデオラインとの交点で決まる。この仮想ビデオラインの計算は、最後のビデオバッファサイズを用いて、ビデオがザッピング無しに標準スピードでレンダリングされた場合にレンダリングされるだろうビデオＰＴＳを外挿して行われる。正確に計算すると、オーディオとビデオはフェーズ２の終わりで同期される。最後のビデオバッファサイズを計算するために、ビデオコンポーネントのビットレートが必要である。最後のビデオバッファサイズが時間単位で表されるからである。

仮想ビデオラインは、最小ビデオバッファサイズと、オーディオおよびビデオの受信時のＰＴＳの差と、ビデオのビットレートとを考慮して計算する。パケット受信フローを用いて受信ビットレートを継続的に計算する。最小ビデオバッファサイズがbuffer_defaultである。受信フローにおけるオーディオとビデオの差を観測する。これがdelta_audio_videoである。

これから目標ビデオバッファを求める。これがbuffer_realである：

仮想ビデオＰＴＳを継続的に計算する：

実際のオーディオのＰＴＳがvirtual_video_PTSに到達すると、オーディオを標準スピードでレンダリングする。オーディオバッファサイズをその時のオーディオバッファにデータが入っているレベル（audio buffer filling level）に設定する。

ここに示した実施形態は好ましくは小さなバッファに適している。ここで小さなバッファとは、最大５秒に相当するものである。

バッファがもっと大きい場合、ザッピング方法は、フェーズ２とフェーズ３の間に、コンテンツを標準スピードに近いスピードで長時間レンダリングする別のフェーズを含む。リニアにノーマルレベルに到達する。レシーバは、通常、フェーズ３において、ノーマルなバッファのデータ蓄積レベル（filling level）を継続的に更新する補正メカニズムをセットアップし、トランスポートジッタの変化をサポートする。プログレッシブにバッファにデータが蓄積される仮想ラインである仮想バッファレベルを継続的に更新する補正メカニズムもこのフェーズでセットアップされる。

例えば３０秒バッファの場合、フェーズ２はバッファのデータ蓄積レベルが２秒のところで終わる。その後、新しいフェーズにおいて、標準スピードの９５％のスピードでビデオをレンダリングする。

明細書、特許請求の範囲、及び図面に開示した内容（references）は、独立に設けることもできるし、適切に組み合わせて設けることもできる。必要に応じて、ハードウェア、ソフトウェア、またはこれらの組み合わせで機能を実施することができる。

本明細書において「一実施形態」とは、その実施形態に関して説明する具体的な機能、構造、特徴などが本発明の少なくとも１つの実施形態に含まれ得ることを意味している。本明細書ではいろいろな箇所で「一実施形態とは」と記載するが、必ずしも同じ実施形態を指すものではなく、別の、または代替的な実施形態は、必ずしも他の実施形態と互いに排他的なものではない。

特許請求の範囲に示す参照符号は例示であり、請求項の範囲を限定するものではない。

Claims (1)

1. レシーバにおけるストリームの早期再生方法であって、前記ストリームはビデオサンプルとオーディオサンプルとを含み、前記オーディオサンプルと前記ビデオサンプルとは標準レンダリングスピードで同期してレンダリングされるよう構成され、前記方法は、レシーバにおいて、
   前記ストリームの受信を開始するステップと、
   標準的レンダリングスピードより遅いスピードで、標準的レンダリングスピードでレンダリングされるオーディオサンプルと同期せずに、前記ビデオサンプルのレンダリングを開始するステップと、
   前記ビデオサンプルのレンダリングスピードを標準的レンダリングスピードまで速めるステップと、
   標準的レンダリングスピードでレンダリングされているオーディオサンプルと同期して、標準的レンダリングスピードでビデオサンプルをレンダリングするステップと、を含む方法。
   

Images