リアルタイムデータの送信および受信
【課題】パケットネットワークにおいて、流されたビデオデータを見るためにデータの蓄積器が設けられ、データのパケットの相互到着時間の変化によって引き起こされるジッターの影響を減少させる。
【解決手段】ビデオビューワがデータを消費するより急速にビデオストリーマ２からビデオビューワへデータを送信し、ビデオビューワにバッファを設けるため余分なデータを使用することにより、始動遅れなしに流されたビデオを提供する。適当な大きさのバッファが設けられるとき、バッファへのデータの送信レートは減少するかもしれない。利用可能な帯域幅の最良品質のデータを配達するために、ビデオデータの供給は、蓄積器が満たされるとき、高いビットレートソースに切り換えられる。
【解決手段】ビデオビューワがデータを消費するより急速にビデオストリーマ２からビデオビューワへデータを送信し、ビデオビューワにバッファを設けるため余分なデータを使用することにより、始動遅れなしに流されたビデオを提供する。適当な大きさのバッファが設けられるとき、バッファへのデータの送信レートは減少するかもしれない。利用可能な帯域幅の最良品質のデータを配達するために、ビデオデータの供給は、蓄積器が満たされるとき、高いビットレートソースに切り換えられる。
【発明の詳細な説明】
【技術分野】
【０００１】
発明はパケット交換ネットワーク上の時間に敏感なデータの取り扱いの分野であって、特にインターネット上のビデオデータを送信および受信することに関する。
【０００２】
発明はパケットネットワークを横切って顧客にビデオサービスの流れを提供するとともに、バッファの使用を維持している間にデータのバッファを準備することに通常関連づけられる始動遅れを減少させる方法に関連する。発明はまた、ネットワークで渋滞に順応するためビデオの流れの送信レートを制御する方法に関連する。
【背景技術】
【０００３】
伝統的に、インターネットはFTP、電子メール、およびウェブサーフィンなどのトラフィックを支持し、そこでは、全体の遅れはメディアの最終的なプレゼンテーションを本質的に損なわれない。より速い処理マルチメディアPCの到来はインターネット上にビデオを含むマルチメディアの配送を駆り立てた。しかしながら、時間に敏感なアプリケーションは、保証されたサービスの連続した質、高い帯域幅データチャンネルを必要とし、それは表面上インターネットのパケットベースの特質と相容れず、容認できないパケットジッター、即ち可変ルーティングによって引き起こされたパケットの相互到着時間の変化、および渋滞のために配送率の可変性により送信を中断する可能性を持っている。現在、商業ストリーミング技術は、再生ビデオデータの始まる前に大きいバッファ(5-30秒)を構成することによりジッターを克服した。この始動遅れはユーザにとって非最適であり、要求されたコンテンツが不正確であることがわかる前にユーザはこの期間を待たねばならないかもしれず、一般に、マルチメディアプレゼンテーションのユーザ経験を損ねる。
【発明の概要】
【０００４】
本発明の第１の態様によると、リアルタイムのデータ送信器と、記憶装置を持っているリアルタイムのデータディスプレイ装置と、前記送信器および前記ディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を操作する方法が提供され、前記方法は以下のステップを含む：
リアルタイムのプレゼンテーションの第1の部分を表すデータパケットを複数の第１のコード化レートで前記ディスプレイ装置に送信するように前記送信器を操作し、送信レートが前記コード化レートより高くされ；
前記ディスプレイ装置は、
前記第１のコード化レートのデータパケットを前記記憶装置に受信し、
第１のレベルの品質で前記ユーザに前記リアルタイムのプレゼンテーションを表示するようにデコードするため、前記第１のコード化レートで前記記憶装置からの第１のコード化レートのデータパケットを移転し、
前記第１のコード化レートのデータで予定されたレベルに満たされる前記記憶装置において、前記レベルが到達した指示を前記送信器に送るように操作され、
前記指示を受けて、前記送信器は前記リアルタイムのプレゼンテーションのその後の部分を表している第２のコード化レートでデータパケットを前記ディスプレイ装置に送るように操作され、前記第２のコード化レートは前記第１のコード化レートより高くされ；
前記ディスプレイ装置は、
リアルタイムのプレゼンテーションのその後の部分を表す第２のコード化レートのデータパケットを前記記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイムのプレゼンテーションを前記ユーザに表示するようにデコードするために、前記第２のコード化レートで前記記憶装置から第２のコード化レートのデータパケットを移転するように操作される。
【０００５】
本発明の別の態様によると、時間に敏感なデータのバッファを構成して顧客に時間に敏感なデータを提供する方法が提供され、前記方法は、前記顧客に送られた時間に敏感なデータを受信し、前記時間に敏感なデータをデータバッファに送ることと、データバッファにある時間に敏感なデータの質を監視することと、見るために処理されるべきデータバッファの前記時間に依存したデータを読み出すこととを含み、方法は、時間に敏感なデータがデータバッファから読み出されるレートが時間に敏感なデータがデータバッファに送られるレートよりも低く、顧客が時間に敏感なデータを受け取り、時間に敏感なデータを利用可能にする間の遅れが実質的にないように、データがデータバッファに到着するとき時間に敏感なデータがデータバッファから読み出される、時間に敏感なデータを提示することを特徴とする。
【０００６】
データバッファが十分に満たされるようになる時点が来るであろう。そのとき送信のレートは、見る手段による消費のレートに等しいように減少され、バッファの中のデータの量は均衡にされるであろう。しかしながら、この状況では、接続の帯域幅は完全な容量で使われないかもしれない。
【０００７】
本発明のさらに別の態様において、顧客に時間に敏感なデータを提示する方法が提供され、ここに、コード化された時間に敏感なデータは、予定された量のデータがデータバッファを満たすまで、第１のビットレートで受信され、そのあとコード化された時間に敏感なデータは第２のビットレートで受信され、ここに第２のビットレートは第１のビットレートよりも高い。
【０００８】
本発明のさらに別の態様は、顧客へ時間に敏感なデータを提供する方法を提供し、ここに第１のビットレートでコード化された時間に敏感なデータは顧客に送信されるべき第１の送信レートで第１のデータバッファから読み出され、要求のあったときに、第２のビットレートでコード化された時間に敏感なデータは第２のレートで第２のデータバッファから読み出される。
【０００９】
ビデオデータのより高いビットレートでより良い質の再現をもたらすために、データを送信するためにできるだけ多くの利用可能なリンクの帯域幅を使用することが望ましい。しかしながら、ネットワークのデータの損失は、増加するビットレートの利益をはるかに追い越して、サービスの厳しい低下をもたらす。例えば、H.263およびMPEGなどの予測コード構成で、500kbits-1のビデオストリームの半分を受信することは、250のkbits-1のストリームのすべてよりはるかに悪い品質を与えそうである。したがって、ネットワークでデータを失わせるよりむしろ、制御された方法で送信レートを下げることが重要である。インターネットプロトコルTCPには、パケット損失が検出されるまでデータ送信レートを着実に増加させ、そのあとにデータレートを減少する組み込まれた制御メカニズムがある
。その後データレートはパケット損失が再び起るまで増加される。可変送信レートは弾力性があると言われ、ネットワーク状態に対応してデータの送信レートを制御することができるアプリケーションはTCPフレンドリイであると言われている。TCPフレンドリイな方法によるビデオデータを提供し、それによりどんな特定の時にも利用可能な帯域幅の多くが利用されることが望ましい。TCPフレンドリイなデータ配送のさらなる利点は、それぞれが帯域幅の正当な分け前をもつまで、個々のアプリケーション自体がデータレートを減少させるようにネットワークにおける渋滞が管理されるということである。
【００１０】
MPEG4またはH.263などの標準の圧縮技術はTCPフレンドリイなふるまいを示すように管理することができ、例えば出願人の係属中の出願番号GB9928023.2を参照されたい。しかしながら、この解決策はビデオストリームあたり高速で、専用のPCを必要とする。また、ネットワーク渋滞が探知されるとき、高いビットレートから低ビットレートまでのコード化されたデータストリームを完全にコード化することは計算上必要とされる問題に悩まされる。品質の適合はビデオストリームの層（layer）を加えるか、または落とすことによって達成されるので、ビデオストリームを層にする使用には別のアプローチがある。この方法の不都合は、利用可能な帯域幅のある割合が層を統合するための指示に割り当てられなければならないので効率が悪いということである。
【００１１】
本発明はさらに、時間に敏感なデータが第１および第２のバッファから読みだされるレートが顧客へのリンクの状態に依存してダイナミックに変えられる方法を提供し、さらに顧客へのリンクの状態に依存して、第１のビットレートでコード化された時間に敏感なデータが顧客に送信された第１の送信レートで第１のデータバッファから読み出され、または第２のビットレートでコード化された時間に敏感なデータが第２のレートで第２のデータバッファから読み出され、ここに前記第１のビットレートは第２のビットレートよりも低い。
【００１２】
発明の実施例が例示だけの方法で図を参照して説明される。
【図面の簡単な説明】
【００１３】
【図１】エンコーダと、ビデオストリーマおよび顧客間の関係の概要の概観である。
【図２】ビデオストリーマ配列を示す。
【図３】顧客の配列を示す。
【図４】本発明の1実施例のステップ的操作を示す。
【発明を実施するための形態】
【００１４】
図1に示されるように、本発明の第１の実施例は圧縮されたビデオデータのソース、エンコーダ1を含み、それは例えば500kbits-1の値を有する低いビットレート RLおよび例えば1500kbits-1の高いビットレートRHの両方のデータをコード化する。使用される圧縮コーデックはH.263であるが、等しくMPEG4などのいかなる他のコーデックであってもよい。エンコーダ1はその入力として、例えば、スポーツイベントの放送のような“生”ビデオデータを取る。
【００１５】
2つのコード化されたデータストリームが別々の論理的な接続を通して送信レートTEでビデオストリーマ2へ送信される。ビデオストリーマ2はエンコーダ1と同じ構内にあり、イントラネットを通して結合されるかもしれない。ビデオストリーマ2は、例えばインターネットにアクセスを有するペンティアム（登録商標）III 700MHz、256MB RAMを含むサーバコンピュータで実行する。
【００１６】
これまで顧客と呼ばれたビデオビューワは、インターネットにアクセスを持つために適当に構成されるPC(図1の3a、3b、3cなど)で実行し、インターネットを通してビデオストリーマ2に接続し、その結果、顧客はコンテンツにアクセスすることができる。適当なPC端末は266MHzペンティアム（登録商標）IIラップトップPCである。ビデオストリーマ2は、同じストリームを見る多くの顧客(最大通常1000)を支持することができる。
【００１７】
生放送のために、エンコーダ1はリアルタイムである送信レートTEで送信するであろう。異なるビットレートでコード化されたデータRLとRHの2つのストリームは異なる質のビデオ再現を提供するが、各データストリームは同じ送信レートTEを有する。データはリアルタイムで再生するプログラムためこのレートでデコードされなければならない。
【００１８】
図2はビデオストリーマ2の配列を示す。エンコーダ1から低いビットレートRLでコード化された低い質のコード化ビデオデータ、および高いビットレートRHでコード化された高い質のコード化ビデオデータが、それぞれ入力接続21および22で受け取られ、それぞれバッファ23および24に供給される。ビデオストリーマ2によって受け取られるコード化されたビデオデータのチャンネルあたり1つのバッファが提供されることに注意すべきである。コード化されたビデオデータは選択するスイッチ26を通して各バッファ23、24から読みだされ、コード化されたビデオデータストリームは出力接続27に送られることになっている。データが各バッファ23、24から読みだされるレートを制御することができるバッファマネージャ25が設けられ、その結果ビデオストリーマ2の送信レートTSを定義することができる。バッファマネージャはまたスイッチ26に接続され、かつさらに接続28から信号を受信することができる。TSがエンコーダ送信レートTEよりも小さく、等しく、または大きくすることができるように、TSはそれぞれのパケットの送信の間で時間の遅れを変えることにより選択される。技術に熟練した者は、S kbitsのサイズのバッファがS/2 kbitsのサイズのバッファの2倍長い間TS＝2TEの送信レートを維持することができるように、TS>TEである送信の持続性の制限要因が、バッファ23、24のサイズであることを理解するであろう。スイッチ26と送信レートTSの両方のコントロールを通して、バッファマネージャは2つのスケールでビデオストリーマ2から出力されるビットレートを制御することができ、送信レートTSを調整することによってビットレートの微制御を達成し、ビットレートRLおよびRHでコード化された2つのコード化されたデータストリーム間を切り換えることによって、粗スケールにおけるビットレートの制御を達成する。バッファマネージャ25はTSへの調整を行い、または接続28から受信される信号に対応してバッファの間の出力を切り換える。
【００１９】
図3はPC3a、3b、3cなどで実行している顧客の配列を示す。ビデオストリーマ2から送られるコード化されたビデオデータは、接続27を通して顧客に受け取られ、パケット損失検出器31によって完全性をチェックされる。そして、データはネットワークスループットにおける変動を吸収するために適当なサイズである顧客バッファ32に送られる。顧客バッファ32はデコーダ33に直接接続され、そこからデコードされたデータは顧客スクリーン(示されない)に表示されるために送られる。顧客状態モニター34はパケット損失検出器31と顧客バッファ32に接続される。顧客状態モニター34は接続28を通して信号を送ることができる。
【００２０】
パケット損失検出器31は入って来るパケットを監視する。パケット損失が検出されるなら、その時信号が顧客状態モニター34に送られ、それは接続28を通してビデオストリーマ2のバッファマネージャに知らせる。欠けているパケットを再送することができる。最大の帯域幅が利用されていることを示しているパケット損失の一貫したパターンが起こるまで、バッファマネージャ25は送信レートTSを着実に増加させる。渋滞のないネットワークを維持するために、送信レートTSは指数関数的に減少されるかもしれない。顧客バッファ32がデータで十分いっぱいになるとき、信号は接続28を通してビデオストリーマ2のバッファマネージャ25に送られるように、顧客状態モニター34が顧客バッファ32のデータ量を監視する。
【００２１】
上で説明したように、ビデオストリーマ2と顧客3のシステムはユーザフレンドリーなビデオの流れを許容し、即ち、顧客バッファ32はネットワーク状態の変化にもかかわらず、ビデオの品質をエネーブルにし、それはそうでなければメディアの総合的な知覚された品質に有害な影響を与えたかもしれない。
【００２２】
発明のこの実施例の動作は図4を参照して記述される。
【００２３】
ビデオストリーマ2が初期化され、それはエンコーダ1からのデータの量によりバッファ23、24を満たすことを含む。生放送のため、データは絶えずバッファ23、24に供給され、次に、バッファのサイズと受け取られるデータの質によって定義される時間量の後に捨てられる。
【００２４】
インターネットでウェブページをブラウズするためにブラウザソフトウェアを実行するPCは、例えば、流されたビデオを提供する実体によってホストされたサイトの生放送へのリンクを選択するために使用されているかもしれない。特定のクリップまたは放送を見ることに関心があると、ユーザはリンクをクリックする(選択する)。ブラウジングソフトウェアは、流されたビデオデータが要求されていたことを検出して、顧客3を具体化する顧客ソフトウェアを見てビデオを発送する。顧客3は接続28を経てバッファマネージャ25へ“send data”命令を発行し、バッファマネージャは低いビットレートデータバッファ23からのコード化されたビデオデータを読み出し、かつTS=2TEの送信レートを要求するようにスイッチ26を設定する。データはデータ接続27、そしてそこから顧客3に送られる。RLとして500kbits-1以上を引用されたビットレートでコード化する例を使用すると、
データは1000kbits-1のレートで顧客へネットワーク内を流れる。
【００２５】
顧客3はコード化されたビデオデータを受信し、それをパケット損失検出器31を通してレート2TEで供給される顧客バッファ32に送る。データがバッファ32に検出されるとき、コード化されたビデオデータはTEのレートで即座にデコーダ33に読みだされる。したがって、バッファ32はレートTEで満たされ、その間デコーダ33からのデコードされたデータが表示される。したがって、ユーザは顧客バッファ32が満たされるまで待つ必要はなくビデオ画像を提供される。
【００２６】
顧客モニター34は顧客バッファ32のRLデータの量が指定されたレベルに達するまで待っており、それ以上になると“switch buffer”命令を接続28を通してビデオストリーマ2のバッファマネージャ25に送る。バッファマネージャ25はそのとき、データの流れを低いビットレートのデータバッファ23から高いビットレートのデータバッファ24へ切り換えて、レートTS＝TEで送信を指示する。上で引用されたレートでコード化する例を使用すると、データは1500kbits-1でネットワークに送信される。
【００２７】
顧客バッファ32はそのとき高い質のデータで満たされ始め、それは低い質のデータの後ろに置かれるであろう。時間の長さの後に、RHデータがデコーダ33に読み取られ始めると、ユーザは画質の増加を知覚するであろう。このポイントについて、顧客3は十分なバッファを有し、ユーザはネットワークリンクの容量と一致した品質の画像を見守っている。
【００２８】
ビデオストリーマ2は多くの顧客(通常1000)を支持することができる。各顧客は初めに、始動フェーズのためのユニークな読み取りポイントを与えられ、そうすると、顧客バッファ32の均衡が達せられた後、ビデオストリーマ2がバッファ24から高いビットレートデータを供給し、読み取りポイントが他の顧客読み取りポイントと融合されることができる。読み取りポイントは、特定の顧客のために送信レートを増加するか、または減少させるかを要求されたネットワーク容量における不一致として委ねなくてはならないかもしれない。
【００２９】
熟練した者は、低いビットレートのデータバッファ23が、データの適当な量を顧客バッファ32に提供するに十分長い期間の間、2TEのレートでデータをバッファ23から読み出すことを許容するサイズのものであるべきであることを認識するであろう。例えば、バッファのために5秒が顧客3で500kbits-1データの価値があるとすると、ビデオストリーマ2は5秒間にデータの1000kbitsを供給しなければならず、その500kbitsは1秒あたりのデコーダ33によって消費され、500kbitsは5秒が経過するまで、1秒あたりバッファの中で増すであろう。したがって、低いビットレートのデータバッファは少なくとも5Mbitsのデータ(5x1000kbits)、または0.5Mbのすぐ上に保持できるに違いない。
【００３０】
熟練した者は、データがバッファから初めに読みだされるとき、コード化されたデータのストリームの“盗聴”と関連づけられた問題があると認識するであろう。エンコーダ1によって通常使われる圧縮技術は、アンカーフレームまたはＩ-フレームと呼ばれるビデオデータのフレームをコード化することを含み、このフレームから次のフレームが似ていることとして推定がなされ、推定されたフレームはB-フレームと呼ばれる。このように、一連のフレームを表すデータの量は大いに減少するかもしれない。しかしながら、データバッファ23、24のどちらかから読み出されるべき第１のフレームがB-フレームであるならば、デコードされたデータの第１の数フレームが推定に基づくフレームを再構成しようとするとき、デコーダとして難解であるかもしれない。発明のさらなる実施例では、データの余分なバッファが単にI-フレームからなるデータバッファ23、24と平行して供給される。送信されるべき第１のフレームがl-フレームバッファから読まれて、その結果、そこからデコードし始める信頼できるポイントをデコーダに与える。そして、データはデータバッファ23、24のどちらかから読み出されるように切り換えられる。
【００３１】
システムはユーザフレンドリーなビデオの流れを許容し、即ち、メディアの総合的な知覚された品質に有害な影響を及ぼすネットワーク状態変化の際に、ビデオの品質は急速に変動しない。顧客によって報告されるパケットの損失の場合に、システムはその送信レートを指数関数的に減少させることができる。顧客でバッファされるデータがあるとき、これはビデオソースの即座の切り換えをもたらす必要はない。パケットの損失の直後に、送信レートがコード化レートよりも低くなることが可能であり、ビデオデコーダの需要にこたえるために顧客がバッファされたデータで受信されたデータを補っているので、結果として顧客のバッファは空になる。孤立されたパケットの損失の場合、システムは、結局はバッファを満たす状態に戻る前に、初めに顧客のバッファが空になっているレートを遅く
して、再び送信レートを立ち上げることができる。
【００３２】
熟練した者は、しばらくは可変レートでデータを送信する能力が、流されたデータを弾性的にすることを可能にし、TCPフレンドリイな送信を許容することを認識するであろう。パケット損失検出器31による持続しているパケットの損失の検出はネットワーク渋滞を暗示している。ビデオストリーマ2のバッファマネージャ25は、高いビットレートデータバッファ24からのデータの送信レートの減少を指示することにより、パケットの損失の通知に反応する。高いビットレートデータバッファ24は、そのような出来事に対処するために適切な大きさにされるべきである。高いビットレートのデータバッファが支えることができるより長い間、減少された送信レートでパケットの損失が持続するなら、バッファマネージャ25は、低いビットレートのデータバッファ23からデータを供給するために切り換わるであろう。これは再生ビデオの知覚された品質の変化を引き起こすので、有効な管理プロトコルがネットワーク変動のデータ容量としてデータバッファ23および24間の急速な切り換えを防ぐ必要がある。ユーザが低い質の再生を許容する間、品質における急速な変化はユーザにとっていらだたしい場合がある。
【００３３】
ビデオストリーマに供給されるコード化されたデータストリームの数にはどんな制限もない。最大の帯域幅利用は、低いビットレートデータバッファからデータを読むことにより始まって、送信レートが増加されるようにして達成される。この送信レートでどんなパケットも失われないことの発見で、出力はより高いビットレートデータバッファに切り換えられ、そうすると送信レートが増加される。この送信レートがどんな障害にも遭遇しないならば、もっと高いビットレートのデータバッファが切り換えられ、そして、最大の帯域幅が採用されるまで続く。
【００３４】
ビデオストリーマ2に位置するバッファマネージャ25は、送信レートTSをどのように調整するか、およびいつバッファを切り換えるかを決めることが可能にされる。同様に、送信レートTSとどのバッファからデータを供給するかに関して顧客3からビデオストリーマ2へ指示が送られる。この場合ISPであるサービスについて請求に応答可能であるセンターの近くにコントロールセンターを位置させるのが実用的であるので、記述された実施例のバッファマネージャ25の位置は選択された。
【００３５】
ビデオデータの例は、上の実施例を例証するためにマルチメディアデータの例として選ばれる。発明は同様に、オーディオデータやマルチメディアプレゼンテーションなどの時間に敏感なデータのいかなる他の形にも適合する。
【００３６】
上記実施例において、データはエンコーダ1によって供給される。同様に、圧縮されたビデオデータはプログラムデータファイルのライブラリ、例えば呼び物フィルムのライブラリに保持され、必要なときにアクセスされるかもしれない。
【００３７】
ビデオストリーマ2とエンコーダ1はインターネットを通して接続されるように、ビデオストリーマ2がエンコーダ1から離れていてもよい。ビデオストリーマ2がインターネットサービスプロバイダ(ISP)により操作され、ビデオストリーマ2とエンコーダ1のと遠隔接続は、ISPが多くのエンコーダから顧客にコンテンツを利用可能にすることを許容するであろう。
【符号の説明】
【００３８】
１…エンコーダ ２…ビデオストリーマ ３…顧客
【技術分野】
【０００１】
発明はパケット交換ネットワーク上の時間に敏感なデータの取り扱いの分野であって、特にインターネット上のビデオデータを送信および受信することに関する。
【０００２】
発明はパケットネットワークを横切って顧客にビデオサービスの流れを提供するとともに、バッファの使用を維持している間にデータのバッファを準備することに通常関連づけられる始動遅れを減少させる方法に関連する。発明はまた、ネットワークで渋滞に順応するためビデオの流れの送信レートを制御する方法に関連する。
【背景技術】
【０００３】
伝統的に、インターネットはFTP、電子メール、およびウェブサーフィンなどのトラフィックを支持し、そこでは、全体の遅れはメディアの最終的なプレゼンテーションを本質的に損なわれない。より速い処理マルチメディアPCの到来はインターネット上にビデオを含むマルチメディアの配送を駆り立てた。しかしながら、時間に敏感なアプリケーションは、保証されたサービスの連続した質、高い帯域幅データチャンネルを必要とし、それは表面上インターネットのパケットベースの特質と相容れず、容認できないパケットジッター、即ち可変ルーティングによって引き起こされたパケットの相互到着時間の変化、および渋滞のために配送率の可変性により送信を中断する可能性を持っている。現在、商業ストリーミング技術は、再生ビデオデータの始まる前に大きいバッファ(5-30秒)を構成することによりジッターを克服した。この始動遅れはユーザにとって非最適であり、要求されたコンテンツが不正確であることがわかる前にユーザはこの期間を待たねばならないかもしれず、一般に、マルチメディアプレゼンテーションのユーザ経験を損ねる。
【発明の概要】
【０００４】
本発明の第１の態様によると、リアルタイムのデータ送信器と、記憶装置を持っているリアルタイムのデータディスプレイ装置と、前記送信器および前記ディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を操作する方法が提供され、前記方法は以下のステップを含む：
リアルタイムのプレゼンテーションの第1の部分を表すデータパケットを複数の第１のコード化レートで前記ディスプレイ装置に送信するように前記送信器を操作し、送信レートが前記コード化レートより高くされ；
前記ディスプレイ装置は、
前記第１のコード化レートのデータパケットを前記記憶装置に受信し、
第１のレベルの品質で前記ユーザに前記リアルタイムのプレゼンテーションを表示するようにデコードするため、前記第１のコード化レートで前記記憶装置からの第１のコード化レートのデータパケットを移転し、
前記第１のコード化レートのデータで予定されたレベルに満たされる前記記憶装置において、前記レベルが到達した指示を前記送信器に送るように操作され、
前記指示を受けて、前記送信器は前記リアルタイムのプレゼンテーションのその後の部分を表している第２のコード化レートでデータパケットを前記ディスプレイ装置に送るように操作され、前記第２のコード化レートは前記第１のコード化レートより高くされ；
前記ディスプレイ装置は、
リアルタイムのプレゼンテーションのその後の部分を表す第２のコード化レートのデータパケットを前記記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイムのプレゼンテーションを前記ユーザに表示するようにデコードするために、前記第２のコード化レートで前記記憶装置から第２のコード化レートのデータパケットを移転するように操作される。
【０００５】
本発明の別の態様によると、時間に敏感なデータのバッファを構成して顧客に時間に敏感なデータを提供する方法が提供され、前記方法は、前記顧客に送られた時間に敏感なデータを受信し、前記時間に敏感なデータをデータバッファに送ることと、データバッファにある時間に敏感なデータの質を監視することと、見るために処理されるべきデータバッファの前記時間に依存したデータを読み出すこととを含み、方法は、時間に敏感なデータがデータバッファから読み出されるレートが時間に敏感なデータがデータバッファに送られるレートよりも低く、顧客が時間に敏感なデータを受け取り、時間に敏感なデータを利用可能にする間の遅れが実質的にないように、データがデータバッファに到着するとき時間に敏感なデータがデータバッファから読み出される、時間に敏感なデータを提示することを特徴とする。
【０００６】
データバッファが十分に満たされるようになる時点が来るであろう。そのとき送信のレートは、見る手段による消費のレートに等しいように減少され、バッファの中のデータの量は均衡にされるであろう。しかしながら、この状況では、接続の帯域幅は完全な容量で使われないかもしれない。
【０００７】
本発明のさらに別の態様において、顧客に時間に敏感なデータを提示する方法が提供され、ここに、コード化された時間に敏感なデータは、予定された量のデータがデータバッファを満たすまで、第１のビットレートで受信され、そのあとコード化された時間に敏感なデータは第２のビットレートで受信され、ここに第２のビットレートは第１のビットレートよりも高い。
【０００８】
本発明のさらに別の態様は、顧客へ時間に敏感なデータを提供する方法を提供し、ここに第１のビットレートでコード化された時間に敏感なデータは顧客に送信されるべき第１の送信レートで第１のデータバッファから読み出され、要求のあったときに、第２のビットレートでコード化された時間に敏感なデータは第２のレートで第２のデータバッファから読み出される。
【０００９】
ビデオデータのより高いビットレートでより良い質の再現をもたらすために、データを送信するためにできるだけ多くの利用可能なリンクの帯域幅を使用することが望ましい。しかしながら、ネットワークのデータの損失は、増加するビットレートの利益をはるかに追い越して、サービスの厳しい低下をもたらす。例えば、H.263およびMPEGなどの予測コード構成で、500kbits-1のビデオストリームの半分を受信することは、250のkbits-1のストリームのすべてよりはるかに悪い品質を与えそうである。したがって、ネットワークでデータを失わせるよりむしろ、制御された方法で送信レートを下げることが重要である。インターネットプロトコルTCPには、パケット損失が検出されるまでデータ送信レートを着実に増加させ、そのあとにデータレートを減少する組み込まれた制御メカニズムがある
。その後データレートはパケット損失が再び起るまで増加される。可変送信レートは弾力性があると言われ、ネットワーク状態に対応してデータの送信レートを制御することができるアプリケーションはTCPフレンドリイであると言われている。TCPフレンドリイな方法によるビデオデータを提供し、それによりどんな特定の時にも利用可能な帯域幅の多くが利用されることが望ましい。TCPフレンドリイなデータ配送のさらなる利点は、それぞれが帯域幅の正当な分け前をもつまで、個々のアプリケーション自体がデータレートを減少させるようにネットワークにおける渋滞が管理されるということである。
【００１０】
MPEG4またはH.263などの標準の圧縮技術はTCPフレンドリイなふるまいを示すように管理することができ、例えば出願人の係属中の出願番号GB9928023.2を参照されたい。しかしながら、この解決策はビデオストリームあたり高速で、専用のPCを必要とする。また、ネットワーク渋滞が探知されるとき、高いビットレートから低ビットレートまでのコード化されたデータストリームを完全にコード化することは計算上必要とされる問題に悩まされる。品質の適合はビデオストリームの層（layer）を加えるか、または落とすことによって達成されるので、ビデオストリームを層にする使用には別のアプローチがある。この方法の不都合は、利用可能な帯域幅のある割合が層を統合するための指示に割り当てられなければならないので効率が悪いということである。
【００１１】
本発明はさらに、時間に敏感なデータが第１および第２のバッファから読みだされるレートが顧客へのリンクの状態に依存してダイナミックに変えられる方法を提供し、さらに顧客へのリンクの状態に依存して、第１のビットレートでコード化された時間に敏感なデータが顧客に送信された第１の送信レートで第１のデータバッファから読み出され、または第２のビットレートでコード化された時間に敏感なデータが第２のレートで第２のデータバッファから読み出され、ここに前記第１のビットレートは第２のビットレートよりも低い。
【００１２】
発明の実施例が例示だけの方法で図を参照して説明される。
【図面の簡単な説明】
【００１３】
【図１】エンコーダと、ビデオストリーマおよび顧客間の関係の概要の概観である。
【図２】ビデオストリーマ配列を示す。
【図３】顧客の配列を示す。
【図４】本発明の1実施例のステップ的操作を示す。
【発明を実施するための形態】
【００１４】
図1に示されるように、本発明の第１の実施例は圧縮されたビデオデータのソース、エンコーダ1を含み、それは例えば500kbits-1の値を有する低いビットレート RLおよび例えば1500kbits-1の高いビットレートRHの両方のデータをコード化する。使用される圧縮コーデックはH.263であるが、等しくMPEG4などのいかなる他のコーデックであってもよい。エンコーダ1はその入力として、例えば、スポーツイベントの放送のような“生”ビデオデータを取る。
【００１５】
2つのコード化されたデータストリームが別々の論理的な接続を通して送信レートTEでビデオストリーマ2へ送信される。ビデオストリーマ2はエンコーダ1と同じ構内にあり、イントラネットを通して結合されるかもしれない。ビデオストリーマ2は、例えばインターネットにアクセスを有するペンティアム（登録商標）III 700MHz、256MB RAMを含むサーバコンピュータで実行する。
【００１６】
これまで顧客と呼ばれたビデオビューワは、インターネットにアクセスを持つために適当に構成されるPC(図1の3a、3b、3cなど)で実行し、インターネットを通してビデオストリーマ2に接続し、その結果、顧客はコンテンツにアクセスすることができる。適当なPC端末は266MHzペンティアム（登録商標）IIラップトップPCである。ビデオストリーマ2は、同じストリームを見る多くの顧客(最大通常1000)を支持することができる。
【００１７】
生放送のために、エンコーダ1はリアルタイムである送信レートTEで送信するであろう。異なるビットレートでコード化されたデータRLとRHの2つのストリームは異なる質のビデオ再現を提供するが、各データストリームは同じ送信レートTEを有する。データはリアルタイムで再生するプログラムためこのレートでデコードされなければならない。
【００１８】
図2はビデオストリーマ2の配列を示す。エンコーダ1から低いビットレートRLでコード化された低い質のコード化ビデオデータ、および高いビットレートRHでコード化された高い質のコード化ビデオデータが、それぞれ入力接続21および22で受け取られ、それぞれバッファ23および24に供給される。ビデオストリーマ2によって受け取られるコード化されたビデオデータのチャンネルあたり1つのバッファが提供されることに注意すべきである。コード化されたビデオデータは選択するスイッチ26を通して各バッファ23、24から読みだされ、コード化されたビデオデータストリームは出力接続27に送られることになっている。データが各バッファ23、24から読みだされるレートを制御することができるバッファマネージャ25が設けられ、その結果ビデオストリーマ2の送信レートTSを定義することができる。バッファマネージャはまたスイッチ26に接続され、かつさらに接続28から信号を受信することができる。TSがエンコーダ送信レートTEよりも小さく、等しく、または大きくすることができるように、TSはそれぞれのパケットの送信の間で時間の遅れを変えることにより選択される。技術に熟練した者は、S kbitsのサイズのバッファがS/2 kbitsのサイズのバッファの2倍長い間TS＝2TEの送信レートを維持することができるように、TS>TEである送信の持続性の制限要因が、バッファ23、24のサイズであることを理解するであろう。スイッチ26と送信レートTSの両方のコントロールを通して、バッファマネージャは2つのスケールでビデオストリーマ2から出力されるビットレートを制御することができ、送信レートTSを調整することによってビットレートの微制御を達成し、ビットレートRLおよびRHでコード化された2つのコード化されたデータストリーム間を切り換えることによって、粗スケールにおけるビットレートの制御を達成する。バッファマネージャ25はTSへの調整を行い、または接続28から受信される信号に対応してバッファの間の出力を切り換える。
【００１９】
図3はPC3a、3b、3cなどで実行している顧客の配列を示す。ビデオストリーマ2から送られるコード化されたビデオデータは、接続27を通して顧客に受け取られ、パケット損失検出器31によって完全性をチェックされる。そして、データはネットワークスループットにおける変動を吸収するために適当なサイズである顧客バッファ32に送られる。顧客バッファ32はデコーダ33に直接接続され、そこからデコードされたデータは顧客スクリーン(示されない)に表示されるために送られる。顧客状態モニター34はパケット損失検出器31と顧客バッファ32に接続される。顧客状態モニター34は接続28を通して信号を送ることができる。
【００２０】
パケット損失検出器31は入って来るパケットを監視する。パケット損失が検出されるなら、その時信号が顧客状態モニター34に送られ、それは接続28を通してビデオストリーマ2のバッファマネージャに知らせる。欠けているパケットを再送することができる。最大の帯域幅が利用されていることを示しているパケット損失の一貫したパターンが起こるまで、バッファマネージャ25は送信レートTSを着実に増加させる。渋滞のないネットワークを維持するために、送信レートTSは指数関数的に減少されるかもしれない。顧客バッファ32がデータで十分いっぱいになるとき、信号は接続28を通してビデオストリーマ2のバッファマネージャ25に送られるように、顧客状態モニター34が顧客バッファ32のデータ量を監視する。
【００２１】
上で説明したように、ビデオストリーマ2と顧客3のシステムはユーザフレンドリーなビデオの流れを許容し、即ち、顧客バッファ32はネットワーク状態の変化にもかかわらず、ビデオの品質をエネーブルにし、それはそうでなければメディアの総合的な知覚された品質に有害な影響を与えたかもしれない。
【００２２】
発明のこの実施例の動作は図4を参照して記述される。
【００２３】
ビデオストリーマ2が初期化され、それはエンコーダ1からのデータの量によりバッファ23、24を満たすことを含む。生放送のため、データは絶えずバッファ23、24に供給され、次に、バッファのサイズと受け取られるデータの質によって定義される時間量の後に捨てられる。
【００２４】
インターネットでウェブページをブラウズするためにブラウザソフトウェアを実行するPCは、例えば、流されたビデオを提供する実体によってホストされたサイトの生放送へのリンクを選択するために使用されているかもしれない。特定のクリップまたは放送を見ることに関心があると、ユーザはリンクをクリックする(選択する)。ブラウジングソフトウェアは、流されたビデオデータが要求されていたことを検出して、顧客3を具体化する顧客ソフトウェアを見てビデオを発送する。顧客3は接続28を経てバッファマネージャ25へ“send data”命令を発行し、バッファマネージャは低いビットレートデータバッファ23からのコード化されたビデオデータを読み出し、かつTS=2TEの送信レートを要求するようにスイッチ26を設定する。データはデータ接続27、そしてそこから顧客3に送られる。RLとして500kbits-1以上を引用されたビットレートでコード化する例を使用すると、
データは1000kbits-1のレートで顧客へネットワーク内を流れる。
【００２５】
顧客3はコード化されたビデオデータを受信し、それをパケット損失検出器31を通してレート2TEで供給される顧客バッファ32に送る。データがバッファ32に検出されるとき、コード化されたビデオデータはTEのレートで即座にデコーダ33に読みだされる。したがって、バッファ32はレートTEで満たされ、その間デコーダ33からのデコードされたデータが表示される。したがって、ユーザは顧客バッファ32が満たされるまで待つ必要はなくビデオ画像を提供される。
【００２６】
顧客モニター34は顧客バッファ32のRLデータの量が指定されたレベルに達するまで待っており、それ以上になると“switch buffer”命令を接続28を通してビデオストリーマ2のバッファマネージャ25に送る。バッファマネージャ25はそのとき、データの流れを低いビットレートのデータバッファ23から高いビットレートのデータバッファ24へ切り換えて、レートTS＝TEで送信を指示する。上で引用されたレートでコード化する例を使用すると、データは1500kbits-1でネットワークに送信される。
【００２７】
顧客バッファ32はそのとき高い質のデータで満たされ始め、それは低い質のデータの後ろに置かれるであろう。時間の長さの後に、RHデータがデコーダ33に読み取られ始めると、ユーザは画質の増加を知覚するであろう。このポイントについて、顧客3は十分なバッファを有し、ユーザはネットワークリンクの容量と一致した品質の画像を見守っている。
【００２８】
ビデオストリーマ2は多くの顧客(通常1000)を支持することができる。各顧客は初めに、始動フェーズのためのユニークな読み取りポイントを与えられ、そうすると、顧客バッファ32の均衡が達せられた後、ビデオストリーマ2がバッファ24から高いビットレートデータを供給し、読み取りポイントが他の顧客読み取りポイントと融合されることができる。読み取りポイントは、特定の顧客のために送信レートを増加するか、または減少させるかを要求されたネットワーク容量における不一致として委ねなくてはならないかもしれない。
【００２９】
熟練した者は、低いビットレートのデータバッファ23が、データの適当な量を顧客バッファ32に提供するに十分長い期間の間、2TEのレートでデータをバッファ23から読み出すことを許容するサイズのものであるべきであることを認識するであろう。例えば、バッファのために5秒が顧客3で500kbits-1データの価値があるとすると、ビデオストリーマ2は5秒間にデータの1000kbitsを供給しなければならず、その500kbitsは1秒あたりのデコーダ33によって消費され、500kbitsは5秒が経過するまで、1秒あたりバッファの中で増すであろう。したがって、低いビットレートのデータバッファは少なくとも5Mbitsのデータ(5x1000kbits)、または0.5Mbのすぐ上に保持できるに違いない。
【００３０】
熟練した者は、データがバッファから初めに読みだされるとき、コード化されたデータのストリームの“盗聴”と関連づけられた問題があると認識するであろう。エンコーダ1によって通常使われる圧縮技術は、アンカーフレームまたはＩ-フレームと呼ばれるビデオデータのフレームをコード化することを含み、このフレームから次のフレームが似ていることとして推定がなされ、推定されたフレームはB-フレームと呼ばれる。このように、一連のフレームを表すデータの量は大いに減少するかもしれない。しかしながら、データバッファ23、24のどちらかから読み出されるべき第１のフレームがB-フレームであるならば、デコードされたデータの第１の数フレームが推定に基づくフレームを再構成しようとするとき、デコーダとして難解であるかもしれない。発明のさらなる実施例では、データの余分なバッファが単にI-フレームからなるデータバッファ23、24と平行して供給される。送信されるべき第１のフレームがl-フレームバッファから読まれて、その結果、そこからデコードし始める信頼できるポイントをデコーダに与える。そして、データはデータバッファ23、24のどちらかから読み出されるように切り換えられる。
【００３１】
システムはユーザフレンドリーなビデオの流れを許容し、即ち、メディアの総合的な知覚された品質に有害な影響を及ぼすネットワーク状態変化の際に、ビデオの品質は急速に変動しない。顧客によって報告されるパケットの損失の場合に、システムはその送信レートを指数関数的に減少させることができる。顧客でバッファされるデータがあるとき、これはビデオソースの即座の切り換えをもたらす必要はない。パケットの損失の直後に、送信レートがコード化レートよりも低くなることが可能であり、ビデオデコーダの需要にこたえるために顧客がバッファされたデータで受信されたデータを補っているので、結果として顧客のバッファは空になる。孤立されたパケットの損失の場合、システムは、結局はバッファを満たす状態に戻る前に、初めに顧客のバッファが空になっているレートを遅く
して、再び送信レートを立ち上げることができる。
【００３２】
熟練した者は、しばらくは可変レートでデータを送信する能力が、流されたデータを弾性的にすることを可能にし、TCPフレンドリイな送信を許容することを認識するであろう。パケット損失検出器31による持続しているパケットの損失の検出はネットワーク渋滞を暗示している。ビデオストリーマ2のバッファマネージャ25は、高いビットレートデータバッファ24からのデータの送信レートの減少を指示することにより、パケットの損失の通知に反応する。高いビットレートデータバッファ24は、そのような出来事に対処するために適切な大きさにされるべきである。高いビットレートのデータバッファが支えることができるより長い間、減少された送信レートでパケットの損失が持続するなら、バッファマネージャ25は、低いビットレートのデータバッファ23からデータを供給するために切り換わるであろう。これは再生ビデオの知覚された品質の変化を引き起こすので、有効な管理プロトコルがネットワーク変動のデータ容量としてデータバッファ23および24間の急速な切り換えを防ぐ必要がある。ユーザが低い質の再生を許容する間、品質における急速な変化はユーザにとっていらだたしい場合がある。
【００３３】
ビデオストリーマに供給されるコード化されたデータストリームの数にはどんな制限もない。最大の帯域幅利用は、低いビットレートデータバッファからデータを読むことにより始まって、送信レートが増加されるようにして達成される。この送信レートでどんなパケットも失われないことの発見で、出力はより高いビットレートデータバッファに切り換えられ、そうすると送信レートが増加される。この送信レートがどんな障害にも遭遇しないならば、もっと高いビットレートのデータバッファが切り換えられ、そして、最大の帯域幅が採用されるまで続く。
【００３４】
ビデオストリーマ2に位置するバッファマネージャ25は、送信レートTSをどのように調整するか、およびいつバッファを切り換えるかを決めることが可能にされる。同様に、送信レートTSとどのバッファからデータを供給するかに関して顧客3からビデオストリーマ2へ指示が送られる。この場合ISPであるサービスについて請求に応答可能であるセンターの近くにコントロールセンターを位置させるのが実用的であるので、記述された実施例のバッファマネージャ25の位置は選択された。
【００３５】
ビデオデータの例は、上の実施例を例証するためにマルチメディアデータの例として選ばれる。発明は同様に、オーディオデータやマルチメディアプレゼンテーションなどの時間に敏感なデータのいかなる他の形にも適合する。
【００３６】
上記実施例において、データはエンコーダ1によって供給される。同様に、圧縮されたビデオデータはプログラムデータファイルのライブラリ、例えば呼び物フィルムのライブラリに保持され、必要なときにアクセスされるかもしれない。
【００３７】
ビデオストリーマ2とエンコーダ1はインターネットを通して接続されるように、ビデオストリーマ2がエンコーダ1から離れていてもよい。ビデオストリーマ2がインターネットサービスプロバイダ(ISP)により操作され、ビデオストリーマ2とエンコーダ1のと遠隔接続は、ISPが多くのエンコーダから顧客にコンテンツを利用可能にすることを許容するであろう。
【符号の説明】
【００３８】
１…エンコーダ ２…ビデオストリーマ ３…顧客
【特許請求の範囲】
【請求項１】
リアルタイムのデータ送信器と、記憶装置を有するリアルタイムのデータディスプレイ装置と、前記送信器および前記ディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を操作する方法において、
リアルタイムのプレゼンテーションの第1の部分を表すデータパケットを複数の第１のコード化レートで前記ディスプレイ装置に送信するように前記送信器を操作し、前記送信レートが前記コード化レートより高くされ、
前記ディスプレイ装置を操作して、
前記第１のコード化レートのデータパケットを前記記憶装置に受信し、
第１のレベルの品質でユーザに前記リアルタイムのプレゼンテーションを表示するようにデコードするため、前記第１のコード化レートで前記記憶装置からの第１のコード化レートのデータパケットを移転し、
前記第１のコード化レートのデータで予定されたレベルに満たされる前記記憶装置において、前記レベルが到達した指示を前記送信器に送り、
前記指示を受けて、前記送信器を操作し、前記リアルタイムのプレゼンテーションのその後の部分を表している第２のコード化レートのデータパケットを前記ディスプレイ装置に送り、前記第２のコード化レートは前記第１のコード化レートより高くされ、
前記ディスプレイ装置を操作して、
リアルタイムのプレゼンテーションのその後の部分を表す第２のコード化レートのデータパケットを前記記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイムのプレゼンテーションを前記ユーザに表示するようにデコードするために、前記第２のコード化レートで前記記憶装置から第２のコード化レートのデータパケットを移転するステップを含む方法。
【請求項２】
時間に敏感なデータを表示し、かつ時間に敏感なデータのバッファを構成する方法において、
時間に敏感なデータを受信し、
前記時間に敏感なデータをデータバッファに読み込み、
プレゼンテーションのために前記時間に敏感なデータをデータバッファから読み出し、
時間に敏感なデータを表示し、
時間に敏感なデータがデータバッファから読み出されるレートが、時間に敏感なデータがデータバッファに読取られるレートよりも低く、
顧客が時間に敏感なデータを最初に受信する時とプレゼンテーションのため時間に敏感なデータを利用可能にする時との間にどんな遅れも実質的にないように、時間に敏感なデータがデータバッファに最初に到着するときに、時間に敏感なデータをデータバッファから読み出すことが開始されることを特徴とする方法。
【請求項３】
データバッファ内の時間に敏感なデータの量を監視し、
受信された時間に敏感なデータのビットレートがデータバッファのデータ量に依存している、請求項２に従って顧客に時間に敏感なデータを表示する方法。
【請求項４】
第１のビットレートでコード化された時間に敏感なデータは、データバッファのデータ量が上側の閾値に達するまで受信され、そのあと第２のビットレートでコード化された時間に敏感なデータが受信され、前記第１のビットレートが第２のビットレートより低い、請求項３に従って顧客に時間に敏感なデータを表示する方法。
【請求項５】
第２のビットレートでコード化された時間に敏感なデータは、データバッファのデータ量が下側の閾値に達するまで受信され、そのあと第１のビットレートでコード化された時間に敏感なデータが受信される、請求項４に従って顧客に時間に敏感なデータを表示する方法。
【請求項６】
時間に敏感なデータがデータバッファに読み取られるレートはデータバッファのデータ量に依存している、請求項１乃至５の何れかに従って顧客に時間に敏感なデータを表示する方法。
【請求項７】
時間に敏感なデータを複数のビットレートでコード化し、
複数のビットレートの１つでコード化されたデータが顧客への送信のため選択され、
顧客にデータを送信する、
顧客に時間に敏感なデータを提供する方法。
【請求項８】
顧客へ送信するために選択された時間に敏感なデータが顧客に送信されるレートがダイナミックに変えられる、請求項7に従って顧客に時間に敏感なデータを提供する方法。
【請求項９】
複数のビットレートの１つでコード化された時間に敏感なデータが受信された信号に依存して選択される、請求項7に従って顧客に時間に敏感なデータを提供する方法。
【請求項１０】
送信のため選択された時間に敏感なデータが送信されるレートが、受信された信号に依存している、請求項８に従って顧客に時間に敏感なデータを提供する方法。
【請求項１１】
受信された信号は顧客へのリンクの状態を表している、請求項９または１０に従って顧客に時間に敏感なデータを提供する方法。
【請求項１２】
受信された信号は顧客のデータバッファのデータ量を表している、請求項９または１０に従って顧客に時間に敏感なデータを提供する方法。
【請求項１３】
顧客へのリンクの状態が顧客のデータバッファのデータ量により決定される、請求項１１に従って顧客に時間に敏感なデータを提供する方法。
【請求項１４】
時間に敏感なデータがビデオデータを表すか、またはオーディオデータを表すかの何れかである、請求項７乃至１３の何れかに従って顧客に時間に敏感なデータを提供する方法。
【請求項１５】
受信された時間に敏感なデータを時間の期間記憶するバッファ手段と、
前記時間に敏感なデータをバッファ手段に読み込む手段と、
前記時間に敏感なデータを前記バッファ手段から読み出す手段と、
バッファ手段に保持されたデータの量を監視するためのモニター手段と、
前記バッファ手段に保持された時間依存データの量に関係しているデータを送信する手段とを含み、
顧客が時間に敏感なデータを最初に受信する時と時間に敏感なデータをバッファから読み出す時との間の遅れを実質的になくするように、モニター手段がデータバッファで時間に敏感なデータの到着を検出するとき、データバッファから時間に敏感なデータの読み出しを開始する手段を有することを特徴とする、
時間に敏感なデータを受信する装置。
【請求項１６】
複数のデータストリームの各々が異なる量子化パラメタで同じソースからコード化されたビデオデータを含む複数のデータストリームを受信する手段と、
時間の期間コード化されたビデオデータの各ストリームを記憶する複数のバッファ手段と、
複数のバッファ手段の1つからコード化されたビデオデータを読み出すための少なくとも１つの読み出し手段と、
少なくとも１つの読み出し手段を制御するように配置されたバッファ管理手段とを含み、
前記読み出し手段が、バッファ管理手段の制御のもとで、ビデオデータがコード化されるフレームレートより小さいか、等しいかまたは大きいフレームレートで何れかのバッファ手段からコード化されたビデオデータを読み出すように配置されることを特徴とする、少なくとも１人の顧客にコード化されたビデオデータを供給する装置。
【請求項１７】
顧客のバッファのコード化されたビデオデータの量に関するデータを受信する手段と、
リンクの現在の容量を顧客に対して決定する手段とを含み、
バッファ管理手段が顧客のバッファのコード化されたビデオデータおよび顧客のリンクの容量に依存して読み出し装置を制御するように配置された、
請求項１６に従う顧客にコード化されたビデオデータを供給する装置。
【請求項１】
リアルタイムのデータ送信器と、記憶装置を有するリアルタイムのデータディスプレイ装置と、前記送信器および前記ディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を操作する方法において、
リアルタイムのプレゼンテーションの第1の部分を表すデータパケットを複数の第１のコード化レートで前記ディスプレイ装置に送信するように前記送信器を操作し、前記送信レートが前記コード化レートより高くされ、
前記ディスプレイ装置を操作して、
前記第１のコード化レートのデータパケットを前記記憶装置に受信し、
第１のレベルの品質でユーザに前記リアルタイムのプレゼンテーションを表示するようにデコードするため、前記第１のコード化レートで前記記憶装置からの第１のコード化レートのデータパケットを移転し、
前記第１のコード化レートのデータで予定されたレベルに満たされる前記記憶装置において、前記レベルが到達した指示を前記送信器に送り、
前記指示を受けて、前記送信器を操作し、前記リアルタイムのプレゼンテーションのその後の部分を表している第２のコード化レートのデータパケットを前記ディスプレイ装置に送り、前記第２のコード化レートは前記第１のコード化レートより高くされ、
前記ディスプレイ装置を操作して、
リアルタイムのプレゼンテーションのその後の部分を表す第２のコード化レートのデータパケットを前記記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイムのプレゼンテーションを前記ユーザに表示するようにデコードするために、前記第２のコード化レートで前記記憶装置から第２のコード化レートのデータパケットを移転するステップを含む方法。
【請求項２】
時間に敏感なデータを表示し、かつ時間に敏感なデータのバッファを構成する方法において、
時間に敏感なデータを受信し、
前記時間に敏感なデータをデータバッファに読み込み、
プレゼンテーションのために前記時間に敏感なデータをデータバッファから読み出し、
時間に敏感なデータを表示し、
時間に敏感なデータがデータバッファから読み出されるレートが、時間に敏感なデータがデータバッファに読取られるレートよりも低く、
顧客が時間に敏感なデータを最初に受信する時とプレゼンテーションのため時間に敏感なデータを利用可能にする時との間にどんな遅れも実質的にないように、時間に敏感なデータがデータバッファに最初に到着するときに、時間に敏感なデータをデータバッファから読み出すことが開始されることを特徴とする方法。
【請求項３】
データバッファ内の時間に敏感なデータの量を監視し、
受信された時間に敏感なデータのビットレートがデータバッファのデータ量に依存している、請求項２に従って顧客に時間に敏感なデータを表示する方法。
【請求項４】
第１のビットレートでコード化された時間に敏感なデータは、データバッファのデータ量が上側の閾値に達するまで受信され、そのあと第２のビットレートでコード化された時間に敏感なデータが受信され、前記第１のビットレートが第２のビットレートより低い、請求項３に従って顧客に時間に敏感なデータを表示する方法。
【請求項５】
第２のビットレートでコード化された時間に敏感なデータは、データバッファのデータ量が下側の閾値に達するまで受信され、そのあと第１のビットレートでコード化された時間に敏感なデータが受信される、請求項４に従って顧客に時間に敏感なデータを表示する方法。
【請求項６】
時間に敏感なデータがデータバッファに読み取られるレートはデータバッファのデータ量に依存している、請求項１乃至５の何れかに従って顧客に時間に敏感なデータを表示する方法。
【請求項７】
時間に敏感なデータを複数のビットレートでコード化し、
複数のビットレートの１つでコード化されたデータが顧客への送信のため選択され、
顧客にデータを送信する、
顧客に時間に敏感なデータを提供する方法。
【請求項８】
顧客へ送信するために選択された時間に敏感なデータが顧客に送信されるレートがダイナミックに変えられる、請求項7に従って顧客に時間に敏感なデータを提供する方法。
【請求項９】
複数のビットレートの１つでコード化された時間に敏感なデータが受信された信号に依存して選択される、請求項7に従って顧客に時間に敏感なデータを提供する方法。
【請求項１０】
送信のため選択された時間に敏感なデータが送信されるレートが、受信された信号に依存している、請求項８に従って顧客に時間に敏感なデータを提供する方法。
【請求項１１】
受信された信号は顧客へのリンクの状態を表している、請求項９または１０に従って顧客に時間に敏感なデータを提供する方法。
【請求項１２】
受信された信号は顧客のデータバッファのデータ量を表している、請求項９または１０に従って顧客に時間に敏感なデータを提供する方法。
【請求項１３】
顧客へのリンクの状態が顧客のデータバッファのデータ量により決定される、請求項１１に従って顧客に時間に敏感なデータを提供する方法。
【請求項１４】
時間に敏感なデータがビデオデータを表すか、またはオーディオデータを表すかの何れかである、請求項７乃至１３の何れかに従って顧客に時間に敏感なデータを提供する方法。
【請求項１５】
受信された時間に敏感なデータを時間の期間記憶するバッファ手段と、
前記時間に敏感なデータをバッファ手段に読み込む手段と、
前記時間に敏感なデータを前記バッファ手段から読み出す手段と、
バッファ手段に保持されたデータの量を監視するためのモニター手段と、
前記バッファ手段に保持された時間依存データの量に関係しているデータを送信する手段とを含み、
顧客が時間に敏感なデータを最初に受信する時と時間に敏感なデータをバッファから読み出す時との間の遅れを実質的になくするように、モニター手段がデータバッファで時間に敏感なデータの到着を検出するとき、データバッファから時間に敏感なデータの読み出しを開始する手段を有することを特徴とする、
時間に敏感なデータを受信する装置。
【請求項１６】
複数のデータストリームの各々が異なる量子化パラメタで同じソースからコード化されたビデオデータを含む複数のデータストリームを受信する手段と、
時間の期間コード化されたビデオデータの各ストリームを記憶する複数のバッファ手段と、
複数のバッファ手段の1つからコード化されたビデオデータを読み出すための少なくとも１つの読み出し手段と、
少なくとも１つの読み出し手段を制御するように配置されたバッファ管理手段とを含み、
前記読み出し手段が、バッファ管理手段の制御のもとで、ビデオデータがコード化されるフレームレートより小さいか、等しいかまたは大きいフレームレートで何れかのバッファ手段からコード化されたビデオデータを読み出すように配置されることを特徴とする、少なくとも１人の顧客にコード化されたビデオデータを供給する装置。
【請求項１７】
顧客のバッファのコード化されたビデオデータの量に関するデータを受信する手段と、
リンクの現在の容量を顧客に対して決定する手段とを含み、
バッファ管理手段が顧客のバッファのコード化されたビデオデータおよび顧客のリンクの容量に依存して読み出し装置を制御するように配置された、
請求項１６に従う顧客にコード化されたビデオデータを供給する装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−１４２９５６（Ｐ２０１２−１４２９５６Ａ）
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−２６２４９（Ｐ２０１２−２６２４９）
【出願日】平成２４年２月９日（２０１２．２．９）
【分割の表示】特願２００２−５４６３８４（Ｐ２００２−５４６３８４）の分割
【原出願日】平成１３年１１月２８日（２００１．１１．２８）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
【公開日】平成２４年７月２６日（２０１２．７．２６）
【国際特許分類】
【出願番号】特願２０１２−２６２４９（Ｐ２０１２−２６２４９）
【出願日】平成２４年２月９日（２０１２．２．９）
【分割の表示】特願２００２−５４６３８４（Ｐ２００２−５４６３８４）の分割
【原出願日】平成１３年１１月２８日（２００１．１１．２８）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
[ Back to top ]