JP2016500504A - 低レイテンシ・ストリーミング - Google Patents

Abstract

少なくとも１つのネットワークを通じたセグメントのクライアントへの低レイテンシ・ストリーミングを可能にする方法およびシステムについて記載する。前記クライアントは、マニフェスト・ファイルに基づいて、セグメントを少なくとも１つのサーバに要求し受信するように構成される。前記方法は、前記ネットワークの少なくとも一部において前記クライアントが受けるサービス品質の情報を収集し、前記サービス品質情報を前記ネットワークの品質データベースに格納するステップと、前記サービス品質情報の少なくとも一部を前記コンテンツ処理デバイスに送るステップと、前記サービス品質情報の前記少なくとも一部に基づいて、前記コンテンツ処理デバイスにおいてバッファ、好ましくは、プレイアウト・バッファ、および／またはセグメント要求機能に対する１つ以上の構成パラメータを決定するステップと、前記構成パラメータにしたがって、前記バッファおよび／または前記セグメント要求機能を構成するステップとを含む。【選択図】 図１

Description

本発明は、低レイテンシ・ストリーミングに関し、特に、クライアントに対するセグメントの低レイテンシ・ストリーミングを可能にする方法およびシステム、クライアントに対する低レイテンシ・ストリーミングを可能にする構成、このようなシステムにおける使用のためのクライアントおよびデータベース構造、ならびにこのような方法を使用するためのコンピュータ・プログラム製品に関するが、これらに限定されるのではない。

従来技術

インターネット・ビデオおよびインターネットＴＶが増々普及するに連れて、変化するネットワーク条件の下で連続再生および最良のユーザ体験を可能にする、適応型ストリーミング解決手段(solution)が増々求められている。適応型ストリーミングの概念は、ビデオ・ストリームによって要求される帯域幅を、ストリーミング・ソースとクライアントとの間のネットワーク経路上で利用可能な帯域幅に適応させるという理念に基づいており、ビデオ・ストリームのビット・レート（即ち、品質）を変化させることによって、帯域幅を適応させる。

現在、多数のＨＴＴＰに基づく適応ストリーミング（ＨＡＳ）プロトコルが開発されており、これらの解決手段の内最良の実地は、現在、発展しつつあるＩＳＯ規格ISO/IEC23001-6に凝縮されている。これは、MPEG Dynamic Adaptive Streaming over HTTP（ＭＰＥＧ ＤＡＳＨ：ＭＰＥＧ ＨＴＴＰ動的適応ストリーミング）と呼ばれる。ＨＡＳの解決手段では、コンテンツ・ストリームは、通常、セグメント（「チャンク」とも呼ばれる）に区分され、これらのセグメントの各々を異なる品質レベル（表現）でエンコードすることができる。コンテンツ配信ネットワーク（ＣＤＮ）が、通例、セグメントを大多数のコンテンツ処理デバイスに効率的に配信するために使用される。

セグメントおよびそれらの異なる表現は、いわゆるマニフェスト・ファイル内に記述される。マニフェスト・ファイルは、ストリームにおけるセグメントについての情報（セグメント識別子、位置、プレイアウト(play-out)時刻等）およびストリームにおける異なるセグメント間の時間的関係についての情報を含むことができる。コンテンツ処理デバイスにおけるクライアントは、マニフェスト・ファイルを使用してネットワークにセグメントを要求し、プレイアウトのためにそのセグメントを処理することができる。クライアントは、ネットワーク条件に依存して、異なる表現間で切り替えるように構成することができる。

ＭＰＥＧ ＤＡＳＨおよび他の適応ストリーミング解決手段は、非管理（ベスト・エフォート）ネットワークおよびインターネット上での配信のために開発された。予期されないジッタや輻輳に対処するために、そしてバッファのアンダーランのリスクを低減するために、クライアントにおいて行われるバッファリングは、コンテンツ処理デバイスのソースおよびプレイアウトの間における全エンド・ツー・エンド遅延と比較するとかなりの量になる。

ＨＡＳクライアントは、通例、プレイアウトが開始される前に、少なくとも完全なセグメント３つ分の（予め構成された）プレイアウト・バッファを使用する。このバッファは、セグメント・サイズと共に線形に増大し、したがって容易に３０秒以上に達する。更に、プレイアウト・バッファを満たすために十分なセグメントが入手できないリスクを低減するために、クライアントは、当該クライアントによって要求されることになる（ストリーミング・イベントに加入するときに）最初のセグメントが、ストリーミング・イベントに加入するときにストリーミング・ソースによって入手可能にされていたセグメントよりも早く（通例、３セグメント早い）ストリーミング・ソースによって入手可能にされるセグメントとなるように構成される。

したがって、ＨＡＳクライアントによるライブ・ストリーミング・イベントのプレイアウトと、従来のブロードキャストまたはマルチキャスト・ストリーミングのような他の移送メカニズム(transport mechanism)に基づく他のコンテンツ処理デバイスによるライブ・ストリームのプレイアウトとの間には、かなりのレイテンシ（遅延）が存在する。

管理ネットワーク（例えば、ＴＶチャネル）上におけるコンテンツ、特に、ライブ・コンテンツの配信であっても、異なる移送メカニズム（例えば、ＤＶＢ−Ｓ、ＤＶＢ−Ｃ、無線、およびＭＰＥＧ ＤＡＳＨ）によって前記コンテンツを受信することができる異なるコンテンツ処理デバイス（例えば、ＴＶ、ＳＴＢ、タブレット、スマート・フォン等）において、ほぼ同じコンテンツのプレイアウト時刻を有することが望まれる。

通例、異なるコンテンツ処理デバイス間における同期プレイアウトは、宛先間メディア同期（ＩＤＭＳ）技法によって達成することができる。ＩＤＭＳは、同期プレイアウトが達成されるように、全ての受信機のプレイアウトを最も遅れた受信機まで遅れさせることに基づく。

ＨＡＳストリーミング・デバイスと一致するように全ての他の受信機を遅延させることに伴う問題は、現在のＨＡＳ実施態様では、プレイアウト遅延が、１０秒単位程度になり得ることである。したがって、同期プレイアウトを達成することは、全ての他のデバイスを同じ量だけ遅延させなければならないことを意味する。しかしながら、多種多様なデバイスにおいて１０秒単位でメディア信号を遅延させると、予想できない問題が生ずるおそれがある。例えば、ＤＶＢ信号を受信しデコードするように構成された正規のセット・トップ・ボックス（ＳＴＢ）では、３０秒間もＤＶＢストリームを格納できる程十分なメモリを有していないこともあり得る。したがって、ＩＤＭＳ同期社会ＴＶサービス（例えば、「離れて一緒に視聴する」）は、正規のＳＴＢとＨＡＳクライアントとの間では、実現可能ではないおそれがある。

更に、ライブ・ストリーミング・アプリケーション、およびユーザの対話処理を許すストリーミング・アプリケーションでは、メディア信号の配信および提示に対して最大許容エンド・ツー・エンド遅延を有することが望ましく、場合によって法によって規定されることさえある。

以上のことから、ＨＡＳストリーミングによって混入されるプレイアウト遅延は、ユーザ体験を著しく劣化させ、ＨＡＳストリーミングの大規模な商用用途を阻害するという結果になる。

したがって、当技術分野では、高いユーザ体験を提供しつつ、最適な低レイテンシ・プレイアウトを可能にする、低レイテンシ適応ストリーミングのために改良された方法およびシステムが求められている。

特に、当技術分野では、異質なデバイスおよび配信方式に対するコンテンツの低レイテンシ適応ストリーミングを可能にする方法およびシステムが求められている。

本発明の目的は、先行技術において知られている欠点の内少なくとも１つを低減または解消することである。一態様において、本発明は、クライアント処理デバイスにおいて、ネットワークを介してクライアント、好ましくはＨＡＳ（ＨＴＴＰ−ベース適応ストリーミング）クライアントへのセグメントの低レイテンシ・ストリーミングを可能にする方法に関することができる。前記クライアントは、マニフェスト・ファイルに基づいて、セグメントをサーバ・システムに要求し受信するように構成される。前記方法は、前記ネットワークにおける監視システムが、前記クライアントと前記サーバ・システムにおける１つ以上のストリーミング・サーバとの間にある１つ以上のパスに関連付けられた品質メトリックを集め、前記品質メトリックを前記ネットワークにおける品質データベース、好ましくは、クライアント・アクセス−ライン品質データベース（ＣＡＱＤ）に格納するステップ、および／または前記コンテンツ処理デバイスに、前記格納された品質メトリックの少なくとも一部、あるいは前記格納された品質メトリックの少なくとも一部および／または１つ以上の構成パラメータに基づいて決定されたサービス品質情報を提供するステップ、
および／または、前記品質メトリックまたは前記サービス品質情報または前記構成パラメータの少なくとも一部に基づいて、前記コンテンツ処理デバイスにおける構成モジュールが、前記コンテンツ処理デバイスにおけるバッファ、好ましくは、プレイアウト・バッファ、および／または前記コンテンツ処理デバイスにおけるセグメント要求機能を構成するステップとを含むことができる。

本発明は、クライアント（コンテンツ処理デバイスに含まれる）が、前記クライアントと前記サーバ・システムにおける１つ以上のストリーミング・サーバとの間にある１つ以上のストリーミング・パスに関連付けられた品質メトリックを収容する品質データベースにアクセスすることを可能にする。品質メトリックは、自宅または住宅用ネットワーク・パラメータを含む被測定ネットワーク・パラメータ、および監視システムによって収集され品質データベースに格納される被測定デバイス・パラメータである。品質メトリックは、コンテンツ処理デバイスによって直接アクセスすることができ（例えば、コンテンツ処理デバイスに供給される／送られる）、構成モジュールによって使用することができる。代わりに、収集された品質メトリック（の少なくとも一部）の履歴に基づいて、好ましくは、予想ＱｏＳレベルを決定することもできる。このＱｏＳレベルは、好ましくは、監視システムまたは品質メトリックにアクセスすることができる他のネットワーク・エンティティによって、ネットワークにおいて決定することもできる。続いて、このＱｏＳレベルをコンテンツ処理デバイスに送ることができる。代わりに、品質メトリックは、ネットワークからクライアントに供給（送信）するのでもよく、この場合、このＱｏＳレベルは、受信された品質メトリックに基づいて、クライアントによって決定されてもよい。この情報（例えば、ＱｏＳレベル）は、ＨＡＳクライアントが（ライブ）ストリーミング・イベントに加入したいときに、バッファおよび／またはセグメント要求機能を構成するために、ＨＡＳクライアントによって（構成モジュールを介して）使用されてもよい。代わりに、品質メトリックは、予想ＱｏＳレベルを決定する中間ステップを経ずに、バッファまたはセグメント要求機能を構成するために、構成モジュールによって直接使用されてもよい。

管理されたネットワーク（例えば、帯域幅が保証される）を通じてコンテンツがストリーミングされるとき、非管理ネットワーク（公衆インターネットのような）を通じてコンテンツがストリーミングされる状況と比較して、輻輳は少なくなり、存在するレイテンシの変動もすくなくなる。管理されたネットワークを通じてコンテンツをストリーミングする場合、バッファ・アンダーランを回避するための大きなバッファ・サイズの設定値は、したがって、もはや不要となる。ＱｏＳレベルは、つまり、セグメント化コンテンツをストリーミングするために使用されるストリーミング・パスの品質（例えば、安定性）を示す。

したがって、ストリーミング・パスの品質メトリックが、一定のＱｏＳレベルが予想され得ることを示すとき、コンテンツ処理デバイスにおけるバッファ・サイズを減らす（または増やす）ことができ、プレイアウトのために、ＨＡＳクライアントがストリーミング・セッションに加入した時点において入手可能であったセグメントに（から）比較的近い（または比較的遠い）最初のセグメントを要求することができる。このように、ＨＡＳクライアントを使用するコンテンツ処理デバイスと、他のストリーミング・クライアント、例えば、高ＱｏＳレベルのネットワークにおけるＤＶＢを使用するコンテンツ処理デバイスとの間におけるプレイアウト遅延の差を、大幅に低減することができる。

一実施形態では、前記方法は、前記品質メトリックの前記少なくとも一部に基づいて、前記構成モジュールに対して前記１つ以上の構成パラメータを決定するステップを含むことができる。

一実施形態では、前記１つ以上の構成パラメータは、前記バッファにおけるデータのプレイアウトが開始される前に前記バッファのサイズを決定する、少なくとも１つのバッファ・サイズ・パラメータを含むとよい。一実施形態では、バッファのサイズを決定するために、ＭＰＥＧ ＤＡＳＨ規格において定められる通りのminBufferTimeパラメータを使用することができる。

一実施形態では、前記１つ以上の構成パラメータは、前記マニフェスト・ファイルにおいて識別されたセグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する最初のセグメントを決定する、少なくとも１つのセグメント要求パラメータ、好ましくは、segmentStartOffsetパラメータと含むとよい。

ストリーミング・パスに関連付けられた品質メトリックは、ストリーミング・パスのあるＱｏＳレベルを表す（または示す）のでもよく、クライアント・デバイス（即ち、コンテンツ処理デバイス）における構成モジュールによって、バッファ・サイズおよび／またはセグメント要求機能を構成するために使用することができる、（構成）パラメータを決定するために使用することもできる。minBufferTimeパラメータは、ＭＰＥＧ ＤＡＳＨにおいて既知のパラメータであるので、本発明は、従来のＨＡＳクライアント（デバイス）に基づいて、容易に実現することができる。

一実施形態では、本方法は、前記品質メトリックに基づいてサービス品質情報を判定するステップであって、前記サービス品質情報が、１つ以上のＱｏＳレベルを定め、ＱｏＳレベルが、前記構成モジュールに対する（によって使用される）１つ以上の所定の構成パラメータと関連付けられる。実施形態では、前記１つ以上のＱｏＳレベルが、前記ＨＡＳクライアントを低レイテンシ・モードに構成するための１つ以上の（予め構成された）構成パラメータに関連付けられた少なくとも低レイテンシ・レベル（即ち、小さなバッファ・サイズ、小さなセグメント・オフセット開始）と、前記クライアントを高レイテンシ［「正規」］モード（即ち、大きなバッファ・サイズ、大きなセグメント・オフセット開始）に構成するための１つ以上の（予め構成された）構成パラメータに関連付けられた高レイテンシ・レベル（「正規」モードとも呼ばれる）とを少なくとも含むのでもよい。したがって、サービス品質情報は、クライアントにおいて予め構成されているかもしれない異なる複数組の構成パラメータと関連付けられてもよい。このように、ＨＡＳクライアントのある（低、中間、高）レイテンシ・モードは、予想ＱｏＳレベル（モード）を含むメッセージを構成モジュールに送ることによって、選択することができる。

一実施形態では、前記１つ以上の構成パラメータの少なくとも一部が、前記監視システムによって決定され、前記品質データベースに格納されるのでもよい。

他の実施形態では、前記サービス品質情報が、前記監視システムによって判定され、前記品質データベースに格納されてもよい。他の実施形態では、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部が、前記コンテンツ処理デバイスに送られてもよい。これらの実施形態では、監視システムは、品質メトリックに基づいて、１つ以上の構成パラメータまたはサービス品質情報を判定するように構成されてもよい。代わりに、監視システムからは離れたエンティティであってもよい、他のネットワーク・エンティティ（例えば、ストリーミング・サーバ、要求導出機能を含むネットワーク・ノード、マニフェスト・ファイルを生成または更新する、および／またはコンテンツ処理デバイスへのＨＡＳ制御チャネルを設定する役割を担うネットワーク・ノード）が、データベースに格納された品質メトリックに基づいて、これらのパラメータを決定してもよい。これらの構成パラメータは、クライアントに送ることができる。ネットワークにおいて品質メトリック（の一部）を処理する（例えば、監視サーバ）ことによってクライアント側における処理パワーを節約することにより、クライアント側における処理時間を節約することができる。

一実施形態では、本方法は、前記クライアントが、マニフェスト・ファイルまたはマニフェスト・ファイル更新の少なくとも一部を前記サーバ・システムに要求するステップと、前記サーバ・システムが、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部を前記品質データベースから引き出すステップと、前記サーバ・システムが、前記品質メトリック、および／または前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部を含むマニフェスト・ファイルの少なくとも一部を前記クライアントに送るステップの内少なくとも１つを含むこともできる。したがって、品質メトリック、ＱｏＳ情報、および／または構成パラメータは、マニフェスト・ファイルにおいてクライアントに送ることができる。このように、ＨＡＳクライアントを構成する必要がある時点で、即ち、クライアントがストリーミング・セッションに加入したい時点で、この情報がクライアントに送られる。

一実施形態では、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の少なくとも一部が、別の通信チャネルを通じてクライアントまたは構成モジュールに送られる。実施形態では、通信チャネルは、マニフェスト・ファイルにおける監視システムに関連付けられた位置情報、例えば、ＵＲＬまたはＵＲＩに基づいて、監視システム（または監視システムに関連付けられた品質データベース）間に確立することができる。代わりに、このような通信チャネルは、コンテンツ処理デバイスと通信するように構成された他のネットワーク・エンティティ（ノード）と、コンテンツ処理デバイスとの間に確立されてもよい。

一実施形態では、通信チャネルが（ＨＡＳ）ストリーミング制御チャネル、好ましくは、Websocketベースのストリーミング制御チャネルであってもよい。実施形態では、前記方法が、前記サーバ・システムと前記クライアントとの間に（双方向）ストリーミング制御チャネルを設定するためのチャネル設定情報を前記クライアントに提供するステップであって、前記ストリーミング制御チャネルが好ましくはWebsocketストリーミング制御チャネルである、ステップと、前記チャネル設定情報に基づいて、前記（双方向）ストリーミング制御チャネルを確立するステップと含むこともできる。ＨＴＴＰベースの（Websocket）ストリーミング・チャネルは、ネットワークにおけるサーバが、ＨＡＳクライアント・メッセージ、例えば、マニフェスト更新要求またはサービス品質要求を、セグメントのストリーミングの間に、ストリーミング・パスを通じて送ることを可能にする。更に、実施形態では、ＨＡＳストリーミング制御チャネルは、マニフェスト・ファイルを介してクライアントに送られるチャネル設定情報に基づいて、構成することもできる。

一実施形態では、前記方法が、前記コンテンツ処理デバイスにおける少なくとも第１監視エージェントが、前記コンテンツ処理デバイスに関連付けられた第１メトリックを収集するステップ、および／または前記ネットワークにおける少なくとも第２監視エージェントが、前記ネットワークの少なくとも一部に関連付けられた第２メトリックを収集するステップと、前記第１および／または第２メトリックに基づいて、前記監視システムが、前記サーバ・システムにおける前記１つ以上のストリーミング・サーバと前記クライアントとの間における１つ以上のパスに関連付けられた品質メトリックを判定するステップと、前記品質メトリックを前記品質データベースに格納するステップとを含むこともできる。

したがって、リアル・タイムＱｏＳ（サービス品質）およびＱｏＥ（体験品質）メトリック（以後品質メトリックと呼ぶ）をクライアントおよびネットワークから集めるように構成された二点間監視システムを使用することができる。監視システムをインターネット・サービス・プロバイダ（ＩＳＰ）ネットワークに配置すると、クライアントと１つ以上のストリーミング・サーバとの間における１つ以上のストリーミング・パスに関連付けられたサービス品質情報を判定するために、品質メトリックを使用することができる。

監視システムは、ホーム・ネットワークにおいて使用される異なるデバイス間で区別することによって、このホーム・ネットワークにおけるソース・パケット逸失、ホーム・ネットワークの負荷変動、端末の能力、ホーム・ネットワーク内において利用可能な帯域幅を考慮に入れることができるように構成することができる。このように、同じホーム・ゲートウェイに接続された異なるＨＡＳストリーミング・デバイス、例えば、テレビジョンおよび電子タブレットのようなワイヤレス移動体デバイスを、異なる品質メトリックに基づいて構成することができる。

一実施形態では、マニフェスト・ファイルは、１つ以上のレイテンシ・モード（例えば、低、中間、および／または高、または代わりに「低」および「正規」）に関する情報を含むこともできる。この情報は、クライアントに入手可能である。一実施形態では、各レイテンシ・モードが、１組の構成パラメータと関連付けられてもよい。

更に他の態様では、本発明は、少なくとも１つのネットワークを通じたセグメントのコンテンツ処理デバイスへの低レイテンシ・ストリーミングを可能にするコンテンツ配信システムに関することができる。前記システムは、クライアント、好ましくは、ＨＡＳクライアントを含むコンテンツ処理デバイスであって、前記クライアントが、マニフェスト・ファイルに基づいて、１つ以上のストリーミング・サーバにセグメントを要求し受信するように構成される、コンテンツ処理デバイスと、
前記コンテンツ処理デバイス、好ましくは前記クライアント処理デバイスにおけるクライアントが、更に、前記格納された品質メトリックの少なくとも一部、あるいは前記格納された品質メトリックおよび／または１つ以上の構成パラメータの少なくとも一部に基づいて判定されるサービス品質情報が供給されるように構成され、
前記クライアントと前記１つ以上のストリーミング・サーバとの間における１つ以上のパスに関連付けられた品質メトリックを収集し、前記品質メトリックを前記ネットワークにおける品質データベースに格納するように構成された監視システムと、
前記コンテンツ処理デバイスにおいて、前記品質メトリックおよび／または前記サービス品質情報、および／または前記構成パラメータの少なくとも一部に基づいて、前記コンテンツ処理デバイスにおいてバッファ、好ましくは、プレイアウト・バッファを構成し、および／または前記コンテンツ処理デバイスにおいてセグメント要求機能を構成する構成モジュールと、
を含むことができる。

更に他の態様では、本発明は、コンテンツ処理デバイスにおける使用のための構成モジュールに関するのでもよく、前記構成モジュールが、前記コンテンツ処理デバイスにおいて、クライアント、好ましくは、ＨＡＳクライアントへの低レイテンシ・ストリーミングを可能にするように構成され、前記クライアントが、マニフェスト・ファイルに基づいて、サーバ・システムにおける１つ以上のストリーミング・サーバにセグメントを要求し受信するように構成される。前記構成モジュールは、更に、品質メトリックに基づいて、および／または前記格納された品質メトリックの少なくとも一部に基づいて、および／または１つ以上の構成パラメータに基づいて判定されるサービス品質情報に基づいて、前記コンテンツ処理デバイスにおいて、バッファ、好ましくは、プレイアウト・バッファ、および／または前記コンテンツ処理デバイスにおいてセグメント要求機能を構成し、前記品質メトリックが、前記クライアントと前記サーバ・システムにおける１つ以上のストリーミング・サーバとの間における１つ以上のパスと関連付けられ、前記品質メトリックが、前記ネットワークにおける監視システムによって収集され、前記ネットワークにおける品質データベースに格納されるように構成される。

一実施形態では、前記バッファが、１つ以上の構成パラメータ、好ましくは、minBufferTimeパラメータに基づいて、前記バッファにおいてデータのプレイアウトが開始される前に、前記バッファのサイズを決定するように構成されてもよく、および／または前記セグメント要求機能が、１つ以上の構成パラメータ、好ましくは、segmentStartOffsetパラメータに基づいて、前記マニフェスト・ファイルにおいて識別された前記セグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する第１セグメントを決定するように構成される。

一態様において、本発明は、コンテンツ処理デバイスにおけるＨＡＳクライアントとストリーミング・サーバとの間のネットワークにおけるストリーミング・パスに関連付けられた品質メトリックを監視する監視システムに関することができる。前記監視システムは、前記コンテンツ処理デバイスに関連付けられたデバイス・メトリックと、１つ以上の監視エージェントからの前記ネットワークの少なくとも一部に関連付けられたネットワーク・メトリックとを収集する手段と、前記デバイスおよび前記ネットワーク・メトリックに基づいて、ストリーミング・パスに関連付けられた品質メトリックを判定する手段と、前記品質メトリックの前記少なくとも一部に基づいて、前記コンテンツ処理デバイスにおける構成モジュールに対する１つ以上の構成パラメータを判定する手段であって、前記１つ以上の構成パラメータが、前記バッファにおけるデータのプレイアウトが開始される前に前記バッファのサイズを決定するための少なくとも１つのバッファ・サイズ・パラメータ、好ましくは、minBufferTimeパラメータ、および／または前記マニフェスト・ファイルにおいて識別された前記セグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する第１セグメントを決定するための少なくとも１つのセグメント要求パラメータ、好ましくは、segmentStartOffsetパラメータとを含む、手段とを含む。

一態様において、本発明は、データ構造、好ましくは、コンテンツ処理デバイスにおいてクライアントによる使用のためのマニフェスト・ファイルの少なくとも一部に関することができ、前記クライアントが、前記マニフェスト・ファイルに基づいて、少なくとも１つのサーバにセグメントを要求し受信するように構成され、前記データ構造が、前記クライアントへの低レイテンシ・ストリーミングを可能にし、前記データ構造が、１つ以上のセグメント識別子とセグメント・プレイアウト情報とを含み、前記データ構造が、更に、
品質メトリック、および／または前記クライアントとストリーミング・サーバとの間のストリーミング・パスに関連付けられた１つ以上のＱｏＳレベルを含むサービス品質情報を含み、前記品質メトリックおよび／または前記サービス品質情報が、前記クライアントに関連付けられた構成モジュールが、バッファ、好ましくは、プレイアウト・バッファおよび／または前記コンテンツ処理デバイスにおけるセグメント要求機能に対する１つ以上の構成パラメータを決定することを可能にし、および／または前記データ構造が、更に、前記クライアントと前記ストリーミング・サーバとの間のストリーミング・パスに関連付けられた１つ以上の構成パラメータを含み、前記１つ以上の構成パラメータが、前記コンテンツ処理デバイスにおいて、前記クライアントに関連付けられた構成モジュールが、バッファ、好ましくは、プレイアウト・バッファおよび／またはセグメント要求機能を構成することを可能にする。

また、本発明は、プログラム製品にも関することができ、コンピュータ・プログラム製品は、コンピュータのメモリにおいて実行されると、以上で説明したように、方法ステップを実行するように構成されたソフトウェア・コード部分を含む。本発明について、本発明による実施形態を模式的に示す添付図面を参照しながら、更に例示する。尚、本発明はこれらの具体的な実施形態には全く限定されないことは理解されよう。

図１は、本発明の一実施形態によるコンテンツ配信システムの模式図を示す。 図２は、本発明の一実施形態によるマニフェスト・ファイルの模式図を示す。 図３は、本発明の実施形態にしたがってマニフェスト・ファイルを更新するプロセスを示す。 図４は、本発明の一実施形態にしたがって、セグメントをクライアントに配信するプロセスを示す。 図５は、本発明の他の実施形態によるコンテンツ配信システムの模式図を示す。 図６は、本発明の更に他の実施形態によるマニフェスト・ファイルの模式図を示す。 図７は、本発明の他の実施形態にしたがってセグメントをクライアントに配信するプロセスを示す。 図８は、本発明の実施形態にしたがってメトリックを収集するプロセスを示す。 図９は、本発明の実施形態による、コンテンツ処理デバイスとサーバとの間におけるプロトコル・フローを示す。 図１０は、本発明の実施形態にしたがってメトリックを報告するためのプロトコル・フォーマットを示す。 図１１は、本発明の他の実施形態にしたがってメトリックを報告するための他のプロトコル・フォーマットを示す。 図１２は、本発明の実施形態にしたがってメトリックを報告するための更に他のフォーマットを示す。 図１３は、本発明の更に他の実施形態による、サービス品質情報を含むマニフェスト・ファイルの模式図を示す。 図１４は、本発明の実施形態にしたがって、ＡＬＴＯプロトコルに基づいてサービス品質情報を要求するプロトコル・フローを示す。

当業者には認められるであろうが、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することができる。したがって、本発明の態様は、全体的にハードウェアの実施形態、全体的にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロ・コード等を含む）、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態という形態を取ることができ、これらを全て本明細書では、総称的に「回路」、「モジュール」、または「システム」、「ノード」と呼ぶことができる。更に、本発明の態様は、コンピュータ読み取り可能プログラム・コードが具体化された１つ以上のコンピュータ読み取り可能媒体において具体化されたコンピュータ・プログラム製品の形態を取ることもできる。

本明細書において説明する機能ユニットの多くは、更に特定してそれらの実現独立性を強調するためにモジュールと呼ばれている。例えば、モジュールは、カスタムＶＬＳＩ回路またはゲート・アレイ、論理チップのようないつでも買える半導体、トランジスタ、またはその他のディスクリート・コンポーネントを含むハードウェア回路として実現することができる。また、モジュールは、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ・ロジック、プログラマブル・ロジック・デバイス等のような、プログラマブル・ハードウェア・デバイス内に実現することもできる。

また、モジュールは、種々のタイプのプロセッサによる実行のためのソフトウェアで実現することもできる。コンピュータ読み取り可能プログラム・コードの識別されたモジュールは、例えば、オブジェクト、プロシージャ、または関数として編成することができるコンピュータ命令の、例えば、１つ以上の物理ブロックまたは論理ブロックを含むことができる。しかしながら、識別されたモジュールの実行可能ファイルは、物理的に一緒に位置する必要はなく、異なる位置に格納された異質の命令を含むこともでき、これらが論理的に一緒に集められると、そのモジュールを構成し、そのモジュールのために述べられた目的を達成する。

実際、コンピュータ読み取り可能プログラム・コードのモジュールは、１つの命令、または多くの命令でもよく、様々な異なるコード・セグメントにわたって、異なるプログラム間で、そして様々なメモリ・デバイスにまたがって分散させることさえもできる。同様に、動作データは、本明細書では、モジュール内部で識別および例示することができ、任意の適した形態で具体化し、任意の適したタイプのデータ構造内で編成することができる。動作データは、１つのデータ集合として収集することができ、または異なる記憶デバイスを含む異なる場所にわたって分散させることもでき、少なくとも部分的に、システムまたはネットワーク上において単なる電子信号として存在することもできる。モジュールまたはモジュールの一部がソフトウェアで実現される場合、コンピュータ読み取り可能プログラム・コードは、１つ以上のコンピュータ読み取り可能媒体（１つまたは複数）において格納することおよび／または伝搬することができる。

コンピュータ読み取り可能媒体は、コンピュータ読み取り可能プログラム・コードを格納する有形コンピュータ読み取り可能記憶媒体であってもよい。コンピュータ読み取り可能記憶媒体は、例えば、電子、磁気、光、電磁、赤外線、ホログラフ、微小機械、または半導体システム、装置、またはデバイス、あるいは以上のものの任意の適した組み合わせであってもよいが、これらに限定されるのではない。

コンピュータ読み取り可能媒体の更に具体的な例には、可搬型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（「ＲＡＭ」）、リード・オンリー・メモリ（「ＲＯＭ」）、消去可能プログラマブル・リード・オンリー・メモリ（「ＥＰＲＯＭ」または「フラッシュ・メモリ」）、可搬型コンパクト・ディスク・リード・オンリー・メモリ（「ＣＤ−ＲＯＭ」）、ディジタル・バーサタイル・ディスク（「ＤＶＤ」）、光記憶デバイス、磁気記憶デバイス、ホログラフ記憶媒体、微小機械記憶デバイス、または以上のものの任意の適した組み合わせを含むことができるが、これらに限定されるのではない。本文書のコンテキストでは、コンピュータ読み取り可能記憶媒体は、命令実行システム、装置、またはデバイスによる使用のためにおよび／またはこれと関連付けて、コンピュータ読み取り可能プログラム・コードを収容および／または格納することができる任意の有形媒体であればよい。

また、コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体であってもよい。コンピュータ読み取り可能信号媒体は、例えば、ベースバンドにまたは搬送波の一部として、コンピュータ読み取り可能プログラム・コードが内部に具体化された伝搬データ信号を含むことができる。このような伝搬信号は、電子、電磁、磁気、光、またはこれらの任意の適した組み合わせを含むがこれらに限定されない種々の形態の内いずれでも取ることができる。コンピュータ読み取り可能信号媒体は、コンピュータ読み取り可能記憶媒体ではなく、命令実行システム、装置、またはデバイスによる使用のために、またはそれと関連付けて、コンピュータ読み取り可能プログラム・コードを通信、伝搬、または移送(transport)ことができる、任意のコンピュータ読み取り可能媒体とすることができる。コンピュータ読み取り可能信号媒体上に具体化されたコンピュータ読み取り可能プログラム・コードは、ワイヤレス、ワイヤライン、光ファイバ・ケーブル、無線周波数（「ＲＦ」）等、または以上のものの任意の適した組み合わせを含むがこれらに限定されない、任意の適した媒体を使用して送信することができる。

一実施形態では、コンピュータ読み取り可能媒体は、１つ以上のコンピュータ読み取り可能記憶媒体および１つ以上のコンピュータ読み取り可能信号媒体の組み合わせを含むことができる。例えば、コンピュータ読み取り可能プログラム・コードは、プロセッサによる実行のために光ファイバ・ケーブルを通じて電磁信号として伝搬され、プロセッサによる実行のためにＲＡＭ記憶デバイスに格納することの双方が可能である。

本明細書全体を通じて「一実施形態」(one embodiment)、「実施形態」(an embodiment)、または同様の文言を引用する(reference)ときは、その実施形態と関連付けて説明される特定の特徴、構造、または特性が、少なくとも１つの実施形態に含まれることを意味する。つまり、本明細書全体を通じて、「一実施形態において」、「実施形態において」という句、または同様の文言が現れるときは、全て同じ実施形態を指すことができるが必ずしもそうではなく、別段明示的に指定されなければ、「１つ以上であるが全てではない実施形態」を意味する。「含む」(including)、「備える」(comprising)、「有する」(having)という用語、およびその変形は、別段明示的に指定されなければ、「含むが限定されない」ことを意味する。品目を列挙するリストは、別段明示的に指定されなければ、これらの品目のいずれかまたは全てが相互に排他的であることを暗示するのではない。「ａ」、「ａｎ」、および「ｔｈｅ」という用語も、別段明示的に指定されなければ、「１つ以上」を指す。

更に、実施形態の説明される特徴、構造、または特性は、任意の適したやり方で組み合わせることもできる。以下の説明では、実施形態の完全な理解を得るために、プログラミング、ソフトウェア・モジュール、ユーザ選択、ネットワーク・トランザクション、データベース・クエリー、データベース構造、ハードウェア・モジュール、ハードウェア回路、ハードウェア・チップ等の例というような、多数の具体的な詳細が示される(provide)。しかしながら、これらの具体的な詳細の内１つ以上がなくても、または他の方法、コンポーネント、材料等を使用しても、実施形態を実施できることは、当業者には認められよう。他方では、周知の構造、材料、または動作は、実施形態の態様を曖昧にするのを避けるために、詳細に示したり説明することはしない。

本発明の実施形態による方法、装置、システム、およびコンピュータ・プログラム製品の模式流れ図および／または模式ブロック図を参照して、以下に実施形態の態様について説明する。尚、模式流れ図および／または模式ブロック図の各ブロック、ならびに模式流れ図および／または模式ブロック図におけるブロックの組み合わせは、コンピュータ読み取り可能プログラム・コードによって実現できることは、理解されよう。これらのコンピュータ読み取り可能プログラム・コードは、機械を生成するために、汎用コンピュータ、特殊目的コンピュータ、シーケンサ、またはその他のプログラマブル・データ処理装置のプロセッサに供給することができ、命令が、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサによって実行されると、模式流れ図および／または模式ブロック図の１つまたは複数のブロックにおいて指定される機能／アクトを実施するための手段が形成されるようになっている。

図１は、本発明の一実施形態によるコンテンツ配信システムの模式図を示す。具体的には、図１は、サーバ・システム１０２を含むコンテンツ配信システムの模式図を示す。サーバ・システム１０２は、コンテンツ処理デバイス１０６における少なくとも１つのクライアント１０４にコンテンツをストリーミングするように構成される。サーバ・システム１０２は、１つ以上のストリーミング・サーバを含むことができる。ストリーミング・サーバは、１つ以上のコンテンツ信号１０８、例えば、（ライブ）ビデオおよび／またはマルチメディア信号を受信し、セグメント化コンテンツ・ストリームを生成するために、コンテンツ信号を処理するように構成される。

以下で更に詳細に説明するが、セグメント化コンテンツ・ストリームの生成は、コンテンツ信号を所定サイズの分離セグメントに分割することを含むのでもよく、各セグメントは多数の異なる表現にエンコードすることができる。ここで、表現は、２Ｄおよび３Ｄフォーマット、異なるビデオおよび／またはオーディオ品質（例えば、ＳＤ／ＨＤ、ビットレート等）、異なる空間解像度等を含む、コンテンツ信号の異なる異形(variants)に関係することができる。

セグメント化コンテンツ・ストリームの生成の間、１つ以上のマニフェスト・ファイル（ＭＰＥＧ−ＤＡＳＨではメディア・プレゼンテーション記述またはＭＰＤとしても知られ、Ａｐｐｌｅ ＨＴＴＰライブ・ストリームではＭ３Ｕ８プレイ・リストとしても知られる）を生成することができる。ここで、「マニフェスト・ファイル」という用語は、コンテンツ項目、例えば、ビデオ・タイトルを形成するセグメントを識別するセグメント識別子（記述子）を含むことができる、特殊データ構造を一般に指すことができる。更に、これは（１組の）ネットワーク・ノード（１つまたは複数）の位置情報、例えば、（メディア）ストリーミング・サーバ（１つまたは複数）も含むことができる。ストリーミング・サーバは、セグメントをクライアントに配信するように、またはクライアントに情報を提供しそこでセグメントを引き出すことができるように構成することができる。マニフェスト・ファイルは、更に、セグメントとメディア・メタデータとの間における（基幹的）関係を判断するためのセグメント・プレイアウト情報も含むことができる。メディア・メタデータは、ビデオ解像度、ビット・レート等のような、メディア特性に関する情報を含む。

異なる表現に関連付けられたマニフェスト・ファイルおよびセグメントは、サーバ・システム、例えば、セグメント記憶ノード１１０およびマニフェスト記憶ノード１１２における所定位置に格納することができる。実施形態では、マニフェスト・ファイルの位置は、ＵＲＬまたはＵＲＩとして格納することができる。特定のコンテンツ項目を要求するとき、サーバ・システムはマニフェスト・ファイルのＵＲＬまたはＵＲＩをクライアントに供給することができる。

ユーザが（ライブ）ストリーミング・イベントに加入するときまたはストリーミング・サービスを開始したいとき、ウェブ・ページからイベントまたはサービスを選択することができる。選択の後、サーバ・システムにおける（ＨＴＴＰ）ストリーミング機能１１６が、そのストリーミング・イベントまたはサービスに関連付けられたマニフェスト・ファイルを、ネットワーク接続１１４を介してクライアントに送ることができる。実施形態では、ストリーミング機能は、サーバ・システムにおけるＨＴＴＰサーバ上に実装することができる。

クライアントは、マニフェスト・ファイルを解析し、マニフェスト・ファイルにおける情報を使用して、セグメント化ストリームをサーバ・ストリームのストリーミング・サーバに要求し、ネットワークを通じてクライアントに送られるセグメントを受信するように構成することができる。ストリーミングの間、セグメントに関連付けられたパケットは、ネットワークにおける１つ以上の経路に従うことができる。このような経路を、以後「ストリーミング・パス」と呼ぶ場合もある。クライアントとストリーミング・サーバとの間のストリーミング・パスは、ＨＴＴＰ／ＴＣＰプロトコルに基づいて確立することができる。

そのために、サーバ・システムはＨＴＴＰサーバを含むことができる。ＨＴＴＰサーバは、ＨＴＴＰ適応ストリーミング（ＨＡＳ）プロトコルに基づいて、セグメントをクライアントに送るように構成される。このような方式では、クライアント（ＨＡＳクライアント）はセグメントを求めるＨＴＴＰ要求をＨＴＴＰサーバに送ることができ、ＨＴＴＰサーバは、応答して、特定の表現の１つ以上のセグメントを、ＨＴＴＰ応答メッセージ内においてクライアントに送る。クライアントへのセグメントのストリーミングの間、セグメントはクライアントの受信バッファ１１８にバッファされる。セグメントにおいてエンコードされカプセル化されたセグメント・データ（フレーム）は、プレイアウト・バッファ１２０において、アンパック(unpack)、デコード、および配列することができる。プレイアウト・バッファにおけるデータは、コンテンツ・ストリームのプレゼンテーション・タイムラインにしたがって配列することができる。続いて、メディア・エンジン１２２は、プレイアウト・バッファ内のデータをユーザに表示することができる。

適応ストリーミング・プロトコルの例には、Apple HTTP Live Streaming（アップルＨＴＴＰライブ・ストリーミング）[http://tools.ietf.org/html/draft-pantos-http-live-streaming-07]、Microsoft Smooth Streaming（マイクロソフト・スムーズ・ストリーミング）[http://www.iis.net/download/ SmoothStreaming]、Adobe HTTP Dynamic Streaming（アドービＨＴＴＰダイナミック・ストリーミング）[http://www.adobe.com/products/httpdynamicstreaming]、3GPP-DASH [TS26.247 Transparent end-to-end Packet-switched Streaming Service（ＰＳＳ：packet-switched Streaming Service：パケット交換ストリーミング・サービス）、Progressive Download and Dynamic Adaptive Streaming over HTTP（ＨＴＴＰ上累進ダウンロードおよび動的適応ストリーミング）、およびMPEG Dynamic Adaptive Streaming over HTTP [MPEG DASH ISO/IEC 23001-6]が含まれる。ＨＴＴＰは、セグメントをクライアントに配信するための効率的で、ファイアウォールが簡単で(Firewall-friendly)、スケーラブルな方式を可能にする。

コンテンツ処理デバイスは、一般に、電子タブレット、スマート・フォン、ノートブック、メディア・プレーヤ、ホーム・ゲートウェイ、またはＤＡＳＨ対応ＨｂｂＴＶディスプレイ・デバイスのようなＤＡＳＨ対応デバイス等の、（移動体）コンテンツ・プレイアウト・デバイスに関係すればよい。あるいは、コンテンツ処理デバイスは、格納されたコンテンツにアクセスすることができるコンテンツ・プレイアウト・デバイスによる今後の消費のために、コンテンツを処理し一時的に格納するように構成されたセット・トップ・ボックスまたはコンテンツ記憶デバイスであってもよい。

同様に、サーバ・システムは、１つ以上のＨＴＴＰストリーミング・サーバを含む、１つ以上のストリーミング・サーバを含むことができる。あるいは、サーバ・システムは１つ以上のコンテンツ配信ネットワーク（ＣＤＮ）（の一部）を含むのでもよい。ＣＤＮ（図示せず）は、１つ以上のエッジ・ノード（配信ノードまたは代用ノードとも呼ばれる）と、少なくとも１つの中央ＣＤＮノードとを含むことができる。中央ＣＤＮノードは、外部ソース（例えば、コンテンツ・プロバイダまたは他のＣＤＮ）からＣＤＮへのコンテンツの収集(ingestion)を制御するコンテンツ起源機能（ＣＯＦ：content origin function）と、セグメントの１つ以上のコピーの配信ノードへの配給を制御し、クライアントをしかるべき配信ノードにリディレクトするＣＤＮ制御機能（ＣＤＮＣＦ）（要求ルーティングとしても知られるプロセス）とを含むことができる。ＣＤＮ内においてセグメントがどこに格納されるかについての情報（例えば、どの配信ノードか、そして配信ノードにおけるどのフォルダか）を格納するために、コンテンツ位置データベースを使用することもできる。

一実施形態では、ＣＤＮは、ＣＤＮによって収集された後に、（ライブ）メディア・ストリームを処理するように構成されたコンテンツ処理機能を含むことができる。コンテンツ処理機能は、コンテンツ信号の（リアル・タイムの）異なるバージョン（表現）を生成するエンコーダを含むことができる。その後、コンテンツ信号は、所定サイズのセグメントに区分され、各セグメントに特定の表現を関連付けることができる。例えば、コンテンツ信号の１つの表現が、所定の品質（例えば、高、平均、および低ビットレート）のセグメントを含むこともできる。これらのセグメントは、適したトランスポート・プロトコル・フォーマット、例えば、ＭＰＥＧに基づく方式にしたがってカプセル化することができる。実施形態では、セグメントに区分される前に、セグメントを暗号化および／またはスクランブルすることもできる。ライブ・ストリームに関連付けられたセグメントは、コンテンツ消費デバイスがそれらにアクセスできるようになる前に、ＣＤＮの１つ以上の配信ノード・サーバにおいて一時的に格納（バッファ）されてもよい。

変化するネットワーク条件に応答して（例えば、ストリーミング・パスを通じてクライアントに送られるデータ（セグメント）に起こる可変遅延）、ストリーミング・プロトコルは、適応パラメータとしてバッファ・ステータスを使用することができる適応アルゴリズムにしたがって、クライアントへのセグメントのストリーミングの間表現の動的な適応（例えば、高品質表現から低品質表現へ、またはその逆への切り替え）に対処することができる。プレイアウト・バッファがアンダーラン・ステータスに近づく場合、クライアントは表現を第１表現から第２（それよりも低い品質）表現に変更する（適応させる）ことができる。

この場合、クライアントにおけるセグメント要求機能１２５が、要求された表現に関連付けられたセグメントをマニフェスト・ファイルから選択し、これらのセグメントに基づいてストリーミング・プロセスを継続することができる。このように、クライアントは、変化するネットワーク条件（バッファ・ステータスに反映される）に応答して、ストリーミング・プロセスを適応させることができる。これは、インターネットのような非管理ネットワーク上でコンテンツがストリーミングされるときには非常に大切になることもある。

従来のＨＡＳクライアント構成では、プレイアウト・バッファのサイズは予め構成されており、通常比較的大きい（例えば、３つ以上のセグメント程度のサイズ）。予期しないジッタや輻輳に対処するために、そしてバッファ・アンダーランが発生する機会を減らすために、クライアントにおいて行われるバッファリングは、ソースとコンテンツ処理デバイスのプレイアウトとの間の全エンド・ツー・エンド遅延に比較して、相当大きくなっている。このように、従来のＨＡＳクライアントは、インターネットのような非管理ネットワークにおいて起こり得る変動状況に対処するように構成される。

エンド・ツー・エンド遅延は、セグメントの作成およびエンコーディングに伴う遅延、セグメントのコンテンツ配信ネットワーク（ＣＤＮ）への配給に伴う遅延、およびＣＤＮ内部におけるセグメントのそのエッジ・ノードへの内部配給に伴う遅延、ＣＤＮへのセグメントの要求およびクライアントへのセグメントの配信（ネットワークおよびホーム・ネットワークを介して）に伴う遅延、およびコンテンツ処理デバイスにおけるセグメントの処理に伴う遅延を含むことができる。これらの遅延は、例えば、バッファリングおよびデコーディング・プロセスによる遅延を含む場合もある。

バッファを満たすために入手可能なセグメントが十分にないというリスクを低減するために、従来のクライアントは、更に、クライアントによって要求されることになる（ストリーミング・イベントに加入するとき）最初のセグメントが、ストリーミング・イベントに加入するときにストリーミング・ソースによって入手可能にされていたセグメントよりも早く（通例、３セグメント早い）ストリーミング・ソースによって入手可能にされるセグメントとなるように構成される。

したがって、ストリーミングを開始するとき、これは「過去に戻る」セグメントを要求し、プレーアウト・バッファにおいてデータのデコーディングおよびプレイアウトが開始する前に、プレイアウト・バッファは、構成されたサイズまでセグメントで満たされる。バッファおよびセグメント要求機能の構成により、大きなプレイアウト・バッファが必要でない場合であっても、ＨＡＳクライアントによるライブ・ストリーミング・イベントのプレイアウトと、従来のブロードキャストまたはマルチキャスト・ストリーミングのような他のトランスポート・メカニズムに基づく他のコンテンツ処理デバイスによるライブ・ストリームのプレイアウトとの間には、相当大きなレイテンシ（遅延）が存在する。これらの遅延は、既知のＩＤＭＳ技法によって解決することはできない。

例えば、場合によっては、ストリーミング・イベントおよびストリーミング・サービスが、管理されたネットワーク、例えば、ネットワーク運営会社のＩＰネットワークを通じて配信されることもあり得る（少なくとも部分的に配信される）。これは、所定のサービス品質（ＱｏＳ）にしたがって管理される。このようなネットワークにおける遅延の変動は、非管理ネットワークのネットワーク遅延と比較すると、遙かに小さく、そして遙かに予測可能で安定であると考えられる。

これらの望ましくない影響に対処するために、一実施形態では、コンテンツ処理モジュールが構成モジュール１２６を含むことができる。構成モジュール１２６は、サーバ・システムとコンテンツ処理デバイスとの間におけるストリーミング・パス１１４に関連付けられた品質メトリックに基づいて、プレイアウト・バッファのサイズを適応させるように構成される。更に他の実施形態では、構成モジュールは、クライアントにおけるセグメント要求機能１２５を、品質メトリックに基づいて構成することができ、これによって、クライアントが（ライブ）ストリーミング・イベントに加入するときに、どのセグメントがこのクライアントによって最初に要求されるかについて、セグメント要求機能が判定することを可能にする。

ストリーミング・パスの品質メトリックは、監視システム１２８によって判定することができる。監視システム１２８は、品質メトリックを１つ以上の監視エージェント１２４、１３０から受信することができる。実施形態では、監視システムは、コンテンツ処理デバイスにおける監視エージェント１２４からデバイス品質メトリックを受信することができる。デバイス監視エージェント１２４は、デバイス品質メトリックを集めるように構成することができる（即ち、受信バッファおよび／またはプレイアウト・バッファのセグメント受信時刻、バッファ過負荷およびアンダーラン、セグメント・プレイアウト時刻等というような、コンテンツ処理デバイス上で実行されるセグメントの引き出しおよびプレイアウト・プロセスに関連付けられた測定パラメータ）。デバイス監視エージェントは、これらのパラメータを、クライアント１０４、受信バッファ１１８、プレイアウト・バッファ１２０、およびメディア・エンジン１２２から引き出し、これらのデバイス品質メトリックを、サーバ・システムに関連付けられた監視システム１２８に送ることができる。品質メトリックを集めて処理するプロセスについては、以下で図２を参照しながら更に詳細に説明する。

他の実施形態では、監視システムは、ネットワーク品質メトリックを、ネットワークにおける１つ以上のネットワーク監視エージェント１３０から受信することもできる。ネットワーク監視エージェントは、ネットワークからの、ネットワークのリアル・タイムサービス品質（ＱｏＳ）および／または体験品質（ＱｏＥ）メトリック（ネットワーク品質メトリック）を測定して集め、これらのネットワーク品質メトリックの少なくとも一部を、クライアントとサーバ・システムの１つ以上のストリーミング・サーバとの間にある１つ以上のストリーミング・パスと相関付けるように構成することができる。

監視エージェントは、メトリックを終端間毎に(on an end-to-end basis)で集めることができる。即ち、ホーム・ネットワーク、およびこのホーム・ネットワークに接続されるタイプのデバイスに関連付けられたメトリックまで集め、これらを含むことによって、ホーム・ネットワークにおけるソース・パケットの逸失、ホーム−ネットワークの負荷変動、端末の能力、ホーム−ネットワーク内で利用可能な帯域幅も考慮に入れる。監視エージェントは、異なるアクセス・ネットワーク、例えば、ＷＬＡＮまたはＷｉ−Ｆｉネットワークによってサーバ・システムに接続される異なるデバイスを区別することができるように、ＩＰアドレスおよび／またはネットワーク識別子に基づいて品質メトリックを集めることができる。一実施形態では、監視エージェントは、ＨＴＴＰ−ベース通信チャネル１３１を通じて監視システムと通信することができる。

コンテンツのクライアントへのストリーミングの間、監視システムは、クライアントとサーバ・システムとの間にあるストリーミング・パスに関連付けられた品質メトリックを集めて、この品質メトリックを品質データベース１３２に格納することができる。実施形態では、品質メトリックをＱｏＳクライアント・プロファイルに格納することができる。十分なデータが集められると、品質データベースにおけるＱｏＳクライアント・プロファイルは、十分に信頼性のある品質メトリックを含むことができ、ＨＡＳクライアントが（ライブ）ストリーミング・イベントに加入するときに、このクライアントによって最初に要求されるのはどのセグメントか判定するために、プレイアウト・バッファおよび／またはセグメント要求機能を構成するために使用することができる。

クライアントがストリーム・イベントに加入することをサーバ・システムに要求したとき、例えば、このストリーミング・イベントに関連付けられたマニフェストを要求または受信したとき、要求側クライアントのＱｏＳクライアント・プロファイルにアクセスし、品質メトリックを引き出し、構成モジュール１２６によって使用することができるようにこれを処理することができる。構成モジュールを処理し命令する種々の方法については、以下で更に詳細に説明する。

一実施形態では、品質メトリックの少なくとも一部が、コンテンツ処理デバイスの構成モジュールに送られ、コンテンツ処理デバイスは、前記バッファにおけるデータのプレイアウトが開始される前にバッファのサイズを決定するために、および／またはセグメント要求機能がストリーミング・サーバに要求する、マニフェスト・ファイルにおいて識別されたセグメントからの最初のセグメントを決定するために、１つ以上の構成パラメータ１３４、１３５を決定することができる。あるいは、監視システムは、前記１つ以上の構成パラメータを決定し、これらのパラメータを構成モジュールに送ることもできる。

代わりにおよび／または加えて、他の実施形態では、監視システムが、品質メトリックに基づいてＱｏＳ情報および／または１つ以上の構成パラメータを決定し、この情報をＱｏＳクライアントに格納することもできる。

ＱｏＳ情報は、１つ以上のＱｏＳレベルを定めることができ、ＱｏＳレベルは、前記構成モジュールに対する１つ以上の所定の構成パラメータと関連付けることができる。

例えば、１つ以上のＱｏＳレベルは、少なくとも、クライアントを低レイテンシ・モード（即ち、小さいバッファ・サイズ、小さいセグメント・オフセット開始）で構成するための１つ以上の（予め構成された）構成パラメータを定めるＱｏＳ（低レイテンシ）レベル、およびクライアントを高レイテンシ・モード（即ち、大きなバッファ・サイズ、大きなセグメント・オフセット開始）で構成するための１つ以上の（予め構成された）構成パラメータを定めるＱｏＳ（高レイテンシ）レベルを含むことができる。高レイテンシ・モードまたはレベルは、「正規」(regular)レイテンシ・レベルまたはモードと呼ばれることもあり、この場合、インターネットのような非管理ネットワークを通じてセグメント化コンテンツを引き出すときに一般的に使用する（例えば、「正規に」）デフォルト・レベルまたはモードに関係付けることができる。したがって、サービス品質情報は、監視システムまたはクライアントにおいて予め構成されている場合もある、異なる構成パラメータの集合と関連付けられてもよい。このように、予想ＱｏＳレベル（低、中間、高）に関連付けられたＱｏＳ情報を含むメッセージを構成モジュールに送ることにより、ＨＡＳクライアントのある種の（低、中間、高）レイテンシ・モードを選択することができる。ＱｏＳ情報に基づいて、構成モジュールは、予め構成された１組の構成パラメータを選択し、クライアントを構成するためにこれらを使用することができる。

このように、過度に大きな（過剰な寸法に作られた）プレイアウト・バッファによるプレイアウト遅延を低減することができる。ある実施形態では、サーバ・システムが、ＱｏＳ情報が構成モジュールに送られる前に、これを処理することもできる。ＱｏＳ情報の更に詳細な例、およびＷｏＳ情報の処理については、以下で説明する。

ストリーミングの間、監視システムは、ストリーミング・パスの品質メトリックを集め、品質データベースにおけるＱｏＳクライアント・プロファイルを更新することができる。これらのメトリックは、連続的に、周期的に、または所定の時点において集めることができる。

ストリーミング・パスのＱｏＳレベルが所定量だけ低下または上昇した場合、新たな品質メトリックに基づいて、クライアントを構成モジュールによって再構成することができる。このために、一実施形態では、クライアントは、規則的に（周期的に）品質メトリックの更新要求をサーバ・システムまたは監視システムに送るように構成することができる。一実施形態では、更新要求はマニフェスト・ファイルの要求に関係するのでもよく、マニフェスト・ファイルは、現在の品質メトリック、ＱｏＳ情報、および／またはストリーミング・パスに関連付けられた構成パラメータを含めばよい。

他の実施形態では、監視システムはストリーミング・パスのＱｏＳレベルの変化を監視することもできる。このような変化が検出された場合、監視システムは品質メトリックの更新をトリガーし、ストリーミング・パスに関連付けられた品質メトリック、ＱｏＳ情報、および／または構成パラメータをコンテンツ処理デバイスに、別の通信チャネル（例えば、ＨＴＴＰ−ベース通信チャネル）を通じて送ることができる。一実施形態では、この通信チャネルは、ストリーミング・パスと関連付けられた（双方向）ＨＡＳ制御チャネルに関係することができる。ＨＡＳ制御チャネルの詳細については、以下で図９を参照しながら更に詳細に説明する。このように、バッファおよび／またはセグメント要求機能は、変化するネットワーク条件（および関連するＱｏＳレベルの変化）に応答して動的に調節することができる。

構成モジュールがプレイアウト・バッファを構成するために、一実施形態では、ＱｏＳ情報をマニフェスト・ファイルにおいてクライアントに送ることができる。この場合、好ましくは、構成モジュールはＨＡＳクライアントの一部であってもよい。クライアントがサーバ・システムに（ライブ）ストリーミング・イベントに加入することを要求すると、ストリーミング・パスを確立することができ、この要求に応答して、このストリーミング・パスに関連付けられたＱｏＳ情報を含むマニフェスト・ファイルをクライアントに送ることができる。他の実施形態では、ＱｏＳ情報を別個にマニフェスト・ファイルからクライアントにＨＴＴＰ／ＴＣＰ接続を介して送ることもできる。

図２は、本発明の実施形態にしたがってメトリックを集めるプロセスを示す。具体的には、図２は、セグメントをＨＡＳクライアントにストリーミングするプロセスの少なくとも一部を示し、この場合、クライアントはセグメントをサーバ・システムから引き出すためにマニフェスト・ファイルを使用し、１つ以上の監視エージェントが、このＨＡＳクライアントとストリーミング・サーバとの間にあるストリーミング・パスに関連付けられた品質メトリックを集めることができる。このストリーミング・プロセスは、ＨＡＳクライアントが所定のセグメント（この場合、segment_high-1.mp4）を求める（ＨＴＴＰ）要求をサーバ・システムに送るステップを含むことができ（ステップ２０２）、サーバ・システムが、要求されたセグメント（の一部）を含む（ＨＴＴＰ）応答をクライアントに送ることによって、この要求に応答することができ（ステップ２０４）、クライアントは、受信したデータを処理して、これらのデータがデコードされユーザに提示される前に、メディア・プレーヤに関連付けられたプレイアウト・バッファにデータを送る（ステップ２０６）ことができる。

このプロセスの間、コンテンツ処理デバイスにおける監視エージェントは、ＨＡＳクライアント、プレイアウト・バッファ、およびメディア・エージェントからデバイス品質メトリックを集め（ステップ２０８）、この情報をＱｏＳ報告において監視サーバに送る（ステップ２１０）ことができ、監視サーバはこの報告を使用して、品質データベースにおけるＱｏＳクライアント・プロファイルを更新する（ステップ２１１）ことができる。このプロセスは、コンテンツ処理デバイスにおけるバッファおよびセグメント要求機能の設定を決定するために使用することができる（履歴）品質メトリックを含むストリーミング・パスのＱｏＳクライアント・プロファイルを監視サーバが集めて構築することができるように、ストリーミング・プロセス全域にわたって繰り返す（例えば、ステップ２１２〜２２４を参照のこと）ことができる。一実施形態では、監視エージェントは、デバイス・メトリックを監視システムに送る前に、多数の要求されたセグメントについてのデバイス品質メトリックを集めることができる。

監視エージェントは、異なるタイプのメトリックを集めて測定することができ、これらのメトリックは、デバイス・タイプ、データ・タイプ、プロトコル／コデック・タイプ、ネットワーク・タイプ、アクセス技術タイプ等に関してメトリックを品質データベースに分類するために監視システムによって使用することができるメタデータも含むことができる。実施形態では、品質メトリックは、適応ストリーミング・プロセスに関連付けられたメトリックを含むことができ、例えば、マニフェスト・ファイル番号、コンテンツ・プロファイル、コンテンツの名称、コンテンツの説明、指定されたプレイアウト期間、初期プロファイル、発生元(originating)サーバ・マニフェスト、発生元サーバ・セグメント、リディレクト回数、ビット・レート上昇変化、ビット・レート下降変化、バッファされたセグメントの数、受信したセグメント、要求したセグメント、バッファ・アンダーラン、セグメント受信バイト、セグメント・プロファイル・ビットレート、セグメント・リード・ビットレート、プロファイルよりも低いセグメントｎｒリード・ビットレート、セグメント・タイムアウトの回数、セグメント不良の数、受信バッファおよび／またはプレイアウト・バッファにおけるセグメントの数が上げられる。

他の実施形態では、品質メトリックは、アクセス技術に関連付けられた情報、例えば、アクセス技術のタイプ（Cable、ＤＳＬ、ファイバ等）、アクセス・ラインのタイプ（ＶＤＳＬ、ＡＤＳＬ等）、これらのアクセス・ラインに関連付けられた典型的な遅延および／または帯域幅を含むことができる。

更に他の実施形態では、品質メトリックは、コンテンツ処理デバイスに関連付けられた情報、例えば、連番、コンテンツ処理デバイスの製造業者、および／またはチップセット識別子を含むこともできる。他の実施形態では、メトリックは、コンテンツ処理デバイスにおけるハードウェアの利用度に関連付けられた情報、例えば、利用可能な空きメモリ、ＣＰＵ利用度、および／または信号強度を含むこともできる。更に他の実施形態では、メトリックは、アクセス・ネットワークおよび／またはプラットフォームを識別するための識別子を含むこともできる。

一実施形態では、品質メトリックは、ネットワークに関連付けられた情報を含むことができ、同じネットワーク・リソースを共有するユーザの数による負荷に関連付けられたスループット、欠落したパケット、ビット・エラー、キューまたは輻輳によるレイテンシ、ジッタ、および異なるパケットが異なる順序で宛先に到達するおそれがあるという事実による順序狂い遅延(out-of-order delay)を含む。

更に他の実施形態では、監視エージェントが、MPEG DASH ISO/IEC 23001-6に定められる、ＤＡＳＨ（品質）メトリックにしたがって、ストリーミング・プロセス（少なくとも部分的に）に関連付けられたデバイス品質メトリックを監視して集めることもできる。この文書における「ＤＡＳＨメトリック」と題する付録Ｄは、種々のＤＡＳＨ（品質）メトリック、即ち、ＴＣＰ接続、ＨＴＴＰ要求／応答トランザクション、表現切り替えイベント、バッファ・レベル、およびプレイ・リストを指定する。

例えば、一実施形態では、ＨＡＳクライアントの入力において、監視エージェントが複数組のＴＣＰ接続（ＩＰアドレス、開始、接続、および閉鎖時間）、１つ以上の送信されたＨＴＴＰセグメント要求（各々、送信時刻、コンテンツ、およびＴＣＰ接続によって定められる）、および要求されたセグメントを含む１つ以上の受信ＨＴＴＰ応答（各々、応答メッセージの受信時刻、応答ヘッダの内容、および応答本体の各バイトの受信時刻によって定められる）を監視することができる。

他の実施形態では、監視エージェントは、ＨＡＳクライアントの出力において１つ以上のエンコードされた（ＭＰＥＧ）フレームを監視することもできる（エンコードされたフレームは、メディア・タイプ、識別子、デコーディング時刻、提示時刻、および／または配信時刻によって定めることができる）。同様に、メディア・エンジンにおいて、監視エージェントが、１つ以上のデコードされた（ＭＰＥＧ）フレーム（各々、メディア・タイプ、フレームの提示タイムスタンプ、およびデコードされたフレーム（またはその一部）の実際の提示時刻によって定められる）を監視することもできる。

一旦監視エージェントによってメトリックが集められると、報告プロセスが行われ、監視エージェントは、集めたメトリックをサーバに送信する。

本発明の実施形態では、これらの集められたメトリックは、ＨＴＴＰ ＧＥＴまたはＨＴＴＰ ＰＯＳＴ要求のＵＲＩ内部に、パラメータとして挿入される。ＨＴＴＰ ＧＥＴまたはＨＴＴＰ ＰＯＳＴ要求は、集められたメトリックを報告するために使用することができる。図１０は、バッファ・レベル・メトリックに関するこのような要求１００１、１００２の例を示す。

本発明による代替実施形態では、メトリックは、監視エージェントによって、ＨＴＴＰ ＰＯＳＴ またはＨＴＴＰ ＰＵＴ要求において報告することもできる。図１１は、バッファ・レベル・メトリックに関するこのような要求１１０３、１１０４の例を示す。

一実施形態では、メトリックを記述するためにＪＳＯＮフォーマットが利用される。更に他の実施形態では、メトリックはＸＭＬフォーマットにしたがって書かれる。図１２は、バッファ・レベル・メトリックを収容するこのような要求１２０５、１２０６のフォーマット例を示す。

図１１の要求例において、この要求の第１ラインにおけるＵＲＩは、サーバ上で作成されるファイルの名称を表す。したがって、例えば、図１２に詳細を示すフォーマットにしたがって、しかるべき拡張子、.xmlまたはJsonが与えられる。

他の実施形態では、集められたメトリックは、WebSocketを介して返送され報告される。一旦監視エージェントとサーバとの間にWebSocketを介した接続が確立されると、集められたメトリックは監視エージェントによってサーバに送信される。

他の実施形態では、集められたメトリックは、監視エージェントによってファイルに書き込まれ、次いでサーバに送られる。ファイルの移送は、例えば、ＦＴＰ、ＦＴＰＳ、ピア・ツー・ピア（例えば、Bittorent）、ＳＦＴＰ、ＳＣＰによって行うことができる。ファイルは、例えば、図１２に示すような、ＸＭＬまたはＪＳＯＮフォーマットで書き込むことができる。WebSocketが使用される場合、base64でファイルをエンコードし、ＨＴＴＰメッセージの本体に挿入することができる。ＨＴＴＰメッセージは、WebSocket接続を介して、監視エージェントによってサーバ（システム）に送ることができる。

図３は、本発明の一実施形態によるマニフェスト・ファイルの少なくとも一部の模式図を示す。具体的には、図３は、ＱｏＳ情報および構成パラメータを含むマニフェスト・ファイルの少なくとも一部（この例では、ＭＰＥＧ ＤＡＳＨ ＭＰＤの一部）を示し、コンテンツ処理デバイスにおける構成モジュールによって、プレイアウト・バッファおよびセグメント要求機能を構成するために使用することができる。

この特定実施形態では、マニフェスト・ファイルは、第１ＱｏＳレベル（例えば、「高レイテンシ」または「正規」モード）３１０と、第２ＱｏＳレベル（「低レイテンシ」モード）３１２とを含むＱｏＳ情報を含むことができる。第１ＱｏＳレベルは、非管理メットワークを通じてストリーミングするときに適したＨＡＳクライアントの従来の設定に関連付けられた構成パラメータを含む正規モード３１０を定めることができる。第２ＱｏＳレベルは、管理されたネットワークを通じてストリーミングするときに適したＨＡＳクライアントの低レイテンシ設定に関連付けられた構成パラメータを含む低レイテンシ・モード３１２を定めることができる。

ＱｏＳ情報および関連する構成パラメータを含むマニフェスト・ファイルは、マニフェスト・ファイルにおいてＨＡＳクライアントに送ることができ、ＨＡＳクライアントはこのマニフェスト・ファイルを解析し、ＱｏＳ情報および構成パラメータを構成モジュールに送ることができる。構成モジュールは、この情報およびパラメータを格納する。

ストリーミング・パスの現在の品質メトリックに基づいて、監視システムまたは構成モジュールは、例えば、正規モードまたは低レイテンシ・モードを選択することができる。

尚、本発明から逸脱することなく、品質メトリック、ＱｏＳ情報、および／または構成パラメータの使用には、多くの異形が可能であることを具申する。例えば、一実施形態では、マニフェスト・ファイルが、現在の品質メトリックに関連付けられた構成パラメータのみを含むのでもよく、これらはバッファおよび／またはセグメント要求機能を構成するために構成モジュールによって使用される。他の実施形態では、マニフェスト・ファイルは、構成パラメータを全く含まずに、（予想）ＱｏＳレベルを通知するためのＱｏＳ情報だけを含むのでもよい（例えば、正規モードまたは低レイテンシ・モード）。ＱｏＳレベルは、構成モジュールによって、予め構成された１組の構成パラメータを選択するために使用することができ、構成パラメータは、コンテンツ処理デバイスのメモリにローカルに格納される。更に他の実施形態では、マニフェスト・ファイルが、ストリーミング・パスに関連付けられた品質メトリックを含むのでもよい。

品質メトリックは、ＱｏＳレベルを判定しこのＱｏＳレベルに基づいて予め構成された構成パラメータを選択するため、あるいは品質メトリックに基づいて１つ以上の構成パラメータを直接決定するために、構成モジュールによって使用することができる。本発明の実施形態では、このような品質メトリックは、サービス品質に関係する１つ以上のパラメータとすることができ、ＱｏＳパラメータとも呼ばれる。このようなＱｏＳパラメータは、例えば、保証された帯域幅、パケット逸失率、遅延、ジッタに関係することができるが、これらに限定されるのではない。図１３は、ＱｏＳパラメータの形態で品質メトリックを含むＭＰＤの一例を示す。ＭＰＤにおけるこれらのＱｏＳパラメータの例は、次の通りである。
MinGuaranteedBandwidth：クライアントが予想できる最少帯域幅（この例では、ビット／秒単位）。
MaxGuaranteedBandwidth : クライアントが予想できる最大帯域幅（この例では、ビット／秒単位）。
PacketLossRatelnPercent : トラフィック履歴に基づくパケット逸失の割合。
Delay: クライアントとコンテンツ引き出しノード（例えば、ストリーミング・サーバ／キャッシュ）との間におけるレイテンシ。この例では、ミリ秒単位で与えられる。
Jitter: クライアントとコンテンツ引き出しノード（例えば、ストリーミング・サーバ／キャッシュ）との間におけるジッタ。この例では、ミリ秒単位で与えられる。

一実施形態では、構成パラメータは、所望のプレイアウト・バッファ構成を達成するために、 ISO standard ISO/IEC 23001-6において定められるＭＤＰパラメータまたはＭＤＰパラメータの組み合わせを含むことができる。例えば、最少バッファ・サイズ・パラメータ「minBufferTime」３１４、３１８は、バッファにおけるデータのプレーアウトが開始される前のバッファの最少サイズを設定するための構成パラメータとして使用することができる（例えば、正規モードでは５秒のサイズ、そして低レイテンシ・モードでは１秒のサイズ）。

他の実施形態では、構成パラメータは、提案提示遅延パラメータ「suggestedPresentationDelay」３１６、３２０を含むことができる。このパラメータは、マニフェスト・ファイルにおいて示される所定のセグメントのプレイアウト時間に加えて、プレイアウト遅延を導入するようにＨＡＳクライアントを構成するために使用することができる。例えば、マニフェスト・ファイルにおける情報が、セグメントを１２：１０にプレイアウトする必要があり、パラメータsuggestedPresentationDelayが００：１０に設定されると判定した場合、セグメントは、１０秒後、即ち、１２：２０にプレイアウトする。

更に他の実施形態では、構成パラメータは、セグメント要求機能がストリーミング・サーバに要求する、マニフェスト・ファイルにおいて識別されたセグメントから最初のセグメントを判定するためのセグメント開始パラメータ「segmentStartOffset」３２４、３２６を含むことができる。

このパラメータは、クライアントがライブ・ストリーミング・イベントに加入したときにコンテンツ・ソースによって入手可能にされた現在のセグメントに関するオフセットを定めることができる。例えば、サーバ・システムにおけるストリーミング・サーバが現在のセグメント１０００を作成したのでもよい。しかしながら、クライアントが現在のセグメント１０００に基づいてプレイアウトを開始する場合、セグメント１００１が未だ入手可能でないので、十分なサイズのバッファを構築することは不可能である。このために、ＱｏＳレベルが低いまたは中間のネットワークにおいて問題が発生するおそれがあり、その場合、クライアントがセグメント１００１を適時に受信することを保証できない。

この問題に対処するために、「segmentStartOffset」パラメータを設定することができる。このパラメータを１、２、または３にそれぞれ設定すると、セグメント要求機能は、セグメント９９９、９９８、または９９７に基づいて、即ち、ユーザがライブ・ストリーミング・イベントに加入したときにソースにおいて入手可能であった、現在のセグメント１０００よりも早く生成されたセグメントに基づいて、プレイアウトが開始されると判断する。例えば、図３において、正規モードは第１セグメントに関連付けられる。第１セグメントは、ＨＡＳクライアントがストリーミング・セッションに加入する時点においてストリーミング・サーバによって入手可能とされたセグメントよりも３セグメント遅れる。低レイテンシ・モードは、第１セグメントと関連付けられる。第１セグメントは、ＨＡＳクライアントがストリーミング・イベントに加入するときにストリーミング・ソースによって入手可能とされたセグメントよりも１セグメント遅れる。ストリーミング・パスが低ＱｏＳ（非管理）ネットワークに関連付けられることを品質メトリックが示すとき、プレイアウト・バッファによって十分なデータ（セグメント）をバッファできないというリスクを低減するために、正規モードを選択することができる。ストリーミング・パスが高ＱｏＳ（管理された）ネットワークに関連付けられることを品質メトリックが示すとき、ストリーミングにおけるレイテンシをできるだけ低減するために、低レイテンシ・モードを選択することができる。

クライアントへのマニフェスト・ファイルにおいて品質メトリック、ＱｏＳ情報および／または構成パラメータを供給する代わりに、この情報の少なくとも一部は、マニフェスト・ファイルの一部の代わりに、別の通信チャネルによってクライアントに供給することもできる。この実施形態については、図６〜図８を参照して後に更に詳細に説明する。

マニフェスト・ファイルは更に他の情報も含むことができる。例えば、マニフェスト・ファイルは、マニフェスト・タイプ・インディケータ３０２を含むことができる。マニフェスト・タイプ・インディケータ３０２は、マニフェスト・ファイルが、ときと共に変化しない静的マニフェスト・ファイル、またはときと共に変化する動的マニフェスト・ファイルのどちらであるのかを示す。例えば、一実施形態では、クライアントは、所定の時点で、例えば、周期的に、新たに更新されたマニフェスト・ファイル、またはクライアントにおいてマニフェスト・ファイルを更新するためのマニフェスト・ファイル更新を受信することができる。マニフェスト・ファイル更新は、セグメント・パスに関連付けられた、新たに更新された情報を含む。このように、ＨＡＳクライアントを、ストリーム・パスにおけるＱｏＳレベルの変化に応答して再構成することができる。

更に、マニフェスト・ファイルは、セグメント提示期間パラメータ「mediaPresentationDuriation」３０４、即ち、コンテンツ・ストリームの長さ（秒単位）、セグメント位置情報３２２、例えば、コンテンツを引き出すことができる場所を示す１つ以上のＵＲＬ、およびメディア・メタデータ、例えば、ＨＡＳファイルのタイプ、例えば、ＭＰＥＧ−ＤＡＳＨおよび／またはサービスのタイプ、例えば、ＶｏＤサービスの２０１１バージョンを示すプロファイル・パラメータ３０８を含むこともできる。

図４は、本発明の実施形態にしたがって、マニフェスト・ファイルを更新するプロセスを示す。このプロセスは、顧客がコンテンツ・プロバイダのウェブサイトを通じてライブ・ストリーミング・イベントに加入するための支払いを行うときに開始することができる。アクセス権を得た後、顧客は、ある時点において、クライアントに、ライブ・ストリーミング・イベントに加入するようにユーザ・インターフェースを通じて（例えば、プレー・ボタンを押すことによって）命令することができる。この場合、クライアントは、マニフェスト・ファイルをサーバ・システムに要求することができる。例えば、ストリーミング・イベントに関連付けられたマニフェスト・ファイルに対する要求メッセージ、例えば、ＨＴＴＰ ＧＥＴメッセージを、サーバ・システムに送ることができる（ステップ４０２）。この場合、要求メッセージは、ストリーミング・サービスを要求しているクライアントを識別するために、例えば、マニフェスト・ファイルの名称およびクライアント識別子（例えば、ＩＰアドレスおよび／またはデバイス識別子および／またはＨＴＴＰ、ＴＣＰ、またはＩＰヘッダからの任意の他の情報）を使用することができる。

要求メッセージを受信した後、サーバ・システムは、クライアント識別子に基づいて、品質データベースに問い合わせて、ストリーミング・パスに関連付けられたＱｏＳ情報を求めることができる（ステップ４０４）。このデータベースは、ＱｏＳクライアント・プロファイルを探すことができ（ステップ４０６）、そしてプロファイルが発見された場合、品質メトリックに基づいてＱｏＳ情報を判定し、この情報をサーバ・システムに送ることができる（ステップ４０８）。次いで、サーバ・システムは、（ライブ）ストリーミング・イベントに関連付けられたマニフェスト・ファイルをマニフェスト・ストレージから引き出し、ＱｏＳ情報をマニフェスト・ファイルに挿入することによってこれを修正することができる。このように、クライアント特定のマニフェスト・ファイルが作成され、これはこのクライアントに特定的であり、コンテンツ処理デバイスの最適な構成を規定するＱｏＳ情報を含む（ステップ４１０）。

図１〜図３を参照して既に詳細に説明したように、ストリーミング・パスに関連付けられた品質メトリックに基づいてコンテンツ処理デバイスを構成するために、種々のタイプの情報（品質メトリック、ＱｏＳ情報、および／または構成パラメータ）をコンテンツ処理デバイスに送ることができる。したがって、図４〜図９を参照して説明する実施形態は、ＱｏＳ情報の使用に基づいて説明するが、これらの例は品質メトリック、ＱｏＳ情報、および／または構成パラメータの使用も含む(encompass)ことを具申する。

ＱｏＳ情報を含むマニフェスト・ファイルをクライアントに送ることができる（ステップ４１２）。一実施形態では、マニフェスト・ファイルは、クライアントへのＨＴＴＰ応答メッセージにおいて送ることができ、クライアントはマニフェスト・ファイル内の情報を解析し（ステップ４１４）、ＱｏＳ情報を構成モジュール（クライアントの一部であってもよい）に転送する（ステップ４１６）ことができる。加えて、マニフェスト・ファイルは、構成パラメータも含むことができるが、必ずしもそうとは限らない。構成パラメータも構成モジュールに転送することができる（例えば、構成モジュールが未だこれらを有していない場合）。構成モジュールは、プレイアウト・バッファを構成するために、ＱｏＳ情報を使用することができる（ステップ４１８）。したがって、ストリーミング・パスおよび／またはコンテンツおよび／またはマニフェスト・ファイルにおけるクライアント特定ＱｏＳ情報は、始動遅延を最小限に抑えるようなサイズにプレイアウト・バッファを設定するために使用することができる。

このように、（ライブ）ストリーミング・イベントに加入するＨＡＳクライアントを、ストリーミング・イベントにおいて他のコンテンツ処理デバイスと一層早く同期させることができる。

図５は、本発明の一実施形態にしたがって、クライアントへのセグメントの低レイテンシ・ストリーミングを可能にするプロトコル・フローを示す。このプロセスは、図４を参照して説明したのと同様に開始することができる。ライブ・ストリーミング・イベントに加入するようにクライアントが命令された場合、マニフェスト・ファイルをサーバ・システムに要求することができる（ステップ５０２）。要求を受けると、サーバ・システムは、ストリーミング・パスに関連付けられたＱｏＳ情報を含むクライアント特定マニフェスト・ファイルを作成することができる（ステップ５０４）。マニフェスト・ファイルは、図４を参照して説明したようなプロセスにしたがって作成することができる。

ＱｏＳ情報を含むクライアント特定マニフェスト・ファイルは、クライアントに送ることができ（ステップ５０６）、クライアントはマニフェスト・ファイル内の情報（例えば、ＱｏＳ情報、セグメント識別子、セグメント位置情報、およびセグメント・プレイアウト情報）を解析することができる（ステップ５０８）。

ＱｏＳ情報に基づいて、構成モジュール（クライアントの一部であってもよい）は、プレイアウト遅延を最小限に抑えるために、コンテンツ処理デバイスを構成することができる。このために、構成モジュールは、所定のsegmentStartOffsetパラメータと関連付けることができるＱｏＳ情報に基づいて、クライアントにおいてセグメント要求機能を構成することができる（ステップ５１０）。このように、セグメント要求機能は、ストリーミングを開始するときに要求すべき最初のセグメントを決定することができる。代わりにおよび／または加えて、構成モジュールは、プレイアウト・バッファのサイズを構成するために、所定のminBufferTimeパラメータ（構成パラメータ）と関連付けることができるＱｏＳ情報を使用してもよい。このパラメータは、バッファをしかるべく構成することができるように（ステップ５１４）、バッファに送ることができる（ステップ５１２）。

その間に、クライアントはセグメントをサーバ・システムに要求するプロセスを開始することができる。具体的には、クライアントが第１セグメント（例えば、引き出される必要があるsegment_high-2.mp4）を識別した後、位置情報、例えば、第１セグメントに関連付けられたＵＲＬを引き出すことができ、ＨＴＴＰ要求メッセージ、例えば、ＨＴＴＰ ＧＥＴメッセージをその位置（例えば、ＨＴＴＰサーバのネットワーク・アドレス）に送ることができる（ステップ５１６）。ＨＴＴＰサーバは、要求されたセグメントを含むＨＴＴＰ応答メッセージをクライアントに送る（ステップ５１８）ことによって要求に応答することができる。クライアントは、セグメント・データをアンパックしデコードして、デコードしたデータを、メディア・エンジンに関連付けられたプレイ・バッファに転送することができる（ステップ５２０）。

図６は、本発明の他の実施形態によるコンテンツ配信システムの模式図を示す。この配信システムは、図１を参照して説明したコンテンツ配信システムと同様のコンポーネントを含むことができる。即ち、サーバ・システム６０２は、コンテンツ処理デバイス６０６における少なくとも１つの（ＨＡＳ）クライアント６０４にコンテンツをストリーミングするように構成される。サーバ・システムは、１つ以上のコンテンツ信号６０８、例えば、（ライブ）ビデオおよび／またはマルチメディア信号を受信し、セグメント化コンテンツ・ストリームおよび関連するマニフェスト・ファイルを生成するためにコンテンツ信号を処理するように構成することができる。セグメント化コンテンツ・ストリームおよび関連するマニフェスト・ファイルは、それぞれ、セグメント・ストレージ６１０およびマニフェスト・ストレージ６１２に格納することができる。

（ライブ）ストリーミング・イベントに加入するとき、サーバ・システムにおける（ＨＴＴＰ）ストリーミング機能が、このストリーミング・イベントに関連付けられたマニフェスト・ファイルをクライアントに、（ＨＴＴＰ）ネットワーク接続６１４を介して送ることができる。マニフェスト・ファイルは、クライアントがセグメントをＨＴＴＰストリーミング機能に要求するために使用することができ、ＨＴＴＰストリーミング機能は、セグメントをクライアントに（ＨＴＴＰ）ネットワーク接続（ストリーミング・パス）を介して送る。ＨＴＴＰストリーミング機能は、ＨＡＳプロトコルに基づいてセグメントをクライアントに配信するように構成される。ストリーミングの間、セグメントはクライアントの受信バッファ６１８内にバッファされ、クライアントはカプセル化されたセグメント（フレーム）をアンパックし、アンパックした（ＭＰＥＧエンコードされた）データを、メディア・エンジン６２２によるデコーディングおよびプレイアウトのために、プレイアウト・バッファ６２０に配列することができる。

変化するネットワーク条件（例えば、ストリーミング・パスを通じてクライアントに送られるデータ（セグメント）に生ずる遅延）に応答して、ストリーミング・プロトコルは、セグメントのクライアントへのストリーミングの間に、表現の動的適応に対処する(allow)ことができる。

コンテンツ処理デバイスは、構成モジュール６２６を含むことができる。構成モジュール６２６は、ＱｏＳ情報に基づいて１つ以上の構成パラメータ６３４、６３５を決定するように構成される。一実施形態では、１つ以上の構成パラメータは、プレイアウト・バッファのサイズを適応させるために使用することができる。このように、バッファ・サイズは、ストリーミング・パス６１６に関連付けられた品質メトリックに基づいて制御することができる。更に、他の実施形態では、１つ以上の構成パラメータ６３５は、ライブ・ストリーミング・イベントに加入するときに要求する必要がある最初のセグメントを判定するために、クライアントにおけるセグメント要求機能６２５によって使用することができる。

監視システム６２８は、品質メトリックを１つ以上の監視エージェントから受信することができる。デバイス監視エージェント６２４は、デバイス品質メトリックをクライアント６０４、受信バッファ６１８、プレイアウト・バッファ５２０、およびメディア・エンジン６２２から集めて、これらのデバイス品質メトリックを、サーバ・システムに関連付けられた監視システム６２８に送るように構成することができる。

ネットワーク監視エージェントは、品質メトリックをネットワークから集め、これらのメトリックを特定のストリーミング・パスと相関付けるように構成することができる。品質メトリックに基づいて、監視システムは、クライアントとストリーミング・サーバとの間のストリーミング・パスに関連付けられたサービス情報の品質を判定し、品質メトリックを品質データベース６３２に格納することができる（図１を参照して説明したのと同様に）。十分なデータが集められたとき、データベースにおけるＱｏＳクライアント・プロファイルには信頼性のある品質メトリックが集められたと考えられる。

ＱｏＳクライアント・プロファイルにおける品質メトリックは、プレイアウト・バッファをあるサイズに設定するため、および／またはプレイアウト遅延が低減するようにセグメント要求機能を構成するために、コンテンツ処理デバイスにおける構成モジュールによって使用することができる。

この特定実施形態では、マニフェスト・ファイルに基づいて（図３〜図５を参照して詳細に説明したように）ＱｏＳ情報（および／または品質メトリックおよび／または構成パラメータ）はクライアントに送られない。代わりに、品質データベース（または品質データベースに関連付けられた監視システム）と構成モジュール（または構成モジュールに関連付けられたクライアント）との間に別の（双方向）通信チャネル６３６を確立し、ＱｏＳ情報の少なくとも一部を構成モジュールに送信するために使用することができる。一実施形態では、この通信チャネルは、クライアントが特定の（ライブ）ストリーミング・イベントに加入するときに設定することもできる。

一実施形態では、（ライブ）ストリーミング・イベントに加入するとき、クライアントは、品質データベース、例えば、クライアント・アクセス−ライン品質データベース（ＣＡＱＤ）の位置情報、例えば、ＵＲＬ、caqd.example.com/を含むマニフェスト・ファイルを受信することができる。 クライアント・アクセス−ライン品質データベースは、ストリーミング・パスに関連付けられた品質メトリック、ＱｏＳ情報、および／または構成パラメータを含むＱｏＳクライアント・プロファイルを含むことができる。

このようなマニフェスト・ファイルの実施形態を図７に示す。ここでは、マニフェスト・ファイルの少なくとも一部は、図３を参照して説明したのと同様の情報を含むことができ、マニフェスト・ファイルが、ときと共に変化しない静的マニフェスト・ファイル、またはときと共に変化する動的マニフェスト・ファイルのどちらであるのかを示すマニフェスト・タイプ・インディケータ７０２、セグメント提示期間パラメータ「mediaPresentationDuriation」７０４、セグメント位置情報７２０、およびメディア・メタデータ、例えば、プロファイル・パラメータ７０８を含む。

加えて、マニフェスト・ファイルは、品質データベースの位置情報、例えば、ＵＲＬ、 caqd.example.com/ </CAQDLocation>を含むことができる。この位置情報は、ＱｏＳ情報および／または品質メトリックおよび／または構成パラメータを品質データベースに要求するために、コンテンツ処理デバイスにおける構成モジュールによって使用することができる。

更に他の実施形態では、マニフェスト・ファイルは、ストリーミング・パスに関連付けられた通信チャネル、特に、（双方向）ＨＡＳ制御チャネルを設定するためのチャネル設定情報７２４、７２６を含むことができる。一実施形態では、チャネル設定情報は、ストリーミング制御機能を含むネットワーク・ノードへの参照を与えるチャネル・ターゲット・パラメータ７２４を含むことができる。更に、他の実施形態では、チャネル設定情報は、チャネル・パラメータ１４０２、即ち、ストリーミング制御機能／制御チャネル・サーバ機能によって使用されるパラメータを含むことができる。例えば、WebSocketの場合、これらのパラメータは、WebSocketサブプロトコル、WebSocketバージョン等の使用を指すことができる。ＨＡＳ制御チャネルの設定および使用については、図９を参照しながら更に詳しく説明する。

図８は、本発明の他の実施形態にしたがってセグメントをクライアントに配信するプロセスを示す。具体的には、図８は、図６および図７を参照して説明したようなコンテンツ配信システムを使用してセグメントをクライアントに配信するプロセスを示す。このプロセスは、クライアントが（ライブ）ストリーミング・イベントに加入するときに開始することができ、クライアントは、例えば、ＨＴＴＰ要求メッセージを使用して、マニフェスト・ファイルをサーバ・システムに要求し、応答して、例えば、ＨＴＴＰ応答メッセージにおいてマニフェスト・ファイルを受信することができる（ステップ８０２および８０４）。

次いで、クライアントはマニフェスト・ファイルを解析し、品質データベースに関連付けられた位置情報をマニフェスト・ファイルから抽出することができる（ステップ８０６）。位置情報、品質データベースのＵＲＬを構成モジュールに転送することができる（ステップ８０８）。構成モジュールは、位置情報を使用して、品質データベースと構成モジュール（または構成モジュールに関連付けられたＨＡＳクライアント）との間に（双方向）通信チャネルを設定することができる。通信チャネルを確立した後、構成モジュールは、品質データベースに問い合わせてＱｏＳ情報、具体的には、ストリーミング・パスの予想ＱｏＳに関する情報を求めることができる（ステップ８１０）。構成モジュールは、ＱｏＳ情報を応答において受信し、所定のＱｏＳレベル、例えば、低レイテンシ・モードを含むＱｏＳ情報に基づいて、構成モジュールにおいて構成パラメータ、例えば、予め構成された構成パラメータを決定するために、このＱｏＳ情報を使用することができる。

構成モジュールは、メディア・エンジンに関連付けられたプレイアウト・バッファを構成するための１つ以上の構成パラメータを送ることができる（ステップ８１４）。更に、構成モジュールは、１つ以上の構成パラメータを、クライアントにおけるセグメント要求機能に送ることができ（ステップ８１５）、セグメント要求機能は、パラメータを使用して、ライブ・ストリーミング・イベントに加入するときどの（最初の）セグメントを要求すべきか判定することができる（ステップ８１６）。

その後、ＨＡＳクライアントは、１つ以上の第構成パラメータに基づいて決定される（最初の）セグメントを要求し、応答においてこの要求したセグメントを受信する（それぞれ、ステップ８１８および８２０）ことによって、ストリーミング・プロセスを開始することができる。

図９は、本発明の実施形態にしたがって双方向ＨＡＳ制御チャネルを設定するための、コンテンツ処理デバイス９３０とサーバ・システム９３２との間におけるプロトコル・フローを示す。コンテンツ処理デバイスは、ＨＡＳクライアント９４８と、メディア・エンジン９４６（図１および図６を参照して説明したものと同様または同一）とを含むことができる。同様に、サーバ・システムは、クライアントＱｏＳプロファイル（図１および図６を参照して説明したものと同様または同一）を含む品質データベース９４１に接続されたＨＡＳクライアントおよび監視システム９４０にコンテンツをストリーミングするためのＨＴＴＰストリーミング機能９４２を含むことができる。

コンテンツ処理デバイスおよびサーバ・システムは、更に、制御チャネル・クライアント機能（ＣＣＣＦ）９４４と、制御チャネル・サーバ機能（ＣＣＳＦ）、例えば、ＨＡＳ制御チャネル・サーバ機能９３４とをそれぞれ含むことができる。これらは、ＣＣＳＦとＣＣＣＦ９４４との間にストリーミング制御チャネル９３６を確立するために構成される。ここで、ストリーミング制御チャネルは、クライアントとサーバとの間でストリーミング制御情報を交換するために使用することができる。具体的には、ストリーミング制御チャネルは、サーバ・システムから発してクライアントに向かうストリーミング制御情報を、セグメント化コンテンツ９３８のクライアントへのストリーミングの間送るために使用することができる。例えば、一実施形態では、ストリーミング制御チャネルは、クライアントがマニフェスト・ファイル（またはマニフェスト更新）の要求をサーバ・システムに送るように、更新マニフェスト・トリガーをサーバ・システム（または監視システム）からＣＣＣＦに送るために使用することができる。

ここで、本プロセスは、他のプロセスを参照して先に説明したのと同様に、例えば、ユーザがライブ・ストリーミング・イベントに加入するときに開始することができる（ステップ９００）。クライアントは、サーバ・システムからマニフェスト・ファイルを得るために、ＨＴＴＰ ＧＥＴ要求を送ることができ、サーバ・システムは、マニフェスト・ファイルをクライアントに送ることによって、この要求に応答することができる（ステップ９０２、９０４）。

サーバにおけるＣＣＳＦは、チャネル設定情報をマニフェスト・ファイルに挿入するように構成される。この情報は、クライアントにおけるＣＣＣＦおよびサーバにおけるＣＣＳＦがストリーミング制御チャネルを設定することを可能にする。したがって、マニフェスト・ファイルの解析（ステップ９０６）の間、チャネル設定情報をマニフェスト・ファイルから抽出し（例えば、図７参照）、サーバ−クライアント間ストリーミング制御チャネルを設定するためのチャネル設定要求をサーバにおけるＣＣＳＦに送る（ステップ９０８）ために、コンテンツ処理デバイスにおけるＣＣＣＦによって使用することができる。

一実施形態では、ＣＣＣＦおよびＣＣＳＦは、WebSocketプロトコルを使用するように構成されたＨＴＴＰ WebSocket ＡＰＩと、クライアントとサーバとの間にストリーミング制御チャネルを設定するためのチャネル設定情報とを含むことができる。WebSocket接続は、通例、データが容易にファイアウォールおよびＮＡＴを通過する(transfer)ように、標準的なＨＴＴＰポート８０および４４３を使用するが、他のポートを使用してもよい。

WebSocketプロトコルの使用には、スケーラビリティに対する低いメッセージ・オーバーヘッド、プロトコル収束およびファイアウォールの通過(traversal)のためのＨＴＴＰの使用、および他のプロトコルのトンネリングの可能性というような、ＣＤＮおよびＨＡＳのコンテキスト内では様々な利点がある。他の実施形態では、セッション開始プロトコル（ＳＩＰ）(http://tools.ietf.org/html/rfc3261)を使用することもでき、この場合、クライアントはＳＩＰユーザ・エージェントを含むことができ、サーバはＳＩＰアプリケーション・サーバである。

更に他の実施形態では、拡張可能メッセージングおよびプレゼンス・プロトコル（ＸＭＰＰ）(http://www.ietf.org/rfc/rfc3920.txt)が使用され、この場合、クライアントはＸＭＰＰクライアントを含むことができ、サーバはＸＭＰＰサーバを含む。ＳＩＰおよびＸＭＰＰプロトコル・メッセージの双方は、draft-ibc-rtcweb-sip-websocket-00およびdraft-moffitt-xmpp-over-websocket-00にしたがって、WebSocket上でトンネリングすることができる。

ストリーミング制御チャネルの設定中に、ＣＣＣＦとＣＣＳＦとの間でチャネル・パラメータを交換することができる（ステップ９１０）。更に、クライアントから発するメッセージを処理する(handle)ために、ＣＣＳＦは専用のチャネル処理プロセス（スレッド）を作成することができる（ステップ９１２）。一旦ストリーミング制御チャネルが確立されたなら（９１４）、クライアントは、マニフェスト・ファイルにおいて識別されたセグメントをストリーミングするプロセスを開始することができる。ストリーミング・プロセスは、ＨＡＳ−型ストリーミング・プロトコルに基づき、最初のセグメントsegment_low-1.aviに関連付けられたＵＲＬを含むＨＴＴＰ ＧＥＴ要求と共に開始することができる（ステップ９１６）。一旦最初のセグメントの配信がＨＴＴＰ２００ＯＫ応答によって確認されたなら（ステップ９１８）、クライアントは後続のセグメントsegment_high-2.aviを要求することができる（ステップ９２０、９２２）。

次いで、サーバ・システムにおけるＣＣＳＦは、クライアントがそのマニフェスト・ファイルを更新する必要があると判断することができる。例えば、ＣＣＳＦは、ストリーミング・パスのＱｏＳレベルが大幅に変化したので、プレイアウト・バッファのサイズ変更が望まれる可能性があるというメッセージを監視システムから受信したということがあり得る。したがって、マニフェスト更新信号をストリーミング制御チャネルを通じて送ることができる（ステップ９２４）。一実施形態では、この更新信号は、新たなＱｏＳ情報を含む新たなマニフェスト・ファイルを指し示すＵＲＬを含むことができる。マニフェスト・ファイル更新信号を受信すると、ＣＣＣＦは新たなマニフェスト・ファイルを要求することができる。新たなＱｏＳ情報を含む新たなマニフェスト・ファイルの受信時に、クライアントはＱｏＳ情報を構成モジュールに送ることができ、続いて、構成モジュールは、受信したＱｏＳ情報に基づいて、プレイアウト・バッファを再構成する。セグメントのクライアントへのストリーミングは、再構成されたプレイアウト・バッファに基づいて継続することができる。同じように、セグメント要求機能も、ＱｏＳ情報に基づいて再構成することができる。

他の実施形態では、マニフェスト・ファイルにおいてＱｏＳ情報をクライアントに送る代わりに、ＱｏＳ情報（の少なくとも一部）は、ＨＡＳ制御チャネルを通じてクライアントに送られてもよい。

一実施形態では、マニフェスト・ファイルにおいてチャネル設定情報を転送する代わりに、チャネル設定情報を予め端末にインストールしておいてもよく、または別の通信チャネルを通じて他の（ネットワーク）ソースから引き出すのでもよい。その場合、クライアントがマニフェスト・ファイルを受信したとき、ストリーミング制御チャネル・クライアント機能をトリガーして、図９のステップ９０８〜９１４を参照して説明したように、ストリーミング制御チャネルを確立するために、チャネル設定情報を引き出す。

他の実施形態では、サーバ・システムはセグメントを多数のクライアントにストリーミングするように構成することもでき、各クライアントは、図９を参照して説明したような、ネットワーク開始、例えば、サーバ開始制御を可能にするために、それ自体のストリーミング制御チャネルに関連付けられる。このように、サーバ・システムは、品質データベースに格納された品質メトリックに基づいて、セグメント化コンテンツの多数のクライアントへのストリーミングを制御することができる。サーバ・システムに関連付けられた監視システム９４０がネットワークのＱｏＳ変化を検出したとき、ＣＣＳＦにマニフェスト・ファイル更新を開始するように通知することができ、ＨＡＳクライアント（の少なくとも一部）に、新たなＱｏＳ情報を含む新たなマニフェスト・ファイルが供給され、新たなＱｏＳ情報は、プレイアウト・バッファをしかるべきサイズに再構成するために使用することができる。

尚、図は本発明の非限定的な例を描画すること、そしてこれらの図を参照して説明した実施形態は、本発明から逸脱することなく、互いに組み合わせてもよいことを具申する。例えば、実施形態では、マニフェスト・ファイルを使用して、ＱｏＳ情報、品質メトリック、および／または構成パラメータの第１部分をコンテンツ処理デバイスに送り（図１〜図４を参照して説明したように）、ＱｏＳ情報、品質メトリック、および／または構成パラメータの他の部分は、別の通信チャネルを通じて送ることができる（図６〜図９を参照して説明したように）。したがって、この場合、マニフェスト・ファイルは、ＱｏＳ情報、品質メトリック、および／または構成パラメータ（図３を参照して説明したように）、位置情報、例えば、ストリーミング・パスのＱｏＳクライアント・プロファイルを含む品質データベースに関連付けられたＵＲＬ、および／またはＨＡＳ制御チャネルを設定するためのチャネル設定情報（図７を参照して説明したように）の双方を含むことができる。

図１４は、ＨＡＳクライアント、好ましくは、ＨＡＳクライアント（デバイス）の構成モジュールがＡＬＴＯクライアント機能性を含み、ＡＬＴＯプロトコルを使用して、ネットワークにおけるＡＬＴＯサーバ／データベースに問い合わせてＱｏＳ情報を求める（１４１０）実施形態について説明する。次いで、ＡＬＴＯサーバ機能性を含むＡＬＴＯサーバ／データベースは、前記ＱｏＳ情報を含む応答（１４１２）を供給することができる。受信したＱｏＳ情報に基づいて、プレイアウト・バッファ（パラメータ）を（再）構成することができる。

更に、前述の図における実施形態は、プレイアウト・バッファの構成を参照して説明したが、本発明は、コンテンツ処理デバイスにおいて、プレイアウト遅延に寄与するいずれのタイプのバッファにも応用することができる（例えば、受信バッファ、デコーディング・バッファ等）。

尚、いずれの１つの実施形態に関して説明したいずれの特徴も、単独で、または説明した他の特徴と組み合わせて使用することができ、更に前述の実施形態の他のいずれのものの１つ以上の特徴、または前述の実施形態の他のいずれのもののいずれの組み合わせと組み合わせも使用できることは理解されてしかるべきである。本発明の一実施形態は、コンピュータシステムによる使用のためのプログラム製品として実現することができる。

プログラム製品のプログラム（１つまたは複数）は、前述の実施形態（本明細書において説明した方法を含む）の機能を定め、種々のコンピュータ読み取り可能記憶媒体に収容することができる。例示的なコンピュータ読み取り可能記憶媒体は、（ｉ）情報が永続的に格納される非書き込み可能記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内部のリード・オンリー・メモリ・デバイス、フラッシュ・メモリ、ＲＯＭチップ、または任意のタイプのソリッド・ステート不揮発性半導体メモリ）、および（ｉｉ）変化可能な情報が格納される書き込み可能記憶媒体（例えば、ディスケット・ドライブ内におけるフロッピ・ディスク、またはハード・ディスク・ドライブ、または任意のタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）を含むが、これらに限定されるのではない。本発明は、以上で説明した実施形態に限定されるのではなく、添付する請求項の範囲内で変更することができる。

Claims (15)

1. クライアント、好ましくは、ＨＡＳクライアントへのネットワークを通じたセグメントの低レイテンシ・ストリーミングをコンテンツ処理デバイスにおいて可能にする方法であって、前記クライアントが、マニフェスト・ファイルに基づいてセグメントをサーバ・システムに要求および受信するように構成され、当該方法が、
   前記ネットワークにおける監視システムが、前記クライアントと前記サーバ・システムにおける１つ以上のストリーミング・サーバとの間にある１つ以上のストリーミング・パスに関連付けられた品質メトリックを収集し、前記品質メトリックを前記ネットワークにおける品質データベースに格納するステップと、
   前記コンテンツ処理デバイスに、前記格納された品質メトリックの少なくとも一部を供給、あるいは、前記格納された品質メトリックの少なくとも一部および／または１つ以上の構成パラメータに基づいて決定されたサービス品質情報を供給するステップと、
   前記品質メトリック若しくは前記サービス品質情報の少なくとも一部、または前記構成パラメータに基づいて、前記コンテンツ処理デバイスにおける構成モジュールが、前記コンテンツ処理デバイスにおいてバッファ、好ましくは、プレイアウト・バッファ、および／または前記コンテンツ処理デバイスにおけるセグメント要求機能を構成するステップと
   を含む、方法。
2. 請求項１記載の方法であって、
   前記品質メトリックの前記少なくとも一部に基づいて、前記構成モジュールに対して前記１つ以上の構成パラメータを決定するステップを含み、前記１つ以上の構成パラメータが、
   前記バッファにおけるデータのプレイアウトが開始される前に前記バッファのサイズを決定する、少なくとも１つのバッファ・サイズ・パラメータ、好ましくは、minBufferTimeパラメータ、および／または
   前記マニフェスト・ファイルにおいて識別されたセグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する最初のセグメントを決定する、少なくとも１つのセグメント要求パラメータ、好ましくは、asegmentStartOffsetパラメータと、
   を含む、方法。
3. 請求項１または２記載の方法であって、
   前記品質メトリックに基づいて前記サービス品質情報を判定するステップであって、前記サービス品質情報が、１つ以上のＱｏＳレベルを定める、ステップを含み、前記１つ以上のＱｏＳレベルが、前記クライアントを低レイテンシ・モードに構成するための１つ以上の（予め構成された）構成パラメータに関連付けられた少なくとも低レイテンシ・レベルと、前記クライアントを高レイテンシ・モードに構成するための１つ以上の（予め構成された）構成パラメータに関連付けられた高レイテンシ・レベルとを少なくとも含む、方法。
4. 請求項１から３までのいずれか１項記載の方法において、前記１つ以上の構成パラメータおよび／または前記サービス品質情報の少なくとも一部が、前記監視システムによって決定され、前記品質データベースに格納される、方法。
5. 請求項１から４までのいずれか１項記載の方法において、前記供給するステップが、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部を前記コンテンツ処理デバイスに送るステップを含む、方法。
6. 請求項５記載の方法において、前記供給するステップが、
   前記クライアントが、マニフェスト・ファイルまたはマニフェスト・ファイル更新の少なくとも一部を前記サーバ・システムに要求するステップと、
   前記サーバ・システムが、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部を前記品質データベースから抽出し、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の前記少なくとも一部を含むマニフェスト・ファイルを前記クライアントに送るステップと、
   を含む、方法。
7. 請求項５または６記載の方法において、前記品質メトリック、前記１つ以上の構成パラメータ、および／または前記サービス品質情報の少なくとも一部が、（ＨＡＳ）ストリーミング制御チャネル、好ましくは、WebSocketベースのストリーミング制御チャネルを通じて前記クライアントに送られる、方法。
8. 請求項７記載の方法であって、
   前記サーバ・システムと前記クライアントとの間に（双方向）ストリーミング制御チャネルを設定するためのチャネル設定情報を前記クライアントに供給するステップであって、好ましくは、前記ストリーミング制御チャネルがWebSocketストリーミング制御チャネルである、ステップと、
   前記チャネル設定情報に基づいて、前記（双方向）ストリーミング制御チャネルを確立するステップと、
   を含む、方法。
9. 請求項１から８までのいずれか１項記載の方法であって、
   前記コンテンツ処理デバイスにおける少なくとも第１監視エージェントが、前記コンテンツ処理デバイスに関連付けられた第１メトリックを収集するステップ、および／または 前記ネットワークにおける少なくとも第２監視エージェントが、前記ネットワークの少なくとも一部に関連付けられた第２メトリックを収集するステップと、
   前記第１および／または第２メトリックに基づいて、前記監視システムが、前記サーバ・システムにおける前記１つ以上のストリーミング・サーバと前記クライアントとの間における１つ以上のストリーミング・パスに関連付けられた品質メトリックを判定するステップと、
   前記品質メトリックを前記品質データベースに格納するステップと、
   を含む、方法。
10. 少なくとも１つのネットワークを通じたセグメントのコンテンツ処理デバイスへの低レイテンシ・ストリーミングを可能にするコンテンツ配信システムであって、
    クライアント、好ましくはＨＡＳクライアントを含むコンテンツ処理デバイスであって、前記クライアントが、マニフェスト・ファイルに基づいて、１つ以上のストリーミング・サーバにセグメントを要求および受信するように構成された、コンテンツ処理デバイスと、
    前記コンテンツ処理デバイスが、更に、前記格納された品質メトリックの少なくとも一部、あるいは前記格納された品質メトリックおよび／または１つ以上の構成パラメータの少なくとも一部に基づいて判定されるサービス品質情報が供給されるように構成され、
    前記クライアントと前記１つ以上のストリーミング・サーバとの間における１つ以上のパスに関連付けられた品質メトリックを収集し、前記品質メトリックを前記ネットワーク内の品質データベースに格納するように構成された監視システムと、
    前記コンテンツ処理デバイスにおいてバッファ、好ましくは、プレイアウト・バッファを構成し、および／または、前記コンテンツ処理デバイスにおいてセグメント要求機能を、前記品質メトリック、前記サービス品質情報、および／または前記構成パラメータの少なくとも一部に基づいて構成する構成モジュールと
    を含む、コンテンツ配信システム。
11. コンテンツ処理デバイスにおける使用のための構成モジュールであって、前記構成モジュールが、前記コンテンツ処理デバイスにおいて、クライアント、好ましくは、ＨＡＳクライアントへの低レイテンシ・ストリーミングを可能にするように構成され、前記クライアントが、マニフェスト・ファイルに基づいて、サーバ・システムにおける１つ以上のストリーミング・サーバにセグメントを要求および受信するように構成され、前記構成モジュールが、更に、
    前記コンテンツ処理デバイスにおいてバッファ、好ましくは、プレイアウト・バッファを構成し、並びに／または、前記コンテンツ処理デバイスにおいてセグメント要求機能を、品質メトリックに基づいて、前記格納された品質メトリックの少なくとも一部に基づき判定されるサービス品質情報に基づいて、および／若しくは１つ以上の構成パラメータに基づいて、構成し、
    前記品質メトリックが、前記クライアントと前記サーバ・システムにおける１つ以上のストリーミング・サーバとの間における１つ以上のストリーミング・パスと関連付けられ、
    前記品質メトリックが、前記ネットワークにおける監視システムによって収集され、前記ネットワークにおける品質データベースに格納される、
    ように構成される、構成モジュール。
12. 請求項１１記載の構成モジュールにおいて、
    前記バッファが、１つ以上の構成パラメータ、好ましくは、minBufferTimeパラメータに基づいて、前記バッファにおいてデータのプレイアウトが開始される前に、前記バッファのサイズを決定するように構成され、および／または
    前記セグメント要求機能が、１つ以上の構成パラメータ、好ましくは、segmentStartOffsetパラメータに基づいて、前記マニフェスト・ファイルにおいて識別された前記セグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する第１セグメントを決定するように構成される、構成モジュール。
13. コンテンツ処理デバイスにおけるＨＡＳクライアントとストリーミング・サーバとの間のネットワークにおけるストリーミング・パスに関連付けられた品質メトリックを監視する監視システムであって、
    前記コンテンツ処理デバイスに関連付けられたデバイス・メトリックと、１つ以上の監視エージェントからの前記ネットワークの少なくとも一部に関連付けられたネットワーク・メトリックとを収集する手段と、
    前記デバイスおよび前記ネットワーク・メトリックに基づいて、ストリーミング・パスに関連付けられた品質メトリックを判定する手段と、
    前記品質メトリックの前記少なくとも一部に基づいて、前記コンテンツ処理デバイスにおける構成モジュールに対する１つ以上の構成パラメータを判定する手段であって、前記１つ以上の構成パラメータが、前記バッファにおけるデータのプレイアウトが開始される前に前記バッファのサイズを決定するための少なくとも１つのバッファ・サイズ・パラメータ、好ましくは、minBufferTimeパラメータ、および／または前記マニフェスト・ファイルにおいて識別された前記セグメントから選択され、前記セグメント要求機能が前記ストリーミング・サーバに要求する第１セグメントを決定するための少なくとも１つのセグメント要求パラメータ、好ましくは、asegmentStartOffsetパラメータとを含む、手段と、
    を含む、監視システム。
14. データ構造、好ましくは、コンテンツ処理デバイスにおいてクライアントによる使用のためのマニフェスト・ファイルの少なくとも一部であって、前記クライアントが、前記マニフェスト・ファイルに基づいて、少なくとも１つのサーバにセグメントを要求し受信するように構成され、前記データ構造が、前記クライアントへの低レイテンシ・ストリーミングを可能にし、前記データ構造が、１つ以上のセグメント識別子とセグメント・プレイアウト情報とを含み、前記データ構造が、更に、品質メトリック、および／または前記クライアントとストリーミング・サーバとの間におけるストリーミング・パスに関連付けられた１つ以上のＱｏＳレベルを含むサービス品質情報を含み、前記品質メトリックおよび／または前記サービス品質情報が、前記クライアントに関連付けられた構成モジュールが、バッファ、好ましくは、プレイアウト・バッファおよび／または前記コンテンツ処理デバイスにおけるセグメント要求機能に対する１つ以上の構成パラメータを決定することを可能にし、および／または前記データ構造が、更に、前記クライアントとストリーミング・サーバとの間のストリーミング・パスに関連付けられた１つ以上の構成パラメータを含み、前記１つ以上の構成パラメータは、前記コンテンツ処理デバイスにおいて、前記クライアントに関連付けられた構成モジュールが、バッファ、好ましくは、プレイアウト・バッファおよび／またはセグメント要求機能を構成することを可能にする、データ構造。
15. コンピュータ・プログラム製品であって、コンピュータのメモリにおいて実行されると、請求項１から９までのいずれか１項記載の前記方法ステップを実行するように構成されたソフトウェア・コード部分を含む、コンピュータ・プログラム製品。

Images