JP4440651B2 - データストリーミングシステムのためのデータ構造 - Google Patents

Description

本発明はＩＰ（インターネットプロトコル）ネットワーク上でストリーミングされる音声/コンテンツとビデオコンテンツを記憶するために適したデータ構造に関する。特に、本発明は、物理的なネットワーク特性および／または他のトラフィックとの競合のために使用可能なビットレートが本質的に可変のシステムでの使用に適している。例えば、本発明はＧＰＲＳ（一般パケットラジオサービス）または３Ｇネットワークを介したＰＤＡ（パーソナルデジタルアシスタント）などのハンドヘルドモバイル端末に対するマルチメディアストリーミングに適している。

圧縮およびフリークライアントソフトウェアの可用性の進展と相まって、ケーブルモデムおよびＡＤＳＬ（非対称デジタル加入者回線）モデムなどの新しいデータネットワークアクセス技術がインターネット上でのビデオストリーミングの成長を推進している。この技術の使用は飛躍的に伸び、６ヶ月ごとに規模はおそらく倍増し、２０００年には５億ストリームが供給されていると推測されている。しかしながら、ユーザのインターネットストリーミングに対する認識は依然として輻輳と大きな起動時遅延の経験に影響されている。

現在のＩＰネットワークは、そのすべてがエンドユーザによるマルチメディアコンテンツの享受を失わせる可能性がある、可変の達成可能スループットだけではなくパケット損失、遅延およびジッタ(jitter)（遅延変動）も示すためにビデオコンテンツのストリーミングには十分に適していない。

リアルタイムビデオアプリケーションはすべてのパケットがタイムリに到着することを必要とする。パケットが失われると、エンコーダとデコーダの間の同期は破壊され、しばらくの間エラーがレンダリングされたビデオを通して伝搬する。パケットが過剰に遅延すると、それらは、リアルタイムで動作しなければならないデコーダにとっては無用となり、損失として処理される。パケット損失、およびレンダリングされたビデオに対するこの視覚的な影響は、Ｈ．２６３などの予測ビデオコーディングシステムにおいて特に重大である。パケット損失の影響は、ビデオストリーム内にエラー保護を導入することにより削減できるが、排除することはできない。このような障害許容力（ｒｅｓｉｌｉｅｎｃｅ）技術は、パケット損失の影響を排除するのではなく、最小限に抑えることができるにすぎないことが分かっている。

スループットの長期的な低下を示すパケット損失が持続するケースでは、ストリーミングシステムはその長期の要件を削減できる必要がある。一般的には、これはストリーミングされた媒体のビットレートを削減しなければならないことを意味している。

Ｈ．２６３およびＭＰＥＧ−４などの標準的な圧縮技術は、その符号化速度を動的に変更することができるマルチメディアソースを提供するために管理できる。このような特性を持つビデオソースはここでは融通性のあるソース、つまりネットワークスループットにおいて長期の変動に適応することができるソースとして説明される。これは、一般的には連続的に適応可能なビデオビットレートを提供することにより達成される。これは、ビデオ圧縮規格が、音声コーデックとは異なり絶対動作ビットレートを明記していないため可能である。

ビデオストリーミングシステムは、ビットレートがクライアントのフィードバックに応えて瞬時に使用可能なネットワーク帯域幅に適応する場合に、ビットレートが変化する符号化されたストリームを提供するように設計されてよい。このようなシステムは、パケット損失が起きた場合に伝送速度が急激に減速し、他のときにはゆっくりと加速するように制御することによってネットワークフレンドリになるように作られるであろう。

しかしながら、この解決策は次の２つの理由から実践的ではない。第１に、リアルタイムビデオ符号化は通常大量の処理能力を必要とするため、このような解決策が多くのユーザをサポートするために縮小する(scaling)のを妨げる。第２に、エンドユーザの総体的な品質に対する認識は、瞬間的な品質の急激な変動によって悪影響を受けるであろう。

単向性のストリームアプリケーションの場合、送信者と受信者の間の遅延は起動時に認知できるにすぎない。したがって、一般的な技法はパケット損失とジッタと引き換えに遅延を得る。もしビデオストリームの平均スループット要件が使用可能な平均帯域幅に一致するのであれば、受信機のバッファサイズは遅延の予想される変動を包含する大きさにすることができる。

市場を先導するストリーミングシステムは、インターネットで遭遇する可能性のあるジッタの影響を削減するために、クライアント側でかなりのバッファリングを使用すると考えられている。これは役立つが、バッファが充填するにつれて、通常５秒から３０秒の間の大きな起動遅延も生じさせる。これらのシステムはクライアントが使用可能な帯域幅の変動に適応できるようにする技術も含む。これらの技法の詳細は公には利用可能ではないが、それらは一般的には単独ファイル内のマルチデータレート符号化（ＳＮＲスケラビリティ(scalability)）、および音声品質を維持するための映像ピクチャのサーバ側での縮小などのインテリジェント伝送技法を使用していると推測されている。これらの再送自体は同じネットワーク特性を条件とするが、このような大量のバッファリングによりかなりの割合のパケットを再送できると考えられるであろう。失われたデータを再送するという決定は、この要因および複数の他の要因を条件とする。一般的には、このような技法はユニキャスト(unicast)伝送にのみ適用できる。マルチキャスト(multicast)伝送システムには、通常フォワードエラーコレクションまたはＲＬＭとＲＬＣなどの受信機をベースにしたスケラビリティがさらによく役立っている。Ｓ．ＭｃＣａｎｎｅ、「受信機駆動式階層マルチキャスト（Receiver driven layered multicast）」、１９９６年８月カリフォルニア州スタンフォード（Ｓｔａｎｆｏｒｄ，ＣＡ）、ＳＩＧＣＯＭＭ９６の議事録。Ｌ．Ｖｉｃｉｓａｎｏ、Ｌ．ＲｉｚｚｏおよびＪ．Ｃｒｏｗｃｒｏｆｔ、「階層マルチキャストデータ転送のためのＴＣＰ状の輻輳制御（TCP-like congestion control for layered multicast data transfer）」、Ｉｎｆｏｃｏｍ、９８年。

前述されたようにバッファを使用すると、システムはパケットの損失およびジッタを克服できる。しかしながら、システムはネットワークから使用できるビットレートが不十分であるという問題を克服していない。ビデオ題材の長期平均ビットレート要件がネットワークから使用可能な平均ビットレートを超えると、クライアントバッファは最終的に空にされ、バッファが充填し直されるまでビデオレンダラ(video renderer)は停止する。使用可能なネットワークビットレートと、コンテンツが符号化された速度間の不一致の程度が、バッファを充填し直すための休止の頻度を決定する。

前述されたように、Ｈ．２６３とＭＰＥＧ−４を含む大部分のビデオ圧縮アルゴリズムは連続的に適応可能なビットレートを提供するために実現できる。しかしながら、ビデオと音声はいったん圧縮されると、それらは融通がきかなくなり、符号化されたビットレートで送信される必要がある。

ネットワークジッタおよびネットワークスループットの短期の変動は受信機でバッファを動作することにより吸収できるが、融通性はネットワークスループットの長期変動も吸収できるときにだけ達成される。

階層符号化は融通性のあるビデオソースを作成するための周知の技法である。階層ビデオ圧縮は、受信機での品質が、基本表現に順次追加されるより高い層の受信と復号により改善される階層的なコーディング方式を使用する。いかなる時点でも各クライアントは、ソースに対する現在のネットワーク接続性に応じて任意の数のこれらのビデオ層を受信してよい。その最も簡略な実施では、これはマルチキャストシナリオで有利であるネットワーク状態に粗粒(coarse-grain)適応を提供する。階層ビデオ圧縮は、ネットワーク状態に細粒(fine-grain)適応を加えるためにクライアントでのバッファリングとも組み合わされてきた。しかしながら、階層符号化技法が非効率的であり、通常、クライアントでかなり多くの処理を必要するようになり、処理能力が削減されている可能性のあるモバイルデバイスを対処するときに特定の問題を引き起こすことが示されている。

トランスコーディング(transcoding)は融通性のあるビデオソースを作成するための別の周知の技法である。ビデオトランスコーディングは計算の複雑性がビデオ符号化よりはるかに低くなるように設計できることが示されている。しかしながら、計算の複雑性は無視できないため、ビデオストリーミングのためのスケラブルアーキテクチャにつながらないであろう。

本発明の１つの態様によると、ストリーミングシステムのためのデータソースを格納するためのデータ構造が提供され、該データソースは複数の符号化されたデータストリームを含み、該複数のデータストリームのそれぞれは複数のデータストリームの他のストリームに対する異なる解像度で符号化されたデータソースからのデータの独立した表現であり、該データ構造はヘッダ、符号化されたデータストリームごとのストリームデータ構造、および符号化されたデータストリームの１以上のパケットを含み、ヘッダはストリームデータ構造の１つにリンクされ、各ストリームデータ構造はヘッダ、次のストリームデータ構造へのリンク、および符号化されたデータストリームの第１のパケットへのリンクを含む。

データ構造を使用するための適切なシステムおよび方法は以下に詳細に説明される。データ構造の複雑さは、潜在的に多くのストリームからパケットがインタリーブされる(interleaved)こと、および切り替えと回復をサポートするニーズの結果である。パケットからパケットへのナビゲーションは、一般的にはあるストリーム内で連続しているパケットはファイル内で隣接して記憶されないために、必然的にポインタによる。切り替えパケットおよび回復パケットを書き込むには、ソースパケットと宛て先パケットの正確な詳細が記録されることが必要になる。プレイバック中のストリーム間の切り替えには、第１に、「元（ｆｒｏｍ）」ストリームからの残りのパケットのプレイバック、切り替えパケットのプレイバックが後に続く次に使用可能な切り替えパケットの識別、それから適切な時点からの「先（ｔｏ）」ストリームからのパケットのプレイバックが必要になる。さらに、ストリーム間で切り替えるときには感知できるほどの遅延がないことが好ましい。

好ましくは、複数の符号化されたデータストリームはビデオデータストリームである。音声データはデータストリームとして符号化されてよい。

ビデオデータストリームおよび音声データストリームのためのストリームデータ構造は、それぞれのデータストリームのためのビットレート符号化データを含んでよい。

データソースは、ビデオデータストリームのあるストリームとビデオデータストリームの別のストリームの間の切り替えのために複数の切り替え点を画定する切り替えストリームをさらに含んでよく、切り替えデータストリームのためのデータストリーム構造は、ビデオストリーム上のデータと、先へのおよび元からの（ｔｏ ａｎｄ ｆｒｏｍ）切り替えが可能であるパケットを含む。

データ構造のヘッダは、最後のストリームデータ構造へのリンクを含んでよい。ストリームデータ構造のヘッダは、符号化されたデータストリームの最後のパケットへのリンクを含んでよい。

本発明は、変化するネットワーク状態に応じて圧縮されたビデオの伝送ビットレートを縮小すること(scaling)を可能にする。

説明されているシステムでは、生成された視聴覚ストリームは単一の固定されたビットレートで送信される必要はないため、データ構造はこれをサポートし、ネットワークが瞬時にサポートするどのような速度での伝送も可能にしなければならない。

システムおよびデータ構造は、申し分のないマルチメディア品質を提供するために、使用可能なネットワーク帯域幅を活用して、ＧＰＲＳネットワーク上でうまく機能することが示されてきた。

システムおよびデータ構造はＩＰネットワークの特性を克服し、特定のモバイルＩＰネットワークにおいては、ユーザに起動遅延が最小の、一貫した品質のマルチメディアを提供するように設計されてきた。

本発明の例はここで添付の図面を参照して詳しく説明される。

図１は、本発明の実施形態に使用するための視聴覚データストリーミングシステムの概略図である。

サーバ１０は、エンコーダ２０またはファイル３０のどちらかから直接的に符号化されたマルチメディアコンテンツを受信し、このコンテンツを１台以上のクライアント４０〜６０に供給する。サーバ１０は、それは、ただ順方向伝送のためのパケットを選択するような小さな処理を実行するだけなので数多くのコンテンツに独立してアクセスする多くのクライアント４０〜６０をサポートするために縮小する(scales)。サーバ１０では媒体の符号化またはトランスコーディングは実行されない。

原則的には、サーバ１０はエンコーダ２０から提供されるライブストリームと、ファイル３０からの事前に符号化されたストリームの両方について同じように動作する。この特定の実施形態では、ライブメディアのストリーミングが説明される。事前に符号化されたファイルから媒体をストリーミングする際の相違点は後半の実施形態で説明される。

サーバ１０は多くの循環するバッファ７０〜９０を含む。クライアント４０〜６０のそれぞれにパケット送信機１００の１つのインスタンスがある。パケット送信機１００は、いつ７０〜９０のどのバッファから次のパケットが読み取られるのかを決定し、選ばれたパケットを読み取り、それをネットワークコネクション１１０でそれぞれのクライアントに送信する。

送信されたほとんどすべてのパケットが受信されることを確実にするためには、やや信頼できる（ｓｅｍｉ−ｒｅｌｉａｂｌｅ）ネットワークコネクション１１０が、サーバ１０から各それぞれのクライアント４０〜６０に必要とされるため、ユーザによって認識される品質に対する障害を最小限に抑える。したがって、バッファ（１２０、１３０）は、失われたパケットの再送を可能とするためにネットワークコネクション１１０のそれぞれの端部で使用される。ネットワークコネクション１１０はネットワークフレンドリとなる、つまり輻輳が経験されないときには使用されるビットレートを加速し、輻輳が発生するときは劇的に減速できるようにすることも所望される。

システム構成要素は統合された構成要素と別々の構成要素の組み合わせとして例示され、説明されているが、異なる構成を使用できることが理解されるであろう。例えば、外部エンコーダ２０および／またはファイルストア３０が使用できるであろう。等しく、バッファ１３０はクライアントデバイス４０〜６０に一体化される可能性が高い。

図２は、図１のシステムで使用されるビデオ符号化階層の概略図である。エンコーダ２０は、融通性のある符号化された表現に、ライブのあるいは記憶されているマルチメディアコンテンツを符号化する。音声は低ビットレートで単一の符号化ビットストリームに符号化されるため、それ自体融通はきかない。しかしながら、通常、音声はビデオより小さいビットレートを必要とするため、ビデオが融通の利く様式で符号化されるのであれば、音声とビデオの組み合わされた符号化は融通性があると見なすことができる。

音声は、毎秒４．８ｋｂｉｔでＡＭＲ（適応マルチレート）エンコーダを使用して符号化される。ビデオは融通性のある表現に符号化される。階層化に類似した方法で、エンコーダ２０は独立したビデオストリームの階層を生成する。各ストリームに、階層の下の方のすべてのストリームに依存させることによってこの階層を構築する代わりに、それぞれのストリームは独立して符号化される。このような階層は周知であり、「サイマルキャスト(simulcast)」と呼ばれている。

音声データは低ビットレートＡＭＲ方式を使用して符号化されると説明されてきたが、他のＡＭＲ符号化速度、およびＭＰ３などの他の符号化規格もまたサポートできるであろう。多様な速度で符号化された音声は、各音声フレームは通常個別にコード化されるという事実から符号化された表現間の切り替えの簡略化は行われるが、ビデオについて後述されるのと類似した方法で独立したストリームの階層内に構築できるであろう。

ＩＴＵ−Ｔ規格Ｈ．２６３の拡張版を使用して作成されるビデオ階層は、ビデオストリームに対するランダムアクセスを可能にするための内部ストリーム２００、およびコンテンツの通常の表示のための１つ以上の再生ストリーム２１０ａ、２１０ｂを含む。各再生ストリーム２１０ａ、２１０ｂは異なるビットレートで符号化されるため、所与のクライアント４０〜６０がサーバ１０に対するこの現在のネットワークコネクション１１０に適切な速度で受信できるようにする。階層は、内部ストリーム２００から最低速度の再生ストリーム２１０ａへの、および再生ストリーム間の切り替えを可能にする切り替えストリーム２２０、２３０、２４０も含む。

符号化アルゴリズムは運動補償(motion-compensated)予測を利用するため、再生ストリームの中の任意の点でのビットストリーム間の切り替えは可能であるが、異なるビットストリームの同じ瞬間での再構築されたフレーム間の不一致のために視覚的なアーチファクト(artifacts)につながるであろう。視覚的なアーチファクトはそのうちにさらに伝搬するであろう。

現在のビデオ符号化規格では、ビットストリーム間の完全な（不一致のない）切り替えは、将来のフレーム／領域が現在の切り替えロケーションにとって過去の情報を全く使用しない位置、つまりアクセスピクチャでのみ可能である。さらに、アクセスピクチャを固定（例えば１秒）間隔で設置することにより、ランダムアクセスまたはビデオコンテンツをストリーミングするための「早送り」および「早戻し（Ｆａｓｔ Ｂａｃｋｗａｒｄ）」（加速されたプレイバック速度）などのＶＣＲ機能性が達成される。ユーザはビデオの一部をとばし、任意のアクセスピクチャロケーションで再生を開始できる。同様に、加速されたプレイバック速度、つまり早送りは、アクセスピクチャだけを送信することで達成できる。

しかしながら、アクセスピクチャが運動補償予測フレームより多くのビットを必要とすることは周知である。したがって、内部ストリーム２００および切り替えストリーム２２０、２３０、２４０が使用される。ストリームを切り替えることの主要な特性とは、異なる基準フレームが使用されていても、同一のピクチャを獲得できるという点である。

階層の主要な目的は、受信データのバッファをクライアント４０〜６０で構築し、パケット損失およびネットワークスループットの突然の低下に障害許容力(resilience)を提供することと、そのネットワークコネクション１１０が瞬時にサポートする最高のビットレートに応じてクライアント４０〜６０に最良の再生ストリーム２１０ａまたは２１０ｂを提供することの間で最適バランスを達成するために、サーバ１０が再生ストリーム２１０ａまたは２１０ｂをクライアント４０〜６０に送信できるようにすることである。

内部ストリーム２００は、ランダムアクセスおよび厳しいエラー状態からの回復を提供するために使用される一連の内部コード化ピクチャ（２０１、２０２）である。再生ストリーム２１０ａ、２１０ｂは双方向で予測されてよく、複数の基準ピクチャから予測されてよい予測コード化ピクチャ（２１１ａ、２１２ａ、２１３ａ、２１４ａ、２１５ａ；２１１ｂ、２１２ｂ、２１３ｂ、２１４ｂ、２１５ｂ）を含む。再生ストリーム２１０ａ、２１０ｂは、周期的なアクセスピクチャ２１６ａ、２１７ａ；２１６ｂ、２１７ｂも含む。切り替えストリーム２２０、２３０、２４０は一連のリンクピクチャ（２２１、２２２；２３１、２３２；２４１、２４２）から構成されている。

循環バッファ７０〜９２はストリーム型ごと、つまり各個のコンテンツについて、内部（７０）、再生（８０、８５）、および切り替え（９０、９１、９２）ストリームごとに１つ指定される。

クライアント４０が初めてサーバ１０に接続すると、サーバ１０は適切な内部ピクチャ（例えば内部ピクチャ２０１）の位置を、内部ストリームを記憶する循環バッファ７０から突き止め、これをクライアント４０に送信する。次に、サーバ１０は内部ストリーム２２０から最低の符号化ビットレートを有する再生ストリーム２１０ａに切り替えるためにリンクピクチャ（２２１）を選択し、その後、この再生ストリーム（２１３ａ以降）から供給し続ける。

クライアント４０へのパケットの伝送は１つの独立したプロセスであり、伝送の速度はネットワークの状態と使用される伝送プロトコルに依存する。しかしながら、初期には、伝送速度が、最低の符号化ビットレートを有する再生ストリーム２１０ａの符号化ビットレートより大きいことが意図されている。これにより、クライアント４０はその復号化バッファで余分な圧縮媒体データを蓄積できる一方で、クライアント４０は、データが受信され、復号された時点で即座にユーザに対して媒体の復号と提示を開始できるようになる。

（上記例ではアクセスピクチャ２１７ａなどの）アクセスピクチャの時点で、クライアント４０およびサーバ１０の少なくとも一方は、（例えばネットワーク容量の増加または減少のために）異なる再生ストリームがより適していると判断してよい。上記例では、低速度の再生ストリーム２１０ａからより高速の再生ストリーム２１０ｂへの切り替えは、サーバ１０がアクセスピクチャ２１７ａの代わりにリンクピクチャ２３２を送信することによって達成される。リンクピクチャ２３２は、さらに高速の再生ストリーム２１０ｂの再生ストリームピクチャ２１５ｂにリンクし、クライアント４０がその再生ストリームを受信できるようにする。減速したビットレートの再生ストリームへの切り替えは同様に達成される。

リンクピクチャを符号化する３つの方法が調査されてきた。それぞれの方法は、切り替えからのドリフトの蓄積、実際の切り替えのビットレート単位でのコスト、およびドリフトのない低ビットレート切り替えを可能にするタイプの規則正しいピクチャを符号化することにより生じる個々の再生ストリームの品質に対する影響の間で、異なる妥協案を提供する。

１．予測コード化リンクピクチャ
第１の方法では、リンクピクチャは予測されたピクチャとして生成される。それらは、宛て先再生ストリームの中の同時アクセスピクチャの再構築に対して、例えば小さな平均二乗差を有するという意味で、再構築時にそれらが類似するような方法でコード化される。アクセスピクチャは予測されたピクチャとしてコード化できる。リンクピクチャを符号化するために使用されるビット数は、再構築されたリンクピクチャが再構築されたアクセスピクチャに対してどの程度整合しているのかを判断し、切り替えの結果生じるドリフトの量を決定する。しかしながら、ドリフトは切り替えが発生するたびに蓄積する。

２．内部コード化リンクピクチャ
第２の方法では、リンクピクチャは内部ピクチャとして生成される。それらは、宛て先再生ストリームの中の同時アクセスピクチャの再構築に対して、例えば小さな平均二乗差を有するという意味で、再構築時にそれらが類似するような方法でコード化される。アクセスピクチャは予測されたピクチャとしてコード化できる。リンクピクチャを符号化するために使用されるビットの数が、再構築されたリンクピクチャが再構築されたアクセスピクチャに対してどの程度整合しているのかを判断し、切り替えの結果発生するであろうドリフトの量を決定する。しかしながら所与の量の不一致の場合、内部コード化リンクピクチャは、通常、予測コード化リンクピクチャより多くのビットを必要とするであろう。リンクピクチャのために内部コード化を使用すると、ドリフトの蓄積が妨げられる。

３．量子化ソースコード化リンクピクチャ
第３の方法では、リンクピクチャは、ここでは量子化ソースピクチャと呼ばれる、”ｆｔｐ：／／ｓｔａｎｄａｒｄ．ｐｉｃｔｅｌ．ｃｏｍ／ｖｉｄｅｏ−ｓｉｔｅ／”で入手可能な２００１年１月９日から１２日、ドイツ、ＥｉｂｓｅｅでのＩＴＵ−電気通信規格化セクタビデオコーディング専門家グループ（ＩＴＵ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）の第１２回会議でＭａｒｔａ ＫａｒｃｚｅｗｉｃｚおよびＲａｇｉｐ Ｋｕｒｃｅｒｅｎによって提出されたＶＣＥＧ−Ｌ２７、ＳＰフレームのための提案（ＶＣＥＧ−Ｌ２７、Ａ ｐｒｏｐｏｓａｌ ｆｏｒ ＳＰ−ｆｒａｍｅｓ）」にて説明された概念に基づいた技法でコード化される。

量子化ソースピクチャの符号化アーキテクチャは図３に示されている。ソースピクチャおよび運動補償予測は、同じ量子化器(quantiser)指数を用いてそれぞれステップ３００と３１０で個別に量子化され、ステップ３２０で減算される前に変換され、ステップ３３０で可変長符号化される。再構築されたピクチャは、ステップ３４０で減算器３２０の出力および量子化と変換３１０の出力を加算し、ステップ３５０で結果を逆変換、逆量子化することによって形成される。再構築されたピクチャはピクチャストア３６０に記憶される。その結果、再構築されたピクチャは単に量子化ソースピクチャにすぎず、運動補償予測とは無関係である。したがって、所与のソースピクチャは、異なる基準ピクチャから予測されるときに同一に再構築することができるため、ドリフトのない切り替えが可能になる。運動補償予測は、可変長符号化される信号のエントロピーを削減し、したがってピクチャを符号化することにより生成されるビット数を削減するため、関連性がない。

アクセスピクチャも、コーディングモード、内部または相互、および量子化器の選択でリンクピクチャと同一の選択を行うことにより、量子化ソースピクチャとしてコード化される。これにより、リンクピクチャが宛て先再生ストリームの中の同時アクセスピクチャに同一に再構築することが確実になる。

リンクピクチャを符号化するために必要とされるビット数は、対応するアクセスピクチャの符号化によって決定される。アクセスピクチャを符号化するために使用されるビット数は量子化がどのようにして実行されるのかに依存するが、一般的には予測ピクチャを符号化するために使用されるビット数より多く、内部ピクチャを符号化するために使用されるビットの数より少ない。これは、符号化が予測を使用するために内部符号化より効率的であるが、予測誤差の量子化のために通常の予測ほど効率的ではないためである。したがって、量子化ソースピクチャを使用すると、再生ストリームのより効率的ではない符号化を犠牲にするが、ドリフトのない切り替えが可能になる。

量子化ソースピクチャは、それらがＭＰＰＴＹＰＥの最初の３ビットを「１１０」という予約値に設定することにより予測されたピクチャと区別されるのを除き、予測されたピクチャと同じＨ．２６３構文で符号化される。

量子化ソースピクチャの周期的な符号化は、ピクチャの静止領域内でこう解（ｂｅａｔｉｎｇ）効果を生じさせることがある。これは以下のように説明される。通常の予測コーディングでは、ソースピクチャの妥当な表現としてすでに符号化されているピクチャの静止領域は修正されない。量子化ソースピクチャのこのような領域の符号化では、予測は量子化されなければならず、ピクチャの非静止領域に使用される量子化器指数で行われると、領域を変更させ、おそらくそれを悪化させるが、いずれにせよそれを変更する。この変更がこう解効果(beating effect)である。

これは、ピクチャのある領域の予測が十分に良好なソースの表現を提供するときには、情報を送信する必要はなく、したがって領域を変更する必要はないことを注目することによって克服される。したがって、アクセスピクチャが量子化ソースピクチャとして符号化されると、ピクチャが量子化ソースピクチャよりむしろ、予測ピクチャとして符号化されていた場合に領域についての情報が送信されたかどうかを判断するために試験が行われる。情報が送信されていなかった場合には、ステップ３００と３１０の量子化、およびステップ３５０の逆量子化により使用される量子化器指数は小さな値に設定され、通常予測誤差として知られている減算器３２０の出力はゼロに設定され、このようにして新規に再構築されたピクチャのこの領域は、細かい量子化器で量子化された過去の再構築ピクチャの対応する領域に等しくなる。Ｈ．２６３および他の規格では、量子化器指数の範囲は１（細かい）から３１（粗い）である。小さな指数とは、通常８以下の値を意味する。これは、送信されなければならない情報量を最小限に抑える一方で、再構築されたピクチャに対する不必要な変更を最小限に抑える。しかしながら、対応するリンクピクチャでのビットレートには、予測誤差がゼロとなる可能性が低いが、同じ細かい量子化器が使用されなければならないという犠牲(cost)がある。

図４は、図１のシステムでの使用に適したクライアント−サーバアーキテクチャの概略図である。

クライアント４０は、ネットワークバッファ１３０、復号バッファ４１、およびデコーダ４２を含む。サーバ１０は、前述されたように循環バッファ７０、８０、９０、およびクライアントごとにパケット送信機１００とネットワークバッファ１２０を含む。

クライアント４０は、サーバ１０にその復号バッファ４１内での情報量、およびそれがデータを受信する速度に関して知らせておく。サーバ１０はこの情報を使用して、再生ストリーム間でいつ切り替えるのかを決定する。例えば、クライアント４０が、その復号バッファ４１内で、例えばデータの１５秒など、データのしきい値より多く蓄積し、クライアント４０が階層内の次に高い再生ストリームの符号化速度以上の速度で受信しているとき、サーバ１０は次のリンクピクチャで次に高い再生ストリームに、クライアントのパケット送信機１００を切り替えることができる。

同様に、クライアント４０によりその復号バッファ４１内に蓄積されたデータ量がしきい値未満であるときには、サーバ１０は次のリンクピクチャでクライアントのパケット送信機１００を次に低い再生ストリームに切り替えることができる。

総体的な影響は、ネットワーク内での輻輳の状態に応じてネットワークフレンドリな様式で伝送速度は変化するが、クライアントの復号バッファ４１でのデータの蓄積のため、ユーザは伝送速度の短期変化の結果としての品質の変化を認識しないということである。ネットワークがこれを許可するときには品質の向上を可能にし、ネットワークスループットが低下するときには、プレゼンテーションを回避したり、ユーザに破壊した媒体を提示することなく品質を下げるために、異なる符号化速度を有するストリームに切り替えることにより、伝送速度のさらに長期の変化に対処する。

クライアントでの復号バッファ４１は、ユーザに提示される媒体の品質に関するネットワーク性能の変動の影響を削減するために使用される。バッファが処理するように設計されているネットワーク特性は、パケットジッタ、パケット損失および可変のスループットの３つのカテゴリに分類される。実際は、これらの３つのネットワーク特性は無関係ではなく、すべてがネットワーク輻輳に、またモバイルネットワークのケースでは物理層での劣化に結び付いている。

媒体符号化速度から伝送速度を切り離すことにより、クライアントの復号バッファ４１は、ネットワーク条件がそれほど良好ではないときのために障害許容力を与えるために、ネットワーク条件が好ましいときに充填できる。

復号バッファ４１に数十秒のデータを蓄積することで、同じ大きさのパケットジッタ（遅延変動）をユーザから隠すことができる。実際は、さらに大量のジッタは、後述されるエラー回復プロセスによって処理される一時的なコネクションドロップアウトとしてさらによく分類されるため、これはすべてのパケットジッタを隠す。

復号バッファ４１にデータを蓄積することにより、それが復号に必要とされる前に失われたパケットの再送に時間を使用できる。再び、多様な往復遅延より多くのデータを含む大きさにデコーダバッファ４１を作ることによって、パケット損失から回復するための少ない数の再送試行のための時間がある。これは、復号された媒体品質に影響を及ぼさずにパケット損失の大部分のインスタンス(instances)から回復することを可能にし、コネクションをやや信頼できるようにする。

最後に、再び復号バッファ４１にデータを蓄積することにより、クライアント４０は、受信ビットレートが符号化ビットレート未満であるときにしばらくの間、および受信速度がゼロに低下したときにしばらくの間、一貫した媒体品質を維持できる。

データは符号化レートには関係のない速度でクライアント４０にストリーミングされ、復号バッファ４１にバッファリングされるため、データの復号にとっては、単に可能な限り高速で復号し、提示するのではなく、むしろ正しく計時されることが必要である。タイムスタンプは、音声とビデオの同期のためだけではなく、この目的のためにも使用される。

ネットワーク変動のために、バイト単位で測定されるクライアントの復号バッファ４１内のデータの量は経時的に変化してよい。加えて、これが表現する媒体提示時間の長さという単位で測定される復号バッファ４１内のデータの量も経時的に変化するであろう。これにはライブコンテンツのストリーミングについて以下の含みがある。つまり、クライアント４０に送信される第１のデータが、それが捕捉、符号化された時点から最小の遅延で送信されると、復号バッファ４１の中にデータを構築することはできない。したがって、クライアント４０に送信される第１のデータは旧いデータ、つまりクライアント４０がサーバ１０に接続されるしばらく前に発生した事象を表すデータでなければならない。その結果、ユーザに提示される媒体は実際の発生時刻から一定に遅延したままであるが、復号バッファ４１が充填するにつれてこの中の最も新しいデータはますます新しくなる。

サーバは、クライアント４０がサーバ１０に接続するときに「旧い」データがクライアント４０にストリーミングするために使用できるように、符号化後の一定期間その循環バッファ７０、８０、９０に符号化データをバッファリングする。クライアントの復号バッファ４１が充填するにつれて、循環バッファ７０、８０、９０からの読み取り点はこれらのバッファ内の最新のデータにさらに近くなる。

循環バッファ７０、８０、９０およびクライアント復号バッファ４１の最適なサイジングは、それぞれが、これが表現する媒体提示時間という形で測定された同量のデータを包含できるようになるのが好ましい。

それぞれサーバ１０とクライアント４０の中のネットワークバッファ１２０、１３０は、やや信頼できるデータ接続を実現するトランスポートプロトコルによって使用される。通常、データは、このデータ、および初期のすべてのデータがクライアント４０で受信されたことが認知されるまで、サーバのネットワークバッファ１２０内に保持される。同様に、データは、このデータ、および初期のすべてのデータが無事に受信され、復号バッファ４１に渡されるとクライアントのネットワークバッファ１３０から削除されるであろう。その結果、サーバ１０は、各自のネットワークバッファ１２０内に残るデータを知ることにより、単向性伝送遅延により与えられる境界内でどのデータがクライアント４０によって無事に受信されたのかを知る。

これは、サーバ１０がクライアント４０によってどの程度のデータが受信されたのかを知り、その結果再生ストリーム間の切り替えについて決定を下すことができるためには、トランスポートプロトコル自体により必要とされるもの以上の、クライアント４０からサーバ１０へのフィードバックが必要とされていないことを暗示している。

クライアントの復号バッファ４１内にデータの蓄積が存在するということは、ジッタ、パケット損失および可変のスループットなどの多くのネットワークの欠陥に対する障害許容力を提供する。復号バッファ４１が媒体コンテンツ全体を包含する大きさに作られ、すべてのデータが受信されるまで提示が遅延されない限り、すべてのネットワーク欠陥から回復することが不可能であることは明らかである。このケースはストリーミングではなくダウンロードであるため、深刻なネットワーク欠陥から回復するための戦略が必要とされている。

ネットワークスループットが、かなりの長期間、最低速度の再生ストリームの符号化速度以下のレベルまで低下するときには、復号バッファ４１のデータ量は削減し、最終的にはゼロになるであろう。この時点でユーザへの提示は停止する。しかしながら、循環バッファ充填はサーバ１０で続行する。その結果、ネットワークが最低速度の再生ストリームの伝送が再び可能な状態に回復したときには、クライアント４０が必要とする次のデータは、それがより新しいデータで上書きされているであろうため、大抵サーバの循環バッファ７０、８０、９０内にはない。

この状況から回復するには、サーバ１０は、クライアントから新しい接続がなされたかのようにストリーミングを再開しなければならない。つまり、それは内部ストリーム内のある点を発見し、そこからストリーミングを開始し、次にリンクストリームを経て最低速度の再生ストリームに切り替わる。ユーザに関する影響は、復号バッファ４１が空になったときから、サーバが内部ストリームの送信を開始するときまでの媒体の損失であろう。

サーバ１０は、クライアントが復号を開始したとき、およびどの程度のデータが無事に受信されたのかを認識しているため、クライアントの復号バッファ４１が空になるのを認識するであろう。したがって、クライアントからの特定のメッセージを必要としなくても内部ストリームピクチャで再スタートすることができるであろう。しかしながら、例えばサーバおよびクライアント内での異なるクロック速度の影響から回復するためなど、システムに障害許容力を与えるためには、この状況でクライアント４０からサーバ１０に制御メッセージが送信される。

原則的には、ファイルからのストリーミングはライブストリーミングに同一である。実際には、それはいくぶん簡単である。データは必要に応じて、および必要とされるときにファイルから読み取ることができるため、循環バッファ７０、８０、９０に対するニーズはない。しかしながら、クライアント４０で復号バッファ４１を充填し、再生ストリーム間で切り替えるためにサーバ１０は同じ技法を使用する。復号バッファ４１が空になるケースでは、ネットワークスループットが再び十分になると提示を再開できるため、内部ストリームピクチャを有するコンテンツ内の後の点で再開する必要はない。ユーザは媒体が提示されない期間を認識するにすぎない。

早送り、早戻し、およびランダムアクセスなどのトリックモード(trick modes)は、内部ストリームを使用することで可能になる。

クライアントに対するストリーミング用のデータは常に入手可能となるため、上書きされる直前に循環バッファ７０、８０、９０内の「旧い」データをファイルに書き込むことによって、復号バッファ４１が空になり、ユーザが内部ストリームピクチャを用いた回復が発生するまでコンテンツを失うという前述された問題は回避できる。それは、循環バッファ７０、８０、９０からではなくむしろファイルから読み取られなければならない。

このような機能性により、クライアントは、不定期間、提示された媒体を休止し、後にストリーミングを続行することも可能になるであろう。それにより、ユーザはこのような休止の後に早送りをして、ライブストリームに追いつくこともできるであろう。

上述のクライアント−サーバアーキテクチャで試験されるトランスポートプロトコルの実施は、Ｙ．ＰｏｕｆｆａｒｙによるＲＦＣ−２１２６「ＴＣＰ上部でのＩＳＯトランスポートサービス（ＩＳＯ Ｔｒａｎｓｐｏｒｔ Ｓｅｒｖｉｃｅ ｏｎ ｔｏｐ ｏｆ ＴＣＰ（ＩＴＯＴ））」に詳説される、ＩＳＯ ＴＣＰトランスポートプロトコルＴＰＫＴに基づいている。

標準ＴＰＫＴプロトコルは図５ａに描かれている、ペイロードが後に続くヘッダを定義する。パケット長は、オクテット(octets)でのヘッダおよびペイロードの結合された長さを示している。

上述のシステムのために使用される実施では、ＴＰＫＴはペイロードが後に続くヘッダを有するために拡張され、その例は図５ｂに描かれている。パケット長はヘッダ、存在する場合はタイムスタンプ、およびペイロードのオクテットでの結合された長さを示している。Ｔはタイムスタンプが存在するかどうかを示すビットであり、Ｍはペイロードに音声情報が含まれているのか、あるいはビデオ情報が含まれているのかを示すビットである。

前述されたように、データの復号の正しいタイミングのためにはタイムスタンプが必要とされる。パケットヘッダに埋め込まれた情報はパケットの長さ、パケット内のデータのタイムスタンプ、およびストリーム識別子を含む。

ストリーム識別子は、音声およびビデオを単一のＴＣＰコネクションに多重化できるようにするために提供される。これは、音声伝送およびビデオ伝送の同期を確実にするためである。別々のＴＣＰコネクションが使用される場合、それらがネットワーク特性にわずかに異なって反応し、異なるスループットを達成することが可能であり、最終的には、クライアントの復号バッファ内に、提示時間という形で測定される大いに異なる量のデータを生じさせるであろう。これらの相違点は管理できるであろうが、単一のＴＣＰコネクションを使用し、音声およびビデオを近接パケット内の同じ提示時間で多重化することによって問題は完全に回避される。つまり、ビデオ専用システムに音声を追加するには、関連するビデオと同時に音声パケットを送信することが単純に必要となる。つまり更なる制御は必要とされない。

サーバ１０は可能な限り迅速にパケットを送信しようとする。最初は、多くのパケットはサーバのネットワークバッファ１２０内に蓄積するだけなので、それらはネットワークの容量に関係なく立て続けに送信される。ネットワークバッファ１２０がいっぱいになると、パケットをネットワークバッファ１２０に送信できる速度がネットワークでの伝送速度に一致し、伝送プロセスはソケット送信機能に対する呼を遮ることで制限される。

また、伝送速度は、クライアントでバッファリングされるデータ量が、例えば３０秒などのしきい値に達すると制限される。クライアントの復号バッファ４１がこれほど多くのデータを有すると、サーバ１０は充満のこのレベルを維持するために伝送速度を制限する。

ネットワークスループットはネットワークバッファ１２０に送信されたバイトを数え、ネットワークバッファのサイズをこれから減算し、伝送開始からの時間で除算することで推定される。ネットワークスループットのより短期間の推定値は、送信されるバイトの２回のカウントとこれらを送信するために要する時間の２回の測定を使用し、１つの組からスループットを計算し、次には周期的に切り替え、もはや使用されていない組をゼロにリセットすることによって計算される。例えば、リセットが２００秒ごとに発生する場合、ネットワークスループットは、リセット直後の２００秒から再びリセットする直前の４０秒に変化する期間で推定される。

この技法は、サーバ１０が可能な限り迅速にストリーミングしようと試みるならば申し分なく機能する。しかし、前述したように、復号バッファ４１内のデータ量がしきい値を超えると、サーバ１０は一定のバッファ充填を維持するためにその伝送速度を制限する。このケースでは、ネットワークスループットは現在の再生ストリームの符号化ビットレートとして推定されるであろう。この状態にあるとき、ネットワークは現在ストリーミングされている再生ストリームより高速の再生ストリームを送信できる可能性があるが、サーバ１０は、独自の速度制限のためにネットワークスループットの真の推定を行うことができないため切り替わらない。この状態から逃れるためには、サーバは周期的にクライアントの復号バッファの充填しきい値を無視し、所与の期間または所与のデータ量に対するフルレートでストリーミングする。サーバは、送信機能に対するブロックコールにより検出されるように、ネットワークバッファ１２０がいっぱいになると開始し、ネットワークバッファ１２０に送信されるバイト数、および要する時間を記録する。サーバは次に達成可能なスループットを推定し、これを使用してさらに高速の再生ストリームに切り替えるかどうかを決定する。

前述されたように、サーバ１０は、そのネットワークバッファ１２０内に保持されるデータを知っていることによって、どのデータがクライアント４０により受信され、その復号バッファ４１に送信されたのかを暗黙の内に知る。この情報は、次に再生ストリーム間でいつ切り替えるのか、およびいつエラー回復手順を呼び出すのかを決定するために使用できる。しかしながら、大部分のソケット実施での、コンテンツの可視性およびサーバのネットワークバッファ１２０の充満は、サポートされていない。ネットワークバッファ１２０のコンテンツを監視するためには、ミラーバッファ１２０ａが実現される。ミラーバッファ１２０ａはネットワークバッファ１２０に送信される実際のデータを記憶しないが、代わりにデータの送信されたバイト数とタイムスタンプだけを記憶する。ネットワークバッファ１２０のサイズを知り、それが常にいっぱいであると仮定するため、サーバ１０はミラーバッファ１２０ａを介して、クライアントの復号バッファ４１内での最新データのタイムスタンプとほぼ同じであるネットワークバッファ１２０内の最も古いデータのタイムスタンプにアクセスできる。

試験において、サーバ１０でのネットワークバッファ１２０が常にいっぱいであるという仮定がほとんどのときに正しいことが分かった。これは、伝送プロセスが可能な限り迅速にネットワークバッファ１２０に送信するように制御されるためである。主要な問題はオーバフローよりむしろクライアント４０でのデータの消耗と見られるため、ネットワークバッファ１２０がいっぱいでなくなると、ほとんどのケースでは安全であるクライアント４０でのデータの量を過小評価するという影響が出る。実際には、復号バッファ４１は、それが記憶するために必要とする最大量のデータを上回る大きさに作ることができる。いずれせよ、復号バッファ４１がいっぱいになると、クライアント４０は、次にサーバネットワークバッファ１２０が空になるのを停止するネットワークバッファ１３０からの読み出しを停止し、伝送が停止する。

クライアントの復号バッファ４１内の正確なデータ量を決定するために、サーバは、クライアントが現在復号し、提示しているデータパケットのタイムスタンプを知る必要もある。サーバ１０は、第１に、クライアント４０はサーバ１０が第１のパケットを送信した直後に復号を開始する、第２に、クライアントのクロックがストリーミング期間中サーバのクロックから大幅にドリフトしないという２つの仮定を使用してこれを計算する。

実際には、両方の仮定とも有効であることが判明している。クライアント４０はデータを受信すると即座に復号を開始するように設計されているため、サーバの推定提示時間でのどんな誤差も、前述されたように問題ではない復号バッファ４１でのデータ量の過小評価につながるであろう。通常のストリーミングセッション中のクライアントのクロックとサーバのクロックの間のドリフトは、バッファリングされているデータ量に比べれば大抵無視できる。例えば、１００万ごとに１００個のパーツという差異を用いると、１秒のドリフトが発生するには１００００秒、またはほぼ３時間を要するであろう。大量のドリフトが蓄積するという稀なケースでは、クライアント４０は、復号バッファアンダーフローのために送信される前述されたメッセージなどのような制御メッセージを使用することでサーバ１０に警告できる。

サーバ１０は当初、ネットワーク欠陥に障害許容力を与えるために復号バッファ４１内のデータのレベルも増強する一方で、クライアント４０が媒体を復号し、即座にユーザに提示できるようにするために最低ビットレートを有する再生ストリームをストリーミングする。ネットワークがより高速の再生ストリームの伝送をサポートするほど十分な容量を有する場合には、サーバ１０は、適切な瞬間にさらに高速の再生ストリームのストリーミングに切り替えるべきである。

より高速な再生ストリームにいつ切り替わるのかを決定するために使用できるであろう多くの可能な戦略がある。好ましくは、クライアント４０はその復号バッファ４１の中に、例えば１５秒などの所定の期間、媒体を復号、提示し続けることができるほど十分なデータを有する必要がある。また、好ましくは例えば最も最近の６０秒に測定された最近の過去に達成されたネットワークスループットが無限に切り替えられるためには再生ストリームのストリーミングを持続するほど十分でなければならない。つまり、最近達成されたネットワークスループット速度は再生ストリームのビットレート以上でなければならない。これは低い速度での不変の品質よりユーザにとってさらに鬱陶しい可能性があるため、目的はストリーム間の頻繁な切り替えを回避することである。

この目的を達成するために、切り下げ（ｓｗｉｔｃｈｉｎｇ ｄｏｗｎ）決定が切り上げ（ｓｗｉｔｃｈｉｎｇ ｕｐ）決定に相対的なヒステリシス(hysteresis)を含むことが好ましい。例えば、次に低いビットレートの再生ストリームへの切り下げは、クライアント４０がその復号バッファ４１内に例えば８秒などの特定期間、媒体を復号、提示し続けることができるほど十分なデータをもはや有さなくなると、引き起こすことができるであろう。３以上の再生ストリームを有する、現在ストリーミングされている再生ストリームが３番目、あるいはさらに高速の再生ストリームである構成の場合、この戦略は、アクセスピクチャが周期的に発生するだけのために階層の最下部までの即時低下は生じさせず、第２の切り下げが必要ではなくなるように、復号バッファの充満が第１の切り下げ後に回復することが期待される。

図６ａから図６ｃは、本発明の実施形態による視聴覚データソースを記憶するためのデータ構造の態様の概略図である。

図６ａに図示されている主要なデータ構造により、複数の音声再生ストリーム、内部ビデオストリーム、および複数のビデオ再生ストリームおよび切り替えストリームの単一のファイルでの記憶が可能になる。

本発明で作成、使用される視聴覚データソースは常にクライアントに送信できるであろう多くの符号化ストリームを有しているため、従来の連続のファイルでの記憶は不可能である。例えばビデオの場合、特定のソースピクチャは各再生ストリームにて符号化されてよく、内部ストリームおよび切り替えストリームのいくつかまたはすべてにて符号化されてもよい。

ファイルは、例が図６ａに描かれている、ストリームデータが後に続くデータ構造を含む。データ構造はストリームの数および型（音声、ビデオ、切り替え等）についての情報を含むヘッダ６００を含む。ストリームのそれぞれの型の最初のインスタンスおよび最後のインスタンスについて、それは、それぞれのストリームのヘッダに対する（ファイルの始まりからのオフセットとして表される）ポインタ６１０〜６８０も含む。

各ポインタ６２０〜６８０は、同型の次のストリームヘッダに対するポインタ７１０、それぞれストリームの最初のパケットと最後のパケットに対するポインタ７２０、７３０を含むストリームヘッダ７００を含むストリームデータ構造を指す。各ストリームタイプは特定のストリームヘッダタイプを使用するが、ある要素、つまり、ストリーム識別番号７０５、同タイプの次のストリームヘッダに対するポインタ７１０、およびそれぞれストリームの最初のパケットと最後のパケットに対するポインタ７２０、７３０はすべてのストリームヘッダタイプに共通である。これらの共通の要素だけを含む例のストリームヘッダは図６ｂに描かれている。再生ストリームヘッダおよび音声ストリームヘッダは、さらに、ストリームが符号化されたビットレート７４０も含む。切り替えストリームヘッダは切り替えストリームがそれとの間の切り替えを可能にする再生ストリームのストリーム識別子を含む。

各ストリームは、それぞれが、例が図６ｃに描かれているパケットデータ構造で表されるパケットのシーケンスから構成される。各パケットデータ構造はパケットヘッダ８００とペイロード８１０を含む。ヘッダは、ストリーム内の次のパケットに対するポインタ８０１、タイムスタンプ８０２、パケットシーケンス番号８０３、パケットサイズ８０４、およびフレーム番号８０５（つまり、おそらく他のパケットと一緒にパケットが表現するビデオピクチャまたは音声フレームのシーケンス番号）を含むデータを含んでいる。切り替えパケットは、さらに、それらが、ビットレート切り替えが発生できるようにする再生元（ｆｒｏｍ−Ｐｌａｙ）ストリームおよび再生先（ｔｏ−Ｐｌａｙ）ストリーム内のパケットのシーケンス番号も含む。切り替えストリームパケットヘッダは、実際には切り替え点を定め、切り替え前の「元（ｆｒｏｍ）」ストリームから再生される最後のパケット、および切り替え後の「先（ｔｏ）」ストリームから再生される最初のパケットのシーケンス番号を含む。シーケンス番号は０で始まり、決して負にならない。この方法はこの特定の実施形態では適用されていないが、切り替え時のストリーム間のナビゲーションを補助するポインタを使用することも可能である。

最後のストリームデータ構造および最後のパケットに対するポインタは、ファイル全体を検索しなくても、それらがファイルが拡張されなければならない点への即時アクセスを実現するので、ファイルに付加するときに有益である。

データ構造の複雑さは、インタリーブされている潜在的に多くのストリームからのパケットと、および切り替えと回復をサポートするニーズの結果である。パケットからパケットへのナビゲーションは、一般的にはあるストリーム内で連続しているパケットはファイル内で隣接して記憶されないために、必然的にポインタによる。切り替えパケットおよび回復パケットを書き込むには、ソースパケットと宛て先パケットの正確な詳細が記録されることが必要になる。プレイバック中のストリーム間の切り替えには、第１に、「元（ｆｒｏｍ）」ストリームからの残りのパケットのプレイバック、切り替えパケットのプレイバックが後に続く、次に使用可能な切り替えパケットの識別と、それから適切な時点からの「先（ｔｏ）」ストリームからのパケットのプレイバックが必要になる。さらに、ストリーム間で切り替えるときには感知できるほどの遅延があってはならない。

試験では、ファイルベースのストリーミングシナリオとライブストリーミングシナリオの両方が、ＢＴＣｅｌｌｎｅｔ（登録商標）ＧＰＲＳネットワークを使用して調査された。デスクトップＰｅｎｔｉｕｍ(ＴＭ) ＰＣがエンコーダとサーバを動作するために使用された。クライアントは、赤外線リンクを介してＭｏｔｏｒｏｌａ Ｔｉｍｅｐｏｒｔ（登録商標）ＧＰＲＳ携帯電話に接続されたＣｏｍｐａｑ ｉＰａｑ（登録商標）であった。

ビデオ専用構成では、２つの切り替えストリームが使用され、ビットレートは６ｋｂｉｔ／秒と１２ｋｂｉｔ／秒であった。

システムは予想されたとおりに機能した。伝送は内部ストリームで開始し、次にしばらく留まる６ｋｂｉｔ／秒の再生ストリームに切り替わり、６ｋｂｉｔ／秒より高速で実際に送信した結果としてクライアント内にデータを蓄積する。十分なデータが蓄積され、短期平均受信速度が１２ｋｂｉｔ／秒を超えると、伝送はさらに高速の再生ストリームに切り替わる。

長期に渡るセッションの間、ネットワークスループットが削減した結果、ときおり、より低速な再生ストリームへ切り替え復帰が発生する。そして、ネットワークがデータをクライアントに送達できないかなりの期間のために、非常にまれに、媒体提示は中断される。

総体的な影響は大部分のセッションに対してであり、ユーザは、品質はときおり変化するが、通常はビットエラーおよびパケット損失に結び付くタイプの歪みがない連続的な媒体提示を見ることができる。深刻なネットワーク欠陥およびスループットの損失の結果として見られる媒体提示の完全な停止は非常に稀にすぎない。

本発明に使用するための視聴覚データストリーミングシステムの概略図である。 図１のシステムで使用されるビデオ符号化階層の概略図である。 ビデオストリーム間での不一致のない切り替えを達成できるようにするビデオ符号化アーキテクチャの概略図である。 図１のシステムでの使用に適したクライアント−サーバアーキテクチャの概略図である。 図５ａは標準的なＴＫＰＴトランスポートパケット構造を描く図であり、図５ｂは図１のシステムのために実現されるＴＫＰＴトランスポートパケット構造の変形を描く図である。 図６ａ〜６ｃは、本発明の実施形態による視聴覚データストリームを含むデータ構造の態様を描く概略図である。

Claims (10)

1. ストリーミングシステムのデータソースを格納するデータ構造を用いた通信システムであって、前記データソースは複数の符号化されたデータストリームを含み、前記複数の符号化されたデータストリームの少なくとも幾つかの符号化されたデータストリームは、前記複数の符号化されたデータストリームの他の符号化されたデータストリームと異なる解像度で符号化されたデータソースからのデータの独立した表現であり、前記データ構造は、
   ヘッダ（６００）と、
   前記符号化されたデータストリームの各１つに関連付けられたストリームデータ部分と、
   前記符号化されたデータストリームの１以上のパケット（８００）と、
   前記ストリームデータ部分の１つへのリンク（６１０、６３０、６５０、６７０）と
   を含み、
   前記ストリームデータ部分はストリームヘッダ（７００）を含み、前記ストリームヘッダ（７００）は、次のストリームデータ部分への第１のリンク（７１０）と、前記符号化されたデータストリームの第１のパケットへの第２のリンク（７２０）とを含む、データ構造を用いた通信システム。
2. データストリームとして符号化された音声データを含む、請求項１に記載のデータ構造を用いた通信システム。
3. 前記複数の符号化されたデータストリームはビデオデータストリームである、請求項１に記載のデータ構造を用いた通信システム。
4. 前記データソースは、ビデオデータストリームのあるストリームとビデオデータストリームの別のストリームとの間の切り替えのために複数の切り替え点を定める切り替えデータストリームをさらに含み、前記切り替えデータストリームのための前記データストリーム部分は、ビデオデータストリーム上のデータと、先へのおよび元からの切り替えが可能であるパケットを含む、請求項３に記載のデータ構造を用いた通信システム。
5. 前記データ構造の前記ヘッダは、最後のストリームデータ部分への第３のリンク（６２０）を含む、請求項１乃至請求項４のいずれか１項に記載のデータ構造を用いた通信システム。
6. 前記ストリームデータ部分の前記ストリームヘッダ（７００）は、符号化されたデータストリームの最後のパケットへの第４のリンク（７３０）を含む、請求項１乃至請求項５のいずれか１項に記載のデータ構造を用いた通信システム。
7. ストリーミングシステムのデータソースを格納する方法であって、前記データソースは複数の符号化されたデータストリームを含み、
   前記複数の符号化されたデータストリームの少なくとも幾つかの符号化されたデータストリームが、前記複数の符号化されたデータストリームの他の符号化されたデータストリームと異なる解像度で符号化されたデータソースからのデータの独立した表現であることを特徴とし、
   前記方法は、
   ヘッダ（６００）と、
   前記符号化されたデータストリームの各１つに関連付けられたストリームデータ部分と、
   前記符号化されたデータストリームの１つ以上のパケット（８００）と、
   前記ストリームデータ部分の１つへのリンク（６１０、６３０、６５０、６７０）と
   を格納するステップを備え、
   前記ストリームデータ部分はストリームヘッダ（７００）を含み、前記ストリームヘッダは、
   次のストリームデータ部分への第１のリンク（７１０）と、
   前記符号化されたデータストリームの第１のパケットへの第２のリンク（７２０）と
   を含む、方法。
8. データストリームとして音声データを符号化するステップを含む、請求項７に記載の方法。
9. 前記複数の符号化されたデータストリームはビデオデータストリームである、請求項７に記載の方法。
10. ビデオデータストリームのあるストリームとビデオデータストリームの別のストリームとの間の切り替えのために複数の切り替え点を定める切り替えデータストリームを格納するステップをさらに備え、前記切り替えデータストリームのための前記ストリームデータ部分は、ビデオストリーム上のデータと、先へのおよび元からの切り替えが可能であるパケットを含む、請求項９に記載の方法。

Images