JP4426316B2 - データストリーミングシステムおよび方法 - Google Patents

Description

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

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

現在のＩＰネットワークは、そのすべてがエンドユーザによるマルチメディアコンテンツの享受を損なってしまうような、パケット損失、遅延およびジッタ（遅延変動）と同様に変わりやすい達成可能スループットを示すために、ビデオコンテンツのストリーミングには満足いくように適していない。

リアルタイムビデオアプリケーションはすべてのパケットがタイムリに到着することを必要とする。もし、パケットが失われたとすると、エンコーダとデコーダとの間の同期が崩され、しばらくの間はエラーが渡されたされたビデオを通して伝搬する。パケットが過度に遅延したとすると、それらのパケットは、リアルタイムで動作しなければならないデコーダにとっては無用となり、ロストとして処理される。パケット損失、および渡されたビデオに対するその視覚的な影響は、Ｈ．２６３などの予測ビデオコーディングシステムにおいて特に重大である。パケット損失の影響は、ビデオストリーム内にエラープロテクションを導入することにより低減することができるが、消去することはできない。このような回復技術はパケット損失の影響を消去するのではなく最小化することができるにすぎないということが分かっている。

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

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

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

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

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

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

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

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

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

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

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

本発明の一態様に従うと、複数の符号化されたデータストリームの１つをクライアント（４０、５０、６０）にストリームするために構成されたサーバ（１０）を備えるデータストリーミングシステムであって、前記複数のデータストリームのそれぞれがこれら複数のデータストリームの他のストリームに対して異なる分解能で符号化された共通のデータソースの独立した提示であり、前記サーバ（１０）が送信機（１００）と第１のバッファ（１２０）とを備え、前記送信機（１００）は、前記第１のバッファ（１２０）を介して前記クライアント（４０、５０、６０）に前記符号化されたデータストリームのデータパケットを送信するとともに、前記クライアント（４０、５０、６０）による前記パケットの受信の確認応答に基づいて前記第１のバッファ（１２０）からデータパケットを除去するために構成されており、前記送信機（１００）は前記クライアント（４０、５０、６０）においてバッファされるデータのコンテンツによって示される再生時間を推定するとともに、前記推定される再生時間が所定の基準を満足する場合に前記複数のデータストリームの別のストリームを送信するために切り替えるように構成され、前記送信機（１００）は前記第１のバッファ（１２０）のコンテンツを監視するとともに、前記推定される再生時間は前記第１のバッファ（１２０）から除去される最新のデータパケット及び前記送信機によってなされる推定に従って前記クライアント（４０、５０、６０）によって復号されるパケット数から判定される、データストリーミングシステムが提供される。

全体的なシステムの重要な属性のいくつかは以下のとおりである。

・ネットワークフレンドリに伝送レートを変更させること、
・媒体符号化レートから送信レートを切り離すこと、
・起動遅延を招くことなく、クライアントにおいてデータのバッファを構築すること、
・クライアントバッファリングを使用することによりネットワークスループットの短期変動を平滑化すること、
・様々なビットレートで符号化されたマルチメディアストリームの間で切り替えることによってネットワークで使用可能な資源に適合するように長期平均帯域幅要件を調整すること、および
・クライアントバッファリングを使用することによりユーザによって認知される品質に影響を及ぼすことなく、失われたパケットを選択的に再送することによりパケット損失に対する回復を提供することである。

本発明は、変動するネットワーク状態に依存して圧縮ビデオの伝送ビットレートをスケーリングすることを可能にする。

本発明では、生成された音声−視覚ストリームは単一の固定ビットレートで送信される必要がないため、ネットワークが瞬時にサポートするどのようなレートでも伝送を可能にする。伝送損失に対する回復は、それが復号および提示に必要とされる前に再送すべき失われたデータについての時間を与えるために、受信機にデータのバッファを構築することによって提供される。

つねに、このようなストリームの階層からの１つのビデオストリームと１つの音声ストリームがクライアントに送信される。これはコース−グレイン（ｃｏａｒｓｅ−ｇｒａｉｎ）適応性のためのいわゆる「サイマルキャスト（同時放送）切り替え」とファイン−グレイン（ｆｉｎｅ−ｇｒａｉｎ）適応のための伝送レートの変動の組み合わせの形態で実現される。

このシステムは、満足の行くマルチメディア品質を提供するために使用可能なネットワーク帯域幅を活用して、ＧＰＲＳネットワーク上でよく働くことが示されている。

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

前記送信機は前記第１のバッファのコンテンツから前記クライアントにおいてバッファされるデータ量を判定するために構成されていてもよく、前記所定の基準は前記クライアントにおいてバッファすべく判定されるデータの所定のレベルを含む。前記データパケットは前記クライアントから前記パケットの受信の確認応答に基づいて、前記第１のバッファから除去されるようにしてもよい。前記送信機は前記第１のバッファから除去された最新のデータパケット、および前記クライアントによって復号されるパケット数の推定値に応じて前記クライアントにおいてバッファされるデータの量を判定するために構成されていてもよい。

前記第１のバッファは該第１のバッファ内のパケットにデータを格納するミラーバッファを含んでいてもよく、前記送信機は該ミラーバッファ内のデータを使用して前記第１のバッファのコンテンツを監視するために構成されている。

データパケットが拡張ＴＰＫＴプロトコルを使用して前記クライアントに送信されるようにしてもよく、該データパケットは復号タイムスタンプとデータストリーム識別子を収納するヘッダを含んでいる。

このシステムは、それぞれがそれぞれの所定の基準に依存して決定される複数のデータストリームの１つを送信するためにそれぞれの第１のバッファを介してそれぞれのクライアントと通信する複数の送信機をさらに備えていてもよい。

前記データストリームは符号化されたビデオデータであってもよい。

前記送信機は、データパケットの送信の内部で音声パケットとビデオパケットとを多重化するために構成されていてもよい。隣接する音声パケットとビデオパケットとは実質的に同時に提示することが意図される音声情報とビデオ情報とを提示してもよい。

前記データストリームは、符号化された音声データであってもよい。

前記分解能は、データの符号化ビットレートであってもよい。

前記サーバは、データフィードを受け入れるとともに、該データフィードを複数の符号化されたデータストリームの中に符号化するために構成されたエンコーダを含んでいてもよい。

このシステムは複数のバッファをさらに備えていてもよく、前記エンコーダは該複数のバッファのそれぞれのバッファに各符号化データストリームを出力するために構成され、前記送信機は該複数のバッファのそのそれぞれのバッファからのそれぞれのデータストリームについてのデータパケットを取得するために構成されている。

前記サーバは複数の符号化されたデータストリームを格納するファイルソースを含んでいてもよい。

本発明の別の態様に従うと、クライアントおよびサーバを備えるデータストリーミングシステムが提供され、前記サーバは複数の符号化されたデータストリームの１つを前記クライアントにストリームするために構成され、該複数のデータストリームのそれぞれは該複数のデータストリームの他方に対して異なる分解能で符号化された共通のデータソースの独立した提示であり、前記サーバは送信機と第１のバッファを備え、前記クライアントは受信側バッファを含み、該送信機は該第１のバッファを介して前記クライアントに符号化されたデータストリームのデータパケットを送信するために構成され、前記クライアントは前記受信側バッファに受信されたデータパケットを格納し、前記サーバに受信を確認応答するために構成され、前記送信機は受信の確認応答が受け取られると前記第１のバッファからパケットを削除するために構成され、前記サーバは所定の基準が満たされると該複数のデータストリームの別のストリームに切り替えるために構成され、該所定の基準が前記第１のバッファのコンテンツに基づく分析を備える。

前記パケットはパケットシーケンスデータを含んでいてもよく、前記クライアントは該シーケンスデータに基づいて受信されていないパケットの再送を要求するために構成され、前記サーバは再送要求に基づいて前記第１のバッファからパケットを再送するために構成されている。

本発明のさらなる態様に従うと、それぞれが複数のデータストリームの他のストリームに対して異なる分解能で符号化された共通データストリームの独立した提示である複数の符号化されたデータストリームの１つをクライアントにストリーミングする方法が提供され、該方法は、
第１のバッファを介して符号化されたデータストリームのデータパケットを前記クライアントに送信する工程と、
前記第１のバッファのコンテンツを監視する工程と、および
所定の基準が前記第１のバッファから検出された場合に、前記複数のデータストリームの別のストリームを送信するために切り替える工程と、を備える。

前記複数のデータストリームはそれぞれ異なるビットレートで符号化されていてもよく、前記方法はさらに最低ビットレートデータストリームのデータパケットを初めに送信する工程を備える。

前記所定の基準は前記クライアントにおいてバッファすべく判定されたデータの量を含んでいてもよい。

前記所定の基準は１つまたは複数のネットワークスループットしきい値を含んでいてもよい。

ネットワークスループットは、
前記第１のバッファに渡されるバイト数を数える工程と、
前記第１のバッファのサイズから数えられたバイト数を減算する工程と、および
送信の開始以来の時間で前記減算の結果を除算する工程と、によって計算されるようにしてもよい。

前記方法は、スループット変動を求めるために、１つ以上のインターバルに渡ってネットワークを測定する工程をさらに備えていてもよい。

前記所定の基準は、前記複数のデータストリームの他のストリームを持続するために十分なネットワークスループットの決定を含んでいてもよい。

前記方法は、前記クライアントにおいてバッファされるデータの量に関係なく、最大レートでデータを送信する工程をさらに備えていてもよく、前記所定の基準は前記最大レートで決定されるネットワークスループットを含む。

前記データストリームは、前記データストリーム内の過去のピクチャに依存して予測的に符号化される一連のピクチャとして符号化されていてもよく、前記データストリームはピクチャの連続の中の所定の期間に散在する量子化されたソースアクセスピクチャを含み、前記量子化されたソースアクセスピクチャを符号化する方法は、
予測されるピクチャとしてピクチャを符号化する工程と、および
ピクチャの領域についての情報が前記符号化された予測ピクチャに示されていない場合、前記量子化されたソースアクセスピクチャとして符号化するときに量子化器指数を細かい量子化の値に設定する工程と、を含む。

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

図１は本発明の実施形態による音声−視覚データストリーミングシステムの概略図である。

サーバ１０は、エンコーダ２０またはファイル３０のどちらかから直接的に符号化されたマルチメディアコンテンツを受信し、このコンテンツを１台または複数台のクライアント４０〜６０に供給する。サーバ１０は、それが、前進伝送についてパケットを正しく選択するといった小さな処理を実行するので、独立して多くの個数のコンテンツにアクセスする多くのクライアント４０〜６０をサポートすることを縮小する。サーバ１０では、媒体の符号化またはトランスコーディングは実行されない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６ａ〜図６ｃは、本発明での使用に適した音声−視覚データソースを格納するためのデータ構造の態様の概略図である。

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

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

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

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

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

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

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

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

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

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

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

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

本発明の実施形態による音声−視覚データストリーミングシステムの概略図である。 図１のシステムで使用されるビデオ符号化階層の概略図である。 達成されるビデオストリーム間での不一致がない切り替えを可能にするビデオ符号化アーキテクチャの概略図である。 図１のシステムで使用するのに適したクライアント−サーバアーキテクチャの概略図である。 標準ＴＫＰＴトランスポートパケット構造を描く図である。 本発明のために実現されるその構造の変形を描く図である。 本発明で使用するためのデータを格納するために適した音声−視覚データストリームを備えるデータ構造の態様を描く概略図である。 本発明で使用するためのデータを格納するために適した音声−視覚データストリームを備えるデータ構造の態様を描く概略図である。 本発明で使用するためのデータを格納するために適した音声−視覚データストリームを備えるデータ構造の態様を描く概略図である。

Claims (3)

1. 複数の符号化されたデータストリームの１つを、ネットワークを介してサーバに接続されたクライアントにストリームするために構成された前記サーバを備えるデータストリーミングシステムであって、前記複数のデータストリームのそれぞれがこれら複数のデータストリームの他のストリームに対して異なる分解能で符号化された共通のデータソースの独立した提示であり、前記サーバが、
   送信機と、
   前記送信機に接続された第１のバッファとを備え、
   前記送信機は、前記第１のバッファを介して前記クライアントに前記符号化されたデータストリームのデータパケットを送信するとともに、前記クライアントによる前記パケットの受信の確認応答に基づいて前記第１のバッファからデータパケットを除去するために構成されており、
   前記サーバは、前記第１のバッファのコンテンツを監視するとともに、前記第１のバッファのサイズ、前記クライアントによるデータの復号の正しいタイミングのために必要とされる前記第１のバッファから除去された最新のデータパケットのヘッダ内のタイムスタンプ、前記第１のバッファ内の前記データストリームコンテンツの分解能、および前記クライアントにおいて復号されるパケット数の推定値に基づいて前記クライアントにおいてバッファされるデータのコンテンツによって示される再生時間を推定するように構成され、
   前記送信機は、前記推定される再生時間が第１の所定のしきい値を上回った場合により高い分解能を有する、前記複数のデータストリーム中の別のストリームを送信するために切り替え、前記推定される再生時間が第２の所定のしきい値を下回った場合により低い分解能を有する、前記複数のデータストリーム中の別のストリームを送信するために切り替えるようにさらに構成される、データストリーミングシステム。
2. 前記第１のバッファは、該第１のバッファ内のパケットにデータを格納するミラーバッファを含み、前記送信機は、前記ミラーバッファ内のデータを使用して該第１のバッファの前記コンテンツを監視するために構成される、請求項１に記載のシステム。
3. 前記データストリームは符号化されたビデオデータである、請求項１または２に記載のシステム。

Images