JP2015520966A - コード変換された複数のコンテンツストリームを提供するための方法および装置 - Google Patents

Abstract

コンテンツストリームの複数バージョンを異なるビットレートで提供する方法が提案される。方法によると、コンテンツストリームのバージョンのセットが異なるビットレートで、クライアントに対して推奨される。コンテンツストリームのバージョンの推奨されるセットを記述するマニフェスト部が、クライアントにサブミットされる。クライアントが、特定のビットレートを持つコンテンツストリームの１バージョンをリクエストする。クライアントに対して推奨されるバージョンのビットレートが動的に選択されて、隣接するバージョンのビットレート間の差が動的に適応されるようにする。提案される方法では、適応コード変換が向上するため、現在配信されるビットレート周辺の、配給されるビットレート値の小さなセットに基づく、小さなマニフェスト部が使用できる。これに加えて、方法を実装するシステムが提案される。

Description

本発明は、複数バージョンのコンテンツストリームを異なるビットレートで提供するための方法に係わる。本発明の方法によると、各バージョンが同じ入力コンテンツストリームからコード変換されている。本発明はまた、本発明による方法を実装するために適したシステムに係わる。

今日、ますます多くのデジタルの音声および映像がサーバ上に格納され、オンラインで配信することができるようになった。コンテンツを物理媒体で配給することは、減り続けている。オンライン配信のための第１のアプローチによると、音声および映像のコンテンツ（Ａ／Ｖコンテンツ）を、サーバからクライアント装置に、１つのファイルで全部を、例えば、デジタルＭＰ３音声ファイルとして、ダウンロードすることができる。しかし、このアプローチでは、そのような１つの完全ファイルで映像コンテンツを配信すると、映像コンテンツをダウンロードするのに通常長時間を要し、これにより、ユーザが映像コンテンツを楽しむことが可能となる時間の開始を遅らせることになる。

オンライン配信のための第２のアプローチによると、音声／映像コンテンツが、小エレメントのシーケンスに分割されて次々にダウンロードされる。個々のエレメントは「チャンク」とも呼ばれる。チャンクは数秒程度の短時間を表し、連結されて完全なコンテンツを再現させることができる。一連のチャンクとして送信されるチャンク全体を、音声／映像ストリームとも呼ぶ。音声および映像のコンテンツは、「ストリーミング型コンテンツ」とも呼ぶ。ストリーミング型コンテンツは、音声および／または映像のストリームで構成される。

音声および／または映像のストリームは、ユーザが様々な異なる装置を使用することにより消費されてよい。とりわけ、映像ストリームでは、再生装置の画面サイズに適応する形式または表現を必要とすることがある。音声ストリームでも同様に、再生装置による制限が課されることがある。ところで、以下においては、本発明は映像ストリームに着目して例示的に提示されるが、本発明は映像ストリームに限定されない。

任意の種類のストリーミング型コンテンツを適応させることが必要とされるのは、コンテンツがサーバからクライアント装置にストリーミングされる際の接続の多様性にも起因する。例えば、無線接続では、回線の混雑によるスループットの変動のみ、または、受信装置のローミングによる受信条件の変動をもたらすことがある。適応するストリーミングが適切に機能すれば、ネットワークまたは再生条件における変化に対して、配信されるストリームの最高のレートが継続的に動的に適応されるため、コンテンツの消費者は最良のコンテンツを常に楽しむことができる。

コンテンツの適応ストリーミングの様々な実装が提案されている。

一例として、カリフォルニア州のアップル社による実装があり、「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」または「ＨＬＳ」としても既知である。本実装については、Ｒ．Ｐａｎｔｏｓによる「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」、ＩＥＴＦ，Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ Ｖｅｒｓｉｏｎ５（ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０５）、２０１０年１１月、に記載される。

別の実装については、マイクロソフト（登録商標）社により提示され、「Ｓｉｌｖｅｒｌｉｇｈｔ Ｓｍｏｏｔｈ ｓｔｒｅａｍｉｎｇ」として既知である。本実装については、「ＩＩＳ ｓｍｏｏｔｈ ｓｔｒｅａｍｉｎｇ ｔｅｃｈｎｉｃａｌ ｏｖｅｒｖｉｅｗ」に記載される。詳細は下記においてオンラインで入手可能である。
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｄｏｗｎｌｏａｄｓ／ｄｅｔａｉｌｓ．ａｓｐｘ？ｄｉｓｐｌａｙｌａｎｇ＝ｅｎ＆ＦａｍｉｌｙＩＤ＝０３ｄ２２５８３−３ｅｄ６−４４ｄａ−８４６４−ｂｌｂ４ｂ５ｃａ７５２０。

さらに別の実装については、アドビシステム社により提示され、「Ａｄｏｂｅ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ」という名称により既知である。詳細は、論文「ＨＴＴＰ ｄｙｎａｍｉｃ ｓｔｒｅａｍｉｎｇ ｏｎ ｔｈｅ Ａｄｏｂｅ Ｆｌａｓｈ ｐｌａｔｆｏｒｍ」にて知ることができ、下記においてオンラインで入手可能である。
ｈｔｔｐ：／／ｗｗｗ．ａｄｏｂｅ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｈｔｔｐｄｙｎａｍｉｃｓｔｒｅａｍｉｎｇ／ｐｄｆｓ／ｈｔｔｐｄｙｎａｍｉｃｓｔｒｅａｍｉｎｇｗｐｕｅ．ｐｄｆ。

適応ストリーミングの標準化作業が、ＳＡ４作業グループにおける３ＧＰＰ、および、ＭＰＥＧにおいて「Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ」（ＤＡＳＨ）作業グループにより、今なお行われている。ＤＡＳＨ作業グループは、２０１１年１２月に、第１の仕様の公開を行った。この作業の詳細は、Ｔ．Ｓｔｏｃｋｈａｍｍｅｒによる「Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ−ｓｔａｎｄａｒｄｓ ａｎｄ ｄｅｓｉｇｎ ｐｒｉｎｃｉｐｌｅｓ」、会報２０１１ＡＣＭ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｓｙｓｔｅｍｓ（ＭＭＳｙｓＥ ２０１１）、２０１１年２月、１５７−１６８ページ、に公開されている。

異なる技術において、サーバが、時間期間ごとに、ビットレートの適応が可能なチャンクの数バージョンを提供するという点が共通する。システムは、サーバ、エンコーダ、クライアント、および、この３者を接続するネットワーク、で表され、クライアントが、任意の時間期間について対応するチャンクバージョンをリクエストすることにより、１つのビットレートから別のビットレートに切替えることができるように、構成される。チャンクの構成（チャンクのデュレーション、チャンクのビットレートおよび／または形式）を既述するマニフェスト部は、別個に与えられ、ストリーミングの場合は、定期的に更新のために再ロードする必要がある。

これをどのように達成するのかについての詳細、および、マニフェスト部の形式は、アップル社のＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ、マイクロソフト社のＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、アドビ社のＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ、など、使用する特定の技術によって変わる。しかし、全て、基本的には同じ概念に依存する。

そのようなシステムの通常の使用は、インターネットを介してウェブサーバから任意のクライアントにデータを配信することである。そのようなサーバ、および配信経路上のｈｔｔｐのキャッシュは、クライアントが所与の時間にリクエストすることができる全てのチャンクバージョンを記憶する。

先に提出された、欧州特許出願ＥＰ１１３０６０９．３号において、本発明者は、ＨＴＴＰ適応トランスコーダについて記載しており、これは、動的にＡＶストリームをコード変換して、それを、そのようなＨＴＴＰ適応ストリーミングプロトコルを実装するクライアントに送信することができるものである。ＥＰ１１３０６０９．３号に記載される適応トランスコーダでは、計算資源を限定し、従って、単一ビットレートまたは非常に少ない数の異なるビットレートにコード変換するだけであるが、より多くの可能なビットレートがクライアントに対してマニフェストファイルでアドバタイズ（公示）されている。エンコーダの目標ビットレートを、クライアントのリクエストに従って動的に適応させて、ＨＴＴＰ適応配信の利点が保持されるようにし、すなわち、ネットワークおよび／または端末の制限に対して動的に適応させる。適応トランスコーダは、トランスコーディングプラットフォームとも呼ばれる。

ＨＴＴＰ適応ストリーミングでは、サーバは、コンテンツのいくつのバージョンを提示するのか、また、ビットレートをどれにするのか、を決定しなければならない。一方、より高いビットレートから選択するほど、最良の音声および映像（Ａ／Ｖ）の品質を維持したまま、クライアントはより良好に現在のネットワークのスループット条件に適応することができる。一方、ＨＴＴＰサーバは、通常、チャンクのバージョン数で決まるデータ量を記憶しなければならない。例えば、１Ｍｂｐｓ、２Ｍｂｐｓおよび３Ｍｂｐｓの３レベルを提供する場合、ストリームでは、最高のビットレートを与えるだけのために必要されるものの２倍のデータ量が使用される。従って、異なるビットレートと共に、利用可能なバージョン数を増加させると、サーバへのデータのロードが、直ぐにコンテンツの通常ボリュームの数倍となり得る。

ＥＰ１１３０６０９．３号に記載される上述の装置では、オンザフライでコード変換を行い、「リクエストされない」チャンクは生成されず、ＡＶストリームのデータボリュームは、提示されるビットレートの個数に依存しない。従って、アドバタイズされるビットレートの個数を有意に増加させて、クライアントが非常に正確にその必要性に適応すること可能になる。例えば、１Ｍｂｐｓから３Ｍｂｐｓまでのビットレート範囲内で、異なるバージョンのコンテンツ間でステップサイズが５０ｋｂｐｓの場合、アドバタイズされる４１個の可能なビットレートがある。アドバタイズされるビットレートは、クライアントのプレイリストを構成する。

しかし、利用可能なビットレートのセットを記述するマニフェスト部は、提示されるビットレートの個数に比例するサイズを有する。ライブストリームを再生する際、クライアントは、そのプレイリストをかなり頻繁にリフレッシュする必要があり、これには、利用可能なビットレートのためのマニフェスト部を再ロードすることが含まれる。従って、利用可能なビットレートの個数が高くなる場合、マニフェスト部の形式で送信される、記述データの量は、もはやコンテンツのビットレートと比較して小さくない。また、ストリーミング型コンテンツを処理するためのクライアント上で稼働するアプリケーションについての構文解析作業も増加する。

本発明は、上述のマニフェスト部のサイズの問題に対処する。

第１の態様によると、本発明は上述の問題の解決を、コンテンツストリームのバージョンのセットを異なるビットレートでクライアント（４）に対して推奨する方法によって提案し、本方法は、
ａ）コンテンツストリームのバージョンの推奨されるセットを記述するマニフェスト部を準備するステップと、
ｂ）マニフェスト部をクライアント（４）にサブミットするステップと、
ｃ）特定のビットレートを持つ、コンテンツストリームの１バージョンを求めるクライアント（４）からのリクエストを受信するステップと、
ｄ）コンテンツストリームの１バージョンを、クライアント（４）がリクエストするビットレートにコード変換するステップと、
ｆ）クライアント（４）に対して推奨されるビットレートを動的に選択して、隣接するバージョンのビットレート間の差を動的に適応させるステップと、
ｇ）ステップａ）からｆ）を繰り返すステップと
を含む。

本発明の概念では、適応トランスコーダを向上させるため、現在配信されるビットレート周辺の、配給されるビットレート値の小さなセットに基づく、小さなマニフェスト部が使用できる。

有利な一実装において、本発明は、コンテンツストリームのバージョンのセットを１つのクライアントに対して推奨するステップをさらに含む。

本発明は、推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、隣接ビットレートが、クライアントがリクエストするビットレートの変更に応じて決まるようにする、ステップをさらに含むことで、有利であることが分かった。

同様に、本発明は、推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、ビットレートの差が、クライアントが異なるビットレートをリクエストする頻度に応じて決まるようにする、 ステップをさらに含むことで、有利であることが分かった。

有利な一実施形態において、本発明は、推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、ビットレートの差が、現在受信されるバージョンのビットレートと比較して、クライアントがリクエストするビットレートの変化がどのくらい大きいかに応じて決まるようにする、ステップをさらに含む。

さらに別の実施形態において、本発明の方法は、現在リクエストされているビットレートに近いほど、隣接ビットレートとの差が増加するビットレートを持つ、推奨されるビットレートのセットを提供するステップをさらに含む。

有利には、方法は、それぞれが隣接ビットレートと等間隔である、推奨されるビットレートのセットを提供するステップをさらに含む。

有利な一実装において、本発明は、現在受信されるバージョンのビットレートと比較した、リクエストされるバージョンのビットレートの差が、閾値を超える場合に、異なるバージョンの隣接ビットレートのステップサイズを動的に適応させるステップをさらに含む。

第２の態様によると、本発明は、本発明による方法を実装するために適応されるシステムを提案する。

図面において、本発明の実施形態を例示する。
本発明の一実装の概略ブロック図である。 異なる条件における推奨されるバージョンのビットレート示すグラフである。 特別な状況でのビットレートを示す別のグラフである。 発明の方法を例示するフロー図である。

図１は、本発明を実装するシステム１の概略ブロック図を示す。システム１には、ソース２、適応プラットフォーム３、および、再生装置４、が含まれる。

ソース２は、例えば、映像コンテンツなどのストリーミング型コンテンツの出所である。換言すれば、ソース２は、ストリーミング型コンテンツの提供を行うものである。例えば、任意の種類のホームビデオもしくはプリペイド方式の映像を配信する家庭用機器、または、放送映像またはマルチキャスト映像（ＤＶＢ−Ｔ、ＤＶＢ−ＩＰＴＶなど）を配信する外部のコンテンツプロバイダ、さらには、１ファイルとして示される、または、ネットワークからストリーミングされることが可能な、ビデオオンデマンドサービス（ＶｏＤサービス）の映像などである。図１において、ソース２は、ＤＶＢおよびＩＰＴＶの信号の形式でＡ／Ｖコンテンツを提供するものとして示される。

再生装置４は、市販の端末、またはクライアント装置であり、その能力およびネットワーク条件によって異なる品質で、音声および／または映像を再生することが可能である。本願において、クライアント装置は、ユーザが、サーバに接続し、コンテンツをダウンロードし、コンテンツをユーザにとって視聴可能な様式で再生することができる、任意の装置である。本願において、用語「クライアント装置」と「クライアント」は同意語として使用される。ＨＴＴＰ適応ストリーミングの本文脈においては、再生装置４はクライアント４とも称する。ＨＴＴＰ適応ストリーミングのようなプロトコルが好ましいのは、クライアント４が再生の直前に適切な品質をリクエストすることが可能とされるからである。

適応プラットフォーム３には、入力コンテンツストリームを、妥当な場合は、分離した音声と映像の成分に逆多重化するためのデマルチプレクサ６（“ｄｅｍｕｘ”）が設けられる。映像成分は、デコーダ７“ｄｅｃｏｄｅ”において復号され、映像セグメント化ユニット８“ｓｅｇｍｅｎｔ”においてセグメント化される。そして、エンコーダ９“ｅｎｃｏｄｅ”において、セグメント（“ｓｏｕｒｃｅ ｃｈｕｎｋｓ”）がコード変換され、すなわち、元のパラメータとは異なるパラメータを使用して再符号化される。エンコーダ９は、Ｈ．２６４エンコーダとしてよいが、他の形式も同様に可能である。音声成分は、セグメント化ユニット１１“ｓｅｇｍｅｎｔ”においてセグメント（“ａｕｄｉｏ ｃｈｕｎｋｓ”）に分割され、また、コード変換されてもよい（図示せず）。次に、音声およびコード変換された映像のセグメントは、マルチプレクサ１２“ＴＳ ｍｕｘ”に与えられる。マルチプレクサ１２は、Ｍ３Ｕ８マニフェスト形式に従ってマニフェスト部を作成する。マルチプレクサ１２“ＴＳ ｍｕｘ”は、コード変換かつ多重化されたセグメント、およびマニフェスト部を、大容量記憶装置１３“ｆｉｌｅｓ”に記憶し、ここからサーバ１４“ｗｅｂ ｓｅｒｖｅｒ”、例えば、ＨＴＴＰサーバ、がセグメントをクライアント４に転送する。

上記においてさらに検討したように、本発明が特に有用であるのは、適応プラットフォーム３、すなわち処理能力が制限されたトランスコーダにおいて実装される際であり、例えば、ＩｎｔｅｌＣＥ４２００プロセッサに基づく基本メディア処理能力のインターネットゲートウェイにおいて実装される際である。

当業者は、Ｈ．２６４コーデックおよびＭ３Ｕ８マニフェスト形式を選択して、上記で検討した実施形態において使用したことは、単に、アップル社のクライアント装置に適用する場合の本発明の説明のために必要であることを認識するであろう。ＶＣ１、ＷｅｂＭなどの他のコーデックおよび他のマニフェスト形式を必要とする他の適応ストリーミングの実装においては、符号化するリソースが乏しいために、１ストリームの全ての必要な代替バージョンを並行して生成することができない場合には、説明した発明から同様に恩恵をうけることができる。

ライブ映像をストリーミングする場合、マニフェストにより、時間と共に変化するチャンクのセットを公表する。公表されるバリアント（変形）のセットも変化する。これは、本発明では、提案されるバリアントのセットまたは推奨されるバージョンのセットを動的に修正することにより使用される。マニフェストで提示されるバージョンは、接続のスループットの過去の変動に応じて更新される。換言すれば、以下でさらに説明するように、マニフェスト部のバージョンが、クライアントのリクエストに応じて更新される、ということもできる。

適応プラットフォーム３では、チャンクが生成される実際のビットレートと、クライアント４がリクエストするビットレートとの間の結びつきが緩いため、マニフェストを比較的自由に生成することができる。本発明によると、適応プラットフォーム３は以下のビットレートを選択して、クライアントに提案する。

適応プラットフォームは、クライアントにとっての現在の目標ビットレート、すなわちクライアントがリクエストした最新のビットレート、を提案する。これは、ネットワーク条件が安定している時には、クライアントが最適な値に収束して、リクエストを同一に保つ、という理由から、重要である。従って、この提案は必要である。

適応プラットフォーム３はまた、現在の目標ビットレートに極めて近いいくつかのビットレートも提案する。クライアントの最適な収束のために（最大使用可能帯域幅の直下にある状態での最良の品質のために）、現在受信されるビットレートから小さなステップサイズだけ離れた代替ビットレートが提案される。これにより、クライアント４は、滑らかな品質変化に正確に適応することが可能となる。これは、エンドユーザが感知する視覚的品質に対して重要である。

これに加えて、適応プラットフォーム３は、現在の目標から離れたいくつかの他のビットレートを提案する。これにより、クライアント４は、ネットワーク条件に著しい変化があった場合に素早い適応を行うことができる。

具体的な例において、コンテンツストリームの１バージョンがビットレート２Ｍｂｐｓで配信されるとする。次に、マニフェストにより、ビットレート、１Ｍｂｐｓ、１．５Ｍｂｐｓ、１．８Ｍｂｐｓ、１．９Ｍｂｐｓ、１．９５Ｍｂｐｓ、２Ｍｂｐｓ、２．０５Ｍｂｐｓ、２．１Ｍｂｐｓ、２．２Ｍｂｐｓ、２．５Ｍｂｐｓ、３Ｍｂｐｓを用いて、バージョンのセットが推奨される。

実際、ステップ数およびステップ間の間隔は、システム１の種々のパラメータに適応させることができる。

クライアント４の挙動に応じて、ステップを設定する方法を動的に変更することも可能である。リクエストされたビットレートが極めて安定している場合、本発明では、現在配信されるバージョンの１つに近くステップが非常に小さい、より多くのビットレートを提案し、現在のバージョンから離れたビットレートは少なく提案する。条件が不安定になる場合は、本発明では、ビットレート間に規定のステップを設けてビットレートに間隔をおくことを提案し、クライアントが、利用可能なビットレート範囲内の任意の領域に、自身を再配置することが可能とされる。

説明された状況が、図２（ａ）から（ｃ）に示され、１Ｍｂｐｓから３Ｍｂｐｓの範囲にあるビットレートのスケール２１を示す。垂直方向の線が、クライアント４に対して提案または推奨されるビットレートを示す。スケール２１の真ん中にある長い垂直方向の線が、「現在の」ビットレートを表す。図２（ａ）から（ｃ）には、１０個の代替ビットレートを有するバージョンをクライアント４に対して提案する、本発明の例示の実施形態が示される。

図２（ａ）には、安定した状況でのビットレートが示され、現在配信されるビットレートの周辺に小ステップがある。図２（ａ）に示すように、最低および最高の可能ビットレート１Ｍｂｐｓおよび３Ｍｂｐｓは、クライアント４に対して提案されない。提案されるビットレートはむしろ、より限定される範囲に広がるが、それは、安定した帯域幅が想定される場合には、本実施形態において、クライアントが１Ｍｂｐｓまたは３Ｍｂｐｓなどの極端な値に変更する必要があるとは考えにくいためである。

図２（ｃ）では、最大限利用可能な範囲に広がるビットレートのセットが等間隔に配置されている。ビットレートについてこの種の選択がなされるのは、状況が安定しておらず、かつ、クライアント４が利用可能な範囲内の「任意の」ビットレートに移行することができるときである。

図２（ｂ）には、中間の状況が示され、図２（ａ）と比較すると、提案されるビットレートが現在配信されるビットレートの周辺にはそれほど集中していないが、図２（ｃ）のように等間隔ではない。

図２（ａ）から（ｃ）は、本発明の１つの基本概念を示しており、すなわち、クライアント４に対して推奨されるバージョンのビットレートを動的に選択して、隣接するバージョンのビットレート間の差を動的に適応させる。隣接するバージョンのビットレート間の差は、図２（ａ）から（ｃ）および図３においては、水平方向の線の間隔に対応する。

実際は、提案されるビットレートの個数は、本発明の概念に影響を与えることなく、異ならせることができ、時間と共に変化してよい。提案されるビットレートのセットはまた、図２（ａ）から（ｃ）に示すように対称に分布されなくてもよい。例えば、現在リクエストされているビットレートが、所与のコンテンツについての可能な範囲に比べて、非常に低いか、または非常に高い場合、それぞれ、現在のビットレートより下または上で間隔を小さくして値の個数を少なくしてもよいし、また、それぞれ、現在のビットレートより上または下で間隔を大きくして値の個数を多くしてもよい。

図３には、現在配信されるビットレートが、利用可能なビットレートの範囲の上限にある状況を示す。その結果として、全ての他の推奨されるビットレートは、現在配信されるビットレートより低い。

本発明の特定の一実施形態において、以下のプロセスが使用される。

アドバタイズされるビットレートの個数が１１に設定される。

所与のコンテンツについて、最小および最大のビットレート値が判定される。最大値は最良の品質での映像のビットレートであり、すなわち、理想的にはコード変換はしない。ソース２と出力コーデック９のビットレートが確実に異なっている場合、コード変換は必須であり、最大ビットレートはソースビットレートとは異なるであろう。最小ビットレートは、エンドユーザが受け入れ可能な最も低いビットレートとして判定される。これは、全く主観的なものであり、装置のタイプに依存する−ＨＤテレビに対しては、携帯電話に対するよりも良い品質が期待される−また、ユーザの好みに依存する。最大ビットレート（ｍａｘ）および最小ビットレート（ｍｉｎ）の比率は、例えば１０である。

次に、時間経過の中の任意の時点で、現在のビットレートＢを、最後にリクエストされたものであると考える。欧州特許出願ＥＰ１１３０６０９．３号でも説明されるように、起動時に、いくつかの初期値がトランスコーダにより選択される。このビットレートは、アドバタイズされるビットレートのリストに常に含まれる。１０個の残りのビットレート値について、まず、Ｂより下または上のそれらの個数を決める。これら２つの数を、それぞれ（Ｂ−ｍｉｎ）および（ｍａｘ−Ｂ）に比例させるが、上限値に対して最小の数値を丸める。これは、Ｂが最小または最大のビットレートと全く等しい場合を除いて、小さい数値側に常に少なくとも１つの値があるということを意味する。例えば、Ｂが、下端が最小ビットレートで、上端が最大ビットレートで制限されるビットレート区間の７５％の値に相当する場合（要するに、この区間は［ｍｉｎ，ｍａｘ］である）、Ｂより下に７個のアドバタイズ値があり、Ｂより上に３個ある。Ｂが区間［ｍｉｎ，ｍａｘ］の９０％の値に相当する場合、Ｂより下に９個のアドバタイズ値があり、Ｂより上に１個のアドバタイズ値がある。特に言及すると、Ｂが区間［ｍｉｎ，ｍａｘ］の９９％の値に相当する場合、Ｂより下になお９個のアドバタイズ値があり、Ｂより上に１個のアドバタイズ値がある。

次に、それらの値を各区間に配置するために、クライアント４の安定性が測定される。この目的で、コンテンツチャンクを配信するウェブサーバ１４が、リクエストされたビットレート値をクライアント４から収集する。このことから、クライアントがリクエストした最新の２０個のビットレート値のセット上での標準偏差σが計算される。Ｎは、既に説明したようなＢより上に生成されるビットレートの個数とする。σが（ｍａｘ−Ｂ）／Ｎより大きいならば、リクエストの不安定性により、等間隔のビットレートを設けることが要求される。そうでないならば、率ｐ＝（ｍａｘ−Ｂ）／（Ｎ×σ）を使用して、［１，Ｎ］（１からＮまでの自然数の区間）内のｎに対して値ｎ＾ｐ（他の記述では：ｎ^ｐ）が生成される。これらＮ個の値は、（ｍａｘ−Ｂ）／Ｎ＾ｐと乗算させ、かつ、基本値Ｂを加算することにより、最終的に正しい範囲に換算される。

同じアルゴリズムを、公式において（ｍａｘ−Ｂ）の代わりに（Ｂ−ｍｉｎ）を使用することにより、簡単にＢの下の値に適用する。なお、他の公式でも望ましい結果を生み出すことができる。本発明は、ネットワークの安定性の特定の計算方法に限定されない。

本発明の主要な利点は、高い正確性を伴って、全ての可能なビットレートを網羅する代替バージョンの非常に長いリストをアドバタイズする必要なく、Ａ／Ｖコンテンツの適応配信を任意の最適な値に収束させることだができることである。

小さなビットレートステップを設けることも役立つことであり、何故なら、リクエストされるビットレートと、制限された数のビットレートでチャンクを事前にコード変換することによって紹介されて提供されるチャンクと、の間の差が小さくなるからである。例えば、クライアントがビットレートＢのチャンクＮをリクエストした場合、適用トランスコーダが、同じビットレートＢのチャンクＮ＋１を準備し、続くチャンクＮ＋２もビットレートＢで準備する。換言すると、別のビットレートを求めるリクエストが適応トランスコーダに送信される時と、リクエストされたビットレートで最初のチャンクが生成される時との間にディレイが存在する。例えば、クライアントがビットレートＢから、より低いビットレートＢ’への変更を必要とし、その結果ビットレートＢ’のチャンクＮ＋１をリクエストする場合、クライアントは、実際には、ビットレートＢ’ではなくビットレートＢのチャンクＮ＋１とチャンクＮ＋２をそのまま受信する。トランスコーダは、チャンクＮ＋３だけをビットレートＢ’でエンコードする。

ＢとＢ’との間の差が大きいときは、大量のデータを送信する際のこのディレイがクライアントのバッファを枯渇させ、クライアント４において映像のフリーズを引き起こすかもしれない。その理由は、受信されるチャンクが、利用可能な帯域幅に比べて非常に大きいために、到着に長時間かかるからである。この時間の間、クライアント４は、事前にバッファリングしたデータを全て使ってしまい、再生を中止しなければならず、残りのデータの到着を待つことになる。

より小さなステップを設けることで、ビットレートの差を小さくしてもっと頻繁に変更する機会をクライアントに与えることができ、これにより、クライアント４での映像のフリーズのリスクを下げることができる。

ビットレートのリストの形成に必要な計算には、計算能力の観点からはコストはかからない。この低コストは、マニフェスト部におけるクライアント４に送信されるボリュームの節約によってバランスがとられるが、大容量記憶装置１３においてシンボリックリンクを通してなどして《疑似チャンク》を生成するコストを制限することによってもバランスがとられる。このことは、次のように説明できる。適応トランスコーダにおいて、１チャンクをビットレートＢで生成する際、各ビットレートについて１ファイルが作成されて、マニフェストで信号として送られる。ウェブサーバは、リクエストされたファイルについて機能しさえすればよい。ファイルのファイル名は、チャンク番号とビットレート値を用いて形成される。多くの記憶スペースを使用してファイルを複製するのではなく、シンボリックリンクが形成されて、その全てが同じファイルを指し示す。しかし、それがファイルシステムコールであるため、リンクの作成もコストがかかる。チャンク毎に何度も発生する場合には、要求される計算能力は考慮すべきものとなり得る。

なお、適応プラットフォーム３により推奨されるバージョンのビットレートのセットは、所定の閾値を超えてクライアント４の安定性が変化する場合に適応されるだけである。一実施形態において、閾値は、所定の時間内の現在配信されるビットレートとは異なるビットレート、を求める特定の個数のリクエストとして、定義される。別の実施形態において、閾値は、現在配信されるビットレートと比較した、リクエストされるビットレートの差として定義される。本発明の実装において、２つ以上の閾値が存在してよい。閾値が１つまたは数個を超えると、推奨されるバージョンのセットのビットレートの適応が開始される。

図４は、フロー図で本発明に係わる方法の原理を説明する。ステップ４１にて、適応プラットフォーム３が、異なるビットレートを有するＡ／Ｖコンテンツのバージョンを、クライアント４に推奨する。ステップ４２にて、適応プラットフォーム３が、推奨されるバージョンのマニフェスト部の準備も行う。ステップ４３にて、適応プラットフォーム３が、マニフェスト部をクライアント４にサブミット（提出）する。ステップ４４にて、クライアントが、特定のバージョンのコンテンツをリクエストする。クライアント４のリクエストに応答して、適応プラットフォーム３が、推奨されるバージョンのビットレートを選択する。上述のように、選択されたビットレートは、クライアント４のリクエストに応じて変化してもしなくてもよい。ループ４６で示すように、方法は、ステップ４１に戻り、そこで、適応プラットフォーム３がコンテンツのバージョンのセットをクライアント４に推奨する。

本発明に係わるシステムでは、適応トランスコーダを用いて得られるユーザ経験を、最適なビットレートに近づくべく収束させることにより、すなわち、安定したネットワーク条件にある際のクライアントの安定した挙動を可能にすることにより、向上させる。望ましい値の上と下の２つの値の間に変動はない。

１ システム
２ ソース
３ 適応プラットフォーム
４ 再生装置
６ デマルチプレクサ
７ デコーダ
８ 映像セグメント化ユニット
９ エンコーダ
１１ 音声セグメント化ユニット
１２ マルチプレクサ
１３ 大容量記憶装置
１４ サーバ
２１ ビットレートのスケール
４１ バージョンを推奨するステップ
４２ マニフェスト部を準備するステップ
４３ マニフェスト部をサブミットするステップ
４４ 特定のバージョンをリクエストするステップ
４５ ビットレートを選択するステップ
４６ ループ

Claims (9)

1. コンテンツストリームのバージョンのセットを異なるビットレートでクライアント（４）に対して推奨する方法であって、
   ａ）前記コンテンツストリームのバージョンの推奨されるセットを記述するマニフェスト部を準備するステップと、
   ｂ）前記マニフェスト部をクライアント（４）にサブミットするステップと、
   ｃ）特定のビットレートを持つ、前記コンテンツストリームの１つを求めるリクエストをクライアント（４）から受信するステップと、
   ｄ）前記コンテンツストリームの１バージョンを、クライアント（４）がリクエストするビットレートにコード変換するステップと、
   ｆ）前記マニフェスト部でクライアント（４）に対して推奨されるビットレートを動的に選択して、隣接するバージョンのビットレート間の差を動的に適応させるステップと、
   ｇ）ステップａ）からｆ）を繰り返すステップと、
   を含む、前記方法。
2. 前記コンテンツストリームのバージョンのセットを１つのクライアント（４）に対して推奨するステップをさらに含む、請求項１に記載の方法。
3. 前記推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、前記隣接ビットレートが、クライアント（４）がリクエストするビットレートの変更に応じて決まるようにする、ステップをさらに含む、請求項１に記載の方法。
4. 前記推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、前記ビットレートの差が、クライアントが異なるビットレートをリクエストする頻度に応じて決まるようにする、 ステップをさらに含む、請求項３に記載の方法。
5. 前記推奨されるビットレートのセット内の異なる隣接するバージョン間のビットレートの差を動的に適応させて、前記ビットレートの差が、現在受信されるバージョンのビットレートと比較して、クライアントがリクエストするビットレートの変化がどのくらい大きいかに応じて決まるようにする、ステップをさらに含む、請求項３に記載の方法。
6. 現在リクエストされるビットレートに近いほど、隣接ビットレートとの差が増加するビットレートを持つ、推奨されるビットレートのセットを提供するステップをさらに含む、請求項３に記載の方法。
7. それぞれが隣接ビットレートと等間隔である、推奨されるビットレートのセットを提供するステップをさらに含む、請求項３に記載の方法。
8. 現在受信されるバージョンのビットレートと比較した、リクエストされるバージョンのビットレートの差が、閾値を超える場合に、異なるバージョンの隣接ビットレートのステップ幅を動的に適応させるステップをさらに含む、請求項３から５の１つまたは複数に記載の方法。
9. 先行請求項の１つまたは複数に記載の方法を実装するのに適したシステム（１）。

Images