(57)【要約】【課題】  メディア・サーバを現在の状態に適応させること。【解決手段】  通信ネットワーク上において、様々なストリーミング状態でデータをストリーミングするシステム及び方法は、複数の表現を作成することによりデータを調整するための調整装置、該調整装置に応答して、複数の調整されたデータ表現をパッケージ化するためのパッケージ化装置、パッケージ化手段に応答して、少なくとも１つの現在のストリーミング状態を監視し、監視された少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するためのメディア・サーバ、及び、該メディア・サーバに応答して、選択され、パッケージ化され、調整されたデータ表現をストリーミングするための通信ネットワークを含む。【選択図】      図１
2007525053.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク上において、様々なストリーミング状態でデータをストリーミングする方法であって、
複数の表現を作成することによりデータを調整するステップと、
複数の調整されたデータ表現をパッケージ化するステップと、
少なくとも１つの現在のストリーミング状態を監視するステップと、
監視された前記少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するステップと、
選択され、パッケージ化され、調整された前記データ表現をストリーミングするステップと、
を含む方法。
【請求項２】
前記データが複数のデータ単位を含む、請求項１に記載の方法。
【請求項３】
前記複数のデータ単位が順次的である、請求項２に記載の方法。
【請求項４】
前記データが、データ単位毎に複数の表現を作成することにより調整される、請求項２に記載の方法。
【請求項５】
前記調整されたデータ表現が、所定の有限のストリーミング状態の組について、異なるデータ単位における軌道を予め計算することによりパッケージ化される、請求項４に記載の方法。
【請求項６】
前記監視された現在のストリーミング状態が与えられている場合に、前記選択され、最適にパッケージ化され、調整されたデータ表現が、データ単位における最適な軌道に対応する、請求項５に記載の方法。
【請求項７】
前記現在のストリーミング状態が与えられている場合に、前記調整されたデータ表現が、ストリーミング・サーバが最小のコストで最適な軌道を決定できるように、メタデータを各々のデータ単位に取り付けることによってパッケージ化される、請求項４に記載の方法。
【請求項８】
前記監視された現在のストリーミング状態が与えられている場合に、前記選択され、最適にパッケージ化され、調整されたデータ表現が、データ単位における最適な軌道に対応する、請求項７に記載の方法。
【請求項９】
前記データがビデオ・ストリームを含む、請求項１に記載の方法。
【請求項１０】
前記通信ネットワークがデータ・ネットワークを含む、請求項１に記載の方法。
【請求項１１】
前記データ・ネットワークがインターネットを含む、請求項１０に記載の方法。
【請求項１２】
前記少なくとも１つの現在のストリーミング状態が、使用可能なデータ・チャンネル帯域幅を含む、請求項１に記載の方法。
【請求項１３】
前記少なくとも１つの現在のストリーミング状態が、監視されたデータ・パケット損失率を含む、請求項１に記載の方法。
【請求項１４】
前記少なくとも１つの現在のストリーミング状態が、使用可能なストリーミング・サーバの出力帯域幅を含む、請求項１に記載の方法。
【請求項１５】
通信ネットワーク上において、様々なストリーミング状態でデータをストリーミングするシステムであって、
複数の表現を作成することによりデータを調整するための調整手段と、
前記調整手段に応答して、複数の調整されたデータ表現をパッケージ化するためのパッケージ化手段と、
前記パッケージ化手段に応答して、少なくとも１つの現在のストリーミング状態を監視するための監視手段と、
前記監視手段に応答して、監視された前記少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するための選択手段と、
前記選択手段に応答して、選択され、パッケージ化され、調整された前記データ表現をストリーミングするためのストリーミング手段と、
を備えるシステム。
【請求項１６】
前記調整手段が調整装置を含み、
前記パッケージ化手段が、前記調整装置と信号通信状態にあるパッケージ化装置を含み、
前記監視手段が、前記パッケージ化装置及び前記通信ネットワークと信号通信状態にあるメディア・サーバを含み、
前記選択手段が、前記パッケージ化装置及び前記通信ネットワークと信号通信状態にある前記メディア・サーバを含み、
前記ストリーミング手段が、前記メディア・サーバ及び前記通信ネットワークの少なくとも１つを含む、
請求項１５に記載のシステム。
【請求項１７】
前記パッケージ化装置が、所定の有限のストリーミング状態の組について、異なるデータ単位における軌道を予め計算する、請求項１６に記載のシステム。
【請求項１８】
前記現在のストリーミング状態が与えられている場合に、前記パッケージ化装置は、ストリーミング・サーバが最小のコストで最適な軌道を決定できるように、メタデータを複数のデータ単位の各々に取り付ける、請求項１６に記載のシステム。
【請求項１９】
通信ネットワーク上において、様々なストリーミング状態でデータをストリーミングするプログラム・ステップを実行するための、コンピュータ・システムによって実行可能な命令のプログラムを実体的に具体化する、機械読み取り可能なプログラム記憶装置であって、前記プログラム・ステップが、
複数の表現を作成することによりデータを調整するステップと、
複数の調整されたデータ表現をパッケージ化するステップと、
少なくとも１つの現在のストリーミング状態を監視するステップと、
監視された前記少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するステップと、
選択され、パッケージ化され、調整された前記データ表現をストリーミングするステップと、
を含むプログラム記憶装置。
【請求項２０】
前記少なくとも１つの現在のストリーミング状態が、使用可能なデータ・チャンネル帯域幅、監視されたデータ・パケット損失率、及び使用可能なストリーミング・サーバの出力帯域幅のうちの少なくとも１つを含む、請求項１９に記載のプログラム記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にデータ・ストリーミングに関し、より具体的には、通信ネットワーク上において、様々なストリーミング状態でデータをストリーミングするメディア・サービスに関する。
【背景技術】
【０００２】
メディアの圧縮及び配信は、マルチメディア通信に不可欠な様式を与える。デジタルＴＶ、ビデオ・オン・デマンド、ビデオ電子メール、テレビ電話、テレビ会議、及びリッチ・メディア電子学習を含む様々なアプリケーションが存在する。これらのアプリケーションは、ＩＰベースのワールド・ワイド・ウェブ及び無線通信サービスによって最も顕著に実現されてきた。ケーブル及びデジタル加入者回線モデムを通しての、より大きなアクセス帯域幅が利用可能となり、ＩＰマルチキャストの大規模な展開によりサーバ及びネットワーク負荷が軽減され、バックボーン帯域幅が増加するために、近い将来、リッチ・メディア通信のより迅速な発展及びより広範囲にわたる展開が実現するであろう。
【０００３】
残念なことに、接続に対して保証されたサービス品質（「ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ」）を提供できるＩＳＤＮといった、より普遍的なネットワークとは異なり、ＩＰベースのインターネット及び無線ネットワークは、両方とも比較的信頼性がない。現在のところ、これらはＱｏＳ保証を与えない。全てのリッチメディア・ストリーム全体に対するＱｏＳ保証された伝送は実現不可能であり、技術的及び経済的制約のために長期にわたりそのままの状態である可能性がある。避けることのできないパケット損失、ビット・エラー、バースト・エラー、遅延、及びジッタ（ｊｉｔｔｅｒ）によって、このような損失が多いネットワーク上での効率的なリッチ・メディアの伝送が困難なものとなる。これらのネットワーク特性は、圧縮されたビット・ストリームの伝送に影響を及ぼし、終端間品質の性質を変更し、実質的に、リッチ・メディア配信システムの新たな設計を要する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従って、メディア・サーバが、そのコンテンツを現在の状態に適応させることができるようにすることが望ましい。適応メディア・サービスが本開示の焦点である。例えば、クライアントが、損失が多い無線チャンネル上で連続画像の継続的配信を要求する場合には、メディア・サーバは、ストリームされたコンテンツを、パケット損失率が異なり、かつ、使用可能なチャネル速度が異なるものの両方に適応させねばならない。この適応によって、ユーザ体験がより良いものとなるであろう。そういった適応は、典型的なオンライン・トランスコーディング技術の場合によくあるような、メディア・サーバに極端に大きな処理能力を要求すべきものではないことが特に望ましい。
【課題を解決するための手段】
【０００５】
従来技術のこれら及び他の難点及び欠点は、適応メディア・サービスのための複数記述の示唆及び切換のシステム及び方法によって対処される。
【０００６】
本システムは、複数の表現を作成することによりデータを調整するための調整装置、該調整装置に応答して、複数の調整されたデータ表現をパッケージ化するためのパッケージ化装置、パッケージ化手段に応答して、少なくとも１つの現在のストリーミング状態を監視し、該監視された少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するためのメディア・サーバ、及び、該メディア・サーバに応答して、選択され、パッケージ化され、調整されたデータ表現をストリーミングするための通信ネットワークを含む。
【０００７】
これに対応する方法は、複数の表現を作成することによりデータを調整するステップと、複数の調整されたデータ表現をパッケージ化するステップと、少なくとも１つの現在のストリーミング状態を監視するステップと、該監視された少なくとも１つの現在のストリーミング状態に応じて、最適にパッケージ化され、調整されたデータ表現を選択するステップと、選択され、パッケージ化され、調整されたデータ表現をストリーミングするステップとを含む。
【０００８】
本開示のこれら及び他の態様、特色及び利点は、添付の図面に関連して参照されるべき、以下の例示的な実施形態の説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【０００９】
本開示は、以下の例示的な図面に従って、適応メディア・サービスのための複数記述のヒンティング及び切換のシステム及び方法を教示する。
【００１０】
適応メディア・サービスのための複数記述のヒンティング及び切換のシステム及び方法が提供される。次の説明において、以下の用語を予め定義する。
【００１１】
アクセス単位：アクセス単位とは、例えば、連続画像における映像又はサウンド・トラックにおける音声フレームといった、本開示の実施形態が適用されるメディア単位である。
【００１２】
記述：記述とは、サーバによる配信準備が整った圧縮されたアクセス単位である。
【００１３】
記述特性：特定の記述に関する特性のベクトルであり、このベクトルは「ｐ」により示される。このベクトルは、本開示の具体的な実施又は実施形態に対応する方法により、特定の記述を表現する。
【００１４】
稼動状態：サーバが適応しなくてはならない実際の状態のベクトルであり、このベクトルは「ｘｃ」と示される。
【００１５】
本開示の実施形態は、１つの情報又は「メタデータ（ｍｅｔａｄａｔａ）」を全ての記述に取り付ける。このメタデータは、記述選択アルゴリズムの実施と両立性のある方法により、記述をその記述の特性に関して特徴づける。メディア・サーバは、考慮中のアクセス単位に関する全記述のメタデータを分析して、監視された及び／又は計算された稼動状態ｘｃに応じて、どの記述を送信すべきか決定する。すなわち、異なる記述において所定の軌道は存在しない。その代わりに、メディア・サーバは、各時点ごとに、又は各アクセス単位持続期間ごとに、予め確立された制約の下で、｜ｘ（ｐ）−ｘｃ｜が最小になるように、特性ｐをもつ最適な記述を選出する。
【００１６】
図１に示すように、本開示のシステムの実施形態が、参照番号１０１によって全体的に示される。システム１０１は、データ受信のための調整ツール１００、該調整ツール１００と信号通信状態のパッケージ化ツール２００、及び該パッケージ化ツール２００及びインターネット４００と信号通信状態のメディア・サーバ３００を含む。調整ツール１００は、ソース・データを取り込み、そのソース・データを一連のデータ単位に分割する（例えば、ビデオ・ストリームは一連のビデオ・フレームに分割できる）。次いで、調整ツールは、一組の予測される稼動状態を与えられて、各データ単位の複数のバージョンを作成し、場合によっては、データ単位毎に様々な数のバージョンを作成する。
【００１７】
図２を参照すると、図１によるパッケージ化のためのフロー図全体が参照番号２０１によって示されている。初期設定ブロック２１０は、カウンタ・ブロック２１２に制御を渡し、これは次いで、決定ブロック２１４に制御を渡す。決定ブロック２１４は、カウンタがアクセス単位の数に到達したかどうかをチェックし、到達している場合には、終了ブロック２１６に制御を渡す。カウンタがアクセス単位の数に到達していない場合には、ループ初期設定ブロック２１８に制御を渡し、これは次いで、機能ブロック２２０に制御を渡す。機能ブロック２２０は、カウンタ・ブロック２１２によりトラックされたものに対応する時点で、ローカル・ループ・カウンタに応じた記述のメタデータを検索して、最大ひずみを計算する。内部ループ・カウンタ・ブロック２２２は、ブロック２２０から制御を受け取り、ローカル・ループ・カウンタをインクリメントさせ、決定ブロック２２４に制御を渡す。決定ブロック２２４は、ローカル・ループ・カウンタが限度値より小さいかどうかチェックし、もしそうであれば、機能ブロック２２０に制御を戻す。
【００１８】
ブロック２２４が、ローカル・ループ・カウンタが限度値に達したと判断した場合には、制御はループ初期設定ブロック２２６に渡される。ループ初期設定ブロック２２６は、次いで、機能ブロック２２８に制御を渡し、これは２つの記述を検索し、以前に計算されたひずみが２つの検索された記述の間のひずみより少ないかどうかをチェックし、アルファ値を計算する。機能ブロック２２８は、内部ループ・カウンタをインクリメントするカウンタ・ブロック２３０に制御を渡し、これは次いで、決定ブロック２３２に制御を渡す。決定ブロック２３２は、内部ループ・カウンタが限度値より少ないかどうかをチェックし、そうである場合には、機能ブロック２２８に制御を戻す。決定ブロック２３２が、内部ループ・カウンタが限度値に達していることを見出した場合には、制御は外部カウンタ・ブロック２３４に渡され、これは次いで、決定ブロック２３６に制御を渡す。ブロック２３６は、外部ループ・カウンタが限度値より少ないかどうかをチェックし、そうである場合には、機能ブロック２２８に制御を戻す。決定ブロック２３６が、外部ループ・カウンタが限度値に達したと判断した場合には、書き込みブロック２３８に制御を渡す。書き込みブロック２３８は、次いで、メタデータ・アルファを書き込み、カウンタ・ブロック２１２に制御を戻す。
【００１９】
従って、パッケージ化ツール２００は、種々のバージョンをディスクといったファイルにパッケージ化し、メタデータを取り付けて、ストリーミング・サーバが、これらのバージョンにおける最適な軌道を容易に判断して、現在監視されている稼動状態（すなわち、図１におけるｘｃ）をターゲットできるようにする。
【００２０】
ここで図３を参照すると、図１によるパッケージ化によりメタデータを与えられた場合の、ストリーミングのためのフロー図が、全体を参照番号３０１により示される。ここでは、初期設定ブロック３１０がカウンタ・ブロック３１２に制御を渡し、これは次いで、決定ブロック３１４に制御を渡す。決定ブロック３１４は、カウンタがアクセス単位の数より少ないかどうかチェックし、そうでない場合には、エンド・ブロック３１６に制御を渡す。そのカウンタが、依然としてアクセス単位の数より少ない場合には、制御が機能ブロック３１８に渡されて、稼動制約Ｒを計算する。機能ブロック３１８は、検索ブロック３２０に制御を渡して現在の限度値Ｎｉを検索し、次いで、機能ブロック３２２に制御を渡す。機能ブロック３２２は現在のアルファを検索し、その記述に対するＮｉひずみ値を計算する。機能ブロック３２４は、機能ブロック３２２から制御を受け取り、ストリーミングのために、現在のカウンタ時刻値に対応する記述を選択し、カウンタ・ブロック３１２に制御を戻す。
【００２１】
従って、ストリーミング・サーバ３００は、パッケージ化データが流されるシステム４００から現在の稼動状態ｘｃを定期的に測定する。顧客が割り込み、以前に調整され、パッケージ化されたデータを要求する。これにより、ストリーミング・サーバは、データをパッケージ化データから読み取り、時刻ｔにおいて、取り付けられたメタデータと併せて種々のバージョンを検索し、時刻０と時刻Ｔ（すなわち、パッケージ化データの終端）との間の全ての時刻ｔについて、与えられたｘｃを時刻ｔにおいて送信するのに最適なバージョンのサブセットを計算する。
【００２２】
図４に示すように、順次記述の概略的な組が、全体を参照番号４０１により示されている。ここでは、例えば、ｉ−２からｉ＋４の記述はビデオ・クリップの圧縮されたビデオ・フレームを表すことができる。全てのアクセス単位は、メディア・ストリームの典型的な単一エンコーディングを行うための、一つの、かつ、唯一の記述を有する。例えば、圧縮されていないビデオ・クリップが１００のフレーム又はアクセス単位から成る場合には、このビデオ・クリップを圧縮することによって、各々のビデオ・フレームが一度圧縮されることになり、これにより、１対１のマッピングに対して１００の記述がもたらされることになる。これらの１００の記述を含むファイルは、次いで、メディア・サーバにロードされる。
【００２３】
図５を参照すると、アクセス単位毎に１つの記述をもつ、順次記述の概略的な組全体が参照番号５０１により示されている。メディア・サーバは、監視された及び／又は計算された稼動状態ｘｃがどうであろうと、｜ｘ−ｘｃ｜に比例する振幅で認知劣化となる可能性がある、これらの記述を順次送信する。
【００２４】
再生が要求された場合には、メディア・サーバは記述を送信する。記述は、アクセス単位をデジタル圧縮することによりもたらされるため、圧縮パラメータ（例えば、ＣＯＤＥＣ、ビットレート）は、記述の特性（例えば、サイズ、ひずみ）に直接的に影響を及ぼす。従って、順次記述の組は、最適に、一つの、かつ、唯一の稼動状態ｘｃの組をターゲットとする。一組の順次記述がターゲットとする稼動状態をｘにより示す。
【００２５】
図７のシーケンスを参照すると、記述ｉがその特性ｐにより述べられる、順次記述の概略的な組全体が参照番号７０１により示されている。ここでは、挙げられた特性（例えば、種類、サイズ、ひずみ、堅牢性）は例示的なものにすぎない。ｘは、エンコーディング特性ｐに大いに依存する。実際の稼動状態ｘｃの下で、メディア・サーバがｘをターゲットとする記述を送信する場合には、ｘがｘｃと異なるときはいつでも、表示品質が劣化する。ＩＰネットワークの最善努力性質により、ｘｃと異なるｘは、一般的なシナリオである。この問題は他でも確認されており、異なる解決策がもたらされている。
【００２６】
第１の解決策は、全ての独特な記述が実際にネットワーク上に送信され、そこでなんらかの処理（例えば、トランスコーディング・アルゴリズム）が実行される前に、この記述を取り込むことであった。この解決策は、きめ細かい拡張容易性を与える（｜ｘ−ｘｃ｜をできるだけ小さくできる）が、膨大な処理要件ももたらし、それによって、メディア・サーバが取り扱うことができる並行ストリームの数が劇的に減少された。別の解決策は、アクセス単位毎に複数の記述を作成した。本開示は、このパラダイムに基づくものである。
【００２７】
ここで図６を参照すると、実ネットワークからの確実なストリーミングといった個別のターゲットの稼動状態ｘｃｉの概略的な組全体が参照番号６０１により示されている。既存の実施は、個別のターゲットの組の稼動状態ｘｉに依存する（例えば、実ネットワークからの確実なストリーミング）。図６は、その理念を図によって示す。アクセス単位毎に複数の記述（図では４つ）が作成されて、４つの区別できる記述の組が、正確に稼動状態ｘ１、ｘ２、ｘ３、及びｘ４をターゲットする。メディア・サーバは、稼動状態ｘｃを監視及び／又は計算して、異なる区別できる記述の組ｘｉ（図においてはｉ＝｛０，１，２，３｝）に切り換えるように決定することができる。この解決策には、ごくわずかな余分な処理能力が要求されるが、適応のための粒度レベルは、記憶スペースに直接影響を及ぼす。
【００２８】
本開示の実施形態は、両者の利点を兼ね備えている。すなわち、本実施形態は、きめ細かい拡張容易性を、要求される処理能力に対してごくわずかな影響で達成することができる一般的なフレームワークを与える。
【００２９】
共に説明されるべき図８乃至図１０に示すように、好ましい実施形態の操作が説明されており、記述Ｄの組が特定のビデオ・アセットとして与えられている。デルタは、一定の内部フレーム間隔を示す。例えば、毎秒２５フレームの連続画像は１／２５ｓのデルタを有する。
【００３０】
図８に示すように、順次記述の概略的な組全体が参照番号８０１により示されている。記述の特性を説明するために、メタデータが全ての記述に取り付けられている。
【００３１】
図９に示すように、順次記述の概略的な組全体が参照番号９０１により示されており、ここでは、メディア・サーバが、考慮中のアクセス単位に関する全記述のメタデータを分析して、監視された及び／又は計算された稼動状態に応じて、どの記述を送信するか決定する。
【００３２】
図１０に示すように、順次記述の概略的な組全体が参照番号１００１により示されており、ここでは、Ｄｉｋ（．）はＭＳＥ（Ｄｉｋ）（：）を示し、アクセス単位ｉ＋１を考えると、Ｎｉ＝３の値は、［０，Ｎｉ］内のｋについてａｌｐｈａｉ＋１２（ｋ）によって示される記述２において計算され、これらのＮｉ値は記憶され、記述ｊは、時刻ｉ＋１及びＤｉ＋１２により示される記述２における最大ひずみを持つｊ＝ａｒｇ  ｍａｘｋＤｉ＋１２（ｋ）となるように維持される。
【００３３】
０＜＝ｋ＜Ｎｉ及び０＜＝ｉ＜Ａである場合に、Ｄｉｊがアクセス単位ｉのｊ番目の記述を示すとする。例えば、図９を検討する。記述を２つしかもたない（すなわち、（ｉ＋２）及びＮｉ＋２＝２と異なる全てのＩに対してＮＩ＝３）アクセス単位ｉ＋２以外の全てのアクセス単位は、３つの記述を有する。稼動制約のベクトルはｘｃ＝［Ｒ（ｉ）］として示され、この例示的な実施形態では、Ｒ（ｉ）は時刻ｉにおいて使用可能なチャネル速度である。稼動制約ベクトルは、本開示の代替実施形態において、さらに多くの要素を含むことができる。
【００３４】
この好ましい実施形態の方法は、２つの部分から成る。第一に、記述特性を識別し、それらの値を計算するための方法を提案する。次に、現在の稼動制約を与えられている場合に、メディア・サーバが、これらの特性を効率的に用いるための方法を提案する。
【００３５】
記述特性においては、記述特性のベクトルがｐ＝［Ｓ，ａｌｐｈａ］として定義され、ここでは、Ｓはバイトで表した記述のサイズ、ａｌｐｈａは間隔［−１  １］における可能性のある計測値を考慮した重み係数であり、偏差はソースひずみで示されている。時刻ｉにおける記述のソースひずみは、ゼロとすることもできるが、この例においては、時刻ｉ−１における記述のひずみの２倍ほどになることはないと仮定する。代替的な実施形態においては、記述特性のベクトルは、さらに多くの要素を含むことができる。さらに、ここ及び以下でのアルファの計算は、例示的なものにすぎない。
【００３６】
サイズＳの計算は単純である。アルファ（図１０を参照）の計算は以下のとおりである。記述Ｄｉｊの平均二乗誤差（ＭＳＥ）をＭＳＥ（Ｄｉｊ）により表す。全てのアクセス単位ｉについて、アクセス単位ｉ−１の任意の以前の０＜＝ｊ＜Ｎｉ−１が与えられているものに対して、アクセス単位ｉの全ての記述０＜＝ｊ＜ＮｉのＭＳＥひずみを計算する。全ての０＜＝ｊ＜Ｎ０及びＮ−１＝１に対して、ＭＳＥ（Ｄ−１ｊ）＝１００と定義する。全ての０＜＝ｊ＜Ｎ−１及びＮ−１＝１に対して、ＭＳＥ（Ｄ−１ｊ）＝１００を初期設定する。次いで、全てのアクセス単位ｉに対して、ＮｉｘＮｉ−１値を計算する。これらのひずみを、ＭＳＥ（Ｄｉｊ）（ｋ）により示し、ここでは、ｋは０からＮｉ−１までの範囲である。次いで、ｋを、０＜＝ｋ＜Ｎｉ−１及びＭＳＥ（Ｄｉ−１ｊ）＝ｍａｘｋ（ＭＳＥ（Ｄｉ−１ｊ）（ｋ））として、パラメータａｌｐｈａｉｊ（ｋ）を、
ａｌｐｈａｉｊ（ｋ）＝ＭＳＥ（Ｄｉｊ）（ｋ）／ＭＳＥ（Ｄｉ−１ｊ）−１        （１）
により計算する。
従って、記述は１＋ＮｉｘＮｉ−１値により完全に説明され、サイド情報（例えばメタデータ）として記憶される。
【００３７】
メディア・サーバにおいては、標準プロトコルＲＴＰ／ＲＴＣＰ上でのメディアのストリーミングが考慮される。メディア・サーバは、定期的に、パケット損失率及び接続における往復時間の両方の評価を含む、ＲＴＣＰレシーバ・レポート・メッセージを受信する。このパケット損失率及び往復時間を、それぞれｒｈｏとＲＴＴにより示す。Ｒ（ｉ）は、
Ｒ（ｉ）＝（１．３×ＭＴＵ）／（ＲＴＴ×ｓｑｒｔ（ｒｈｏ））  （２）
として計算し、ここで、ＭＴＵは、その接続で使用されているパケット・サイズである。アクセス単位毎の時刻ｉにおいて、メディア・サーバは、時刻ｉ−１で選択された記述を知ることになる。この記述の索引をｋにより示す。次いで、Ｎｉひずみ値Ｄｉｊを、Ｄｉｊ＝Ｄｉ−１ｋ（１＋ａｌｐｈａｉｋ）を用いて計算する。最後にメディア・サーバは、最小のひずみ値を持ち、サイズＳｉｋ＊がＲ（ｉ）×Ｄｅｌｔａより小さいか又は等しくなる、時刻ｉにおける記述ｋ＊を選択する。
【００３８】
従って、アクセス単位スキップによる速度適応が、本開示によりカバーされ、その実施形態は、全てのスキップ可能なアクセス単位に対して、余分なヌル記述を作成する。本発明の好ましい実施形態の実施は、標準のＭＰＥＧ−４ファミリーに十分に適合し、従ってＱｕｉｃｋｔｉｍｅ  ６．０、ＩＢＭ  ＪＡＶＡ（Ｒ）プレイヤ及びＲｅａｌ  ＯｎｅといったＭＰ４クライアント・プレイヤに直接応用することができる。
【００３９】
本開示のこれら及び他の特色及び利点は、ここに示された教示に基づいて、当業者には容易に確認されるであろう。本開示の教示は、ハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、又はこれらの組み合わせの様々な形態で実施可能であることが理解されるべきである。
【００４０】
本開示の教示は、ハードウェアとソフトウェアの組み合わせとして実施することができる。さらに、ソフトウェアは、プログラム記憶装置上で実体的に具体化されるファームウェアにより実施されることが好ましい。ソフトウェアは、任意の適切なアーキテクチャからなる機械によりアップロード及び実行することができる。その機械は、１つ又はそれ以上の中央処理装置（「ＣＰＵ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）、及び入出力（「Ｉ／Ｏ」）インターフェースといったハードウェアを有するコンピュータ・プラットフォーム上で実施されることが望ましい。コンピュータ・プラットフォームは、さらに、オペレーティング・システム及びマイクロ命令コードを含むこともできる。ここに説明される様々なプロセス及び機能は、マイクロ命令コードの一部か、ソフトウェアの一部か、又はこれらのあらゆる組み合わせとすることができ、ハードウェアによって実行することができる。さらに、付加的なデータ記憶装置といった様々な他の周辺装置を、コンピュータ・プラットフォームに接続することができる。
【００４１】
さらに、添付の図に示される構成システム部品及び方法のいくつかは、ソフトウェアで実行されるのが好ましいため、システム部品間又はプロセス機能ブロック間の実際の連結は、本開示がプログラムされる方法に応じて異なってよいことを理解すべきである。ここでの教示が与えられるとすると、当業者は、本開示のこれら及び同様な実施又は構成を想定できることになるであろう。
【００４２】
添付の図面を参照して、例示的な実施形態が説明されたが、本開示はこれらの正確な実施形態に限定されるものではなく、本開示の範囲又は趣旨から離れることなく、当業者により種々の変更及び修正を行うことができることを理解すべきである。全てのこのような変更及び修正は、特許請求の範囲に述べられる本開示の範囲内に含まれることが意図される。
【図面の簡単な説明】
【００４３】
【図１】本開示の好ましい実施形態によるシステムの概略ブロック図である。
【図２】図１によるパッケージ化のフロー図である。
【図３】図１によるパッケージ化からのメタデータを与えられた場合のストリーミングのフロー図である。
【図４】各々の記述が、サーバにより配信される準備ができた圧縮されたアクセス単位であり、例えば、ｉ−２からｉ＋４の記述がビデオ・クリップの圧縮ビデオ・フレームを表すことができる、順次記述の概略的な組を示す。
【図５】メディア・サーバが、監視された及び／又は計算された稼動状態ｘｃがどうであろうと、｜ｘ−ｘｃ｜に比例する振幅で認知劣化となる可能性がある、これらの記述を順次配信する、アクセス単位毎に１つの記述をもつ順次記述の概略的な組を示す。
【図６】実ネットワークからの確実なストリーミングといった個別のターゲットの稼動状態ｘｃｉの概略的な組を示す。
【図７】記述ｉがその特性ｐによって説明され、挙げられた特性（すなわち種類、サイズ、ひずみ、堅牢性）が例示的なものにすぎない、順次記述の概略的な組を示す。
【図８】記述の特性を説明するメタデータが全ての記述に取り付けられた、順次記述の概略的な組を示す。
【図９】メディア・サーバが、考慮中のアクセス単位に関する全ての記述のメタデータを分析し、監視された及び／又は計算された稼動状態に応じて、どの記述を送信するかを決定する、順次記述の概略的な組を示す。
【図１０】Ｄｉｋ（．）がＭＳＥ（Ｄｉｋ）（：）を示し、アクセス単位ｉ＋１を考えると、Ｎｉ＝３の値は、［０，Ｎｉ］内のｋについてａｌｐｈａｉ＋１２（ｋ）によって示される記述２において計算され、これらのＮｉ値は記憶され、記述ｊは、時刻ｉ＋１及びＤｉ＋１２により示される記述２における最大ひずみを持つｊ＝ａｒｇ  ｍａｘｋＤｉ＋１２（ｋ）となるように維持される、順次記述の概略的な組を示す。
【図１】
2007525053.tif 000003
【図２】
2007525053.tif 000004
【図３】
2007525053.tif 000005
【図４】
2007525053.tif 000006
【図５】
2007525053.tif 000007
【図６】
2007525053.tif 000008
【図７】
2007525053.tif 000009
【図８】
2007525053.tif 000010
【図９】
2007525053.tif 000011
【図１０】
2007525053.tif 000012
【国際調査報告】
2007525053.tif 000013
2007525053.tif 000014